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

[Samuel Lelievre]

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 version with which I can do it. I am prepared to
> collaborate with any developer who is prepared to go after this bug
> seriously. The calculation involves some manipulations over polynomial
> rings in nine variables. The largest object is a 3838x3838 dense matrix.
> My own coding is modest, just a bunch of small functions calling each
> other and invoking user-level Sage routines.

Could you tell us your operating system, and how you installed Sage?

Can you reproduce your problem on SageCell [1] or SageMathCloud [2]?

Can you share your benchmark code, by sharing either of the following?
- a .py or .sage file with the code
- a Sage worksheet in the form of a .sws file or a .ipynb file
- a SageCell link
- a public worksheet on SageMathCloud

[1] SageCell: http://sagecell.sagemath.org
[2] SageMathCloud: https://cloud.sagemath.com

Samuel

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Dima Pasechnik]

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 is 
> the last version with which I can do it. I am prepared to collaborate with 
> any developer who is prepared to go after this bug seriously. The 
> calculation involves some manipulations over polynomial rings in nine 
> variables. The largest object is a 3838x3838 dense matrix. My own coding is 
> modest, just a bunch of small functions calling each other and invoking 
> user-level Sage routines.
>
> Let me repeat that without seeing an example that works in 7.0, but not in 
later versions, it is basically impossible to help you.
Please make such an example available.

Best,
Dima
 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Volker Braun]

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 you change 
> > timestamps of modified files. Git does not track timestamps. Updated 
> > timestamps cause recompilation. 
>
> So... instead of using timestamps, maybe Cython should use file hashes 
> to determine whether or not to recompile code?My distant memory of 
> when we first wrote the cython dep code for Sage long long ago was 
> that I used timestamps, then Craig Citro or Robert Bradshaw wrote 
> something better using hashes, but I'm not sure.  I'm cc'ing them in 
> case they have any thoughts. 
>
>
> -- 
> William (http://wstein.org) 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Johan S . H . Rosenkilde]

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 again, a lot 
> of files get changed again. The fact that they are changed to have the 
> same content that they originally had, is irrelevant. As far as the 
> filesystem is concerned, those files are changed.

Yes, and even fixing Cythonizing to using file hashes is only a partial
solution, right: Make would still cause huge recompilations all over the
place, AFAIK.

I've completely stopped jumping directly between tickets, and always use
the following schema for checking out a ticket:

$ git checkout develop
$ git trac pull develop
$ Run "make" if develop was not up to date
$ git checkout -b _
$ git trac pull 

If I already had a branch checking out #ticketno, then I'll delete it
first. This way, you'll never inadvertently check out an old releases of
Sage. I'm sure many developers are using variations of this schema.

IMHO, this or a similar way of checking out should be the recommended
one in the Sage Developer's manual. It would save a lot of people a lot
of compilation time.

Best,
Johan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Volker Braun]

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



On Saturday, September 10, 2016 at 11:25:15 AM UTC+2, Johan S. R. Nielsen 
wrote:
>
> 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 again, a lot 
> > of files get changed again. The fact that they are changed to have the 
> > same content that they originally had, is irrelevant. As far as the 
> > filesystem is concerned, those files are changed. 
>
> Yes, and even fixing Cythonizing to using file hashes is only a partial 
> solution, right: Make would still cause huge recompilations all over the 
> place, AFAIK. 
>
> I've completely stopped jumping directly between tickets, and always use 
> the following schema for checking out a ticket: 
>
> $ git checkout develop 
> $ git trac pull develop 
> $ Run "make" if develop was not up to date 
> $ git checkout -b _ 
> $ git trac pull  
>
> If I already had a branch checking out #ticketno, then I'll delete it 
> first. This way, you'll never inadvertently check out an old releases of 
> Sage. I'm sure many developers are using variations of this schema. 
>
> IMHO, this or a similar way of checking out should be the recommended 
> one in the Sage Developer's manual. It would save a lot of people a lot 
> of compilation time. 
>
> Best, 
> Johan 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Harald Schilly]

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 404, for whatever reason. 



What is a good solution  here? I would suggest such a redirect from 
mirror/win/README.txt to the wiki page?

-- h

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: PYTHONUSERBASE?

[Volker Braun]

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 seconds installing my favorite package into Sage than an 
hour debugging what in ~/.local makes Sage crash. 

And there are a lot of potential conflicts; for startes if you compile Sage 
with SAGE_DEBUG=yes then the Python ABI will be incompatible with any 
extension modules in ~/.local

If anything I would document that you can opt-in to the account-wide 
packages by running "PYTHONUSERBASE=~/.local sage"








