> This could be a nice replacement to the current MQ-based Sage development.
>
They're fighting to replace it by Git these days :-)
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email to sage-devel@googl
On Tue, 18 Dec 2012 09:16:05 +0100
Burcin Erocal wrote:
> This was indeed intentional at the time. When writing the "new
> symbolics" code based on pynac, William and I thought that this
> behavior was the one that led to least confusion.
>
> Working with expression trees that involve relational
The desktop machine my department provides for me, on which I usually
install Sage even though I do most real work on bigger and better
boxes, was unable to build Sage-5.5. (I usually only build full
releases on this machine as I do not use it for any development work.)
The problem is in building
You could try the currently-stable ATLAS version instead of the old one we
ship:
http://trac.sagemath.org/10508
On Wednesday, January 9, 2013 12:08:14 PM UTC, John Cremona wrote:
>
> The desktop machine my department provides for me, on which I usually
> install Sage even though I do most re
On Wednesday, January 9, 2013 1:33:18 PM UTC+1, Volker Braun wrote:
>
> You could try the currently-stable ATLAS version instead of the old one we
> ship:
>
> http://trac.sagemath.org/10508
>
>
> Not to hijack this thread but we should really get the new ATLAS in (and
use a system-wide install
Thanks, I will try that -- is it possible to try it out with a mostly
incomplete build? I see that I would replace the existing spkg file
with the new one, but is it possible to apply the other patches at
#10508 before Sage has built?
John
On 9 January 2013 12:33, Volker Braun wrote:
> You coul
You don't really need any of the patches to build the new ATLAS spkg.
On Wednesday, January 9, 2013 1:14:07 PM UTC, John Cremona wrote:
>
> Thanks, I will try that -- is it possible to try it out with a mostly
> incomplete build? I see that I would replace the existing spkg file
> with the new
Did you explicitly ask *not* to install GCC (i.e. SAGE_INSTALL_GCC=no)?
Because by default, Sage should build GCC if your system has gcc-4.3.4.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email to sage-devel@googleg
On 9 January 2013 05:06, Nathann Cohen wrote:
>
>> This could be a nice replacement to the current MQ-based Sage development.
>
>
> They're fighting to replace it by Git these days :-)
I'm well aware. I think this is misguided. The problem isn't the DVCS.
Both git and hg are powerful and flexible
There is a discussion going on at #13032 about the configuration of
ccache within Sage. ccache is a program which caches object files
produced by a compiler and which can considerably speed up compilation
if the same file is compiled more than once (e.g. when building
sage-5.6.beta3 after building
There are certainly pros an cons for both mercurial and git. But
* Sage needs something better than mq now, not "when its finished"
* And for which one can buy a book at an average bookstore today
* I don't want to beta-test a mercurial extension with a >>500 ksloc
project.
On Tuesday, Janu
On 2013-01-09 17:23, Volker Braun wrote:
> * I don't want to beta-test a mercurial extension with a >>500 ksloc
> project.
+1
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsu
Also, ccache is awesome. If your distribution doesn't come with it by
default you should switch ;-)
I say we don't do anything special. Ccache will use the default ~/.ccache
or CCACHE_DIR if set. Why muck around with it if there is a perfectly fine
configuration system in place already?
[vbr
On 2013-01-09 17:34, Volker Braun wrote:
> Also, ccache is awesome.
Absolutely. Now we only need sphinx-cache, THAT would speed up building
Sage!
> I say we don't do anything special. Ccache will use the default
> ~/.ccache or CCACHE_DIR if set. Why muck around with it if there is a
> perfectly f
On 01/10/2013 12:50 AM, Jeroen Demeyer wrote:
On 2013-01-09 17:34, Volker Braun wrote:
Also, ccache is awesome.
Absolutely. Now we only need sphinx-cache, THAT would speed up building
Sage!
I don't want to go offtopic here, but since you mentioned this, I have
been searching for sphinx cach
On 9 January 2013 11:23, Volker Braun wrote:
> * Sage needs something better than mq now, not "when its finished"
"Now" is probably "very soon". Mercurial is being used and developed
heavily by Facebook, since they've hired a couple of key hg devs, and
Evolve has been, well, evolving, quite rapid
On 9 January 2013 17:34, P Purkayastha wrote:
> On 01/10/2013 12:50 AM, Jeroen Demeyer wrote:
>
>> On 2013-01-09 17:34, Volker Braun wrote:
>>
>>> Also, ccache is awesome.
>>>
>> Absolutely. Now we only need sphinx-cache, THAT would speed up building
>> Sage!
>>
>
> I don't want to go offtopic h
On Jan 9, 8:34 am, Volker Braun wrote:
> I say we don't do anything special. Ccache will use the default ~/.ccache
> or CCACHE_DIR if set. Why muck around with it if there is a perfectly fine
> configuration system in place already?
>
> [vbraun@volker-desktop ~]$ du -sh ~/.ccache/
> 44G /home/vbra
On 2013-01-09 19:15, Nils Bruin wrote:
> Incidentally, how does ccache operate if $HOME/.ccache is shared
> between computers with different architectures and operating system
> versions/compiler versions? Does it notice and avoid that? Does it
> notice when difference are small enough that both ma
I am on OSX 10.8.2 and just installed the new Xcode 4.5.2
I had the same problem with mercurial as encountered in
https://groups.google.com/forum/?fromgroups=#!searchin/sage-devel/10.8$20build$20cython/sage-devel/kfXamuej_Gs/kLUoIxrQnYMJ
and the suggested fix worked. Now it has failed to build c
On Wednesday, January 9, 2013 10:45:32 AM UTC-8, Ben Hutz wrote:
>
> I am on OSX 10.8.2 and just installed the new Xcode 4.5.2
>
> I had the same problem with mercurial as encountered in
> https://groups.google.com/forum/?fromgroups=#!searchin/sage-devel/10.8$20build$20cython/sage-devel/kfXamuej
ccache defaults to using one gigabyte at most. This would still be useful
on slow disks as it should fit into the disk cache of today's systems, no
matter how slow your network file system is. I just manually increased it
to 50GB on my desktop.
On Wednesday, January 9, 2013 6:15:09 PM UTC, Ni
This is http://trac.sagemath.org/13898. The following workaround should
help to get around Apple's broken headers:
CFLAGS="-DOS_OBJECT_USE_OBJC=0"
export CFLAGS
make
On Wednesday, January 9, 2013 6:45:32 PM UTC, Ben Hutz wrote:
>
> I am on OSX 10.8.2 and just installed the new Xcode 4.5.2
>
>
On 9 January 2013 13:33, Jeroen Demeyer wrote:
> Did you explicitly ask *not* to install GCC (i.e. SAGE_INSTALL_GCC=no)?
> Because by default, Sage should build GCC if your system has gcc-4.3.4.
No, I did not. No SAGE* environment variables were set. Somewhere in
the install log I see
checking
On 2013-01-09 20:34, John Cremona wrote:
> On 9 January 2013 13:33, Jeroen Demeyer wrote:
>> Did you explicitly ask *not* to install GCC (i.e. SAGE_INSTALL_GCC=no)?
>> Because by default, Sage should build GCC if your system has gcc-4.3.4.
>
> No, I did not. No SAGE* environment variables were s
On 9 January 2013 19:37, Jeroen Demeyer wrote:
> On 2013-01-09 20:34, John Cremona wrote:
>> On 9 January 2013 13:33, Jeroen Demeyer wrote:
>>> Did you explicitly ask *not* to install GCC (i.e. SAGE_INSTALL_GCC=no)?
>>> Because by default, Sage should build GCC if your system has gcc-4.3.4.
>>
>>
Opps. I didn't realize I had to re-install those as well.
Now, to ask dumb question. I installed them and tried to build again, to
get the same error. Do I need to delete the partial build and start over
now that I've installed the tools?
On Wednesday, January 9, 2013 1:54:37 PM UTC-5, John H P
This doesn't work for my cython error. (The error in my first post is what
I get after trying that)
On Wednesday, January 9, 2013 2:03:38 PM UTC-5, Volker Braun wrote:
>
> This is http://trac.sagemath.org/13898. The following workaround should
> help to get around Apple's broken headers:
>
> CFL
You need to rebuild from scratch, the real error was during the Python
compilation.
On Wednesday, January 9, 2013 8:13:46 PM UTC, Ben Hutz wrote:
>
> This doesn't work for my cython error. (The error in my first post is what
> I get after trying that)
>
--
You received this message because you
Hi all,
what do I need to do to use ccache? On my openSuse laptop, I did install
ccache (yast2 -i ccache), but there is no ~/.ccache folder even though I
compiled a couple of things after installation.
Best regards,
Simon
--
You received this message because you are subscribed to the Google Gro
On 9 January 2013 19:50, John Cremona wrote:
> On 9 January 2013 19:37, Jeroen Demeyer wrote:
>> On 2013-01-09 20:34, John Cremona wrote:
>>> On 9 January 2013 13:33, Jeroen Demeyer wrote:
Did you explicitly ask *not* to install GCC (i.e. SAGE_INSTALL_GCC=no)?
Because by default, Sage
The gcc/g++/... should all be symlinks to ccache if it is correctly set up.
E.g.:
[vbraun@volker-desktop ~]$ ls -al `which gcc`
lrwxrwxrwx. 1 root root 16 Dec 1 19:05 /usr/lib64/ccache/gcc ->
../../bin/ccache
On Wednesday, January 9, 2013 8:57:32 PM UTC, Simon King wrote:
>
> Hi all,
>
> w
On Jan 9, 12:57 pm, Simon King wrote:
> Hi all,
>
> what do I need to do to use ccache?
See "man ccache". However, some comments on gotchas to get that
working properly with sage would be welcome.
Would something like
ln -s ccache $SAGE_ROOT/local/bin/gcc
ln -s ccache $SAGE_ROOT/local/bin/g++
l
Is 1G an acceptable default for Sage? (I.e is it sufficient for a full
Sage build (plus some branching) plus a fair amount of other stuff?
This is my only concern, otherwise I'd say option (1) is the best.
Where $HOME sits is is rather irrelevant, as both .ccache and .sage
sit there (by default, a
I installed ccache (on ubuntu) but did no symlinking -- instead I
compiled eclib after (re)configuring using CXX='ccache gcc'
./configure. The result was a 320MB ~/.ccache, and a *very* quick
recompile after "make clean; make".
I did not want to mess around with the system gcc as it's a shared
ma
On Wed, Jan 9, 2013 at 2:00 PM, John Cremona wrote:
> I installed ccache (on ubuntu) but did no symlinking -- instead I
> compiled eclib after (re)configuring using CXX='ccache gcc'
> ./configure. The result was a 320MB ~/.ccache, and a *very* quick
> recompile after "make clean; make".
>
Unfor
On Wed, Jan 9, 2013 at 2:07 PM, R. Andrew Ohana wrote:
> On Wed, Jan 9, 2013 at 2:00 PM, John Cremona wrote:
>>
>> I installed ccache (on ubuntu) but did no symlinking -- instead I
>> compiled eclib after (re)configuring using CXX='ccache gcc'
>> ./configure. The result was a 320MB ~/.ccache, an
On Jan 9, 2:46 pm, Robert Bradshaw
wrote:
> Disk space is (relatively) cheap. I think anyone who builds Sage from
> source is likely to build it again, i.e. be a (potential) developer.
Not *all* disk space is cheap, though. If I install and build a piece
of software on a disk I have designated fo
On Jan 9, 2:46 pm, Robert Bradshaw
wrote:
> I think anyone who builds Sage from
> source is likely to build it again, i.e. be a (potential) developer.
But you shouldn't measure this per person. Given sage's finicky
configuration, the most trustworthy deployment on multiple computers
is to just co
On Wed, Jan 9, 2013 at 4:27 PM, Nils Bruin wrote:
> On Jan 9, 2:46 pm, Robert Bradshaw
> wrote:
>> Disk space is (relatively) cheap. I think anyone who builds Sage from
>> source is likely to build it again, i.e. be a (potential) developer.
>
> Not *all* disk space is cheap, though. If I install
On Jan 9, 5:00 pm, Robert Bradshaw wrote:
> That defeats the purpose of sharing ccache across Sage builds.
That won't yield a benefit anyway. Quoting from the manpage:
"""
For both modes, the following information is included in the hash:
· the extension used by the compiler for a file with p
On Wed, Jan 9, 2013 at 5:24 PM, Nils Bruin wrote:
> On Jan 9, 5:00 pm, Robert Bradshaw wrote:
>
> > That defeats the purpose of sharing ccache across Sage builds.
> That won't yield a benefit anyway. Quoting from the manpage:
>
> """
> For both modes, the following information is included in the
Benjamin Jones writes:
> On Mon, Jan 7, 2013 at 10:53 AM, Keshav Kini wrote:
>> Benjamin Jones writes:
>>> sage: y = var('y')
>>> sage: x * (y > 0)
>>> x*y > 0
>>>
>>> Just like applying the operator (x*_) over a list [ y, 0 ].
>>
>> Couldn't you apply the same logic to "*" as well? Now (a * b)
On Wednesday, January 9, 2013 9:46:09 AM UTC-8, Jordi Gutiérrez Hermoso
wrote:
>
> On 9 January 2013 11:23, Volker Braun >
> wrote:
> > * Sage needs something better than mq now, not "when its finished"
>
> "Now" is probably "very soon". Mercurial is being used and developed
> heavily by Faceb
44 matches
Mail list logo
