SymPy 0.7.1 Release Candidate 1

[Aaron Meurer]

Hi everyone.

I have made the first release candidate for SymPy 0.7.1. You can
download the source at
http://code.google.com/p/sympy/downloads/detail?name=sympy-0.7.1.rc1.tar.gz,
a Windows32 installer at
http://code.google.com/p/sympy/downloads/detail?name=sympy-0.7.1.rc1.win32.exe,
and the docs for this version at
http://code.google.com/p/sympy/downloads/detail?name=sympy-0.7.1.rc1-docs-html.zip.

The release notes are at
https://github.com/sympy/sympy/wiki/Release-Notes-for-0.7.1. I will
give this in more detail when I do the full release, but the big
changes here are that isympy now works in IPython 0.11, which will be
released soon, Pyglet is now an optional external dependency, Python
2.4 is no longer supported, and our docs use MathJax to render the
LaTeX math. There have also been several bug fixes and new
functionality (see the full release notes).

So please download the release and test it. Also, since our docs have
received a significant update with the MathJax, I ask that you also
download the docs and see if they render correctly in your broswer of
choice. Some pages that use a lot of MathJax math include
modules/simplify/hyperexpand.html, most of the mpmath documentation,
and modules/galgebra/GA/GAsympy.html. We also enabled a feature in
Sphinx that lets you view the source code of a function in the
documentation. So, next to every function definition, there should be
a "source" button which takes you to the source code of the function.

If there are no major problems, I will do the full release in about a week.

Aaron Meurer

[Vladimir Perić]

> --
> 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.
>
>

