On Mon, Apr 7, 2008 at 11:35 AM, Anders Logg wrote:
>
> On 7 Apr, 16:47, "Ondrej Certik" wrote:
>> On Mon, Apr 7, 2008 at 4:15 PM, David Joyner wrote:
>>
>> > On Mon, Apr 7, 2008 at 10:08 AM, Ondrej Certik wrote:
>>
>> > > On Mon, Apr 7, 2008 at 3:41 PM, Mike Hansen wrote:
>>
>> > > > On
On 2014-02-06 19:19, Andy Miller wrote:
Thanks!
Can 6.1.1 be upgraded to with sage -upgrade, or would I need to do a
fresh install?
You need a fresh install to upgrade from version 5.x to 6.x
--
You received this message because you are subscribed to the Google Groups
"sage-support" group.
To
Thanks!
Can 6.1.1 be upgraded to with sage -upgrade, or would I need to do a fresh
install?
--Andy
On Wednesday, February 5, 2014 2:18:18 PM UTC-6, John Cremona wrote:
>
> Version 5.0 is very old, try installing 6.1.1. Note that 6.1 was very
> recently released but had a similar issue with la
I tried this example myself and got a similar failure. The error
message is not very informative, but what's happening is that PARI-GP
(which Simon's 2-descent script uses) is raising an error, because the
fundamental units of the number fields coming up in the 2-descent
calculation are too big for
On 2014-02-06 10:17, Tobias Weich wrote:
Hi,
I tried to install sage on a computer of some of our new phd students.
It is a machine running Scientific Linux 6.4.
As Volker said, it's a bug in gfortran. I recommend upgrading your
compiler toolchain or build Sage with SAGE_INSTALL_GCC=yes.
--
Y
Thanks for your Info Jason.
On Wednesday, February 5, 2014 6:02:15 AM UTC-8, Jason Grout wrote:
>
> On 1/31/14 4:00 PM, y tan wrote:
> > One more problem remaining. Sage notebook doesnt show sage plot. R plot
> > showing fine now.
>
> If I recall correctly, the Sage Cell Server patches to sag
On Thursday, February 6, 2014 8:36:08 AM UTC-5, Bruno wrote:
>
> Dear Sage-support,
>
> I'm trying reproduce a function,namely uq, of the variable t which I know
> that exist but don't know the symbolic expression of it. I can determine
> the expression by a system of 3 equations (eq0,eq1,eq2)
Fix is at http://trac.sagemath.org/ticket/15791, needs review.
On Thursday, February 6, 2014 1:50:55 PM UTC, Volker Braun wrote:
>
> The problem is that Solaris sed is always broken in innovative new ways
> and doesn't understand character classes.
>
> It seems that in Norwegian, "aa" is matche
The problem is that Solaris sed is always broken in innovative new ways and
doesn't understand character classes.
It seems that in Norwegian, "aa" is matched like a special character (one
of the weird a's, I guess) and therefore is not in the [a-z] range:
$ export LC_COLLATE=nn_NO.utf8
$ echo a
Dear Sage-support,
I'm trying reproduce a function,namely uq, of the variable t which I know
that exist but don't know the symbolic expression of it. I can determine
the expression by a system of 3 equations (eq0,eq1,eq2) and 4 variables
(p0,p1,t,uq) ,as it follows
var('p0 p1 uq q t')
q=0.8
On Thu, Feb 6, 2014 at 2:22 PM, Vegard Lima wrote:
> On Thu, Feb 6, 2014 at 2:07 PM, Volker Braun wrote:
>> This works for me on Fedora 20. Something must be wrong with your sed. What
>> do you get for
...
>> $ echo 5b5e732cd1eaa01bcfa2b47903ce6ea041a0fae3 | sed 's/[^0-9a-f].*//'
>> 5b5e732cd1eaa
On Thu, Feb 6, 2014 at 2:07 PM, Volker Braun wrote:
> This works for me on Fedora 20. Something must be wrong with your sed. What
> do you get for
>
> $ rpm -qf `which sed`
> sed-4.2.2-5.fc20.x86_64
> $ rpm -V sed
> $ echo 5b5e732cd1eaa01bcfa2b47903ce6ea041a0fae3 | sed 's/[^0-9a-f].*//'
> 5b5e732c
This works for me on Fedora 20. Something must be wrong with your sed. What
do you get for
$ rpm -qf `which sed`
sed-4.2.2-5.fc20.x86_64
$ rpm -V sed
$ echo 5b5e732cd1eaa01bcfa2b47903ce6ea041a0fae3 | sed 's/[^0-9a-f].*//'
5b5e732cd1eaa01bcfa2b47903ce6ea041a0fae3
On Thursday, February 6, 2014
Hi,
I don't know if this is known but I get this error while
building sage 6.1.1 from source on fedora 20:
Found local sources at /sage-6.1.1/upstream/iconv-1.14.tar.bz2
Checksum: 5b5e732cd1eaa01bcfa2b47903ce6ea041a0fae3 vs 5b5e732cd1e
Invalid checksum for /sage-6.1.1/upstream/iconv-1.14.tar.bz2
Nice, gfortran ICE.
As a workaround, build with
SAGE_INSTALL_GCC=yes make
compile options:
'-I/app/home/stormrw/programms/sage/local/lib/python2.7/site-packages/numpy/core/include
-c'
gfortran:f77: scipy/special/specfun/specfun.f
scipy/special/specfun/specfun.f:2507: internal compiler error
On 2014-02-06 08:58, Jori Mantysalo wrote:
and remember this part: "Also, every user in the server pool must share
the same /tmp directory right now - -"
Or apply the patch from
http://trac.sagemath.org/ticket/11679
and you can change that directory.
--
You received this message because you are
16 matches
Mail list logo