[sage-devel] Teaching in Cape Town

[Jan Groenewald]

Dear All,

Course Proposals for the 2013-14 Masters at AIMS, Cape Town are now open.
Courses in Sage or in mathematical topics using Sage for computer exercises
are welcome:
http://www.aims.ac.za/en/apply/structured-masters-course-proposals

More about AIMS:
http://www.nature.com/news/education-africa-s-counting-house-1.11757

Regards,
Jan


-- 
  .~.
  /V\ Jan Groenewald
 /( )\www.aims.ac.za
 ^^-^^

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: ccache defaults?

[Julien Puydt]

Le 11/01/2013 06:21, Robert Bradshaw a écrit :

Perhaps I value my time more than I value disk space, but to save
minutes or hours at each build is worth a lot to me. Maybe once this
gets to be a standard spkg and people have played around with it, we
can have a vote on whether to enable it by default.


May I once again notice that the two point of views in opposition are 
about sage-as-a-distribution versus sage-as-a-software?


Those working on sage-as-a-distribution want ccache in sage to speed up 
their compilation, because that's what counts.


Those working on sage-as-a-software don't want ccache in sage because it 
is a burden without bringing any feature, and that's what counts.


Snark on #sagemath

--
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: ccache defaults?

[Julien Puydt]

Le 11/01/2013 02:47, Robert Bradshaw a écrit :

If 1G, or even 4G, is a sizable portion of your disk space, your disk
is really small and you shouldn't be using ccache at all...


The ARM box I use has 16G of storage. It has the system and a sage 
install with enough room to build the bdist. If you add a big ccache to 
the mix, that will be painful.


Snark on #sagemath

--
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: About log and ln. Free fight.

[rjf]

A much more problematical issue is whether you are going to do this:

Log,  the Principal Log 
  vs
log,   the ordinary log, where log(x) = Log(x) + 2*n*i*pi  for integer n.



-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: [sage-nt] Re: On Sage-days

[Robert Bradshaw]

On Thu, Jan 10, 2013 at 6:41 PM, Dima Pasechnik  wrote:
> On 2013-01-04, Zhibin Liang  wrote:
>> --14dae9cfce94af9cb504d2769785
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Dear  all,
>>
>> I want to organise a "sage-days sports" in Beijing International Center for
>> Mathematical Research in Beijing University. Can anybody tell me what I
>> should do next?

I would give a little bit of a background about yourself, and also
what topics you would expect the Sage Days to revolve around (do you
mean "sports" like football, hockey, ? I'm not seeing how that's a
Sage Days, and I bet a lot of others are in the same boat, so there's
probably some misunderstanding here). It would also be good to state
the intended audience (locals? core developers or newbies?). Sage Days
are typically organized (and funded) by the hosting organization,
there's no central planning committee (though plenty of people willing
to give advice).

- Robert

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: ccache defaults?

[Robert Bradshaw]

On Thu, Jan 10, 2013 at 9:04 PM, Nils Bruin  wrote:
> On Jan 10, 7:44 pm, P Purkayastha  wrote:
>> We are thinking about people using 256G or even 500G+ hard disks and
>> desktops. But what about people who are developing on notebooks with
>> only SSDs?
>
> If you only have one disk the question isn't where the cache should be
> but if there should be one at all. It's on more complicated systems
> with multiple disks that the location is important. If I put an SSD in
> my desktop (60Gb for / and /usr/local etc, so 4Gb is considerable, but
> that's what the disk is for) and put sage in /usr/local/sage (owned by
> my UID because no-one else really uses that machine, or at least not
> for sage) for fast development I'd be really disappointed if it
> silently puts most crap in /home, which is slow NFS and premium backed
> up stuff. I'm already less than pleased with all the temporary things
> sage scribbles in .sage.
> .sage/gap is the worst offender with 63Mb; .sage/tmp a close second
> due to accumulated failed doctest scripts.
>
> Just locating .sage elsewhere is not easy to do either, because there
> are valuable things in there too that deserve getting backed up and/or
> being shared between different machines (notebook, config files)
>
> Without warning I would definitely not expect that sage would be
> silently scribbling up to 4Gb into .sage for something that's not even
> relevant for my *use* of sage, only for building it.
>
> I understand sage cannot be clairvoyant. However, it seems to me that
> sage needs several kinds of storage that would need different kind of
> storage:
>
>  - user configuration (traditional $HOME/.sage and/or $HOME/.sagerc
> stuff)
>  - valuable data (notebook. A little bulky but needs backup)
>  - runtime caches etc. (some sobjs and workspaces. Some would better
> be read-only during read time)
>  - testing scribble space
>  - buildtime ccache
>
> If sage would separate things out by subdir of .sage (or even more
> environment variables) it would be easier to locate each on
> appropriate disks.

A huge +1 for separating out the ephemeral .sage stuff from the
slow-changing backup-worthy stuff (config, worksheets). Any objections?

- Robert

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: ccache defaults?

[Robert Bradshaw]

On Thu, Jan 10, 2013 at 7:44 PM, P Purkayastha  wrote:
> On 01/11/2013 09:47 AM, Robert Bradshaw wrote:
>>
>> On Thu, Jan 10, 2013 at 4:32 PM, P Purkayastha  wrote:
>>>
>>> On 01/11/2013 02:46 AM, Robert Bradshaw wrote:

 I am not opposed to this. Lets get the package in; if we need to
 revise where the default cache sits at some later date based on how it
 actually gets used we can do so then.

 - Robert
>>>
>>>
>>> Given that ccache will take up a sizable portion of your disk space (if
>>> you
>>> started using it), I think it is important to finalize the directory now
>>> rather than at some later update of Sage.
>>
>>
>> If 1G, or even 4G, is a sizable portion of your disk space, your disk
>> is really small and you shouldn't be using ccache at all... If we use
>> our own cache somewhere, we can always purge it when we move it, and
>> if we use the common one it'll get collected by the user and/or other
>> compilations over time, so changing our minds later isn't that big of
>> a deal.
>>
>> - Robert
>
>
> We are thinking about people using 256G or even 500G+ hard disks and
> desktops. But what about people who are developing on notebooks with only
> SSDs? SSDs will be more prevalent in the coming months,

