[sage-devel] Re: Some work on Minimal Sage in Gentoo
Here's a basic ebuild to merge sage-2.3 to /opt. It is not in
compliance with gentoo quality control standards, etc. etc. It puts
sage under /opt/sage/ as listed in the top-level sage makefile.
Gentoo complains of a number of fast and loose things going on in
some of the compiled code. Some of these things might be necessary
(for sage) even if gentoo complains about them. I'll put the log up
later (my dept. server seems to be done ATM).
**
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
DESCRIPTION=Software for Algebra and Geometry Experimentation
HOMEPAGE=http://modular.math.washington.edu/sage/;
SRC_URI=http://modular.math.washington.edu/sage/dist/src/${P}.tar;
LICENSE=
SLOT=0
KEYWORDS=x86
IUSE=
DEPEND=
RDEPEND=${DEPEND}
#S=${WORKDIR}/${P}
src_compile() {
emake || die emake failed
sed -e 's:\(^SAGE_ROOT=\).*:\1/opt/sage:' sage tmpfile
mv tmpfile sage
}
src_install() {
emake DESTDIR=${D}/opt/sage install || die emake install
failed
}
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: DSAGE Questions
On 3/18/07, Yi Qiang [EMAIL PROTECTED] wrote: Are you trying to run DSAGE between different versions of SAGE? The way that jobs are handled changed quite a bit, which is why it complains about some attributes not being there. Try it again using sage-2.3 throughout. I suspect that is what is happening too. By the way, could you make it so the .sage/dsage config files have some sort of version, so instead of getting weird random errors, the users gets a message that they have to re-run dsage.[whatever] to generate new config files? This would save a lot of confusion. Likewise, it would be very useful if a job is run on a worker that is an old version, there is a warning, or error, or something. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: DSAGE Questions
That really shouldn't be happening. It looks like Worker 1 and Worker 14 are getting the same job which is definitely not right. Your job database might have gotten screwed up. I think the easiest thing to try right now is to remove the $HOME/.sage/dsage/db and $HOME/.sage/dsage/tmp_worker_files directory and try again. This happens even after wiping .sage/dsage and running dsage.setup(). Are you trying to run DSAGE between different versions of SAGE? The way that jobs are handled changed quite a bit, which is why it complains about some attributes not being there. Try it again using sage-2.3 throughout. I've been tesitng with two separate DSAGE instances so that there is no talking between different versions of DSAGE. It works fine on my local machine with 2.1.4, but gives the Job attribute when I try just running it the 2.3 install. This is the job method that I'm using: def t32_job(self, i): job = Job(file= %s h_basis = load_da_basis(%s) k_basis = load_da_basis(%s) pairs = %s result = map(lambda x: theorem32(h_basis[x[0]], k_basis[x[1]], %s), pairs) save(result, 'result') DSAGE_RESULT = 'result.sobj' % (self.file_text, str(self.h), str(self.k), str(self.p_pairs[i]), str(self.rep) ) , name='t32') job.i = i return job Is there something obvious that I'm missing with it? --Mike --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: DSAGE Questions
On Mar 18, 2007, at 2:21 PM, Mike Hansen wrote: That really shouldn't be happening. It looks like Worker 1 and Worker 14 are getting the same job which is definitely not right. Your job database might have gotten screwed up. I think the easiest thing to try right now is to remove the $HOME/.sage/dsage/db and $HOME/.sage/dsage/tmp_worker_files directory and try again. This happens even after wiping .sage/dsage and running dsage.setup(). Are you trying to run DSAGE between different versions of SAGE? The way that jobs are handled changed quite a bit, which is why it complains about some attributes not being there. Try it again using sage-2.3 throughout. I've been tesitng with two separate DSAGE instances so that there is no talking between different versions of DSAGE. It works fine on my local machine with 2.1.4, but gives the Job attribute when I try just running it the 2.3 install. This is the job method that I'm using: def t32_job(self, i): job = Job(file= %s h_basis = load_da_basis(%s) k_basis = load_da_basis(%s) pairs = %s result = map(lambda x: theorem32(h_basis[x[0]], k_basis[x[1]], %s), pairs) save(result, 'result') DSAGE_RESULT = 'result.sobj' % (self.file_text, str(self.h), str(self.k), str(self.p_pairs[i]), str(self.rep) ) , name='t32') job.i = i return job Is there something obvious that I'm missing with it? Mike and I figured this one out over google talk. It appears that the problem was with setting the attribute 'job.i'. For some reason, setting that attribute caused unpickling the Job object on the otherside to fail. Changing that one line to 'job.n = i' fixed the problem. Cheers, Yi --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
