current master woes

[smichr]

I ran into some problem when trying to do some simple rebasing and so
I just went to master and attempted an interactive rebase of the last
11 commits. Two problems occur:

1) 46 commits show up for editing instead of 11
2) as the rebase is proceeding it stops here with an error:

$ git r11
Automatic cherry-pick failed. After resolving the conflicts,
mark the corrected paths with 'git add <paths>', and
run 'git rebase --continue'
Could not apply c1cd078... No longer import raises() with "from sympy
import *"

I'm not sure what the problem is.

/c

[smichr]

I also get the following doctest failures under windows 32 bit

________________________________________________________________________________

_____________ sympy.physics.secondquant.AntiSymmetricTensor.lower
______________

File "C:\documents and settings\chris\sympy\sympy\physics
\secondquant.py", line
10, in sympy.physics.secondquant.AntiSymmetricTensor.lower
Failed example:
AntiSymmetricTensor('t', (a, b), (i, j))
Expected:
AntiSymmetricTensor(t, Tuple(a, b), Tuple(i, j))
Got:
-AntiSymmetricTensor(t, Tuple(b, a), Tuple(i, j))
**********************************************************************
File "C:\documents and settings\chris\sympy\sympy\physics
\secondquant.py", line
12, in sympy.physics.secondquant.AntiSymmetricTensor.lower
Failed example:
AntiSymmetricTensor('t', (a, b), (i, j)).lower
Exception raised:
Traceback (most recent call last):
File "C:\Python26\lib\doctest.py", line 1241, in __run
compileflags, 1) in test.globs
File "<doctest
sympy.physics.secondquant.AntiSymmetricTensor.lower[5]>", l
ine 1, in <module>
AntiSymmetricTensor('t', (a, b), (i, j)).lower
AttributeError: 'Mul' object has no attribute 'lower'
________________________________________________________________________________

_____________ sympy.physics.secondquant.AntiSymmetricTensor.symbol
_____________

File "C:\documents and settings\chris\sympy\sympy\physics
\secondquant.py", line
10, in sympy.physics.secondquant.AntiSymmetricTensor.symbol
Failed example:
AntiSymmetricTensor('t', (a, b), (i, j))
Expected:
AntiSymmetricTensor(t, Tuple(a, b), Tuple(i, j))
Got:
-AntiSymmetricTensor(t, Tuple(b, a), Tuple(i, j))
**********************************************************************
File "C:\documents and settings\chris\sympy\sympy\physics
\secondquant.py", line
12, in sympy.physics.secondquant.AntiSymmetricTensor.symbol
Failed example:
AntiSymmetricTensor('t', (a, b), (i, j)).symbol
Exception raised:
Traceback (most recent call last):
File "C:\Python26\lib\doctest.py", line 1241, in __run
compileflags, 1) in test.globs
File "<doctest
sympy.physics.secondquant.AntiSymmetricTensor.symbol[5]>",
line 1, in <module>
AntiSymmetricTensor('t', (a, b), (i, j)).symbol
AttributeError: 'Mul' object has no attribute 'symbol'
________________________________________________________________________________

_____________ sympy.physics.secondquant.AntiSymmetricTensor.upper
______________

File "C:\documents and settings\chris\sympy\sympy\physics
\secondquant.py", line
10, in sympy.physics.secondquant.AntiSymmetricTensor.upper
Failed example:
AntiSymmetricTensor('t', (a, b), (i, j))
Expected:
AntiSymmetricTensor(t, Tuple(a, b), Tuple(i, j))
Got:
-AntiSymmetricTensor(t, Tuple(b, a), Tuple(i, j))
**********************************************************************
File "C:\documents and settings\chris\sympy\sympy\physics
\secondquant.py", line
12, in sympy.physics.secondquant.AntiSymmetricTensor.upper
Failed example:
AntiSymmetricTensor('t', (a, b), (i, j)).upper
Exception raised:
Traceback (most recent call last):
File "C:\Python26\lib\doctest.py", line 1241, in __run
compileflags, 1) in test.globs
File "<doctest
sympy.physics.secondquant.AntiSymmetricTensor.upper[5]>", l
ine 1, in <module>
AntiSymmetricTensor('t', (a, b), (i, j)).upper
AttributeError: 'Mul' object has no attribute 'upper'
________________________________________________________________________________

_________________ sympy.physics.secondquant.NO.has_q_creators
__________________

File "C:\documents and settings\chris\sympy\sympy\physics
\secondquant.py", line
20, in sympy.physics.secondquant.NO.has_q_creators
Failed example:
no_pq.has_q_creators
Exception raised:
Traceback (most recent call last):
File "C:\Python26\lib\doctest.py", line 1241, in __run
compileflags, 1) in test.globs
File "<doctest sympy.physics.secondquant.NO.has_q_creators[9]>",
line 1, i
n <module>
no_pq.has_q_creators
AttributeError: 'Mul' object has no attribute 'has_q_creators'