I'll make tje wild prediction that SSD capacity will go up in the
future as well :-).

> with all the
> "ultrabook" craze. The processors are pretty powerful but most
> configurations come with 128G disks. So yes, 1G and 4G are still a premium.

Perhaps I value my time more than I value disk space, but to save
minutes or hours at each build is worth a lot to me. Maybe once this
gets to be a standard spkg and people have played around with it, we
can have a vote on whether to enable it by default.

- Robert

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: ccache defaults?

[Nils Bruin]

On Jan 10, 7:44 pm, P Purkayastha  wrote:
> We are thinking about people using 256G or even 500G+ hard disks and
> desktops. But what about people who are developing on notebooks with
> only SSDs?

If you only have one disk the question isn't where the cache should be
but if there should be one at all. It's on more complicated systems
with multiple disks that the location is important. If I put an SSD in
my desktop (60Gb for / and /usr/local etc, so 4Gb is considerable, but
that's what the disk is for) and put sage in /usr/local/sage (owned by
my UID because no-one else really uses that machine, or at least not
for sage) for fast development I'd be really disappointed if it
silently puts most crap in /home, which is slow NFS and premium backed
up stuff. I'm already less than pleased with all the temporary things
sage scribbles in .sage.
.sage/gap is the worst offender with 63Mb; .sage/tmp a close second
due to accumulated failed doctest scripts.

Just locating .sage elsewhere is not easy to do either, because there
are valuable things in there too that deserve getting backed up and/or
being shared between different machines (notebook, config files)

Without warning I would definitely not expect that sage would be
silently scribbling up to 4Gb into .sage for something that's not even
relevant for my *use* of sage, only for building it.

I understand sage cannot be clairvoyant. However, it seems to me that
sage needs several kinds of storage that would need different kind of
storage:

 - user configuration (traditional $HOME/.sage and/or $HOME/.sagerc
stuff)
 - valuable data (notebook. A little bulky but needs backup)
 - runtime caches etc. (some sobjs and workspaces. Some would better
be read-only during read time)
 - testing scribble space
 - buildtime ccache

If sage would separate things out by subdir of .sage (or even more
environment variables) it would be easier to locate each on
appropriate disks.

Incidentally, I've just found:

$ which gcc
/usr/lib64/ccache/gcc

and indeed, together with .mozilla/firefox, .ccache is the biggest dot-
directory, .java coming pretty close too and .sage featuring in the
top 10. So this problem is not unique for .sage but it would be nice
if we could ameliorate it.

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: ccache defaults?

[P Purkayastha]

On 01/11/2013 09:47 AM, Robert Bradshaw wrote:

On Thu, Jan 10, 2013 at 4:32 PM, P Purkayastha  wrote:

On 01/11/2013 02:46 AM, Robert Bradshaw wrote:

I am not opposed to this. Lets get the package in; if we need to
revise where the default cache sits at some later date based on how it
actually gets used we can do so then.

- Robert


Given that ccache will take up a sizable portion of your disk space (if you
started using it), I think it is important to finalize the directory now
rather than at some later update of Sage.


If 1G, or even 4G, is a sizable portion of your disk space, your disk
is really small and you shouldn't be using ccache at all... If we use
our own cache somewhere, we can always purge it when we move it, and
if we use the common one it'll get collected by the user and/or other
compilations over time, so changing our minds later isn't that big of
a deal.

- Robert


We are thinking about people using 256G or even 500G+ hard disks and 
desktops. But what about people who are developing on notebooks with 
only SSDs? SSDs will be more prevalent in the coming months, with all 
the "ultrabook" craze. The processors are pretty powerful but most 
configurations come with 128G disks. So yes, 1G and 4G are still a premium.


--
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: ccache defaults?

[Robert Bradshaw]

On Thu, Jan 10, 2013 at 4:32 PM, P Purkayastha  wrote:
> On 01/11/2013 02:46 AM, Robert Bradshaw wrote:
>>
>> On Thu, Jan 10, 2013 at 6:25 AM, Jeroen Demeyer 
>> wrote:
>>>
>>> On 2013-01-09 17:13, Jeroen Demeyer wrote:

 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 sage-5.6.beta2). There is an optional Sage
 package for ccache.

 The problematic question is: where should the cache files (i.e. the
 files produced by ccache) be stored by default?  These are the
 possibilities:
 (1) The ccache default directory: $HOME/.ccache
 (2) Inside .sage: $HOME/.sage/ccache
 (3) Compromise: (1) if using a system-wide ccache installation, (2) when
 using the ccache optional spkg.
>>>
>>>
>>> Is anybody against implementing (3)?  I believe it gives us the best of
>>> both worlds: it won't bother people already using ccache and it will
>>> keep the people happy who are using the ccache spkg and who want Sage to
>>> be as self-contained as possible.
>>
>>
>> I am not opposed to this. Lets get the package in; if we need to
>> revise where the default cache sits at some later date based on how it
>> actually gets used we can do so then.
>>
>> - Robert
>
> Given that ccache will take up a sizable portion of your disk space (if you
> started using it), I think it is important to finalize the directory now
> rather than at some later update of Sage.

If 1G, or even 4G, is a sizable portion of your disk space, your disk
is really small and you shouldn't be using ccache at all... If we use
our own cache somewhere, we can always purge it when we move it, and
if we use the common one it'll get collected by the user and/or other
compilations over time, so changing our minds later isn't that big of
a deal.

- Robert

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: Evolve extension in hg: almost ready for use

[Keshav Kini]

Jordi Gutiérrez Hermoso  writes:
>> Also, is there a specific feature of Evolve that would greatly
>> benefit Sage's development?
>
> Evolve is directly targetting to replace MQ usage. For Sage users
> already used to MQ, they can use Evolve as a direct replacement for MQ
> without having to learn a whole other DVCS and a completely different
> way to work. There's a direct dictionary translating MQ usage to
> Evolve usage.

Just a note: one of our major goals for moving to git is to switch from
a patch-based to a commit-based development model. This of course
entails completely ditching the concept of "patch queues".

-Keshav

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: ccache defaults?

[P Purkayastha]

