advance release of 1.2.99
Dan Grayson
We've put some binary distributions of version 1.2.99 here:
http://www.math.uiuc.edu/Macaulay2/1.2.99/
and are hoping that some of you will be able to try them out on your
systems and let us know if you encounter any problems. If you do,
that will help us prepare for the release of version 1.3 next week.
Thank you!
Alex Ghitza
Hello,
I've tried this out on two machines, with the following results. (The
MacBook dual-boots 64-bit Ubuntu, so I can try 64-bit Linux binaries
when they're out.)
Best,
Alex
---------------------------------------------------------------------
Dell laptop running Archlinux, used Macaulay2-1.2.99-i486-Linux-Generic.tar.gz
[ghitza@artin ~]$ uname -a
Linux artin 2.6.31-ARCH #1 SMP PREEMPT Tue Oct 13 13:36:23 CEST 2009 i686 Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz GenuineIntel GNU/Linux
Running M2, trying out some things, exiting. All fine.
---------------------------------------------------------------------
MacBook4,1 running OS X 10.5.8, used Macaulay2-1.2.99-x86_64-MacOS-10.5.dmg
aghitza@192-168-1-7:~$ uname -a
Darwin 192-168-1-7.tpgi.com.au 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
Getting errors when starting M2, and when exiting it with Ctrl-D
(typing 'exit' seems to have no problems, however). Tried out a few
things while in there, all fine.
aghitza@192-168-1-7:~$ M2
Macaulay2, version 1.2.99
with packages: ConwayPolynomials, Elimination, IntegralClosure, LLLBases, PrimaryDecomposition, ReesAlgebra, SchurRings, TangentCone
opt/Macaulay2-1.2.99/share/Macaulay2/Core/last.m2:66:37:(0):[3]: error: realpath failed: Bad address
opt/Macaulay2-1.2.99/share/Macaulay2/Core/last.m2:66:37:(0):[3]: --entering debugger (type help to see debugger commands)
opt/Macaulay2-1.2.99/share/Macaulay2/Core/last.m2:66:37-66:68: --source code:
prefixPath = prepend(realpath(applicationDirectory()|"local/"), prefixPath);
i1 : # here I try Ctrl-D to exit
/Users/dan/src/M2-1.3/BUILD/dan/../../Macaulay2/d/startup.m2.in:70:58:(0):[2]: --entering debugger (type help to see debugger commands)
opt/Macaulay2-1.2.99/share/Macaulay2/Core/debugging.m2:4:17:(0):[7]: error: couldn't find file /Users/dan/src/M2-1.3/BUILD/dan/../../Macaulay2/d/startup.m2.in
opt/Macaulay2-1.2.99/share/Macaulay2/Core/code.m2:14:53:(0):[6]: --back trace--
opt/Macaulay2-1.2.99/share/Macaulay2/Core/code.m2:7:33:(0):[5]: --back trace--
opt/Macaulay2-1.2.99/share/Macaulay2/Core/code.m2:57:40:(0):[3]: --back trace--
opt/Macaulay2-1.2.99/share/Macaulay2/Core/code.m2:192:16:(0):[1]: --back trace--
/Users/dan/src/M2-1.3/BUILD/dan/../../Macaulay2/d/startup.m2.in:70:32:(0):[-1]: --back trace--
ii2 : # Ctrl-D again, works this time
aghitza@192-168-1-7:~$
--
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne
-- Australia -- http://www.ms.unimelb.edu.au/~aghitza/
Dan Grayson
doesn't exist. Could you make this change
Index: Macaulay2/m2/last.m2
===================================================================
--- Macaulay2/m2/last.m2 (revision 9447)
+++ Macaulay2/m2/last.m2 (working copy)
@@ -63,7 +63,7 @@
if isDirectory(prefixDirectory|version#"machine") then
realpath(prefixDirectory|version#"machine")
};
if not noinitfile and getenv "HOME" =!= "" then (
- prefixPath = prepend(realpath(applicationDirectory
()|"local/"), prefixPath);
+ prefixPath = prepend(applicationDirectory()|"local/",
prefixPath);
userMacaulay2Directory();
makePackageIndex())))
and try it again on that second machine?
PS: The multiple CTRL-D's to exit are because you're in the debugger.
Each CTRL-D climbs the stack once. To avoid getting into it, add --no-
debug to the M2 command line.
Alex Ghitza
>
> Oops, "realpath" is too aggressive, and gives an error if the path
> doesn't exist. Could you make this change
>
>
> and try it again on that second machine?
>
Tried, and it is now fixed. Excellent!
Alex
Dr Andrew C Aitchison
Scientific Linux 5.4 (which is a recompliation of based on Red Hat
Enterprise Linux 5 release 4) still ships with glibc 2.5.
bin/M2: /lib/libc.so.6: version `GLIBC_2.7' not found (required by bin/M2)
This is the latest version of RHEL and SL. Since this supposed
to be a long-term stable OS, glibc is ecxeedingly unlikely
to be upgraded until RHEL 6 which Wikipedia suggests might be out
first quarter of 2010.
--
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
A.C.Ai...@dpmms.cam.ac.uk http://www.dpmms.cam.ac.uk/~werdna
Dan Grayson
a machine -- thank you for the tip. (We're not in a position to do
that easily for 1.2.99, though, because our virtual machine farm
needs to be reincarnated.)
Should we do both 32 and 64 bit versions?
Would it be enough, I wonder, to ship linux versions linking with as
few sharable libraries as possible, and annotated only with the
version of glibc required? That might reduce the glut of
distributions with names, which may not be needed to distinguish
anything important.
On Oct 18, 2:56 am, Dr Andrew C Aitchison
...
Dan Grayson
place. The binary was linked against glibc 2.9.
Dr Andrew C Aitchison
>
> Thank you for trying it. We'll certainly compile version 1.3 on such
> a machine -- thank you for the tip. (We're not in a position to do
> that easily for 1.2.99, though, because our virtual machine farm
> needs to be reincarnated.)
>
> Should we do both 32 and 64 bit versions?
Ideally yes.
I have 100+ 64bit machines and only keep a 32bit machine for
building and testing 32bit code.
> Would it be enough, I wonder, to ship linux versions linking with as
> few sharable libraries as possible, and annotated only with the
> version of glibc required? That might reduce the glut of
> distributions with names, which may not be needed to distinguish
> anything important.
I guess the number of third party libraries makes it difficult,
but I'd really rather the time was spent making the source
distribution easy to build on the standard OSes
(I'm afraid that that might mean a different .spec files for SuSE,
Red Hat and Fedora).
I guess the version dependencies could become a nightmare,
but then again if I already have gc, gdbm, gmp, pari, readline, libtool
etc. installed would I want to build them again just for Macaulay2 ?
Dan Grayson
for Macaulay2 -- so far, I've automated only the production of a
binary rpm (bypassing rpm's way of building). I could specify the
dependencies on other rpm's appropriately, and your system would just
install them. For 3rd party libraries for which no rpm's exist, I
could just include the sources in our rpm, and we would disable the
option that allows our makefile to download those libraries' source
archives from the internet.
Does that sound like a good plan? If so, can you point me to the
appropriate documentation?
On Oct 18, 11:26 am, Dr Andrew C Aitchison
...
> I guess the number of third party libraries makes it difficult,
> but I'd really rather the time was spent making the source
> distribution easy to build on the standard OSes
> (I'm afraid that that might mean a different .spec files for SuSE,
> Red Hat and Fedora).
> I guess the version dependencies could become a nightmare,
> but then again if I already have gc, gdbm, gmp, pari, readline, libtool
> etc. installed would I want to build them again just for Macaulay2 ?
Dr Andrew C Aitchison
> Probably that means I should automate the production of a source rpm
> for Macaulay2 -- so far, I've automated only the production of a
> binary rpm (bypassing rpm's way of building).
I was think of using the option to read the specfile from (possibly
compressed) tarball, so people could just download
Macaulay2-1.3-src.tar.bz2, put it in the right directory
(usually /usr/src/redhat/SOURCES) and run
rpmbuild -ta Macaulay2-1.3-src.tar.bz2
I must admit I hardly ever do this;
http://aaronhawley.livejournal.com/17061.html
describes the process, and makes me think that a source rpm
might be better after all.
> I could specify the
> dependencies on other rpm's appropriately, and your system would just
> install them. For 3rd party libraries for which no rpm's exist, I
> could just include the sources in our rpm, and we would disable the
> option that allows our makefile to download those libraries' source
> archives from the internet.
There might be a problem for 3rd party libraries which have rpms
but aren't in the distribution ...
> Does that sound like a good plan? If so, can you point me to the
> appropriate documentation?
online at
http://www.redhat.com/docs/books/max-rpm/
or
http://www.oldrpm.org/local/maximum-rpm.ps.gz
Eric Foster-Johnson has a more recent book "Red Hat RPM Guide"
a late draft ow which is available at
http://fedora.redhat.com/docs/drafts/rpm-guide-en/
More rpm docs at
http://www.oldrpm.org/
> On Oct 18, 11:26 am, Dr Andrew C Aitchison
> <A.C.Aitchi...@dpmms.cam.ac.uk> wrote:
>> On Sun, 18 Oct 2009, Dan Grayson wrote:
> ...
>>
>> I guess the number of third party libraries makes it difficult,
>> but I'd really rather the time was spent making the source
>> distribution easy to build on the standard OSes
>> (I'm afraid that that might mean a different .spec files for SuSE,
>> Red Hat and Fedora).
>> I guess the version dependencies could become a nightmare,
>> but then again if I already have gc, gdbm, gmp, pari, readline, libtool
>> etc. installed would I want to build them again just for Macaulay2 ?
> ..@dpmms.cam.ac.uk http://www.dpmms.cam.ac.uk/~werdna
> >
>
Thomas Kahle
Hi, I know I am too late, but I think in the current 1.3 svn branch the
configure script does not check for the presence of mpfr in the system
and downloads in any case.
Regards
Thomas
>
> Thank you!
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Macaulay2" group.
> To post to this group, send email to maca...@googlegroups.com
> To unsubscribe from this group, send email to macaulay2+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/macaulay2?hl=en
> -~----------~----~----~----~------~----~------~--~---
--
Thomas Kahle
The fundamental theorem of algebra is open source. Like any other
mathematical theorem it can be applied free of charge and everybody
has access to its proof and can convince himself how it works. Why
should software be any different?
Daniel R. Grayson
download mpfr anyway, if mpir is not installed, because we will be
using mpir to supplant the gmp library that most likely is installed
on your system, and there might be version differences.
Thomas Kahle
>> and are hoping that some of you will be able to try them out on your
>> systems and let us know if you encounter any problems. If you do,
>> that will help us prepare for the release of version 1.3 next week.
>
> Hi, I know I am too late, but I think in the current 1.3 svn branch the
> configure script does not check for the presence of mpfr in the system
> and downloads in any case.
... and if I am not mistaken it also does not even try to check whether
4ti2 or normaliz are present. From a distributional viewpoint I would
prefer to use the versions of these programs that my distribution ships.
all the best
Thomas
P.S.
I hope that M2 does not turn into a second sage and brings its own
python/version control system/linux kernel ... :)
Daniel R. Grayson
what distributions they are, and I'll work on it. What I would want
to do is to make sure that, after not compiling one of those programs,
the package in your distribution that provides it gets put on the list
of prerequisites for our package.
Meanwhile, the M2 packages that use those programs are easily
configured by the user to get the programs from a different location.
Thomas Kahle
> I had no idea those programs were in any linux distributions. Tell me
> what distributions they are, and I'll work on it. What I would want
> to do is to make sure that, after not compiling one of those programs,
> the package in your distribution that provides it gets put on the list
> of prerequisites for our package.
I am using Gentoo and I am the maintainer of the M2, 4ti2, normaliz and
a couple of other "packages with few users". So I can assure that before
M2 is installed via the package manager all deps that are available as
seperate packages are installed. The ones that are not available I will
let M2 build internally. (currently libfrobby, mpir, factory, libfac and
probably a couple of others in 1.3)
The "packages with few users" are available through the so called
science overlay which adds additional science packages that are waiting
to be added to the main repository. Maybe comparable to Debian unstable.
Generally Gentoo developers are very unhappy about packages that ship
internal copies of programs that are available seperately. So if my M2
package has some, then negotiations about adding it to the main
repository will be harder as they tell me to fix those first. (It is
tolerable if M2 is the only package using a library (like libfrobby at
the current stage)).
Regarding mpfr, indeed, mpir is not installed here, but mpfr is present
as it is dep of gcc since 4.3, I think.
> Meanwhile, the M2 packages that use those programs are easily
> configured by the user to get the programs from a different location.
>
> On Oct 23, 2009, at 10:22 AM, Thomas Kahle wrote:
>
>> ... and if I am not mistaken it also does not even try to check
>> whether
>> 4ti2 or normaliz are present. From a distributional viewpoint I would
>> prefer to use the versions of these programs that my distribution
>> ships.
>
>
Daniel R. Grayson
a command line option to the configure script that tells it which
external programs not to incorporate (from the list 4ti2 gfan
normaliz). I will have to change the code of the packages that use
those programs, too, as I have recently modified their code to look in
Macaulay2's private place for them.
Automatic detection is not the right thing to do, because some other
installer might be preparing an ubuntu M2 package, unless I code it to
determine not only presence, but availability from an ubuntu package
that can be listed on the list of prerequisites.
I should also make a section of our web page Downloads section that
points to Gentoo Linux and to the M2 package there. If the link to
use isn't obvious, let me know.
By the way, if gentoo distributes source packages, too, then you will
want not to enable our makefile to do automatic downloads. You can
simply include the needed source tar files in BUILD/tarfiles, and no
downloads will be needed. You will find the needed files there after
a build on your machine.
If gentoo uses rpms or debs, we could cooperate (eventually) and let
the M2 build system make the package all by itself. That might save
you time.
Thomas Kahle
> points to Gentoo Linux and to the M2 package there. If the link to
> use isn't obvious, let me know.
You can write something like "In Gentoo Linux Macaulay 2 is available
via the science overlay." Most people will know how to install it then,
but here is the manual for using overlays.
http://www.gentoo.org/proj/en/overlays/userguide.xml
> By the way, if gentoo distributes source packages, too,
Actually Gentoo distributes source packages only. Gentoo is more like a
meta-distribution. The package manager downloads the sources and builds
the programs right on your computer. This sounds weird in the beginning,
but it has a lot of advantages! For instance the complete problem of
backporting to stable is simply not present. You can basicly combine any
unstable version of a package with your otherwise stable system. The
package manager takes care of all the building, installing,
uninstalling, etc.
This said, packaging for Gentoo is writing a bash script, called ebuild,
which is executed by the package manager in a secured environment. To
get an idea you can see Macaulay 2's current ebuild here:
> want not to enable our makefile to do automatic downloads. You can
> simply include the needed source tar files in BUILD/tarfiles, and no
> downloads will be needed.
That is basicly what the ebuild will do. It lets the package manager
download the files and then puts them into the right location for M2 to
find them.
all the best
Thomas
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Macaulay2" group.
> To post to this group, send email to maca...@googlegroups.com
> To unsubscribe from this group, send email to macaulay2+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/macaulay2?hl=en
> -~----------~----~----~----~------~----~------~--~---