[sage-devel] Re: Generators in Sage
Hi guys,
Thanks for the insights. I knew that trying to define the generators
in my original way was asking for trouble, but it's good to learn
why. Right now, I just did the simple thing (which I should have done
from the start):
class DifferentialForms(Algebra):
def __init__(..., coordinates = ('x', 'y', 'z')):
# Create a dz for every z in coordinates
This way I can avoid any confusion with the 'names' keyword.
The "preparse" command is pretty cool!
All the best,
Joris
On 18 mei, 18:30, Jason Grout wrote:
> On 05/18/2010 11:14 AM, John Cremona wrote:
>
> > In our example, how does DifferentialForms() know that there are three
> > variables?
>
> > Also, note that the syntax F. = ... would normally be a
> > shorthand for something like F = ; x,y,z = F.gens().
>
> Good point. Joris, the syntax is just syntactic sugar that is
> preparsed into:
>
> sage: preparse('F.=DifferentialForms()')
> "F = DifferentialForms(names=('x', 'y', 'z',)); (x, y, z,) =
> F._first_ngens(3)"
>
> So you can see from the "(x,y,z,)=..." statement that you are in reality
> defining the variables "x", "y", and "z", and there is nothing a class
> can do about that without changing the preparser.
>
> In fact, if I wanted to call what you call "dx" by the name "x", I
> suppose that is my business, regardless of how many conventions it
> messes up :).
>
> In that sense, would it be so hard to expect the user to do something like:
>
> F.=DifferentialForms()
>
> which preparses into
>
> sage: preparse('F.=DifferentialForms()')
> "F = DifferentialForms(names=('dx', 'dy', 'dz',)); (dx, dy, dz,) =
> F._first_ngens(3)"
>
> Thanks,
>
> Jason
>
> --
> 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, visit this group athttp://groups.google.com/group/sage-devel
> URL:http://www.sagemath.org
--
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, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Do 'sympow' and 'palp' build 64-bit on OS X ?
On May 23, 2010, at 6:10 PM, Dr. David Kirkby wrote: > Trying to build Sage on OpenSolaris in 64-bit mode I discovered two packages > which look to me that they don't try to build 64-bit. They don't use the > SAGE64 variable at all and nothing else there suggests that the -m64 flag > ever gets added. > > This makes me think that they will not build properly as 64-bit on OS X > either, unless 64-bit is the default for the particular release of OS X. 64-bit is the default for OS X 10.6. We only bother building 64-bit Sage on OS X 10.6. William > > Comments? > > Dave > > -- > 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, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Do 'sympow' and 'palp' build 64-bit on OS X ?
Trying to build Sage on OpenSolaris in 64-bit mode I discovered two packages which look to me that they don't try to build 64-bit. They don't use the SAGE64 variable at all and nothing else there suggests that the -m64 flag ever gets added. This makes me think that they will not build properly as 64-bit on OS X either, unless 64-bit is the default for the particular release of OS X. Comments? Dave -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Fwd: [sage-combinat-devel] permutation group perspectives
> > Besides the usual suspects (who I hope are interested as well, you > know who you are!), Mike O'Sullivan and his students at San Diego > State might also be interested. > > Rob Yes, indeed, we are very interested. Our primary interest is classroom use, rather than research. Some of the of the things I would like to do: have various types of groups be integrated better e.g. unit groups of rings, matrix groups, permutation groups, abelian groups; be able to construct homomorphisms between them; construct direct products, construct a group via generators and relations compute cosets and conjugacy classes. Well, I am still a novice, so I'm not sure what can be done in Sage, what needs directly calling gap, and what all is involved in fulfilling this wish list. Mike -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: icc
On 24 Mai, 01:18, Tim Daly wrote:
> how about using:
>
> find . -name "*.pyx" -exec touch {} \;
We can save one more character:
find . -name \*.pyx -exec touch {} \;
-Leif
--
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, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: icc
how about using:
find . -name "*.pyx" -exec touch {} \;
William A. Stein wrote:
On May 23, 2010, at 1:12 PM, leif wrote:
On 23 Mai, 21:40, "Dr. David Kirkby" wrote:
'lcalc' had a particularly annoying attempt to cover up warnings from the
assembler, as it actually caused the build to break on Solaris, as the option to
cover up the warnings was passed directly to the Sun assembler, but it did not
accept the option.
They seem to think gcc (the compiler driver) will be smart enough to
know all options passed to any component of the tool chain, even if
passed verbatim ;-)
IMHO, the quality of the coding in Sage leaves a lot to be desired in places.
One of my current favorites is a snippet from sage-build:
cd "$SAGE_ROOT/devel/sage/sage"
echo "*** TOUCHING ALL CYTHON (.pyx) FILES ***"
touch */*.pyx */*/*.pyx */*/*/*.pyx */*/*/*/*.pyx */*/*/*/*/*.pyx */
*/*/*/*/*.pyx */*/*/*/*/*/*.pyx 2> /dev/null
Reminds me of M$-DOS, where the "shell" did not expand wildcards. (If
you have fun, count the asterisks...)
-Leif
Instead of keeping this as a favorite, implement a better version, and post a
patch.
-- William
--
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, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
--
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, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] What package(s) are these files part of?
> I've tried to create a 64-bit version of Sage on OpenSolaris, but some > files are building as 32-bit. Does anyone know what package(s) these are > part of? > > local/bin/class.x: > local/bin/cws.x: > local/bin/dikcube: > local/bin/nef.x: > local/bin/poly.x: > local/bin/QuadraticSieve: > local/bin/size222: > > local/lib/omalloc_debug.o: > local/lib/omalloc.o: *.x are from palp QuadraticSieve flintqs omalloc* from singular I think, size222 from rubiks I guess dikcube too. Francois -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] What package(s) are these files part of?
I've tried to create a 64-bit version of Sage on OpenSolaris, but some files are building as 32-bit. Does anyone know what package(s) these are part of? local/bin/class.x: local/bin/cws.x: local/bin/dikcube: local/bin/nef.x: local/bin/poly.x: local/bin/QuadraticSieve: local/bin/size222: local/lib/omalloc_debug.o: local/lib/omalloc.o: Dave -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Anyone know how to force 64-bit via python in gdmodule?
On 23 Mai, 22:47, "Dr. David Kirkby" wrote: > >> Host system > >> uname -a: > >> SunOS hawk 5.11 snv_134 i86pc i386 i86pc > > > uname -m == i386 is bad for a 64-bit machine... > > uname -m does not give i386. > > drkir...@hawk:~/sage-4.4.2$ uname -m > i86pc > drkir...@hawk:~/sage-4.4.2$ uname -p > i386 Ok, but a (system on a) Xeon should give x86_64 (or at least i686), not i386. I wonder if gcc detected the real cpu type, since it reports "Target: i386-pc-solaris2.11". Strange anyway, what does "gcc -v -Q -march=native foo.c" report? > If you do have some ideas, perhaps you can post them on the trac ticket. Certainly. -Leif -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Ubuntu 10.04, JMOL, Java
I found this page:
http://sites.google.com/site/easylinuxtipsproject/java#TOC-Install-JRE-32-bit-
to be quite useful. jmol now works on all my machines (running Ubuntu
10.04)
-Bruce
On May 12, 9:07 pm, Bruce Cohen wrote:
> I have just tried jmol on two machines running 32 bitUbuntu10.04.
> At the command line
>
> var('x y')
> plot3d(x^2+y^2, (x,-2,2), (y,-2,2))
>
> works on both machines.
>
> The same commands in the notebook work fine on the machine with the
> fresh 10.04 install, but do not work on the one which
> was upgraded from 9.10.
>
> On the fresh install, I show this with a url of "about:plugins"
>
> Java(TM) Plug-in 1.6.0_20
>
> File: libnpjp2.so
> Version:
> The next generationJavaplug-in for Mozilla browsers.
>
> -Bruce
>
> On May 12, 5:05 am, Pablo Angulo wrote:
>
> > My experience before 10.04 was that openjdk worked from the command
> > line, but not in the notebook. This appeared to be the case.
> > After reading this thread, I tried to drop my .mozilla folder, which I
> > have carried for years and now applets do work. More concretely, I
> > renamed .mozilla into .mozilla-no, and got a freash browser.
> > I've tried to find the particular file within .mozilla that causes the
> > trouble, as I want to keep the bookmarks and history, unsuccessfully.
>
> --
> 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, visit this group athttp://groups.google.com/group/sage-devel
> URL:http://www.sagemath.org
--
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, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: icc
On 23 Mai, 22:41, "Dr. David Kirkby" wrote:
> On 05/23/10 09:16 PM, William A. Stein wrote:
> > Instead of keeping this as a favorite, implement a better version, and post
> > a patch.
Work in progress. (But things depend on reviewing/merging other
tickets, too.
> I'm not going to hunt down the doggy code myself, but
>
> find "$SAGE_ROOT/devel/sage/sage" -name "*.pyx" -exec touch {} \;
>
> would probably do what the above intends to do, but in a slightly more elegant
> way.
Exactly.
-Leif
--
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, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: Anyone know how to force 64-bit via python in gdmodule?
On 05/23/10 09:40 PM, leif wrote: On 23 Mai, 22:03, "Dr. David Kirkby" wrote: gcc is being called without the -m64 option when building 'gdmodule' on OpenSolaris, despite SAGE64 being set to "yes". But I've no idea how to go about changing this behavior. There seems to be no code which does anything special on OS X for 64-bit builds. For Cygwin there is. I searched for '64' in setup.py and could not find any trace of the number '64'. I might have made a mistake. but don't have much clue about how to solve it, as I don't understand the build process involved here. You have to edit patches/Setup.py[.patch] and pass extra args to the compiler. (I can perhaps later post what/how exactly on the ticket.) Host system uname -a: SunOS hawk 5.11 snv_134 i86pc i386 i86pc uname -m == i386 is bad for a 64-bit machine... uname -m does not give i386. drkir...@hawk:~/sage-4.4.2$ uname -m i86pc drkir...@hawk:~/sage-4.4.2$ uname -p i386 drkir...@hawk:~/sage-4.4.2$ (I wonder why/how gcc was [auto-?]configured; without multi-lib support?) No particular multi-lib option was added. The compiler is certainly able to build both 32 and 64-bit libraries without any problem. gcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc-4.4.4/configure --prefix=/usr/local/gcc-4.4.4 --with-as=/usr/local/binutils-2.20/bin/as --with-ld=/usr/ccs/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.4.4 (GCC) -Leif If you do have some ideas, perhaps you can post them on the trac ticket. Dave -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: icc
On 05/23/10 09:16 PM, William A. Stein wrote:
On May 23, 2010, at 1:12 PM, leif wrote:
On 23 Mai, 21:40, "Dr. David Kirkby" wrote:
'lcalc' had a particularly annoying attempt to cover up warnings from the
assembler, as it actually caused the build to break on Solaris, as the option to
cover up the warnings was passed directly to the Sun assembler, but it did not
accept the option.
They seem to think gcc (the compiler driver) will be smart enough to
know all options passed to any component of the tool chain, even if
passed verbatim ;-)
IMHO, the quality of the coding in Sage leaves a lot to be desired in places.
One of my current favorites is a snippet from sage-build:
cd "$SAGE_ROOT/devel/sage/sage"
echo "*** TOUCHING ALL CYTHON (.pyx) FILES ***"
touch */*.pyx */*/*.pyx */*/*/*.pyx */*/*/*/*.pyx */*/*/*/*/*.pyx */
*/*/*/*/*.pyx */*/*/*/*/*/*.pyx 2> /dev/null
Reminds me of M$-DOS, where the "shell" did not expand wildcards. (If
you have fun, count the asterisks...)
-Leif
Instead of keeping this as a favorite, implement a better version, and post a
patch.
-- William
I'm not going to hunt down the doggy code myself, but
find "$SAGE_ROOT/devel/sage/sage" -name "*.pyx" -exec touch {} \;
would probably do what the above intends to do, but in a slightly more elegant
way.
Dave
--
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, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: Anyone know how to force 64-bit via python in gdmodule?
On 23 Mai, 22:03, "Dr. David Kirkby" wrote: > gcc is being called without the -m64 option when building 'gdmodule' on > OpenSolaris, despite SAGE64 being set to "yes". > > But I've no idea how to go about changing this behavior. There seems to be no > code which does anything special on OS X for 64-bit builds. For Cygwin there is. > but don't have much clue about how to solve it, as I don't understand the > build > process involved here. You have to edit patches/Setup.py[.patch] and pass extra args to the compiler. (I can perhaps later post what/how exactly on the ticket.) > Host system > uname -a: > SunOS hawk 5.11 snv_134 i86pc i386 i86pc uname -m == i386 is bad for a 64-bit machine... (I wonder why/how gcc was [auto-?]configured; without multi-lib support?) > gcc -v > Using built-in specs. > Target: i386-pc-solaris2.11 > Configured with: ../gcc-4.4.4/configure --prefix=/usr/local/gcc-4.4.4 > --with-as=/usr/local/binutils-2.20/bin/as --with-ld=/usr/ccs/bin/ld > --with-gmp=/usr/local --with-mpfr=/usr/local > Thread model: posix > gcc version 4.4.4 (GCC) -Leif -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: icc
On May 23, 2010, at 1:12 PM, leif wrote: > On 23 Mai, 21:40, "Dr. David Kirkby" wrote: >> 'lcalc' had a particularly annoying attempt to cover up warnings from the >> assembler, as it actually caused the build to break on Solaris, as the >> option to >> cover up the warnings was passed directly to the Sun assembler, but it did >> not >> accept the option. > > They seem to think gcc (the compiler driver) will be smart enough to > know all options passed to any component of the tool chain, even if > passed verbatim ;-) > >> IMHO, the quality of the coding in Sage leaves a lot to be desired in places. > > One of my current favorites is a snippet from sage-build: > > cd "$SAGE_ROOT/devel/sage/sage" > echo "*** TOUCHING ALL CYTHON (.pyx) FILES ***" > touch */*.pyx */*/*.pyx */*/*/*.pyx */*/*/*/*.pyx */*/*/*/*/*.pyx */ > */*/*/*/*.pyx */*/*/*/*/*/*.pyx 2> /dev/null > > Reminds me of M$-DOS, where the "shell" did not expand wildcards. (If > you have fun, count the asterisks...) > > -Leif > > -- > 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, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: icc
On May 23, 2010, at 1:12 PM, leif wrote: > On 23 Mai, 21:40, "Dr. David Kirkby" wrote: >> 'lcalc' had a particularly annoying attempt to cover up warnings from the >> assembler, as it actually caused the build to break on Solaris, as the >> option to >> cover up the warnings was passed directly to the Sun assembler, but it did >> not >> accept the option. > > They seem to think gcc (the compiler driver) will be smart enough to > know all options passed to any component of the tool chain, even if > passed verbatim ;-) > >> IMHO, the quality of the coding in Sage leaves a lot to be desired in places. > > One of my current favorites is a snippet from sage-build: > > cd "$SAGE_ROOT/devel/sage/sage" > echo "*** TOUCHING ALL CYTHON (.pyx) FILES ***" > touch */*.pyx */*/*.pyx */*/*/*.pyx */*/*/*/*.pyx */*/*/*/*/*.pyx */ > */*/*/*/*.pyx */*/*/*/*/*/*.pyx 2> /dev/null > > Reminds me of M$-DOS, where the "shell" did not expand wildcards. (If > you have fun, count the asterisks...) > > -Leif Instead of keeping this as a favorite, implement a better version, and post a patch. -- William > > -- > 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, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: icc
On 23 Mai, 21:40, "Dr. David Kirkby" wrote: > 'lcalc' had a particularly annoying attempt to cover up warnings from the > assembler, as it actually caused the build to break on Solaris, as the option > to > cover up the warnings was passed directly to the Sun assembler, but it did not > accept the option. They seem to think gcc (the compiler driver) will be smart enough to know all options passed to any component of the tool chain, even if passed verbatim ;-) > IMHO, the quality of the coding in Sage leaves a lot to be desired in places. One of my current favorites is a snippet from sage-build: cd "$SAGE_ROOT/devel/sage/sage" echo "*** TOUCHING ALL CYTHON (.pyx) FILES ***" touch */*.pyx */*/*.pyx */*/*/*.pyx */*/*/*/*.pyx */*/*/*/*/*.pyx */ */*/*/*/*.pyx */*/*/*/*/*/*.pyx 2> /dev/null Reminds me of M$-DOS, where the "shell" did not expand wildcards. (If you have fun, count the asterisks...) -Leif -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Anyone know how to force 64-bit via python in gdmodule?
gcc is being called without the -m64 option when building 'gdmodule' on OpenSolaris, despite SAGE64 being set to "yes". But I've no idea how to go about changing this behavior. There seems to be no code which does anything special on OS X for 64-bit builds. I've raised this as bug: http://trac.sagemath.org/sage_trac/ticket/9021 but don't have much clue about how to solve it, as I don't understand the build process involved here. gdmodule-0.56.p7/src/PKG-INFO Finished extraction Host system uname -a: SunOS hawk 5.11 snv_134 i86pc i386 i86pc CC Version gcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc-4.4.4/configure --prefix=/usr/local/gcc-4.4.4 --with-as=/usr/local/binutils-2.20/bin/as --with-ld=/usr/ccs/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.4.4 (GCC) ['gd', 'png12', 'z', 'freetype'] running build running build_py creating build creating build/lib.solaris-2.11-i86pc-2.6 copying gd.py -> build/lib.solaris-2.11-i86pc-2.6 running build_ext building '_gd' extension creating build/temp.solaris-2.11-i86pc-2.6 gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBZ -DHAVE_LIBFREETYPE -I/export/home/drkirkby/sage-4.4.2/local/include -I/usr/local/include -I/usr/include -I/usr/include/X11 -I/usr/X11R6/include -I/export/home/drkirkby/sage-4.4.2/local/include/python2.6 -c _gdmodule.c -o build/temp.solaris-2.11-i86pc-2.6/_gdmodule.o In file included from /export/home/drkirkby/sage-4.4.2/local/include/python2.6/Python.h:58, from _gdmodule.c:126: /export/home/drkirkby/sage-4.4.2/local/include/python2.6/pyport.h:685:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." _gdmodule.c:152: warning: function declaration isn’t a prototype _gdmodule.c:169: warning: function declaration isn’t a prototype _gdmodule.c: In function ‘image_string’: _gdmodule.c:993: warning: pointer targets in passing argument 5 of ‘gdImageString’ differ in signedness /export/home/drkirkby/sage-4.4.2/local/include/gd.h:363: note: expected ‘unsigned char *’ but argument is of type ‘char *’ _gdmodule.c: In function ‘image_string16’: _gdmodule.c:1008: warning: passing argument 5 of ‘gdImageString16’ from incompatible pointer type /export/home/drkirkby/sage-4.4.2/local/include/gd.h:367: note: expected ‘short unsigned int *’ but argument is of type ‘Py_UNICODE *’ _gdmodule.c: In function ‘image_stringup’: _gdmodule.c:1022: warning: pointer targets in passing argument 5 of ‘gdImageStringUp’ differ in signedness /export/home/drkirkby/sage-4.4.2/local/include/gd.h:365: note: expected ‘unsigned char *’ but argument is of type ‘char *’ _gdmodule.c: In function ‘image_stringup16’: _gdmodule.c:1037: warning: passing argument 5 of ‘gdImageStringUp16’ from incompatible pointer type /export/home/drkirkby/sage-4.4.2/local/include/gd.h:369: note: expected ‘short unsigned int *’ but argument is of type ‘Py_UNICODE *’ error: command 'gcc' failed with exit status 1 Failure to build gdmodule real0m0.118s user0m0.083s sys 0m0.031s sage: An error occurred while installing gdmodule-0.56.p7 -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: icc
On 05/23/10 04:18 PM, leif wrote:
The more evil thing is that currently *all* warnings in the
compilation of C/C++ Sage library files are suppressed by a *trailing*
"-w", so nobody will see any warning unless he/she edits setup.py
Unfortunately, this is all too common in many components of Sage. I find it very
worrying indeed.
'lcalc' had a particularly annoying attempt to cover up warnings from the
assembler, as it actually caused the build to break on Solaris, as the option to
cover up the warnings was passed directly to the Sun assembler, but it did not
accept the option.
make[1]: Entering directory `/export/home/drkirkby/L-1.23/src'
g++ -Wa,-W -O3 -Wno-deprecated -ffast-math -fPIC -I../include -c Lglobals.cc
/usr/ccs/bin/as: error: unknown option 'W'
usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-q] [-s]
[-S] [-K {pic,PIC}] [-o objfile] [-L] [-T]
[-P [[-Yc,path] [-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
[-m [-Ym,path]] [-n] [-ul] [-xF]
[-m32] [-m64]
[-xarch={v7,v8,v8a,v8plus,v8plusa,v8plusb,v9,v9a,v9b,sparc,sparcvis,
sparcvis2,sparcfmaf,sparcima}]
[-xcode={pic13,pic32}] file.s...
make[1]: *** [Lglobals.o] Error 1
IMHO, the quality of the coding in Sage leaves a lot to be desired in places.
Dave
--
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, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: Two line patch needs review.
On 05/23/10 04:52 PM, Minh Nguyen wrote: Hi David, On Mon, May 24, 2010 at 12:50 AM, Dr. David Kirkby wrote: If someone has a minute or two. http://trac.sagemath.org/sage_trac/ticket/9009 The changes look harmless enough. But I wanted to test building that updated spkg as 64-bit. It hardly ever occurred to me to build Sage as 64-bit on t2.math. In trying to do so, I did $ export SAGE64=yes and executed "make". Of course this didn't work because my SAGE_FORTRAN_LIB pointed to a 32-bit Fortran library. So I figured that I should change that variable to $ export SAGE_FORTRAN_LIB=/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9/libgfortran.so I then re-ran "make". Now I'm playing the waiting game to see if Sage builds as 64-bit on t2.math, or at least your updated spkg build as 64-bit on that machine. Sage will not build fully as 64-bit on 't2'. I've tried it on 't2' and on other SPARCs in the past (months ago). My experience on OpenSolaris in 64-bit mode shows me that there are some bits which will still build 32-bit, even when SAGE64 is set to "yes". As such, they will build 32-bit on 't2'. You would need to run the 'file' command on the files in $SAGE_LOCAL/lib and $SAGE_LOCAL/bin, as some might build 32-bit, but you wont discover the problems until you try to link a library. Others bits I know will cause a failure include: 1) sage_fortran will not add the -m64 option, so any fortran objects will be built 32-bit. A patch for that, written by Jaap Spies solves that, but his patch is against an older version of the fortran package. I've rebased that against the current package, which needs reviewing. http://trac.sagemath.org/sage_trac/ticket/7982 Unless that is done, lapack, ATLAS etc will not build properly as 64-bit. 2) zlib will build, but you *might* find it produces a 32-bit library, rather than a 64-bit library. I'd run the 'file' command on $SAGE_LOCAL/lib/libz* If not, the following http://boxen.math.washington.edu/home/kirkby/patches/zlib-1.2.5/zlib-1.2.5.spkg should resolve it, though it needs more testing. See: http://trac.sagemath.org/sage_trac/ticket/9008 It would be great to get a 64-bit SPARC build. But I think many of the issues would be much quickly resolved on a machine like 'fulvia' or an OpenSolaris machine on the x64 platform, as their better performance will allow many of the issues to be discovered much more quickly. Of course, there will be some issues specific to 64-bit SPARC and others specific to 64-bit OpenSolaris on x64, but I would expect 95% of the issues preventing 64-bit builds on both Intel and SPARC hardware will be the same on both architectures. Dave -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Building Sage from source fails on Slackware 13.0 x86_64
On 23 Mai, 15:30, geep999 wrote: > Anyway, all 2.1 Gb of Sage is now built, documentation created and > notebook seems OK with Firefox. Fine. If you find the time, you could try running "./sage -testall", "./sage -testall -long" or e.g. "make testlong"/"make ptestlong" (the latter runs tests in parallel). (The "standard" tests shouldn't take much more than an hour, with "long" tests enabled, perhaps up to two+. The "long" option includes the standard tests.) Thanks, -Leif -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Two line patch needs review.
Hi David, On Mon, May 24, 2010 at 12:50 AM, Dr. David Kirkby wrote: > If someone has a minute or two. > > http://trac.sagemath.org/sage_trac/ticket/9009 The changes look harmless enough. But I wanted to test building that updated spkg as 64-bit. It hardly ever occurred to me to build Sage as 64-bit on t2.math. In trying to do so, I did $ export SAGE64=yes and executed "make". Of course this didn't work because my SAGE_FORTRAN_LIB pointed to a 32-bit Fortran library. So I figured that I should change that variable to $ export SAGE_FORTRAN_LIB=/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9/libgfortran.so I then re-ran "make". Now I'm playing the waiting game to see if Sage builds as 64-bit on t2.math, or at least your updated spkg build as 64-bit on that machine. -- Regards Minh Van Nguyen -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: icc
On 23 Mai, 14:29, "Dr. David Kirkby" wrote: > On 05/23/10 01:27 PM, Dr. David Kirkby wrote: > > > *Both* -ansi and -pedantic should be used for the best conformance to > > standards, though it will not be perfect. But I doubt the Sage library > > would build with those. If Cython could generate code that works with > > those options, there is some hope the library would build with Sun Studio. > > Sorry, it is -ansi and -pedantic-errors which would be needed. For C, "-ansi" is equivalent to "-std=c89"... (that's perhaps not what we want) The more evil thing is that currently *all* warnings in the compilation of C/C++ Sage library files are suppressed by a *trailing* "-w", so nobody will see any warning unless he/she edits setup.py (even if CFLAGS are set to report them). (And they're compiled with "-O3", which implies "-fstrict- aliasing"...) The use of gcc's "-W..." / "-Wno-..." options in combination with "- Werror[=...]" or "-Wno-error=..." wouldn't be bad, too (if it was enabled on a compiler-sensitive basis). -Leif -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Two line patch needs review.
If someone has a minute or two. http://trac.sagemath.org/sage_trac/ticket/9009 needs review. The only change it the removal of if [ `uname` = "Darwin" -a "$SAGE64" = "yes" ]; then echo "64 bit MacIntel" to if [ "x$SAGE64" = xyes ]; then echo "Compiling Mercurial as 64-bit" which ensures the program builds as 64-bit only an OS where SAGE64 is set to "yes" - not just on OS X, which plagues many bits in Sage, though they are gradually being removed. Dave -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Building Sage from source fails on Slackware 13.0 x86_64
On 05/23/10 02:30 PM, geep999 wrote: Mea culpa. I hadn't got into the Sage way of doing things and didn't realize that the build would be alongside the Sage source tree created from sage-4.4.2.tar. Maybe README.txt should mention this. Or it's somewhere and I haven't noticed it. I don't feel README.txt needs to mention that, as this is how 99% of programs are built. Conversely, if Sage did always build under $HOME, then it would be right to mention it, as it would be almost unique in doing that. For some reason I thought it was going to build under $HOME - where I have little space. That would be very unusual for a program to do that. The only other strategy I know of is a few programs will refuse to build inside the directory where the sources are. It is certainly recommended one does not build gcc in the same directory as the gcc source. But 99% of programs are built in this directory. After building, typing 'make distclean' will remove all the built files for many programs, though not all. So I used DESTDIR to make it build where I have lots of free space. Using DESTDIR seems to have caused all the problems. I don't believe DESTDIR is anything used by Sage. Even thought things that are used by Sage (CC, CXX, CFLAGS, MAKE) are not used consistently. But I'm not even aware of DESTFIR being documented. Anyway, all 2.1 Gb of Sage is now built, documentation created and notebook seems OK with Firefox. Great. Now to learn how to use it... That is the more difficult bit! Thanks for your help everybody. Cheers, Peter -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Building Sage from source fails on Slackware 13.0 x86_64
Mea culpa. I hadn't got into the Sage way of doing things and didn't realize that the build would be alongside the Sage source tree created from sage-4.4.2.tar. Maybe README.txt should mention this. Or it's somewhere and I haven't noticed it. For some reason I thought it was going to build under $HOME - where I have little space. So I used DESTDIR to make it build where I have lots of free space. Using DESTDIR seems to have caused all the problems. Anyway, all 2.1 Gb of Sage is now built, documentation created and notebook seems OK with Firefox. Now to learn how to use it... Thanks for your help everybody. Cheers, Peter -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: icc
On 05/23/10 01:27 PM, Dr. David Kirkby wrote: *Both* -ansi and -pedantic should be used for the best conformance to standards, though it will not be perfect. But I doubt the Sage library would build with those. If Cython could generate code that works with those options, there is some hope the library would build with Sun Studio. Sorry, it is -ansi and -pedantic-errors which would be needed. Dave -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: icc
On 05/22/10 01:59 PM, Nathan O'Treally wrote: On 22 Mai, 13:17, "Dr. David Kirkby" wrote: On 05/22/10 03:24 AM, Nathan O'Treally wrote: On 21 Mai, 19:42, Robert Bradshaw wrote: Please let us know if you run into *any* examples of this--our goal is to always produce standard compliant C89 or C++ code (or C99 if the user has requested C99 complex support). Of course most Cython users are using gcc or MSVC. [W.r.t. Sage, not the code generated by cython:] Just try to compile the Sage library (with gcc!) with "-ansi" added - this very soon fails just because some people can't resist using (C99/C ++) end-of-line comments. ;-) Take a look at $SAGE_LOCAL/include/csage/*.h It would suggest to me that it would be wise to make that option the default and sort out the issues. Then hopefully the code should be more portable. I began cleaning those files, than resorted to compiling *all* Sage library C files with "-std=c99 -pedantic", but that still doesn't mean [full] C99-compliance (but at least works with gcc ;-). GCC does not support full C99 compliance. 11 years after the standard was ratified, the GCC developers are sill working on it. http://gcc.gnu.org/c99status.html *Both* -ansi and -pedantic should be used for the best conformance to standards, though it will not be perfect. But I doubt the Sage library would build with those. If Cython could generate code that works with those options, there is some hope the library would build with Sun Studio. Compiling the C++ files with -std=c++98 or c++0x fails very early... 8/ The Sun Studio compiler also objects pretty early on. That caught what even William considered were two serious bugs, where code that was expected to return data but did not do so. I think the whole Sage library build process has to be cleaned up... (see also #8844; I'll open a new ticket the next days...) I've not looked much at the library, but my impression is that there there are whole chunks of Sage which could be cleaned up. It's unfortunate that much of it is not really closely controlled by Sage developers. -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: wiki: No space left on device
Hi folks, On Sun, May 23, 2010 at 5:02 PM, Minh Nguyen wrote: > Hi folks, > > I'm getting a report on IRC that wiki.sagemath.org is returning an IOError: > > [Errno 28] No space left on device > > On the virtual machine sagemath, the root partition is 100% full. Harald Schilly has resolved this problem. Thanks, Harald. -- Regards Minh Van Nguyen -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Building Sage from source fails on Slackware 13.0 x86_64
On May 23, 12:50 am, Robert Bradshaw wrote: > That's almost certainly testing your system Python. > > Try the above using the python inside $SAGE_ROOT/local/bin and see if > it gives anything different. The interesting part will be the > traceback it gives (or not). > > - Robert > It was using Sage Python - before executing ./python I did a cd /space3/sage/space/software/Source/sage/sage-4.4.2/local/bin which is where Sage installed Python. Slackware Python: python --version gives Python 2.6.2 Sage Python: ./python --version gives Python 2.6.4 I have rerun the test by calling the Sage Python explicitly thus: /space3/sage/space/software/Source/sage/sage-4.4.2/local/bin/python -- version gives Python 2.6.4 Same result - hashlib and zlib load OK. Cheers, Peter test script results showing version of Python used - i.e. Sage Python: Working directory: /space3/sage/space/software/Source/sage/sage-4.4.2/ local/bin Sage Python : Python 2.6.4 which /space3/sage/space/software/Source/sage/sage-4.4.2/local/bin/ python : /space3/sage/space/software/Source/sage/sage-4.4.2/local/bin/ python Slackware Python : Python 2.6.2 which python : /usr/bin/python hashlib imported zlib imported Traceback (most recent call last): File "", line 1, in ImportError: No module named totalrubbish totalrubbish module failed to import test script test.sh #!/bin/bash cd /space3/sage/space/software/Source/sage/sage-4.4.2/local/bin echo -n "Working directory: " pwd echo -n "Sage Python : " /space3/sage/space/software/Source/sage/sage-4.4.2/local/bin/python -- version echo -n "which /space3/sage/space/software/Source/sage/sage-4.4.2/ local/bin/python : " which /space3/sage/space/software/Source/sage/sage-4.4.2/local/bin/ python echo -n "Slackware Python : " python --version echo -n "which python : " which python /space3/sage/space/software/Source/sage/sage-4.4.2/local/bin/python -c "import hashlib" if [ $? -eq 0 ]; then echo "hashlib imported" else echo "hashlib module failed to import" fi /space3/sage/space/software/Source/sage/sage-4.4.2/local/bin/python -c "import zlib" if [ $? -eq 0 ]; then echo "zlib imported" else echo "zlib module failed to import" fi /space3/sage/space/software/Source/sage/sage-4.4.2/local/bin/python -c "import totalrubbish" if [ $? -eq 0 ]; then echo "totalrubbish imported" else echo "totalrubbish module failed to import" fi test script modified to show Sage and Slackware Pythons -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] wiki: No space left on device
Hi folks, I'm getting a report on IRC that wiki.sagemath.org is returning an IOError: [Errno 28] No space left on device On the virtual machine sagemath, the root partition is 100% full. -- Regards Minh Van Nguyen -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Can LaTeX of strings be improved?
On 23 Mai, 08:15, Rob Beezer wrote: > Based on some limited testing - just editing the text version of a > worksheet - would indicate that jsMath does not want to deal with > \newline or \\ to break lines. With no better idea, I was able to use > HTML paragraph tags to get two chunks of text on different lines, of > course. Maybe a string could be chunked up based on the presence of > \n, then each handled on its own, producing HTML (as currently), > though deciding just when to wrap these with sounds > problematic (maybe just the presence of \n would be good enough?). I think the presence of \n indicates some ASCII art (_asciiart_()?, _is_asciiart_()?), but I would use instead of . -Leif -- 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, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