On 01/11/2013 02:46 AM, Robert Bradshaw wrote:

On Thu, Jan 10, 2013 at 6:25 AM, Jeroen Demeyer  wrote:

On 2013-01-09 17:13, Jeroen Demeyer wrote:

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 sage-5.6.beta2). There is an optional Sage
package for ccache.

The problematic question is: where should the cache files (i.e. the
files produced by ccache) be stored by default?  These are the
possibilities:
(1) The ccache default directory: $HOME/.ccache
(2) Inside .sage: $HOME/.sage/ccache
(3) Compromise: (1) if using a system-wide ccache installation, (2) when
using the ccache optional spkg.


Is anybody against implementing (3)?  I believe it gives us the best of
both worlds: it won't bother people already using ccache and it will
keep the people happy who are using the ccache spkg and who want Sage to
be as self-contained as possible.


I am not opposed to this. Lets get the package in; if we need to
revise where the default cache sits at some later date based on how it
actually gets used we can do so then.

- Robert


Given that ccache will take up a sizable portion of your disk space (if 
you started using it), I think it is important to finalize the directory 
now rather than at some later update of Sage.




--
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: Weird issue with matrix mutability

[Nils Bruin]

On Jan 10, 3:20 pm, Johannes  wrote:
> But in the _copy_() method _mutability is set to a value.
Yes, that's the line that led me to the fixed ticket #8294.

A thing to keep in mind is that the designers of 2x2 matrices might
have been willing to give up some features (such a immutability) in
favor of efficiency. By properly setting mutability you suddenly have
a full-blown python object hanging off your matrix. The cost of its
construction and allocation can easily overshadow everything else (I
haven't timed it).

It could be more appropriate to fix this by making 2x2 matrices always
immutable (then the methods accessing that can be special-cases on the
class) or by lying and just making set_immutable a no-op.

Or perhaps by documenting "2x2 matrices aren't a full implementation
of matrices, but we inherit from it anyway by way of a hack. Don't
expect that ... will always properly work. Only use 2x2 matrices when
you need the speed and don't care about the unimplemented features".

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: Weird issue with matrix mutability

[Johannes]

I think it would be enough to move the _mutability = Mutability(False)
statement from the _copy_() method to the _new_c() method.

On 11.01.2013 00:20, Johannes wrote:
> But in the _copy_() method _mutability is set to a value. Even if I
> think this should be done in _new_c().
> 
> By the way, this bug also appears for x + y and x - y.
> 
> greatz Johannes
> 
> On 10.01.2013 23:34, Nils Bruin wrote:
>> On Jan 10, 12:55 pm, Johannes  wrote:
>>> hey list,
>>>
>>> If you look at the code, there is a function called _new_c() which is
>>> used in the multiplication algorithm.
>>
>> See
>>
>> http://trac.sagemath.org/sage_trac/ticket/8294
>>
>> Looks like a little more is broken than just __copy__.
>>
>> Normally, _mutability gets set in matrix0's Matrix.__init__.
>>
>> Matrix_integer_dense gets that by explicitly calling a superclass
>> __init__ in its __cinit__. I guess 2x2 tries to avoid that for
>> efficiency reasons, but it suggests that its __cinit__ (or at least
>> its _new_c) should then set the _mutability attribute. Is this class
>> intentionally producing maimed instances for efficiency reasons
>> perhaps?
>>
> 

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: Weird issue with matrix mutability

[Johannes]

But in the _copy_() method _mutability is set to a value. Even if I
think this should be done in _new_c().

By the way, this bug also appears for x + y and x - y.

greatz Johannes

On 10.01.2013 23:34, Nils Bruin wrote:
> On Jan 10, 12:55 pm, Johannes  wrote:
>> hey list,
>>
>> If you look at the code, there is a function called _new_c() which is
>> used in the multiplication algorithm.
> 
> See
> 
> http://trac.sagemath.org/sage_trac/ticket/8294
> 
> Looks like a little more is broken than just __copy__.
> 
> Normally, _mutability gets set in matrix0's Matrix.__init__.
> 
> Matrix_integer_dense gets that by explicitly calling a superclass
> __init__ in its __cinit__. I guess 2x2 tries to avoid that for
> efficiency reasons, but it suggests that its __cinit__ (or at least
> its _new_c) should then set the _mutability attribute. Is this class
> intentionally producing maimed instances for efficiency reasons
> perhaps?
> 

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: Weird issue with matrix mutability

[Nils Bruin]

On Jan 10, 12:55 pm, Johannes  wrote:
> hey list,
>
> If you look at the code, there is a function called _new_c() which is
> used in the multiplication algorithm.

See

http://trac.sagemath.org/sage_trac/ticket/8294

Looks like a little more is broken than just __copy__.

Normally, _mutability gets set in matrix0's Matrix.__init__.

Matrix_integer_dense gets that by explicitly calling a superclass
__init__ in its __cinit__. I guess 2x2 tries to avoid that for
efficiency reasons, but it suggests that its __cinit__ (or at least
its _new_c) should then set the _mutability attribute. Is this class
intentionally producing maimed instances for efficiency reasons
perhaps?

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Weird issue with matrix mutability

[Johannes]

hey list,

If you look at the code, there is a function called _new_c() which is
used in the multiplication algorithm.

In there, the following line is called:
x =  Matrix_integer_2x2.__new__(Matrix_integer_2x2,
self._parent, None, False, False)

this returns a Matrix_integer_2x2, but is different from the one you
get, if you call:
Matrix_integer_2x2(M2Z,None,false,false)


sage: from sage.matrix.matrix_integer_2x2 import Matrix_integer_2x2 as mi2x2
sage: M2Z = MatrixSpace(ZZ,2)
sage: null = mi2x2(M2Z,None,false,false);null
[0 0]
[0 0]
sage: some_other_null = mi2x2.__new__(mi2x2, M2Z , None, False,
False);some_other_null
[]
sage: some_other_null.set_immutable()
---
AttributeError Traceback (most recent call last):

[..]

AttributeError: 'NoneType' object has no attribute 'set_immutable'

even, if in _new_c the number of cols and rows is set, I think there is
some internal object, which still has no value

greatz Johannes

On 10.01.2013 10:10, David Loeffler wrote:
> The following curious bug came up during work on ticket #12233. For some
> reason, if one creates a 2x2 integer matrix directly using the
> constructor then it is possible to tell it to be immutable; but if one
> creates one via arithmetic operations then calling "set_immutable" on it
> fails. Here's an example:
> 
>  sage: from sage.matrix.matrix_integer_2x2 import Matrix_integer_2x2 as
>  mi2x2
>  sage: M2Z = MatrixSpace(ZZ,2)
>  sage: mi2x2(M2Z, [1,0,0,1])
>  sage: x=mi2x2(M2Z, [1,0,0,1], false, false)
>  sage: y=mi2x2(M2Z, [1,0,0,1], false, false)
>  sage: type(x)
>  
>  sage: z = x*y
>  sage: type(z)
>  
>  sage: x.set_immutable()# ok
>  sage: z.set_immutable()# error
> [...]
> AttributeError: 'NoneType' object has no attribute 'set_immutable'
>  
> (Many thanks to Timo Kluck for clarifying the problem and finding this
> example.) Does anyone have any idea what's going on here, and if so how
> to fix it?
> 
> Regards, David
> 
> -- 
> 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 unsubscribe from this group, send email to
> sage-devel+unsubscr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel?hl=en.
>  
>  

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: ccache defaults?

[Robert Bradshaw]

On Thu, Jan 10, 2013 at 9:01 AM, Nils Bruin  wrote:
> On Jan 10, 1:50 am, Volker Braun  wrote:
>> I don't
>> think anybody is proposing to make ccache a standard spkg, for starters it
>> does not help for the one-time Sage build. Just don't use ccache if it
>> doesn't fit in your or your organization's infrastructure.
>
> I agree with that. If it's an optional spkg, it's completely
> reasonable that you have to read some doc to get it to behave the way
> you want. I had the impression Robert was suggesting to make ccache
> *standard*, though. I think in that case one has to be a bit more
> careful with what gets dumped in $HOME (by default).

I am advocating making ccache (at least the spkg and maybe even its
use) standard, but getting it in as an optional spkg is the first step
of course.

- Robert

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] ccache defaults?