I've run the usual tests on my computer, everything seems fine. One
issue is the hyperexpand tests. They rely on random numbers so they
fail occasionally (see the SymPy-hyperexpand job on Jenkins, they fail
about 1% of the time with ness' latest patch). This is bad because
users might think this is some more important failure. On the other
hand, simply reverting the whole patchset is no good either, as it
does bring nice new features. So, if ness doesn't manage to solve it
completely in a few days it might be a good idea to apply a patch to
branch that'll use some specific numbers in the tests.

--
Vladimir Perić

[Aaron Meurer]

I'm not sure if that's a good idea. The point of the random tests is
to increase coverage. Tom, what is your opinion on this?

Aaron Meurer

[Aaron Meurer]

By the way, if someone could actually review the changes at
https://github.com/sympy/sympy/pull/491 (my mathjax branch) before the
release, that would be great. I have included it in the release
candidate, but it hasn't been fully reviewed, which I would like to
happen before releasing and merging back with master.

Aaron Meurer

[Ondřej Čertík]

I also don't like random tests, because it is not robust. I think that
random tests should be disabled by default, but can be turned on if
needed.

Ondrej

[Tom Bachmann]

>>> I've run the usual tests on my computer, everything seems fine. One
>>> issue is the hyperexpand tests. They rely on random numbers so they
>>> fail occasionally (see the SymPy-hyperexpand job on Jenkins, they fail
>>> about 1% of the time with ness' latest patch). This is bad because
>>> users might think this is some more important failure. On the other
>>> hand, simply reverting the whole patchset is no good either, as it
>>> does bring nice new features. So, if ness doesn't manage to solve it
>>> completely in a few days it might be a good idea to apply a patch to
>>> branch that'll use some specific numbers in the tests.
>>>
>>> --
>>> Vladimir Perić
>>>
>>
>> I'm not sure if that's a good idea. The point of the random tests is
>> to increase coverage. Tom, what is your opinion on this?
>
> I also don't like random tests, because it is not robust. I think that
> random tests should be disabled by default, but can be turned on if
> needed.
>

That would be one possibility; defaulting to a specific, tested seed in
release tests.

On the other hand my tests have not failed in the last >300 runs on
jenkins (since I pushed the last fix). This does not mean too much of
course.

> Ondrej
>

[Vinzent Steinberg]

On Jul 24, 4:45 pm, Tom Bachmann <e_mc...@web.de> wrote:
> That would be one possibility; defaulting to a specific, tested seed in
> release tests.
>
> On the other hand my tests have not failed in the last >300 runs on
> jenkins (since I pushed the last fix). This does not mean too much of
> course.

I think our tests should be determined by default, there should be no
randomness, because it makes it impossible to reproduce failures. (If
the test runner printed the seed and it was possible to pass the seed
to the test runner, this would be something else, but this is
currently not the case.)

So I suggest we make random tests optional for now. Having random
tests by default needs to be discussed IMHO.

Vinzent

[Ondřej Čertík]

I 100% agree.

Ondrej

[Francois Bissey]

Hi all,

I have noticed this recent python bug about linux-3.0:
http://bugs.python.org/issue12326

They also mention that any code checking for linux2 is fundamentally
broken. Looking at my sympy-0.7.0 install with grep I found:
/usr/lib64/python2.7/site-packages/sympy/thirdparty/pyglet/pyglet/lib.py:
if self.platform == 'linux2':
/usr/lib64/python2.7/site-packages/sympy/thirdparty/pyglet/pyglet/lib.py:elif
sys.platform == 'linux2':
/usr/lib64/python2.7/site-packages/sympy/galgebra/latex_ex.py: if
sys.platform == 'linux2':

Will this be addressed in 0.7.1? The suggested fix is using
sys.platform.startswith('linux') rather than variation on
sys.platform == 'linux2'

Francois

This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.

Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
information.

[Mateusz Paprocki]

Hi,

On 25 July 2011 00:32, Francois Bissey <francoi...@canterbury.ac.nz> wrote:

Hi all,

I have noticed this recent python bug about linux-3.0:
http://bugs.python.org/issue12326

They also mention that any code checking for linux2 is fundamentally
broken. Looking at my sympy-0.7.0 install with grep I found:
/usr/lib64/python2.7/site-packages/sympy/thirdparty/pyglet/pyglet/lib.py:
if self.platform == 'linux2':
/usr/lib64/python2.7/site-packages/sympy/thirdparty/pyglet/pyglet/lib.py:elif
sys.platform == 'linux2':
/usr/lib64/python2.7/site-packages/sympy/galgebra/latex_ex.py:            if
sys.platform == 'linux2':

Will this be addressed in 0.7.1? The suggested fix is using
sys.platform.startswith('linux') rather than variation on
sys.platform == 'linux2'

Thanks for pointing this out. Apparently Linux kernel 3.0 was released two days ago. Fix is trivial, we just have to change one line in galgebra, because we don't ship pyglet anymore.

 

Francois

This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.

Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
information.

--
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.

Mateusz

[Vladimir Perić]

On Sun, Jul 24, 2011 at 11:16 PM, Vinzent Steinberg
<vinzent....@googlemail.com> wrote:
> On Jul 24, 4:45 pm, Tom Bachmann <e_mc...@web.de> wrote:
>> That would be one possibility; defaulting to a specific, tested seed in
>> release tests.
>>
>> On the other hand my tests have not failed in the last >300 runs on
>> jenkins (since I pushed the last fix). This does not mean too much of
>> course.
>
> I think our tests should be determined by default, there should be no
> randomness, because it makes it impossible to reproduce failures. (If
> the test runner printed the seed and it was possible to pass the seed
> to the test runner, this would be something else, but this is
> currently not the case.)

Actually, it does print the seed now and you can pass one with
"--seed=123". This was added in commit 9210842: Implement randomised
testing.

>
> So I suggest we make random tests optional for now. Having random
> tests by default needs to be discussed IMHO.

A quick search comes up with this issue, maybe we should discuss it
there (or on the list, of course):
http://code.google.com/p/sympy/issues/detail?id=2281

>
> Vinzent

>
> --
> 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.
>
>

--
Vladimir Perić

[Mateusz Paprocki]

Hi,

On 25 July 2011 00:58, Mateusz Paprocki <mat...@gmail.com> wrote:

Hi,

On 25 July 2011 00:32, Francois Bissey <francoi...@canterbury.ac.nz> wrote:

Hi all,

I have noticed this recent python bug about linux-3.0:
http://bugs.python.org/issue12326

They also mention that any code checking for linux2 is fundamentally
broken. Looking at my sympy-0.7.0 install with grep I found:
/usr/lib64/python2.7/site-packages/sympy/thirdparty/pyglet/pyglet/lib.py:
if self.platform == 'linux2':
/usr/lib64/python2.7/site-packages/sympy/thirdparty/pyglet/pyglet/lib.py:elif
sys.platform == 'linux2':
/usr/lib64/python2.7/site-packages/sympy/galgebra/latex_ex.py:            if
sys.platform == 'linux2':

Will this be addressed in 0.7.1? The suggested fix is using
sys.platform.startswith('linux') rather than variation on
sys.platform == 'linux2'

Thanks for pointing this out. Apparently Linux kernel 3.0 was released two days ago. Fix is trivial, we just have to change one line in galgebra, because we don't ship pyglet anymore.

Pull request fixing galgebra is here: https://github.com/sympy/sympy/pull/509

 

 

Francois

This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.

Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
information.

--
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.

Mateusz

Mateusz

[Aaron Meurer]

On Sun, Jul 24, 2011 at 4:59 PM, Vladimir Perić <vlada...@gmail.com> wrote:
> On Sun, Jul 24, 2011 at 11:16 PM, Vinzent Steinberg
> <vinzent....@googlemail.com> wrote:
>> On Jul 24, 4:45 pm, Tom Bachmann <e_mc...@web.de> wrote:
>>> That would be one possibility; defaulting to a specific, tested seed in
>>> release tests.
>>>
>>> On the other hand my tests have not failed in the last >300 runs on
>>> jenkins (since I pushed the last fix). This does not mean too much of
>>> course.
>>
>> I think our tests should be determined by default, there should be no
>> randomness, because it makes it impossible to reproduce failures. (If
>> the test runner printed the seed and it was possible to pass the seed
>> to the test runner, this would be something else, but this is
>> currently not the case.)
>
> Actually, it does print the seed now and you can pass one with
> "--seed=123". This was added in commit 9210842: Implement randomised
> testing.
>
>>
>> So I suggest we make random tests optional for now. Having random
>> tests by default needs to be discussed IMHO.
>
> A quick search comes up with this issue, maybe we should discuss it
> there (or on the list, of course):
> http://code.google.com/p/sympy/issues/detail?id=2281

Yes, reproducibility was a necessity, and I wouldn't have pushed in
any random test code without it.

I think that random tests can complement regular tests, because they
can essentially increase coverage in a way that is impossible
otherwise. Of course, it's very important that they are 100%
reproducible, meaning that it should print a seed that can later be
entered, and this seed should be universally used for all random code.

Actually, I'm not really convinced that the random tests in Tom's new
code are doing a good job of "complementing" regular tests. If I
remember correctly, there were many cases where random tests were the
only tests. Perhaps the others here who are more critical of random
testing could do a quick audit of the random tests (see any test added
by Tom recently in the git history) to see how well this holds.

By the way, Tom, was the fix for the test failures included in the 0.7.1 branch?

Aaron Meurer

[Aaron Meurer]

Do you want me to include this in the release?

Aaron Meurer

[Francois Bissey]

On Sun, 24 Jul 2011 17:21:00 Aaron Meurer wrote:
> Do you want me to include this in the release?
>

That'd be nice. That way it would be done and there wouldn't be a need to
worry about it later.

[Aaron Meurer]

Well, it would go in either way, but I could either put it in this
release or in master, which would mean that it would go in the next
release.

Aaron Meurer

[François]

On Monday, July 25, 2011 11:29:12 AM UTC+12, Aaron Meurer wrote:

Well, it would go in either way, but I could either put it in this
release or in master, which would mean that it would go in the next
release.

Sooner is better in my opinion.

Francois 

[Aaron Meurer]

OK, I'll merge it in to the release.

By the way, you might want to ping the Pyglet project about the other instances.

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/sympy/-/YFN1sNTQ5q0J.

[Aaron Meurer]

So what's the best way to do this? Should I create a release
candidate 2, or should I just release? There have been a couple of
changes to 0.7.1 since 0.7.1.rc1 (The first commits here
https://github.com/sympy/sympy/commits/0.7.1 up until the "SymPy
0.7.1.rc1 release" commit). And if I create an rc2, how long should I
let that sit until I do a final release?

Note that the IPython guys *still* haven't released 0.11, and it looks
like unless we really poke around with this that we will beat them, so
there are no real worries there.

Also, it would be great if I could get some confirmation that the
Windows installer works, and that tests pass on Windows.

Finally, can someone with a Windows machine help me build a 64-bit
installer (see http://code.google.com/p/sympy/issues/detail?id=1235)?
It's fairly straightforward, but requires a Windows machine to do
(unlike the 32-bit installer, which can be made on Mac or Linux).
Otherwise, people on Windows who installed a 64-bit version of Python
will have to install from source like the rest of us.

Aaron Meurer

[Vinzent Steinberg]

On Jul 29, 12:50 am, Aaron Meurer <asmeu...@gmail.com> wrote:
> So what's the best way to do this?  Should I create a release
> candidate 2, or should I just release?  There have been a couple of

> changes to 0.7.1 since 0.7.1.rc1 (The first commits herehttps://github.com/sympy/sympy/commits/0.7.1up until the "SymPy

> 0.7.1.rc1 release" commit).  And if I create an rc2, how long should I
> let that sit until I do a final release?
>
> Note that the IPython guys *still* haven't released 0.11, and it looks
> like unless we really poke around with this that we will beat them, so
> there are no real worries there.

+1 for releasing a final. We can have a quick 0.7.2 if need be.

I just made sure that the tests pass on 64 bit Linux. (I was a bit
surprised how long it took.) The docs look also good.

Vinzent

[Aaron Meurer]

OK, I'll do the final release later today.

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups "sympy" group.