[sage-devel] Re: how we develop sage

[William Stein]

On Friday, April 8, 2016, Dima Pasechnik  wrote:

>
>
> On Friday, April 8, 2016 at 7:40:02 PM UTC+1, William wrote:
>>
>>
>>
>> On Friday, April 8, 2016, Volker Braun  wrote:
>>
>>> On Friday, April 8, 2016 at 6:43:46 PM UTC+2, William wrote:

 this "one other problem of Sage is that it does not define
 clearly what's the public API and what's internal.
>>>
>>>
>>> IMHO thats just not true; What you get on the commandline (i.e. from
>>> sage.all import *) is public and the rest is not. If thats not enough (and
>>> really nobody ever asked) we could mark extra imports as public, e.g. by
>>> adding special sage.foo.public packages.
>>>
>>
>>
>> Why does nobody ever ask?
>>
>>
>>>
>>> If there were large body of pip-installable packages, which are user
 code, this would help *define* what the public API of Sage really is,
 and also give us a much larger body of code to test against before
 making new releases.

>>>
> testing against sufficiently large body of code which is not maintained by
> a project is a perfect way to make
> sure that no new releases are made by the project, ever.
>
>
>
>
>
>

False.  You are simply arguing for ignorance. How we chose to use the
results of such testing is up to us to decide.



>
>
>>
>>> What API design school is that? You dump code on users and whoever
>>> manages to build the most convoluted contraption out of that will determine
>>> the future direction of the project ;-) Where is the leadership there? Who
>>> is going to handle the testing for each ticket, are you going to do that
>>> yourself?
>>>
>>>
>>>
>> I don't care about design schools.   I would much rather be aware of how
>> sage-dependent code is actually being used in the wild than to sit in
>> school blissfully ignorant of how sage is really being used.
>>
>
> I thought that with SMC you have a near-perfect opportunity to see what
> Sage users use in the wild...
>

SMC does inform my frustration with the current limitations  on Sage
development.



>
> And perhaps, perhaps, the 1st thing would be to get a single-user SMC
> frontend available as a pip-installable package, so that sagenb can retire,
> at last?
>

SMC is not a Python program.


William



>
> Dima
>
>
>>
>>
>>
>>>


 --
>>> You received this message because you are subscribed to the Google
>>> Groups "sage-devel" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to sage-devel+unsubscr...@googlegroups.com.
>>> To post to this group, send email to sage-devel@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/sage-devel.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Sent from my massive iPhone 6 plus.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com
> 
> .
> To post to this group, send email to sage-devel@googlegroups.com
> .
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Sent from my massive iPhone 6 plus.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] LaurentPolynomialRing and PolynomialRing behave inconsistently -- Request For Comments

[VulK]

Dear All,
for some project I have been working on for some time I found myself interested
in comparing elements of two different LaurentPolynomialRing. Unfortunately,
at the moment this is somewhat broken. The current behaviour is this:


sage: L1 = LaurentPolynomialRing(ZZ, 'x0,x1,x2,y0,y1,y2')
sage: L2 = LaurentPolynomialRing(ZZ, 'y0,y1,y2')
sage: L2.gen(0) in L1
False
sage: L1(L2.gen(0))
---
TypeError Traceback (most recent call last)
...
TypeError: tuple key must have same length as ngens


On the other hand PolynomialRing behave differently:

sage: P1 = PolynomialRing(ZZ, 'x0,x1,x2,y0,y1,y2')
sage: P2 = PolynomialRing(ZZ, 'y0,y1,y2')
sage: P2.gen(0) in P1
True
sage: P1(P2.gen(0))
y0


I made a ticket to address this issue #19538 and in the discussion there many
more inconsistencies popped out. This e-mail is to ask the community which 
should
be the desired behavior of both PolynomialRing and LaurentPolynomialRing and how
to get them to agree.

I will use this function to prettyprint

sage: def printmap(target, source):
print(str(source) + " --> " + str(map(target,source)))


* PolynomialRing

  sage: P1 = PolynomialRing(ZZ, 'x,y')
  sage: P2 = PolynomialRing(ZZ, 'x,t')
  sage: P3 = PolynomialRing(ZZ, 't,x')
  sage: P4 = PolynomialRing(ZZ, 'x,t,y')
  # these behave somewhat predictably
  sage: printmap(P4, P1.gens())
  (x, y) --> [x, y]
  sage: printmap(P4, P3.gens())
  (t, x) --> [t, x]
  y
  sage: P1(P4('t'))
  Traceback (most recent call last):
  ...
  TypeError: Could not find a mapping of the passed element to this ring.
   these instead are not really behaving in the same way
  sage: printmap(P1, P3.gens()) # this maps the i-th generator to the i-th 
generator irregardless of their names (t to x and x to y)
  (t, x) --> [x, y]
  sage: printmap(P3, P2.gens()) # this instead maps x to x and t to t 
  (x, t) --> [x, t]

* LaurentPolynomialRing

  sage: L1 = LaurentPolynomialRing(ZZ, 'x,y')
  sage: L2 = LaurentPolynomialRing(ZZ, 'x,t')
  sage: L3 = LaurentPolynomialRing(ZZ, 't,x')
  sage: L4 = LaurentPolynomialRing(ZZ, 'x,t,y')
  sage: printmap(L4, L1.gens())
  ---
  TypeError Traceback (most recent call last)
  ...
  TypeError: tuple key must have same length as ngens
  sage: printmap(L4, L3.gens())
  ---
  TypeError Traceback (most recent call last)
  ...
  TypeError: tuple key must have same length as ngens
  sage: L1(L4('t'))
  ---
  TypeError Traceback (most recent call last)
  ...
  TypeError: tuple key must have same length as ngens
  sage: sage: printmap(L1, L3.gens())
  (t, x) --> [x, y]
  sage: sage: printmap(L3, L2.gens())
  (x, t) --> [t, x]

As you can see for LaurentPolynomialRing the maps currently work only if source
and target have the same number of variables. Moreover, whenever they do, the
behaviour is different from the one of PolynomialRing: in any case the map sends
the i-th generator to the i-th generator (arguably this could e seen as more 
consistent).

After the patch I wrote the situation is the following:

* patched LaurentPolynomialRing

  sage: R1 = LaurentPolynomialRing(ZZ, 'x,y')
  sage: R2 = LaurentPolynomialRing(ZZ, 'x,t')
  sage: R3 = LaurentPolynomialRing(ZZ, 't,x')
  sage: R4 = LaurentPolynomialRing(ZZ, 'x,t,y')
  sage: printmap(R4, R1.gens())
  (x, y) --> [x, y]
  sage: printmap(R4, R3.gens())
  (t, x) --> [t, x]
  sage: R1(R4('t'))
  ---
  ValueErrorTraceback (most recent call last)
  ...
  ValueError: tuple.index(x): x not in tuple
  sage: sage: printmap(R1, R3.gens())
  ---
  ValueErrorTraceback (most recent call last)
  ValueError: tuple.index(x): x not in tuple
  sage: sage: printmap(R3, R2.gens())
  (x, t) --> [x, t]

The patch maps a generator to the generator having the same name, if any (which
explain the failures). The error code should probably be improved.  Note that 

sage: R1(R3.gen(1))
x
 
works as expected. This patch, though, while making LaurentPolynomialRing behave
like PolynomialRing in most cases, makes the behaviour inconsistent in the
previous to last case.

A note on speed: I expect the patched code to be slower than the original one. I
did not make any test to gauge how much.


In view of the above examples, which do you think should be the behaviour of 
both
LaurentpolynomialRing and PolynomialRing? This is quite a central piece of code
in sage and it would be better if the decision about how to proceed is not 

[sage-devel] Re: Automated Downloading of Most Recent Version of Sage

[Chris Swierczewski]

> The easiest way is probably to poll one of
>
> https://raw.githubusercontent.com/sagemath/sage/master/src/sage/version.py
>
> https://raw.githubusercontent.com/sagemath/sage/master/src/bin/sage-version.sh
>
>
That's a cute trick. I'll try that out. Thanks!

-- 
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 we develop sage

[Volker Braun]

On Friday, April 8, 2016 at 8:40:02 PM UTC+2, William wrote:
>
> Why does nobody ever ask?
>

I'd like to think thats because there is simply no need for obscure imports 
when using Sage; We have public constructors for basic mathematical 
objects, and computations are then done using methods of said objects. 
Unless you muck in the Sage internals (=you want to patch Sage) you 
*shouldn't* have to import stuff thats not already global on the 
commandline, how else are users supposed to use it?

What API design school is that? You dump code on users and whoever manages 
>> to build the most convoluted contraption out of that will determine the 
>> future direction of the project
>>
> I don't care about design schools
>

I disagree, IMHO designing interfaces carefully is much more important than 
(and should come before) banging on the keyboard.

 

-- 
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 we develop sage

[Dima Pasechnik]

