On Apr 22, 10:18 am, Robert Gerbicz wrote:
> 2009/4/22 Cactus
Hi Robert,
> > Would you be willing to release it under a license that would allow
> > MPIR to incorporate it?
>
> > Thank you for your interest, which is much appreciated.
>
> > Brian Gladman
>
> OK, I've changed the license,
On Apr 21, 5:25 pm, Jeff Gilchrist wrote:
> On Tue, Apr 21, 2009 at 6:30 PM, Bill Hart
> wrote:
> > I've put release candidate 1 for MPIR 1.1.1 up on the website.
>
> Houston we have a problem (you guys must really love me by now)...
Well, as long as you are finding bugs I don't see any prob
On Apr 21, 3:29 pm, mabshoff wrote:
> On Apr 21, 1:12 pm, Jason Moxham wrote:
>
> > All the machines on skynet that have compilers installed are OK
>
> > We are set to go :)
>
> I reported the problem on menas to Mariah yesterday and I got an email
> earlie
On Apr 21, 1:12 pm, Jason Moxham wrote:
> All the machines on skynet that have compilers installed are OK
>
> We are set to go :)
I reported the problem on menas to Mariah yesterday and I got an email
earlier today that it was fixed. The problem was that binutils 2.19-1
did no longer function
On Apr 17, 10:49 pm, Jason Moxham wrote:
> How about we set up a virtual? machine which cycles thru all available OS's
> testing sage/mpir on each one. One machine could then cover quite a few
> different configurations.
We have that already, i.e. about 18 different images running on the
same
On Apr 17, 9:09 pm, Bill Hart wrote:
> I guess the idea of doing a 32 bit test if the 64 bit code fails is
> probably a sensible one. The CPUID should still be returned correctly.
Yep, that seems like the best solution to me.
> I too don't want to work around every broken system. However this
On Apr 17, 10:32 pm, Jason Moxham wrote:
> On Saturday 18 April 2009 05:52:08 Bill Hart wrote:
> > As got_count is 0 then it is comparing two length 0 arrays and says
> > they are not equal. So this appears to be a problem with memcmp which
> > is just a C library function.
>
> memcmp may no
On Apr 17, 5:08 am, Jeff Gilchrist wrote:
Hi Jeff,
> On Fri, Apr 17, 2009 at 7:44 AM, Jason Moxham
> wrote:
> > our config.guess uses cc which is before configure even gets to the compiler
> > tests , same for gmp-4.3.0
>
> It seems gmp-4.3.0 works fine so if they are using cc, then they ar
On Apr 17, 4:37 am, Jason Moxham wrote:
> Have you tried building sage with gmp , does that pass the tests?
Since we have switched away from GMP I doubt he did it and since MPIR
1.1 works I don't think it matters too much for Sage at least since we
will update today :). The box did build the v
On Apr 17, 1:35 am, Burcin Erocal wrote:
> Hi,
Hi Burcin,
> I got the following error while building Sage-3.4.1.rc3 on my 32-bit Pentium
> D workstation (prescott?):
For the record: That version of Sage ships MPIR 1.0.rc8, 3.4.1.rc4
will ship MPIR 1.1, so no worries.
> Let me know if you
On Apr 14, 4:40 pm, Bill Hart wrote:
> I already adjusted the docs. If you are *absolutely sure*, I will
> revert the doc changes.
>
> Bill.
Ok, we still do need it on Linux, but it does work as required. I find
it strange it works on OSX, but not on Linux, but we can worry about
that post 1.0
en
resolved on OSX 10.5:
# Libraries that this one depends upon.
dependency_libs=' /Users/mabshoff/mpir-1.0-test/lib/libmpir.la'
Strangely enough this is the result of running "make install" only
once, so it seems that Jason's concern about having to run "make
instal
On Apr 11, 4:35 pm, Jason Moxham wrote:
> On Sunday 12 April 2009 00:04:10 Jason Moxham wrote:
> How about
>
> We go back to the previous method,
> I'll make gmpxx depend on gmp (NOT mpir)
>
> Make install installs mpir
>
> make install-gmpcompat installs gmp
>
> Superficially the same as
On Apr 11, 3:18 pm, Jason Moxham wrote:
> On Saturday 11 April 2009 22:21:04 mabshoff wrote:
>
>
>
> > Opps,
>
> > this OSX 10.4 specific issues slipped through my testing so far. The
> > bug itself is generally present on OSX, but only leads to linking
Opps,
this OSX 10.4 specific issues slipped through my testing so far. The
bug itself is generally present on OSX, but only leads to linking
failures on OSX 10.4.
g++ -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/
liblinboxsage.0.0.0.dylib .libs/linbox-sage.o -L/Users/Roed/Math/
sag
On Apr 10, 8:18 pm, Bill Hart wrote:
> 2009/4/11 mabshoff :
> >> Anyhow, make and make check now work fine on cato with pathcc.
>
> > Are the default flags still not using optimization?
>
> I don't understand the question.
>
> If gcc is used, it uses
On Apr 10, 8:13 pm, Bill Hart wrote:
> I've added support as per Mariah's recommendation in trunk. It only
> supports ABI=64 not n32 so I've changed that to the first one tried
> for that arch. I had to edit acinclude.m4 to make sure it excluded
> pathcc from the list of compilers it tested to
By the way: Yasm 0.8 was released *today*, so we might want to upgrade
for the next major release of MPIR anyway:
Changes from 0.7.2 to 0.8.0:
* Add TASM-like basic syntax and frontend (contributed by Samuel
Thibault).
* Add movbe instruction and CPU feature.
* Use UNIX (not Windows) path fun
On Apr 10, 5:39 pm, Bill Hart wrote:
> The yasm tests fail on so many systemss that I think we should work
> harder to disable them. They really aren't relevant to the MPIR
> library. Yasm itself works fine, whether or not the tests pass and the
> real test of that for us is whether the library
oops, twenty minutes after I reported that there was no problem an
issue with "make check" for yasm on some Acer notebook popped up:
PASS: modules/parsers/nasm/tests/nasm_test.sh
Test nasm_test: W +0-1/1 0%
** W: orphanwarn did not match errors and warnings!
FAIL: modules/parsers/nasm/tests/worp
On Apr 8, 12:18 pm, Bill Hart wrote:
> Release candidate 8 is available. It changes from symlinks to creating
> libraries in GMP compatibility mode and the option has been changed
> from --enable-gmplink to --enable-gmpcompat.
Ok, I ran some more tests with Sage last night and from this end th
On Apr 7, 3:04 pm, Bill Hart wrote:
> What do you guys think about changing the name back to --enable-
> gmpcompat now that we actually build the library and not just provide
> symlinks?
+1 from me.
The current behavior is also consistent with the fact that gmp.h was
never a link to mpir.h.
On Apr 6, 5:25 am, Jason Moxham wrote:
> On Monday 06 April 2009 06:30:37 mabshoff wrote:
Hi Jason,
> Yes , I should of been clearer , instead of creating
> sym-links , --enable-gmplink creates an actual library called libgmp.so
Mhh, I would be happied if it were symlinks since
libgmp.dylib and libmpir.dylib as well as the matching xx libraries:
bsd:lib mabshoff$ ls -al *libgmp* *libmpir*
-rwxr-xr-x 1 mabshoff mabshoff 259568 Apr 5 22:24 libgmp.
3.4.1.dylib
lrwxr-xr-x 1 mabshoff mabshoff 18 Apr 5 22:24 libgmp.3.dylib -
> libgmp.3.4.1.dylib
lrwxr-xr-x
There is an somewhat interesting article about "A First Look at the
Larrabee New Instructions (LRBni)" at
http://www.ddj.com/hpc-high-performance-computing/216402188
You might want to read the print version since that one is all on one
page. I am not sure how much of this will be useful to M
On Apr 5, 7:46 pm, Jason Moxham wrote:
> On Monday 06 April 2009 03:15:46 mabshoff wrote:
Hi Jason,
> I don't understand why it works , surely we have
> libmpir.so.3.4.1 in linux
> libmpir.3.4.1.dylib in OSX
> so a
> libmpir.${shared_ext}.3.4.1
>
> shouldn&
On Apr 5, 7:15 pm, mabshoff wrote:
> On Apr 5, 7:11 pm, Jason Moxham wrote:
> I've svn'ed into mpir-1.0.0 branch
I am not seeing it in the 1.0.0 branch. The top of "svn log" in 1.0.0
says:
On Apr 5, 7:11 pm, Jason Moxham wrote:
> There doesn't seem to be an easy way to this.
>
> I can do another hack for OSX , but then we will need another hack for cygwin,
> and for each system which names it libraries differently, and looking at
> libtool there are quite a few.
>
> The libtool -
On Apr 5, 2:46 pm, Jason Moxham wrote:
> Varro on Skynet is Darwin , so perhaps I can test it , if I can get past the
> make install needing root access . I remember reading somewhere that you can
> set the install path .
Use --prefix to do that.
The names on OSX in general need to be dylib,
Hi,
--enable-gmplibnk on OSX produces link from *so* to *so*, not *dylib*
to *dylib*, i.e.
bash-3.2$ uname -a
Darwin bsd.local 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24
17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386
bash-3.2$ ls -al libgmp*
lrwxr-xr-x 1 mabshoff mabshoff 10
On Apr 1, 7:07 pm, Jason Moxham wrote:
> I've just installed the old versions , and run them on mpir-1.0.0 and we get a
> diff , I'll svn them in mpir-1.0.0 directory
Ok, feel free to cut an 1.0.0.rc5 and put it somewhere. I am at a
dinner right now and will do some work in a couple hours a
On Apr 1, 7:26 pm, Jason Moxham wrote:
> On Thursday 02 April 2009 02:38:13 Jason Moxham wrote:
Hi Jason,
> > I was aware of this , I didn't think dead links would be a problem.
> > Fix is easy
>
> Confirming ?
>
> the *.so are only needed for shared
Well, there is also dylib on OSX and pro
And the old autoconf issue from 0.9.rc3 is rearing its ugly head
again:
PASS: t-istream
istream mpf_t operator>> wrong
point ,
str "1,"
got 123
want 1
localeconv point ","
/bin/sh: line 1: 9727 Abort trap ${dir}$tst
See
http://groups.google.com/group/mpir-devel/bro
Hi,
the first buglet while testing with Sage is the following: We are
building MPIR with
--enable-gmplink --enable-shared --disable-static --enable-cxx
After make install there are two dead links for the static libs, i.e.
libgmp.a -> libmpir.a
libgmpxx.a -> libmpirxx.a
These are causing tou
On Mar 29, 2:43 pm, Bill Hart wrote:
> I've put release candidate 4 up. This fixes the yasm configure error
> when -pc is present in the hostname.
>
> Known issues:
>
> * MSYS and mingw32: --enable-fat build failure
> * Cygwin32: make check fails if build path contained spaces
> * X86 32 bit Ap
On Mar 29, 2:53 pm, Bill Hart wrote:
> I've opened a ticket for this issue. It looks like a serious issue,
> and so we'll try to fix this one as soon as possible once we get the
> configure output from this machine.
>
> Bill.
Check out
http://gmplib.org/list-archives/gmp-devel/2006-April/0
On Mar 16, 10:00 am, Bill Hart wrote:
> Someone with access to the machine is going to have to give me more clues.
This is a Sage build on varro (a G5), but it is being run on a G4
laptop we do not have access to.
> How does it know that it is an invalid cpu subtype?
I do not know, but I hav
On Mar 16, 9:46 am, Bill Hart wrote:
> I have no particular insight into this. A G5 is a PPC right? Well, I
> don't know of anything that we've changed for PPC's.
Yes, I am surprised that the problem came up since I did not expect
any changes relative to MPIR 0.9 and the GMP 4.2.1 Sage shipped
On Mar 15, 1:09 pm, Jason Moxham wrote:
Hi,
> I cant access cato either :(
cato is not available to SkyNet account holders.
Mariah: Can you please add Jason to the people who can log into cato?
Cheers,
Michael
--~--~-~--~~~---~--~~
You received this message
On Feb 27, 3:30 pm, Jeff Gilchrist wrote:
Hi,
> On Thu, Feb 26, 2009 at 9:31 PM, Bill Hart
> wrote:
> > As far as we know MPIR 0.9.0 is highly stable and correct, so you
> > shouldn't have any issues using it in production code. It is used in
> > Sage for example, which has thousands of use
On Feb 27, 9:49 am, Bill Hart wrote:
> Hi Brian,
Hi,
> If Michael sets up a 1.0.0 milestone on trac, then we'll just close
> tickets when they are fixed. What you did was actually right.
I set up 0.9.1 and 1.0 milestones - see
http://trac.mpir.org/mpir_trac/roadmap
I also closed the 0.9
On Feb 27, 9:07 am, Bill Hart wrote:
> Hi Brian,
Hi Bill,
> I think it is much better if we don't close trac tickets until the
> release is made. That way it is easy for someone writing the NEWS file
> to see what has changed for this release. Instead simply prepend
> [done] to the title of t
On Feb 27, 8:40 am, ja...@njkfrudils.plus.com wrote:
> I was going to add redc_basecase to the fat structure when
>
> the fat build is broken in trunk rev 1638
> I don't know if this is picked up automatically , or manual , it certainly
> doesn't pick up redc basecase
Nice catch.
> Do I ha
On Feb 24, 8:07 am, Mariah wrote:
> Michael,
Hi Mariah,
> > > Even if I set SHAREDFLAGS=-fno-common, I get the same failure.
>
> > Ok. I do believe that the fix for inline semantics for OSX does not
> > cover that XCode release. Is this varro? Can you give us gcc -v in
> > either case?
>
> Ye
On Feb 23, 2:44 pm, Bill Hart wrote:
Hi,
> Do Brian and Mariah have trac accounts?
I am not sure, but I would tend to say no.
> Is it easy to upload a whole
> pile of files to a ticket without uploading them all individually?
No, it has to be one by one unless you attach a tarball.
> Bill
On Feb 23, 2:32 pm, Cactus wrote:
> On Feb 23, 10:26 pm, Cactus wrote:
> > Does file uploading need to be enabled in some way?
>
> It looks as if the group owner has not enabled file uploading for
> members.
>
> I run this group:
>
> http://groups.google.com/group/sunday-times-teaser-solut
On Feb 22, 11:49 am, ja...@njkfrudils.plus.com wrote:
> If there are no objections , I will merge the core-2 branch into trunk
> tomorrow. All I have changed are inc/dec to add/sub .
> I didn't do it for mpn-divexact_byff or the sub,add part of redc_basecase
> because it was not trivial.
>
> Whe
On Feb 21, 6:25 am, ja...@njkfrudils.plus.com wrote:
Hi,
I am sure the C compiler works, i.e. I am using it right now :)
> checking build system type... core2-unknown-linux-gnu
> checking host system type... core2-unknown-linux-gnu
> checking for a BSD-compatible install... /usr/bin/install -
On Feb 20, 8:45 am, ja...@njkfrudils.plus.com wrote:
Jason: those numbers already *rock*
> Some benchmarks on core2-unknown-linux-gnu (sage.math)Intel(R) Xeon(R) CPU
>
> X7460 @ 2.66GHz
>
> 8307 on trunk r1623 , should be same score as mpir-0.9.0
> 10252 on core-2 branch r1623
>
>
On Feb 18, 2:07 pm, Mariah wrote:
> Michael,
Hi Mariah,
> Even if I set SHAREDFLAGS=-fno-common, I get the same failure.
Ok. I do believe that the fix for inline semantics for OSX does not
cover that XCode release. Is this varro? Can you give us gcc -v in
either case?
> By the way, my confi
On Feb 18, 8:37 am, Mariah wrote:
Hi Mariah,
> mpir-0.9.0 built with gcc-4.3.3 fails 'make check' on G5-Darwin-tiger
> (powerpc970-apple-darwin8.11.0):
>
> gcc -std=gnu99 -m64 -mcpu=970 -O3 -o t-bswap t-bswap.o ./.libs/
> libtests.a /usr/local/mpir-0.9.0/src/obj-G5-Darwin-tiger-
> gcc-4.3.3/
On Feb 16, 10:08 pm, Case Vanhorsen wrote:
> On Mon, Feb 16, 2009 at 9:25 PM, William Stein wrote:
>
> > Hi,
>
> > I had to migrate all the cython, Sage and mpir websites and related
> > servers to another machine, due to some hardware failures on the
> > server that was hosting them. Pleas
On Feb 15, 6:13 am, David Harvey wrote:
Hi David,
> Hi, I'm curious to try this new divide-by-3 code, but I can't find it
> in the repo. Where do I look? How many c/l is it?
>
> david
>
> p.s. The wiki still says
>
> svn co svn://sage.math.washington.edu/mpir/
>
> but this is wrong, apparently
On Feb 14, 8:16 am, Bill Hart wrote:
> There's a copy in my home directory which is up2date.
Yeah, once I took the time to read the thread it kind of answered all
my questions :)
> I think William set up the original page, so he should know where it is.
I found it. All is live, i.e. the tarb
On Feb 14, 7:39 am, mabshoff wrote:
> On Feb 14, 5:55 am, Bill Hart wrote:
> Can someone point me to the latest version of the webpages? I should
> also get Bill access since that takes me out of the equation for
> updates and will get the latency down when I am snowed
On Feb 14, 5:55 am, Bill Hart wrote:
> We have. We're just waiting on someone to move the webpage over. I
> guess Michael will do that when he finds the time. He's deep into the
> Sage 3.3 release atm, which actually uses the new eMPIRe.
Yeah, it would be an understatement to say things are cr
On Feb 8, 2:19 pm, Bill Hart wrote:
Hi Bill,
> I don't understand what the t-locale test actually does. It looks to
> me like in some parts of the world a decimal point is a comma and this
> test somehow changes to that locale and tries to set an mpf to the
> value given in a string (containi
Ok, I just check again to be 100% sure an on varro, i.e. OSX 10.4/PPC
using
varro:~/sage-3.3.alpha6-32 mabshoff$ gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /var/tmp/gcc/gcc-5370~2/src/configure --disable-
checking -enable-werror --prefix=/usr --mandir=/share/man
On Feb 8, 11:41 am, William Stein wrote:
> On Sun, Feb 8, 2009 at 10:36 AM, mabshoff
>
> wrote:
>
> > Ok, testing turned up this:
>
> > Build failed on Mac OS X, Intel iMac while compiling gmp-mpir:
>
> The exact same failure happens on OS X 10.5 PPC iMac, a
Ok, testing turned up this:
Build failed on Mac OS X, Intel iMac while compiling gmp-mpir:
PASS: t-assign
PASS: t-binary
PASS: t-cast
PASS: t-constr
PASS: t-headers
PASS: t-istream
istream mpf_t operator>> wrong
point ,
str "1,"
got 123
want 1
localeconv point ","
/bin/sh: line 1:
On Feb 4, 10:30 am, Bill Hart wrote:
> I've made some changes to some documentation due to some incorrect bug
> addresses pointed out by Paul Zimmermann.
>
> I've also done some hacking to the autotools stuff to stop these silly
> errors I was getting on sage.math.
>
> The new tarball replaces
On Feb 5, 1:09 pm, Bill Hart wrote:
> 2009/2/5 mabshoff :
> > (a) I can give you access
> > (b) I can move the html and the tarball over there, too. I am busy for
> > the next couple hours, but I will try to squeeze it in.
>
> I would prefer to have access.
On Feb 5, 12:18 pm, Bill Hart wrote:
> 2009/2/5 :
>
>
>
> > On Wednesday 04 February 2009 19:54:03 Bill Hart wrote:
> >> Thanks. As soon as we release, it would be great if you could give it
> >> a go and we can issue a service release.
>
> > Should I create a branch for it?
>
> I don't think
On Feb 5, 12:20 pm, Bill Hart wrote:
> I don't understand why you don't get ABI=64 when you select
> -host=x86_64-blah. It *should* give you ABI = 64. If not there is some
> other problem here.
Well, with gmp 4.2.1 on William's Xeon OSX box doing "ABI=64 ./
configure" stopped dead in its track
On Feb 5, 8:11 am, Bill Hart wrote:
> Not sure what we can do about this.
>
> Configfsf.guess is run first and it gives:
>
> x86_64-unknown-linux-gnu
>
> This is passed to config.guess which tries to sharpen up the detection:
>
> 1) It runs a 64 bit x86_64 cpuid coded in assembly to get vendor
On Feb 5, 1:04 am, Willem Jan Palenstijn wrote:
> Hi,
Hi,
I talked to wjp about this in #sage-devel, so I have a head start :)
> When building the mpir shipped with sage 3.3.alpha5 (r1555) on a
> kvm/qemu amd64 virtual machine I get a 32-bit libgmp.so.
>
> The two config*.guess scripts repor
On Feb 3, 9:25 pm, Bill Hart wrote:
Hi Bill,
> I have placed a tarball here:
>
> http://sage.math.washington.edu/home/wbhart/mpir-0.9.0.tar.gz
>
> It will become the final version of MPIR if no further build failures
> are reported. Testing has not occurred on SkyNet yet. I would
> appreciate
On Jan 19, 5:45 am, "Case Vanhorsen" wrote:
> On 1/19/09, Bill Hart wrote:
>
>
>
> > Hi Case,
Hi,
> > can you run ./config.guess for us on your machine (it is in the main
> > directory of the source tree for MPIR). You may need to set
> > permissions first by doing chmod 755 config.guess
>
>
On Jan 18, 8:24 pm, Bill Hart wrote:
> 2009/1/19 mabshoff :
> >> Basically we can do a similar sort of thing for Moller's ngcd
> >> function. It's relatively straightforward - should be only about half
> >> a page of code. Might make a nice project fo
On Jan 18, 6:46 pm, Bill Hart wrote:
Hi,
> Ouch, that sounds painful!!
Well, it was mostly bloody since I was a couple kilometers away from
clean water or some kind of tissue to apply pressure to stop the
bleeding. The ice I slipped on was rather red. I have photos of the
hand, but I won't pos
On Jan 18, 6:25 pm, Bill Hart wrote:
Hi,
> As mentioned before, there is no LGPL Moller patch for xgcd. We have
> to write one.
Ok, I should know that by now. I am a little loopy due to pain killers
after tearing open my hand due to me hitting the pavement. I will
survive and I am leaving fo
On Jan 17, 5:09 pm, Bill Hart wrote:
> I made some changes to the website, including changing AMD Dunnington
> to Intel Dunnington and adding a section about planned improvements in
> the next version of MPIR. I made mention of the hard work Jason Moxham
> has been doing on the assembly support
Hello folks,
I *just* merged svn1555 into Sage :)
I build and tested for regressions in Sage 3.2.3 on
* FC 9 x86
* FC 9, OpenSUSE 10.3 x86-64
* RHEL 5.2, SLES 10 Itanium
* Solaris 10 Sparc and x86
* OSX 10.4 ppc
* OSX 10.5 32 bit *and* 64 bit builds
And eMPIRe also work
On Jan 14, 4:58 pm, "Bill Hart" wrote:
Hi Bill,
> The problem with --enable-fat on 64 bit systems is that it searches
> the 64 bit assembly directories for functions but sets the fat
> directories to the 32 bit x86 directories. This can easily be fixed.
> Lines 1457-1476 of configure.in need t
On Jan 12, 2:36 pm, Bill Hart wrote:
Hi,
> What Jason is saying (I think) is that currently xgcd (not gcd)
> doesn't use Moller's patches as such. It will in future, but not at
> the moment. So whatever guarantees you had before, you still have now.
> But that will soon change.
Ok, thanks fo
On Jan 11, 9:20 pm, "Jason Martin"
wrote:
Hi,
> No, we can't guarantee minimality. The xgcd that you're seeing right
> now in MPIR only uses Moller's code when it calls to gcd. It isn't as
> nice as the xgcd that is in GMP 4.3. Hopefully, we will be able to
> re-invent that wheel since I cou
Hi,
I just build a svn1555 eMPIRe.spkg and the good news is that it seems
that it can be "just dropped" a current install, i.e. we don't have to
bump each spkg depending on gmp for the upgrade. So far I am only
testing x86-64 Linux, but OSX is next. That makes the switch
significantly less disrup
(cd $subdir && \
make -j8 \
top_distdir="$top_distdir" \
distdir="$distdir/$subdir" \
distdir) \
|| exit 1; \
fi; \
done
make[1]: Entering directory `/scratch/mabshoff/junk/gmp-mpir-svn1523/
svn/
On Jan 11, 5:19 pm, Bill Hart wrote:
Hi Bill,
> I spent the afternoon constructing a rudimentary web page for MPIR
> (viewable here):
>
> http://sage.math.washington.edu/home/wbhart/RoundedCorner/index.html
Nice.
> Note the links to download the source and docs, etc are broken at
> present.
casevh wrote:
> Hello,
Hi,
> I am one of the maintainers of gmpy, a Python wrapper for GMP. I have
> added support to gmpy so it properly reports the MPIR version and
> properly displays the license information.
>
> I also tried compiling on various platforms. I tried to use the --
> enable-fa
On Jan 10, 1:42 pm, Bill Hart wrote:
Hi,
> I've just updated the CHANGELOG, NEWS and AUTHORS files.
Nice.
> Basically I can't replicate these memory leaks, so I think we are
> done.
Well, given that you now should valgrind the test and not bash you
might still hit them :)
> Is anything ou
On Jan 10, 11:45 am, Bill Hart wrote:
> Actually, these look like leaks in bash, not in MPIR:
>
Yes, those are bash since the tests are run by a shell wrapper. Bash
up to release 3.1 was *really* leaky.
Just go into .libs to valgrind the "original"
> Bill.
Cheers,
Michael
--~--~-
On Jan 10, 10:53 am, Bill Hart wrote:
> I get this on eno when compiling with --enable-cxx
>
> ../../gmp.h:532: error: âstd::FILEâ has not been declared
>
> I thought we'd fixed this issue ages ago. But I don't recall the
> solution.
Including in the right condition should fix that problem.
J
Bill Hart wrote:
> Oh, probably standard locale is not available on that machine, so the
> conditional compilation prevents the leak from showing up.
>
> Looks like I'll need access to a machine on which the leak occurs (and
> which has valgrind) in order to fix that one.
Ok, the problem shows
On Jan 10, 10:32 am, "Bill Hart" wrote:
> Hmm, when I valgrind t-locale on sage.math, no leaks show up. What am
> I doing wrong?
How exactly, i.e. with what parameters, are you calling valgrind?
> Bill.
Cheers,
Michael
--~--~-~--~~~---~--~~
You received this
On Jan 10, 8:03 am, "Bill Hart" wrote:
Hi,
> At the moment we don't use mpir.h.
>
> It should be possible for them to make a gmp-4.3.spkg. I don't see any
> technical hurdles there.
Yes, as mentioned in the other email getting something that works on
at least a couple platforms is easy, but ma
On Jan 10, 7:24 am, "Bill Hart" wrote:
> I knocked the bastard off:
Nice!
> MPIR now builds and passes make check with --enable-cxx with the Sun
> CC compiler. Technically the Sun compiler is correct to complain.
> Let's hope it still compiles with GCC!
Yep and all that code that uses the
On Jan 10, 7:42 am, David Harvey wrote:
> Hi,
Hi David,
> Suppose that, in a month or two, MPIR and GMP 4.3 have been released,
> and that the official Sage distribution now uses MPIR instead of GMP.
> Suppose that a friend of mine wants to run Sage using GMP instead of
> MPIR. Under th
On Jan 9, 4:59 pm, Bill Hart wrote:
> I've added a ticket for the memory leak.
Yeah, I saw the ticket. I am not 100% sure this isn't a false positive
since the C++ runtime could be involved here and that some times leads
to issues. Either way, I wouldn't consider it a blocker since it has
been
On Jan 9, 5:39 pm, "Jason Martin"
wrote:
Hi,
> I'd like to get rid of NAILS support. It adds a huge amount of
> complication, and I haven't seen it actually pan out for any modern
> processor.
>
> I vote for leaving the existing NAILS code alone, but explicitly
> stating that NAILS is not sup
On Jan 9, 5:57 pm, "Jason Martin"
wrote:
> Okay, I'll just start at the top and open them... I see the blocker
> notation once I open them.
>
> yes, I scrolled, and they are all the same color. That's not a big
> deal as I'm sure it's just some issue with my browser.
Look at http://trac.mpir
On Jan 9, 4:05 pm, Bill Hart wrote:
> OK, I see Jason already fixed the make tune issue. So perhaps the
> nails issue is all that is left.
>
> On Jan 9, 11:28 pm, Bill Hart wrote:
>
> > I've added the missing gcd prototypes to gmp-impl.h.
>
> > What else do we need to do before release?
>
> >
Hi,
in between svn1523 and svn1534 someone broken make install by setting
permissions of install-sh to 644:
test -z "/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local//share/
info" || /Users/michaelabshoff/Desktop/sage-3.2.3-64bit/trunk/install-
sh -d "/Users/michaelabshoff/Desktop/sage-3.2.3
On Jan 3, 5:58 pm, "Jason Martin"
wrote:
> Excellent!! Thanks for the error checking Michael!!
>
> Jason Worth Martin
> Asst. Professor of Mathematicshttp://www.math.jmu.edu/~martin
Ok, I have now verified that for all a up to 10**10 "(-
a^3).is_perfect_power()" returns true. Now obviously I
oking around:
==4835== 24 bytes in 1 blocks are still reachable in loss record 1 of
6
==4835==at 0x4C23849: operator new(unsigned long)
(vg_replace_malloc.c:230)
==4835==by 0x403134: set_point(char) (in /home/mabshoff/build/
eMPIRe/vg/t-locale)
==4835==by 0x404163: check_output() (in
On Jan 3, 7:00 pm, ja...@njkfrudils.plus.com wrote:
> On Sunday 04 January 2009 02:52:55 mabshoff wrote:
Hi Jason,
> > Can you write a test and check it in? I am not sure if anyone added
> > one yet.
>
> the above from current svn of mpir trunk at tests/mpz/t-perfpow.c
On Jan 3, 6:48 pm, ja...@njkfrudils.plus.com wrote:
> On Sunday 04 January 2009 01:56:15 mabshoff wrote:
Hi Jason,
> > So while the results are correct we either have an unfixed memory leak
> > either in Sage and/or eMPIRe. I have planned to do some valgrinding on
> > e
On Jan 3, 5:20 pm, mabshoff wrote:
> Hi,
> I am now running some larger examples to see if anything pops up.
Oops, I nearly too sage.math down with a 189GB job (not a typo) when
running this:
time len([a for a in srange(10*10) if not (-a^3).is_perfect_power
()])
This might have
Hi,
I just created a gmp-mpir-svn1523.spkg and build Sage 3.2.3.final
against it. The good new is that the segfaults I reported for svn-14XX
are gone and that we are seeing 11 doctest failures:
sage -t devel/sage/sage/modular/cusps.py # 1 doctests failed
sage -t devel/sage/sage
On Jan 3, 2:25 pm, jason wrote:
> On Jan 3, 9:00 am, "Bill Hart" wrote:
Hi,
> > The new intel machines. And I don't know if all Dunnington's use the
> > same family/system CPUID etc. So there might be mutiple CPUID's we
> > need to add to config.guess.
>
> > Bill.
>
> We should change the lo
1 - 100 of 133 matches
Mail list logo