[Robert Bradshaw]

On Thu, Jan 10, 2013 at 6:25 AM, Jeroen Demeyer  wrote:
> On 2013-01-09 17:13, Jeroen Demeyer wrote:
>> 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 sage-5.6.beta2). There is an optional Sage
>> package for ccache.
>>
>> The problematic question is: where should the cache files (i.e. the
>> files produced by ccache) be stored by default?  These are the
>> possibilities:
>> (1) The ccache default directory: $HOME/.ccache
>> (2) Inside .sage: $HOME/.sage/ccache
>> (3) Compromise: (1) if using a system-wide ccache installation, (2) when
>> using the ccache optional spkg.
>
> Is anybody against implementing (3)?  I believe it gives us the best of
> both worlds: it won't bother people already using ccache and it will
> keep the people happy who are using the ccache spkg and who want Sage to
> be as self-contained as possible.

I am not opposed to this. Lets get the package in; if we need to
revise where the default cache sits at some later date based on how it
actually gets used we can do so then.

- Robert

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: ccache defaults?

[Nils Bruin]

On Jan 10, 1:50 am, Volker Braun  wrote:
> I don't
> think anybody is proposing to make ccache a standard spkg, for starters it
> does not help for the one-time Sage build. Just don't use ccache if it
> doesn't fit in your or your organization's infrastructure.

I agree with that. If it's an optional spkg, it's completely
reasonable that you have to read some doc to get it to behave the way
you want. I had the impression Robert was suggesting to make ccache
*standard*, though. I think in that case one has to be a bit more
careful with what gets dumped in $HOME (by default).

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: ccache defaults?

[Nils Bruin]

On Jan 10, 12:21 am, Jeroen Demeyer  wrote:
> jdemeyer@sage:~$ ccache -s
> cache directory                     /home/jdemeyer/.ccache
> cache hit (direct)               5889666
> cache hit (preprocessed)          980843
> cache miss547099
> called for link   668036
[...]
Those stats show that ccache likely has an impact with the way in
which you compile sage. Does it show that the cache has a beneficial
effect between builds of sage in different directories? The setting of
CCACHE_BASEDIR makes me hopeful.

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: About log and ln. Free fight.

[kcrisman]

>
> > Don't change anything. Status quo is fine. 
>
> +1 
>
> Agreed. There is likely some optimization possible, but probably not 
really necessary.

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: About log and ln. Free fight.

[Burcin Erocal]

On Thu, 10 Jan 2013 22:15:45 +0800
P Purkayastha  wrote:

> On 01/10/2013 10:09 PM, Nathann Cohen wrote:
> > H Yep, log2 and log10 sound good indeed !
> >
> > So what do we do, in the end ?
> >
> > ln(e) = 1
> > log(10) = 1
> > log2(2) = 1
> >
> > Or do we stick log(e) = ln(e) = 1 ?
> 
> Don't change anything. Status quo is fine.

+1

We have too many aliases as it is. Anybody who needs these can add a
suitable lambda expression to their init.sage file.

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: About log and ln. Free fight.

[Nathann Cohen]

> I don't see why we have to burn anything.

Sheer fun.

> Why not define log_2 and log_10?
> Aren't those legitimate identifiers?

It would be weird to have both log2 and log_2, both having different
meanings O_o

> The only objection I can see to this is the ISO standard mentioned above,
in
> which case. I wasn't aware we were following ISO standards, though.

Following a standard is always a bad reason for doing something.

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@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: About log and ln. Free fight.

[john_perry_usm]

On Thursday, January 10, 2013 8:38:56 AM UTC-6, Nathann Cohen wrote:
>
> > i.e. log2 is already defined to equal log(2) (to base e!).  We are
> > already inconsistent, since log2 is a symbolic constant meaning
> > log(2), whereas there are *already* functions in Sage whenre log2
> > means log-to-the-base-2:
> >
> > sage: RR(32).log2()
> > 5.00
>
> Ahahaahahahahahahahahahaah :-
>
> So ? What do we burn ? :-P
>
> (if log2 becomes a function, it should break all code using it as a 
> constant, which is nice. And as log2() will raise an error too, I'd say 
> that we are safe if we change log2(x) to log(x,2))

 
I don't see why we have to burn anything. Why not define log_2 and log_10? 
Aren't those legitimate identifiers?