On Friday, April 8, 2016 at 7:40:02 PM UTC+1, William wrote:
>
>
>
> On Friday, April 8, 2016, Volker Braun  
> wrote:
>
>> On Friday, April 8, 2016 at 6:43:46 PM UTC+2, William wrote:
>>>
>>> this "one other problem of Sage is that it does not define 
>>> clearly what's the public API and what's internal.
>>
>>
>> IMHO thats just not true; What you get on the commandline (i.e. from 
>> sage.all import *) is public and the rest is not. If thats not enough (and 
>> really nobody ever asked) we could mark extra imports as public, e.g. by 
>> adding special sage.foo.public packages.
>>
>
>
> Why does nobody ever ask?
>  
>
>>
>> If there were large body of pip-installable packages, which are user 
>>> code, this would help *define* what the public API of Sage really is, 
>>> and also give us a much larger body of code to test against before 
>>> making new releases. 
>>>
>>
testing against sufficiently large body of code which is not maintained by 
a project is a perfect way to make
sure that no new releases are made by the project, ever.
 

>
>> What API design school is that? You dump code on users and whoever 
>> manages to build the most convoluted contraption out of that will determine 
>> the future direction of the project ;-) Where is the leadership there? Who 
>> is going to handle the testing for each ticket, are you going to do that 
>> yourself? 
>>
>>
>>
> I don't care about design schools.   I would much rather be aware of how 
> sage-dependent code is actually being used in the wild than to sit in 
> school blissfully ignorant of how sage is really being used. 
>

I thought that with SMC you have a near-perfect opportunity to see what 
Sage users use in the wild...

And perhaps, perhaps, the 1st thing would be to get a single-user SMC 
frontend available as a pip-installable package, so that sagenb can retire, 
at last?

Dima


>
>  
>
>>
>>>
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to sage-devel+unsubscr...@googlegroups.com.
>> To post to this group, send email to sage-devel@googlegroups.com.
>> Visit this group at https://groups.google.com/group/sage-devel.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Sent from my massive iPhone 6 plus.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Automated Downloading of Most Recent Version of Sage

[Volker Braun]

The easiest way is probably to poll one of

https://raw.githubusercontent.com/sagemath/sage/master/src/sage/version.py
https://raw.githubusercontent.com/sagemath/sage/master/src/bin/sage-version.sh



On Friday, April 8, 2016 at 11:27:33 PM UTC+2, Chris Swierczewski wrote:
>
> I have written an sort of experimental package for Sage and I am currently 
> using TravisCI to run my tests. Since TravisCI doesn't have an installation 
> of Sage I decided to make downloading it a step in the travis.yml config, 
> in particular, during the before_install step:
>
> wget 
> http://mirrors.mit.edu/sage/linux/64bit/sage-7.0-Ubuntu_12.04-x86_64.tar.bz2
>
> However, with the release of sage-7.1 this link appears to be broken. At 
> least, TravisCI reported failure on this step of the automated testing.
>
> My question is: is there are better way to obtain a particular version or, 
> at least, the most recent version of Sage or do I have to update my 
> travis.yml script every time a new version of Sage comes out? Thanks in 
> advance for any help on the matter.
>

-- 
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: catch a "sagemath" DeprecationWarning

[Chris Swierczewski]

> I was expecting the following to catch the DeprecationWarning
>
> import warnings
>
> warnings.filterwarnings('error',category=DeprecationWarning)
> try:
> print (exp(x)*exp(3*x)).simplify_exp()   #example with exp function
> except DeprecationWarning:
> print 'MegBook.py say: exercise needs review!'
>
> but it does not. I still got
>
>
In Python the warning construct behaves a little differently. I think if 
you use the "catch_warnings" context manager you'll be able at least test 
if a warning occurred. See 
https://docs.python.org/2/library/warnings.html#testing-warnings for 
information. 

import warnings
with warnings.catch_warnings(record=True) as w:
#
# do some things here that may cause a warning
#
if len(w) > 0:
print 'A warning was thrown'

-- 
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] Automated Downloading of Most Recent Version of Sage

[Chris Swierczewski]

I have written an sort of experimental package for Sage and I am currently 
using TravisCI to run my tests. Since TravisCI doesn't have an installation 
of Sage I decided to make downloading it a step in the travis.yml config, 
in particular, during the before_install step:

wget 
http://mirrors.mit.edu/sage/linux/64bit/sage-7.0-Ubuntu_12.04-x86_64.tar.bz2

However, with the release of sage-7.1 this link appears to be broken. At 
least, TravisCI reported failure on this step of the automated testing.

My question is: is there are better way to obtain a particular version or, 
at least, the most recent version of Sage or do I have to update my 
travis.yml script every time a new version of Sage comes out? Thanks in 
advance for any help on the matter.

-- 
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] catch a "sagemath" DeprecationWarning

[Vincent Delecroix]

Ha ha. In misc/superseded.py the function warning just reset all filters 
each time it is called


def warning(...):
_check_trac_number(trac_number)
message += '\n'
message += 'See http://trac.sagemath.org/'+ str(trac_number) + ' 
for details.'

resetwarnings()
# Stack level 3 to get the line number of the code which called
# the deprecated function which called this function.
warn(message, warning_class, stacklevel)

As it is used everywhere the filterwarnings just not works. I just 
removed the "resetwarnings()" line and I was able to get an error with 
your example.


Was it done on purpose?!

Vincent


On 08/04/16 13:07, João Pedro Cruz wrote:

Hello,

I was expecting the following to catch the DeprecationWarning

import warnings

warnings.filterwarnings('error',category=DeprecationWarning)
try:
 print (exp(x)*exp(3*x)).simplify_exp()   #example with exp function
except DeprecationWarning:
 print 'MegBook.py say: exercise needs review!'

but it does not. I still got

DeprecationWarning: simplify_exp is deprecated. Please use
canonicalize_radical instead.
See http://trac.sagemath.org/11912 for details.
   print (exp(x)*exp(_sage_const_3 *x)).simplify_exp()   #example with exp
function


*How can we catch this "type" of* DeprecationWarning  ?

I've checked
https://github.com/sagemath/sage/blob/master/src/sage/misc/superseded.py
but reached no conclusion.

I appreciate help,
Thank you.

Pedro


The following works easy:
try:
 raise DeprecationWarning
except DeprecationWarning :
 print 'Got 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.

[sage-devel] Re: how we develop sage

[William Stein]

On Friday, April 8, 2016, Volker Braun  wrote:

> On Friday, April 8, 2016 at 6:43:46 PM UTC+2, William wrote:
>>
>> this "one other problem of Sage is that it does not define
>> clearly what's the public API and what's internal.
>
>
> IMHO thats just not true; What you get on the commandline (i.e. from
> sage.all import *) is public and the rest is not. If thats not enough (and
> really nobody ever asked) we could mark extra imports as public, e.g. by
> adding special sage.foo.public packages.
>


Why does nobody ever ask?


>
> If there were large body of pip-installable packages, which are user
>> code, this would help *define* what the public API of Sage really is,
>> and also give us a much larger body of code to test against before
>> making new releases.
>>
>
> What API design school is that? You dump code on users and whoever manages
> to build the most convoluted contraption out of that will determine the
> future direction of the project ;-) Where is the leadership there? Who is
> going to handle the testing for each ticket, are you going to do that
> yourself?
>
>
>
I don't care about design schools.   I would much rather be aware of how
sage-dependent code is actually being used in the wild than to sit in
school blissfully ignorant of how sage is really being used.




>
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com
> 
> .
> To post to this group, send email to sage-devel@googlegroups.com
> .
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Sent from my massive iPhone 6 plus.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: how we develop sage

[Volker Braun]

On Friday, April 8, 2016 at 6:43:46 PM UTC+2, William wrote:
>
> this "one other problem of Sage is that it does not define 
> clearly what's the public API and what's internal.


IMHO thats just not true; What you get on the commandline (i.e. from 
sage.all import *) is public and the rest is not. If thats not enough (and 
really nobody ever asked) we could mark extra imports as public, e.g. by 
adding special sage.foo.public packages.

If there were large body of pip-installable packages, which are user 
> code, this would help *define* what the public API of Sage really is, 
> and also give us a much larger body of code to test against before 
> making new releases. 
>

What API design school is that? You dump code on users and whoever manages 
to build the most convoluted contraption out of that will determine the 
future direction of the project ;-) Where is the leadership there? Who is 
going to handle the testing for each ticket, are you going to do that 
yourself? 

-- 
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: how we develop sage

[Volker Braun]

On Friday, April 8, 2016 at 6:50:19 PM UTC+2, William wrote:
>
> > But then there is nothing to do on the Sage side, this already works and 
> is 
> > totally standard. 

Just because 
> it is technically possible to do something and documented how to do so 
> online, doesn't mean there is nothing to do on the sage side. 
>

What I meant was: there is nothing that we need to implement to make it 
work. As I also mentioned, it would surely be good to have examples and 
documentation.
 

> > Much of the memory usage of the current docbuild is the huge intersphinx 
> > data, and no amount of modularization would make that smaller. 
> I disagree.  If the elliptic curves docs aren't in Sage at all (say), 
> then it certainly 
> isn't going to make that stuff larger. 
>

