On Wed, Feb 11, 2015 at 4:27 PM, Andrey Novoseltsev <[email protected]> wrote: > On Wednesday, 11 February 2015 17:12:03 UTC-7, William Stein wrote: >> >> On Wed, Feb 11, 2015 at 3:56 PM, Gurshabad Grover >> <[email protected]> wrote: >> > Hello again, >> > >> > Yes, I noticed how SageCell uses a different branch of Sage. That would >> > be a >> > nice problem to solve for all future versions and developers of >> > SageCell. I >> > guess the best way to go about this would be to carefully find out the >> > exact >> > differences between the two branches being used and figuring out a >> > solution >> > for each difference. I'd love to help with the Javascript parts, let me >> > know >> > what exactly I'll be looking at in that situation and how I should >> > begin. >> >> There's a basic philosophical reason that this problem exists in Sage >> Cell and not in SageMathCloud, say, where I have to deal with >> precisely the same compatibility problems -- except on I think a >> larger scale. >> >> There are three options: >> >> 1. Maintain a separate branch and repeatedly merge/rebase it against >> each new version of Sage. >> >> 2. Monkey patch the Sage library on startup to make all necessary >> changes. >> >> 3. Significantly modify Sage so that every single change that >> SageCell (and SageMathCloud) has to make to the Sage library can be >> done via a clearly documented hook/API/plugin mechanism. >> >> >> Option 1 is what Sage cell does right now. It's technically the >> worst, hardest to maintain, and people are not happy with it. >> >> Option 2 is what SageMathCloud does right now. It's technically bad >> too since it's potentially confusing/ugly/random, but it's pretty easy >> to maintain and flexible. For SMC, 1 is simply not an option, since >> what SMC does has to work with whatever random copy of sage people >> build for themselves. But it is an option for SageCell, since >> SageCell only supports one canonical sage install. >> >> Option 3 is probably the best technically, and both Sage cell and SMC >> (and IPython) could use it. It is hard technically to implement, and >> would also require waiting a while until it actually gets into Sage. >> It's even harder socially, since technically it isn't really doing >> anything, but you have to get several people to agree on an API. >> >> Often patches to sage take months (or more) from when they are >> basically done to when they get into Sage, due our current pace of >> development (since we have very little money and most work is done in >> people's spare time). Due to things being slow, if there's one extra >> new thing about Sage that needs to be changed for SMC or SageCell, and >> there's no hook in the plugin mechanism for it (e.g., change >> pretty_print), then you have to do either 1 or 2 *and* also 3, and >> then switch out 1 or 2 for 3 later when it eventually gets into Sage. >> That's not fun. If Sage releases happened much more frequently >> (like every week or two, like they used to), then this wouldn't be a >> problem. But these days stable Sage releases happen maybe every 3 >> months. It might get worse, since our release manager is going to be >> much busier with other things (besides Sage) soon. >> > > Yet meanwhile, in his negative spare time, he is making steady progress to > 3: http://trac.sagemath.org/ticket/17234 and some already merged tickets.
Awesome! Personally, I'm for a hybrid of 2 and 3. Do 3 as much as possible, but do a little of 2 if necessary... -- William -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups "sage-gsoc" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-gsoc. For more options, visit https://groups.google.com/d/optout.