The only objection I can see to this is the ISO standard mentioned above, 
in which case. I wasn't aware we were following ISO standards, though.

john perry

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: About log and ln. Free fight.

[Nathann Cohen]

> i.e. log2 is already defined to equal log(2) (to base e!).  We are
> already inconsistent, since log2 is a symbolic constant meaning
> log(2), whereas there are *already* functions in Sage whenre log2
> means log-to-the-base-2:
>
> sage: RR(32).log2()
> 5.00

Ahahaahahahahahahahahahaah :-

So ? What do we burn ? :-P

(if log2 becomes a function, it should break all code using it as a
constant, which is nice. And as log2() will raise an error too, I'd say
that we are safe if we change log2(x) to log(x,2))

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@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: About log and ln. Free fight.

[John Cremona]

I would agree to all the above, but be warned:

sage: log2
log2
sage: type(log2)

sage: log2.n()
0.693147180559945
sage: log(2)
log(2)
sage: log(2).n()
0.693147180559945


i.e. log2 is already defined to equal log(2) (to base e!).  We are
already inconsistent, since log2 is a symbolic constant meaning
log(2), whereas there are *already* functions in Sage whenre log2
means log-to-the-base-2:

sage: RR(32).log2()
5.00


John

On 10 January 2013 14:18, Nathann Cohen  wrote:
>> Certainly don't change log(), that would break way too much!
>
> Ahahaah. I'm in this kind of mood, sometimes :-P
>
> okok, then just an alias for log10 and log2 ? I believe that this makes 
> sense...
>
> 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@googlegroups.com.
> To unsubscribe from this group, send email to 
> sage-devel+unsubscr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel?hl=en.
>
>

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] ccache defaults?

[Jeroen Demeyer]

On 2013-01-09 17:13, Jeroen Demeyer wrote:
> 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 sage-5.6.beta2). There is an optional Sage
> package for ccache.
> 
> The problematic question is: where should the cache files (i.e. the
> files produced by ccache) be stored by default?  These are the
> possibilities:
> (1) The ccache default directory: $HOME/.ccache
> (2) Inside .sage: $HOME/.sage/ccache
> (3) Compromise: (1) if using a system-wide ccache installation, (2) when
> using the ccache optional spkg.

Is anybody against implementing (3)?  I believe it gives us the best of
both worlds: it won't bother people already using ccache and it will
keep the people happy who are using the ccache spkg and who want Sage to
be as self-contained as possible.

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: About log and ln. Free fight.

[Nathann Cohen]

> Certainly don't change log(), that would break way too much!

Ahahaah. I'm in this kind of mood, sometimes :-P

okok, then just an alias for log10 and log2 ? I believe that this makes sense...

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@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: About log and ln. Free fight.

[P Purkayastha]

On 01/10/2013 10:09 PM, Nathann Cohen wrote:

H Yep, log2 and log10 sound good indeed !

So what do we do, in the end ?

ln(e) = 1
log(10) = 1
log2(2) = 1

Or do we stick log(e) = ln(e) = 1 ?


Don't change anything. Status quo is fine.


--
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: About log and ln. Free fight.

[Jeroen Demeyer]

On 2013-01-10 15:09, Nathann Cohen wrote:
> H Yep, log2 and log10 sound good indeed !
> 
> So what do we do, in the end ?
> 
> ln(e) = 1
> log(10) = 1
> log2(2) = 1
> 
> Or do we stick log(e) = ln(e) = 1 ?

Certainly don't change log(), that would break way too much!

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: About log and ln. Free fight.

[Nathann Cohen]

H Yep, log2 and log10 sound good indeed !

So what do we do, in the end ?

ln(e) = 1
log(10) = 1
log2(2) = 1

Or do we stick log(e) = ln(e) = 1 ?

Nathann

On 10 January 2013 14:07, Kresimir Kumericki  wrote:

> Note that log(x) means log(x, 10) for many people, including most of those
> using pocket calculators where "log" key often calculates log(x, 10) by
> default. Furthermore ISO standard 31-11 
> says:
> lb(x) = log(x, 2).
>
> --
> 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 unsubscribe from this group, send email to
> sage-devel+unsubscr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel?hl=en.
>
>
>

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: ccache defaults?

[Jeroen Demeyer]

On 2013-01-10 14:39, Simon King wrote:
> Hi!
> 
> I tried to understand from "man ccache" how the compiled .c or .cc files
> are cached, but to no avail. Will it be verified whether the actual
> content has changed? Or will there be a new compilation, if the time
> stamp of the .c/.cc file is more recent than during the last compilation
> of that file?
> 
> If it is the latter, then I wonder how all the Cython code in Sage would
> benefit from ccache. First, Cython translates the .pyx file into a .c
> file, whose time stamp is thus new.
Timestamps aren't used, a hash of the source file (and other data, such
as include files and the compiler executable) *or* a hash of the
pre-processed source file is used, whichever matches.

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: Evolve extension in hg: almost ready for use

[Jordi Gutiérrez Hermoso]

On 10 January 2013 00:04, Kelvin Li  wrote:
> 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 Facebook, since they've hired a couple of key hg devs, and
>> Evolve has been, well, evolving, quite rapidly. It's not ready for
>> production use, but it's very close.
>
> Is it possible to use mercurial to interact with other git users? If so,
> then there shouldn't be any problems, right?