But not smaller either, unless you get rid of the intersphinx data. The 
reference manual is already broken up into smaller chunks that are 
processed independently. Breaking it up more is never going to give us a 
significant improvement. We can only make sphinx more efficient or build 
shittier docs. And there you are IMHO just throwing out the baby with the 
bathwater. Remove (or making inaccessible) large chunks of our 
documentation and/or disabling hyperlinks surely saves a lot of time and 
ram when building the documentation. But why? If you don't care about the 
documentation then just compile Sage without it in the first place ("make 
build"). 


-- 
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: how we develop sage

[Jeroen Demeyer]

On 2016-04-08 18:43, William Stein wrote:

the first thing I noticed in that from sage-6.10 to sage-7.x

import sage.rings.arith

completely BROKE.


That's totally exaggerated.

It didn't completely BREAK, it still works with a nice deprecation warning:

Importing is_prime from here is deprecated. If you need to use it, 
please import it directly from sage.arith.all

See http://trac.sagemath.org/19879 for details.

Saying that stuff BREAKS when people take the effort to make proper 
deprecation is not encouraging those people to care about deprecations.


(disclaimer: I made that change)

--
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: how we develop sage

[William Stein]

On Fri, Apr 8, 2016 at 1:00 AM, Volker Braun  wrote:
> On Friday, April 8, 2016 at 2:36:23 AM UTC+2, William wrote:
>>>
>>> Whats wrong with the obvious solution: make it a Python package
>>> (basically add setup.py) and then "sage -pip install
>>> https://github.com/vbraun/awesomepackage.git;. Clearly we could have more
>>> documentation for how to write the setup.py or some package directory
>>> service. But really it is already a one-liner.
>>
>>
>>  That is exactly what I'm proposing
>
>
> But then there is nothing to do on the Sage side, this already works and is
> totally standard.  Documentation for how to package your own Python code can
> easily be found online.

(Volker, I really hate to disagree with you, since I respect you
*very* highly.) However, this is where you are wrong.   Just because
it is technically possible to do something and documented how to do so
online, doesn't mean there is nothing to do on the sage side.
Software, Sage, etc. is all about people, what they endorse, what
examples they set, etc.  It's a leadership thing.  The very thing that
makes you say "there is nothing to do" is what tells me "there is a
lot to do".


>
>
>>>
>>> Yes but cython and cysignals don't do anything for math directly, they
>>> are pure dependencies. By contrast, lets say we break out all elliptic curve
>>> stuff into a separate package. Just like with cysignals, this will remove
>>> all elliptic curve documentation from the Sage reference manual. Still a
>>> win-win?
>>
>> 1. Not necessarily true.
>
>
> It is if you want to have a uniform document with cross references working.

I continue to disagree.

> Much of the memory usage of the current docbuild is the huge intersphinx
> data, and no amount of modularization would make that smaller.

I disagree.  If the elliptic curves docs aren't in Sage at all (say),
then it certainly
isn't going to make that stuff larger.

> That is not
> to say that docbuilding can't be improved, but certainly not by spreading
> out the documentation sources.
>
>>
>> 2. Is it so bad that the Cython docs aren't in the sage reference manual?
>
>
> As I said before,  cython and cysignals don't do anything for math directly
> so they are a special case. In fact, they shouldn't be in the main Sage docs
> even if they were part of Sage.

And for 99.99% of sage users who don't know an elliptic curve from an
"elliptical curve" there is no gain by having the elliptic curves in
the same daunting reference manual as plotting functions.

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

[sage-devel] Re: how we develop sage

[Luca De Feo]

> I merely said that this appears to work. I never said that everything 
should go there.

Sorry for misunderstanding you.

> On the other hand, you mention a core Magma library that helps it beat 
Sage on benchmarks, I imagine such a library would be a nice fit into core 
Sage.
 
It would be lovely, but unfortunately the licence forbids us to distribute 
it :( But we're drifting away from the subject.

-- 
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: how we develop sage

[William Stein]

On Fri, Apr 8, 2016 at 9:33 AM, Luca De Feo  wrote:
>> How often do you feel that changes in Sage breaks your code?
>
> Looking at my log (this project
> https://github.com/defeo/ss-isogeny-software)
>
> - Sage 6.2: module renamed in Pari/GP interface (without deprecation, as far
> as I recall)
> - Sage 6.4: frankly, I don't know, but possibly a change in the finite
> fields implementation
> - Sage 6.7: changes in cython, not really Sage's fault, I guess
> - Sage 6.7: changes in the finite fields implementation (with proper
> deprecation, this time)
> - Sage 6.10: changes in richcmp (did not get deprecation warnings, but the
> change concerns an internal function)
> - Sage 7.1: affected by #19941 (properly deprecated, note that 7.1 is stable
> right now, but not yet in SMC)
>
> It may be argued that I'm taking risks because I sometimes fiddle with "the
> internals" of Sage, but one other problem of Sage is that it does not define
> clearly what's the public API and what's internal.

+1 -- this "one other problem of Sage is that it does not define
clearly what's the public API and what's internal." is a HUGE problem
-- and we're not aware of it because "user code" is typically private.

If there were a large body of pip-installable packages, which are user
code, this would help *define* what the public API of Sage really is,
and also give us a much larger body of code to test against before
making new releases.

As an example, when working on

  https://github.com/williamstein/sage_modabvar

the first thing I noticed in that from sage-6.10 to sage-7.x

   import sage.rings.arith

completely BROKE.  It became "import sage.arith".

This is (who knows?) a change in the public api of the core sage
library.  Maybe it's a gratituous one, and in this case one I'm
puzzled by why this change was made.  (I wrote sage.rings.arith in the
first place, and it was meant to be some misc arith needed to
implement rings.  Why move it to its own top level module like that?)

By writing Python packages that depend on "the core sage library" we
will be forced to define what the core library is and stabilize it.
If you guys want Sage to survive/thrive, this **MUST HAPPEN**.   The
core sage library should -- like with Python -- be the place where
code, which has been tested/used by people and got stable, goes to
stay stable (at least API-wise).  Like the standard Python library.

William

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

[sage-devel] Re: how we develop sage

[Luca De Feo]

> How often do you feel that changes in Sage breaks your code? 

Looking at my log (this project 
https://github.com/defeo/ss-isogeny-software)

- Sage 6.2: module renamed in Pari/GP interface (without deprecation, as 
far as I recall)
- Sage 6.4: frankly, I don't know, but possibly a change in the finite 
fields implementation
- Sage 6.7: changes in cython, not really Sage's fault, I guess
- Sage 6.7: changes in the finite fields implementation (with proper 
deprecation, this time)
- Sage 6.10: changes in richcmp (did not get deprecation warnings, but the 
change concerns an internal function)
- Sage 7.1: affected by #19941 (properly deprecated, note that 7.1 is 
stable right now, but not yet in SMC)

It may be argued that I'm taking risks because I sometimes fiddle with "the 
internals" of Sage, but one other problem of Sage is that it does not 
define clearly what's the public API and what's internal.

Luca

-- 
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] catch a "sagemath" DeprecationWarning

[João Pedro Cruz]

Hello,

I was expecting the following to catch the DeprecationWarning

import warnings

warnings.filterwarnings('error',category=DeprecationWarning)
try:
print (exp(x)*exp(3*x)).simplify_exp()   #example with exp function
except DeprecationWarning:
print 'MegBook.py say: exercise needs review!'

but it does not. I still got

DeprecationWarning: simplify_exp is deprecated. Please use 
canonicalize_radical instead.
See http://trac.sagemath.org/11912 for details.
  print (exp(x)*exp(_sage_const_3 *x)).simplify_exp()   #example with exp 
function


*How can we catch this "type" of* DeprecationWarning  ?

I've checked 
   https://github.com/sagemath/sage/blob/master/src/sage/misc/superseded.py
but reached no conclusion.

I appreciate help,
Thank you.

Pedro


The following works easy:
try:
raise DeprecationWarning
except DeprecationWarning :
print 'Got 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.

[sage-devel] Re: how we develop sage

[Dima Pasechnik]

On Friday, April 8, 2016 at 1:45:00 PM UTC+1, Luca De Feo wrote:
>
> > if research developers 1) don't care enough about their own code to 
> polish it enough for going through our review process
>
> I don't agree with Dima that putting their code into Sage is what 
> researchers should do, no matter what.
>
 
I merely said that this appears to work. I never said that everything 
should go there.
On the other hand, you mention a core Magma library that helps it beat Sage 
on benchmarks, I imagine such a library would be a nice fit into core Sage.
 

-- 
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: failed install of pyopenssl

[Dima Pasechnik]

perhaps, try
$ sudo yum install libffi-devel

then ./sage -pip install pyopenssl
should work, IMHO

