Re: [sage-devel] Make JupyterLab a standard package

I am not sure there is a need for such distinction. As a user, you mostly don't care. As a developer, you know the "real" status. Vincent On 14/03/2018 02:08, John H Palmieri wrote: I feel like we need another class of package: "pending" (or perhaps some other name) = those which we propose to

Re: [sage-devel] Make JupyterLab a standard package

I feel like we need another class of package: "pending" (or perhaps some other name) = those which we propose to make standard soon. Most optional packages are not intended to be converted to standard, as far as I can tell, so "optional" isn't the appropriate tag in this case. John On

Re: [sage-devel] Re: GitHub authentication is live on trac.sagemath.org

Perhaps it's a silly suggestion, but what does prevent trac from using an external git server, as opposed to the internal one? Does it need to do git calls which are not possible to do remotely? If this is possible (perhaps there is even a trac plugin for this?) then it would be possible to

Re: [sage-devel] Make JupyterLab a standard package

On Tuesday, March 13, 2018 at 10:26:55 PM UTC, Samuel Lelievre wrote: > > 2018-03-13 20:01 GMT+01:00 Jeroen Demeyer >: > > > > On 2018-03-13 18:33, Samuel Lelievre wrote: > >> > >> Let me try to make the case for making JupyterLab a standard package. > > > > What is your

Re: [sage-devel] Move the automatic_names() feature into the Sage interpreter proper

On Wednesday, March 14, 2018 at 3:39:14 AM UTC+10, vdelecroix wrote: > > I remember somebdy implementing directly in Ipython at some Sage days > (there is a way to plug hooks as we do with the preparser). The hook > itself was very naive (just a while loop catching NameError in sage_eval). >

Re: [sage-devel] Make JupyterLab a standard package

2018-03-13 20:01 GMT+01:00 Jeroen Demeyer : > > On 2018-03-13 18:33, Samuel Lelievre wrote: >> >> Let me try to make the case for making JupyterLab a standard package. > > What is your case for *NOT* making it an optional package first? My view is that since it's

Re: [sage-devel] Re: Failing patchbot due to PCRE tests

Ah, no. I was trying vanilla 8.2.beta8. Best, Travis On Tuesday, March 13, 2018 at 9:09:08 PM UTC+10, Erik Bray wrote: > > On Tue, Mar 13, 2018 at 1:13 AM, Travis Scrimshaw > wrote: > > FYI - I also tried to build this on Cygwin64 last night and got stuck at > > PCRE. >

[sage-devel] Fwd: [cython-users] Cython 0.28 released

Cython 0.28 has been released, see below for the official announcement. The Sage ticket is #24111, but it needs to be updated. Hi everyone, I'm pleased to announce the immediate availability of Cython 0.28, after almost half a year of development. https://pypi.python.org/pypi/Cython/0.28

Re: [sage-devel] Make JupyterLab a standard package

On 2018-03-13 18:33, Samuel Lelievre wrote: Let me try to make the case for making JupyterLab a standard package. What is your case for *NOT* making it an optional package first? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe

Re: [sage-devel] Move the automatic_names() feature into the Sage interpreter proper

