As mentioned on the ticket, this big-endian incompatibility does not
prevent the inclusion of primecount as an "experimental package" that I
still aim to achieve (the type of the package "experimental", "optional"
or "standard" is simply a flag). In practice "experimental" means "not
officially supported" and "less tested".
And as Dima mentioned, it would be simpler for SageMath to have
primecount supporting big-endian. We certainly do not want that a single
library prevents using SageMath on big-endian architecture.
Now, three questions for Sage developers:
- Who is testing a big-endian architecture?
- Are all optional packages big-endian compatible?
- Is it reasonable to ask for big-endian compatibility for
PS: to discuss these kind of issues related to development, it is better
to use the other google group sage-devel.
On 13/03/2018 23:11, Dima Pasechnik wrote:
On Tuesday, March 13, 2018 at 9:41:50 PM UTC, Kim Walisch wrote:
We all know that the big-endian CPU architecture is slowly dying,
some people even state that "Big-Endian is effectively dead".
So my question is: Does sagemath still support big-endian CPU
architectures like e.g. 32-bit Sparc?
We have recently more or less revived a SPARC Solaris 11 port of Sagemath.
So yes, please, make it both-endian...
I am asking because there is a ticket
to integrate my primecount
library into sagemath and primecount currently only supports
little-endian CPUs. I could support big-endian CPUs but I want to
make sure this is required by sagemath.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.