On Friday, September 9, 2016 at 5:38:58 PM UTC+2, William wrote:
>
> Hi, 
>
> I personally disagree with trying to make Sage's python and the 
> general environment be as isolated as possibly from each other. We 
> should try to interoperate with the greater Python world as much as 
> possible, not change things to discourage that. If you want total 
> isolation, use Docker, don't mess with environment variables like 
> this... 
>
> I realize that this might just get closed due to philosophical 
> differences. How about just document PYTHONUSERBASE in our FAQ or 
> something (like it is in python) and trust users to have a clue? 
>
> I've made https://trac.sagemath.org/ticket/21456 about this.  However, 
> the authors of the new code in Sage that sets PYTHONUSERBASE if it 
> isn't set, might have a very different opinion, and for a good reason. 
> Thoughts? 
>
>  -- William 
>
>
> -- 
> William (http://wstein.org) 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Johan S . H . Rosenkilde]

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 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've heard arguments against "gratuitously" merging the ticket to
newest release when e.g. just fixing a typo. But that seems to me to be
a rather theoretical complaint, since the ticket will be merged later on
anyway.

I agree with the problem with the merge order which can be annoying. I
don't know if there is an obscure Git command for changing that. But if
the alternative is to spend tons of time recompiling every time I'm
checking out a ticket, I'm not sure I'll do the trade ;-)

Best,
Johan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: PYTHONUSERBASE?

[William Stein]

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 workflow. And
> Sage-the-distribution really is like a big venv.
>
> I'd rather spend 5 seconds installing my favorite package into Sage than an
> hour debugging what in ~/.local makes Sage crash.
>
> And there are a lot of potential conflicts; for startes if you compile Sage
> with SAGE_DEBUG=yes then the Python ABI will be incompatible with any
> extension modules in ~/.local
>
> If anything I would document that you can opt-in to the account-wide
> packages by running "PYTHONUSERBASE=~/.local sage"

Python itself could make those same arguments, as one can install
multiple copies of Python in different ways on a single computer.

I wish more people were interested in integrating Sage with the wider
Python ecosystem and community...

William