On Tue, Mar 13, 2018 at 6:36 PM, Vincent Delecroix <20100.delecr...@gmail.com> wrote: > I remember somebdy implementing directly in Ipython at some Sage days > (there is a way to plug hooks as we do with the preparser). The hook > itself was very naive (just a while loop catching NameError in

Re: [sage-devel] Move the automatic_names() feature into the Sage interpreter proper

I remember somebdy implementing directly in Ipython at some Sage days (there is a way to plug hooks as we do with the preparser). The hook itself was very naive (just a while loop catching NameError in sage_eval). I am not able to find any trace of it. But +1 for the feature at IPython level.

[sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

Tue 2018-03-13 17:32:11 UTC, Erik Bray: > > Paul Zimmerman pointed out to me that there's a feature of the legacy > Sage Notebook, automatic_names() [1], which turns on automatic > creation of symbolic variables and functions when they are not already > defined. [...] > I see no reason this

Re: [sage-devel] Make JupyterLab a standard package

Let me try to make the case for making JupyterLab a standard package. (1) According to a recent post on the Jupyter blog [0], - JupyterLab is ready for daily use. - JupyterLab will eventually replace the classic Jupyter Notebook. - JupyterLab has been over three years in the making, with over

[sage-devel] Move the automatic_names() feature into the Sage interpreter proper

Paul Zimmerman pointed out to me that there's a feature of the legacy Sage Notebook, automatic_names() [1], which turns on automatic creation of symbolic variables and functions when they are not already defined. For example, by default if you enter: sage: x + y + z you get: NameError:

Re: [sage-devel] Re: A little Python 3 status update

Thanks. I think for the doc we need at least https://trac.sagemath.org/ticket/24312 and https://trac.sagemath.org/ticket/24936 But this does not seem to be enough.. Le mardi 13 mars 2018 15:55:30 UTC+1, Erik Bray a écrit : > > On Tue, Mar 13, 2018 at 3:40 PM, Frédéric Chapoton

Re: [sage-devel] Re: A little Python 3 status update

On Tue, Mar 13, 2018 at 3:40 PM, Frédéric Chapoton wrote: > Thanks Erik. So we are getting close indeed to be able ot use the doctest > framework ! And what about doc-building (not so close to be working, I am > afraid ) ? I know I had doc builds mostly working at one point

Re: [sage-devel] Re: A little Python 3 status update

Thanks Erik. So we are getting close indeed to be able ot use the doctest framework ! And what about doc-building (not so close to be working, I am afraid ) ? Le mardi 13 mars 2018 15:31:04 UTC+1, Erik Bray a écrit : > > On Tue, Mar 13, 2018 at 2:46 PM, Erik Bray > wrote:

Re: [sage-devel] Re: A little Python 3 status update

On Tue, Mar 13, 2018 at 2:46 PM, Erik Bray wrote: > On Tue, Mar 13, 2018 at 2:42 PM, Frédéric Chapoton > wrote: >> Could you give us the precise list of tickets that are needed to make the >> doctest framework work ? > > Let me go through and make

Re: [sage-devel] Re: WeakValueDictionary: items are deleted too soon

On Tue, Mar 13, 2018 at 3:10 PM, Jeroen Demeyer wrote: > On 2018-03-13 14:42, Erik Bray wrote: >> >> But it >> sounds like that's more or less what Jeroen is proposing (as long as >> it's not caching matrices by value?) > > > I'm not caching the Element (Matrix) but the Parent

Re: [sage-devel] Re: WeakValueDictionary: items are deleted too soon

On 2018-03-13 14:42, Erik Bray wrote: But it sounds like that's more or less what Jeroen is proposing (as long as it's not caching matrices by value?) I'm not caching the Element (Matrix) but the Parent (MatrixSpace). -- You received this message because you are subscribed to the Google

Re: [sage-devel] Re: WeakValueDictionary: items are deleted too soon

On Tue, Mar 13, 2018 at 1:58 PM, Jeroen Demeyer wrote: > On 2018-03-13 10:38, Dima Pasechnik wrote: >> >> this example, assuming the matrix size is a parameter, would easily >> become a memory leak > > > You mean with my code from #24954? My idea is to cache strongly only a

Re: [sage-devel] Re: WeakValueDictionary: items are deleted too soon

On Tue, Mar 13, 2018 at 2:02 PM, Jeroen Demeyer wrote: > On 2018-03-13 12:00, Nils Bruin wrote: >> >> you'd be making life harder for the memory cache of the processor. > > > IMHO, if you worry about that, you shouldn't be writing Python. While I definitely agree with that

Re: [sage-devel] Re: A little Python 3 status update

On Tue, Mar 13, 2018 at 2:42 PM, Frédéric Chapoton wrote: > Could you give us the precise list of tickets that are needed to make the > doctest framework work ? Let me go through and make sure the exact fixes that are needed all have tickets now. I believe they should but

Re: [sage-devel] Re: A little Python 3 status update

Could you give us the precise list of tickets that are needed to make the doctest framework work ? Le mardi 13 mars 2018 12:24:33 UTC+1, Erik Bray a écrit : > > On Tue, Mar 13, 2018 at 8:48 AM, François Bissey > wrote: > > Well I should add that the current vbraun branch

Re: [sage-devel] Re: WeakValueDictionary: items are deleted too soon

On Tue, Mar 13, 2018 at 12:43 PM, Nils Bruin wrote: > On Tuesday, March 13, 2018 at 11:14:41 AM UTC, Erik Bray wrote: >> >> >> Doesn't Sage allow creating mutable matrices? In a case like that you >> should mutate the object rather than go through expensive object >> creation over

Re: [sage-devel] Re: WeakValueDictionary: items are deleted too soon

On 2018-03-13 12:00, Nils Bruin wrote: you'd be making life harder for the memory cache of the processor. IMHO, if you worry about that, you shouldn't be writing Python. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this

Re: [sage-devel] Re: WeakValueDictionary: items are deleted too soon

