On Friday, April 15, 2016 at 3:16:25 PM UTC+1, Dima Pasechnik wrote: > > > > 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> >> 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) >
in fact, it seems that things are moving here, see e.g. http://trac.sagemath.org/ticket/20276 > > > 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.
