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
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')
> 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
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
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
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
> 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
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
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
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 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
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
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
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
>>>
> 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
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
> 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
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
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
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
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.
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
--
> 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.
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
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
> 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
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
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
> 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
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...
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.
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
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:
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:
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
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
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
>
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
> 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
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.
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
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:
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
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
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
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
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
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
48 matches
Mail list logo