On Friday, April 8, 2016 at 12:55:07 PM UTC+1, Mike Zabrocki wrote:
>
>
>
> I've tried installing pyopenssl to a linux server running CENTOS on Sage 
> 7.2.beta2 (and beta3).
> I used one of two commands 
> ./sage -i pyopenssl
> ./sage -pip install pyopenssl
>
> Both are terminating because of a missing header file: ffi.h
> Is there something that I should have installed that is missing?
>
> -Mike
>
>
> [sageuser@algebra sage]$ ./sage -pip install pyopenssl
>
> Collecting pyopenssl
>
>   Using cached pyOpenSSL-16.0.0-py2.py3-none-any.whl
>
> Collecting cryptography>=1.3 (from pyopenssl)
>
>   Using cached cryptography-1.3.1.tar.gz
>
> Requirement already satisfied (use --upgrade to upgrade): six>=1.5.2 in 
> ./local/lib/python2.7/site-packages/six-1.10.0-py2.7.egg (from pyopenssl)
>
> Requirement already satisfied (use --upgrade to upgrade): idna>=2.0 in 
> ./local/lib/python2.7/site-packages (from cryptography>=1.3->pyopenssl)
>
> Requirement already satisfied (use --upgrade to upgrade): pyasn1>=0.1.8 in 
> ./local/lib/python2.7/site-packages (from cryptography>=1.3->pyopenssl)
>
> Requirement already satisfied (use --upgrade to upgrade): setuptools>=11.3 
> in ./local/lib/python2.7/site-packages/setuptools-20.3.1-py2.7.egg (from 
> cryptography>=1.3->pyopenssl)
>
> Requirement already satisfied (use --upgrade to upgrade): enum34 in 
> ./local/lib/python2.7/site-packages (from cryptography>=1.3->pyopenssl)
>
> Requirement already satisfied (use --upgrade to upgrade): ipaddress in 
> ./local/lib/python2.7/site-packages (from cryptography>=1.3->pyopenssl)
>
> Collecting cffi>=1.4.1 (from cryptography>=1.3->pyopenssl)
>
>   Using cached cffi-1.5.2.tar.gz
>
> Requirement already satisfied (use --upgrade to upgrade): pycparser in 
> ./local/lib/python2.7/site-packages (from 
> cffi>=1.4.1->cryptography>=1.3->pyopenssl)
>
> Installing collected packages: cffi, cryptography, pyopenssl
>
>   Running setup.py install for cffi ... error
>
> Complete output from command 
> /usr/local/sage-7.2.beta3/local/bin/python -u -c "import setuptools, 
> tokenize;__file__='/tmp/pip-build-qYgPpy/cffi/setup.py';exec(compile(getattr(tokenize,
>  
> 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" 
> install --record /tmp/pip-kgVvmG-record/install-record.txt 
> --single-version-externally-managed --compile:
>
> Package libffi was not found in the pkg-config search path.
>
> Perhaps you should add the directory containing `libffi.pc'
>
> to the PKG_CONFIG_PATH environment variable
>
> No package 'libffi' found
>
> Package libffi was not found in the pkg-config search path.
>
> Perhaps you should add the directory containing `libffi.pc'
>
> to the PKG_CONFIG_PATH environment variable
>
> No package 'libffi' found
>
> Package libffi was not found in the pkg-config search path.
>
> Perhaps you should add the directory containing `libffi.pc'
>
> to the PKG_CONFIG_PATH environment variable
>
> No package 'libffi' found
>
> Package libffi was not found in the pkg-config search path.
>
> Perhaps you should add the directory containing `libffi.pc'
>
> to the PKG_CONFIG_PATH environment variable
>
> No package 'libffi' found
>
> Package libffi was not found in the pkg-config search path.
>
> Perhaps you should add the directory containing `libffi.pc'
>
> to the PKG_CONFIG_PATH environment variable
>
> No package 'libffi' found
>
> running install
>
> running build
>
> running build_py
>
> creating build
>
> creating build/lib.linux-x86_64-2.7
>
> creating build/lib.linux-x86_64-2.7/cffi
>
> copying cffi/setuptools_ext.py -> build/lib.linux-x86_64-2.7/cffi
>
> copying cffi/commontypes.py -> build/lib.linux-x86_64-2.7/cffi
>
> copying cffi/cffi_opcode.py -> build/lib.linux-x86_64-2.7/cffi
>
> copying cffi/__init__.py -> build/lib.linux-x86_64-2.7/cffi
>
> copying cffi/lock.py -> build/lib.linux-x86_64-2.7/cffi
>
> copying cffi/cparser.py -> build/lib.linux-x86_64-2.7/cffi
>
> copying cffi/verifier.py -> build/lib.linux-x86_64-2.7/cffi
>
> copying cffi/api.py -> build/lib.linux-x86_64-2.7/cffi
>
> copying cffi/backend_ctypes.py -> build/lib.linux-x86_64-2.7/cffi
>
> copying cffi/recompiler.py -> build/lib.linux-x86_64-2.7/cffi
>
> copying cffi/ffiplatform.py -> build/lib.linux-x86_64-2.7/cffi
>
> copying cffi/model.py -> build/lib.linux-x86_64-2.7/cffi
>
> copying cffi/vengine_gen.py -> build/lib.linux-x86_64-2.7/cffi
>
> copying cffi/gc_weakref.py -> build/lib.linux-x86_64-2.7/cffi
>
> copying cffi/vengine_cpy.py -> build/lib.linux-x86_64-2.7/cffi
>
> copying cffi/_cffi_include.h -> build/lib.linux-x86_64-2.7/cffi
>
> copying cffi/parse_c_type.h -> build/lib.linux-x86_64-2.7/cffi
>
> copying cffi/_embedding.h -> 

Re: [sage-devel] failed install of pyopenssl

[Mike Zabrocki]

Thanks,

The file "ffi.h" was the problem after all.
I had to 
sudo yum install libffi-devel

just having libffi alone wasn't cutting it.  I couldn't track down the 
"ffi.h" file from Volker's command and so I went back to see what I was not 
reading correctly from the yum whatprovides command.

I've installed pyopenssl on this machine before so I am surprised that it 
was fighting me on this install.

-Mike

-- 
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 we develop sage

[Simon King]

Hi Johan,

On 2016-04-08, Johan S  R  Nielsen  wrote:
> How often do you feel that changes in Sage breaks your code?

As I stated before, several times in one year (that year being 2013 or 2014,
I am not sure), after it was more or less stable since 2009.

Cheers,
Simon

-- 
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: how we develop sage

[Johan S . R . Nielsen]

> I don't agree with Dima that putting their code into Sage is what 
> researchers should do, no matter what.
>
> I do care a lot about my research code, and I know some of it has no place 
> inside Sage. Maintaining it outside of Sage is not just carelessness or 
> laziness, it's a design choice.

For sure - and you were not in the group of people I meant, since you
clearly stated you cared enough to rebase your code.

Changes to Sage so that external packages like yours break is
unfortunate. But I'm questioning how much we should shape our
development methodology around research projects whose developers
*don't* care enough to fix their code when it breaks. And it will break
once in a while, as long as it is not part of Sage proper.

How often do you feel that changes in Sage breaks your code?

Best,
Johan

-- 
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 we develop sage

[Simon King]

Hi Dima,

On 2016-04-08, Dima Pasechnik  wrote:
> mind you, Magma group invites such people for paid months-long visits, 
> where they work on implementing these algorithms in close contact with 
> Magma core devs.
> If only Sage could do this too... :-)

Sage has SageDays, and Sage has a rather responsive community. I recall
that in the past, the only serious issue in cooperative projects in Sage
was the time difference between Europe/Africa, Americas and Asia. But
that could be solved by staying up late.

So, I think it *is* possible to implement algorithms in close contact
with Sage core devs.

> or it might make things worse, as the functionality becomes a function of a 
> multitude of versions of different parts...

+1

And *making* it modular in the first place or even just *coping* with
modularisation is something that doesn't lie within the core competences
of (most) Sage developers, IMHO.

> But there is a way to make code work in Sage as upgrades happen - making it 
> a part of Sage :-)

Indeed that's the approach that I now take with my optional group
cohomology spkg. Thereby making it modular, just to give that concept a try.
Splitting off one third-party component, upgrading to the current
upstream version; rebasing a second third party component on top of the
upgraded first third party component (that's the main obstacle); and
eventually rebasing my own code on top of it, putting it into the Sage
library rather than keeping it in one spkg together with the other two
components.

But it costs me resources that I'd prefer to spend in a more productive
way --- and *nothing* came out of it yet! The attempt to modularise and
upgrade one upstream source to cooperate with a more recent version of
another upstream source takes longer than creating the original version of
the spkg!

> Thus I don't buy this "future-proof" statement

+1

> (well, of course, Sage may 
> fold if sufficient number of right people get hit by a bus - but the same 
> is true for Magma)

Perhaps that's the hidden purpose of SageDays. Let's make a conspiracy
theory out of it ;-)

Cheers,
Simon

-- 
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 we develop sage

[Erik Bray]

On Tue, Apr 5, 2016 at 8:44 PM, William Stein  wrote:
> Some thoughts:
>
>   - For now, work can be done that is valuable but doesn't have to
> impact the current sage/trac workflow.  For example, somebody might
> create an awesome Python package that does BLAH and depends on the
> core Sage library (what you get via "import sage" now).

FWIW in the Astropy project we have a concept called affiliated
packages [1].  The idea behind this is that if someone says "Hey, I
need  functionality for my work, can you add
that to Astropy?"  And we say, "No, because none of the Astropy core
developers understand this subject well enough to maintain the code,
and it's perhaps a little too specialized.  But you could implement it
as an affiliated package."

We require for affiliated packages that they depend on Astropy and use
Astropy's core features, such as common data structures, file format
handling, time and coordinate transformations, etc. etc. This ensures
that all affiliated packages interoperate well with each other through
the core Astropy features (in analogy to sage these might be common
representations of various core mathematical objects).

The benefits of being an "astropy affiliated package", in addition to
promising a certain level of interface commonality as described above,
also include being advertised through Astropy.  We're also working on
the ability to better discover the functionality provided by different
affiliated packages such as a cross-documentation search.  That's
still an open issue though.

And sometimes affiliated packages may be merged into the Astropy core
package as well.  This has't been done often yet, but it has been done
and will be done again.  For example the "gwcs" package is intended to
be an Astropy core package, but it's still very experimental and
volatile so it's better to develop it as a separate project for now,
rather that merge it directly into the Astropy core and then be left
being basically unable to make stable releases until the "gwcs"
feature is ready (or being forced to make releases with big warning
flags around incomplete features).

I thinks a model similar to this could work well for sage, and also
free its core developers from having to maintain huge piles of already
poorly-supported code (some "affiliated package" projects die out,
but it has no impact on the Astropy core).

Erik

[1] http://www.astropy.org/affiliated/

-- 
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 we develop sage

[Luca De Feo]

 > if research developers 1) don't care enough about their own code to 
polish it enough for going through our review process

I don't agree with Dima that putting their code into Sage is what 
researchers should do, no matter what.

I do care a lot about my research code, and I know some of it has no place 
inside Sage. Maintaining it outside of Sage is not just carelessness or 
laziness, it's a design choice.

Luca

-- 
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] failed install of pyopenssl

[Volker Braun]

Seems like the libffi header directory is versioned, that sounds like a bug 
to me. In  centos-7 it is not (/usr/include/ffi.h)

Try:

CFLAGS=-I/usr/include/libffi-3.0.5 make openssl

-- 
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: how we develop sage

[Erik Bray]

On Wed, Apr 6, 2016 at 9:51 AM, Volker Braun  wrote:
> On Tuesday, April 5, 2016 at 8:44:45 PM UTC+2, William wrote:
>>
>> [...] toward standard open source practices.
>
>
> You mean like in the Linux kernel, which uses a single monolithic git
> repository?

No piece of user-mode software is so special that it should look to
the Linux kernel as a good project to emulate.

> Really, modularization is not a useful goal in of itself. And it comes with
> its own sets of issues, see the left-pad fiasco last week when the nodejs
> clown boat caught fire.

That kind of issue is not so common though which is why it was such a
fiasco. If this happened all the time you wouldn't even hear about it.

[As an aside I wouldn't characterize an entire developer community as
a 'clown boat']

-- 
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: how we develop sage

[Johan S . R . Nielsen]

> But there is a way to make code work in Sage as upgrades happen - making it 
> a part of Sage :-)
> Thus I don't buy this "future-proof" statement (well, of course, Sage may 
> fold if sufficient number of right people get hit by a bus - but the same 
> is true for Magma)

It has something to do with the friction that William mentioned, though:
researchers barely has the time and motivation to implement their
algorithms, but they don't want to afterwards go through the - for
new-comers - rather arduous trac/ticket/reviewing process. One reason is
probably that they don't want to mature the doc and API of their code
sufficiently for it to enter sage-proper. I used to maintain a coding
theory library on bitbucket for exactly this reason.

Their work could be more available if Sage wasn't so monolithic, or at
least, if there was more of a culture of having small Sage packages
floating around. If you want their not-completely-nicely-documented
code, install their package into your Sage and be at your own risk.

What Luca is talking about poses a problem for that strategy though:
their code will work with only a few versions of Sage before breaking.
Note that I don't personally share this experience: in my own coding
theory library for Sage, no function was (AFAIK) broken in the last 5
years due to a Sage update (except for my own bugs, and some stuff
related to non-standard packaging).

But of course: if research developers 1) don't care enough about their
own code to polish it enough for going through our review process, and
2) don't care enough to fix it when incompatibilities with Sage occurs;
then is it really code we should be caring about? Won't it quickly rot
on github anyway? The research code going into Magma is exactly polished
during those visits to Magma HQ that Dima mentions.

Best,
Johan

-- 
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 we develop sage

[Simon King]

Hi Jeroen,

On 2016-04-08, Jeroen Demeyer  wrote:
> On 2016-04-08 13:26, Luca De Feo wrote:
>> This is something that should only happen at major version bumps, if ever.
>
> That's easily solved: the next stable release of Sage should be Sage 8, 
> then Sage 9 and so on...
>
> We do have a 1-year deprecation policy, but of course it's not enforced 
> (and I wouldn't know how to enforce that). If the author and reviewer of 
> a ticket don't care about deprecation, then stuff will break.

Or rather if the release manager believes that a change is "internal"
and doesn't need deprecation, then stuff will break.

Cheers,
Simon

-- 
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 we develop sage

[Erik Bray]

On Tue, Apr 5, 2016 at 8:44 PM, William Stein  wrote:
> Hi,
>
> This was a comment I just put on trac #965: "I would make a completely
> separate python package, maybe called pysmalljac, which builds
> smalljac and makes it usable from Python.  It would be on github and
> pypi.  That's how most Sage development should be done.  What a
> monster I've created by following the Magma way of doing things
> instead of the standard open source best practices..."
>
> I am recommending to absolutely everybody I talk with about Sage
> development that we switch from our current massive monolithic
> centralized approach toward standard open source practices.  Namely,
> lots of smaller libraries, standard open source practices, etc.   It
> would be really valuable to have a thread on sage-devel about how to
> more systematically support this.

Sorry for the vapid response for now, but +1 to this principle.

-- 
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 we develop sage

[Simon King]

Hi Luca,

On 2016-04-08, Luca De Feo  wrote:
> Let me recall something that comes up often, but that I haven't seen yet in 
> this thread nor at the Sage days. Just two weeks ago I was said: "We are 
> going to make our student write code in Magma, because we want something 
> future proof. We've used Sage a couple of times before, but each time Sage 
> updates break our code in <1yr, and it takes too much work to know why and 
> update our code".

+1

I was seriously fed up when my research software was broken by backwards
incompatible ostensibly "internal" changes --- repeatedly within one year---,
which hempered my work on a funded project to the extent that I couldn't
successfully finish.

I considered quitting Sage for that reason. Mainly I didn't quit because
in the *past* Sage used to be an ideal platform for my purposes, and while it
was moving forward it didn't break too much of existing code --- thus,
maintanance of my package and persistence of data was much less of a
hastle than it has been in the past one or two years. Since it was OK
till perhaps two years ago, I still hope Sage will be able to revive its
strength.

> I have this experience myself, though, being more involved in Sage, I make 
> the effort to patch my code to work with the latest stable. At some points 
> in time, it has even been impossible to have code that works both with the 
> latest stable and the latest beta (and/or the version in SMC). This is 
> something that should only happen at major version bumps, if ever.

+1

> Of course, this is not easy to solve, but having a more modular 
> distribution (at least for some meaning of "modular") might help.

-1.

My impression was that what I perceive as "decay" of Sage was caused by
changing Sage's development model. Changing the whole architecture would
create even more of an overhead, or rather a swamp in which Sage would
disappear.

Sage should build the car and not re-invent the wheel --- and much less
Sage should re-invent Sage.

Best regards,
Simon

-- 
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] failed install of pyopenssl

[Mike Zabrocki]

Well that doesn't seem to be the problem:

libffi-devel-3.0.5-3.2.el6.i686 : Development files for libffi

Repo: base

Matched from:

Filename: /usr/lib/libffi-3.0.5/include/ffi.h


libffi-devel-3.0.5-3.2.el6.x86_64 : Development files for libffi

Repo: base

Matched from:

Filename: /usr/lib64/libffi-3.0.5/include/ffi.h




[zabrocki@algebra sage]$ sudo yum install libffi

...

Package libffi-3.0.5-3.2.el6.x86_64 already installed and latest version

Nothing to do




On Friday, 8 April 2016 07:59:32 UTC-4, Jori Mäntysalo wrote:
>
> On Fri, 8 Apr 2016, Mike Zabrocki wrote: 
>
> > I've tried installing pyopenssl to a linux server running CENTOS on Sage 
> 7.2.beta2 
> > 
> > Both are terminating because of a missing header file: ffi.h 
> > Is there something that I should have installed that is missing? 
>
> yum whatprovides '*/ffi.h' 
>
> will tell what you need to install. 
>
> -- 
> Jori Mäntysalo 
>

-- 
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] failed install of pyopenssl

[Mike Zabrocki]

Well that doesn't seem to be the problem:

libffi-devel-3.0.5-3.2.el6.i686 : Development files for libffi

Repo: base

Matched from:

Filename: /usr/lib/libffi-3.0.5/include/ffi.h


libffi-devel-3.0.5-3.2.el6.x86_64 : Development files for libffi

Repo: base

Matched from:

Filename: /usr/lib64/libffi-3.0.5/include/ffi.h




[zabrocki@algebra sage]$ sudo yum install libffi

...

Package libffi-3.0.5-3.2.el6.x86_64 already installed and latest version

Nothing to do

On Fri, Apr 8, 2016 at 7:59 AM, Jori Mäntysalo 
wrote:

> On Fri, 8 Apr 2016, Mike Zabrocki wrote:
>
> I've tried installing pyopenssl to a linux server running CENTOS on Sage
>> 7.2.beta2
>>
>> Both are terminating because of a missing header file: ffi.h
>> Is there something that I should have installed that is missing?
>>
>
> yum whatprovides '*/ffi.h'
>
> will tell what you need to install.
>
> --
> Jori Mäntysalo
>

-- 
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] failed install of pyopenssl

[Jori Mäntysalo]

On Fri, 8 Apr 2016, Mike Zabrocki wrote:


I've tried installing pyopenssl to a linux server running CENTOS on Sage 
7.2.beta2

Both are terminating because of a missing header file: ffi.h
Is there something that I should have installed that is missing?


yum whatprovides '*/ffi.h'

will tell what you need to install.

--
Jori Mäntysalo

[sage-devel] failed install of pyopenssl

[Mike Zabrocki]

I've tried installing pyopenssl to a linux server running CENTOS on Sage 
7.2.beta2 (and beta3).
I used one of two commands 
./sage -i pyopenssl
./sage -pip install pyopenssl

Both are terminating because of a missing header file: ffi.h
Is there something that I should have installed that is missing?

-Mike


[sageuser@algebra sage]$ ./sage -pip install pyopenssl

Collecting pyopenssl

  Using cached pyOpenSSL-16.0.0-py2.py3-none-any.whl

Collecting cryptography>=1.3 (from pyopenssl)

  Using cached cryptography-1.3.1.tar.gz

Requirement already satisfied (use --upgrade to upgrade): six>=1.5.2 in 
./local/lib/python2.7/site-packages/six-1.10.0-py2.7.egg (from pyopenssl)

Requirement already satisfied (use --upgrade to upgrade): idna>=2.0 in 
./local/lib/python2.7/site-packages (from cryptography>=1.3->pyopenssl)

Requirement already satisfied (use --upgrade to upgrade): pyasn1>=0.1.8 in 
./local/lib/python2.7/site-packages (from cryptography>=1.3->pyopenssl)

Requirement already satisfied (use --upgrade to upgrade): setuptools>=11.3 
in ./local/lib/python2.7/site-packages/setuptools-20.3.1-py2.7.egg (from 
cryptography>=1.3->pyopenssl)

Requirement already satisfied (use --upgrade to upgrade): enum34 in 
./local/lib/python2.7/site-packages (from cryptography>=1.3->pyopenssl)

Requirement already satisfied (use --upgrade to upgrade): ipaddress in 
./local/lib/python2.7/site-packages (from cryptography>=1.3->pyopenssl)

Collecting cffi>=1.4.1 (from cryptography>=1.3->pyopenssl)

  Using cached cffi-1.5.2.tar.gz

Requirement already satisfied (use --upgrade to upgrade): pycparser in 
./local/lib/python2.7/site-packages (from 
cffi>=1.4.1->cryptography>=1.3->pyopenssl)

Installing collected packages: cffi, cryptography, pyopenssl

  Running setup.py install for cffi ... error

Complete output from command /usr/local/sage-7.2.beta3/local/bin/python 
-u -c "import setuptools, 
tokenize;__file__='/tmp/pip-build-qYgPpy/cffi/setup.py';exec(compile(getattr(tokenize,
 
'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" 
install --record /tmp/pip-kgVvmG-record/install-record.txt 
--single-version-externally-managed --compile:

Package libffi was not found in the pkg-config search path.

Perhaps you should add the directory containing `libffi.pc'

to the PKG_CONFIG_PATH environment variable

No package 'libffi' found

Package libffi was not found in the pkg-config search path.

Perhaps you should add the directory containing `libffi.pc'

to the PKG_CONFIG_PATH environment variable

No package 'libffi' found

Package libffi was not found in the pkg-config search path.

Perhaps you should add the directory containing `libffi.pc'

to the PKG_CONFIG_PATH environment variable

No package 'libffi' found

Package libffi was not found in the pkg-config search path.

Perhaps you should add the directory containing `libffi.pc'

to the PKG_CONFIG_PATH environment variable

No package 'libffi' found

Package libffi was not found in the pkg-config search path.

Perhaps you should add the directory containing `libffi.pc'

to the PKG_CONFIG_PATH environment variable

No package 'libffi' found

running install

running build

running build_py

creating build

creating build/lib.linux-x86_64-2.7

creating build/lib.linux-x86_64-2.7/cffi

copying cffi/setuptools_ext.py -> build/lib.linux-x86_64-2.7/cffi

copying cffi/commontypes.py -> build/lib.linux-x86_64-2.7/cffi

copying cffi/cffi_opcode.py -> build/lib.linux-x86_64-2.7/cffi

copying cffi/__init__.py -> build/lib.linux-x86_64-2.7/cffi

copying cffi/lock.py -> build/lib.linux-x86_64-2.7/cffi

copying cffi/cparser.py -> build/lib.linux-x86_64-2.7/cffi

copying cffi/verifier.py -> build/lib.linux-x86_64-2.7/cffi

copying cffi/api.py -> build/lib.linux-x86_64-2.7/cffi

copying cffi/backend_ctypes.py -> build/lib.linux-x86_64-2.7/cffi

copying cffi/recompiler.py -> build/lib.linux-x86_64-2.7/cffi

copying cffi/ffiplatform.py -> build/lib.linux-x86_64-2.7/cffi

copying cffi/model.py -> build/lib.linux-x86_64-2.7/cffi

copying cffi/vengine_gen.py -> build/lib.linux-x86_64-2.7/cffi

copying cffi/gc_weakref.py -> build/lib.linux-x86_64-2.7/cffi

copying cffi/vengine_cpy.py -> build/lib.linux-x86_64-2.7/cffi

copying cffi/_cffi_include.h -> build/lib.linux-x86_64-2.7/cffi

copying cffi/parse_c_type.h -> build/lib.linux-x86_64-2.7/cffi

copying cffi/_embedding.h -> build/lib.linux-x86_64-2.7/cffi

running build_ext

building '_cffi_backend' extension

creating build/temp.linux-x86_64-2.7

creating build/temp.linux-x86_64-2.7/c

gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall 
-Wno-unused -fPIC -DUSE__THREAD -I/usr/include/ffi -I/usr/include/libffi 
-I/usr/local/sage-7.2.beta3/local/include/python2.7 -c c/_cffi_backend.c -o 

[sage-devel] Re: how we develop sage

[Dima Pasechnik]

On Friday, April 8, 2016 at 12:26:22 PM UTC+1, Luca De Feo wrote:
>
> > This thread is first and foremost about reducing the friction involved 
> in making code that depends on the Sage distribution available to the world.
> > Based on feedback I get from users, this friction is a very, very 
> significant problem to the growth of Sage. 
>
> Let me recall something that comes up often, but that I haven't seen yet 
> in this thread nor at the Sage days. Just two weeks ago I was said: "We are 
> going to make our student write code in Magma, because we want something 
> future proof. We've used Sage a couple of times before, but each time Sage 
> updates break our code in <1yr, and it takes too much work to know why and 
> update our code".
>
> Let me stress that these are highly skilled researchers who develop 
> amazing software and have a very deep knowledge about programming. One of 
> them develops a library that is a core piece of infrastructure for Magma, 
> and which is responsible for a good fraction of the benchmarks where Magma 
> crushes Sage. If we could make these people stick to Sage, I can only 
> imagine benefits for us.
>

mind you, Magma group invites such people for paid months-long visits, 
where they work on implementing these algorithms in close contact with 
Magma core devs.
If only Sage could do this too... :-)

 

>
> I have this experience myself, though, being more involved in Sage, I make 
> the effort to patch my code to work with the latest stable. At some points 
> in time, it has even been impossible to have code that works both with the 
> latest stable and the latest beta (and/or the version in SMC). This is 
> something that should only happen at major version bumps, if ever.
>
> Of course, this is not easy to solve, but having a more modular 
> distribution (at least for some meaning of "modular") might help.
>
or it might make things worse, as the functionality becomes a function of a 
multitude of versions of different parts...

But there is a way to make code work in Sage as upgrades happen - making it 
a part of Sage :-)
Thus I don't buy this "future-proof" statement (well, of course, Sage may 
fold if sufficient number of right people get hit by a bus - but the same 
is true for Magma)


 

