[sage-devel] Re: 404 in Sage Installation Guide

Ticket to address this issue: https://trac.sagemath.org/ticket/21468 I used the text from the intermediate README file (with corrections) for the description of URL to the wiki. I also updated the only other URL in the SageMath repository pointing to sagemath.org/mirror/. On Saturday,

[sage-devel] Re: State of Sage Wiki and Support

> Two steps are already done (#21309, #20690), and follow-up improvements > are being worked on at #20893. > > - #21309 Package Thebe > https://trac.sagemath.org/ticket/21309 > - #20690 Live documentation in Jupyter using Thebe > https://trac.sagemath.org/ticket/20690 > - #20893 Improve live

Re: [sage-devel] Jupyter notebook by default?

On Friday, September 9, 2016 at 6:51:00 PM UTC-4, Jason Grout wrote: > > Nice! That's even better that it works out-of-the-box! > >> >> +1 Yes, that is great that the same hooks work in Jupyter for this - and thanks Samuel for using this to answer the original post. -- You received this

Re: [sage-devel] Re: sage -br rebuilds things that were not changed

On 2016-09-10 18:36, Johan S. H. Rosenkilde wrote: > Without this or a similar schema, working on multiple tickets becomes > absolutely unbearable for me due to compilation time. How do you guys > cope with that? Having a version of each stable/rc/beta SageMath in a separate directory. Every now

[sage-devel] Re: sage -br rebuilds things that were not changed

Johan S. H. Rosenkilde wrote: > leif writes: >>> But if you want to actually make changes then this creates a new merge >>> commit which furthermore is against the conventional order (where the >>> feature branch is the first parent). So it makes the commit history harder >>> to understand. >>

[sage-devel] Re: sage -br rebuilds things that were not changed

On Saturday, September 10, 2016 at 9:14:08 AM UTC-7, leif wrote: > > For new branches, I think it's best to base them on the last *stable* > release (i.e., check out master before creating the new branch), unless > you really need fixes from later betas, or it's clear (or likely) that > you'd

Re: [sage-devel] Re: sage -br rebuilds things that were not changed

leif writes: >> But if you want to actually make changes then this creates a new merge >> commit which furthermore is against the conventional order (where the >> feature branch is the first parent). So it makes the commit history harder >> to understand. > > I'd rather say "impossible", or

[sage-devel] Re: PYTHONUSERBASE?

On Saturday, September 10, 2016, Volker Braun wrote: > On Saturday, September 10, 2016 at 4:55:48 PM UTC+2, William wrote: >> >> Python itself could make those same arguments, as one can install >> multiple copies of Python in different ways on a single computer. >> > >

[sage-devel] Re: sage -br rebuilds things that were not changed

The upstream bugs are still open: https://github.com/cython/cython/issues?q=is%3Aissue%20is%3Aopen%20cycache On Saturday, September 10, 2016 at 5:36:53 PM UTC+2, leif wrote: > > Volker Braun wrote: > > There is cycache, but its currently disabled in Sage as we ran into some > > bugs. > >

[sage-devel] Re: PYTHONUSERBASE?

On the plus side, now that we don't sent LD_LIBRARY_PATH any more any extensions modules found in ~/.local actually have a chance of working. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving

[sage-devel] Re: sage -br rebuilds things that were not changed

Johan S. H. Rosenkilde wrote: > Volker Braun writes: > >> Thats ok for reviewing tickets, and implemented as "git trac try >> ". > > OK. I had a chat with Thierry Monteil and we agreed there were some > subtle differences I don't remember - but I'll take a look at "git trac > try". > >> But

Re: [sage-devel] Re: PYTHONUSERBASE?

On Saturday, September 10, 2016 at 4:55:48 PM UTC+2, William wrote: > > Python itself could make those same arguments, as one can install > multiple copies of Python in different ways on a single computer. > Thats not really a valid argument, you are comparing apples and oranges. If anything,

[sage-devel] Re: sage -br rebuilds things that were not changed

Volker Braun wrote: > There is cycache, but its currently disabled in Sage as we ran into some > bugs. Well, since quite a while though, isn't it? Did anyone recently check whether the issue still exists, or could you give a pointer? -leif > On Saturday, September 10, 2016 at 12:20:54 AM

[sage-devel] Re: 404 in Sage Installation Guide

Harald Schilly wrote: > On Friday, September 9, 2016 at 12:16:36 AM UTC+2, leif wrote: > > The link to README..txt ("Be sure to read the file ..." [!]) > > http://www.sagemath.org/mirror/win/README.txt > > > referenced in > >

[sage-devel] Re: PYTHONUSERBASE?

Volker Braun wrote: > I think this idea of installing stuff globally (either system-wide or in > ~/.local) is outdated. Really its always better to make a venv if you > need some sort of specialist package. Its just an all-around better > workflow. And Sage-the-distribution really is like a big

Re: [sage-devel] Re: PYTHONUSERBASE?

On Sat, Sep 10, 2016 at 3:30 AM, Volker Braun wrote: > I think this idea of installing stuff globally (either system-wide or in > ~/.local) is outdated. Really its always better to make a venv if you need > some sort of specialist package. Its just an all-around better

Re: [sage-devel] sage -br rebuilds things that were not changed

Volker Braun writes: > Thats ok for reviewing tickets, and implemented as "git trac try > ". OK. I had a chat with Thierry Monteil and we agreed there were some subtle differences I don't remember - but I'll take a look at "git trac try". > But if you want to actually make changes then this

[sage-devel] Re: PYTHONUSERBASE?

I think this idea of installing stuff globally (either system-wide or in ~/.local) is outdated. Really its always better to make a venv if you need some sort of specialist package. Its just an all-around better workflow. And Sage-the-distribution really is like a big venv. I'd rather spend 5

[sage-devel] Re: 404 in Sage Installation Guide

On Friday, September 9, 2016 at 12:16:36 AM UTC+2, leif wrote: > > The link to README.txt ("Be sure to read the file ..." [!]) > > http://www.sagemath.org/mirror/win/README.txt > > referenced in > > > http://doc.sagemath.org/html/en/installation/binary.html#microsoft-windows > > gives a

Re: [sage-devel] sage -br rebuilds things that were not changed

Thats ok for reviewing tickets, and implemented as "git trac try ". But if you want to actually make changes then this creates a new merge commit which furthermore is against the conventional order (where the feature branch is the first parent). So it makes the commit history harder to

Re: [sage-devel] sage -br rebuilds things that were not changed

Jeroen Demeyer writes: > On 2016-09-10 00:03, Paul Masson wrote: >> Why would recythonizing be necessary when only changing the same file on >> the same branch? > > You are not changing just one file. When you checkout a new branch, a > lot of files get changed. When you checkout the old branch

Re: [sage-devel] sage -br rebuilds things that were not changed

There is cycache, but its currently disabled in Sage as we ran into some bugs. On Saturday, September 10, 2016 at 12:20:54 AM UTC+2, William wrote: > > On Fri, Sep 9, 2016 at 3:08 PM, Volker Braun > wrote: > > Whenever you switch to a branch with a different working set

[sage-devel] Re: memory management issue: deleted variables not released

On Saturday, September 10, 2016 at 6:56:04 AM UTC, Denis wrote: > > > As far as I am concerned, development of Sage stopped at 7.0 - I tried 7.3 > yesterday, and could not do a mid-level benchmark calculation, which I have > been repeating since at least 6.4. The problem is a memory fault. 7.0

[sage-devel] Re: memory management issue: deleted variables not released

Sat 2016-09-10 08:56:04 UTC+2, Denis on sage-devel: > As far as I am concerned, development of Sage stopped at 7.0 - I tried > 7.3 yesterday, and could not do a mid-level benchmark calculation, which > I have been repeating since at least 6.4. The problem is a memory fault. > 7.0 is the last

[sage-devel] Re: memory management issue: deleted variables not released

As far as I am concerned, development of Sage stopped at 7.0 - I tried 7.3 yesterday, and could not do a mid-level benchmark calculation, which I have been repeating since at least 6.4. The problem is a memory fault. 7.0 is the last version with which I can do it. I am prepared to collaborate