On Apr 25, 9:14 pm, Francois Bissey
wrote:
> I have been contacted off-list for details but didn't realise it was not on
> the
> list. If you could repost instruction here for all to see it would be good.
Here's a combination of what you sent me, and what I recall having to
do.
1. Unpack the n
Hi all,
I have created a ticket (#11244) with fix for deprecation warning in
python-2.7. The fix should not harm a sage using python-2.6 but it has to be
reviewed.
The heart of the problem is that python devs have decided deprecation warnings
are of no value to the end user and therefore shouldn
> On Apr 25, 4:33 pm, Francois Bissey
>
> wrote:
> > You could build numpy without lapack to check if it is the source of the
> > problem. I gave someone instructions on how to do that a while ago.
> > But that may have been on sage-release rather than sage-devel.
>
> It was me you sent them to.
On Apr 25, 4:33 pm, Francois Bissey
wrote:
> You could build numpy without lapack to check if it is the source of the
> problem. I gave someone instructions on how to do that a while ago.
> But that may have been on sage-release rather than sage-devel.
It was me you sent them to. When calculus/r
I also prefer trac, but I know why: it's shorter! Also it's more clearly
related to trac.sagemath.org/sage_trac . Patch comments also say stuff like
"trac #1234", not "ticket #1234".
And yeah, I'm with John - it's a waste to use sphinx and not take advantage
of its capabilities. The same goes f
> I'm thinking about something like :ticket:`3412` or :trac:`2132`.
> Any preferences or objections ?
I prefer trac. I don't know why.
Sébastien
--
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...@google
In general I think it might be useful to have a "sage-lint" script to find
and highlight weird or probably weird stuff in the codebase. This could
subsume both your suggested script and the coverage script, as well as
perhaps look for python 2.x -> 3.x issues, internal usage of deprecated
funct
> > It seems like a good idea to me. Should we also add a comment to the
> > developer's guide about this kind of mark-up for the documentation?
>
> Good idea. Done.
In the same veins, I think that links to trac ticket should be
hyperlinks. Sphinx extlinks extension make it very easy. The only
> On Apr 25, 2:56 pm, John H Palmieri wrote:
> > I can answer part of this: on Mac OS X, we don't install ATLAS at all, we
> > just rely on the system's version. I can't answer the rest of your
> > questions.
>
> Thanks, John. So I wonder if somebody could exercise the Mac system
> ATLAS/LAPACK
Hi John,
> > I'm working on #9128 whose goal is to resolve dangling links by looking in
> > python docs and in sage.all. On the way, I noticed that there are lots of
> > todos in the doc but no systematic way to handle them in sage. Fortunately,
> > there is a nice sphinx extension to handle
On Apr 25, 2:56 pm, John H Palmieri wrote:
> I can answer part of this: on Mac OS X, we don't install ATLAS at all, we
> just rely on the system's version. I can't answer the rest of your
> questions.
Thanks, John. So I wonder if somebody could exercise the Mac system
ATLAS/LAPACK with a Fortra
On Monday, April 25, 2011 1:29:42 PM UTC-7, Rob Beezer wrote:
>
> Lots of details on the Trac ticket [3]. I'm now out of my element on
> this one. I don't know enough about the Mac OS, how we build ATLAS, or
> how to test ATLAS with a Fortran or a C example.
>
I can answer part of this: on Ma
A new routine [1] to check if a matrix is unitary checked to see if
one of the outputs of the singular value decomposition is unitary.
For a few configurations, it wasn't, so the doctest failed.
Sage's SVD wraps numpy, and numpy wraps LAPACK. ("thinly" according
to a reply to my query on the nump
On Monday, April 25, 2011 10:04:04 AM UTC-7, fhivert wrote:
>
> Hi there,
>
> I'm working on #9128 whose goal is to resolve dangling links by looking in
> python docs and in sage.all. On the way, I noticed that there are lots of
> todos in the doc but no systematic way to handle them in sage
Dear Sage developers:
I just stumbled upon a site that should probably have links to Sage.
http://eqworld.ipmnet.ru/index.htm
This is a site that has collected information about solutions to known
equations and has a list of software including Maple, Mathematica, Matlab, R,
Maxima and so on...
Hi!
The background of my question is trac ticket #5. It provides a
Cython version of @cached_method, and it is really fast now.
Apart from the speed up, another problem is addressed: If an element
or parent structure is an extension class that does not allow
attribute assignment then it can s
Hi there,
I'm working on #9128 whose goal is to resolve dangling links by looking in
python docs and in sage.all. On the way, I noticed that there are lots of
todos in the doc but no systematic way to handle them in sage. Fortunately,
there is a nice sphinx extension to handle them and gathe
it's fixed in http://trac.sagemath.org/sage_trac/ticket/11246
which needs review.
On Apr 25, 10:32 pm, David Kirkby wrote:
> On 25 April 2011 15:25, Dima Pasechnik wrote:
>
> >> > #ifndef ulong
> >> > #define ulong unsigned long
> >> > #endif
>
> >> > would not be platform specific (so fairly ea
On 25 April 2011 15:25, Dima Pasechnik wrote:
>> > #ifndef ulong
>> > #define ulong unsigned long
>> > #endif
>
>> > would not be platform specific (so fairly easy to maintain).
>
> This does not work, as the header inclusion order in ZmodF_mul.c
> does #include ZmodF_poly.h (which includes stdio
-- Forwarded message --
From: Dima Pasechnik
Date: Apr 25, 10:24 pm
Subject: #11246: flint-1.5.0.p5 defines ulong on a system with ulong a
type
To: sage-windows
Hi Bill,
On Apr 25, 3:41 am, Bill Hart wrote:
> On 24 April 2011 20:20, Dr. David Kirkby wrote:
> > On 04/24/11 12:
On Mon, Apr 25, 2011 at 2:19 PM, Jason Grout
wrote:
> On 4/25/11 6:10 AM, John Cremona wrote:
>>
>> Thanks for the various comments.
>>
>> I have definitely used cp to copy sage from one place to another
>> before, with expected behaviour on first startup. This time I used
>> scp for some reason.
On 4/25/11 6:10 AM, John Cremona wrote:
Thanks for the various comments.
I have definitely used cp to copy sage from one place to another
before, with expected behaviour on first startup. This time I used
scp for some reason. I just redid it using rsync, following Dave's
suggestion, and everyt
On Apr 25, 8:04 am, "Nicolas M. Thiery"
wrote:
> On Sat, Apr 23, 2011 at 08:45:06AM -0700, kcrisman wrote:
> > And it should be
>
> > EXAMPLES:
>
> > We here give an interesting example::
>
> > sage: bla
>
> +1 on the S to EXAMPLES. And, when not obvious, +1 on having a
> descrip
On Sat, Apr 23, 2011 at 08:45:06AM -0700, kcrisman wrote:
> And it should be
>
> EXAMPLES:
>
> We here give an interesting example::
>
> sage: bla
+1 on the S to EXAMPLES. And, when not obvious, +1 on having a
description of the intention of the example is doing.
On the other
Thanks for the various comments.
I have definitely used cp to copy sage from one place to another
before, with expected behaviour on first startup. This time I used
scp for some reason. I just redid it using rsync, following Dave's
suggestion, and everything is normal.
John
On Mon, Apr 25, 201
Hi David,
The package glpk-4.42.p0 has been removed from
http://www.sagemath.org/packages/optional/.
--
Regards
Minh Van Nguyen
--
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 m
On 04/25/11 08:46 AM, Dima Pasechnik wrote:
On Apr 25, 3:39 am, John Cremona wrote:
I just moved a fresh build in this way (using scp -pr, though source
and destination were local) and the first time I run Sage from the new
location is starts up normally.
John
Using rsync will be a
On 04/20/11 01:48 PM, Simon wrote:
The whole symja thing is interesting...
how much of Mathematica's syntax are they allowed to copy without breaching
some sort of intellectual property rights?
Although this case was in the USA, and different countries have different laws,
this situation arose
> > I just moved a fresh build in this way (using scp -pr, though source
> > and destination were local) and the first time I run Sage from the new
> > location is starts up normally.
>
> I can't reproduce this.
> Have you actually moved anything?
I ran into something like this once too. I can't
On Apr 25, 1:48 am, "Dr. David Kirkby"
wrote:
> We still have GPLK as an optional package (an outdated version), despite a
> more
> recent version is a standard Sage package.
>
> Can someone with the right permissions sort this out.
>
> I've created a trac ticket for this - see:
>
> http://trac
On Apr 25, 3:39 am, John Cremona wrote:
> It always used to be the case that if you moved the entire Sage build
> tree to another place, the first time you ran Sage from the new place
> it issued a warning to wait a while while it updated some hard-wired
> paths, Has anything changed to make th
31 matches
Mail list logo
