[sage-devel] Re: 4.1.1.alpha0 Installation just 'dying' for no known reason
Hi David, On Thu, Jul 23, 2009 at 4:54 PM, Dr. David Kirkby wrote: > Minh, > your build on t2 has stopped with: > > sage: An error occurred while installing polybori-0.5rc.p8 > > You appear to have forgot to install the .p9 version. > > http://sage.math.washington.edu/home/kirkby/Solaris-fixes/polybori-0.5rc.p9-Second-try/polybori-0.5rc.p9.spkg I've started building the PolyBori SPKG up at http://sage.math.washington.edu/home/mvngu/patch/polybori-0.5rc.p9.spkg on t2. I was too immersed in merging tickets in the last couple of hours :-) Thank you very much for your reminder. Let's wait and see if polybori-0.5rc.p9.spkg builds OK on t2. > Note that despite singular-3-1-0-2-20090620 appearing to install, it > will not actually install properly on t2, as it can't find install-sh, > so some of the files don't get copied. > > http://sagetrac.org/sage_trac/ticket/6563 > http://sage.math.washington.edu/home/kirkby/Solaris-fixes/singular-3-1-0-2-20090620.p0/singular-3-1-0-2-20090620.p0.spkg Once PolyBori finishes compiling, I'll start compiling singular-3-1-0-2-20090620.p0.spkg. By the way, I have checked in all changes in your name and have uploaded the updated SPKG to http://sage.math.washington.edu/home/mvngu/patch/singular-3-1-0-2-20090620.p0.spkg > Ticket http://sagetrac.org/sage_trac/ticket/6558 > http://sage.math.washington.edu/home/mvngu/patch/atlas-3.8.3.p6.spkg > should be easy to review, as its only a change to a single line. I'll start building that once PolyBori and Singular finishes. -- Regards Minh Van Nguyen --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] SCons issues: 'modified Sage library' build fails at c_lib if Sun C++ compiler can be found.
I'm copying this to Steven Knight, a SCons developer, since he might have some comments. When building Sage 4.1.1.alpha0 on my home machine, which does not have the Sun Studio Compiler suite installed, the Sage package containing the 'modified Sage library' builds ok. (I eventually get failures at ecl, but that is another issue). On the machine 't2' the 'modified Sage library' fails. For some reason, despite gcc having been used to compile the C files, Sun's /opt/SUNWspro/bin/CC gets used for the C++ files. The Sun compiler is unhappy about the C++ code and exits with an error. (PolyBoRi had the same issue, but Alexander Dreyer fixed that) However, that aside, the call to Sun's compiler is mixing up GNU and Sun flags, which they are I believe being inherited from SCons. Perhaps SCons is giving the wrong flags, or perhaps somewhere in the Sage code some GNU flags are added. But either way, the result is wrong. /opt/SUNWspro/bin/CC -o src/so_ZZ_pylong.o -c -KPIC -fPIC -I/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/include -I/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/include/python2.6 -I/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/include/NTL -Iinclude src/ZZ_pylong.cpp CC: Warning: Option -fPIC passed to ld, if ld is invoked, ignored otherwise "src/ZZ_pylong.cpp", line 47: Error: "ZZ_set_pylong(NTL::ZZ&, _object*)" is expected to return a value. 1 Error(s) detected. Note -KPIC is an acceptable flag to Sun's compiler, but -fPIC is not. (The converse is true with gcc). I've created this as bug id http://sagetrac.org/sage_trac/ticket/6595 Dave --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: 4.1.1.alpha0 Installation just 'dying' for no known reason
Minh Nguyen wrote: > Hi David, > > On Thu, Jul 23, 2009 at 4:54 PM, Dr. David > Kirkby wrote: > > > >> Minh, >> your build on t2 has stopped with: >> >> sage: An error occurred while installing polybori-0.5rc.p8 >> >> You appear to have forgot to install the .p9 version. >> >> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/polybori-0.5rc.p9-Second-try/polybori-0.5rc.p9.spkg > > I've started building the PolyBori SPKG up at > > http://sage.math.washington.edu/home/mvngu/patch/polybori-0.5rc.p9.spkg > > on t2. I was too immersed in merging tickets in the last couple of > hours :-) Thank you very much for your reminder. Let's wait and see if > polybori-0.5rc.p9.spkg builds OK on t2. > > >> Note that despite singular-3-1-0-2-20090620 appearing to install, it >> will not actually install properly on t2, as it can't find install-sh, >> so some of the files don't get copied. >> >> http://sagetrac.org/sage_trac/ticket/6563 >> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/singular-3-1-0-2-20090620.p0/singular-3-1-0-2-20090620.p0.spkg > > Once PolyBori finishes compiling, I'll start compiling > singular-3-1-0-2-20090620.p0.spkg. By the way, I have checked in all > changes in your name and have uploaded the updated SPKG to > > http://sage.math.washington.edu/home/mvngu/patch/singular-3-1-0-2-20090620.p0.spkg > > >> Ticket http://sagetrac.org/sage_trac/ticket/6558 >> http://sage.math.washington.edu/home/mvngu/patch/atlas-3.8.3.p6.spkg >> should be easy to review, as its only a change to a single line. > > I'll start building that once PolyBori and Singular finishes. > I think you will finally bomb out at the 'modified sage files' in c_lib, which appears to be a bug that only shows up when the Sun C++ compiler is present. (Just like the second of the two Solaris polybori bugs). I have a hacked version of SCons which would fix that, by making SCons unaware of /opt/SUNWspro/bin/, but that is not really the answer. We need to sort out why some Sage packages are using a mix of GNU and Sun compilers. It might be a fault in SCons, or it might not be (to state the obvious I guess!!) Steven Knight, one of the SCons developers, now has an account on t2 and intends adding 't2' to his SCons build farm, so any change he commits to CVS will be tested on t2. This should hopefully improve the Solaris support of SCons. But for now, I think you build will fail there. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: 4.1.1.alpha0 Installation just 'dying' for no known reason
On Thu, Jul 23, 2009 at 5:19 PM, Minh Nguyen wrote: > Hi David, > > On Thu, Jul 23, 2009 at 4:54 PM, Dr. David > Kirkby wrote: > > > >> Minh, >> your build on t2 has stopped with: >> >> sage: An error occurred while installing polybori-0.5rc.p8 >> >> You appear to have forgot to install the .p9 version. >> >> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/polybori-0.5rc.p9-Second-try/polybori-0.5rc.p9.spkg > > I've started building the PolyBori SPKG up at > > http://sage.math.washington.edu/home/mvngu/patch/polybori-0.5rc.p9.spkg > > on t2. I was too immersed in merging tickets in the last couple of > hours :-) Thank you very much for your reminder. Let's wait and see if > polybori-0.5rc.p9.spkg builds OK on t2. That PolyBori SPKG successfully compiles! To paraphrase someone, it's such a shock when things just work. -- Regards Minh Van Nguyen --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Should we check files ARE installed, not just hope they are installed?
I've noticed a couple of issues on Solaris, where it appears packages have been installed properly (the $SAGE_HOME/spkg/installed/foobar is created), but this has not actually happened. On one occasion 'cp -a' was called, which failed to copy files to $SAGE_HOME/local/include, as '-a' is not an option on Solaris to the cp command. Sun's 'cp' reported this as an error, but this did not cause the 'make' to stop. On another occasion, singular fails to install files with 'install-sh' as it could not find install-sh. This is despite there being about 15 copies of install-sh in the singular distribution!!! I think it is only luck that it worked on linux, as the path given in singular is broken. It would be a good idea when creating new .spkg files that one actually checks that at least a subset of the files that are supposed to be installed in $SAGE_HOME/local, actually are installed - preferably all of them if possible. Comments? Dave --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: 4.1.1.alpha0 Installation just 'dying' for no known reason
Minh Nguyen wrote: > On Thu, Jul 23, 2009 at 5:19 PM, Minh Nguyen wrote: >> Hi David, >> >> On Thu, Jul 23, 2009 at 4:54 PM, Dr. David >> Kirkby wrote: >> >> >> >>> Minh, >>> your build on t2 has stopped with: >>> >>> sage: An error occurred while installing polybori-0.5rc.p8 >>> >>> You appear to have forgot to install the .p9 version. >>> >>> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/polybori-0.5rc.p9-Second-try/polybori-0.5rc.p9.spkg >> I've started building the PolyBori SPKG up at >> >> http://sage.math.washington.edu/home/mvngu/patch/polybori-0.5rc.p9.spkg >> >> on t2. I was too immersed in merging tickets in the last couple of >> hours :-) Thank you very much for your reminder. Let's wait and see if >> polybori-0.5rc.p9.spkg builds OK on t2. > > That PolyBori SPKG successfully compiles! To paraphrase someone, it's > such a shock when things just work. > Good. You can thank Alexander Dreyer, as he changed some files to make that work. I only fixed the linker flags. We seem to have exactly the same issues in sage-4.1.1.alpha0.spkg, as that is mixing up Sun and GNU flags when Sun's compiler is present, but works if Sun's compiler is not present. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Should we check files ARE installed, not just hope they are installed?
On Thu, Jul 23, 2009 at 1:22 AM, Dr. David Kirkby wrote: > > I've noticed a couple of issues on Solaris, where it appears packages > have been installed properly (the $SAGE_HOME/spkg/installed/foobar is > created), but this has not actually happened. > > On one occasion 'cp -a' was called, which failed to copy files to > $SAGE_HOME/local/include, as '-a' is not an option on Solaris to the cp > command. Sun's 'cp' reported this as an error, but this did not cause > the 'make' to stop. After every single command in spkg-install one *must* check the error return value. That's why there is code like the following all over in them: if [ $? -ne 0 ]; then echo "blah went wrong" exit 1 fi Anywhere such code doesn't happen is a bug. > On another occasion, singular fails to install files with 'install-sh' > as it could not find install-sh. This is despite there being about 15 > copies of install-sh in the singular distribution!!! > > I think it is only luck that it worked on linux, as the path given in > singular is broken. > > It would be a good idea when creating new .spkg files that one actually > checks that at least a subset of the files that are supposed to be > installed in $SAGE_HOME/local, actually are installed - preferably all > of them if possible. > > Comments? That won't necessarily "prove" anything, since e.g., on doing an upgrade the files might appear to be installed, but in fact old versions are installed. William > > Dave > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pointsize and thickness in list_plot
On Jul 22, 2009, at 2:47 PM, William Stein wrote: > > On Wed, Jul 22, 2009 at 11:49 AM, Robert > Bradshaw wrote: >> >> On Jul 22, 2009, at 11:24 AM, William Stein wrote: >> >>> On Wed, Jul 22, 2009 at 11:19 AM, Ethan Van >>> Andel wrote: In list_plot there's some confusion with the pointsize and thickness keyword arguments. These 2 commands run just fine. list_plot([(0,0),(1,1)],thickness = 20,plotjoined = true) list_plot([(0,0),(1,1)],pointsize = 20,plotjoined = false) This one runs but ignores thickness and gives you a warning saying that it is ignoring thickness. list_plot([(0,0),(1,1)],thickness = 20,plotjoined = false) This one doesn't run at all but gives you an invalid option error. This behavior is needlessly finnicky, especially when writing functions that call list_plot with user supplied parameters. For example, this method would fail half of the time. def foo(size,joined): return list_plot(mydata,pointsize = size, plotjoined = joined) My first thought for a fix was to make the arguments interchangable, ie thickness = 5 and pointsize = 5 would do the same thing in both joined and discrete plots. However, they don't actually behave the same. For example, the line drawn with thickness = 20 is much thicker than a point with pointsize = 20. Therefore, if they were to be merged in some way what would be the best way to go about it? >>> >>> I have always found the value of pointsize to be very mysterious. I >>> wonder if we >>> could make it so pointsize=20 and thickness=20 are the same. This >>> would of course >>> break all existing use of pointsize, but at least it would make >>> sense. >>> >>> I have heard many people chuckle when wondering what the pointsize >>> units are. >> >> +1 for consistency. However, shouldn't it be able to specify both >> (and have it draw a line with (possibly larger) points? > > Ooooh, that's a good idea. Are you saying that if both options are > given, then the large is always taken? I like that. Oh, I was thinking of pointsize meaning "size of the plotted points," not "1/72 inch measurment." - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: 4.1.1.alpha0 Installation just 'dying' for no known reason
On Thu, Jul 23, 2009 at 5:19 PM, Minh Nguyen wrote: >> Note that despite singular-3-1-0-2-20090620 appearing to install, it >> will not actually install properly on t2, as it can't find install-sh, >> so some of the files don't get copied. >> >> http://sagetrac.org/sage_trac/ticket/6563 >> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/singular-3-1-0-2-20090620.p0/singular-3-1-0-2-20090620.p0.spkg That Singular SPKG successfully compiles! Now onto ATLAS. -- Regards Minh Van Nguyen --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Should we check files ARE installed, not just hope they are installed?
William Stein wrote: > On Thu, Jul 23, 2009 at 1:22 AM, Dr. David > Kirkby wrote: >> I've noticed a couple of issues on Solaris, where it appears packages >> have been installed properly (the $SAGE_HOME/spkg/installed/foobar is >> created), but this has not actually happened. >> >> On one occasion 'cp -a' was called, which failed to copy files to >> $SAGE_HOME/local/include, as '-a' is not an option on Solaris to the cp >> command. Sun's 'cp' reported this as an error, but this did not cause >> the 'make' to stop. > > After every single command in spkg-install one *must* check the error > return value. That's why there is code like the following all over in > them: > > if [ $? -ne 0 ]; then > echo "blah went wrong" > exit 1 > fi > > Anywhere such code doesn't happen is a bug. Well, there are a lot of bugs then, as a lot of code I see does not check every command. Checking at the end does not work. I just looked at one random package I've never looked at before - (numpy-1.3.0.p1] This contains: cp ../patches/gnu.py numpy/distutils/fcompiler/gnu.py cp ../patches/__init__.py numpy/distutils/fcompiler/__init__.py There are no checks. There is a check later: if [ $? -ne 0 ]; then echo "Error building numpy." exit 1 fi but that does not help, as the following script I wrote shows. #!/bin/sh # Try to do something which will fail as non-root touch /this-should-fail pwd if [ $? -ne 0 ]; then echo "This script failed" exit 1 fi the 'touch' command gives an error, but the message "This script failed" is *not* printed, as the 'pwd' command later succeeded. If I remove the 'pwd' command, so it prints the error message. Writing if [ $? -ne 0 ]; then echo "This script failed" exit 1 fi after every single command in spkg-install would make the code very long, >> It would be a good idea when creating new .spkg files that one actually >> checks that at least a subset of the files that are supposed to be >> installed in $SAGE_HOME/local, actually are installed - preferably all >> of them if possible. >> >> Comments? > > That won't necessarily "prove" anything, since e.g., on doing an > upgrade the files might appear to be installed, but in fact old > versions are installed. > > William True, but it might go some way. Perhaps modification times could be used in some way. I don't claim to know a complete foolproof solution (fools are very resourceful), but it's clear that there are things going wrong which are not being noticed. With a log file of 20 MB or more, its not easy for a human to look for the errors. In Solaris, any time a package is installed with the pkgadd command, a record is kept of the checksum of every file, the permissions of the file so it is possible to determine if something has changed. I don't know if it's practical to do similar in Sage. It's very clear to me not every error in Sage is being caught during the installation. dave --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Should we check files ARE installed, not just hope they are installed?
On Thu, Jul 23, 2009 at 2:18 AM, Dr. David Kirkby wrote: > > William Stein wrote: >> On Thu, Jul 23, 2009 at 1:22 AM, Dr. David >> Kirkby wrote: >>> I've noticed a couple of issues on Solaris, where it appears packages >>> have been installed properly (the $SAGE_HOME/spkg/installed/foobar is >>> created), but this has not actually happened. >>> >>> On one occasion 'cp -a' was called, which failed to copy files to >>> $SAGE_HOME/local/include, as '-a' is not an option on Solaris to the cp >>> command. Sun's 'cp' reported this as an error, but this did not cause >>> the 'make' to stop. >> >> After every single command in spkg-install one *must* check the error >> return value. That's why there is code like the following all over in >> them: >> >> if [ $? -ne 0 ]; then >> echo "blah went wrong" >> exit 1 >> fi >> >> Anywhere such code doesn't happen is a bug. > > Well, there are a lot of bugs then, as a lot of code I see does not > check every command. Checking at the end does not work. > > I just looked at one random package I've never looked at before - > (numpy-1.3.0.p1] > > This contains: > > cp ../patches/gnu.py numpy/distutils/fcompiler/gnu.py > cp ../patches/__init__.py numpy/distutils/fcompiler/__init__.py > > There are no checks. There is a check later: > > if [ $? -ne 0 ]; then > echo "Error building numpy." > exit 1 > fi > > but that does not help, as the following script I wrote shows. > > #!/bin/sh > # Try to do something which will fail as non-root > > touch /this-should-fail > pwd > if [ $? -ne 0 ]; then > echo "This script failed" > exit 1 > fi > > the 'touch' command gives an error, but the message "This script failed" > is *not* printed, as the 'pwd' command later succeeded. If I remove the > 'pwd' command, so it prints the error message. > > > > > Writing > > if [ $? -ne 0 ]; then > echo "This script failed" > exit 1 > fi > > > after every single command in spkg-install would make the code very long, > Nonetheless, we should be checking the error code after every line executes, one way or another. Is there a way to automatically do this in bash? > > >>> It would be a good idea when creating new .spkg files that one actually >>> checks that at least a subset of the files that are supposed to be >>> installed in $SAGE_HOME/local, actually are installed - preferably all >>> of them if possible. >>> >>> Comments? >> >> That won't necessarily "prove" anything, since e.g., on doing an >> upgrade the files might appear to be installed, but in fact old >> versions are installed. >> >> William > > > True, but it might go some way. Perhaps modification times could be used > in some way. > > I don't claim to know a complete foolproof solution (fools are very > resourceful), but it's clear that there are things going wrong which are > not being noticed. With a log file of 20 MB or more, its not easy for a > human to look for the errors. > > > In Solaris, any time a package is installed with the pkgadd command, a > record is kept of the checksum of every file, the permissions of the > file so it is possible to determine if something has changed. I don't > know if it's practical to do similar in Sage. It certainly is. This might make the Sage package management system "too complicated" though. Right now it is still very simple. > It's very clear to me not every error in Sage is being caught during the > installation. Fixes very welcome. > > dave > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: 4.1.1.alpha0 Installation just 'dying' for no known reason
Minh Nguyen wrote: > On Thu, Jul 23, 2009 at 5:19 PM, Minh Nguyen wrote: > > > >>> Note that despite singular-3-1-0-2-20090620 appearing to install, it >>> will not actually install properly on t2, as it can't find install-sh, >>> so some of the files don't get copied. >>> >>> http://sagetrac.org/sage_trac/ticket/6563 >>> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/singular-3-1-0-2-20090620.p0/singular-3-1-0-2-20090620.p0.spkg > > That Singular SPKG successfully compiles! That patch http://sagetrac.org/sage_trac/ticket/6563 fixes the problem, but perhaps in a non-ideal way, as it adds install-sh to the top level directory. (There are already 15 or so copies of that file in the singular distribution.) The failure to find install-sh when there are about 15 copies of it is probably a bug in autoconf or singular's build system. The problem I have is that if ever problem noticed on Solaris was fully investigated as well as I'd like to do, progress would drop to a crawl. It seems to me that adding install-sh in the top level directory will not break anything and will allow singular to install properly. > Now onto ATLAS. I won't expect to hear from you for another 8 hours or so then! I'm trying to add support for the later processors in ATLAS's code. Then hopefully I can reduce the time it takes to install, once I have the tuning data for the T2+ processor and I have ATLAS understanding what it is. Currently it checks for various UltraSPARC CPUs, but the T2+ is not one of them. dave --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Should we check files ARE installed, not just hope they are installed?
On Thu, 23 Jul 2009 02:25:26 -0700 William Stein wrote: > > On Thu, Jul 23, 2009 at 2:18 AM, Dr. David > Kirkby wrote: > > > > after every single command in spkg-install would make the code very > > long, > > > > Nonetheless, we should be checking the error code after every line > executes, one way or another. Is there a way to automatically do this > in bash? "set -e" should do it. Google brings up this page, besides lots of others: http://www.davidpashley.com/articles/writing-robust-shell-scripts.html Cheers, Burcin --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Should we check files ARE installed, not just hope they are installed?
William Stein wrote: > On Thu, Jul 23, 2009 at 2:18 AM, Dr. David > Kirkby wrote: >> William Stein wrote: >>> On Thu, Jul 23, 2009 at 1:22 AM, Dr. David >>> Kirkby wrote: I've noticed a couple of issues on Solaris, where it appears packages have been installed properly (the $SAGE_HOME/spkg/installed/foobar is created), but this has not actually happened. On one occasion 'cp -a' was called, which failed to copy files to $SAGE_HOME/local/include, as '-a' is not an option on Solaris to the cp command. Sun's 'cp' reported this as an error, but this did not cause the 'make' to stop. >>> After every single command in spkg-install one *must* check the error >>> return value. That's why there is code like the following all over in >>> them: >>> >>> if [ $? -ne 0 ]; then >>> echo "blah went wrong" >>> exit 1 >>> fi >>> >>> Anywhere such code doesn't happen is a bug. >> Well, there are a lot of bugs then, as a lot of code I see does not >> check every command. Checking at the end does not work. >> >> I just looked at one random package I've never looked at before - >> (numpy-1.3.0.p1] >> >> This contains: >> >> cp ../patches/gnu.py numpy/distutils/fcompiler/gnu.py >> cp ../patches/__init__.py numpy/distutils/fcompiler/__init__.py >> >> There are no checks. There is a check later: >> >> if [ $? -ne 0 ]; then >> echo "Error building numpy." >> exit 1 >> fi >> >> but that does not help, as the following script I wrote shows. >> >> #!/bin/sh >> # Try to do something which will fail as non-root >> >> touch /this-should-fail >> pwd >> if [ $? -ne 0 ]; then >> echo "This script failed" >> exit 1 >> fi >> >> the 'touch' command gives an error, but the message "This script failed" >> is *not* printed, as the 'pwd' command later succeeded. If I remove the >> 'pwd' command, so it prints the error message. >> >> >> >> >> Writing >> >> if [ $? -ne 0 ]; then >> echo "This script failed" >> exit 1 >> fi >> >> >> after every single command in spkg-install would make the code very long, >> > > Nonetheless, we should be checking the error code after every line > executes, one way or another. Is there a way to automatically do this > in bash? I'm not aware of one, but I'll ask on comp.unix.shell - that is my favorite place to ask for this sort of information. Even if you solve it in spkg-install, it still leaves all the makefiles that are used in packages - it is clear to me they don't check that their actions have succeeded. If the did, things like a missing 'install-sh' would cause it to exit, rather than continue and exit with an exit code of 0. dave --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Should we check files ARE installed, not just hope they are installed?
On Thu, Jul 23, 2009 at 2:37 AM, Dr. David Kirkby wrote: > > William Stein wrote: >> On Thu, Jul 23, 2009 at 2:18 AM, Dr. David >> Kirkby wrote: >>> William Stein wrote: On Thu, Jul 23, 2009 at 1:22 AM, Dr. David Kirkby wrote: > I've noticed a couple of issues on Solaris, where it appears packages > have been installed properly (the $SAGE_HOME/spkg/installed/foobar is > created), but this has not actually happened. > > On one occasion 'cp -a' was called, which failed to copy files to > $SAGE_HOME/local/include, as '-a' is not an option on Solaris to the cp > command. Sun's 'cp' reported this as an error, but this did not cause > the 'make' to stop. After every single command in spkg-install one *must* check the error return value. That's why there is code like the following all over in them: if [ $? -ne 0 ]; then echo "blah went wrong" exit 1 fi Anywhere such code doesn't happen is a bug. >>> Well, there are a lot of bugs then, as a lot of code I see does not >>> check every command. Checking at the end does not work. >>> >>> I just looked at one random package I've never looked at before - >>> (numpy-1.3.0.p1] >>> >>> This contains: >>> >>> cp ../patches/gnu.py numpy/distutils/fcompiler/gnu.py >>> cp ../patches/__init__.py numpy/distutils/fcompiler/__init__.py >>> >>> There are no checks. There is a check later: >>> >>> if [ $? -ne 0 ]; then >>> echo "Error building numpy." >>> exit 1 >>> fi >>> >>> but that does not help, as the following script I wrote shows. >>> >>> #!/bin/sh >>> # Try to do something which will fail as non-root >>> >>> touch /this-should-fail >>> pwd >>> if [ $? -ne 0 ]; then >>> echo "This script failed" >>> exit 1 >>> fi >>> >>> the 'touch' command gives an error, but the message "This script failed" >>> is *not* printed, as the 'pwd' command later succeeded. If I remove the >>> 'pwd' command, so it prints the error message. >>> >>> >>> >>> >>> Writing >>> >>> if [ $? -ne 0 ]; then >>> echo "This script failed" >>> exit 1 >>> fi >>> >>> >>> after every single command in spkg-install would make the code very long, >>> >> >> Nonetheless, we should be checking the error code after every line >> executes, one way or another. Is there a way to automatically do this >> in bash? > > I'm not aware of one, but I'll ask on comp.unix.shell - that is my > favorite place to ask for this sort of information. > > Even if you solve it in spkg-install, it still leaves all the makefiles > that are used in packages - it is clear to me they don't check that > their actions have succeeded. If the did, things like a missing > 'install-sh' would cause it to exit, rather than continue and exit with > an exit code of 0. > > dave Fortunately you're not right. If an error is raised by any command in a makefile, then the make program terminates with an error and exit code. As a little test, try this make file: wst...@boxen:~/tmp$ more makefile all: ls / touch /x echo "hello" --- Burcin -- bravo, using "set -e" is a great idea. This is now trac #6598: http://trac.sagemath.org/sage_trac/ticket/6598 William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Should we check files ARE installed, not just hope they are installed?
William Stein wrote: > On Thu, Jul 23, 2009 at 2:37 AM, Dr. David > Kirkby wrote: >> William Stein wrote: >>> On Thu, Jul 23, 2009 at 2:18 AM, Dr. David >>> Kirkby wrote: William Stein wrote: > On Thu, Jul 23, 2009 at 1:22 AM, Dr. David > Kirkby wrote: >> I've noticed a couple of issues on Solaris, where it appears packages >> have been installed properly (the $SAGE_HOME/spkg/installed/foobar is >> created), but this has not actually happened. >> >> On one occasion 'cp -a' was called, which failed to copy files to >> $SAGE_HOME/local/include, as '-a' is not an option on Solaris to the cp >> command. Sun's 'cp' reported this as an error, but this did not cause >> the 'make' to stop. > After every single command in spkg-install one *must* check the error > return value. That's why there is code like the following all over in > them: > > if [ $? -ne 0 ]; then > echo "blah went wrong" > exit 1 > fi > > Anywhere such code doesn't happen is a bug. Well, there are a lot of bugs then, as a lot of code I see does not check every command. Checking at the end does not work. I just looked at one random package I've never looked at before - (numpy-1.3.0.p1] This contains: cp ../patches/gnu.py numpy/distutils/fcompiler/gnu.py cp ../patches/__init__.py numpy/distutils/fcompiler/__init__.py There are no checks. There is a check later: if [ $? -ne 0 ]; then echo "Error building numpy." exit 1 fi but that does not help, as the following script I wrote shows. #!/bin/sh # Try to do something which will fail as non-root touch /this-should-fail pwd if [ $? -ne 0 ]; then echo "This script failed" exit 1 fi the 'touch' command gives an error, but the message "This script failed" is *not* printed, as the 'pwd' command later succeeded. If I remove the 'pwd' command, so it prints the error message. Writing if [ $? -ne 0 ]; then echo "This script failed" exit 1 fi after every single command in spkg-install would make the code very long, >>> Nonetheless, we should be checking the error code after every line >>> executes, one way or another. Is there a way to automatically do this >>> in bash? >> I'm not aware of one, but I'll ask on comp.unix.shell - that is my >> favorite place to ask for this sort of information. >> >> Even if you solve it in spkg-install, it still leaves all the makefiles >> that are used in packages - it is clear to me they don't check that >> their actions have succeeded. If the did, things like a missing >> 'install-sh' would cause it to exit, rather than continue and exit with >> an exit code of 0. >> >> dave > > Fortunately you're not right. If an error is raised by any command in > a makefile, then the make program terminates with an error and exit > code. As a little test, try this make file: > wst...@boxen:~/tmp$ more makefile > all: > ls / > touch /x > echo "hello" > Good, but the fact remains some installations (like singular's) are breaking and not reporting the error. I assume the 'install-sh' was called from a makefile, but perhaps not. Either way, the is a problem here. > Burcin -- bravo, using "set -e" is a great idea. This is now trac #6598: > > http://trac.sagemath.org/sage_trac/ticket/6598 > > William That certainly looks useful. Next time I create a package, I'll try that out and implement it if it looks to be ok. dave --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: A Haskell-Python bridge? GHCi and JS notebook interfaces?
It's a great idea -- and it seems feasible. One way to set up an interface to GHCi would be to just send the contents of the cell to GHCi -- taking care to put function definitions and the like in one line, and pipe the output -- but it may set some constraints to the input -- "let" before definitions, difficulty giving types, etc. It may or may not be possible to automatically fix these problems. Another approach would be to send the contents to GHC, compile it, and run it -- but we'll have to keep track of the cells that have been evaluted containing Haskell code, and concatenate them before sending the stuff to GHC. We'll have to make sure that only one ``main`` function exists -- this should be pretty easy -- just remove all ``main`` functions in other cells, and make the last line in the cell the ``main`` function if none exists. I have little polyglot experience -- I'll leave that to others. On Jul 22, 12:51 am, Pat LeSmithe wrote: > A very cool, possibly very difficult(?), project would bridge Python and > Haskell, or to be concrete, the standard Python interpreter and the > interactive version of the Glasgow Haskell Compiler: > > http://www.haskell.org/ghc/ > > The Haskell community actually has a Trac server for rating their Google > Summer of Code proposals: > > http://hackage.haskell.org/trac/summer-of-code/report/1 > > Should Sage have such a ready list, too? > > Returning to the HaPy bridge... I found #1547 > > http://hackage.haskell.org/trac/summer-of-code/ticket/1547 > > and MissingPy > > http://hackage.haskell.org/package/MissingPy > > which seems to go in just one direction (calling Python code from Haskell). > > I suppose an easier first step would be to set up a notebook interface > to GHCi --- a notebook monad (I think). Can some Haskell experts offer > Sage advice? I speculate that a number of mathematical algorithms could > benefit from the sophisticated program transformations available in > purely functional languages. > > How about a *JavaScript* analogue to the increasingly common Python > notebook? One challenge here is to wrap the browser's native JS engine > so it's possible to restart the notebook cleanly without reloading the > page, yet retain the engine's power. We could load various libraries, > for 2D / 3D graphics and widgets, on demand. One such library might > transparently wrap a remote Python shell... --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Is new symbolic derivative really worth the efforts?
Hi Burcin, I am sorry if I have hurt you by my earlier statements in this thread. Best, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Catalan Numbers
You could make the ultimate "proof-without-words" submission!
I think this is cool, and although I am not a combinatorics person at
all it seems reasonable as an addition to sage. I think it could
underpin a really fantastic @interact.
-Marshall
On Jul 23, 1:20 am, Tom Boothby wrote:
> Richard Stanley currently lists 172 combinatorial interpretations of
> the Catalan numbers. I've been doing some research on Coxeter groups
> this summer, and we recently found that a class of permutations in S_n
> which are counted by the Catalan numbers. Turns out, the permutations
> are just the 321-avoiding permutations. A research partner, Matt
> Macauley noted that when one finds objects counted by the Catalan
> numbers, that it can be interesting to see what other objects they
> might correspond to.
>
> In particular, we've got a subset of the 321-avoiding permutations
> that we want to investigate. If there's a nice bijection between
> 321-avoiding permutations, and say, Dyck paths, we'd like to look at
> the Dyck paths which correspond to this special subset. So, I've
> started going down Stanley's list and hacking up as many bijections as
> I can devise between the objects he's listed. At the present, I can
> generate the following given, say, a Dyck word (one can generate these
> in Sage), and draw nice pictures of them all. Further, almost all of
> them are strongly connected -- given almost any object below, I can
> create any of the others. (though my constructions are bijective, I
> haven't coded both ways for a couple of them)
>
> These reference Stanley's numbering scheme, see [1] and [2]
>
> (c) binary trees on n vertices
> (h) lattice paths from (0,0) to (n,n) below x=y
> (i) Dyck paths from (0,0) to (n,0) above x=0
> (o) non-crossing matchings of [2n]
> (r) valid strings of parentheses (description in text differs by '('
> <-> 1, ')' <-> -1)
> (ff) 231-avoiding permutations (hah -- but I don't have 321-avoiding
> permutations yet -- I found these by a lucky guess)
> (pp) non-crossing partitions of [n]
> (tt) non-crossing partitions of [2n+1] into n+1 parts with
> nonconsecutive entries
> (hhh) stacks of coins
> (z^4) non-nesting matchings of [2n]
>
> I'm mostly doing this for research and for pleasure, but since I'm
> doing the research with a few partners, the code is readable. I'm
> wondering: is there sufficient interest for this to be added to Sage?
> If I manage to construct even a quarter of the bijections listed, it
> will be a rather large amount of code. I'd like some input from the
> combinat people as to what sort of interface would be appropriate.
>
> Thanks,
>--tom
>
> Note: the attached is a sample image of my current constructions --
> the binary trees are particularly ugly, but they're drawn that way to
> make the bijection between (r) and (c) clear. Also, the objects look
> much better when plotted on their own, but I couldn't figure out how
> to get a graphics_array to fix the aspect ratio for the individual
> images.
>
> [1]http://math.mit.edu/~rstan/ec/catalan.pdf
> [2]http://math.mit.edu/~rstan/ec/catadd.pdf
>
> catalan.png
> 26KViewDownload
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: CoMarketing: Sage & Sun
On Mon, 20 Jul 2009 at 05:31AM -0700, Jason Grout wrote: > I don't have any marketing ideas at the moment beyond what has already > been mentioned. However, I do have to say that if there was a > reasonably-priced, pre-configured sage notebook server box from Sun, it > would be *very* tempting (emphasis on the "reasonably-priced" above, > though :). > > Such a box would be very tempting if: > > * you could run multiple notebooks with proper security layers between > themselves and the system. > * it was trivial to upgrade all of the notebooks or just some of them. > * you could also do development on some of the notebooks. > * all (or at least most) optional spkgs worked > * it would be easy for IT to administer the server centrally (e.g., a > rack version, as well as a standalone box version) Just this morning I was talking to my department head about possibly setting up a "real" Sage server for our campus (i.e., something more than a VM running on the computer in my office) and this sort of product would be great. Right now you need some knowledgeable and tech-inclined people and a department head who is very understanding and/or trusting; with a "Sage in a box" machine, it would be easier to for people with skeptical IT staff or department heads to get a nice server setup. Dan -- --- Dan Drake - KAIST Department of Mathematical Sciences --- http://mathsci.kaist.ac.kr/~drake signature.asc Description: Digital signature
[sage-devel] spkg dependencies + graph layouts
Partly out of curiosity, I've tried to make a graph of Sage's spkg dependencies: http://www.sagenb.org/home/pub/673/ Can anyone recommend settings for laying out this graph elegantly in Sage? I've also experimented a bit with NetworkX, but my ignorance here is deep. GraphViz, which happens to be installed on my machine, seems to do well, but it would be great to be able to style the vertices and edges natively. For example, I could use one color for packages written mostly in pure Python and others for Cython, C / C++, Fortran, and JavaScript. Styled edges might represent different Makefile commands in a more general graph. It would be cool if we could update the graph in real-time with information about an ongoing build... --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Notebook translation tips
On Wed, 22 Jul 2009 at 10:32PM -0700, William Stein wrote: > On Wed, Jul 22, 2009 at 2:03 AM, Sergey Semerikov wrote: > > > > I tried to translate the interface of the notebook using gettext and > > faced with the need to make several changes to the source code: > > Thanks for working on this!! > > (1) What is gettext? I've never heard of it? My (vastly incomplete) understanding is that gettext makes string translations easy. You write your program so that instead of just printing something, it calls a string-printing function. That function knows what language should be used, so it looks up the right string and prints that. It makes it easy for people to contribute translations; you have a list of strings, probably in a "base" language (for us, that'd be English) and it's easy for someone to get that list, translate everything into some new language, and we just ship that along with our code. I would *love* to have better support for this. Dan -- --- Dan Drake - KAIST Department of Mathematical Sciences --- http://mathsci.kaist.ac.kr/~drake signature.asc Description: Digital signature
[sage-devel] Re: Catalan Numbers
On Wed, 22 Jul 2009 at 11:20PM -0700, Tom Boothby wrote: [...] > I'm mostly doing this for research and for pleasure, but since I'm > doing the research with a few partners, the code is readable. I'm > wondering: is there sufficient interest for this to be added to Sage? > If I manage to construct even a quarter of the bijections listed, it > will be a rather large amount of code. I'd like some input from the > combinat people as to what sort of interface would be appropriate. I don't know about an interface, but I'd like to see this in Sage. I work with Catalan stuff all the time. Dan -- --- Dan Drake - KAIST Department of Mathematical Sciences --- http://mathsci.kaist.ac.kr/~drake signature.asc Description: Digital signature
[sage-devel] Sage 4.1 succeeds on SuSE 10.1 (SLES/SLED 10)
For those, who like legacy systems: Sage 4.1 builds on SuSE 10.1 (binary compatible to SuSE Enterprise 10) 32bit: http://sage.math.washington.edu/home/dreyer/suse101/ Remark: gcc 4.1.2 from SLED 10 SP2 is necessary, as gcc 4.1.0 is quite buggy.) Regards, Alexander --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] New Riemann mapping package/patch
My project is nearing completion. It provides Riemann mapping capabilities (http://en.wikipedia.org/wiki/Riemann_mapping_theorem). it produces both numerical data on the map, and useful (and pretty) graphs to show how it works. I also created a couple of interpolators that allow you to interpolate a list of complex points as a parametric curve, either as a polygon or with cubic splines. This makes it easier for users to define the figures that they wish to map. The Riemann Mappping stuff is about 700 lines with documentation, and the interpolators about 100. These are my questions: Does this sound like the type if thing that should be included in sage? If so, should I make it a package or patch? I incorporated and repurposed a lot of Robert Bradshaw's complex_plot code. How should I cite him in the copyright box at the top of the file? Thanks, Ethan --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: New Riemann mapping package/patch
Hi Ethan, On Fri, Jul 24, 2009 at 12:19 AM, Ethan Van Andel wrote: > > My project is nearing completion. It provides Riemann mapping > capabilities (http://en.wikipedia.org/wiki/Riemann_mapping_theorem). > it produces both numerical data on the map, and useful (and pretty) > graphs to show how it works. I also created a couple of interpolators > that allow you to interpolate a list of complex points as a parametric > curve, either as a polygon or with cubic splines. This makes it easier > for users to define the figures that they wish to map. The Riemann > Mappping stuff is about 700 lines with documentation, and the > interpolators about 100. > > These are my questions: > > Does this sound like the type if thing that should be included in > sage? If so, should I make it a package or patch? Yes, absolutely. But make sure that you agree to license your work under GPLv2+ or a compatible license. So if I understand you correctly, your whole project is less than 1000 lines of code and documentation combined. In that case, a patch is more appropriate than a package. But you then need to figure out where to patch against. > I incorporated and repurposed a lot of Robert Bradshaw's complex_plot > code. How should I cite him in the copyright box at the top of the > file? You can cite Robert to the effect that your code is based upon or portions of which are adapted from his complex_plot code. -- Regards Minh Van Nguyen --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: New Riemann mapping package/patch
> under GPLv2+ or a compatible license. So if I understand you > correctly, your whole project is less than 1000 lines of code and > documentation combined. In that case, a patch is more appropriate than > a package. But you then need to figure out where to patch against. Yeah, that was another thing I meant to ask. Where should I put this stuff? Ethan --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: New Riemann mapping package/patch
Hi Ethan, On Fri, Jul 24, 2009 at 12:40 AM, Ethan Van Andel wrote: > >> under GPLv2+ or a compatible license. So if I understand you >> correctly, your whole project is less than 1000 lines of code and >> documentation combined. In that case, a patch is more appropriate than >> a package. But you then need to figure out where to patch against. > > Yeah, that was another thing I meant to ask. Where should I put this > stuff? The only place I can think of is under sage/calculus. But don't trust me on this as I know next to nothing about your project or the maths involved. -- Regards Minh Van Nguyen --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Patches for Linear Programming in SAGE - GLPK and COIN-OR
Hello everybody !!! I am sending a message here to get in touch with those who may be interested in LP/MIP features in SAGE. I finally wrote a first version of it, which uses GLPK by default and COIN-OR if installed ( you can change the solver you want to use easily, though ). In the case you would like to help a bit by reviewing the changes ( or more, as it could take some time to get it all perfect ), you will find the patches at these adresses : SPKG : COIN-OR / CBC for Sage http://trac.sagemath.org/sage_trac/ticket/6603 SPKG : GLPK for Sage http://trac.sagemath.org/sage_trac/ticket/6602 Patch : numerical.mip Class http://trac.sagemath.org/sage_trac/ticket/6502 Thank you all for your help ;-) Nathann Cohen --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Is new symbolic derivative really worth the efforts?
On Thu, 23 Jul 2009 11:25:35 + Golam Mortuza Hossain wrote: > > Hi Burcin, > > I am sorry if I have hurt you by my earlier statements in this thread. As William said, no worries. I am sorry if my message sounded personal. I was just trying to point out that I don't agree with your proposal and William's +1 vote to change the default behavior of symbolic derivatives. I didn't have time to go over the e-mail again, and check/adjust the tone. I am not opposed to having the unevaluated diff as an alternative operator. Cheers, Burcin --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Sage 4.1 compilation problem
I compiled Sage on two nearly identical machines at school. One
succeeded, the other failed building givaro (see make output below).
I did a quick Google search on the error message, and one author called
this the "dangling extern "C" syndrome." Sure enough, the givaro header
(see below) has an extern "C" section enclosing an include of
gmp.h -- which #include's C++ libraries. I thought I had a decent
knowledge of C/C++, and I don't see how this could have *worked* on the
other machine. I'm using GCC 4.1.2 on both machines.
Any help or hints are appreciated. Thanks!
- Ryan
-- make output --
g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../.. -DGMP_VERSION_3
-I../../../src/kernel/memory -I../../../src/kernel/system
-I/path/sage-4.1/local//include -fPIC -I/path/sage-4.1/local/include -MT
gmp++_int_div.lo -MD -MP -MF .deps/gmp++_int_div.Tpo -c gmp++_int_div.C
-fPIC -DPIC -o .libs/gmp++_int_div.o
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux/bits/c++locale.h:67:
error: template with C linkage
... (lots of similar errors)
make[5]: *** [gmp++_int_div.lo] Error 1
make[5]: Leaving directory
`/path/sage-4.1/spkg/build/givaro-3.2.13rc2/src/src/kernel/gmp++
-- end make output --
Here is the source code that I think is causing the problem:
-- gmp++.h --
#ifdef __GIVARO_GMP_VERSION_3
extern "C" {
#endif
#include "gmp.h"
#ifdef __GIVARO_GMP_VERSION_3
}
#endif
-- end gmp++.h snippet --
and then has
-- gmp.h --
#if defined (__cplusplus)
#include/* for std::istream, std::ostream, std::string */
#include
#endif
-- end gmp.h snippet --
My configuration:
-- shell --
$ g++ -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)
$ uname -srp
Linux 2.6.29-2 x86_64
-- end shell --
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: C graph backend
Jason, > Do you have a todo list of what needs to be done to get the C graph backend > as the default backend? Technically nothing -- if you switch all the default function arguments from implementation='networkx' to implementation='c_graph', all the doctests pass (I think you need sage-4.1.1.alpha0). This took over a month of nonstop work-- I was in Europe too, so we're talking frequent twelve hour days, no family... > Also, I noticed that there is a huge difference between getting the in and > out neighbors of a vertex in a digraph, and the incoming edges for sparse C > graphs take 1.5 times as long as either the outgoing edges or networkx > (either direction). This is one of the reasons that they're not default now-- several functions are still slower than NetworkX. First of all, in_neighbors for SparseGraphs are their own issue (see #2): 1. The SparseGraph and DenseGraph datastructures themselves are significantly faster than the corresponding backends: sage: a=graphs.PathGraph(1000).to_directed().copy(implementation='c_graph') sage: b=a._backend sage: c=b._cg sage: %timeit L = list(b.iterator_out_nbrs(30)) 10 loops, best of 3: 5.67 µs per loop sage: %timeit L = list(c.out_neighbors(30)) 100 loops, best of 3: 1.47 µs per loop This is because the current state of the backends are *working,* not *fast.* 2. SparseGraphs are by their nature directed -- this is part of the data structure. Probably the best way to have fast in_neighbors functions is to store two SparseGraphs, but this would double the run time of every other operation. You reviewed the original SparseGraph patch, so you probably understand why this is the case-- all edges coming out of a vertex are stored together, but edges coming into a given vertex could be all over the place. 3. If you (or anyone else interested in getting faster graphs in Sage) wanted to put in some work to get things ready to switch over, one thing that would be very useful is to grep through the SparseGraphBackend and DenseGraphBackend for "iter": this is likely the worst bottleneck, and should be the first to get fixed. Since Cython doesn't yet support the "yield" statement, I had to use the "iter" command to quickly get working code. What would be much better would be to implement Cython classes just for iterating through the different things that happen in backends. Even SparseGraphs and DenseGraphs themselves could use some "yield/iter - love" -- I bet you could get some significant speedups in those classes too. I've made this last one a trac ticket, and I see this as the next big step: http://trac.sagemath.org/sage_trac/ticket/6604 -- Robert L. Miller http://www.rlmiller.org/ --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: spkg dependencies + graph layouts
> Can anyone recommend settings for laying out this graph elegantly in > Sage? I've also experimented a bit with NetworkX, but my ignorance here > is deep. Posets! See: http://www.sagenb.org/home/pub/674/ --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: iGraph in SAGE?!
Johannes, I'm forwarding this to sage-devel, as there are probably a lot more developers than just myself who are interested in this! On Thu, Jul 23, 2009 at 7:51 AM, Johannes Reichold wrote: > Dear Robert, > > I am a once-in-a-while user of SAGE and just browsed through sage-devel, > reading that you are currently implementing c_graphs. > I don't know how far you have progressed already, but I just wanted to draw > your attention to iGraph (http://igraph.sourceforge.net/index.html). > "igraph is a free software package for creating and manipulating undirected > and directed graphs. It includes implementations for classic graph theory > problems like minimum spanning trees and network flow, and also implements > algorithms for some recent network analysis methods, like community > structure search." > It also has Python bindings, which would probably make it very suitable for > SAGE. > > Sorry for the noise if this is all known to you / unsuitable / too late. > > Best, > Johannes > > -- Robert L. Miller http://www.rlmiller.org/ --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: CoMarketing: Sage & Sun
Regarding Sage running on a server: some of the components may be sufficiently general as to pose hazards in a server environment. For example, Maxima can create and delete files, quickly fill up all available memory, etc. I would guess that other components are also hazardous. It seems to me that the only practical solution is to run Sage in a virtual machine on the server, which may be costly. Is that what is being proposed? Is that what UW Sage servers are doing? Regarding Sage adoption by schools -- there is a large literature on computer algebra and teaching. The evidence I've seen at Berkeley is that the curriculum is already "full". Adding a section of "computing with Sage" to (say) calculus, prompts the response from instructors: "what will we REMOVE from calculus". (I usually say "logarithmic derivatives" :) ) If there is an instructor who is excited by a computer program (could be one of the M's) he/she can introduce it into the course in some way, sometimes. Evidence at Berkeley is that when that instructor is not teaching the course, the computer stuff falls into disuse. Students using Mathematica get it (essentially) free for their own laptops at their dorm room. Those that use it seem to be unconcerned about it being proprietary. They are only occasionally concerned that it gets the answers wrong sometimes. While the enthusiastic teacher may think that Sage will enrich the course and allow the instructor to demonstrate wonderful and interesting things, and allow the students to explore new worlds and go where no person has gone before, the evidence I've seen published is that (a) students don't learn anything more from course X + computer lab vs. course X; (b) students view the computer enrichment as something else to learn -- additional material. Also note that half the class is below average. Will using Sage help weak students? Also for many students, math courses are an (unwelcome) requirement. Will they change because of Sage? Any instructor who has been asked, after a particularly beautifully delivered lecture/demonstration, "Will this be on the final?" may have to say, oh, I guess not. You won't be using a computer during the final. Of course there are some students who are wonderful, interested, creative, energetic, clever, and they may love Sage, etc. I think they should be provided great opportunities. If a student just doesn't understand (say) what is a function, or what is a group, will a computer program help? .. If you haven't looked at the literature, I did some googling... Here's one article with lots of references. Heid, M. Kathleen and Edwards, Michael Todd(2001)'Computer Algebra Systems: Revolution or Retrofit for Today's Mathematics Classrooms?',Theory Into Practice,40:2,128 — 136 URL: http://dx.doi.org/10.1207/s15430421tip4002_7 ... perhaps closer to the heart of Sage is Using the Magma Computer Algebra System in Abstract Algebra Courses JOHN CANNON and CATHERINE PLAYOUST Journal of Symbolic Computation Volume 23, Issues 5-6, May 1997, Pages 459-484 which I found particularly informative. I highly recommend reading it. There are many juicy revelations. Since you may not have access to a copy, I quote just 2 sentences from that article, "From earlier experiences in tertiary mathematics, many students felt that it was possible to pass mathematics courses with minimal attendance at lectures and tutorials. Approximately half of the students did a negligible amount of private study during the semester." What I found particularly telling, is that the data they collected showed the students really didn't want to do this computer stuff. And from this, the authors took an enormous leap of faith to conclude that therefore the programs should be improved. Cheers RJF --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Solaris issue: Pari / modified sage library code
2009/7/22 Dr. David Kirkby : > > John Cremona wrote: >> If by "this code" you mean paripriv.h then that belongs to pari, i.e. >> is upstream. But sage/ext/fast_callable.c will have been written by >> someone who subscribes to this list, I hope! >> >> John > > But the build of pari works fine, including the lines in paripriv.h. If > the code is commented out, pari will not build. Hence I personally don't > feel happy to report this to the pari developers, as I don't understand > why the code is implemented in the first place. The person(s) that wrote > this code, would be in a much better position than me to make a good > statement to the pair developers - if it is their fault at all, which I > somewhat doubt myself. I don't think I explained well what I meant. Certainly, the pari code is fine as it is. But when that include file is included by another file, it may be that some macros have been defined in that environment which change the content of those 3 lines. e.g. in line 258: GEN ZY_ZXY_resultant_all(GEN A, GEN B0, long *lambda, GEN *LPRS); The macro cannot be GEN or A or B or lambda since they occur on other lines which cause no trouble. It is most unlikely to be the function name! But it could be LPRS. I think that to debug this you would need to give the compile command which caused the error: gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall (etc etc) and add the flag "-E" which means " Preprocess only; do not compile, assemble or link", pipe the (long) output of that to a file and search it for where paripric.h is included. That might tell you whether the file has been corrupted by macro definitions as I suspect. If this works, then the next step will be to find out where the offending macros are defined and then who wrote that code and then get the macros changed... John > > Dave > >> >> 2009/7/22 Dr. David Kirkby : >>> John Cremona wrote: >>> Line 428 defines an enum struct which is only relevant for gp. The earlier two have no numeric constants that I can see but the function prototypes have variables in upper case, and it's possible that these are macros which are getting expanded into numbers. John >>> Thank you John, >>> >>> I still don't feel happy about debugging this code, which I don't >>> understand at all. Perhaps someone who has some idea what is is all >>> supposed to be doing can look at it. I assume this is code which someone >>> reading this list probably wrote, rather than code which is buggy and >>> needs reporting to an upstream developer. >>> >>> Dave >>> 2009/7/22 Dr. David Kirkby : > Pari build fine on Solaris now. However, many packages later, there is a > failure when building the 'modified sage library code' which is related > to the inclusion of the pari header file > > $SAGE_HOME/local/include/pari/paripriv.h > > There are according to gcc on Solaris a problem with this file. I see > the exact same issue on t2 as I do on my home machine and William has > said he has seen it on OpenSolaris too. > > gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall > -Wstrict-prototypes -fPIC > -I/export/home/drkirkby/sage/sage-4.1.1.alpha0/local//include > -I/export/home/dr kirkby/sage/sage-4.1.1.alpha0/local//include/csage > -I/export/home/drkirkby/sage/ sage-4.1.1.alpha0/devel//sage/sage/ext > -I/export/home/drkirkby/sage/sage-4.1.1.a lpha0/local/include/python2.6 > -c sage/ext/fast_callable.c -o build/temp.solaris- > 2.10-sun4u-2.6/sage/ext/fast_callable.o -w > In file included from sage/ext/fast_callable.c:141: > /export/home/drkirkby/sage/sage-4.1.1.alpha0/local//include/pari/paripriv.h:258: > error: expected ';', ',' or ')' before numeric constant > /export/home/drkirkby/sage/sage-4.1.1.alpha0/local//include/pari/paripriv.h:259: > error: expected ';', ',' or ')' before numeric constant > In file included from sage/ext/fast_callable.c:141: > /export/home/drkirkby/sage/sage-4.1.1.alpha0/local//include/pari/paripriv.h:428: > error: expected identifier before numeric constant > error: command 'gcc' failed with exit status 1 > sage: There was an error installing modified sage library code > ERROR installing SAGE > > real 43m59.533s > user 42m14.541s > sys 1m30.477s > sage: An error occurred while installing sage-4.1.1.alpha0 > > Commenting out lines 258, 259 and 428 in the pari header file allows the > "modified sage library code" to build, but it's probably not the right > thing to do. Trying to build pari with those lines commented out fails, > as pari does reference them. > > It's a bit difficult to report this to the pari developers, as their > code works fine - it is the inclusion of one of their header files in > the modified sage library which is causing the problem. > > The file that includes the header file is > $SAGE_
[sage-devel] Re: iGraph in SAGE?!
On Thu, Jul 23, 2009 at 9:19 AM, Robert Miller wrote: > > Johannes, > > I'm forwarding this to sage-devel, as there are probably a lot more > developers than just myself who are interested in this! I looked at it briefly, and noticed that it has an implementation of two graph isomorphism testing algorithms, neither of which is McKay's algorithm. One algorithm is callled VF2. I think found a paper http://amalfi.dis.unina.it/people/vento/lavori/gbr01bm.pdf that benchmarks various algorithms, and concludes that in many cases VF2 is faster than McKay's, and in other cases McKay's is faster than VF2. "In particular, for randomly connected graphs, the Nauty algorithm is the better if the graphs are quite dense and/or of quite large size. For smaller and quite sparse graphs, on the contrary, VF2 performs better. On more regular graphs, i.e. on 2D meshes, VF2 is definitely the best algorithm: in this case the Nauty algorithm is even not able to find a solution for graphs bigger than few dozens of nodes. " Anyway, I learned something. -- William > > On Thu, Jul 23, 2009 at 7:51 AM, Johannes > Reichold wrote: >> Dear Robert, >> >> I am a once-in-a-while user of SAGE and just browsed through sage-devel, >> reading that you are currently implementing c_graphs. >> I don't know how far you have progressed already, but I just wanted to draw >> your attention to iGraph (http://igraph.sourceforge.net/index.html). >> "igraph is a free software package for creating and manipulating undirected >> and directed graphs. It includes implementations for classic graph theory >> problems like minimum spanning trees and network flow, and also implements >> algorithms for some recent network analysis methods, like community >> structure search." >> It also has Python bindings, which would probably make it very suitable for >> SAGE. >> >> Sorry for the noise if this is all known to you / unsuitable / too late. >> >> Best, >> Johannes >> >> > > > > -- > Robert L. Miller > http://www.rlmiller.org/ > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.1 compilation problem
On Thu, Jul 23, 2009 at 8:27 AM, Ryan Hinton wrote:
>
> I compiled Sage on two nearly identical machines at school. One
> succeeded, the other failed building givaro (see make output below).
It might also be worth emailing the author(s) of Givaro:
http://www-lmc.imag.fr/CASYS/LOGICIELS/givaro/
>
> I did a quick Google search on the error message, and one author called
> this the "dangling extern "C" syndrome." Sure enough, the givaro header
> (see below) has an extern "C" section enclosing an include of
> gmp.h -- which #include's C++ libraries. I thought I had a decent
> knowledge of C/C++, and I don't see how this could have *worked* on the
> other machine. I'm using GCC 4.1.2 on both machines.
>
> Any help or hints are appreciated. Thanks!
>
> - Ryan
>
> -- make output --
> g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../.. -DGMP_VERSION_3
> -I../../../src/kernel/memory -I../../../src/kernel/system
> -I/path/sage-4.1/local//include -fPIC -I/path/sage-4.1/local/include -MT
> gmp++_int_div.lo -MD -MP -MF .deps/gmp++_int_div.Tpo -c gmp++_int_div.C
> -fPIC -DPIC -o .libs/gmp++_int_div.o
> /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux/bits/c++locale.h:67:
> error: template with C linkage
> ... (lots of similar errors)
> make[5]: *** [gmp++_int_div.lo] Error 1
> make[5]: Leaving directory
> `/path/sage-4.1/spkg/build/givaro-3.2.13rc2/src/src/kernel/gmp++
> -- end make output --
>
> Here is the source code that I think is causing the problem:
>
> -- gmp++.h --
> #ifdef __GIVARO_GMP_VERSION_3
>
> extern "C" {
>
> #endif
>
>
>
> #include "gmp.h"
>
>
>
> #ifdef __GIVARO_GMP_VERSION_3
>
> }
>
> #endif
>
> -- end gmp++.h snippet --
>
> and then has
>
> -- gmp.h --
> #if defined (__cplusplus)
>
> #include /* for std::istream, std::ostream, std::string */
>
> #include
>
> #endif
>
> -- end gmp.h snippet --
>
> My configuration:
>
> -- shell --
> $ g++ -v
> Using built-in specs.
> Target: x86_64-redhat-linux
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --enable-checking=release --with-system-zlib --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-libgcj-multifile
> --enable-languages=c,c++,objc,obj-c++,java,fortran,ada
> --enable-java-awt=gtk --disable-dssi --enable-plugin
> --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
> --with-cpu=generic --host=x86_64-redhat-linux
> Thread model: posix
> gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)
>
> $ uname -srp
> Linux 2.6.29-2 x86_64
> -- end shell --
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: C++ and Cython
> 1) Do you have any priorities for features you'd like to see sooner > rather than later? While debugging and fixing an issue in the current PolyBoRi wrapper with Alexander Dreyer we noticed the following behaviour in Cython which doesn't mix well with C++: Consider the following code: cdef BoolePolyRing ring = pbenv_ring() where pbenv_ring() returns a reference to the currently active PolyBoRi ring. This is fine because Cython doesn't care whether a variable or a reference is returned. However, Cython re-arranges the code as follows internally: cdef BoolePolyRing ring ring = pbenv_ring() This is fine if BoolePolyRing is a C data structure because in C declaration is never code execution. However, this is not fine in C++ where declaration may be code execution: the default constructor. (In our case the default constructor for BoolePolyRing would define a new ring and mark it as active and thus render the later assignment useless) So my nr.1 feature request is to not re-arrange declarations if C++ is the language Cython compiles to. Cheers, 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 email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Singular and Sage
Hi there, as mentioned earlier I am visiting the Singular team this week in Kaiserslautern. On the technical side we worked on - updating to Singular 3-1-04 where it was very valuable to have both Sage and Singular developers within shouting distance, - updating to PolyBoRi 0.6 which wouldn't have been possible without the two teams present in person (we had to change both sides to make it work) - better integration of libSingular which soon will allow calling Singular library functions (not written in C) via libSingular, cf. libgap (Michael Brickenstein is working on this) - other convenient stuff like fast normal forms and docstring extraction. == new mailinglist == Right now I am the main person working on linking against Singular on a C/C++ level. This is insufficient, well, because I don't get enough stuff done. To support the development we started a new mailing list [libsingular-devel] at http://groups.google.com/group/libsingular-devel which should host discussions between Sage and Singular and anyone interested in linking against Singular. At first the name [sage-singular] was suggested but we figured we should keep it more open to other projects as well. So if there is stuff in Singular which you'd like to see properly wrapped in Sage, this is the mailing list to discuss it etc. Examples of this are: - submodules of free modules over polynomial rings, - non-commutative algebras, - quotient rings, - rational function fields - etc. Btw. I am also currently refactoring the libSingular stuff to make it easier to accomplish the above, cf. http://trac.sagemath.org/sage_trac/ticket/6596 == coercion == The Singular team is thinking about a C++ wrapper for their native data structures (and others) to make development in the Singular kernel easier. Thus we discussed how we wrap Singular in our object oriented structure in Sage. One point of interest was the coercion system. Robert, David, etc. are the 'rules' used for coercion written up somewhere or would one have to read the code to 'get' it? By rules I mean how to find a common ring for two rings etc. == credit == The situation with giving credit was again a topic of discussion. There are no hard feelings: the Singular team knows that we are doing what we can to give 'upstream' credit. However, it is a permanent concern not only for them. Btw. didn't we have some experimental patch at some point which would try to trace the subsystems involved in a calculation? == other ideas == An idea which wasn't really discussed but mentioned was to use a re-branded stand-alone Sage notebook as the Singular GUI. Furthermore the option of making Sage's Cython interface to Singular more independent was briefly discussed. All this stuff is far from being settled, just ideas to play with. Cheers, Martin PS: My final slides are available at http://bit.ly/ng3Xl -- 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 email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Singular and Sage
Martin Albrecht wrote: > Hi there, > > as mentioned earlier I am visiting the Singular team this week in > Kaiserslautern. On the technical side we worked on > > - updating to Singular 3-1-04 where it was very valuable to have both Sage > and > Singular developers within shouting distance, As a quick note, I found a problem with the singular build system. Perhaps you could forward it to the most appropriate person. First, there are 7 identical copies of install-sh $ find . -name install-sh ./libfac/install-sh ./kernel/install-sh ./Singular/install-sh ./omalloc/install-sh ./factory/bin/install-sh ./install-sh ./svd/install-sh But more to the point, there is a problem, in that in one case, there is a path to install-sh which is not valid. This is only seen on Solaris, which someone else believes is because linux will have install-sh in the path, so that would be used. make[1]: Entering directory `/export/home/drkirkby/sage/sage-4.1/spkg/build/singular-3-1-0-2-20090620/src/kernel' ./mkinstalldirs /export/home/drkirkby/sage/sage-4.1/local/include/singular for file in *.h; do ../.././install-sh -c $file /export/home/drkirkby/sage/sage-4.1/local/include/singular; done /bin/sh: ../.././install-sh: not found /bin/sh: ../.././install-sh: not found /bin/sh: ../.././install-sh: not found /bin/sh: ../.././install-sh: not found /bin/sh: ../.././install-sh: not found /bin/sh: ../.././install-sh: not found /bin/sh: ../.././install-sh: not found /bin/sh: ../.././install-sh: not found /bin/sh: ../.././install-sh: not found Changing to the directory `/export/home/drkirkby/sage/sage-4.1/spkg/build/singular-3-1-0-2-20090620/src/kernel' and doing an 'ls' of ../.././ I see that it got me to the root directory of the singular installation - by that I mean where spkh-install, SPKG.txt etc exist. This is ABOVE the top level directory of the normal singular code. Copying install-sh to there solved the problem, but clearly there is some issue here. Dave --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Singular and Sage
On Thu, Jul 23, 2009 at 1:14 PM, Martin Albrecht wrote: > > Hi there, > > as mentioned earlier I am visiting the Singular team this week in > Kaiserslautern. On the technical side we worked on > > - updating to Singular 3-1-04 where it was very valuable to have both Sage and > Singular developers within shouting distance, > Excellent! > - updating to PolyBoRi 0.6 which wouldn't have been possible without the two > teams present in person (we had to change both sides to make it work) Excellent too! > > - better integration of libSingular which soon will allow calling Singular > library functions (not written in C) via libSingular, cf. libgap (Michael > Brickenstein is working on this) Very nice. By the way, if anybody wants to start working on libgap, I did a lot but ran out of steam/interest, and hope somebody else will volunteer to look at it. If you like nicely documented interpreters and speeding up much in Sage that uses GAP by a huge amount, this is the project for you. > - other convenient stuff like fast normal forms and docstring extraction. > > == new mailinglist == > > Right now I am the main person working on linking against Singular on a C/C++ > level. This is insufficient, well, because I don't get enough stuff done. To > support the development we started a new mailing list [libsingular-devel] at > > http://groups.google.com/group/libsingular- I've joined and cc'd this message there. > > which should host discussions between Sage and Singular and anyone interested > in linking against Singular. At first the name [sage-singular] was suggested > but we figured we should keep it more open to other projects as well. That makes sense. And we could always have a sage-singular mailing list at some point in the future if need be. > So if there is stuff in Singular which you'd like to see properly wrapped in > Sage, this is the mailing list to discuss it etc. Examples of this are: > > - submodules of free modules over polynomial rings, > - non-commutative algebras, > - quotient rings, > - rational function fields > - etc. > > Btw. I am also currently refactoring the libSingular stuff to make it easier > to accomplish the above, cf. http://trac.sagemath.org/sage_trac/ticket/6596 > > == coercion == > > The Singular team is thinking about a C++ wrapper for their native data > structures (and others) to make development in the Singular kernel easier. > Thus we discussed how we wrap Singular in our object oriented structure in > Sage. One point of interest was the coercion system. > > Robert, David, etc. are the 'rules' used for coercion written up somewhere or > would one have to read the code to 'get' it? By rules I mean how to find a > common ring for two rings etc. As Robert's thesis adviser, I hereby strongly encourage him to publish a short (?) research paper explaining the Sage coercion model. I think such a paper would be easy to get published. > == credit == > > The situation with giving credit was again a topic of discussion. There are no > hard feelings: the Singular team knows that we are doing what we can to give > 'upstream' credit. However, it is a permanent concern not only for them. > > Btw. didn't we have some experimental patch at some point which would try to > trace the subsystems involved in a calculation? Mike Hansen wrote it, and I think it's in Sage. But I can't remember the command name. > > == other ideas == > > An idea which wasn't really discussed but mentioned was to use a re-branded > stand-alone Sage notebook as the Singular GUI. That would be excellent. > Furthermore the option of > making Sage's Cython interface to Singular more independent was briefly > discussed. All this stuff is far from being settled, just ideas to play with. That's a good idea.It could yield an alternative faster Singular interpreter interface that depends only on Python/Cython, and hence is much more lightweight than Sage. > Cheers, > Martin > > PS: My final slides are available at http://bit.ly/ng3Xl > -- > 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 > > > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Singular and Sage
On Thu, Jul 23, 2009 at 09:28:12PM +0100, Dr. David Kirkby wrote: > > Martin Albrecht wrote: > > Hi there, > > > > as mentioned earlier I am visiting the Singular team this week in > > Kaiserslautern. On the technical side we worked on > > > > - updating to Singular 3-1-04 where it was very valuable to have both Sage > > and > > Singular developers within shouting distance, > > As a quick note, I found a problem with the singular build system. > Perhaps you could forward it to the most appropriate person. > > First, there are 7 identical copies of install-sh > > $ find . -name install-sh > ./libfac/install-sh > ./kernel/install-sh > ./Singular/install-sh > ./omalloc/install-sh > ./factory/bin/install-sh > ./install-sh > ./svd/install-sh > > But more to the point, there is a problem, in that in one case, there is > a path to install-sh which is not valid. This is only seen on Solaris, > which someone else believes is because linux will have install-sh in the > path, so that would be used. > > make[1]: Entering directory > `/export/home/drkirkby/sage/sage-4.1/spkg/build/singular-3-1-0-2-20090620/src/kernel' > ./mkinstalldirs /export/home/drkirkby/sage/sage-4.1/local/include/singular > for file in *.h; do ../.././install-sh -c $file > /export/home/drkirkby/sage/sage-4.1/local/include/singular; done > /bin/sh: ../.././install-sh: not found > /bin/sh: ../.././install-sh: not found > /bin/sh: ../.././install-sh: not found > /bin/sh: ../.././install-sh: not found > /bin/sh: ../.././install-sh: not found > /bin/sh: ../.././install-sh: not found > /bin/sh: ../.././install-sh: not found > /bin/sh: ../.././install-sh: not found > /bin/sh: ../.././install-sh: not found Note that this usage of $(INSTALL) in kernel/Makefile is patched in by sage, so the issue doesn't manifest itself in Singular itself. It does seem that pointing to a parent directory as done in 'AC_OUTPUT([Makefile ../kernel/Makefile])' in Singular/configure.in is not really supported by autoconf. Singular avoids problem by using plain 'cp' to install files instead of $(INSTALL). See my post to the autoconf mailing list at http://lists.gnu.org/archive/html/autoconf/2009-07/msg00057.html and the reply at http://lists.gnu.org/archive/html/autoconf/2009-07/msg00060.html for more details. -Willem Jan --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Solaris issue: Pari / modified sage library code
John Cremona wrote: > 2009/7/22 Dr. David Kirkby : >> John Cremona wrote: >>> If by "this code" you mean paripriv.h then that belongs to pari, i.e. >>> is upstream. But sage/ext/fast_callable.c will have been written by >>> someone who subscribes to this list, I hope! >>> >>> John >> But the build of pari works fine, including the lines in paripriv.h. If >> the code is commented out, pari will not build. Hence I personally don't >> feel happy to report this to the pari developers, as I don't understand >> why the code is implemented in the first place. The person(s) that wrote >> this code, would be in a much better position than me to make a good >> statement to the pair developers - if it is their fault at all, which I >> somewhat doubt myself. > > I don't think I explained well what I meant. Certainly, the pari code > is fine as it is. But when that include file is included by another > file, it may be that some macros have been defined in that environment > which change the content of those 3 lines. > > e.g. in line 258: > GEN ZY_ZXY_resultant_all(GEN A, GEN B0, long *lambda, GEN *LPRS); > > The macro cannot be GEN or A or B or lambda since they occur on other > lines which cause no trouble. It is most unlikely to be the function > name! But it could be LPRS. > > I think that to debug this you would need to give the compile command > which caused the error: > gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall (etc etc) > > and add the flag "-E" which means " Preprocess only; do not compile, > assemble or link", pipe the (long) output of that to a file and search > it for where paripric.h is included. That might tell you whether the > file has been corrupted by macro definitions as I suspect. > > If this works, then the next step will be to find out where the > offending macros are defined and then who wrote that code and then get > the macros changed... > > John Is there anyone who feels more confident than me about trying to debug this? (i.e. I don't have much a of a clue.) I just done a rercursive grep (using the GNU version) for 'LPRS' in the whole of the contents of the sage-4.1.1.alpha0.spkg file (once extracted of course). I don't see a reference to LPRS. Neither is the function name 'ZY_ZXY_resultant_all' there. $ ggrep -R LPRS sage-4.1.1.alpha0 $ ggrep -R ZY_ZXY_resultant_all sage-4.1.1.alpha0 I also did the same for the Solaris header files (/usr/include) and the gcc header files (/usr/local/gcc-4.2.4-sun-linker/include), and don't see LPRS there either. In fact, greping the contents of $SAGE_HOME/spkg/build, the only references to them is in pari and maxima. Maxima has not been built yet, as I can't get ecl to build (another issue altogether). I have kept the intermediate files. So it's not clear to me where anything outside of pari might define something that causes the conflict. Dave --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Catalan Numbers
On Thu, Jul 23, 2009 at 8:20 AM, Tom Boothby wrote:
> Richard Stanley currently lists 172 combinatorial interpretations of
> the Catalan numbers. I've been doing some research on Coxeter groups
> this summer, and we recently found that a class of permutations in S_n
> which are counted by the Catalan numbers. Turns out, the permutations
> are just the 321-avoiding permutations. A research partner, Matt
> Macauley noted that when one finds objects counted by the Catalan
> numbers, that it can be interesting to see what other objects they
> might correspond to.
>
> In particular, we've got a subset of the 321-avoiding permutations
> that we want to investigate. If there's a nice bijection between
> 321-avoiding permutations, and say, Dyck paths, we'd like to look at
> the Dyck paths which correspond to this special subset. So, I've
> started going down Stanley's list and hacking up as many bijections as
> I can devise between the objects he's listed. At the present, I can
> generate the following given, say, a Dyck word (one can generate these
> in Sage), and draw nice pictures of them all. Further, almost all of
> them are strongly connected -- given almost any object below, I can
> create any of the others. (though my constructions are bijective, I
> haven't coded both ways for a couple of them)
>
> These reference Stanley's numbering scheme, see [1] and [2]
>
> (c) binary trees on n vertices
> (h) lattice paths from (0,0) to (n,n) below x=y
> (i) Dyck paths from (0,0) to (n,0) above x=0
> (o) non-crossing matchings of [2n]
> (r) valid strings of parentheses (description in text differs by '('
> <-> 1, ')' <-> -1)
> (ff) 231-avoiding permutations (hah -- but I don't have 321-avoiding
> permutations yet -- I found these by a lucky guess)
> (pp) non-crossing partitions of [n]
> (tt) non-crossing partitions of [2n+1] into n+1 parts with
> nonconsecutive entries
> (hhh) stacks of coins
> (z^4) non-nesting matchings of [2n]
>
> I'm mostly doing this for research and for pleasure, but since I'm
> doing the research with a few partners, the code is readable. I'm
> wondering: is there sufficient interest for this to be added to Sage?
> If I manage to construct even a quarter of the bijections listed, it
> will be a rather large amount of code. I'd like some input from the
> combinat people as to what sort of interface would be appropriate.
It would definitely be cool to have this in Sage. There is a sage-combinat
conference starting on Saturday, which I will be attending, and I'll make
sure to bring this up and ask about interface design.
Take care,
Franco
--
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: [sage-release] Re: Sage 4.1.1.alpha0 released
Hi Kiran,
On Fri, Jul 24, 2009 at 4:02 AM, Kiran Kedlaya wrote:
>
> Running make ptestlong (which I had never tried before on this
> machine), I see the following failures on 64-bit (Opteron) Fedora 10.
>
>sage -t -long devel/sage/sage/interfaces/r.py # 1 doctests
> failed
>sage -t -long devel/sage/sage/schemes/elliptic_curves/
> ell_rational_field.py # 0 doctests failed
>sage -t -long devel/sage/sage/schemes/elliptic_curves/
> sha_tate.py # 0 doctests failed
>sage -t -long devel/sage/sage/groups/perm_gps/partn_ref/
> refinement_matrices.pyx # 0 doctests failed
>
> The three "0 doctests failed" are timeouts; they pass when run
> individually. The R failure gave
> **
> File "/scratch/sage-4.1.1.alpha0/devel/sage-main/sage/interfaces/
> r.py", line 838:
>sage: r.completions('tes')
> Expected:
>['testPlatformEquivalence', 'testVirtual']
> Got:
>
>Building R command completion list (this takes
>a few seconds only the first time you do it).
>To force rebuild later, delete /home/r1/kedlaya/.sage//
> r_commandlist.sobj.
>['testPlatformEquivalence', 'testVirtual']
> **
> but passes if I run it again. However, if I then delete the file
> ~/.sage/r_commandlist.sobj, the failure reappears.
This has been fixed by ticket #6594
http://trac.sagemath.org/sage_trac/ticket/6594
--
Regards
Minh Van Nguyen
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Notebook translation tips
On Jul 23, 8:32 am, William Stein wrote:
> (1) What is gettext? I've never heard of it?
Good describe of gettext we can find in
http://docs.python.org/library/gettext.html
(23.1.3. Internationalizing your programs and modules). The main
advantage of such
way is an ability to change languages on the fly.
> (2) Thanks for making the list below. Now we need to figure out how
> to get this into Sage in an incremental way.
I did some steps:
1. First step: simply add
# -*- coding: utf-8 -*-
at first line of every .py-file. In run_notebook.py additionally
encoding
must be at lines 170-172:
config.write(_("""
# -*- coding: utf-8 -*-
Then I rewrite convert_seconds_to_meaningful_time_span (as described
in
first messages).
2. Next step: every string constant, which can be translated, was
converted
from
raise ValueError, 'invalid failure type'
to
raise ValueError, _('invalid failure type')
Before begin of the string add underscore and open bracket, after end
-
close bracket.
Changed files at step 1, 2, please, download from
http://semerikov.googlepages.com/notebook_modify.tar.bz2
3. Then we need to define function "_" as described in 23.1.3.1
in every module (I don't do it yet):
import gettext
t = gettext.translation('modulename', '/usr/local/sage/../locale')
_ = t.lgettext
all.py (or some main module) must contain
import gettext
gettext.install('applicationname', '/usr/local/sage/../locale',
unicode=1)
4. For every changed file running xgettext or Tools/i18n/pygettext.py:
python pygettext.py *.py
Resulting file (http://semerikov.googlepages.com/messages.pot) is an
template for any notebook translation. To do new translation you must
rename messages.pot at LANG_CODE.po (e.g., for Korean - kr.po) and
write translation in msgstr (empty in template):
#: avatars.py:65
msgid "invalid failure type"
msgstr ""
> (3) Somebody else just popped up on the sage list a few days ago who
> is moving all the html generation code to jinja templates.
Thanks, I don't touch html-templates.
> I don't have a lot of time to work on the notebook now, but will in Sept -
> Dec.
Steps 1-4 will produce only minor (cosmetic) code changes. I hope,
it
can be done quickly (the main reason - easy and fast translation: for
example,
try Korean/English notebook at http://math1.skku.ac.kr/).
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Singular and Sage
Willem Jan Palenstijn wrote:
> On Thu, Jul 23, 2009 at 09:28:12PM +0100, Dr. David Kirkby wrote:
>> make[1]: Entering directory
>> `/export/home/drkirkby/sage/sage-4.1/spkg/build/singular-3-1-0-2-20090620/src/kernel'
>> ./mkinstalldirs /export/home/drkirkby/sage/sage-4.1/local/include/singular
>> for file in *.h; do ../.././install-sh -c $file
>> /export/home/drkirkby/sage/sage-4.1/local/include/singular; done
>> /bin/sh: ../.././install-sh: not found
>> /bin/sh: ../.././install-sh: not found
>> /bin/sh: ../.././install-sh: not found
>> /bin/sh: ../.././install-sh: not found
>> /bin/sh: ../.././install-sh: not found
>> /bin/sh: ../.././install-sh: not found
>> /bin/sh: ../.././install-sh: not found
>> /bin/sh: ../.././install-sh: not found
>> /bin/sh: ../.././install-sh: not found
>
> Note that this usage of $(INSTALL) in kernel/Makefile is patched in by
> sage, so the issue doesn't manifest itself in Singular itself.
OK, thank you for that.
Given there appears to be a lot of things in the patches directory, why
does the singular package not follow the usual convention of a .p0, .p1
etc. The name of the .spkg seems a bit odd.
Looking at patches/kernel.Makefile.in.diff, I see:
--- ../Singular-3-1-0/kernel/Makefile.in2009-02-06
07:54:38.0 +
+++ kernel.Makefile.in 2009-05-12 18:20:10.0 +0100
@@ -292,7 +292,9 @@
install-libsingular:
${MKINSTALLDIRS} ${includedir}/singular
- cp *.h ${includedir}/singular
+ -for file in *.h; do \
+ ${INSTALL_PROGRAM} $$file ${includedir}/singular; \
+done
install: all installbin
That looks remarkably similar to the code that is broken. There's
nothing in SPKG.txt which tells me who made those changes, or why.
Clearly they have substituted 'cp' for the install program, and messed
up somewhere.
> It does seem that pointing to a parent directory as done in
> 'AC_OUTPUT([Makefile ../kernel/Makefile])' in Singular/configure.in is
> not really supported by autoconf. Singular avoids problem by using plain 'cp'
> to install files instead of $(INSTALL).
>
> See my post to the autoconf mailing list at
> http://lists.gnu.org/archive/html/autoconf/2009-07/msg00057.html
> and the reply at
> http://lists.gnu.org/archive/html/autoconf/2009-07/msg00060.html
> for more details.
>
>
> -Willem Jan
OK, thank you.
That means I should be able to get a better patch to this, than my hack
of leaving another copy of install-sh lying around. But it would be nice
to know who patched this and why. Why was 'cp' replaced by $(INSTALL_PROG)?
Dave
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Linking aged debtors report with MS Access
Hi, I'm really struggling with this one, 'All' I need is a single line of Aged Debtor analysis to appear on a form in Access, from a list of outstanding customer transactions, grouped by Current, 30 days, 60 days 90+ days, as the sage accounts does in the reports section. I have been playing around with the ms query on the sales ledger table but not sure how to get the transactions grouped into the appropriate 30, 60 90+ category. Any ideas on this one? --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: 4.1.1.alpha0 Installation just 'dying' for no known reason
Hi David, On Thu, Jul 23, 2009 at 7:29 PM, Dr. David Kirkby wrote: >> Now onto ATLAS. > > I won't expect to hear from you for another 8 hours or so then! > > I'm trying to add support for the later processors in ATLAS's code. Then > hopefully I can reduce the time it takes to install, once I have the > tuning data for the T2+ processor and I have ATLAS understanding what it > is. Currently it checks for various UltraSPARC CPUs, but the T2+ is not > one of them. The ATLAS SPKG atlas-3.8.3.p6 is successfully compiled on t2! -- Regards Minh Van Nguyen --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Linking aged debtors report with MS Access
Dear John, Unfortunately, this is the support list for the mathematics software Sage (http://www.sagemath.org), not the accounting software Sage. There seems to be some support at http://www.sagenorthamerica.com/support_training/ but that's the best we can direct you. Good luck! - kcrisman On Jul 23, 6:08 pm, John wrote: > Hi, > > I'm really struggling with this one, > 'All' I need is a single line of Aged Debtor analysis to appear on a > form in Access, from a list of outstanding customer transactions, > grouped by Current, 30 days, 60 days 90+ days, as the sage accounts > does in the reports section. > I have been playing around with the ms query on the sales ledger table > but not sure how to get the transactions grouped into the appropriate > 30, 60 90+ category. > > Any ideas on this one? --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: 4.1.1.alpha0 Installation just 'dying' for no known reason
Minh Nguyen wrote: > Hi David, > > On Thu, Jul 23, 2009 at 7:29 PM, Dr. David > Kirkby wrote: > > > >>> Now onto ATLAS. >> I won't expect to hear from you for another 8 hours or so then! >> >> I'm trying to add support for the later processors in ATLAS's code. Then >> hopefully I can reduce the time it takes to install, once I have the >> tuning data for the T2+ processor and I have ATLAS understanding what it >> is. Currently it checks for various UltraSPARC CPUs, but the T2+ is not >> one of them. > > The ATLAS SPKG atlas-3.8.3.p6 is successfully compiled on t2! > I thought ATLAS would build! I believe if you should be able to get up to the point where the sage-4.1.1.spkg gets going. I think the installation will fail there due to two separate bugs. At least now the impact of not fully tuning the ATLAS code will only be seen on sun4v machines, not all of them. Perhaps you can review the atlas patch, which is about as simple as they go. http://sagetrac.org/sage_trac/ticket/6558 Since polybori-0.5rc.p9 built for you, perhaps you can look at: http://sagetrac.org/sage_trac/ticket/6437 Perhaps you could try the revised MPFR patch, http://sagetrac.org/sage_trac/ticket/6453 Note however, the version of gcc you used (4.2.4), did not actually exhibit the problem, which is why I changed the default gcc. But I have confirmed it passes with the latest gcc now. It is NOT a bug in gcc 4.4.0, but Sun have admitted this is a bug in Solaris. The fix allows MPFR to build on any machine, with any version of gcc and pass all tests with no impact on performance except on sun4v machines. I noticed my patch to singular worked for you http://sagetrac.org/sage_trac/ticket/6563 There is probably a better solution than that one. The singular installation appears to be broken by a patch added to Sage to patches/kernel.Makefile.in.diff. I don't know if you can shed any light onto what that patch was supposed to fix, as it seems have changed 'cp' for the 'install-sh' program and broke the installation in the process. I seem to be slacking at the minute, as there are only 4 Solaris patches needing review!! Dave --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Catalan Numbers
Cool to hear that people are interested.
So far, I've implemented a CatalanCatalog class, which keeps lists of
descriptions of Catalan constructions, maps between different
constructions, and functions which enumerate various families of
constructions. It also maintains a directed graph of which maps have
been established, so one can ask for a mapping from one class of
objects to another.
At some point, I'm thinking to make a CatalanConstruction class which
has a nice interface for which CatalanCatalog is a backend. The user
would be able to construct a generic object through any number of
means:
sage: s = SymmetricGroup(3)([1,3,2])
sage: c = CatalanConstruction(s,'avoid312')
sage: b = c.binary_tree()
sage: d = CatalanConstruction(b,'binary tree')
sage: c == d
True
sage: d.plot(style='coin stack')
...
similarly, one could enumerate Catalan objects:
sage: for c in CatalanConstructions(3):
... print c.parentheses(), c.avoid312()
...
()()() ()
(())() (12)
()(()) (23)
(()()) (13)
((())) (123)
Part of my problem is that these objects can have quite verbose
descriptions. How should they be referenced? I've been using the
numbering system that Stanley uses, but it's very clumsy. Also, I can
come up with short names like "avoid312", but that's not really good
enough, because a number of the constructions are rather hard to
summarize in a word or two. Ideas?
On Thu, Jul 23, 2009 at 2:58 PM, Franco Saliola wrote:
>
> On Thu, Jul 23, 2009 at 8:20 AM, Tom Boothby wrote:
>> Richard Stanley currently lists 172 combinatorial interpretations of
>> the Catalan numbers. I've been doing some research on Coxeter groups
>> this summer, and we recently found that a class of permutations in S_n
>> which are counted by the Catalan numbers. Turns out, the permutations
>> are just the 321-avoiding permutations. A research partner, Matt
>> Macauley noted that when one finds objects counted by the Catalan
>> numbers, that it can be interesting to see what other objects they
>> might correspond to.
>>
>> In particular, we've got a subset of the 321-avoiding permutations
>> that we want to investigate. If there's a nice bijection between
>> 321-avoiding permutations, and say, Dyck paths, we'd like to look at
>> the Dyck paths which correspond to this special subset. So, I've
>> started going down Stanley's list and hacking up as many bijections as
>> I can devise between the objects he's listed. At the present, I can
>> generate the following given, say, a Dyck word (one can generate these
>> in Sage), and draw nice pictures of them all. Further, almost all of
>> them are strongly connected -- given almost any object below, I can
>> create any of the others. (though my constructions are bijective, I
>> haven't coded both ways for a couple of them)
>>
>> These reference Stanley's numbering scheme, see [1] and [2]
>>
>> (c) binary trees on n vertices
>> (h) lattice paths from (0,0) to (n,n) below x=y
>> (i) Dyck paths from (0,0) to (n,0) above x=0
>> (o) non-crossing matchings of [2n]
>> (r) valid strings of parentheses (description in text differs by '('
>> <-> 1, ')' <-> -1)
>> (ff) 231-avoiding permutations (hah -- but I don't have 321-avoiding
>> permutations yet -- I found these by a lucky guess)
>> (pp) non-crossing partitions of [n]
>> (tt) non-crossing partitions of [2n+1] into n+1 parts with
>> nonconsecutive entries
>> (hhh) stacks of coins
>> (z^4) non-nesting matchings of [2n]
>>
>> I'm mostly doing this for research and for pleasure, but since I'm
>> doing the research with a few partners, the code is readable. I'm
>> wondering: is there sufficient interest for this to be added to Sage?
>> If I manage to construct even a quarter of the bijections listed, it
>> will be a rather large amount of code. I'd like some input from the
>> combinat people as to what sort of interface would be appropriate.
>
> It would definitely be cool to have this in Sage. There is a sage-combinat
> conference starting on Saturday, which I will be attending, and I'll make
> sure to bring this up and ask about interface design.
>
> Take care,
> Franco
>
> --
>
> >
>
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: memset() bug which caused MPFR test failures will be fixed by Sun.
William Stein wrote: > On Thu, Jul 23, 2009 at 5:36 PM, Dr. David > Kirkby wrote: >> Many people looked at the reason there were 20 test failures of the MPFR >> test suite on a Sun T5240. I believe the issue is due to memset). >> >> I telephoned Sun a couple of days back to report this officially. They >> have been extremely efficient at handling this case. >> >> I now have some information from Sun. I asked the engineer if I could >> make it public, and he has said yes. He is in fact going to put some of >> it on a mailing list, and it will eventually appear in Sunsolve. >> >> I'm told the fix will be backported to Solaris 10 and I should have a >> Interim Diagnostic Relief to test myself in a few weeks, but it wont be >> a public patch for some time, until it's fully tested. >> >> Dave > > Wow, Dave, you are amazingly good at doing things right and being a > professional! Thanks!! > > William Cheers. >> Your service case regarding memset(3C)'s behaviour on sun4v systems >> when the size_t argument is nonzero but zero mod 232 has now been >> transferred to Europe, and I have taken ownership. And I intend to >> keep ownership until we've reached a mutually acceptable resolution, >> barring vacation stand-ins and unforeseen events. That was supposed to be 2 to the power 32, but my 2^32 appears to come out as the number 232 there. >> Let me quickly recapitulate the facts: >> >> + This is on record as a bug under Change Request id 6507249, >> + it's fixed in the internal development version of (future) >> Solaris and thus in OpenSolaris based on builds snv_62 or later, >> + it affects only >> + 32-bit applications >> + running on Solaris 10 >> + on all SPARC sun4v (CoolThreads^TM) platforms, >> + it originates in the hardware-optimized libc_psr_hwcap[12].so.1 >> which (by default) get mounted over /platform/sun4v/lib/libc_psr.so.1 >> during the Solaris boot sequence, >> + it affects invocations of memset(3C) where the third (size_t) >> argument is nonzero but its low-order 32 bits are zero (thus >> it ought to be zero considered as a size_t). >> >> (A subtle point is that it won't affect the *first* call to memset() >> after exec, as the runtime loader processing for lazy symbol binding >> will clear the upper 32 bits as a side effect before passing control >> to the newly-bound function entry point.) >> >> The bugfix has not (yet) been beackported to Solaris 10 because there >> has not (yet) been any tangible demand for such a backport. Until >> just now, there had not yet been a single external customer record >> on CR#6507249! >> >> I am adding one for this present service request now. >> >> In fact, the vast majority of application code would not be at risk >> of being affected by this bug. Most uses of memset() pass a compile- >> time constant for the size, often some sizeof(struct such_and_such). >> Passing a manifest 32-bit int variable for the size will also avoid >> the bug. It can only happen when memset() is invoked with some >> nontrivial arithmetic expression, or some explicit 64-bit variable >> for the size. Such code idioms are quite rare. >> >> Also, there are a number of workarounds to choose from, depending on >> the situation: >> >> + When the application source code is available for modification: >> + store the expression result in a variable and then pass the >> variable to memset() (though compiler optimizations might >> subvert this), >> + test the variable for being 32-bit-equal-to-zero and bypass >> memset() if it is, >> >> + or at runtime: >> + invoke the application with LD_NOAUXFLTR=1 in the environment >> (cf. man ld.so.1(1), which selectively disables the optimized >> libc_psr.so.1 just for this process), >> + umount the optimized libc_psr.so.1 system-wide, >> + interpose a different memset() implementation e.g. via an >> LD_PRELOAD'ed shared object. >> >> > Since the MPFR library code we are using is open source, we have managed >> > to work around this Solaris bug, by sticking an 'if' statement in front >> > of the call to macro which calls memset(). >> > >> > Though of course I don't know if it will affect anything else. So I >> > guess it is safer to unmount this, but I assume that will have quite a >> > performance impact. >> >> The performance impact of not using the optimized libc_psr.so.1 >> varies widely among applications, depending on how much memset()ing >> and memcpy()ing and memmove()ing they do. It can range all the way >> from negligible to a few ten percent in benchmarks. >> >> But the LD_NOAUXFLTR=1 approach limits the performance impact to >> those applications which are known or suspected to be affected >> by the bug.--- >> >> >> >> Would you be willing to test-drive any future binary fix in the >> shape of an Interim Diagnostic Relief prior to patch creation, >> as well as a release-candidate patch at the T-Patch stage prior >> to patch release? For background information on IDRs, ple
[sage-devel] memset() bug which caused MPFR test failures will be fixed by Sun.
Many people looked at the reason there were 20 test failures of the MPFR test suite on a Sun T5240. I believe the issue is due to memset). I telephoned Sun a couple of days back to report this officially. They have been extremely efficient at handling this case. I now have some information from Sun. I asked the engineer if I could make it public, and he has said yes. He is in fact going to put some of it on a mailing list, and it will eventually appear in Sunsolve. I'm told the fix will be backported to Solaris 10 and I should have a Interim Diagnostic Relief to test myself in a few weeks, but it wont be a public patch for some time, until it's fully tested. Dave Your service case regarding memset(3C)'s behaviour on sun4v systems when the size_t argument is nonzero but zero mod 232 has now been transferred to Europe, and I have taken ownership. And I intend to keep ownership until we've reached a mutually acceptable resolution, barring vacation stand-ins and unforeseen events. Let me quickly recapitulate the facts: + This is on record as a bug under Change Request id 6507249, + it's fixed in the internal development version of (future) Solaris and thus in OpenSolaris based on builds snv_62 or later, + it affects only + 32-bit applications + running on Solaris 10 + on all SPARC sun4v (CoolThreads^TM) platforms, + it originates in the hardware-optimized libc_psr_hwcap[12].so.1 which (by default) get mounted over /platform/sun4v/lib/libc_psr.so.1 during the Solaris boot sequence, + it affects invocations of memset(3C) where the third (size_t) argument is nonzero but its low-order 32 bits are zero (thus it ought to be zero considered as a size_t). (A subtle point is that it won't affect the *first* call to memset() after exec, as the runtime loader processing for lazy symbol binding will clear the upper 32 bits as a side effect before passing control to the newly-bound function entry point.) The bugfix has not (yet) been beackported to Solaris 10 because there has not (yet) been any tangible demand for such a backport. Until just now, there had not yet been a single external customer record on CR#6507249! I am adding one for this present service request now. In fact, the vast majority of application code would not be at risk of being affected by this bug. Most uses of memset() pass a compile- time constant for the size, often some sizeof(struct such_and_such). Passing a manifest 32-bit int variable for the size will also avoid the bug. It can only happen when memset() is invoked with some nontrivial arithmetic expression, or some explicit 64-bit variable for the size. Such code idioms are quite rare. Also, there are a number of workarounds to choose from, depending on the situation: + When the application source code is available for modification: + store the expression result in a variable and then pass the variable to memset() (though compiler optimizations might subvert this), + test the variable for being 32-bit-equal-to-zero and bypass memset() if it is, + or at runtime: + invoke the application with LD_NOAUXFLTR=1 in the environment (cf. man ld.so.1(1), which selectively disables the optimized libc_psr.so.1 just for this process), + umount the optimized libc_psr.so.1 system-wide, + interpose a different memset() implementation e.g. via an LD_PRELOAD'ed shared object. > Since the MPFR library code we are using is open source, we have managed > to work around this Solaris bug, by sticking an 'if' statement in front > of the call to macro which calls memset(). > > Though of course I don't know if it will affect anything else. So I > guess it is safer to unmount this, but I assume that will have quite a > performance impact. The performance impact of not using the optimized libc_psr.so.1 varies widely among applications, depending on how much memset()ing and memcpy()ing and memmove()ing they do. It can range all the way from negligible to a few ten percent in benchmarks. But the LD_NOAUXFLTR=1 approach limits the performance impact to those applications which are known or suspected to be affected by the bug.--- Would you be willing to test-drive any future binary fix in the shape of an Interim Diagnostic Relief prior to patch creation, as well as a release-candidate patch at the T-Patch stage prior to patch release? For background information on IDRs, please see: http://sunsolve.sun.com/show.do?target=IDR Since the affected deliverables (libc_psr_hwcap1.so.1) have also been modified by existing patches including some Kernel Update patches, any such IDR would (have to) be built to fit onto a particular set of patch revisions. The most recent change had come in Kernel Update patch 127127-11, thus the easiest would be an IDR with a hard dependency on this patch. Should you have need for an IDR against older patch levels than this, please do let me know! --~--~-~--~~
[sage-devel] Re: Is new symbolic derivative really worth the efforts?
Hi,
On Thu, Jul 23, 2009 at 3:06 PM, Burcin Erocal wrote:
> I am not opposed to having the unevaluated diff as an alternative
> operator.
Thanks Burcin. Surely, it helps to have both derivatives available to
Sage users. As Tim said, similar options are available to Maple users.
It is easy to put a flag that will instruct which derivative to use.
For example, in my prototype I could add another condition
// No derivative defined and user wants diff format? Then dont apply chain rule
if (opt.derivative_f == NULL && use_diff_format) {
.
...
}
The next question is then whether we evaluate symbolic derivative
using "D" by default or we store them un-evaluated using "diff"
and evaluate them in terms of "D" only on-demand?
Mock-up usage could look like
--
sage: diff( f(x), x)
diff( f(x), x, 1)
sage: diff( f(x), x, D_format=True)
D[0](f)(x)
--
Given pynac "D" construct doesn't store enough information
for guaranteed conversion to "diff" format, personally I don't
see any way out other than storing symbolic derivative
un-evaluated by default.
Cheers,
Golam,
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: memset() bug which caused MPFR test failures will be fixed by Sun.
On Thu, Jul 23, 2009 at 5:36 PM, Dr. David Kirkby wrote: > > Many people looked at the reason there were 20 test failures of the MPFR > test suite on a Sun T5240. I believe the issue is due to memset). > > I telephoned Sun a couple of days back to report this officially. They > have been extremely efficient at handling this case. > > I now have some information from Sun. I asked the engineer if I could > make it public, and he has said yes. He is in fact going to put some of > it on a mailing list, and it will eventually appear in Sunsolve. > > I'm told the fix will be backported to Solaris 10 and I should have a > Interim Diagnostic Relief to test myself in a few weeks, but it wont be > a public patch for some time, until it's fully tested. > > Dave Wow, Dave, you are amazingly good at doing things right and being a professional! Thanks!! William > > > Your service case regarding memset(3C)'s behaviour on sun4v systems > when the size_t argument is nonzero but zero mod 232 has now been > transferred to Europe, and I have taken ownership. And I intend to > keep ownership until we've reached a mutually acceptable resolution, > barring vacation stand-ins and unforeseen events. > > Let me quickly recapitulate the facts: > > + This is on record as a bug under Change Request id 6507249, > + it's fixed in the internal development version of (future) > Solaris and thus in OpenSolaris based on builds snv_62 or later, > + it affects only > + 32-bit applications > + running on Solaris 10 > + on all SPARC sun4v (CoolThreads^TM) platforms, > + it originates in the hardware-optimized libc_psr_hwcap[12].so.1 > which (by default) get mounted over /platform/sun4v/lib/libc_psr.so.1 > during the Solaris boot sequence, > + it affects invocations of memset(3C) where the third (size_t) > argument is nonzero but its low-order 32 bits are zero (thus > it ought to be zero considered as a size_t). > > (A subtle point is that it won't affect the *first* call to memset() > after exec, as the runtime loader processing for lazy symbol binding > will clear the upper 32 bits as a side effect before passing control > to the newly-bound function entry point.) > > The bugfix has not (yet) been beackported to Solaris 10 because there > has not (yet) been any tangible demand for such a backport. Until > just now, there had not yet been a single external customer record > on CR#6507249! > > I am adding one for this present service request now. > > In fact, the vast majority of application code would not be at risk > of being affected by this bug. Most uses of memset() pass a compile- > time constant for the size, often some sizeof(struct such_and_such). > Passing a manifest 32-bit int variable for the size will also avoid > the bug. It can only happen when memset() is invoked with some > nontrivial arithmetic expression, or some explicit 64-bit variable > for the size. Such code idioms are quite rare. > > Also, there are a number of workarounds to choose from, depending on > the situation: > > + When the application source code is available for modification: > + store the expression result in a variable and then pass the > variable to memset() (though compiler optimizations might > subvert this), > + test the variable for being 32-bit-equal-to-zero and bypass > memset() if it is, > > + or at runtime: > + invoke the application with LD_NOAUXFLTR=1 in the environment > (cf. man ld.so.1(1), which selectively disables the optimized > libc_psr.so.1 just for this process), > + umount the optimized libc_psr.so.1 system-wide, > + interpose a different memset() implementation e.g. via an > LD_PRELOAD'ed shared object. > > > Since the MPFR library code we are using is open source, we have managed > > to work around this Solaris bug, by sticking an 'if' statement in front > > of the call to macro which calls memset(). > > > > Though of course I don't know if it will affect anything else. So I > > guess it is safer to unmount this, but I assume that will have quite a > > performance impact. > > The performance impact of not using the optimized libc_psr.so.1 > varies widely among applications, depending on how much memset()ing > and memcpy()ing and memmove()ing they do. It can range all the way > from negligible to a few ten percent in benchmarks. > > But the LD_NOAUXFLTR=1 approach limits the performance impact to > those applications which are known or suspected to be affected > by the bug.--- > > > > Would you be willing to test-drive any future binary fix in the > shape of an Interim Diagnostic Relief prior to patch creation, > as well as a release-candidate patch at the T-Patch stage prior > to patch release? For background information on IDRs, please see: > > http://sunsolve.sun.com/show.do?target=IDR > > Since the affected deliverables (libc_psr_hwcap1.so.1) have also > been modified by existing patches including some Kernel Update > patches, any such IDR would (have to)
[sage-devel] scipy_sandbox gives ominous looking errors, but still installs. Is this a bug?
I've been trying to build some of the other packages for Sage on Solaris
- I seem to have got a bit stuck on a couple of the bugs, so thought I'd
leave them (hoping for a bit of help in some cases).
I tried installing scipy_sandbox-20071020.p4 and get what looks like
some serious errors, which I suspect should abort the build process,
though perhaps I am mistaken.
scipy_sandbox-20071020.p4/patches/setup.py~
scipy_sandbox-20071020.p4/patches/setup.py.spline
Finished extraction
Host system
uname -a:
SunOS t2 5.10 Generic_141414-02 sun4v sparc SUNW,T5240
GCC Version
gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.2.4/configure
--prefix=/usr/local/gcc-4.2.4-sun-linker/ --with-as=/usr/ccs/bin/as
--without-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld
--enable-languages=c,c++,fortran --with-mpfr-include=/usr/local/include
--with-mpfr-lib=/usr/local/lib --with-gmp-include=/usr/local/include
--with-gmp-lib=/usr/local/lib
Thread model: posix
gcc version 4.2.4
/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/lib/python2.6/site-packages/numpy/distutils/command/config.py:361:
DeprecationWarning:
+
Usage of get_output is deprecated: please do not
use it anymore, and avoid configuration checks
involving running executable on the target machine.
+
DeprecationWarning)
Undefined first referenced
symbol in file
_gfortran_transfer_integer
/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/lib/libf77blas.so
_gfortran_transfer_character
/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/lib/libf77blas.so
_gfortran_stop_numeric
/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/lib/libf77blas.so
_gfortran_st_write
/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/lib/libf77blas.so
_gfortran_st_write_done
/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/lib/libf77blas.so
ld: fatal: Symbol referencing errors. No output written to _configtest
collect2: ld returned 1 exit status
compiling '_configtest.c':
/* This file is generated from numpy/distutils/system_info.py */
void ATL_buildinfo(void);
int main(void) {
ATL_buildinfo();
return 0;
}
Undefined first referenced
symbol in file
_gfortran_transfer_integer
/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/lib/libf77blas.so
_gfortran_transfer_character
/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/lib/libf77blas.so
_gfortran_stop_numeric
/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/lib/libf77blas.so
_gfortran_st_write
/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/lib/libf77blas.so
_gfortran_st_write_done
/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/lib/libf77blas.so
ld: fatal: Symbol referencing errors. No output written to _configtest
collect2: ld returned 1 exit status
running install
running build
Then finally we get:
Successfully installed scipy_sandbox-20071020.p4
Somehow that does not seem right to me. If these 'undefined symbol
errors' are acceptable, then perhaps there needs to be a few notes
output to say, "Don't be spooked by some error messages", which is what
the ATLAS code says in one place.
Dave
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] GNUism in lcalc-20080205.p2 passing GNU flags directly to the Sun assembler.
After purging out some of the cases where GNU-specific flags like
-soname are passed directly to the Sun linker, I now find
lcalc-20080205.p2 is passing GNU specific flags directly to the Sun
linker, by using the -Wa flag to g++, which means the next item gets
passed directly to the assembler.
g++ -O2 -g -Wa,-W -fno-exceptions -Wno-deprecated -DINCLUDE_PARI \
-I/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/include/pari
-I/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/include\
-I ../include/
-L/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/lib \
cmdline.c \
Lcommandline.cc Lcommandline_elliptic.cc Lcommandline_globals.cc \
Lcommandline_misc.cc Lcommandline_numbertheory.cc \
Lcommandline_twist.cc Lcommandline_values_zeros.cc \
Lgamma.cc Lglobals.cc Lmisc.cc Lriemannsiegel.cc \
-o lcalc -lpari -lmpfr -lgmpxx -lgmp -liberty
/usr/ccs/bin/as: error: unknown option 'W'
usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-q] [-s]
[-S] [-K {pic,PIC}] [-o objfile] [-L] [-T]
[-P [[-Yc,path] [-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
[-m [-Ym,path]] [-n] [-ul] [-xF]
[-m32] [-m64]
[-xarch={v7,v8,v8a,v8plus,v8plusa,v8plusb,v9,v9a,v9b,sparc,sparcvis,
sparcvis2,sparcfmaf,sparcima}]
[-xcode={pic13,pic32}] file.s...
This is now.
http://sagetrac.org/sage_trac/ticket/6609
Dave
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: GNUism in lcalc-20080205.p2 passing GNU flags directly to the Sun assembler.
Dr. David Kirkby wrote:
> After purging out some of the cases where GNU-specific flags like
> -soname are passed directly to the Sun linker, I now find
> lcalc-20080205.p2 is passing GNU specific flags directly to the Sun
> linker, by using the -Wa flag to g++, which means the next item gets
> passed directly to the assembler.
>
> g++ -O2 -g -Wa,-W -fno-exceptions -Wno-deprecated -DINCLUDE_PARI \
>-I/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/include/pari
> -I/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/include\
>-I ../include/
> -L/rootpool2/local/kirkby/sage-4.1.1.alpha0/local/lib \
>cmdline.c \
>Lcommandline.cc Lcommandline_elliptic.cc Lcommandline_globals.cc \
>Lcommandline_misc.cc Lcommandline_numbertheory.cc \
>Lcommandline_twist.cc Lcommandline_values_zeros.cc \
>Lgamma.cc Lglobals.cc Lmisc.cc Lriemannsiegel.cc \
> -o lcalc -lpari -lmpfr -lgmpxx -lgmp -liberty
> /usr/ccs/bin/as: error: unknown option 'W'
> usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-q] [-s]
> [-S] [-K {pic,PIC}] [-o objfile] [-L] [-T]
> [-P [[-Yc,path] [-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
> [-m [-Ym,path]] [-n] [-ul] [-xF]
> [-m32] [-m64]
>
> [-xarch={v7,v8,v8a,v8plus,v8plusa,v8plusb,v9,v9a,v9b,sparc,sparcvis,
> sparcvis2,sparcfmaf,sparcima}]
> [-xcode={pic13,pic32}] file.s...
>
>
>
> This is now.
>
> http://sagetrac.org/sage_trac/ticket/6609
>
> Dave
Looking at the man page for the assembler on sage.math, I see that the
-W option to the GNU assembler just removes warning messages. Under the
circumstances, I think it will be better to change the code the warnings
are output. I can't really find much excuse for hiding warning messages,
especially when the attempts to hide them is causing problems.
Dave
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Suppressing warning messages - not a good idea IMHO
Looking at the CFLAGS in the spkg-install of lcalc-20080205.p2, I see: CFLAGS="$CFLAGS -O2 -g -Wa,-W -fno-exceptions -Wno-deprecated" -Wal,-W will suppress warnings from the assembler (IF the GNU assembler is used). -Wno-deprecated is a gcc flag to remove warnings about deprecated headers. What excuse is there really for suppressing warnings like this? None of us like seeing warnings messages, but hiding them is not a good idea. Dave --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Suppressing warning messages - not a good idea IMHO
Hi David, I'm cc'ing this on to Mike Rubinstein, the author of lcalc, in case he has any comments. William On Thu, Jul 23, 2009 at 8:46 PM, Dr. David Kirkby wrote: > > Looking at the CFLAGS in the spkg-install of lcalc-20080205.p2, I see: > > CFLAGS="$CFLAGS -O2 -g -Wa,-W -fno-exceptions -Wno-deprecated" > > -Wal,-W will suppress warnings from the assembler (IF the GNU assembler > is used). > > -Wno-deprecated is a gcc flag to remove warnings about deprecated headers. > > What excuse is there really for suppressing warnings like this? None of > us like seeing warnings messages, but hiding them is not a good idea. > > Dave > > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Sagemath with Phone
Now I make the WAP Page in Sagemath notebook. http://nosyu.pe.kr/attach/1/3770095285.png http://math1.skku.ac.kr/wap_html You can write the sage code in textbox. 예제 1 means example 1. So click the 예제 3, you can see example sage code like this. http://nosyu.pe.kr/attach/1/6037209279.png Example code is 'plot(sin(x), xmin=-2*pi, xmax=2*pi)'. Click the '실행 (Evaluate)' Button. Then you can see the code and result. http://nosyu.pe.kr/attach/1/5078779878.png I said it is for phone. So Dr Kim tested this his phone. His phone is Samsung SPH-W5000. http://nosyu.pe.kr/attach/1/6834600582.png http://nosyu.pe.kr/attach/1/9329232708.png We can see right result on the phone. We test this on phone that is sold in Korea such as Samsung Anycall, LG CYON. And I test this on phone emulator also. http://nosyu.pe.kr/attach/1/1601193836.png http://nosyu.pe.kr/attach/1/4458016426.png http://www.opera.com/mini/demo/ http://nosyu.pe.kr/attach/1/1792769303.png http://nosyu.pe.kr/attach/1/7577281903.png http://emulator.mtld.mobi/emulator.php It works fine. It works good on the phone that is sold in Korea. So we make this Korean interface. Then Korean people use sagemath on the phone easily. Now we imporve and expand this. So test it and report bug or bad things. http://math1.skku.ac.kr/wap_html You can this post with image on this page. http://nosyu.pe.kr/2065 누구나가 다, 자기 옆에서 눈물을 흘리며 신음하는 불행한 사람들에 비해 자기가 훨씬 더 불행하다고 생각하지요. 이게 바로 우리 가련한 인간들의 오만 중 하나입니다. - 몬테크리스토 백작 it is the infirmity of our nature always to believe ourselves much more unhappy than those who groan by our sides! - The Count of Monte Cristo c'est un des orgueils de notre pauvre humanité, que chaque homme se croie plus malheureux qu'un autre malheureux qui pleure et qui gémit à côté de lui - Le Comte de Monte-Cristo 박진영 - Bak JinYeong 학부재학생 - Undergraduate 컴퓨터공학전공 - Department of Computer Engineering 정보통신공학부 - School of Information & Communication Engineering 성균관대학교 - SungKyunKwan University 블로그 - http://nosyu.pe.kr 이메일 - don...@skku.edu --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