To some extent, yes, as long as you don't rewrite history a whole lot,
hg-git can let you mirror a git repository with hg. Hg and git take
fundamentally different approaches to rewriting history (roughly, hg
uses obsolete markers with Evolve or backup bundles traditionally,
while git garbage collects), so it's not really possible to bridge the
difference between these two. Git also offers no real way to rewrite
public history (look at the section titled "Recovering From Upstream
Rebase" in git-rebase(1) to see what the problems are), while Evolve's
obsolete markers are specifically targetted at being able to
collaboratively edit history.

> Also, is there a specific feature of Evolve that would greatly
> benefit Sage's development?

Evolve is directly targetting to replace MQ usage. For Sage users
already used to MQ, they can use Evolve as a direct replacement for MQ
without having to learn a whole other DVCS and a completely different
way to work. There's a direct dictionary translating MQ usage to
Evolve usage.

- Jordi G. H.

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: ccache defaults?

[Simon King]

Hi!

I tried to understand from "man ccache" how the compiled .c or .cc files
are cached, but to no avail. Will it be verified whether the actual
content has changed? Or will there be a new compilation, if the time
stamp of the .c/.cc file is more recent than during the last compilation
of that file?

If it is the latter, then I wonder how all the Cython code in Sage would
benefit from ccache. First, Cython translates the .pyx file into a .c
file, whose time stamp is thus new.

Best regards,
Simon

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: About log and ln. Free fight.

[Kresimir Kumericki]

Note that log(x) means log(x, 10) for many people, including most of those 
using pocket calculators where "log" key often calculates log(x, 10) by 
default. Furthermore ISO standard 31-11 
says: 
lb(x) = log(x, 2).

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] About log and ln. Free fight.

[John Cremona]

Both log2 and log10 are standard C terminology, as well as being very
close to mathematical \log_{2} and \log_{10}, so I vote for these.

John

On 10 January 2013 12:43, Florent Hivert  wrote:
> On Thu, Jan 10, 2013 at 10:25:16AM +, David Loeffler wrote:
>> -1 -- sorry. If we must have a shorthand for log to base 2, isn't "lb" the
>> canonical one?
>
> Why not log2 since Python allows digits inside identifiers as opposite to 
> LaTeX ?
>
> Cheers,
>
> Florent
>
> --
> 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 unsubscribe from this group, send email to 
> sage-devel+unsubscr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel?hl=en.
>
>

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] hg.sagemath.org server error

[Timo Kluck]

Hi,

Also, it seems that

hg.sagemath.org/extcode-main
hg.sagemath.org/scripts-main

are actually the same repository. That can't be right.

Timo

Op donderdag 6 december 2012 09:19:31 UTC+1 schreef Keshav Kini het 
volgende:
>
> On Wed, Dec 5, 2012 at 11:19 PM, Minh Nguyen 
> > 
> wrote: 
> > Hi Keshav, 
> > 
> > On Sat, Dec 1, 2012 at 8:57 AM, Keshav Kini 
> > > 
> wrote: 
> >> The sage-root repo seemingly isn't being served correctly, as the 
> >> following URL returns an HTTP 500: 
> >> 
> >> http://hg.sagemath.org/sage-root/ 
> > 
> > To be honest with you, I have spent the last hour trying to understand 
> > this.  But I still don't know how to fix it.  If you can sudo as 
> > sagemath, then you should be able to cd to 
> > 
> > /home/sagemath/wiki/sage-hg/hg 
> > 
> > and have a poke around. 
>
> Looks like the problem is that the version of Mercurial on boxen is 
> too old - the repository in ~sagemath/sage_install/sage-hg/sage-root 
> is not readable by Mercurial versions older than 1.7, presumably 
> because it was created with a version of Mercurial newer than or equal 
> to 1.7. (We ran into this on trac #10594.) 
>
> I can fix this temporarily but it would be a better idea to fix 
> whatever script is putting these repositories here. Who's doing this? 
> Is it part of Jeroen's release management scripts? In any case, while 
> the other repos were updated a couple weeks ago, the sage-root one 
> hasn't been updated since February. Maybe the same problem is 
> occurring in the transfer script as well. 
>
> -Keshav 
>

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] About log and ln. Free fight.

[Florent Hivert]

On Thu, Jan 10, 2013 at 10:25:16AM +, David Loeffler wrote:
> -1 -- sorry. If we must have a shorthand for log to base 2, isn't "lb" the
> canonical one?

Why not log2 since Python allows digits inside identifiers as opposite to LaTeX 
?

Cheers,

Florent

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: ccache defaults?

[Jeroen Demeyer]

On 2013-01-10 12:39, Simon King wrote:
> On 2013-01-10, Jeroen Demeyer  wrote:
>> On 2013-01-10 12:25, Simon King wrote:
>>> I tried
>>>   > sudo ln -s ccache /usr/local/bin/gcc
>>>   > ls -l /usr/local/bin/gcc
>>>   lrwxrwxrwx 1 root root 6 10. Jan 10:29 /usr/local/bin/gcc -> ccache
>> What is the output of:
>> ls -l /usr/local/bin/ccache
> 
> There is no /usr/local/bin/ccache. I only have
>   > which ccache
>   /usr/bin/ccache
> 
> Does that mean, I should have done
>   > sudo ln -s /usr/bin/ccache /usr/local/bin/gcc
> rather than
>   > sudo ln -s ccache /usr/local/bin/gcc
Yes.  A symlink is relative to the directory the original file is in.
So, the symlink /usr/local/bin/gcc -> ccache would refer to the
non-existing file /usr/local/bin/ccache.  This effectively means that
the file /usr/local/bin/gcc doesn't exist.

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: ccache defaults?

[Simon King]

Hi,

On 2013-01-10, Simon King  wrote:
> I tried
>  > sudo ln -s ccache /usr/local/bin/gcc

It should have been
   > sudo ln -s /usr/bin/ccache /usr/local/bin/gcc
etc. Doing so solved the problem. Now, after doing some compilations,
the cache is non-empty.

Best regards,
Simon

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: ccache defaults?

[Simon King]

On 2013-01-10, Jeroen Demeyer  wrote:
> On 2013-01-10 12:25, Simon King wrote:
>> I tried
>>   > sudo ln -s ccache /usr/local/bin/gcc
>>   > ls -l /usr/local/bin/gcc
>>   lrwxrwxrwx 1 root root 6 10. Jan 10:29 /usr/local/bin/gcc -> ccache
> What is the output of:
> ls -l /usr/local/bin/ccache

There is no /usr/local/bin/ccache. I only have
  > which ccache
  /usr/bin/ccache