Bisection shows that the first bad commit is

HEAD is now at 9644e55... Merge branches 'Abs', 'imports2',
'copyright', 'github
_docs', '1946', 'property_doctests', 'exprsphinx', '2137',
'mpmath-0.16', 'pytho
n24', 'sysfix' and 't_symbol'


Note that the bisection didn't really "bisect"...it crept along moving
about 1 commit at a time. I wonder why that would be?

chris@CSMITH ~/sympy (master|BISECTING)
$ git co 9f91d07
Note: moving to '9f91d07' which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at 9f91d07... Updated preview to use mode keyword instead
of old inl
ine boolean

chris@CSMITH ~/sympy ((9f91d07...)|BISECTING)
$ git bisect good
Bisecting: 46 revisions left to test after this (roughly 5 steps)
[9644e55facd82b6c1f0efdd9876e1e86696f064e] Merge branches 'Abs',
'imports2', 'co
pyright', 'github_docs', '1946', 'property_doctests', 'exprsphinx',
'2137', 'mpm
ath-0.16', 'python24', 'sysfix' and 't_symbol'

chris@CSMITH ~/sympy ((9644e55...)|BISECTING)
$ git bisect bad
Bisecting: 23 revisions left to test after this (roughly 5 steps)
[27bc1edb7a667285736d9fd8b07edc0e3d7e1b83] secondquant: remove
redundant try..ex
cept

chris@CSMITH ~/sympy ((27bc1ed...)|BISECTING)
$ git bisect good
Bisecting: 19 revisions left to test after this (roughly 4 steps)
[b31b57d96b902793d0e34c52a5e5cb977c866cbc] Import all in matrices.py

chris@CSMITH ~/sympy ((b31b57d...)|BISECTING)
$ git bisect good
Bisecting: 16 revisions left to test after this (roughly 3 steps)
[3f59381c33fbb1cf815b99ec1b56f17d2d713f43] Correctly import the plots
in the mpm
ath Sphinx docs

chris@CSMITH ~/sympy ((3f59381...)|BISECTING)
$ git bisect good
Bisecting: 14 revisions left to test after this (roughly 3 steps)
[0484c49932512892ea438d51c4e160b00450e3e9] Use spaces in the
interactive import
symbols() calls

chris@CSMITH ~/sympy ((0484c49...)|BISECTING)
$ git bisect good
Bisecting: 12 revisions left to test after this (roughly 3 steps)
[a056e92b8eed91f92ed5b58243737c4e1feaf7c8] Use the DeprecationWarning
builtin fo
r the Python 2.4 deprecation warning

chris@CSMITH ~/sympy ((a056e92...)|BISECTING)
$ git bisect good
Bisecting: 10 revisions left to test after this (roughly 3 steps)
[04691e0d4a0457097dfa5978973ce5f9d3aa3de0] Line wrap a test in
test_complex.py

chris@CSMITH ~/sympy ((04691e0...)|BISECTING)
$ git bisect good
Bisecting: 8 revisions left to test after this (roughly 3 steps)
[cd27ed42e7250a403521496e2ea03ca53dbd5d77] Add info about my 2010 GSoC
project t
o the aboutus file

chris@CSMITH ~/sympy ((cd27ed4...)|BISECTING)
$ git bisect good
Bisecting: 6 revisions left to test after this (roughly 2 steps)
[324ba9d3063d7ed1bbb118e90747df70c7d47381] Fix some issues with Abs,
and fix imp
orted docstrings in functions.txt

chris@CSMITH ~/sympy ((324ba9d...)|BISECTING)
$ git bisect good
Bisecting: 5 revisions left to test after this (roughly 2 steps)
[898540ab18c22750b99d4474c26fe4483c00ff33] Prevent sys from being
imported into
the namespace with "from sympy import *"

chris@CSMITH ~/sympy ((898540a...)|BISECTING)
$ git bisect good
Bisecting: 4 revisions left to test after this (roughly 2 steps)
[1d534e1b2a17bc031e9b94621a5a95dbaf1dd391] Fix the docstring of
as_numer_denom()
and add Expr to the Sphinx docs

chris@CSMITH ~/sympy ((1d534e1...)|BISECTING)
$ git bisect good
Bisecting: 3 revisions left to test after this (roughly 1 steps)
[51246adba5c46cf671605762c01b787cdfad1f45] Fix Issue 1947: @property
methods are
not doctested

chris@CSMITH ~/sympy ((51246ad...)|BISECTING)
$ git bisect good
Bisecting: 2 revisions left to test after this (roughly 1 steps)
[1a0028ae01f5ef08803db77106486f9bc0e7cbf5] Use "isinstance(b, (int,
long))" inst
ead of "type(b) is int" in numbers.py

chris@CSMITH ~/sympy ((1a0028a...)|BISECTING)
$ git bisect good
Bisecting: 1 revisions left to test after this (roughly 1 steps)
[2a6140e8f9fd34a5891168ebdaf9cb2b664e6dd3] Replace git.sympy.org with
github in
the docs