>
> --
> Luca
>
>

-- 
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: how we develop sage

[Jeroen Demeyer]

On 2016-04-08 13:26, Luca De Feo wrote:

This is something that should only happen at major version bumps, if ever.


That's easily solved: the next stable release of Sage should be Sage 8, 
then Sage 9 and so on...


We do have a 1-year deprecation policy, but of course it's not enforced 
(and I wouldn't know how to enforce that). If the author and reviewer of 
a ticket don't care about deprecation, then stuff will break.


--
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 we develop sage

[Luca De Feo]

> This thread is first and foremost about reducing the friction involved in 
making code that depends on the Sage distribution available to the world.
> Based on feedback I get from users, this friction is a very, very 
significant problem to the growth of Sage. 

Let me recall something that comes up often, but that I haven't seen yet in 
this thread nor at the Sage days. Just two weeks ago I was said: "We are 
going to make our student write code in Magma, because we want something 
future proof. We've used Sage a couple of times before, but each time Sage 
updates break our code in <1yr, and it takes too much work to know why and 
update our code".

Let me stress that these are highly skilled researchers who develop amazing 
software and have a very deep knowledge about programming. One of them 
develops a library that is a core piece of infrastructure for Magma, and 
which is responsible for a good fraction of the benchmarks where Magma 
crushes Sage. If we could make these people stick to Sage, I can only 
imagine benefits for us.

I have this experience myself, though, being more involved in Sage, I make 
the effort to patch my code to work with the latest stable. At some points 
in time, it has even been impossible to have code that works both with the 
latest stable and the latest beta (and/or the version in SMC). This is 
something that should only happen at major version bumps, if ever.

Of course, this is not easy to solve, but having a more modular 
distribution (at least for some meaning of "modular") might help.

--
Luca

-- 
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 we develop sage

[Sébastien Labbé]

On Tuesday, April 5, 2016 at 8:44:45 PM UTC+2, William wrote:
>
> Hi, 
>
> This was a comment I just put on trac #965: "I would make a completely 
> separate python package, maybe called pysmalljac, which builds 
> smalljac and makes it usable from Python.  It would be on github and 
> pypi.  That's how most Sage development should be done.  What a 
> monster I've created by following the Magma way of doing things 
> instead of the standard open source best practices..." 
>
> I am recommending to absolutely everybody I talk with about Sage 
> development that we switch from our current massive monolithic 
> centralized approach toward standard open source practices.  Namely, 
> lots of smaller libraries, standard open source practices, etc.   It 
> would be really valuable to have a thread on sage-devel about how to 
> more systematically support this. 
>
> Some thoughts: 
>
>   - For now, work can be done that is valuable but doesn't have to 
> impact the current sage/trac workflow.  For example, somebody might 
> create an awesome Python package that does BLAH and depends on the 
> core Sage library (what you get via "import sage" now). 
>
>   - There are 77989 examples of Python packages at 
> https://pypi.python.org/pypi 
>
>   - This is pretty useful to read: 
> https://python-packaging.readthedocs.org/en/latest/


Jeroen suggests also this link which seems to him more up to date:

https://packaging.python.org/en/latest/distributing/
 

>
>
>   - In the beginning I put everything into one library, since it was 
> small.  Then it started getting bigger and in 2006, 2007, etc. we 
> talked a lot about splitting up Sage, having smaller packages, etc. 
> There was a lot of momentum and it was pretty clear to all the CS-type 
> people involved in Sage (who knew about programming from more than 
> just Sage) that this is what we needed to do.  People like Martin 
> Albrecht and David Harvey.  Then those people all got jobs and 
> couldn't work on infrastructure aspects of Sage...  and nothing 
> happened in this direction. 
>
>- PSage was an attempt at something like this where I could work 
> out how to build Cython code in parallel, etc., etc. using more modern 
> packaging.  That was in about 2011, and then I stopped to work on SMC 
> fulltime for several years, hence work on psage stopped, since I can 
> only do one thing at a time. 
>
>  -- William 
>
> -- 
> 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: SageMath for Windows installer

[David Joyner]

On Fri, Apr 8, 2016 at 5:25 AM, Erik Bray  wrote:
> On Fri, Apr 8, 2016 at 11:23 AM, Erik Bray  wrote:
>> On Thu, Apr 7, 2016 at 5:41 PM, David Joyner  wrote:
>>> On Fri, Mar 25, 2016 at 8:41 AM, Dima Pasechnik  wrote:


 On Friday, March 25, 2016 at 11:53:51 AM UTC, aishen wrote:
>
> Unfortunatly it doesn't work on an intel core II pentium I have, it says
> it can't do virtualization...


 you might need to change BIOS settings to allow virtialization.

>>>
>>> The sysadmin at work tried this on a intel windows 7 machine, with the
>>> BIOS setting for hardware virtualization checked, and it gave the
>>> error "Could not start Docker VM".
>>>
>>> Further, no VM was installed on this machine.
>>>
>>> Any idea what the error was caused by?
>>
>> No, there are probably myriad reasons it could go wrong. Were they
>> able to install Docker Toolbox just by itself?
>

It did install Docker into the registry (so one could uninstall it,
which we did when trying a second time to install SageMath).
However, after "Could not start Docker VM" it said "backing out"
or something like that.

> It also sounds like a possible known failure mode is if some version
> of VirtualBox is already installed on the system but is too old.  Try
> uninstalling any existing VirtualBox first.
>

No VM at all was installed.

I'm not a windows user and this wasn't my machine.

> Le mercredi 23 mars 2016 12:15:58 UTC+1, Erik Bray a écrit :
>>
>> Hi all,
>>
>> I've been working for a few weeks on an installer for Sage on Windows,
>> which takes advantage of Docker to accomplish this.*  The goal of this
>> project is to make it possible to run Sage on Windows with as much
>> transparency as possible, such that the user isn't really aware that
>> there is any virtualization involved.  As you can read in my report
>> for the OpenDreamKit project on Docker containers [1] there are limits
>> to this.
>>
>> However, in the ideal case a user simply downloads and runs an
>> executable--clicks through a graphical install wizard, and then gets a
>> desktop icon which launches a Jupyter notebook (with sage and terminal
>> support) in their default web browser.  Although there are still a few
>> rough edges [2] the alpha version of the Sage for Windows installer
>> that I have for you today does just that:
>>
>>
>> https://github.com/embray/sage-windows/releases/download/v1a1/SageMath-7.0-1a1-fat.exe
>>
>> My hope is for this to eventually be adopted into the SageMath project
>> as the "official" distribution for Windows, replacing the existing
>> VM-based solution as I believe that this gives an overall
>> lighter-weight and more transparently "native" user experience.  In
>> the future the same approach could also be adopted--I think--to
>> provide a "local" installation of SMC.
>>
>> Now, if anyone with access to a Windows machine (Windows 7 or newer),
>> it would be a big favor if I could get a few testers to bang this
>> around a bit and see what breaks and what works and what could be
>> improved.
>>
>> To be clear, right now it only supports running the notebook, though
>> I'm also working on making it possible to run `sage` at a Windows
>> command prompt (almost working).  Also be aware if you try to test
>> this: The biggest limitation for now (as described also in [1]) is
>> that for Docker on Windows hardware virtualization support is required
>> to be enabled.  If this is not enabled the most likely outcome is that
>> the installer will fail with an error message like "Could not start
>> Docker VM". In this case you will have to grub around in your BIOS
>> settings to find hardware assisted virtualization support--this of
>> course is going to be the most difficult aspect of making this
>> available to "average" users.  A workaround may be possible but I'm
>> not sure yet.
>>
>> Be aware also that the installer can take a few minutes to run (as
>> much as 5 minutes even on a reasonably fast machine) mostly due to it
>> being highly compressed.
>>
>> Anyways, I look forward to your questions and feedback!
>>
>> Thanks,
>> Erik
>>
>>
>>>
>>> --
>>> 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 

Re: [sage-devel] Re: SageMath for Windows installer

[Erik Bray]

On Fri, Apr 8, 2016 at 11:23 AM, Erik Bray  wrote:
> On Thu, Apr 7, 2016 at 5:41 PM, David Joyner  wrote:
>> On Fri, Mar 25, 2016 at 8:41 AM, Dima Pasechnik  wrote:
>>>
>>>
>>> On Friday, March 25, 2016 at 11:53:51 AM UTC, aishen wrote:

 Unfortunatly it doesn't work on an intel core II pentium I have, it says
 it can't do virtualization...
>>>
>>>
>>> you might need to change BIOS settings to allow virtialization.
>>>
>>
>> The sysadmin at work tried this on a intel windows 7 machine, with the
>> BIOS setting for hardware virtualization checked, and it gave the
>> error "Could not start Docker VM".
>>
>> Further, no VM was installed on this machine.
>>
>> Any idea what the error was caused by?
>
> No, there are probably myriad reasons it could go wrong. Were they
> able to install Docker Toolbox just by itself?

It also sounds like a possible known failure mode is if some version
of VirtualBox is already installed on the system but is too old.  Try
uninstalling any existing VirtualBox first.

 Le mercredi 23 mars 2016 12:15:58 UTC+1, Erik Bray a écrit :
>
> Hi all,
>
> I've been working for a few weeks on an installer for Sage on Windows,
> which takes advantage of Docker to accomplish this.*  The goal of this
> project is to make it possible to run Sage on Windows with as much
> transparency as possible, such that the user isn't really aware that
> there is any virtualization involved.  As you can read in my report
> for the OpenDreamKit project on Docker containers [1] there are limits
> to this.
>
> However, in the ideal case a user simply downloads and runs an
> executable--clicks through a graphical install wizard, and then gets a
> desktop icon which launches a Jupyter notebook (with sage and terminal
> support) in their default web browser.  Although there are still a few
> rough edges [2] the alpha version of the Sage for Windows installer
> that I have for you today does just that:
>
>
> https://github.com/embray/sage-windows/releases/download/v1a1/SageMath-7.0-1a1-fat.exe
>
> My hope is for this to eventually be adopted into the SageMath project
> as the "official" distribution for Windows, replacing the existing
> VM-based solution as I believe that this gives an overall
> lighter-weight and more transparently "native" user experience.  In
> the future the same approach could also be adopted--I think--to
> provide a "local" installation of SMC.
>
> Now, if anyone with access to a Windows machine (Windows 7 or newer),
> it would be a big favor if I could get a few testers to bang this
> around a bit and see what breaks and what works and what could be
> improved.
>
> To be clear, right now it only supports running the notebook, though
> I'm also working on making it possible to run `sage` at a Windows
> command prompt (almost working).  Also be aware if you try to test
> this: The biggest limitation for now (as described also in [1]) is
> that for Docker on Windows hardware virtualization support is required
> to be enabled.  If this is not enabled the most likely outcome is that
> the installer will fail with an error message like "Could not start
> Docker VM". In this case you will have to grub around in your BIOS
> settings to find hardware assisted virtualization support--this of
> course is going to be the most difficult aspect of making this
> available to "average" users.  A workaround may be possible but I'm
> not sure yet.
>
> Be aware also that the installer can take a few minutes to run (as
> much as 5 minutes even on a reasonably fast machine) mostly due to it
> being highly compressed.
>
> Anyways, I look forward to your questions and feedback!
>
> Thanks,
> Erik
>
>
>>
>> --
>> 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] Re: SageMath for Windows installer

