PS:
On 2012-05-04, Simon King wrote:
> change_warning_output(sys.stdout) is not part of the doc test, but it is
> added by the doctest framework. Hence, I can't comment it out.
sage: search_def("change_warning_output")
sage: search_src("change_warning_output")
sage:
Hence, IF it is the culpr
Hi Julien
On 2012-05-03, Julien Puydt wrote:
>> However, when I give the same commands in an interactive session
>> (without change_warning_output(sys.stdout), since I don't know where
>> to import that from), there is no crash. That's not good for
>> debugging. I could try to control garbage col
Le jeudi 03 mai, Simon King a écrit:
> Hi Martin,
>
> On 2012-05-03, Martin Albrecht wrote:
> >> Anyway. What tools are recommended for tracking the problem down? I
> >> tried valgrind, but when I interrupted the test with Ctrl-c (which
> >> is necessary because it hangs after reporting the doubl
For what it's worth, I'm working on allowing debugging to initiated from
within doctesting. But it's not ready yet.
I'm stuck on the redirection of standard out; I've started another thread
to see if anyone has ideas.
David
On Thu, May 3, 2012 at 3:10 PM, Simon King wrote:
> Hi Martin,
>
> On
I cannot post to sage-devel so am sending this to a couple of other groups.
-- Forwarded message --
From: John Cremona
Date: 3 May 2012 22:47
Subject: Re: [sage-edu] Abelian Groups: comments and suggestions
To: Rob Beezer
Cc: sage-...@googlegroups.com, David Joyner
Don't forg
Hi Martin,
On 2012-05-03, Martin Albrecht wrote:
>> Anyway. What tools are recommended for tracking the problem down? I
>> tried valgrind, but when I interrupted the test with Ctrl-c (which is
>> necessary because it hangs after reporting the double free), there
>> seems to be no output from valg
On Thursday 03 May 2012, Simon King wrote:
> Hi Martin,
>
> On 3 Mai, 16:08, Martin Albrecht
>
> wrote:
> > Can you update to
> >
> > http://trac.sagemath.org/sage_trac/ticket/12840
> >
> > and see if that fixes the issue? It's a bit of a long shot but perhaps
> > worth a try (you'll also hav
Hi Martin,
On 3 Mai, 16:08, Martin Albrecht
wrote:
> Can you update to
>
> http://trac.sagemath.org/sage_trac/ticket/12840
>
> and see if that fixes the issue? It's a bit of a long shot but perhaps worth a
> try (you'll also have to rebuild PolyBoRi)
It does not solve the problem.
Anyway. What
On May 3, 4:47 am, Keshav Kini wrote:
> If such conditions exist (necessitating the calling of the parent
> initializer at the end of the child initializer rather than at the
> beginning) then the parent types are pretty clearly "abstract base
> classes", in OOP terminology -- i.e. classes which c
It seems to me that "doctests" are supposed to serve two purposes.
Since I have not looked at them (well, maybe one or two over the years?),
my comments may be naive or irrelevant, but here goes.
documentation has to be written by the programmer who writes the code,
preferably before the code is
Hi Julien
On 3 Mai, 16:02, Julien Puydt wrote:
> The parent class cannot expect anything if it's initialization code
> hasn't been called, can it?
Apparently both the string representation and the hash *are* available
before calling init:
sage: P_init = Parent(category=Rings())
sage: P_init
The former, PolyBoRi needs to be linked against the new M4RI library. I'd
suggest to do this in a copy of your Sage install, you never know what my
update will cause (although I tested it etc)
On Thursday 03 May 2012, Simon King wrote:
> Hi Martin,
>
> On 3 Mai, 16:08, Martin Albrecht
>
> wro
Hi Martin,
On 3 Mai, 16:08, Martin Albrecht
wrote:
> Can you update to
>
> http://trac.sagemath.org/sage_trac/ticket/12840
>
> and see if that fixes the issue? It's a bit of a long shot but perhaps worth a
> try (you'll also have to rebuild PolyBoRi)
Do I need to do "sage -f polybori-0.8.1.p1.s
Can you update to
http://trac.sagemath.org/sage_trac/ticket/12840
and see if that fixes the issue? It's a bit of a long shot but perhaps worth a
try (you'll also have to rebuild PolyBoRi)
On Thursday 03 May 2012, Simon King wrote:
> Hi!
>
> While finalising #11935 together with Nicolas, I g
Le jeudi 03 mai, Simon King a écrit:
> On the other hand: One could argue that the parent class can
> expect that some basic tools (such as __hash__ and __repr__) already
> work when being called. Hence, before calling __init__ of the parent
> class, one is supposed to make sure that the "tool chai
Hi!
While finalising #11935 together with Nicolas, I get the following
(with a lot of patches applied...):
sage -t --verbose -force_lib "devel/sage/sage/crypto/mq/
mpolynomialsystem.py"
Trying:
set_random_seed(0L)
Expecting nothing
ok
Trying:
change_warning_output(sys.stdout)
Expecting no
On May 3, 9:47 am, Simon King wrote:
> Hi!
>
> On 2012-05-03, kcrisman wrote:
>
> >> sage: finish_doctest()
> >> Please upload /tmp/doctest-some_method.patch to trac.
>
> > Zap! Yes! Just like the fabled "making a patch on the web" idea.
> > Though I suspect you could only easily do the above
Hi!
On 2012-05-03, kcrisman wrote:
>> sage: finish_doctest()
>> Please upload /tmp/doctest-some_method.patch to trac.
>
> Zap! Yes! Just like the fabled "making a patch on the web" idea.
> Though I suspect you could only easily do the above for things with no
> docstring...
It could also appen
On May 3, 2:24 am, Robert Bradshaw
wrote:
> On Sun, Apr 29, 2012 at 3:34 PM, David Kirkby wrote:
> > On 29 April 2012 20:58, Simon King wrote:
>
> >> sage: foobar?
> >> it would be doable that one reads:
> >> Type: function
> >> Base Class:
> >> String Form:
> >> Namesp
On May 3, 4:37 am, Keshav Kini wrote:
> Simon King writes:
> > Hi Jeroen,
>
> > On 2012-05-02, Jeroen Demeyer wrote:
> >> On 2012-05-02 21:18, Stephen Montgomery-Smith wrote:
> >>> Would it be fair to say that the optional packages should be considered
> >>> unreliable?
> >> Indeed. That coul
Simon King writes:
> Hi Keshav,
>
> On 2012-05-03, Keshav Kini wrote:
>> Simon King writes:
>>> No idea. Clearly, unless there is a good reason, the init method of the
>>> base class should be called at some point. But I was not aware of a
>>> convention whether the base init should be called fi
Hi Keshav,
On 2012-05-03, Keshav Kini wrote:
> Simon King writes:
>> No idea. Clearly, unless there is a good reason, the init method of the
>> base class should be called at some point. But I was not aware of a
>> convention whether the base init should be called first or last or
>> whatever. D
Simon King writes:
> Hi Kwankyu,
>
> On 2012-05-03, Kwankyu Lee wrote:
>>> > As the "..Algebra.__init__" is expected to be
>>> > placed at the beginning of the initialization code
>>>
>>> Why? Is that a Python convention?
>>
>>
>> Isn't that a convention of objected-oriented programming?
>
> N
Hi Kwankyu,
On 2012-05-03, Kwankyu Lee wrote:
>> > As the "..Algebra.__init__" is expected to be
>> > placed at the beginning of the initialization code
>>
>> Why? Is that a Python convention?
>
>
> Isn't that a convention of objected-oriented programming?
No idea. Clearly, unless there is a
Simon King writes:
> Hi Jeroen,
>
> On 2012-05-02, Jeroen Demeyer wrote:
>> On 2012-05-02 21:18, Stephen Montgomery-Smith wrote:
>>> Would it be fair to say that the optional packages should be considered
>>> unreliable?
>> Indeed. That could be one of the reasons they are considered "optional".
Hi Simon,
The result is that the hash is broken by default, since the string
> representation can be changed *after* creation of the object, which
> means that the hash value would change as well. There is a ticket fixing
> it, though.
>
> > I think the problem lies in that the hash is calcula
Hi
On 2 May 2012 09:02, Jeroen Demeyer wrote:
> http://boxen.math.washington.edu/home/release/sage-5.0.rc0/sage-5.0.rc0.tar
> Please build, test, and report! We'd love to hear about your
> experiences with this release.
>
make -j3 ptestlong on Ubuntu 12.04:
---
27 matches
Mail list logo
