[sage-devel] Re: icc

2010-05-23 Thread leif
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

2010-05-23 Thread Tim Daly

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


[sage-devel] Re: icc

2010-05-23 Thread leif
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: icc

2010-05-23 Thread Dr. David Kirkby

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


Re: [sage-devel] Re: icc

2010-05-23 Thread William A. Stein

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

2010-05-23 Thread William A. Stein

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

2010-05-23 Thread leif
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


Re: [sage-devel] Re: icc

2010-05-23 Thread Dr. David Kirkby

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


[sage-devel] Re: icc

2010-05-23 Thread leif
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


Re: [sage-devel] Re: icc

2010-05-23 Thread Dr. David Kirkby

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

2010-05-23 Thread Dr. David Kirkby

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: icc

2010-05-22 Thread Nathan O'Treally
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 ;-).

Compiling the C++ files with -std=c++98 or c++0x fails very early...
8/

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...)

Btw, it would be nice if someone could review

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

preferably on Cygwin or e.g. OpenSuSE 11.2 (or Fedora 13 [beta], final
will be out in a few days), so that I can base further patches on
that. :)

-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

2010-05-22 Thread Dr. David Kirkby

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

-Leif



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.


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: icc

2010-05-21 Thread Nathan O'Treally
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

-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: icc

2010-05-21 Thread Craig Citro
> 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.
>

And just as important -- make sure to post some performance numbers if/
when you get the code running. ;)

-cc

-- 
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

2010-05-21 Thread Mag Gam
Thanks for the detailed email I will see what i can do.



On Thu, May 20, 2010 at 4:38 AM, Dima Pasechnik  wrote:
> On Itanium systems, icc cannot compile GAP, one of Sage components.
> (well, it can, but the resulting program does not work)
>
> On May 20, 3:25 am, Mag Gam  wrote:
>> Has anyone attempted to compile sage with ICC? This is the Intel
>> compiler. I would like to do some testing with this therefore I would
>> appreciate any tips.
>>
>> --
>> 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
>

-- 
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

2010-05-20 Thread Dima Pasechnik
On Itanium systems, icc cannot compile GAP, one of Sage components.
(well, it can, but the resulting program does not work)

On May 20, 3:25 am, Mag Gam  wrote:
> Has anyone attempted to compile sage with ICC? This is the Intel
> compiler. I would like to do some testing with this therefore I would
> appreciate any tips.
>
> --
> 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