Re: [pypy-svn] r5606 - in pypy/trunk/src/pypy: module objspace/std
benyoung@codespeak.net writes:
Added some more of the the __r...__ functions to complex. Made the objectsapce return complex object rather than cpython wrap them. I think this is the correct behaviour.
I don't understand how you managed to check this in... for one thing, I'd already done it, and for another, cpythonobject is dead on the trunk! Cheers, mwh -- I also fondly recall Paris because that's where I learned to debug Zetalisp while drunk. -- Olin Shivers
On Thursday 22 July 2004 15:57, Michael Hudson wrote:
benyoung@codespeak.net writes:
Added some more of the the __r...__ functions to complex. Made the objectsapce return complex object rather than cpython wrap them. I think this is the correct behaviour.
I don't understand how you managed to check this in... for one thing, I'd already done it, and for another, cpythonobject is dead on the trunk!
Sorry, I guess I didn't introduce myself properly. Holger Krekel gave me an account on codespeak after we had a number on discussions about the implemention on complex objects in pypy. I'm sorry if I have done the wrong thing! Apart from the __r...__ methods the problem was that complex objects appearing in the consts section of the bytecode were being wrapped as cpythonobjects (as they were at the time) rather than producing instances of the class in __builtin__module.py. This was producing lots of weird effects ( 1+2j == complex(1, 2) => False ). Now I am not sure what the fix should have been! Sorry if I have caused any confusion. I won't commit anything again until I have talked it over more fully! Ben ---
Cheers, mwh
Hello Ben, [Ben Young Thu, Jul 22, 2004 at 04:07:55PM +0100]
On Thursday 22 July 2004 15:57, Michael Hudson wrote:
benyoung@codespeak.net writes:
Added some more of the the __r...__ functions to complex. Made the objectsapce return complex object rather than cpython wrap them. I think this is the correct behaviour.
I don't understand how you managed to check this in... for one thing, I'd already done it, and for another, cpythonobject is dead on the trunk!
Sorry, I guess I didn't introduce myself properly. Holger Krekel gave me an account on codespeak after we had a number on discussions about the implemention on complex objects in pypy. I'm sorry if I have done the wrong thing! Apart from the __r...__ methods the problem was that complex objects appearing in the consts section of the bytecode were being wrapped as cpythonobjects (as they were at the time) rather than producing instances of the class in __builtin__module.py. This was producing lots of weird effects ( 1+2j == complex(1, 2) => False ). Now I am not sure what the fix should have been!
Sorry if I have caused any confusion. I won't commit anything again until I have talked it over more fully!
Actually i should have checked your commits and supported you some more. But we have a few EU project negotiation turmoils going on so i didn't really get to any coding recently. cheers, holger
On Thursday 22 July 2004 16:14, holger krekel wrote:
Hello Ben,
[Ben Young Thu, Jul 22, 2004 at 04:07:55PM +0100]
On Thursday 22 July 2004 15:57, Michael Hudson wrote:
benyoung@codespeak.net writes:
Added some more of the the __r...__ functions to complex. Made the objectsapce return complex object rather than cpython wrap them. I think this is the correct behaviour.
I don't understand how you managed to check this in... for one thing, I'd already done it, and for another, cpythonobject is dead on the trunk!
Sorry, I guess I didn't introduce myself properly. Holger Krekel gave me an account on codespeak after we had a number on discussions about the implemention on complex objects in pypy. I'm sorry if I have done the wrong thing! Apart from the __r...__ methods the problem was that complex objects appearing in the consts section of the bytecode were being wrapped as cpythonobjects (as they were at the time) rather than producing instances of the class in __builtin__module.py. This was producing lots of weird effects ( 1+2j == complex(1, 2) => False ). Now I am not sure what the fix should have been!
Sorry if I have caused any confusion. I won't commit anything again until I have talked it over more fully!
Actually i should have checked your commits and supported you some more. But we have a few EU project negotiation turmoils going on so i didn't really get to any coding recently.
Thats ok. Amost as soon as I decided I would dedicate some time to learn more about pypy and see if there was anything I could do to help as load more of my "proper" work came up and it turned out I had time to do very little! At the moment it seems to be quite hard to keep up with some of the changes as some major subsystems still seem to be a state of flux, so I may go back to being a bit of a lurker until it is obvious what I can do to help! Cheers! Ben ---
cheers,
holger _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Ben Young
On Thursday 22 July 2004 15:57, Michael Hudson wrote:
benyoung@codespeak.net writes:
Added some more of the the __r...__ functions to complex. Made the objectsapce return complex object rather than cpython wrap them. I think this is the correct behaviour.
I don't understand how you managed to check this in... for one thing, I'd already done it, and for another, cpythonobject is dead on the trunk!
Sorry, I guess I didn't introduce myself properly. Holger Krekel gave me an account on codespeak after we had a number on discussions about the implemention on complex objects in pypy. I'm sorry if I have done the wrong thing! Apart from the __r...__ methods the problem was that complex objects appearing in the consts section of the bytecode were being wrapped as cpythonobjects (as they were at the time) rather than producing instances of the class in __builtin__module.py. This was producing lots of weird effects ( 1+2j == complex(1, 2) => False ). Now I am not sure what the fix should have been!
No, there's no problem with what you did, it's just that I'd already done it, and I'm surprised svn let you check your changes in without failing some kind of up-to-date check. (Certainly, running svn up before checking in is a good idea...).
Sorry if I have caused any confusion. I won't commit anything again until I have talked it over more fully!
Don't worry about it! (Though as Armin said, running the testsuite *is* appreciated...) Cheers, mwh -- surely, somewhere, somehow, in the history of computing, at least one manual has been written that you could at least remotely attempt to consider possibly glancing at. -- Adam Rixey
On Thursday 22 July 2004 16:18, Michael Hudson wrote:
Ben Young
writes: On Thursday 22 July 2004 15:57, Michael Hudson wrote:
benyoung@codespeak.net writes:
Added some more of the the __r...__ functions to complex. Made the objectsapce return complex object rather than cpython wrap them. I think this is the correct behaviour.
I don't understand how you managed to check this in... for one thing, I'd already done it, and for another, cpythonobject is dead on the trunk!
Sorry, I guess I didn't introduce myself properly. Holger Krekel gave me an account on codespeak after we had a number on discussions about the implemention on complex objects in pypy. I'm sorry if I have done the wrong thing! Apart from the __r...__ methods the problem was that complex objects appearing in the consts section of the bytecode were being wrapped as cpythonobjects (as they were at the time) rather than producing instances of the class in __builtin__module.py. This was producing lots of weird effects ( 1+2j == complex(1, 2) => False ). Now I am not sure what the fix should have been!
No, there's no problem with what you did, it's just that I'd already done it, and I'm surprised svn let you check your changes in without failing some kind of up-to-date check.
(Certainly, running svn up before checking in is a good idea...).
I didn't get any conflicts running svn up. Hmm, weird.
Sorry if I have caused any confusion. I won't commit anything again until I have talked it over more fully!
Don't worry about it! (Though as Armin said, running the testsuite *is* appreciated...)
I have the test suite failing anyway at the moment, with errors seemingly unrelated to my fix. raceback (most recent call last): File "./test_all.py", line 7, in ? testit.main(tool.autopath.pypydir) File "/home/benyoung/pypy/pypy/tool/testit.py", line 385, in main run_tests(suite) File "/home/benyoung/pypy/pypy/tool/testit.py", line 347, in run_tests run_tests_on_space(suite, spacename) File "/home/benyoung/pypy/pypy/tool/testit.py", line 361, in run_tests_on_space runner.run(suite) File "/home/benyoung/pypy/pypy/tool/testit.py", line 222, in run result = unittest.TextTestRunner.run(self, test) File "/usr/lib/python2.3/unittest.py", line 658, in run test(result) File "/home/benyoung/pypy/pypy/tool/testit.py", line 26, in __call__ result = unittest.TestSuite.__call__(self, result) File "/usr/lib/python2.3/unittest.py", line 389, in __call__ test(result) File "/home/benyoung/pypy/pypy/tool/testit.py", line 26, in __call__ result = unittest.TestSuite.__call__(self, result) File "/usr/lib/python2.3/unittest.py", line 389, in __call__ test(result) File "/home/benyoung/pypy/pypy/tool/testit.py", line 26, in __call__ result = unittest.TestSuite.__call__(self, result) File "/usr/lib/python2.3/unittest.py", line 389, in __call__ test(result) File "/home/benyoung/pypy/pypy/interpreter/unittest_w.py", line 161, in __call__ return IntTestCase.__call__(self, result) File "/home/benyoung/pypy/pypy/interpreter/unittest_w.py", line 86, in __call__ self._answer(result, result.addError) File "/home/benyoung/pypy/pypy/interpreter/unittest_w.py", line 70, in _answer errorfn(self, self._TestCase__exc_info()) File "/home/benyoung/pypy/pypy/tool/testit.py", line 82, in addError if isinstance(err[1], OperationError) and test.space.full_exceptions: AttributeError: 'AppTestFunction' object has no attribute 'space' Is this my fault then? Sorry if it is! Cheers Ben ---
participants (3)
-
Ben Young
-
holger krekel
-
Michael Hudson