[Erik Bray]

On Thu, Apr 7, 2016 at 5:41 PM, David Joyner  wrote:
> On Fri, Mar 25, 2016 at 8:41 AM, Dima Pasechnik  wrote:
>>
>>
>> On Friday, March 25, 2016 at 11:53:51 AM UTC, aishen wrote:
>>>
>>> Unfortunatly it doesn't work on an intel core II pentium I have, it says
>>> it can't do virtualization...
>>
>>
>> you might need to change BIOS settings to allow virtialization.
>>
>
> The sysadmin at work tried this on a intel windows 7 machine, with the
> BIOS setting for hardware virtualization checked, and it gave the
> error "Could not start Docker VM".
>
> Further, no VM was installed on this machine.
>
> Any idea what the error was caused by?

No, there are probably myriad reasons it could go wrong. Were they
able to install Docker Toolbox just by itself?

>>> Le mercredi 23 mars 2016 12:15:58 UTC+1, Erik Bray a écrit :

 Hi all,

 I've been working for a few weeks on an installer for Sage on Windows,
 which takes advantage of Docker to accomplish this.*  The goal of this
 project is to make it possible to run Sage on Windows with as much
 transparency as possible, such that the user isn't really aware that
 there is any virtualization involved.  As you can read in my report
 for the OpenDreamKit project on Docker containers [1] there are limits
 to this.

 However, in the ideal case a user simply downloads and runs an
 executable--clicks through a graphical install wizard, and then gets a
 desktop icon which launches a Jupyter notebook (with sage and terminal
 support) in their default web browser.  Although there are still a few
 rough edges [2] the alpha version of the Sage for Windows installer
 that I have for you today does just that:


 https://github.com/embray/sage-windows/releases/download/v1a1/SageMath-7.0-1a1-fat.exe

 My hope is for this to eventually be adopted into the SageMath project
 as the "official" distribution for Windows, replacing the existing
 VM-based solution as I believe that this gives an overall
 lighter-weight and more transparently "native" user experience.  In
 the future the same approach could also be adopted--I think--to
 provide a "local" installation of SMC.

 Now, if anyone with access to a Windows machine (Windows 7 or newer),
 it would be a big favor if I could get a few testers to bang this
 around a bit and see what breaks and what works and what could be
 improved.

 To be clear, right now it only supports running the notebook, though
 I'm also working on making it possible to run `sage` at a Windows
 command prompt (almost working).  Also be aware if you try to test
 this: The biggest limitation for now (as described also in [1]) is
 that for Docker on Windows hardware virtualization support is required
 to be enabled.  If this is not enabled the most likely outcome is that
 the installer will fail with an error message like "Could not start
 Docker VM". In this case you will have to grub around in your BIOS
 settings to find hardware assisted virtualization support--this of
 course is going to be the most difficult aspect of making this
 available to "average" users.  A workaround may be possible but I'm
 not sure yet.

 Be aware also that the installer can take a few minutes to run (as
 much as 5 minutes even on a reasonably fast machine) mostly due to it
 being highly compressed.

 Anyways, I look forward to your questions and feedback!

 Thanks,
 Erik


