I ran into a couple of things while creating a script to install some
optional packages.
pil-1.1.6 is listed as an optional package and pil-1.1.6.p2 is listed
as standard. The optional one can be dropped?
A couple of optional packages have multiple versions.
$ sage -c "install_package('pyx')"
Po
On Dec 10, 8:58 am, Nathann Cohen wrote:
> Hello everybody !!!
>
> I recently had to write two very easy lines of python, and I wondered
> if there was ( there is ) a better way to write them. The problem is
> easy : I have a list A, a list B whose elements all belong to A, and I
> want to retur
I install this every time.
[ X] Yes!
Adam
--
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...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http
On Nov 13, 9:34 am, Martin Rubey
wrote:
> > NOT INSTALLED:
> > fricas-1.0.3.p0
>
> this is ancient! (should be 1.0.8 meanwhile) Although, I admit I have
> no idea whether anybody has built a 1.0.8 package yet.
>
> > 2) checking for noweave... no
> > axiom_build_bindir =
> > /export/home/drkirk
>
> Do we know why the '-L' option is used once?
>
> "cp -L$OPT devel/sage-main "$TMP"/devel/sage-main"
>
> I read the POSIX standard, and although this is a required option, I can't
> really work out exactly what the option is supposed to do. To quote from the
> 2004 standard:
>
> --
On Oct 24, 11:38 am, Maurizio wrote:
> > I have been wondering whether we should start over and create a
> > (fairly minimal) ubuntu 9.10 install using squashfs and unionfs? What
> > do you think? There are a lot of good ideas in the approach of Puppy
> > Linux... but that doesn't mean we act
>
> I believe there will be an ECL release any day now. One was made
> earlier this week I believe, but it had a serious problem. I've no
> idea if any hard-coded paths were found and fixed in the last release.
>
> dave
I did a quick build and check with ecl-10.0.2 and the hard-coded paths
are s
Hi,
There have been a couple of requests on sage-support in regards to
Gnuplot.py. The current package was broken in the upgrade to Python
2.6. The new version Gnuplot.py 1.8 works with Python 2.6 and has some
updates with respect to Numpy. This is now Trac #7187 and there is a
new package at htt
I have put up a new package at
http://sage.math.washington.edu/home/awebb/biopython-1.52.p0.spkg
if someone would like to review it.
Adam
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send
On Oct 10, 7:38 pm, Robert Bradshaw
wrote:
> There is an #optional directive one can pyt on doctests so they get
> run (and output tested) only if the user has installed the package.
> Sounds like that's what we should be using here.
>
> - Robert
>
Unfortunately, these are not run by Sage
I decided to try patching the test but I now realise that test_Wise.py
is not actually the problem. In fact since I don't have the WISE2
software installed that test is skipped. The actual test is in the doc
string of the module.
"""
>>> os.environ["WISE_KBYTE"]="30"
>>> _build_align
On Oct 9, 10:24 pm, Marshall Hampton wrote:
> One alternative would be to patch the test_Wise.py file so that
> instead of
>
> self.assert_(sys.stdout.getvalue().startswith("dnal -kbyte 10
> seq1.fna seq2.fna"))
>
> within test_dnal we'd have
>
> self.assert_(sys.stdout.getvalue().startswit
Hi all,
I am playing around with the new biopython spkg (1.52). In particular,
I would like to have a spkg-check script to run the included tests.
This mostly works and the test skips testing modules that are not
installed. I am having one problem however. I get a failure with one
test.
>
> Sage 4.1.2.rc0 build and pass all doctests (also with the "-long"
> option) on the following platforms:
>
> * eno: 64-bit Fedora 9 with GCC 4.4.1
> * lena: 64-bit Red Hat Enterprise Linux Server 5.3 with GCC 4.4.1
> * menas: 64-bit openSUSE 11.1 with GCC 4.4.1
> * rosemary: 64-bit Red Hat Ent
On Sep 18, 8:35 pm, RProgrammer wrote:
> install.log is the "relevant part of the install log"
> sage.out is the result of copying and pasting the error text from the
> terminal.
>
Hi,
I was not able to download your log file but I tried to install it
myself and got an error that I hope is th
> Aldor is the "second generation" alternative to the Spad compiler. It
> is not part of FriCAS because of different (non-free) license
> restrictions. The aldor interface itself is part of FriCAS but it is
> only built by default if Aldor is first separately installed on the
> same computer.
>
> --
>
> Looking at the code I can see this is because the fricas.py interface
> (which depends on the axiom.py interface) assumes that the type will
> be expressed as a fully parenthesized string like this:
>
> Polynomial(Fraction(Integer))
>
> but this only applies in later versions of FriCAS
On Aug 27, 2:40 am, Bill Page wrote:
> This used to work. Is it a known problem?
>
> The traceback does not make much sense to me. I guess a lot has
> changed in this code since sage-3.4
>
> I would appreciate any help/suggestions for debugging.
>
> Thanks.
>
This is a known problem. The patch
>
> IMO, we should definitely upgrade to the latest versions of both.
> Could you please give the number (roughly) of doctest failures in all?
>
> Best,
> Golam
After running sage -testall, I got ~60 failures which sounds like a
lot. Not all are in maxima.py. However, many seem to be changes in
On Jul 18, 9:36 pm, "Dr. David Kirkby"
wrote:
> Dr. David Kirkby wrote:
>
> > Are you compiling this as 64-bit code? If so, then I would expect this.
> > Can you try as 32-bit code.
>
> try
>
> $ gcc -m32 that-code.c
Okay, that did it. As 32-bit code I get no warning and the output is:
$ ./te
On Jul 18, 5:09 pm, "Dr. David Kirkby"
wrote:
> I'd be interested what you get if you build this program, which was
> written by one of the gcc guys to try to get to the bottom of this issue
> with mpfr not building.
>
I get a warning. The program runs but not much output. This is on an
AMD-
Hi all,
I have opened a ticket for an update to the optional package fricas
(#6517). This is based on the current package and previous discussion.
This is the first spkg that I have posted on trac so I hope that is
more or less correct and ready for review.
Related patches are at trac #6318 which
I am have been looking into the many errors reported in trac #6318
(http://trac.sagemath.org/sage_trac/ticket/6318). Most seem to be due
to only one problem, namely passing Sage symbolic expressions. This
has been mentioned elsewhere:
http://groups.google.com/group/sage-devel/browse_thread/thread
> > I think Bill will not object if this time you do what he did.
>
> :-)
>
> Indeed I would be very happy and appreciative if someone else took
> care of this! I think it would be a good idea to co-ordinate this on
> the sage-devel list. If you feel motivated you could make use of Sage
> trac bu
>
> > Another thing that does not work is "sage -
> > lisp" which gave the clisp prompt. I found this rather convenient
> > since I could just use the clisp within sage. Is there any plan/
> > interest to switch the this lisp interface to ecl? Does ecl use
> > readline?
>
> For now you can at lea
On Jun 14, 3:57 pm, William Stein wrote:
> Hi,
>
> In case anybody cares about the optional Sage polymake spkg, I've
> moved it from optional to experimental, since it doesn't work at all.
> See below. Also, note that the fricas spkg no longer works (unless
> the user has clisp systemwide)
26 matches
Mail list logo