>
>
>
>
>
>
>
>
> On Friday, September 9, 2016 at 5:38:58 PM UTC+2, William wrote:
>>
>> Hi,
>>
>> I personally disagree with trying to make Sage's python and the
>> general environment be as isolated as possibly from each other. We
>> should try to interoperate with the greater Python world as much as
>> possible, not change things to discourage that. If you want total
>> isolation, use Docker, don't mess with environment variables like
>> this...
>>
>> I realize that this might just get closed due to philosophical
>> differences. How about just document PYTHONUSERBASE in our FAQ or
>> something (like it is in python) and trust users to have a clue?
>>
>> I've made https://trac.sagemath.org/ticket/21456 about this.  However,
>> the authors of the new code in Sage that sets PYTHONUSERBASE if it
>> isn't set, might have a very different opinion, and for a good reason.
>> Thoughts?
>>
>>  -- William
>>
>>
>> --
>> William (http://wstein.org)
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.



-- 
William (http://wstein.org)

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: PYTHONUSERBASE?

[leif]

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 venv. 
> 
> I'd rather spend 5 seconds installing my favorite package into Sage than
> an hour debugging what in ~/.local makes Sage crash. 
> 
> And there are a lot of potential conflicts; for startes if you compile
> Sage with SAGE_DEBUG=yes then the Python ABI will be incompatible with
> any extension modules in ~/.local
> 
> If anything I would document that you can opt-in to the account-wide
> packages by running "PYTHONUSERBASE=~/.local sage"

+1

As an alternative to the latter, we could also check for some
user-provided "magic" file in $PYTHONUSERBASE/... such as
OK_TO_BE_USED_BY_SAGE, say, and accept a user's setting iff that file is
present.  Same for IPYTHONDIR etc. by the way.

That way, it is 100% clear that the user actively acts at his/her own
risk (provided Sage itself *never* /creates/ that file of course).

At startup, we could in addition briefly remind the user in case such
"external" folders (settings and packages) are currently used as well.



"Cross-forwarding" from debian-science-sagemath [1] since (I think) this
fits nicely:

On Tue, Aug 23, 2016 at 11:28 PM, Jerome BENOIT  wrote:
> Is Sage a distribution ?

Hi, sorry to drop in on this as a lurker unannounced, but in my
opinion, SageMath is definitely a distribution. It's not something
that's used very widely, but for a narrow target of higher mathematics
(of a certain kind) it is very useful. It setups a rather closed
environment, where all components are tested to work well together and
have a clear version number (that can be used in scientific
publications). Drawback is, that all that is more like organically
grown and detached from the "outside world". That's definitely a bad
aspect, but hey, it still solves a lot of the tiny issues that arise,
when you try to do computational mathematics in those areas.

-- harald


(Feel free to also read the replies which -- regarding the subject of
the list -- naturally state a different point of view.)


-leif

[1]
http://lists.alioth.debian.org/pipermail/debian-science-sagemath/Week-of-Mon-20160822/94.html


> On Friday, September 9, 2016 at 5:38:58 PM UTC+2, William wrote:
> 
> Hi,
> 
> I personally disagree with trying to make Sage's python and the
> general environment be as isolated as possibly from each other. We
> should try to interoperate with the greater Python world as much as
> possible, not change things to discourage that. If you want total
> isolation, use Docker, don't mess with environment variables like
> this...
> 
> I realize that this might just get closed due to philosophical
> differences. How about just document PYTHONUSERBASE in our FAQ or
> something (like it is in python) and trust users to have a clue?
> 
> I've made https://trac.sagemath.org/ticket/21456
>  about this.  However,
> the authors of the new code in Sage that sets PYTHONUSERBASE if it
> isn't set, might have a very different opinion, and for a good reason.
> Thoughts?
> 
>  -- William
> 
> 
> -- 
> William (http://wstein.org)


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[leif]

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
> 
>  
> http://doc.sagemath.org/html/en/installation/binary.html#microsoft-windows
> 
> 
> 
> 
> gives a 404, for whatever reason. 
> 
> 
> What is a good solution  here? I would suggest such a redirect from
> mirror/win/README.txt to the wiki page?

Well, or to (the analogue of)

http://files.sagemath.org/win/README.txt

or

http://files.sagemath.org/win/README-virtualbox.txt

which is the same file (or an identical copy of the former), as
mentioned in my previous post.


In Sage 7.4, we can just change the link in the Installation Guide to
directly lead to the wiki page, which IMHO at least currently makes more
sense.


-leif


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[leif]

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 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 you
> change
> > timestamps of modified files. Git does not track timestamps. Updated
> > timestamps cause recompilation.
> 
> So... instead of using timestamps, maybe Cython should use file hashes
> to determine whether or not to recompile code?My distant memory of
> when we first wrote the cython dep code for Sage long long ago was
> that I used timestamps, then Craig Citro or Robert Bradshaw wrote
> something better using hashes, but I'm not sure.  I'm cc'ing them in
> case they have any thoughts.
> 
> 
> -- 
> William (http://wstein.org)


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: PYTHONUSERBASE?

[Volker Braun]

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, the emphasis that Python places on isolated venvs supports my 
point. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[leif]

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 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 more precisely, to later review exactly
the commits that belong to the ticket in question.


> I've heard arguments against "gratuitously" merging the ticket to
> newest release when e.g. just fixing a typo. But that seems to me to be
> a rather theoretical complaint, since the ticket will be merged later on
> anyway.

Absolutely not, unless you're /creating/ a new / "the" branch on the
ticket.  If you're taking an already existing branch from a ticket and
make changes to be pushed back later, you should *always* fetch, not
pull into whatever head you currently have locally.

But maybe I just misunderstood you.

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 get merge conflicts with later betas if you base your branch on
master.  (But you'd notice that sooner or later when looking at the
colour of the branch on the trac ticket -- unfortunately nobody ever
gets notified when the colour changes after trac's develop has been
updated to the next beta, something either trac or a patchbot could
implement.)

If you always base your branches on the latest *beta*, others will just
get forced to pull and build the latter (with typically loads of
completely unrelated changes), no matter whether they fetch or pull your
branch.  So in other words, you're (at least potentially) moving rebuild
load to others.


-leif

> I agree with the problem with the merge order which can be annoying. I
> don't know if there is an obscure Git command for changing that. But if
> the alternative is to spend tons of time recompiling every time I'm
> checking out a ticket, I'm not sure I'll do the trade ;-)
> 
> Best,
> Johan


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: PYTHONUSERBASE?

[Volker Braun]

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 emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Volker Braun]

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. 
>
> 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 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 you 
> > change 
> > > timestamps of modified files. Git does not track timestamps. 
> Updated 
> > > timestamps cause recompilation. 
> > 
> > So... instead of using timestamps, maybe Cython should use file 
> hashes 
> > to determine whether or not to recompile code?My distant memory 
> of 
> > when we first wrote the cython dep code for Sage long long ago was 
> > that I used timestamps, then Craig Citro or Robert Bradshaw wrote 
> > something better using hashes, but I'm not sure.  I'm cc'ing them in 
> > case they have any thoughts. 
> > 
> > 
> > -- 
> > William (http://wstein.org) 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: PYTHONUSERBASE?

[William Stein]

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.
>>
>
> Thats not really a valid argument, you are comparing apples and oranges.
>
> If anything, the emphasis that Python places on isolated venvs supports my
> point.
>


I think it's a valid argument though you're kind of right - it seems to be
an argument more for your point than mine.

I should better support and encourage use of venvs in SMC of course.   And
good point about LD PATH.



> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com
> 
> .
> To post to this group, send email to sage-devel@googlegroups.com
> .
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Sent from my massive iPhone 6 plus.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Johan S . H . Rosenkilde]

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 more precisely, to later review exactly
> the commits that belong to the ticket in question.

I'd say that's a Git tools question. Without flags, git log will show
the individual commits in chronological order, but you can ask to do
topsort or something. Personally, it seldom comes up for me, and when it
has, I've been able to get by using the commit numbers given by Trac or
searching through the log. Sure, I probably have not been involved in
the most complicated tickets Sage has ever seen, though.

>> I've heard arguments against "gratuitously" merging the ticket to
>> newest release when e.g. just fixing a typo. But that seems to me to be
>> a rather theoretical complaint, since the ticket will be merged later on
>> anyway.
>
> Absolutely not, unless you're /creating/ a new / "the" branch on the
> ticket.  If you're taking an already existing branch from a ticket and
> make changes to be pushed back later, you should *always* fetch, not
> pull into whatever head you currently have locally.
>
> But maybe I just misunderstood you.

"whatever head" is always develop, so I'm always pulling into the newest
beta release.

> 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 get merge conflicts with later betas if you base your branch on
> master.  (But you'd notice that sooner or later when looking at the
> colour of the branch on the trac ticket -- unfortunately nobody ever
> gets notified when the colour changes after trac's develop has been
> updated to the next beta, something either trac or a patchbot could
> implement.)
>
> If you always base your branches on the latest *beta*, others will just
> get forced to pull and build the latter (with typically loads of
> completely unrelated changes), no matter whether they fetch or pull your
> branch.  So in other words, you're (at least potentially) moving rebuild
> load to others.

I don't see why all developers shouldn't always be on the latest beta.

It's also the only version that would make sense to base *all* future
tickets on, though - as you say - many tickets might not care about the
diff between master and develop. So in the interest of minimising
compilation time for developers overall, I think we should base all
tickets on the latest beta. Otherwise, when you jump between
small-ticket-A and small-ticket-B, you might suddenly trigger a huge
recompile since B happened to need one of the 100 tickets between master
and develop, while A didn't.

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?

Best,
Johan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Nils Bruin]

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 get merge conflicts with later betas if you base your branch on 
> master. 


I would think so too. What's more, I'd say "git trac checkout " on a ticket that has no branch connected (yet) should do whatever 
is best. I don't think it bases a branch on master, but on develop. If it's 
clear what the best base is for new ticket branches, I'd say "git trac 
checkout" should do that.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[leif]

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.
>>
>> I'd rather say "impossible", or more precisely, to later review exactly
>> the commits that belong to the ticket in question.
> 
> I'd say that's a Git tools question. Without flags, git log will show
> the individual commits in chronological order, but you can ask to do
> topsort or something. Personally, it seldom comes up for me, and when it
> has, I've been able to get by using the commit numbers given by Trac or
> searching through the log. Sure, I probably have not been involved in
> the most complicated tickets Sage has ever seen, though.

Well, probably it's just me, but I always (also) review tickets on trac
(i.e., via what git-o-lite gives); the whole branch, but also each
individual commit.  You just need a browser to do so.

Having a Sage installation at hand, it's even more tedious to do so on
the command line when the relevant commits are "out-of-order" / mixed
with unrelated commits.


>>> I've heard arguments against "gratuitously" merging the ticket to
>>> newest release when e.g. just fixing a typo. But that seems to me to be
>>> a rather theoretical complaint, since the ticket will be merged later on
>>> anyway.
>>
>> Absolutely not, unless you're /creating/ a new / "the" branch on the
>> ticket.  If you're taking an already existing branch from a ticket and
>> make changes to be pushed back later, you should *always* fetch, not
>> pull into whatever head you currently have locally.
>>
>> But maybe I just misunderstood you.
> 
> "whatever head" is always develop, so I'm always pulling into the newest
> beta release.

Well, that doesn't make much of a difference, unless the ticket is
incidentally based on the same (which is rarely the case, since most
tickets live longer than a single beta-release cycle).  And as said,
whether you pull or fetch is only relevant if you push back changes.  I
guess you review and test many more tickets than you actually push
reviewer changes to.

For trivial changes, you can also put inline patches onto trac the owner
of the ticket / branch can easily apply, and for more complex changes,
you can always create a new branch on trac *without* changing the
ticket's branch to that.  Then the owner of the original branch can
cherry-pick from your branch, if it's based on something else.

(With different Sage installations, you could do similar locally of
course, i.e., "backport" the changes you made on top of your develop to
master+fetched original branch, say, and push the resulting branch.  I
personally often first make changes in some random Sage installation,
then moving them around, later pushing to trac from a "suited" one.)


>> 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 get merge conflicts with later betas if you base your branch on
>> master.  (But you'd notice that sooner or later when looking at the
>> colour of the branch on the trac ticket -- unfortunately nobody ever
>> gets notified when the colour changes after trac's develop has been
>> updated to the next beta, something either trac or a patchbot could
>> implement.)
>>
>> If you always base your branches on the latest *beta*, others will just
>> get forced to pull and build the latter (with typically loads of
>> completely unrelated changes), no matter whether they fetch or pull your
>> branch.  So in other words, you're (at least potentially) moving rebuild
>> load to others.
> 
> I don't see why all developers shouldn't always be on the latest beta.

Time?  Resources?

Note that many, I guess, have Sage installations here and there, and
most likely don't or cannot keep each of them always what you'd call
"up-to-date", but rather at one of the previous "stable" releases, or
something inbetween.


> It's also the only version that would make sense to base *all* future
> tickets on, though - as you say - many tickets might not care about the
> diff between master and develop. So in the interest of minimising
> compilation time for developers overall, I think we should base all
> tickets on the latest beta. Otherwise, when you jump between
> small-ticket-A and small-ticket-B, you might suddenly trigger a huge
> recompile since B happened to need one of the 100 tickets between master
> and develop, while A didn't.

[Random insertion:  Wasn't it you who [had to] upgrade[d] to Ubuntu
16.04 just to get the next version of Emacs? ;-) ]

