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] <javascript:>> 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.
Current changes for the cell server are definitely less invasive/more understandable than what they've used to be and I am full of hopes for the summer. > -- William > > > > > > > In the meanwhile, I've applied to be added to the sage-cell development > > forum to keep myself updated about relevant changes in the system. > Please > > approve the request if you think this would be helpful. I'll send an > update > > over the weekend summarizing some actions and plans. > > > > Thanks a lot, > > > > On Thursday, February 12, 2015 at 3:19:18 AM UTC+5:30, Andrey > Novoseltsev > > wrote: > >> > >> Hi Gurshabad, > >> > >> Contributions to SageCell are certainly welcome! In particular it would > be > >> nice to make it "more standalone" in the sense of not needing any > patches to > >> Sage (which will greatly simplify upgrading to new Sage versions since > there > >> will be no need to resolve merge conflicts and fix resulting bugs) and > >> cleaner interaction with other dependencies, chiefly IPython. I am > trying to > >> improve the situation gradually, but would not mind help, especially > with > >> the JavaScript parts. Another angle is robustness under load spikes and > nice > >> tests for it. > >> > >> Best, > >> Andrey > > > > -- > > 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] <javascript:>. > > To post to this group, send email to [email protected] > <javascript:>. > > Visit this group at http://groups.google.com/group/sage-gsoc. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > 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.
