sage-5.9.beta0 released

[Jeroen Demeyer]

Dear Sage lovers,

We're releasing Sage 5.9.beta0.

Source archive:

http://boxen.math.washington.edu/home/release/sage-5.9.beta0/sage-5.9.beta0.tar

Upgrade path:

http://boxen.math.washington.edu/home/release/sage-5.9.beta0/sage-5.9.beta0/

The source and upgrade path can also be found on the mirror network
(you might need to wait a while before the mirrors are synchronized):

http://www.sagemath.org/download-latest.html


Please build, test, and report! We'd love to hear about your
experiences with this release.

== Tickets ==

* We closed 31 tickets in this release. For details, see

http://boxen.math.washington.edu/home/release/sage-5.9.beta0/tickets.html

Closed tickets:

#4750: make it so sage -t foo.sage pulls in the preparsed version of all
the code in foo.sage before doctesting foo.py; make it so "sage -t
foo.py" has an option to pull in all code from foo.py before doctesting
it. [Reviewed by David Roe]
#8699: allow doctest coverage script to handle triple single quotes
[Reviewed by Minh Van Nguyen, Mike Hansen]
#8708: allow doctest script to handle docstrings with triple single
quotes [Reviewed by John Palmieri, Burcin Erocal]
#9225: New doctesting features [Reviewed by David Roe, Jeroen Demeyer]
#9273: doctest elliptic_curves/BSD.py reports "file not found" [Reviewed
by Jeroen Demeyer]
#9772: unify doctest commands, especially for 'long' and 'parallel'
options [Reviewed by Jeroen Demeyer]
#11336: Update doctest tolerance to work with print statement. [Reviewed
by Jeroen Demeyer]
#11338: Fix signals/interrupts in sage-doctest [Reviewed by Jeroen Demeyer]
#13928: Problematic file filter in skip() from sage-ptest [Reviewed by
Nils Bruin, John H Palmieri]

Merged in sage-5.9.beta0:

#2235: Jeroen Demeyer: doctest issue -- combining # long and # 32-bit /
# 64-bit [Reviewed by David Roe]
#11863: Anna Haensch, Frédéric Chapoton: Bilinear Map [Reviewed by
Kannappan Sampath]
#12415: David Roe, Robert Bradshaw, Jeroen Demeyer: Update doctesting
framework [Reviewed by Jeroen Demeyer, David Roe]
#12708: Punarbasu Purkayastha: limit not correctly computed by maxima
[Reviewed by Karl-Dieter Crisman]
#12828: Stephen Montgomery-Smith: get_memory_usage and top under FreeBSD
[Reviewed by Karl-Dieter Crisman]
#13209: Kannappan Sampath: Fix some minor Cayley table documentation
problems [Reviewed by Karl-Dieter Crisman]
#13262: Sebastien Gouezel: Update doctests after bug correction in pynac
[Reviewed by Burcin Erocal]
#13351: Jean-Pierre Flori: Cannot import sage.libs.lcalc.lcalc_Lfunction
[Reviewed by Dmitrii Pasechnik]
#13424: Christian Stump, Gregg Musiker: Compute Mutation Class for
Cluster Algebra Seed or Cluster Quiver [Reviewed by Gregg Musiker,
Salvatore Stella]
#13432: R. Andrew Ohana: add sage/env.py and fix many inappropriate
references to SAGE_ROOT [Reviewed by François Bissey]
#13729: Burcin Erocal, Sebastien Gouezel: Update pynac to 0.2.6
[Reviewed by François Bissey]
#13743: Travis Scrimshaw: Bug in k-bounded symmetric functions [Reviewed
by Mike Zabrocki]
#14079: Jeroen Demeyer: Cython interface to pselect() system call
[Reviewed by Volker Braun]
#14175: Volker Braun, Nicolas M. Thiéry: More plot options for polytopes
[Reviewed by Volker Braun, Nicolas M. Thiéry]
#14197: Chris Berg, Christian Stump: Add map from PerfectMatchings to
Permutations. Fix string representation in perfect matchings. [Reviewed
by Alejandro Morales, Christian Stump]
#14238: Nathann Cohen: a polyhedron() method for Linear Programs
[Reviewed by Dmitrii Pasechnik]
#14241: Timo Kluck: Patch to FLINT fails to apply because of double path
separator // in filenames [Reviewed by Leif Leonhardy]
#14242: Jeroen Demeyer: Race condition in gap_reset_workspace()
[Reviewed by Volker Braun]
#14251: Nathann Cohen: Circulant digraphs [Reviewed by David Coudert]
#14253: Jeroen Demeyer: sage.misc.sage_ostools.have_program: use
os.access() [Reviewed by David Roe]
#14257: Nathann Cohen: Implements the Wells graph [Reviewed by Dmitrii
Pasechnik]
#14263: John Palmieri: if build fails, print message about which spkgs
failed [Reviewed by Volker Braun]

[Michael Welsh]

On 19/03/2013, at 2:00 AM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
>
> Please build, test, and report! We'd love to hear about your
> experiences with this release.

A few test failures on OS X 10.8.3, which disappeared upon rerunning the test.

----------------------------------------------------------------------
sage -t --long devel/sage/sage/tests/cmdline.py # 5 doctests failed
----------------------------------------------------------------------

There was also this message a couple of times, appearing in between tests.
/Applications/sage-devel/local/lib/python2.7/site-packages/Cython/Build/Dependencies.py:229: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
if code[q-1] == u'\\':

[Michael Orlitzky]

On 03/18/2013 09:00 AM, Jeroen Demeyer wrote:
> Dear Sage lovers,
>
> We're releasing Sage 5.9.beta0.
>

> ...

>
> Please build, test, and report! We'd love to hear about your
> experiences with this release.

Whose idea was it to turn the prompt dark blue? =)

I tried deleting ~/.sage to no avail.

[Volker Braun]

The IPython color scheme... switch the background to white in your terminal unless you have an old CRT monitor with low refresh rate. Before you send us an email objecting to this read Bauer, D. & Cavonius, C. R. (1980): Improving the legibility of visual display units through contrast reversal.

[Michael Orlitzky]

On 03/18/2013 08:36 PM, Volker Braun wrote:
> The IPython color scheme... switch the background to white in your
> terminal unless you have an old CRT monitor with low refresh rate.
> Before you send us an email objecting to this read Bauer, D. & Cavonius,
> C. R. (1980): Improving the legibility of visual display units through
> contrast reversal.

Did you really just try to cite a reference to tell me that my personal
preference is wrong?

[Volker Braun]

Yes, I tried to preempt that discussion ;-)

Alternatively you can just use the standard IPython configuration system: create a file ~/.sage/ipython-0.12/profile_sage/ipython_config.py with the content:

c = get_config()

c.TerminalInteractiveShell.colors = 'NoColor'

Or on the Sage prompt:

 sage: %colors NoColor

[John H Palmieri]

On Monday, March 18, 2013 6:39:19 PM UTC-7, Volker Braun wrote:

Yes, I tried to preempt that discussion ;-)

Alternatively you can just use the standard IPython configuration system: create a file ~/.sage/ipython-0.12/profile_sage/ipython_config.py with the content:

c = get_config()

c.TerminalInteractiveShell.colors = 'NoColor'

or

  c.TerminalInteractiveShell.colors = 'Linux'

if you want to try a different color scheme.

--
John

 

[Michael Orlitzky]

On 03/18/2013 09:39 PM, Volker Braun wrote:
> Yes, I tried to preempt that discussion ;-)

If you're trying to maximize the average legibility, sure, go for
white-on-black. But I'm not. I'm trying to maximize mine. And it's
configurable -- has been since I was a baby -- so anything that doesn't
handle that is busted.

More-practical reasons:

1) These are the default terminal colors in a lot of places. I only
set $PS1 here.

