[sage-devel] sage stuck with GNU parallel

[Sebastiano Vigna]

I am trying to use multiple sage instances on a Linux machine using GNU 
parallel. sage works perfectly from the command line, but gets stuck (ps 
gives a "T" state--stopped) when I try to run it with parallel. If I run

sage dist-xoroshiro128/24-9-11.sage

everything works fine. If I run

echo | parallel -j1 --eta 'sage dist-xoroshiro128/24-9-11.sage'

the process get stuck (the echo is just to give parallel a task to run).

Any idea as why that might happen? Thanks!

seba

> rpm -qi sagemath
Name: sagemath
Version : 7.3
Release : 7.fc25
Architecture: x86_64

Linux nexus.law.di.unimi.it 4.11.5-200.fc25.x86_64 #1 SMP Wed Jun 14 
17:17:29 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

-- 
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.

Re: [sage-devel] How do I overwrite comparison for modules?

[Jeroen Demeyer]

This is an infinite loop:

: if type(other)!=type(self):
: #other knows how to do the comparison
: return other.__eq__(self)

The correct Python thing to do is to return NotImplemented in this case.

--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier
 wrote:
> Again : R is not only a software package but also an ecosystem. The 11638
> (as of today) packages available to R users are a large part of R usefulness
> to its users. So, "disabling downloads from CRAN" is *NOT* fine (to them, at
> least...).

I'm not saying it shouldn't be possible to install R packages at all,
any less than it should be possible to install Python packages.  My
point here was that with Python, for example, one can manually
download a package tarball or wheel from PyPI using, say, curl for
example (maybe if they running on an air-gapped network this was done
on a separate machine and sneaker-netted over, etc.).  pip can then
install from the manually downloaded package file.

I don't know if the same is possible with R but you'd think it should
be.  However R installs packages the sequence still has to be
something like

1) Download package from CRAN
2) Verify that package downloaded successfully (maybe it does this
maybe it doesn't)
3) Install the package

So it should be possible to do steps 1 and 2 manually, and then skip
straight to 3.  Admittedly running R on an air-gapped network is
probably not a situation the developers have in mind but I have very
little doubt that the use case exists.

> And, BTW : which is your vote ?

My vote now is for a re-vote :)

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Thu, Oct 19, 2017 at 5:21 PM, Emmanuel Charpentier
 wrote:
>
>
> Le mercredi 18 octobre 2017 20:36:47 UTC+2, Jeroen Demeyer a écrit :
>>
>> On 2017-10-18 19:02, Emmanuel Charpentier wrote:
>> > This option commits us to maintain (unnecessary and dangerous, IMHO)
>> > Sage-specifc SSL patches at least in R, Python and pip
>>
>> Really? Which Sage-specific SSL patches does this require in Python and
>> pip? *
>
>
> From the Python license page :
>
> The modules hashlib, posix, ssl, crypt use the OpenSSL library for added
> performance if made available by the operating system. Additionally, the
> Windows and Mac OS X installers for Python may include a copy of the OpenSSL
> libraries, so we include a copy of the OpenSSL license here:

All of this is talking about optional functionality--either modules
that are completely optional, or functionality within some modules
that are optional.  Python works just fine without SSL support.

>> It seems to me that R is the only package causing us so much trouble
>> with SSL.
>
>
> No : *I* cause "so much trouble" with SSL issues because they become
> important to R real-world usage, and I do not think that a non-communicating
> R is useful in Sage.  Python/pip SSL usage do not cause "so much trouble"
> with SSL issues because the potential users of SSL functionalities are more
> patient than I am...

Ditto William on thanking you for causing this "trouble".  I know this
is a battle you've been fighting a long time and I really hope we can
come to a resolution soon.  In pointing out that SSL is not an issue
where Python is concerned I hope it alleviates some of your concerns.
Hopefully we can browbeat R into making the same acceptance (at least
insofar as allowing offline package installs).

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Thu, Oct 19, 2017 at 10:56 PM, Thierry
 wrote:
> Hi,
>
> On Thu, Oct 19, 2017 at 08:07:19PM +0200, Luca De Feo wrote:
>> |X| Yes, we should fully support OpenSSL now, and clarify the
>> licensing issue.
>>
>> > the way our
>> > "package manager" works allows to install an optional package without
>> > having to rely on openssl (no https), we only rely on the computation of
>> > sha1
>>
>> There you go for something crippled!  https://shattered.io/
>
> sha256 is also supported by python-hashlib compiled without openssl
> support, so we could/should easily move to using it in Sage "package
> manager" (build/sage_bootstrap/tarball.py).

+1 to switching to and/or adding support for SHA-256 hashes.  As
Thierry noted that are several SHA-256 implementations for Python, in
fact, that don't rely in any way on OpenSSL or have problematic
licenses.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Fri, Oct 20, 2017 at 10:58 AM, Jeroen Demeyer  wrote:
> On 2017-10-19 20:07, Luca De Feo wrote:
>>
>> There you go for something crippled!  https://shattered.io/
>
>
> I don't think that this is actually relevant. This attack would only work if
> an attacker is able to provide a specially manufactured source tarball and
> get it accepted by SageMath. At that point, the attacker could instead just
> insert arbitrary code in the source tarball.

That's not true.  The whole point is that HTTP is ridiculously easy to
hijack, so an attacker need not get anything accepted by Sage.

It's an unlikely attack vector to be sure, but not impossible.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Jeroen Demeyer]

On 2017-10-19 17:21, Emmanuel Charpentier wrote:

I do not think that a
non-communicating R is useful in Sage.


A non-communicating R in Sage can be very useful if you are not using R 
in Sage at all (which is very likely the vast majority of Sage users).


--
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 11:24 AM, Jeroen Demeyer  wrote:
> On 2017-10-19 17:21, Emmanuel Charpentier wrote:
>>
>> I do not think that a
>> non-communicating R is useful in Sage.
>
>
> A non-communicating R in Sage can be very useful if you are not using R in
> Sage at all (which is very likely the vast majority of Sage users).

Or, as you and I have both pointed out, you *are* using R but would
prefer to use a different download method than the one built into R
(which may still use HTTPS, especially if it's necessary to access
CRAN at all, but that doesn't mean R has to be the one doing the
downloading).

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 11:28 AM, Erik Bray  wrote:
> On Mon, Oct 23, 2017 at 11:24 AM, Jeroen Demeyer  
> wrote:
>> On 2017-10-19 17:21, Emmanuel Charpentier wrote:
>>>
>>> I do not think that a
>>> non-communicating R is useful in Sage.
>>
>>
>> A non-communicating R in Sage can be very useful if you are not using R in
>> Sage at all (which is very likely the vast majority of Sage users).
>
> Or, as you and I have both pointed out, you *are* using R but would
> prefer to use a different download method than the one built into R
> (which may still use HTTPS, especially if it's necessary to access
> CRAN at all, but that doesn't mean R has to be the one doing the
> downloading).

