date:20150221

Hi

In my case "0 + MyElement" does find a common parent,
namely the modular forms _ring_.

So basically in my case "0 + some_element" is the same
as "some_element.as_ring_element()", unless the weight of
some_element (resp. its parent) is 0 with multiplier 1
in which case ZZ coerces into the space.

In any case, it's ok. I can work around these issues.

Best
Jonas

On 21.02.2015 23:44, Eric Gourgoulhon wrote:

Le samedi 21 février 2015 23:09:24 UTC+1, Jonas Jermann a écrit :

Hi

It's a good idea but it won't work (in fact the _element_constructor_
does accept zero correctly in my case). The coercion framework _first_
tries to find a common parent and _then_ the rest happens.

At least in the cases I've tried (free modules as implemented in
#15916), if no common parent is found, there is then a conversion of 0
via _element_constructor_, followed by the addition via the _add_
(single underscore) of the module elements.
Do I understand correctly that 0 + whatever first calls
sage.structure.element.RingElement.__add__, which starts by
   if have_same_parent(left, right):
(line 1570 of sage/structure/element.pyx);  if this fails, it performs
   return coercion_model.bin_op(left, right, add)
(line 1579)
and the latter shall invoke your parent._element_constructor_ to convert
0 to your zero element. I am not completely sure about this... (this is
my understanding why it works in my case).

Eric.

Best
  Jonas

On 21.02.2015 22:59, Eric Gourgoulhon wrote:
 > Hi,
 >
 > Le samedi 21 février 2015 21:59:05 UTC+1, Jonas Jermann a écrit :
 >
 >
 > The parent is a vector space / module not a ring. Every
vector space
 > contains zero, so in my opinion from a conceptual point of view
 > adding zero should not change the parent space.
 >
 > However since it views 0 as an integer and not as (an
element) the zero
 > subspace (unless we forcefully map it there) it seems hard to
