[sage-devel] Re: how we develop sage

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

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

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

> 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

[sage-devel] Re: how we develop sage

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

[sage-devel] Re: how we develop sage

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

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

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

[sage-devel] Re: catch a "sagemath" DeprecationWarning

> 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

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

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

Re: [sage-devel] catch a "sagemath" DeprecationWarning

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

[sage-devel] Re: how we develop sage

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

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

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

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

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

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

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

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

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

[sage-devel] Re: how we develop sage

> 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

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

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

[sage-devel] Re: how we develop sage

> 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

[sage-devel] catch a "sagemath" DeprecationWarning

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

[sage-devel] Re: how we develop sage

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

[sage-devel] Re: failed install of pyopenssl

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

Re: [sage-devel] failed install of pyopenssl

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.

[sage-devel] Re: how we develop sage

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

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

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

[sage-devel] Re: how we develop sage

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

Re: [sage-devel] how we develop sage

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

[sage-devel] Re: how we develop sage

> 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

Re: [sage-devel] failed install of pyopenssl

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

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

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

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

> 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

[sage-devel] Re: how we develop sage

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

Re: [sage-devel] how we develop sage

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.

[sage-devel] Re: how we develop sage

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

Re: [sage-devel] failed install of pyopenssl

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:

Re: [sage-devel] failed install of pyopenssl

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:

Re: [sage-devel] failed install of pyopenssl

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

[sage-devel] failed install of pyopenssl

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

[sage-devel] Re: how we develop sage

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 >

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

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

[sage-devel] Re: how we develop sage

> 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

[sage-devel] Re: how we develop sage

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.

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

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

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

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:

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

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

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

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

[sage-devel] Re: make ptestlong

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

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

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

[sage-devel] Re: how we develop sage

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

[sage-devel] Re: What to do with the documentation of an optional spkg

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