Does Sage promise compatibility of worksheets in all of
its future versions?
--
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.c
I couldn't find the code, but I guess that the error here is not occurring
due to an isinstance call; apparently that is discouraged and is not common
in the standard library: http://www.canonical.org/~kragen/isinstance/
On Wednesday, 15 May 2013 16:39:57 UTC-7, Keshav Kini wrote:
>
> Volker Bra
Volker Braun writes:
> Anything that does isinstance(i,int) in the Python standard library
> is broken. Usually thats when multiple input types are allowed. In
> this case the argument to match.group() could be a string if you use
> the ?P syntax to name the match group.
Yup. For example the sim
On 12 May 2013 14:27, Jean-Pierre Flori wrote:
> Dear all,
>
> I've put binaries of Sage 5.9 for Solaris (10)/sparc and Cygwin at:
> * http://boxen.math.washington.edu/home/jpflori/dist/
Can you please change the permission on the Solaris file. Currently it
is read/write to the owner only, with n
Seems like a reasonable first approximation would be to strip ALL
javascript from the worksheet archive.
--
Benjamin Jones
benjaminfjo...@gmail.com
On Wed, May 15, 2013 at 7:05 AM, Volker Braun wrote:
> Somebody needs to volunteer to strip out the malicious javascript from the
> archive of old
Harald, please copy gcc-4.6.3 to the list of *optional* packages. You
can find a version of this spkg at:
http://boxen.math.washington.edu/home/release/sage-5.8/sage-5.8/spkg/standard/gcc-4.6.3.spkg
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group
Jean-Pierre Flori wrote:
Dear all,
I thought the GCC 4.6.3 was supposed to be kept as an optional spkg, but
it seems only the 4.7.2 is kept whereas it is what Sage's currently
ships now (and 4.7.3 in the next version).
That's unfortunate because I have trouvble building 4.7.2 on
debian/sparc64 (
Dear all,
I thought the GCC 4.6.3 was supposed to be kept as an optional spkg, but it
seems only the 4.7.2 is kept whereas it is what Sage's currently ships now
(and 4.7.3 in the next version).
That's unfortunate because I have trouvble building 4.7.2 on debian/sparc64
(but i've put a 4.6.4 spk
On May 15, 8:58 am, Nils Bruin wrote:
> sage: zeta.simplify_radical()
> -1
Sorry, that was supposed to be
sage: (zeta^3).simplify_radical()
-1
my apologies.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and sto
On May 15, 3:25 am, man...@gmx.net wrote:
> It does not work because "abs( )" returns an "Expression" which
> will cause find_local_minimum to cause errors.
The problem here is that 1.0+I*1.0 is a symbolic expression rather
than a complex number (which one would you want? python complex? CDF?
some
Somebody needs to volunteer to strip out the malicious javascript from the
archive of old worksheets, then we can host it...
On Wednesday, May 15, 2013 2:31:28 PM UTC+1, leif wrote:
>
> It would probably at least be possible to freeze (by making them
> read-only) some selected, (already publish
Nathann Cohen wrote:
Hell everybody !!!
Two hours ago I met a nice guy, who among many qualities had used Sage
in a research paper. While he agreed without being threatened that it
was a nice software, he still had a minor complaint :
In one of his papers [1] he provided the address of
Hell everybody !!!
Two hours ago I met a nice guy, who among many qualities had used Sage in a
research paper. While he agreed without being threatened that it was a nice
software, he still had a minor complaint :
In one of his papers [1] he provided the address of a worksheet from sagenb
vdelecroix wrote:
In [1], I mention that sage-clone does recompile Cython files. But the
operation sage-clone still takes a lot of time because of
documentation regeneration. Is there a way to avoid this documentation
regeneration ?
You might like http://trac.sagemath.org/sage_trac/ticket/13245
>> For the impatient, the following at least avoids rebuilding of (most of
>> the) Cython-generated files:
Thanks leif, it works quite well on sage-5.9. Do you have an idea for
avoiding documentation regeneration (see [1]) ?
Best,
Vincent
[1]
http://groups.google.com/group/sage-devel/browse_t
Hi,
In [1], I mention that sage-clone does recompile Cython files. But the
operation sage-clone still takes a lot of time because of
documentation regeneration. Is there a way to avoid this documentation
regeneration ?
Best,
Vincent
[1]
http://groups.google.com/group/sage-devel/browse_thread/
On 2013-05-15, Simon King wrote:
> Hi Nils,
>
> On 2013-05-15, Simon King wrote:
>> Did you open a ticket for cythoning sage.misc.lazy_format and
>> sage.misc.lazy_string (and perhaps make them *one* thing)?
>
> Since I didn't find a ticket by searching trac, I created a new one: See
> #14585.
I
I think you shouldn't blame it all on the user. I understand and
appreciate that Sage makes a clear distinction between different types
and handles them differently. But that doesn't explain the numerous
errors which are caused by SAGE's funtions which should work with a
specific type, but simply r
Hi William,
I tried to fix the bug and provided a patch at
http://trac.sagemath.org/sage_trac/attachment/ticket/14587/
However, I cannot test it as the M2 experimental package won't build (on my
machine).
On Tuesday 14 May 2013, William Stein wrote:
> Hi,
>
> I actually tried to use somet
Hi Nils,
On 2013-05-15, Simon King wrote:
> Did you open a ticket for cythoning sage.misc.lazy_format and
> sage.misc.lazy_string (and perhaps make them *one* thing)?
Since I didn't find a ticket by searching trac, I created a new one: See
#14585.
Best regards,
Simon
--
You received this mess
Hi Nils,
On 2013-05-14, Nils Bruin wrote:
> Cool. Doesn't the coercion framework end up trying all kinds of things
> that may generate errors which get caught? Aren't those also different
> errors that AttributeError? Shouldn't we be using a similar approach?
>
> def LazyError(Error):
> ...
It w
21 matches
Mail list logo
