Thanks to Jeroen and Dan for their help. Jeroen's suggestion that I apply
the patches from 12825 worked fine for me.
cheers,
Hugh
--
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
F
On Sun, 15 Apr 2012 at 09:49PM +0200, Jeroen Demeyer wrote:
> That's actually not true. Currently, GCC is built on all systems where
> the system compiler is not GCC or is GCC version < 4.4.0. The
> environment variable SAGE_INSTALL_GCC can be used to override this.
...also, we use our own gcc ins
Hi,
This is wrong:
sage: A= SteenrodAlgebra(3)
sage: x= A.Q(0)
sage: y= x.coproduct(); y # that's fine:
1 # Q_0 + Q_0 # 1
sage: x^2 # that's also true:
0
sage: y^2# gives a wrong answer
2*Q_0 # Q_0
Now y^2 should be zero because the coproduct is an algebra
hom
Can anyone help discover why the new distribution of eclib which I
have created (at
http://homepages.warwick.ac.uk/staff/J.E.Cremona/ftp/progs/eclib-2012-04-15.tar.gz)
fails exactly one test when compiled with clang but passes with
various new versions of gcc? (See the report by Leif at
http://ho
On 2012-04-13 21:17, Ondřej Čertík wrote:
> Ah, maybe the link went to a wrong email. I meant the email by Georg S. Weber
> which says:
>
> the approach to "include our own GCC 4.5.1" is doomed to fail.
Well, what can I say? It turns out that any potential issues with all
the points raised in tha
Let me add a few clarifications to this email:
On 2012-04-15 21:36, Georg S. Weber wrote:
> "he who codes, rules" as the saying goes. I was wrong (and I'm glad
> about it!). Just some comments w.r.t. the reasoning in that old message
> of mine. Firstly, if I'm not mistaken, OS X is the only system
> Ah, maybe the link went to a wrong email. I meant the email by Georg S.
> Weber
> which says:
>
> "
> the approach to "include our own GCC 4.5.1" is doomed to fail.
> "
>
> and explains why, to which William replied "I think you really know
> what you're talking about.".
>
> And since you did
On 15 Apr., 21:03, Simon King wrote:
> On 15 Apr., 20:10, Simon King wrote:
>
> > I'll try it!
>
> I did, but some patches didn't even apply.
The instructions at #11080 didn't mention that sage-5.0.prealpha0 is
too old. Perhaps I will try again, with sage-5.0.beta13.
--
To post to this group,
On 04/15/2012 12:14 AM, Stephen Montgomery-Smith wrote:
On 04/14/2012 09:33 PM, kcrisman wrote:
I would appreciate any help understanding the cause of the remaining
errors.
Luckily, first we want it to build - then we can fix the errors. Most
look fairly technical - does sympow not work on it
On 15 Apr., 20:10, Simon King wrote:
> I'll try it!
I did, but some patches didn't even apply.
--
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 h
PS:
On 15 Apr., 18:54, Keshav Kini wrote:
> (See ticket #11080 for an SPKG to install.)
I'll try it!
--
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 gro
Hi Keshav,
On 15 Apr., 18:54, Keshav Kini wrote:
> Possibly the stuff has moved from sagenb to Sage proper in preparation
> for the Flask notebook
If I am not mistaken, the sageinspect.py file in Sage was first
commited in the release of sage-2.3, March 2007, whereas the file in
sagenb was first
Keshav Kini writes:
> this weird code reuse
I mean, this weird lack of code reuse, of course :)
-Keshav
Join us in #sagemath on irc.freenode.net !
--
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.
Simon King writes:
> However, looking at the code, I wonder: There is devel/sage/sage/misc/
> sageinspect.py, and there also is devel/sagenb/sagenb/misc/
> sageinspect.py. The two files are *different*, in fact the file in
> sagenb does not contain some patches that are important for source
> insp
I can also test these on my laptop. I'll first do #715 and #11521
which go together, and run a full testlong on them.
John
On 15 April 2012 16:33, john_perry_usm wrote:
> On Apr 14, 7:57 am, Jean-Pierre Flori wrote:
>> We're currently stuck with Simon on tickets #715, #11521 and #12313,
>> bec
Hi!
I try to understand the problem tracked at #11913: If a doc test of an
object tests against an error, then both the doc string and the source
code are truncated when attempting ?/?? inspection in the notebook.
For example, do
sage.graphs.graph_coloring.all_graph_colorings?
or
sage.graphs.gr
On Apr 14, 7:57 am, Jean-Pierre Flori wrote:
> We're currently stuck with Simon on tickets #715, #11521 and #12313,
> because we do not have access to 32 bits systems.
I can do it. I have a very old 32-bit system that I sometimes use both
to develop & test patches. What precisely should I test w/
Martin Albrecht writes:
> 2) unpacks upstream sources (perhaps even as indicated in a file tracked by
> the repository)
Downloading and unpacking upstream sources from a remote location
indicated in a file tracked by the repository is very good idea, IMO. In
fact I hope eventually at least this
On Sunday 15 Apr 2012, John Cremona wrote:
> +1 from me, for exactly the reasons Martin gives. When I am making a
> new eclib spkg (as I am now) I waste time sorting through all the old
> ones littering my computers. But one can always just unpack the spkg
> in the latest Sage (devel) release --
+1 from me, for exactly the reasons Martin gives. When I am making a
new eclib spkg (as I am now) I waste time sorting through all the old
ones littering my computers. But one can always just unpack the spkg
in the latest Sage (devel) release -- is what is being proposed any
easier?
John
On 15
Martin Albrecht writes:
>> If, as I infer from your wording, you propose consolidating all the SPKG
>> repos into a single repo,
>
> No! Not at all. This might be good or bad down the road, but I am definitely
> not proposing this now. Instead I say we should keep canonical copies of each
> SPK
Martin Albrecht writes:
> I was wondering how hard it would be (i.e., whether someone knows of a Trac
> plugin for this) to allow replying to Trac comments via e-mail. It would
> speed
> up the trivial to answer question response time etc.
It seems the Trac developers are against the idea of a
Hi,
On Sunday 15 Apr 2012, Keshav Kini wrote:
> Martin Albrecht writes:
> > Hi,
> >
> > I don't know about you, but I screw up surprisingly often when it comes
> > to cutting SPKGs (starting off from old versions, copying wrong files
> > etc.).
> >
> > I figured perhaps we should make use of th
On 2012-04-15 13:50, Martin Albrecht wrote:
> Hi,
>
> I don't know about you, but I screw up surprisingly often when it comes to
> cutting SPKGs (starting off from old versions, copying wrong files etc.).
>
> I figured perhaps we should make use of the repositories we have inside the
> SPKGs al
Martin Albrecht writes:
> Hi,
>
> I don't know about you, but I screw up surprisingly often when it comes to
> cutting SPKGs (starting off from old versions, copying wrong files etc.).
>
> I figured perhaps we should make use of the repositories we have inside the
> SPKGs already. The idea being
ancienthart writes:
> Thanks guys. I've finished my holidays so it'll probably be next weekend
> before
> I get to this.
> Michael, I'm assuming that step 1 (building from source rather than using a
> binary package) explains why I've been getting errors with hg patch?
Well, for one thing, `hg p
Hi,
I don't know about you, but I screw up surprisingly often when it comes to
cutting SPKGs (starting off from old versions, copying wrong files etc.).
I figured perhaps we should make use of the repositories we have inside the
SPKGs already. The idea being that all changes to SPKGs are pushed
Hi,
I was wondering how hard it would be (i.e., whether someone knows of a Trac
plugin for this) to allow replying to Trac comments via e-mail. It would speed
up the trivial to answer question response time etc.
Cheers,
Martin
--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?
Thanks guys. I've finished my holidays so it'll probably be next weekend
before I get to this.
Michael, I'm assuming that step 1 (building from source rather than using a
binary package) explains why I've been getting errors with hg patch?
Joal Heagney
On Saturday, 14 April 2012 02:32:34 UTC+10
oNNy writes:
> It still fails, even using the latest dev version sage-5.0.beta15.
By the way, the latest dev version is sage-5.0.beta13. Any later
versions than that are still in the progress of being assembled by the
release manager.
Read for example the following file:
http://boxen.math.washi
Simon King writes:
> So, I think a new *standard* spkg is not required to work with an older
> Sage version.
>
> However, an optional or experimental spkg is downloaded by people, and
> we don't know the version of Sage they are using. Of course, one might
> think of making the version of the down
31 matches
Mail list logo
