On Jun 10, 2010, at 8:17 PM, Jason Grout wrote:
On 6/10/10 12:25 PM, Florent Hivert wrote:
Hi There,
I'd like to discuss a design question. Some time ago Adrien
Boussicault and
myself started to write some experimental code for copy-on-write in
Sage/Python. The idea is now more or
On Jun 9, 2010, at 4:36 PM, Dr. David Kirkby wrote:
I think this is such good news, that even those on sage-devel will
not mind too much! Building packages in parallel seems to be working
very well. That said, wtih 128 hardware threads, still only a small
fraction of 't2' is being used
On 06/10/2010 04:49 PM, Jason Grout wrote:
There seem to be a lot of loose ends left hanging when a sage directory
is moved. For example, I usually compile Sage on a ramdisk, and then
move it to my home directory.
[snip]
It seems common knowledge in Sage that you can compile Sage and move
On Thu, Jun 10, 2010 at 11:48 PM, Ivan Andrus darthand...@gmail.com wrote:
I don't think that's actually the case. If the disk image we
distribute is HFS+ it should allow us to hard link directories so that
each application can have it's own copy of the sage directory, without
any real
On 6/11/10 1:09 AM, Ralf Hemmecke wrote:
On 06/10/2010 04:49 PM, Jason Grout wrote:
There seem to be a lot of loose ends left hanging when a sage directory
is moved. For example, I usually compile Sage on a ramdisk, and then
move it to my home directory.
[snip]
It seems common knowledge in
On Thu, Jun 10, 2010 at 10:58 PM, Robert Bradshaw
rober...@math.washington.edu wrote:
On Jun 10, 2010, at 8:17 PM, Jason Grout wrote:
On 6/10/10 12:25 PM, Florent Hivert wrote:
Hi There,
I'd like to discuss a design question. Some time ago Adrien Boussicault
and
myself started to
On 6/11/10 1:50 AM, William Stein wrote:
Copy on write *should* be rather easy to implement for matrices at least.
William indicates otherwise in [1]. I can't think of an easy way to do
it either, so I'm really curious what how you think it would be easy.
Just out of curiosity, is this
On Fri, Jun 11, 2010 at 12:19 AM, Jason Grout
jason-s...@creativetrax.com wrote:
On 6/11/10 1:50 AM, William Stein wrote:
Copy on write *should* be rather easy to implement for matrices at least.
William indicates otherwise in [1]. I can't think of an easy way to do it
either, so I'm really
Hi David,
On Fri, Jun 11, 2010 at 7:21 AM, Dr. David Kirkby
david.kir...@onetel.net wrote:
SNIP
I think their test procedures are a bit over the top, but it certainly
brings in to perspective how some developers feel about testing.
More testing is good. The SQLite team certainly has a good
On 6/11/10 2:44 AM, William Stein wrote:
On Fri, Jun 11, 2010 at 12:19 AM, Jason Grout
jason-s...@creativetrax.com wrote:
On 6/11/10 1:50 AM, William Stein wrote:
Copy on write *should* be rather easy to implement for matrices at least.
William indicates otherwise in [1]. I can't think of
Hi Robert,
Rob and I were just talking yesterday how it's so inconvenient that
identity_matrix() now returns an immutable matrix, so constructing
something from it involves making a copy, which is not the most obvious
thing to a new person, or the most elegant thing to someone that
They can go in separate files, files which, for example, are not
included in the reference manual. The file sage/homology/tests.py is
an example. Each function should have doctests (so the goal is still
100% coverage), but it's not a big deal to relegate lots of technical
test to less
Hi There,
We don't even ensure that every statement of code
gets executed at least once.
Mike Hansen posted some code to use a tool to check that (a long time
ago). I imagine that after doctest coverage is up to 100% function
coverage that there will be a new push to then get the
Hi David,
On Fri, Jun 11, 2010 at 8:32 AM, Dr. David Kirkby
david.kir...@onetel.net wrote:
SNIP
Consider two areas
# interfaces/tachyon.py: 0% (0 of 4)
# graphs/generic_graph.py: 99% (200 of 201)
Where would it be most useful to add one doc test?
At least from my very little
Hi Simon,
On Fri, Jun 11, 2010 at 9:38 AM, Simon King simon.k...@nuigalway.ie wrote:
SNIP
Anyway, I am +1 to trying and getting a 90% overall doc test coverage;
it is a valuable aim.
IMO it is *always* worth it to write doc tests since it is very likely
to uncover flaws (in particular if
Hi Florent,
On Fri, Jun 11, 2010 at 10:07 AM, Florent Hivert
florent.hiv...@univ-rouen.fr wrote:
SNIP
They all looks like they should be deprecated and removed... If it's true I
rather improving the doctest coverage by removing them than adding
doctests... However I'd like to have the
On 11 June, 04:32, Jason Grout jason-s...@creativetrax.com wrote:
On 6/10/10 6:46 PM, Dr. David Kirkby wrote:
Yes, it should, but it does not. I mentioned this on sage-solaris the
other day, though of course very few people read that, so nobody replied
On 6/11/10 4:19 AM, Minh Nguyen wrote:
Hi Florent,
On Fri, Jun 11, 2010 at 10:07 AM, Florent Hivert
florent.hiv...@univ-rouen.fr wrote:
SNIP
They all looks like they should be deprecated and removed... If it's true I
rather improving the doctest coverage by removing them than adding
Hi kcrisman,
On Fri, Jun 11, 2010 at 11:19 AM, kcrisman kcris...@gmail.com wrote:
SNIP
But we do want doctests to test a fairly large number of the options,
so just adding doctest coverage isn't enough. The doctests need to
really test, as you say. Getting in more of the framework tests in
Hi Jason,
On Fri, Jun 11, 2010 at 7:30 PM, Jason Grout
jason-s...@creativetrax.com wrote:
SNIP
60 months old?? How about 6-12 months?
It's = 6 months old. You know what I mean :-)
--
Regards
Minh Van Nguyen
--
To post to this group, send an email to sage-devel@googlegroups.com
To
Hi Minh,
They all looks like they should be deprecated and removed... If it's true I
rather improving the doctest coverage by removing them than adding
doctests... However I'd like to have the confirmation that they are indeed
obsolete...
We are aiming for a Sage 5.0 release. The
On 11 June 2010 07:00, Robert Bradshaw rober...@math.washington.edu wrote:
On Jun 9, 2010, at 4:36 PM, Dr. David Kirkby wrote:
I think this is such good news, that even those on sage-devel will not
mind too much! Building packages in parallel seems to be working very well.
That said, wtih 128
Hi Florent,
On Fri, Jun 11, 2010 at 7:33 PM, Florent Hivert
florent.hiv...@univ-rouen.fr wrote:
SNIP
I like this way of seeing. However, I was speaking about module or functions
which are not tested nor deprecated and nowhere used into sage (easy to check
using grep). Does it make sens
Hi Robert,
On Fri, Jun 11, 2010 at 12:34 PM, Robert Miller r...@rlmiller.org wrote:
Minh,
Can you make a report which lists the files which, if brought up to
100% coverage, would benefit overall coverage the most?
Here is my understanding of what you want. Let's say the Sage
community has
Hi Andrey,
On Fri, Jun 11, 2010 at 2:47 PM, Andrey Novoseltsev novos...@gmail.com wrote:
SNIP
Where should such tests go? I am not sure that it is desirable to show
50 sophisticated examples for a single function in the interactive or
compiled help. On the other hand, I really like when all
Hi,
Where should such tests go? I am not sure that it is desirable to show
50 sophisticated examples for a single function in the interactive or
compiled help. On the other hand, I really like when all the tests are
right next to the body of the function. Is it possible to, say,
Hi,
I like this way of seeing. However, I was speaking about module or functions
which are not tested nor deprecated and nowhere used into sage (easy to
check
using grep). Does it make sens to remove them without a deprecation warning
?
Many code seems to had been put here, just
Minh,
On Fri, Jun 11, 2010 at 2:49 AM, Minh Nguyen nguyenmi...@gmail.com wrote:
Here is my understanding of what you want. Let's say the Sage
community has enough time to write tests for 20 modules. Which 20
modules could we choose to write tests for such that it results in the
greatest
On 11 Jun., 08:43, Jason Grout jason-s...@creativetrax.com wrote:
On 06/10/2010 04:49 PM, Jason Grout wrote:
There seem to be a lot of loose ends left hanging when a sage directory
is moved. For example, I usually compile Sage on a ramdisk, and then
move it to my home directory.
Honestly I can't see much use for a or b, especially since if you want
to use the command line, you probably don't need us to hold your hand,
and you probably aren't using Terminal.app anyway.
Definitely using Terminal.app :) But your main point is right.
I think there was some talk of
Hi Florent,
On Fri, Jun 11, 2010 at 9:32 PM, Florent Hivert
florent.hiv...@univ-rouen.fr wrote:
SNIP
sage/monoids/monoid.py
I think this module should stay put. Here is a dependency chart based
on that module:
monoids.monoid.Monoid_class -- monoids.free_monoid.FreeMonoid_class
--
On Jun 11, 2:46 am, Florent Hivert florent.hiv...@univ-rouen.fr
wrote:
They can go in separate files, files which, for example, are not
included in the reference manual. The file sage/homology/tests.py is
an example. Each function should have doctests (so the goal is still
100%
On Jun 10, 2010, at 11:50 PM, William Stein wrote:
On Thu, Jun 10, 2010 at 10:58 PM, Robert Bradshaw
rober...@math.washington.edu wrote:
On Jun 10, 2010, at 8:17 PM, Jason Grout wrote:
On 6/10/10 12:25 PM, Florent Hivert wrote:
Hi There,
I'd like to discuss a design question. Some
On Jun 11, 2010, at 1:42 AM, Florent Hivert wrote:
Hi Robert,
Rob and I were just talking yesterday how it's so inconvenient that
identity_matrix() now returns an immutable matrix, so constructing
something from it involves making a copy, which is not the most
obvious
thing to a new
On Jun 11, 2010, at 7:57 AM, Andrey Novoseltsev wrote:
On Jun 11, 2:46 am, Florent Hivert florent.hiv...@univ-rouen.fr
wrote:
They can go in separate files, files which, for example, are not
included in the reference manual. The file sage/homology/
tests.py is
an example. Each function
Hi Minh,
Thanks for carefully investigating those:
sage/monoids/monoid.py
I think this module should stay put. Here is a dependency chart based
on that module:
monoids.monoid.Monoid_class -- monoids.free_monoid.FreeMonoid_class
-- monoids.string_monoid.StringMonoid_class
where
On Jun 11, 2010, at 2:33 AM, Florent Hivert wrote:
Hi Minh,
They all looks like they should be deprecated and removed... If
it's true I
rather improving the doctest coverage by removing them than adding
doctests... However I'd like to have the confirmation that they
are indeed
Hi Andrey,
They can go in separate files, files which, for example, are not
included in the reference manual. The file sage/homology/tests.py is
an example. Each function should have doctests (so the goal is still
100% coverage), but it's not a big deal to relegate lots of
Before hitting delete, this is not really about Solaris!
A build problem was recently discovered on Solaris where R fails to build some
modules (Matrix, class, mgcv, rpart, spatial and survival).
http://trac.sagemath.org/sage_trac/ticket/9201
This is not a fatal error, so R reports it has
Obviously grid works on Solaris, otherwise the doctest would faiil, but
Matrix, class, mgcv, rpart, spatial and survival will not. Hence it would be
desirable to have tests for these - either as extra documentation, or as tests
which don't don't get in the manual.
Which is why you opened
On 06/11/10 05:47 PM, kcrisman wrote:
Obviously grid works on Solaris, otherwise the doctest would faiil, but
Matrix, class, mgcv, rpart, spatial and survival will not. Hence it would be
desirable to have tests for these - either as extra documentation, or as tests
which don't don't get in the
Thanks for the response! We'll try to disable it for now, and
investigate some of the other things mentioned in this thread.
The problem we have is that we need to provide something like CC/CXX
flags, as the only compiler we can guarantee is the one which we
install, which is installed in a
Which is why you opened the ticket. The discussion there isn't
suggesting we shouldn't clear bugs, simply that there isn't a
canonical place for putting this sort of test (not that I'm aware of,
perhaps there is).
I was not implying the discussion was that we should not clear the bug.
On 06/11/10 06:54 PM, kcrisman wrote:
Testing every single installed package could be
quite tricky, as likely the packages change in various spkgs over
time, but sometimes in subtle ways that an updater of an spkg wouldn't
be aware of.
Well, it might be tricky, but at least the person
On 06/11/10 06:34 PM, Matthew Gwynne wrote:
Thanks for the response! We'll try to disable it for now, and
investigate some of the other things mentioned in this thread.
The problem we have is that we need to provide something like CC/CXX
flags, as the only compiler we can guarantee is the one
I would expect that when one evaluates a polynomial, only the coercion
properties of the *base ring* of the polynomial ring relative to the
ring of definition of the evaluation point are important, but the
example below gave me an unexpected negative answer.
The fact that R is has an automatic
Dear sage-devel,
Calculating the Taylor expansion of gamma functions sometimes causes
an error. For example, this is correct:
sage: taylor(gamma(1/2+x),x,0,2)
1/4*(pi^2 + 2*euler_gamma^2 + 8*euler_gamma*log(2) +
8*log(2)^2)*sqrt(pi)*x^2 - (euler_gamma + 2*log(2))*sqrt(pi)*x +
sqrt(pi)
but this
On 06/11/10 05:11 PM, Dr. David Kirkby wrote:
In fact. ALL these generate errors on Solaris.
sage: r.library('Matrix')
sage: r.library('class')
sage: r.library('mgcv')
sage: r.library('rpart')
sage: r.library('spatial')
sage: r.library('survival')
I just checked that the earlier version of R
Nils,
See http://trac.sagemath.org/sage_trac/ticket/8502. I had found that,
depending on the base ring, the result of evaluating all the variables
was sometimes in the coefficient ring and sometimes a (constant)
polynomial. So I fixed it -- I think. But the result is clearly not
perfect.
John
I've recently started using numpy more seriously, and i've made sage
wrappers (that is sage functions that simply call numpy to do the job)
for numpy's fast fourier transform and polynomial fit. I thought those
might get included in sage, but the start of sage is already quite slow.
My guess
Hi!
On 11 Jun., 18:47, kcrisman kcris...@gmail.com wrote:
... Testing every single installed package could be
quite tricky, as likely the packages change in various spkgs over
time, but sometimes in subtle ways that an updater of an spkg wouldn't
be aware of.
Perhaps each interface to
On Jun 11, 12:44 pm, John Cremona john.crem...@gmail.com wrote:
Nils,
Seehttp://trac.sagemath.org/sage_trac/ticket/8502. I had found that,
depending on the base ring, the result of evaluating all the variables
was sometimes in the coefficient ring and sometimes a (constant)
polynomial. So
I know nothing about Solaris or what might be causing this problem,
but if you put these two lines into a script called TestPackages.R
packages - rownames(installed.packages())
for(i in seq_along(packages)) stopifnot(require(packages[i],
character.only = TRUE))
and then put something like
R
On 11 June 2010 20:55, Nils Bruin nbr...@sfu.ca wrote:
On Jun 11, 12:44 pm, John Cremona john.crem...@gmail.com wrote:
Nils,
Seehttp://trac.sagemath.org/sage_trac/ticket/8502. I had found that,
depending on the base ring, the result of evaluating all the variables
was sometimes in the
Hi Ben!
On 11 Jun., 21:56, Ben Goodrich goodrich@gmail.com wrote:
...
and then put something like
R --vanilla TestPackages.R TestOutput.txt
at the end of the shell script that installs R, it will fail if any
installed R package fails to load properly and something informative
will
On Jun 11, 3:56 pm, Ben Goodrich goodrich@gmail.com wrote:
I know nothing about Solaris or what might be causing this problem,
but if you put these two lines into a script called TestPackages.R
packages - rownames(installed.packages())
for(i in seq_along(packages))
On 10 June, 15:42, Nathann Cohen nathann.co...@gmail.com wrote:
Hello everybody
I have been willing for some time to implement a recognition algorithm
for Interval Graphs [1], and I ended up forgetting to sleep one
evening to have it done in the morning. :-)
What I now have is an
On Jun 11, 12:59 pm, John Cremona john.crem...@gmail.com wrote:
All I really meant was that the function giving your problem has also
given other problems, which have been fixed in it, but that is
certainly the place to look for someone fixing your bug.
It looks like other people consider
On 06/11/10 09:28 PM, Ben Goodrich wrote:
On Jun 11, 3:56 pm, Ben Goodrichgoodrich@gmail.com wrote:
I know nothing about Solaris or what might be causing this problem,
but if you put these two lines into a script called TestPackages.R
packages- rownames(installed.packages())
for(i in
On Jun 11, 5:29 pm, Dr. David Kirkby david.kir...@onetel.net
wrote:
Given actually reading in these 6 libraries takes very little time, it would
not
seem unreasonable to me to make a test that they actually import properly part
of the normal doctests that people run each time people test
On Jun 11, 2010, at 12:52 PM, Oscar Gerardo Lazo Arjona wrote:
I've recently started using numpy more seriously, and i've made sage
wrappers (that is sage functions that simply call numpy to do the
job) for numpy's fast fourier transform and polynomial fit. I
thought those might get
On Jun 11, 2010, at 4:41 PM, Robert Bradshaw wrote:
On Jun 11, 2010, at 12:52 PM, Oscar Gerardo Lazo Arjona wrote:
I've recently started using numpy more seriously, and i've made
sage wrappers (that is sage functions that simply call numpy to do
the job) for numpy's fast fourier transform
On Jun 9, 2010, at 1:44 PM, Dr. David Kirkby wrote:
On 06/ 9/10 08:39 PM, leif wrote:
On 9 Jun., 18:29, Robert Bradshawrober...@math.washington.edu
wrote:
On Jun 9, 2010, at 9:19 AM, Dr. David Kirkby wrote:
I thought it would be useful if there was a way to indicate to
other
Sage
On Jun 11, 2010, at 1:00 PM, Simon King wrote:
Hi Ben!
On 11 Jun., 21:56, Ben Goodrich goodrich@gmail.com wrote:
...
and then put something like
R --vanilla TestPackages.R TestOutput.txt
at the end of the shell script that installs R, it will fail if any
installed R package fails to
On Jun 11, 2010, at 11:22 AM, Dr. David Kirkby wrote:
On 06/11/10 06:54 PM, kcrisman wrote:
Testing every single installed package could be
quite tricky, as likely the packages change in various spkgs over
time, but sometimes in subtle ways that an updater of an spkg
wouldn't
be aware of.
On 06/12/10 01:07 AM, Robert Bradshaw wrote:
On Jun 11, 2010, at 11:22 AM, Dr. David Kirkby wrote:
On 06/11/10 06:54 PM, kcrisman wrote:
Testing every single installed package could be
quite tricky, as likely the packages change in various spkgs over
time, but sometimes in subtle ways that
http://trac.sagemath.org/sage_trac/ticket/8049
was marked as a blocker by William, then marked as fixed. But there is nothing
there to indicate how it was fixed. Was the fix to manually copy the libgfortran
library every time a binary distribution of Sage is made? I assumed this would
have
Anyway, enough virtual ink spilled/spilt on this. The real issue is
that one needs massive amounts of time to write the right kind of
doctests and documentation, and since the incentive to add it is not
so high in a volunteer project for many people (though thanks to those
for whom it
If the goal were to test that the R functions in these packages are
working correctly, that is documented at
http://cran.r-project.org/doc/manuals/R-admin.html#Testing-a-Unix-Installation
In particular, one might want to call
library(tools)
testInstalledBasic(basic)
which would probably take
Hi Robert,
On Fri, Jun 11, 2010 at 9:47 PM, Robert Miller r...@rlmiller.org wrote:
SNIP
Yes, exactly. Or 5 modules, or 100. I want to go down the list and
start writing doctests for the first module I see there which I feel
relatively comfortable working on.
See the updated coverage report
70 matches
Mail list logo
