Hello Bill,
ZmodF_mul-test segfaulted for me on an Opteron/Linux box. Valgrind
says:
Testing ZmodF_mul_info_mul_fft()... ==19149== Invalid read of size 8
==19149==at 0x453155: ZmodF_poly_pointwise_mul (in /tmp/Work2/
sage-2.8.2/spkg/build/flint-0.1/src/ZmodF_mul-test)
==19149==by
Hello Michael,
knowing very little about your setup I can only give you a shot in the
dark: any chance you are compiling without -fPIC and/or -fpic? From my
experience this might also point to linker/binutils issues. Maybe you
should try the whole build with GNU binutils.
We tried out both
Hi,
The newest tarball posted here builds on a bunch of test machines:
http://sage.math.washington.edu/home/was/dist/s/dist/
It has numerous doctest failures. All that remains to release SAGE-2.8.3 is
to fix all those doctest failures.
I won't work on this again until late tomorrow
On Aug 28, 9:50 pm, William Stein [EMAIL PROTECTED] wrote:
On 8/28/07, Iftikhar Burhanuddin [EMAIL PROTECTED] wrote:
Dear William,
On Sun, 19 Aug 2007, William Stein wrote:
On 8/19/07, Iftikhar Burhanuddin [EMAIL PROTECTED] wrote:
There was a huge bug-squashing day today with
On Aug 29, 1:19 pm, mabshoff [EMAIL PROTECTED]
dortmund.de wrote:
On Aug 28, 9:50 pm, William Stein [EMAIL PROTECTED] wrote:
SNIP
William did suggest a fix but he either didn't code it up and merge it
or it somehow got lost. We should open an individual ticket for that
one because it
On Wednesday 29 August 2007, mabshoff wrote:
On Aug 29, 1:19 pm, mabshoff [EMAIL PROTECTED]
dortmund.de wrote:
On Aug 28, 9:50 pm, William Stein [EMAIL PROTECTED] wrote:
SNIP
William did suggest a fix but he either didn't code it up and merge it
or it somehow got lost. We should open
SNIP
Hello Martin,
Your patch seems 'free' memory allocated with 'new'. So either we
should 'm/calloc' the buffer or 'delete' it.
I did ask Wiliam the same thing (I would have used delete), but the
ntl wrapper is still C, so the calloc option might be the better one
in the short term. Feel
On Wed, 29 Aug 2007 01:54:08 -0700
William Stein [EMAIL PROTECTED] wrote:
The newest tarball posted here builds on a bunch of test machines:
http://sage.math.washington.edu/home/was/dist/s/dist/
It has numerous doctest failures. All that remains to release
SAGE-2.8.3 is to fix all
On Wed, 29 Aug 2007 01:54:08 -0700
William Stein [EMAIL PROTECTED] wrote:
snip
It has numerous doctest failures. All that remains to release
SAGE-2.8.3 is to fix all those doctest failures.
snip
The tests in the files
combinat/combinat.py
groups/perm_gps/permgroup_element.py
On Wednesday 29 August 2007 07:19, mabshoff wrote:
==22784== 791,674 bytes in 65,421 blocks are definitely lost in loss
record 2,472 of 2,481
==22784==at 0x4A05CB9: operator new[](unsigned long)
(vg_replace_malloc.c:199)
==22784==by 0x9280247: ZZ_pX_repr (in
Another gap problem: the patch
http://sage.math.washington.edu/home/wdj/patches/gap-4.4.9.p1.spkg
has the latest version of guava (guava 3.0, incorporating work
of Robert Miller and Tom Boothby). It has not been applied.
I'll see if a trac ticket can be created for this.
On 8/29/07, William
On Aug 29, 4:22 pm, Joel B. Mohler [EMAIL PROTECTED] wrote:
On Wednesday 29 August 2007 07:19, mabshoff wrote:
==22784== 791,674 bytes in 65,421 blocks are definitely lost in loss
record 2,472 of 2,481
==22784==at 0x4A05CB9: operator new[](unsigned long)
(vg_replace_malloc.c:199)
On Aug 29, 4:22 pm, Joel B. Mohler [EMAIL PROTECTED] wrote:
On Wednesday 29 August 2007 07:19, mabshoff wrote:
==22784== 791,674 bytes in 65,421 blocks are definitely lost in loss
record 2,472 of 2,481
==22784==at 0x4A05CB9: operator new[](unsigned long)
(vg_replace_malloc.c:199)
On Wednesday 29 August 2007 08:27, mabshoff wrote:
William also stated that there is a bug need to rewrite the ntl
wrapper in C++ from scratch and those memleaks could give the needed
push to get the rewrite started.
Yes, I'm well started and waiting (forever) for things to get integrated.
On Aug 29, 2007, at 10:22 AM, Joel B. Mohler wrote:
On Wednesday 29 August 2007 07:19, mabshoff wrote:
==22784== 791,674 bytes in 65,421 blocks are definitely lost in loss
record 2,472 of 2,481
==22784==at 0x4A05CB9: operator new[](unsigned long)
(vg_replace_malloc.c:199)
==22784==
On Wednesday 29 August 2007, William Stein wrote:
On 8/29/07, Martin Albrecht [EMAIL PROTECTED] wrote:
It seems that none of those is a memleak because they all operate on a
Python objects only which should be taken care of py Cython.
What does this sentence refer to? The ntl wrapper
On 8/29/07, Pablo De Napoli [EMAIL PROTECTED] wrote:
Thanks.
Isn't there security issues by using a weak password?
I've looked for a place in the track system to change it, but I could
not find it.
Short answer: If you can figure out how to actually setup trac to use a much
more
On Wednesday 29 August 2007 12:11, William Stein wrote:
On 8/29/07, Martin Albrecht [EMAIL PROTECTED] wrote:
It seems that none of those is a memleak because they all operate on a
Python objects only which should be taken care of py Cython.
What does this sentence refer to? The ntl
This is on a suse 10.2 amd64. Build works fine and command line seems
to work okay but the notebook crashes:
sage: notebook()
Please choose a new password for the SAGE Notebook 'admin' user.
Do _not_ choose a stupid password, since anybody who could guess your password
and connect to your
David, Thanks for testing that. I might have missed it if you hadn't
done so. Thanks.
I know what's wrong and am fixing it now.
You can try the notebook further by doing
./sage -inotebook
to run in insecure mode.
I just put your new gap package into sage-2.8.3 and closed that ticket.
hi
make -j (i.e. multi-core make) doesn't currently work for sage, it
seems to get a few dependencies screwed up, although william
mentioned there was some decent way to at least get make -j working
for many individual packages.
Would it be difficult to make this available easily via just
Hi,
(1) The release candidate I posted doesn't build because spkg-dist doesn't
get c_lib, as it isn't listed in the MANIFEST.in file. I can't attempt to fix
this until tomorrow, since my home network connection is so flaky.
(2) On 8/29/07, David Harvey [EMAIL PROTECTED] wrote:
make -j (i.e.
On Aug 30, 2007, at 12:21 AM, William Stein wrote:
(2) On 8/29/07, David Harvey [EMAIL PROTECTED] wrote:
make -j (i.e. multi-core make) doesn't currently work for sage, it
seems to get a few dependencies screwed up, although william
mentioned there was some decent way to at least get make
23 matches
Mail list logo