change
 > this behavior. :-(
 >
 >
 > It seems that a possible way to have 0 + MyElement work even if
ZZ does
 > not coerce to MyElement.parent() is to have
 > MyElement.parent()._element_constructor_ accept 0 (i.e.
Integer(0)) as
 > an argument and return the zero element of your vector space /
module
 > for such an argument.  Am I correct?
 >
 > Eric.
 >

--
You received this message because you are subscribed to the Google
Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to sage-devel+unsubscr...@googlegroups.com
.
To post to this group, send email to sage-devel@googlegroups.com
.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Addition of zero in the coercion model

Hi Eric,

On 2015-02-21, Eric Gourgoulhon  wrote:
> It seems that a possible way to have 0 + MyElement work even if ZZ does=
>=20
> not coerce to MyElement.parent() is to have=20
> MyElement.parent()._element_constructor_ accept 0 (i.e. Integer(0)) as an=
>=20
> argument and return the zero element of your vector space / module for such=
>=20
> an argument.  Am I correct?=20

That's conversion. It would *not* enable x+0.

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Addition of zero in the coercion model

2015-02-21 Thread Eric Gourgoulhon

Le samedi 21 février 2015 23:09:24 UTC+1, Jonas Jermann a écrit :
>
> Hi 
>
> It's a good idea but it won't work (in fact the _element_constructor_ 
> does accept zero correctly in my case). The coercion framework _first_ 
> tries to find a common parent and _then_ the rest happens. 
>

At least in the cases I've tried (free modules as implemented in #15916), 
if no common parent is found, there is then a conversion of 0 via 
_element_constructor_, followed by the addition via the _add_ (single 
underscore) of the module elements.
Do I understand correctly that 0 + whatever first calls 
sage.structure.element.RingElement.__add__, which starts by
  if have_same_parent(left, right):
(line 1570 of sage/structure/element.pyx);  if this fails, it performs
  return coercion_model.bin_op(left, right, add)
(line 1579)
and the latter shall invoke your parent._element_constructor_ to convert 0 
to your zero element. I am not completely sure about this... (this is my 
understanding why it works in my case). 

Eric.

> Best 
>  Jonas 
>
> On 21.02.2015 22:59, Eric Gourgoulhon wrote: 
> > Hi, 
> > 
> > Le samedi 21 février 2015 21:59:05 UTC+1, Jonas Jermann a écrit : 
> > 
> > 
> > The parent is a vector space / module not a ring. Every vector space 
> > contains zero, so in my opinion from a conceptual point of view 
> > adding zero should not change the parent space. 
> > 
> > However since it views 0 as an integer and not as (an element) the 
> zero 
> > subspace (unless we forcefully map it there) it seems hard to change 
> > this behavior. :-( 
> > 
> > 
> > It seems that a possible way to have 0 + MyElement work even if ZZ does 
> > not coerce to MyElement.parent() is to have 
> > MyElement.parent()._element_constructor_ accept 0 (i.e. Integer(0)) as 
> > an argument and return the zero element of your vector space / module 
> > for such an argument.  Am I correct? 
> > 
> > Eric. 
> > 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: how to unsubscribe from Trac ticket updates

http://trac.edgewall.org/ticket/9971


On Saturday, February 21, 2015 at 10:42:31 PM UTC+1, kcrisman wrote:
>
> Hi, I have been getting email updates for a ticket that I commented 
>>> on a long time ago and I was wondering if I can unsubscribe from the 
>>> updates.
>>
>>
>> I know at least one way: review the ticket! The author is usually 
>> responsive
>> and quick with fixes.
>>  
>>
> :)
>
> But more seriously, I don't know if there is an easy way to do this, and 
> it would be useful at times. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Addition of zero in the coercion model


Hi

It's a good idea but it won't work (in fact the _element_constructor_ 
does accept zero correctly in my case). The coercion framework _first_

tries to find a common parent and _then_ the rest happens.

Best
Jonas

On 21.02.2015 22:59, Eric Gourgoulhon wrote:

Hi,

Le samedi 21 février 2015 21:59:05 UTC+1, Jonas Jermann a écrit :


The parent is a vector space / module not a ring. Every vector space
contains zero, so in my opinion from a conceptual point of view
adding zero should not change the parent space.

However since it views 0 as an integer and not as (an element) the zero
subspace (unless we forcefully map it there) it seems hard to change
this behavior. :-(


It seems that a possible way to have 0 + MyElement work even if ZZ does
not coerce to MyElement.parent() is to have
MyElement.parent()._element_constructor_ accept 0 (i.e. Integer(0)) as
an argument and return the zero element of your vector space / module
for such an argument.  Am I correct?

Eric.

--
You received this message because you are subscribed to the Google
Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to sage-devel+unsubscr...@googlegroups.com
.
To post to this group, send email to sage-devel@googlegroups.com
.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Addition of zero in the coercion model

2015-02-21 Thread Eric Gourgoulhon

Hi,

Le samedi 21 février 2015 21:59:05 UTC+1, Jonas Jermann a écrit :
>
>
> The parent is a vector space / module not a ring. Every vector space 
> contains zero, so in my opinion from a conceptual point of view 
> adding zero should not change the parent space. 
>
> However since it views 0 as an integer and not as (an element) the zero 
> subspace (unless we forcefully map it there) it seems hard to change 
> this behavior. :-( 
>
>
> It seems that a possible way to have 0 + MyElement work even if ZZ does 
not coerce to MyElement.parent() is to have 
MyElement.parent()._element_constructor_ accept 0 (i.e. Integer(0)) as an 
argument and return the zero element of your vector space / module for such 
an argument.  Am I correct? 

Eric.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: how to unsubscribe from Trac ticket updates

2015-02-21 Thread kcrisman


>
> Hi, I have been getting email updates for a ticket that I commented 
>> on a long time ago and I was wondering if I can unsubscribe from the 
>> updates.
>
>
> I know at least one way: review the ticket! The author is usually 
> responsive
> and quick with fixes.
>  
>
:)

But more seriously, I don't know if there is an easy way to do this, and it 
would be useful at times. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Addition of zero in the coercion model

Hi Nils,

On 2015-02-21, Nils Bruin  wrote:
> I'm not so sure. How does x+3 make unambiguous sense?

If there is a coercion then (by definition of coercion in contrast to
conversion) it is unique.

> We can map ZZ onto 
> any cyclic subgroup.

Yes, but at most one map is a coercion.

> On the other hand,  x*0 should work: A commutative additive group is a left 
> and right ZZ-module, so x*0 and 0*x should match as scalar multiplication. 

Actually, in the case at hand it will probably work, because there is a
module action of ZZ on the parent. So, I should perhaps withdraw my
example, as n*x should work for any element n of ZZ and any element x of
a commutative additive group P, as P is a ZZ-module.

But what I don't need to withdraw is the general statement that coercion should
work on the level of parents, not on the level of elements. I.e., I
withdraw my example, because there is an action (involving the *whole*
parents). However, element-wise rules such as "if the first factor lives in an
additive group and the right factor is the neutral element for the additive 
group
of its parent, then the product shall be the zero element of the left factor"
should be banned.

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: 2x2 integer matrices

2015-02-21 Thread Vincent Delecroix

Hello Frederik,

Finally, with some work the generic integer dense matrix class using
flint (sage.matrix.matrix_integer_dense) is as fast as the 2x2 matrix.
This is #17822.

It is then not so hard to get rid of Matrix_integer_2x2. This is #17824.

Vincent

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Addition of zero in the coercion model


Hi

On 21.02.2015 22:13, Nils Bruin wrote:

On Saturday, February 21, 2015 at 12:57:44 PM UTC-8, Simon King wrote:


I.e., if P is a commutative additive group, then P.coerce_map_from(ZZ)
should return a morphism in the category of commutative additive
groups.
Then, x+0 should work (because the coercion map is a morphism in the
category of additive groups), but x*0 should not work (because it is
not
a morphism of multiplicative groups).


I'm not so sure. How does x+3 make unambiguous sense? We can map ZZ onto
any cyclic subgroup. There is not necessarily a unique maximal one (for
x+0 it obviously doesn't matter which one we choose, though)


x+3 makes no sense. I was trying to argue that x+0 makes sense. But
I guess it works against the way the coercion model is set up. So I will
just have to deal with "+0" and "sum()" issues I guess.

Thanks to both of you and Simon for the clarifications.
So I will consider the issue closed/answered.


Best
Jonas

P.S. in sage.modular.modform_hecketriangle I implemented both, the ring
of modular forms and the vector spaces (homogeneous parts of the graded 
ring). Note in particular that I implemented it in such a way that

multiplication of module elements give again module elements (in a
different space). Check it ouf if you're interested.

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Addition of zero in the coercion model

2015-02-21 Thread Nils Bruin

On Saturday, February 21, 2015 at 12:57:44 PM UTC-8, Simon King wrote:
>
>
> I.e., if P is a commutative additive group, then P.coerce_map_from(ZZ) 
> should return a morphism in the category of commutative additive groups. 
> Then, x+0 should work (because the coercion map is a morphism in the 
> category of additive groups), but x*0 should not work (because it is not 
> a morphism of multiplicative groups). 

I'm not so sure. How does x+3 make unambiguous sense? We can map ZZ onto 
any cyclic subgroup. There is not necessarily a unique maximal one (for x+0 
it obviously doesn't matter which one we choose, though)

On the other hand,  x*0 should work: A commutative additive group is a left 
and right ZZ-module, so x*0 and 0*x should match as scalar multiplication. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Addition of zero in the coercion model

Hi Jonas,

On 2015-02-21, Jonas Jermann  wrote:
> I'm confused. Why does the additive group of ZZ coerce into P?

Oops, you are right. You can map ZZ onto an additive subgroup
of P, but that would be not canonical and hence not a coercion.

Anyway, Sage's coercion model works on the level of parents, not on the
level of elements. Hence, the fact that the element 0 has a canonical
interpretation in P is not relevant. It only matters whether or not ZZ
has a canonical morphism to P.

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Addition of zero in the coercion model


Hi

On 21.02.2015 21:57, Simon King wrote:

On 2015-02-21, Simon King  wrote:

If ZZ does not coerce into the parent of your element, then the parent
is not a (unitary) ring.


PS:
And if it is not a ring, then many things don't work as smoothly as they
should.

For example, if P is a commutative additive group with an element x, then most
people would expect that x+0 should be equal to x. Reason: The ADDITIVE
group of ZZ coerces into P.


I'm confused. Why does the additive group of ZZ coerce into P?


Best
Jonas

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Addition of zero in the coercion model


Hi Simon

On 21.02.2015 21:47, Simon King wrote:

Hi Jonas,

On 2015-02-21, Jonas Jermann  wrote:

ZZ does not coerce into myElement.parent() so I end up in a much
larger space than myElement.parent(). However I would prefer if adding
zero didn't change the parent space.


If ZZ does not coerce into the parent of your element, then the parent
is not a (unitary) ring.


The parent is a vector space / module not a ring. Every vector space 
contains zero, so in my opinion from a conceptual point of view

adding zero should not change the parent space.

However since it views 0 as an integer and not as (an element) the zero 
subspace (unless we forcefully map it there) it seems hard to change

this behavior. :-(


One reason is for instance that
sum(...) no longer works properly because it always prepends "0+".


You can avoid it by explicitly providing the starting element to the sum
function.


Eg: from sage.modular.modform_hecketriangle.all import *
  myElement = ModularForms().E4()
  myElement.parent() != sum([myElement]).parent()

Clearly "0" is a special case (the zero subspace does coerce into any of
the spaces).

How should I fix this?


By providing a starting point for the summation:
   sage: sum([myElement]).parent()
   ModularFormsRing(n=3) over Integer Ring
   sage: myElement.parent()
   ModularForms(n=3, k=4, ep=1) over Integer Ring
   sage: sum([myElement], myElement.parent().zero()).parent()
   ModularForms(n=3, k=4, ep=1) over Integer Ring


Thanks. Yes, I was aware of this, for instance I could also use
python's reduce function or a for loop. I was hoping to fix the issue
in a proper way, namely to get "adding zero" to work. Always having to
work around sum is annoying. What if "sum" is called outside of my
control in some other function? The issue can also be a hidden source 
for bugs.



Best
Jonas

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Addition of zero in the coercion model

On 2015-02-21, Simon King  wrote:
> If ZZ does not coerce into the parent of your element, then the parent
> is not a (unitary) ring.

PS:
And if it is not a ring, then many things don't work as smoothly as they
should.

For example, if P is a commutative additive group with an element x, then most
people would expect that x+0 should be equal to x. Reason: The ADDITIVE
group of ZZ coerces into P. However, Sage wants to coerce the RING ZZ
into P. It would be quite challanging to extend Sage's coercion model so
that the same parent (here: ZZ) can play different roles in coercion.

I.e., if P is a commutative additive group, then P.coerce_map_from(ZZ)
should return a morphism in the category of commutative additive groups.
Then, x+0 should work (because the coercion map is a morphism in the
category of additive groups), but x*0 should not work (because it is not
a morphism of multiplicative groups).

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Addition of zero in the coercion model

Hi Jonas,

On 2015-02-21, Jonas Jermann  wrote:
> ZZ does not coerce into myElement.parent() so I end up in a much
> larger space than myElement.parent(). However I would prefer if adding
> zero didn't change the parent space.

If ZZ does not coerce into the parent of your element, then the parent
is not a (unitary) ring.

> One reason is for instance that
> sum(...) no longer works properly because it always prepends "0+".

You can avoid it by explicitly providing the starting element to the sum
function.

> Eg: from sage.modular.modform_hecketriangle.all import *
>  myElement = ModularForms().E4()
>  myElement.parent() != sum([myElement]).parent()
>
> Clearly "0" is a special case (the zero subspace does coerce into any of 
> the spaces).
>
> How should I fix this?

By providing a starting point for the summation:
  sage: sum([myElement]).parent()
  ModularFormsRing(n=3) over Integer Ring
  sage: myElement.parent()
  ModularForms(n=3, k=4, ep=1) over Integer Ring
  sage: sum([myElement], myElement.parent().zero()).parent()
  ModularForms(n=3, k=4, ep=1) over Integer Ring

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Addition of zero in the coercion model


Hi

When I do "0 + myElement" the coercion framework seems to map this
to a common parent of 0 and myElement (by checking the parent of 0 and
myElement).

ZZ does not coerce into myElement.parent() so I end up in a much
larger space than myElement.parent(). However I would prefer if adding
zero didn't change the parent space. One reason is for instance that
sum(...) no longer works properly because it always prepends "0+".

Eg: from sage.modular.modform_hecketriangle.all import *
myElement = ModularForms().E4()
myElement.parent() != sum([myElement]).parent()

Clearly "0" is a special case (the zero subspace does coerce into any of 
the spaces).


How should I fix this?


Best
Jonas

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] sage-6.5.1?

2015-02-21 Thread Jan Groenewald

I would appreciate any feedback on how well or not well the 14.04 trusty
binary works on 14.10 utopic.

Regards,
Jan


On 21 February 2015 at 14:54, Jan Groenewald  wrote:

> Hi
>
> I have now deleted the quantal/raring/saucy (they are all End of Life
> already) on the PPA (to make space, the usual size of a PPA is 2G, mine has
> been increased and status is now 4.3 GiB (27.05%) of 16.0 GiB) after the
> changes below. I'm suprised those were not deleted automatically.
>
> I requested a copy in the PPA of the existing trusty 14.04 binary to
> utopic 14.10, so that (64bit only) will be available on utopic, and
> hopefully work (the quantal/raring/saucy were copied from precise and never
> gave problems). It should be available in a few hours. Such binary copies
> may also possibly NOT count towards my PPA size allocation.
>
> The PPA now has 64bit for precise, trusty, utopic.
>
> 32bit is a work in progress (I mean to add buildbot slaves for LTS 32bit
> and 64 bit in the next month or three, and to repackage them for the PPA)
>
> While we (www.aims.ac.za) will mainly want to support LTS, and can copy
> binaries to other releases, if there are actual builds for in-between
> non-LTS releases available for download on sagemath.org, I might have the
> time or give someone access to upload them to the PPA.
>
> Regards,
> Jan
>
> On 20 February 2015 at 18:09, Thierry 
> wrote:
>
>> Hi,
>>
>> On Fri, Feb 20, 2015 at 07:47:59AM -0800, Jean-Pierre Flori wrote:
>> >
>> > On Friday, February 20, 2015 at 4:29:38 PM UTC+1, John Cremona wrote:
>> > >
>> > > On 20 February 2015 at 15:10, Vincent Delecroix
>> > > <20100.d...@gmail.com > wrote:
>> > > > Hello,
>> > > >
>> > > > We do have two very serious critical bug with the new version 6.5,
>> > > namely
>> > > >  * #17806 (MPIR compilation)
>> > > >  * #17816 (flint polynomial gcd)
>> > > > The first one is waiting for a fix while the second is in positive
>> > > > review. Both bugs are worth for a new stable release. What do you
>> > > > think of having a sage-6.5.1 as soon as #17806 is done?
>> > >
>> > Is #17806 so urgent?
>>
>> Nothing is urgent, but i need to build fat 32 bits binary for building
>> Sage Debian Live USB http://sagedebianlive.metelu.net/ This is currently
>> the only way to spread Sage in places where huge download is impossible.
>>
>> Also, when we went in Senegal with Vincent in October, we noticed that
>> most poeple in universities are running Ubuntu, but with various versions
>> and both architectures. Unfortunately, the PPA offers only a few of them
>> and there were quite a few people unable to install Sage without having to
>> compile it themselves (which means : not having Sage until you meet some
>> developper).
>>
>> Hence, i worked recently on building all possible (32,64 x
>> precise,trusty,utopic) binaries for Ubuntu in a row (and Debian while i am
>> at it), so that AIMS could offer PPA's for everyone.
>>
>> Ciao,
>> Thierry
>>
>>
>>
>>
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "sage-devel" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to sage-devel+unsubscr...@googlegroups.com.
>> > To post to this group, send email to sage-devel@googlegroups.com.
>> > Visit this group at http://groups.google.com/group/sage-devel.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to sage-devel+unsubscr...@googlegroups.com.
>> To post to this group, send email to sage-devel@googlegroups.com.
>> Visit this group at http://groups.google.com/group/sage-devel.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
>   .~.
>   /V\ Jan Groenewald
>  /( )\www.aims.ac.za
>  ^^-^^
>



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

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

2015-02-21 Thread William Stein

On Feb 21, 2015 9:32 AM, "Volker Braun"  wrote:
>
> Followups to sage-flame please...
>

I strongly agree.

>
> On Saturday, February 21, 2015 at 6:14:33 PM UTC+1, Felix Salfelder wrote:
>>
>> Hi Volker.
>>
>> actually i anticipate that you know better. anyway i reply. again. just
>> for the record.
>>
>> On Sat, Feb 21, 2015 at 06:55:26AM -0800, Volker Braun wrote:
>> > That is not true. What is true is that none of the core developers
wants to
>> > make their life even more difficult so that the debian packages have
less
>> > to do.
>>
>> this is *not* *about* *debian*. only about 1/3 of linux installations
>> are debian based. a lot of distributions are not even based on any
>> other. sage does not only run on linux. go figure.
>>
>> > At the bottom of it, it is a social rather than a technical problem.
You
>> > need to convince people that you have a better way, and be able to
listen
>> > to upstream projects.
>>
>> at no time did i have a better way to do what you do. i wanted to try
>> something else. somehing more straightforward. i listened to upstream
>> and i have dropped the idea (see my last mail). still i do not know
>> which other way might have done the trick. for the very least i did not
>> try to move to portage. conversation could have been more productive.
>>
>> > Trying to rip out cythonize() because automake doesn't do wildcards?
>>
>> i fell back to automake, because cythonize does not support dependency
>> tracking. does it today? don't know. needless to say that i have asked
>> for alternatives. out-of-tree builds solved a different set of
>> problems. afaik, the recompile-everything-everytime issue stroke back a
>> few months ago...
>>
>> while i tried to address some of these issues (yes, the technical
>> side), i learned that
>> - modularisation is evil
>> - libgap is necessary and must pretend to be gap
>> - tabs are bad and so are makefiles
>> - autotools releases must be pulled from git
>> - capitalization is important
>> and maybe other surprising or interesting things that i forgot about
>> (still, thanks for the useful input!).
>>
>> and again: in which way does autotools not support wildcards? i guess
>> you are pointing to the fact that i did not want to rely on them. just
>> add it to the list above.
>>
>> > And you are surprised that this did not make it upstream?
>>
>> no. should i? this was never complete nor will it be of any use for the
>> better-bootstrap-the-universe folks. it is not your obligation to
>> support or even think any of this.
>>
>> sage is a great/interesting piece of software. sure, attempts to package
>> (with or without help from upstream) will not die down. it is a matter
>> of how to deal with external ideas, needs and resources. hopefully, my
>> project will serve as a warning to others and eventually justify a fork
>> that avoids sage-the-distribution completely. just sagelib alone is
>> considerably simpler to deal with. for packaging you don't need
>> dependency tracking *hint hint*.
>>
>> all the best
>> felix
>
> --
> You received this message because you are subscribed to the Google Groups
"sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

Followups to sage-flame please...


On Saturday, February 21, 2015 at 6:14:33 PM UTC+1, Felix Salfelder wrote:
>
> Hi Volker. 
>
> actually i anticipate that you know better. anyway i reply. again. just 
> for the record. 
>
> On Sat, Feb 21, 2015 at 06:55:26AM -0800, Volker Braun wrote: 
> > That is not true. What is true is that none of the core developers wants 
> to 
> > make their life even more difficult so that the debian packages have 
> less 
> > to do. 
>
> this is *not* *about* *debian*. only about 1/3 of linux installations 
> are debian based. a lot of distributions are not even based on any 
> other. sage does not only run on linux. go figure. 
>
> > At the bottom of it, it is a social rather than a technical problem. You 
> > need to convince people that you have a better way, and be able to 
> listen 
> > to upstream projects. 
>
> at no time did i have a better way to do what you do. i wanted to try 
> something else. somehing more straightforward. i listened to upstream 
> and i have dropped the idea (see my last mail). still i do not know 
> which other way might have done the trick. for the very least i did not 
> try to move to portage. conversation could have been more productive. 
>
> > Trying to rip out cythonize() because automake doesn't do wildcards? 
>
> i fell back to automake, because cythonize does not support dependency 
> tracking. does it today? don't know. needless to say that i have asked 
> for alternatives. out-of-tree builds solved a different set of 
> problems. afaik, the recompile-everything-everytime issue stroke back a 
> few months ago... 
>
> while i tried to address some of these issues (yes, the technical 
> side), i learned that 
> - modularisation is evil 
> - libgap is necessary and must pretend to be gap 
> - tabs are bad and so are makefiles 
> - autotools releases must be pulled from git 
> - capitalization is important 
> and maybe other surprising or interesting things that i forgot about 
> (still, thanks for the useful input!). 
>
> and again: in which way does autotools not support wildcards? i guess 
> you are pointing to the fact that i did not want to rely on them. just 
> add it to the list above. 
>
> > And you are surprised that this did not make it upstream? 
>
> no. should i? this was never complete nor will it be of any use for the 
> better-bootstrap-the-universe folks. it is not your obligation to 
> support or even think any of this. 
>
> sage is a great/interesting piece of software. sure, attempts to package 
> (with or without help from upstream) will not die down. it is a matter 
> of how to deal with external ideas, needs and resources. hopefully, my 
> project will serve as a warning to others and eventually justify a fork 
> that avoids sage-the-distribution completely. just sagelib alone is 
> considerably simpler to deal with. for packaging you don't need 
> dependency tracking *hint hint*. 
>
> all the best 
> felix 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

2015-02-21 Thread Felix Salfelder

Hi Volker.

actually i anticipate that you know better. anyway i reply. again. just
for the record.

On Sat, Feb 21, 2015 at 06:55:26AM -0800, Volker Braun wrote:
> That is not true. What is true is that none of the core developers wants to 
> make their life even more difficult so that the debian packages have less 
> to do.

this is *not* *about* *debian*. only about 1/3 of linux installations
are debian based. a lot of distributions are not even based on any
other. sage does not only run on linux. go figure.

> At the bottom of it, it is a social rather than a technical problem. You 
> need to convince people that you have a better way, and be able to listen 
> to upstream projects.

at no time did i have a better way to do what you do. i wanted to try
something else. somehing more straightforward. i listened to upstream
and i have dropped the idea (see my last mail). still i do not know
which other way might have done the trick. for the very least i did not
try to move to portage. conversation could have been more productive.

> Trying to rip out cythonize() because automake doesn't do wildcards?

i fell back to automake, because cythonize does not support dependency
tracking. does it today? don't know. needless to say that i have asked
for alternatives. out-of-tree builds solved a different set of
problems. afaik, the recompile-everything-everytime issue stroke back a
few months ago...

while i tried to address some of these issues (yes, the technical
side), i learned that
- modularisation is evil
- libgap is necessary and must pretend to be gap
- tabs are bad and so are makefiles
- autotools releases must be pulled from git
- capitalization is important
and maybe other surprising or interesting things that i forgot about
(still, thanks for the useful input!).

and again: in which way does autotools not support wildcards? i guess
you are pointing to the fact that i did not want to rely on them. just
add it to the list above.

> And you are surprised that this did not make it upstream?

no. should i? this was never complete nor will it be of any use for the
better-bootstrap-the-universe folks. it is not your obligation to
support or even think any of this.

sage is a great/interesting piece of software. sure, attempts to package
(with or without help from upstream) will not die down. it is a matter
of how to deal with external ideas, needs and resources. hopefully, my
project will serve as a warning to others and eventually justify a fork
that avoids sage-the-distribution completely. just sagelib alone is
considerably simpler to deal with. for packaging you don't need
dependency tracking *hint hint*.

all the best
felix

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [ARM] sage 6.5

The atlas build script just aborts with SAGE_ATLAS_ARCH=base, nothing else 
to see here.

Pointing to a specific location for the atlas library isn't going to be 
much use in a binary that we distribute.



On Saturday, February 21, 2015 at 4:54:12 PM UTC+1, Snark wrote:
>
> Le 21/02/2015 14:56, Volker Braun a écrit : 
> > We have an ARM buildbot but it doesn't work: atlas install fails when 
> > SAGE_FAT_BINARY=yes is set. If you have an idea about suitable defaults 
> > then we could make it automatic *hint* 
> > 
>
> Is there a trac ticket or some such on the matter, with some kind of log 
> I could have a look at ? 
>
> I generally build my bdist with SAGE_ATLAS_LIB set to /usr/lib -- or 
> else just atlas takes something a full day (I can't remember exactly). 
>
> Snark on #sagemath 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [ARM] sage 6.5

2015-02-21 Thread Julien Puydt


Le 21/02/2015 14:56, Volker Braun a écrit :

We have an ARM buildbot but it doesn't work: atlas install fails when
SAGE_FAT_BINARY=yes is set. If you have an idea about suitable defaults
then we could make it automatic *hint*



Is there a trac ticket or some such on the matter, with some kind of log 
I could have a look at ?


I generally build my bdist with SAGE_ATLAS_LIB set to /usr/lib -- or 
else just atlas takes something a full day (I can't remember exactly).


Snark on #sagemath

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

2015-02-21 Thread Johan S. R. Nielsen

On Saturday, February 21, 2015 at 3:42:28 AM UTC+1, Michael Orlitzky wrote:
>
> On 02/20/2015 11:02 AM, kcrisman wrote: 
> > 
> >> 
> >> I no longer use sage for my day-to-day work, but when I was and I had 
> to 
> >> e.g. give a presentation, it was infuriating to find sage broken AGAIN 
> >> 
> > 
> > ??? I assume this is because you updated some dependency and Sage didn't 
> > work quite properly somewhere in its bowels with that?  I've never once 
> had 
> > that happen with Sage on Mac, since it is a distribution by necessity 
> > there. To me that sounds like an argument for installing 
> > sage-the-distribution, because I assume this could happen with any 
> software 
> > that has a dependency, before upstream had repackaged based on that 
> updated 
> > dependency.  I may be misunderstanding something in your argument, 
> though. 
> > 
>
> It happens when I update something that is a sage dependency, but for 
> which there is no spkg. 
>
> All of the C code that we ship depends on glibc, but we don't ship an 
> spkg for glibc. When I update glibc, sage begins to segfault until I 
> rebuild every spkg and the sage library. 
>
> There are two ways to fix that: first, we could bundle literally an 
> entire Linux distribution down to the kernel. Or, we could make sage 
> play nice with package managers and let the package manager reinstall 
> (i.e. rebuild) any parts of sage that are broken by the update. 
>
> The first solution duplicates an enormous amount of effort that Linux 
> distros have already put forth. It makes the sage download half a 
> gigabyte instead of a few megabytes. It creates security problems -- now 
> I have two version of openssl on my machine, and nobody updates the sage 
> copy. It causes the sage build process to take 4 hours instead of 5 
> minutes. It makes installation much harder for users who are used to 
> doing "yum install sage". It ensures that system administrators won't go 
> near it, so sage can't be installed once globally on the department 
> server. 
>
> The second has none of those problems, but we can't depend on "silent 
> forks" of packages. I don't think there are very many packages where we 
> really need to have a full-fledged fork. Pari may be one of them, who 
> knows. But if we need to fork it we should just fork it and rename all 
> of the libs and get it over with. 
>
>  
I find that really surprising! I run Arch linux so more or less all 
packages are upgraded on a weekly to monthly basis. Besides the package 
manager, I keep a
stable installation of Sage that I don't touch so often, maybe for 6-9 
months at a time, so that I always have something on which to do 
computations. I have
never once experienced segfaults as you describe...

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

On Saturday, February 21, 2015 at 3:09:58 PM UTC+1, Felix Salfelder wrote:
>
> as it seems, hardly anybody (and about zero of the core developers) from 
> the sage community wants to make use of system-installed packages 
> (except for maybe gcc, ssl and whatnot).

That is not true. What is true is that none of the core developers wants to 
make their life even more difficult so that the debian packages have less 
to do. 

At the bottom of it, it is a social rather than a technical problem. You 
need to convince people that you have a better way, and be able to listen 
to upstream projects. Trying to rip out cythonize() because automake 
doesn't do wildcards? And you are surprised that this did not make it 
upstream? Are you also surprised that our tanks were not received with open 
arms on the streets of Baghdad? ;-)

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

2015-02-21 Thread Felix Salfelder

On Sat, Feb 21, 2015 at 03:58:29AM -0800, Volker Braun wrote:
> [..] it still doesn't work.

you keep saying that. but does it matter? the configuration worked
pretty good as a proof-of-concept. i am sorry if your expectations were
higher. note that this particular part was just optional within the
project ([1] part 2, last item), no more no less.

as it seems, hardly anybody (and about zero of the core developers) from
the sage community wants to make use of system-installed packages
(except for maybe gcc, ssl and whatnot). yet, i did not expect that much
headwind. after all the mere attempt of a straightforward bypass
implementation has been pretty pointless.

in the meantime, i have dropped the top-level part to concentrate on
making just sage (the library, the software, the essential part) work
for non-(sage-the-distribution or OSX-based) software distributions. the
effort makes no sense for sage-the-distribution, where all paths are to
stay static and hardcoded. forks are evil and all that, but the
build/install now works if the build dependencies are available. it's
lagging behind at 6.3-something, i don't use sage currently, and i have
other things to do.

> Nor is it a particularly good way of exposing a lot of configuration
> options (at least one per package).

the intent was to have exactly one option per package. this (would have)
allowed to install/develop sage-the-distribution with all foreign packages
disabled except pari (hey, this is not even off topic!). may anyone find
a better way.

good luck
felix

[1]
https://www.google-melange.com/gsoc/project/details/google/gsoc2013/felixs/5779342353235968

--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: [ARM] sage 6.5

We have an ARM buildbot but it doesn't work: atlas install fails when 
SAGE_FAT_BINARY=yes is set. If you have an idea about suitable defaults 
then we could make it automatic *hint*

On Saturday, February 21, 2015 at 2:30:10 PM UTC+1, Snark wrote:
>
> Hi, 
>
> is there an ARM build box which will take care of preparing a bdist 
> which I'll just have to unpack, or shall I build such a bdist as usual ? 
>
> Snark on #sagemath 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] [ARM] sage 6.5

2015-02-21 Thread Julien Puydt


Hi,

is there an ARM build box which will take care of preparing a bdist 
which I'll just have to unpack, or shall I build such a bdist as usual ?


Snark on #sagemath

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: formatted latex-output / typeset in ipython notebook

2015-02-21 Thread Daniel Krenn

Am 2015-02-21 um 12:51 schrieb Volker Braun:
> This will work as a side-effect of http://trac.sagemath.org/ticket/17234

Excellent :)

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] sage-6.5.1?

2015-02-21 Thread Jan Groenewald

Hi

I have now deleted the quantal/raring/saucy (they are all End of Life
already) on the PPA (to make space, the usual size of a PPA is 2G, mine has
been increased and status is now 4.3 GiB (27.05%) of 16.0 GiB) after the
changes below. I'm suprised those were not deleted automatically.

I requested a copy in the PPA of the existing trusty 14.04 binary to utopic
14.10, so that (64bit only) will be available on utopic, and hopefully work
(the quantal/raring/saucy were copied from precise and never gave
problems). It should be available in a few hours. Such binary copies may
also possibly NOT count towards my PPA size allocation.

The PPA now has 64bit for precise, trusty, utopic.

32bit is a work in progress (I mean to add buildbot slaves for LTS 32bit
and 64 bit in the next month or three, and to repackage them for the PPA)

While we (www.aims.ac.za) will mainly want to support LTS, and can copy
binaries to other releases, if there are actual builds for in-between
non-LTS releases available for download on sagemath.org, I might have the
time or give someone access to upload them to the PPA.

Regards,
Jan

On 20 February 2015 at 18:09, Thierry 
wrote:

> Hi,
>
> On Fri, Feb 20, 2015 at 07:47:59AM -0800, Jean-Pierre Flori wrote:
> >
> > On Friday, February 20, 2015 at 4:29:38 PM UTC+1, John Cremona wrote:
> > >
> > > On 20 February 2015 at 15:10, Vincent Delecroix
> > > <20100.d...@gmail.com > wrote:
> > > > Hello,
> > > >
> > > > We do have two very serious critical bug with the new version 6.5,
> > > namely
> > > >  * #17806 (MPIR compilation)
> > > >  * #17816 (flint polynomial gcd)
> > > > The first one is waiting for a fix while the second is in positive
> > > > review. Both bugs are worth for a new stable release. What do you
> > > > think of having a sage-6.5.1 as soon as #17806 is done?
> > >
> > Is #17806 so urgent?
>
> Nothing is urgent, but i need to build fat 32 bits binary for building
> Sage Debian Live USB http://sagedebianlive.metelu.net/ This is currently
> the only way to spread Sage in places where huge download is impossible.
>
> Also, when we went in Senegal with Vincent in October, we noticed that
> most poeple in universities are running Ubuntu, but with various versions
> and both architectures. Unfortunately, the PPA offers only a few of them
> and there were quite a few people unable to install Sage without having to
> compile it themselves (which means : not having Sage until you meet some
> developper).
>
> Hence, i worked recently on building all possible (32,64 x
> precise,trusty,utopic) binaries for Ubuntu in a row (and Debian while i am
> at it), so that AIMS could offer PPA's for everyone.
>
> Ciao,
> Thierry
>
>
>
>
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to sage-devel+unsubscr...@googlegroups.com.
> > To post to this group, send email to sage-devel@googlegroups.com.
> > Visit this group at http://groups.google.com/group/sage-devel.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>



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

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

On Saturday, February 21, 2015 at 12:26:26 PM UTC+1, Snark wrote:
>
> Felix Salfelder did a GSOC about using a configure script. 


You keep saying that but it still doesn't work.

Nor is it a particularly good way of exposing a lot of configuration 
options (at least one per package). 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: formatted latex-output / typeset in ipython notebook

This will work as a side-effect of http://trac.sagemath.org/ticket/17234





On Friday, February 20, 2015 at 5:23:46 PM UTC+1, Daniel Krenn wrote:
>
> Dear all, 
>
> what is the status in Sage's ipython notebook about showing formulas 
> (its Latex-representation) inline by, e.g., 
>
>   view(x^42+1) 
>
> ? 
>
> Daniel 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

2015-02-21 Thread Julien Puydt


Le 21/02/2015 11:15, Volker Braun a écrit :

I agree that we should have some user configuration mechanism to customize
how we build packages (including replacing sage packages with distro
dependencies), but going about it by patching Sage or adding $DISTRO
subdirectories everywhere are crap. Something like yaml config files (e.g.
hashdist) is imho the way to go.


Felix Salfelder did a GSOC about using a configure script.

Snark on #sagemath

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code