2) For every sage, there are 10 other console apps that will assume
a dark-on-light theme. Like, say, ipython, which has 'Linux' as its
default color scheme. Someone patched it to his personal
preference in sage.

3) There's already a better way to do console colors. The console has
a palette that is guaranteed to be usable. Git uses this with great
success. This is an ipython problem I guess -- there should be a
safe default option that uses the console palette.

The 'NoColor' scheme is the most degenerate of safe defaults, since it
will at least use the text color from the console's palette. It just
doesn't use anything *but* the text color. In any case, we're going to
get a lot of bug reports if we have a default that's broken out of the
box on 25% of machines.

> Alternatively you can just use the standard IPython configuration
> system: create a file
> ~/.sage/ipython-0.12/profile_sage/ipython_config.py with the content:
>
> c = get_config()
> c.TerminalInteractiveShell.colors = 'NoColor'
>
> Or on the Sage prompt:
>
> sage: %colors NoColor
>

Ah, that's it. For what it's worth, I did try to create that file with,

c.InteractiveShell.colors = 'NoColor'

according to,

http://ipython.org/ipython-doc/dev/config/ipython.html

Is that out of date?

[François]

On Tuesday, March 19, 2013 2:00:07 AM UTC+13, Jeroen Demeyer wrote:

Dear Sage lovers,

We're releasing Sage 5.9.beta0.

Source archive:

http://boxen.math.washington.edu/home/release/sage-5.9.beta0/sage-5.9.beta0.tar

Upgrade path:

http://boxen.math.washington.edu/home/release/sage-5.9.beta0/sage-5.9.beta0/

The source and upgrade path can also be found on the mirror network
(you might need to wait a while before the mirrors are synchronized):

http://www.sagemath.org/download-latest.html


Please build, test, and report!  We'd love to hear about your
experiences with this release.