On 2018-03-13 10:38, Dima Pasechnik wrote: this example, assuming the matrix size is a parameter, would easily become a memory leak You mean with my code from #24954? My idea is to cache strongly only a fixed finite number (currently 128) of CachedRepresentation instances. So even if you

[sage-devel] Re: WeakValueDictionary: items are deleted too soon

Hi Dima, On 2018-03-13, Dima Pasechnik wrote: > On Tuesday, March 13, 2018 at 8:37:49 AM UTC, Jeroen Demeyer wrote: >> I can imagine a small function constructing a matrix (for which it needs >> to construct the MatrixSpace) to do some computation but not keeping >> that

Re: [sage-devel] Re: WeakValueDictionary: items are deleted too soon

On Tuesday, March 13, 2018 at 11:14:41 AM UTC, Erik Bray wrote: > > > Doesn't Sage allow creating mutable matrices? In a case like that you > should mutate the object rather than go through expensive object > creation over and over. > I think the scenario would be one where the discriminant

Re: [sage-devel] Re: A little Python 3 status update

On Tue, Mar 13, 2018 at 8:48 AM, François Bissey wrote: > Well I should add that the current vbraun branch where Volker merges tickets > before releasing betas is starting with python3. There is still a lot of work > around unicode to do before either building documentation

Re: [sage-devel] Re: A little Python 3 status update

On Tue, Mar 13, 2018 at 2:45 AM, Dima Pasechnik wrote: > by the way, is there a python3 meta-ticket? I can't find it. There are a couple very old ones that aren't entirely relevant anyore. A starting point is https://trac.sagemath.org/ticket/15530 I started doing some work

Re: [sage-devel] Re: WeakValueDictionary: items are deleted too soon

On Tue, Mar 13, 2018 at 9:36 AM, Jeroen Demeyer wrote: > On 2018-03-12 23:07, Nils Bruin wrote: >> >> Your example doesn't convince me at all that we need this change though. >> You should only consider making a change if you have a real-world >> example that would

Re: [sage-devel] Re: Failing patchbot due to PCRE tests

On Tue, Mar 13, 2018 at 1:13 AM, Travis Scrimshaw wrote: > FYI - I also tried to build this on Cygwin64 last night and got stuck at > PCRE. Did you have https://trac.sagemath.org/ticket/24756 ? Because otherwise this shouldn't even be able to happen. -- You received this

Re: [sage-devel] Re: WeakValueDictionary: items are deleted too soon

On Tuesday, March 13, 2018 at 9:38:05 AM UTC, Dima Pasechnik wrote: > > > >> I can imagine a small function constructing a matrix (for which it needs >> to construct the MatrixSpace) to do some computation but not keeping >> that matrix in memory. For example, the output of that function could

Re: [sage-devel] Re: WeakValueDictionary: items are deleted too soon

On Tuesday, March 13, 2018 at 8:37:49 AM UTC, Jeroen Demeyer wrote: > > On 2018-03-12 23:07, Nils Bruin wrote: > > Your example doesn't convince me at all that we need this change though. > > You should only consider making a change if you have a real-world > > example that would

Re: [sage-devel] Re: WeakValueDictionary: items are deleted too soon

On 2018-03-12 23:07, Nils Bruin wrote: Your example doesn't convince me at all that we need this change though. You should only consider making a change if you have a real-world example that would significantly benefit and if you can show that degradation in other normal use is minimal. A

Re: [sage-devel] Re: A little Python 3 status update

No need for Volker branch. Sage 8.2.b8 itself starts when built with python3. Le mardi 13 mars 2018 08:48:45 UTC+1, François Bissey a écrit : > > Well I should add that the current vbraun branch where Volker merges > tickets > before releasing betas is starting with python3. There is still a

Re: [sage-devel] Re: A little Python 3 status update

Well I should add that the current vbraun branch where Volker merges tickets before releasing betas is starting with python3. There is still a lot of work around unicode to do before either building documentation or running doctests. François > On 13/03/2018, at 20:14, Frédéric Chapoton

[sage-devel] Re: A little Python 3 status update

Vanilla sage is now building and starting with python3. But mostly not yet working smoothly. Next logical steps would be : make so that (1) documentation builds (2) doctest framework works Concerning meta-tickets, you can look at https://trac.sagemath.org/query?status=!closed=python3 and

[sage-devel] Re: WeakValueDictionary: items are deleted too soon

On 2018-03-12, Nils Bruin wrote: > Your example doesn't convince me at all that we need this change though. > You should only consider making a change if you have a real-world example > that would significantly benefit and if you can show that degradation in > other normal use