I think Keshav ran into the same problem and it was because vbox wasn't
reporting the correct cpu parameters or something like that.
On Friday, May 18, 2012 1:00:54 PM UTC+8, William wrote:
>
> Hi,
>
> I know something like this has been reported, but I can't figure out
> where. I am using Ub
Hi Luis,
On 18 Mai, 00:45, Luis Finotti wrote:
> The problem is that it seems that it creates a loop, as in
> witt_element.py I need witt.py and vice-versa. That's why at the
> bottom of witt_element I had
>
> class RingOfWittVectors(RingOfWittVectors):
> # def _call_(self,data,parent,coerce
On Thu, May 17, 2012 at 10:08 PM, Jason Grout
wrote:
> I upgraded the Sage servers to 5.0, and it seems that there is some sort of
> really bad scalability problem that I'm only seeing on sagenb.org (or more
> likely, is only noticeable on a server the size of sagenb.org). Some of you
> may have n
I upgraded the Sage servers to 5.0, and it seems that there is some sort
of really bad scalability problem that I'm only seeing on sagenb.org (or
more likely, is only noticeable on a server the size of sagenb.org).
Some of you may have noticed that sagenb.org has been unbearably slow
the last f
Hi,
I know something like this has been reported, but I can't figure out
where. I am using Ubuntu 12.04 in Virtualbox on my Mac, and I can't
build Sage because of MPIR. Which ticket? What's the workaround?
This will probably impact me a lot, since I use virtual machines quite
a bit...
libtool
You have a circular import error. One way to solve it is to import
RingOfWittVectors inside the __init__ method of WittVector rather than at
the top level of the module.
David
On Thu, May 17, 2012 at 3:45 PM, Luis Finotti wrote:
> Dear Simon,
>
> Firstly, thank you for your help.
>
> On Thu, May
On 05/17/2012 11:24 AM, Jeroen Demeyer wrote:
As noted on sage-support, the sage-5.0 *binary* requires the boost
library libboost_unit_test_framework at runtime, if the binary was built
on such a machine. I.e. PolyBoRi checks for boost_unit_test_framework
and links against it if available.
This
Dear Simon,
Firstly, thank you for your help.
On Thu, May 17, 2012 at 5:50 PM, Simon King wrote:
> So, I guess it would suffice if you started the class definition in
> witt.py by
>
> from witt_element import WittVector
> class RingOfWittVectors(CommutativeRing):
>Element = WittVector
>
On Thu, May 17, 2012 at 3:18 AM, Keshav Kini wrote:
> Julien Puydt writes:
>> It would definitely help if more sage developers knew how things are
>> done in debian, fedora or gentoo -- the mail Harald Schilly sent
>> yesterday and the citation therein are spot on there.
>
> Knowing how things ar
> No, that's wrong. In that way, you would make it impossible to merge the
> methods defined in the category framework into the element class. It
> should be
>Element = WittVector
> and then element_class would be automagically created.
>
You're right.
David
--
To post to this group, send an
Hi David,
On 2012-05-17, David Roe wrote:
> --f46d04374501cea75604c042359d
> * You need to define the element class in the parent. So for example,
>
> class RingOfWittVectors(CommutativeRing):
> element_class = WittVector
No, that's wrong. In that way, you would make it impossible to merge
Hi Luis,
On 2012-05-17, Luis Finotti wrote:
> I cannot create an element as below:
> sage:
> R=RingOfWittVectors(GF(5),3)
> sage:
> F=GF(5)
> sage:
> w=[F(1),F(2),F(0)]
Here are a couple problems with those files, though I'm not getting exactly
the same problems you observe.
* You need to define the element class in the parent. So for example,
class RingOfWittVectors(CommutativeRing):
element_class = WittVector
def __init__(self, base, n, p=None, catego
Let me also add that there is a good reason for separating the
build-time dependencies: it allows the Sage library to be built in
parallel with other packages.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsub
Le jeudi 17 mai, Jeroen Demeyer a écrit:
> On 2012-05-17 21:03, Julien Puydt wrote:
> > For $(INST)/$(ELLIPTIC_CURVES), shouldn't it be in the list of
> > things $(INST)/$(SAGE) *build* depends on?
> > After all, if it isn't supposed to
> > run without it, can one consider the target successfully b
Dear all,
I've been working on this, following Simon King's worksheet (at
http://flask.sagenb.org/home/pub/82) closely, but am stuck. The files
I am using (witt.py and witt_element.py), based on Roe and Dupuy
previous work, are attached for your reference.
I cannot create an element as below:
On 2012-05-17 21:03, Julien Puydt wrote:
> For $(INST)/$(ELLIPTIC_CURVES), shouldn't it be in the list of things
> $(INST)/$(SAGE) *build* depends on?
> After all, if it isn't supposed to
> run without it, can one consider the target successfully built?
This is just a matter of definition. The tar
Le jeudi 17 mai, Jeroen Demeyer a écrit:
> On 2012-05-17 18:32, Julien Puydt wrote:
> > I was strolling in spkg/standards/deps, when I saw that $(ECLIB)
> > and $(ELLIPTIC_CURVES) are built because they appear in the 'all'
> > target, but that nothing depends on them.
> >
> > Surely there are sile
On 2012-05-17 18:32, Julien Puydt wrote:
> I was strolling in spkg/standards/deps, when I saw that $(ECLIB)
> and $(ELLIPTIC_CURVES) are built because they appear in the 'all'
> target, but that nothing depends on them.
>
> Surely there are silent dependencies?
I don't know what you mean with "sil
kcrisman writes:
> Do you like supporting people's use of Sage? Did you know there is a
> sage tag on stackoverflow.com? You didn't? Neither did I - but there
> is actually a fair stream of questions!
>
> Simon K. and Doug M. have been doing great work there, but there are
> definitely unanswe
As far as I know, parts of the Sage library depend on these, but no other spkgs.
John
On 17 May 2012 17:32, Julien Puydt wrote:
> Hi,
>
> I was strolling in spkg/standards/deps, when I saw that $(ECLIB)
> and $(ELLIPTIC_CURVES) are built because they appear in the 'all'
> target, but that nothin
Hi,
I was strolling in spkg/standards/deps, when I saw that $(ECLIB)
and $(ELLIPTIC_CURVES) are built because they appear in the 'all'
target, but that nothing depends on them.
Surely there are silent dependencies?
Snark on #sagemath
--
To post to this group, send an email to sage-devel@google
Do you like supporting people's use of Sage? Did you know there is a
sage tag on stackoverflow.com? You didn't? Neither did I - but there
is actually a fair stream of questions!
Simon K. and Doug M. have been doing great work there, but there are
definitely unanswered questions. You can help!
As noted on sage-support, the sage-5.0 *binary* requires the boost
library libboost_unit_test_framework at runtime, if the binary was built
on such a machine. I.e. PolyBoRi checks for boost_unit_test_framework
and links against it if available.
This is because of the PolyBoRi upgrade to version 0
Julien Puydt writes:
> Le jeudi 17 mai, Keshav Kini a écrit:
>> Julien Puydt writes:
>> > Le jeudi 17 mai, Keshav Kini a écrit:
>> >> Julien Puydt writes:
>> >> > It would definitely help if more sage developers knew how things
>> >> > are done in debian, fedora or gentoo -- the mail Harald Schi
Le jeudi 17 mai, Keshav Kini a écrit:
> Julien Puydt writes:
> > Le jeudi 17 mai, Keshav Kini a écrit:
> >> Julien Puydt writes:
> >> > It would definitely help if more sage developers knew how things
> >> > are done in debian, fedora or gentoo -- the mail Harald Schilly
> >> > sent yesterday and
Julien Puydt writes:
> Le jeudi 17 mai, Keshav Kini a écrit:
>> Julien Puydt writes:
>> > It would definitely help if more sage developers knew how things are
>> > done in debian, fedora or gentoo -- the mail Harald Schilly sent
>> > yesterday and the citation therein are spot on there.
>>
>> Kn
Le jeudi 17 mai, Keshav Kini a écrit:
> Julien Puydt writes:
> > It would definitely help if more sage developers knew how things are
> > done in debian, fedora or gentoo -- the mail Harald Schilly sent
> > yesterday and the citation therein are spot on there.
>
> Knowing how things are done in G
... and the story continues a bit. basically, the same issue happened for
an installed ipython 0.13dev inside my
~/.local/lib/python/site-packages/... directory.
$ cat start.log
[2012-05-17 12:48:55] Sage version 5.0, released 2012-05-14
Traceback (most recent call last):
File "/home/opt/sage
Julien Puydt writes:
> It would definitely help if more sage developers knew how things are
> done in debian, fedora or gentoo -- the mail Harald Schilly sent
> yesterday and the citation therein are spot on there.
Knowing how things are done in Gentoo is probably the most useful of
these since G
Le jeudi 17 mai, Robert Bradshaw a écrit:
> On Wed, May 16, 2012 at 11:34 PM, Julien Puydt
> wrote:
> > Le mercredi 16 mai, Robert Bradshaw a écrit:
> >> I don't like spkg.txt because it's just a (under-specified)
> >> convention of what to put there when you make manual changes.
> >> Better would
On Wed, May 16, 2012 at 11:34 PM, Julien Puydt wrote:
> Le mercredi 16 mai, Robert Bradshaw a écrit:
>> I don't like spkg.txt because it's just a (under-specified) convention
>> of what to put there when you make manual changes. Better would be to
>> have some specification file (json?) like
>>
>>
32 matches
Mail list logo