OK, just built it and it seems to work fine (OK I wanted to add numpy-1.7.0 on top

but let's leave that for a moment). I haven't completed the tests but the new doctesting

framework has a behavior I didn't expect.

I usually run batch of tests (mostly because of sage-on-gentoo) like this:

 nohup ./sage -tp --long devel/sage-main/sage &

or variation thereof. And I get a log in nohup.out at the end. I know there

are other ways, this is just my current workflow that worked quite well over

several years.

The new doctesting framework doesn't like it at all:

 Running doctests with ID 2013-03-19-14-52-17-1032e799.

Sorting sources by runtime so that slower doctests are run first....

Doctesting 1857 files using 8 threads.

Process DocTestWorker-1:

Traceback (most recent call last):

  File "/home/work/fbissey/sandbox/sage-5.9.beta0/local/lib/python/multiprocessing/process.py", line 258, in _bootstrap

    self.run()

  File "/home/work/fbissey/sandbox/sage-5.9.beta0/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 1655, in run

    sys.stdin = os.fdopen(0, "r")

OSError: [Errno 22] Invalid argument

Process DocTestWorker-2:

Traceback (most recent call last):

  File "/home/work/fbissey/sandbox/sage-5.9.beta0/local/lib/python/multiprocessing/process.py", line 258, in _bootstrap

    self.run()

  File "/home/work/fbissey/sandbox/sage-5.9.beta0/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 1655, in run

    sys.stdin = os.fdopen(0, "r")

OSError: [Errno 22] Invalid argument

etc... You get the idea. Is it in any way fixable or do I have to do something different from now on.

Francois

[Volker Braun]

On Monday, March 18, 2013 10:20:48 PM UTC-4, Michael Orlitzky wrote:

If you're trying to maximize the average legibility, sure, go for
white-on-black. But I'm not. I'm trying to maximize mine.

All major Linux distros and all commercial unices have defaulted to white background for ages, precisely because usability studies say its the best choice for most. Thats a fact, and not my personal preference.

And its configurable, so if you are color blind or fall out of the norm otherwise then you can change things. 

 

[Justin C. Walker]

On Mar 18, 2013, at 06:00 , Jeroen Demeyer wrote:

> Dear Sage lovers,
>
> We're releasing Sage 5.9.beta0.
>
> Source archive:
>
> http://boxen.math.washington.edu/home/release/sage-5.9.beta0/sage-5.9.beta0.tar

Built w/o problems on two Mac OS X systems (10.6.8/Dual 6-core Xeons, 10.8.2/Quad-core Core i7), and all tests ('ptestlong') passed on each system.

Justin

--
Justin C. Walker, Curmudgeon-At-Large, Director
Institute for the Enhancement of the Director's Income
--------
The path of least resistance:
it's not just for electricity any more.
--------

[Jeroen Demeyer]

Please create a ticket and CC me.

[Francois Bissey]

Yeah I got that one about unicode too on Linux.

Francois

[Jeroen Demeyer]

On 2013-03-19 09:32, Francois Bissey wrote:
> Yeah I got that one about unicode too on Linux.

It's a known issue but we (i.e. David Roe and me) decided to ignore that
warning for now, since fixing it would be some work. Anyway, there is a
ticket:
http://trac.sagemath.org/sage_trac/ticket/14153

[Andrey Novoseltsev]

I've "make ptestlong"ed 5.9.beta0 yesterday, all tests passed, but
this morning I've discovered two running ecl processes still running
and consuming all memory (the machine has 16Gb RAM, swap use went up
to 18Gb). This has never happened before:

novoselt@sage:~$ ps -eF |grep ecl
novoselt 21122 1 2 2458547 7056900 0 Mar18 ? 00:35:15 /home/
novoselt/sage-5.9.beta0/local/bin/ecl
novoselt 21131 1 2 2458516 7137532 0 Mar18 ? 00:33:44 /home/
novoselt/sage-5.9.beta0/local/bin/ecl
novoselt 32461 31910 0 1958 840 0 08:34 pts/0 00:00:00 grep
ecl

[John Cremona]

Exactly the same happened to me: 2 rogue ecl processes consuming lots
of RAM. This is on ubuntu, same set us worked fine with 5.8 at the
same time.

John

> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-release...@googlegroups.com.
> To post to this group, send email to sage-r...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-release?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[kcrisman]

On Tuesday, March 19, 2013 11:16:21 AM UTC-4, John Cremona wrote:

Exactly the same happened to me: 2 rogue ecl processes consuming lots
of RAM.  This is on ubuntu, same set us worked fine with 5.8 at the
same time.

So likely candidates are... #12415? 

[François Bissey]

I have two weird doctest failures on Gentoo linux (64bit) and
this is _not_ a sage-on-gentoo install:
sage -t --long devel/sage-main/sage/schemes/elliptic_curves/gal_reps.py # Bad
exit: 1
sage -t --long devel/sage-main/sage/misc/interpreter.py # 1 doctest failed

For the first one I have:
sage -t --long devel/sage-main/sage/schemes/elliptic_curves/gal_reps.py

Process DocTestWorker-1:
Traceback (most recent call last):
File
"/home/work/fbissey/sandbox/sage-5.9.beta0/local/lib/python/multiprocessing/process.py",
line 258, in _bootstrap
self.run()
File "/home/work/fbissey/sandbox/sage-5.9.beta0/local/lib/python2.7/site-

packages/sage/doctest/forker.py", line 1677, in run
task(self.options, self.outtmpfile, msgpipe, self.result_queue)
File "/home/work/fbissey/sandbox/sage-5.9.beta0/local/lib/python2.7/site-
packages/sage/doctest/forker.py", line 1966, in __call__
result_queue.put(result, False)
File
"/home/work/fbissey/sandbox/sage-5.9.beta0/local/lib/python/multiprocessing/queues.py",
line 102, in put
raise Full
Full
Bad exit: 1


.... lots of stuff...

sage: sig_on_count() ## line 1537 ##
0
sage: rho = EllipticCurve('27a2').galois_representation() ## line 1558 ##
sage: rho.is_potentially_semistable(3) ## line 1559 ##
True
sage: sig_on_count() ## line 1561 ##
0

so it fails in that area.

The second one, weirdly enough gives more error when run individually:
sage -t --long devel/sage-main/sage/misc/interpreter.py
**********************************************************************
File "devel/sage-main/sage/misc/interpreter.py", line 150, in
sage.misc.interpreter.sage_prompt
Failed example:
shell.run_cell('sage_prompt()')
Expected:
u'sage'
Got:
u'sage'
**********************************************************************
File "devel/sage-main/sage/misc/interpreter.py", line 187, in
sage.misc.interpreter.SageInteractiveShell.system_raw
Failed example:
shell.system_raw('R --version')
Expected:
R version ...
Got:
WARNING: ignoring environment value of R_HOME
R version 2.15.2 (2012-10-26) -- "Trick or Treat"
Copyright (C) 2012 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
Platform: x86_64-unknown-linux-gnu (64-bit)
<BLANKLINE>
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under the terms of the
GNU General Public License versions 2 or 3.
For more information about these matters see
http://www.gnu.org/licenses/.
<BLANKLINE>
**********************************************************************
File "devel/sage-main/sage/misc/interpreter.py", line 566, in
sage.misc.interpreter.interface_shell_embed
Failed example:
shell.run_cell('List( [1..10], IsPrime )')
Expected:
[ false, true, true, false, true, false, true, false, false, false ]
Got:
[ false, true, true, false, true, false, true, false, false, false ]
**********************************************************************
3 items had failures:
1 of 15 in sage.misc.interpreter.SageInteractiveShell.system_raw
1 of 4 in sage.misc.interpreter.interface_shell_embed
1 of 4 in sage.misc.interpreter.sage_prompt
[107 tests, 3 failures, 2.4 s]

The log I have only showed the R error. I am guessing the R_HOME problem
is gentoo specific as I have a R_HOME variable in my shell coming from the
system install of R, we may want to override that in sage-env. The other two
could be unicode related. I may try the unicode patch next.

Francois

[Michael Orlitzky]

On 03/18/2013 10:50 PM, Volker Braun wrote:
> On Monday, March 18, 2013 10:20:48 PM UTC-4, Michael Orlitzky wrote:
>
> If you're trying to maximize the average legibility, sure, go for
> white-on-black. But I'm not. I'm trying to maximize mine.
>
>
> All major Linux distros and all commercial unices have defaulted to
> white background for ages, precisely because usability studies say its
> the best choice for most. Thats a fact, and not my personal preference.

Cooommmmeee onnnn. Did you think I wouldn't bother to check? Here's #1,
#2, #5 and #6 according to distrowatch.org:

1. Linux Mint 14 - dark background
2. Mageia 3 (beta) - dark background
5. Debian 6 XFCE - dark background
6. OpenSuSE 12.3 - dark background

Before you accuse me of being selective, I already know that Ubuntu and
Fedora (#3 and #4) use a gnome-terminal with a light background, so I
skipped them.

The terminal background in Debian depends on which desktop environment
you choose. Gnome will give you a light background, while XFCE give you
a dark background. KDE is also dark I believe, but I haven't tested it.
In my experience, most distros that allow you a choice of desktops at
install-time follow the same pattern.

[Dan Drake]

On Tue, 19 Mar 2013 at 07:41AM -0700, Andrey Novoseltsev wrote:
> I've "make ptestlong"ed 5.9.beta0 yesterday, all tests passed, but
> this morning I've discovered two running ecl processes still running
> and consuming all memory (the machine has 16Gb RAM, swap use went up
> to 18Gb). This has never happened before:

I had a similar thing happen to me. Ubuntu 12.10, 64-bit, 12 GB RAM, 8
cores. I killed the ecl processes and things kept going from there.

The bigger problem was that doctesting with more than 1 thread froze up
my machine. Four times. I start it with:

env MAKE='make -jN -lN' make ptestlong

and if N > 1, my machine froze after a while. I've had some minor
trouble with this computer freezing under heavy load, but doctesting
Sage with all 8 cores has always worked in the past.

Anyone else having this problem?

Dan

--
--- Dan Drake
----- http://math.pugetsound.edu/~ddrake
-------

[P Purkayastha]

While the config is being fixed (if it is fixed), you can try and see if
a change in the blue color helps you. I didn't notice that the sage
prompt was barely readable because I was using urxvt for some time. And
I use a different (muted) color scheme for urxvt.

Attached picture will show you the difference. On the left is
terminology, and on the right is urxvt.

[Jeroen Demeyer]

In part, this is because the sage-cleaner is broken:
http://trac.sagemath.org/sage_trac/ticket/14055

[Jeroen Demeyer]

On 2013-03-19 16:16, John Cremona wrote:
> Exactly the same happened to me: 2 rogue ecl processes consuming lots
> of RAM. This is on ubuntu, same set us worked fine with 5.8 at the
> same time.

Unfortunately, I cannot reproduce this problem on boxen.math.

[Volker Braun]

On Tuesday, March 19, 2013 11:47:54 PM UTC+1, Michael Orlitzky wrote:

Cooommmmeee onnnn. Did you think I wouldn't bother to check? Here's #1,
#2, #5 and #6 according to distrowatch.org:

You are joking, right? distrowatch.org hit counts are just the odd-ball distros that are so uncommon that there are no dedicated sites and distrowatch.org comes out near the top if you google for it. Do you know any Mageia 3 (beta) users? Me neither.

[Michael Orlitzky]

On 03/20/2013 10:59 AM, Volker Braun wrote:
> On Tuesday, March 19, 2013 11:47:54 PM UTC+1, Michael Orlitzky wrote:
>
> Cooommmmeee onnnn. Did you think I wouldn't bother to check? Here's #1,

> #2, #5 and #6 according to distrowatch.org <http://distrowatch.org>:

>
>
> You are joking, right? distrowatch.org hit counts are just the odd-ball
> distros that are so uncommon that there are no dedicated sites and
> distrowatch.org comes out near the top if you google for it. Do you know
> any Mageia 3 (beta) users? Me neither.

I'm sure Mageia 2 is the same, but I don't have all day to download and
install distros in order to prove you marginally wronger. #1 Mint and #6
SuSE should be enough proof that this is totally made-up:

> All major Linux distros and all commercial unices have defaulted to
> white background for ages, precisely because usability studies say
> its the best choice for most. Thats a fact, and not my personal
> preference.

I'm not going to argue about it forever. People have terminals with dark
backgrounds. We can either fix the default, or deal with the complaints.

[Volker Braun]

On Wednesday, March 20, 2013 4:45:52 PM UTC+1, Michael Orlitzky wrote:

I'm not going to argue about it forever. People have terminals with dark
backgrounds. We can either fix the default, or deal with the complaints.

Whats the fix? The "Linux" color scheme is difficult to see on white background, so thats out. 

[Michael Orlitzky]

Short-term? No color. This will at least get the text color right,
everywhere.

Long-term? Get ipython to support the console palette.

[leif]

Yes. Volker, did you report this upstream (as a bug, with a patch,
references to studies...)?


-leif

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[Volker Braun]

Very funny. How about we add a note to the installation guide to spell out how to change the color scheme?

[leif]

Volker Braun wrote:
> Very funny. How about we add a note to the installation guide to spell
> out how to change the color scheme?

Probably. In black-on-white?


-leif

> On Wednesday, March 20, 2013 5:02:45 PM UTC+1, Michael Orlitzky wrote:
>
> Short-term? No color. This will at least get the text color right,
> everywhere.
>
> Long-term? Get ipython to support the console palette.

[Jason Grout]

On 3/20/13 11:30 AM, Volker Braun wrote:
> Very funny. How about we add a note to the installation guide to spell
> out how to change the color scheme?
>

For what it's worth, here are relevant threads from the IPython list:

http://python.6.n6.nabble.com/Colours-in-IPython-0-11-rc1-PPA-package-td1648601.html

http://python.6.n6.nabble.com/default-colorscheme-td1647858.html


Jason

[Michael Orlitzky]

On 03/20/2013 12:30 PM, Volker Braun wrote:
> Very funny. How about we add a note to the installation guide to spell
> out how to change the color scheme?

We've had NoColor for 8 years, and it's worked fine. It's not an absurd
suggestion. Defaulting to NoColor would not preclude such a note.

[Jason Grout]

On 3/20/13 12:23 PM, Michael Orlitzky wrote:
> We've had NoColor for 8 years, and it's worked fine. It's not an absurd
> suggestion. Defaulting to NoColor would not preclude such a note.

Definitely not absurd at all.

Any other votes?

Jason

P.S. What happened in this thread to the usually very congenial and
respectful spirit around here?

[Volker Braun]

We lacked a lot of stuff 8 years ago, so thats not an argument. Colors improve legibility even more so than the white background. As I've said before, the defaults should be the best choice for most users.  

[Nathann Cohen]

> P.S. What happened in this thread to the usually very congenial and
> respectful spirit around here?

Let's fix it with goooood souuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuunds ! :-P

http://grooveshark.com/s/Oppression/2TtKOG?src=5

Nathann

[Michael Orlitzky]

On 03/20/2013 01:29 PM, Jason Grout wrote:
>
> P.S. What happened in this thread to the usually very congenial and
> respectful spirit around here?
>

Wadler's Law:

The emotional intensity of debate on a language feature
increases as one moves down the following scale:
Semantics,
Syntax,
Lexical syntax,
Comments

You can imagine where syntax highlighting would fall on that scale. I
personally am just having a little fun, and hope there's no hard feelings.

[Benjamin Jones]

I think a NoColor default is a good idea, but let's also make it easy to enable color and change the color scheme. Editing iPython config files doesn't count as easy (for the average user) in my opinion. How about a command line option, or a top-level function?

FWIW, I use a dark background and I think the dark blue sage prompt is fine, but dark blue for syntactic elements in the console help is not good.

ps. That's a nice track, Nathann!

[John Cremona]

Please can the people who care about colours move over to another
thread, leaving this one for actual bug reports, such as the one I
reported?

John (politely)

[leif]

Jason Grout wrote:
> On 3/20/13 12:23 PM, Michael Orlitzky wrote:
>> We've had NoColor for 8 years, and it's worked fine. It's not an absurd
>> suggestion. Defaulting to NoColor would not preclude such a note.
>
> Definitely not absurd at all.
>
> Any other votes?

I personally don't care.

We could add a note on '%colors [...]' (and/or [a reference on] how to
change the default) to the Sage banner, whatever the default is or will be.


-leif

[Dan Drake]

On Tue, 19 Mar 2013 at 07:41AM -0700, Andrey Novoseltsev wrote:

> I've "make ptestlong"ed 5.9.beta0 yesterday, all tests passed, but
> this morning I've discovered two running ecl processes still running
> and consuming all memory (the machine has 16Gb RAM, swap use went up
> to 18Gb). This has never happened before:

Doctesting this release reliably freezes up my machine, regardless of
the number of threads I use. I did several experiments and it seems like
one of the doctests run near the end spawns a couple of ecl processes
which quickly consume several gigabytes of RAM. The doctesting process
continues, and even finishes successfully, but those processes continue
eating up memory and soon my machine freezes.

Any ideas? What can I do to learn more about what's happening? Any way I
can avoid the lockups?

[leif]

At least with bash, you can use 'ulimit' (type 'help ulimit').


The Sage Cleaner gets fixed on #14055 [1]. Still, the ECL issue should
get fixed as well.


-leif


[1] http://trac.sagemath.org/sage_trac/ticket/14055

[Dan Drake]

On Wed, 20 Mar 2013 at 07:50PM +0100, leif wrote:
> At least with bash, you can use 'ulimit' (type 'help ulimit').

I thought of that after sending my previous message. Here's some more
information:

With "ulimit -v 4194304", doctesting finishes successfully. The runaway
ecls get killed. I increased the limit to 5242880 and my machine froze
again.

The weird thing is, I have 12GB RAM and swap:

ddrake@egret:~$ free -m
total used free shared buffers cached
Mem: 12009 971 11037 0 96 331
-/+ buffers/cache: 543 11465
Swap: 12277 0 12277


I don't know why it doesn't start swapping. Two 5GB processes along with
a regular desktop shouldn't even fill the RAM.

Oh, and when I say "freeze", things aren't *completely* frozen: I can
still do the "magic sysrq key" sequence [1] and reboot.

Dan


[1]: https://en.wikipedia.org/wiki/Magic_SysRq_key#Uses

[Hugh Thomas]

Hi!

I get doctest failures in sage/misc/interpreter.py and sage/misc/sage_extension.py.  Output below.  

I am running ubuntu 11.10 (oneiric), on a 32 bit machine, with processors Intel CPU U7300 @ 1.30GHz × 2.  

cheers,

Hugh

hugh@hugh-laptop:~/sage-5.9.beta0$ ./sage -t --force-lib devel/sage/sage/misc/interpreter.py 

Running doctests with ID 2013-03-21-02-02-01-4979b14d.

Doctesting 1 file.

sage -t devel/sage/sage/misc/interpreter.py

**********************************************************************

File "devel/sage/sage/misc/interpreter.py", line 150, in sage.misc.interpreter.sage_prompt

Failed example:

    shell.run_cell('sage_prompt()')

Expected:

    u'sage'

Got:

    u'sage'

**********************************************************************

File "devel/sage/sage/misc/interpreter.py", line 566, in sage.misc.interpreter.interface_shell_embed

Failed example:

    shell.run_cell('List( [1..10], IsPrime )')

Expected:

    [ false, true, true, false, true, false, true, false, false, false ]

Got:

    [ false, true, true, false, true, false, true, false, false, false ]

**********************************************************************

2 items had failures:

   1 of   4 in sage.misc.interpreter.interface_shell_embed

   1 of   4 in sage.misc.interpreter.sage_prompt

    [107 tests, 2 failures, 6.5 s]

----------------------------------------------------------------------

sage -t devel/sage/sage/misc/interpreter.py  # 2 doctests failed

----------------------------------------------------------------------

Total time for all tests: 6.6 seconds

    cpu time: 1.0 seconds

    cumulative wall time: 6.5 seconds

hugh@hugh-laptop:~/sage-5.9.beta0$ ./sage -t --force-lib devel/sage/sage/misc/sage_extension.py 

Running doctests with ID 2013-03-21-02-02-20-3fc48de2.

Doctesting 1 file.

sage -t devel/sage/sage/misc/sage_extension.py

**********************************************************************

File "devel/sage/sage/misc/sage_extension.py", line 34, in sage.misc.sage_extension

Failed example:

    shell.run_cell('a')

Expected:

    2

Got:

    2

**********************************************************************

File "devel/sage/sage/misc/sage_extension.py", line 39, in sage.misc.sage_extension

Failed example:

    shell.run_cell('%time 594.factor()')

Expected:

    CPU times: user ...

    Wall time: ...

    2 * 3^3 * 11

Got:

    CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s

    Wall time: 0.00 s

    2 * 3^3 * 11

**********************************************************************

File "devel/sage/sage/misc/sage_extension.py", line 75, in sage.misc.sage_extension.SageMagics.runfile

Failed example:

    shell.run_cell('a')

Expected:

    2

Got:

    2

**********************************************************************

File "devel/sage/sage/misc/sage_extension.py", line 99, in sage.misc.sage_extension.SageMagics.attach

Failed example:

    shell.run_cell('a')

Expected:

    2

Got:

    2

**********************************************************************

File "devel/sage/sage/misc/sage_extension.py", line 103, in sage.misc.sage_extension.SageMagics.attach

Failed example:

    shell.run_cell('a')

Expected:

    3

Got:

    3

**********************************************************************

File "devel/sage/sage/misc/sage_extension.py", line 106, in sage.misc.sage_extension.SageMagics.attach

Failed example:

    shell.run_cell('attached_files()')

Expected:

    []

Got:

    []

**********************************************************************

File "devel/sage/sage/misc/sage_extension.py", line 127, in sage.misc.sage_extension.SageMagics.pre_run_code_hook

Failed example:

    shell.run_cell('a')

Expected:

    2

Got:

    2

**********************************************************************

File "devel/sage/sage/misc/sage_extension.py", line 131, in sage.misc.sage_extension.SageMagics.pre_run_code_hook

Failed example:

    shell.run_cell('a')

Expected:

    3

Got:

    3

**********************************************************************

File "devel/sage/sage/misc/sage_extension.py", line 134, in sage.misc.sage_extension.SageMagics.pre_run_code_hook

Failed example:

    shell.run_cell('attached_files()')

Expected:

    []

Got:

    []

**********************************************************************

File "devel/sage/sage/misc/sage_extension.py", line 210, in sage.misc.sage_extension.SagePlainTextFormatter

Failed example:

    shell.run_cell('a = identity_matrix(ZZ, 2); [a,a]')

Expected:

    [

    [1 0]  [1 0]

    [0 1], [0 1]

    ]

Got:

    [

    [1 0]  [1 0]

    [0 1], [0 1]

    ]

**********************************************************************

5 items had failures:

   2 of  12 in sage.misc.sage_extension

   3 of  14 in sage.misc.sage_extension.SageMagics.attach

   3 of  14 in sage.misc.sage_extension.SageMagics.pre_run_code_hook

   1 of   9 in sage.misc.sage_extension.SageMagics.runfile

   1 of   5 in sage.misc.sage_extension.SagePlainTextFormatter

    [55 tests, 10 failures, 2.5 s]

----------------------------------------------------------------------

sage -t devel/sage/sage/misc/sage_extension.py  # 10 doctests failed

----------------------------------------------------------------------

Total time for all tests: 2.5 seconds

    cpu time: 0.3 seconds

    cumulative wall time: 2.5 seconds

On Monday, March 18, 2013 10:00:07 AM UTC-3, Jeroen Demeyer wrote:

Dear Sage lovers,

We're releasing Sage 5.9.beta0.

Source archive:

http://boxen.math.washington.edu/home/release/sage-5.9.beta0/sage-5.9.beta0.tar

Upgrade path:

http://boxen.math.washington.edu/home/release/sage-5.9.beta0/sage-5.9.beta0/

The source and upgrade path can also be found on the mirror network
(you might need to wait a while before the mirrors are synchronized):

http://www.sagemath.org/download-latest.html


Please build, test, and report!  We'd love to hear about your
experiences with this release.

== Tickets ==

* We closed 31 tickets in this release. For details, see

  http://boxen.math.washington.edu/home/release/sage-5.9.beta0/tickets.html

Closed tickets:

#4750: make it so sage -t foo.sage pulls in the preparsed version of all
the code in foo.sage before doctesting foo.py; make it so "sage -t
foo.py" has an option to pull in all code from foo.py before doctesting
it. [Reviewed by David Roe]
#8699: allow doctest coverage script to handle triple single quotes
[Reviewed by Minh Van Nguyen, Mike Hansen]
#8708: allow doctest script to handle docstrings with triple single
quotes [Reviewed by John Palmieri, Burcin Erocal]
#9225: New doctesting features [Reviewed by David Roe, Jeroen Demeyer]
#9273: doctest elliptic_curves/BSD.py reports "file not found" [Reviewed
by Jeroen Demeyer]
#9772: unify doctest commands, especially for 'long' and 'parallel'
options [Reviewed by Jeroen Demeyer]
#11336: Update doctest tolerance to work with print statement. [Reviewed
by Jeroen Demeyer]
#11338: Fix signals/interrupts in sage-doctest [Reviewed by Jeroen Demeyer]
#13928: Problematic file filter in skip() from sage-ptest [Reviewed by
Nils Bruin, John H Palmieri]