Doing a little more research on this*, it seems that R can in fact
perfectly well install packages from compressed tarballs, etc.
(through the UI, importantly).  For downloading files it actually
supports multiple download methods, one of which is to use libcurl
(which can be built without HTTPS support; I've done so myself).  But
it also has a built-in "internal" method which may be part of the
problem.  If that can't be built without SSL support then that needs
to be fixed.  Finally, it also supports pointing to alternative
package repositories which may or may not use HTTPS.

Naturally, for the "average" user we *do* want to support transparent
package installation from CRAN with HTTPS support which is why the
OpenSSL issue needs to be resolved.  But assuming that R *can* be
built without SSL, and can work without SSL, that is acceptable too
especially for users who know what they're doing and don't need the
SSL support.  I suggest that this be allowed to proceed, just with a
loud warning (as Thierry suggested).  I'll have a look at your patch
to see what it's doing and if such a patch really needs to be
maintained or not...


* https://www.rdocumentation.org/packages/utils/versions/3.4.1/topics/INSTALL
  
https://www.rdocumentation.org/packages/utils/versions/3.4.1/topics/install.packages
  https://www.rdocumentation.org/link/download.file?package=utils&version=3.4.1

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Dear Erik,

Le lundi 23 octobre 2017 11:16:05 UTC+2, Erik Bray a écrit :
>
> On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier 
> > wrote: 
> > Again : R is not only a software package but also an ecosystem. The 
> 11638 
> > (as of today) packages available to R users are a large part of R 
> usefulness 
> > to its users. So, "disabling downloads from CRAN" is *NOT* fine (to 
> them, at 
> > least...). 
>
> I'm not saying it shouldn't be possible to install R packages at all, 
> any less than it should be possible to install Python packages.  My 
> point here was that with Python, for example, one can manually 
> download a package tarball or wheel from PyPI using, say, curl for 
> example (maybe if they running on an air-gapped network this was done 
> on a separate machine and sneaker-netted over, etc.).  pip can then 
> install from the manually downloaded package file. 
>
> I don't know if the same is possible with R but you'd think it should 
> be.  However R installs packages the sequence still has to be 
> something like 
>
> 1) Download package from CRAN 
> 2) Verify that package downloaded successfully (maybe it does this 
> maybe it doesn't) 
> 3) Install the package 
>
> So it should be possible to do steps 1 and 2 manually, and then skip 
> straight to 3.  Admittedly running R on an air-gapped network is 
> probably not a situation the developers have in mind but I have very 
> little doubt that the use case exists. 
>

Indeed, it *is* possible to install a manually downloaded package (not as 
straightforward as  the automatic download-and-install default method). But 
the problem isn't here :

There are a large number of CRAN packages (11660 as of this morning). More 
and more of these packages have mutual dependencies, which are easily 
accounted for bu install.packages() but are a pain to deal with "manually".

In fact, the problem (roughly) has same magnitude as the maintainance of 
your operating system : it *is* indeed possible to maintain a Unix/Linux 
installation using only tarballs conveyed to the system via sneakersnet, 
but it' certainly a) not fun and b) chronophage to the extreme...

As it happened with Linux distributions, these intermutual dependencies, 
which started scarce and lightweight, are getting more and more important. 
My prediction (or prognostication, or oracle, if you wish...;-) is that 
they will reach the level of complexity of operating system distributions 
in an amount of time short enough for this problem to be of interest to all 
but the oldest (i. e. closest to retirement or death) of R users.

I'm not old enough to not feel concerned ;-)...

> And, BTW : which is your vote ? 
>
> My vote now is for a re-vote :) 
>

Not possible,  given the terms of the vote (I can't pull an after-the-fact 
rule on the people who have already voted). But whatever the result is, 
there will remain the question of implementation, which might need a formal 
vote on sub-issues and methods

--
Emmanuel Charpentier

-- 
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.

Re: [sage-devel] Re: Bug? Sympy, Fricas & Giac can solve this simple integral, why not Maxima?

[Erik Bray]

On Sun, Oct 22, 2017 at 12:07 AM, Dima Pasechnik  wrote:
>
>
> On Saturday, October 21, 2017 at 10:52:48 PM UTC+1, Emmanuel Charpentier
> wrote:
>>
>> That doesn't tell us why Maxima thiks that this is a Cauch principal
>> value. In fact :
>> sage: integrate(1/cos(theta)^2,theta)
>> tan(theta)
>> which I remind having learned when I was about 15...
>>
>> Maxima bug ?
>
>
> Maxima's definite integration package appears to be a big mess,
> and it's not being given a lot of attention.
> There are dozens of bugs of this sort on their bug tracker.

Which again, maybe calls into question the choice of Maxima as the
default backend?  I'm sure the reason for this has been explained
before but it does seem like a strange thing to get wrong, especially
for integrals I knew how to do in high school


>> --
>> Emmanuel Charpentier
>>
>> Le vendredi 20 octobre 2017 08:39:03 UTC+2, Ralf Stephan a écrit :
>>>
>>> The immediate reason is that maxima returns:
>>> Principal Value
>>> (%o4)  2
>>>
>>> and Sage since #7377 (7 years ago) catches "Principal Value" and makes it
>>> divergent.
>>> See https://trac.sagemath.org/ticket/7377 for reasons this was
>>> introduced.
>>> There are tickets that urge to fix this:
>>>
>>> https://trac.sagemath.org/ticket/13511
>>> https://trac.sagemath.org/ticket/17608
>>>
>>> So it's a Sage bug in the Maxima interface.
>>>
>>> Regards,
>
> --
> 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.

-- 
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.

Re: [sage-devel] Use system R with sage?

[Erik Bray]

On Fri, Oct 20, 2017 at 11:47 PM, François Bissey  wrote:
>
>
> On 21/10/2017, at 10:37, Michael Orlitzky  wrote:
>
> On 10/20/2017 11:30 AM, Nils Bruin wrote:
>
> Do we actually get real benefit from packaging R with sage? It seems to
> me R is a very popular, very mature piece of software. Isn't it easy to
> install R on any of the platforms supported by sage? If that is the
> case, wouldn't it be much easier to let sage just work with the
> system-wide R if that is available?
>
>
>
> No, yes, yes.
>
>
>
> Of course we had those conversations before. sage interfaces with R in two
> ways:
> * directly with the R command line through the pexpect interface
> * through rpy
>
> The first way can happily use system wide R.
> The second is more complicated. We have to build sage’s rpy and rpy
> links directly to libR and that’s where the potential madness comes in,
> libR links to blas/lapack. So there is a potential clash between
> system blas/lapack and sage blas/lapack in rpy.
> This may (or not) be dealt with by being careful in building rpy in sage.

This is a problem for using some other system packages in Sage as
well, so it would be good to resolve in general.

I don't have a strong opinion on whether or not Sage should include a
package for R, or if should be standard or optional.  But I do believe
that in either case it should be able to resolve an R dependency from
the system R, as should be the case for almost any other dependency
(which is a problem I'm still working on but progress is slow due to
slow progress in getting the necessary preliminaries accepted...)

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 11:57 AM, Emmanuel Charpentier
 wrote:
