On Nov 7, 2007 11:02 AM, Kate Minola <[EMAIL PROTECTED]> wrote:
> I go away for a while, and now SAGE does not build
> on any of my machines of interest:
>
> Compiling from source using gcc-4.2.2, I get
>
> ***
> x86-Linux, ia64-Linux
> ***
> While compiling cvxopt-0.8.2.p4, I get
>
> gcc -pthread
I go away for a while, and now SAGE does not build
on any of my machines of interest:
Compiling from source using gcc-4.2.2, I get
***
x86-Linux, ia64-Linux
***
While compiling cvxopt-0.8.2.p4, I get
gcc -pthread -shared build/temp.linux-i686-2.5/C/base.o
build/temp.linux-i686-2.5/C/dense.o
bui
On Nov 7, 5:33 pm, "John Cremona" <[EMAIL PROTECTED]> wrote:
Hello John,
> Isn't there a problem with this:
>
> "the latter for resources used by those of its
> children that have terminated and have been waited for."
Yep, that is indeed a problem.
>
> We want to add up the time us
On Nov 7, 5:29 pm, Simon King <[EMAIL PROTECTED]> wrote:
> Dear Michael,
>
> On Nov 7, 4:22 pm, mabshoff <[EMAIL PROTECTED]> wrote:
Hi Simon,
>
>
>
> > > This is indeed non-trivial! Even when i compute maxideal(19), which
> > > takes a couple of seconds, singular.cputime(t) only returns 0.001
Isn't there a problem with this:
"the latter for resources used by those of its
children that have terminated and have been waited for."
We want to add up the time used by child processes *which are still
running*. For example, if sage needs to use maxima (say) it checks to
see if max
Yes, it is a bug and the fix is at
http://trac.sagemath.org/sage_trac/ticket/1122
Martin
On Wednesday 07 November 2007, William Stein wrote:
> Here's a support request from Jim Carlson:
>
>
> -- Forwarded message --
> From: James Carlson <[EMAIL PROTECTED]>
> Date: Nov 7, 200
Dear Michael,
On Nov 7, 4:22 pm, mabshoff <[EMAIL PROTECTED]
dortmund.de> wrote:
> > This is indeed non-trivial! Even when i compute maxideal(19), which
> > takes a couple of seconds, singular.cputime(t) only returns 0.001. I
> > doubt that this is the correct time.
>
> If you can reproduce this
On Nov 7, 2007 7:22 AM, mabshoff
<[EMAIL PROTECTED]> wrote:
>
>
>
> On Nov 7, 4:17 pm, Simon King <[EMAIL PROTECTED]> wrote:
> > Dear Martin,
> >
>
> Hello Simon,
>
> > > Actually, for Singular it is trivial:
> >
> > > sage: R=singular.ring(0,'(x(1..10))','dp')
> > > sage: t= singular.cputime()
>
Here's a support request from Jim Carlson:
-- Forwarded message --
From: James Carlson <[EMAIL PROTECTED]>
Date: Nov 7, 2007 7:03 AM
Subject: Bug?
To: William Stein <[EMAIL PROTECTED]>
Hi William,
Attached is a file with odd behavior.
p = a prime
n = a postive
On Nov 7, 4:17 pm, Simon King <[EMAIL PROTECTED]> wrote:
> Dear Martin,
>
Hello Simon,
> > Actually, for Singular it is trivial:
>
> > sage: R=singular.ring(0,'(x(1..10))','dp')
> > sage: t= singular.cputime()
> > sage: singular.eval('ideal G = maxideal(14)')
> > sage: singular.cputime(t)
>
>
Dear Martin,
> Actually, for Singular it is trivial:
>
> sage: R=singular.ring(0,'(x(1..10))','dp')
> sage: t= singular.cputime()
> sage: singular.eval('ideal G = maxideal(14)')
> sage: singular.cputime(t)
This is indeed non-trivial! Even when i compute maxideal(19), which
takes a couple of seco
On Nov 7, 5:08 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Nov 7, 2007 4:34 AM, John Cremona <[EMAIL PROTECTED]> wrote:
>
> > It is true that the cpu time does not include any of the child
> > processes, and also that in many cases most of the computation is done
> > by those.
>
> > In t
On Wednesday 07 November 2007, Simon King wrote:
> John,
>
> > Many people agree with you that it would be more useful to have the
> > aggregate time.
> So do i.
I made this trac ticket #1118
http://trac.sagemath.org/sage_trac/ticket/1118
> In the meantime, it would be ok for me to determine th
Dear Paul,
I'm not sure I have the hang of these google groups yet. I answered
your posting, and some others have posted replies, but you may not
have seen any of that! The thread is here:
http://groups.google.com/group/sage-support/browse_thread/thread/98e3a6ca615019a3
which I think you can
John,
> Many people agree with you that it would be more useful to have the
> aggregate time.
So do i.
In the meantime, it would be ok for me to determine the cpu time of,
say, a Singular child process via the Singular timer. But apparently
this is non-trivial, according to this example:
sage:
On Nov 7, 2007 4:34 AM, John Cremona <[EMAIL PROTECTED]> wrote:
> It is true that the cpu time does not include any of the child
> processes, and also that in many cases most of the computation is done
> by those.
>
> In this case the cardinality is either computed via a call to the
> libpari func
Paul,
It is true that the cpu time does not include any of the child
processes, and also that in many cases most of the computation is done
by those.
In this case the cardinality is either computed via a call to the
libpari function ellap, or by running gp and calling the sea
implementation ther
Hi,
it seems the cpu time reported by SAGE does not include that of the spawned
processes (sorry for using an old release :-)
mermoz% sage
--
| SAGE Version 2.8.10, Release Date: 2007-10-28 |
| Type n
Dear William,
you wrote:
> You can accomplish the same thing as follows, by simply changing the
> ._name attribute (and being sure to kill the sage5 _name that is
> generated, to avoid a memory leak):
Thank you! I didn't know that the name attribute is called '_name',
and i thought that setting
As an alternative, which would give you much more than just pari/gp,
you could install Sage (www.sagemath.org) which is fully supported on
the mac, and then you will have pari/gp. Sage will install everythng
it needs.
John Cremona
CC'd ro sage-support
On 06/11/2007, Louis Granboulan <[EMAIL PR
20 matches
Mail list logo
