gmpy moving to code.google.com

[aleaxit at gmail.com]

On Feb 27, 9:10 am, "Daniel Nogradi" <nogr... at gmail.com> wrote:
> > > Hi Alex,
>
> > > I did another test, this time with python 2.4 on suse and things are
> > > worse than in the previous case (which was python 2.5 on fedora 3),
> > > ouput of 'python gmp_test.py' follows:
>
> > Interesting!  gmpy interacts with decimal.Decimal by "monkey-
> > patching" that class on the fly; clearly the monkey-patching isn't
> > working with 2.4 on SuSE, so all the addition attempts are failing
> > (all 6 of them).
>
> > So the issue is finding out why this strategy is failing there, while
> > succeeding on other Linux distros, Mac, and Windows.
>
> > To that end, I have added a feature in the latest svn trunk (revision
> > 11) to set gmpy's own options.debug flag from an environment variable
> > named GMPY_DEBUG at startup (if that environment variable is set).
>
> > If you could please svn up and rebuild, then running with GMPY_DEBUG
> > set in the environment should give something like:
>
> > brain:~/gmpy alex$ GMPY_DEBUG=1 python -c 'import gmpy' 2>&1 | tail -5
> > mp_allocate( 4->8 )
> > mp_allocate( 4->8 ) ->0x60b8b0
> > gmpy_module at 0x63390
> > gmpy_module imported decimal OK
> > gmpy_module tweaked decimal OK
>
> > This is the expected behavior when module decimal is present, while,
> > when it's absent, you should see something like:
>
> > brain:~/gmpy alex$ GMPY_DEBUG=1 python2.3 -c 'import gmpy' 2>&1 |
> > tail -5
> > Initing new not in zcache
> > mp_allocate( 4->8 )
> > mp_allocate( 4->8 ) ->0x3017d0
> > gmpy_module at 0x6de70
> > gmpy_module could not import decimal
>
> > In each case, what matters is the last line or two after "gmpy_module
> > at" -- the rest of the copious debugging output is irrelevant here.
>
> > Module decimal is expected to be present from 2.4 forward (though it
> > could also be explicitly installed on 2.3).  However, from the test
> > failures you report, it looks like SuSE's 2.4 does not have decimal
> > available for importing when gmpy is starting up -- so I'd like to
> > confirm that first.
>
> > If it's confirmed, it will be interesting to discover how this
> > happens (but that requires a SuSE installation, which I don't have)
> > and secondarily what is gmpy to do about it -- maybe offer a warning
> > on startup when module decimal is unexpectedly not importable but
> > then skip the relevant unittests in that case?  (Note that the tests
> > ARE already skipped if module decimal is not importable _at test
> > time_ -- what's really weird is that apparently on SuSE decimal CAN
> > be imported by the tests but CANNOT be imported earlier while gmpy is
> > loading, which is truly puzzling).
>
> > I'd appreciate reports about this behavior on as many Python/Linux
> > installations as possible -- yours, of course (to check my guess that
> > the problem is that decimal can't be imported while gmpy is loading),
> > but also others' (to see how widespread the problem is, etc, etc).
>
> > Thanks again for reporting this, and thanks in advance to anybody
> > who'll lend a hand in tracking down this little strangeness!!!
>
> Okay, here is a summary. The notation is:
>
> platform version python version debug unittest
>
> where debug will be either 'pass' or 'fail' if that particular
> platform and python version passes or fails the GMPY_DEBUG=1
> importing/tweaking test. Unittest will also be 'pass' or 'fail' if the
> full unittesting passes or fails respectively.
>
> Fedora 3 python 2.5                pass    pass
> Fedora 3 python 2.4                pass    fail
> Fedora 3 python 2.3.4             fail       pass
> Suse 9.3 python 2.4                pass    fail
> Suse 10 python 2.4.1              pass    pass
> Suse 10.2(64bit) python 2.5     pass    fail
>
> The output from each test is zipped and you can grab it from here:http://lorentz.leidenuniv.nl/~nogradi/gmpy_test.zip

Thanks for all the testing!  So, Ziga's next post explains that the
2.4 problems are 2.4.0 bugs fixed since 2.4.1 -- I don't think I can
do anything about in gmpy, nor (I think) even if I could should I go
to great complications to support old, known-buggy, easily upgradable
(I hope) releases of Python.

The 2.5 issues have nothing to do with decimal -- they _do_ have to do
with 64-bit builds:

For the hash(z) issue, I think I know what to do -- instead of
claiming I know what the hash value should be (which clearly I don't
when it can be either a 32-bit or 64-bit build:-), I'll just claim
that the hash value
of z is the same as the the hash value of long(z).

I have svn committed that change (svn repository for gmpy is now at
revision 14) -- could you please svn up and run the tests again
(ideally after updating the Python 2.4 installations to 2.4.1 or
better, but that's minor, what I'd really need to see would be the
results on the 64-bit build... thanks!


I _am_ a bit surprised at the other failure, the one of:

ix(_g.mpz(sys.maxint)) == sys.maxint

where ix is operator.index -- particularly considering that the other
tests around that one succeed (e.g., the identical one using
sys.maxint + 1).  Maybe that's an actual bug of 1.02 on a 64-bit build
of Python.

Could you please tell me, on that 64-bit build, what happens with:

>>> import gmpy, sys, operator
>>> sys.maxint
???
>>> gmpy.mpz(sys.maxint)
???
>>> operator.index(gmpy.mpz(sys.maxint))
???
>>> sys.maxint+1
???
>>> gmpy.mpz(sys.maxint+1)
???
>>> operator.index(gmpy.mpz(sys.maxint)+1)
???

i.e., what are the values correspondiing to the ??? occurrences when
you actually do that...?


Thanks again


Alex