Le 04/11/2011 02:29, kcrisman a écrit :
On the other hand, it's also clear that without significantly more
help on the Cygwin port, it's not going to be there for a while. I
just messed with it today, and decided to uninstall my Cygwin instead
because of some weird sed problem Leif and I were tr
Le 05/11/2011 14:31, Jeroen Demeyer a écrit :
On 2011-11-04 08:19, Julien Puydt wrote:
but rather a more deliberately fragile one :
- check very-specific-arch1, and set magic options if so ;
...
- check very-specific-archN, and set magic options if so ;
- if we aren't on a known arch, or
Le 05/11/2011 17:42, William Stein a écrit :
What do you base this "probably" on? Having started and watched Sage
"evolve" of over 6 years, if anything it is not evolving in the
direction you suggest.
Fair point. But that can't last.
All the libs and programs on my system weight 9G, with many
Le 05/11/2011 21:24, Justin C. Walker a écrit :
There are so many different versions of each library and system (for Linux, in
particular)
that it's a practical impossibility to produce a package like Sage that will
work on the systems currently supported.
I would like to point out that quite
Le 08/11/2011 07:37, Jonathan Bober a écrit :
On Sun, Nov 6, 2011 at 5:59 AM, Julien Puydt mailto:julien.pu...@laposte.net>> wrote:
Le 05/11/2011 21:24, Justin C. Walker a écrit :
There are so many different versions of each library and system
(for Linux, in part
Le 08/11/2011 09:31, William Stein a écrit :
On Tue, Nov 8, 2011 at 12:09 AM, Julien Puydt wrote:
Sage developers shouldn't care. If you start down that road, you'll soon end
up putting in your own libc, your own libc++, your own editor, your own
C/C++/whatever compiler, etc.
I dis
Le 08/11/2011 17:04, Michael Orlitzky a écrit :
In any case, the "do them both" approach is fine until one is so
obviously superior that the other side can be convinced.
Just to make my position clear again ; I'm for the "do them both"
approach. And I don't call for breaking anything at once,
Here is a rough translation, as asked. I hope that helps,
Snark on #sagemath
PS: here it comes :
Le 21/11/2011 18:07, Nicolas M. Thiery a écrit :
Bonjour,
Hi,
Avec quelques autres utilisateurs et développeurs de Sage [1] à Orsay
et à Jussieu, nous souhaitons lancer un groupe d'utili
Hi,
Le 03/12/2011 09:19, William Stein a écrit :
On Tue, Aug 23, 2011 at 5:39 AM, Julien Puydt wrote:
I fought again to compile sage on my little ARM box, then reported the
progress in trac -- with some hope 4.7.2 may compile without patching.
Is there any chance you could create a trac
Le 03/12/2011 09:21, William Stein a écrit :
... since I may be interested in trying a binary from you, which you
could make with "sage -bdist" or just by tarring up your existing
install of Sage, if you have the disk space.
I'm not sure I have the disk space, but I gave it a try :
./sage -bdis
Le 03/12/2011 16:41, kcrisman a écrit :
On Dec 3, 4:58 am, Julien Puydt wrote:
Le 03/12/2011 09:21, William Stein a crit :
... since I may be interested in trying a binary from you, which you
could make with "sage -bdist" or just by tarring up your existing
install of Sage, if yo
Le 03/12/2011 17:16, kcrisman a écrit :
Oh dear ; can't it get the version number itself like a big kid!?
The idea is that one can make longer name versions for different
purposes - like different architectures. Point taken, though - maybe
there's even a ticket for a "default" version...
In fa
Le 03/12/2011 19:27, William Stein a écrit :
Thanks for the updated ticket. I will probably just use the ubuntu
atlas binary instead of building atlas, to avoid trouble with that.
How does one do that for atlas? For other things?
Snark on #sagemath
--
To post to this group, send an email t
Le 03/12/2011 20:07, John H Palmieri a écrit :
Take a look at the Sage installation guide,
http://sagemath.org/doc/installation/source.html#environment-variables
in particular the ATLAS variables.
Thanks.
Snark on #sagemath
--
To post to this group, send an email to sage-devel@googlegroups.
Le 04/12/2011 16:58, Dima Pasechnik a écrit :
https://wiki.ubuntu.com/ARM/TEGRA/AC100
which Ubuntu version are you running, by the way?
Ubuntu 11.10 (GNU/Linux 2.6.38-1001-ac100-armv7l)
Snark on #sagemath
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe fr
Le 03/12/2011 10:58, Julien Puydt a écrit :
I'll try to compile 4.7.2 now : I don't need the box before monday noon.
I have successfully built 4.7.2 (with my special spkg, of course) ; it
took about 30h -- but there was an ICE so I had to re-launch make at
some point.
I star
Le 04/12/2011 20:09, Julien Puydt a écrit :
I started ./sage -bdist 4.7.2 ; I hope there is enough disk space. We'll
see.
It worked.
I recompressed it as a bzip2 before uploading to the server.
You'll find it at the big-file-service of my ISP :
http://dl.free.fr/tHJI33UqE
It wi
Le 09/12/2011 09:28, Georg S. Weber a écrit :
after reading the discussion at http://trac.sagemath.org/sage_trac/ticket/10572
it occured to me that as a rule, rules comes with exceptions.
More precisely, renaming the readline library that is bundled with
sage as "sage-readline" and adapting the
Le 02/01/2012 10:50, daveloeffler a écrit :
(What does -lm mean?)
That's for the C math lib.
Snark on #sagemath
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, v
Hi,
I finished today the compilation of sage 4.8.alpha5 on my little ARM box.
Three problems occurred:
(1) flint, but ticket #10328 has a solution ;
(2) R-readline -- I'm running ubuntu, so it hurts ;
(3) singular, but ticket #12110 has a solution.
Of course, (2) makes the resulting sage broken
Le 07/01/2012 05:44, Dima Pasechnik a écrit :
For me, alpha5 built OK on an ARM box running 11.10.
(it needed a couple of ARM-specific fixes, but otherwise was just fine).
It does not have readline-dev installed, which probably explains why I
had not R-related
problems.
Should one expect any regr
Le 07/01/2012 09:37, Dima Pasechnik a écrit :
by the way, I do "make -j3" on my ARM box. It holds up OK, and does not
seem to take 30h to build the thing. Building documentation is something
that really takes forever there, though...
Oh? I never *dared* using -j... How long does it take to buil
Le 07/01/2012 19:56, ssu a écrit :
Okay. gcc version is 4.6.2 2025. My os is arch bang linux (i686)
with kernel 3.1.5-1-ARCH. What might have gone wrong, should I try it
again?
On Jan 7, 10:27 am, John Cremona wrote:
You need to provide more information about your laptop's operating
sy
Le 09/01/2012 17:39, William Stein a écrit :
Hi Sage-Devel,
PROPOSAL: I propose that we remove python_gnutls, gnutls, opencdk,
libgcrypt, and
libgpg_error from Sage-5.0. See below for details.
Removing the above 5 packages will save space, make Sage build more
quickly and easily, and make
Le 09/01/2012 22:09, William Stein a écrit :
By the way, how can http://localhost:8000 ever work? If I'm using
VirtualBox and I go to http://localhost:8000 in Internet Explorer, I'm
definitely *not* going to get something having anything to do with the
virtual machine.
The browser could be _i
Le 09/01/2012 22:26, Julien Puydt a écrit :
The browser could be _in_ the VM ; that would make it easy to ensure
that both http://localhost:8000 and jsmath work.
... and no firewall & AV problems either ;-)
Snark on #sagemath
--
To post to this group, send an email to sage-d
Le 07/01/2012 09:37, Dima Pasechnik a écrit :
by the way, I do "make -j3" on my ARM box. It holds up OK, and does not
seem to take 30h to build the thing. Building documentation is something
that really takes forever there, though...
I launched a new compilation 20h ago with "make -j 3", and fr
Hi,
I would like to know how accurate the explicit dependencies in
spkg/standard/deps are.
For example, I see there that bzip2 needs prereq, but isn't listed
anywhere -- which would mean that it's only used as a build tool more
than a real dependency.
As another example, near line 435, the
Le 10/01/2012 15:03, Jeroen Demeyer a écrit :
On 2012-01-10 12:16, Julien Puydt wrote:
Hi,
I would like to know how accurate the explicit dependencies in
spkg/standard/deps are.
For example, I see there that bzip2 needs prereq, but isn't listed
anywhere -- which would mean that it's
Le 10/01/2012 23:16, Jeroen Demeyer a écrit :
On 2012-01-10 19:45, Julien Puydt wrote:
(2) Now consider :
A depends on C
B depends on C
but the Makefile just says :
A depends on C
and it just happens that since A is always built before B, then
everything works... but there is an implicit
Le 10/01/2012 23:14, Jeroen Demeyer a écrit :
On 2012-01-10 19:45, Julien Puydt wrote:
what is bzip2 used for, since it's not explicitly needed by anything?
bzip2 is used for uncompressing spkg's.
Would sage maintainers accept a patch to bzip2's spkg adding the
following
Le 10/01/2012 23:26, Jeroen Demeyer a écrit :
On 2012-01-10 23:25, Julien Puydt wrote:
Would sage maintainers accept a patch to bzip2's spkg adding the
following to spkg-install : "if there's already a bzip2 on the system
then don't compile&install a new one"?
I
Le 12/01/2012 05:10, William Stein a écrit :
On Wednesday, January 11, 2012, Michael Orlitzky mailto:mich...@orlitzky.com>> wrote:
> On 01/11/2012 03:40 AM, Jeroen Demeyer wrote:
>>
>> True, but we're talking a different order of magnitude here. Speeding
>> up the atlas installation by jus
Le 12/01/2012 16:08, Michael Orlitzky a écrit :
On 01/11/12 23:10, William Stein wrote:
On Wednesday, January 11, 2012, Michael Orlitzkymailto:mich...@orlitzky.com>> wrote:
On 01/11/2012 03:40 AM, Jeroen Demeyer wrote:
True, but we're talking a different order of magnitude here. Speeding
Le 14/01/2012 00:48, Jason Grout a écrit :
I'd love to, if we have enough disk space for another sage install on
that disk. Right now, we have around 4.4G free, so it would take up
about a quarter to half of the space left for all of the sagenb.org
servers. That seems a little tight to me.
A go
Hi,
after looking at the spkg/standard/deps file (in both 4.8.alpha6 and
5.0.beta1), I was wondering why patch isn't in $(BASE).
One reason would be that not everything depends on it, and so adding a
more explicit dependency is a good idea. But then, why would $(BASE)
exist anyway?
This ap
Hi,
I wrote two scripts to help me visualize package dependencies in sage
better, and thought it would be nice to share them.
Here is a sample use :
jpuydt@newton:~$ ./deps_cleaner.sh ~/sage-5.0.beta1/spkg/standard/deps |
./deps_to_dot.py > sage.dot
jpuydt@newton:~$ dot -Tpng sage.dot -osage
Le 15/01/2012 22:54, William Stein a écrit :
On Jan 15, 2012 1:20 PM, "Julien Puydt" mailto:julien.pu...@laposte.net>> wrote:
>
> Hi,
>
> I wrote two scripts to help me visualize package dependencies in sage
better, and thought it would be nice to share them
Le 16/01/2012 09:26, Jeroen Demeyer a écrit :
On 2012-01-15 22:24, Julien Puydt wrote:
PS: Of course, it's still possible those script are buggy to the core
and the graphs unreliable sources of information.
I'm pretty sure you are missing dependencies. On the graph, it looks
like T
Le 16/01/2012 10:23, Julien Puydt a écrit :
Less roots, but still too many of them.
I did some stats ; the roots are :
PALP
POLYTOPES_DB
SYMPOW
FLINTQS
G2RED
MAXIMA
PIL
TACHYON
GFAN
MOIN
SAGETEX
SCIPY
CVXOPT
and the only leaf is DIR, which is quite appropriate.
Snark on #sagemath
--
To post
Le 16/01/2012 11:57, Dr. David Kirkby a écrit :
On 01/16/12 09:45 AM, Jeroen Demeyer wrote:
It's important to understand that the list of merged tickets *varies
often*. The sage-5.0.beta1 you download today will likely be different
from the sage-5.0.beta1 somebody else downloaded yesterday. The
Le 16/01/2012 13:09, Dima Pasechnik a écrit :
it might be a good idea to publish the script alone, no?
Uh... I attached my scripts to my original mail, and attached the fixed
script to the answering mail.
In fact, if I hadn't been asked, I wouldn't have shared the result, only
the recipe!
Le 16/01/2012 15:08, Jason Grout a écrit :
On 1/16/12 4:36 AM, Julien Puydt wrote:
Le 16/01/2012 10:23, Julien Puydt a écrit :
Less roots, but still too many of them.
I did some stats ; the roots are :
PALP
POLYTOPES_DB
SYMPOW
FLINTQS
G2RED
MAXIMA
PIL
TACHYON
GFAN
MOIN
SAGETEX
SCIPY
CVXOPT
Le 16/01/2012 15:42, Burcin Erocal a écrit :
On Mon, 16 Jan 2012 04:21:37 -0800 (PST)
Dima Pasechnik wrote:
Once again, let me bring up the numerical noise issue on ARM.
The problem is that while we pretty much narrowed it down to a
particular function computing the log of the gamma-function,
Le 16/01/2012 15:51, Jason Grout a écrit :
On 1/16/12 8:45 AM, Julien Puydt wrote:
Uh... I just tried :
- firefox : ok
- midori : ok
- wget (command-line) : ok
So I don't understand the problem you have :-/
Sorry, I should have been more clear: my chrome blocks cookies, firefox
has nos
Le 16/01/2012 16:42, Keshav Kini a écrit :
All relevant files are now hosted at
http://boxen.math.washington.edu/home/keshav/files/Snark/ . Hopefully
this should solve any problems people are having :)
-Keshav
Thanks!
Snark on #sagemath
--
To post to this group, send an email to sage-devel@
Le 16/01/2012 13:49, mmarco a écrit :
Is there any hope of compiling sage for android? or the only way to
have sage running on a tablet would be to install a linux system on
top of the android one?
That is a very good question.
For a big phone (the marketing name is "smartphone"), there is
de
Le 16/01/2012 17:01, William Stein a écrit :
On Mon, Jan 16, 2012 at 4:49 AM, mmarco wrote:
Is there any hope of compiling sage for android? or the only way to
have sage running on a tablet would be to install a linux system on
top of the android one?
My impression is that the only way to bui
Le 16/01/2012 21:09, Jeroen Demeyer a écrit :
On 2012-01-16 16:58, daveloeffler wrote:
so there's always a canonical latest beta
which would be the natural one to use for general development work and
general bug-reporting?
But there is a canonical "latest beta" and in my post I mentioned
three(
Le 16/01/2012 23:36, jason-s...@creativetrax.com a écrit :
We don't apply any customizations to twisted anymore; we just install it
straight as a python package. I think it would be easier to just include
it in the sagenb spkg as a dependency (like flask, etc.). That would
mean that we automatica
Le 17/01/2012 15:33, Jason Grout a écrit :
If we separate out twisted on principle, it seems like we should
separate out the other 13 dependent packages that are included. That's a
maintenance burden I can't take on right now.
Are those heavily patched with respect to upstream?
Snark on #sagem
Le 17/01/2012 15:03, Jeroen Demeyer a écrit :
I have edited the supported platforms page to reflect the following, see
http://wiki.sagemath.org/SupportedPlatforms
* Increased needed diskspace to 3GB.
This is very bad.
* Changed phrase about memory to "It is recommended to have at least 2
GB
Le 17/01/2012 17:20, Jeroen Demeyer a écrit :
On 2012-01-17 17:09, kcrisman wrote:
On some very old Mac machines it is possible to build and run tests
with as little as .5 GB, with additional swap, because we do not have
to build ATLAS on that platform - but there are no guarantees.
You actuall
Le 17/01/2012 20:54, Jason Grout a écrit :
On 1/17/12 1:38 PM, Julien Puydt wrote:
Le 17/01/2012 15:33, Jason Grout a écrit :
If we separate out twisted on principle, it seems like we should
separate out the other 13 dependent packages that are included. That's a
maintenance burden I
Le 17/01/2012 21:10, Jason Grout a écrit :
On 1/17/12 2:04 PM, Julien Puydt wrote:
Le 17/01/2012 20:54, Jason Grout a écrit :
On 1/17/12 1:38 PM, Julien Puydt wrote:
Le 17/01/2012 15:33, Jason Grout a écrit :
If we separate out twisted on principle, it seems like we should
separate out the
Le 17/01/2012 17:22, Jeroen Demeyer a écrit :
On 2012-01-17 17:19, William Stein wrote:
FWIW, This reminds me that in Boston a number theorist named Simon Wong
showed me Pari running on his Android tablet as a proper android app
with a GUI.
Cross-compiled? I know PARI is fairly portable as lon
Le 18/01/2012 11:36, Jeroen Demeyer a écrit :
On 2012-01-18 11:22, Nicolas M. Thiery wrote:
On Tue, Jan 17, 2012 at 01:46:27AM -0800, Nathann Cohen wrote:
graphs.maps.WorldMap(world = "US")
Ahem. No, rather
graphs.maps.WorldMap()
graphs.maps.USMap()
Or just, from the user pers
Le 18/01/2012 12:35, Nathann Cohen a écrit :
No strings please. Use something which is TAB-completion-friendly.
HMmm... In this case it would make sense, but for #11880 the database is
really huge O_o
I'd like to find a smooth trick for that one :-/
What about a tree instead of a whole l
Le 19/01/2012 09:15, Dima Pasechnik a écrit :
Installing cephes means building static libs and putting appropriate
headers somewhere in $SAGE_ROOT/local (cephes is currently only
installed on Cygwin, where it provides some missing functionality for
complex number support), using parts of its code
Le 19/01/2012 20:11, Jeroen Demeyer a écrit :
On 2012-01-19 14:46, Julien Puydt wrote:
Does there exist a mechanism which allows an spkg to leave some file,
where some variables are defined, which will get used for the
compilation of packages afterwards?
What do you have in mind?
We need
Hi,
I just finished building successfully sage-4.8 on my ARM box, with only
a single change : the flint package. I just checked and sage-5.0.beta2
still has the same flint package as 4.8, so it still won't compile
natively on ARM.
It would be nice to clear that last hurdle :
http://trac.sage
Le 23/01/2012 02:12, François Bissey a écrit :
Seriously using system python with the stock sage tarball is just asking
for a lot of pain (including serious patching).
What kind of pain?
Were does the serious patching apply? In python itself or in dependent
packages?
Snark on #sagemath
--
Le 23/01/2012 21:29, François Bissey a écrit :
On Mon, 23 Jan 2012 07:24:14 Julien Puydt wrote:
Were does the serious patching apply? In python itself or in dependent
packages?
If you want to use system python you have to start doing some serious
juggling with PYTHONPATH or put things in a
Hi,
I ran sage-4.8 (with the flint-1.5.2 spkg)'s ptestlong :
Total time for all tests: 29104.6 seconds
There are three kinds of failures in the log :
(1) numerical uncertainty :
sage -t --long -force_lib devel/sage/sage/functions/other.py
**
Le 25/01/2012 13:22, Julien Puydt a écrit :
sage -t --long -force_lib devel/sage/sage/interfaces/quit.py
**
File "/home/jpuydt/sage-4.8/devel/sage-main/sage/interfaces/quit.py",
line 116:
sage: a, b
Expected:
(2, 3)
Go
Le 25/01/2012 14:16, Dima Pasechnik a écrit :
That's on 32-but ARM running Ubuntu 11.10, right?
Right.
So these graph-related things were not here before, or was it the 1st
time you ran ptestlong?
The previous times I ran ptestlong, there was just numerical noise and
pickle ; I can't remem
Le 25/01/2012 13:22, Julien Puydt a écrit :
(2) strange graph errors :
The good news is that if I put the following lines in a test_graphs.py
file, the problem is still there:
from sage.all import *
from sage.graphs.graph_decompositions.vertex_separation import
vertex_separation
from
Le 25/01/2012 17:14, Julien Puydt a écrit :
Le 25/01/2012 13:22, Julien Puydt a écrit :
(2) strange graph errors :
The good news is that if I put the following lines in a test_graphs.py
file, the problem is still there:
from sage.all import *
from
Le 25/01/2012 17:32, Julien Puydt a écrit :
What bothers me is that the "exists" function looks quite portable, so
the reason of the failure is unclear.
What bothers me even more is that this file has a very short history :
$ hg log sage/graphs/graph_decompositions/vertex_sepa
Le 26/01/2012 12:33, Nathann Cohen a écrit :
And I did not write this popcount myself, I found it on the (many)
pages on which everybody contributes with his own version of that code
:-D
Copyright issue?
Snark on #sagemath
--
To post to this group, send an email to sage-devel@googlegroups.com
Le 26/01/2012 10:53, Dima Pasechnik a écrit :
Is the popcount() there even big-endian/little-endian safe?
It's not obvious. As well, it will blow on architectures that have
a different from x86 idea about the length of int...
So one quick test would be to use __builtin_popcount(i) and see if it
m
Le 27/01/2012 16:25, Nathann Cohen a écrit :
Hell !!
Anyway, I finally have sage-4.8 again on that box, and the result of using
the builtin popcount is that it still doesn't work.
Where do we go from that point on?
Hmmm O_o
Well, I read the code again and the only weird thing I was
Le 27/01/2012 16:52, Willem Jan Palenstijn a écrit :
On Fri, Jan 27, 2012 at 02:05:25PM +0100, Julien Puydt wrote:
Le 26/01/2012 10:53, Dima Pasechnik a écrit :
Is the popcount() there even big-endian/little-endian safe?
It's not obvious. As well, it will blow on architectures that h
Le 27/01/2012 17:02, Julien Puydt a écrit :
Le 27/01/2012 16:52, Willem Jan Palenstijn a écrit :
Is char signed or unsigned on your platform?
Good question ; how do I find out?
If I put the following in test.c :
#include
#include
int
main()
{
printf ("%d\n", CHAR_MIN);
Le 27/01/2012 17:14, Willem Jan Palenstijn a écrit :
On Fri, Jan 27, 2012 at 05:07:56PM +0100, Julien Puydt wrote:
Le 27/01/2012 17:02, Julien Puydt a écrit :
Le 27/01/2012 16:52, Willem Jan Palenstijn a écrit :
Is char signed or unsigned on your platform?
Good question ; how do I find out
Le 27/01/2012 18:00, Nathann Cohen a écrit :
Wait... It means that on your platform the default "char" are unsigned ? O_o
I'm almost scared right now O_O
You'll be happy to learn (eh, I just learnt it this very afternoon) that
the C standards says that char can be either "unsigned char" or "s
Le 27/01/2012 17:56, Dima Pasechnik a écrit :
Perhaps some other doctest failures on ARM are also related to unsigned
char business? E.g. the pickling problem might be also due to this
messing with bits
I'll get to this pickling problem sooner or later ; I've known it to be
there ever sinc
Le 27/01/2012 18:08, Nathann Cohen a écrit :
I'm almost scared right now O_O
You'll be happy to learn (eh, I just learnt it this very afternoon) that the
C standards says that char can be either "unsigned char" or "signed char"...
so if you want to be safe, just use the most precise form.
Ok
Le 27/01/2012 19:14, Volker Braun a écrit :
Instead of sprinkling "unsigned" around until it works,
Well, that's not exactly what happened.
Once it was recognized that the problem was that the code was using
"char" thinking it meant "signed char" and that was wrong (surprise!),
then I checke
Hi,
I ran "make ptestlong" again ; this time with the SAGE_PICKLE_JAR
environment variable.
Now, here is what I have for example in ptestlong.log :
* unpickle failure:
load('/home/jpuydt/.sage/temp/hecke/26329/dir_2/pickle_jar/_class__sage_coding_linear_code_LinearCode__.sobj')
and here is
Le 29/01/2012 12:13, Willem Jan Palenstijn a écrit :
So this is the same issue with char being unsigned on your platform.
Specifically, it seems the corresponding __reduce__ function converts a char
array into a list of python ints, which has range 0-255 for you, instead of the
-128-127 on x86. A
Le 29/01/2012 13:38, Dima Pasechnik a écrit :
and then it does (line 1750):
cdef char *buf = gdImagePngPtr(im, &size)
data = [buf[i] for i in range(size)]
and this data goes into the pickle. No wonder it gets different on
different platforms!
Would that also be a case of just using uint8_t an
Le 29/01/2012 13:54, Dima Pasechnik a écrit :
On Sunday, 29 January 2012 00:34:28 UTC+8, Snark wrote:
Le 29/01/2012 13:38, Dima Pasechnik a �crit :
> and then it does (line 1750):
>
> cdef char *buf = gdImagePngPtr(im, &size)
> data = [buf[i] for i in range(size)]
Le 30/01/2012 03:10, Dima Pasechnik a écrit :
Working on the ARM port (kudos to Snark), which has, unlike x86,
unsigned char, we stumbled upon several places in Sage library (in
Cython code) where char type was used for (essentially) operating on bit
strings.
To be more specific : all platforms
Le 30/01/2012 09:43, Martin Albrecht a écrit :
Did you by any chance test whether switching to unsigned char in the
matrix_mod2 reduce function indeed fixes the issue? I don't have an ARM box
here to test?
I will try that as soon as Dima will have confirmed I'm not stepping on
his toes doing s
Le 30/01/2012 04:12, Julien Puydt a écrit :
I will try that as soon as Dima will have confirmed I'm not stepping on
his toes doing so.
He did, I tried, it worked :
http://trac.sagemath.org/sage_trac/ticket/12386
One more ARM problem down *g*
Snark on #sagemath
--
To post to this
Le 30/01/2012 17:16, William Stein a écrit :
On Jan 30, 2012 8:09 AM, "Nathann Cohen" mailto:nathann.co...@gmail.com>> wrote:
> Come ooon ! Half a second when you rebuild Sage !!! How bad can
that be ?
>
It takes nearly an hour on one cpu to build the sage library now right?
If you change
Le 30/01/2012 17:28, Nathann Cohen a écrit :
Spoiled, both of you.
If I touch devel/sage/sage/graph/graph_decompositions/vertex_separation.pyx,
then run sage -b, it takes already more than 30s on my little ARM box.
THIS file takes 30 seconds ? O_O
How long did it take to build Sage on this m
Le 31/01/2012 08:37, Iftikhar Burhanuddin a écrit :
When I execute a Sage script using the 'nohup' command [1], for instance
nohup sage test.sage> out.txt&
I generally use gnu screen [1] when I want to let some process run. That
still makes it possible to go Ctrl+C on the process if I'm unha
Hi,
I was patching happily, when I was hit by this:
sage -t --long "devel/sage-main/sage/rings/arith.py"
**
File "/home/jpuydt/sage-4.8/devel/sage-main/sage/rings/arith.py", line 3061:
sage: n(binomial(0.5r, 5),prec=53)
Expe
= Forewords =
I investigated the numerical issues on my ARM build, and after much
poking around and searching, I found that I was chasing the dahu : the
tests were wrong, and the result were good.
Let's consider the numerical failures one by one :
= 1/4 ===
Le 01/02/2012 18:26, William Stein a écrit :
On Wed, Feb 1, 2012 at 4:19 AM, Julien Puydt wrote:
So the tests should be modified not to depend on the specific implementation
: they're currently testing equality of floats!
See http://trac.sagemath.org/sage_trac/ticket/10952
Oh, dear!
Le 01/02/2012 20:43, Julien Puydt a écrit :
sage: SR(10.0r).gamma() # rel tol 1e-15
Out of tolerance 362880.0 vs 362880.0
In fact, the printed result is misleading : the floats *are* different,
and the difference is 4.6566...e-10, so the relative error is
1.2832...e-15, so it's indeed o
Le 02/02/2012 19:06, Dima Pasechnik a écrit :
On Tuesday, January 31, 2012 3:40:02 PM UTC-5, Snark wrote:
Hi,
I was patching happily, when I was hit by this:
sage -t --long "devel/sage-main/sage/rings/arith.py"
***
Le 02/02/2012 05:52, Jonathan Bober a écrit :
I've just been looking at this trying to figure out what was going on
and I was just going to say exactly the same thing.
I don't really know anything about the whole glibc vs eglibc thing, but
I bet the implementation is the same as
glibc-2.14.1/sys
Le 03/02/2012 07:31, Dr. David Kirkby a écrit :
Here's two from OpenSolaris on x86 - one with gcc, the other with the
Sun compiler 'cc'
drkirkby@hawk:~$ gcc test.c -lm
drkirkby@hawk:~$ ./a.out
sizof(double)=8
lgamma (6.)=4.78749174278204581157
tgamma (6.)=
Le 02/02/2012 23:22, Jonathan Bober a écrit :
Can you think of a reason that the answer should change? Does maxima use
less that 53 bits of precision ever?
Well, if I don't err, $10^{17}$ has 18 decimal digits, which is more
than the 15,95.. that fit in 53 binary digits.
In any case, let me
Le 03/02/2012 02:28, Jonathan Bober a écrit :
On Thu, Feb 2, 2012 at 3:05 PM, rjf mailto:fate...@gmail.com>> wrote:
I don't know about arithmetic on ARM specifically, but there is
something
wrong with a gamma() function that fails to return an integer (perhaps
in float format) w
Le 03/02/2012 10:56, Jonathan Bober a écrit :
On Thu, Feb 2, 2012 at 1:16 PM, Julien Puydt mailto:julien.pu...@laposte.net>> wrote:
Well, if I don't err, $10^{17}$ has 18 decimal digits, which is more
than the 15,95.. that fit in 53 binary digits.
It is not that simple. 1
Le 04/02/2012 07:39, Jonathan Bober a écrit :
For another example: I recently tried to compile some of my own code using
clang++ and discovered that I am not allowed to do
void f(int j) {
complex x[j];
[...]
}
even though g++ accepts that. ( See
http://clang.llvm.org/compatibility.htm
1 - 100 of 735 matches
Mail list logo
