Re: Re: [sage-devel] Re: Singular: Is 'flex' needed to build Sage?
> I will add to that from a, I hope logical perspective, the components > removed were all static libraries: > <<< obj /opt/sage/local/lib/libfac.a > <<< obj /opt/sage/local/lib/libcfmem.a > <<< obj /opt/sage/local/lib/libcf.a > Some other may have slightly changed has the build procedure in the spkg > was actually building them twice. Different build options are needed for linking against libcf and libfac directly than for including them in Singular as a stand-alone program. We used to link against libfac and libcf directly but this is long gone. So I think you are probably safe here. Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://www.informatik.uni-bremen.de/~malb _jab: martinralbre...@jabber.ccc.de -- 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] matplotlib is reading old system headers, in preference to Sage ones.
On 06/10/10 07:16 AM, David Kirkby wrote: I've tried the following - none of which avoid matplotlib finding the version of freetype on my system and not the one in Sage. 1) $ export PKG_CONFIG_PATH=/export/home/drkirkby/32/sage-4.4.3/local/pkgconfig Actually, that should have been PKG_CONFIG_PATH=/export/home/drkirkby/32/sage-4.4.3/local/lib/pkgconfig but it does not help the situation. This issue is not specific to Solaris either. On sage.math (linux), the install shows: freetype2: 9.16.3 which is what is shown by kir...@sage:~$ /usr/bin/pkg-config --modversion freetype2 9.16.3 So it looks to me like the presence of pkg-config on a system is forcing matplotlib to use that version of freetype and ignore the one which is shipped with Sage. That can't be desirable, but how to fix it is less than clear to me. The *only* way I have found so far to avoid matplotlib finding the old version of freetype2, is to change the permissions on pkg-config so it can't be executed. That needs root access of course. Then Sage reports it finds freetype2, but does not know the version. It would appear to me at that point that it probably finds the one shipped with Sage. I thought the high version number of freetype2 on Solaris might have been a mistake, but it is similar on sage.math too. There's something I'm not understanding here. 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] Error Bar plot
Hello to everybody, i'm try to use sage in my physics elaboration, but i could not make plot point with an error bar for each point.. there is the possibility to develop this function? Marco -- 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] matplotlib is reading old system headers, in preference to Sage ones.
On Thu, Jun 10, 2010 at 07:16:56AM +0100, David Kirkby wrote:
> drkir...@redstart:~$ cat /usr/lib/pkgconfig/freetype2.pc
> prefix=/usr/sfw
> exec_prefix=${prefix}
> libdir=${exec_prefix}/lib
> includedir=${prefix}/include
>
> Name: FreeType 2
> Description: A free, high-quality, and portable font engine.
> Version: 9.7.3
> Requires:
> Libs: -L${libdir} -R${libdir} -lfreetype
> Cflags: -I${includedir}/freetype2
>
> Perhaps that file has an error in it, or perhaps freetype2 at one
> point decided to change their version numbering in a rather odd way,
> going backwards!
Freetype just has a couple of different versioning schemes. The version number
"9.7.3" in the .pc file corresponds to release 2.1.9, and "9.16.3" corresponds
to release 2.3.5. (And then there's the numbering scheme which it uses for its
.so versions, which is different yet again.)
See the file src/docs/VERSION.DLL in the freetype package for details.
-Willem Jan
--
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] matplotlib is reading old system headers, in preference to Sage ones.
On 06/10/10 10:43 AM, Willem Jan Palenstijn wrote:
On Thu, Jun 10, 2010 at 07:16:56AM +0100, David Kirkby wrote:
drkir...@redstart:~$ cat /usr/lib/pkgconfig/freetype2.pc
prefix=/usr/sfw
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: FreeType 2
Description: A free, high-quality, and portable font engine.
Version: 9.7.3
Requires:
Libs: -L${libdir} -R${libdir} -lfreetype
Cflags: -I${includedir}/freetype2
Perhaps that file has an error in it, or perhaps freetype2 at one
point decided to change their version numbering in a rather odd way,
going backwards!
Freetype just has a couple of different versioning schemes. The version number
"9.7.3" in the .pc file corresponds to release 2.1.9, and "9.16.3" corresponds
to release 2.3.5. (And then there's the numbering scheme which it uses for its
.so versions, which is different yet again.)
See the file src/docs/VERSION.DLL in the freetype package for details.
-Willem Jan
Thank you. Having read src/docs/VERSION.DLL, I see that there are in fact
*three* different numbers all associated with the version. It is any wonder I've
been confused?
Dave
releaselibtool so
---
2.3.12 10.0.46.4.0
2.3.11 9.22.36.3.22
2.3.10 9.21.36.3.21
2.3.9 9.20.36.3.20
2.3.8 9.19.36.3.19
2.3.7 9.18.36.3.18
2.3.6 9.17.36.3.17
2.3.5 9.16.36.3.16
2.3.4 9.15.36.3.15
2.3.3 9.14.36.3.14
2.3.2 9.13.36.3.13
2.3.1 9.12.36.3.12
2.3.0 9.11.36.3.11
2.2.1 9.10.36.3.10
2.2.0 9.9.3 6.3.9
2.1.10 9.8.3 6.3.8
2.1.9 9.7.3 6.3.7
2.1.8 9.6.3 6.3.6
2.1.7 9.5.3 6.3.5
2.1.6 9.5.3 6.3.5
2.1.5 9.4.3 6.3.4
2.1.4 9.3.3 6.3.3
2.1.3 9.2.3 6.3.2
2.1.2 9.1.3 6.3.1
2.1.1 9.0.3 ?
2.1.0 8.0.2 ?
2.0.9 9.0.3 ?
2.0.8 8.0.2 ?
2.0.4 7.0.1 ?
2.0.1 6.1.0 ?
--
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: ANSI C vs. C99
Hello, Robert. You wrote 10 июня 2010 г., 7:58:49: > I'd be glad to know exactly what is special about writing ALGLIB > that's more difficult to do with using Cython. I can't say that it is difficult to do with Cython. I just want to say that for me - and just for me - Cython has no benefits over ctypes. Cython advantages are: a) improved performance of Python code, and b) easier integration of external libraries. I don't need (a) because all time-consuming operations are done in external library. As for (b), the most important aspect of Cython is that it makes easier _non-automated_, manual creation of interfaces. But all my interface code is automatically generated :) Ctypes, from the other side, is a part of standard library, so code relying on Ctypes will be more portable. It also provides me with direct access to shared library linking mechanism. >> Ctypes gives me better control over situation. Arrays and records >> with complex fields (which are records/arrays too) are hard to >> represent in Cython, I think. > > By records, are you talking about C structs? Cython can handle > (nested) structs and arrays just fine, and easier (in my opinion) > than ctypes can. Actually, I can't think of anything control that > ctypes gives that Cython doesn't (though I'd be glad to be > corrected). > I am talking about C structs which contain dynamically allocated arrays which should be freed when the structure is destroyed. I'll explain it below in more details. I develop Python<->ALGLIB interface keeping in mind one more goal - to apply same interface generation technology to another programming languages. The idea is to create binary release of ALGLIB, which includes assembly optimized implementations of algorithms, and to access its functionality from multiple languages. So we will have one shared library alglib.so (or alglib.dll) which can be used from several programming environments - Python, .NET, maybe Java... Furthermore, I want it to be efficient, especially for large problems (it should be able to work with matrices up to several GBs). Such ambitious goal requires me to develop very complex interface. Several examples: * all data structures are platform-oblivious (necessary for seamless integration with C#; lesson I've learned from work on MPIR interface) * all records have special constructor and destructor functions which allocate and deallocate dynamic arrays associated with their fields. * if calling environment provides me with matrix stored in contiguous memory block, interface will try to reuse this memory as much as possible * all allocations/deallocations are tracked, i.e. upon returning from ALGLIB function we can say whether input arrays were unchanged, used to store result, or result was stored in another location. * everything said above requires complex communication protocols to be implemented. It took most part of the May to implement, but now I can say that interface part is almost over :) You can see that it goes far beyond SAGE and Python, although future integration in SAGE is very important for me. And, with such complex interface, you can see that independently of what I'll use - Ctypes or Cython - I'll have a lot of work to do :) -- With best regards, Sergey mailto:sergey.bochka...@alglib.net -- 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: matplotlib is reading old system headers, in preference to Sage ones.
On 6/10/10 6:01 AM, Dr. David Kirkby wrote: Thank you. Having read src/docs/VERSION.DLL, I see that there are in fact *three* different numbers all associated with the version. It is any wonder I've been confused? Now *I'm* confused :). What is the conclusion? Does anything need to be done? I'm in the process of updating matplotlib in Sage to 0.99.3 to get a needed bugfix into the Sage version. David: are you working on the spkg too? Thanks, Jason -- Jason Grout -- 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: ANSI C vs. C99
On 06/ 9/10 08:53 PM, Sergey Bochkanov wrote: Hello, thanks to all who've replied to this discussion! Taking into account what was said above, I've decided to target pure ANSI C, i.e. C without newer constructs like // comments and other stuff from newer standards. I don't want to use C99 because it isn't supported by MSVC (de facto standard under Windows). I think that I'll make exception for static inlines because they can be easily turned on/off with just one #define. Another exception - I want to make use of SSE intrinsics (if they are provided by compiler), but slower ANSI C equivalent will be provided so one #define - and everything will be ANSI. It would be great if you could check your code with the Sun Studio compiler, which you can get for free for Linux or Solaris. Sage builds on Solaris systems with SPARC processors. These will never have SSE instructions, as the processor is completely different to Intel/AMD. You can check if the system has a sparc processor by detecting if __sparc__ is defined. In which case, you can immediately rule out there being SSE instructions of any sort. -- 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: matplotlib is reading old system headers, in preference to Sage ones.
On 6/9/10 10:22 PM, John Hunter wrote:
On Wed, Jun 9, 2010 at 9:15 PM, John Hunter wrote:
* sys.platform != 'darwin' on the box you are building on. In this
case you need to modify your patch to include sys.platform. This is
the most likely culprit as far as I can see.
Sorry, upon rereading your post, I see you are building on a solaris
platform and not an OSX platform. It does look like you need an entry
in basedir that maps your solaris sys.platform -> [sage_lib].
Presumably this is 'sunos5'.
Yes. Currently, the patched setupext.py file looks like:
-
### FOR SAGE
sage_inc = os.environ['SAGE_LOCAL'] + '/include/'
sage_lib = os.environ['SAGE_LOCAL'] + '/lib/'
basedir = {
'win32' : ['win32_static',],
'linux2' : [sage_lib],
'linux' : ['/usr/local', '/usr',],
'cygwin' : ['/usr/local', '/usr',],
'_darwin' : ['/sw/lib/freetype2', '/sw/lib/freetype219', '/usr/local',
'/usr', '/sw'],
# it appears builds with darwin are broken because of all the
# different flags the deps can be compile with, so I am pushing
# people to :
# make -f make.osx fetch deps mpl_build mpl_install
'darwin' : [sage_lib],
'freebsd4' : ['/usr/local', '/usr'],
'freebsd5' : ['/usr/local', '/usr'],
'freebsd6' : ['/usr/local', '/usr'],
'sunos5' : [os.getenv('MPLIB_BASE') or '/usr/local',],
'gnukfreebsd5' : ['/usr/local', '/usr'],
'gnukfreebsd6' : ['/usr/local', '/usr'],
'aix5' : ['/usr/local'],
}
-
AND there's another patch, where basedir is actually used:
---
def add_base_flags(module):
incdirs = filter(os.path.exists,
[os.path.join(p, 'include') for p in
basedir[sys.platform] ])
libdirs = filter(os.path.exists,
[os.path.join(p, 'lib') for p in
basedir[sys.platform] ]+
[os.path.join(p, 'lib64') for p in
basedir[sys.platform] ] )
module.include_dirs.extend(incdirs)
module.include_dirs.append('.')
module.include_dirs.append(sage_inc)
module.library_dirs.extend(libdirs)
module.library_dirs.extend([sage_lib])
-
(note that we added sage_inc and sage_lib *after* the platform specific
directories) (and we confusingly use append and extend---minor nitpick,
though).
So my guess is that sunos5 is getting set in the basedirs definition,
and then the sage-specific directories are then getting appended after
the platform-specific directories in the second piece of code above.
What if we merely change the second piece of code to be:
-
def add_base_flags(module):
module.include_dirs.append(os.environ['SAGE_LOCAL'] + '/include/')
module.library_dirs.append(os.environ['SAGE_LOCAL'] + '/lib/')
incdirs = filter(os.path.exists,
[os.path.join(p, 'include') for p in
basedir[sys.platform] ])
libdirs = filter(os.path.exists,
[os.path.join(p, 'lib') for p in
basedir[sys.platform] ]+
[os.path.join(p, 'lib64') for p in
basedir[sys.platform] ] )
module.include_dirs.extend(incdirs)
module.include_dirs.append('.')
module.library_dirs.extend(libdirs)
-
(and we leave the definition of basedir alone). That puts the sage
directories in front of the platform-specific directories on all platforms.
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 at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: matplotlib is reading old system headers, in preference to Sage ones.
On 06/10/10 12:04 PM, Jason Grout wrote: On 6/10/10 6:01 AM, Dr. David Kirkby wrote: Thank you. Having read src/docs/VERSION.DLL, I see that there are in fact *three* different numbers all associated with the version. It is any wonder I've been confused? Now *I'm* confused :). I can't possibly understand why! What is the conclusion? matplotlib is *not* finding the correct (i.e Sage supplied) version of freetype on Solaris, and I doubt it is on linux either, though I may be wrong about Linux. Does anything need to be done? Yes, it does, but exactly what I do not know. Go ahead and update matplotlib, that can't do any harm. Certainly on Solaris 10, the version of freetype2 being reported by matplotlib is the one in /usr/sfw, and not the one in Sage. drkir...@redstart:~$ /usr/bin/pkg-config --modversion --cflags --libs freetype2 9.7.3 indicates version 9.7.3, which is also known as 2.1.9 and has a library version of 6.3.7 . (See table I posted). That is different to the version of freetype in Sage, which is 2.3.5 (aka 9.17.3) On sage.math, I expect that is broken too, but I'm not 100% sure, as the version of freetype installed globally on sage.math is 9.16.2 (aka 2.3.5), which is conincidently the same version supplied in the Sage tarball. Hence it's not possible to tell where matplotlib has found freetype from on sage.math (or boxen.math), since they both version as in Sage. I assume you have a linux box there. Can you check the output of /usr/bin/pkg-config --modversion freetype2 Hopefully it will show something other than 9.17.3. If it does, then it would be useful to compare that version with whatever matplotlib says is your freetype2 version (just grep for "freetype2:" in install.log). The only two systems I have access to (boxen.math and sage.math) happen to have version 9.16.2 (aka 2.3.5), which is the same version as in Sage. So I can't easily tell where matplotlib is finding freetype2 from. I'm in the process of updating matplotlib in Sage to 0.99.3 to get a needed bugfix into the Sage version. David: are you working on the spkg too? Yes. Can you create a ticket, and cc me on it. Should I find the fix before you do, then I'll let you know. If not, just release a new matplotlib. I've tried the latest version of matplotlib, but it does not fix the issues I have on Solaris. I'm just in the process of building Sage on 'sage.math' and will try a new freetype on there, and see what happens. Thanks, Jason Grout 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: matplotlib is reading old system headers, in preference to Sage ones.
On 06/10/10 12:30 PM, Jason Grout wrote:
On 6/9/10 10:22 PM, John Hunter wrote:
On Wed, Jun 9, 2010 at 9:15 PM, John Hunter wrote:
* sys.platform != 'darwin' on the box you are building on. In this
case you need to modify your patch to include sys.platform. This is
the most likely culprit as far as I can see.
Sorry, upon rereading your post, I see you are building on a solaris
platform and not an OSX platform. It does look like you need an entry
in basedir that maps your solaris sys.platform -> [sage_lib].
Presumably this is 'sunos5'.
Yes. Currently, the patched setupext.py file looks like:
-
### FOR SAGE
sage_inc = os.environ['SAGE_LOCAL'] + '/include/'
sage_lib = os.environ['SAGE_LOCAL'] + '/lib/'
basedir = {
'win32' : ['win32_static',],
'linux2' : [sage_lib],
'linux' : ['/usr/local', '/usr',],
'cygwin' : ['/usr/local', '/usr',],
'_darwin' : ['/sw/lib/freetype2', '/sw/lib/freetype219', '/usr/local',
'/usr', '/sw'],
# it appears builds with darwin are broken because of all the
# different flags the deps can be compile with, so I am pushing
# people to :
# make -f make.osx fetch deps mpl_build mpl_install
'darwin' : [sage_lib],
'freebsd4' : ['/usr/local', '/usr'],
'freebsd5' : ['/usr/local', '/usr'],
'freebsd6' : ['/usr/local', '/usr'],
'sunos5' : [os.getenv('MPLIB_BASE') or '/usr/local',],
'gnukfreebsd5' : ['/usr/local', '/usr'],
'gnukfreebsd6' : ['/usr/local', '/usr'],
'aix5' : ['/usr/local'],
}
-
AND there's another patch, where basedir is actually used:
---
def add_base_flags(module):
incdirs = filter(os.path.exists,
[os.path.join(p, 'include') for p in basedir[sys.platform] ])
libdirs = filter(os.path.exists,
[os.path.join(p, 'lib') for p in basedir[sys.platform] ]+
[os.path.join(p, 'lib64') for p in basedir[sys.platform] ] )
module.include_dirs.extend(incdirs)
module.include_dirs.append('.')
module.include_dirs.append(sage_inc)
module.library_dirs.extend(libdirs)
module.library_dirs.extend([sage_lib])
-
(note that we added sage_inc and sage_lib *after* the platform specific
directories) (and we confusingly use append and extend---minor nitpick,
though).
So my guess is that sunos5 is getting set in the basedirs definition,
and then the sage-specific directories are then getting appended after
the platform-specific directories in the second piece of code above.
What if we merely change the second piece of code to be:
-
def add_base_flags(module):
module.include_dirs.append(os.environ['SAGE_LOCAL'] + '/include/')
module.library_dirs.append(os.environ['SAGE_LOCAL'] + '/lib/')
incdirs = filter(os.path.exists,
[os.path.join(p, 'include') for p in basedir[sys.platform] ])
libdirs = filter(os.path.exists,
[os.path.join(p, 'lib') for p in basedir[sys.platform] ]+
[os.path.join(p, 'lib64') for p in basedir[sys.platform] ] )
module.include_dirs.extend(incdirs)
module.include_dirs.append('.')
module.library_dirs.extend(libdirs)
-
(and we leave the definition of basedir alone). That puts the sage
directories in front of the platform-specific directories on all platforms.
Thanks,
Jason
Note also
1) There is a section "def check_for_freetype():"
2) The code seems to have changed in the latest matplotlib, so I would not waste
too much time over that in Sage if you intend updating matplotlib. I'd fix it
after updating.
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: matplotlib is reading old system headers, in preference to Sage ones.
On 6/10/10 7:55 AM, Dr. David Kirkby wrote: I'm in the process of updating matplotlib in Sage to 0.99.3 to get a needed bugfix into the Sage version. David: are you working on the spkg too? Yes. Can you create a ticket, and cc me on it. Should I find the fix before you do, then I'll let you know. If not, just release a new matplotlib. I've tried the latest version of matplotlib, but it does not fix the issues I have on Solaris. I'm just in the process of building Sage on 'sage.math' and will try a new freetype on there, and see what happens. I've posted the update to http://trac.sagemath.org/sage_trac/ticket/9202 Actually, I'm pretty sure I fixed the issue in this thread with the new spkg (see my other message in this thread for a discussion of what the issue is, or see the hg commit log in the new spkg). I also removed another solaris-specific patch that we apply, that I'm pretty sure is obsolete as of a year ago or so. Can you check the new spkg on Solaris and let us know if there are any problems? 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 at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: matplotlib is reading old system headers, in preference to Sage ones.
On 6/10/10 8:15 AM, Dr. David Kirkby wrote: Note also 1) There is a section "def check_for_freetype():" Yes, good point. My hope is that *prepending* the sage directories will have taken care of the problem, as check_for_freetype works with that list of directories. 2) The code seems to have changed in the latest matplotlib, so I would not waste too much time over that in Sage if you intend updating matplotlib. I'd fix it after updating. I have to update the patches anyway for the upgrade (because setupext.py had changed), so I had to look at this anyway. 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 at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: ANSI C vs. C99
Hello, David You wrote 10 июня 2010 г., 15:25:03: > It would be great if you could check your code with the Sun Studio > compiler, which you can get for free for Linux or Solaris. It is not great, it is must-have. Building ALGLIB on every platform where SAGE builds and with every popular compiler is top priority for me. > Sage builds on Solaris systems with SPARC processors. These will > never have SSE instructions, as the processor is completely > different to Intel/AMD. You can check if the system has a sparc > processor by detecting if __sparc__ is defined. I have no experience with SPARC, but I've studied different CPU architectures before starting this project. "Generic C" build with all optimizations turned off should work on SPARC and other non x86 ISA's. BTW, what compilers support this __sparc__ symbol? -- With best regards, Sergey mailto:sergey.bochka...@alglib.net -- 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: matplotlib is reading old system headers, in preference to Sage ones.
On 06/10/10 01:19 PM, Jason Grout wrote: On 6/10/10 7:55 AM, Dr. David Kirkby wrote: I'm in the process of updating matplotlib in Sage to 0.99.3 to get a needed bugfix into the Sage version. David: are you working on the spkg too? Yes. Can you create a ticket, and cc me on it. Should I find the fix before you do, then I'll let you know. If not, just release a new matplotlib. I've tried the latest version of matplotlib, but it does not fix the issues I have on Solaris. I'm just in the process of building Sage on 'sage.math' and will try a new freetype on there, and see what happens. I've posted the update to http://trac.sagemath.org/sage_trac/ticket/9202 Actually, I'm pretty sure I fixed the issue in this thread with the new spkg (see my other message in this thread for a discussion of what the issue is, or see the hg commit log in the new spkg). I also removed another solaris-specific patch that we apply, that I'm pretty sure is obsolete as of a year ago or so. Can you check the new spkg on Solaris and let us know if there are any problems? Thanks, Jason No, it has not fixed it. Leaving pkg-config working, matplotlib reports version REQUIRED DEPENDENCIES numpy: 1.3.0 freetype2: 9.7.3 That's the version in /usr/sfw. When I change the permission of the files in /usr/sfw so they can't be read, I get an error while installing matplotlib. /export/home/drkirkby/32/sage-4.4.3/local/lib/python2.6/site-packages/numpy/core/include/numpy/npy_interrupt.h:83:20: error: /usr/sfw/include/freetype2/setjmp.h: Permission denied So we can see, matplotlib is still trying to read from /usr/sfw. From what I've been playing around with, the only way I can get matplotlib to find the sage version is to stop pkg-config from working. drkir...@redstart:~/32/sage-4.4.3/spkg/standard$ su Password: # chmod 000 /usr/bin/pkg-config # exit Then, it would appear that matplotlib finds the freetype2 version in Sage, though it is unable to find the version number. REQUIRED DEPENDENCIES numpy: 1.3.0 freetype2: found, but unknown version (no pkg-config) I think the solution will revolve around stopping matplotlib making use of the output from the pkg-config command. If you can do that, it should find the version in Sage, and will report "freetype2: found, but unknown version (no pkg-config)" It seems at the minute, that pkg-config is used in preference to any settings that we have so far tried. 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: ANSI C vs. C99
On 06/10/10 01:30 PM, Sergey Bochkanov wrote:
Hello, David
You wrote 10 июня 2010 г., 15:25:03:
It would be great if you could check your code with the Sun Studio
compiler, which you can get for free for Linux or Solaris.
It is not great, it is must-have. Building ALGLIB on every platform
where SAGE builds and with every popular compiler is top priority for
me.
Sage builds on Solaris systems with SPARC processors. These will
never have SSE instructions, as the processor is completely
different to Intel/AMD. You can check if the system has a sparc
processor by detecting if __sparc__ is defined.
I have no experience with SPARC, but I've studied different CPU
architectures before starting this project. "Generic C" build with all
optimizations turned off should work on SPARC and other non x86 ISA's.
BTW, what compilers support this __sparc__ symbol?
Having checked again, __sparc is preferable. That is supported by gcc, g++, cc
and CC (the Sun compilers)
kir...@t2:[~] $ cat test.c
#include
#include
int main(int argc, char **argv) {
#ifdef __sparc
printf("I'm a SPARC\n");
#endif
}
First on a Solaris 10 machine based on a Sun SPARC processor.
kir...@t2:[~] $ /opt/SUNWspro/bin/cc test.c
kir...@t2:[~] $ ./a.out
I'm a SPARC
kir...@t2:[~] $ /opt/SUNWspro/bin/CC test.c
kir...@t2:[~] $ ./a.out
I'm a SPARC
kir...@t2:[~] $ gcc test.c
kir...@t2:[~] $ ./a.out
I'm a SPARC
kir...@t2:[~] $ g++ test.c
kir...@t2:[~] $ ./a.out
I'm a SPARC
So both the Sun and GNU compilers support __sparc.
On another Solaris machine, but this time based on an Intel Xeon.
drkir...@hawk:~$ /opt/sunstudio12.1/bin/cc test.c
drkir...@hawk:~$ ./a.out
drkir...@hawk:~$ /opt/sunstudio12.1/bin/CC test.c
drkir...@hawk:~$ ./a.out
drkir...@hawk:~$ gcc test.c
drkir...@hawk:~$ ./a.out
drkir...@hawk:~$ g++ test.c
drkir...@hawk:~$ ./a.out
drkir...@hawk:~$ uname -a
SunOS hawk 5.11 snv_134 i86pc i386 i86pc
So I think __sparc will be ok on Solaris. It is defined on a SPARC system and it
is not defined on an Intel system.
One can run Linux on a SPARC too, but that is very very rare. I'm not aware of
any active development of any Linux distro for the SPARC processor.
I've also got machines running AIX, tru64, HP-UX and IRIX. None of the CPUs in
those sorts of machines would support SSE. Clearly there are many system which
will never support SSE, though Solaris SPARC is the most critical for Sage.
I doubt the Intel Itanium processors support SSE either, though I'm not 100%
sure of that.
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] Recognition of Interval graphs, or matrices with "Consecutive one"... Where would this code fit ?
Hello everybody I have been willing for some time to implement a recognition algorithm for Interval Graphs [1], and I ended up forgetting to sleep one evening to have it done in the morning. :-) What I now have is an algorithm which uses PQ-Trees [2] and is able to tell, given a graph, whether it is an interval graph and if so, to enumerate all its possible embeddings. Equivalently, this problem can be seen the following way [3] : Given a binary Matrix, find whether there exists a way to reorder its columns so that each row has all its "ones" on an interval (no "1+0+1+" pattern). It can also, if needed, give all such representations. I could store this code in the graph/ folder, but it would be a pity to do so while it is (slightly) more general. I think it would be better to store it in some place dealing with matrices or binary vectors, but as I do not know these areas I a asking you this very question... Where would you see it fitting ? :-) (As it will probably be a long review, even though I did my best to comment the code, please tell me if you would be interested in giving it a look !) Thanks !! Nathann [1] http://en.wikipedia.org/wiki/Interval_graph [2] http://en.wikipedia.org/wiki/PQ_tree [3] http://www.ic.unicamp.br/~meidanis/research/pqr/ -- 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: ANSI C vs. C99
Hello, > Having checked again, __sparc is preferable. That is supported by gcc, g++, cc > and CC (the Sun compilers) Thanks a lot! > I've also got machines running AIX, tru64, HP-UX and IRIX. None of > the CPUs in those sorts of machines would support SSE. Clearly there > are many system which will never support SSE, though Solaris SPARC > is the most critical for Sage. Well, I am from x86 world and (currently) have no access to anything beyond 32/64-bit Intel CPUs. I'll move to optimizations specific to other ISA's when I'll get hands on machines with these CPU's :) But now I have to optimize at least for x86. > I doubt the Intel Itanium processors support SSE either, though I'm > not 100% sure of that. Itanium doesn't support SSE, you are right. -- With best regards, Sergey mailto:sergey.bochka...@alglib.net -- 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: Sage OSX Clickable App
Another option that I use is a simple clickable applescript/automator
task that opens a terminal, runs ./sage -notebook. I'm primarily
working on notebook development and making sure things work for the
server I use in my class, so don't directly use the command line. I
can make this little script available. I just need to know where to
put it. It runs which ever Sage is in the directory you put it in.
This has the advantage that the Sage directory structure is not
hidden.
Jonathan
On Jun 10, 1:53 am, "Georg S. Weber"
wrote:
> On 10 Jun., 02:37, Jason Grout wrote:
>
> > Karl-Dieter just showed me how to get the OSX App built using sage -bdist:
>
> > export SAGE_APP_BUNDLE=yes
> > sage -bdist 4.4.2-app
>
> > There are people I know that would *love* to have a clickable app on
> > OSX. Why do we not have this as a download option on the webpage?
>
> As far as I remember, there was no consensus reached as to *what
> exactly* should happen if you "just click" on some Sage App Icon. As
> of now, there are at least three different possibilities:
>
> a.) A "Sage shell" opens, i.e. a terminal that is already cd'ed to
> $SAGE_ROOT and "./sage -sh" is executed.
> b.) A "Sage interpreter" opens, i.e. a terminal that is already cd'ed
> to $SAGE_ROOT and "./sage" is executed.
> c.) A "Sage notebook" opens, i.e. a terminal that is already cd'ed to
> $SAGE_ROOT and "./sage -notebook" is executed.
>
> If one "exit"s, in all three cases any window etc. should be closed,
> so no "CTRL-C" the terminal after leaving the notebook etc. I'd really
> love to have some "true" Sage App" on OS X, i.e. having a status line
> that shows me which terminals are open, which notebook server(s) are
> running, and all this --- but that is a dream yet.
>
> BTW.: If one makes a duplicate of the "sage" script in $SAGE_ROOT and
> renames it to "sage.tool", then it *is* clickable under OS X without
> the fuzzing around described in the OS X Readme.txt. I was already
> thinking about a ticket adding three scripts "sage-shell.tool", "sage-
> interpreter.tool" and "sage-notebook.tool" on OS X, but didn't get
> around to do so. I mean, personally I mostly use the "Sage
> shell" ("Sash" ?!?) and then do "sage -br", "exit", edit, "sage -br"
> etc. If there were someone to somehow add buttons to do *that*, I'd
> appreciate it ... but nobody has volunteered yet to even think about a
> really graphical "user experience". Let alone some graphical
> "developer experience" for Sage; AFAIK, most sage-devel people seem to
> be rather fine to use emacs, vim, ... instead of the likes of Eclipse,
> XCode, VisualStudio, ... (just like me, I use plain jEdit for coding)
>
> Back to the "Sage App" ticket(s)/patch(es). One problem is, that there
> would be only one icon left on the desktop/in the program folder (like
> e.g. for Firefox), i.e. one has (at least in the current absence of a
> "full-scale" Sage App) to make a choice among a.), b.) c.) --- but
> then more or less one has to stick with that choice, because you can
> no longer (easily) browse the directory, or do some different of the
> three "with one click". Of course there is the possibility to always
> to "./sage -sh" and let implicitly make that choice by ".sagerc" in
> the users home dir --- but that is *very* Linuxish. And we wanted to
> enhance the OS X user experience!
> I don't really have made up my mind yet. But I'm happy to participate
> in a discussion!
>
> Cheers,
> Georg
>
>
>
> > 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 at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: matplotlib is reading old system headers, in preference to Sage ones.
On Thu, Jun 10, 2010 at 01:32:19PM +0100, Dr. David Kirkby wrote: > On 06/10/10 01:19 PM, Jason Grout wrote: >> I've posted the update to http://trac.sagemath.org/sage_trac/ticket/9202 >> >> Actually, I'm pretty sure I fixed the issue in this thread with the new >> spkg (see my other message in this thread for a discussion of what the >> issue is, or see the hg commit log in the new spkg). I also removed >> another solaris-specific patch that we apply, that I'm pretty sure is >> obsolete as of a year ago or so. >> >> Can you check the new spkg on Solaris and let us know if there are any >> problems? >> >> Thanks, >> >> Jason > > No, it has not fixed it. Leaving pkg-config working, matplotlib reports > version > > REQUIRED DEPENDENCIES > numpy: 1.3.0 > freetype2: 9.7.3 Are you really sure that using PKG_CONFIG_PATH doesn't fix that? i.e., if you have the file /export/home/drkirkby/32/sage-4.4.3/local/lib/pkgconfig/freetype2.pc, then $ export PKG_CONFIG_PATH=/export/home/drkirkby/32/sage-4.4.3/local/lib/pkgconfig $ pkg-config --modversion freetype2 should really return 9.16.3. If it doesn't, I think we should try to figure out why not, rather than add hack upon hack... In general I think it would make a lot of sense to set PKG_CONFIG_PATH in sage-env. In any case we could set it in the matplotlib spkg-install if that helps. -Willem Jan -- 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: Sage OSX Clickable App
On Jun 9, 2010, at 11:53 PM, Georg S. Weber wrote:
On 10 Jun., 02:37, Jason Grout wrote:
Karl-Dieter just showed me how to get the OSX App built using sage -
bdist:
export SAGE_APP_BUNDLE=yes
sage -bdist 4.4.2-app
There are people I know that would *love* to have a clickable app on
OSX. Why do we not have this as a download option on the webpage?
As far as I remember, there was no consensus reached as to *what
exactly* should happen if you "just click" on some Sage App Icon. As
of now, there are at least three different possibilities:
a.) A "Sage shell" opens, i.e. a terminal that is already cd'ed to
$SAGE_ROOT and "./sage -sh" is executed.
b.) A "Sage interpreter" opens, i.e. a terminal that is already cd'ed
to $SAGE_ROOT and "./sage" is executed.
c.) A "Sage notebook" opens, i.e. a terminal that is already cd'ed to
$SAGE_ROOT and "./sage -notebook" is executed.
I think for the vast majority of people wanting a double-clickable app
rather than the command line, (c) would be the way to go. The tricky
part is how to quit.
If one "exit"s, in all three cases any window etc. should be closed,
so no "CTRL-C" the terminal after leaving the notebook etc. I'd really
love to have some "true" Sage App" on OS X, i.e. having a status line
that shows me which terminals are open, which notebook server(s) are
running, and all this --- but that is a dream yet.
BTW.: If one makes a duplicate of the "sage" script in $SAGE_ROOT and
renames it to "sage.tool", then it *is* clickable under OS X without
the fuzzing around described in the OS X Readme.txt. I was already
thinking about a ticket adding three scripts "sage-shell.tool", "sage-
interpreter.tool" and "sage-notebook.tool" on OS X, but didn't get
around to do so. I mean, personally I mostly use the "Sage
shell" ("Sash" ?!?) and then do "sage -br", "exit", edit, "sage -br"
etc. If there were someone to somehow add buttons to do *that*, I'd
appreciate it ... but nobody has volunteered yet to even think about a
really graphical "user experience". Let alone some graphical
"developer experience" for Sage; AFAIK, most sage-devel people seem to
be rather fine to use emacs, vim, ... instead of the likes of Eclipse,
XCode, VisualStudio, ... (just like me, I use plain jEdit for coding)
Back to the "Sage App" ticket(s)/patch(es). One problem is, that there
would be only one icon left on the desktop/in the program folder (like
e.g. for Firefox), i.e. one has (at least in the current absence of a
"full-scale" Sage App) to make a choice among a.), b.) c.) --- but
then more or less one has to stick with that choice, because you can
no longer (easily) browse the directory, or do some different of the
three "with one click". Of course there is the possibility to always
to "./sage -sh" and let implicitly make that choice by ".sagerc" in
the users home dir --- but that is *very* Linuxish. And we wanted to
enhance the OS X user experience!
I don't really have made up my mind yet. But I'm happy to participate
in a discussion!
Cheers,
Georg
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 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: Sage OSX Clickable App
On Thu, Jun 10, 2010 at 8:07 AM, Robert Bradshaw
wrote:
> On Jun 9, 2010, at 11:53 PM, Georg S. Weber wrote:
>
>> On 10 Jun., 02:37, Jason Grout wrote:
>>>
>>> Karl-Dieter just showed me how to get the OSX App built using sage
>>> -bdist:
>>>
>>> export SAGE_APP_BUNDLE=yes
>>> sage -bdist 4.4.2-app
>>>
>>> There are people I know that would *love* to have a clickable app on
>>> OSX. Why do we not have this as a download option on the webpage?
>>
>> As far as I remember, there was no consensus reached as to *what
>> exactly* should happen if you "just click" on some Sage App Icon. As
>> of now, there are at least three different possibilities:
>>
>> a.) A "Sage shell" opens, i.e. a terminal that is already cd'ed to
>> $SAGE_ROOT and "./sage -sh" is executed.
>> b.) A "Sage interpreter" opens, i.e. a terminal that is already cd'ed
>> to $SAGE_ROOT and "./sage" is executed.
>> c.) A "Sage notebook" opens, i.e. a terminal that is already cd'ed to
>> $SAGE_ROOT and "./sage -notebook" is executed.
>
> I think for the vast majority of people wanting a double-clickable app
> rather than the command line, (c) would be the way to go. The tricky part is
> how to quit.
>
Many of us use OS X, so let's just assume we can program anything if
we want. What would be the best UI for Sage?
The first thing that pops into my mind is that Sage runs as some sort
of server, kind of like say DropBox or any of the many other programs
running with an icon in the bar at the top of the screen. So I
imagine that when one double clicks on the Sage icon,
(1) the default browser opens with the Sage notebook running,
(2) a small Sage icon appears in the bar at the top of the screen.
(3) When clicked, the Sage icon in the bar has at least two options:
- Sage Notebook (which just opens the browser to the
notebook server)
- Quit (which quits the Sage notebook server and makes
the icon vanish)
It could (but probably shouldn't) also have some slightly more advanced options:
- Log (pop up a Terminal window with "tail -f" on the
notebook server log)
- Kill all running Sage sessions
This is basically how I use the Sage notebook on my laptop anyways,
but with the bar/icon above replaced by a screen session.
Regarding (1), the notebook itself could be slightly modified to
provide a reminder to the user about how to control the notebook
server.
-- William
>> If one "exit"s, in all three cases any window etc. should be closed,
>> so no "CTRL-C" the terminal after leaving the notebook etc. I'd really
>> love to have some "true" Sage App" on OS X, i.e. having a status line
>> that shows me which terminals are open, which notebook server(s) are
>> running, and all this --- but that is a dream yet.
>>
>> BTW.: If one makes a duplicate of the "sage" script in $SAGE_ROOT and
>> renames it to "sage.tool", then it *is* clickable under OS X without
>> the fuzzing around described in the OS X Readme.txt. I was already
>> thinking about a ticket adding three scripts "sage-shell.tool", "sage-
>> interpreter.tool" and "sage-notebook.tool" on OS X, but didn't get
>> around to do so. I mean, personally I mostly use the "Sage
>> shell" ("Sash" ?!?) and then do "sage -br", "exit", edit, "sage -br"
>> etc. If there were someone to somehow add buttons to do *that*, I'd
>> appreciate it ... but nobody has volunteered yet to even think about a
>> really graphical "user experience". Let alone some graphical
>> "developer experience" for Sage; AFAIK, most sage-devel people seem to
>> be rather fine to use emacs, vim, ... instead of the likes of Eclipse,
>> XCode, VisualStudio, ... (just like me, I use plain jEdit for coding)
>>
>> Back to the "Sage App" ticket(s)/patch(es). One problem is, that there
>> would be only one icon left on the desktop/in the program folder (like
>> e.g. for Firefox), i.e. one has (at least in the current absence of a
>> "full-scale" Sage App) to make a choice among a.), b.) c.) --- but
>> then more or less one has to stick with that choice, because you can
>> no longer (easily) browse the directory, or do some different of the
>> three "with one click". Of course there is the possibility to always
>> to "./sage -sh" and let implicitly make that choice by ".sagerc" in
>> the users home dir --- but that is *very* Linuxish. And we wanted to
>> enhance the OS X user experience!
>> I don't really have made up my mind yet. But I'm happy to participate
>> in a discussion!
>>
>>
>> Cheers,
>> Georg
>>
>>>
>>> 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 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...@goo
[sage-devel] Design discussion / request for comment
Hi There,
I'd like to discuss a design question. Some time ago Adrien Boussicault and
myself started to write some experimental code for copy-on-write in
Sage/Python. The idea is now more or less dropped because performance gain was
not so good and the syntax was not very usable. It still remain that along the
way we had a design idea that I would like to submit here for comment:
The idea is inspired from the "prototype" design pattern (see [Pro], [GOF]).
I want to define subclasses of Element with the following behavior: Those
classes are intended to be used to model *mathematical* objects, which are by
essence immutable. However, in many occasions, one wants to construct the
data-structure encoding of a new mathematical object by small modifications of
the data structure encoding some already built object. This is a very common
stuff for example in matrices: For example: given a matrix M we want to
replace every non_zero position by 1
res = copy(M)
for pos in res._nonzero_positions_by_row():
res[pos] = 1
res.set_immutable()
However in many cases, for the resulting data-structure to correctly encode
the mathematical object, some structural invariants must hold (say for example
we want that the matrix is symmetric). One problem is that, in many cases,
during the modification process, there is no possibility but to break the
invariants. Here there is no way to keep the matrix symmetric during the
replacement by 1...
A typical example in combinatorics, in a list modeling a permutation of
\{1,\dots,n\}, the integers must be distinct. A very common operation is to
take a permutation to make a copy with some small modifications, like
exchanging two consecutive values in the list or cycling some values. Though
the result is clearly a permutations there's no way to avoid breaking the
permutations invariants at some point during the modifications.
So the idea is the following: to allows local breaking of invariant on a
locally mutable copy and to check that things are restored in a proper state
at the end. So I wrote a small class called ClonableElement and several
derived subclasses (clone is the standard name for the copy method in the
"prototype" design pattern):
A class C inheriting from ClonableElement must implement the following
two methods
- obj.__copy__() -- returns a fresh copy of obj
- obj.check() -- returns nothing, raise an exception if obj
doesn't satisfies the data structure invariants
Then, given an instance obj of C, the following sequences of
instructions ensures that the invariants of new_obj are properly
restored at the end
with obj.clone() as new_obj:
...
# lot of invariant breaking modifications on new_obj
...
# invariants are ensured to be fulfilled
The following equivalent sequence of instructions can be used if speed is
needed, in particular in Cython code (unfortunately, the handling of the with
instruction make some overhead)...
new_obj = obj.__copy__()
...
# lot of invariant breaking modifications on new_obj
...
new_obj.set_immutable()
new_obj.check()
# invariants are ensured to be fulfilled
I also took to chance to handle hashing... All the code is on #8702, together
with some performance tests... Also this is my first real life Cython code so
any help is welcome.
Thanks for any comment or suggestion.
Cheers,
Florent
[Pro] Prototype pattern http://en.wikipedia.org/wiki/Prototype_pattern
[GOF] Design Patterns: Elements of Reusable Object-Oriented
Software. E. Gamma; R. Helm; R. Johnson; J. Vlissides (1994).
Addison-Wesley. ISBN 0-201-63361-2.
--
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: matplotlib is reading old system headers, in preference to Sage ones.
On 06/10/10 04:06 PM, Willem Jan Palenstijn wrote: On Thu, Jun 10, 2010 at 01:32:19PM +0100, Dr. David Kirkby wrote: On 06/10/10 01:19 PM, Jason Grout wrote: I've posted the update to http://trac.sagemath.org/sage_trac/ticket/9202 Actually, I'm pretty sure I fixed the issue in this thread with the new spkg (see my other message in this thread for a discussion of what the issue is, or see the hg commit log in the new spkg). I also removed another solaris-specific patch that we apply, that I'm pretty sure is obsolete as of a year ago or so. Can you check the new spkg on Solaris and let us know if there are any problems? Thanks, Jason No, it has not fixed it. Leaving pkg-config working, matplotlib reports version REQUIRED DEPENDENCIES numpy: 1.3.0 freetype2: 9.7.3 Are you really sure that using PKG_CONFIG_PATH doesn't fix that? i.e., if you have the file /export/home/drkirkby/32/sage-4.4.3/local/lib/pkgconfig/freetype2.pc, then $ export PKG_CONFIG_PATH=/export/home/drkirkby/32/sage-4.4.3/local/lib/pkgconfig $ pkg-config --modversion freetype2 Yes, sorry, that is working. Not sure what I typed before, but that does work. rkir...@redstart:~$ grep Version /export/home/drkirkby/32/sage-4.4.3/local/lib/pkgconfig/freetype2.pc Version: 9.16.3 drkir...@redstart:~$ export PKG_CONFIG_PATH=/export/home/drkirkby/32/sage-4.4.3/local/lib/pkgconfig drkir...@redstart:~$ pkg-config --modversion freetype2 9.16.3 drkir...@redstart:~$ I could have swore I set that before! I apologise for the confusion. $ ./sage -f matplotlib-0.99.3 | grep freetype2: freetype2: 9.16.3 should really return 9.16.3. If it doesn't, I think we should try to figure out why not, rather than add hack upon hack... Sorry about that. In general I think it would make a lot of sense to set PKG_CONFIG_PATH in sage-env. In any case we could set it in the matplotlib spkg-install if that helps. It sounds to me that we should set it in sage-env, since there are several packages which get built in Sage whose .pc files reside in $SAGE_LOCAL/lib/pkgconfig. drkir...@redstart:~/32/sage-4.4.3$ ls local/lib/pkgconfig bdw-gc.pcgnutls.pclibpng12.pc pynac.pc freetype2.pc gsl.pc libR.pc sqlite3.pc gnutls-extra.pc libpng.pcopencdk.pc This could mean several packages are picking up the wrong versions of software, if they make use of pkgconfig Note however pkgconfig does not appear to be on OS X (or at least in the version of OS X on bsd.math). [kir...@bsd ~]$ uname -a Darwin bsd.local 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26 11:58:09 PST 2010; root:xnu-1504.3.12~1/RELEASE_I386 i386 i386 MacPro1,1 Darwin [kir...@bsd ~]$ pkgconfig -bash: pkgconfig: command not found though pkg-config exists on both Solaris (even my March 2005 release) and Linux systems. So what will happen on Linux? -Willem Jan Thank you for your help Willem 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: matplotlib is reading old system headers, in preference to Sage ones.
On 06/10/10 07:04 PM, Dr. David Kirkby wrote: Note however pkgconfig does not appear to be on OS X (or at least in the version of OS X on bsd.math). [kir...@bsd ~]$ uname -a Darwin bsd.local 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26 11:58:09 PST 2010; root:xnu-1504.3.12~1/RELEASE_I386 i386 i386 MacPro1,1 Darwin [kir...@bsd ~]$ pkgconfig -bash: pkgconfig: command not found though pkg-config exists on both Solaris (even my March 2005 release) and Linux systems. So what will happen on Linux? I mean what will happen on OS X? It seems there may need to be another way on OS X at least to determine how to link freetype and possibly all the other ten packages which create .pc files and put them in /export/home/drkirkby/32/sage-4.4.3/local/lib/pkgconfig Setting PKG_CONFIG_PATH may not be sufficient on OS X. 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: Error Bar plot
On Jun 10, 5:40 am, Marco Boretto wrote: > Hello to everybody, i'm try to use sage in my physics elaboration, > but i could not make plot point with an error bar for each point.. > there is the possibility to develop this function? > Marco Dear Marco, Thanks for trying Sage! This possibility certainly exists, but no one has done so yet 'natively'. However, it is pretty easy to get matplotlib, R or Scipy to do this, I believe, from within Sage. Your easiest bet for now is matplotlib, because you can just do import pyplot as plt or something like that and use examples on the matplotlib site fairly directly. R has really nice ones too, of course, since it's a statistics program :) and %r with usual R commands for such things in the notebook should 'just work', as long as you define a graphics viewer and then do dev.off(). Good luck, - kcrisman -- 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] Error compiling Python Image Library (pil-1.1.6.p2)...
I am building Sage from source as a user without root privileges. The machine on which I am building Sage has the following specifications: Red Hat Enterprise Linux Client release 5.2 (Tikanga) 4 X 1GHz Dual-Core AMD Opteron(tm) Processor 2220 32G RAM . In the "make" output, I'm seeing 68 instances of /usr/local/lib/libpython2.6.a: could not read symbols: Bad value . Shouldn't Sage ignore all pre-existing installs of Python? Despite the 68 "Bad value" messages, the only portion of Sage that does not successfully build is the Python Image Library (pil-1.1.6.p2). At least, I have good reason to believe that this is the only portion that fails to build, as the only test run by "make test" that fails does so because of the condition "ImportError: No module named Image": = BEGIN: Relevant "make test" output. = sage -t "devel/sage/sage/plot/plot3d/base.pyx" ** File "/home/txbruser/TxBR/sage-4.4.3/devel/sage/sage/plot/plot3d/ base.pyx", line 1160: sage: G.save(f) Exception raised: Traceback (most recent call last): File "/home/txbruser/TxBR/sage-4.4.3/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/home/txbruser/TxBR/sage-4.4.3/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/home/txbruser/TxBR/sage-4.4.3/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "", line 1, in G.save(f)###line 1160: sage: G.save(f) File "base.pyx", line 1197, in sage.plot.plot3d.base.Graphics3d.save (sage/plot/plot3d/base.c:11690) ImportError: No module named Image ** File "/home/txbruser/TxBR/sage-4.4.3/devel/sage/sage/plot/plot3d/ base.pyx", line 1165: sage: G.save(f, zoom=2, figsize=[5, 10]) Exception raised: Traceback (most recent call last): File "/home/txbruser/TxBR/sage-4.4.3/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/home/txbruser/TxBR/sage-4.4.3/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/home/txbruser/TxBR/sage-4.4.3/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "", line 1, in G.save(f, zoom=Integer(2), figsize=[Integer(5), Integer(10)])###line 1165: sage: G.save(f, zoom=2, figsize=[5, 10]) File "base.pyx", line 1197, in sage.plot.plot3d.base.Graphics3d.save (sage/plot/plot3d/base.c:11690) ImportError: No module named Image ** File "/home/txbruser/TxBR/sage-4.4.3/devel/sage/sage/plot/plot3d/ base.pyx", line 1170: sage: G.save(f, viewer='jmol') # Looks the same Exception raised: Traceback (most recent call last): File "/home/txbruser/TxBR/sage-4.4.3/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/home/txbruser/TxBR/sage-4.4.3/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/home/txbruser/TxBR/sage-4.4.3/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "", line 1, in G.save(f, viewer='jmol') # Looks the same###line 1170: sage: G.save(f, viewer='jmol') # Looks the same File "base.pyx", line 1197, in sage.plot.plot3d.base.Graphics3d.save (sage/plot/plot3d/base.c:11690) ImportError: No module named Image ** File "/home/txbruser/TxBR/sage-4.4.3/devel/sage/sage/plot/plot3d/ base.pyx", line 1175: sage: cube().save(tmp_filename() + '.gif') Exception raised: Traceback (most recent call last): File "/home/txbruser/TxBR/sage-4.4.3/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/home/txbruser/TxBR/sage-4.4.3/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/home/txbruser/TxBR/sage-4.4.3/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "", line 1, in cube().save(tmp_filename() + '.gif')###line 1175: sage: cube().save(tmp_filename() + '.gif') File "base.pyx", line 1197, in sage.plot.plot3d.base.Graphics3d.save (sage/plot/plot3d/base.c:11690) ImportError: No module named Image *
Re: [sage-devel] pushing towards 90% doctest coverage for Sage 5.0
On Thu, Jun 10, 2010 at 2:21 PM, Dr. David Kirkby wrote: > On 06/10/10 09:25 PM, Minh Nguyen wrote: >> >> Hi folks, >> >> One of the main goals of the upcoming Sage 5.0 release is to get >> doctest coverage of the Sage library up to at least 90%. As of Sage >> 4.4.4.alpha0, the overall weighted coverage is 82.7%. > > Seems we are a long way off. > > It seems to me, rather than pick a number like 90%, the areas should be > targeted carefully. The goal for Sage-5.0 is 90% coverage. And we should aim for 100% by the end of the year. -- 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
[sage-devel] Re: Error Bar plot
Here's a simple example, it might be tweakable to get want you want: def stdplot(somedata): means = [N(mean(row)) for row in somedata] stds = [N(std(row)) for row in somedata] outplot = Graphics() for i in range(len(means)): outplot += point([i,means[i]]) outplot += line([[i,means[i]-stds[i]],[i,means[i]+stds[i]]]) outplot += line([[i-.4,means[i]-stds[i]],[i+.4,means[i]- stds[i]]]) outplot += line([[i-.4,means[i]+stds[i]],[i+.4,means[i] +stds[i]]]) return outplot rdata = [[j + j*random()/2 for i in range(10)] for j in range(20)] stdplot(rdata) -Marshall Hampton On Jun 10, 4:40 am, Marco Boretto wrote: > Hello to everybody, i'm try to use sage in my physics elaboration, > but i could not make plot point with an error bar for each point.. > there is the possibility to develop this function? > Marco -- 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: matplotlib is reading old system headers, in preference to Sage ones.
On 10 Jun., 20:04, "Dr. David Kirkby" wrote: > Note however pkgconfig does not appear to be on OS X (or at least in the > version > of OS X on bsd.math). > > [kir...@bsd ~]$ uname -a > Darwin bsd.local 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26 11:58:09 PST > 2010; root:xnu-1504.3.12~1/RELEASE_I386 i386 i386 MacPro1,1 Darwin > [kir...@bsd ~]$ pkgconfig > -bash: pkgconfig: command not found > > though pkg-config exists on both Solaris (even my March 2005 release) and > Linux > systems. Ooops? pkg-config vs. pkgconfig? ;-) -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] pushing towards 90% doctest coverage for Sage 5.0
On 06/10/10 09:25 PM, Minh Nguyen wrote: Hi folks, One of the main goals of the upcoming Sage 5.0 release is to get doctest coverage of the Sage library up to at least 90%. As of Sage 4.4.4.alpha0, the overall weighted coverage is 82.7%. Seems we are a long way off. It seems to me, rather than pick a number like 90%, the areas should be targeted carefully. To get a sense of which modules in the Sage library need work on their coverage scores, you could use the coverage script as follows: $ ./sage -coverage /path/to/module.py[x] Or you could do the following to get the coverage scores of all modules, including a coverage summary: $ ./sage -coverageall You might be interested in knowing which modules have a certain coverage percentage, in which case you could save the output of -coverageall to a text file and then grep that file for certain coverage scores. At this repository [1] is a script to generate various types of coverage analysis reports. You can also find the script at [3]. The script currently supports the following reports * The coverage summary of all modules. * Modules with 100% coverage. * Modules with zero coverage. I don't really understand these docs tests well, but to me at least, concentrating on modules which have zero coverage would seem best, even if only one doctest/module is added. My logic being something could be totally broken, and we would never know about it. At least if there is even one doctest, it shows it is not totally broken. (Though one could argue being totally broken is better than being partially broken. At least one finds out in use.) It was recently discovered that certain modules (matrix, class, mgcv, nnet, rpart, spatial, and survival) in R are not building on Solaris. http://trac.sagemath.org/sage_trac/ticket/9201 Had there been even one doctest for each module, this would have been obvious. There is an interesting information about the SQlite database (incluced in Sage) is tested. The number of lines of test code is 679 times that of the actual source code of the project. The number of lines of test code is 45.7 million, the number of lines of source code in the database is 67000! (Both exclude comments and blank lines) http://www.sqlite.org/testing.html I think their test procedures are a bit over the top, but it certainly brings in to perspective how some developers feel about testing. If what is written at http://reference.wolfram.com/mathematica/tutorial/TestingAndVerification.html about testing Mathematica is true, then the following statement is intesting "There is also a special instrumented version of Mathematica which is set up to perform internal consistency tests. This version of Mathematica runs at a small fraction of the speed of the real Mathematica, but at every step it checks internal memory consistency, interruptibility, and so on" I must admit, reading that Wolfram Research page, the statement that "The standards of correctness for Mathematica are certainly much higher than for typical mathematical proofs" is extremely stupid, when they don't define "typical" and they provide no evidence of it. (It was not me he spotted that, but it is extremely dumb thing to write) Of course we can't verify the claims made by Wolfram Reserach, but we can verify what the SQlite developers say, that the number of lines of test code is 679 x the amount of actual code in the database. Even I would refuse to write 679 lines of test code for every line of code I wrote! But really the specification, implementation and testing should be done by different people. In practice, that is not going to happen in Sage, though I would not be surprised if that happens with Mathematica, since it is pretty standard technique in software engineering. 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] pushing towards 90% doctest coverage for Sage 5.0
On 06/10/10 10:27 PM, William Stein wrote: On Thu, Jun 10, 2010 at 2:21 PM, Dr. David Kirkby wrote: On 06/10/10 09:25 PM, Minh Nguyen wrote: Hi folks, One of the main goals of the upcoming Sage 5.0 release is to get doctest coverage of the Sage library up to at least 90%. As of Sage 4.4.4.alpha0, the overall weighted coverage is 82.7%. Seems we are a long way off. It seems to me, rather than pick a number like 90%, the areas should be targeted carefully. The goal for Sage-5.0 is 90% coverage. And we should aim for 100% by the end of the year. -- William Consider two areas # interfaces/tachyon.py: 0% (0 of 4) # graphs/generic_graph.py: 99% (200 of 201) Where would it be most useful to add one doc test? At least from my very little understanding of this, Having 89% coverage would be better than 90% coverage, if those 89% were well targeted. 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: matplotlib is reading old system headers, in preference to Sage ones.
On 06/10/10 08:43 PM, leif wrote: On 10 Jun., 20:04, "Dr. David Kirkby" wrote: Note however pkgconfig does not appear to be on OS X (or at least in the version of OS X on bsd.math). [kir...@bsd ~]$ uname -a Darwin bsd.local 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26 11:58:09 PST 2010; root:xnu-1504.3.12~1/RELEASE_I386 i386 i386 MacPro1,1 Darwin [kir...@bsd ~]$ pkgconfig -bash: pkgconfig: command not found though pkg-config exists on both Solaris (even my March 2005 release) and Linux systems. Ooops? pkg-config vs. pkgconfig? ;-) -Leif Above was a typo, but it does not change the fact OS X lacks this [kir...@bsd ~]$ pkg-config -bash: pkg-config: command not found or if it does exist, it is not in my path, and not at the most obvious place [kir...@bsd ~]$ /usr/bin/pkg-config -bash: /usr/bin/pkg-config: No such file or directory -- 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] pushing towards 90% doctest coverage for Sage 5.0
Hi folks, One of the main goals of the upcoming Sage 5.0 release is to get doctest coverage of the Sage library up to at least 90%. As of Sage 4.4.4.alpha0, the overall weighted coverage is 82.7%. To get a sense of which modules in the Sage library need work on their coverage scores, you could use the coverage script as follows: $ ./sage -coverage /path/to/module.py[x] Or you could do the following to get the coverage scores of all modules, including a coverage summary: $ ./sage -coverageall You might be interested in knowing which modules have a certain coverage percentage, in which case you could save the output of -coverageall to a text file and then grep that file for certain coverage scores. At this repository [1] is a script to generate various types of coverage analysis reports. You can also find the script at [3]. The script currently supports the following reports * The coverage summary of all modules. * Modules with 100% coverage. * Modules with zero coverage. * Modules with between 1% and 9% coverage. * Modules with between 10% and 19% coverage. * Modules with between 20% and 29% coverage. * Modules with between 30% and 39% coverage. * Modules with between 40% and 49% coverage. * Modules with between 50% and 59% coverage. * Modules with between 60% and 69% coverage. * Modules with between 70% and 79% coverage. * Modules with between 80% and 89% coverage. * Modules with between 90% and 99% coverage. Each report has links to detailed reports for individual modules. To run the script, copy it to the SAGE_ROOT of a Sage source or binary installation and do [mv...@sage sage-4.4.4.alpha0]$ ./coverage-status.py Coverage report of all modules... Summary of doctest coverage... Modules with 0% coverage... Modules with 100% coverage... Coverage reports within certain ranges... Detailed coverage report for all modules... Format the detailed coverage reports... Format the summary reports... Generate index.html... And you're done. Here [2] is a report generated by the script. The idea is to provide an overview of which modules need work. I'd be interested to know what other types of doctest coverage reports people would like to see. Comments, suggestions, critiques, etc. are welcome. [1] http://bitbucket.org/mvngu/coverage [2] http://sage.math.washington.edu/home/mvngu/doctest-coverage/ [3] http://sage.math.washington.edu/home/mvngu/apps/coverage/ -- 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: pushing towards 90% doctest coverage for Sage 5.0
Hi David, On 11 Jun., 00:32, "Dr. David Kirkby" wrote: > At least from my very little understanding of this, Having 89% coverage would > be > better than 90% coverage, if those 89% were well targeted. It is not clear to me why one module should be considered being more important than another. I would not support if you suggest targeting the effort by the *topic* of the modules being doc tested. Arguing like "many people do calculus and graphics, so, concentrate on this" will only lead to a meta-discussion. Or do you just say that adding a single doc test to a module with 0% coverage will have a better impact than adding a single test for a module with 70% coverage? This might indeed be a good way to find a starting point. Anyway, I am +1 to trying and getting a 90% overall doc test coverage; it is a valuable aim. IMO it is *always* worth it to write doc tests since it is very likely to uncover flaws (in particular if the person who writes the test is not the same as the one who wrote the code). My 0.02€ Simon -- 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] Error compiling Python Image Library (pil-1.1.6.p2)...
On 06/10/10 11:59 PM, akuloncmir wrote: I am building Sage from source as a user without root privileges. The machine on which I am building Sage has the following specifications: Red Hat Enterprise Linux Client release 5.2 (Tikanga) 4 X 1GHz Dual-Core AMD Opteron(tm) Processor 2220 32G RAM . In the "make" output, I'm seeing 68 instances of /usr/local/lib/libpython2.6.a: could not read symbols: Bad value . Shouldn't Sage ignore all pre-existing installs of Python? Yes, it should, but it does not. I mentioned this on sage-solaris the other day, though of course very few people read that, so nobody replied http://groups.google.com/group/sage-solaris/browse_thread/thread/5dcc7ed68d279f67?hl=en (In fact, I've yet to have a single reply to anything I've posted no sage-solaris!) In my case, matplotlib failed to build. The "solution" (which is not a solution), was to run as root: # chmod 000 /usr/local/lib/libpython2.6.a /usr/local/lib/python2.6 so the install in /usr/local could not be found. Thanks, Alex This is now http://trac.sagemath.org/sage_trac/ticket/9209 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] pushing towards 90% doctest coverage for Sage 5.0
Hi Minh, > And you're done. Here [2] is a report generated by the script. The > idea is to provide an overview of which modules need work. I'd be > interested to know what other types of doctest coverage reports people > would like to see. Comments, suggestions, critiques, etc. are welcome. This reports definitely looks like a good idea ! However, I tried to pick-up some random files in the lists: sage/monoids/monoid.py sage/structure/element_py.py sage/structure/element_verify.py sage/misc/typecheck.py They all looks like they should be deprecated and removed... If it's true I rather improving the doctest coverage by removing them than adding doctests... However I'd like to have the confirmation that they are indeed obsolete... This remark also hold for the following typecheck function in sage/misc/misc.py # # Type checking # def typecheck(x, C, var="x"): """ Check that x is of instance C. If not raise a TypeError with an error message. """ if not isinstance(x, C): raise TypeError, "%s (=%s) must be of type %s."%(var,x,C) Cheers, Florent -- 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: pushing towards 90% doctest coverage for Sage 5.0
On 06/11/10 12:38 AM, Simon King wrote:
Hi David,
On 11 Jun., 00:32, "Dr. David Kirkby" wrote:
At least from my very little understanding of this, Having 89% coverage would be
better than 90% coverage, if those 89% were well targeted.
It is not clear to me why one module should be considered being more
important than another. I would not support if you suggest targeting
the effort by the *topic* of the modules being doc tested. Arguing
like "many people do calculus and graphics, so, concentrate on this"
will only lead to a meta-discussion.
I would not say there is no logic to that, but it was not what I was suggesting.
Or do you just say that adding a single doc test to a module with 0%
coverage will have a better impact than adding a single test for a
module with 70% coverage? This might indeed be a good way to find a
starting point.
That was exactly what I meant. In the case of the interface to tachyon, it would
appear there is absolutely no testing of this whatsoever
# interfaces/tachyon.py: 0% (0 of 4)
so adding just one test would be useful. It would at least show the interface is
not completely broken.
In contrast, getting graphs/generic_graph.py up to 100%, by adding one test when
there are already 200, would seem less useful to me.
# graphs/generic_graph.py: 99% (200 of 201)
So I would suggest that doctests are targeted, rather than randomly chosen. (The
obvious way to get the coverage up quickly is to write simple tests.)
Anyway, I am +1 to trying and getting a 90% overall doc test coverage;
it is a valuable aim.
Yes, but IMHO, it is a bit of a simplistic metric.
I personally do not feel Sage is sufficiently tested, and I doubt my opinion
will change if the doctest coverage is increased to 100%.
IMO it is *always* worth it to write doc tests since it is very likely
to uncover flaws (in particular if the person who writes the test is
not the same as the one who wrote the code).
Really, that should be the case.
http://www.sqlite.org/testing.html
is worth a read. Particularly section 7.1 about how there are various ways of
defining test coverage. (I stuck section 7.1 below my name). What is clear is
that the method of calculating coverage in Sage is even weaker than what that
sqlite document consider to be a weak method (statement coverage). We don't even
ensure that every statement of code gets executed at least once.
Dave
Section 7.1 from http://www.sqlite.org/testing.html
=
There are many ways to measure test coverage. The most popular metric is
"statement coverage". When you hear someone say that their program as "XX% test
coverage" without further explanation, they usually mean statement coverage.
Statement coverage measures what percentage of lines of code are executed at
least once by the test suite.
Branch coverage is more rigorous than statement coverage. Branch coverage
measure the number of machine-code branch instructions that are evaluated at
least once on both directions.
To illustrate the difference between statement coverage and branch coverage,
consider the following hypothetical line of C code:
if( a>b && c!=25 ){ d++; }
Such a line of C code might generate a dozen separate machine code instructions.
If any one of those instructions is ever evaluated, then we say that the
statement has been tested. So, for example, it might be the case that the
conditional expression is always false and the "d" variable is never
incremented. Even so, statement coverage counts this line of code as having been
tested.
Branch coverage is more strict. With branch coverage, each test and each
subblock within the statement is considered separately. In order to achieve 100%
branch coverage in the example above, there must be at least three test cases:
* a<=b
* a>b && c==25
* a>b && c!=25
Any one of the above test cases would provide 100% statement coverage but all
three are required for 100% branch coverage. Generally speaking, 100% branch
coverage implies 100% statement coverage, but the converse is not true. To
reemphasize, the TH3 test harness for SQLite provides the stronger form of test
coverage - 100% branch test coverage.
My 0.02€
Simon
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: pushing towards 90% doctest coverage for Sage 5.0
> That was exactly what I meant. In the case of the interface to tachyon, it > would > appear there is absolutely no testing of this whatsoever > > # interfaces/tachyon.py: 0% (0 of 4) Though there is some testing of it in the plot files. The point is good, just not for that example. > In contrast, getting graphs/generic_graph.py up to 100%, by adding one test > when > there are already 200, would seem less useful to me. > > # graphs/generic_graph.py: 99% (200 of 201) > > So I would suggest that doctests are targeted, rather than randomly chosen. > (The > obvious way to get the coverage up quickly is to write simple tests.) But we do want doctests to test a fairly large number of the options, so just adding doctest coverage isn't enough. The doctests need to really test, as you say. Getting in more of the framework tests in (which I don't quite understand) will help, as would real randomization (which has been often discussed but perhaps is hard to implement?). Florent's point is also very good. There are a number of files which are no longer needed (e.g., axes.py) which are nearly undoctested. - kcrisman -- 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: Sage OSX Clickable App
> > There are people I know that would *love* to have a clickable app on > > OSX. Why do we not have this as a download option on the webpage? > > As far as I remember, there was no consensus reached as to *what > exactly* should happen if you "just click" on some Sage App Icon. As Correct. > of now, there are at least three different possibilities: > > a.) A "Sage shell" opens, i.e. a terminal that is already cd'ed to > $SAGE_ROOT and "./sage -sh" is executed. > b.) A "Sage interpreter" opens, i.e. a terminal that is already cd'ed > to $SAGE_ROOT and "./sage" is executed. > c.) A "Sage notebook" opens, i.e. a terminal that is already cd'ed to > $SAGE_ROOT and "./sage -notebook" is executed. > > If one "exit"s, in all three cases any window etc. should be closed, > so no "CTRL-C" the terminal after leaving the notebook etc. I'd really > love to have some "true" Sage App" on OS X, i.e. having a status line > that shows me which terminals are open, which notebook server(s) are > running, and all this --- but that is a dream yet. > Yes. If anyone knows someone who can actually use InterfaceBuilder or whatever, it would be great to recruit them :) I know that we're even a little uneasy with the current Platypus-supplied binary piece. (Though I believe we can use Platypus to ask for some things, such as double-clickable .sws files.) > Back to the "Sage App" ticket(s)/patch(es). One problem is, that there > would be only one icon left on the desktop/in the program folder (like > e.g. for Firefox), i.e. one has (at least in the current absence of a > "full-scale" Sage App) to make a choice among a.), b.) c.) --- but > then more or less one has to stick with that choice, because you can > no longer (easily) browse the directory, or do some different of the > three "with one click". Of course there is the possibility to always > to "./sage -sh" and let implicitly make that choice by ".sagerc" in > the users home dir --- but that is *very* Linuxish. And we wanted to > enhance the OS X user experience! It must be possible for there to be an opening window that asks to choose among a,b,c and then to be able to set that in Preferences -> etc. But I don't know how to do that :( - kcrisman -- 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] moving Sage directories
There seem to be a lot of loose ends left hanging when a sage directory
is moved. For example, I usually compile Sage on a ramdisk, and then
move it to my home directory. Here is a list of places where the
ramdisk path still appears in the $SAGE_ROOT/local/bin directory:
gr...@tiny:~/sage/local/bin% grep -ri "/Volumes/ramdisk" *
Binary file ESingular matches
Binary file LLL matches
Binary file QuadraticSieve matches
R:R_HOME_DIR=/Volumes/ramdisk/sage-4.4.2/local/lib/R
R:if test "${R_HOME_DIR}" = "/Volumes/ramdisk/sage-4.4.2/local/lib/R"; then
R: if [ -x "/Volumes/ramdisk/sage-4.4.2/local/${libnn}/R/bin/exec/R"
]; then
R:R_HOME_DIR="/Volumes/ramdisk/sage-4.4.2/local/${libnn}/R"
R: elif [ -x
"/Volumes/ramdisk/sage-4.4.2/local/${libnn_fallback}/R/bin/exec/R" ]; then
R:R_HOME_DIR="/Volumes/ramdisk/sage-4.4.2/local/${libnn_fallback}/R"
R:R_SHARE_DIR=/Volumes/ramdisk/sage-4.4.2/local/lib/R/share
R:R_INCLUDE_DIR=/Volumes/ramdisk/sage-4.4.2/local/lib/R/include
R:R_DOC_DIR=/Volumes/ramdisk/sage-4.4.2/local/lib/R/doc
Binary file Rscript matches
Binary file Singular-3-1-0 matches
Binary file TSingular matches
Binary file adjacency matches
Binary file adjacency_gmp matches
Binary file allfaces matches
Binary file allfaces_gmp matches
Binary file allisog matches
Binary file annotate matches
Binary file cdd_both_reps matches
Binary file cdd_both_reps_gmp matches
Binary file certtool matches
Binary file change_cost matches
Binary file class.x matches
Binary file conductor matches
Binary file cu2 matches
Binary file cubex matches
Binary file cws.x matches
Binary file dumpsexp matches
Binary file ecl matches
ecl-config: echo "-Ddarwin @DEBUG_CFLAGS@
-I/Volumes/ramdisk/sage-4.4.2/local/include/"
ecl-config: echo "@LDRPATH@ -L/Volumes/ramdisk/sage-4.4.2/local/lib/
$LDFLAGS -L/Volumes/ramdisk/sage-4.4.2/local/lib -lffi-lm "
Binary file ecm matches
Binary file findinf matches
Binary file fourier matches
Binary file fourier_gmp matches
Binary file fplll matches
Binary file fplll_micro matches
Binary file fplll_verbose matches
freetype-config:prefix=/Volumes/ramdisk/sage-4.4.2/local
freetype-config:major=`grep define
/Volumes/ramdisk/sage-4.4.2/local/include/freetype2/freetype/freetype.h \
freetype-config:minor=`grep define
/Volumes/ramdisk/sage-4.4.2/local/include/freetype2/freetype/freetype.h \
freetype-config:patch=`grep define
/Volumes/ramdisk/sage-4.4.2/local/include/freetype2/freetype/freetype.h \
Binary file gd2copypal matches
Binary file gd2togif matches
Binary file gd2topng matches
Binary file gdcmpgif matches
gdlib-config:prefix=/Volumes/ramdisk/sage-4.4.2/local
gdlib-config: echo -L/Volumes/ramdisk/sage-4.4.2/local/lib
-L/Volumes/ramdisk/sage-4.4.2/local/lib
gdlib-config: echo "ldflags: -L/Volumes/ramdisk/sage-4.4.2/local/lib
-L/Volumes/ramdisk/sage-4.4.2/local/lib "
Binary file gdparttopng matches
Binary file gdtopng matches
Binary file gen_test matches
Binary file generate matches
Binary file genus2reduction matches
Binary file gfan matches
Binary file gfan_buchberger matches
Binary file gfan_doesidealcontain matches
Binary file gfan_fancommonrefinement matches
Binary file gfan_fanlink matches
Binary file gfan_fanproduct matches
Binary file gfan_groebnercone matches
Binary file gfan_homogeneityspace matches
Binary file gfan_homogenize matches
Binary file gfan_initialforms matches
Binary file gfan_interactive matches
Binary file gfan_ismarkedgroebnerbasis matches
Binary file gfan_krulldimension matches
Binary file gfan_latticeideal matches
Binary file gfan_leadingterms matches
Binary file gfan_markpolynomialset matches
Binary file gfan_minkowskisum matches
Binary file gfan_minors matches
Binary file gfan_polynomialsetunion matches
Binary file gfan_render matches
Binary file gfan_renderstaircase matches
Binary file gfan_saturation matches
Binary file gfan_secondaryfan matches
Binary file gfan_stats matches
Binary file gfan_substitute matches
Binary file gfan_tolatex matches
Binary file gfan_topolyhedralfan matches
Binary file gfan_tropicalbasis matches
Binary file gfan_tropicalbruteforce matches
Binary file gfan_tropicalevaluation matches
Binary file gfan_tropicalfunction matches
Binary file gfan_tropicalhypersurface matches
Binary file gfan_tropicalintersection matches
Binary file gfan_tropicallifting matches
Binary file gfan_tropicallinearspace matches
Binary file gfan_tropicalmultiplicity matches
Binary file gfan_tropicalrank matches
Binary file gfan_tropicalstartingcone matches
Binary file gfan_tropicaltraverse matches
Binary file gfan_tropicalweildivisor matches
ghmm-config:prefix=/Volumes/ramdisk/sage-4.4.2/local
Binary file giftogd2 matches
givaro-config:prefix=/Volumes/ramdisk/sage-4.4.2/local
givaro-config: echo -I${includedir}
-I/Volumes/ramdisk/sage-4.4.2/local//include
givaro-config: echo -L${libdir} -lgivaro
-L/Volumes/ramdisk/sage-4.4.2/local//lib -lgmp
givaro-makefile:prefix=/Volumes/ramdisk/sage-4.4.2/local
givaro-
Re: [sage-devel] pushing towards 90% doctest coverage for Sage 5.0
Minh, Can you make a report which lists the files which, if brought up to 100% coverage, would benefit overall coverage the most? On Thu, Jun 10, 2010 at 1:25 PM, Minh Nguyen wrote: > Hi folks, > > One of the main goals of the upcoming Sage 5.0 release is to get > doctest coverage of the Sage library up to at least 90%. As of Sage > 4.4.4.alpha0, the overall weighted coverage is 82.7%. To get a sense > of which modules in the Sage library need work on their coverage > scores, you could use the coverage script as follows: > > $ ./sage -coverage /path/to/module.py[x] > > Or you could do the following to get the coverage scores of all > modules, including a coverage summary: > > $ ./sage -coverageall > > You might be interested in knowing which modules have a certain > coverage percentage, in which case you could save the output of > -coverageall to a text file and then grep that file for certain > coverage scores. At this repository [1] is a script to generate > various types of coverage analysis reports. You can also find the > script at [3]. The script currently supports the following reports > > * The coverage summary of all modules. > > * Modules with 100% coverage. > > * Modules with zero coverage. > > * Modules with between 1% and 9% coverage. > > * Modules with between 10% and 19% coverage. > > * Modules with between 20% and 29% coverage. > > * Modules with between 30% and 39% coverage. > > * Modules with between 40% and 49% coverage. > > * Modules with between 50% and 59% coverage. > > * Modules with between 60% and 69% coverage. > > * Modules with between 70% and 79% coverage. > > * Modules with between 80% and 89% coverage. > > * Modules with between 90% and 99% coverage. > > Each report has links to detailed reports for individual modules. To > run the script, copy it to the SAGE_ROOT of a Sage source or binary > installation and do > > [mv...@sage sage-4.4.4.alpha0]$ ./coverage-status.py > Coverage report of all modules... > Summary of doctest coverage... > Modules with 0% coverage... > Modules with 100% coverage... > Coverage reports within certain ranges... > Detailed coverage report for all modules... > Format the detailed coverage reports... > Format the summary reports... > Generate index.html... > > And you're done. Here [2] is a report generated by the script. The > idea is to provide an overview of which modules need work. I'd be > interested to know what other types of doctest coverage reports people > would like to see. Comments, suggestions, critiques, etc. are welcome. > > > [1] http://bitbucket.org/mvngu/coverage > > [2] http://sage.math.washington.edu/home/mvngu/doctest-coverage/ > > [3] http://sage.math.washington.edu/home/mvngu/apps/coverage/ > > -- > 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 > -- Robert L. Miller http://www.rlmiller.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: Design discussion / request for comment
On 6/10/10 12:25 PM, Florent Hivert wrote: Hi There, I'd like to discuss a design question. Some time ago Adrien Boussicault and myself started to write some experimental code for copy-on-write in Sage/Python. The idea is now more or less dropped because performance gain was not so good and the syntax was not very usable. Rob and I were just talking yesterday how it's so inconvenient that identity_matrix() now returns an immutable matrix, so constructing something from it involves making a copy, which is not the most obvious thing to a new person, or the most elegant thing to someone that has been using matrices for a while now. It would be fantastic if immutable matrices had copy-on-write semantics, not necessarily for performance, but just for usability after some of the recent design decisions (which I guess were made for performance reasons). I like the ideas you've described in the rest of the message, so +1 on the prototype ideas too! 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 at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: matplotlib is reading old system headers, in preference to Sage ones.
On 6/10/10 1:29 PM, Dr. David Kirkby wrote: On 06/10/10 07:04 PM, Dr. David Kirkby wrote: Note however pkgconfig does not appear to be on OS X (or at least in the version of OS X on bsd.math). [kir...@bsd ~]$ uname -a Darwin bsd.local 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26 11:58:09 PST 2010; root:xnu-1504.3.12~1/RELEASE_I386 i386 i386 MacPro1,1 Darwin [kir...@bsd ~]$ pkgconfig -bash: pkgconfig: command not found though pkg-config exists on both Solaris (even my March 2005 release) and Linux systems. So what will happen on Linux? I mean what will happen on OS X? I have pkg-config installed automatically via MacPorts, so at least some OSX systems will have the program. In the case of matplotlib, it looks like it has a fallback (which is taken care of in the patches in the update spkg) 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 at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Error compiling Python Image Library (pil-1.1.6.p2)...
On 6/10/10 6:46 PM, Dr. David Kirkby wrote: Yes, it should, but it does not. I mentioned this on sage-solaris the other day, though of course very few people read that, so nobody replied http://groups.google.com/group/sage-solaris/browse_thread/thread/5dcc7ed68d279f67?hl=en (In fact, I've yet to have a single reply to anything I've posted no sage-solaris!) The archives link you give above shows lots of instances of people replying to your posts. I was just looking at the matplotlib dependency system today, so I'd be interested in taking a look at the issue you raised to see if it's easy to fix. Who is the admin to sage-solaris, so I can ask them to add my email address? Can we add sage-solaris to gmane (see http://gmane.org/subscribe.php)? 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 at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Sage OSX Clickable App
On 6/10/10 11:08 AM, William Stein wrote: Many of us use OS X, so let's just assume we can program anything if we want. What would be the best UI for Sage? The first thing that pops into my mind is that Sage runs as some sort of server, kind of like say DropBox or any of the many other programs running with an icon in the bar at the top of the screen. So I imagine that when one double clicks on the Sage icon, (1) the default browser opens with the Sage notebook running, (2) a small Sage icon appears in the bar at the top of the screen. (3) When clicked, the Sage icon in the bar has at least two options: - Sage Notebook (which just opens the browser to the notebook server) - Quit (which quits the Sage notebook server and makes the icon vanish) It could (but probably shouldn't) also have some slightly more advanced options: - Log (pop up a Terminal window with "tail -f" on the notebook server log) - Kill all running Sage sessions It would be great to also have some sort of Preferences box that allows one to switch to automatically starting a Terminal Sage session instead of a notebook session. Possibly also an option to start a new Terminal Sage session, even if the notebook is also running. 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 at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
On 6/10/10 7:20 PM, Dr. David Kirkby wrote: We don't even ensure that every statement of code gets executed at least once. Mike Hansen posted some code to use a tool to check that (a long time ago). I imagine that after doctest coverage is up to 100% function coverage that there will be a new push to then get the statement coverage up to 100%. It would be interesting even now to see how much statement coverage lagged behind function coverage. 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 at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
On Jun 10, 9:41 pm, Jason Grout wrote: > I imagine that after doctest coverage is up to 100% function > coverage that there will be a new push to then get the statement > coverage up to 100%. It would be interesting even now to see how much > statement coverage lagged behind function coverage. Where should such tests go? I am not sure that it is desirable to show 50 sophisticated examples for a single function in the interactive or compiled help. On the other hand, I really like when all the tests are right next to the body of the function. Is it possible to, say, have "EXAMPLES" and "TESTS" sections in the docstring and avoid showing "TESTS" by default? For the Sphynx documentation it would be nice to have a way to either "expand" this section on demand or have a link to the file with tests, in case someone really wants to see them... Thank you, Andrey -- 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: pushing towards 90% doctest coverage for Sage 5.0
On Jun 10, 9:47 pm, Andrey Novoseltsev wrote: > On Jun 10, 9:41 pm, Jason Grout wrote: > > > I imagine that after doctest coverage is up to 100% function > > coverage that there will be a new push to then get the statement > > coverage up to 100%. It would be interesting even now to see how much > > statement coverage lagged behind function coverage. > > Where should such tests go? They can go in separate files, files which, for example, are not included in the reference manual. The file sage/homology/tests.py is an example. Each function should have doctests (so the goal is still 100% coverage), but it's not a big deal to relegate lots of technical test to less visible places. -- John -- 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: pushing towards 90% doctest coverage for Sage 5.0
On Jun 10, 2010, at 10:34 PM, John H Palmieri wrote: On Jun 10, 9:47 pm, Andrey Novoseltsev wrote: On Jun 10, 9:41 pm, Jason Grout wrote: I imagine that after doctest coverage is up to 100% function coverage that there will be a new push to then get the statement coverage up to 100%. It would be interesting even now to see how much statement coverage lagged behind function coverage. Where should such tests go? They can go in separate files, files which, for example, are not included in the reference manual. The file sage/homology/tests.py is an example. Each function should have doctests (so the goal is still 100% coverage), but it's not a big deal to relegate lots of technical test to less visible places. Personally, I would much rather put the relevant tests locally right in the docstring and hide them from the documentation generators. Especially as TESTS blocks often test corner cases or other technicalities relevant to that specific function. - Robert -- 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: Sage OSX Clickable App
On 6/10/10, William Stein wrote:
> On Thu, Jun 10, 2010 at 8:07 AM, Robert Bradshaw
> wrote:
>> On Jun 9, 2010, at 11:53 PM, Georg S. Weber wrote:
>>
>>> On 10 Jun., 02:37, Jason Grout wrote:
Karl-Dieter just showed me how to get the OSX App built using sage
-bdist:
export SAGE_APP_BUNDLE=yes
sage -bdist 4.4.2-app
There are people I know that would *love* to have a clickable app on
OSX. Why do we not have this as a download option on the webpage?
>>>
>>> As far as I remember, there was no consensus reached as to *what
>>> exactly* should happen if you "just click" on some Sage App Icon. As
>>> of now, there are at least three different possibilities:
>>>
>>> a.) A "Sage shell" opens, i.e. a terminal that is already cd'ed to
>>> $SAGE_ROOT and "./sage -sh" is executed.
>>> b.) A "Sage interpreter" opens, i.e. a terminal that is already cd'ed
>>> to $SAGE_ROOT and "./sage" is executed.
>>> c.) A "Sage notebook" opens, i.e. a terminal that is already cd'ed to
>>> $SAGE_ROOT and "./sage -notebook" is executed.
>>
>> I think for the vast majority of people wanting a double-clickable app
>> rather than the command line, (c) would be the way to go. The tricky part
>> is
>> how to quit.
Honestly I can't see much use for a or b, especially since if you want
to use the command line, you probably don't need us to hold your hand,
and you probably aren't using Terminal.app anyway.
What we have now is basically option c except that it opens a separate
application instead of a terminal, so that quitting does the right
thing.
> Many of us use OS X, so let's just assume we can program anything if
> we want. What would be the best UI for Sage?
>
> The first thing that pops into my mind is that Sage runs as some sort
> of server, kind of like say DropBox or any of the many other programs
> running with an icon in the bar at the top of the screen. So I
> imagine that when one double clicks on the Sage icon,
>
>(1) the default browser opens with the Sage notebook running,
>(2) a small Sage icon appears in the bar at the top of the screen.
>(3) When clicked, the Sage icon in the bar has at least two options:
> - Sage Notebook (which just opens the browser to the
> notebook server)
> - Quit (which quits the Sage notebook server and makes
> the icon vanish)
>
> It could (but probably shouldn't) also have some slightly more advanced
> options:
> - Log (pop up a Terminal window with "tail -f" on the
> notebook server log)
> - Kill all running Sage sessions
>
> This is basically how I use the Sage notebook on my laptop anyways,
> but with the bar/icon above replaced by a screen session.
Interesting. My initial reaction is I have too many menu extras
already, but it does seem like a natural way to control a server. I
think that at least for new users, however, something that acts as
much like a normal application as possible is desirable.
I think I am probably the only one who wants Sage to actually
be/have/use a separate browser so that it's easy to Cmd-TAB to, quit
etc.
>>> If one "exit"s, in all three cases any window etc. should be closed,
>>> so no "CTRL-C" the terminal after leaving the notebook etc. I'd really
>>> love to have some "true" Sage App" on OS X, i.e. having a status line
>>> that shows me which terminals are open, which notebook server(s) are
>>> running, and all this --- but that is a dream yet.
I think there was some talk of this recently, but I don't know what
became of it. That seems to be recurring theme with OS X Sage
applications. No decision or real progress gets made. I think we
should start distributing what's there right now (perhaps as a
separate download) and start getting some feedback (release early,
release often). It should be easy to add features such as opening sws
files later. We can also include the source for the platypus-created
binary and modify that or replace it entirely if desired. We can also
make a menu extra and see which people like (or have both).
>>> BTW.: If one makes a duplicate of the "sage" script in $SAGE_ROOT and
>>> renames it to "sage.tool", then it *is* clickable under OS X without
>>> the fuzzing around described in the OS X Readme.txt. I was already
>>> thinking about a ticket adding three scripts "sage-shell.tool", "sage-
>>> interpreter.tool" and "sage-notebook.tool" on OS X, but didn't get
>>> around to do so. I mean, personally I mostly use the "Sage
>>> shell" ("Sash" ?!?) and then do "sage -br", "exit", edit, "sage -br"
>>> etc. If there were someone to somehow add buttons to do *that*, I'd
>>> appreciate it ... but nobody has volunteered yet to even think about a
>>> really graphical "user experience". Let alone some graphical
>>> "developer experience" for Sage; AFAIK, most sage-devel people seem to
>>> be rather fine to use emacs, vim, ... instead of the likes of Eclipse,
>>> XCode, VisualStudio, ... (just like me, I use plain
Re: [sage-devel] pushing towards 90% doctest coverage for Sage 5.0
On Jun 10, 2010, at 2:21 PM, Dr. David Kirkby wrote: On 06/10/10 09:25 PM, Minh Nguyen wrote: Hi folks, One of the main goals of the upcoming Sage 5.0 release is to get doctest coverage of the Sage library up to at least 90%. As of Sage 4.4.4.alpha0, the overall weighted coverage is 82.7%. Seems we are a long way off. It seems to me, rather than pick a number like 90%, the areas should be targeted carefully. 90% is a very nice global goal to have--it's something concrete to shoot for while still letting everyone work on what they like/think is most important. That being said, I agree with you that I'd rather people write tests for more valuable areas rather than easy ones is certainly worthwhile. To get a sense of which modules in the Sage library need work on their coverage scores, you could use the coverage script as follows: $ ./sage -coverage /path/to/module.py[x] Or you could do the following to get the coverage scores of all modules, including a coverage summary: $ ./sage -coverageall You might be interested in knowing which modules have a certain coverage percentage, in which case you could save the output of -coverageall to a text file and then grep that file for certain coverage scores. At this repository [1] is a script to generate various types of coverage analysis reports. You can also find the script at [3]. The script currently supports the following reports * The coverage summary of all modules. * Modules with 100% coverage. * Modules with zero coverage. I don't really understand these docs tests well, but to me at least, concentrating on modules which have zero coverage would seem best, even if only one doctest/module is added. My logic being something could be totally broken, and we would never know about it. At least if there is even one doctest, it shows it is not totally broken. (Though one could argue being totally broken is better than being partially broken. At least one finds out in use.) +1, though of course some files (e.g. tachyon) are indirectly tested, so it's hard to tell just looking at the numbers alone. - Robert -- 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: pushing towards 90% doctest coverage for Sage 5.0
On Jun 10, 2010, at 8:41 PM, Jason Grout wrote: On 6/10/10 7:20 PM, Dr. David Kirkby wrote: We don't even ensure that every statement of code gets executed at least once. Mike Hansen posted some code to use a tool to check that (a long time ago). I imagine that after doctest coverage is up to 100% function coverage that there will be a new push to then get the statement coverage up to 100%. It would be interesting even now to see how much statement coverage lagged behind function coverage. That would be very interesting indeed. I don't think it'll be too long before we have line profilers fully supported (and hence coverage tools too) for Cython as well as Python code. I'm not sure what tools there are to deal with branch coverage. - Robert -- 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: Design discussion / request for comment
On Jun 10, 2010, at 8:17 PM, Jason Grout wrote: On 6/10/10 12:25 PM, Florent Hivert wrote: Hi There, I'd like to discuss a design question. Some time ago Adrien Boussicault and myself started to write some experimental code for copy-on-write in Sage/Python. The idea is now more or less dropped because performance gain was not so good and the syntax was not very usable. Rob and I were just talking yesterday how it's so inconvenient that identity_matrix() now returns an immutable matrix, so constructing something from it involves making a copy, which is not the most obvious thing to a new person, or the most elegant thing to someone that has been using matrices for a while now. It would be fantastic if immutable matrices had copy-on-write semantics, not necessarily for performance, but just for usability after some of the recent design decisions (which I guess were made for performance reasons). Copy on write *should* be rather easy to implement for matrices at least. - Robert -- 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] Fwd: building on t2 in 4 hours
On Jun 9, 2010, at 4:36 PM, Dr. David Kirkby wrote: I think this is such good news, that even those on sage-devel will not mind too much! Building packages in parallel seems to be working very well. That said, wtih 128 hardware threads, still only a small fraction of 't2' is being used effectively. I've found with multi- threaded coded, around 500 threads seems optimal on 't2' - certainly a lot more than the number of cores (16) or hardware threads (128). That's quite strange. Are the threads locking on disk I/O for most of the compilation process? Clint, the main ATLAS developer, sent an email the other day to William in which he said the latest ATLAS would build in under an hour on 't2', so hopefully 'ATLAS' wont be a bottleneck for much longer. Now at least 't2' should build Sage quicker than the 10-year old SPARC I bought from eBay for a US equivalent of under $50. Excellent! - Robert -- 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] moving Sage directories
On 06/10/2010 04:49 PM, Jason Grout wrote: > There seem to be a lot of loose ends left hanging when a sage directory > is moved. For example, I usually compile Sage on a ramdisk, and then > move it to my home directory. [snip] > It seems common knowledge in Sage that you can compile Sage and move the > directory around to your heart's content. Maybe we should put a warning > somewhere cautioning people that there are lot of packages included in > Sage, and Sage might not automatically change the right directory > information for every package? > This seems like a goldmine for possible subtle bugs... :-) Ralf -- 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: Sage OSX Clickable App
On Thu, Jun 10, 2010 at 11:48 PM, Ivan Andrus wrote: > > I don't think that's actually the case. If the disk image we > distribute is HFS+ it should allow us to hard link directories so that > each application can have it's own copy of the sage directory, without > any real duplication (and we can have a copy at the top level as > well). Once you copy it onto your own disk the links will probably be > broken though, which could be bad. I wonder if zip files can preserve > hard linked directories... I spoke too soon. I knew Time Machine uses hardlinks to directories, and I assumed users could as well. According to http://stackoverflow.com/questions/1432540/creating-directory-hard-links-in-macos-x that is not true in Snow Leopard, and not true from the shell in Leopard. Nevertheless there must be some suitably clever way to get the same outcome. -Ivan -- 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: moving Sage directories
On 6/11/10 1:09 AM, Ralf Hemmecke wrote: On 06/10/2010 04:49 PM, Jason Grout wrote: There seem to be a lot of loose ends left hanging when a sage directory is moved. For example, I usually compile Sage on a ramdisk, and then move it to my home directory. [snip] It seems common knowledge in Sage that you can compile Sage and move the directory around to your heart's content. Maybe we should put a warning somewhere cautioning people that there are lot of packages included in Sage, and Sage might not automatically change the right directory information for every package? This seems like a goldmine for possible subtle bugs... :-) See http://trac.sagemath.org/sage_trac/ticket/9210 for an updated sage-location script which takes care of the problems with pkg-config if the build directory moves. This should take care of the matplotlib freetype problems from a recent thread if the build directory is moved (the fix on #9208 only works if the build directory hasn't been moved). See also http://trac.sagemath.org/sage_trac/ticket/5776, where mabshoff filed a ticket for these kinds of things over a year ago. 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 at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Design discussion / request for comment
On Thu, Jun 10, 2010 at 10:58 PM, Robert Bradshaw wrote: > > On Jun 10, 2010, at 8:17 PM, Jason Grout wrote: > >> On 6/10/10 12:25 PM, Florent Hivert wrote: >>> >>> Hi There, >>> >>> I'd like to discuss a design question. Some time ago Adrien Boussicault >>> and >>> myself started to write some experimental code for copy-on-write in >>> Sage/Python. The idea is now more or less dropped because performance >>> gain was >>> not so good and the syntax was not very usable. >> >> Rob and I were just talking yesterday how it's so inconvenient that >> identity_matrix() now returns an immutable matrix, so constructing something >> from it involves making a copy, which is not the most obvious thing to a new >> person, or the most elegant thing to someone that has been using matrices >> for a while now. It would be fantastic if immutable matrices had >> copy-on-write semantics, not necessarily for performance, but just for >> usability after some of the recent design decisions (which I guess were made >> for performance reasons). > > Copy on write *should* be rather easy to implement for matrices at least. Just out of curiosity, is this what would happen below with what you guys are envisioning for immutable copy on write matrices? sage: a = matrix(ZZ, 3) sage: a[1,2] = 5 sage: a.set_immutable() sage: a[1,2] = 7 sage: print a 7 If so, what about: sage: A = M.hecke_matrix(2) sage: A[1,2] 20 sage: A[1,2] = 5; A 5 sage: M.hecke_matrix(2)[1,2] 20 I think the above would be very, very confusing to me. If immutable matrices *act* as if they are fully mutable, but basically silently have completely different semantics, this will be confusing. -- William -- William Stein Professor of Mathematics University of Washington http://wstein.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
