On 28 Okt., 02:53, "Justin C. Walker" <[EMAIL PROTECTED]> wrote:
> Hi, Michael,
>
> On Oct 27, 2008, at 18:39 , mabshoff wrote:
>
> > On Oct 27, 4:57 pm, "Justin C. Walker" <[EMAIL PROTECTED]> wrote:
> >> On Oct 26, 2008, at 11:09 PM, mabshoff wrote:
> >> The build on Mac OS X, 10.4.11 (Core 2 D
On Mon, Oct 27, 2008 at 7:21 PM, mabshoff <[EMAIL PROTECTED]> wrote:
>
>
>
> On Oct 27, 7:17 pm, "Mike Hansen" <[EMAIL PROTECTED]> wrote:
>> Hello,
>
> Hi,
>
>> Since this requires a C compiler in order to work anyway, it seems
>> like it should be an optional package.
>
> cough *Cython* cough :)
On Mon, Oct 27, 2008 at 10:15 PM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> \On Oct 27, 2008, at 9:41 PM, Tim Abbott wrote:
>
>> On Oct 28, 12:31 am, "Mike Hansen" <[EMAIL PROTECTED]> wrote:
>>> Hi Tim,
>>>
>>> I assume that we would/should add some other marker to the
>>> filename to
>>> ide
\On Oct 27, 2008, at 9:41 PM, Tim Abbott wrote:
> On Oct 28, 12:31 am, "Mike Hansen" <[EMAIL PROTECTED]> wrote:
>> Hi Tim,
>>
>> I assume that we would/should add some other marker to the
>> filename to
>> identify it as the Sage version of that package rather than the
>> vanilla upstream sourc
Tim Abbott wrote:
[...]
> However, I think this is a good opportunity to discuss whether the merits
> of the .spkg extension for Sage packages. Fundamentally, we're using a
> nonstandard extension for a standard file type. This breaks various tools
> that try to infer file types from extensio
On Oct 28, 12:31 am, "Mike Hansen" <[EMAIL PROTECTED]> wrote:
> Hi Tim,
>
> I assume that we would/should add some other marker to the filename to
> identify it as the Sage version of that package rather than the
> vanilla upstream source.
Yeah, that's an issue I probably should have mentioned in
Hi Tim,
On Mon, Oct 27, 2008 at 9:19 PM, Tim Abbott <[EMAIL PROTECTED]> wrote:
> So, I'd like to get people's opinions on moving to standard .tar.bz2
> extensions for spkg archives.
>
> If people think it's a good idea in principle, I'll work on generating a
> patch for gracefully handling the tr
I've recently learned that one factor contributing to the long review
delay for the Debian sagemath package has been the fact that their tools
for reviewing packages for copyright issues weren't able to open ".spkg"
files (they do handle .tar.bz2 files correctly, but apparently detect file
typ
> Also one could like to do similar computations for instance with Dedekind
> zeta function of a number fileld, something like...
>
> sage: K. = QuadraticField(2)
> sage: Z.DedekindZeta()
> sage: Z.zeros(10)
it would be
sage: K. = QuadraticField(2)
sage: Z=K.DedekindZeta()
sage: Z.zeros(10)
Pa
Hi,
I'm reading the notes of William's talk "Three Lectures about Explicit
Methods in Number Theory Using Sage", that are indeed very interesting.
It comments that Sage includes functionallity to compute the zeros of L-series
of elliptic curves, by doing
sage: E = EllipticCurve(’389a1’)
sage
On Oct 27, 7:17 pm, "Alex Ghitza" <[EMAIL PROTECTED]> wrote:
Hi Alex,
> Built fine on
>
> Linux artin 2.6.27-ARCH #1 SMP PREEMPT Fri Oct 17 07:35:10 UTC 2008 i686
> Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz GenuineIntel GNU/Linux
Ok.
> (yes I'm giving archlinux a try; btw i had no problems wi
On Oct 27, 7:17 pm, "Mike Hansen" <[EMAIL PROTECTED]> wrote:
> Hello,
Hi,
> Since this requires a C compiler in order to work anyway, it seems
> like it should be an optional package.
cough *Cython* cough :)
> For those that use it, it
> seems like doing an extra "sage -i" isn't asking for t
Built fine on
Linux artin 2.6.27-ARCH #1 SMP PREEMPT Fri Oct 17 07:35:10 UTC 2008 i686
Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz GenuineIntel GNU/Linux
(yes I'm giving archlinux a try; btw i had no problems with gfortran on
archlinux, contrary to a recent build problem report on sage-support).
Hello,
Since this requires a C compiler in order to work anyway, it seems
like it should be an optional package. For those that use it, it
seems like doing an extra "sage -i" isn't asking for that much. The
code to make it easy to use from Sage should still go into the main
library.
--Mike
--
I've submited a patch for integrating gp2c into sage
gp2c is a program that converts a gp script into a C program.
description of my patch
"This patch implements two functions for the Gp object: gp2c_compile_file and
gp2c
The first one compiles a file using gp2c-run and load its into the i
Hi, Michael,
On Oct 27, 2008, at 18:39 , mabshoff wrote:
> On Oct 27, 4:57 pm, "Justin C. Walker" <[EMAIL PROTECTED]> wrote:
>> On Oct 26, 2008, at 11:09 PM, mabshoff wrote:
>> The build on Mac OS X, 10.4.11 (Core 2 Duo) failed building sage-
>> spkg. Apparently, I had no CPUs when this blew :-
On Oct 27, 4:53 pm, Jaap Spies <[EMAIL PROTECTED]> wrote:
> Jaap Spies wrote:
> > mabshoff wrote:
> >> Oops, as usual sources as well as a sage.math binary are in
>
> >>http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2/
Hi Jaap,
> > On Fedora 9, 32 bits:
>
> > The following test
On Oct 27, 4:57 pm, "Justin C. Walker" <[EMAIL PROTECTED]> wrote:
> On Oct 26, 2008, at 11:09 PM, mabshoff wrote:
>
Hi Justin,
>
> > Oops, as usual sources as well as a sage.math binary are in
>
> >http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2/
>
> The build on Mac OS X, 10.
On Oct 26, 2008, at 11:09 PM, mabshoff wrote:
>
> Oops, as usual sources as well as a sage.math binary are in
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2/
The build on Mac OS X, 10.4.11 (Core 2 Duo) failed building sage-
spkg. Apparently, I had no CPUs when this blew
Jaap Spies wrote:
> mabshoff wrote:
>> Oops, as usual sources as well as a sage.math binary are in
>>
>> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2/
>>
>
> On Fedora 9, 32 bits:
>
> The following tests failed:
>
>
> sage -t devel/sage/sage/plot/plot.py
> sage
mabshoff wrote:
> Oops, as usual sources as well as a sage.math binary are in
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2/
>
On Fedora 9, 32 bits:
The following tests failed:
sage -t devel/sage/sage/plot/plot.py
sage -t devel/sage/sage/combinat/root
Hi Robert and all who attend this thread,
well, since we just can't fix the path search behaviour in Python's
sys module, I headed for a pragmatic workaround.
I just attached a first patch to #4366. (Hah. My very first Sage
patch.)
This needs a bit more work, but already all doctests pass.
Any
Whle doing a program, i found a problem when trying to compute the
syzygy module of an ideal of polynomials over the complexes.
Here is the code tha showed the error:
R.=PolynomialRing(CC)
config2=(x^2+8*y^2+21*x*y-x*z-8*y*z)*(x^2+5*y^2+13*x*y-
x*z-5*y*z)*(x^2+9*y^2-4*x*y-x*z-9*y*z)*(x^2+11*y^2
On Mon, Oct 27, 2008 at 2:14 PM, mabshoff <[EMAIL PROTECTED]> wrote:
>
>
>
> On Oct 27, 11:10 am, "David Joyner" <[EMAIL PROTECTED]> wrote:
>> On amd64 hardy heron, build went fine but there were a lot of errors
>> in sage -testall.
>> log posted tohttp://sage.math.washington.edu/home/wdj/patches/
On Oct 27, 11:47 am, mcelis <[EMAIL PROTECTED]> wrote:
> Forgot to mention it is SAGE 3.1.4
>
> On Oct 27, 11:44 am, mcelis <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> > I am trying to build SAGE on a SiCortex machine with MIPS processors
> > running Linux Gentoo Base System release 1.12.12.
> >
Forgot to mention it is SAGE 3.1.4
On Oct 27, 11:44 am, mcelis <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am trying to build SAGE on a SiCortex machine with MIPS processors
> running Linux Gentoo Base System release 1.12.12.
>
> The build/install for libpari-gmp failed (results below). I believe it
>
Hi,
I am trying to build SAGE on a SiCortex machine with MIPS processors
running Linux Gentoo Base System release 1.12.12.
The build/install for libpari-gmp failed (results below). I believe it
is because -lgmp gets built using -n32 while libpari-gmp is being
built with the default n64. Is there
On amd64 hardy heron, build went fine but there were a lot of errors
in sage -testall.
log posted to
http://sage.math.washington.edu/home/wdj/patches/test.log
On Mon, Oct 27, 2008 at 1:31 AM, mabshoff <[EMAIL PROTECTED]> wrote:
>
> Hello folks,
>
> here goes 3.2.alpha1. We merged a lot of fixes a
On Oct 27, 11:10 am, "David Joyner" <[EMAIL PROTECTED]> wrote:
> On amd64 hardy heron, build went fine but there were a lot of errors
> in sage -testall.
> log posted tohttp://sage.math.washington.edu/home/wdj/patches/test.log
The devel repo is broken - run "hg update -C" in $SAGE_ROOT/devel/
s
On Oct 27, 11:01 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 27, 2008 at 10:09 AM, mabshoff <[EMAIL PROTECTED]> wrote:
>
> > On Oct 27, 8:01 am, "John Cremona" <[EMAIL PROTECTED]> wrote:
> >> The following tests failed:
>
> > Hi John,
>
> >> sage -t devel/sage/sage/int
On Mon, Oct 27, 2008 at 10:09 AM, mabshoff <[EMAIL PROTECTED]> wrote:
>
>
>
> On Oct 27, 8:01 am, "John Cremona" <[EMAIL PROTECTED]> wrote:
>> The following tests failed:
>
> Hi John,
>
>>sage -t devel/sage/sage/interfaces/sage0.py
>> sage -t devel/sage/sage/tests/book_stein_en
On Oct 27, 8:01 am, "John Cremona" <[EMAIL PROTECTED]> wrote:
> The following tests failed:
Hi John,
> sage -t devel/sage/sage/interfaces/sage0.py
> sage -t devel/sage/sage/tests/book_stein_ent.py
>
> The first passed on second separate run.
Ok.
> The second does this:
>
On Oct 26, 2008, at 2:15 PM, Georg S. Weber wrote:
>
> Hi,
>
> I know now how to change the code so that when we had before:
>
> sage: time for i in range(10^4): float(1)/2
> CPU times: user 17.72 s, sys: 13.44 s, total: 31.16 s
> Wall time: 31.20 s
>
> then after the changes we get:
>
> sage: ti
On Oct 26, 2008, at 23:09 , mabshoff wrote:
>
> Oops, as usual sources as well as a sage.math binary are in
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2/
Mac OS X, 10.5.5, Dual Quad Xeon:
Built w/o problems, one test failed:
sage -t devel/sage/sage/algebras/group_algeb
The following tests failed:
sage -t devel/sage/sage/interfaces/sage0.py
sage -t devel/sage/sage/tests/book_stein_ent.py
The first passed on second separate run.
The second does this:
sage -t devel/sage/sage/tests/book_stein_ent.py
*
2008/10/27 Jaap Spies <[EMAIL PROTECTED]>:
>
> John Cremona wrote:
>> 2008/10/27 mabshoff <[EMAIL PROTECTED]>:
>>>
>>>
>>> On Oct 27, 5:29 am, "John Cremona" <[EMAIL PROTECTED]> wrote:
Built fine but _every_single_ test failed which all seem to look like this:
jinja.exceptions.Templ
John Cremona wrote:
> 2008/10/27 mabshoff <[EMAIL PROTECTED]>:
>>
>>
>> On Oct 27, 5:29 am, "John Cremona" <[EMAIL PROTECTED]> wrote:
>>> Built fine but _every_single_ test failed which all seem to look like this:
>>>
>>> jinja.exceptions.TemplateNotFound: login.html
>>>
>>> A mysterious error (pe
2008/10/27 mabshoff <[EMAIL PROTECTED]>:
>
>
>
> On Oct 27, 5:29 am, "John Cremona" <[EMAIL PROTECTED]> wrote:
>> Built fine but _every_single_ test failed which all seem to look like this:
>>
>> jinja.exceptions.TemplateNotFound: login.html
>>
>> A mysterious error (perphaps a memory error?) occu
On Oct 27, 5:29 am, "John Cremona" <[EMAIL PROTECTED]> wrote:
> Built fine but _every_single_ test failed which all seem to look like this:
>
> jinja.exceptions.TemplateNotFound: login.html
>
> A mysterious error (perphaps a memory error?) occurred, which may have
> crashed doctest.
> [
Built fine but _every_single_ test failed which all seem to look like this:
jinja.exceptions.TemplateNotFound: login.html
A mysterious error (perphaps a memory error?) occurred, which may have
crashed doctest.
[0.8 s]
[EMAIL PROTECTED] /proc/version
Linux version 2.6.16.60-0.29-smp ([E
Minh Nguyen wrote:
> Hi folks,
[...]
I've cleaned up my previous posts to this thread and rewritten them as a
post on my blog. You can find it at
http://mvngu.wordpress.com/2008/10/27/sage-301-reviewed-in-lxf/
That post contains a link to this thread so that readers can follow the
discussion.
41 matches
Mail list logo