Thanks, Mike. That's very helpful.
Rob
On Apr 17, 10:58 pm, Mike Hansen wrote:
> On Fri, Apr 17, 2009 at 3:49 PM, John H Palmieri
> wrote:
>
> > Since (I believe) it passes doctests without the link directive,
> > removing it *is* the right thing: these verbatim environments are
> > linked d
On Fri, Apr 17, 2009 at 3:49 PM, John H Palmieri wrote:
> Since (I believe) it passes doctests without the link directive,
> removing it *is* the right thing: these verbatim environments are
> linked during doctesting as is, apparently.
>
> It would be good to understand how ".. link::" works, or
On Apr 17, 10:20 pm, William Cauchois
wrote:
Hi Bill,
> I tried sage -t --verbose, and it appears to freeze on the following test:
>
> > Trying:
> > polar_plot([(RealNumber('1.2')+k*RealNumber('0.2'))*log(x) for k in
> > range(Integer(6))], Integer(1), Integer(3) * pi,
> > fill = {Integer(0)
I tried sage -t --verbose, and it appears to freeze on the following test:
> Trying:
> polar_plot([(RealNumber('1.2')+k*RealNumber('0.2'))*log(x) for k in
> range(Integer(6))], Integer(1), Integer(3) * pi,
> fill = {Integer(0): [Integer(1)], Integer(2): [Integer(3)], Integer(4):
> [Integer(5)]}
On Apr 17, 9:27 pm, Rado wrote:
Hi Rado,
> I just realized that my cpu fan wasn't spinning and my CPU was at 90C!
> That my explain the weirdness with my installation. Consider this
> thread closed.
Good to know. I am surprised you didn't have more problems while
building and testing Sage.
I just realized that my cpu fan wasn't spinning and my CPU was at 90C!
That my explain the weirdness with my installation. Consider this
thread closed.
Rado
On Apr 17, 12:04 pm, Rado wrote:
> Here is the original error:
>
> sage -t "devel/sage/sage/finance/time_series.pyx"
> **
On Thu, Apr 9, 2009 at 12:22 AM, Stan Schymanski wrote:
>
> Dear all,
>
> I encountered some mysterious problems earlier when I used .subs(locals
> ()), where some global variables such as pi and e were lost (see. e.g.
> thread
> http://groups.google.com/group/sage-support/browse_thread/thread/0
On Fri, Apr 17, 2009 at 7:08 PM, William Cauchois
wrote:
>
> Hi,
>
> I'm having trouble running the unit tests on "sage/plot/plot.py"
> (using sage -t; this is Sage 3.4). The tests consistently time out
> after about 360 seconds. Is this because my computer is slow (I've got
> a 2.2 GHz Core2 Duo
On Apr 17, 7:08 pm, William Cauchois
wrote:
> Hi,
Hi Bill,
> I'm having trouble running the unit tests on "sage/plot/plot.py"
> (using sage -t; this is Sage 3.4). The tests consistently time out
> after about 360 seconds. Is this because my computer is slow (I've got
> a 2.2 GHz Core2 Duo pro
Hi,
I'm having trouble running the unit tests on "sage/plot/plot.py"
(using sage -t; this is Sage 3.4). The tests consistently time out
after about 360 seconds. Is this because my computer is slow (I've got
a 2.2 GHz Core2 Duo processor and 2 gigs of RAM), or are the unit
tests flawed? Does anyon
On Apr 17, 5:21 pm, Chris Godsil wrote:
> Michael
Hi Chris,
> The compressed install log is athttp://quoll.uwaterloo.ca/install.log.gz
Your build did not finish:
GCC Version
gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5490~1/src/configure --disa
Michael
The compressed install log is at http://quoll.uwaterloo.ca/install.log.gz
Thanks
Chris
On Apr 17, 4:40 pm, mabshoff wrote:
> On Apr 17, 1:12 pm, Chris Godsil wrote:
>
> > Michael
>
> Hi Chris,
>
>
>
>
>
> > I followed your suggestion and then sage compiled without a hitch.
> > Thanks
On Friday 17 April 2009, Kiran Kedlaya wrote:
> Oooh! Support for Z and Z/m as coefficient rings!
>
> Kiran
Yeah, pretty cool. I'm planning to update Singular in Sage while I'm in
Seattle in May (if noone beats me to it that is)
Martin
--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/
On Apr 17, 3:01 pm, Rob Beezer wrote:
> The error that Michael A reported seems to have the space in it, but I
> believe I used the ..link construction somewhere else in that file
> (its on my home machine) and it didn't raise an error, and probably it
> didn't have a space?
Yes, removing the
The error that Michael A reported seems to have the space in it, but I
believe I used the ..link construction somewhere else in that file
(its on my home machine) and it didn't raise an error, and probably it
didn't have a space?
It would be nice to do the right thing (whatever that is), but if i
On Apr 17, 1:43 pm, Rob Beezer wrote:
> On Apr 17, 8:49 am, John Cremona wrote:
>
> > > I think I took care of it in #5808 -- take a quick look if you have a
> > > chance.
>
> > No, after applying #5808 there are still two lines in that file (55
> > and 204) containing "..link::" which should be
On Apr 17, 8:49 am, John Cremona wrote:
> > I think I took care of it in #5808 -- take a quick look if you have a
> > chance.
>
> No, after applying #5808 there are still two lines in that file (55
> and 204) containing "..link::" which should be ".. link::", I think.
> Though I do not know what
On Apr 17, 1:12 pm, Chris Godsil wrote:
> Michael
Hi Chris,
> I followed your suggestion and then sage compiled without a hitch.
> Thanks for this.
>
> In the interim, I have been busy grading, but I was working with sage
> this afternoon
> even though I should still have been grading. As a
Michael
I followed your suggestion and then sage compiled without a hitch.
Thanks for this.
In the interim, I have been busy grading, but I was working with sage
this afternoon
even though I should still have been grading. As a punishment I find
now that the spectrum()
command in the graphs cla
Oooh! Support for Z and Z/m as coefficient rings!
Kiran
On Apr 17, 1:21 pm, William Stein wrote:
> On Fri, Apr 17, 2009 at 10:18 AM, William Stein wrote:
> > Hi Sage-Devel,
>
> > See below -- Singular 3-1-0 has been released.
>
> > Note that their polynomial factorization over GF(p) is still b
On Fri, Apr 17, 2009 at 10:18 AM, William Stein wrote:
> Hi Sage-Devel,
>
> See below -- Singular 3-1-0 has been released.
>
> Note that their polynomial factorization over GF(p) is still broken (I
> try to factor the same polynomial over GF(3) twice and get different
> answers). I'm reporting t
Hi Sage-Devel,
See below -- Singular 3-1-0 has been released.
Note that their polynomial factorization over GF(p) is still broken (I
try to factor the same polynomial over GF(3) twice and get different
answers). I'm reporting this here:
http://www.singular.uni-kl.de/request_form.html
wst...@sa
Here is the original error:
sage -t "devel/sage/sage/finance/time_series.pyx"
**
File "/home/rado/sage-3.4/devel/sage/sage/finance/time_series.pyx",
line 2361:
sage: s.mean()
Expected:
1.354073591877...
Got:
15614865
On Fri, Apr 17, 2009 at 3:35 AM, mabshoff wrote:
[...]
> I am not sure what you refer to, but we either aren't taking about the
> same thing or there is some misunderstanding.
http://groups.google.com/group/sage-devel/browse_thread/thread/a8d89440bdff814b/
>
> What I would like to see is the po
A quick follow-up:
On Apr 17, 2009, at 02:52 , mabshoff wrote:
> On Apr 17, 12:27 am, "Justin C. Walker" wrote:
>> On Apr 16, 2009, at 09:10 , mabshoff wrote:
[snip]
>> preparing documents... WARNING: html_favicon is not an .ico file
As I mentioned in my last note, this warning still occur
2009/4/17 John H Palmieri :
>
>
>
> On Apr 17, 7:35 am, Rob Beezer wrote:
>> On Apr 15, 4:50 am, mabshoff wrote:
>>
>> > Aside from this it would be nice if someone fixed the following.
>> > WARNING: /scratch/mabshoff/sage-3.4.1.rc3/local/lib/python2.5/site-
>> > packages/sage/games/sudoku.py:do
I applied the 'ext' patch and the 'alt sage' patch.
On Apr 17, 2009, at 02:52 , mabshoff wrote:
> On Apr 17, 12:27 am, "Justin C. Walker" wrote:
>> On Apr 16, 2009, at 09:10 , mabshoff wrote:
>>> The bits are as usual in
>>
>>> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.1/
On Apr 17, 7:35 am, Rob Beezer wrote:
> On Apr 15, 4:50 am, mabshoff wrote:
>
> > Aside from this it would be nice if someone fixed the following.
> > WARNING: /scratch/mabshoff/sage-3.4.1.rc3/local/lib/python2.5/site-
> > packages/sage/games/sudoku.py:docstring of
> > sage.games.sudoku.solve_
On Apr 17, 4:35 am, mabshoff wrote:
> Ok, after analyzing all reports here, the build farm on boxen and
> problems on selcted boxen on SkyNet it seems that we have a total of
> four failures introduced in 3.4.1.rc3:
>
> * #5805: Sage 3.4.1.rc3: numerical noise in "devel/sage/sage/modular/
> diri
On Apr 15, 4:50 am, mabshoff wrote:
> Aside from this it would be nice if someone fixed the following.
> WARNING: /scratch/mabshoff/sage-3.4.1.rc3/local/lib/python2.5/site-
> packages/sage/games/sudoku.py:docstring of
> sage.games.sudoku.solve_recursive:66: (ERROR/3) Unknown directive type
> "lin
On Thu, 16 Apr 2009 15:43:41 -0700 (PDT)
Maurizio wrote:
>
> > For people interested in helping out, a few words about integration is
> > in order. As we discussed on this list before, many problems in
> > integration can be handled with heuristics before calling more advanced
> > algorithms. T
On Apr 17, 5:01 am, Pat LeSmithe wrote:
Hi,
> I'm not sure if it helps, but a ticket search yields
>
> http://trac.sagemath.org/sage_trac/ticket/4158
Yes, I am aware of that ticket and unfortunately it does not really
help. Last time this specific problem popped up (around Sage 3.1.4) it
als
I'm not sure if it helps, but a ticket search yields
http://trac.sagemath.org/sage_trac/ticket/4158
mabshoff wrote:
>
>
> On Apr 17, 4:35 am, mabshoff wrote:
>> Ok, after analyzing all reports here, the build farm on boxen and
>> problems on selcted boxen on SkyNet it seems that we have a
simon.k...@uni-jena.de wrote:
> Hi!
>
> On 17 Apr., 09:11, Jason Grout wrote:
>> If you were working on a shared server, then you wouldn't have to email
>> things back to the students. You'd simply "publish" the worksheet back
>> to the student or something.
>
> Please excuse my lack of knowle
On Apr 17, 4:35 am, mabshoff wrote:
> Ok, after analyzing all reports here, the build farm on boxen and
> problems on selcted boxen on SkyNet it seems that we have a total of
> four failures introduced in 3.4.1.rc3:
>
> * #5805: Sage 3.4.1.rc3: numerical noise in "devel/sage/sage/modular/
> di
Ok, after analyzing all reports here, the build farm on boxen and
problems on selcted boxen on SkyNet it seems that we have a total of
four failures introduced in 3.4.1.rc3:
* #5805: Sage 3.4.1.rc3: numerical noise in "devel/sage/sage/modular/
dirichlet.py"
* #5806: Sage 3.4.1.rc3: failing test
On Apr 17, 3:13 am, Ondrej Certik wrote:
> On Fri, Apr 17, 2009 at 2:33 AM, mabshoff wrote:
> > Well, it would happen from my end. I think that in the process we
> > would do some serious cleanup, but the switch over should be quick
> > *if* we do it IMHO.
>
> Yes -- but wait until I have a
Hi!
On 17 Apr., 09:11, Jason Grout wrote:
> If you were working on a shared server, then you wouldn't have to email
> things back to the students. You'd simply "publish" the worksheet back
> to the student or something.
Please excuse my lack of knowledge: What exactly does "publishing a
worksh
On Apr 17, 2:57 am, John Cremona wrote:
> 2009/4/17 mabshoff :
> >> File "/home/john/sage-3.4.1.rc3/devel/sage/sage/modular/dirichlet.py",
> >> line 1044:
> >> sage: e.kloosterman_sum_numerical()
> >> Expected:
> >> 7.21644966006e-16 + 1.73205080757*I
> >> Got:
> >> 5.55111512313
On Fri, Apr 17, 2009 at 2:33 AM, mabshoff wrote:
>
>
>
> On Apr 17, 2:04 am, Ondrej Certik wrote:
>> On Fri, Apr 17, 2009 at 1:07 AM, mabshoff wrote:
>
>
>
>> > Well, I think what we should do is merge as much of SPD into Sage as
>> > possible to lessen the maintainance burden. One thing I cou
On 64-bit Ubuntu (Bill Hart's machine) all tests pass.
John
2009/4/17 John Cremona :
> 2009/4/17 mabshoff :
>>
>> On Apr 17, 12:37 am, John Cremona wrote:
>>
>> Hi John,
>>
>>> On 32-bit ubuntu, after a successful build from scratch:
>>>
>>> The following tests failed:
>>> sage -t "dev
2009/4/17 mabshoff :
>
> On Apr 17, 12:37 am, John Cremona wrote:
>
> Hi John,
>
>> On 32-bit ubuntu, after a successful build from scratch:
>>
>> The following tests failed:
>> sage -t "devel/sage/sage/misc/sagedoc.py"
>
>
> This one has actually been reported - see #5806 - but I would
On Apr 17, 12:27 am, "Justin C. Walker" wrote:
> On Apr 16, 2009, at 09:10 , mabshoff wrote:
> > Hi,
Hi Justin,
> > this is rc3 and it is much larger than I anticipated. Loads of
> > doctests merged, i.e. we are at
> [snip]
>
> > The bits are as usual in
>
> > http://sage.math.washington.edu
On Apr 17, 12:04 am, Ondrej Certik wrote:
> > It is a bug, without looking at the context: Does removing the first
> > hunk fix the problem for you? I am not sure why the hunk was added, it
> > has been a while since I did that review ;)
>
> I just applied the patch that changed f->filename,
On Apr 17, 2:25 am, Prabhu Ramachandran
wrote:
> On 04/17/09 13:37, mabshoff wrote:
>
> > If your plan is still to recreate all scripts to be BSD the above
> > would be more or less pointless, so you need to let us know what you
> > want to do. I really don't want to relicense my code in $SAGE_
On Apr 17, 2:04 am, Ondrej Certik wrote:
> On Fri, Apr 17, 2009 at 1:07 AM, mabshoff wrote:
> > Well, I think what we should do is merge as much of SPD into Sage as
> > possible to lessen the maintainance burden. One thing I could see here
> > is to define SAGE_EXECUTABLE and you would just
On 04/17/09 13:37, mabshoff wrote:
> If your plan is still to recreate all scripts to be BSD the above
> would be more or less pointless, so you need to let us know what you
> want to do. I really don't want to relicense my code in $SAGE_LOCAL/
> bin/sage-$FOO to BSD since the EPD for example has
On Apr 17, 12:37 am, John Cremona wrote:
Hi John,
> On 32-bit ubuntu, after a successful build from scratch:
>
> The following tests failed:
> sage -t "devel/sage/sage/misc/sagedoc.py"
This one has actually been reported - see #5806 - but I would be
surprised if it were a timeout. Do
> part of this is the notebook, which is also GPL. And also I most
> probably will want to include (in my custom modifications of SPD for
> finite elements) some GPL library anyway, like libmesh.sf.net.
Actually, libmesh is LGPL. But maybe I'd use some other program that
is GPL (most electronic s
On Fri, Apr 17, 2009 at 1:07 AM, mabshoff wrote:
>
>
>
> On Apr 17, 12:58 am, Ondrej Certik wrote:
>> On Fri, Apr 17, 2009 at 12:21 AM, mabshoff wrote:
>
>
>
>> > If SAGE_ROOT is already set sage aborts:
>>
>> Ah, so I think I smell where the problem is --- I broke the SAGE_ROOT
>> stuff. Whe
On Apr 17, 12:58 am, Ondrej Certik wrote:
> On Fri, Apr 17, 2009 at 12:21 AM, mabshoff wrote:
> > If SAGE_ROOT is already set sage aborts:
>
> Ah, so I think I smell where the problem is --- I broke the SAGE_ROOT
> stuff. When I fix it, which I have to fix anyway, thing should start
> work
On Fri, Apr 17, 2009 at 12:21 AM, mabshoff wrote:
>
>
>
> On Apr 17, 12:09 am, Ondrej Certik wrote:
>> Hi,
>>
>> why is the notebook trying to execute "sage" that it finds in the
>> path, rather than another copy of the sage that it is running?
>
> Because sage-env assures that the right sage sc
+1
I always wondered why this doesn't work. Forcing
me to remember the syntax for a numerical integral...
> %maxima
> integrate(sqrt(x^3+1),x,2,10), float
> ///
> 'integrate((x^3+1)^0.5,x,2,10)
>
> It would be very nice to have this feature though!
>
> -- William
>
>
>
>
--~--~-~--~
On 32-bit ubuntu, after a successful build from scratch:
The following tests failed:
sage -t "devel/sage/sage/misc/sagedoc.py"
sage -t "devel/sage/sage/modular/dirichlet.py"
The first looks like a timeout. The second has been reported already.
File "/home/john/sage-3.4.1.rc3/
On Apr 16, 2009, at 09:10 , mabshoff wrote:
>
> Hi,
>
> this is rc3 and it is much larger than I anticipated. Loads of
> doctests merged, i.e. we are at
[snip]
>
> The bits are as usual in
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.1/
I built rc3 as an upgrade from rc
On Apr 17, 12:09 am, Ondrej Certik wrote:
> Hi,
>
> why is the notebook trying to execute "sage" that it finds in the
> path, rather than another copy of the sage that it is running?
Because sage-env assures that the right sage script is called, see
below.
> The following patches fix that (fo
Rob Beezer wrote:
> Sorry.
>
> 1. blast, blare -- make a strident sound
> 2. blast, shell -- create by using explosives
> 3. blast-out -- email each student's graded worksheet back to them as
> part of a batch process for the whole class
It seems that the worksheet will have to somehow know the
Hi,
why is the notebook trying to execute "sage" that it finds in the
path, rather than another copy of the sage that it is running?
The following patches fix that (for SPD):
http://github.com/certik/spd_notebook/commit/f0d66f283c4f398927a7e60caeaf9cabfdca77c3
http://github.com/certik/spd_noteb
Rob Beezer wrote:
> On Apr 13, 12:20 am, William Stein wrote:
>> It might also be nice to integrate this with email, I.e., after I
>> grade all the worksheets, I could have sage use its email command to
>> email out all the graded versions of the worksheets back to the
>> students I'm looki
>> - if os.access (filename, os.X_OK):
>> + if os.access (filename, os.X_OK) and not os.path.isdir(f):
>> return filename
>
> Ok, I see the problem now. Sorry for being dense earlier. In Sage that
No problem.
> codepath clearly doesn't seem to be hit.
Yes, clearly that
60 matches
Mail list logo