Does that mean, I should have done
  > sudo ln -s /usr/bin/ccache /usr/local/bin/gcc
rather than
  > sudo ln -s ccache /usr/local/bin/gcc
?

Anyway, it seem that this solves the problem, because I now get
  > ls -l `which gcc`
  lrwxrwxrwx 1 root root 15 10. Jan 12:38 /usr/local/bin/gcc -> /usr/bin/ccache

Best regards,
Simon

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Problem building 5.5 on SUSE Linux Enterprise Desktop 11 (x86_64)

[John Cremona]

That worked, I do indeed see

Installing GCC because you have gcc version 4.3, which is quite old.


I will let the build run.  The one I did yesterday (using
SAGE_INSTALL_GCC=yes) did work, and -- thanks to your reminder!  I did
unset that variable before this run.


I'll give the ticket a positive review when the build is finished!

John

On 10 January 2013 11:12, Jeroen Demeyer  wrote:
> On 2013-01-09 13:08, John Cremona wrote:
>> 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 Atlas.  The gcc version is
>> gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux)
>
> John, could you try the following: download and extract sage-5.5 (or a
> later sage-5.6.beta if you wish) on that machine, apply the patch from
> #13937 to the Sage root and then compile Sage as usual, without any SAGE
> environment variables set.
>
> At the very beginning of install.log, you should see a message about
> "installing GCC because you have gcc version...", please confirm that
> this is indeed the case.
>
>
> Thanks,
> Jeroen.
>
> --
> 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 unsubscribe from this group, send email to 
> sage-devel+unsubscr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel?hl=en.
>
>

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: ccache defaults?

[Jeroen Demeyer]

On 2013-01-10 12:32, Volker Braun wrote:
> Bash caches path lookups.
True, but "which" doesn't.

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: ccache defaults?

[Simon King]

On 2013-01-10, Volker Braun  wrote:
> --=_Part_274_11050162.1357817552491
> Content-Type: text/plain; charset=ISO-8859-1
>
> Bash caches path lookups. Try "hash -r" to invalidate the cache.

This didn't work:
  > hash -r
  > which gcc
  /usr/bin/gcc
  > ls -l /usr/local/bin/gcc
  lrwxrwxrwx 1 root root 6 10. Jan 10:29 /usr/local/bin/gcc -> ccache

Best regards,
Simon

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: ccache defaults?

[Jeroen Demeyer]

On 2013-01-10 12:25, Simon King wrote:
> I tried
>   > sudo ln -s ccache /usr/local/bin/gcc
>   > ls -l /usr/local/bin/gcc
>   lrwxrwxrwx 1 root root 6 10. Jan 10:29 /usr/local/bin/gcc -> ccache
What is the output of:
ls -l /usr/local/bin/ccache

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: ccache defaults?

[Volker Braun]

Bash caches path lookups. Try "hash -r" to invalidate the cache.



On Thursday, January 10, 2013 11:25:23 AM UTC, Simon King wrote:
>
> Hi Volker, 
>
> On 2013-01-09, Volker Braun > wrote: 
> > 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 
>
> I tried 
>   > sudo ln -s ccache /usr/local/bin/gcc 
>   > ls -l /usr/local/bin/gcc 
>   lrwxrwxrwx 1 root root 6 10. Jan 10:29 /usr/local/bin/gcc -> ccache 
>
> but I still get 
>   > which gcc 
>   /usr/bin/gcc 
>   > ls -al `which gcc` 
>   lrwxrwxrwx 1 root root 7  6. Dez 2011  /usr/bin/gcc -> gcc-4.6 
>
> even though /usr/local/bin comes before /usr/bin in PATH. 
>   >  echo $PATH 
>   /home/simon/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/... 
>
> What did I do wrong? 
>
> Best regards, 
> Simon 
>
>

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: ccache defaults?

[Simon King]

Hi Volker,

On 2013-01-09, Volker Braun  wrote:
> 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

I tried
  > sudo ln -s ccache /usr/local/bin/gcc
  > ls -l /usr/local/bin/gcc
  lrwxrwxrwx 1 root root 6 10. Jan 10:29 /usr/local/bin/gcc -> ccache

but I still get
  > which gcc
  /usr/bin/gcc
  > ls -al `which gcc`
  lrwxrwxrwx 1 root root 7  6. Dez 2011  /usr/bin/gcc -> gcc-4.6

even though /usr/local/bin comes before /usr/bin in PATH.
  >  echo $PATH
  /home/simon/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/...

What did I do wrong?

Best regards,
Simon

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Problem building 5.5 on SUSE Linux Enterprise Desktop 11 (x86_64)

[Jeroen Demeyer]

On 2013-01-09 13:08, John Cremona wrote:
> 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 Atlas.  The gcc version is
> gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux)

John, could you try the following: download and extract sage-5.5 (or a
later sage-5.6.beta if you wish) on that machine, apply the patch from
#13937 to the Sage root and then compile Sage as usual, without any SAGE
environment variables set.

At the very beginning of install.log, you should see a message about
"installing GCC because you have gcc version...", please confirm that
this is indeed the case.


Thanks,
Jeroen.

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Removing startup.py test

[Jeroen Demeyer]

Please review the following ticket which removes said test:
http://trac.sagemath.org/sage_trac/ticket/13927

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] About log and ln. Free fight.

[Jeroen Demeyer]

On 2013-01-10 11:25, David Loeffler wrote:
> -1 -- sorry. If we must have a shorthand for log to base 2, isn't "lb"
> the canonical one?
I've never seen lb(), I have seen lg().

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] About log and ln. Free fight.

[David Loeffler]

-1 -- sorry. If we must have a shorthand for log to base 2, isn't "lb" the
canonical one?

Regards, David


On 10 January 2013 09:45, Nathann Cohen  wrote:

> Hello everybody !
>
> I understand very well that asking questions like that can easily get me
> killed by a crowd of angry mathematicians, but I just wondered
> Given that ln(e)=1 is not ambiguous at all, what would you think of log(2)
> = 1 ? :-P
>
> We would have ln(x) = log(x,e) and log(x) = log(x,2) ...
>
>  and now can I run ? :-P
>
> 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@googlegroups.com.
> To unsubscribe from this group, send email to
> sage-devel+unsubscr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel?hl=en.
>
>
>

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: ccache defaults?

