Just listening in - curious what the proposed move would do for sagenb
server installs? Is there a realistic porting option for those? I assume
that authentication etc. would not just port at all to either SMC or
Jupyterhub, assuming the latter is even usable (I don't know the answer to
that)
Emmanuel Charpentier wrote:
> 2) In contrast, the Sage notebook, while quite advanced *for its time*, has
> remained a Sage-only interface. Yes, you can use a number of other tools
> with i, *as long as they are known by Sage*.
> This simultaneously enhances and limits its utility. For example, one
A few random thoughts :
1) the Jupyter notebook is an interface used by a *lot* of projects.
Jupyter kernels do exist for a large number of computing tools. It is
therefore well-developed and actively maintained.
2) In contrast, the Sage notebook, while quite advanced *for its time*, has
remai
Hi Dima,
Thankyou for your quick reply - I appreciate what you said about
development of sagenb as a whole, and actually I do see the point.
Logically therefore, as you indicate, iPython is a good alternative.
Unfortunately, it is not fully compatible with sagemath, for example R
doesn't acces
On Wednesday, November 23, 2016 at 6:42:40 PM UTC, Jack Dyson wrote:
>
> On Friday, April 15, 2016 at 10:44:21 AM UTC+2, Jeroen Demeyer wrote:
> > Hello all,
> >
> > I propose to make SageNB no longer a separate package but to move it
> > back into the Sage git tree. For purposes of installat
On Friday, April 15, 2016 at 10:44:21 AM UTC+2, Jeroen Demeyer wrote:
> Hello all,
>
> I propose to make SageNB no longer a separate package but to move it
> back into the Sage git tree. For purposes of installation and use of
> SageNB, it will still be a separate Python package, but the sources
On Fri, Apr 15, 2016 at 10:08 PM, Jeroen Demeyer wrote:
> On 2016-04-15 22:06, John H Palmieri wrote:
>>
>> I don't know if there are any right now, but I think that many of the
>> recent changes in sagenb have come because there were changes in the
>> Sage library. Maybe "difficult" is not the ri
On 2016-04-17 03:27, kcrisman wrote:
Last night I was thinking about another issue - the eventual proposed
complete removal of sagenb from Sage
Just a small addition: even if we switch to Jupyter by default, that
doesn't mean that we will drop SageNB immediately. We should still ship
it as no
> Isn't that exactly the current situation? As long as Sage and SageNB are
>> in a separate git repo, we still need somebody to accept pull requests
>> and make releases.
>>
>
> Yes, but I'm proposing that anybody on the SageNB github team (including
> you) can make the release whenever a Sag
On Fri, Apr 15, 2016 at 6:26 PM William Stein wrote:
> On Fri, Apr 15, 2016 at 2:59 PM, Volker Braun
> wrote:
> > Is there really going to be much activity on SageNB in the future? I
> > appreciate that you fixed the packaging and dependency nightmare, but it
> > seems that we are now (i.e. afte
On Saturday, April 16, 2016 at 5:57:32 AM UTC+2, Jeroen Demeyer wrote:
>
> Isn't that exactly the current situation? As long as Sage and SageNB are
> in a separate git repo, we still need somebody to accept pull requests
> and make releases.
>
Yes, but I'm proposing that anybody on the SageNB g
On 2016-04-15 23:59, Volker Braun wrote:
So as a
minimal proposal, how about we just take over the SageNB github repo and
make releases whenever we need them. Which really isn't all that often.
Isn't that exactly the current situation? As long as Sage and SageNB are
in a separate git repo, we
> > indefinitely for a new SageNB release *IS* a big problem. So as a
> minimal
> > proposal, how about we just take over the SageNB github repo and make
> > releases whenever we need them. Which really isn't all that often.
>
> +1 -- I agree 100% with everything above. If anybody wants add
On Saturday, April 16, 2016 at 12:32:44 AM UTC+2, Dima Pasechnik wrote:
>
> What I dislike about #14840 is that it creates 14 new standard packages
> (not needed for anything except sagenb), instead of just running 'sage
> --pip'. We already install stuff by 'sage --pip', e.g. the ssl support
>
On Friday, April 15, 2016 at 10:59:52 PM UTC+1, Volker Braun wrote:
>
> Is there really going to be much activity on SageNB in the future? I
> appreciate that you fixed the packaging and dependency nightmare, but it
> seems that we are now (i.e. after #14840) at the point where we are likely
>
On Fri, Apr 15, 2016 at 2:59 PM, Volker Braun wrote:
> Is there really going to be much activity on SageNB in the future? I
> appreciate that you fixed the packaging and dependency nightmare, but it
> seems that we are now (i.e. after #14840) at the point where we are likely
> to just wait and eve
Is there really going to be much activity on SageNB in the future? I
appreciate that you fixed the packaging and dependency nightmare, but it
seems that we are now (i.e. after #14840) at the point where we are likely
to just wait and eventually remove SageNB. I always found it frustrating to
do
On 2016-04-15 22:06, John H Palmieri wrote:
I don't know if there are any right now, but I think that many of the
recent changes in sagenb have come because there were changes in the
Sage library. Maybe "difficult" is not the right word, but this adds an
artificial layer of complexity: instead of
On Friday, April 15, 2016 at 10:40:25 AM UTC-7, Dima Pasechnik wrote:
>
>
>
> On Friday, April 15, 2016 at 5:06:34 PM UTC+1, John H Palmieri wrote:
>>
>> +1.
>>
>> For those who disagree, please recognize that the current situation is
>> unmanageable: there are interdependencies between sage and
On Friday, April 15, 2016 at 5:06:34 PM UTC+1, John H Palmieri wrote:
>
> +1.
>
> For those who disagree, please recognize that the current situation is
> unmanageable: there are interdependencies between sage and sagenb, so
> certain changes in sage require changes in sagenb. Getting those cha
On Fri, Apr 15, 2016 at 9:21 AM, Vincent Delecroix
<20100.delecr...@gmail.com> wrote:
> +1 (both for Jeroen proposition and John intervention)
>
> Indeed the -1 from William is just about a general philosophy that he will
> be of no help implementing.
I would like to hear what Volker thinks. I wo
+1 (both for Jeroen proposition and John intervention)
Indeed the -1 from William is just about a general philosophy that he
will be of no help implementing.
I agree with Erik remark but holding this move makes it just worse. And
doing it will not prevent us from analyzing why we failed keepi
+1.
For those who disagree, please recognize that the current situation is
unmanageable: there are interdependencies between sage and sagenb, so
certain changes in sage require changes in sagenb. Getting those changes
done in sagenb is difficult, because sagenb is not really actively
maintaine
+1
El viernes, 15 de abril de 2016, 10:44:22 (UTC+2), Jeroen Demeyer escribió:
>
> Hello all,
>
> I propose to make SageNB no longer a separate package but to move it
> back into the Sage git tree. For purposes of installation and use of
> SageNB, it will still be a separate Python package, but
+1
On Friday, April 15, 2016 at 9:44:22 AM UTC+1, Jeroen Demeyer wrote:
>
> Hello all,
>
> I propose to make SageNB no longer a separate package but to move it
> back into the Sage git tree. For purposes of installation and use of
> SageNB, it will still be a separate Python package, but the so
+1
--
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
> I propose to make SageNB no longer a separate package but to move it
> back into the Sage git tree.
>
+1
I agree.
--
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 ema
27 matches
Mail list logo
