On Saturday, April 9, 2016 at 12:17:21 AM UTC+1, William wrote: > > > > On Friday, April 8, 2016, Dima Pasechnik <dim...@gmail.com <javascript:>> > wrote: > >> >> >> On Friday, April 8, 2016 at 7:40:02 PM UTC+1, William wrote: >>> >>> >>> >>> On Friday, April 8, 2016, Volker Braun <vbrau...@gmail.com> wrote: >>> >>>> On Friday, April 8, 2016 at 6:43:46 PM UTC+2, William wrote: >>>>> >>>>> this "one other problem of Sage is that it does not define >>>>> clearly what's the public API and what's internal. >>>> >>>> >>>> IMHO thats just not true; What you get on the commandline (i.e. from >>>> sage.all import *) is public and the rest is not. If thats not enough (and >>>> really nobody ever asked) we could mark extra imports as public, e.g. by >>>> adding special sage.foo.public packages. >>>> >>> >>> >>> Why does nobody ever ask? >>> >>> >>>> >>>> If there were large body of pip-installable packages, which are user >>>>> code, this would help *define* what the public API of Sage really is, >>>>> and also give us a much larger body of code to test against before >>>>> making new releases. >>>>> >>>> >> testing against sufficiently large body of code which is not maintained >> by a project is a perfect way to make >> sure that no new releases are made by the project, ever. >> >> >> >> >> >> > > False. You are simply arguing for ignorance. How we chose to use the > results of such testing is up to us to decide. >
No, I am arguing against splitting Sage into independent fifedoms. And I have very good reasons for this. Hell, even a model where the kernel is relatively small, and there is a largish collection of independent packages (cf. GAP), functions with a lot of friction between core devs and the rest, with some package authors often endlessly pedalling back kernel changes, kernel development happening in a fork, etc etc is not something one would look forward too. A large part of work for the release manager is being a politician, not a developer, etc etc. And the reason for this is trivial - many package authors don't like to touch their code, once it is written. Which is understandable, but counter-productive for kernel development. > > >> >> >>> >>>> What API design school is that? You dump code on users and whoever >>>> manages to build the most convoluted contraption out of that will >>>> determine >>>> the future direction of the project ;-) Where is the leadership there? Who >>>> is going to handle the testing for each ticket, are you going to do that >>>> yourself? >>>> >>>> >>>> >>> I don't care about design schools. I would much rather be aware of how >>> sage-dependent code is actually being used in the wild than to sit in >>> school blissfully ignorant of how sage is really being used. >>> >> >> I thought that with SMC you have a near-perfect opportunity to see what >> Sage users use in the wild... >> > > SMC does inform my frustration with the current limitations on Sage > development. > I am afraid we see a conflict of interest here. It is in interests of SMC that Sage is very, very stable... Frozen. > > > >> >> And perhaps, perhaps, the 1st thing would be to get a single-user SMC >> frontend available as a pip-installable package, so that sagenb can retire, >> at last? >> > > SMC is not a Python program. > and because of this, it cannot get python bindings? Dima > > William > > > >> >> 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. >>>> >>> >>> >>> -- >>> Sent from my massive iPhone 6 plus. >>> >> -- >> 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. >> > > > -- > Sent from my massive iPhone 6 plus. > -- 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.