> Dear Erik,
>
> Le lundi 23 octobre 2017 11:16:05 UTC+2, Erik Bray a écrit :
>>
>> On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier
>>  wrote:
>> > Again : R is not only a software package but also an ecosystem. The
>> > 11638
>> > (as of today) packages available to R users are a large part of R
>> > usefulness
>> > to its users. So, "disabling downloads from CRAN" is *NOT* fine (to
>> > them, at
>> > least...).
>>
>> I'm not saying it shouldn't be possible to install R packages at all,
>> any less than it should be possible to install Python packages.  My
>> point here was that with Python, for example, one can manually
>> download a package tarball or wheel from PyPI using, say, curl for
>> example (maybe if they running on an air-gapped network this was done
>> on a separate machine and sneaker-netted over, etc.).  pip can then
>> install from the manually downloaded package file.
>>
>> I don't know if the same is possible with R but you'd think it should
>> be.  However R installs packages the sequence still has to be
>> something like
>>
>> 1) Download package from CRAN
>> 2) Verify that package downloaded successfully (maybe it does this
>> maybe it doesn't)
>> 3) Install the package
>>
>> So it should be possible to do steps 1 and 2 manually, and then skip
>> straight to 3.  Admittedly running R on an air-gapped network is
>> probably not a situation the developers have in mind but I have very
>> little doubt that the use case exists.
>
>
> Indeed, it *is* possible to install a manually downloaded package (not as
> straightforward as  the automatic download-and-install default method). But
> the problem isn't here :
>
> There are a large number of CRAN packages (11660 as of this morning). More
> and more of these packages have mutual dependencies, which are easily
> accounted for bu install.packages() but are a pain to deal with "manually".
>
> In fact, the problem (roughly) has same magnitude as the maintainance of
> your operating system : it *is* indeed possible to maintain a Unix/Linux
> installation using only tarballs conveyed to the system via sneakersnet, but
> it' certainly a) not fun and b) chronophage to the extreme...
>
> As it happened with Linux distributions, these intermutual dependencies,
> which started scarce and lightweight, are getting more and more important.
> My prediction (or prognostication, or oracle, if you wish...;-) is that they
> will reach the level of complexity of operating system distributions in an
> amount of time short enough for this problem to be of interest to all but
> the oldest (i. e. closest to retirement or death) of R users.

I understand all that, and the same is true of some Python packages as
well (which is why sometimes Sage winds up having to add quite a few
spkgs for Python packages--see for example the dependencies of Flask).
But that's simply a matter that has to be dealt with, and people do
(*I* do, even, in some cases).

