Hi, Simon,
On Feb 9, 2012, at 22:28 , Simon King wrote:
> On 10 Feb., 00:50, "Justin C. Walker" wrote:
>> I'm not sure whether this qualifies as a problem, but my first attempt blew
>> up in my face because I didn't have GAP's 'small groups' package installed.
>>
>> Should this be a dependency
Excellent. That's the first confirmation I've had from someone with the
problem that it really was #12161. I'm cc-ing sage-devel to let them know it
worked.
-Ivan
On Feb 10, 2012, at 1:17 AM, Michael E O'Sullivan wrote:
> Brilliant!
>
> I restarted terminal and
> MAC043:~ instructor$ /Appli
Well, to be fair, it's generally less wise to state in public how much
others suck than to state in public how much we ourselves suck :)
-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
Hi Justin!
On 10 Feb., 00:50, "Justin C. Walker" wrote:
> I'm not sure whether this qualifies as a problem, but my first attempt blew
> up in my face because I didn't have GAP's 'small groups' package installed.
>
> Should this be a dependency for your package? It seems a bit rough around
> th
On Thu, Feb 9, 2012 at 10:02 PM, Oscar Lazo wrote:
> Hello!
>
> I am interested in developing Broyden's method in sage
>
> http://en.wikipedia.org/wiki/Broyden%27s_method
>
> But I'm not sure whether it exists already, perhaps in some library included
> in sage. Is there some non-linear solver in
Hello!
I am interested in developing Broyden's method in sage
http://en.wikipedia.org/wiki/Broyden%27s_method
But I'm not sure whether it exists already, perhaps in some library
included in sage. Is there some non-linear solver in sage?
thanks!
Oscar
--
To post to this group, send an email
On Feb 8, 4:12 pm, "Dr. David Kirkby" wrote:
> since its clear some don't have a clue.
"Perhaps that's not the wisest thing to state in public."
Rob
--
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...@g
On Feb 9, 9:41 pm, Alex Kramer wrote:
> On Thu, Feb 9, 2012 at 8:58 PM, kcrisman wrote:
> > Do things also change to
>
> > inputLocation: "#sagecell-test",
>
> > then?
>
> Not necessarily, the inputLocation/outputLocation fields for embedding
> should be able to be set to anything as l
On Thu, Feb 9, 2012 at 8:58 PM, kcrisman wrote:
> Do things also change to
>
> inputLocation: "#sagecell-test",
>
> then?
Not necessarily, the inputLocation/outputLocation fields for embedding
should be able to be set to anything as long as it is a valid jQuery
selector that corresponds
On Feb 9, 6:24 pm, Jason Grout wrote:
> On 2/9/12 2:06 PM, Jason Grout wrote:
>
> > We just finished a pretty big upgrade of our experimental beta
> > aleph.sagemath.org sage cell server. Now it is running Sage 5.0beta3
> > with the new jmol 12.x from the new notebook. If anyone sees any
> > pro
On Feb 9, 5:44 pm, William Stein wrote:
> On Thu, Feb 9, 2012 at 2:34 PM, Jason Grout
> wrote:
> > On 2/9/12 4:28 PM, Michael Orlitzky wrote:
>
> >> I think if we could get rid of a few magic commands in favor of 'mv',
> >> 'cp', and 'ln', it would make the process seem less daunting.
>
> > +1
Hi, Simon,
On Feb 9, 2012, at 12:29 , Simon King wrote:
> Hi Jim and all others interested in group cohomology!
>
> On 4 Feb., 17:27, Jim Milgram wrote:
>> Using openSUSE 12.1. Sage compliled without difficulty, but
>> the compilation of the optional program "p_group_cohomolgy" failed.
>
> I
Hi Jim!
On 9 Feb., 23:06, Jim Milgram wrote:
> Thanks. The new version compiled without any problems.
That's good to know!
> So back
> to looking at these groups with really powerful tools. Jon,
> Alex and I did a lot of these calculations by hand some 15 years
> back, including most of the a
On 2/9/12 2:06 PM, Jason Grout wrote:
We just finished a pretty big upgrade of our experimental beta
aleph.sagemath.org sage cell server. Now it is running Sage 5.0beta3
with the new jmol 12.x from the new notebook. If anyone sees any
problems with aleph, please let us know.
We put in some back
On Thu, Feb 9, 2012 at 2:28 PM, Michael Orlitzky wrote:
> A personal anecdote: I've used sage for about 4 years, but only started
> contributing in the last couple of months because the development process
> looks scary to an outsider.
>
> When I started, at every step of the process, I already kn
On 2/9/12 4:44 PM, William Stein wrote:
On Thu, Feb 9, 2012 at 2:34 PM, Jason Grout wrote:
On 2/9/12 4:28 PM, Michael Orlitzky wrote:
I think if we could get rid of a few magic commands in favor of 'mv',
'cp', and 'ln', it would make the process seem less daunting.
+1. And then the new us
On Thu, Feb 9, 2012 at 2:34 PM, Jason Grout wrote:
> On 2/9/12 4:28 PM, Michael Orlitzky wrote:
>
>> I think if we could get rid of a few magic commands in favor of 'mv',
>> 'cp', and 'ln', it would make the process seem less daunting.
>
>
> +1. And then the new user that is learning how to do sa
On 2/9/12 4:28 PM, Michael Orlitzky wrote:
I think if we could get rid of a few magic commands in favor of 'mv',
'cp', and 'ln', it would make the process seem less daunting.
+1. And then the new user that is learning how to do sage has skills
that transfer elsewhere.
Jason
--
To post t
On 02/09/2012 04:18 PM, kcrisman wrote:
I think you are totally missing the point. To a newbie who has heard
of the following:
cd
mv
hg
ln
you are right. My assumption is that we would like to be as inviting
as possible to those who have not. (And they are legion; think of the
Windows world
Hi Simon,
Thanks. The new version compiled without any problems. So back
to looking at these groups with really powerful tools. Jon,
Alex and I did a lot of these calculations by hand some 15 years
back, including most of the analysis needed for M_{24} mod 2.
But determining the invariant sub
On Thu, Feb 9, 2012 at 10:13 AM, William Stein wrote:
> On Thu, Feb 9, 2012 at 10:08 AM, Robert Bradshaw
> wrote:
>> On Wed, Feb 8, 2012 at 9:46 PM, Kwankyu Lee wrote:
>>> Hi,
>>>
>>> A couple of simple developer questions. Sorry...
>>>
>>> (1) I uploaded a new patch of the same name with the pr
When in question, look at the logs. If you see "Killed" that means
that the subprocess doing the patching/building/testing was killed.
On Thu, Feb 9, 2012 at 11:25 AM, Kwankyu Lee wrote:
> Anyway, I just noticed that many of the patches with positive reviews have
> the red swirling symbol with "A
Le jeudi 09 février, Julien Puydt a écrit:
> Le mercredi 08 février, R. Andrew Ohana a écrit:
> > On Wed, Feb 8, 2012 at 16:26, William Stein
> > wrote:
> > > Believe it or not, the environment variables that control how Sage
> > > is built globally are documented (and aren't random):
> > >
> > >
On 9 February 2012 18:23, William Stein wrote:
>
> FUD. I've spent significant time with autotools documentation.
>
If I could be bothered (which I can't), I could point to lots of things in
that early prereq script which dont conform even one little bit to how you
are supposed to use autoconf.
> Would you have any objection to getting rid of the actual commands
> `sage -clone`, `sage -b ` (just plain `sage -b` would stay of
> course), and friends, so that this behavior can be removed? Again, you
> could easily do this stuff manually:
>
> $ cd $SAGE_ROOT/devel/
> $ mv sage vanilla
> $ hg
Le jeudi 09 février, Martin Albrecht a écrit:
> How about the configure script would write a makefile which would
> setup the right environment variables that the spkg-install scripts
> expect, so from their perspective nothing would change for now.
+2
Snark on #sagemath
--
To post to this grou
This would definitely be the goal for the initial version of an autotools
conversion:
* Move prereq to $SAGE_ROOT
* Just make configure set up the usual environment variables and write
the top-level makefiel, but don't change anything in the sage build process.
--
To post to this group, sen
On Thursday 09 February 2012, Mike Hansen wrote:
> On Thu, Feb 9, 2012 at 11:30 AM, Michael Orlitzky
wrote:
> > No one has proposed anything un-vague yet. But yes, some of the
> > environment variables would become ./configure options. Many of them
> > would just go away though, since they manu
Hi Jim and all others interested in group cohomology!
On 4 Feb., 17:27, Jim Milgram wrote:
> Using openSUSE 12.1. Sage compliled without difficulty, but
> the compilation of the optional program "p_group_cohomolgy" failed.
I solved the problems:
- After upgrading the Cython version in Sage, s
We just finished a pretty big upgrade of our experimental beta
aleph.sagemath.org sage cell server. Now it is running Sage 5.0beta3
with the new jmol 12.x from the new notebook. If anyone sees any
problems with aleph, please let us know.
Thanks,
Jason
--
To post to this group, send an emai
On 2012-02-09 19:17, William Stein wrote:
> On Thu, Feb 9, 2012 at 9:30 AM, David Roe wrote:
>> I will take a look later today.
>> David
>
> David -- want to meet in 401 during the time when the sage seminar is
> scheduled to work on this? I.e., today at 2pm in Padelford C401?
>
> I worked on t
On Thu, Feb 9, 2012 at 11:30 AM, Michael Orlitzky wrote:
> No one has proposed anything un-vague yet. But yes, some of the environment
> variables would become ./configure options. Many of them would just go away
> though, since they manually tell the build process things that ./configure
> can de
On 02/09/2012 01:23 PM, William Stein wrote:
I still feel that what is being proposed is very vague. Is it to
deprecate all of these variables [1] (but still fully support them for
at least one year!), and make them options to a ./configure script?
http://sagemath.org/doc/installation/sou
Anyway, I just noticed that many of the patches with positive reviews have
the red swirling symbol with "Apply Failed" on Sage 4.8. Then I wonder the
patchbot is working correctly now...
Kwankyu
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this gr
That makes sense, thanks.
-Keshav
Join us in #sagemath on irc.freenode.net !
On Fri, Feb 10, 2012 at 03:02, Jeroen Demeyer wrote:
> On 2012-02-09 18:19, Keshav Kini wrote:
>> Why not just upgrade Mercurial?
> I wanted to make a minimal change to make it build on OS X 10.7 with
> gcc-4.6.2.
Don't forget:
* Upgrade to Python-2.7 (#9958)
which is already done, mostly thanks to François Bissey.
--
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 gr
On 2012-02-09 20:04, William Stein wrote:
> I'm 100% confident about the statement: "Sage-5.0 is going to include
> the new flask version of the notebook".
Given your post about "Sage-5.0 goals", you are trivially right.
--
To post to this group, send an email to sage-devel@googlegroups.com
To un
The second patch is small, but the doctest takes quite a bit of time. So I
changed the doctest and uploaded the patch again. Let me see this helps...
Kwankyu
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+uns
On Thu, Feb 9, 2012 at 11:02 AM, Jeroen Demeyer wrote:
> On 2012-02-09 18:19, Keshav Kini wrote:
>> Why not just upgrade Mercurial?
> I wanted to make a minimal change to make it build on OS X 10.7 with
> gcc-4.6.2.
That's also a very good point.
A big +1 to actually finishing the 10.7 support g
On Thu, Feb 9, 2012 at 10:58 AM, Jeroen Demeyer wrote:
> On 2012-02-09 19:26, William Stein wrote:
>> On Thu, Feb 9, 2012 at 8:29 AM, Jeroen Demeyer
>> wrote:
>>> The old (pre-flask-sagenb) Twisted spkg has some .c files with invalid C
>>> code generated by an old version of Pyrex. This are fil
On 2012-02-09 18:19, Keshav Kini wrote:
> Why not just upgrade Mercurial?
I wanted to make a minimal change to make it build on OS X 10.7 with
gcc-4.6.2.
--
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...
On 2012-02-09 19:26, William Stein wrote:
> On Thu, Feb 9, 2012 at 8:29 AM, Jeroen Demeyer wrote:
>> The old (pre-flask-sagenb) Twisted spkg has some .c files with invalid C
>> code generated by an old version of Pyrex. This are files which are
>> only compiled on OS X Darwin and gcc-4.6.2 fails
Apparently something in the Sage library still depends on Twisted, as
Jeroen noted on #11874 ( http://trac.sagemath.org/sage_trac/ticket/11874 ).
-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 t
Hi Sage-Devel,
As decided on November 3, 2011, the blocker goals for sage-5.0 are:
1. Trac 12024: 90% doctest coverage:
http://trac.sagemath.org/sage_trac/ticket/12024
Status:
"sage-5.0.beta3-sage.math.washington.edu-x86_64-Linux$ ./sage -coverageall
Overall weighted coverage score: 86.5%
To
Hi Robert,
> (1) I uploaded a new patch of the same name with the previous patch, but
> the
> > patchbot doesn't seem to be triggered. I already tried "?kick", with no
> > help. Is there other way to kick the patchbot? Do I need to upload the
> same
> > patch with other name?
>
> Has it ever bee
On Thu, Feb 9, 2012 at 8:29 AM, Jeroen Demeyer wrote:
> The old (pre-flask-sagenb) Twisted spkg has some .c files with invalid C
> code generated by an old version of Pyrex. This are files which are
> only compiled on OS X Darwin and gcc-4.6.2 fails to compile them.
> Re-generating these files wi
On Thu, Feb 9, 2012 at 8:01 AM, David Kirkby wrote:
>
>
> On 9 February 2012 14:04, Michael Orlitzky wrote:
>>
>> I'll +1 both sides:
>>
>> 1) autotools is the worst thing on Earth
>
>
> I believe if it was as bad as you make out, it would not be as popular as it
> is. I would guess guess at leas
On Thu, Feb 9, 2012 at 9:30 AM, David Roe wrote:
> I will take a look later today.
> David
David -- want to meet in 401 during the time when the sage seminar is
scheduled to work on this? I.e., today at 2pm in Padelford C401?
I worked on the NTL interface a lot at one point, so might have a clu
On Thu, Feb 9, 2012 at 10:08 AM, Robert Bradshaw
wrote:
> On Wed, Feb 8, 2012 at 9:46 PM, Kwankyu Lee wrote:
>> Hi,
>>
>> A couple of simple developer questions. Sorry...
>>
>> (1) I uploaded a new patch of the same name with the previous patch, but the
>> patchbot doesn't seem to be triggered. I
On Wed, Feb 8, 2012 at 9:46 PM, Kwankyu Lee wrote:
> Hi,
>
> A couple of simple developer questions. Sorry...
>
> (1) I uploaded a new patch of the same name with the previous patch, but the
> patchbot doesn't seem to be triggered. I already tried "?kick", with no
> help. Is there other way to kic
On Thu, Feb 9, 2012 at 7:53 AM, Jason Grout wrote:
> On 2/9/12 9:44 AM, Keshav Kini wrote:
>>
>> On Thu, Feb 9, 2012 at 23:30, Jason Grout
>> wrote:
>>>
>>> I use separate directories in devel/ to have multiple versions of the new
>>> sage notebook installed. They're almost all git repositories,
I will take a look later today.
David
On Thu, Feb 9, 2012 at 08:16, Jeroen Demeyer wrote:
> For the Sage port to OS X 10.7 using GCC-4.6.2 (#12369), I am down to
> *one doctest failure*: #12480.
>
> This is however one huge can of worms involving padics and NTL.
>
> In sage/rings/padics/pow_comp
On Fri, Feb 10, 2012 at 00:51, kcrisman wrote:
> I think it's great that we've made the updates to the developer guide
> that explain queues, and I have been using them a lot more for the
> last year or so. But remember, a lot of the infrastructure was put in
> place in order to aid new developer
Why not just upgrade Mercurial? The upstream is about as far ahead of us as
it was the last time we upgraded, looks like.
-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
On Feb 9, 11:15 am, John Cremona wrote:
> People are answering the question I intended to ask. So far no-one
> uses the branching mechanism. Who knows if it still worksif it
> doesn't someone should remove mention of it from the docs.
Oh, it works, or at least has within the last year.
I
Le jeudi 09 février, Jason Grout a écrit:
> On 2/9/12 10:17 AM, Jason Grout wrote:
>
> > What about cmake? That also seems pretty popular, and, for example,
> > KDE switched from autotools to cmake.
> >
> > Disclaimer: I know almost nothing about writing either autotools
> > things or cmake things
Le jeudi 09 février, Jason Grout a écrit:
> What about cmake? That also seems pretty popular, and, for example,
> KDE switched from autotools to cmake.
>
> Disclaimer: I know almost nothing about writing either autotools
> things or cmake things.
I had a look at cmake years ago when I wanted to
On OS X, when XCode 4 is installed, Mercurial is built with certain
CFLAGS which only Apple's compiler understands. This obviously breaks a
build with GCC. This is an upstream problem, but is already fixed
upstream (simply by not using those flags). My spkg does the same as
the upstream fix.
Pl
The old (pre-flask-sagenb) Twisted spkg has some .c files with invalid C
code generated by an old version of Pyrex. This are files which are
only compiled on OS X Darwin and gcc-4.6.2 fails to compile them.
Re-generating these files with a newer version of Pyrex solves the problem.
Please review:
On 2/9/12 10:17 AM, Jason Grout wrote:
What about cmake? That also seems pretty popular, and, for example, KDE
switched from autotools to cmake.
Disclaimer: I know almost nothing about writing either autotools things
or cmake things.
For that matter, scons seems like a viable alternative (in
On 02/09/2012 11:01 AM, David Kirkby wrote:
On 9 February 2012 14:04, Michael Orlitzky mailto:mich...@orlitzky.com>> wrote:
I'll +1 both sides:
1) autotools is the worst thing on Earth
I believe if it was as bad as you make out, it would not be as popular
as it is. I would guess gue
On 2/9/12 10:01 AM, David Kirkby wrote:
On 9 February 2012 14:04, Michael Orlitzky mailto:mich...@orlitzky.com>> wrote:
I'll +1 both sides:
1) autotools is the worst thing on Earth
I believe if it was as bad as you make out, it would not be as popular
as it is. I would guess guess a
For the Sage port to OS X 10.7 using GCC-4.6.2 (#12369), I am down to
*one doctest failure*: #12480.
This is however one huge can of worms involving padics and NTL.
In sage/rings/padics/pow_computer_ext.pyx, I found some code where
Py_None is type-casted into something completely different. It i
People are answering the question I intended to ask. So far no-one
uses the branching mechanism. Who knows if it still worksif it
doesn't someone should remove mention of it from the docs.
John
On 9 February 2012 15:53, Jason Grout wrote:
> On 2/9/12 9:44 AM, Keshav Kini wrote:
>>
>> On Th
On 9 February 2012 14:04, Michael Orlitzky wrote:
> I'll +1 both sides:
>
> 1) autotools is the worst thing on Earth
>
I believe if it was as bad as you make out, it would not be as popular as
it is. I would guess guess at least one third of open-source projects use
it.
I know William called it
On 02/09/2012 09:21 AM, Julien Puydt wrote:
It's unfair : the problems they try to solve is basically unsolvable,
and that is _a part_ of why they're so complex.
Agreed. And other build systems that work comparably-well usually end up
looking worse.
It will hurt, but it still should to b
On 2/9/12 9:44 AM, Keshav Kini wrote:
On Thu, Feb 9, 2012 at 23:30, Jason Grout wrote:
I use separate directories in devel/ to have multiple versions of the new
sage notebook installed. They're almost all git repositories, though :). I
don't know if that counts as a yes or no to your question
On Thu, Feb 9, 2012 at 23:30, Jason Grout wrote:
> I use separate directories in devel/ to have multiple versions of the new
> sage notebook installed. They're almost all git repositories, though :). I
> don't know if that counts as a yes or no to your question.
IMO it's important to note that
On 2/9/12 9:01 AM, John Cremona wrote:
Does anyone still use branches?
I use separate directories in devel/ to have multiple versions of the
new sage notebook installed. They're almost all git repositories,
though :). I don't know if that counts as a yes or no to your question.
Jason
--
On Feb 9, 2012 4:58 AM, "Harald Schilly" wrote:
>
> On Thu, Feb 9, 2012 at 13:42, Julien Puydt
wrote:
> >> I've had a couple of theories about why applications might fail.
> >> 2) The Sage development process is not exactly a shining example of
> >> best practice in software engineering.
> > 1. I
On Feb 9, 2012 7:01 AM, "John Cremona" wrote:
>
> Does anyone still use branches?
I haven't in years!
>I used to always do a "sage -clone"
> right after building a test version, but since using queues I never do
> that. If I need to test something which affects more than the Sage
> library, not
Does anyone still use branches? I used to always do a "sage -clone"
right after building a test version, but since using queues I never do
that. If I need to test something which affects more than the Sage
library, notably a new version of an spkg, I just copy the entire
build using cp -r, and wo
On Thu, Feb 9, 2012 at 01:45, William Stein wrote:
> On Tue, Feb 7, 2012 at 9:57 PM, Keshav Kini wrote:
>> My $0.02.
>
> I disagree with what you wrote above. Perhaps you have a different
> impression than me of how Mercurial is used, given the relative sizes
> of our contributions to the Sage l
On Thu, Feb 9, 2012 at 06:18, Dima Pasechnik wrote:
>
>
> On Thursday, 9 February 2012 17:10:55 UTC+8, Jeroen Demeyer wrote:
>>
>> On 2012-02-09 00:46, Dr. David Kirkby wrote:
>> > But on OS X, this should be easy to test - assuming you can find the
>> > hardware with a sufficiently old version of
On Thu, Feb 9, 2012 at 05:51, David Kirkby wrote:
>
>
> On 9 February 2012 12:59, R. Andrew Ohana wrote:
>>
>> On Thu, Feb 9, 2012 at 01:56, David Kirkby
>> wrote:
>>
>> > There are a lot of packages in Sage which don't respect CC. I've fixed
>> > some
>> > of them, but gave up at some point as
Le jeudi 09 février, Michael Orlitzky a écrit:
> I'll +1 both sides:
>
> 1) autotools is the worst thing on Earth
It's unfair : the problems they try to solve is basically unsolvable,
and that is _a part_ of why they're so complex.
> 2) sage should use it
It will hurt, but it still should to be
On Thursday, 9 February 2012 17:10:55 UTC+8, Jeroen Demeyer wrote:
>
> On 2012-02-09 00:46, Dr. David Kirkby wrote:
> > But on OS X, this should be easy to test - assuming you can find the
> > hardware with a sufficiently old version of OS X
>
> Apparently this *only* applies to OS X 10.5, so the
I'll +1 both sides:
1) autotools is the worst thing on Earth
2) sage should use 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 group at http://groups
On 9 February 2012 12:59, R. Andrew Ohana wrote:
> On Thu, Feb 9, 2012 at 01:56, David Kirkby
> wrote:
>
> > There are a lot of packages in Sage which don't respect CC. I've fixed
> some
> > of them, but gave up at some point as there were too many. Is is funny,
> as
> > there are the odd packag
I have a patch for the small misc function branch_current_hg(). It was
horribly written and broken "sage --gdb" on OS X 10.7.
It should be an easy review, please have a look at
http://trac.sagemath.org/sage_trac/ticket/12481
Thanks,
Jeroen.
--
To post to this group, send an email to sage-devel
On Thu, Feb 9, 2012 at 01:56, David Kirkby wrote:
>
>
> On 9 February 2012 09:38, Jeroen Demeyer wrote:
>>
>> On 2012-02-09 10:34, David Kirkby wrote:
>> > No, one what would do in this case is
>> >
>> > ./configure CC="gcc -m64"
>>
>> Exactly. If every spkg would actually respect the CC environ
On Thu, Feb 9, 2012 at 13:42, Julien Puydt wrote:
>> I've had a couple of theories about why applications might fail.
>> 2) The Sage development process is not exactly a shining example of
>> best practice in software engineering.
> 1. Is it available readily in most distributions? No.
>
> 2. Does
Le mercredi 08 février, R. Andrew Ohana a écrit:
> On Wed, Feb 8, 2012 at 16:26, William Stein wrote:
> > Believe it or not, the environment variables that control how Sage
> > is built globally are documented (and aren't random):
> >
> > http://sagemath.org/doc/installation/source.html#envi
Le mercredi 08 février, Dr. David Kirkby a écrit:
> On 02/ 8/12 09:41 AM, Julien Puydt wrote:
> > Le mardi 7/2/2012, David Kirkby a écrit :
> >> Unfortunately, from a developers point of view, it is not the
> >> easiest language to learn, and my experience of many Sage
> >> developers would sugges
Le jeudi 09 février, Dr. David Kirkby a écrit:
> I've had a couple of theories about why applications might fail.
>
> 1) Too mathematical, though that theory seems to have been dismissed,
> as I gather other heavy maths has been funded.
I don't think so.
> 2) The Sage development process is not
On 9 February 2012 09:38, Jeroen Demeyer wrote:
> On 2012-02-09 10:34, David Kirkby wrote:
> > No, one what would do in this case is
> >
> > ./configure CC="gcc -m64"
>
> Exactly. If every spkg would actually respect the CC environment
> variable, this would work and we wouldn't need SAGE64 anym
On 9 February 2012 09:10, Jeroen Demeyer wrote:
> On 2012-02-09 00:46, Dr. David Kirkby wrote:
> > But on OS X, this should be easy to test - assuming you can find the
> > hardware with a sufficiently old version of OS X
>
> Apparently this *only* applies to OS X 10.5, so the assumption is not so
On 2012-02-09 10:34, David Kirkby wrote:
> No, one what would do in this case is
>
> ./configure CC="gcc -m64"
Exactly. If every spkg would actually respect the CC environment
variable, this would work and we wouldn't need SAGE64 anymore.
--
To post to this group, send an email to sage-devel@g
On 9 February 2012 08:39, Jean-Pierre Flori wrote:
> About the SAGE64 stuff, right now when the option is tested it
> basically sets the different C??FLAGS to -m64 -g -O2
> As you pointed above I guess the -m64 forces gcc to produce 64 bits
> binaries even though the default is 32 bits, so I'm fi
On 2012-02-09 00:46, Dr. David Kirkby wrote:
> But on OS X, this should be easy to test - assuming you can find the
> hardware with a sufficiently old version of OS X
Apparently this *only* applies to OS X 10.5, so the assumption is not so
easy.
--
To post to this group, send an email to sage-de
About the SAGE64 stuff, right now when the option is tested it
basically sets the different C??FLAGS to -m64 -g -O2
As you pointed above I guess the -m64 forces gcc to produce 64 bits
binaries even though the default is 32 bits, so I'm fine with that.
I guess that the -g -O2 flags are set because t
91 matches
Mail list logo
