Trac #28877 may benefit from review.
96 views
Skip to first unread message
Emmanuel Charpentier
Dec 13, 2019, 8:05:10 AM12/13/19
to sage-devel
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...
E. Madison Bray
Dec 13, 2019, 8:12:01 AM12/13/19
to sage-devel
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.
But given that it's just a bug fix release I can't imagine there's a problem...
Dima Pasechnik
Dec 13, 2019, 8:46:08 AM12/13/19
to sage-devel
with https://trac.sagemath.org/ticket/27870 ready soon (in some form
good for the users of openblas, at least),
the last hurdle that prevents the use of system R, its dependence on (open)blas,
should be cleared, and I'll plan to get it fixed then.
> --
> 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+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAOTD34YwK9%2B4Q_%3DEmCiCZci0sBQ4_C3ht%3DSknqOcX%2BBdCvLsfQ%40mail.gmail.com.
good for the users of openblas, at least),
the last hurdle that prevents the use of system R, its dependence on (open)blas,
should be cleared, and I'll plan to get it fixed then.
> 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+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAOTD34YwK9%2B4Q_%3DEmCiCZci0sBQ4_C3ht%3DSknqOcX%2BBdCvLsfQ%40mail.gmail.com.
Emmanuel Charpentier
Dec 13, 2019, 11:16:17 AM12/13/19
to sage-devel
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).
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...
But given that it's just a bug fix release I can't imagine there's a problem...
Famous last words...
Emmanuel Charpentier
Dec 13, 2019, 11:26:07 AM12/13/19
to sage-devel
Le vendredi 13 décembre 2019 14:46:08 UTC+1, Dima Pasechnik a écrit :
with https://trac.sagemath.org/ticket/27870 ready soon
I didn't see it becoming needs_review. I'll have a look ASAP. (But don't homd your breath : we also have a government to topple... ;-).
(in some form
good for the users of openblas, at least),
That may become a problem : at least on Unix, openblas is but an option for R users, who can also elect some other Atlas implementation (possibly with fine-tuning to the current system: that's what ebian proposes...). I do not know what is the situation is for other Linuces, other Unices (if we still support them), <Shudder> Mac OS and <DoubleShudde> Windows </DoubleShudder></Shudder>...
Maybe run a quick pool about this on sage-devel ?
the last hurdle that prevents the use of system R, its dependence on (open)blas,
should be cleared, and I'll plan to get it fixed then.
That would be definitely great ! Thinning sage-the-distribution is a Good Thing (TM).
On Fri, Dec 13, 2019 at 1:12 PM E. Madison Bray <erik...@gmail.com> wrote:
>
> 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.
>
> But given that it's just a bug fix release I can't imagine there's a problem...
>
> --
> 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-...@googlegroups.com.
Dima Pasechnik
Dec 13, 2019, 12:23:35 PM12/13/19
to sage-devel
On Fri, Dec 13, 2019 at 4:26 PM Emmanuel Charpentier
<emanuel.c...@gmail.com> wrote:
>
>
>
> Le vendredi 13 décembre 2019 14:46:08 UTC+1, Dima Pasechnik a écrit :
>>
>> with https://trac.sagemath.org/ticket/27870 ready soon
>
>
> I didn't see it becoming needs_review. I'll have a look ASAP. (But don't homd your breath : we also have a government to topple... ;-).
>
>>
>> (in some form
>> good for the users of openblas, at least),
>
>
> That may become a problem : at least on Unix, openblas is but an option for R users, who can also elect some other Atlas implementation (possibly with fine-tuning to the current system: that's what ebian proposes...). I do not know what is the situation is for other Linuces, other Unices (if we still support them), <Shudder> Mac OS and <DoubleShudde> Windows </DoubleShudder></Shudder>...
>
> Maybe run a quick pool about this on sage-devel ?
>
it is in no way prevent use of other Blas/Lapack implementations (run
<emanuel.c...@gmail.com> wrote:
>
>
>
> Le vendredi 13 décembre 2019 14:46:08 UTC+1, Dima Pasechnik a écrit :
>>
>> with https://trac.sagemath.org/ticket/27870 ready soon
>
>
> I didn't see it becoming needs_review. I'll have a look ASAP. (But don't homd your breath : we also have a government to topple... ;-).
>
>>
>> (in some form
>> good for the users of openblas, at least),
>
>
> That may become a problem : at least on Unix, openblas is but an option for R users, who can also elect some other Atlas implementation (possibly with fine-tuning to the current system: that's what ebian proposes...). I do not know what is the situation is for other Linuces, other Unices (if we still support them), <Shudder> Mac OS and <DoubleShudde> Windows </DoubleShudder></Shudder>...
>
> Maybe run a quick pool about this on sage-devel ?
>
configure with --with-blas=atlas)
So there is nothing to poll about here, I think.
>>
>> the last hurdle that prevents the use of system R, its dependence on (open)blas,
>> should be cleared, and I'll plan to get it fixed then.
>
>
> That would be definitely great ! Thinning sage-the-distribution is a Good Thing (TM).
>
Dima
>>
>> On Fri, Dec 13, 2019 at 1:12 PM E. Madison Bray <erik...@gmail.com> wrote:
>> >
>> > 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.
>> >
>> > But given that it's just a bug fix release I can't imagine there's a problem...
>> >
>> > --
>> > 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-...@googlegroups.com.
>> > To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAOTD34YwK9%2B4Q_%3DEmCiCZci0sBQ4_C3ht%3DSknqOcX%2BBdCvLsfQ%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/5f1e33da-3236-47c6-8c93-b08ffcac33bf%40googlegroups.com.
E. Madison Bray
Dec 16, 2019, 6:06:52 AM12/16/19
to sage-devel
On Fri, Dec 13, 2019 at 5:16 PM Emmanuel Charpentier
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. 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. 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.
> 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. I think R is popular enough that there is value
in having an interface to it, but I tend to agree that distributing R
with Sage by default is not so useful; it should instead be easier to
configure Sage to interface to an existing system R if there is one.
<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
>
> 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).
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. 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. 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.
> 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...
open-source, so can be distributed as part of Sage anyways, whereas
the other M's aren't. I think R is popular enough that there is value
in having an interface to it, but I tend to agree that distributing R
with Sage by default is not so useful; it should instead be easier to
configure Sage to interface to an existing system R if there is one.
Dima Pasechnik
Dec 16, 2019, 9:28:16 AM12/16/19
to sage-devel, Erik Bray
Please have a look. It tests OK on various Debian/Ubuntu, on
(obsolete) Fedora 26 I had to supply openplas.pc, as it does
not install it, and even on MacOS 10.13 with R and openblas from
Homebrew it tests just fine.
It should be possible to use the "native" R installation, if they
supplied libR.pc (which they don't, but
it should be easy to produce one).
>
> --
> 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+...@googlegroups.com.
Emmanuel Charpentier
Dec 16, 2019, 10:01:35 AM12/16/19
to sage-devel
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.
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).
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...).
> 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...).
Emmanuel Charpentier
Dec 16, 2019, 10:09:59 AM12/16/19
to sage-devel
Le lundi 16 décembre 2019 15:28:16 UTC+1, Dima Pasechnik a écrit :
According to this bug report, this should be fixed in Debian Real Soon Now(TM), but it seems that this fix has triggered another bug. Mektoub...
and even on MacOS 10.13 with R and openblas from
Homebrew it tests just fine.
It should be possible to use the "native" R installation, if they
supplied libR.pc (which they don't, but
it should be easy to produce one).
Upstream creates libR.pc ; it is also present in Debian packages. Do you mean it is a Mac OS-specific problem ?
E. Madison Bray
Dec 16, 2019, 10:13:09 AM12/16/19
to sage-devel
On Mon, Dec 16, 2019 at 4:01 PM Emmanuel Charpentier
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.
<emanuel.c...@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
>
>
>
> 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.
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).
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...).
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...).
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.
Dima Pasechnik
Dec 16, 2019, 10:17:07 AM12/16/19
to sage-devel
it is specific to MacOS "binary* distributed by R project. It includes libR and headers, but no libR.pc
if providing the latter works, we should report it to them.
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/64b4d468-77d4-4898-b768-69195cc5083d%40googlegroups.com.
Emmanuel Charpentier
Dec 16, 2019, 10:39:07 AM12/16/19
to sage-devel
Le lundi 16 décembre 2019 16:13:09 UTC+1, E. Madison Bray a écrit :
[ Bandwidth savings... ]
> 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.
That's the problem...
I don't
think that has anything to do with whether not Sage itself is a "first
class citizen".
Again, my choice of words may hjave been suboptimal...
>> 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
=)
I've heard pleasant things about WSL2, which *might* become an alternate solution (if and when it is released for public consumption, not for "Insider" use...). It boasts "two-way transparency" in those inter-system calls.
It's Windows 10-only, but Windows 7 is due for end of support in January 2020, and windows 8 is already (as far I understand Microsoft policies) in "extended support" (i. e. not very much maintained beyond obvious security issues).
>> > 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.
Anyway, our rpy2 policy has to be reviewed: we are stuck with an obsolete versin of rpy2 because it is (almost ?) the last Python 2-compatible version available. If/when we drop Python 2 compatibility, an upgrade will be very welcome...
E. Madison Bray
Dec 16, 2019, 10:46:24 AM12/16/19
to sage-devel
On Mon, Dec 16, 2019 at 4:39 PM Emmanuel Charpentier
<emanuel.c...@gmail.com> wrote:
> Le lundi 16 décembre 2019 16:13:09 UTC+1, E. Madison Bray a écrit :
>
> [ Bandwidth savings... ]
>
>> > 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.
>
>
> That's the problem...
>
>>
>> I don't
>> think that has anything to do with whether not Sage itself is a "first
>> class citizen".
>
>
> Again, my choice of words may hjave been suboptimal...
>
>
>> >> 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
>> =)
>
>
> I've heard pleasant things about WSL2, which *might* become an alternate solution (if and when it is released for public consumption, not for "Insider" use...). It boasts "two-way transparency" in those inter-system calls.
>
> It's Windows 10-only, but Windows 7 is due for end of support in January 2020, and windows 8 is already (as far I understand Microsoft policies) in "extended support" (i. e. not very much maintained beyond obvious security issues).
Same thing I've always said about WSL: It's fine for power users and
<emanuel.c...@gmail.com> wrote:
> Le lundi 16 décembre 2019 16:13:09 UTC+1, E. Madison Bray a écrit :
>
> [ Bandwidth savings... ]
>
>> > 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.
>
>
> That's the problem...
>
>>
>> I don't
>> think that has anything to do with whether not Sage itself is a "first
>> class citizen".
>
>
> Again, my choice of words may hjave been suboptimal...
>
>
>> >> 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
>> =)
>
>
> I've heard pleasant things about WSL2, which *might* become an alternate solution (if and when it is released for public consumption, not for "Insider" use...). It boasts "two-way transparency" in those inter-system calls.
>
> It's Windows 10-only, but Windows 7 is due for end of support in January 2020, and windows 8 is already (as far I understand Microsoft policies) in "extended support" (i. e. not very much maintained beyond obvious security issues).
developers, but is not available by default nor designed for end-user
software installation.
WSL 2 is even somewhat worse in this regard: With WSL 1 they were
trying to build POSIX-compatibility directly into the kernel, so
hypothetically it would be possible one day to install software
containing ELF binaries on Windows and have it "just work" (even if
that was not made to work by design initially). Now they've given up
on that (surprise surprise, it's hard! Maybe they should have hired
some of the Cygwin devs...), and WSL 2 just runs custom-built Linux
kernel in a VM using Hyper-V, meaning for WSL 2 to work users must
install Hyper-V and enable hardware virtualization in their BIOS.
Again, fine for power-users--completely inaccessible for people who
just want to install Sage.
Reply all
Reply to author
Forward
0 new messages