[Volker Braun]

On Thursday, January 10, 2013 12:27:24 AM UTC, Nils Bruin wrote:

> Not *all* disk space is cheap, though.


If its not then the system admin will have a quota in place. And you 
shouldn't have installed the (optional) ccache spkg to start with. I don't 
think anybody is proposing to make ccache a standard spkg, for starters it 
does not help for the one-time Sage build. Just don't use ccache if it 
doesn't fit in your or your organization's infrastructure.


-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Testing new MPIR and zn_poly on Mac OS X.

[Jean-Pierre Flori]

Dear all,

Could someone try to build the new MPIR from 
http://trac.sagemath.org/sage_trac/ticket/13137 and build zn_poly on top of 
it (especially the make check target).
(You could reinstall zn_poly spkg using -f and -s flags to keep the build 
dir and run a few time "./test nuss_mul" in the test dir.)
We had reports of the nuss_mul test failing on Mac OS X 10.7 using the 
Sage's GCC (4.6.3) and on a 32 bits Windows XP Cygwin using Cygwin GCC 
4.5.3.
Which was quite unexepected and could be conf errors, GCC bugs or worse 
bugs in MPIR new FFT.

Best,
JP

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] About log and ln. Free fight.

[Nathann Cohen]

Hello everybody !

I understand very well that asking questions like that can easily get me
killed by a crowd of angry mathematicians, but I just wondered
Given that ln(e)=1 is not ambiguous at all, what would you think of log(2)
= 1 ? :-P

We would have ln(x) = log(x,e) and log(x) = log(x,2) ...

 and now can I run ? :-P

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@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Trac milestones

[Jeroen Demeyer]

Some general advise concerning the Trac milestones:

*** sage-X.Y ***

(X.Y denotes a version number) This is for ordinary tickets. Normally,
users should not change the version number, it is up to the release
manager to decide in which release a particular ticket will be merged.
For example, now that the sage-5.6 release is coming to an end, I will
postpone some tickets to sage-5.7.


*** sage-duplicate/invalid/wontfix ***

When working on a Trac ticket, you should set the milestone to
"sage-duplicate/invalid/wontfix" *if and only if* the ticket can be
closed without merging anything (no patch, no spkg). Such a ticket
cannot have an author, since there is nothing to be the author of.

A ticket which is essentially a duplicate but adds a doctest should not
be sage-duplicate/invalid/wontfix.

A ticket which at some point had a patch but later it was decided not to
merge that patch (for whatever reason), should have the milestone set to
sage-duplicate/invalid/wontfix.


*** sage-pending ***

This is for tickets which cannot be merged now, mainly because they
depend on another ticket. Or it could be sage-pending because there is
some disagreement on whether or not the patch should be merged.

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: ccache defaults?

[Jean-Pierre Flori]

On Thursday, January 10, 2013 9:33:24 AM UTC+1, Jeroen Demeyer wrote:
>
> On 2013-01-09 22:39, Robert Bradshaw wrote: 
> > 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? 
> Most likely not, I think. But even if the cache is only 1GB, it can 
> never make things *worse* than without ccache. And 1GB is surely enough 
> for the Sage library such that branching would still be fast. 
>
> This might an argument in favour of (3): if ccache already exists, 
> assume the user knows best (he might have configured a larger cache). If 
> ccache doesn't exist on the system, then it doesn't matter that much 
> where we put the cache files, so we might as well configure them 
> specifically for Sage with a known cache size of 4GB. 
>
I would be in favour of such a solution, even though depending on the fact 
that ccache is installed or not system-wide adds a little bit of 
complexity. 

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Weird issue with matrix mutability

[David Loeffler]

The following curious bug came up during work on ticket #12233. For some
reason, if one creates a 2x2 integer matrix directly using the constructor
then it is possible to tell it to be immutable; but if one creates one via
arithmetic operations then calling "set_immutable" on it fails. Here's an
example:

 sage: from sage.matrix.matrix_integer_2x2 import Matrix_integer_2x2 as
 mi2x2
 sage: M2Z = MatrixSpace(ZZ,2)
 sage: mi2x2(M2Z, [1,0,0,1])
 sage: x=mi2x2(M2Z, [1,0,0,1], false, false)
 sage: y=mi2x2(M2Z, [1,0,0,1], false, false)
 sage: type(x)
 
 sage: z = x*y
 sage: type(z)
 
 sage: x.set_immutable()# ok
 sage: z.set_immutable()# error
[...]
AttributeError: 'NoneType' object has no attribute 'set_immutable'

(Many thanks to Timo Kluck for clarifying the problem and finding this
example.) Does anyone have any idea what's going on here, and if so how to
fix it?

Regards, David

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: ccache defaults?

[Jeroen Demeyer]

On 2013-01-09 22:39, Robert Bradshaw wrote:
> 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?
Most likely not, I think. But even if the cache is only 1GB, it can
never make things *worse* than without ccache. And 1GB is surely enough
for the Sage library such that branching would still be fast.

This might an argument in favour of (3): if ccache already exists,
assume the user knows best (he might have configured a larger cache). If
ccache doesn't exist on the system, then it doesn't matter that much
where we put the cache files, so we might as well configure them
specifically for Sage with a known cache size of 4GB.

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] Re: ccache defaults?

[Jeroen Demeyer]

On 2013-01-10 02:24, 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.
To prove you wrong, these are my ccache statistics from sage.math, which
is used essentially only to build (pieces of) Sage:

jdemeyer@sage:~$ ccache -s
cache directory /home/jdemeyer/.ccache
cache hit (direct)   5889666
cache hit (preprocessed)  980843
cache miss547099
called for link   668036
called for preprocessing  367512
multiple source files   4246
compiler produced stdout1529
compile failed 89015
ccache internal error  1
preprocessor error 54472
cache file missing 1
bad compiler arguments 62960
unsupported source language   294972
autoconf compile/link 748338
unsupported compiler option   167889
no input file 309608
files in cache280195
cache size   3.2 Gbytes
max cache size   4.0 Gbytes

-- 
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 unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.