On Friday, April 15, 2016 at 2:25:06 PM UTC+1, Erik Bray wrote: > > On Fri, Apr 15, 2016 at 3:19 PM, Dima Pasechnik <dim...@gmail.com > <javascript:>> wrote: > > On Friday, April 15, 2016 at 1:34:57 PM UTC+1, Erik Bray wrote: > >> > >> On Thu, Apr 14, 2016 at 5:46 PM, Jeroen Demeyer <jdem...@cage.ugent.be> > > >> wrote: > >> > On 2016-04-14 17:38, Erik Bray wrote: > >> >> > >> >> Sage already has the problem of large > >> >> chunks of code that are effectively unmaintained and create a > >> >> maintenance burden on anyone serious about maintaining sage. Their > >> >> interfaces whither, and become inconsistent with the rest of the > >> >> package. It's dead weight. > >> > > >> > I disagree with the above. It's not necessarily a problem to have > >> > unmaintained-but-still-working code. > >> > >> It is a problem to have unmaintained and maybe working but poorly > >> tested and poorly integrated code that nobody knows how to maintain > >> anymore and that doesn't meet the coding and interface standards of > >> the rest of the package. > > > > > > sagenb is a good example here. A lot of it is a very old javascript > code, > > mixed up with twisted and its callbacks, and other partly outdated web > > design > > things, that perhaps noone actively involved in Sage project proper > > understands now. > > > > Attempts to replace it completely with something newer are stalled. It > > actually appears > > to be a legacy that has to be maintained for long time, as there > textbooks > > and courses > > developed and relying on it... > > > > There were attempts to improve it, which also failed, not the least by > > existence > > of better alternatives (SMC and Jupyter nb). > > I admit I obviously don't have a deep understanding of how sagenb > integrates with sage-the-library. I think a better thing to do with > it would be to determine how it currently depends on sage and maintain > those interfaces for some time to come so that it's still possible to > open and use existing sage notebooks. I agree it should be kept > functional, but folding it back into the main library seems like a > backwards approach to me :) > well:
upstream$ tar tf sagenb-0.11.7.tar sagenb-0.11.7/ sagenb-0.11.7/webassets-0.11.1.tar.gz sagenb-0.11.7/Flask-OpenID-1.2.5.tar.gz sagenb-0.11.7/python-openid-2.2.5.zip sagenb-0.11.7/itsdangerous-0.24.tar.gz sagenb-0.11.7/zope.interface-4.1.3.tar.gz sagenb-0.11.7/Flask-0.10.1.tar.gz sagenb-0.11.7/install_order sagenb-0.11.7/sagenb-0.11.7.tar.gz sagenb-0.11.7/speaklater-1.3.tar.gz sagenb-0.11.7/Flask-Babel-0.9.tar.gz sagenb-0.11.7/Twisted-15.5.0.tar.bz2 sagenb-0.11.7/Flask-Silk-0.2.tar.gz sagenb-0.11.7/pytz-2013b.zip sagenb-0.11.7/Flask-AutoIndex-0.5.tar.gz sagenb-0.11.7/Werkzeug-0.11.4.tar.gz sagenb-0.11.7/Babel-2.2.0.tar.gz sagenb-0.11.7/Flask-OldSessions-0.10.tar.gz need I say more? (of this, webassets it not used...) > >> My greatest joy as a software engineer is almost always deleting code > >> not adding it. > >> > >> I think part of the larger problem of this discussion about > >> modularization is that nobody has made any concrete proposals yet. > >> You and others state that there are parts of Sage that are too > >> difficult to separate out because they're too deeply intertwined. But > >> nobody is necessarily proposing making cuts in those places. In some > >> cases maybe the extent of their circular dependency should be taken as > >> evidence of a need for refactoring. But I also believe you that there > >> are large parts where this is not the case. Those parts I believe > >> mostly make up the core package and shouldn't be broken up. > > > > > > the core problem is that the core package is actually very big. > > It is probably 80% of Sage library. > > And it has circular dependencies simply due to the fact that they > > follow circular mathematical dependencies of various mathematical > > concepts (e.g. posets depend on graphs, graphs depend on posets, > > matroids depend on graphs and posets, yet graphs and posets also > > depend on matroids; all the three depend on a lot of algebra, llinear > and > > not, > > and again the other way around, etc etc) > > That all sounds reasonable. I don't disagree with this--at the end > the "core" library may still be quite large. > > > There a clear outliers, like finances, sagenb, graphics, and duplicates > > (functionality-wise), > > such as two different interefaces to GAP (pexpect and libGAP), to Maxima > > (pexpect vs library), > > Cutting these out would already be a huge improvement... > > (but e.g. completely replacing GAP with libGAP is quite a job...) > > Yep, I think these are the best places to focus first, as well as a > lot of the other stuff in sage.interfaces. > > What is the difficulty as it stands with completely switching over to > libGAP? I was under the (apparently false?) impression that that was > mostly a done deal by this point, despite the pexect interface still > being around. > IMHO it's still a good solid person-month of work, to clean it all up, to replace various glue functions which are GAP-specific, but absent in libGAP, etc... And libGAP itself still needs some fixes, as it does not work when one has to exchange a hell of a lot of data, IIRC. (old GAP interface reads/writes files for such cases) 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.
