Dear Jean-Pierre,
Le mercredi 2 novembre 2016 11:40:30 UTC+1, Jean-Pierre Flori a écrit :
>
> I would say we even have a shorter-time solution: close the tickets for
> including curl (modulo adding a SAGE_FAT_BINARY mode to avoid overlinking)
>
?? What do you mean ?
> and updating R (modulo a
I would say we even have a shorter-time solution: close the tickets for
including curl (modulo adding a SAGE_FAT_BINARY mode to avoid overlinking)
and updating R (modulo adding a 6-line patch to not check for https
support, note that most of the time https will be supported anyway).
On Wednesd
So far, the only plan I can propose which is consistent with the various
points that have been stated is :
I) short-term workaround : add a dependance for Sage, by :
a) depending on libcurl and its development files, or
b) depending on a systemwide R + its development files
II) solve current is
Le mardi 1 novembre 2016 15:03:19 UTC+1, Samuel Lelievre a écrit :
>
>
>
> Fri 2016-10-28 17:03:26 UTC+2, William:
>
>
>>- Python stats have come a *LONG* way in the last 10 years, with
>> libraries like Pandas. Why use rpy2 when you can much more
>> effectively use pandas and statsmode
Fri 2016-10-28 17:03:26 UTC+2, William:
>- Python stats have come a *LONG* way in the last 10 years, with
> libraries like Pandas. Why use rpy2 when you can much more
> effectively use pandas and statsmodels and so on.
>
> In my opinion, it would be way, way better to completely remov
Dear William,
Sorry to have sounded frightened by *you* : I'm frightened by the amount of
*my* ignorance...
Since it seems that I'm (almost) alone among Sage users to be interested by
the development of an interface to R, I'm exploring the options. And I'm
trying to understand things I was use
On Sun, Oct 30, 2016 at 12:09 PM, Emmanuel Charpentier
wrote:
> Dear William,
>
> thanks for this advice, which I'll consider seriously, notwithstanding its
> total opacity to me at the moment
>
> I just checked that the r interface in SMC is indeed different from what
> exists in sage "standa
Dear William,
thanks for this advice, which I'll consider seriously, notwithstanding its
total opacity to me at the moment
I just checked that the r interface in SMC is indeed different from what
exists in sage "standalone". It is also a bit difficult to understand, due
to present lack of
On Sun, Oct 30, 2016 at 1:19 AM, Emmanuel Charpentier
wrote:
> OK. It seems that a clear consensus exists for the excision of R _proprio
> dictu_ from Sage.
>
> If we break it, can we at least keep the (Sage's) pieces ? An optional
> package offering the current R interface(s) depending on a syst
OK. It seems that a clear consensus exists for the excision of R _proprio
dictu_ from Sage.
If we break it, can we at least keep the (Sage's) pieces ? An optional
package offering the current R interface(s) depending on a systemwide(at
least user-reachable) version of R and the R library might
On Friday, October 28, 2016 at 5:24:35 PM UTC, William wrote:
>
> On Fri, Oct 28, 2016 at 9:38 AM, Dima Pasechnik > wrote:
> >
> >
> > On Friday, October 28, 2016 at 3:03:26 PM UTC, William wrote:
> >>
> >> Hi,
> >>
> >> Regarding the openssl dependency issue, the standard way people
> >
>
> It's ridiculous that we spend no effort on pandas/statsmodels, and all
> this
> effort on R.
+1
> For example, I recall that there are some issues involving pandas +
> statsmodels + the sage preparser.
>
I use Pandas in the default Sage Interpreter on a daily basis and have only
On Friday, October 28, 2016 at 8:03:26 AM UTC-7, William wrote:
>
> we should **completely and totally remove R
> from Sage**.
>
We could also demote the R package to "optional" or "experimental" status.
I'd support that.
--
You received this message because you are subscribed to the Google
On Fri, Oct 28, 2016 at 9:38 AM, Dima Pasechnik wrote:
>
>
> On Friday, October 28, 2016 at 3:03:26 PM UTC, William wrote:
>>
>> Hi,
>>
>> Regarding the openssl dependency issue, the standard way people
>> justify getting around it is the "system library exemption", which
>> allows for GPL'd progr
On Friday, October 28, 2016 at 3:03:26 PM UTC, William wrote:
>
> Hi,
>
> Regarding the openssl dependency issue, the standard way people
> justify getting around it is the "system library exemption", which
> allows for GPL'd programs to link in system libraries that are not
> GPL'd (otherwis
Hi,
Regarding the openssl dependency issue, the standard way people
justify getting around it is the "system library exemption", which
allows for GPL'd programs to link in system libraries that are not
GPL'd (otherwise, things like GPL software on MS Windows would be
impossible!). Some links her
On Friday, October 28, 2016 at 3:58:42 PM UTC+2, Volker Braun wrote:
>
> I think you are making it more difficult than it is. I'm pretty sure our
> binaries already depend on openssl being installed, and we do this under
> the GPL system library exception. We just can't ship our own openssl (no
I think you are making it more difficult than it is. I'm pretty sure our
binaries already depend on openssl being installed, and we do this under
the GPL system library exception. We just can't ship our own openssl (nor
would I want to).
So we may just as well include libcurl, linked to the sys
Hi,
On 28/10/2016 15:39, Emmanuel Charpentier wrote:
However, this does not seem to be a problem per se : Debian (one of the
most nitpicking distros in terms of licensing) happily ships libraries
and utilities (such as cups, for starter) linked with openssl-linked
libcurl. I think that it wou
My thoughts so far :
I : Is there really a problem ?
=
What all the brouhaha around libcurl boils down to is that there *might* be
a (pseudo)-legal difficulty in shipping a libcurl liibrary requiring
OpenSSL and a GPL-licensed piece of software *in the same package*. This
m
20 matches
Mail list logo