Merged in sage-5.9.beta0:

#2235: Jeroen Demeyer: doctest issue -- combining # long and # 32-bit /
# 64-bit [Reviewed by David Roe]
#11863: Anna Haensch, Fr?d?ric Chapoton: Bilinear Map [Reviewed by
Kannappan Sampath]
#12415: David Roe, Robert Bradshaw, Jeroen Demeyer: Update doctesting
framework [Reviewed by Jeroen Demeyer, David Roe]
#12708: Punarbasu Purkayastha: limit not correctly computed by maxima
[Reviewed by Karl-Dieter Crisman]
#12828: Stephen Montgomery-Smith: get_memory_usage and top under FreeBSD
[Reviewed by Karl-Dieter Crisman]
#13209: Kannappan Sampath: Fix some minor Cayley table documentation
problems [Reviewed by Karl-Dieter Crisman]
#13262: Sebastien Gouezel: Update doctests after bug correction in pynac
[Reviewed by Burcin Erocal]
#13351: Jean-Pierre Flori: Cannot import sage.libs.lcalc.lcalc_Lfunction
[Reviewed by Dmitrii Pasechnik]
#13424: Christian Stump, Gregg Musiker: Compute Mutation Class for
Cluster Algebra Seed or Cluster Quiver [Reviewed by Gregg Musiker,
Salvatore Stella]
#13432: R. Andrew Ohana: add sage/env.py and fix many inappropriate
references to SAGE_ROOT [Reviewed by Fran?ois Bissey]
#13729: Burcin Erocal, Sebastien Gouezel: Update pynac to 0.2.6
[Reviewed by Fran?ois Bissey]
#13743: Travis Scrimshaw: Bug in k-bounded symmetric functions [Reviewed
by Mike Zabrocki]
#14079: Jeroen Demeyer: Cython interface to pselect() system call
[Reviewed by Volker Braun]
#14175: Volker Braun, Nicolas M. Thi?ry: More plot options for polytopes
[Reviewed by Volker Braun, Nicolas M. Thi?ry]
#14197: Chris Berg, Christian Stump: Add map from PerfectMatchings to
Permutations. Fix string representation in perfect matchings. [Reviewed
by Alejandro Morales, Christian Stump]
#14238: Nathann Cohen: a polyhedron() method for Linear Programs
[Reviewed by Dmitrii Pasechnik]
#14241: Timo Kluck: Patch to FLINT fails to apply because of double path
separator // in filenames [Reviewed by Leif Leonhardy]
#14242: Jeroen Demeyer: Race condition in gap_reset_workspace()
[Reviewed by Volker Braun]
#14251: Nathann Cohen: Circulant digraphs [Reviewed by David Coudert]
#14253: Jeroen Demeyer: sage.misc.sage_ostools.have_program: use
os.access() [Reviewed by David Roe]
#14257: Nathann Cohen: Implements the Wells graph [Reviewed by Dmitrii
Pasechnik]
#14263: John Palmieri: if build fails, print message about which spkgs
failed [Reviewed by Volker Braun]

