[sage-devel] Re: ~/.sage/R created on the second run only

2018-03-04 Thread Andrey Novoseltsev
On Sunday, 4 March 2018 19:12:14 UTC-7, Andrey Novoseltsev wrote: > > On the first run of Sage, it is supposed to create some folders in .sage > What I observe is that R directory is created only on the second run (and > Sage fails to start if by then .sage is made immutable). Looking at >

[sage-devel] ~/.sage/R created on the second run only

2018-03-04 Thread Andrey Novoseltsev
Hello, On the first run of Sage, it is supposed to create some folders in .sage What I observe is that R directory is created only on the second run (and Sage fails to start if by then .sage is made immutable). Looking at https://github.com/sagemath/sage/blob/master/src/bin/sage-env I fail to

[sage-devel] Re: Asking for advice: differential operators in the global namespace

2018-03-04 Thread Nils Bruin
On Sunday, March 4, 2018 at 10:58:32 AM UTC, Eric Gourgoulhon wrote: > > > I'm also -1 for this, after the argument given by Travis on the ticket: > injecting silently names in the global namespace may override names already > defined by the user. Initially, I naively thought this was a good way

[sage-devel] Re: Compilation error: 'sage/ext/interrupt.pxi' not found

2018-03-04 Thread 'Paul Mercat' via sage-devel
You're right, I have found where I call sage/ext/interrupt.pxi and changed it and now it works. The compiler gave no information on where is the problem. It's a little bit annoying... Le dimanche 4 mars 2018 00:41:45 UTC+1, Dima Pasechnik a écrit : > > > On Saturday, March 3, 2018 at 5:19:37 PM

[sage-devel] Re: nbextensions on jupyterlab

2018-03-04 Thread mmarco
With my aproach there is no need of an extra apache server. The jupyterhub server takes care of that. I guess that my patch would conflict with the standard use (without jupyterhub). So in order to include it in the main branch we would need a way to distinguish if we are running through

[sage-devel] Re: Sagemath 8.2.beta7: issue compiling cbc

2018-03-04 Thread David Coudert
After distclean, it's now compiling. Thanks, David. -- 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

Re: [sage-devel] Re: Asking for advice: differential operators in the global namespace

2018-03-04 Thread Eric Gourgoulhon
Hi Vincent, Le dimanche 4 mars 2018 11:35:04 UTC+1, vdelecroix a écrit : > > Hi Eric, > > I agree with Kwankyu and Simon: > - the global namespace is already bloated > - abbreviations should be avoided in most places in Sage > > Thanks for your feedback. > And having the namespace modified

[sage-devel] Re: Asking for advice: differential operators in the global namespace

2018-03-04 Thread Eric Gourgoulhon
Hi Simon, Le dimanche 4 mars 2018 08:25:09 UTC+1, Simon King a écrit : > > > > What's wrong with v.div(), to cope with standard notation in SageMath? > > Nothing from my point of view: I also prefer object-oriented notations over functional ones and v.div() is already implemented in the ticket

[sage-devel] Re: Asking for advice: differential operators in the global namespace

2018-03-04 Thread Eric Gourgoulhon
> > An alternative (disapproved by the reviewer) is to inject these names in >> the global namespace only if any pseudo-Riemannian manifold is constructed, >> by means of the function sage.repl.user_globals.set_global in >> PseudoRiemannianManifold.__init__, see line 398 of >> this source

Re: [sage-devel] Re: Asking for advice: differential operators in the global namespace

2018-03-04 Thread Vincent Delecroix
Hi Eric, I agree with Kwankyu and Simon: - the global namespace is already bloated - abbreviations should be avoided in most places in Sage And having the namespace modified at the time an object is created is by far the worst solution. The following two alternatives would be fine 1) using