Obviously, there are more "recent" beta releases than stable ones.  And
as mentioned, tickets and their branches age.

So you'll never have all tickets (not even a large percentage) based on
t

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

[Daniel Krenn]

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 and then I delete an old rc/beta. For working on a
ticket I use exactly the version of the branch of this ticket.
Recompiliation time is very low in this way (usually).

I have one additional directory "merge", which is only the git
repository without anything created for
- looking at tickets if I am in doubt about the current version (git
describe) and
- for merging in a newer stable/rc/beta into a branch.

Best wishes

Daniel

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[kcrisman]

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 message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[kcrisman]

> 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 documentation in the Jupyter notebook
>   https://trac.sagemath.org/ticket/20893
>
>
This is great news, I had no idea that live doc was now available in 
Jupyter!  Great work. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Paul Masson]

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, September 10, 2016 at 8:22:23 AM UTC-7, leif wrote:
>
> 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 
> > 
> >   
> > 
> http://doc.sagemath.org/html/en/installation/binary.html#microsoft-windows 
> > <
> http://doc.sagemath.org/html/en/installation/binary.html#microsoft-windows> 
>
> > 
> > 
> > gives a 404, for whatever reason. 
> > 
> > 
> > What is a good solution  here? I would suggest such a redirect from 
> > mirror/win/README.txt to the wiki page? 
>
> Well, or to (the analogue of) 
>
> http://files.sagemath.org/win/README.txt 
>
> or 
>
> http://files.sagemath.org/win/README-virtualbox.txt 
>
> which is the same file (or an identical copy of the former), as 
> mentioned in my previous post. 
>
>
> In Sage 7.4, we can just change the link in the Installation Guide to 
> directly lead to the wiki page, which IMHO at least currently makes more 
> sense. 
>
>
> -leif 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Jeroen Demeyer]

On 2016-09-10 18:36, Johan S. H. Rosenkilde wrote:

How do you guys cope with that?


https://en.wikipedia.org/wiki/Patience

https://ccache.samba.org/

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Jeroen Demeyer]

On 2016-09-11 08:43, Jeroen Demeyer wrote:

On 2016-09-10 18:36, Johan S. H. Rosenkilde wrote:

How do you guys cope with that?


https://en.wikipedia.org/wiki/Patience

https://ccache.samba.org/


And I forgot to mention that I have 2 complete Sage installation trees 
so I can let one compile while I use the other.


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.