chris@CSMITH ~/sympy ((2a6140e...)|BISECTING)
$ git bisect good
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[f79a0dd64b31521dfa78e6df3f6047e641cd4290] Move ast parsing related
files from s
ympy/core to sympy/parsing

chris@CSMITH ~/sympy ((f79a0dd...)|BISECTING)
$ git bisect good
9644e55facd82b6c1f0efdd9876e1e86696f064e is first bad commit

[Aaron S. Meurer]

Are you sure this isn't issue 2041? What Python version is this with?
Your paths indicate that it is Python 2.6. If this is 2.6.6, then it
is issue 2041 (which hasn't been pushed in yet because it hasn't been
reviewed).

There are some doctest failures that came up in master because of
issue 1947, but they weren't these.

This is because I merged those branches into master, instead of
rebasing, so it has to check each branch for the problem. Look at the
history in gitk or do git log --graph to see what I mean.

This is one disadvantage of merging as opposed to rebasing I suppose.
The advantage though is that you preserve each commit's history
exactly, and in this case, the advantage was that it was a much easier
way to push in a dozen branches.

Aaron Meurer

> --
> You received this message because you are subscribed to the Google
> Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+un...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en
> .
>

[Aaron S. Meurer]

There is something wrong with your rebasing procedure. You are trying
to rebase the commits that are already in master for some reason.

What exact commands are you using to rebase?

Aaron Meurer

Sent from my iPod touch.

[Øyvind Jensen]

lø., 15.01.2011 kl. 11.59 -0700, skrev Aaron S. Meurer:
> Are you sure this isn't issue 2041? What Python version is this with?
> Your paths indicate that it is Python 2.6. If this is 2.6.6, then it
> is issue 2041 (which hasn't been pushed in yet because it hasn't been
> reviewed).
>
> There are some doctest failures that came up in master because of
> issue 1947, but they weren't these.

To me it looks like another set of hash-dependent doctests in
secondquant. The patches that got in recently changed the code in some
way that made the hash dependency apparent. I will propose a fix ASAP.

Øyvind

[Chris Smith]

Aaron S. Meurer wrote:
>> There is something wrong with your rebasing procedure. You are trying
>> to rebase the commits that are already in master for some reason.
>>
>> What exact commands are you using to rebase?

Let's say I have about 6 commits that I want to rebase. I have shortcuts for 11, 22, 33 commits, etc, so I issue the one for 11:

rebase -i head~11

This (presently) picks up 46 rather than 11. Usually commits that aren't marked for editing or squashing just rebase quietly but now the rebase stops on some commits of master that need adjusting. Is this because merge was used instead of rebase?

/c

[Aaron S. Meurer]

OK, that is what I thought you might be doing. You shouldn't do this. git rebase master is a better way to achieve what you want. The problem with doing what you are doing is that rebase tries to convert merge commits into a linear history, and in this case, it is trying to do it with merge commits that are already in master.

You *might* also avoid it by adding the -p option to rebase, but really your best bet is to just issue git rebase master. You want to rebase your commits on top of master, so this is exactly the command to do it.

Aaron Meurer

[smichr]

The branch jeger/fix_doctests3 does not raise any errors under win32.
However, rewriting the test is a shallow fix of the problem which
appears to be that -Object.method has tigher binding on the negation
that it does on the method so that -AntiSymmetricTensor().symbol gives
an error because Mul (note the preceding minus sign) doesn't have a
symbol method. Is there any way to fix this so .symbol is evaluated
before the Mul?

[Øyvind Jensen]

But how can you do that without implementing a Mul.symbol method?

Øyvind

[Chris Smith]

I'm not sure but it works for count_ops:

h[2] >>> (x+y).count_ops()
ADD
h[3] >>> -(x+y).count_ops()
-ADD

The count_ops is evaluated before the negation. I see that your AntiSymmetricTensor derives from Tensor which derives from Expr. I don't understand class behavior well enough to say why your method of AST is being applied to the Mul rather than the AST.

Could you store the sign within AST in some way?

/c

[Øyvind Jensen]

This dosn't work because the AST constructor sometimes returns a Mul
before the method has any chance to be applied.

>
> Could you store the sign within AST in some way?

That would be the solution I guess, but I think it is a too complicated
design change just before the 7.0 release.

As you pointed out in the other post, the constructor has some redundant
lines and the cleanup you suggest works. Are you going to place a pull
request?

Øyvind

>
> /c
>

[Chris Smith]

Øyvind Jensen wrote:
> As you pointed out in the other post, the constructor has some
> redundant
> lines and the cleanup you suggest works. Are you going to place a
> pull request?
>

sure...I'll put it in with 1917's pull

/c

[Øyvind Jensen]

Chris, was this after all a positive review of https://github.com/sympy/sympy/pull/85
?