>
> --
> 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] Re: SageMath for Windows installer

[Sebastien Gouezel]

Le jeudi 7 avril 2016 21:14:24 UTC+2, Emil Widmann a écrit :
>
> < I don't really wee why it could not be user-friendly, can you elaborate 
> on this? 
>
> I think cygwin is a lot slower than virtualisation - or has this changed?
>

I did once a pretty big Sage computation on the same computer (involving 
big matrices and cython routines), both on Ubuntu and on Cygwin. Timings 
were essentially the same. I can't give you recent figures as my Ubuntu is 
broken since its last big update... Of course, if a package is specially 
optimized for Linux, then it will be much faster there, but otherwise there 
should not be a big difference (what is much slower on Cygwin, however, is 
Sagemath compilation, but this is not really relevant for users).

Sébastien

-- 
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: make ptestlong

[Volker Braun]

On Thursday, April 7, 2016 at 5:03:44 PM UTC+2, kcrisman wrote:
>
> Yes, though again this is a loaner so very little was preinstalled.  But 
> where is Sage invoking Java (as a command) during non-optional tests in the 
> first place?  Running doctests shouldn't be using jmol - or do some of them?
>

Java is used to pre-render a jmol scene preview, if it is available. There 
are doctests for that, and they will trigger the java popup on OSX.

