Dear all,
My Sage 6.6 install quits after printing a depreciation warning message
when I issue:
sage: vars()
Same is true for at least globals().
Any clue on what's going on?
Best,
JP
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To
Hi again,
The ticket is again ready for review!
http://trac.sagemath.org/ticket/18128
Thanks!!
JP
--
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
On 2015-05-06 11:04, jplab wrote:
Hi again,
The ticket is again ready for review!
... just like 225 other tickets.
--
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
There were some changes to how globals() are handled. Did you run make,
can you show us the output, debugger, ...
On Wednesday, May 6, 2015 at 10:51:27 AM UTC+2, Jean-Pierre Flori wrote:
Dear all,
My Sage 6.6 install quits after printing a depreciation warning message
when I issue:
Jean-Pierre Flori wrote:
My Sage 6.6 install quits after printing a depreciation warning message
when I issue:
sage: vars()
Works for me:
...
'zeta': zeta,
'zeta__exact': function zeta__exact at 0x7fa3b8c84b90,
'zeta_symmetric': function zeta_symmetric at 0x7fa3bac2f9b0,
'zeta_zeros':
In the same vein, shouldn't base_ring be removed from Parent as well ?
sage: Set([1,2,3]).base_ring()
The return value is None, which is arguably correct, for a generic set has
no base ring, but it might be surprising when using tab completion to
discover functionalities to see that a
I also have a 6.6 install which quites badly when I give (as the first
command) vars(). The output is hunderds of lines long and ends with
TypeError Traceback (most recent call last)
ipython-input-1-ef3ed5b882d8 in module()
1 vars()
On 6 May 2015 at 12:49, Volker Braun vbraun.n...@gmail.com wrote:
vars() works as documented.
Its a good test whether every object that we define can actually print
That sounds like a good thing, but I still do not understand why an
error is raised.
John
itself. That caughs up plenty of
Technically its because
* notebook is a lazy import,
* printing notebook causes sagenb to be imported
* which changes the displayhook to the SageNB displayhook which causes
various problems.
On Wednesday, May 6, 2015 at 1:58:45 PM UTC+2, John Cremona wrote:
On 6 May 2015 at 12:49, Volker
It is of course just about oneliner to check if a set is gcd closed or
not.
But would it be useful to have is_gcd_closed() as a Sage built-in
function?
--
Jori Mäntysalo
vars() works as documented.
Its a good test whether every object that we define can actually print
itself. That caughs up plenty of deprecation warnings and fails for
sage: notebook
sagenb.notebook.notebook_object.NotebookObject instance at 0x7fbf8537e758
Hi!
Compare the following code in the command line and the cloud:
In the terminal:
sage: t=timeit('factor(ZZ.random_element(10^40))', seconds=True)
sage: t
0.019134044647216797
sage: type(t)
type 'float'
In the cloud:
sage: t=timeit('factor(ZZ.random_element(10^40))', seconds=True)
On Wed, 6 May 2015, John Cremona wrote:
But would it be useful to have is_gcd_closed() as a Sage built-in function?
I have not come across this function before (and I am a number
theorist!). I am guessing on what it means: applied to a set of
integers (?) or positive integers, it checks
On Wed, May 6, 2015 at 7:03 AM, jplab jeanphilippela...@gmail.com wrote:
Hi!
Compare the following code in the command line and the cloud:
In the terminal:
sage: t=timeit('factor(ZZ.random_element(10^40))', seconds=True)
sage: t
0.019134044647216797
sage: type(t)
type 'float'
In the
On 6 May 2015 at 13:32, Jori Mäntysalo jori.mantys...@uta.fi wrote:
It is of course just about oneliner to check if a set is gcd closed or not.
But would it be useful to have is_gcd_closed() as a Sage built-in function?
I have not come across this function before (and I am a number
I unpacked the sage 6.6 tarball and ran make.
I'll have some trouble posting the exact output here as the machine is not
connected to the network, but basically:
* I'm on an amd64 Ubuntu 14.04.2 LTS.
* I launch: sage
* I type at Sage's prompt: vars()
* I get:
/blablabla/pretty_print.py:147:
On 2015-05-06 14:09, Volker Braun wrote:
Technically its because
* notebook is a lazy import,
* printing notebook causes sagenb to be imported
* which changes the displayhook to the SageNB displayhook which causes
various problems.
I guess that's a bug. Simply *importing* sagenb should not
Hi,
Thanks for the feedback.I decided to (1) use sage-6.7.beta4, and
(2) upgrade to Ubuntu-15.04. The Sage build has gone perfectly with
this combination.
-- William
On Wed, May 6, 2015 at 8:32 AM, John Foster jfoster81...@gmail.com wrote:
Just a suggestion:
Try a different make, as you
Hello,
Travis Scrimshaw wrote:
On #15635, we are trying to decide whether we want non-associative
algebras to be included in the catalog of algebras.
For a general mathematical software system such as Sage, I think it is
overly restrictive to impose the rule that algebras are associative.
Hello,
I have tried to compile sage from sources but it does not work.
Attached is a log of the last part of the compiling output.
My OS is a Linux Mint 17 64 bits.
Thanks in advance for any help.
Christophe
--
You received this message because you are subscribed to the Google Groups
Forward to sage-algebra?
John
On 6 May 2015 at 20:08, Travis Scrimshaw tsc...@ucdavis.edu wrote:
On #15635, we are trying to decide whether we want non-associative algebras
to be included in the catalog of algebras.
The argument against including them is most people think of algebras as
On 2015-05-06 20:00, Clemens Heuberger wrote:
I'm happy to switch to closed when I merge it, and not only when it tests ok.
The downside is that you'll get more emails as I'll inevitably have to reopen
tickets, but merging/unmerging is scripted anyways. Eventually the merge will be
done by a
On Wednesday, May 6, 2015 at 8:07:08 PM UTC+2, Jeroen Demeyer wrote:
And it just feels like an unneeded restriction that tickets shouldn't be
changed after positive_review: there is no fundamental reason why
positive_review should be final.
There is no reason that closed should be final,
This is now ticket #18374
El miércoles, 6 de mayo de 2015, 17:47:54 (UTC+2), Jakob Kroeker escribió:
It is definitely a bug in the dimension method.
could you open a ticket and post the link here?
Am Sonntag, 3. Mai 2015 15:25:13 UTC+2 schrieb mmarco:
It is definitely a bug in the
Am 2015-05-06 um 20:07 schrieb Jeroen Demeyer:
On 2015-05-06 20:00, Clemens Heuberger wrote:
I'm happy to switch to closed when I merge it, and not only when it tests
ok.
The downside is that you'll get more emails as I'll inevitably have to
reopen
tickets, but merging/unmerging is
On #15635 http://trac.sagemath.org/ticket/15635, we are trying to decide
whether we want non-associative algebras to be included in the catalog of
algebras.
The argument against including them is most people think of algebras as
being associative (and maybe even unital), and as such, might
There are some unicode typesetting enhancements coming down the road:
#18357: Unicode Art
#18270: Print matrices using unicode large delimiters (on demand)
On Wednesday, May 6, 2015 at 7:03:23 PM UTC+2, Bill Page wrote:
Perhaps this is more specifically related to Sage. Anyone have any
Am 2015-05-04 um 12:46 schrieb Volker Braun:
It didn't work, there is no deprecation period for removing bugs.
I see. Sorry, that was not clear to me, neither here nor on the ticket.
Regards, CH
On Monday, May 4, 2015 at 11:14:43 AM UTC+2, Clemens Heuberger wrote:
On 2015-05-04
Perhaps this is more specifically related to Sage. Anyone have any
suggestions or comments? Has the issue of sending unicode to external
programs been discussed before?
Is there a better way to implement this without having to modify a
common python site package?
Is there a good way to make
Am 2015-04-19 um 01:10 schrieb Volker Braun:
On Saturday, April 18, 2015 at 4:47:05 AM UTC-4, Clemens Heuberger wrote:
Freezing tickets once release manager starts merging them
- change status to closed
- some new status)
I'm happy to switch to closed when
John Foster wrote:
Just a suggestion:
Try a different make, as you know there are several.
You mean a different 'make' program?
There's nothing wrong with 'make' here; the R binary crashed:
$ printf '#includestdlib.h\nint main(){abort();}' | gcc -o dump_core
-x c -
$ printf 'all:\n\t@echo |
After reading the docs:
http://pexpect.readthedocs.org/en/latest/index.html
It seems that version 3 and later are supposed to handler unicode
properly. Version 3.3 requires Python 2.6 or later. Since Sage is
already at Python 2.7 is there a good reason why Sage is still using
an older version
Is there a possibility of creating an experimental package to install
pexpect 3.3 ?
I see references to doctests failing but no details. It would be
good to make this easier to test.
On 6 May 2015 at 22:41, leif not.rea...@online.de wrote:
Bill Page wrote:
After reading the docs:
Am 2015-05-07 um 03:42 schrieb leif:
I might be wrong, but isn't it trivial to check whether the branch of a
ticket changed (after you merged it into some preliminary release)?
It is easy to check. But what if it did change? This might lead to an infinite
cycle, as outlined before.
Regards, CH
On Wed, May 6, 2015 at 4:54 PM, William Stein wst...@gmail.com wrote:
Hi,
Thanks for the feedback.I decided to (1) use sage-6.7.beta4, and
(2) upgrade to Ubuntu-15.04. The Sage build has gone perfectly with
this combination.
This worked and all long tests passed.
William
-- William
Haven’t checked recently but the notebook has been broken each
time someone has tried to update pexpect. There is a pexpect upgrade
ticket where there should be more details.
François
On 7/05/2015, at 13:55, Bill Page bill.p...@newsynthesis.org wrote:
After reading the docs:
Bill Page wrote:
After reading the docs:
http://pexpect.readthedocs.org/en/latest/index.html
It seems that version 3 and later are supposed to handler unicode
properly. Version 3.3 requires Python 2.6 or later. Since Sage is
already at Python 2.7 is there a good reason why Sage is still
Volker Braun wrote:
On Wednesday, May 6, 2015 at 8:07:08 PM UTC+2, Jeroen Demeyer wrote:
And it just feels like an unneeded restriction that tickets
shouldn't be
changed after positive_review: there is no fundamental reason why
positive_review should be final.
+1
http://trac.sagemath.org/ticket/10295
Looks like no one is interested any more.
On 6 May 2015 at 22:03, Francois Bissey
francois.bis...@canterbury.ac.nz wrote:
Haven’t checked recently but the notebook has been broken each
time someone has tried to update pexpect. There is a pexpect upgrade
Bill Page wrote:
Is there a possibility of creating an experimental package to install
pexpect 3.3 ?
mkdir foo-1.0
echo 'print Installing foo..' foo-1.0/setup.py
tar czf foo-1.0.spkg foo-1.0/
./sage -i foo-1.0.spkg
-leif
I see references to doctests failing but no details. It would be
Just a suggestion:
Try a different make, as you know there are several. I see at the bottom
there is a core dump but no justification. Could be a memory addressing
issue. best wishes.
On 05/04/2015 01:43 AM, William Stein wrote:
Hi,
I'm trying to build Sage-6.6 on the latest Ubuntu 14.10
Clemens Heuberger wrote:
Am 2015-05-07 um 03:42 schrieb leif:
I might be wrong, but isn't it trivial to check whether the branch of a
ticket changed (after you merged it into some preliminary release)?
It is easy to check. But what if it did change? This might lead to an infinite
cycle, as
On 6 May 2015 at 23:28, leif not.rea...@online.de wrote:
Bill Page wrote:
Is there a possibility of creating an experimental package to install
pexpect 3.3 ?
mkdir foo-1.0
echo 'print Installing foo..' foo-1.0/setup.py
tar czf foo-1.0.spkg foo-1.0/
./sage -i foo-1.0.spkg
OK but I was
It is definitely a bug in the dimension method.
could you open a ticket and post the link here?
Am Sonntag, 3. Mai 2015 15:25:13 UTC+2 schrieb mmarco:
It is definitely a bug in the dimension method.
If singular can handle the ring, sage asks singular to compute the
dimension, which
44 matches
Mail list logo
