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 access it properly in all respects or the 3D graphics formatting was of last time I checked. The current sagenb is excellent on both those things even if the structure is dated: I want to just make clear it does *work* extremely well and that's what a user spends 80% of their time doing. It is great that SMC's notebook is actually available in some way: and here I feel that a decision needs to be made: therefore one of these should answer well: 1) "phase out" sagenb completely and* integrate SMC into the sage distributable quickly* so that it is the default option - as was hinted at a few years ago. It was in fact stated then that developing sagenb was a "waste of developer resources" 2) dump jmol and make iPython the default notebook and address its remaining incompatibilities with packages (which would need a rewrite of the sagemath API so it is no longer view model dependent I suppose) 3) create a new independent team around sagenb : decide what we need and continue Sam's work in whatever framework we want, the functional model of the code made independent from the implementation The corollary is clear: not all sagemath users want to specialize to SMC for various reasons, and the sagemath userbase (universities for example) as a distributable is going to be under threat without a viable modern *local* interface just like Maxima was years back before wxmaxima. I think William wrote something below about installing a docker and getting SMC up, very welcome indeed : I'll give that a go for starters. Best from here, Jack On Wednesday, November 23, 2016 at 9:05:50 PM UTC+1, Dima Pasechnik wrote: > > > 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 installation and use of >> > SageNB, it will still be a separate Python package, but the sources >> will >> > be in $SAGE_ROOT/src/sagenb instead of a separate git repo. The changes >> > to the Sage build system to support this move will be minimal. >> > >> > The reason is that SageNB is truly in maintenance mode currently. >> Making >> > new SageNB releases regularly to fix things is a burden for the SageNB >> > release manager Karl-Dieter Crisman. On #14840 [1], he said "the sooner >> > sagenb gets back in Sage proper, the better!" >> > >> > The original reason to split SageNB from Sage was to enable quick >> > development. That worked for a while, but now that development has >> > stalled, this reason no longer applies. A secondary reason was to make >> > SageNB truly independent from Sage, but that also never happened. So I >> > see no reason to keep SageNB split from Sage currently. >> > >> > I know this is a controversial proposal, but it will certainly be >> easier >> > to maintain SageNB this way. I also want to stress that this is >> > orthogonal to any future deprecation or removal of SageNB: we can still >> > do that from the Sage git tree. >> > >> > Jeroen. >> > >> > >> > >> > [1] http://trac.sagemath.org/ticket/14840#comment:58 >> >> Hi everyone, >> >> With the greatest respect, I disagree strongly - chopping and changing >> the notebook this way leads to a lot of instability in the code and >> confusion for anyone who wants to get into developing on sagenb projects. >> >> Added to the fact that none of us would have time to document changes in >> detail causes new contributions stagnate, which wastes effort and >> randomizes progress. >> >> Actually the functionality of the current notebook is good, the look and >> ui is very dated and as many are aware, a bit on the unpolished side. >> >> Remembering Samuel Ainsworth's really good work a few year's back, I >> would like to ask why was that system not developed and integrated into the >> local sagemath distributable? >> >> From the trials he conducted in 2012 it ran well on Sage 5.3 and was in >> my opinion a decent step forward. I'll post this to a separate question as >> I wanted to explore the possibilities of getting that up and running again, >> even if only for private use here. >> >> It doesn't seem to connect to sage 7.3 so I wanted to see if anyone knew >> why ? >> > > I understand that opinions on usability of > https://github.com/sagemath/sagenb/tree/newui > diverge. (and with the breakneck speed javascript > frameworks are developed, one may ask whether something written in 2012 is > still a great idea) > > You ask why sagenb is not developed further. > 1) the sagenb's design is really dated, and jupyter notebook seems a > better (and much better > supported) alternative. > 2) Another actively developed alternative is SMCs notebook, which can be > run > locally. > > > -- 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.
