On Mon, Dec 16, 2019 at 4:01 PM Emmanuel Charpentier <emanuel.charpent...@gmail.com> wrote: > > > > Le lundi 16 décembre 2019 12:06:52 UTC+1, E. Madison Bray a écrit : >> >> On Fri, Dec 13, 2019 at 5:16 PM Emmanuel Charpentier >> <emanuel.c...@gmail.com> wrote: >> > >> > Le vendredi 13 décembre 2019 14:12:01 UTC+1, E. Madison Bray a écrit : >> >> >> >> On Fri, Dec 13, 2019 at 2:05 PM Emmanuel Charpentier >> >> <emanuel.c...@gmail.com> wrote: >> >> > >> >> > While we are already late in the Sage 9 release cycle, Trac#28877, >> >> > which is a (routine) upgrade of R to the current release, may be of >> >> > benefit. >> >> > For non-R-users : using the latest released R is almost a sine qua non >> >> > to get help from the R-help mailing list... >> >> >> >> I will have a look at it. FWIW while I still think it's good and >> >> right to distribute R with Sage, I think serious users of R are not >> >> installing Sage to get R so I don't think we should be in the business >> >> of worrying about what is sine qua non in the R community to get help >> >> from the rest of their community. >> > >> > >> > I initially thought that getting people to "just install Sage" to get a >> > consistent and interoperable set of modeling-related software was a clean >> > way to get rid of the complexity of available software set maintainance. >> > >> > But the current state of Sage distribution makes this a bit of a dream. >> > Currently, the best way to install Sage is to compile it from source : >> > definitely not an "end-user" task... It's even worse on Windows, where >> > Sage isn't even a "first class citizen", notwithstanding the Herculean >> > efforts of one E. Madison Bray (more on this in a little while on This >> > issue). >> >> I don't think that's true. On the vast majority of systems I've >> tried, the best way to install Sage is to install the pre-compiled >> binaries. I've almost never HAD to compile Sage from source just to >> have a working Sage on some system. > > > Right. What I meant was that, at least on Windows, you have to compile Sage > if you want to be able to *try to* install an optional package.
Yes and no. Back around Sage 8.7 or 8.8 optional package installation was actually pretty well. Just recently, with 8.9 it broke again :( https://github.com/sagemath/sage-windows/issues/34 I've been working towards fixing it but haven't had much time. That's a good point though, thank you for reminding. >> It's also been packaged for most >> major Linux distributions, including the latest Debian (of course in >> that case you're not always going to get the most recent version, >> depending on the distro). I don't know what you mean by "first class >> citizen" w.r.t. Windows. > > > What I mean is that a Windows program can't call a Cygwin program > "transparently" and, vice-versa, a Cygwin program can't transparently call a > Windows program. Some common operatins (redirection/piping) are awkward (if > ever possible). It works in many cases but some cases do require finesse. I don't think that has anything to do with whether not Sage itself is a "first class citizen". >> The only extent to which it isn't is that >> there still is not a stable buildbot for Windows, despite my efforts, >> as it tends to need more maintenance than a Linux server would... very >> annoying. Other than that I don't know what you mean. So I don't >> think you should be giving anyone the wrong impressions here. > > > I should have been clearer (i tried in the lines above...). Yeah, this makes sense. It would still be ideal if Sage could run 100% natively on Windows, but that's an effort that will require I think at least another 3 years of funding for one full-time employee =) >> > Do you think that it is possible to keep the R *interface* standard while >> > R being *optional*, in a way similar to Mathematica, Magma and Maple ? It >> > might require a bit more work, R being updated at least twice annually, >> > while Mathematica's release are at multi-years intervals... >> >> I think the only reason it isn't currently is that R is free and >> open-source, so can be distributed as part of Sage anyways, whereas >> the other M's aren't. > > > What I had in mind is that our curent Mthematica (and Magma, AFAICT) > interface(s) do(es) not require the presence of any part of Mathematica > (resp. Magma) on te target sysem at Sage installation ; I'm afraid that > building the R interface (which uses rpy2) requires to know the location of > libR at compile time (but I hadn't time to peruse the rpy doc to check it...). There might be ways to work around that. For example, even if Sage were not shipped with R, rpy2 could be loaded with `LD_PRELOAD` pointing to the right libR (it would have to be a compatible libR, however, but this can also be checked at runtime). Worse comes to worse we require rebuilding rpy2. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAOTD34YzYcKSGj%2BefsOow5ux9z1upJk5L27KDnmwm-kwYN8MaQ%40mail.gmail.com.