If we had a reliable way to distinguish the Apple popup from the real 
"java" then we could prevent it from happening...

-- 
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: how we develop sage

[Jeroen Demeyer]

On 2016-04-08 00:58, William Stein wrote:

- Cython: relying on pxi/pxd files from the sage library.


Please push for https://github.com/cython/cython/pull/483 if you care 
about this. Cython upstream doesn't seem to "get" that we need this patch.


--
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 we develop sage

[Volker Braun]

On Friday, April 8, 2016 at 2:36:23 AM UTC+2, William wrote:
>
> Whats wrong with the obvious solution: make it a Python package (basically 
>> add setup.py) and then "sage -pip install 
>> https://github.com/vbraun/awesomepackage.git;. Clearly we could have 
>> more documentation for how to write the setup.py or some package directory 
>> service. But really it is already a one-liner.
>>
>
>  That is exactly what I'm proposing
>

But then there is nothing to do on the Sage side, this already works and is 
totally standard. Documentation for how to package your own Python code can 
easily be found online.

 

> Yes but cython and cysignals don't do anything for math directly, they are 
>> pure dependencies. By contrast, lets say we break out all elliptic curve 
>> stuff into a separate package. Just like with cysignals, this will remove 
>> all elliptic curve documentation from the Sage reference manual. Still a 
>> win-win? 
>>
> 1. Not necessarily true.
>

It is if you want to have a uniform document with cross references working. 
Much of the memory usage of the current docbuild is the huge intersphinx 
data, and no amount of modularization would make that smaller. That is not 
to say that docbuilding can't be improved, but certainly not by spreading 
out the documentation sources.
 

> 2. Is it so bad that the Cython docs aren't in the sage reference manual?
>

As I said before,  cython and cysignals don't do anything for math directly 
so they are a special case. In fact, they shouldn't be in the main Sage 
docs even if they were part of Sage.
 

-- 
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: What to do with the documentation of an optional spkg

[Simon King]

Hi!

On 2016-04-08, Volker Braun  wrote:
> Automatic import of additional globals into the Sage command line should be 
> determined by configuration file(s) in SAGE_LOCAL/etc/sagemath (or so), not 
> by mokeypatching stuff in Sage. Feel free to send in a patch...

One should also mention that meanwhile we have optional Cython modules.
In other words, if you have an optional spkg foo and some code that
makes foo usable in Sage, then you could create an optional Cython
module sage.bar that depends on foo.

Consquence:
- Documentation of sage.bar would be available, regardless whether foo
  is installed or not. A side remark on modularisation: I very much
  appreciate to have the full documentation available from within
  Sage. I wouldn't like to search the internet for documentation of
  things that I *could* do with Sage after installing some optional
  module.
- The installation of the optional spkg foo would *not* alter the Sage
  library (which would end in chaos). Instead, "make foo" (if I recall
  correctly) would install the optional spkg foo and then create
  sage.bar. While documentation of sage.bar is always available,
  documentation of foo will only be available after you install it,
  preferably in the default location mentioned by Volker.

See sage.matrix.matrix_gfpn_dense for an example (and have a look at
SAGE_ROOT/src/module_list.py). It is an optional Cython module depending
on the optional MeatAxe spkg.

Cheers,
Simon

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