On Feb 24, 9:25 pm, "Georg S. Weber"
wrote:
> Hi Michael,
Hi Georg,
> this got me a bit high-spirited
:)
>, so I assembled another singular.spkg
> with some bigger cleanups w.r.t memory allocator usage. I did a
> complete build with this spkg dropped into Sage 3.3 instead of the
> original
Hi Michael,
this got me a bit high-spirited, so I assembled another singular.spkg
with some bigger cleanups w.r.t memory allocator usage. I did a
complete build with this spkg dropped into Sage 3.3 instead of the
original spkg on my OS X 32bit box, and the build and subsequent
"testlong" runs jus
On Feb 24, 12:10 am, "Georg S. Weber"
wrote:
> On 23 Feb., 18:53, mabshoff wrote:
Hi Gerog,
> Hi Michael,
>
> I could not put that much effort into it yesterday evening, but one
> overnight complete build & testlong of Sage 3.3 with a
> "singular...p3a.spkg" dropped in instead of the origina
On 23 Feb., 18:53, mabshoff wrote:
> On Feb 23, 4:42 am, mabshoff wrote:
>
> > Hi Georg,
>
> > here is the result of Sage 3.3 + your spkg patch for 64 bit. This is
> > compiled using --with-malloc=system:
>
> Ok, it turns out the failures I listed here are caused by oMalloc, but
> they are not
On Mon, Feb 23, 2009 at 9:53 AM, mabshoff wrote:
> The remaining issues for the 64 bit OSX build certainly seem rather
> strange failures and are deep inside oMalloc, so the whole commentary
> about the minpoly issue is likely a wrong lead. The strange thing is
> also that I can reproducibly segf
On Feb 23, 4:42 am, mabshoff wrote:
> Hi Georg,
>
> here is the result of Sage 3.3 + your spkg patch for 64 bit. This is
> compiled using --with-malloc=system:
Ok, it turns out the failures I listed here are caused by oMalloc, but
they are not caused by Georg's patch. They are also identical
r
Hi Georg,
here is the result of Sage 3.3 + your spkg patch for 64 bit. This is
compiled using --with-malloc=system:
sage -t devel/sage/sage/calculus/calculus.py # 0 doctests failed
sage -t devel/sage/sage/crypto/mq/sr.py # Segfault
sage -t devel/sage/sage/groups/generi
On Feb 23, 12:44 am, "Georg S. Weber"
wrote:
> On 23 Feb., 08:10, mabshoff wrote:
Hi Georg,
>
> We definitely *are* closing in on this devious bunch of bugs. I had
> touched four Cython files (the ones noted in that other recent
> Singular thread) and then did "sage -b" quite many times the
On 23 Feb., 08:10, mabshoff wrote:
> On Feb 22, 10:01 pm, "Georg S. Weber"
> wrote:
>
> > C'mon,
>
> Hi Georg,
>
> > this does need a very thorough doctesting on as many architectures as
> > possible! My own overnight run with Sage 3.3 with additionally #5344
> > and #4181 applied has finished
Actually, from my perspective overloading malloc is a constant source
of pain.
This makes developers fighting malloc implementation, instead of
writing algorithms.
I would prefer Singular not doing so and I hope, that Sage doesn't
follow our bad example.
I think, the problem omalloc solves would
On Feb 22, 10:01 pm, "Georg S. Weber"
wrote:
> C'mon,
Hi Georg,
> this does need a very thorough doctesting on as many architectures as
> possible! My own overnight run with Sage 3.3 with additionally #5344
> and #4181 applied has finished:
> {{{
>
C'mon,
this does need a very thorough doctesting on as many architectures as
possible! My own overnight run with Sage 3.3 with additionally #5344
and #4181 applied has finished:
{{{
--
All tests passed!
Total time for all tests:
On Feb 22, 2:34 pm, mabshoff wrote:
> On Feb 22, 2:19 pm, "Georg S. Weber"
> wrote:
>
> > Hi sage-devel,
>
> Hi,
>
>
>
> > currently Sage uses, if possible, the system's malloc.
> > This has a big advantage --- that strategy certainly is the one
> > supporting portability of Sage best.
>
> > I
On Feb 22, 2:19 pm, "Georg S. Weber"
wrote:
> Hi sage-devel,
Hi,
> currently Sage uses, if possible, the system's malloc.
> This has a big advantage --- that strategy certainly is the one
> supporting portability of Sage best.
>
> I don't know if there is a timeline already for the use of cus
14 matches
Mail list logo
