> Thought you might like to know that sage-4.6.1.alpha1 built with no
> probs but
> alpha2 failed to build on Ubuntu 10.10 (linux 2.6.35-23-generic)
> (PC = 2GB Ram, Intel Pentium 4 CPU 3.2GHz)
>
> Error was...
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/home/kyprir/sage-4.6.1.alph
> Hi Jeroen!
>
> On 14 Nov., 00:02, Jeroen Demeyer wrote:
> > At #9704, there is a positively reviewed proposal to rename the
> > debugging function trace() to trace_execution() and to use trace() in
> > the mathematical sense.
> >
> > I have nothing to do with that ticket, but I would like to p
> On 2010-11-10 10:13, Minh Nguyen wrote:
> > It depends on whether your're talking about the Sage library (i.e. the
> > package sage-x.y.z.spkg) or some other spkg. Components of Sage
> > (spkg's) are covered by GPL compatible licenses. As far as I know,
> > there is no single license that covers
> Hi,
>
> > I have toyed with singular-3.1.2 and tried to see if it could work with
> > sage.
>
> nice, I meant to get around to it but never did.
>
> > The short story is that we should stay clear of it for a some time.
> > The singular executables are fine, the problems are with libsingular.
>
Hi all,
I have toyed with singular-3.1.2 and tried to see if it could work with
sage.
The short story is that we should stay clear of it for a some time.
The singular executables are fine, the problems are with libsingular.
The headers shipped for libsingular are currently completely broken,
this
> This is a topic which I already touched in the "Merging tickets into
> sagenb" thread, but I believe the discussion was not finished.
>
> Currently, every new Sage version has a new version of the following
> spkgs: sage, sage_scripts, extcode, examples. However, it is likely
> that not all tho
> (The following is a *spoof* of something I just got from the Director
> of computing at UW. I replaced the name of some famous math software
> with Sage. See if you can guess which.)
>
> Sage users-
>
> Documented use of Sage on computers not authorized under our contract
> with Stein has ca
> On 10/27/10 08:38 PM, François Bissey wrote:
> > I should pipe in since we are talking about that.
> > Generally speaking sage should work on a reasonably up to date stable
> > Gentoo system. However it would be a good thing to point user to
> > sage-on-gentoo
> On 10/28/10 06:37 AM, Minh Nguyen wrote:
>
> f2c
> http://trac.sagemath.org/sage_trac/ticket/7027
> This to me looks like the upstream source code has been modified. SPKG.txt
> says "The one change is to use cc instead of gcc in the makefiles". I
> think the comment is round the other way, and t
> On Wed, Oct 27, 2010 at 6:01 PM, kcrisman wrote:
> >> > Regarding fortran, for a "Microsoft Visual C++" version of Sage, I
> >> > will just get rid of Fortran (and Lisp) entirely, and not bother with
> >> > building anything currently in Sage that depends on them...
> >>
> >> My thoughts about
> I would expect significant pushback from the Gentoo people
> on the issue of including other projects inside Sage. GCL
> packaged gmp4 (now fixed) and their response was that this
> should not be part of GCL. I'm not sure if independently
> available projects (e.g. ECL, Maxima, etc) would fit t
Hi Georg
> Hi Francois,
>
> > Well thanks for the plug for our work. We are quite happy to develop the
> > prefix
> :
> :-)
> :
> > part of sage-on-gentoo, so far the effort has been limited but if you are
> > testing it on an arch we are quite happy to try to get as much as
> > possible keyworde
> On 10/27/10 04:26 PM, mmarco wrote:
> > A few words about the gentoo platform.
> >
> > Since gentoo does not follow the usual system of versions, but is
> > based on continuous incremental upgrades, there is no way to ensure
> > that sage binaries would work on a given gentoo box. As far as i kn
> Hi folks,
>
> for sime time now, there is a tendency of the Sage distribution to
> become unmaintanable (only minutes ago, I read the upteenth message
> thread and trac ticket about the recurrent Suse Linux 11.x/Arch Linux
> bash/readline issue ...).
>
> There are several possibilities/ways to
> Note that fs in the example is a list of length 1.
> David
>
> > which suggests that fs should instead be an array. If I try to go through
> > the
> > steps of the initialization process by hand using the data from the test
> > I get
> > error messages:
> > sage: import sage.calculus.riemann
Hi,
I am looking at the code and tests for the class Riemann_Map in
calculus/riemann.pyx and I have a hard time understanding how it can be
working at all.
The init method starts with:
def __init__(self, fs, fprimes, a, int N=500, int ncorners=4, opp=False):
"""
Initializes
> Hi,
>
> Just for fun, I created this page:
>
>http://code.google.com/p/sagemath/
>
> It has the Sage source code repo, so you can browse the history of Sage:
>
>http://code.google.com/p/sagemath/source/list
>
I actually installed hgview to inspect changes on my machine and it looks
> > On 10/ 8/10 10:18 PM, Jeroen Demeyer wrote:
> > > (forwarding this from
> > > http://pari.math.u-bordeaux.fr/archives/pari-announce-10/msg0.html)
> > >
> > >
> > > Dear PARI lovers,
> > >
> > > I would like to announce the release of pari-2.4.3-ALPHA. The sources
> > > can be obtained th
> Hi
>
> On Sun, Oct 17, 2010 at 09:37:55AM +0200, Jan Groenewald wrote:
> > Looking for libpari-gmp.so, I found these:
> > r...@capepoint:/usr/local/src/sage-4.5.3/local/lib#ls -l libpari*
> > -rwxr-xr-x 1 root root 3160120 Oct 11 17:06 libpari-gmp.so.2
> > -rwxr-xr-x 1 root root 3160120 Oct 11 1
> On 10/ 8/10 10:18 PM, Jeroen Demeyer wrote:
> > (forwarding this from
> > http://pari.math.u-bordeaux.fr/archives/pari-announce-10/msg0.html)
> >
> >
> > Dear PARI lovers,
> >
> > I would like to announce the release of pari-2.4.3-ALPHA. The sources
> > can be obtained through the address
> On 2010-10-06 02:04, François Bissey wrote:
> >> I would like to see the source code of
> >> sage.matrix.matrix_modn_sparse.Matrix_modn_sparse.__eq__(), but I have
> >> no idea where to look.
> >
> > sage/matrix/matrix_modn_sparse.pyx ?
>
> We
> I would like to see the source code of
> sage.matrix.matrix_modn_sparse.Matrix_modn_sparse.__eq__(), but I have
> no idea where to look. The following doesn't work::
>
> sage: L1 = matrix(GF(43), 3, 3, range(9), sparse=True)
> sage: L1.__eq__??
> Error getting source: arg is not a module, class
> On 2010-10-04 11:41, François Bissey wrote:
> > Well someone screwed up with that in #9876.
>
> If someone screwed up, that someone must be me :-)
>
> On 2010-10-04 10:37, John Cremona wrote:
> > According to the pari SVN logs, the change was pade at revision 12605:
> According to the pari SVN logs, the change was pade at revision 12605:
>
> http://pari.math.u-bordeaux.fr/cgi-bin/viewcvs.cgi?view=rev&root=pari&revis
> ion=12605
>
> while the spkg name pari-2.4.3.svn-12577.p7 suggests that we ship
> 12577, i.e. before that patch.
>
> Here we appreciate the p
> Hi all,
>
> I am a bit puzzled by something I noticed while looking at problem
> with sage -t -long -force_lib "devel/sage/sage/tests/parigp.py"
> in sage-on-gentoo and followed the upstream thread
> (http://pari.math.u-bordeaux.fr/cgi-bin/bugreport.cgi?bug=1079)
> We include the patch for iss
Hi all,
I am a bit puzzled by something I noticed while looking at problem
with sage -t -long -force_lib "devel/sage/sage/tests/parigp.py"
in sage-on-gentoo and followed the upstream thread
(http://pari.math.u-bordeaux.fr/cgi-bin/bugreport.cgi?bug=1079)
We include the patch for issue 1079 as is
> Could you alse give the 1.4.1.p0 a spin? it contains the patch for
> linux ppc. (download link a few posts above) Perhaps the whole thing
> will get obsolete
> with 1.5.0 but I'm curious if that would work also, because I'm not
> sure if I get 1.5.0 ready in time.
Missed that. I will have to do t
> On Sep 29, 9:01 am, Marshall Hampton wrote:
> > It looks like it might be a while before this is fixed by numpy:
> >
> > http://projects.scipy.org/numpy/ticket/1403
> >
> > Given the importance of numpy to Sage, I think it might make sense to
> > drop support for PPC linux. On the positive si
> Ok latest update: numpy-1.4.1 and scipy-0.8 should now be ready! (see
> ticket #9808; http://trac.sagemath.org/sage_trac/ticket/9808 )
>
> Many many thanks to fbissey for the help with the spkg-install script,
> and kcrisman for additional testing!
>
> I have now a question: Should we merge it
Hi Dave,
> I spent a bit of time yesterday seeing how far Sage would build on AIX 5.3
> after resurrecting my IBM RS/6000.
>
> I've not made any patches for AIX yet, as I'm primarily keen to get Sage
> running on 64-bit Solaris, not AIX. I will use Sage on Solaris, but would
> only personally bui
> On 09/18/10 10:49 PM, François Bissey wrote:
> > /lib/libdl.so.2
> > /lib/libm.so.6
> >
> > Funny they are not the same as yours. You should check libraries as well.
> >
> > Francois
>
> I'm finding even a hello world is li
> On 09/18/10 09:49 PM, François Bissey wrote:
>
> BTW, although ECL is the worst offender in the current version with 3
> unused libraries, there's only one in the latest git version.
>
> I have reported this to the ECL list, and created a trac ticket for it.
>
> I was reading something quite interesting here.
>
>
> http://blogs.sun.com/rie/entry/tt_dependencies_tt_define_what
>
> It is written with Solaris in mind, but basically says that linking to
> unnecessary libraries is is a way to slow down code. So I decided to use
> the method it suggests, an
> > I am taking a look at this shortly. I don't have hardware on which I can
> > push parallel make so far. There are some messages I haven't seen before
> > in a parallel make of singular I must say. This particular failure
> > should be easy but there may be more after it.
> >
> > Francois
>
>
> On 09/17/2010 02:25 AM, Dr. David Kirkby wrote:
> > http://trac.sagemath.org/sage_trac/ticket/9733
> >
> > is supposed to fix "Parallel build of Singular 3-1-1-4-package fails in
> > rare case"
> >
> > I just downloaded the sage-4.6.alpha1.tar file (Mihesh gave a hint where
> > it was), and it
> On 09/12/10 12:10 AM, François Bissey wrote:
> > +1 to move to FC.
>
> I raised this back in November 2009 - William is against using FC.
>
> http://www.mail-archive.com/sage-devel@googlegroups.com/msg31854.html
>
I read the thread in question. I think more rece
> On 11 September 2010 21:48, Ondrej Certik wrote:
> > When building femhub and packages for femhub, I have to deal with
> > these fortran issues as well. And I never understood
> >
> > a) why sage used g95 in the first place (yes I know it's smaller, but
> > it's not standard at all imho)
>
> A
> There's odd bits code scattered around in Sage that do tests for g95, which
> is an old Fortran 95 compiler that in any modern Linux or Unix systems.
>
> According to Wikipedia
>
> http://en.wikipedia.org/wiki/G95
>
> gfortran was forked from g95 in 2003 - i.e. 7 years ago.
>
That doesn't me
Hi Dave,
shared libraries, nice to have but not strictly necessary.
I am backing you up on that one until it is properly fixed.
I will look at that ticket but I think sage's BLAS/LAPACK
subsytstem needs a big revamp if we are going to use
shared libraries by default.
Note that until recently ATL
> I've made a couple of changes to the ATLAS package so SAGE_ATLAS_LIB works
> on Solaris. When I tested it on Solaris it worked of course.
>
> kir...@sage:~/sage-4.5.alpha4$ export SAGE_ATLAS_LIB=/tmp
> kir...@sage:~/sage-4.5.alpha4$ export
> SAGE_ATLAS_LIB=/home/kirkby/sage-4.4.3/local
> kir...@
> On 2 Sep, 05:55, François Bissey wrote:
> > > Who would agree with making this a policy and so adding to the Sage
> > > Developers Guide a few sentences saying that any updates of packages
> > > that are not to a stable release (i.e snapshots, alpha, beta, releas
> On 2 September 2010 02:12, Jason Grout wrote:
> > On 9/1/10 7:00 AM, David Kirkby wrote:
> >> Should any desire to update to a non-stable release be discussed on
> >> sage-devel first?
> >
> > That sounds reasonable to me.
> >
> > Jason
>
> Thank you Jason.
>
> Who would agree with making th
> And another thing: Do you have Any Idea, where I could start. I think
> at least I have an Idea
Just quickly, did you do a 'sage -b' after upgrading numpy?
Francois
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-de
>
> @Francois: Thank you! I haven't seen that. I will build then a package
> for the latest release soon (I think some ours ago it was numpy
> 1.5.0b2...)
> But I fear the problem will remain
If you had asked I could have told you there would be problems, API changes
you know. Jason knew as well
> On 8/26/10 1:18 PM, maldun wrote:
> > Hi,
> >
> > is anyone outthere who is working on the latest numpy version 1.5b,
> > and scipy 0.8?
> >
> > I really would need them, and would help testing if there are already
> > some packages available.
> >
> > If no one is working on it, it would also
> Of course I know it depends on swap space, operating system, lots of
> things, so nobody can give an exact answer, but I'd be interested to know
> if building Sage on a machine with only 1 GB of RAM is likely to be
> possible.
>
> The machine, which runs AIX (or it would if I can fix the PSU), h
> Here's the full traceback for easy_install bpython too, just in case:
>
> SAGE_ROOT=/opt/sage\n(sage subshell) \h:\W \u$ sudo !!
> sudo easy_install bpython
> Password:
> Traceback (most recent call last):
> File "/opt/sage/local/bin/easy_install", line 8, in
> load_entry_point('setuptool
> he's on an experimental Gentoo
> distribution of Sage, that most probably uses the system Python rather
> than the Sage's Python.
> So this means that the system Python needs to be rebuilt, probably
>
Hi,
I am one of the two sage-on-gentoo dev. I actually tried it on s-o-g
without trouble. I ha
> On 08/16/10 11:43 PM, François Bissey wrote:
> > If you weren't using sympow you won't be missing it and nothing would
> > break. Nothing apart from lfunctions/sympow.py calls sympow and I don't
> > think anything in that python file is called from anyw
> Where do I find "sage-on-gentoo"? And where would I find this list?
http://github.com/cschwan/sage-on-gentoo
As for the lists I am copying then here (beware Gentoo-speak):
*buildtime dependencies:
DEPEND="|| ( =dev-lang/python-2.6.4-r99
=dev-lang/python-2.6.5-r99 )
dev-libs/gmp
> Is there even a link from which Sympow can be downloaded so that one
> can look through the code to see if it is worth salvaging. I can't
> even find a webpage for Mark Watkins at the moment, let alone sympow.
I asked that question on the 17th of February on this very same mailing list.
No one co
> sage: sympow.new_data(2)
> Make data for symmetric power 2
> sage: a = sympow.L(EllipticCurve('11a'), 2, 16); a
> "Inertia Group is C1 MULTIPLICATIVE REDUCTION\nConductor is 11\n**ERROR**
> P02L not found in param_data file\nIt can be added with './sympow
> -new_data 2'"
>
> This could be at l
> On 8/3/2010 7:34 PM, Dr. David Kirkby wrote:
> > I think I've discovered something which should be a blocker for 4.5.2.
> >
> > http://trac.sagemath.org/sage_trac/ticket/9681
> >
> > Please correct me if I'm mistaken. It would not be the first time I've
> > been mistaken over dependencies in th
> On 08/ 3/10 12:30 PM, François Bissey wrote:
> At the minute I think we need an agreement of the overall plan of how we
> define supported systems. I don't personally think either of the following
> are sensible
>
> * Saying we support a whole distribution like "De
> Is there anyone that would disagree that we need a list of supported
> platforms for Sage? If so, I'd love to hear your explanation why!
>
> Assuming you agree we need a list of supported platforms, you must agree
> that
>
> http://trac.sagemath.org/sage_trac/ticket/9487
>
> has at least some
Actually the comentator from linbox breaks sage. I thought this was
known and patched in the linbox spkg. I just checked the linbox
spkg and it is removed.
That's strange that you seem to have built a linbox with commentator.
Francois
--
To post to this group, send an email to sage-devel@google
> Hi!
>
> This is related with #9583.
>
> If the patch from #1396 is applied, Sage segfaults on t2 at startup.
> It seems that the offending part of the code is in sage/libs/singular/
> option.pyx.
>
> I thought that Cython generates C code, which is then processed
> further with gcc. But in thi
> While I'm not discounting a parallel make issue entirely, it doesn't look
> like a typical one. The failing .lo's include the first one to be built in
> a non-parallel build, so it seems unlikely that one would be suffering
> from missing dependencies. (And there are no errors reporting missing
>
> I just tried to build Sage, and got a failure with building IML. See log
> here.
>
> http://boxen.math.washington.edu/home/kirkby/iml-1.0.1.p12.log
>
> As soon as I restarted "make" again, so the build completed ok.
>
>
> On thing I did do, was reverse the order of the list of items listed un
> Here's the ticket:
>
> http://trac.sagemath.org/sage_trac/ticket/9567
>
> And the new links on the google code pages
>
> http://spkg-upload.googlecode.com/files/networkx-1.1.spkg
>
> http://code.google.com/p/spkg-upload/downloads/detail?name=networkx-1.1.spk
> g.md5&can=2&q=
>
Hi Ben,
will
> On Fri, Jul 16, 2010 at 3:21 PM, François Bissey
>
> wrote:
> >> Hi,
> >>
> >> Newer sympy has a bundled copy of mpmath, what causes several
> >> problems in my sagemath package. I was in vacation during most of
> >> Mandriva 2010
> On Mon, Jul 19, 2010 at 1:18 PM, François Bissey
>
> wrote:
> > Hi,
> >
> > We have noticed in sage-on-gentoo that the sage-4.5 tarball has
> > been available for a few days but not the individual spkgs as far as
> > we can see.
> > Which means th
Hi,
We have noticed in sage-on-gentoo that the sage-4.5 tarball has
been available for a few days but not the individual spkgs as far as
we can see.
Which means that sage -upgrade doesn't upgrade anything and
we cannot push sage-4.5 ebuilds either as we rely on the individual
spkg to be available.
> On Sat, Jul 17, 2010 at 7:16 AM, William Stein wrote:
> > Hi Sage-Devel,
> >
> > Amazingly, University of Washington has >= 1 postdoc jobs starting in
> > 2011. It's a very competitive position, and pays pretty well.
> > Anyway, here is the job ad:
> >
> > http://www.math.washingt
> As an aside, if two upstream packages include another upstream
> package (e.g. both include GMP) what does Sage do? Are there
> two copies of GMP? They could have different versions of the
> same package since project 1 could have stopped at one version
> and project 2 could have stopped at anoth
> Hi,
>
> Newer sympy has a bundled copy of mpmath, what causes several
> problems in my sagemath package. I was in vacation during most of
> Mandriva 2010.1 freeze, and did not fully test the package for some
> time, but I am working on an update for it; basically an 's/import
> mpmath/import
> In my email above, I just appended '$(INST)/$(GLPK)' to the end of the
> CVXOPT line as it currently is in spkg/standard/deps.. I did not add
> NUMPY myself. If a dependency can be removed, it would be useful, as
> it might permit more efficient parallel builds.
sorry Dave, I didn't imply you di
> On 07/14/10 10:58 PM, Nathan Dunfield wrote:
> >> On a similar note cvxopt can make use of glpk as well.
> >
> > Yes, it can --- I was just using this yesterday.
> >
> > The trick is that you have to tell cvxopt that glpk is available when
> > it is compiled/installed. Now that glpk is standa
> I know GPLK was added to Sage recently, and also that R is in Sage. I don't
> know if there is any advantage, but there is a GLPK package for R.
>
> http://cran.r-project.org/web/packages/glpk/vignettes/glpk-intro.pdf
>
> I don't know if there is any advantage in making that.
>
> I assume it w
> On Tue, Jul 6, 2010 at 2:10 AM, Dr. David Kirkby
> > > BTW, the use of 'which' is not a good idea. First its non portable.
> > Secondly, do we not know the patch of cython? If so, why is it not
> > hard-coded? That will save some time. One a 3.33 GHz machine, the
> > overhead in calling 'which' i
> make check runs lots of binaries, say "abc" with input file abc.in and
> compares the output with abc.out, complaining if they differ.
>
> The *.out files are there already, and the temporary output files
> should be deleted after the test.
>
> If there is a better way, please tell me!
>
That
One last question John, slightly unrelated.
How am I supposed to interpret the tests results?
I ran the tests and got some .out files in qcurves.
Is it supposed to happen?
Francois
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an emai
> Let me explain.
>
> eclib uses pari for integer factorization, if the pari library is
> installed. Otherwise it uses gp, if gp is installed. Otherwise it
> falls back to trial division.
>
> The PATH_TO_GP variable is only needed if you DO have gp but you DO
> NOT have libpari. So this is irr
Hi all,
this is probably aimed specifically at john Cremona but I am guessing anyone
can have a stab at it.
while working on ticket #9343 and how to perform the migration to pari-2.4.3
in sage-on-gentoo I came across this piece of code in eclib, more precisely
procs/gpslave.cc:
int do_we_have_pa
> Since building packages in parallel has speeded up the build process
> immensely, I thought I'd have a look at what stops it running even
> quicker. Although I've not done any systematic tests, on my OpenSolaris
> Ultra 27, I've come to the conclusion there are 3 parts taking up a lot of
> the bu
Hi,
In making a patch for ticket #9097 I simplified the
logic of the building sage_clib on OSX and 64 bit platforms.
It works for Dave on solaris 64 bits. But it would be nice
if we didn't have any surprise from the OSX side.
So if a friendly OSX tester could try the patch at
http://trac.sagemath.
> On Fri, 2 Jul 2010 01:10:25 -0700
>
> Mike Hansen wrote:
> > I don't think it's feasible to carry out William's proposal with
> > conditional patches. I'm +1 on including GNU patch in Sage.
>
> I also vote YES to including patch in Sage.
>
> I would like to see some more standardization in h
> I propose that we make GNU patch a standard package, so that patches
> to Sage can be made in a more sensible manner than using 'cp' as now.
> (There's no point in 'patch' being optional at all, as it would be
> needed when building Sage).
>
> For
> * It is small - the source code is about 240
I was thinking of "sage -testall" make test does a few things before
starting sage -testall that I suspect will stop the whole thing.
Francois
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googleg
> I've tried to build a slightly modified version of Sage 4.5.alpha1 on
> OpenSolaris x64 as a 64-bit application, but have hit two non-trivial
> issues.
>
> * Maxima will not build.
> * R will not build
>
> So I typed
>
> $ touch spkg/installed/maxima-$version
> $ touch spkg/installed/r-$Rv
> On 07/ 1/10 05:26 AM, François Bissey wrote:
> >> I must admit, I can't follow your patch - one obvious thing is that it
> >> would appear to print "MacIntel in 64 bit mode" whenever SAGE64 is set
> >> to yes. I've not actually applied your versi
>
> I must admit, I can't follow your patch - one obvious thing is that it
> would appear to print "MacIntel in 64 bit mode" whenever SAGE64 is set
> to yes. I've not actually applied your version. I'm actually sitting
> in bed now, and have given up coding today. So I will investigate
> tomorrow.
> It would be really good to get this patch into Sage asap, as it allows one
> to build a very large part of the Sage library on OpenSolaris.
>
> All it does, is adds these 4 lines a SCons configuration file
>
>
> if env['PLATFORM'] != "darwin" and os.environ['SAGE64']=="yes":
> env.Append(
> On 06/30/10 07:30 PM, Mariah Lenox wrote:
> > The spkg r-2.10.1 includes inside it the spkg rpy2-2.0.8.
> >
> > According to the relevant SPKG.txt, r-2.10.1 comes from
> > http://www.r-project.org/, while rpy2-2.0.8 comes from
> > http://rpy.sourceforge.net/rpy2.html.
> >
> > Is it policy to pu
> On 06/30/2010 02:05 AM, Dr. David Kirkby wrote:
> > On 06/30/10 12:54 AM, Tim Daly wrote:
> >> I'm surprised you don't use patch.
> >> Mercurial can generate patches.
> >
> > That would only be ok at the point Mercurial is built, so might be
> > tricky.
>
> $SAGE_ROOT/sage/spkg/standard/deps sa
> I've been chasing my tail much of today, trying to make Singular play ball.
> Managed to find out one for for sure. Someone has written a patch to
> src/Singular/Makefile.in, then someone else has written one to the same
> file and overwrote the first one.
>
What we need here is probably a stan
> On Jun 29, 4:13 pm, François Bissey wrote:
> > sage doesn't assume that the patch command is installed but rely on cp
> > being there. That's why patch aren't used.
> > I agree not ideal but that's a lowest common denominator issue.
>
> Perhaps
> On Jun 29, 2010, at 5:18 PM, Dr. David Kirkby wrote:
> > I've been chasing my tail much of today, trying to make Singular play
> > ball. Managed to find out one for for sure. Someone has written a patch
> > to src/Singular/Makefile.in, then someone else has written one to the
> > same file and o
> > Outstanding issues:
> > -singular: we really wish sage would move to the latest upstream.
>
> When we tried to update the last time we found a bug (or change of
> behaviour) in the most recent Singular release:
>
> cf. http://trac.sagemath.org/sage_trac/ticket/8059
>
> It is likely that ups
Hi all,
this message is cross-posted between the gentoo-science and sage-devel
mailing lists.
So this is sage-4.4.4 and we have come a long way.
sage-on-gentoo is now usable for the majority of people and can be used
to test development ideas.
We have a page where we list our current issues:
htt
> Matplotlib is used as part of the Sage project, where we aim to run
> test-suites that are part of upstream packages where possible. Someone
> suggested it would be good if we did that for Matplotlib, which we
> currently do not do. However, on reading the contents of the source
> directory (READ
> On 06/24/10 04:14 PM, Adam Webb wrote:
> > test_distutils passes if I use a plain python 2.6.5 tarball. This is
> > consistent with the problem being in Sage or at least in the
> > environment used for building packages.
> >
> > Adam
>
> That's interesting!
>
> So far everyone seems to see thi
> On 06/24/10 09:29 AM, Dr. David Kirkby wrote:
> > On 06/24/10 01:26 AM, Alex Ghitza wrote:
> >> I got the following:
> >>
> >> 1 test failed:
> >> test_distutils
> >>
> >>
> >> Best,
> >> Alex
> >
> > You are doing better than most. But *everyone* gets that failure. I
> > don't know how criti
> > So do you believe BLAS needs to remain in Sage,
>
> Probably not.
>
> > or could it be removed in 4.5?
>
> If somebody removes it.
>
> > If it is removed, what should numpy and scipy link to - ATLAS, cblas ??
>
> I don't know.
>
numpy needs lapack and because of it the blas library lapac
> On 06/22/10 10:10 AM, François Bissey wrote:
> >> Someone commented the other day that he could not understand why BLAS
> >> was in Sage when we had ATLAS. This was in response to my concern
> >> about linbox not being able to find BLAS
> >
> > That
> Someone commented the other day that he could not understand why BLAS
> was in Sage when we had ATLAS. This was in response to my concern
> about linbox not being able to find BLAS
That was me. For info sage-on-gentoo only uses ATLAS without any issues.
I believe the blas spkg only ship libblas.
> I would have thought python was pretty critical, but I can'f find a
> way of testing python. Although python is built with the usual
>
> configure
> make
> make install
>
> there is no 'make check'.
try 'make test'.
Francois
--
To post to this group, send an email to sage-devel@googlegroups.
> On 10 Jun., 00:06, Alex Ghitza wrote:
> > I am not convinced that testing only libs/singular/ and
> > interfaces/singular.py is sufficient to conclude this. Functionality
> > from various parts of Singular is used all over the Sage library. I
> > would be a bit more confident if a global "make
> On 9 Jun., 22:20, François Bissey wrote:
> > > On 9 Jun., 13:43, François Bissey wrote:
> > I haven't tested your new spkg but I ran
> > sage -t -long devel/sage/sage/lib/singular/
> > as you did in your ticket after removing everything that happens
> &g
> On 9 Jun., 13:43, François Bissey wrote:
> > > It does take a long time to build compared to most other packages,
> > > which is probably due to the fact the package is large and so has a
> > > lot of source code.
> >
> > Well I am trying that now.
601 - 700 of 813 matches
Mail list logo