[Jeroen Demeyer]

On 2013-03-21 06:06, Hugh Thomas wrote:
>
> Hi!
>
> I get doctest failures in sage/misc/interpreter.py and
> sage/misc/sage_extension.py. Output below.

This is related to IPython, did you change any configuration of IPython,
different from the default?

[Hugh Thomas]

Hi!

I certainly didn't change anything associated to my installation of 5.9.beta0.  I could have changed some installation-independent configuration file at some time in the past that could still be sitting around somewhere, if that's relevant.  These changes are not important (I don't think I even actually managed to produce the change in behaviour that I was looking for), so if there is a directory I should delete to get rid of any possibly problematic configuration files, and then run the doctests again, I'm happy to try doing that.  

cheers,

Hugh

[Volker Braun]

If deleting ~/.sage/ipython* doesn't fix this, can you check what you get here:

[vbraun@localhost hg]$ sage -c "sage.misc.interpreter.get_test_shell().run_cell('sage_prompt()')" | od -c

 

0000000   u   '   s   a   g   e   '  \n

0000010

[vbraun@localhost hg]$ sage -c 'print 1+1' | od -c

0000000   2  \n

0000002

[Hugh Thomas]

Hi!

On Thursday, March 21, 2013 12:15:05 PM UTC-3, Volker Braun wrote:

If deleting ~/.sage/ipython* doesn't fix this, can you check what you get here:

[vbraun@localhost hg]$ sage -c "sage.misc.interpreter.get_test_shell().run_cell('sage_prompt()')" | od -c

 

0000000   u   '   s   a   g   e   '  \n

0000010

[vbraun@localhost hg]$ sage -c 'print 1+1' | od -c

0000000   2  \n

0000002

I deleted the directories .sage/ipython and .sage/ipython-0.12.  It didn't solve the problem.  (I get more failures when I run the two doctests immediately after removing those two directories, until I run sage normally, after which I get exactly the same error messages as I was reporting previously.)

Here is the output Volker asked for.  

hugh@hugh-laptop:~/sage-5.9.beta0$ ./sage -c "sage.misc.interpreter.get_test_shell().run_cell('sage_prompt()')" | od -c

0000000   u   '   s   a   g   e   '  \n

0000010

hugh@hugh-laptop:~/sage-5.9.beta0$ ./sage -c 'print 1+1' | od -c

0000000   2  \n

0000002

cheers,

Hugh

[David Kirkby]

On 20 March 2013 21:50, Dan Drake <ddr...@pugetsound.edu> wrote:

> The weird thing is, I have 12GB RAM and swap:
>
> ddrake@egret:~$ free -m
> total used free shared buffers cached
> Mem: 12009 971 11037 0 96 331
> -/+ buffers/cache: 543 11465
> Swap: 12277 0 12277
>
>
> I don't know why it doesn't start swapping. Two 5GB processes along with
> a regular desktop shouldn't even fill the RAM.

> Dan

Depending on what CPUs you have, it may be the case that each CPU only
has access to 6 GB, or that each CPU can only access 6 GB quickly, and
accessing the other 6 GB takes much longer. Some of the AMD Opterons
used to suffer this issue.

Dave

[leif]

Jeroen Demeyer wrote:
> On 2013-03-19 03:25, Fran�ois wrote:

>> On Tuesday, March 19, 2013 2:00:07 AM UTC+13, Jeroen Demeyer wrote:
>>
>> Dear Sage lovers,
>>
>> We're releasing Sage 5.9.beta0.
>>
>> Source archive:
>>
>> http://boxen.math.washington.edu/home/release/sage-5.9.beta0/sage-5.9.beta0.tar
>> <http://boxen.math.washington.edu/home/release/sage-5.9.beta0/sage-5.9.beta0.tar>
>>
>>
>> Upgrade path:
>>
>> http://boxen.math.washington.edu/home/release/sage-5.9.beta0/sage-5.9.beta0/
>> <http://boxen.math.washington.edu/home/release/sage-5.9.beta0/sage-5.9.beta0/>
>>
>>
>> The source and upgrade path can also be found on the mirror network
>> (you might need to wait a while before the mirrors are synchronized):
>>
>> http://www.sagemath.org/download-latest.html
>> <http://www.sagemath.org/download-latest.html>
>>
>>
>> Please build, test, and report! We'd love to hear about your
>> experiences with this release.
>>
>>

>> OK, just built it and it seems to work fine (OK I wanted to add
>> numpy-1.7.0 on top
>> but let's leave that for a moment). I haven't completed the tests but
>> the new doctesting
>> framework has a behavior I didn't expect.
>>
>> I usually run batch of tests (mostly because of sage-on-gentoo) like this:
>> nohup ./sage -tp --long devel/sage-main/sage &
>> or variation thereof. And I get a log in nohup.out at the end. I know there
>> are other ways, this is just my current workflow that worked quite well over
>> several years.
>>
>> The new doctesting framework doesn't like it at all:
>> Running doctests with ID 2013-03-19-14-52-17-1032e799.
>> Sorting sources by runtime so that slower doctests are run first....
>> Doctesting 1857 files using 8 threads.
>> Process DocTestWorker-1:
>> Traceback (most recent call last):
>> File
>> "/home/work/fbissey/sandbox/sage-5.9.beta0/local/lib/python/multiprocessing/process.py",
>> line 258, in _bootstrap
>> self.run()
>> File
>> "/home/work/fbissey/sandbox/sage-5.9.beta0/local/lib/python2.7/site-packages/sage/doctest/forker.py",
>> line 1655, in run
>> sys.stdin = os.fdopen(0, "r")
>> OSError: [Errno 22] Invalid argument
>> Process DocTestWorker-2:
>> Traceback (most recent call last):
>> File
>> "/home/work/fbissey/sandbox/sage-5.9.beta0/local/lib/python/multiprocessing/process.py",
>> line 258, in _bootstrap
>> self.run()
>> File
>> "/home/work/fbissey/sandbox/sage-5.9.beta0/local/lib/python2.7/site-packages/sage/doctest/forker.py",
>> line 1655, in run
>> sys.stdin = os.fdopen(0, "r")
>> OSError: [Errno 22] Invalid argument
>>
>>
>> etc... You get the idea. Is it in any way fixable or do I have to do
>> something different from now on.
> Please create a ticket and CC me.

This is #14307 [1], merged into Sage 5.9.beta1.


-leif

[1] http://trac.sagemath.org/sage_trac/ticket/14307

[Dan Drake]

That's a very good idea, but I did a test and it seems like accessing
more than 6GB is fine: I just did

sage: a = [0]*(int(1.25*10^9)) ; a.append(1) ; sum(a)

which consumes about 80% of my RAM and completes with no trouble.
Instead, it seems like my machine has trouble as soon as it needs to
start swapping. I know it will get slow and less responsive, but I don't
think it should be this bad. I'll keep investigating.

Dan

[kcrisman]

Question on the new reference manual:  I know that there was some recent change so that it doesn't build from scratch if there are no changes.  Did that also cover the case where one file changed, but then one has to wait through all zillion things like

[numerical] no targets are out of date.

Build finished. The built documents can be found in /Users/.../sage-5.9.beta0/devel/sage/doc/output/html/en/reference/numerical

so it actually takes much longer to do

./sage -b; ./sage -docbuild reference html

to check out trivial changes than it did before?  http://trac.sagemath.org/sage_trac/ticket/14204 doesn't fix this because I don't have any need to set whatever environment variable one needs to for more than one docbuild thread if I'm only changing one file!

Thanks,

- kcrisman

[leif]

kcrisman wrote:
> Question on the new reference manual: I know that there was some recent
> change so that it doesn't build from scratch if there are no changes.
> Did that also cover the case where one file changed, but then one has
> to wait through all zillion things like
>
> [numerical] no targets are out of date.
> Build finished. The built documents can be found in
> /Users/.../sage-5.9.beta0/devel/sage/doc/output/html/en/reference/numerical
>
> so it actually takes much longer to do
>
> ./sage -b; ./sage -docbuild reference html
>
> to check out trivial changes than it did before?

I don't think it now takes longer (modulo the two passes); you just see
more messages (i.e., lines on the screen) now. (The second dumb line
has been reintroduced upon request... 8-/ )

> http://trac.sagemath.org/sage_trac/ticket/14204 doesn't fix this
> because I don't have any need to set whatever environment variable one
> needs to for more than one docbuild thread if I'm only changing one file!

Well, even if Sphinx effectively does nothing (or just has to recreate
one file), it will know sooner if you're using more than one thread.

('make doc; make doc' *always* takes ages, even the second run, but
it'll run faster with 'make -j12', provided you have enough CPU / memory
resources and your disk / I/O subsystem is fast enough.)


-leif

[Jeroen Demeyer]

On 2013-03-23 09:22, leif wrote:

> ('make doc; make doc' *always* takes ages

You mean ages since sage-5.8 or it always took ages?

For me, running "make doc" with MAKE="make -j2" in sage-5.8 is faster
than in sage-5.7.

[Nathann Cohen]

> For me, running "make doc" with MAKE="make -j2" in sage-5.8 is faster
> than in sage-5.7.

When there is some doc to build, or when everything is already compiled ?

I am experiencing the same problem : when you work on a patch affecting just one patch and change its doc, building the doc (that is checking that everything but one filt has aready been built) is much slower than before.

Illustration (I just updated a reference in a file)

$ sage -docbuild reference html

[...]

[reference] no targets are out of date.

Build finished. The built documents can be found in /home/ncohen/.Sage/devel/sage/doc/output/html/en/reference

real 0m44.245s

user 1m4.896s

sys 0m6.376s

40 seconds to do that :-P

Nathann

[leif]

Jeroen Demeyer wrote:
> On 2013-03-23 09:22, leif wrote:
>
>> ('make doc; make doc' *always* takes ages
> You mean ages since sage-5.8 or it always took ages?

I meant always (including releases prior to 5.8).

> For me, running "make doc" with MAKE="make -j2" in sage-5.8 is faster
> than in sage-5.7.

With enough cores, and enough memory, yes, perhaps unless I/O is the
bottleneck.

But I was especially referring to the "dry run", i.e., when all docs are
up-to-date. This (still) takes quite some time, but with multiple
threads, it may be faster than previously. (Orthogonal to the speed, it
floods the screen.)


[Not sure whether performing the second pass of reference manual
building could be avoided when the first pass revealed nothing changed.]


-leif


P.S.: It seems the recursive $(MAKE) calls in spkg/deps aren't
silenced, i.e., if 'build' (which 'doc' depends on) is up-to-date, there
are too many messages. (Haven't investigated yet.)

[Jeroen Demeyer]

On 2013-03-23 03:08, kcrisman wrote:
> so it actually takes much longer to do
>
> ./sage -b; ./sage -docbuild reference html
>
> to check out trivial changes than it did before?

With 1 thread, it does indeed take about twice as much time as earlier
versions of Sage. With 2 threads, you should be able to get more or less
the same time as before.

[leif]

But indeed something weird is happening:

$ ./sage --docbuild reference html

repeatably takes about twice as long as

$ make doc # which does a lot more


In both cases with '-j' threads according to the setting of MAKE,
SAGE_NUM_THREADS unset.


-leif


P.S.: Unrelated (I think): I always see

[reference] Compiling the master document
[reference] updating environment: 0 added, 0 changed, 1129 removed

What got removed?

[Kannappan Sampath]

I am unclear about one more thing about the new documentation building: sage -docbuild -D lists that reference/<dir-name> is a valid option that can go in ./sage -docbuild <here> html, for instance. But, I get the error that conf file was missing. Is this the intended behaviour? If so, what is suggested by the message that comes up on sage -docbuild -D? 

Regards, 

Kannappan.

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

To unsubscribe from this group and stop receiving emails from it, send an email to sage-release+unsubscribe@googlegroups.com.

[leif]

Kannappan Sampath wrote:
> I am unclear about one more thing about the new documentation building:
> sage -docbuild -D lists that reference/<dir-name> is a valid option that
> can go in ./sage -docbuild <here> html, for instance. But, I get the
> error that conf file was missing. Is this the intended behaviour? If so,
> what is suggested by the message that comes up on sage -docbuild -D?

Are you really using 5.9.beta0?

$ ./sage --docbuild reference/games html

for example works for me.


-leif

[Kannappan Sampath]

Are you really using 5.9.beta0?

$ ./sage --docbuild reference/games html

for example works for me.

No, I am using sage-5.9.beta1 (The only recent beta, after sage-5.8-beta0, to which I don't have access to, is this 5.9b0) and the following fails: 

$ ./sage -docbuild reference/symbolic html 

Moreover, on all the betas through sage-5.8.beta0. 

~KnS

[John H Palmieri]

On Saturday, March 23, 2013 7:42:23 AM UTC-7, KnS wrote:

Are you really using 5.9.beta0?

$ ./sage --docbuild reference/games html

for example works for me.

No, I am using sage-5.9.beta1 (The only recent beta, after sage-5.8-beta0, to which I don't have access to, is this 5.9b0) and the following fails: 

$ ./sage -docbuild reference/symbolic html 

When I run "./sage --docbuild -D", it says

    Other valid document names take the form 'reference/DIR', where
    DIR is a subdirectory of SAGE_ROOT/devel/sage/doc/en/reference/.

"symbolic" is not a subdirectory, so it's not surprising if this fails. At least some of the symbolics files are in the "calculus" section of the reference manual, so try "reference/calculus" instead.

--
John

[John Cremona]

On 19 March 2013 15:16, John Cremona <john.c...@gmail.com> wrote:
> Exactly the same happened to me: 2 rogue ecl processes consuming lots
> of RAM. This is on ubuntu, same set up worked fine with 5.8 at the
> same time.

This report provoked almost no reaction in a thread dominated by vital
discussion of colour schemes.

I made the mistake of starting "make ptestlong" on a 5.9.beta1 build
last night without checking that that anything had been done so fix
this catastrophic problem (and without creative use of ulimit, I
admit). This morning the machine responds to ping but we cannot login
to it.

I will not be able to get physical access to the machine room until
Monday at the earliest to reset the machine. In the meantime does
anyone have any suggestions on how to get into it? Increasing the
ConnectTimeout option for ssh does not help: after a few minutes the
connection is broken with a message saying that the server is not
responding.

How come testing sage-5.9.beta? has not had a similar effect on all
other Sage developers?

John

>
> John
>

[John Cremona]

While I still think there is a serious issue here, friends will be
delighted to hear that I was able to get onto the server in question
and kill the two offending ecl processes. I do not know why, but
while it was impossible to login from off campus, I could login to a
different machine on the university network and login from there to
the machine having difficulties.

No doubt there is a logical reason for that!

John

[Dan Drake]

On Sat, 23 Mar 2013 at 03:18PM +0000, John Cremona wrote:
> On 19 March 2013 15:16, John Cremona <john.c...@gmail.com> wrote:
> > Exactly the same happened to me: 2 rogue ecl processes consuming lots
> > of RAM. This is on ubuntu, same set up worked fine with 5.8 at the
> > same time.
>
> This report provoked almost no reaction in a thread dominated by vital
> discussion of colour schemes.

I noticed that, too. I understand the important of bikeshedding our
colo(u)r schemes (no sarcasm!) but there's something really wrong with
ecl.

> I made the mistake of starting "make ptestlong" on a 5.9.beta1 build
> last night without checking that that anything had been done so fix
> this catastrophic problem (and without creative use of ulimit, I
> admit). This morning the machine responds to ping but we cannot login
> to it.

5.9.beta1 is doing something similar for me, just like beta0. The good
news is that my computer doesn't crash, but it does take a while for my
computer to become responsive again. Any idea what doctest is starting
these bad processes?

[leif]

John Cremona wrote:
> On 19 March 2013 15:16, John Cremona <john.c...@gmail.com> wrote:
>> Exactly the same happened to me: 2 rogue ecl processes consuming lots
>> of RAM. This is on ubuntu, same set up worked fine with 5.8 at the
>> same time.
>
> This report provoked almost no reaction in a thread dominated by vital
> discussion of colour schemes.

Well, IIRC I pointed you to the Sage Cleaner ticket [1], which doesn't
have positive review yet and hence didn't get into beta1, so for now the
problem remains.

(The ticket doesn't solve the real problem, namely ECL running amok, but
it alleviates the situation by hopefully killing the ECL processes "in
time".)

Would probably have been worth a warning in the release notes /
announcement... ;-)


-leif

P.S.: Of course the colour of the Sage prompt is much more important
than whether testing Sage potentially crashes your machine; my
apologies to those only interested in the former.


[1] http://trac.sagemath.org/sage_trac/ticket/14055

> I made the mistake of starting "make ptestlong" on a 5.9.beta1 build
> last night without checking that that anything had been done so fix
> this catastrophic problem (and without creative use of ulimit, I
> admit). This morning the machine responds to ping but we cannot login
> to it.
>
> I will not be able to get physical access to the machine room until
> Monday at the earliest to reset the machine. In the meantime does
> anyone have any suggestions on how to get into it? Increasing the
> ConnectTimeout option for ssh does not help: after a few minutes the
> connection is broken with a message saying that the server is not
> responding.
>
> How come testing sage-5.9.beta? has not had a similar effect on all
> other Sage developers?
>
> John
>
>>
>> John
>>
>

[John Cremona]

On 23 March 2013 16:07, leif <not.r...@online.de> wrote:
> John Cremona wrote:
>>
>> On 19 March 2013 15:16, John Cremona <john.c...@gmail.com> wrote:
>>>
>>> Exactly the same happened to me: 2 rogue ecl processes consuming lots
>>> of RAM. This is on ubuntu, same set up worked fine with 5.8 at the
>>> same time.
>>
>>
>> This report provoked almost no reaction in a thread dominated by vital
>> discussion of colour schemes.
>
>
> Well, IIRC I pointed you to the Sage Cleaner ticket [1], which doesn't have
> positive review yet and hence didn't get into beta1, so for now the problem
> remains.
>

Thanks, leif -- hence the "almost".

> (The ticket doesn't solve the real problem, namely ECL running amok, but it
> alleviates the situation by hopefully killing the ECL processes "in time".)
>
> Would probably have been worth a warning in the release notes /
> announcement... ;-)
>

Agreed.

>
> -leif
>
> P.S.: Of course the colour of the Sage prompt is much more important than
> whether testing Sage potentially crashes your machine; my apologies to
> those only interested in the former.
>
>
> [1] http://trac.sagemath.org/sage_trac/ticket/14055

I will look at that.

John

>
>
>
>> I made the mistake of starting "make ptestlong" on a 5.9.beta1 build
>> last night without checking that that anything had been done so fix
>> this catastrophic problem (and without creative use of ulimit, I
>> admit). This morning the machine responds to ping but we cannot login
>> to it.
>>
>> I will not be able to get physical access to the machine room until
>> Monday at the earliest to reset the machine. In the meantime does
>> anyone have any suggestions on how to get into it? Increasing the
>> ConnectTimeout option for ssh does not help: after a few minutes the
>> connection is broken with a message saying that the server is not
>> responding.
>>
>> How come testing sage-5.9.beta? has not had a similar effect on all
>> other Sage developers?
>>
>> John
>>
>>>
>>> John
>>>
>>
>
>
> --
> () The ASCII Ribbon Campaign
> /\ Help Cure HTML E-Mail
>

> --
> You received this message because you are subscribed to the Google Groups
> "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to sage-release...@googlegroups.com.

[leif]

AFAIK the only files whose doctests run ECL directly are:

sage/interfaces/{lisp.py,maxima_lib.py}

and

sage/tests/cmdline.py


You may try testing these verbosely, watching 'top' (or a tree view of
the running processes) carefully...


-leif

[leif]

Apparently maxima_lib.py doesn't; for the tests in sage/interfaces/ you
may use


diff --git a/sage/interfaces/cleaner.py b/sage/interfaces/cleaner.py
--- a/sage/interfaces/cleaner.py
+++ b/sage/interfaces/cleaner.py
@@ -19,6 +19,10 @@
def cleaner(pid, cmd=''):
if cmd != '':
cmd = cmd.strip().split()[0]
+ import sys, time
+ open(os.path.join(misc.SAGE_ROOT,"cleaner.log"),"a").write(
+ "%s Process %5d (%s):\n\tChild process %5d: %s\n" % (
+ time.ctime(),os.getpid()," ".join(sys.argv),pid,cmd))
# This is safe, since only this process writes to this file.
F = os.path.join(misc.SAGE_TMP, 'spawned_processes')
if os.path.exists(F):


which logs spawned subprocesses in $SAGE_ROOT/cleaner.log (provided they
appropriately call cleaner()), FWIW.

(Don't forget to 'sage -b' before running tests; sys.argv[] only makes
sense if you specify a single file rather than directories or multiple
files, e.g. 'sage -t devel/sage/sage/interfaces/lisp.py' instead of
'sage -t devel/sage/sage/interfaces/' or 'sage -t
devel/sage/sage/interfaces/*.py', unfortunately. You could of course
use 'for f in devel/sage/sage/interfaces/*.py; do ./sage -t $f; done'
instead.)

But /I think/ the only relevant file is sage/interfaces/lisp.py anyway.

[Andrey Novoseltsev]

On Mar 23, 10:07 am, leif <not.rea...@online.de> wrote:
> John Cremona wrote:

> > On 19 March 2013 15:16, John Cremona <john.crem...@gmail.com> wrote:
> >> Exactly the same happened to me: 2 rogue ecl processes consuming lots
> >> of RAM.  This is on ubuntu, same set up worked fine with 5.8 at the
> >> same time.
>
> > This report provoked almost no reaction in a thread dominated by vital
> > discussion of colour schemes.
>
> Well, IIRC I pointed you to the Sage Cleaner ticket [1], which doesn't
> have positive review yet and hence didn't get into beta1, so for now the
> problem remains.
>
> (The ticket doesn't solve the real problem, namely ECL running amok, but
> it alleviates the situation by hopefully killing the ECL processes "in
> time".)
>

I tried that ticket and still had ECL processes running after all
tests finished, so it does not seem to be a solution.

On a related note, I have reported this on the ticket:
http://trac.sagemath.org/sage_trac/ticket/14055#comment:12

Thank you!
Andrey

[John Cremona]

I just did a full test of beta0, not in parallel, just using sage -t
--long, and there were no ecl's at the end. So perhaps the problem
only arises when parallel testing.

There were test failures though (this is with beta0, not beta1):


sage -t --long devel/sage/sage/misc/sage_extension.py # 10 doctests failed
sage -t --long devel/sage/sage/misc/interpreter.py # 2 doctests failed
sage -t --long devel/sage/sage/misc/sageinspect.py # AttributeError
in doctesting framework
sage -t --long devel/sage/sage/symbolic/callable.py # AttributeError
in doctesting framework
sage -t --long devel/sage/sage/combinat/ncsf_qsym/tutorial.py #
AttributeError in doctesting framework

I will try the same with beta1.

John

[Volker Braun]

Might be because of the SIGCHLD handler issue in libgap that has been waiting for a review at http://trac.sagemath.org/14039. See also http://trac.sagemath.org/14323 for a more temporary fix. Though if thats the root cause then I don't understand why it would not be triggered for everyone...