My point here is not that that that's a nice thing to foist on average
users (it isn't).  Just that it *should* be possible regardless,
without patching or anything else.  My concern is just why are we
maintaining a patch just to be able to build R without SSL...

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Dear Jeroen

Le lundi 23 octobre 2017 11:24:18 UTC+2, Jeroen Demeyer a écrit :
>
> On 2017-10-19 17:21, Emmanuel Charpentier wrote: 
> > I do not think that a 
> > non-communicating R is useful in Sage. 
>
> A non-communicating R in Sage can be very useful if you are not using R 
> in Sage at all (which is very likely the vast majority of Sage users). 
>

? You are saying that X is useful if you don't use X at all ?

Either :

   - I totally miss your point : I can't see how something can be useful if 
   you don't use it at all. Or :
   - either :
  - you are a Zen master using padoxes to enlighten your student (and 
  you failed to do so) ;
  - you are a dandy  enjoying paradoxes for the hell of it ;
  - you are preparing for a career in management or politics.
   
Would you care to explain to a dentist of very little mind ?

as for "which is very likely the vast majority of Sage users" : I do not 
know. I agree that I seem to be the only such voice on the sage-xxx lists. 
Which might be a strong argument for splitting R off Sage
 as already discussed on sage devel, and still discussed in this thread 
. But the 
last time this was discussed, the agreement seemed to be that R had to stay 
in Sage.

And that does *not* solve "our" pip's lack of functionality, nor the 
(interesting) security problem raised by Thierry.

--
Emmanuel Charpentier


 

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le lundi 23 octobre 2017 12:17:06 UTC+2, Erik Bray a écrit :
>
> On Mon, Oct 23, 2017 at 11:57 AM, Emmanuel Charpentier 
> > wrote: 
> > Dear Erik, 
> > 
> > Le lundi 23 octobre 2017 11:16:05 UTC+2, Erik Bray a écrit : 
> >> 
> >> On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier 
> >>  wrote: 
> >> > Again : R is not only a software package but also an ecosystem. The 
> >> > 11638 
> >> > (as of today) packages available to R users are a large part of R 
> >> > usefulness 
> >> > to its users. So, "disabling downloads from CRAN" is *NOT* fine (to 
> >> > them, at 
> >> > least...). 
> >> 
> >> I'm not saying it shouldn't be possible to install R packages at all, 
> >> any less than it should be possible to install Python packages.  My 
> >> point here was that with Python, for example, one can manually 
> >> download a package tarball or wheel from PyPI using, say, curl for 
> >> example (maybe if they running on an air-gapped network this was done 
> >> on a separate machine and sneaker-netted over, etc.).  pip can then 
> >> install from the manually downloaded package file. 
> >> 
> >> I don't know if the same is possible with R but you'd think it should 
> >> be.  However R installs packages the sequence still has to be 
> >> something like 
> >> 
> >> 1) Download package from CRAN 
> >> 2) Verify that package downloaded successfully (maybe it does this 
> >> maybe it doesn't) 
> >> 3) Install the package 
> >> 
> >> So it should be possible to do steps 1 and 2 manually, and then skip 
> >> straight to 3.  Admittedly running R on an air-gapped network is 
> >> probably not a situation the developers have in mind but I have very 
> >> little doubt that the use case exists. 
> > 
> > 
> > Indeed, it *is* possible to install a manually downloaded package (not 
> as 
> > straightforward as  the automatic download-and-install default method). 
> But 
> > the problem isn't here : 
> > 
> > There are a large number of CRAN packages (11660 as of this morning). 
> More 
> > and more of these packages have mutual dependencies, which are easily 
> > accounted for bu install.packages() but are a pain to deal with 
> "manually". 
> > 
> > In fact, the problem (roughly) has same magnitude as the maintainance of 
> > your operating system : it *is* indeed possible to maintain a Unix/Linux 
> > installation using only tarballs conveyed to the system via sneakersnet, 
> but 
> > it' certainly a) not fun and b) chronophage to the extreme... 
> > 
> > As it happened with Linux distributions, these intermutual dependencies, 
> > which started scarce and lightweight, are getting more and more 
> important. 
> > My prediction (or prognostication, or oracle, if you wish...;-) is that 
> they 
> > will reach the level of complexity of operating system distributions in 
> an 
> > amount of time short enough for this problem to be of interest to all 
> but 
> > the oldest (i. e. closest to retirement or death) of R users. 
>
> I understand all that, and the same is true of some Python packages as 
> well (which is why sometimes Sage winds up having to add quite a few 
> spkgs for Python packages--see for example the dependencies of Flask). 
> But that's simply a matter that has to be dealt with, and people do 
> (*I* do, even, in some cases). 
>
> My point here is not that that that's a nice thing to foist on average 
> users (it isn't).  Just that it *should* be possible regardless, 
> without patching or anything else.  My concern is just why are we 
> maintaining a patch just to be able to build R without SSL... 
>

...which is **exactly** my point !

Presently, the only reason ever given to this patch (which lifts upstream 
R's requirement on an https-enabled library) is to be able to build Sage 
without OpenSSL because it's not, in some eyes, GPL-compatible.
 
I balk at the idea of maintaining this patch again and again for this 
issue, which can be solved either by depending on a systemwide openssl (but 
there goes our "batteries included" philosophy) or including OpenSSL 
(currently not possible for licensing reasons, but that should change).

I also balk at the idea of shipping a crippled pip.

-- 
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.

[sage-devel] Re: sage stuck with GNU parallel

[Sebastiano Vigna]

Il giorno lunedì 23 ottobre 2017 10:45:31 UTC+2, Sebastiano Vigna ha 
scritto:
>
> I am trying to use multiple sage instances on a Linux machine using GNU 
> parallel. sage works perfectly from the command line, but gets stuck (ps 
> gives a "T" state--stopped) when I try to run it with parallel. If I run
>
>
>
In fact, it is a more generic problem—sage does not work when forked:

> sage dist-xoroshiro128/24-9-11.sage >dist-xoroshiro128/24-9-11.out &
[2] 12105
13:48:53 [nexus] ~/Sux4J
>

[2]+  Stopped sage dist-xoroshiro128/24-9-11.sage > 
dist-xoroshiro128/24-9-11.out 

I did my best to find bug reports about this, to no avail. :(

-- 
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.

Re: [sage-devel] How do I overwrite comparison for modules?

[Simon Brandhorst]

I am aware of this. It is just unexpected that other.__eq__(self) calls
self._eq(other)

As a user of that rich cmp method I would have expected it to call
other._eq(self).

Raising a not implemented error seems nice. :)
Anyways I believe it should be better documented if you want people to use 
these functions. 

On Monday, October 23, 2017 at 10:51:29 AM UTC+2, Jeroen Demeyer wrote:
>
> This is an infinite loop: 
>
> : if type(other)!=type(self): 
> : #other knows how to do the comparison 
> : return other.__eq__(self) 
>
> The correct Python thing to do is to return NotImplemented in this case. 
>

-- 
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.

Re: [sage-devel] Re: sage stuck with GNU parallel

[William Stein]

On Mon, Oct 23, 2017 at 4:49 AM, Sebastiano Vigna
 wrote:
>
>
> Il giorno lunedì 23 ottobre 2017 10:45:31 UTC+2, Sebastiano Vigna ha
> scritto:
>>
>> I am trying to use multiple sage instances on a Linux machine using GNU
>> parallel. sage works perfectly from the command line, but gets stuck (ps
>> gives a "T" state--stopped) when I try to run it with parallel. If I run
>>
>>
>
> In fact, it is a more generic problem—sage does not work when forked:

Use the @parallel decorator from within Sage instead:

http://doc.sagemath.org/html/en/reference/parallel/index.html

William

>
>> sage dist-xoroshiro128/24-9-11.sage >dist-xoroshiro128/24-9-11.out &
> [2] 12105
> 13:48:53 [nexus] ~/Sux4J
>>
>
> [2]+  Stopped sage dist-xoroshiro128/24-9-11.sage >
> dist-xoroshiro128/24-9-11.out
>
> I did my best to find bug reports about this, to no avail. :(
>
> --
> 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.



-- 
William (http://wstein.org)

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 12:27 PM, Emmanuel Charpentier
 wrote:
>
>
> Le lundi 23 octobre 2017 12:17:06 UTC+2, Erik Bray a écrit :
>>
>> On Mon, Oct 23, 2017 at 11:57 AM, Emmanuel Charpentier
>>  wrote:
>> > Dear Erik,
>> >
>> > Le lundi 23 octobre 2017 11:16:05 UTC+2, Erik Bray a écrit :
>> >>
>> >> On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier
>> >>  wrote:
>> >> > Again : R is not only a software package but also an ecosystem. The
>> >> > 11638
>> >> > (as of today) packages available to R users are a large part of R
>> >> > usefulness
>> >> > to its users. So, "disabling downloads from CRAN" is *NOT* fine (to
>> >> > them, at
>> >> > least...).
>> >>
>> >> I'm not saying it shouldn't be possible to install R packages at all,
>> >> any less than it should be possible to install Python packages.  My
>> >> point here was that with Python, for example, one can manually
>> >> download a package tarball or wheel from PyPI using, say, curl for
>> >> example (maybe if they running on an air-gapped network this was done
>> >> on a separate machine and sneaker-netted over, etc.).  pip can then
>> >> install from the manually downloaded package file.
>> >>
>> >> I don't know if the same is possible with R but you'd think it should
>> >> be.  However R installs packages the sequence still has to be
>> >> something like
>> >>
>> >> 1) Download package from CRAN
>> >> 2) Verify that package downloaded successfully (maybe it does this
>> >> maybe it doesn't)
>> >> 3) Install the package
>> >>
>> >> So it should be possible to do steps 1 and 2 manually, and then skip
>> >> straight to 3.  Admittedly running R on an air-gapped network is
>> >> probably not a situation the developers have in mind but I have very
>> >> little doubt that the use case exists.
>> >
>> >
>> > Indeed, it *is* possible to install a manually downloaded package (not
>> > as
>> > straightforward as  the automatic download-and-install default method).
>> > But
>> > the problem isn't here :
>> >
>> > There are a large number of CRAN packages (11660 as of this morning).
>> > More
>> > and more of these packages have mutual dependencies, which are easily
>> > accounted for bu install.packages() but are a pain to deal with
>> > "manually".
>> >
>> > In fact, the problem (roughly) has same magnitude as the maintainance of
>> > your operating system : it *is* indeed possible to maintain a Unix/Linux
>> > installation using only tarballs conveyed to the system via sneakersnet,
>> > but
>> > it' certainly a) not fun and b) chronophage to the extreme...
>> >
>> > As it happened with Linux distributions, these intermutual dependencies,
>> > which started scarce and lightweight, are getting more and more
>> > important.
>> > My prediction (or prognostication, or oracle, if you wish...;-) is that
>> > they
>> > will reach the level of complexity of operating system distributions in
>> > an
>> > amount of time short enough for this problem to be of interest to all
>> > but
>> > the oldest (i. e. closest to retirement or death) of R users.
>>
>> I understand all that, and the same is true of some Python packages as
>> well (which is why sometimes Sage winds up having to add quite a few
>> spkgs for Python packages--see for example the dependencies of Flask).
>> But that's simply a matter that has to be dealt with, and people do
>> (*I* do, even, in some cases).
>>
>> My point here is not that that that's a nice thing to foist on average
>> users (it isn't).  Just that it *should* be possible regardless,
>> without patching or anything else.  My concern is just why are we
>> maintaining a patch just to be able to build R without SSL...
>
>
> ...which is *exactly* my point !
>
> Presently, the only reason ever given to this patch (which lifts upstream
> R's requirement on an https-enabled library) is to be able to build Sage
> without OpenSSL because it's not, in some eyes, GPL-compatible.
>
> I balk at the idea of maintaining this patch again and again for this issue,
> which can be solved either by depending on a systemwide openssl (but there
> goes our "batteries included" philosophy) or including OpenSSL (currently
> not possible for licensing reasons, but that should change).

I agree.

> I also balk at the idea of shipping a crippled pip.

It's not crippled if you don't need it to install from HTTPS which not
everyone does.

Okay.  I think I see the problem here.  We're talking about multiple
issues simultaneously and some things are getting confused--some
streams crossed.

First: There is the *general* issue of whether or not these packages
need any kind of SSL support in order to function.  This is an issue
*completely* independent from Sage (except insofar as we may or may
not need to maintain some patches to ensure that they don't require
SSL, but that is a separate issue that I will get to next).  From the
general standpoint of pip's design and functionality, it does not in
any way require SSL to work.  There was a time when it did, but only
due

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 2:31 PM, Erik Bray  wrote:
> The same should be true for R,
> and if this is not the case (and I'm not convinced it isn't)

This part I take back.  I see now that in R's configure it really does
refuse to proceed if it doesn't find the right libcurl with SSL
support.  It's not possible to disable since it's now the default
download method.  This is silly though, since other download methods
still work.  It should be possible to disable the requirement at
configure time and fallback to a different default.  It's a shame we
require a patch for this for now but I can help push for an upstream
fix to this if need be, because I think it's fairly silly.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le lundi 23 octobre 2017 14:32:03 UTC+2, Erik Bray a écrit :
>
> On Mon, Oct 23, 2017 at 12:27 PM, Emmanuel Charpentier 
> > wrote: 
> > 
> > 
> > Le lundi 23 octobre 2017 12:17:06 UTC+2, Erik Bray a écrit : 
> >> 
> >> On Mon, Oct 23, 2017 at 11:57 AM, Emmanuel Charpentier 
> >>  wrote: 
> >> > Dear Erik, 
> >> > 
> >> > Le lundi 23 octobre 2017 11:16:05 UTC+2, Erik Bray a écrit : 
> >> >> 
> >> >> On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier 
> >> >>  wrote: 
> >> >> > Again : R is not only a software package but also an ecosystem. 
> The 
> >> >> > 11638 
> >> >> > (as of today) packages available to R users are a large part of R 
> >> >> > usefulness 
> >> >> > to its users. So, "disabling downloads from CRAN" is *NOT* fine 
> (to 
> >> >> > them, at 
> >> >> > least...). 
> >> >> 
> >> >> I'm not saying it shouldn't be possible to install R packages at 
> all, 
> >> >> any less than it should be possible to install Python packages.  My 
> >> >> point here was that with Python, for example, one can manually 
> >> >> download a package tarball or wheel from PyPI using, say, curl for 
> >> >> example (maybe if they running on an air-gapped network this was 
> done 
> >> >> on a separate machine and sneaker-netted over, etc.).  pip can then 
> >> >> install from the manually downloaded package file. 
> >> >> 
> >> >> I don't know if the same is possible with R but you'd think it 
> should 
> >> >> be.  However R installs packages the sequence still has to be 
> >> >> something like 
> >> >> 
> >> >> 1) Download package from CRAN 
> >> >> 2) Verify that package downloaded successfully (maybe it does this 
> >> >> maybe it doesn't) 
> >> >> 3) Install the package 
> >> >> 
> >> >> So it should be possible to do steps 1 and 2 manually, and then skip 
> >> >> straight to 3.  Admittedly running R on an air-gapped network is 
> >> >> probably not a situation the developers have in mind but I have very 
> >> >> little doubt that the use case exists. 
> >> > 
> >> > 
> >> > Indeed, it *is* possible to install a manually downloaded package 
> (not 
> >> > as 
> >> > straightforward as  the automatic download-and-install default 
> method). 
> >> > But 
> >> > the problem isn't here : 
> >> > 
> >> > There are a large number of CRAN packages (11660 as of this morning). 
> >> > More 
> >> > and more of these packages have mutual dependencies, which are easily 
> >> > accounted for bu install.packages() but are a pain to deal with 
> >> > "manually". 
> >> > 
> >> > In fact, the problem (roughly) has same magnitude as the maintainance 
> of 
> >> > your operating system : it *is* indeed possible to maintain a 
> Unix/Linux 
> >> > installation using only tarballs conveyed to the system via 
> sneakersnet, 
> >> > but 
> >> > it' certainly a) not fun and b) chronophage to the extreme... 
> >> > 
> >> > As it happened with Linux distributions, these intermutual 
> dependencies, 
> >> > which started scarce and lightweight, are getting more and more 
> >> > important. 
> >> > My prediction (or prognostication, or oracle, if you wish...;-) is 
> that 
> >> > they 
> >> > will reach the level of complexity of operating system distributions 
> in 
> >> > an 
> >> > amount of time short enough for this problem to be of interest to all 
> >> > but 
> >> > the oldest (i. e. closest to retirement or death) of R users. 
> >> 
> >> I understand all that, and the same is true of some Python packages as 
> >> well (which is why sometimes Sage winds up having to add quite a few 
> >> spkgs for Python packages--see for example the dependencies of Flask). 
> >> But that's simply a matter that has to be dealt with, and people do 
> >> (*I* do, even, in some cases). 
> >> 
> >> My point here is not that that that's a nice thing to foist on average 
> >> users (it isn't).  Just that it *should* be possible regardless, 
> >> without patching or anything else.  My concern is just why are we 
> >> maintaining a patch just to be able to build R without SSL... 
> > 
> > 
> > ...which is *exactly* my point ! 
> > 
> > Presently, the only reason ever given to this patch (which lifts 
> upstream 
> > R's requirement on an https-enabled library) is to be able to build Sage 
> > without OpenSSL because it's not, in some eyes, GPL-compatible. 
> > 
> > I balk at the idea of maintaining this patch again and again for this 
> issue, 
> > which can be solved either by depending on a systemwide openssl (but 
> there 
> > goes our "batteries included" philosophy) or including OpenSSL 
> (currently 
> > not possible for licensing reasons, but that should change). 
>
> I agree. 
>
> > I also balk at the idea of shipping a crippled pip. 
>
> It's not crippled if you don't need it to install from HTTPS which not 
> everyone does. 
>

Unless I'm mistaken, pip won't  instamm from Pipy if https isn't enabled. 
Isn't that an important source of Python modules ?

Okay.  I think I see the problem here.  We're talking about multiple 
> issues simultane

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le lundi 23 octobre 2017 14:43:18 UTC+2, Erik Bray a écrit :
>
> On Mon, Oct 23, 2017 at 2:31 PM, Erik Bray  > wrote: 
> > The same should be true for R, 
> > and if this is not the case (and I'm not convinced it isn't) 
>
> This part I take back.  I see now that in R's configure it really does 
> refuse to proceed if it doesn't find the right libcurl with SSL 
> support.  It's not possible to disable since it's now the default 
> download method.  This is silly though, since other download methods 
> still work.


Probably not as silly as it seems : it pushes users towards SSL downloading 
(for good reasons, I think), while leaving the CRAN mirrors managers some 
time to adapt (i. e. getting an SSL certificate from an acknowledged CA).

I think that a second step is the programmed disappearance of the http 
access to CRAN mirrors. But we're not yet there.
 

> It should be possible to disable the requirement at 
> configure time and fallback to a different default.  It's a shame we 
> require a patch for this for now but I can help push for an upstream 
> fix to this if need be, because I think it's fairly silly. 
>

Could you explain why ? I think that the move towards authentication of the 
download sources is a Good Idea (TM), but I may be wrong. In any case, the 
"silliness" of this is nor obvious to my dentist's eyes...

--
Emmanuel Charpentier

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 3:19 PM, Emmanuel Charpentier
 wrote:
>
>
> Le lundi 23 octobre 2017 14:32:03 UTC+2, Erik Bray a écrit :
>>
>> On Mon, Oct 23, 2017 at 12:27 PM, Emmanuel Charpentier
>>  wrote:
>> >
>> >
>> > Le lundi 23 octobre 2017 12:17:06 UTC+2, Erik Bray a écrit :
>> >>
>> >> On Mon, Oct 23, 2017 at 11:57 AM, Emmanuel Charpentier
>> >>  wrote:
>> >> > Dear Erik,
>> >> >
>> >> > Le lundi 23 octobre 2017 11:16:05 UTC+2, Erik Bray a écrit :
>> >> >>
>> >> >> On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier
>> >> >>  wrote:
>> >> >> > Again : R is not only a software package but also an ecosystem.
>> >> >> > The
>> >> >> > 11638
>> >> >> > (as of today) packages available to R users are a large part of R
>> >> >> > usefulness
>> >> >> > to its users. So, "disabling downloads from CRAN" is *NOT* fine
>> >> >> > (to
>> >> >> > them, at
>> >> >> > least...).
>> >> >>
>> >> >> I'm not saying it shouldn't be possible to install R packages at
>> >> >> all,
>> >> >> any less than it should be possible to install Python packages.  My
>> >> >> point here was that with Python, for example, one can manually
>> >> >> download a package tarball or wheel from PyPI using, say, curl for
>> >> >> example (maybe if they running on an air-gapped network this was
>> >> >> done
>> >> >> on a separate machine and sneaker-netted over, etc.).  pip can then
>> >> >> install from the manually downloaded package file.
>> >> >>
>> >> >> I don't know if the same is possible with R but you'd think it
>> >> >> should
>> >> >> be.  However R installs packages the sequence still has to be
>> >> >> something like
>> >> >>
>> >> >> 1) Download package from CRAN
>> >> >> 2) Verify that package downloaded successfully (maybe it does this
>> >> >> maybe it doesn't)
>> >> >> 3) Install the package
>> >> >>
>> >> >> So it should be possible to do steps 1 and 2 manually, and then skip
>> >> >> straight to 3.  Admittedly running R on an air-gapped network is
>> >> >> probably not a situation the developers have in mind but I have very
>> >> >> little doubt that the use case exists.
>> >> >
>> >> >
>> >> > Indeed, it *is* possible to install a manually downloaded package
>> >> > (not
>> >> > as
>> >> > straightforward as  the automatic download-and-install default
>> >> > method).
>> >> > But
>> >> > the problem isn't here :
>> >> >
>> >> > There are a large number of CRAN packages (11660 as of this morning).
>> >> > More
>> >> > and more of these packages have mutual dependencies, which are easily
>> >> > accounted for bu install.packages() but are a pain to deal with
>> >> > "manually".
>> >> >
>> >> > In fact, the problem (roughly) has same magnitude as the maintainance
>> >> > of
>> >> > your operating system : it *is* indeed possible to maintain a
>> >> > Unix/Linux
>> >> > installation using only tarballs conveyed to the system via
>> >> > sneakersnet,
>> >> > but
>> >> > it' certainly a) not fun and b) chronophage to the extreme...
>> >> >
>> >> > As it happened with Linux distributions, these intermutual
>> >> > dependencies,
>> >> > which started scarce and lightweight, are getting more and more
>> >> > important.
>> >> > My prediction (or prognostication, or oracle, if you wish...;-) is
>> >> > that
>> >> > they
>> >> > will reach the level of complexity of operating system distributions
>> >> > in
>> >> > an
>> >> > amount of time short enough for this problem to be of interest to all
>> >> > but
>> >> > the oldest (i. e. closest to retirement or death) of R users.
>> >>
>> >> I understand all that, and the same is true of some Python packages as
>> >> well (which is why sometimes Sage winds up having to add quite a few
>> >> spkgs for Python packages--see for example the dependencies of Flask).
>> >> But that's simply a matter that has to be dealt with, and people do
>> >> (*I* do, even, in some cases).
>> >>
>> >> My point here is not that that that's a nice thing to foist on average
>> >> users (it isn't).  Just that it *should* be possible regardless,
>> >> without patching or anything else.  My concern is just why are we
>> >> maintaining a patch just to be able to build R without SSL...
>> >
>> >
>> > ...which is *exactly* my point !
>> >
>> > Presently, the only reason ever given to this patch (which lifts
>> > upstream
>> > R's requirement on an https-enabled library) is to be able to build Sage
>> > without OpenSSL because it's not, in some eyes, GPL-compatible.
>> >
>> > I balk at the idea of maintaining this patch again and again for this
>> > issue,
>> > which can be solved either by depending on a systemwide openssl (but
>> > there
>> > goes our "batteries included" philosophy) or including OpenSSL
>> > (currently
>> > not possible for licensing reasons, but that should change).
>>
>> I agree.
>>
>> > I also balk at the idea of shipping a crippled pip.
>>
>> It's not crippled if you don't need it to install from HTTPS which not
>> everyone does.
>
>
> Unless I'm mistaken, pip won't  instamm from Pipy if https is

[sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

My vote :

|X| Yes, we should fully support OpenSSL now, and clarify the licensing 
issue.

BTW : the vote closes in about 20 minutes. This is your last chance to take 
back any "too hasty" votes.

--
Emmanuel Charpentier

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 3:28 PM, Emmanuel Charpentier
 wrote:
>> It should be possible to disable the requirement at
>> configure time and fallback to a different default.  It's a shame we
>> require a patch for this for now but I can help push for an upstream
>> fix to this if need be, because I think it's fairly silly.
>
>
> Could you explain why ? I think that the move towards authentication of the
> download sources is a Good Idea (TM), but I may be wrong. In any case, the
> "silliness" of this is nor obvious to my dentist's eyes...

Perhaps this should clarify:  If the CRAN service is switched to using
HTTPS, then it can't be accessed without HTTPS.  If the user tries to
access the site with software that doesn't have HTTPS support then
they are prevented from performing insecure downloads, QED.

In other words, the security here is being provided by the service.
The client is free to decide whether or not they wish to implement
their end in order to be able to access the service.

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

['Julien Puydt' via sage-devel]

Le 23/10/2017 à 15:40, Emmanuel Charpentier a écrit :
> BTW : the vote closes in about 20 minutes. This is your last chance to
> take back any "too hasty" votes.

My vote: no openSSL now - wait until the license issues are solved

Snark on #sagemath

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Le lundi 23 octobre 2017 15:44:09 UTC+2, Erik Bray a écrit :
>
> On Mon, Oct 23, 2017 at 3:28 PM, Emmanuel Charpentier 
> > wrote: 
> >> It should be possible to disable the requirement at 
> >> configure time and fallback to a different default.  It's a shame we 
> >> require a patch for this for now but I can help push for an upstream 
> >> fix to this if need be, because I think it's fairly silly. 
> > 
> > 
> > Could you explain why ? I think that the move towards authentication of 
> the 
> > download sources is a Good Idea (TM), but I may be wrong. In any case, 
> the 
> > "silliness" of this is nor obvious to my dentist's eyes... 
>
> Perhaps this should clarify:  If the CRAN service is switched to using 
> HTTPS, then it can't be accessed without HTTPS.  If the user tries to 
> access the site with software that doesn't have HTTPS support then 
> they are prevented from performing insecure downloads, QED. 
>
> In other words, the security here is being provided by the service. 
> The client is free to decide whether or not they wish to implement 
> their end in order to be able to access the service. 
>

Indeed. But since R is "the software" used to access CRAN, the authors of 
"this software" want to be sre that "saif software" is indeed able to 
access it. Sounds sound to me : not a security problem, but just plain old 
specificatin of an essential requirement.

Where is the silliness ?

--
Emmanuel Charpentier

-- 
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.

[sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Vote is closed.

A tally of the vote should follow more or less quickly (I have about a 
hundredth of message to review...).

A tally of the comments will take longer. Expect it at the start of a new 
thread.

--
Emmanuel Charpentier

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Nathan Dunfield]

On Monday, October 23, 2017 at 7:32:03 AM UTC-5, Erik Bray wrote:
>
> > I also balk at the idea of shipping a crippled pip. 
>
> It's not crippled if you don't need it to install from HTTPS which not 
> everyone does.
>

I agree with Emmanuel that providing "pip" without HTTPS is shipping a 
broken product.  While there are other uses for "pip", by far the most 
common is to install Python packages off PyPI, which requires HTTPS.  

For the same reasons Emmanuel lists for R, installing Python packages via 
manual download and then pip breaks down fast for all but the simplest 
packages.  I once installed "snappy" [1] into a copy of SageMath on macOS 
where Sage's pip lacked OpenSSL support via such manual downloads.  I 
succeed but it was quite painful and in any event I'm a maintainer of said 
package...

Best,

Nathan

[1] https://pypi.python.org/pypi/snappy/

-- 
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.

Re: [sage-devel] Re: sage stuck with GNU parallel

[Sebastiano Vigna]

Il giorno lunedì 23 ottobre 2017 14:29:35 UTC+2, William ha scritto:
>
>
> Use the @parallel decorator from within Sage instead: 
>
> http://doc.sagemath.org/html/en/reference/parallel/index.html 
>
> William 
>
>
>
I know about @parallel, but in this case sage is part of a pipeline of 
transformations, including generated code. @parallel would be a pain to 
use. From what I understand it is not considered a bug that sage cannot be 
forked, but that seriously limits its usability in complex environments.

-- 
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.

[sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

Vote tally

Each vote is linked (via google groups) to the last expression of the vote.

 Yes, we should fully support OpenSSL now, and clarify the licensing issue 
: 11 unambiguous votes :


Erik Bray 

Dima Pasechnik 

William Stein 

John Cremona 

David Roe 

Nathan Dunfield 

Richard_L 

Marteen Derickx 

Luca de Feo 

Eric Gourgoulhon 

Emmanuel Charpentier 


 


 No, we should wait until OpenSSL finishes fixing their license situation 
formally : 3 unambiguous votes.


Jeroen Demeyer 

Ralf Stephan 

Snark  
 
Other participants to discussion, which did not formally vote, or "threw 
their vote away" ((C) Michael Orlitzky) in favor of another option : 10 
people
David Joyner
Michael Orlitzky
Nicolas M Thiéry
Dr David Kirby
Thierry (sage-googlesucks@xxx)
kcrisman
John H Palmieri

The ayes have it ;-). One note that even if all the comments without 
explicit votes were turned into "No" votes, the ayes would still have it.

You have up to Tuesday Oct 24, 2017 14h UTC to point errors or omission in 
this tally by mail to the present thread.

A tally of the comments will (not so soon : it's complicated...) be posted 
on sage-devel. A discussion for a porposal for implementation will also be 
posted (in a separate thread).

--
Emmanuel Charpentier


-- 
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.

[sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Emmanuel Charpentier]

 
>
> Other participants to discussion, which did not formally vote, or "threw 
> their vote away" ((C) Michael Orlitzky) in favor of another option : 10 
> people
>

No : make that 7 people...
 

> David Joyner
> Michael Orlitzky
> Nicolas M Thiéry
> Dr David Kirby
> Thierry (sage-googlesucks@xxx)
> kcrisman
> John H Palmieri
>

Thats seven indeed... Sorry for that lapsus. I was probably thinking of the 
sum of discussant + "No" voters...

--
Emmanuel Charpentier

-- 
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.

Re: [sage-devel] Re: sage stuck with GNU parallel

[William Stein]

On Mon, Oct 23, 2017 at 7:50 AM Sebastiano Vigna 
wrote:

>
>
> I know about @parallel, but in this case sage is part of a pipeline of
> transformations, including generated code. @parallel would be a pain to
> use. From what I understand it is not considered a bug that sage cannot be
> forked, but that seriously limits its usability in complex environments.
>
> Sage is a complicated piece of software.  @parallel is implemented using
fork.  Sage can be forked, but certain steps must be taken, as is done in
the @parallel code.

Good luck,

William
-- 
-- William Stein

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 5:15 PM, Emmanuel Charpentier
 wrote:
>
>>
>> Other participants to discussion, which did not formally vote, or "threw
>> their vote away" ((C) Michael Orlitzky) in favor of another option : 10
>> people
>
>
> No : make that 7 people...
>
>>
>> David Joyner
>> Michael Orlitzky
>> Nicolas M Thiéry
>> Dr David Kirby
>> Thierry (sage-googlesucks@xxx)
>> kcrisman
>> John H Palmieri
>
>
> Thats seven indeed... Sorry for that lapsus. I was probably thinking of the
> sum of discussant + "No" voters...

I should note that up thread I think I changed my vote to "No", but
really there should be a third option specifically along the lines of
"support SSL optionally".

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[John H Palmieri]

By the way, on OS X, an SSL-enabled curl is installed along with Xcode, so 
if we use that in Sage, I wonder if R will work with full functionality. 
(See #24081.) If so, OpenSSL would only be "needed" for Sage's pip.

  John


On Monday, October 23, 2017 at 9:05:16 AM UTC-7, Erik Bray wrote:
>
> On Mon, Oct 23, 2017 at 5:15 PM, Emmanuel Charpentier 
> > wrote: 
> > 
> >> 
> >> Other participants to discussion, which did not formally vote, or 
> "threw 
> >> their vote away" ((C) Michael Orlitzky) in favor of another option : 10 
> >> people 
> > 
> > 
> > No : make that 7 people... 
> > 
> >> 
> >> David Joyner 
> >> Michael Orlitzky 
> >> Nicolas M Thiéry 
> >> Dr David Kirby 
> >> Thierry (sage-googlesucks@xxx) 
> >> kcrisman 
> >> John H Palmieri 
> > 
> > 
> > Thats seven indeed... Sorry for that lapsus. I was probably thinking of 
> the 
> > sum of discussant + "No" voters... 
>
> I should note that up thread I think I changed my vote to "No", but 
> really there should be a third option specifically along the lines of 
> "support SSL optionally". 
>

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Erik Bray]

On Mon, Oct 23, 2017 at 4:16 PM, Nathan Dunfield  wrote:
> On Monday, October 23, 2017 at 7:32:03 AM UTC-5, Erik Bray wrote:
>>
>> > I also balk at the idea of shipping a crippled pip.
>>
>> It's not crippled if you don't need it to install from HTTPS which not
>> everyone does.
>
>
> I agree with Emmanuel that providing "pip" without HTTPS is shipping a
> broken product.  While there are other uses for "pip", by far the most
> common is to install Python packages off PyPI, which requires HTTPS.

It is literally not a broken product.  In fact support for SSL was
deliberately made optional (minus the time it wasn't due to a bug)
because PyPI is not the only use for pip and never was the only use.
Likewise for R's package.install() it supports other sources than CRAN
and as far as I can tell always has.

If you look at my message a little further up I was explicit that in
the common case of "average users", from the Sage perspective, we
definitely want to support this functionality.  From a software design
perspective, however, it doesn't make sense to unconditionally require
SSL when all other features of the software, including package
installation from other sources, works without it.

-- 
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.

Re: [sage-devel] How do I overwrite comparison for modules?

[David Roe]

On Mon, Oct 23, 2017 at 8:24 AM, Simon Brandhorst 
wrote:

> I am aware of this. It is just unexpected that other.__eq__(self) calls
> self._eq(other)
>
> As a user of that rich cmp method I would have expected it to call
> other._eq(self).
>
> Raising a not implemented error seems nice. :)
>

Note that it should return NotImplemented (a built in constant to be
returned by rich comparisons), not raise a NotImplementedError.
David

-- 
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.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Dima Pasechnik]

There are various https-only software repos, not only Python or R-relayed. IIRC 
kernel.org is one of them. Without SSL headers one cannot build tools to access 
such repos; e.g. there are no such headers in Xcode. 
One may keep repeating "optional" etc mantras, but it does not make 
non-functioning tools functioning, SSL is one of feature creeping and becoming 
de facto standard, just as one cannot really build a functioning single-thread 
CPython, even though it is officially not acknowledged...

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.

[sage-devel] broken docbuild in SageMath 8.1.beta9

[uaw]

In the current develop branch, running "make doc-clean" and then "sage 
--docbuild reference html" spews a long error message on building 
[manifolds], of which the most illuminating section is:

OSError: [manifolds] 
/projects/cc1903e2-29de-404b-93c1-8068b0aca31d/Src/sage-ursula/src/doc/en/reference/manifolds/index.rst:4:
 
WARNING: undefined label: tensors-on-free-modules (if the link has no 
caption the label must precede a section header)

Can anyone track down the origin of this problem?

--Ursula Whitcher.

-- 
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.

Re: [sage-devel] How do I overwrite comparison for modules?

[Travis Scrimshaw]

> I am aware of this. It is just unexpected that other.__eq__(self) calls
>> self._eq(other)
>>
>> As a user of that rich cmp method I would have expected it to call
>> other._eq(self).
>>
>> Raising a not implemented error seems nice. :)
>>
>
> Note that it should return NotImplemented (a built in constant to be 
> returned by rich comparisons), not raise a NotImplementedError.
>
>
There is also precedent in Python for raising a TypeError with < and > too. 
However, I think that causes more headaches than it solves.

Best,
Travis

-- 
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.

[sage-devel] Re: How do I overwrite comparison for modules?

[Travis Scrimshaw]

> > (how often is the first 
> > thing you do is verify the object has a compatible type?). 
>
> Almost never, at least for elements! 
>
> For elements (not for parents, though), one is supposed to 
> implement single underscore arithmetic *and* comparison methods, 
> which will only be called after coercion took place and so the 
> two arguments of _richcmp_ are guaranteed to belong to the 
> same parent. 
>
> So, verifying that the types are compatible only applies to 
> the rare case that elements of a single parent are implemented 
> by different types, simultaneously. Just never ever override 
> double underscore __richtcmp__ for elements. 
>
> Yes, that is a very good point to make and reinforce.

Best,
Travis

 

-- 
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.

[sage-devel] Workaround for ipython build hang

[Jori Mäntysalo]

There is #24088 already in positive_review. But as a sidenote: I was able 
to compile Sage with many, many rounds. So here is a workaround to those 
seeing an error from ipython in compilation:


until make; do echo Duh. Another try.; done

--
Jori Mäntysalo

Re: [sage-devel] How do I overwrite comparison for modules?

[Simon Brandhorst]

Ahhh

On Monday, October 23, 2017 at 6:09:02 PM UTC+2, David Roe wrote:
>
>
>
> On Mon, Oct 23, 2017 at 8:24 AM, Simon Brandhorst  > wrote:
>
>> I am aware of this. It is just unexpected that other.__eq__(self) calls
>> self._eq(other)
>>
>> As a user of that rich cmp method I would have expected it to call
>> other._eq(self).
>>
>> Raising a not implemented error seems nice. :)
>>
>
> Note that it should return NotImplemented (a built in constant to be 
> returned by rich comparisons), not raise a NotImplementedError.
> David
>

-- 
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.

[sage-devel] Re: broken docbuild in SageMath 8.1.beta9

[Ralf Stephan]

Confirmed. 'make doc' works however. I have seen such discrepancy before...

-- 
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.

[sage-devel] Re: broken docbuild in SageMath 8.1.beta9

[Ralf Stephan]

Please 
see 
https://groups.google.com/forum/#!searchin/sage-devel/docbuild$20reference|sort:date/sage-devel/R9k7wmTv7MM/gQKPDOS5CQAJ

-- 
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.