Re: [sage-devel] Short fr, de, pt, ru translation
2015-08-27 16:20 GMT-03:00 Jeroen Demeyer : > If you are a native French, German, Portuguese, Russian speaker, > could you please translate the following short paragraph for #19106: Hi, pt translation below > For some GAP functionality, you should install two optional > Sage packages. This can be done with the command:: """ Para algumas funcionalidades do GAP, deve-se instalar dois pacotes Sage opcionais. Isso pode ser feito com o comando:: """ Thanks, Paulo -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Pari 2.8 and distro packages of sagemath
2015-06-21 0:21 GMT-03:00 Francois Bissey : > There are two factors here: > 1) libcsage is gone in the upcoming sage 6.8. Ok. I would prefer it kept around as a "generic" place to add wrappers, or better saying "hacks" :) > 2) I bit the bullet and used the pari git snapshot used in sage > for sage-on-gentoo. I noticed arch did the same: https://www.archlinux.org/packages/community/x86_64/pari-sage/ But I would still prefer to, as much as possible, and to avoid bureaucracy, to use the upstream pristine version. > This was not a light decision. I looked at the packages depending > of pari and I found they were in two class: > a) packages using an outdated (pari 2.3) interface to pari. Those > are clisp and perl binding to pari. For those if you want to use pari > you would have to provide an outdated version for their use. Currently I am a co-maintainer of pari in Fedora. The official maintainer "kind of" inherited it, to provide the perl bindings. I am a bit unsure about clisp interfaces, but the main maintainer is of clisp is very friendly to sage, so he should not "block" work on getting everything in place. > b) all the other packages I knew to be depending on pari are > in sage. They will compile and work with the pari provided by > sage, if sometimes with patches (lcalc for example). This is currently my major issue, if creating a pari-sage package, it would also be required by all other packages, that, currently only sagemath uses anyway... But getting it approved needs to pass a "steering committee". Well, sorry for so many " so far :) > I don’t know any other packages depending on pari in Gentoo, > I don’t know the situation in fedora but I suspect it will be similar. When I was maintaining a sagemath package in Mandriva it was a bit easier, as I had "superpowers", but now, in Fedora I need to follow any rules in place. I am still believing sagemath could become a standard package in most distros, so, libcsage is/was a place to add wrappers to sage specific patches, otherwise, sagemath should really, really, rely only on released upstream releases or third party packages. > François Thanks, Paulo -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Pari 2.8 and distro packages of sagemath
Hi, I believe this should be one of the best places to ask, about any estimative of when it will be available. I have sagemath 6.5 packaged in Fedora. Today I started implementing a "pari_wrap.c" and "pari_wrap.h" interface in libcsage, but noticed it would not be a trivial patch to create sage_parifunc wrappers to implement variants of those that are different from pari 2.7.4, because it would need to know too much about pari internals, and the number of dependency extra static functions started growing too much... At the moment I prefer to not "attempt" to have Fedora accepting something like a pari-sage package. Thanks, Paulo -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Packaging rant
2015-06-12 6:18 GMT-03:00 Jeroen Demeyer : > On 2015-06-11 10:31, Julien Puydt wrote: >> >> Open software is about cooperation. > > Of course. The question is: what should we do if upstream does not want to > cooperate? I don't want to call names in this thread, but I have proposed > patches to many upstream projects which are part of Sage (usually they are > small bugfixes). The chances of actually getting a patch accepted by > upstream are unfortunately much smaller than I would wish. I understand your frustration. I understand that sage needs to bundle all it needs because otherwise it would be pretty much impossible to install sage on old, or too new systems. But keeping as close as possible to upstream is really desirable. For example, I have some patches in a few packages in Fedora, to satisfy sage, but for others it is not easy... Right now, Fedora has sagemath 6.5 packaged, and I need to find some time to see if reasonable, and how I would patch sage to use a non released and patched pari, to update to 6.7 (skipping 6.6). > Some people think that Sage should only add patches to upstream packages if > they are accepted by upstream. This is frustrating, because it really slows > down Sage development. > > Jeroen. Thaks, Paulo -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Problem with "extern C" in c_lib and C++ reference
2014-12-01 0:41 GMT-02:00 François Bissey : > In sage-on-gentoo I don't seem to hit that problem with 4.9.2 > either. I am really curious about your default building flags. Actually, it was partly my fault. I was using an early patch to adapt to use ntl6, what is no longer required as sagemath now uses ntl6. Just removing that patch correct the problem. But, the patch was working previously, basically it was a "typedef struct someZZ someZZ;" and update prototypes to use the typedef. I could not create a small reproducer. But found it interesting that adding an explicit: +#ifdef __cplusplus +extern "C" +#endif int ZZ_p_to_int(const ZZ_p& x ) to not_wrap.c would cause a compilation failure telling it was not compatible with EXTERN int ZZ_p_to_int(const ZZ_p& x) defined in ntl_wrap.h. The non expanded EXTERN was weird. And apparently the issue happens because I am trying to build with ntl-6.2.1, as with previous ntl it did not happen. > Francois > > On Mon, 01 Dec 2014 12:51:50 François Bissey wrote: >> Very strange I don't have it in sage-on-gentoo. >> objdump -T --demangle /usr/lib64/libcsage.so |grep ZZ_p_to_int >> 9320 gDF .text 000e BaseZZ_p_to_int >> >> sage -v >> Sage Version 6.5.beta1, Release Date: 2014-11-23 >> >> We had a few issue with C++ ompiling during the upgrade and more have >> surfaced on my side with people trying out -flto but not that particular >> symbol. flto seems to mess up inline templates the same way that we found >> not all versions of were producing symbol for them in >> http://trac.sagemath.org/ticket/16882 >> as pointed out by Volker. >> >> Since gcc 4.9.2 is shipped in sage and a number of people are using it >> I would be looking at any flags you are using. I may have a shot at >> gcc 4.9.2 here. >> >> Francois >> >> On Sun, 30 Nov 2014 11:44:09 Paulo César Pereira de Andrade wrote: >> > I think this may have been working somewhat of by accident >> > >> > before, because it says 'extern "C"' in one place and in another >> > say '// sorry, if you want a C version, feel free to add it' >> > >> > I delayed a bit sagemath 6.4 update due to some dependencies >> > >> > needing to be updated in Fedora, in the meantime 6.4.1 was >> > released. >> > >> > Trying to update to Fedora sagemath rpm to 6.4.1 I am being >> > >> > hit by this: >> > >> > ---%<--- >> > >> > File >> > >> > "/home/pcpa/rpmbuild/BUILDROOT/sagemath-6.4.1-1.fc22.x86_64/usr/lib64/pyth >> > o >> > n2.7/site-packages/sage/libs/ntl/__init__.py", line 1, in >> > >> > import all >> > >> > File >> > >> > "/home/pcpa/rpmbuild/BUILDROOT/sagemath-6.4.1-1.fc22.x86_64/usr/lib64/pyth >> > o >> > n2.7/site-packages/sage/libs/ntl/all.py", line 34, in >> > >> > from sage.libs.ntl.ntl_ZZ_p import ( >> > >> > ImportError: >> > /home/pcpa/rpmbuild/BUILDROOT/sagemath-6.4.1-1.fc22.x86_64/usr/lib64/pytho >> > n >> > 2.7/site-packages/sage/libs/ntl/ntl_ZZ_p.so: undefined symbol: ZZ_p_to_int >> > error: Bad exit status from /var/tmp/rpm-tmp.moMkJq (%install) >> > ---%<--- >> > >> > Previously it was exported as a "C" symbol: >> > $ rpm -q sagemath >> > sagemath-6.3-3.fc22.x86_64 >> > $ objdump -T --demangle /usr/lib64/libcsage.so | grep ZZ_p_to_int >> > 8760 gDF .text 0005 BaseZZ_p_to_int >> > >> > But the newly generated libcsage.so does only show a C++ symbol: >> > $ objdump -T --demangle BUILD/sage-6.4.1/src/c_lib/libcsage.so | grep >> > ZZ_p_to_int >> > 87d0 gDF .text 0005 Base >> > ZZ_p_to_int(NTL::ZZ_p const&) >> > >> > So, it may be required some extra wrapping, but more likely, >> > >> > patch the cython code to only use ZZ_to_int(ZZ*). >> > >> > This may also be useful... >> > >> > $ rpm -q gcc binutils >> > gcc-4.9.2-1.fc22.x86_64 >> > binutils-2.24-29.fc22.x86_64 Thanks, Paulo -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Problem with "extern C" in c_lib and C++ reference
I think this may have been working somewhat of by accident before, because it says 'extern "C"' in one place and in another say '// sorry, if you want a C version, feel free to add it' I delayed a bit sagemath 6.4 update due to some dependencies needing to be updated in Fedora, in the meantime 6.4.1 was released. Trying to update to Fedora sagemath rpm to 6.4.1 I am being hit by this: ---%<--- File "/home/pcpa/rpmbuild/BUILDROOT/sagemath-6.4.1-1.fc22.x86_64/usr/lib64/python2.7/site-packages/sage/libs/ntl/__init__.py", line 1, in import all File "/home/pcpa/rpmbuild/BUILDROOT/sagemath-6.4.1-1.fc22.x86_64/usr/lib64/python2.7/site-packages/sage/libs/ntl/all.py", line 34, in from sage.libs.ntl.ntl_ZZ_p import ( ImportError: /home/pcpa/rpmbuild/BUILDROOT/sagemath-6.4.1-1.fc22.x86_64/usr/lib64/python2.7/site-packages/sage/libs/ntl/ntl_ZZ_p.so: undefined symbol: ZZ_p_to_int error: Bad exit status from /var/tmp/rpm-tmp.moMkJq (%install) ---%<--- Previously it was exported as a "C" symbol: $ rpm -q sagemath sagemath-6.3-3.fc22.x86_64 $ objdump -T --demangle /usr/lib64/libcsage.so | grep ZZ_p_to_int 8760 gDF .text 0005 BaseZZ_p_to_int But the newly generated libcsage.so does only show a C++ symbol: $ objdump -T --demangle BUILD/sage-6.4.1/src/c_lib/libcsage.so | grep ZZ_p_to_int 87d0 gDF .text 0005 Base ZZ_p_to_int(NTL::ZZ_p const&) So, it may be required some extra wrapping, but more likely, patch the cython code to only use ZZ_to_int(ZZ*). This may also be useful... $ rpm -q gcc binutils gcc-4.9.2-1.fc22.x86_64 binutils-2.24-29.fc22.x86_64 Thanks, Paulo -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] proposal: make the Sage build system more distribution friendly (update)
2013/4/23 Felix Salfelder :
> Hi There
Hi,
Sorry for only commenting in this thread this late; I have been very
busy with my work and should still be for a few months, but always
find some time to contribute and work on some personal projects :-)
I had a sagemath review request for Fedora for several months,
and only made the official review request after roughly 8 months
working on it, in which time I got most dependencies updated in
the base Fedora distribution:
https://bugzilla.redhat.com/show_bug.cgi?id=877651
A few days ago I finally got the sagemath package approved,
and after submitting it as update for f18, f19 and rawhide *yesterday*,
it should now be reaching mirrors, afaik already available for rawhide
in most mirrors, and should be shortly in updates-testing for f18
and f19:
https://admin.fedoraproject.org/updates/sagemath-5.8-6.fc18
https://admin.fedoraproject.org/updates/sagemath-5.8-6.fc19
In the past I had kept a working sagemath package for Mandriva
since late sagemath 3.x, and still have it somewhat working for
"openmandriva" (I should update it to match the fedora package
soon):
https://abf.rosalinux.ru/openmandriva/sagemath
> i have updated my proposal, taking into account the discussion. I've
> mostly extended the Details section. Thanks for reading.
I will make a few comments, attempting to be as constructive
as possible :-)
> === Title, Project Synopsis
> "Get Sage ready for Linux distributions"
>
> Sage is currently shipped as a software distribution that, next to
> genuine code, includes all dependencies as foreign packages.
> Moreover, the core library and python modules cannot be compiled in a
> straightforward way, as most linux distributions expect. Aim of this
> project is to detach the build process of sage ("the software") from
> sage ("the distribution"). The goal is a build system that works within
> the context of sage as well as for any gnu/linux distribution that ships
> the dependencies for sage.
The biggest problem is compatibility of version of the components.
Sagemath works in its current setup due to bundling most components,
so that it can be built on a 3 year old distribution as well as on a
bleeding edge one.
Using a more standard build system should help, but, very close
to what sagemath already does is kind of standard for several
python based packages. Some more strict rules on spkg would
make it actually easier to get sagemath integrated in distributions,
example:
o avoid carrying patches that upstream does not accept,
or were never submitted upstream.
o avoid creating spkgs of software that does not have a home
page, or that is a snapshot of something without any ETA to
be released, and not available anywhere for download.
> === Personal involvement/relationship
> To me, a Debian user, who likes maths (and doesn't like big Ms), this
> project fills an obvious gap. I have already worked on packaging sage
> dependencies for debian occasionally. There, I have learned some of the
> basics of packaging and software distribution. I found out that a
> package for sage cannot be done overnight...
>
> === Details
> Switching the build system of the core parts to autotools allows
> implementing a standard interface to build and install the software.
> Such a build system includes a mechanism to figure out the
> availibility/names/locations of tools/headers/libraries and adapts the
> build/install process accordingly.
One example is scons usage, that I patch to generate a more
standard library:
http://pkgs.fedoraproject.org/cgit/sagemath.git/tree/sagemath-scons.patch
and after that patch, some regex are applied to SConstruct during build
(to not hardcode cflags, ldflags, arch specific directories, etc).
> An autotools build system can be used easily by package generation
> scripts such as debhelper (creating Debian packages) and can be called
> from within sage ("the distribution"). The difference between these uses
> consists in passing different flags to the corresponding "configure"
> script.
>
> This sums up to three tasks
> 1 write/exchange the build systems for the core parts (c_lib,
> python-sage, sage-scripts, extcode, ...).
c_lib should be split out of the sage-$version directory. This way,
IMO, there is not much of a need to change how the core python
modules are built. Well, I would be happy enough to not need to
add this pseudo patch:
+if os.environ.has_key('DESTDIR'):
+DESTDIR = os.environ['DESTDIR']
+else:
+DESTDIR = ''
[...]
-pyx_inst_file = '%s/%s'%(SITE_PACKAGES, f)
+pyx_inst_file = '%s%s/%s'%(DESTDIR, SITE_PACKAGES, f)
to setup.py.
> 2 modify sage ("the distribution") to use the new build systems instead
> of running 'setup.py'.
> 3 build stand-alone sage, draft debian packages, figure out dependencies
>
> which split up into [optional in brackets]
> 1 - carefully read setup.py (within the sage-git-transition repo)
> - implement checks for headers and libraries
> - implement
[sage-devel] Any information about reason of needing to use ancient ipython and pexpect in sagemath ?
I opened a ticket in fedora to bundle cython, ipython and pexpect for the hopefully very close, fedora sagemath package, see https://fedorahosted.org/fpc/ticket/238 cython hopefully should not be an issue, and I said it should require roughly 6 months to be able to use system ipython. About pexpect I am not sure. I recall some comments about newer versions being too slow. For the sake of using system packages, I would go with it slower, but it actually does not work... I did not debug it much recently, but almost 4 years ago when I packaged sagemath in Mandriva I gave up debugging, but for somebody that knows the code, it should not be too hard to at least tell why it cannot be used, and I can use that comment as the reason of needing to bundle pexpect :-) Thanks, Paulo -- You received this message because you are subscribed to the Google Groups "sage-devel" group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] sagemath 5.4.1 fedora package review request
Hi, I need help from a Fedora packager for the proper review procedures. See https://bugzilla.redhat.com/show_bug.cgi?id=877651 I am asking because people searching for a review will most likely run away when looking at it due to the complexity :-) and it is better to have someone with some prior experience with sagemath to do the review. It will not be a fedora 18 package, but after the review process is complete, it can be submitted as a fedora 18 update. All the build requires should now be already in f18 or any remaining one should be trivial to make an update. Thanks, Paulo -- You received this message because you are subscribed to the Google Groups "sage-devel" group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] problems compiling sage-5.2.rc0 en debian wheezy+some sid amd64
2012/7/19 Jeroen Demeyer : > This is most likely a bug in GCC. > Could you try to install the package > http://boxen.math.washington.edu/home/jdemeyer/spkg/gcc-4.7.1.spkg > and compile again? > > This is to check whether using vanilla gcc-4.7.1 (as opposed to > Debian's) works. A possible patch is http://pkgs.fedoraproject.org/gitweb/?p=pari.git;a=blob;f=pari-2.5.1-gcc47.patch;h=f0d616d2b4260c972496fad06b5b0586d1a87e73;hb=HEAD > -- > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org Paulo -- -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: ARM port (again)
Em 24 de abril de 2012 13:46, mmarco escreveu: > > Nevermind, it worked by mounting an empty tmpfs as shm device Good to know the real issue :-) My workaround only works for missing /dev/shm. Missing /dev/pts on build chroots I managed to bug at Mandriva sometime ago, to get it properly mounted in build nodes, otherwise it cannot generate documentation because gap would fail to start. > On 24 abr, 18:07, mmarco wrote: >> There is no /dev/shm in my android system. Could it be that this is >> the problem? If so, is there any hope of solving it? Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: ARM port (again)
Em 23 de abril de 2012 16:54, mmarco escreveu: > Ok, switching to a newer version of ubuntu solved the eclib problem. > Now i have another one. Building the sage package i get this error > message: > > Building modified file sage/ext/interpreters/wrapper_el.pyx. > Executing 296 commands (using 4 threads) > Traceback (most recent call last): > File "setup.py", line 830, in > execute_list_of_commands(queue) > File "setup.py", line 287, in execute_list_of_commands > execute_list_of_commands_in_parallel(command_list, nthreads) > File "setup.py", line 238, in execute_list_of_commands_in_parallel > p = Pool(nthreads) > File "/sage/sage-4.8/local/lib/python/multiprocessing/__init__.py", > line 227, in Pool > return Pool(processes, initializer, initargs) > File "/sage/sage-4.8/local/lib/python/multiprocessing/pool.py", line > 84, in __init__ > self._setup_queues() > File "/sage/sage-4.8/local/lib/python/multiprocessing/pool.py", line > 131, in _setup_queues > self._inqueue = SimpleQueue() > File "/sage/sage-4.8/local/lib/python/multiprocessing/queues.py", > line 328, in __init__ > self._rlock = Lock() > File "/sage/sage-4.8/local/lib/python/multiprocessing/ > synchronize.py", line 117, in __init__ > SemLock.__init__(self, SEMAPHORE, 1, 1) > File "/sage/sage-4.8/local/lib/python/multiprocessing/ > synchronize.py", line 49, in __init__ > sl = self._semlock = _multiprocessing.SemLock(kind, value, > maxvalue) > OSError: [Errno 38] Function not implemented > sage: There was an error installing modified sage library code. > > > It seems that some os function that sage uses is not provided by the > android kernel. Maybe this means that there is no hope for sage runing > over android in a chroot? I did not look very closely at a related issue in chroot'ed builds in x86, but it should be possible to make python multiprocessing use some other approach like pipes in these conditions. What I did to get sage to build in the Mandriva build system was to "backport" the previous logic for a single process build: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/sagemath/current/SOURCES/sage-4.8-build.patch?r1=767969&r2=767968&pathrev=767969 > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Any Portuguese reader around? Translations need review
Em 10 de abril de 2012 13:50, Paulo César Pereira de Andrade escreveu: > Em 10 de abril de 2012 05:05, Gustavo de Oliveira > escreveu: >> I have recently uploaded to the trac server a Portuguese translation of "A >> Tour of Sage" and "Tutorial": >> >> http://trac.sagemath.org/sage_trac/ticket/12502 >> http://trac.sagemath.org/sage_trac/ticket/12822 >> >> If you read Portuguese, please review the above tickets. If you know someone >> who could do that, please let him know. Otherwise I will look for reviewers. >> It just happens that I don't have any Portuguese reader near me at the >> moment... After further reading, I notice that you did put significant work on it, as the quality is actually very good and there are no (aparent) spelling errors. A few long phrases translations could be better, but that is the job of someone from Linguistics, not Mathematics, as it is very easy to miss the context :-) And you did the right thing of not translating literal output of programs, comments, etc, what is a bane of several translations not done by, or not properly reviewed by people from the specific area. Quoting of "overhead" in doc/pt/tutorial/interactive_shell.rst could be better done with something like "Devido ao processamento extra da interface pexect" I am a bit unsure about the usage of the word "salvado" where "salvo" looks more natural, but I am probably wrong, and read almost only english text... In doc/pt/tutorial/interfaces.rst the first quote of ``'znprimroot(10007)'`` may cause issues in documentation generation, as it is a utf8 quote, not a single quote. Spelling error "poliômios" (and variáveis without accent in the same line) in doc/pt/tutorial/interfaces.rst In no place the word "navegador" is used, so should be ok, as at least does not mix with the english word "browser". "Debugador" probably should be translated to "depurador". In doc/pt/tutorial/introduction.rst, probably should translate "O arquivo de instalação ..." instead of "O arquivo para donwload ..." Some people prefer shift+clique instaed of shift-click, so, but optional, may be better to use "+" instead of "-" and translate click (but not shift). "(escaped)" in parenthesis (in latex.rst) may need a better translation. Maybe rephrase, to remove contradictory information, somewhat like: ... uma barra adicional para prevenir a interpretação pelo Python ... "é necessário interver na decisão" should be "intervir" ou "decidir"? Too bad there isn't a proper word for "string" as used in computer science, so, it should be better to use it instead of something like "texto quotado" or "cadeia de caracteres". "mas define environments adicionais" should be ok to translate to "ambientes" or "interfaces"? Now in doc/pt/tutorial/programming.rst... Esse "preparsing" ..., should translate to Essa "preparação" ... "Nenhum pré-processador (preparsing)", just write "Nenhum pré-processamento" mapeamento de objetos "hashable" em objetos arbitrários probably better to s/"hashable"/(hash table)/. Or call it somewhat like "lista associativa". "O Python possui um tipo set (conjuntos) nativo." should not mix quoting or parenthesis from/to english :-) Better to use "O Python possui um tipo de conjuntos (set) nativo." Or even be more verbose as in "(set em inglês)" as pattern done later in tour_advanced.rst but in same place a mispelling :-) "(singla em inglês)" instead of "(sigla em inglês)". "laços (loops)" just use "interações"? "Profiling" is another word without proper translation as used in computer sciences, could use somewhat like "análise de desempenho", but probably just to clarify what the term "profiling" stands for. "As macros utilizadas ... environment". Macro in portuguese, is the antonym of micro, so, a non programmer will not understand. The non translated environment could be "campo" (instead of the usual 1 to 1 ambiente translation). I prefer to read "entretanto" instead of "todavia" but either is correct. In doc/pt/tutorial/tour_assignment.rst ... O Python é uma linguagem "dinâmicamente digitada" ... should be ... O Python é uma linguagem de tipagem dinâmica ... I also prefer to use "Sage" or "Python" instead of "O Sage" or "O Python". Same for C, should be "tipagem estática", and then remove the english text in parenthesis. Now in doc/pt/tutorial/tour_coercion.rst... T
Re: [sage-devel] Any Portuguese reader around? Translations need review
Em 10 de abril de 2012 05:05, Gustavo de Oliveira escreveu: > I have recently uploaded to the trac server a Portuguese translation of "A > Tour of Sage" and "Tutorial": > > http://trac.sagemath.org/sage_trac/ticket/12502 > http://trac.sagemath.org/sage_trac/ticket/12822 > > If you read Portuguese, please review the above tickets. If you know someone > who could do that, please let him know. Otherwise I will look for reviewers. > It just happens that I don't have any Portuguese reader near me at the > moment... I did at first a quick look and it appears good. Will attempt a proper review with the pt_BR and english texts side by side. But can only help with check for mistakes or something really odd, cannot help much in getting the text not looking like output of google translator a few times :-) Need also to check if it is explicitly tagged as pt_BR, because from what I read, it is pt_BR. > -- Gustavo de Oliveira > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Natural language interface to sage
Em 29 de fevereiro de 2012 19:24, Julien Puydt escreveu: > Le mercredi 29 février, Jan Groenewald a écrit: >> Hi >> >> On 29 February 2012 22:21, Julien Puydt >> wrote: >> >> > If it only built what it *needs to build*, not what it *needs*, then >> > there would be a gain too. Let me stress again : I have some of the >> > things it needs already, so it could just use it. >> > >> > >> I was under the impression... >> >> Building Sage Just Works because it insists on such tightly coupled >> versions of its components. This is why the debianization of Sage was >> such a hard project. It is probably a good (very very long) long term >> goal though. > > That is why in all serious systems I know, package dependencies are > versioned. Tightly if needed. And yes, it is a long term goal. But it's > worthy. > >> That is why I want to not-debianize sage, but to make a from-source >> version of Sage in a PPA for Ubuntu, containing all the >> Sage-sanctioned components. > > How many distributions have sage? [by distribution, I mean linux > distributions, but also the various BSD variants] I have been packaging sagemath, "integrated" in Mandriva since late sage 3.x. There is also sage-on-gentoo. Not sure if other distro does it "integrated" in the distro (MIB did it based on my sagemath-4.x packages, MIB stands for Mandriva International Backports as I only package to Mandriva cooker development version). >> The weaker but valid object is wasted space, time, and cpu in >> building, but the larger objection is security. Sage now has to watch >> the security updates for each component, and so will not get into >> Debian as a single from-source build, only into a PPA. > > And when two packages have bad interactions, it becomes > the sage developpers problem. It would add a lot more work for sage to support different versions of components, but like it or not, sage developers are better at fixing sage to work with different versions, e.g. I had lots of trouble due to most times using python-2.6 and sage using python-2.5, or using python-2.7 and sage using python-2.6. But there are other issues, for example, ipython in my package I just build the version that works with sage, and set it to $PATH and or $PYTHONPATH > And when a sage package has a bad interaction with a system piece of > code, then that's a sage developper problem too. [I'm thinking very > specifically about the termcap issues.] Recently I started packaging several R- packages; R in Mandriva was outdated, so, I updated to R-2.14.1, and while at that, also imported over 330 R packages in the distro, and plan to do more, so that I should solve most issues users would not be expected to fix themselves. R appears to work a lot better with recent software in distros. But R packages are more like python modules... > Snark on #sagemath Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] New flask notebook; please test
Em 19 de outubro de 2011 23:33, Dan Drake escreveu: > On Tue, 18 Oct 2011 at 03:17AM -0500, Jason Grout wrote: >> I think we've fixed the last remaining bugs in the flask notebook. >> Can people please test the new flask notebook, either at >> test.sagenb.org, or by following the instructions here: >> http://code.google.com/r/jasongrout-flask-sagenb/ >> >> We are looking for any regressions compared to the released version >> of the notebook in Sage 4.7.1 or any regression compared to >> sagenb.org. > > Is Jmol working? I can't get Jmol to work on test.sagenb, using either > Firefox 7 or Chromium 14; I get the applet window, it says "Loading Jmol > applet..." and a seconds counter that just keeps counting. No plot ever > appears. > > Locally, I can use Sage 4.7.1 from the command line and via the notebook > and Jmol works. > > I'm using OpenJDK on Ubuntu Oneiric, 64 bit. Has anyone else seen this? I updated Mandriva (cooker) to use $ rpm -q java-1.7.0-openjdk icedtea-web java-1.7.0-openjdk-1.7.0.1-2.0.3-mdv2012.0.x86_64 icedtea-web-1.1.4.1-1-mdv2012.0.x86_64 and I also commented about flask.sagenb.org as a test case at http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=866 Now, in firefox it appears I have this symptom of counter never stopping in firefox (actually, did not way more than 600 seconds). What I see in the terminal for firefox: $ firefox java version "1.7.0_b147-icedtea" OpenJDK Runtime Environment (Mandriva-2.0.3-x86_64) OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode) Jmol applet jmolApplet0__40509062449486__ initializing AppletRegistry.checkIn(jmolApplet0__40509062449486__) Jmol applet jmolApplet0__40509062449486__ initializing AppletRegistry.checkIn(jmolApplet0__40509062449486__) urlImage=jar:http://flask.sagenb.org/java/jmol/JmolApplet0.jar!/jmol75x29x8.gif Jmol applet jmolApplet1__40509062449486__ initializing 1722 script command tokens applet context: -applet appletDocumentBase=http://flask.sagenb.org/doc/live/tutorial/ appletCodeBase=http://flask.sagenb.org/java/jmol/ AppletRegistry.checkIn(jmolApplet1__40509062449486__) Jmol applet jmolApplet1__40509062449486__ initializing (C) 2009 Jmol Development Jmol Version: 12.0.45 2011-05-21 18:09 java.vendor: Oracle Corporation java.version: 1.7.0_b147-icedtea os.name: Linux memory: 165.3/245.4 processors available: 4 useCommandThread: false appletId:jmolApplet0__40509062449486__ urlImage=jar:http://flask.sagenb.org/java/jmol/JmolApplet0.jar!/jmol75x29x8.gif FileManager opening http://flask.sagenb.org/java/jmol/appletweb/SageMenu.mnu 1722 script command tokens applet context: -applet applet context: -applet appletDocumentBase=http://flask.sagenb.org/doc/live/tutorial/ appletCodeBase=http://flask.sagenb.org/java/jmol/ appletDocumentBase=http://flask.sagenb.org/doc/live/tutorial/ appletCodeBase=http://flask.sagenb.org/java/jmol/ (C) 2009 Jmol Development Jmol Version: 12.0.45 2011-05-21 18:09 java.vendor: Oracle Corporation java.version: 1.7.0_b147-icedtea os.name: Linux memory: 180.5/245.4 processors available: 4 useCommandThread: false appletId:jmolApplet0__40509062449486__ (C) 2009 Jmol Development Jmol Version: 12.0.45 2011-05-21 18:09 java.vendor: Oracle Corporation java.version: 1.7.0_b147-icedtea os.name: Linux memory: 180.5/245.4 processors available: 4 useCommandThread: false appletId:jmolApplet1__40509062449486__ FileManager opening http://flask.sagenb.org/java/jmol/appletweb/SageMenu.mnu FileManager opening http://flask.sagenb.org/java/jmol/appletweb/SageMenu.mnu defaults = "Jmol" backgroundColor = "black" language=pt_BR FileManager opening http://flask.sagenb.org/home/_sage_/127/cells/14/sage0-size500.jmol?1329234859 FileManager opening http://flask.sagenb.org/home/_sage_/127/cells/14//home/_sage_/127/cells/14//home/_sage_/127/cells/14//home/_sage_/127/cells/14/cells/14/sage0-size500-390427185.jmol.zip ERRO no "script": ERRO no "script": io error reading http://flask.sagenb.org/home/_sage_/127/cells/14//home/_sage_/127/cells/14//home/_sage_/127/cells/14//home/_sage_/127/cells/14/cells/14/sage0-size500-390427185.jmol.zip|SCRIPT: java.io.FileNotFoundException: http://flask.sagenb.org/home/_sage_/127/cells/14//home/_sage_/127/cells/14//home/_sage_/127/cells/14//home/_sage_/127/cells/14/cells/14/sage0-size500-390427185.jmol.zip And for chromium-browser it still gets somewhat confused with paths: $ chromium-browser $ java version "1.7.0_b147-icedtea" OpenJDK Runtime Environment (Mandriva-2.0.3-x86_64) OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode) Jmol applet jmolApplet0__44187487475574__ initializing AppletRegistry.checkIn(jmolApplet0__44187487475574__) Jmol applet jmolApplet1__44187487475574__ initializing AppletRegistry.checkIn(jmolApplet1__44187487475574__) urlImage=jar:http://flask.sagenb.org/java/jmol/JmolApplet0.jar!/jmol75x29x8.gif java.lang.ArrayIndexOutOfBoundsException: 2 at sun.applet.PluginAppletSecurityContext.handleMessage(PluginAppletSecurityContext.java:856) at sun.applet.A
Re: [sage-devel] Compilation failure of pari (ARM, gcc 4.6.2)
2012/2/4 Julien Puydt : > Hi, > > I upgraded my AC100 to (a snapshot of the forthcoming) ubuntu precise, > thinking it woud perhaps raise new issues, and that would be interesting to > detect them beforehand. > > And indeed, pari doesn't compile! > > One of the files gives an assembler file which doesn't compile, but the > problem is optimization-dependent : > > (sage subshell) hecke:Olinux-armv7l jpuydt$ make > gcc -c -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer -g > -funroll-loops -fPIC -I. -I../src/headers > -I/home/jpuydt/sage-4.8/local/include -o mp.o mp.c Try running something like: gcc -c -S -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer -g -funroll-loops -fPIC -I. -I../src/headers -I/home/jpuydt/sage-4.8/local/include -o mp.s mp.c and then look at the assembler generated in mp.s you can also s/-S/-E/; s/mp.s/mp.e/ or variant to reduce to, and create a self contained small test case and report upstream. If you want it "working now", you can try removing -funroll-loops > /tmp/ccgVJ73D.s: Assembler messages: > /tmp/ccgVJ73D.s:376: Error: branch out of range > /tmp/ccgVJ73D.s:5127: Error: branch out of range > make: *** [mp.o] Erreur 1 > SAGE_ROOT=/home/jpuydt/sage-4.8 > (sage subshell) hecke:Olinux-armv7l jpuydt$ gcc -c -O2 -Wall > -fno-strict-aliasing -fomit-frame-pointer -g -funroll-loops -fPIC -I. > -I../src/headers -I/home/jpuydt/sage-4.8/local/include -o mp.o mp.c > /tmp/ccMfUGHc.s: Assembler messages: > /tmp/ccMfUGHc.s:376: Error: branch out of range > /tmp/ccMfUGHc.s:5120: Error: branch out of range > SAGE_ROOT=/home/jpuydt/sage-4.8 > (sage subshell) hecke:Olinux-armv7l jpuydt$ gcc -c -O -Wall > -fno-strict-aliasing -fomit-frame-pointer -g -funroll-loops -fPIC -I. > -I../src/headers -I/home/jpuydt/sage-4.8/local/include -o mp.o mp.c > SAGE_ROOT=/home/jpuydt/sage-4.8 > > The gcc version is Ubuntu/Linaro 4.6.2-12ubuntu1. > > I'll try to investigate where the problem is (pari? gcc? other?), but I > thought sharing early would raise good suggestions. Hard to tell without looking at what is being generated, but I suspect something related to -mimplict-it=??? assembler option with the assembler generating extra code, and branch encoding for short jumps (8 or 11 bits). You can add -marm to CFLAGS and then it can only generate 24 bit displacement jumps... > Snark on #sagemath Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] FreeBSD and Sage
2012/1/22 François Bissey : > On Sun, 22 Jan 2012 17:31:34 Stephen Montgomery-Smith wrote: >> One thing I want to rule out is that the problem is created by python. >> FreeBSD has a working python version 2.7. How do I tell the sage build >> to use the FreeBSD python rather than building its own? > That kind of scenario is very much unsupported (He says while producing > sage-on-gentoo that does just that). > Seriously using system python with the stock sage tarball is just asking > for a lot of pain (including serious patching). The major problem is "bootstraping", and possibly "political" issues if you need patches in other packages you do not maintain. Once you get it working, usually updating to a newer sagemath is reasonably simple, just don't let it rot for too long. François know I did not look in my sage package for almost too months :-) While I had some known doctest failures for very long due to using a different version of some component, e.g. python, for several times I found bugs that just did not trigger in sage due to it not using packages outside its install tree. > I don't think your problem is with python strictly speaking, if it turns out > to be pynac, that's quite different, although discussion is that something > in the sage code can be done to mitigate the issue. Since the problem appears to be related to linbox, besides the patch I suggested, maybe this can help: $ ldd /usr/lib64/liblinboxsage.so.0.0.0 linux-vdso.so.1 => (0x7fff24f62000) libntl.so.5 => /usr/lib64/../lib64/libntl.so.5 (0x7f1670bd9000) liblinbox.so.0 => /usr/lib64/../lib64/liblinbox.so.0 (0x7f16709c7000) libcblas.so.3 => /usr/lib64/atlas-sse3/libcblas.so.3 (0x7f167076e000) libgmp.so.10 => /usr/lib64/../lib64/libgmp.so.10 (0x7f167050) libgivaro.so.0 => /usr/lib64/../lib64/libgivaro.so.0 (0x7f16702b2000) libstdc++.so.6 => /usr/lib64/../lib64/libstdc++.so.6 (0x7f166ffb4000) libm.so.6 => /lib64/libm.so.6 (0x7f166fd3) libc.so.6 => /lib64/libc.so.6 (0x7f166f98) libgcc_s.so.1 => /usr/lib64/../lib64/libgcc_s.so.1 (0x7f166f76b000) libgf2x.so.1 => /usr/lib64/libgf2x.so.1 (0x7f166f55d000) libatlas.so.3 => /usr/lib64/atlas-sse3/libatlas.so.3 (0x7f166ef44000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f166ed28000) /lib64/ld-linux-x86-64.so.2 (0x7f167136c000) $ ldd /usr/lib64/liblinbox.so.0.0.0 linux-vdso.so.1 => (0x7fff6bbf) libstdc++.so.6 => /usr/lib64/../lib64/libstdc++.so.6 (0x7fbf6f86b000) libm.so.6 => /lib64/libm.so.6 (0x7fbf6f5ab000) libc.so.6 => /lib64/libc.so.6 (0x7fbf6f1fc000) libgcc_s.so.1 => /usr/lib64/../lib64/libgcc_s.so.1 (0x7fbf6efe7000) /lib64/ld-linux-x86-64.so.2 (0x7fbf6fd7b000) > Francois Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] FreeBSD and Sage
2012/1/22 Stephen Montgomery-Smith : > On 01/21/2012 08:05 PM, Stephen Montgomery-Smith wrote: >> >> I am able to build sage on FreeBSD. I have attached a tar file which >> contains a "port" to build sage on FreeBSD. (FreeBSD users will know >> what I mean by a "port.") >> >> It does seem to work, but it segfaults on exit: >> >> %./sage >> -- >> | Sage Version 4.8, Release Date: 2012-01-20 | >> | Type notebook() for the GUI, and license() for information. | >> -- >> sage: 1+1 >> 2 >> sage: exit >> Exiting Sage (CPU time 0m0.03s, Wall time 0m6.24s). >> local/bin/sage-sage: line 303: 22511 Segmentation fault: 11 (core >> dumped) sage-ipython "$@" -i >> >> Any ideas on how to proceed? >> > > > I did a "sage -gdb" and it suggests that the problem might be to do with > ~Commentator in commentator.C. This is part of the linbox subpackage. I did > a google and found this: http://trac.sagemath.org/sage_trac/ticket/11718 > > Does construction and/or deconstruction of Commentator tend to cause > problems? I do not remember all details about this, but hopefully this can help http://svn.mandriva.com/viewvc/packages/cooker/linalg-linbox/current/SOURCES/linbox-1.1.6-build.patch?view=markup Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Debian Version?
2011/11/11 Francois Bissey : >> On Fri, Nov 11, 2011 at 12:59 PM, frosty wrote: >> > I have just discovered Sage & want to know if there are any folks here >> > working on making a Debian version that would work without having to >> > compile all the parts. i.e. use the needed files, apps & libraries >> > that are already packaged in Debian. >> >> There are people in the Mandriva and Gentoo communities that have got >> Sage (mostly) into their distros. Nobody in Debian is taking on the >> challenge, as it turns out. All it would take would be somebody who >> really wanted to do it (and had the drive). >> >> > Secondly I have downloaded the binary for Linux and have it installed >> > & runnimng: I want to actually compile Sage for my server which is an >> > AMD 6 core based server with 8Gb of ram running Debian stable. I >> > tried , but it errored out, error 1 showing a segmentation fault. I am >> > including the message snippet part of the install log to this mail. >> > Maybe it will help. >> >> Either you have some really old version of GCC that is broken, your >> compilers are misinstalled, or your hardware is somehow broken. >> "internal compiler error" means the compiler crashed, which can be >> caused by faulty hardware or a buggy compiler. >> > I think that when tabbott tried to get it into debian he tried to take the > highway in some way. In debian you can add repo. > Someone with debian knowledge could take the work we have done in > Gentoo and Mandriva and create a sage repo with binaries for debian. > All that is needed is someone with the drive, I, Christopher and Paulo > (Mandriva) would certainly help someone taking that route. The major issue of working on integrating sage on a distro is how to keep up with upstream versions of packages. Save for packages where sage is upstream, I cannot, or not dare to, tell package maintainers to freeze for several years some packages, so, I either get it to work with sage or use some approach to have sage using the older version it distributes. The other major issue is when sage needs patches. You know, getting a patch in some projects sometimes may be an impossible mission, for the most different reasons. And then, if you attempt to add a patch to the package as distributed by the distro and you are not the maintainer, you may clash with that package maintainer because the patch does not come from upstream... But after all, I would say that like 95% of packages just works with the system version, and can keep up to date with updates. The major problem is getting it to work in the first time, after that, as long as it does not rot for too long, maintenance is a lot easier. Since start of working on sage on Mandriva I was expecting other distros to do the same, so that sage developers would actually use sage as shipped by their preferred distro, and would be a win win for everybody. Gentoo is doing a great job :-) > Francois Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Feedback of update to sagemath 4.7.2 Mandriva rpm package
Em 9 de novembro de 2011 23:27, Paulo César Pereira de Andrade
escreveu:
> Em 9 de novembro de 2011 23:24, Paulo César Pereira de Andrade
> escreveu:
>
>> But, since gmpy call to mp_set_memory_functions is kind of redundant,
>> as it just ends up calling malloc/realloc/free anyway, with this patch:
>
> Err, this patch probably should require an environment variable, because
> what it calls actually is:
> if(!(res = PyMem_Malloc(usize)))
> Py_FatalError("mp_allocate failure");
> ...
> if(!(res = PyMem_Realloc(ptr, unew)))
> Py_FatalError("mp_reallocate failure");
> ...
> PyMem_Free(ptr);
>
> I think this may be related to some double free issues I noticed some
> time ago.
I opened two upstream tickets about it:
http://code.google.com/p/gmpy/issues/detail?id=49
http://code.google.com/p/mpmath/issues/detail?id=215
In the meantime, I will take the safe path of making the sagemath
package conflict with gmpy.
Paulo
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Feedback of update to sagemath 4.7.2 Mandriva rpm package
Em 9 de novembro de 2011 23:24, Paulo César Pereira de Andrade
escreveu:
> But, since gmpy call to mp_set_memory_functions is kind of redundant,
> as it just ends up calling malloc/realloc/free anyway, with this patch:
Err, this patch probably should require an environment variable, because
what it calls actually is:
if(!(res = PyMem_Malloc(usize)))
Py_FatalError("mp_allocate failure");
...
if(!(res = PyMem_Realloc(ptr, unew)))
Py_FatalError("mp_reallocate failure");
...
PyMem_Free(ptr);
I think this may be related to some double free issues I noticed some
time ago.
Paulo
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Feedback of update to sagemath 4.7.2 Mandriva rpm package
2011/11/9 Francois Bissey : >> >> rsync://distrib-coffee.ipsl.jussieu.fr/pub/linux/MandrivaLinux/devel/co > >> oker/x86_64/media/contrib/release/python-gmpy-1.14-1mdv2011.0.x86_64.rpm >> instalando python-gmpy-1.14-1mdv2011.0.x86_64.rpm a partir de >> /var/cache/urpmi/rpms >> Preparando... > > Interesting mix of French and Brazilian Portuguese. What happens you try to Forgot to add LC_ALL=C to sample command line :-) > use mpmath on its own (it will use sage in the background) but I am > wondering > if it will spit all these glic warnings. ]$ python Python 2.7.2 (default, Aug 30 2011, 03:39:21) [GCC 4.6.1 20110826 (Mandriva)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mpmath Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/site-packages/mpmath/__init__.py", line 6, in from .ctx_mp import MPContext File "/usr/lib/python2.7/site-packages/mpmath/ctx_mp.py", line 48, in from sage.libs.mpmath.ext_main import Context as BaseMPContext File "parent.pxd", line 11, in init sage.libs.mpmath.ext_main (sage/libs/mpmath/ext_main.c:24996) File "element.pxd", line 12, in init sage.structure.parent (sage/structure/parent.c:21563) File "element.pyx", line 184, in init sage.structure.element (sage/structure/element.c:28577) File "/usr/lib64/python2.7/site-packages/sage/misc/sageinspect.py", line 161, in SAGE_ROOT = os.environ["SAGE_ROOT"] File "/usr/lib64/python2.7/UserDict.py", line 23, in __getitem__ raise KeyError(key) KeyError: 'SAGE_ROOT' >>> $ MPMATH_NOSAGE=1 python Python 2.7.2 (default, Aug 30 2011, 03:39:21) [GCC 4.6.1 20110826 (Mandriva)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mpmath Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/site-packages/mpmath/__init__.py", line 6, in from .ctx_mp import MPContext File "/usr/lib/python2.7/site-packages/mpmath/ctx_mp.py", line 48, in from sage.libs.mpmath.ext_main import Context as BaseMPContext File "parent.pxd", line 11, in init sage.libs.mpmath.ext_main (sage/libs/mpmath/ext_main.c:24996) File "element.pxd", line 12, in init sage.structure.parent (sage/structure/parent.c:21563) File "element.pyx", line 184, in init sage.structure.element (sage/structure/element.c:28577) File "/usr/lib64/python2.7/site-packages/sage/misc/sageinspect.py", line 161, in SAGE_ROOT = os.environ["SAGE_ROOT"] File "/usr/lib64/python2.7/UserDict.py", line 23, in __getitem__ raise KeyError(key) KeyError: 'SAGE_ROOT' >>> But, since gmpy call to mp_set_memory_functions is kind of redundant, as it just ends up calling malloc/realloc/free anyway, with this patch: -mp_set_memory_functions(gmpy_allocate, gmpy_reallocate, gmpy_free); +//mp_set_memory_functions(gmpy_allocate, gmpy_reallocate, gmpy_free); and rebuild/reinstall of python mpmath, it works, e.g. without the patch: $ GMPY_DEBUG=99 echo "import mpmath" | sage -- | Sage Version 4.7.2, Release Date: 2011-10-29 | | Type notebook() for the GUI, and license() for information.| -- *** glibc detected *** python: realloc(): invalid pointer: 0x02e067e0 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02dac530 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02dac550 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02dac570 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02e462e0 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02e46300 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02d472a0 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02d472c0 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02e06da0 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02e06dc0 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02e45cd0 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02e269c0 *** *** glibc detected *** python: realloc(): invalid pointer: 0x0249a3e0 *** *** glibc detected *** python: realloc(): invalid pointer: 0x020d1250 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02148320 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02ad6960 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02c30e80 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02587d90 *** *** glibc detected *** python: realloc(): invalid pointer: 0x021ceb80 *** *** glibc detected *** python: realloc(): invalid pointer: 0x028b8570 *** *** glibc detected *** python: realloc(): invali
Re: [sage-devel] Feedback of update to sagemath 4.7.2 Mandriva rpm package
2011/11/9 Francois Bissey : >> 2011/11/9 Francois Bissey : > >> >> Maybe setting MPMATH_NOGMPY is not enough to prevent it to >> call to gmpy "init" function that calls mp_set_memory_functions. >> >> I will try to debug a bit further, in the worst case, I can resubmit a >> sagemath package with "Conflicts: python-gmpy". I had it for a long >> time with "Conflicts: python-numpy" when using the patch to use s/python-numpy/python-mpmath/ >> sympy version of mpmath... With the conflicts rpm information, it >> asks the user for removal of the package unless using some >> "--force" like option (actually, usually --nodeps). >> > I already complained to mpmath upstream that they have added some code > that looks for sage even if MPMATH_NOSAGE is set, it could be that something > similar has been done with gmpy. I only noticed that if having sagemath installed, it will fail to build documentation if SAGE_ROOT, etc environment variables are not set. It can be worked around by building the package under "sage -sh" but that is kind ugly :-) > Upstream listened to my request favorably but we may have to contribute the > bits. I'll search my home inbox for it. There was some good suggestions on > what to do. Sample of run: MPMATH_NOGMPY=1 GMPY_DEBUG=99 sage -t -force_lib "devel/sage/sage/rings/integer.pyx" besides all warnings in format: *** glibc detected *** python: free(): invalid pointer: 0x0585b770 *** *** glibc detected *** python: free(): invalid pointer: 0x0585b750 *** *** glibc detected *** python: free(): invalid pointer: 0x0585b730 *** *** glibc detected *** python: free(): invalid pointer: 0x0585b710 *** *** glibc detected *** python: free(): invalid pointer: 0x0494c200 *** *** glibc detected *** *** glibc detected *** python: free(): invalid pointer: 0x0585b690 *** I see: sage -t -force_lib "devel/sage/sage/rings/integer.pyx" [?1034hinitgmpy() called... Entering set_pympzcache Entering set_pympqcache gmpy_module at 0x7f68ffb122b8 gmpy_module imported copy_reg OK Pygmpy_mpz() called... Entering Pympz_new Pympz_new is creating a new object Initing new not in zcache mp_allocate( 8->16 ) mp_allocate( 8->16 ) ->0x49929b0 anynum2Pympz(0x1c949b0)->0x7f690096c530 Pygmpy_mpz: created mpz = 0 Pympz_dealloc: 0x7f690096c530 Pygmpy_mpq() called... Entering Pympq_new Pympq_new is creating a new object Initing new not in qcache mp_allocate( 8->16 ) mp_allocate( 8->16 ) ->0x4b8afb0 mp_allocate( 8->16 ) mp_allocate( 8->16 ) ->0x470f620 Initing new not in qcache, done anynum2Pympq(0x1c949b0)->0x7f68ffb14630 ... Or less output: $ sudo urpmi python-gmpy; MPMATH_NOGMPY=1 GMPY_DEBUG=99 echo "import mpmath" | sage rsync://distrib-coffee.ipsl.jussieu.fr/pub/linux/MandrivaLinux/devel/cooker/x86_64/media/contrib/release/python-gmpy-1.14-1mdv2011.0.x86_64.rpm instalando python-gmpy-1.14-1mdv2011.0.x86_64.rpm a partir de /var/cache/urpmi/rpms Preparando...# 1/1: python-gmpy # -- | Sage Version 4.7.2, Release Date: 2011-10-29 | | Type notebook() for the GUI, and license() for information.| -- *** glibc detected *** python: realloc(): invalid pointer: 0x03b1ef50 *** *** glibc detected *** python: realloc(): invalid pointer: 0x03b1ef70 *** *** glibc detected *** python: realloc(): invalid pointer: 0x03adad80 *** *** glibc detected *** python: realloc(): invalid pointer: 0x03a1aff0 *** *** glibc detected *** python: realloc(): invalid pointer: 0x03b0e4f0 *** *** glibc detected *** python: realloc(): invalid pointer: 0x033081b0 *** *** glibc detected *** python: realloc(): invalid pointer: 0x03228460 *** *** glibc detected *** python: realloc(): invalid pointer: 0x029fd4b0 *** *** glibc detected *** python: realloc(): invalid pointer: 0x033e15b0 *** *** glibc detected *** python: realloc(): invalid pointer: 0x033e04d0 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02d69920 *** *** glibc detected *** python: realloc(): invalid pointer: 0x031f5e00 *** *** glibc detected *** python: realloc(): invalid pointer: 0x031f58a0 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02ca0d30 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02796220 *** *** glibc detected *** python: realloc(): invalid pointer: 0x02574490 *** *** glibc detected *** python: realloc(): invalid pointer: 0x0309c050 *** *** glibc detected *** python: realloc(): invalid pointer: 0x035702a0 *** *** glibc detected *** python: realloc(): invalid pointer: 0x032a79a0 *** *** glibc detected *** python: realloc(): invalid point
Re: [sage-devel] Feedback of update to sagemath 4.7.2 Mandriva rpm package
2011/11/9 Francois Bissey : >> Em 9 de novembro de 2011 00:29, Paulo César Pereira de Andrade >> >> escreveu: >> > 2011/11/8 Francois Bissey : >> >>> 2011/11/8 Francois Bissey : >> >>> >> >>> [...] >> >>> >> >>> > I don't get any of that. I suspect there may be an issue with >> >>> > gmp/mpir. But I have really no clue about the glibc problem, you are >> >>> > using mpmath-0.17 I expect. >> >>> >> >>> Yes, mpmath-0.17. >> >>> >> >>> This should be an issue with gmp / pylong / ntl conversions, in >> >>> >> >>> the sage/c_lib/src/*c or sage/c_lib/include/*.h >> >>> >> >>> Should be an off by one wordsize miscalculation of some buffer. >> >>> >> >>> I will try to debug some of it soon, but in the meantime, these may >> >>>ring >> >>> >> >>> some bell to somebody... >> >>> >> >>> Invalid write of size 8 >> >>> ==6304== at 0x1FCB67F8: ??? (in /usr/lib64/libgmp.so.10.0.2) >> >>> ==6304== by 0x1FCB7253: __gmpz_fac_ui (in >> >>> /usr/lib64/libgmp.so.10.0.2) ==6304== by 0x2728775F: ??? (in >> >>> /usr/lib64/python2.7/site-packages/sage/rings/integer.so) >> >>> ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 >> >>> alloc'd >> >>> >> >>> ==6304== Invalid read of size 8 >> >>> ==6304== at 0x1FA956B5: ??? (in /usr/lib64/libcsage.so) >> >>> ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 >> >>> alloc'd >> >>> >> >>> ==6304== Invalid read of size 8 >> >>> ==6304== at 0x1FA95871: mpn_get_pylong (in /usr/lib64/libcsage.so) >> >>> ==6304== by 0x1FA95D61: mpz_get_pylong (in /usr/lib64/libcsage.so) >> >>> ==6304== by 0x1FA95DCB: mpz_get_pyintlong (in >> >>> /usr/lib64/libcsage.so) ==6304== Address 0x29c39df8 is 0 bytes after >> >>> a block of size 8 alloc'd >> >>> >> >>> ==6304== Invalid write of size 8 >> >>> ==6304== at 0x1FA95A74: mpn_set_pylong (in /usr/lib64/libcsage.so) >> >>> ==6304== by 0x1FA95E7B: mpz_set_pylong (in /usr/lib64/libcsage.so) >> >>> ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 >> >>> alloc'd >> >>> >> >>> ==6304== Invalid read of size 8 >> >>> ==6304== at 0x1FCC06AA: __gmpz_sizeinbase (in >> >>> /usr/lib64/libgmp.so.10.0.2) ==6304== Address 0x29c39df8 is 0 bytes >> >>> after a block of size 8 alloc'd >> >>> >> >>> .. >> >>> >> >>> Also miscalculation and warning because of reading non initialized >> >>>data >> >>> >> >>> ==6304== Conditional jump or move depends on uninitialised value(s) >> >>> ==6304== at 0x1FCB7EE3: __gmpz_fits_slong_p (in >> >>> /usr/lib64/libgmp.so.10.0.2) ==6304== by 0x1FA95DA5: >> >>> mpz_get_pyintlong (in /usr/lib64/libcsage.so) >> >>> >> >>> ==6304== Conditional jump or move depends on uninitialised value(s) >> >>> ==6304== at 0x1FA95689: ??? (in /usr/lib64/libcsage.so) >> >>> ==6304== by 0x1FA957E6: mpn_pylong_size (in /usr/lib64/libcsage.so) >> >>> ==6304== by 0x1FA95CD8: mpz_get_pylong (in /usr/lib64/libcsage.so) >> >>> ==6304== by 0x1FA95DCB: mpz_get_pyintlong (in >> >>> /usr/lib64/libcsage.so) >> >>> >> >>> ==6304== Use of uninitialised value of size 8 >> >>> ==6304== at 0x1FA956B5: ??? (in /usr/lib64/libcsage.so) >> >>> ==6304== by 0x1FA957E6: mpn_pylong_size (in /usr/lib64/libcsage.so) >> >>> ==6304== by 0x1FA95CD8: mpz_get_pylong (in /usr/lib64/libcsage.so) >> >>> ==6304== by 0x1FA95DCB: mpz_get_pyintlong (in >> >>> /usr/lib64/libcsage.so) >> >>> >> >>> And a lot of other warnings following this pattern. >> >>> >> >> Hi Paulo, >> >> >> >> with gmp5 I had to do the following for sage to even compile in >> >> sage/rings/integer.so precisely: >> >> sed -i "s:__GMP_BITS_PER_MP_LIMB:GMP_LIMB_BITS:g" >> >> sage/rings/integer.pyx >> >> >> >
Re: [sage-devel] Feedback of update to sagemath 4.7.2 Mandriva rpm package
Em 9 de novembro de 2011 00:29, Paulo César Pereira de Andrade escreveu: > 2011/11/8 Francois Bissey : >>> 2011/11/8 Francois Bissey : >>> >>> [...] >>> >>> > I don't get any of that. I suspect there may be an issue with gmp/mpir. >>> > But I have really no clue about the glibc problem, you are using >>> > mpmath-0.17 I expect. >>> >>> Yes, mpmath-0.17. >>> >>> This should be an issue with gmp / pylong / ntl conversions, in >>> the sage/c_lib/src/*c or sage/c_lib/include/*.h >>> >>> Should be an off by one wordsize miscalculation of some buffer. >>> >>> I will try to debug some of it soon, but in the meantime, these may ring >>> some bell to somebody... >>> >>> Invalid write of size 8 >>> ==6304== at 0x1FCB67F8: ??? (in /usr/lib64/libgmp.so.10.0.2) >>> ==6304== by 0x1FCB7253: __gmpz_fac_ui (in /usr/lib64/libgmp.so.10.0.2) >>> ==6304== by 0x2728775F: ??? (in >>> /usr/lib64/python2.7/site-packages/sage/rings/integer.so) >>> ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 alloc'd >>> >>> ==6304== Invalid read of size 8 >>> ==6304== at 0x1FA956B5: ??? (in /usr/lib64/libcsage.so) >>> ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 alloc'd >>> >>> ==6304== Invalid read of size 8 >>> ==6304== at 0x1FA95871: mpn_get_pylong (in /usr/lib64/libcsage.so) >>> ==6304== by 0x1FA95D61: mpz_get_pylong (in /usr/lib64/libcsage.so) >>> ==6304== by 0x1FA95DCB: mpz_get_pyintlong (in /usr/lib64/libcsage.so) >>> ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 alloc'd >>> >>> ==6304== Invalid write of size 8 >>> ==6304== at 0x1FA95A74: mpn_set_pylong (in /usr/lib64/libcsage.so) >>> ==6304== by 0x1FA95E7B: mpz_set_pylong (in /usr/lib64/libcsage.so) >>> ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 alloc'd >>> >>> ==6304== Invalid read of size 8 >>> ==6304== at 0x1FCC06AA: __gmpz_sizeinbase (in >>> /usr/lib64/libgmp.so.10.0.2) ==6304== Address 0x29c39df8 is 0 bytes after >>> a block of size 8 alloc'd >>> >>> .. >>> >>> Also miscalculation and warning because of reading non initialized data >>> >>> ==6304== Conditional jump or move depends on uninitialised value(s) >>> ==6304== at 0x1FCB7EE3: __gmpz_fits_slong_p (in >>> /usr/lib64/libgmp.so.10.0.2) ==6304== by 0x1FA95DA5: mpz_get_pyintlong >>> (in /usr/lib64/libcsage.so) >>> >>> ==6304== Conditional jump or move depends on uninitialised value(s) >>> ==6304== at 0x1FA95689: ??? (in /usr/lib64/libcsage.so) >>> ==6304== by 0x1FA957E6: mpn_pylong_size (in /usr/lib64/libcsage.so) >>> ==6304== by 0x1FA95CD8: mpz_get_pylong (in /usr/lib64/libcsage.so) >>> ==6304== by 0x1FA95DCB: mpz_get_pyintlong (in /usr/lib64/libcsage.so) >>> >>> ==6304== Use of uninitialised value of size 8 >>> ==6304== at 0x1FA956B5: ??? (in /usr/lib64/libcsage.so) >>> ==6304== by 0x1FA957E6: mpn_pylong_size (in /usr/lib64/libcsage.so) >>> ==6304== by 0x1FA95CD8: mpz_get_pylong (in /usr/lib64/libcsage.so) >>> ==6304== by 0x1FA95DCB: mpz_get_pyintlong (in /usr/lib64/libcsage.so) >>> >>> And a lot of other warnings following this pattern. >>> >> Hi Paulo, >> >> with gmp5 I had to do the following for sage to even compile in >> sage/rings/integer.so precisely: >> sed -i "s:__GMP_BITS_PER_MP_LIMB:GMP_LIMB_BITS:g" sage/rings/integer.pyx >> >> Since that's a deprecation problem that will reach mpir eventually, we >> should >> open a ticket on trac even it is not your present problem. >> >> While I don't have a crash or any warnings I am wondering if it is >> related to http://trac.sagemath.org/sage_trac/ticket/11986 >> Since it seems that some stuff in pylong is not working as expected. >> Is it working on x86 but not on x86_64? > > For the record, do you not notice the warnings if running sage as > $ MALLOC_CHECK_=1 sage > > ? If I do not set MALLOC_CHECK_=1 I do not see any warnings, > and if setting to 2, useful in sage -gdb, I get it to call abort, what > is useful with "sage -gdb". I found a way to run it with exporting MALLOC_CHECK_=1 and not having any warnings printed. It appears to be an issue when python-gmpy is installed. If running something like: $ sudo rpm -e python-gmpy And
Re: [sage-devel] Feedback of update to sagemath 4.7.2 Mandriva rpm package
2011/11/8 Francois Bissey : >> 2011/11/8 Francois Bissey : >> >> [...] >> >> > I don't get any of that. I suspect there may be an issue with gmp/mpir. >> > But I have really no clue about the glibc problem, you are using >> > mpmath-0.17 I expect. >> >> Yes, mpmath-0.17. >> >> This should be an issue with gmp / pylong / ntl conversions, in >> the sage/c_lib/src/*c or sage/c_lib/include/*.h >> >> Should be an off by one wordsize miscalculation of some buffer. >> >> I will try to debug some of it soon, but in the meantime, these may ring >> some bell to somebody... >> >> Invalid write of size 8 >> ==6304== at 0x1FCB67F8: ??? (in /usr/lib64/libgmp.so.10.0.2) >> ==6304== by 0x1FCB7253: __gmpz_fac_ui (in /usr/lib64/libgmp.so.10.0.2) >> ==6304== by 0x2728775F: ??? (in >> /usr/lib64/python2.7/site-packages/sage/rings/integer.so) >> ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 alloc'd >> >> ==6304== Invalid read of size 8 >> ==6304== at 0x1FA956B5: ??? (in /usr/lib64/libcsage.so) >> ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 alloc'd >> >> ==6304== Invalid read of size 8 >> ==6304== at 0x1FA95871: mpn_get_pylong (in /usr/lib64/libcsage.so) >> ==6304== by 0x1FA95D61: mpz_get_pylong (in /usr/lib64/libcsage.so) >> ==6304== by 0x1FA95DCB: mpz_get_pyintlong (in /usr/lib64/libcsage.so) >> ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 alloc'd >> >> ==6304== Invalid write of size 8 >> ==6304== at 0x1FA95A74: mpn_set_pylong (in /usr/lib64/libcsage.so) >> ==6304== by 0x1FA95E7B: mpz_set_pylong (in /usr/lib64/libcsage.so) >> ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 alloc'd >> >> ==6304== Invalid read of size 8 >> ==6304== at 0x1FCC06AA: __gmpz_sizeinbase (in >> /usr/lib64/libgmp.so.10.0.2) ==6304== Address 0x29c39df8 is 0 bytes after >> a block of size 8 alloc'd >> >> .. >> >> Also miscalculation and warning because of reading non initialized data >> >> ==6304== Conditional jump or move depends on uninitialised value(s) >> ==6304== at 0x1FCB7EE3: __gmpz_fits_slong_p (in >> /usr/lib64/libgmp.so.10.0.2) ==6304== by 0x1FA95DA5: mpz_get_pyintlong >> (in /usr/lib64/libcsage.so) >> >> ==6304== Conditional jump or move depends on uninitialised value(s) >> ==6304== at 0x1FA95689: ??? (in /usr/lib64/libcsage.so) >> ==6304== by 0x1FA957E6: mpn_pylong_size (in /usr/lib64/libcsage.so) >> ==6304== by 0x1FA95CD8: mpz_get_pylong (in /usr/lib64/libcsage.so) >> ==6304== by 0x1FA95DCB: mpz_get_pyintlong (in /usr/lib64/libcsage.so) >> >> ==6304== Use of uninitialised value of size 8 >> ==6304== at 0x1FA956B5: ??? (in /usr/lib64/libcsage.so) >> ==6304== by 0x1FA957E6: mpn_pylong_size (in /usr/lib64/libcsage.so) >> ==6304== by 0x1FA95CD8: mpz_get_pylong (in /usr/lib64/libcsage.so) >> ==6304== by 0x1FA95DCB: mpz_get_pyintlong (in /usr/lib64/libcsage.so) >> >> And a lot of other warnings following this pattern. >> > Hi Paulo, > > with gmp5 I had to do the following for sage to even compile in > sage/rings/integer.so precisely: > sed -i "s:__GMP_BITS_PER_MP_LIMB:GMP_LIMB_BITS:g" sage/rings/integer.pyx > > Since that's a deprecation problem that will reach mpir eventually, we > should > open a ticket on trac even it is not your present problem. > > While I don't have a crash or any warnings I am wondering if it is > related to http://trac.sagemath.org/sage_trac/ticket/11986 > Since it seems that some stuff in pylong is not working as expected. > Is it working on x86 but not on x86_64? For the record, do you not notice the warnings if running sage as $ MALLOC_CHECK_=1 sage ? If I do not set MALLOC_CHECK_=1 I do not see any warnings, and if setting to 2, useful in sage -gdb, I get it to call abort, what is useful with "sage -gdb". Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Feedback of update to sagemath 4.7.2 Mandriva rpm package
2011/11/8 Francois Bissey : > Hi Paulo, > > with gmp5 I had to do the following for sage to even compile in > sage/rings/integer.so precisely: > sed -i "s:__GMP_BITS_PER_MP_LIMB:GMP_LIMB_BITS:g" sage/rings/integer.pyx Yes, I have been using a similar approach (rediffing patch from time to time) for quite some time. > Since that's a deprecation problem that will reach mpir eventually, we > should > open a ticket on trac even it is not your present problem. > > While I don't have a crash or any warnings I am wondering if it is > related to http://trac.sagemath.org/sage_trac/ticket/11986 > Since it seems that some stuff in pylong is not working as expected. > Is it working on x86 but not on x86_64? Cut&paste from the trac tests, I see: ]$ sage -- | Sage Version 4.7.2, Release Date: 2011-10-29 | | Type notebook() for the GUI, and license() for information.| -- sage: sage: hash(R(-1)) -2001418380740004879 sage: n = -920390823904823094890238490238484; n.__hash__() -2623069716 sage: hash(n) -2623069716 sage: hash(n) == hash(int(n)) False sage: n=2^63+2^13 sage: n 9223372036854784000 sage: hash(n) 8192 sage: int(n) 9223372036854784000L sage: hash(int(n)) -9223372036854767616 sage: > Francois Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Feedback of update to sagemath 4.7.2 Mandriva rpm package
2011/11/8 Francois Bissey : [...] > I don't get any of that. I suspect there may be an issue with gmp/mpir. But > I have really no clue about the glibc problem, you are using mpmath-0.17 > I expect. Yes, mpmath-0.17. This should be an issue with gmp / pylong / ntl conversions, in the sage/c_lib/src/*c or sage/c_lib/include/*.h Should be an off by one wordsize miscalculation of some buffer. I will try to debug some of it soon, but in the meantime, these may ring some bell to somebody... Invalid write of size 8 ==6304==at 0x1FCB67F8: ??? (in /usr/lib64/libgmp.so.10.0.2) ==6304==by 0x1FCB7253: __gmpz_fac_ui (in /usr/lib64/libgmp.so.10.0.2) ==6304==by 0x2728775F: ??? (in /usr/lib64/python2.7/site-packages/sage/rings/integer.so) ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 alloc'd ==6304== Invalid read of size 8 ==6304==at 0x1FA956B5: ??? (in /usr/lib64/libcsage.so) ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 alloc'd ==6304== Invalid read of size 8 ==6304==at 0x1FA95871: mpn_get_pylong (in /usr/lib64/libcsage.so) ==6304==by 0x1FA95D61: mpz_get_pylong (in /usr/lib64/libcsage.so) ==6304==by 0x1FA95DCB: mpz_get_pyintlong (in /usr/lib64/libcsage.so) ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 alloc'd ==6304== Invalid write of size 8 ==6304==at 0x1FA95A74: mpn_set_pylong (in /usr/lib64/libcsage.so) ==6304==by 0x1FA95E7B: mpz_set_pylong (in /usr/lib64/libcsage.so) ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 alloc'd ==6304== Invalid read of size 8 ==6304==at 0x1FCC06AA: __gmpz_sizeinbase (in /usr/lib64/libgmp.so.10.0.2) ==6304== Address 0x29c39df8 is 0 bytes after a block of size 8 alloc'd .. Also miscalculation and warning because of reading non initialized data ==6304== Conditional jump or move depends on uninitialised value(s) ==6304==at 0x1FCB7EE3: __gmpz_fits_slong_p (in /usr/lib64/libgmp.so.10.0.2) ==6304==by 0x1FA95DA5: mpz_get_pyintlong (in /usr/lib64/libcsage.so) ==6304== Conditional jump or move depends on uninitialised value(s) ==6304==at 0x1FA95689: ??? (in /usr/lib64/libcsage.so) ==6304==by 0x1FA957E6: mpn_pylong_size (in /usr/lib64/libcsage.so) ==6304==by 0x1FA95CD8: mpz_get_pylong (in /usr/lib64/libcsage.so) ==6304==by 0x1FA95DCB: mpz_get_pyintlong (in /usr/lib64/libcsage.so) ==6304== Use of uninitialised value of size 8 ==6304==at 0x1FA956B5: ??? (in /usr/lib64/libcsage.so) ==6304==by 0x1FA957E6: mpn_pylong_size (in /usr/lib64/libcsage.so) ==6304==by 0x1FA95CD8: mpz_get_pylong (in /usr/lib64/libcsage.so) ==6304==by 0x1FA95DCB: mpz_get_pyintlong (in /usr/lib64/libcsage.so) And a lot of other warnings following this pattern. > Francois Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Feedback of update to sagemath 4.7.2 Mandriva rpm package
Em 8 de novembro de 2011 04:20, Paulo César Pereira de Andrade escreveu: > 2011/11/7 Francois Bissey : > >> Hi Paulo, >> >> You are using python-2.7 right? In #9958 I have a list of patches >> as long as my arm to deal with the numerical noise and changes >> in warnings. > > Yes, python 2.7.2. Thanks for the hint on the patches. They appear > to address exactly a good share of the doctest failures I noticed. > >> For mpmath/sympy in gentoo we are now using sympy-0.7.1 with >> the patches I wrote. This will land in sage-4.8.0 proper. Now for >> Gentoo I wrote a sympy package in which I removed mpmath and >> forced sympy to use the system mpmath. >> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev- >> python/sympy/sympy-0.7.1.ebuild?revision=1.2&view=markup >> and: >> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev- >> python/sympy/files/sympy-0.7.1-mpmath.patch?revision=1.1&view=markup > > I am going to use these patches also. With the sympy/mpmath patches, I can drop a hack I have been rediff'ing for some time, but anything that uses mpmath now shows a lot of warnings like these: sage -t -force_lib "devel/sage/sage/libs/mpmath/ext_main.pyx" *** glibc detected *** python: realloc(): invalid pointer: 0x03b4d3c0 *** ... *** glibc detected *** python: realloc(): invalid pointer: 0x042465c0 *** *** glibc detected *** python: free(): invalid pointer: 0x03b4d3a0 *** *** glibc detected *** python: free(): invalid pointer: 0x035c86f0 *** [3.8 s] Previously there was only one test case with this behavior, but now it works with some test cases that would fail, most notably this: TypeError: object.__new__(sage.libs.mpmath.ext_main.mpc) is not safe, use sage.libs.mpmath.ext_main.mpc.__new__() that now works. But this one got a lot larger numeric variation, now: File "/usr/share/sage/devel/sage/sage/libs/mpmath/utils.pyx", line 367: sage: a.call(a.polylog, 2, 1/3+4/5*I) Expected: 0.153548951541433 + 0.875114412499637*I Got: 0.254715070352197 + 0.874801794256724*I and before: File "/usr/share/sage/devel/sage/sage/libs/mpmath/utils.pyx", line 367: sage: a.call(a.polylog, 2, 1/3+4/5*I) Expected: 0.153548951541433 + 0.875114412499637*I Got: 0.159841737717642 + 0.875386092681844*I Thanks, Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Feedback of update to sagemath 4.7.2 Mandriva rpm package
2011/11/7 Francois Bissey : > Hi Paulo, > > You are using python-2.7 right? In #9958 I have a list of patches > as long as my arm to deal with the numerical noise and changes > in warnings. Yes, python 2.7.2. Thanks for the hint on the patches. They appear to address exactly a good share of the doctest failures I noticed. > For mpmath/sympy in gentoo we are now using sympy-0.7.1 with > the patches I wrote. This will land in sage-4.8.0 proper. Now for > Gentoo I wrote a sympy package in which I removed mpmath and > forced sympy to use the system mpmath. > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev- > python/sympy/sympy-0.7.1.ebuild?revision=1.2&view=markup > and: > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev- > python/sympy/files/sympy-0.7.1-mpmath.patch?revision=1.1&view=markup I am going to use these patches also. > I have been patching sage to use whatever version of png on the > system for a while - since 1.4 has become stable on gentoo at least. Most things just work with png15, but others fail miserably, due to requiring access to internal data structures no longer exported... Mandriva actually did jump from png12 to png15, afaik was submitted without much testing, probably because latest firefox configure wants it. > Francois Thanks, Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Feedback of update to sagemath 4.7.2 Mandriva rpm package
Hi,
I updated the mandriva sagemath package to 4.7.2. For quite some time, I think
one year++, updates are basically a rediff of some patches, but while
the package
initially had a lot of doctest failures, then gone to a "gold age" of
like 3-5 doctest
failures for a long time, now after every newer version several
failures remain, and
newer ones are added...
But most common failure is numeric noise, e.g.:
File "/usr/share/sage/devel/sage/sage/calculus/test_sympy.py", line 23:
sage: float(pi)
Expected:
3.1415926535897931
Got:
3.141592653589793
-%<-
I think sage-on-gentoo corrected this pattern, or I may be wrong...
File "/usr/share/sage/devel/doc/en/numerical_sage/numpy.rst", line 97:
sage: 2.5*l
Expected:
array([ 0. , 2.5, 5. , 7.5, 10. , 12.5, 15. , 17.5,
20. , 22.5])
Got:
array([0.000, 2.50, 5.00,
7.50, 10.0, 12.5,
15.0, 17.5, 20.0,
22.5], dtype=object)
-%<-
Most errors should be due to different versions of some components:
File "/usr/share/sage/devel/sage/sage/misc/lazy_import.pyx", line 391:
sage: iter(version_info)
Expected:
Got:
There are several python <-> R issues:
File "/usr/share/sage/devel/sage/sage/interfaces/r.py", line 183:
sage: d['_r_class']
Expected:
'table'
Got:
['summaryDefault', 'table']
...
sage: list(sorted(d.items()))
Expected:
[('DATA', [1, 1.75, 3, 2.875, 4, 5]),
('_Names', ['Min.', '1st Qu.', 'Median', 'Mean', '3rd Qu.', 'Max.']),
('_r_class', 'table')]
Got:
[('DATA', [1, 1.75, 3, 2.875, 4, 5]), ('_Names', ['Min.', '1st
Qu.', 'Median', 'Mean', '3rd Qu.', 'Max.']), ('_r_class',
['summaryDefault', 'table'])]
-%<-
Some that show some issue somewhere:
File "/usr/share/sage/devel/sage/sage/matrix/matrix_double_dense.pyx",
line 2468:
sage: B.is_hermitian(algorithm='naive', tol=1.0e-17)
Expected:
False
Got:
True
File "/usr/share/sage/devel/sage/sage/matrix/constructor.py", line 1068:
sage: random_matrix(RR, 3, 4, density=0.66)
Expected:
[ 0.000 0.566500636438206 0.0870635178173962
0.000]
[-0.662290145671671 0.000 0.475667133865666
0.000]
[-0.276405104068647 0.000 0.000
-0.636689607643642]
Got:
[ 0.000 -0.806696574554030 -0.693915509972359
0.000]
[ 0.629781664418083 0.000 -0.833709843116637
0.000]
[ 0.922346867410064 0.000 0.000
-0.940316454178921]
-%<-
This pattern is what I think I did already debug for some time some time
ago, but never get a good solution due to wanting to use same python,
cython, etc used by the system:
File "/usr/share/sage/devel/sage/sage/modules/vector_double_dense.pyx",
line 675:
sage: v.norm(p=6)
Exception raised:
Traceback (most recent call last):
File "/usr/share/sage/local/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/usr/share/sage/local/bin/sagedoctest.py", line 38, in
run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/usr/share/sage/local/bin/ncadoctest.py", line 1172, in
run_one_example
compileflags, 1) in test.globs
File "", line 1, in
v.norm(p=Integer(6))###line 675:
sage: v.norm(p=6)
File "vector_double_dense.pyx", line 742, in
sage.modules.vector_double_dense.Vector_double_dense.norm
(sage/modules/vector_double_dense.c:6873)
File "/usr/lib64/python2.7/site-packages/numpy/linalg/linalg.py",
line 1964, in norm
return ((abs(x)**ord).sum())**(1.0/ord)
File "real_double.pyx", line 1677, in
sage.rings.real_double.RealDoubleElement.__pow__
(sage/rings/real_double.c:11391)
AttributeError: 'NoneType' object has no attribute 'parent'
...
File "/usr/share/sage/devel/sage/sage/modules/free_module_element.pyx",
line 1357:
sage: v.norm(5)
Exception raised:
Traceback (most recent call last):
File "/usr/share/sage/local/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/usr/share/sage/local/bin/sagedoctest.py", line 38, in
run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/usr/share/sage/local/bin/ncadoctest.py", line 1172, in
run_one_example
compileflags, 1) in test.globs
File "", line 1, in
v.norm(Integer(5))###line 1357:
sage: v.norm(5)
File "vector_double_dense.pyx", line 742, in
sage.modules.vector_double_dense.Vector_double_dense.norm
(sage/modules/vector_double_dense.c:6873)
File "/usr/lib64/python2.7/site-packages/numpy/linalg/linalg.py",
line 1964, in norm
return ((abs(x)**ord).sum())**(1.0/ord)
Re: [sage-devel] sage and python 2.7: migration strategies?
Em 2 de junho de 2011 11:15, Paulo César Pereira de Andrade escreveu: > 2011/6/2 Francois Bissey : >>> Em 1 de junho de 2011 18:22, Paulo César Pereira de Andrade >>> >>> escreveu: >>> > If I understand it correctly, at least for this particular case: >>> > >>> > >>> > sage/libs/singular/groebner_strategy.pyx:GroebnerStrategy(SageObject)._pa >>> > rent => >>> > sage/rings/polynomial/multi_polynomial_libsingular.pyx:MPolynomialRing_l >>> > ibsingular(MPolynomialRing_generic) >>> > >>> > and the _parent field has a __dealloc__ as: >>> > singular_ring_delete(self._ring) while the GroebnerStrategy >>> > __dealloc__ deferences _parent._ring. >>> > >>> > So, again if I understand correctly, the crash is happening because >>> > MPolynomialRing_libsingular:__deallocate__ should be called >>> > after pyx:GroebnerStrategy:__deallocate__, but in python 2.7 >>> > this is not happening, as the order is not guaranteed, and >>> > apparently just happens to be in the correct order with >>> > python 2.6. >>> >>> Sorry for replying to myself, but actually, it should be quite >>> simple to have it functional, just that it must be done in a case >>> by case approach. Something like: >>> >>> GroebnerStrategy(): >>> __new__: >>> ... >>> the_ring_handle = ... >>> incref(the_ring_handle) >>> __del__: >>> ... >>> decref(the_ring_handle) >>> del the_ring_handle ## requirement of this depends on semantics >>> >>> MPolynomialRing_libsingular(): >>> __new__: >>> ... >>> the_ring_ptr = ... >>> __del__: >>> if (refcnt(self) <= 0) ## how to do this in python? check if >>> == 1? or do not use python reference counter? >>> free(the_ring_ptr) >>> >>> This should be easy for python internal experts to >>> implement (I can try to experiment with that, but I do >>> not know much of python and only do mark&sweep :-) >>> >> Quoting Volker: >> Just to clarify, right now Cython extension classes do not call the Python >> destructor __del__ upon finalization, so Sage can't rely on this mechanism. >> I'm >> not quite sure if it is an intentional thing or if the Cython devs just >> haven't gotten around to implementing it. > > I started doing some experiments mostly for the sake of testing :-) > But my python/cython kung-fu is too weak, as well as general > knowledge of the sage "object model" and my experiments > ended in the same backtrace, so I did not work on the correct > point or something, and for now I give up. > >> So we need cython to catch up with that one. > > Cython probably will also not understand the context of > memory being allocated and released outside its control. > The proper approach should be to ensure that python does > not see reachable sage objects as a looping cycle with 0 > references, and then "breaks" the cycle in unpredictable > ways. > > In my basic understanding of sage classes, it should > release things somewhat like: > >>>> del a > ===> > list = > while length(list): > foreach item in list: > if item._parent == item: > > item._parent = None > test = map(list, _._parent == item) > if length(test) == 0: > item.__dealloc__() > remove(list, item) Err, ignore it, this is bogus for some "complex" cycles, and should be the case here, where somewhere down in MPolynomialRing_libsingular it may reference again GroebnerStrategy. I will become silent now :-) Hopefully at least this brought the problem to attention of someone that knows what is going on. >> Francois Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] sage and python 2.7: migration strategies?
2011/6/2 Francois Bissey : >> Em 1 de junho de 2011 18:22, Paulo César Pereira de Andrade >> >> escreveu: >> > If I understand it correctly, at least for this particular case: >> > >> > >> > sage/libs/singular/groebner_strategy.pyx:GroebnerStrategy(SageObject)._pa >> > rent => >> > sage/rings/polynomial/multi_polynomial_libsingular.pyx:MPolynomialRing_l >> > ibsingular(MPolynomialRing_generic) >> > >> > and the _parent field has a __dealloc__ as: >> > singular_ring_delete(self._ring) while the GroebnerStrategy >> > __dealloc__ deferences _parent._ring. >> > >> > So, again if I understand correctly, the crash is happening because >> > MPolynomialRing_libsingular:__deallocate__ should be called >> > after pyx:GroebnerStrategy:__deallocate__, but in python 2.7 >> > this is not happening, as the order is not guaranteed, and >> > apparently just happens to be in the correct order with >> > python 2.6. >> >> Sorry for replying to myself, but actually, it should be quite >> simple to have it functional, just that it must be done in a case >> by case approach. Something like: >> >> GroebnerStrategy(): >> __new__: >> ... >> the_ring_handle = ... >> incref(the_ring_handle) >> __del__: >> ... >> decref(the_ring_handle) >> del the_ring_handle ## requirement of this depends on semantics >> >> MPolynomialRing_libsingular(): >> __new__: >> ... >> the_ring_ptr = ... >> __del__: >> if (refcnt(self) <= 0) ## how to do this in python? check if >> == 1? or do not use python reference counter? >> free(the_ring_ptr) >> >> This should be easy for python internal experts to >> implement (I can try to experiment with that, but I do >> not know much of python and only do mark&sweep :-) >> > Quoting Volker: > Just to clarify, right now Cython extension classes do not call the Python > destructor __del__ upon finalization, so Sage can't rely on this mechanism. > I'm > not quite sure if it is an intentional thing or if the Cython devs just > haven't gotten around to implementing it. I started doing some experiments mostly for the sake of testing :-) But my python/cython kung-fu is too weak, as well as general knowledge of the sage "object model" and my experiments ended in the same backtrace, so I did not work on the correct point or something, and for now I give up. > So we need cython to catch up with that one. Cython probably will also not understand the context of memory being allocated and released outside its control. The proper approach should be to ensure that python does not see reachable sage objects as a looping cycle with 0 references, and then "breaks" the cycle in unpredictable ways. In my basic understanding of sage classes, it should release things somewhat like: >>> del a ===> list = while length(list): foreach item in list: if item._parent == item: item._parent = None test = map(list, _._parent == item) if length(test) == 0: item.__dealloc__() remove(list, item) > Francois Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] sage and python 2.7: migration strategies?
Em 1 de junho de 2011 18:22, Paulo César Pereira de Andrade escreveu: > If I understand it correctly, at least for this particular case: > > sage/libs/singular/groebner_strategy.pyx:GroebnerStrategy(SageObject)._parent > => > sage/rings/polynomial/multi_polynomial_libsingular.pyx:MPolynomialRing_libsingular(MPolynomialRing_generic) > > and the _parent field has a __dealloc__ as: > singular_ring_delete(self._ring) while the GroebnerStrategy > __dealloc__ deferences _parent._ring. > > So, again if I understand correctly, the crash is happening because > MPolynomialRing_libsingular:__deallocate__ should be called > after pyx:GroebnerStrategy:__deallocate__, but in python 2.7 > this is not happening, as the order is not guaranteed, and > apparently just happens to be in the correct order with > python 2.6. Sorry for replying to myself, but actually, it should be quite simple to have it functional, just that it must be done in a case by case approach. Something like: GroebnerStrategy(): __new__: ... the_ring_handle = ... incref(the_ring_handle) __del__: ... decref(the_ring_handle) del the_ring_handle ## requirement of this depends on semantics MPolynomialRing_libsingular(): __new__: ... the_ring_ptr = ... __del__: if (refcnt(self) <= 0) ## how to do this in python? check if == 1? or do not use python reference counter? free(the_ring_ptr) This should be easy for python internal experts to implement (I can try to experiment with that, but I do not know much of python and only do mark&sweep :-) Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] sage and python 2.7: migration strategies?
2011/6/1 Francois Bissey : >> 2011/4/9 Francois Bissey : >> > It turns out that warnings are not visible to the end users anymore. >> > This is according to the python documentation: >> > http://docs.python.org/library/warnings.html >> > Section 27.6.5 to be precise. >> > Actually more explicit in http://docs.python.org/using/cmdline.html : >> > Starting from Python 2.7, DeprecationWarning and its descendants are >> > ignored by default. The -Wd option can be used to re-enable them. >> > >> > Passing -Wd to python I get to see the warnings again but to see the >> > warnings >> > globally we'll need to add: >> > PYTHONWARNINGS=default >> > to sage-env this is I hope harmless for 2.6 but useful for 2.7. >> >> I am just ignoring doctest failures due to it expecting a warning >> but no warning generated. >> > Hi Paulo, > > we have move a bit from this hack now: > http://trac.sagemath.org/sage_trac/ticket/11244 > >> But I am almost ashamed of myself by adding this to >> sage/all.py: >> >> import gc >> gc.set_debug(gc.DEBUG_SAVEALL) >> >> I still need to run a full sage -testall with that to see if >> there are any remaining crashes. Last one I was debugging >> was rooted in >> sage/libs/singular/groebner_strategy.pyx:GroebnerStrategy:__dealloc__ >> where the call id_Delete(&self._strat.Shdl, self._parent._ring) >> would pass "garbage" to the related singular function. >> >> Maybe for the people more familiar with sage internals >> it would be easier to figure out why python thinks that >> memory is unreachable, and it can garbage collect it. >> >> Disabling gc has a very bad side effect, e.g. I am >> testing a sage rebuild, and sphynx is already using >> almost 3Gb of memory while generating documentation. I needed to revert that change, because a computer with 4GB or ram would not be able to rebuild sage from source; could patch after rebuilding documentation, but would just leave the problem for the user... > Martin (our "chief sage-on-gentoo" debugger of glibc fame) has > tracked down that one to cython: > https://github.com/cschwan/sage-on-gentoo/issues/51#issuecomment-1181259 > and we now have a trac ticket for it: > http://trac.sagemath.org/sage_trac/ticket/11339 > so far it is not encouraging. > > I consider this particular issue to be a "canary in a coal mine" case. > It is revealed by the upgrade to python-2.7 but it is just waiting to > bite people on 2.6, in fact there are indication in the code that > similar issues have been worked around band aid style in the code > before. If I understand it correctly, at least for this particular case: sage/libs/singular/groebner_strategy.pyx:GroebnerStrategy(SageObject)._parent => sage/rings/polynomial/multi_polynomial_libsingular.pyx:MPolynomialRing_libsingular(MPolynomialRing_generic) and the _parent field has a __dealloc__ as: singular_ring_delete(self._ring) while the GroebnerStrategy __dealloc__ deferences _parent._ring. So, again if I understand correctly, the crash is happening because MPolynomialRing_libsingular:__deallocate__ should be called after pyx:GroebnerStrategy:__deallocate__, but in python 2.7 this is not happening, as the order is not guaranteed, and apparently just happens to be in the correct order with python 2.6. Maybe python's Modules/gcmodule.c is the one at fault here then? I mean, it should not just release a list of objects, but should make some kind of topological sort before releasing objects? But that probably would still find cycles in other cases, so, it would more likely need to have an api to, and use it to construct some list of pointers to be released, but that assuming stuff is allocated with malloc... Damn, this indeed does not look much encouraging :-) > Francois Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] sage and python 2.7: migration strategies?
2011/4/9 Francois Bissey : > It turns out that warnings are not visible to the end users anymore. > This is according to the python documentation: > http://docs.python.org/library/warnings.html > Section 27.6.5 to be precise. > Actually more explicit in http://docs.python.org/using/cmdline.html : > Starting from Python 2.7, DeprecationWarning and its descendants are ignored > by default. The -Wd option can be used to re-enable them. > > Passing -Wd to python I get to see the warnings again but to see the > warnings > globally we'll need to add: > PYTHONWARNINGS=default > to sage-env this is I hope harmless for 2.6 but useful for 2.7. I am just ignoring doctest failures due to it expecting a warning but no warning generated. But I am almost ashamed of myself by adding this to sage/all.py: import gc gc.set_debug(gc.DEBUG_SAVEALL) I still need to run a full sage -testall with that to see if there are any remaining crashes. Last one I was debugging was rooted in sage/libs/singular/groebner_strategy.pyx:GroebnerStrategy:__dealloc__ where the call id_Delete(&self._strat.Shdl, self._parent._ring) would pass "garbage" to the related singular function. Maybe for the people more familiar with sage internals it would be easier to figure out why python thinks that memory is unreachable, and it can garbage collect it. Disabling gc has a very bad side effect, e.g. I am testing a sage rebuild, and sphynx is already using almost 3Gb of memory while generating documentation. > Francois Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: http://flask.sagenb.org -- test it!!!
Em 5 de abril de 2011 21:02, Paulo César Pereira de Andrade escreveu: > 2011/4/5 William Stein : >> On Tue, Mar 29, 2011 at 9:21 PM, Rado wrote: >>> Great job Jason and Mike. Seems the Jmol problem is fixed. At least it >>> works here on ubuntu and firefox 3.6 and chromium 10 with sun's java. >>> >>> I pulled Jason's changes into my repo, so every one who pulled from me >>> can do just hg pull; hg up. Finally, there needs to be one line change >>> done in the sage library as given by Jason in >>> http://trac.sagemath.org/sage_trac/ticket/11078. >>> After sage -br you should have Jmol working. >> >> I have updated http://flask.sagenb.org and now 3d works, and I've also >> not seen the tinymce problem anymore. Great work guys! Are there any >> remaining known bugs? > > It still does not work for me, console log: > -%<- > java version "1.6.0_20" > OpenJDK Runtime Environment (IcedTea6 1.9.7) (mandriva-16.b20-x86_64) > OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode) > Exception in thread "Thread-6" java.lang.NullPointerException > at sun.applet.AppletPanel.showAppletStatus(AppletPanel.java:947) > at sun.applet.AppletPanel.run(AppletPanel.java:607) > at java.lang.Thread.run(Thread.java:636) > Jmol applet jmolApplet0__446104758884758__ initializing > AppletRegistry.checkIn(jmolApplet0__446104758884758__) > urlImage=jar:file:/home/pcpa/.icedteaplugin/cache/http/flask.sagenb.org/java/jmol/JmolApplet0.jar!/jmol75x29x8.gif > applet context: -applet > appletDocumentBase=http://flask.sagenb.org/doc/live/tutorial/ > appletCodeBase=http://flask.sagenb.org/java/jmol/ > (C) 2008 Jmol Development > Jmol Version 11.6.16 2008-11-24 13:39 > java.vendor:Sun Microsystems Inc. > java.version:1.6.0_20 > os.name:Linux > memory:78.8/124.3 > useCommandThread: false > appletId:jmolApplet0__446104758884758__ > FileManager opening http://flask.sagenb.org/java/jmol/appletweb/SageMenu.mnu > defaults = "Jmol" > backgroundColor = "black" > language=pt_BR > FileManager opening > http://flask.sagenb.org/home/_sage_/109/cells/14/sage0-size500.jmol?1302047733 > FileManager opening > http://flask.sagenb.org/home/_sage_/109/cells/14/cells/14/sage0-size500-75953492.jmol.zip > ERRO no "script": io error reading > http://flask.sagenb.org/home/_sage_/109/cells/14/cells/14/sage0-size500-75953492.jmol.zip|SCRIPT: > java.io.FileNotFoundException: > http://flask.sagenb.org/home/_sage_/109/cells/14/cells/14/sage0-size500-75953492.jmol.zip > eval ERROR: > line 2 command 2 of file > /home/_sage_/109/cells/14/sage0-size500.jmol?1302047733: > script >> "SCRIPT" << > line 1 command 1: > script >> "/home/_sage_/109/cells/14/sage0-size500.jmol?1302047733" << > -%<- I just updated Mandriva cooker to icedtea 1.10.1, icedtea-web 1.0.2, and openjdk b22, but still no luck with flask.sagenb.org: -%<- java version "1.6.0_22" OpenJDK Runtime Environment (IcedTea6 1.10.1) (mandriva-16.b22-x86_64) OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) urlImage=jar:file:/home/pcpa/.icedtea/cache/http/flask.sagenb.org/java/jmol/JmolApplet0.jar!/jmol75x29x8.gif Jmol applet jmolApplet0__63530260508382__ initializing AppletRegistry.checkIn(jmolApplet0__63530260508382__) applet context: -applet appletDocumentBase=http://flask.sagenb.org/doc/live/tutorial/ appletCodeBase=http://flask.sagenb.org/java/jmol/ (C) 2008 Jmol Development Jmol Version 11.6.16 2008-11-24 13:39 java.vendor:Sun Microsystems Inc. java.version:1.6.0_22 os.name:Linux memory:15.1/61.7 useCommandThread: false appletId:jmolApplet0__63530260508382__ FileManager opening http://flask.sagenb.org/java/jmol/appletweb/SageMenu.mnu document not found! defaults = "Jmol" backgroundColor = "black" language=pt_BR FileManager opening http://flask.sagenb.org/home/_sage_/242/cells/14/sage0-size500.jmol?1306291255 FileManager opening http://flask.sagenb.org/home/_sage_/242/cells/14/cells/14/sage0-size500-897772765.jmol.zip ERRO no "script": io error reading http://flask.sagenb.org/home/_sage_/242/cells/14/cells/14/sage0-size500-897772765.jmol.zip|SCRIPT: java.io.FileNotFoundException: http://flask.sagenb.org/home/_sage_/242/cells/14/cells/14/sage0-size500-897772765.jmol.zip eval ERROR: line 2 command 2 of file /home/_sage_/242/cells/14/sage0-size500.jmol?1306291255: script >> "SCRIPT" << line 1 command 1: script >> "/home/_sage_/242/cells/14/sage0-size500.jmol?1306291255" << -%<- Thanks, Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] gcc 4.6.0 issues
2011/4/11 Dr. David Kirkby : > The latest stable release of gcc is 4.6.0. Does anyone know of any problems > building Sage apart from these 4 I am aware of. > > 1) Singular fails to build > http://trac.sagemath.org/sage_trac/ticket/11084 It is working for me in Mandriva, but in Mandriva it should be building with -O2 (using mostly default rpm build options), so, -O3 may be showing some compiler problem. > 2) Lcalc fails to build > http://trac.sagemath.org/sage_trac/ticket/10892 > (merged in sage-4.7.alpha4 ) I just if 0'ed all lcalc_to_double functions and defined a macro that casts the argument to double... > 3) PolyBoRi fails to build on Solaris > http://trac.sagemath.org/sage_trac/ticket/11083 > (merged in sage-4.7.alpha4 ) Compiles cleanly on Mandriva. > 4) Rubiks failing a doctest on Solaris > http://trac.sagemath.org/sage_trac/ticket/11168 > (needs review). doctest works, but, for testing purposes I am using, sage 4.6.2, singular and polybori rebuilt with gcc 4.6.0, and lcalc with minor patch and rebuilt with gcc 4.6.0. Most other packages were not yet rebuilt with newer gcc. > On what systems have people checked Sage with gcc 4.6.0? > > I doubt anyone will escape the first two of these bugs if using gcc 4.6.0. > The third is definitely going to be specific to Solaris. The fourth might > show up on other platforms, though I've only seen it with OpenSolaris. > > Has anyone tried gcc 4.6.0 on OS X?? Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: http://flask.sagenb.org -- test it!!!
2011/4/5 William Stein : > On Tue, Mar 29, 2011 at 9:21 PM, Rado wrote: >> Great job Jason and Mike. Seems the Jmol problem is fixed. At least it >> works here on ubuntu and firefox 3.6 and chromium 10 with sun's java. >> >> I pulled Jason's changes into my repo, so every one who pulled from me >> can do just hg pull; hg up. Finally, there needs to be one line change >> done in the sage library as given by Jason in >> http://trac.sagemath.org/sage_trac/ticket/11078. >> After sage -br you should have Jmol working. > > I have updated http://flask.sagenb.org and now 3d works, and I've also > not seen the tinymce problem anymore. Great work guys! Are there any > remaining known bugs? It still does not work for me, console log: -%<- java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9.7) (mandriva-16.b20-x86_64) OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode) Exception in thread "Thread-6" java.lang.NullPointerException at sun.applet.AppletPanel.showAppletStatus(AppletPanel.java:947) at sun.applet.AppletPanel.run(AppletPanel.java:607) at java.lang.Thread.run(Thread.java:636) Jmol applet jmolApplet0__446104758884758__ initializing AppletRegistry.checkIn(jmolApplet0__446104758884758__) urlImage=jar:file:/home/pcpa/.icedteaplugin/cache/http/flask.sagenb.org/java/jmol/JmolApplet0.jar!/jmol75x29x8.gif applet context: -applet appletDocumentBase=http://flask.sagenb.org/doc/live/tutorial/ appletCodeBase=http://flask.sagenb.org/java/jmol/ (C) 2008 Jmol Development Jmol Version 11.6.16 2008-11-24 13:39 java.vendor:Sun Microsystems Inc. java.version:1.6.0_20 os.name:Linux memory:78.8/124.3 useCommandThread: false appletId:jmolApplet0__446104758884758__ FileManager opening http://flask.sagenb.org/java/jmol/appletweb/SageMenu.mnu defaults = "Jmol" backgroundColor = "black" language=pt_BR FileManager opening http://flask.sagenb.org/home/_sage_/109/cells/14/sage0-size500.jmol?1302047733 FileManager opening http://flask.sagenb.org/home/_sage_/109/cells/14/cells/14/sage0-size500-75953492.jmol.zip ERRO no "script": io error reading http://flask.sagenb.org/home/_sage_/109/cells/14/cells/14/sage0-size500-75953492.jmol.zip|SCRIPT: java.io.FileNotFoundException: http://flask.sagenb.org/home/_sage_/109/cells/14/cells/14/sage0-size500-75953492.jmol.zip eval ERROR: line 2 command 2 of file /home/_sage_/109/cells/14/sage0-size500.jmol?1302047733: script >> "SCRIPT" << line 1 command 1: script >> "/home/_sage_/109/cells/14/sage0-size500.jmol?1302047733" << -%<- I think this may be related to a patch I once had for sagemath, because I preferred to patch it to use make openjdk find files, and not java-sun... but a later update of openjdk made them agree again on paths. A newer openjdk was released recently, and I should update the mandriva openjdk package soon, and hopefully it will be corrected. > William > >> >> Rado >> >> On Mar 30, 8:41 am, Jason Grout wrote: >>> On 3/29/11 7:07 PM, Jason Grout wrote: >>> >>> > On 3/25/11 9:03 PM, William Stein wrote: >>> >> Hi, >>> >>> >> Please find bugs inhttp://flask.sagenb.org. Is it slow? Fast? >>> >> Broken in *any* way at all? >>> >>> > For some reason, I can't insert text cells. I insert a text cell and the >>> > page refreshes. My guess is that somehow the state numbers get out of >>> > sync and that forces a page refresh. >>> >>> I've committed a fix to my clone: >>> >>> https://code.google.com/r/jasongrout-sagenb/source/detail?r=7a13d03fd... >>> >>> We came, saw, and conquered this issue in January. I remember us fixing >>> it. Well, anyways, there's the fix. Can you look over it Rado and pull >>> my two changes to the official tree? >>> >>> Jason >> >> -- >> To post to this group, send an email to sage-devel@googlegroups.com >> To unsubscribe from this group, send an email to >> sage-devel+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/sage-devel >> URL: http://www.sagemath.org Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: http://flask.sagenb.org -- test it!!!
2011/3/26 Jonathan : > This problem with Jmol appears to be multifaceted. > 1) The path to Jmol looks strange, although the error messages do > appear to come from Jmol. > 2) It looks like something is being added to the top of the script > file for Jmol and confusing it. > 3) Could also related to the JavaVM you are using. Jmol is only > tested against the Sun/Oracle VM. I just tested with firefox also, to ensure it is not some chromium-browser issue, but got the same results. With some extra tests I could see the contents with this procedure: cut&paste from jvm debug output in browser, for example in my test http://flask.sagenb.org/home/_sage_/4/cells/14/sage0-size500.jmol?1301151907 then, look at the contents of sage0-size500.jmol and download http://flask.sagenb.org//home/_sage_/4/cells/14/sage0-size500-525945175.jmol.zip then, unzip sage0-size500-525945175.jmol.zip and run jmol -s SCRIPT I think it may be an authorization issue, because if using wget to fetch the first file, it downloads the top page with form for login and password. > *We are working on patches to Jmol in the present notebook. There are > still some asychronicity issues that I think I've almost got a handle > on. Let's not try to move this stuff to the new notebook until that > is solved. I hope today :) No problems :-) I just tested jmol because of comments, and it usually is what people want to see first, interactive 3d graphics :-) > Jonathan Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: http://flask.sagenb.org -- test it!!!
2011/3/25 Jason Grout :
> On 3/25/11 7:03 PM, William Stein wrote:
>>
>> Hi,
>>
>> Please find bugs in http://flask.sagenb.org. Is it slow? Fast?
>> Broken in *any* way at all?
>
>
> Jmol doesn't work, as far as we can tell. We aren't sure why, though. Kudos
> to whoever can figure out why jmol isn't working!
>
> It seems that the jmol applet loads, but it can't find the file containing
> the jmol instructions, for some reason. It may be that what we really
> should do is just port the new jmol patch up on trac to work on this new
> server.
In case it helps, I see this on console:
-%<-
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.7) (mandriva-16.b20-x86_64)
OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)
Exception in thread "Thread-6" java.lang.NullPointerException
at sun.applet.AppletPanel.showAppletStatus(AppletPanel.java:947)
at sun.applet.AppletPanel.run(AppletPanel.java:607)
at java.lang.Thread.run(Thread.java:636)
urlImage=jar:file:/home/pcpa/.icedteaplugin/cache/http/flask.sagenb.org/java/jmol/JmolApplet0.jar!/jmol75x29x8.gif
Jmol applet jmolApplet0__7259920705109835__ initializing
AppletRegistry.checkIn(jmolApplet0__7259920705109835__)
applet context: -applet
appletDocumentBase=http://flask.sagenb.org/doc/live/tutorial/
appletCodeBase=http://flask.sagenb.org/java/jmol/
(C) 2008 Jmol Development
Jmol Version 11.6.16 2008-11-24 13:39
java.vendor:Sun Microsystems Inc.
java.version:1.6.0_20
os.name:Linux
memory:33.7/91.0
useCommandThread: false
appletId:jmolApplet0__7259920705109835__
FileManager opening http://flask.sagenb.org/java/jmol/appletweb/SageMenu.mnu
defaults = "Jmol"
backgroundColor = "black"
language=pt_BR
FileManager opening
http://flask.sagenb.org/home/_sage_/1/cells/14/sage0-size500.jmol?1301150152
script compiler ERROR: esperado um comando
line 1 command 1 of /home/_sage_/1/cells/14/sage0-size500.jmol?1301150152:
ERRO no "script": script compiler ERROR: esperado um comando
line 1 command 1 of /home/_sage_/1/cells/14/sage0-size500.jmol?1301150152:
eval ERROR:
line 1 command 1:
script >> "/home/_sage_/1/cells/14/sage0-size500.jmol?1301150152" <<
-%<-
But testing on chromium-browser, firefox frequently is "more compatible".
I solved a similar issue of jmol not understanding the input in the mandriva
sagemath package, but for console use, by running "jmol -s", important
bits should be:
-%<-
--- sage-4.6.2/spkg/build/sage-4.6.2/sage/plot/plot3d/base.pyx.orig
2011-01-14
18:06:01.349974001 -0200
+++ sage-4.6.2/spkg/build/sage-4.6.2/sage/plot/plot3d/base.pyx 2011-01-14
18:07:03.463973996 -0200
@@ -817,12 +817,7 @@ end_scene""" % (render_params.antialiasi
return box_min, box_max
def _prepare_for_jmol(self, frame, axes, frame_aspect_ratio,
aspect_ratio, zoom):
-from sage.plot.plot import EMBEDDED_MODE
-if EMBEDDED_MODE:
-s = 6
-else:
-s = 3
-box_min, box_max =
self._rescale_for_frame_aspect_ratio_and_zoom(s, frame_aspect_ratio,
zoom)
+box_min, box_max =
self._rescale_for_frame_aspect_ratio_and_zoom(6, frame_aspect_ratio,
zoom)
a_min, a_max = self._box_for_aspect_ratio(aspect_ratio,
box_min, box_max)
return self._transform_to_bounding_box(box_min, box_max,
a_min, a_max, frame=frame,
axes=axes, thickness=1,
@@ -1110,7 +1105,7 @@ end_scene""" % (render_params.antialiasi
T = self._prepare_for_jmol(frame, axes,
frame_aspect_ratio, aspect_ratio, zoom)
T.export_jmol(archive_name, force_reload=EMBEDDED_MODE,
zoom=zoom*100, **kwds)
-viewer_app = "sage-native-execute " +
os.path.join(sage.misc.misc.SAGE_LOCAL, "bin/jmol")
+viewer_app = "jmol -s"
# We need a script to load the file
f = open(filename + '.jmol', 'w')
-%<-
While not exactly solving the issue, I hope this information may
help find the cause,
but the -s flag should only be required for newer jmol.
> And congrats to Mike, Rado, the many testers, and others who got this all
> working! It will be *much* easier to understand and modify the notebook
> code after we migrate to this.
>
> Thanks,
>
> Jason
Paulo
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] How to tell if a FLOSS project is doomed to FAIL
2011/3/9 Francois Bissey : >> This may be of interest >> >> >> https://www.theopensourceway.org/wiki/How_to_tell_if_a_FLOSS_project_is_doo >> med_to_FAIL >> >> and should explain why sage is not included and/or built from >> sources in any major distro. Well, I make rpms for Mandriva, >> and there is the gentoo port... >> > > My turn? :) :-) >> My last work on a sagemath 4.6.2 rpm ended with these >> main issues: >> >> o I am still preferring to use system python. But making >> sage build/work with python 2.7.1 has pitfalls as sage >> expects python 2.6 > > I don't have time to work on python-2.7.1 but yes I am expecting issues. > By the way folks 2.6.6 with pickling patch works for us. I am still doing an extra python (2.7.1) build during sage build, and then install the patched cPickle.so and pickle.py in $PYTHONPATH (/usr/share/sage/site-packages). >> o Cannot build with with cython 0.14, so the does a cython >> 0.13 build and puts it in the path first, and also installs >> a cython binary in $SAGE_LOCAL/bin and runtime at >> $PYTHONPATH > > The 4.6.2 I ship uses cython-0.14.1, then again I know why I wanted to > review the relevant ticket. I also use ecl-11.1.1/maxima-5.23.2 in advance > of sage-4.7 - I also was involved in the relevant tickets. Admitely it is a > lot of work. I also use mpmath-0.17 but I believe you do things differently > by using mpmath from sympy - or have you changed that? I preferred to have a build of cython 0.13 in $SAGE_LOCAL/bin and $PYTHONPATH because sage itself does build, but fails most doctests if using cython 0.14. This way, cython invoked from within sage or sage -sh will (should) use cython 0.13. Also using ecl-11.1.1 but right now maxima 5.23.0. I usually use maxima with other lisp backends, i.e. I test with clisp, gcl, ecl, and sbcl (never know which one is active :-) >> o Since sagemath 4.6.1, there are crashes at exit. I >> reworked a good share of dependencies, but it still >> fails. glibc/valgrind shows a double mpz_clear call >> when python exits, so, I now set MALLOC_CHECK_=1 >> so that it usually should just print a warning about >> double free, instead of aborting at exit. >> > > Didn't see that. But we have a horror story from glibc: > https://github.com/cschwan/sage-on-gentoo/issues#issue/40 > My presumption is that vanilla sage is protected from the problem > thanks to its antique python or some of its configuration options. Wow, very nice catch! I just opened a bug report for mandriva, requesting that patch on our glibc, as the test case also triggers the failure. Probably my sagemath package is not having the same symptom because I disabled tls support in pari, as that looked like a source of major problems when I updated to pari-2.4.3.alpha, but, the glibc/tls issue may be the cause of the problem I noticed on exit of some doctests. Using MALLOC_CHECK_=1 now I see something like: -%<- sage -t -force_lib "devel/sage/sage/homology/chain_complex.py" *** glibc detected *** python: free(): invalid pointer: 0x03ca3960 *** *** glibc detected *** python: free(): invalid pointer: 0x03ca1270 *** *** glibc detected *** python: free(): invalid pointer: 0x03e09c20 *** [3.7 s] -- All tests passed! Total time for all tests: 3.7 seconds -%<- instead of a crash and a doctest failure... >> BTW, I tried to be impartial, but still accounted sage at >> 280 points. >> > > As has been said before it depends of the objectives of the project. > Currently packager friendliness is not part of it. You, me, the > few other people working with me and possibly with you, are really > going beyond the call of duty. > > What would be nice: better recognition that we are doing some > hard work that may an impact on the quality of sage in the long term > much like portability work. At present time you can use a gentoo > prefix to build sage on other linuxes and OS X, windows is the next > frontier (but that require some kind of windows box, I may have > something in the near future). I have been considering for some time to work on some support, or at least better understanding gentoo prefix... Hope to get something like a rpm to setup anything needed in Mandriva at some point. > Francois > Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: How to tell if a FLOSS project is doomed to FAIL
2011/3/9 Harald Schilly : I understand that this kind of post, besides attempting to state it is a friendly one, could cause more harm than good. The TV show probably would have a small specialized audience :-) But the rants/discussions, and ego wars (not so much as in some other projects) that happens from time to time should be worth a watch. > exactly how did you come up with 280 points? Not "exact" values, as I just did a quick read and add to a sum, but, considering sage base code and mandatory spks, the biggest values I considered were: Building from source - with your own build tool for this code [ +100 points of FAIL ] (( spk-* shell scripts )) Bundling - Your source only comes with other code projects that it depends on [ +20 points of FAIL ] - If your source code cannot be built without first building the bundled code bits [ +10 points of FAIL ] - If you have modified those other bundled code bits [ +40 points of FAIL ] Libraries - Your source does not try to use system libraries if present [ +20 points of FAIL ] But I did not account: Releases - Your releases are only in an encapsulation format that you invented. [ +100 points of FAIL ] (( spkgs )) > quoting to box on top: > """There are obvious exceptions, such as the Linux kernel. Generally these > exceptions work because they started out small and the community and code > grew together. """ > Therefore I'm glad Sage started <17mb and grew slowly: > http://sagemath.org/src-old/ > > Besides that, your first two points are exactly the reasons why Sage needs > this kind of isolation because there is no way to adopt to all variations of > versions distributions are equipped with while still focusing on regular > releases and maintaining quality. Yes. That mainly because sage is not considered a core package. Still, the Mandriva rpm should be "good enough" as the crashes at exit happens only in around 3-5% of the doctests, and weirdly, if cut&pasting the test cases, and trying to bisect the problem, it goes away, so, it should be some issue when a very large amount of objects are allocated. With valgrind, unless using something like --free-fill=0x51, otherwise, it fills released memory with zero, and the double free problem "goes away". > H Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] How to tell if a FLOSS project is doomed to FAIL
This may be of interest https://www.theopensourceway.org/wiki/How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL and should explain why sage is not included and/or built from sources in any major distro. Well, I make rpms for Mandriva, and there is the gentoo port... My last work on a sagemath 4.6.2 rpm ended with these main issues: o I am still preferring to use system python. But making sage build/work with python 2.7.1 has pitfalls as sage expects python 2.6 o Cannot build with with cython 0.14, so the does a cython 0.13 build and puts it in the path first, and also installs a cython binary in $SAGE_LOCAL/bin and runtime at $PYTHONPATH o Since sagemath 4.6.1, there are crashes at exit. I reworked a good share of dependencies, but it still fails. glibc/valgrind shows a double mpz_clear call when python exits, so, I now set MALLOC_CHECK_=1 so that it usually should just print a warning about double free, instead of aborting at exit. BTW, I tried to be impartial, but still accounted sage at 280 points. Friendly, Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] toying with various upgrades (numpy,ecl,maxima,gfan,mpfi)
2011/1/27 François Bissey : > Hi all, I am delaying a Mandriva sagemath 4.6.1 due to related reasons, and may not release it if sagemath 4.6.2 is released soon :-). Since Mandriva cooker is using python 2.7.1 and cython 0.14, I needed to use a custom cython 0.13, but am trying to correct some issues with python, to use python 2.7.1. Just adding unittest.py from python2.6 to PYTHONPATH, that points to /usr/share/sage/site-packages corrected like 90% of the problems, but just now I got this one in sage/rings/polynomial/polynomial_quotient_ring_element.py [[ cut&paste of test case in sage under a python in gdb slightly different than sage -gdb, but effectively the same ]] -%<- sage: R. = PolynomialRing(QQ) sage: sage: S. = R.quotient(x^3-2) sage: sage: int(S(10)) 10 sage: int(a) Fatal Python error: GC object already tracked Program received signal SIGABRT, Aborted. [...] 0x774c4075 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x774c4075 in raise () from /lib64/libc.so.6 #1 0x774c5806 in abort () from /lib64/libc.so.6 #2 0x77b1c9de in Py_FatalError (msg=) at Python/pythonrun.c:1670 #3 0x77a8c76e in PyFrame_New (tstate=0x6020a0, code=, globals=0x998f50, locals=) at Objects/frameobject.c:742 #4 0x77b00d67 in PyEval_EvalCodeEx (co=0x95f5b0, globals=, locals=, args= 0x2265e08, argcount=4, kws=0x2265e28, kwcount=0, defs=0x814d28, defcount= 5, closure=0x0) at Python/ceval.c:3032 #5 0x77aff835 in fast_function (f=, throwflag=) at Python/ceval.c:4108 #6 call_function (f=, throwflag=) at Python/ceval.c:4033 [...] > so it's that time again where I look at how "easy" it would be to update > various pieces of sage to the latest upstream. The tests were performed > on a linux machine running in 64 bit (amd64) based on 4.6.2.alpha2. > > numpy-1.5.1: upgrade quite nicely, just two doctests broken by a new warning > from numpy: > sage -t -force_lib "devel/sage/sage/calculus/interpolators.pyx" > ** > File > "/home/gnuke/gentoo/usr/share/sage/devel/sage/sage/calculus/interpolators.pyx", > line 52: > sage: m = Riemann_Map([lambda x: ps.value(x)], [lambda x: > ps.derivative(x)],0) > Expected nothing > Got: > doctest:1: ComplexWarning: Casting complex values to real discards the > imaginary part > ** I see these too, but like this: sage -t -force_lib "/usr/lib64/python2.7/site-packages/sage/calculus/interpolators.pyx" [?1034hWarning: invalid value encountered in divide Warning: invalid value encountered in divide << last line repeats at least more 300 times >> ** File "/usr/lib64/python2.7/site-packages/sage/calculus/interpolators.pyx", line 52: sage: m = Riemann_Map([lambda x: ps.value(x)], [lambda x: ps.derivative(x)],0) Expected nothing Got: doctest:1: ComplexWarning: Casting complex values to real discards the imaginary part > File > "/home/gnuke/gentoo/usr/share/sage/devel/sage/sage/calculus/interpolators.pyx", > line 183: > sage: m = Riemann_Map([lambda x: cs.value(x)], [lambda x: > cs.derivative(x)], 0) > Expected nothing > Got: > doctest:1: ComplexWarning: Casting complex values to real discards the > imaginary part > ** > > Harmless and easy to correct. > > ecl-11.1.1/maxima-5.23.2 > Lots of numerical noise and a bit of formatting. Mostly due to ecl as > downgrading maxima to 5.22.1 but keeping ecl-11.1.1 doesn't change the results > of the tests. 6 files are affected in total. > > gfan-0.5: that's very bad. I have "gfan-0.4plus" packaged, so, do not see this one... > sage -t "devel/sage-main/sage/rings/polynomial/groebner_fan.py" > [?1034h** > File "/usr/share/sage/devel/sage-main/sage/rings/polynomial/groebner_fan.py", > line 44: > sage: g.reduced_groebner_bases() > Exception raised: > Traceback (most recent call last): > File "/usr/bin/ncadoctest.py", line 1231, in run_one_test > self.run_one_example(test, example, filename, compileflags) > File "/usr/bin/sagedoctest.py", line 38, in run_one_example > OrigDocTestRunner.run_one_example(self, test, example, filename, > compileflags) > File "/usr/bin/ncadoctest.py", line 1172, in run_one_example > compileflags, 1) in test.globs > File "", line 1, in > g.reduced_groebner_bases()###line 44: > sage: g.reduced_groebner_bases() > File "/usr/lib64/python2.6/site- > packages/sage/rings/polynomial/groebner_fan.py", line 696, in > reduced_groebner_bases > G = self._gfan_reduced_groebner_bases() > File "/usr/lib64/python2.6/site- > packages/sage/rings/polynomial/groebner_fan.py", line 647, in > _gfan_reduce
[sage-devel] Re: Sagemath 4.6.1 rpm problem in Mandriva
Em 19 de janeiro de 2011 14:57, Paulo César Pereira de Andrade escreveu: > Em 18 de janeiro de 2011 14:55, Paulo César Pereira de Andrade > escreveu: >> Hi, >> >> I made a patch that allowed it to generate documentation and build, but >> it just gives the same errors when attempting to execute sage. For example: >> >> -%<- >> $ sage >> -- >> | Sage Version 4.6.1, Release Date: 2011-01-11 | >> | Type notebook() for the GUI, and license() for information. | >> -- >> --- >> AttributeError Traceback (most recent call last) > [...] >> AttributeError: 'module' object has no attribute 'is_extension_type' > >> Any ideas of what may be wrong? Sorry for the noise. Previously I had not properly tested with cython-0.13, and after some time testing some patches to python itself, I gone back to check cython... and it is building with cython-0.14 that is causing issues. Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Sagemath 4.6.1 rpm problem in Mandriva
Em 18 de janeiro de 2011 14:55, Paulo César Pereira de Andrade escreveu: > Hi, > > I made a patch that allowed it to generate documentation and build, but > it just gives the same errors when attempting to execute sage. For example: > > -%<- > $ sage > -- > | Sage Version 4.6.1, Release Date: 2011-01-11 | > | Type notebook() for the GUI, and license() for information. | > -- > --- > AttributeError Traceback (most recent call last) [...] > AttributeError: 'module' object has no attribute 'is_extension_type' > Any ideas of what may be wrong? I know what causes the problem now. Rebuilding sagemath 4.6 with Python 2.7.1 will cause the same problem. I was hoping that the extra python build (for the cPickle.so patch) I added to the sagemath package would be corrected when updating the tarball to 2.7.1, but it did not... Build fails in documentation, but if patching it, will fail at runtime. Failure in log is: -%<- + python common/builder.py all html sphinx-build -b html -d /home/pcpa/rpm/BUILD/sage-4.6.1/spkg/build/sage-4.6.1/doc/output/doctrees/en/constructions /home/pcpa/rpm/BUILD/sage-4.6.1/spkg/build/sage-4.6.1/doc/en/constructions /home/pcpa/rpm/BUILD/sage-4.6.1/spkg/build/sage-4.6.1/doc/output/html/en/constructions Running Sphinx v1.0.5 Exception occurred: File "element.pyx", line 190, in init sage.structure.element (sage/structure/element.c:26366) AttributeError: 'module' object has no attribute 'is_extension_type' The full traceback has been saved in /tmp/sphinx-err-RP4XgC.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. Either send bugs to the mailing list at <http://groups.google.com/group/sphinx-dev/>, or report them in the tracker at <http://bitbucket.org/birkenfeld/sphinx/issues/>. Thanks! Setting permissions of DOT_SAGE directory so only you can read and write it. Build finished. The built documents can be found in /home/pcpa/rpm/BUILD/sage-4.6.1/spkg/build/sage-4.6.1/doc/output/html/en/constructions Traceback (most recent call last): File "common/builder.py", line 1076, in getattr(get_builder(name), type)() File "common/builder.py", line 260, in _wrapper getattr(get_builder(document), name)(*args, **kwds) File "common/builder.py", line 371, in _wrapper self.write_auto_rest_file(module_name) File "common/builder.py", line 610, in write_auto_rest_file title = self.get_module_docstring_title(module_name) File "common/builder.py", line 580, in get_module_docstring_title import sage.all File "/home/pcpa/rpm/BUILDROOT/sagemath-4.6.1-1mdv2011.0.x86_64/usr/lib64/python2.7/site-packages/sage/all.py", line 64, in from sage.misc.all import * # takes a while File "/home/pcpa/rpm/BUILDROOT/sagemath-4.6.1-1mdv2011.0.x86_64/usr/lib64/python2.7/site-packages/sage/misc/all.py", line 78, in from functional import (additive_order, File "/home/pcpa/rpm/BUILDROOT/sagemath-4.6.1-1mdv2011.0.x86_64/usr/lib64/python2.7/site-packages/sage/misc/functional.py", line 34, in import sage.interfaces.expect File "/home/pcpa/rpm/BUILDROOT/sagemath-4.6.1-1mdv2011.0.x86_64/usr/lib64/python2.7/site-packages/sage/interfaces/expect.py", line 56, in from sage.structure.parent_base import ParentWithBase File "parent_base.pyx", line 1, in init sage.structure.parent_base (sage/structure/parent_base.c:1945) File "parent_old.pyx", line 1, in init sage.structure.parent_old (sage/structure/parent_old.c:7067) File "element.pxd", line 12, in init sage.structure.parent (sage/structure/parent.c:19852) File "element.pyx", line 190, in init sage.structure.element (sage/structure/element.c:26366) AttributeError: 'module' object has no attribute 'is_extension_type' -%<- Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Sagemath 4.6.1 rpm problem in Mandriva
Hi, I made a patch that allowed it to generate documentation and build, but it just gives the same errors when attempting to execute sage. For example: -%<- $ sage -- | Sage Version 4.6.1, Release Date: 2011-01-11 | | Type notebook() for the GUI, and license() for information.| -- --- AttributeErrorTraceback (most recent call last) /usr/lib/python2.7/site-packages/IPython/ipmaker.pyc in force_import(modname, force_reload) 61 reload(sys.modules[modname]) 62 else: ---> 63 __import__(modname) 64 65 /usr/share/sage/local/bin/ipy_profile_sage.py in () 5 preparser(True) 6 > 7 import sage.all_cmdline 8 sage.all_cmdline._init_cmdline(globals()) 9 /usr/lib64/python2.7/site-packages/sage/all_cmdline.py in () 12 try: 13 ---> 14 from sage.all import * 15 from sage.calculus.predefined import x 16 preparser(on=True) /usr/lib64/python2.7/site-packages/sage/all.py in () 62 get_sigs() 63 ---> 64 from sage.misc.all import * # takes a while 65 66 from sage.misc.sh import sh /usr/lib64/python2.7/site-packages/sage/misc/all.py in () 76 from func_persist import func_persist 77 ---> 78 from functional import (additive_order, 79 sqrt as numerical_sqrt, 80 arg, /usr/lib64/python2.7/site-packages/sage/misc/functional.py in () 32 import sage.misc.latex 33 import sage.server.support ---> 34 import sage.interfaces.expect 35 import sage.interfaces.mathematica 36 /usr/lib64/python2.7/site-packages/sage/interfaces/expect.py in () 54 55 from sage.structure.sage_object import SageObject ---> 56 from sage.structure.parent_base import ParentWithBase 57 import sage.structure.element 58 /usr/share/sage/local/bin/parent_base.pyx in init sage.structure.parent_base (sage/structure/parent_base.c:1945)() > 1 2 3 4 5 /usr/share/sage/local/bin/parent_old.pyx in init sage.structure.parent_old (sage/structure/parent_old.c:7067)() > 1 2 3 4 5 /usr/share/sage/local/bin/element.pxd in init sage.structure.parent (sage/structure/parent.c:19863)() 10 11 ---> 12 13 14 /usr/share/sage/local/bin/element.pyx in init sage.structure.element (sage/structure/element.c:26377)() 188 189 --> 190 191 192 AttributeError: 'module' object has no attribute 'is_extension_type' Error importing ipy_profile_sage - perhaps you should run %upgrade? WARNING: Loading of ipy_profile_sage failed. sage: 1+1 --- NameError Traceback (most recent call last) /usr/share/sage/local/bin/ in () NameError: name 'Integer' is not defined sage: -%<- sage 4.6 works correctly, and I also tried a build with cython 0.13 instead of 0.14, but same result. Any ideas of what may be wrong? Thanks, Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: jmol and implicit_plot3d in notebook and command line
Em 23 de novembro de 2010 16:21, Paulo César Pereira de Andrade escreveu: > Hi, Doing the bad netiquette of replying to myself, but now I am sure this is not specific to my sagemath package. > Sorry if this was already asked/answered as I did not read all threads > about sagemath > and jmol. This is related to mandriva sagemath package, but, > downloading the binary for > mandriva 2009.0 I get the same results. > > I have this strange behavior, where in both notebook and tutorial > sample, it appears > to work correctly, e.g: > > http://img269.imageshack.us/img269/7279/notebookandtutorial.png I am almost 100% certain that the issue is: -> sage-4.6/sage/plot/plot3d/base.pyx:819 <- def _prepare_for_jmol(self, frame, axes, frame_aspect_ratio, aspect_ratio, zoom): from sage.plot.plot import EMBEDDED_MODE if EMBEDDED_MODE: s = 6 else: s = 3 box_min, box_max = self._rescale_for_frame_aspect_ratio_and_zoom(s, frame_aspect_ratio, zoom) because by copying the files generated for the notebook and running jmol on command line it shows what looks like a sphere :-), also, playing with zoom and aspect_ratio/frame_aspect_ratio almost gets there, but not sure how to properly adjust the origin in that case, or start with "unzoomed" image. Also, the only difference from the files generated for the notebook and for the "command line" is that coordinates for the notebook ones are twice bigger than for command line. > but then, just ^C and run on command line: > > http://img843.imageshack.us/img843/2830/xtermwindow.png > > and the result is: > > http://img831.imageshack.us/img831/3907/jmolwindow.png > > Same results with openjdk and java-sun (in these screenshots using openjdk). > > I have packaged jmol 12.0.22, and noticed that I need to pass the "-s" > or "--script" option > to jmol or it will not understand it is a script :-) Maybe there is > something in the notebook > code, or javascript that corrects the issue. I believe it may be > related to jmol having > deprecated the "pmesh" command in favor of the "isosurface" command, but I > don't > think I can figure out a simple patch for the sage3d code. > > [talking about sage3d, I did not yet add it to the sagemath mandriva > package, so, > only jmol and tachyon can be used to view 3d plots for now] I think I could "hack" the package to always act as if EMBEDDED_MODE was set, but that would only hide the problem... Thanks, Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] jmol and implicit_plot3d in notebook and command line
Hi, Sorry if this was already asked/answered as I did not read all threads about sagemath and jmol. This is related to mandriva sagemath package, but, downloading the binary for mandriva 2009.0 I get the same results. I have this strange behavior, where in both notebook and tutorial sample, it appears to work correctly, e.g: http://img269.imageshack.us/img269/7279/notebookandtutorial.png but then, just ^C and run on command line: http://img843.imageshack.us/img843/2830/xtermwindow.png and the result is: http://img831.imageshack.us/img831/3907/jmolwindow.png Same results with openjdk and java-sun (in these screenshots using openjdk). I have packaged jmol 12.0.22, and noticed that I need to pass the "-s" or "--script" option to jmol or it will not understand it is a script :-) Maybe there is something in the notebook code, or javascript that corrects the issue. I believe it may be related to jmol having deprecated the "pmesh" command in favor of the "isosurface" command, but I don't think I can figure out a simple patch for the sage3d code. [talking about sage3d, I did not yet add it to the sagemath mandriva package, so, only jmol and tachyon can be used to view 3d plots for now] Thanks, Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: How to profile I/O?
2010/11/13 Simon King : > Hi Dave! > > On 12 Nov., 16:22, "Dr. David Kirkby" wrote: >> On 11/12/10 03:10 PM, Dr. David Kirkby wrote: >> >> I meant to say Sage is NOT the place to >> >> look. vmstat, sar (possibly top) are worth looking at. > > top would not help. It simply says that my process is sometimes only > taking 30% CPU time, but it gives no indication *why*. Note that it is > only a guess that I/O are to blame. > > Moreover, a system tool would not tell me in what part of my programs > the problem is located. "prun" might give some hint. However, since my > programs use external programs as well as compiled components and > interfaces, I was hoping for a tool that tracks all I/O processes > occuring during my computation. > > Perhaps there is a system tool for that purpose. I think it would help > me if some tool would produce a list of all file names to which I/O > happened, and record the I/O time for each file. Probably the best tool on linux should be perf, e.g: $ perf record -f /bin/sh -c "complex command line" $ perf report -f to overwrite previous recording and "/bin/sh -c" if needs pipes, etc better to do it on an idle system as it reports time kernel and in other processes. Example in my computer (while doing a system update) $ perf record -f sage -- | Sage Version 4.6, Release Date: 2010-10-30 | | Type notebook() for the GUI, and license() for information.| -- sage: Exiting Sage (CPU time 0m0.08s, Wall time 0m7.88s). [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 0.451 MB perf.data (~19711 samples) ] $ perf report|less # Samples: 14408076653 # # Overhead Command Shared Object Symbol # .. .. # 13.46%python libpython2.7.so.1.0 [.] PyParser_AddToken 11.32%python libpython2.7.so.1.0 [.] 0x027ca8 7.84%python libpython2.7.so.1.0 [.] 0x0643bd 5.46%python libpython2.7.so.1.0 [.] 0x0ca601 3.79%python libpython2.7.so.1.0 [.] 0x0725fb 2.63%python libpython2.7.so.1.0 [.] PyEval_EvalFrameEx 2.26%python libpython2.7.so.1.0 [.] PyTokenizer_Get 2.25%python libpython2.7.so.1.0 [.] 0x0dc72c 2.16%python libpython2.7.so.1.0 [.] PyObject_Malloc 2.15%python libpython2.7.so.1.0 [.] PyObject_Free 2.08%python libpython2.7.so.1.0 [.] PyNode_AddChild [...] > Best regards, > Simon Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: what if SAGE_ROOT/local != SAGE_LOCAL ?
2010/8/5 cschwan : Hi, > There are six python files which would need a patch and more than five > (we need only small numbers of scripts from sage_scripts). You may > have look and the patches here: I agree that a s|SAGE_ROOT/foo|SAGE_FOO| is required, that is, not only for SAGE_LOCAL :-) The solution I used in the Mandriva package was to make symlinks, example on a i686 computer with sage 4.4: $ ls -l /usr/share/sage/local total 4 drwxr-xr-x 2 root root 4096 2010-05-08 03:00 bin/ lrwxrwxrwx 1 root root 23 2010-05-08 03:00 include -> ../../../../usr/include/ lrwxrwxrwx 1 root root 19 2010-05-08 03:00 lib -> ../../../../usr/lib/ lrwxrwxrwx 1 root root 21 2010-05-08 03:00 share -> ../../../../usr/share/ also, in x86_64, the lib symlink is actually pointing to /usr/lib64 I agree this is not optimal, but was a way to keep patches more manageable by needing minimal path related patches. The other symlinks are: $ ls -l /usr/share/sage/devel/sage lrwxrwxrwx 1 root root 43 2010-05-08 03:00 /usr/share/sage/devel/sage -> ../../../../usr/lib/python2.6/site-packages/ $ ls -l /usr/share/sage/doc lrwxrwxrwx 1 root root 33 2010-05-08 03:00 /usr/share/sage/doc -> ../../../usr/share/sage/devel/doc/ Also, I prefer to avoid putting too much stuff in /usr/bin in my "specialized" packages, but set $PATH in the /usr/bin/sage script, as well as some other environment variables. There is only one sage package file in /usr/bin: $ rpm -ql sagemath | grep /usr/bin /usr/bin/sage but still... $ ls /usr/bin | wc -l 3517 > - > http://www.students.uni-mainz.de/cschwan/sage-baselayout-4.5.1-fix-SAGE_LOCAL.patch > - > http://www.students.uni-mainz.de/cschwan/sage-baselayout-4.5.1-fix-SAGE_LOCAL.patch Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] About mpmath and sympy
2010/7/17 François Bissey : >> As an aside, if two upstream packages include another upstream >> package (e.g. both include GMP) what does Sage do? Are there >> two copies of GMP? They could have different versions of the >> same package since project 1 could have stopped at one version >> and project 2 could have stopped at another. Sage could be >> using a third. > > Funny you mentioned GMP. At one point givaro was shipping its own > GMP. It was actually an accident on the givaro devs part - and I had > notified them. But I didn't notify this list. So in at least one release > givaro was actually overwriting part of GMP. I think there may be still duplicates somewhere, not just GMP, but probably don't affect sage because either sage doesn't build it by default, e.g. gap optional modules, or sage talks to it using the pexpect interface. > For your question I guess it depends if it is kept internally without > clash with anything else or it actively tries to overwrite things that > have been installed already. > The second one is a no-no, and the first one should be fixed to use upstream > but not as a matter of emergency I would guess. If it is linked statically, and provides only an opaque interface, usually it should just work, but that may depend on how the duplicates access external resources, like files, kernel interface, etc. Problems can get serious on shared objects when there are name clashes (I remember when I tried LD_PRELOAD=libpolybori.so and discovered that it builds stubs to several libc calls if UNIX is not defined, and it is not in Linux). About Tim Daly comment that I think may be related to axiom :-) The axiom package was broken for quite some time in Mandriva. My first work on it I got it to work with system gmp, but need several gcl patches. When someone else in Mandriva updated to gmp 5, I rebuilt axiom using its internal copy of gmp3 (I am using git axiom). In case you want to check it: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/axiom/ > Francois Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] About mpmath and sympy
2010/7/16 François Bissey : >> Hi, >> >> Newer sympy has a bundled copy of mpmath, what causes several >> problems in my sagemath package. I was in vacation during most of >> Mandriva 2010.1 freeze, and did not fully test the package for some >> time, but I am working on an update for it; basically an 's/import >> mpmath/import sympy.mpmath as mpmath/', but would like to know what >> would be the better approach. (just letting the code use both leads to >> SEGvs). >> >> The new sagemath package will conflict with >> python-mpmath-0.14-1mdv2010.1 (forcing it to be uninstalled), because >> the sympy is python-sympy-0.6.7-1mdv2010.1. >> > Hi Paulo, > > that will probably be a pain for us in gentoo as well. > At the moment we are sticking with sympy-0.6.6 as > sympy-0.6.7 gives us trouble. The gentoo philosophy > at this point will be to remove mpmath from sympy and > make it a requirement. But I haven't been actively working > on that. Hi François, I think the proper solution should be for upstream sympy to not have a copy of mpmath, or, somehow not let it conflict with a toplevel mpmath. Otherwise, patching will be required. For now I am using this one (with minor changes for 2010.1 and sage 4.4): http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/sagemath/current/SOURCES/sage-4.4.4-sympy_mpmath.patch?view=markup and forcing python-mpmath to be uninstalled if upgrading the sagemath package. > Francois > > -- Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] About mpmath and sympy
Hi, Newer sympy has a bundled copy of mpmath, what causes several problems in my sagemath package. I was in vacation during most of Mandriva 2010.1 freeze, and did not fully test the package for some time, but I am working on an update for it; basically an 's/import mpmath/import sympy.mpmath as mpmath/', but would like to know what would be the better approach. (just letting the code use both leads to SEGvs). The new sagemath package will conflict with python-mpmath-0.14-1mdv2010.1 (forcing it to be uninstalled), because the sympy is python-sympy-0.6.7-1mdv2010.1. Thanks, Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-on-gentoo status at version 4.4.4
2010/6/30 cschwan :
>
>
> On 30 Jun., 16:05, "Georg S. Weber"
> wrote:
>> Great work!
>>
>> Actually, it makes me think about installing Gentoo just to test this
>> (I do know I don't have the time for this, but it does wet my mouth
>> nevertheless).
>
> I take this as a compliment - thanks !
>
>> Two further comments from me below:
>>
>>
>>
>>
>>
>> > Outstanding issues:
>> ...
>> > -pexpect: version 2 is outdated, version 2.4 has trouble with graphics in
>> > the notebook
Do you see the problems in http://trac.sagemath.org/sage_trac/ticket/6900 ?
I confess I did not yet try a newer pexpect with sagenb, and that trac is about
the old notebook.
>> I think William had tried several newer versions of pexpect than the
>> one currently used in Sage, and the one and main drawback was a
>> serious performance regression hurting all these newer versions. Did
>> you check if/how the performance changed? I don't know exactly what
>> test cases William used, but he will surely tell, if we ask him.
>
> I can confirm this - newer version are extremely slow or do not work
> at all.
I see this is a kind of a can of worms, but the pexpect interface is
also the reason of problems with clisp and gcl as maxima lisp backends
(readline and redirection of stderr issues), because pexpect allocates
a pty, but I think either it, or sage interface to it, doesn't make it
work as a fully functional terminal emulator. I also did not check
again recently the issue with gap, where it "scrolls horizontally" its
input, and somewhere there was a bug due to that, either in gap,
pexpect or most likely, iteration of both in that special case, but
the problem only did appear in the SaveWorkspace("some/long/path");
call, when that call had more the 80 characters (actually less, due to
gap> prompt and auto scroll when cursor would move to column 81).
I hate to make a suggestion but not show the code :-) But I believe
the pexpect interface in sage requires a major rework. I would suggest
making it work as a "dumb" pipe connection, that would automatically
make the "other side" understand it is not in interactive mode, and
not use readline, terminal control sequences, etc, but that is when
the "can" is opened... and would certainly show all kinds of issues.
Nevertheless, if it is controlled by sage developers, it should be
easier to work with. I mean, possibly write a new sage to/from other
application interface, and drop pexpect.
>> > Future:
>> ...
>> > -gentoo-prefix: making sage available on other platform through
>> > gentoo-prefix,
>> > Christopher is looking at this on windows and I have access OS X 10.5.
>>
>> This is excellent news, again I wish my days had 30 hours (or more).
>>
>> Cheers,
>> Georg
Paulo
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: Ubuntu 10.04, JMOL, Java
2010/6/13 ManDay :
> I too haven't got JMol to work in the NB, although it works fine as
> the standalone application when run from the commandline. I don't see
> how the site you mentioned would help. Installing JAVA was no problem
> and it works just fine, including JMol applets on the jmol.sourceforge
> site. This is most likely a problem of SAGE.
>
> I've no ideas how to tackle it. Everything appears to be returned
> correctly, from what I can tell, meaning that SAGE provides a JMol
> file which says
>
> set defaultdirectory "sage0-size500-306189399.jmol.zip"
> script SCRIPT
>
> and the according zip-file has the required contents. However, the
> console gives out an error saying
Out of curiosity, are you using openjdk with firefox or chromium browser?
I opened a bug report at
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=493 where I
describe the procedure I used to make openjdk work with chromium, but
in sage, jmol for some reason only works with chromium in the
tutorial. If I create a new worksheet, I get the errors that appear to
be the same you describe (html contents where a jmol input was
expected). Also in my case, it appears to be some problem that firefox
works around, but I still did not stop to debug the data being
sent/received...
> FileManager opening
> http://localhost:8000/home/admin/0/cells/1/sage0-size500.jmol?1276349004
> script compiler ERROR: command expected
> line 1 command 1 of /home/admin/0/cells/1/sage0-size500.jmol?
> 1276349004:
>
> script ERROR: script compiler ERROR: command expected
> line 1 command 1 of /home/admin/0/cells/1/sage0-size500.jmol?
> 1276349004:
>
> eval ERROR:
> line 1 command 1:
> script >> "/home/admin/0/cells/1/sage0-size500.jmol?
> 1276349004" <<
>
> Any further ideas?
>
> On May 23, 11:39 pm, Bruce Cohen wrote:
>> I found this
>> page:http://sites.google.com/site/easylinuxtipsproject/java#TOC-Install-JR...
>> to be quite useful. jmolnow works on all my machines (running Ubuntu
>> 10.04)
>>
>> -Bruce
>>
>> On May 12, 9:07 pm, Bruce Cohen wrote:
>>
>>
>>
>> > I have just triedjmolon two machines running 32 bitUbuntu10.04.
>> > At the command line
>>
>> > var('x y')
>> > plot3d(x^2+y^2, (x,-2,2), (y,-2,2))
>>
>> > works on both machines.
>>
>> > The same commands in the notebook work fine on the machine with the
>> > fresh 10.04 install, but do not work on the one which
>> > was upgraded from 9.10.
>>
>> > On the fresh install, I show this with a url of "about:plugins"
>>
>> >Java(TM) Plug-in 1.6.0_20
>>
>> > File: libnpjp2.so
>> > Version:
>> > The next generationJavaplug-in for Mozilla browsers.
>>
>> > -Bruce
>>
>> > On May 12, 5:05 am, Pablo Angulo wrote:
>>
>> > > My experience before 10.04 was that openjdk worked from the command
>> > > line, but not in the notebook. This appeared to be the case.
>> > > After reading this thread, I tried to drop my .mozilla folder, which I
>> > > have carried for years and now applets do work. More concretely, I
>> > > renamed .mozilla into .mozilla-no, and got a freash browser.
>> > > I've tried to find the particular file within .mozilla that causes the
>> > > trouble, as I want to keep the bookmarks and history, unsuccessfully.
Paulo
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: Sage on Gentoo - Random SIGABRT failures on exit
2010/5/22 cschwan :
> @Willem: I took the suppression file from Sage's valgrind.spkg - this
> filtered a lot meesages.
>
> @Paulo:
>
> valgrind --db-attach=yes --freelist-vol=1 python
> /usr/share/sage/local/bin/sage-ipython
>
> does not work for me - valgrind prints only a message while starting,
> but does not show summary unless i add --trace-children=yes. Do you
> enable this, too ? With this switch I get tons of output (is this
> normal behaviour?) which make it impossible to find any hint to to
> resolve my problem ...
I just tried it in my computer, to ensure I did not pass any wrong
information :-)
But I first inspected the contents of
"devel/sage/doc/en/reference/sage/categories/examples/algebras_with_basis.rst"
I am not sure what is the correct procedure to view the output in
text mode, so, I just opened
file:///usr/share/sage/devel/doc/output/html/en/reference/sage/categories/examples/algebras_with_basis.html
in firefox. That is the path in my rpm (/usr/share/sage/sage is a
symlink to the system wide python site dir, so I use the doc in a
directory below).
Then, I did a cut&paste of the examples, commenting the expected
results, i.e.:
-%<-
sage: A = AlgebrasWithBasis(QQ).example(); A
# An example of an algebra with basis: the free algebra on the
generators ('a', 'b', 'c') over Rational Field
sage: A.algebra_generators()
# Family (B[word: a], B[word: b], B[word: c])
sage: A = AlgebrasWithBasis(QQ).example()
sage: A.one_basis()
# word:
sage: A.one()
# B[word: ]
sage: A = AlgebrasWithBasis(QQ).example()
sage: Words = A.basis().keys()
sage: A.product_on_basis(Words("acb"), Words("cba"))
# B[word: acbcba]
sage: (a,b,c) = A.algebra_generators()
sage: a * (1-b)^2 * c
# B[word: abbc] - 2*B[word: abc] + B[word: ac]
-%<-
And here is a cut&paste of the session in a fresh xterm:
-%<-
export CUR=`pwd`
export DOT_SAGE="$HOME/.sage/"
export DOT_SAGENB="$DOT_SAGE"
mkdir -p $DOT_SAGE/{maxima,sympow,tmp}
export SAGE_TESTDIR=$DOT_SAGE/tmp
export SAGE_ROOT="/usr/share/sage"
export SAGE_LOCAL="/usr/share/sage/local"
export SAGE_DATA="/usr/share/sage/data"
export SAGE_DEVEL="/usr/share/sage/devel"
export SAGE_DOC="/usr/share/sage/devel/doc"
export PATH=/usr/share/sage/local/bin:/usr/share/cdd/bin:$PATH
export SINGULARPATH=/usr/share/singular/LIB
export SINGULAR_BIN_DIR=/usr/share/singular/i386
export PYTHONPATH="/usr/share/sage/site-packages"
export SAGE_CBLAS=cblas
export SAGE_FORTRAN=/usr/bin/gfortran
export SAGE_FORTRAN_LIB=`gfortran --print-file-name=libgfortran.so`
export SYMPOW_DIR="$DOT_SAGE/sympow"
/usr/share/sage/local/bin/sage-sage "$@"
[pa...@localhost ~]$ export CUR=`pwd`
[pa...@localhost ~]$ export DOT_SAGE="$HOME/.sage/"
[pa...@localhost ~]$ export DOT_SAGENB="$DOT_SAGE"
[pa...@localhost ~]$ mkdir -p $DOT_SAGE/{maxima,sympow,tmp}
[pa...@localhost ~]$ export SAGE_TESTDIR=$DOT_SAGE/tmp
[pa...@localhost ~]$ export SAGE_ROOT="/usr/share/sage"
[pa...@localhost ~]$ export SAGE_LOCAL="/usr/share/sage/local"
[pa...@localhost ~]$ export SAGE_DATA="/usr/share/sage/data"
[pa...@localhost ~]$ export SAGE_DEVEL="/usr/share/sage/devel"
[pa...@localhost ~]$ export SAGE_DOC="/usr/share/sage/devel/doc"
[pa...@localhost ~]$ export
PATH=/usr/share/sage/local/bin:/usr/share/cdd/bin:$PATH
[pa...@localhost ~]$ export SINGULARPATH=/usr/share/singular/LIB
[pa...@localhost ~]$ export SINGULAR_BIN_DIR=/usr/share/singular/i386
[pa...@localhost ~]$ export PYTHONPATH="/usr/share/sage/site-packages"
[pa...@localhost ~]$ export SAGE_CBLAS=cblas
[pa...@localhost ~]$ export SAGE_FORTRAN=/usr/bin/gfortran
[pa...@localhost ~]$ export SAGE_FORTRAN_LIB=`gfortran
--print-file-name=libgfortran.so`
[pa...@localhost ~]$ export SYMPOW_DIR="$DOT_SAGE/sympow"
[pa...@localhost ~]$ export IPYTHONDIR="$DOT_SAGE/ipython"
[pa...@localhost ~]$ export IPYTHONRC="ipythonrc"
[pa...@localhost ~]$ valgrind --db-attach=yes --freelist-vol=1
python /usr/share/sage/local/bin/sage-ipython
==5336== Memcheck, a memory error detector
==5336== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==5336== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==5336== Command: python /usr/share/sage/local/bin/sage-ipython
==5336==
sage: A = AlgebrasWithBasis(QQ).example(); A
An example of an algebra with basis: the free algebra on the
generators ('a', 'b', 'c') over Rational Field
sage: A.algebra_generators()
Family (B[word: a], B[word: b], B[word: c])
sage: A = AlgebrasWithBasis(QQ).example()
sage: A.one_basis()
word:
sage: A.one()
B[word: ]
sage: A = AlgebrasWithBasis(QQ).example()
sage: Words = A.basis().keys()
sage: A.product_on_basis(Words("acb"), Words("cba"))
B[word: acbcba]
sage: (a,b,c) = A.algebra_generators()
sage: a * (1-b)^2 * c
B[word: abbc] - 2*B[word: abc] + B[word: ac]
sage: quit
Exiting Sage (CPU time 0m7.84s, Wall time 1m13.71s).
==5336==
==5336== HEAP SUMMARY:
==5336== in use at exit: 34,615,866 bytes in 253,452 blocks
==5336== total heap usage: 11,757,376 allocs, 11,503,924 frees,
3,758,3
Re: [sage-devel] Re: GMP web sites says Sage relies on GMP
2010/5/18 Bill Hart : > So what do you suggest as a solution then? Peace and Love! That being said, people work better when there is competition. As long as there is "balance in power", and mutual respect/trust, things should just work. But that is something that even with infinite multiple precision, probably cannot be resolved with just math :-) -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: GMP web sites says Sage relies on GMP
I did not follow the history about mpir and gmp, so forgive me for not knowing the reasons behind the fork, and the childish behavior of developers. But this smells somewhat like what I saw in another case, when Xorg took over XFree86. Short story, Xorg people just like to tell others and themselves, about how good they are, and how bad XFree86 was. So, I believe this mpir vs gmp issue where there isn't a friendly relationship from both sides, will just cause harm. Maybe would not get to this point, but for example, when XFree86 released version 4.8.0, I made *functional* rpms for Mandriva, but was asked to not consider to add them as "contrib" packages, to avoid causing problems with Mandriva France packagers, and confusion to users. But having two, inevitably soon or later, to be incompatible versions of the same library is just going to cause people to have to choose one or another. [ I don't have sides on XFree86/Xorg or gmp/mpir ] [ I was a volunteer contributor to XFree86 in the late 90s and early 0s ] [ I did not work with open source or a Linux distro for a few years, and when "coming back", after one year sending patches, I got commit rights in Xorg, and after another year, one single person removed my commit rights without warning or questions (everyone breaks builds, and corrects them shortly, right?). But now, so far, I am doing something that I like, and packaging scientific software, sage included... ] Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Sage on Gentoo - Random SIGABRT failures on exit
2010/5/16 cschwan :
> I already tried valgrind but it did not work - how do I exactly use
> it ? When I run
>
> sage -valgrind -t -force_lib "devel/sage/doc/en/reference/sage/
> categories/examples/algebras_with_basis.rst"
>
> I get:
>
> --
> | Sage Version 4.4.1, Release Date: 2010-05-02 |
> | Type notebook() for the GUI, and license() for information. |
> --
> /opt/sage/local/bin/sage-ipython
> Log file is /home/gnuke/.sage/valgrind/sage-memcheck.%p
> Using default flags:
> --leak-resolution=high --log-file=/home/gnuke/.sage/valgrind/sage-
> memcheck.%p --leak-check=full --num-callers=25 --suppressions=/opt/
> sage/local/lib/valgrind/sage.supp
>
> but nothing happens.
The procedure I use in the Mandriva package is:
1. set environment variables from /usr/bin/sage
--%<--
#!/bin/sh
export CUR=`pwd`
export DOT_SAGE="$HOME/.sage/"
export DOT_SAGENB="$DOT_SAGE"
mkdir -p $DOT_SAGE/{maxima,sympow,tmp}
export SAGE_TESTDIR=$DOT_SAGE/tmp
export SAGE_ROOT="/usr/share/sage"
export SAGE_LOCAL="/usr/share/sage/local"
export SAGE_DATA="/usr/share/sage/data"
export SAGE_DEVEL="/usr/share/sage/devel"
export SAGE_DOC="/usr/share/sage/devel/doc"
export PATH=/usr/share/sage/local/bin:/usr/share/cdd/bin:$PATH
export SINGULARPATH=/usr/share/singular/LIB
export SINGULAR_BIN_DIR=/usr/share/singular/i386
export PYTHONPATH="/usr/share/sage/site-packages"
export SAGE_CBLAS=cblas
export SAGE_FORTRAN=/usr/bin/gfortran
export SAGE_FORTRAN_LIB=`gfortran --print-file-name=libgfortran.so`
export SYMPOW_DIR="$DOT_SAGE/sympow"
/usr/share/sage/local/bin/sage-sage "$@"
--%<--
the above is generated for i586, so, just cut&paste it, but the last
line on a xterm
2. set ipython env
export IPYTHONDIR="$DOT_SAGE/ipython"
export IPYTHONRC="ipythonrc"
3. run valgrind
valgrind --db-attach=yes --freelist-vol=1 python
/usr/share/sage/local/bin/sage-ipython
This is a procedure I "documented" in a commit, but it should not
modify much for
gentoo. It works as sage -gdb or sage -valgrind, but I think I prefer things the
harder way, or where I have more control of what is going on...
On the above procedure, I would also cut&paste the doctest in sage prompt.
If valgrind reports too many memory errors, it may be harder, as you must say
'N' every time it asks if you want to attach gdb...
Paulo
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Potential problems with next version of python (2.6.5 and over)
2010/5/14 François Bissey : > We had a long standing problem in both Gentoo and Mandriva > with the following test > sage -t -force_lib "devel/sage/sage/combinat/iet/strata.py" > which is failing for us using the system python shipped with our > distributions. > As it turns out it is because the python shipped in our system includes > the patch solving: > http://bugs.python.org/issue7491 > The patches have been merged in 2.6.5 and 2.7 and they are included > in python-2.6.4 shipped by a number of distros. > > This is a friendly warning that it will be an issue for the next python > upgrade. The problem François tells is about is this error: -%<- sage -t -force_lib "devel/sage/sage/combinat/iet/strata.py" [?1034h** File "/usr/share/sage/devel/sage/sage/combinat/iet/strata.py", line 1331: sage: c1 != c2_hyp Exception raised: Traceback (most recent call last): File "/usr/share/sage/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/usr/share/sage/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/usr/share/sage/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "", line 1, in c1 != c2_hyp###line 1331: sage: c1 != c2_hyp File "/usr/lib64/python2.6/site-packages/sage/combinat/iet/strata.py", line 1347, in __cmp__ return type.__cmp__(type(self),type(other)) AttributeError: type object 'type' has no attribute '__cmp__' ** File "/usr/share/sage/devel/sage/sage/combinat/iet/strata.py", line 1333: sage: c2_hyp != c2_odd Exception raised: Traceback (most recent call last): File "/usr/share/sage/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/usr/share/sage/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/usr/share/sage/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "", line 1, in c2_hyp != c2_odd###line 1333: sage: c2_hyp != c2_odd File "/usr/lib64/python2.6/site-packages/sage/combinat/iet/strata.py", line 1347, in __cmp__ return type.__cmp__(type(self),type(other)) AttributeError: type object 'type' has no attribute '__cmp__' ** 1 items had failures: 2 of 15 in __main__.example_37 ***Test Failed*** 2 failures. For whitespace errors, see the file /home/pcpa/.sage//tmp/.doctest_strata.py [4.1 s] -%<- > Francois Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Ubuntu 10.04, JMOL, Java
2010/5/12 Jan Groenewald : > Hi Hi, > On Tue, May 11, 2010 at 05:42:52PM -0300, Paulo C?sar Pereira de Andrade > wrote: >> > java version "1.6.0_18" >> > OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-0ubuntu1) >> > OpenJDK Client VM (build 14.0-b16, mixed mode, sharing) >> > java.io.FileNotFoundException: /home/jan/.icedteaplugin/java.stderr (No >> > such file or directory) >> > at java.io.FileOutputStream.open(Native Method) >> > at java.io.FileOutputStream.(FileOutputStream.java:209) >> > at java.io.FileOutputStream.(FileOutputStream.java:160) >> > at sun.applet.PluginMain.(PluginMain.java:130) >> > at sun.applet.PluginMain.main(PluginMain.java:116) >> > 2010-05-11 09:42:12+0200 [HTTPChannel,6,127.0.0.1] Request error: >> > Connection to the other side was lost in a non-clean fashion. >> > script compiler ERROR: command expected >> > line 1 command 1 of >> > /home/admin/0/cells/2/sage0-size500.jmol?1273563709: >> > >> > script ERROR: script compiler ERROR: command expected >> > line 1 command 1 of >> > /home/admin/0/cells/2/sage0-size500.jmol?1273563709: >> > >> > eval ERROR: >> > line 1 command 1: >> > script >> "/home/admin/0/cells/2/sage0-size500.jmol?1273563709" << >> >> Does jmol work from the command line? > > How do I test that? You should be able to run it with: $ sage -sh $ jmol or $ /local/bin/jmol in case you have a system wide jmol. >> But I am doing some extra tests in with openjdk, and noticed that it >> may not work correctly sometimes if the computer >> is not "almost idle" when loading the applet. I did some debugging >> yesterday to try to find some problems in opendjk, >> and currently, my guess is some pthread_cond_timedwait timing out, and >> doing "evil" things, based on the kinds of >> stack/data corruptions I found when loading the plugin under a very high >> load... >> Either way, you should open a bug report at ubuntu, as it may be >> some small detail preventing it work correctly. > > Under which package? openjdk-6-jre ? Probably, but I am sorry I don't use Ubuntu, but that should reach the proper people. [btw forgive my comments about some pthread_cond_timedwait timing out, I found a weird behavior; if I do: (gdb) handle SIGSEGV nostop noprint (gdb) c it just works... kind hard to debug possible problems this way ...] > regards, > Jan > > -- > .~. > /V\ Jan Groenewald > /( )\ www.aims.ac.za > ^^-^^ > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Ubuntu 10.04, JMOL, Java
2010/5/11 Jan Groenewald :
> Hi
Hi,
> On Fri, May 07, 2010 at 09:55:02AM -0700, Rob Beezer wrote:
>> Sounds like Dan Drake has a simple test working on a clean 10.04
>> install (thanks, Dan!), so that is good news, I believe. If you want
>> to test your setup, in the notebook, try something simple like just
>>
>> var('x y')
>> plot3d(x^2+y^2, (x,-2,2), (y,-2,2))
>> and that should be good enough for openers.
>
> Maybe something to do with either
> 1) my crappy graphics card
> a...@numsha:~$ lspci|grep VGA
> 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility
> Radeon 9600 M10], (using open source drivers, I always found fglrx
> proprietary ATI drivers buggy), or
> 2) that I had sun-java6 installed and purged it again (and confirmed
> /etc/alternatives pointed at openjdk)
>
> But then above plot does not work for me :(
>
> The plot is just black, clicking Get Image opens
> a separate window which shows another black plot,
> which when attempting to drag to the desktop says
> error getting information about "=9k" and fails to copy.
> When you right clikc you can copy, but "paste" is disabled
> (greyed out) in the context menu when attempting to put this
> on the desktop. Also right click on the image and save as
> gives a black square window when opened in the default viewer,
> eog (eye of gnome).
>
> During this firefox at "about:plugins" (in the address bar)
> says: IcedTea NPR Web Browser Plugin (using IcedTea6 1.8 (6b18-1.8-0ubuntu1))
> File: IcedTeaPlugin.so
> Version:
> The IcedTea NPR Web Browser Plugin (using IcedTea6 1.8
> (6b18-1.8-0ubuntu1)) executes Java applets.
> and then lists versions from 1.1 to 1.6.0_18 all enabled.
>
> The terminal where sage was launched says:
>
> 2010-05-11 09:39:00+0200 [-] Starting factory
>
> java version "1.6.0_18"
> OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-0ubuntu1)
> OpenJDK Client VM (build 14.0-b16, mixed mode, sharing)
> java.io.FileNotFoundException: /home/jan/.icedteaplugin/java.stderr (No such
> file or directory)
> at java.io.FileOutputStream.open(Native Method)
> at java.io.FileOutputStream.(FileOutputStream.java:209)
> at java.io.FileOutputStream.(FileOutputStream.java:160)
> at sun.applet.PluginMain.(PluginMain.java:130)
> at sun.applet.PluginMain.main(PluginMain.java:116)
> 2010-05-11 09:42:12+0200 [HTTPChannel,6,127.0.0.1] Request error: Connection
> to the other side was lost in a non-clean fashion.
> script compiler ERROR: command expected
> line 1 command 1 of /home/admin/0/cells/2/sage0-size500.jmol?1273563709:
>
> script ERROR: script compiler ERROR: command expected
> line 1 command 1 of /home/admin/0/cells/2/sage0-size500.jmol?1273563709:
>
> eval ERROR:
> line 1 command 1:
> script >> "/home/admin/0/cells/2/sage0-size500.jmol?1273563709" <<
Does jmol work from the command line?
> So I close sage and install sun-java6 from the partner repositories:
>
> aptitude install sun-java6-jdk sun-java6-jre sun-java6-bin sun-java6-fonts
> sun-java6-plugin (and agree to the licenses)
>
> It seems alternatives are now updated for me, and I do not need to.
>
>
> The following NEW packages will be installed:
> sun-java6-bin sun-java6-fonts sun-java6-jdk sun-java6-jre sun-java6-plugin
> 0 packages upgraded, 5 newly installed, 0 to remove and 3 not upgraded.
> Need to get 56.6MB of archives. After unpacking 165MB will be used.
> Writing extended state information... Done
> Get:1 http://proxy.aims.ac.za/apt-cacher/archive.canonical.com/ubuntu/
> lucid/partner sun-java6-jre 6.20dlj-1ubuntu3 [6,410kB]
> Get:2 http://proxy.aims.ac.za/apt-cacher/archive.canonical.com/ubuntu/
> lucid/partner sun-java6-bin 6.20dlj-1ubuntu3 [29.4MB]
> Get:3 http://proxy.aims.ac.za/apt-cacher/archive.canonical.com/ubuntu/
> lucid/partner sun-java6-jdk 6.20dlj-1ubuntu3 [20.7MB]
> Get:4 http://proxy.aims.ac.za/apt-cacher/archive.canonical.com/ubuntu/
> lucid/partner sun-java6-fonts 6.20dlj-1ubuntu3 [1,876B]
> Get:5 http://proxy.aims.ac.za/apt-cacher/archive.canonical.com/ubuntu/
> lucid/partner sun-java6-plugin 6.20dlj-1ubuntu3 [1,850B]
> Fetched 56.6MB in 8s (6,917kB/s)
> Preconfiguring packages ...
> Selecting previously deselected package sun-java6-jre.
> (Reading database ... 55%
> (Reading database ... 238600 files and directories currently installed.)
> Unpacking sun-java6-jre (from .../sun-java6-jre_6.20dlj-1ubuntu3_all.deb) ...
> Selecting previously deselected package sun-java6-bin.
> Unpacking sun-java6-bin (from .../sun-java6-bin_6.20dlj-1ubuntu3_i386.deb) ...
> sun-dlj-v1-1 license has already been accepted
> Selecting previously deselected package sun-java6-jdk.
> Unpacking sun-java6-jdk (from .../sun-java6-jdk_6.20dlj-1ubuntu3_i386.deb) ...
> sun-dlj-v1-1 license has already been accepted
> Selecting previously deselected package sun-java6-fonts.
> Unpacking sun-java6-fonts (from .../sun-java6-fonts_6.20dlj-1ubuntu3_al
Re: [sage-devel] maxima-noreadline
2010/3/23 François Bissey : > Hi, Hi, > I am trying to find the root of some test failure with the maxima interface > on the port of sage of Gentoo and I have just read the content of > maxima-noreadline: > #!/bin/sh > SAGE_CLISP_DISABLE_READLINE_HACK="yes"; export > SAGE_CLISP_DISABLE_READLINE_HACK > exec "$SAGE_LOCAL"/bin/maxima "$@" > -- > > Considering that sage has switched to ecl, is this still relevant? It should not be, and certainly is not for a clisp not built using the sage spkg. I used a different approach in the mandriva package. Instead of using the SAGE_CLISP_DISABLE_READLINE_HACK environment variable, I changed a bit the behavior of the clisp -I option (patch credit to Sam Steingold, after asking in clisp-devel): http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/clisp/current/SOURCES/clisp-noreadline.patch?revision=418280&view=markup And added this change to the maxima script, to pass -I to clisp if --disable-readline is used: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/maxima/current/SOURCES/maxima-5.19.1-clisp-noreadline.patch?revision=421784&view=markup Since you say you are searching for the cause of problems in sage's interface to maxima, this patch to allow building ecl backend may also be useful: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/maxima/current/SOURCES/maxima-5.20.1-ecl-ldflags.patch?revision=514331&view=markup And this sagemath patch to actually allow using also clisp and gcl backends, and passing all doctests: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/sagemath/current/SOURCES/sage-4.3.3-maxima.patch?revision=524719&view=markup The problem with clisp and gcl is that, because the pexpect interface used by sage allocates a pty, it causes the lisp interface to consider it is running in an interactive mode, and redirects stderr to stdout. The solution for clisp was easier, but gcl required sending a ":lisp " command. But the sage interface appears to still be somewhat fragile, as if one mistakingly adds two ";", it will hang any lisp backend, due to the pexpect interface loosing sync. > Francois Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Re: [sage-devel] Re: Complex Coercion Error or User Error?
2010/3/18 kstueve : > Does anyone have information on the maximum size of an array of > doubles in C? I seem to be getting abnormal results using elements > past the first 1e6. What is the standard way to deal with very large > (millions to billions of elements) arrays of data in C? > Kevin Stueve Probably you are using a 32 bits (int) offset (that would not wrap at 1e6*8 bytes, but may be wrapping in some intermediate computation). Save for compiler bugs, as the compiler should work around any instruction limitations when addressing more then 2GB displacement offset (in bytes), as long as you can allocate the memory, it should be addressable with standard C syntax. If you have a buffer larger then 2GB, try to ensure you are working with 64 bits integers/values to calculate offsets. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Debian package...
2010/3/14 Kasper Peeters : >> That review process is what killed the Debian sagemath package >> -- Upgrading during the review process >> sends you to the back of the queue, and by a year after my original >> submission, I had left MIT graduate school to start a startup, and I no >> longer had the time to upgrade past a year of Sage development). > > Tim, I take it that you no longer have time to make an upgrade of the > sagemath package? Would you be willing to give us/me a brief run- > through > of the main obstacles you expect? I am able to put some time into > making a debian package (and have experience doing that), but it would > be good if I could avoid duplicating the work that you have already > put > into it. I don't have much experience with Debian build system, other then building or "hacking" some packages for OEM projects locally. And have zero experience with the procedure for approval of a package, etc. I see there was some work at http://wiki.sagemath.org/debian/sage-4.0.x-in-experimental The package in Mandriva is not officially supported, that is, it is not in the "main" repository, it is in "contrib". But I would really like to see it packaged for Debian and Ubuntu as a "system" package. This way, since Sage releases often, it would have a wider user base to check for problems and besides possibly problematic at first if Sage lags behind on the version of some component, at the end it should be better for everyone packaging Sage. One example, the wiki interface in the Mandriva package had been broken for quite some time, and only yesterday I noticed, and also corrected it So far, I basically only do a "sage -testall" to check for packaging problems, and run some of the tutorials. Just to attempt to make it clear. I am not a Linux or Mandriva evangelist, if anything, I would be a FreeBSD evangelist as it was my first experience with OSS, but I no longer do flaming (and, while I was indiferent to license issues in the past, I would advocate GPL now :-) > Cheers, > Kasper Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Memory leak
Em 6 de março de 2010 13:29, Paulo César Pereira de Andrade escreveu: > 2010/3/6 Robert Bradshaw : >> On Mar 5, 2010, at 6:33 PM, Minh Nguyen wrote: >> >>> Hi Dima, >>> >>> On Sat, Mar 6, 2010 at 1:27 PM, Dima Pasechnik wrote: >>>> >>>> if it's PARI-dependent, it makes sense to upgrade PARI to the latest >>>> version. >>> >>> Perhaps upgrading Pari could be a goal for Sage 5.0? >> >> It is: http://trac.sagemath.org/sage_trac/wiki/stab1 >> >> - Robert > > Just for the record. Currently in Mandriva sagemath package, the only pari > related doctest failure is the version number test :-) Err, sorry, there are a few others, for some reason I only remembered about the version number test, example from a recent log: File "/usr/share/sage/devel/sage/sage/libs/pari/gen.pyx", line 6850: sage: nf.nfroots(y^4 + 2) Expected: [-zz, zz] Got: [Mod(-zz, zz^4 + 2), Mod(zz, zz^4 + 2)] All of remaining test failures match this pattern, and are very few... Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Memory leak
2010/3/6 Robert Bradshaw : > On Mar 5, 2010, at 6:33 PM, Minh Nguyen wrote: > >> Hi Dima, >> >> On Sat, Mar 6, 2010 at 1:27 PM, Dima Pasechnik wrote: >>> >>> if it's PARI-dependent, it makes sense to upgrade PARI to the latest >>> version. >> >> Perhaps upgrading Pari could be a goal for Sage 5.0? > > It is: http://trac.sagemath.org/sage_trac/wiki/stab1 > > - Robert Just for the record. Currently in Mandriva sagemath package, the only pari related doctest failure is the version number test :-) Some time ago I was thinking some other doctest failures (example is CVT with correct, but different result than sage expects) were caused by newer pari, but it is corrected now; I believe due to gmp5 [1] Paulo [1] Currrently Mandriva package uses gmp, but I should add a mpir package at some point; I have one only in my computer, but would prefer to have it as an alternative, i.e. suitable to "update-alternatives", what would mean, same major number, providing the same features, and not breaking existing code dynamically linked to gmp. (I believe it probably already/still matches this, maybe requiring minimal patching, need to test...) -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
2010/3/4 Simon King : > Hi! > > On Mar 4, 8:35 am, Robert Bradshaw > wrote: > [...] >> I think we can have the names there without importing all the code >> behind everything. With tab completion, a huge global namespace isn't >> that bad. > > How would this be possible, technically? I mean, is there a technical > solution that does not require python to be patched? > > Perhaps modifying the sage preparser: > - At startup, virtually nothing of sage.all is imported, but the > names of things in sage.all are known, and it is known where to import > them from. Let SageAllNames be a dictionary that associates the name > with the location for import. > - The preparser could detect whether a given command line contains an > identifier N outside an import or assign statement, with N in > SageAllNames.keys(). If not globals().has_key(N), the preparser would > prepend "from %s import %s"%(SageAllNames[N],N) to the given command > line. > - It would be easy to modify tab completion so that > SageAllNames.keys() is accessible to tab completion. > > Would that be feasible? > > I think it could reduce the startup time considerably. A user wouldn't > notice any change during an interactive session. And since it only > concerns the preparser, it would not break any code. > > Cheers, > Simon After reading the continuation of the thread, the first thing that come to my mind was unexec. A quick google search showed a few matches, and an attempt from 2003, that apparently had a few regressions (in signal and thread tests), and also, in the message I found, the fact that the unexec code was gpl was also considered a problem. I know only as from overview what unexec does; used by emacs and xemacs; basically, a way to dump a running program, and reload it at a later stage, much faster. Does anybody know if there are any new approachs in it (I only found some emails from 2003 in a google search...) ? I believe it may require significant work if starting from emacs/xemacs unexelf.c to work correctly with shared modules/libraries, etc. But, it could be a way to to drastically reduce sage load time, but possibly, by generating a very huge image file. Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
2010/3/3 William Stein : > On Tue, Mar 2, 2010 at 7:56 PM, Dr. David Kirkby > wrote: >>> Right now it takes over 1.5 seconds every time. >>> wst...@sage:~$ time sage -c "print factor(2010)" >>> 2 * 3 * 5 * 67 >>> real 0m1.535s >>> user 0m1.140s >>> sys 0m0.460s >> >> Personaly I don't find that too excessive for a large tool. How long does >> Gimp take to start? > > That's irrelevant. What matters is how long Maple, Mathematica, > Matlab, Maxima, Pari, and Magma take to start. > After repeatedly running the command on sage.math, this is how things > stabilize: > > > Pari 0.030s > Python 0.046s > Maple 0.111s > Maxima 0.456s > Mathematica 0.524s > Matlab 0.844s > Magma 0.971s > Sage 1.658s > > This is probably the only benchmark that involves a "function" that > *everybody* uses -- starting up the program. Sage is currently dead > last, and by a lot. Python and Pari are both by far the fastest to > startup, so at least it isn't Python's fault :-). > > > LOG: > > wst...@sage:~$ time echo "2+2;" | sage -python > real 0m0.046s > > wst...@sage:~$ time echo "2+2;" | magma > Magma V2.14-9 Wed Mar 3 2010 05:40:30 on sage [Seed = 2126205915] > Type ? for help. Type -D to quit. > 4 > > Total time: 0.570 seconds, Total memory usage: 6.94MB > > real 0m0.971s > > -- > > wst...@sage:~$ time echo "2+2;" | maple > |\^/| Maple 12 (X86 64 LINUX) > ._|\| |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2008 > \ MAPLE / All rights reserved. Maple is a trademark of > < > Waterloo Maple Inc. > | Type ? for help. >> 2+2; > 4 > >> quit > memory used=0.8MB, alloc=0.7MB, time=0.01 > > real 0m0.111s > > --- > > wst...@sage:~$ time echo "2+2;" | math > Mathematica 6.0 for Linux x86 (64-bit) > Copyright 1988-2007 Wolfram Research, Inc. > > In[1]:= > In[2]:= > > real 0m0.524s > > > -- > > wst...@sage:~$ time echo "2+2;" | matlab > Warning: Unable to open display , MATLAB is starting without a display. > You will not be able to display graphics on the screen. > Warning: > MATLAB is starting without a display, using internal event queue. > You will not be able to display graphics on the screen. > > > < M A T L A B > > Copyright 1984-2006 The MathWorks, Inc. > Version 7.2.0.283 (R2006a) > January 27, 2006 > > > To get started, type one of these: helpwin, helpdesk, or demo. > For product information, visit www.mathworks.com. > >>> >> > real 0m0.844s > > --- > > wst...@sage:~$ time echo "2+2;" | sage -maxima > ;;; Loading #P"/home/wstein/build/production/sage/local/lib/ecl/defsystem.fas" > ;;; Loading #P"/home/wstein/build/production/sage/local/lib/ecl/cmp.fas" > ;;; Loading #P"/home/wstein/build/production/sage/local/lib/ecl/sysfun.lsp" > Maxima 5.20.1 http://maxima.sourceforge.net > using Lisp ECL 9.10.2 > Distributed under the GNU Public License. See the file COPYING. > Dedicated to the memory of William Schelter. > The function bug_report() provides bug reporting information. > (%i1) > (%o1) 4 > (%i2) > real 0m0.456s > > --- > > > wst...@sage:~$ time echo "2+2;" | sage -gp > GP/PARI CALCULATOR Version 2.3.3 (released) > amd64 running linux (x86-64/GMP-4.2.1 kernel) 64-bit version > compiled: Feb 25 2010, gcc-4.2.4 (Ubuntu 4.2.4-1ubuntu4) > (readline v6.0 enabled, extended help available) > > Copyright (C) 2000-2006 The PARI Group > > PARI/GP is free software, covered by the GNU General Public License, and > comes WITHOUT ANY WARRANTY WHATSOEVER. > > Type ? for help, \q to quit. > Type ?12 for how to get moral (and possibly technical) support. > > parisize = 800, primelimit = 50 > Goodbye! > > real 0m0.030s > > --- > > wst...@sage:~$ time echo "2+2;" | sage > -- > | Sage Version 4.3.3, Release Date: 2010-02-21 | > | Type notebook() for the GUI, and license() for information. | > -- > sage: sage: > Exiting SAGE (CPU time 0m0.05s, Wall time 0m0.06s). > > real 0m1.658s A suggestion to debug these issues is to use oprofile. A cheat sheet from a procedure I used some times in the past to debug performance of multi programs/modules/libraries is: # rm -fr /var/lib/oprofile/samples/current/; opcontrol --init; opcontrol --start; ; opcontrol --dump; opcontrol --stop; opcontrol --deinit # opreport --symbols In my tests, I would run as root, have the computer as idle as possible, and also do the start/stop of oprofile logging to avoid as much as possible any noise. This of couse is Linux specific, but similar tools should exist in other OSes. An examp
Re: [sage-devel] summary of doctest failures in Mandriva cooker sagemath 4.3.3 package
2010/3/2 François Bissey :
>> Hi,
>>
>> Some are known problems due to using different versions of certain
>> packages, example:
>>
>> -%<-
>> File "/usr/share/sage/devel/doc/en/numerical_sage/cvxopt.rst", line 57:
>> sage: print(A)
>> Expected:
>> SIZE: (5,5)
>> (0, 0) 2.e+00
>> (1, 0) 3.e+00
>> (0, 1) 3.e+00
>> (2, 1) -1.e+00
>> (4, 1) 4.e+00
>> (1, 2) 4.e+00
>> (2, 2) -3.e+00
>> (3, 2) 1.e+00
>> (4, 2) 2.e+00
>> (2, 3) 2.e+00
>> (1, 4) 6.e+00
>> (4, 4) 1.e+00
>> Got:
>> [ 2.00e+00 3.00e+00 0 0 0 ]
>> [ 3.00e+00 0 4.00e+00 0 6.00e+00]
>> [ 0 -1.00e+00 -3.00e+00 2.00e+00 0 ]
>> [ 0 0 1.00e+00 0 0 ]
>> [ 0 4.00e+00 2.00e+00 0 1.00e+00]
>>
>> -%<-
>> or
>> -%<-
>> File "/usr/share/sage/devel/sage/sage/libs/pari/gen.pyx", line 6844:
>> sage: nf.nfroots(y^2 + 2)
>> Expected:
>> [-zz, zz]
>> Got:
>> [Mod(-zz, zz^2 + 2), Mod(zz, zz^2 + 2)]
>> -%<-
>>
>> Some are due to system wide installation, example:
>> -%<-
>> File "/usr/share/sage/devel/doc/common/builder.py", line 157:
>> sage: b = builder.DocBuilder('tutorial')
>> Exception raised:
>> Traceback (most recent call last):
>> File "/usr/share/sage/local/bin/ncadoctest.py", line 1231, in
>> run_one_test self.run_one_example(test, example, filename, compileflags)
>> File "/usr/share/sage/local/bin/sagedoctest.py", line 38, in
>> run_one_example
>> OrigDocTestRunner.run_one_example(self, test, example,
>> filename, compileflags)
>> File "/usr/share/sage/local/bin/ncadoctest.py", line 1172, in
>> run_one_example
>> compileflags, 1) in test.globs
>> File "", line 1, in
>> b = builder.DocBuilder('tutorial')###line 157:
>> sage: b = builder.DocBuilder('tutorial')
>> File "/usr/share/sage/devel/doc/common/builder.py", line 145, in
>> __init__ mkdir(os.path.join(self.dir, "static"))
>> File "/usr/share/sage/devel/doc/common/builder.py", line 55, in mkdir
>> os.makedirs(path)
>> File "/usr/lib64/python2.6/os.py", line 157, in makedirs
>> mkdir(name, mode)
>> OSError: [Errno 13] Permission denied:
>> '/usr/share/sage/devel/doc/en/tutorial/static'
>> -%<-
>> or
>> -%<-
>> File "/usr/share/sage/devel/doc/en/constructions/plotting.rst", line 209:
>> sage: maxima.eval('load("plotdf");')
>> Expected:
>> '".../local/share/maxima/.../share/dynamics/plotdf.lisp"'
>> Got:
>> '"/usr/share/maxima/5.20.1/share/dynamics/plotdf.lisp"'
>> -%<-
>>
>> Some are somewhat strange, but I believe they are due to using some
>> package with different version, or missing some patch. Examples:
>> -%<-
>> File "/usr/share/sage/devel/sage/sage/matrix/matrix1.pyx", line 448:
>> sage: sorted(numpy.typecodes.items())
>> Expected:
>> [('All', '?bhilqpBHILQPfdgFDGSUVO'), ('AllFloat', 'fdgFDG'),
>> ('AllInteger', 'bBhHiIlLqQpP'), ('Character', 'c'), ('Complex',
>> 'FDG'), ('Float', 'fdg'), ('Integer', 'bhilqp'), ('UnsignedInteger',
>> 'BHILQP')]
>> Got:
>> [('All', '?bhilqpBHILQPfdgFDGSUVOMm'), ('AllFloat', 'fdgFDG'),
>> ('AllInteger', 'bBhHiIlLqQpP'), ('Character', 'c'), ('Complex',
>> 'FDG'), ('Datetime', 'Mm'), ('Float', 'fdg'), ('Integer', 'bhilqp'),
>> ('UnsignedInteger', 'BHILQP')]
>> -%<-
>> and
>> -%<-
>> File "/usr/share/sage/devel/sage/sage/sets/set.py", line 312:
>> sage: Primes() < Set(QQ)
>> Expected:
>> True
>> Got:
>> False
>> -%<-
>> and
>> -%<
>> File "/usr/share/sage/devel/sage/sage/finance/time_series.pyx", line 1505:
>> sage: finance.TimeSeries([z.hurst_exponent() for z in y]).mean()
>> Expected:
>> 0.579848225779347...
>> Got:
>> 0.5798482257793468
>> -%<-
>>
>> Some details that may be useful:
>> 1) I am using a custom cPickle.so and pickle.py in $PYTHONPATH due to
>> sage's patches
>> 2) I am using a custom sets.py in $PYHTONPATH that doesn't generate a
>> DeprecationWarning,
>> otherwise, the number of false positive positives due to
>> Deprecation warnings is too high...
>> 3) I am using gmp5 instead of mpir (needs only a one line patch so far...)
>> 4) I am using a newer givaro and python-mpmath, because other packages
>> resolved to
>> update those packages :-) So, I built a givaro patch, and used
>> mpmath patches from trac
>>
>>
>> I also found out that clisp maxima backend has a serious issue, in
>> that, for example it hangs
>> with the command:
>> sage: maxima.eval('x==x')
>> (as in sage/interfaces/maxima.py eval_line doctest)
>> and, probably because of the timeout and process kill, it causes some
>> other weird
>> doctest failures like:
>> -%<-
>> File "/usr/share/sage/devel/sage/sage/symbolic/relation.py", line 560:
>> sage: solve([cos(x)*sin(x) == 1/2, x+y == 0],x,y)
>> Expected:
>> [[x == 1/4*pi + pi*
[sage-devel] summary of doctest failures in Mandriva cooker sagemath 4.3.3 package
Hi,
Some are known problems due to using different versions of certain
packages, example:
-%<-
File "/usr/share/sage/devel/doc/en/numerical_sage/cvxopt.rst", line 57:
sage: print(A)
Expected:
SIZE: (5,5)
(0, 0) 2.e+00
(1, 0) 3.e+00
(0, 1) 3.e+00
(2, 1) -1.e+00
(4, 1) 4.e+00
(1, 2) 4.e+00
(2, 2) -3.e+00
(3, 2) 1.e+00
(4, 2) 2.e+00
(2, 3) 2.e+00
(1, 4) 6.e+00
(4, 4) 1.e+00
Got:
[ 2.00e+00 3.00e+00 0 0 0]
[ 3.00e+00 0 4.00e+00 0 6.00e+00]
[0 -1.00e+00 -3.00e+00 2.00e+00 0]
[0 0 1.00e+00 0 0]
[0 4.00e+00 2.00e+00 0 1.00e+00]
-%<-
or
-%<-
File "/usr/share/sage/devel/sage/sage/libs/pari/gen.pyx", line 6844:
sage: nf.nfroots(y^2 + 2)
Expected:
[-zz, zz]
Got:
[Mod(-zz, zz^2 + 2), Mod(zz, zz^2 + 2)]
-%<-
Some are due to system wide installation, example:
-%<-
File "/usr/share/sage/devel/doc/common/builder.py", line 157:
sage: b = builder.DocBuilder('tutorial')
Exception raised:
Traceback (most recent call last):
File "/usr/share/sage/local/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/usr/share/sage/local/bin/sagedoctest.py", line 38, in
run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/usr/share/sage/local/bin/ncadoctest.py", line 1172, in
run_one_example
compileflags, 1) in test.globs
File "", line 1, in
b = builder.DocBuilder('tutorial')###line 157:
sage: b = builder.DocBuilder('tutorial')
File "/usr/share/sage/devel/doc/common/builder.py", line 145, in __init__
mkdir(os.path.join(self.dir, "static"))
File "/usr/share/sage/devel/doc/common/builder.py", line 55, in mkdir
os.makedirs(path)
File "/usr/lib64/python2.6/os.py", line 157, in makedirs
mkdir(name, mode)
OSError: [Errno 13] Permission denied:
'/usr/share/sage/devel/doc/en/tutorial/static'
-%<-
or
-%<-
File "/usr/share/sage/devel/doc/en/constructions/plotting.rst", line 209:
sage: maxima.eval('load("plotdf");')
Expected:
'".../local/share/maxima/.../share/dynamics/plotdf.lisp"'
Got:
'"/usr/share/maxima/5.20.1/share/dynamics/plotdf.lisp"'
-%<-
Some are somewhat strange, but I believe they are due to using some package
with different version, or missing some patch. Examples:
-%<-
File "/usr/share/sage/devel/sage/sage/matrix/matrix1.pyx", line 448:
sage: sorted(numpy.typecodes.items())
Expected:
[('All', '?bhilqpBHILQPfdgFDGSUVO'), ('AllFloat', 'fdgFDG'),
('AllInteger', 'bBhHiIlLqQpP'), ('Character', 'c'), ('Complex',
'FDG'), ('Float', 'fdg'), ('Integer', 'bhilqp'), ('UnsignedInteger',
'BHILQP')]
Got:
[('All', '?bhilqpBHILQPfdgFDGSUVOMm'), ('AllFloat', 'fdgFDG'),
('AllInteger', 'bBhHiIlLqQpP'), ('Character', 'c'), ('Complex',
'FDG'), ('Datetime', 'Mm'), ('Float', 'fdg'), ('Integer', 'bhilqp'),
('UnsignedInteger', 'BHILQP')]
-%<-
and
-%<-
File "/usr/share/sage/devel/sage/sage/sets/set.py", line 312:
sage: Primes() < Set(QQ)
Expected:
True
Got:
False
-%<-
and
-%<
File "/usr/share/sage/devel/sage/sage/finance/time_series.pyx", line 1505:
sage: finance.TimeSeries([z.hurst_exponent() for z in y]).mean()
Expected:
0.579848225779347...
Got:
0.5798482257793468
-%<-
Some details that may be useful:
1) I am using a custom cPickle.so and pickle.py in $PYTHONPATH due to
sage's patches
2) I am using a custom sets.py in $PYHTONPATH that doesn't generate a
DeprecationWarning,
otherwise, the number of false positive positives due to
Deprecation warnings is too high...
3) I am using gmp5 instead of mpir (needs only a one line patch so far...)
4) I am using a newer givaro and python-mpmath, because other packages
resolved to
update those packages :-) So, I built a givaro patch, and used
mpmath patches from trac
I also found out that clisp maxima backend has a serious issue, in
that, for example it hangs
with the command:
sage: maxima.eval('x==x')
(as in sage/interfaces/maxima.py eval_line doctest)
and, probably because of the timeout and process kill, it causes some
other weird
doctest failures like:
-%<-
File "/usr/share/sage/devel/sage/sage/symbolic/relation.py", line 560:
sage: solve([cos(x)*sin(x) == 1/2, x+y == 0],x,y)
Expected:
[[x == 1/4*pi + pi*z38, y == -1/4*pi - pi*z38]]
Got:
[[x == 1/4*pi + pi*z39, y == -1/4*pi - pi*z39]]
-%<-
I reported the clisp problem upstream; last response:
https://sourceforge.net/mailarchive/forum.php?thread_name=4B8D57D2.4080002%40gnu.org&forum_name=clisp-devel
but the tests work with other lisp backends (only did not yet test gcl
from the available backends in Mandriva package)
Paulo
--
To post to this group, send
Re: [sage-devel] Re: Question about pickle in python
Em 3 de fevereiro de 2010 19:00, Paulo César Pereira de Andrade escreveu: > On Jan 13, 8:08 am, François Bissey wrote: >> On Wed, 13 Jan 2010 22:35:16 Craig Citro wrote: >> >> > > If you work on getting this merged upstream as a bug that's a good >> > > selling point for us. We can produce a patched ebuild and possibly >> > > get it accepted. >> > > Do you have a bug tracking number of some kind for it? >> >> > I just submitted the bug: >> >> >http://bugs.python.org/issue7689 >> >> > I'll let you know as I hear anything. (I know one of the corePython >> > devs has a standing offer that he'll review a patch if you review 5 of >> > his; if I don't hear anything in a week or so, I'll just bite the >> > bullet and get this reviewed that way.) >> >> > -cc >> >> That's quite good already I can open a bug in Gentoo, quote that >> bug and put a patched ebuild in the sage-on-gentoo overlay. >> There are more chances of it being included in the main tree if there is a >> bug >> upstream and a need for it in Gentoo. > > Hi, > > Sorry for pestering :-) > > What is the current state of this problem? > > Any chances this will get accepted by upstream? (Currently I need > that to patch > Mandriva's python package). This information may be useful. I "hacked" my sagemath build, basically a search&replace, to use a pickle.py with the sagemath patch, instead of cPickle, But now I have lots of doctest failures in the format: TypeError: sage.structure.sage_object.SageObject.__new__(Sequence) is not safe, use list.__new__() (I may burn some karma later (if any remaining :-) to get the python patch in the mandriva python, but not sure if worth it, as there should not exist too many users of cooker+sagemath, or users that would be affected by this...) Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Question about pickle in python
On Jan 13, 8:08 am, François Bissey wrote: > On Wed, 13 Jan 2010 22:35:16 Craig Citro wrote: > > > > If you work on getting this merged upstream as a bug that's a good > > > selling point for us. We can produce a patched ebuild and possibly > > > get it accepted. > > > Do you have a bug tracking number of some kind for it? > > > I just submitted the bug: > > >http://bugs.python.org/issue7689 > > > I'll let you know as I hear anything. (I know one of the corePython > > devs has a standing offer that he'll review a patch if you review 5 of > > his; if I don't hear anything in a week or so, I'll just bite the > > bullet and get this reviewed that way.) > > > -cc > > That's quite good already I can open a bug in Gentoo, quote that > bug and put a patched ebuild in the sage-on-gentoo overlay. > There are more chances of it being included in the main tree if there is a bug > upstream and a need for it in Gentoo. Hi, Sorry for pestering :-) What is the current state of this problem? Any chances this will get accepted by upstream? (Currently I need that to patch Mandriva's python package). > Thanks, > Francois Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: gcc 4.4.3, linbox 1.1.{6,7}, givaro 3.{2,3}
2010/1/28 Paulo César Pereira de Andrade : > Hi, > > I am trying to update my Mandriva package of sagemath to 4.3.1, but > I am having serious issues with givaro/linbox. Please forgive my previous message. I found out what is the problem. The reason is because I am also working on getting as much as possible libraries linked with -Wl,--as-needed -Wl,--no-undefined, and liblinboxsage.so was corrected with: liblinboxsage_la_LIBADD = $(top_builddir)/linbox/util/libutil.la $(top_builddir)/linbox/randiter/libranditer.la Thanks, Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] gcc 4.4.3, linbox 1.1.{6,7}, givaro 3.{2,3}
Hi,
I am trying to update my Mandriva package of sagemath to 4.3.1, but
I am having serious issues with givaro/linbox.
For some reason, only --enable-sage appears to break linbox, but,
for some reason, with gcc 4.4.3 (the one in
Mandriva cooker), it will not build liblinboxsage.so.
I tried:
o linbox 1.1.6 + givaro 3.2.13, matching sagemath spkgs
o linbox 1.1.6 + givaro 3.3.1
o linbox 1.1.7 + givaro 3.3.1
o todays linbox svn + givaro 3.3.1
sagemath interface to givaro should work correctly with a small patch
for the "minor" changes, e.g. s/amxy/maxpy/,
but no matter what, I am getting several missing symbols.
I am somewhat lost as I am not experienced with C++ templates, but
after making several changes last night
to get linbox 1.1.6 to work with givaro 3.3.1, I ended up with the
same errors I get with linbox 1.1.7 and svn linbox
plus givaro 3.3.1. I stopped last night when I needed:
--- linbox-1.1.6/linbox/util/timer.C.orig 2010-01-27 21:50:11.042264712
-0200
+++ linbox-1.1.6/linbox/util/timer.C2010-01-27 21:51:40.641339799 -0200
@@ -28,14 +28,6 @@ extern "C" {
namespace LinBox
{
-// Return a value to initialize random generator
-long BaseTimer::seed()
-{
- struct timeval tp;
- gettimeofday(&tp, 0) ;
- return(tp.tv_usec);
-}
-
// Output the value of the timer :
std::ostream& BaseTimer::print( std::ostream& o ) const
{ return o << _t ; }
--- linbox-1.1.6/linbox/util/timer.h.orig 2010-01-27 21:49:54.870263887
-0200
+++ linbox-1.1.6/linbox/util/timer.h2010-01-27 21:51:33.168404026 -0200
@@ -20,6 +20,10 @@
#ifndef __LINBOX_TIMER_H
#define __LINBOX_TIMER_H
+extern "C" {
+# include
+}
+
#include
namespace LinBox
@@ -44,7 +48,11 @@ class BaseTimer {
inline double time() const { return _t; }
// -- Return a value to initialize random generator
- static long seed();
+ static long seed() {
+ struct timeval tp;
+ gettimeofday(&tp, 0) ;
+ return(tp.tv_usec);
+ }
// -- basic methods:
std::ostream &print (std::ostream &) const;
-%<-
to not get an unresolved symbol for LinBox::BaseTimer::seed(), but, not using
this patch for linbox newer than 1.1.6, that is exactly the first error:
...
g++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -I. -I../../linbox -O2
-DDISABLE_COMMENTATOR -O2 -g -pipe -Wformat -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
-I/home/pcpa/mandriva/svn/linalg-linbox/BUILD/linbox-1.1.6
-I/home/pcpa/mandriva/svn/linalg-linbox/BUILD/linbox-1.1.6/linbox -c
linbox-sage.C -fPIC -DPIC -o .libs/linbox-sage.o
/bin/sh ../../libtool --tag=CXX --mode=link g++ -O2
-DDISABLE_COMMENTATOR -O2 -g -pipe -Wformat
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector
--param=ssp-buffer-size=4
-I/home/pcpa/mandriva/svn/linalg-linbox/BUILD/linbox-1.1.6
-I/home/pcpa/mandriva/svn/linalg-linbox/BUILD/linbox-1.1.6/linbox
-lgivaro -lgmpxx -lgmp -lntl -L/usr/lib64 -lblas -version-info
0:0:0 -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -o
liblinboxsage.la -rpath /usr/lib64 linbox-sage.lo -L/usr/lib64
-lblas -lgmpxx -lgmp -lgivaro
g++ -shared -nostdlib
/usr/lib/gcc/x86_64-manbo-linux-gnu/4.4.3/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-manbo-linux-gnu/4.4.3/crtbeginS.o
.libs/linbox-sage.o -Wl,--as-needed -Wl,--no-undefined -Wl,-z
-Wl,relro -Wl,-O1 -lntl -L/usr/lib64 -lblas /usr/lib64/libgmpxx.so
/usr/lib64/libgmp.so /usr/lib64/libgivaro.so
-L/usr/lib/gcc/x86_64-manbo-linux-gnu/4.4.3
-L/usr/lib/gcc/x86_64-manbo-linux-gnu/4.4.3/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-manbo-linux-gnu/4.4.3/../../.. -lstdc++ -lm -lc
-lgcc_s /usr/lib/gcc/x86_64-manbo-linux-gnu/4.4.3/crtendS.o
/usr/lib/gcc/x86_64-manbo-linux-gnu/4.4.3/../../../../lib64/crtn.o
-Wl,-soname -Wl,liblinboxsage.so.0 -o .libs/liblinboxsage.so.0.0.0
.libs/linbox-sage.o: In function `RandomPrimeIterator':
/home/pcpa/mandriva/svn/linalg-linbox/BUILD/linbox-1.1.6/interfaces/sage/../../linbox/randiter/random-prime.h:24:
undefined reference to `LinBox::BaseTimer::seed()'
.libs/linbox-sage.o: In function `MultiModRandomPrime':
/home/pcpa/mandriva/svn/linalg-linbox/BUILD/linbox-1.1.6/interfaces/sage/../../linbox/randiter/multimod-randomprime.h:39:
undefined reference to `LinBox::BaseTimer::seed()'
.libs/linbox-sage.o: In function
`LinBox::Timer::operator+=(LinBox::Timer const&)':
...
Sorry for the long email.
Any ideias of how to get this to work, with any linbox version,
preferably givaro 3.3.1 as someone already
updated mandriva package..., and gcc 4.4.3 is welcome.
Thanks,
Paulo
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: Linking libraries - do we need a completely different approach ?
2009/12/17 François Bissey : > On Fri, 18 Dec 2009 09:42:40 Paulo César Pereira de Andrade wrote: >> You may want to check the sagemath package in Mandriva cooker, and >> its dependencies. >> >> Mandriva 2010.0 has a contrib sagemath 4.1.1 package that required a hack >> tough, that is LD_PRELOAD of libpolibori and libntl or it would crash in >> some doctests, it appears to be a clash of some global C++ symbols, or >> just some other kind of name clash, but the current cooker sage 4.2.1 >> doesn't need it. >> >> Almost everything uses system packages, save a few python packages. >> For packages that were not in Mandriva, I used sage spkg or upstream >> "older" tarball with sage patches. >> >> > The point is - in my experience working with a certain number of system >> > provided packages - apart from python - usually works well in practice >> > possibly with some adjustment to sage-env. >> >> The packages I built don't even install sage-env, but sage scripts are >> patched to not rely on it.. The "main" sage script just sets SAGE_ROOT, >> SAGE_LOCAL, DOT_SAGE, etc, and there are some symlinks, example: >> $ ls -l /usr/share/sage/local >> total 8 >> drwxr-xr-x 2 root root 4096 2009-12-03 03:06 bin/ >> drwxr-xr-x 3 root root 4096 2009-11-30 19:42 dsage/ >> lrwxrwxrwx 1 root root 23 2009-12-03 03:06 include -> >> ../../../../usr/include/ lrwxrwxrwx 1 root root 19 2009-12-03 03:06 lib >> -> ../../../../usr/lib/ lrwxrwxrwx 1 root root 21 2009-12-03 03:06 share >> -> ../../../../usr/share/ >> >> > Of course checking whether you can use a system package rather than >> > the sage provided one is a big complication, which would get lots of -1 >> > if suggested. But it is nice to know that it is actually doable. >> >> There are plenty of doctests failures, but as long as the results are >> actually correct, this should be more of a reviewing exercise :-) >> >> If gentoo already have latest upstream of some "binary" packages, that >> sage requires an older one, things may be harder to work, but so far, I >> did only need to use some alternate pytyhon packages and add >> export PYTHONPATH="/usr/share/sage/site-packages" to /usr/bin/sage >> in Mandriva. >> >> You will also have the "usual" issues with upgrades of system libraries, >> that would require rebuilding the sage package. But this should be >> uncommon, and when required, the full sagemath rpm (for example) is 20-40 >> Mb. >> > Thanks for the pointer to your work. As you probably know in Gentoo the user > build everything from source, so it is almost just a question of substituting > the sage build system with Gentoo's. > We can require explicit version of software and directly fetch spkg for > building although older software can be problematic. The PYTHONPATH trick > actually had some problems. Christopher who currently do most of the heavy > lifting thinks it is something related to cython but we are working on that. I used exclusively FreeBSD ports for many years, so I understand the procedure to some extent :-) I tried to make minimal changes to the sage build, so, there is some "magic" with symlinks and setting environment variables in the rpm spec. As long as dynamic libraries are properly versioned, it should not be a major issue, but relinking may be tricky to force to link with the older library, and unfortunately, there isn't either versioning, or consistent versioning of several libraries required by sage. The PYTHONPATH trick is only required because there may be a newer python-networkx, python-pyexpect, etc installed. > William is right in that it is a port and I was working with Tim Abbott when > he was around which make guilty of introducing gnu/linuxism along with him. > We probably should revive debian-sage a little and have a few serious porting > discussion over there. Anything that David think would be a good thing > is a good thing for us as well in the long run. We can adjust the gnu-ism on > our side of the fence. In the long run it should be better to have sage integrated in distros; imagine if every package had its own version of libraries like libm, X11 ones, qt, gtk, etc... I was not around when debian-sage was active, I knew about sage when there was a slashdot post about it, and only started packaging it one+ year later, was in my "todo" list, but if there is discussion about it, please let me know :-) > Francois > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Linking libraries - do we need a completely different approach ?
2009/12/17 François Bissey : > On Thu, 17 Dec 2009 16:45:36 Dr. David Kirkby wrote: >> This is not simply a run-time issue, as the conflicts are causing a failure >> of Sage to build on OpenSolaris. >> >> http://trac.sagemath.org/sage_trac/ticket/7387 >> >> I'm not convinced renaming the libraries would solve it - as you say, it >> might introduce other problems. In fact, I'd take a guess it would be >> highly likely to introduce other problems. >> > I had forgotten this little pearl of yours with gnutls. For what its worth > with the port of sage to Gentoo we rely on system provided packages > as much as possible - in fact the goal is to build sage on Gentoo > bypassing completely the usual sage building process. > So far we have removed almost everything that isn't python related and > it seems to mostly work. Of course some stuff doesn't work/isn't expected > to work like sage -br or sage -upgrade. But if you want to use those you > probably don't want to use a version of sage packaged for your distro. You may want to check the sagemath package in Mandriva cooker, and its dependencies. Mandriva 2010.0 has a contrib sagemath 4.1.1 package that required a hack tough, that is LD_PRELOAD of libpolibori and libntl or it would crash in some doctests, it appears to be a clash of some global C++ symbols, or just some other kind of name clash, but the current cooker sage 4.2.1 doesn't need it. Almost everything uses system packages, save a few python packages. For packages that were not in Mandriva, I used sage spkg or upstream "older" tarball with sage patches. > The point is - in my experience working with a certain number of system > provided packages - apart from python - usually works well in practice > possibly with some adjustment to sage-env. The packages I built don't even install sage-env, but sage scripts are patched to not rely on it.. The "main" sage script just sets SAGE_ROOT, SAGE_LOCAL, DOT_SAGE, etc, and there are some symlinks, example: $ ls -l /usr/share/sage/local total 8 drwxr-xr-x 2 root root 4096 2009-12-03 03:06 bin/ drwxr-xr-x 3 root root 4096 2009-11-30 19:42 dsage/ lrwxrwxrwx 1 root root 23 2009-12-03 03:06 include -> ../../../../usr/include/ lrwxrwxrwx 1 root root 19 2009-12-03 03:06 lib -> ../../../../usr/lib/ lrwxrwxrwx 1 root root 21 2009-12-03 03:06 share -> ../../../../usr/share/ > Of course checking whether you can use a system package rather than > the sage provided one is a big complication, which would get lots of -1 > if suggested. But it is nice to know that it is actually doable. There are plenty of doctests failures, but as long as the results are actually correct, this should be more of a reviewing exercise :-) If gentoo already have latest upstream of some "binary" packages, that sage requires an older one, things may be harder to work, but so far, I did only need to use some alternate pytyhon packages and add export PYTHONPATH="/usr/share/sage/site-packages" to /usr/bin/sage in Mandriva. You will also have the "usual" issues with upgrades of system libraries, that would require rebuilding the sage package. But this should be uncommon, and when required, the full sagemath rpm (for example) is 20-40 Mb. > Francois Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: the creeping library collision problem...
2009/11/18 Georg S. Weber :
> Hi,
>
> this is circle of questions coming up every now and then, I try to
> give a complete yet not too long answer.
>
> The Sage community is limited in resources, and for the time being,
> the focus is set e.g. to further broaden the number of systems that
> are supported. Solaris and BSD are on a good way, but not completely
> done yet AFAIK, considerable efforts are spent on Cygwin, and native
> support for Windows (both in 32bit and 64bit mode) is envisaged.
>
> Given this and other arguments, a clear and precise design decision
> has been made --- there is one and only one Sage distribution which
> includes "almost everything", but which (builds and) runs on a large
> variety of systems at one and the same time, with as few system-
> dependent deviations as possible (for easy maintainability).
>
> This design decision allows for some comfort, e.g. you can move around
> the whole Sage tree, and upon startup, some internal hardcoded paths
> have to be adjusted once, but then it runs fine. Or else, you could
> install Sage-2.9 (say) and Sage-4.2 at the same time (in different
> directories of course), although these two version of Sage might
> depend on different (even incompatible) libraries/progams resp.
> versions of libraries/programs (to be found under the respective
> SAGE_ROOT/local/lib/ and SAGE_ROOT/local/bin/ directories). Another
> benefit is the possibility to distribute precompiled binary
> distributions of Sage (that can be more or less just copied to some
> directory of the users choice).
>
> That said, there should be no need to "rip out some libraries", and
> there should not be collisions. Everything is supposed to live happily
> side-by-side. If problems happen (and they do), usually some
> environment settings are messed up --- or it is a bug in Sage.
>
> Of course there dreams of providing version of Sage that are simply
> "apt-gettable" into current Debian/Ubuntu installs, to have Sage-
> x.y.z.rpm's for Fedora, and so on (I remember some recent work for
> Mandriva in that direction). But currently, simply the manpower lacks
> to do the necessary building and testing (resp. the possibly available
> forces are occupied with tasks that at the moment are considered to be
> more important).
Mandriva release 2010.0 recently, and now I am working on newer
sagemath packages for cooker.
I understand that packaging sage spkgs in some distros may have
too much obstacles, because most patches are sage specific or not
forwarded/merged upstream. Or just because sage uses an older version,
again, the problem of lack of manpower.
From my experience (now running "native" Mandriva cooker sage 4.2),
the major problem is doctest failures, mostly not really a problem,
for example:
File "/usr/share/sage/devel/doc/common/builder.py", line 158:
sage: b._output_dir('html')
Expected:
'.../devel/sage/doc/output/html/en/tutorial'
Got:
'/usr/share/sage/devel/doc/output/html/en/tutorial'
...
File "/usr/share/sage/devel/doc/en/constructions/graph_theory.rst", line 19:
sage: C = graphs.CubeGraph(4)
Expected nothing
Got:
doctest:16: DeprecationWarning: the sets module is deprecated
...
File "/usr/share/sage/devel/doc/en/constructions/polynomials.rst", line 45:
sage: print gap.eval("R:= PolynomialRing( GF(97))")
Expected:
PolynomialRing(..., [ x_1 ])
Got:
GF(97)[x_1]
...
and so on.
The major benefit is probably load time as there is no change to
LD_LIBRARY_PATH, etc. Example:
% echo quit | sage
--
| Sage Version 4.2, Release Date: 2009-10-24 |
| Type notebook() for the GUI, and license() for information.|
--
sage: Exiting SAGE (CPU time 0m0.03s, Wall time 0m0.03s).
and binary (for Mandriva 2009.1) sage:
% cd ~/sage-4.2
% echo quit | ./sage
--
| Sage Version 4.2, Release Date: 2009-10-24 |
| Type notebook() for the GUI, and license() for information.|
--
sage: Exiting SAGE (CPU time 0m0.10s, Wall time 0m0.11s).
> Help is always welcome, and be it in the form of a precise bug report
> --- what kind of problem do you have with gnutls?
>
> Cheers,
> Georg
>
> P.S.:
> William et.al., please feel free to correct me ...
Paulo
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: silly license question
2009/10/1 William Stein : > > On Thu, Oct 1, 2009 at 11:53 AM, David Harvey wrote: >> >> I am confused. I want to release bernmm 1.1 under the (modified) BSD >> license. It depends on NTL, which is GPL-licensed. Can I do this? > > Yes, definitely. > >> Or am I forced to release bernmm under GPL? > > Definitely not. > > If you are going to distribute your program (which you are), then you > must release it under a GPL-compatible license. The (modified) BSD > license is GPL-compatible. Thus you can release it under the BSD > license. > > From the FAQ David just pointed to: "you must release your program > under a license compatible with the GPL (more precisely, compatible > with one or more GPL versions accepted by all the rest of the code in > the combination that you link)." > > Just for comparison, if you were forced to release bernmm under GPL, > then I would similarly be forced to get every BSD'd component of Sage > to be relicensed under the GPL in order to include them in Sage. > > William A long time ago I asked fsf themselves about a similar question :-) They were very kind and pointed me to this: http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html [I wanted to add GPL code to components of a MIT licensed project, but it did not go far, and to avoid problems, I just ignored the license issue and used standard MIT] Paulo --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: "sage -sh" question and possible patch
2009/9/25 Minh Nguyen :
>
> Hi Mariah,
>
> On Sat, Sep 26, 2009 at 6:04 AM, Mariah Lenox wrote:
>>
>> The open trac tickets #4644 and #5507 discuss
>> problems with "sage -sh", specifically
>>
>> #4644 - No new prompt when doing a ./sage -sh
>
> I can confirm that your patch fixes this issue:
>
> {{{
> [mv...@sage sage-4.1.1]$ ./sage -sh
>
> Starting subshell with Sage environment variables set.
> Be sure to exit when you are done and do not do anything
> with other copies of Sage!
>
> Bypassing shell configuration files ...
>
> sage$ exit
> exit
> Exited Sage subshell.
> }}}
>
>
>> #5507 - $ sage -sh -c "echo hi there" # does not work, but should
>
> It also fixes this one as well:
>
> {{{
> [mv...@sage sage-4.1.1]$ ./sage -sh -c "echo hi there"
>
> Starting subshell with Sage environment variables set.
> Be sure to exit when you are done and do not do anything
> with other copies of Sage!
>
> Bypassing shell configuration files ...
>
> hi there
> Exited Sage subshell.
> }}}
>
>
>
>> $ sage -sh -c -c "echo hi there" # works, but shouldn't
>
> This one still works:
>
> {{{
> [mv...@sage sage-4.1.1]$ ./sage -sh -c -c "echo hi there"
>
> Starting subshell with Sage environment variables set.
> Be sure to exit when you are done and do not do anything
> with other copies of Sage!
>
> Bypassing shell configuration files ...
>
> hi there
> Exited Sage subshell.
> }}}
>
>
>
>> There is also a problem that "sage -sh" may pick up the user's
>> $PATH rather than the one defined in sage-env (which
>> is how I got into this issue).
>
> With the patch, the user's $PATH is picked up, but variables in
> sage-env are prepended to it:
>
> {{{
> [mv...@sage sage-4.1.1]$ echo $PATH
> /home/mvngu/usr:/home/mvngu/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
> [mv...@sage sage-4.1.1]$
> [mv...@sage sage-4.1.1]$ ./sage -sh
>
> Starting subshell with Sage environment variables set.
> Be sure to exit when you are done and do not do anything
> with other copies of Sage!
>
> Bypassing shell configuration files ...
>
> sage$ echo $PATH
> /scratch/mvngu/build/sage-4.1.1:/scratch/mvngu/build/sage-4.1.1/local/bin:/home/mvngu/usr:/home/mvngu/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
> sage$ exit
> exit
> Exited Sage subshell.
> }}}
>
>
>> The patch below fixes these three problems - but it may
>> not be what developers want. Specifically, it will set the
>> prompt to be "sage $" for all shells (with the exception of
>> csh which does not have a prompt environment variable and
>> so the prompt gets set to "%"). Note that with the patch
>> the prompt is NOT listing the current directory.
>>
>> Do developers prefer that a sage-sub-shell prompt list
>> the current directory?
>
> Yes, that would be nice.
>
> --
> Regards
> Minh Van Nguyen
Possibly a bit out of context. But I was hit by "sage -sh"
yesterday. I run "./sage -sh" to make some tests, and gone do other
duties in the meantime. Then, I forgot I was under a sage 4.1.1 shell
in that xterm, and things started working incorrectly.
Curiously, I had been debugging a problem with
java-1.6-openjdk-plugin and java-1.6-sun-plugin, where only the sun
plugin works in my Mandriva setup, when loading the jmol plugin. (I
was testing/comparing both, the mandriva rpm package, and sage-4.1.1
binary downloaded from a sagemath mirror).
Then, after playing with install/uninstall of several packages, I
ended up in a state where firefox would always refuse to start, and
the reason was LD_LIBRARY_PATH, because I was starting firefox from
the xterm that was running "sage -sh".
Paulo
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Mandriva
2009/9/24 Robert Bradshaw : > > On Sep 24, 2009, at 12:34 PM, William Stein wrote: > >> Hi, >> >> Harald pointed out Sage getting into Mandriva is featured in their >> release notes. In fact, it's >> a big part of them. Here they are: >> >> "Mandriva Linux 2010 includes (or will include) the following versions >> of the major distribution components: kernel 2.6.31 (estimation), >> X.org 7.5 (with xorg-server 1.7.0 (very rough estimation) or 1.6.2+), >> KDE 4.3.x, GNOME 2.28, GCC 4.4.x, Glibc 2.10.1 or 2.10.2+ and >> OpenOffice.org 3.1 (based on the Go-OO branch). The Release Tour >> contains more information on new features and changes in the new >> versions of these and other components. >> >> Mandriva Linux 2010 will also include sagemath version 4.1, as well as >> several of its dependencies, including software like gap, singular, >> polymake, linbox, and many other scientific applications. " >> >> http://wiki.mandriva.com/en/2010.0_Notes >> >> That's pretty cool. > > Excellent. Does anyone know if they're shipping this as a monolithic > package, or is it broken up into all its pieces (à la Sage debian)? It is split to use system packages. The rpm sources can be viewed at http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/sagemath/current/ > - Robert Paulo --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage notebook project: status report
2009/9/22 William Stein :
>
> Hi,
>
> I was able to create a limited functionality separated sage notebook so far:
>
> http://sage.math.washington.edu/home/wstein/patches/sagenb/
>
> One key thing I did was abstract out how the worksheets communicate
> with another python process. I then did a reference implementation of
> the API. So the above tarball implements a Sage notebook server in it
> that doesn't use pexpect or sage interfaces at all --- it just uses
> the reference api which does computations in the server (so will lock
> during computations).
>
> The above tarball contains its own .hg repo, all the javascript
> libraries, templates, etc., that used to be scattered between the sage
> library and data/extcode/notebook, etc.
>
> People who want to help with the notebook will be able to just grab
> this tarball, change anything, and make a patch that they can share.
>
> Anyway, the next step is to make a 100% functional separated sage
> notebook, so it can very quickly replace the one currently in sage.
I just made a test, to also check how well the Mandriva rpm package
would deal with it :-)
The procedure was:
% cd ~/Download
% wget
http://sage.math.washington.edu/home/wstein/patches/sagenb/sagenb-0.1.6.tar.gz
% tar zxf sagenb-0.1.6.tar.gz
% cd sagenb-0.1.6
<>
% sudo sage -python setup.py install
<>
-%<-
diff -ru sagenb/misc/misc.py
/usr/lib/python2.6/site-packages/sagenb/misc/misc.py
--- sagenb/misc/misc.py 2009-09-22 17:17:54.0 -0300
+++ /usr/lib/python2.6/site-packages/sagenb/misc/misc.py2009-09-23
19:55:40.0 -0300
@@ -157,7 +157,7 @@
return "0"*(size-len(str(s))) + str(s)
-DATA = os.path.join(sys.prefix, 'lib', 'python', 'site-packages',
'sagenb', 'data')
+DATA = os.path.join(sys.prefix, 'lib', 'python2.6', 'site-packages',
'sagenb', 'data')
if os.environ.has_key('DOT_SAGENB'):
DOT_SAGENB = os.environ['DOT_SAGENB']
diff -ru sagenb/notebook/notebook.py
/usr/lib/python2.6/site-packages/sagenb/notebook/notebook.py
--- sagenb/notebook/notebook.py 2009-09-23 19:44:22.0 -0300
+++ /usr/lib/python2.6/site-packages/sagenb/notebook/notebook.py
2009-09-23
19:49:06.0 -0300
@@ -53,7 +53,7 @@
JSMATH = True
-JSMATH_IMAGE_FONTS = is_package_installed("jsmath-image-fonts")
+JSMATH_IMAGE_FONTS = True # is_package_installed("jsmath-image-fonts")
JEDITABLE_TINYMCE = True
-%<-
% sage
sage: import sagenb.notebook.notebook_object as nb; nb.notebook()
After the small patch, it appears to work correctly.
I need to make a reliable package.py patch, currently there is just
some patching to not call it package routines, and rely on rpm having
installed all dependencies...
The python symlink does not exist in Mandriva, so I needed to
explicitly set the path there.
Actually, one of my rpm patches is like:
-%<-
+ import distutils.sysconfig
[...]
-SITE_PACKAGES = '%s/lib/python/site-packages/'%SAGE_LOCAL
+SITE_PACKAGES = distutils.sysconfig.get_python_lib(plat_specific=1)
-%<-
> --
> William Stein
> Associate Professor of Mathematics
> University of Washington
> http://wstein.org
Paulo
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Problem with different maxima versions
2009/9/16 Minh Nguyen : > > On Wed, Sep 16, 2009 at 10:52 AM, Jason Grout > wrote: > > > >> I think networkx 0.99 will require some nontrivial work in Sage, since >> they changed a lot of things. I forgot to say about another package, but at least for now, they don't "cascade" on several other doctest failures, so I am keeping sage using the distro cvxopt for now: sage -t "devel/doc/en/numerical_sage/cvxopt.rst" ESC[?1034h** File "/usr/share/sage/devel/doc/en/numerical_sage/cvxopt.rst", line 57: sage: print(A) Expected: SIZE: (5,5) (0, 0) 2.e+00 (1, 0) 3.e+00 (0, 1) 3.e+00 (2, 1) -1.e+00 (4, 1) 4.e+00 (1, 2) 4.e+00 (2, 2) -3.e+00 (3, 2) 1.e+00 (4, 2) 2.e+00 (2, 3) 2.e+00 (1, 4) 6.e+00 (4, 4) 1.e+00 Got: [ 2.00e+00 3.00e+00 0 0 0] [ 3.00e+00 0 4.00e+00 0 6.00e+00] [0 -1.00e+00 -3.00e+00 2.00e+00 0] [0 0 1.00e+00 0 0] [0 4.00e+00 2.00e+00 0 1.00e+00] ** File "/usr/share/sage/devel/doc/en/numerical_sage/cvxopt.rst", line 73: sage: print(C) Expected: 5.7895e-01 -5.2632e-02 1.e+00 1.9737e+00 -7.8947e-01 Got: [ 5.79e-01] [-5.26e-02] [ 1.00e+00] [ 1.97e+00] [-7.89e-01] ** File "/usr/share/sage/devel/doc/en/numerical_sage/cvxopt.rst", line 97: sage: print(P) Expected: 1 0 2 3 Got: [ 1] [ 0] [ 2] [ 3] ** > NetworkX 1.0 should be out soon under the BSD license. Previous > versions were under LGPL. > > -- > Regards > Minh Van Nguyen Paulo --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Problem with different maxima versions
2009/9/15 Jason Grout : >> sage -t "devel/sage/sage/matrix/constructor.py" >> ** >> File "/usr/share/sage/devel/sage/sage/matrix/constructor.py", line 155: >> sage: g = graphs.PetersenGraph() >> Expected nothing >> Got: >> doctest:16: DeprecationWarning: the sets module is deprecated >> doctest:18: DeprecationWarning: >> ** >> matplotlib.numerix and all its subpackages are deprecated. >> They will be removed soon. Please use numpy instead. >> ** >> >> ** >> 1 items had failures: >> 1 of 94 in __main__.example_1 >> ***Test Failed*** 1 failures. >> ... >> > > The numerix issue should be fixed in #5448, IIRC. Thanks again!! I used the patch in the spkg at http://trac.sagemath.org/sage_trac/ticket/5448#comment:37 and that cleaned up most of the remaining noise in "sage -testall" I am using sage's networkx spkg, because, as expected, upstream networkx 0.99 doesn't work correctly with sage, and is the package in the standard distro. So far, the only python-* packages that I use from sage are pexepect, networkx and sqlachemy. (sqlalchemy afaik only required for dsage, to pass all it's tests). > -- > Jason Grout Paulo --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Problem with different maxima versions
2009/9/15 kcrisman : > >> > As for you for now, you'd need to change the eigenvectors() command in >> > the matrix code. If you wanted to do so and submit a patch, it would be >> > greatly appreciated! >> > > But all doctests pass for me in alpha1: > > ./sage -t "devel/sage/sage/matrix/" > All tests passed! > Total time for all tests: 177.1 seconds I get slightly different results, with two known (hopefully :-) "minor" problems: % sage -t "devel/sage/sage/matrix/" ... sage -t "devel/sage/sage/matrix/matrix_double_dense.pyx" ** File "/usr/share/sage/devel/sage/sage/matrix/matrix_double_dense.pyx", line 996: sage: V Expected: [-0.392540507864 0.824163383692 0.408248290464] [-0.560772154092 0.137360563949 -0.816496580928] [ -0.72900380032 -0.549442255795 0.408248290464] Got: [-0.392540507864 0.824163383692 -0.408248290464] [-0.560772154092 0.137360563949 0.816496580928] [ -0.72900380032 -0.549442255795 -0.408248290464] ** 1 items had failures: 1 of 27 in __main__.example_28 ***Test Failed*** 1 failures. ... sage -t "devel/sage/sage/matrix/constructor.py" ** File "/usr/share/sage/devel/sage/sage/matrix/constructor.py", line 155: sage: g = graphs.PetersenGraph() Expected nothing Got: doctest:16: DeprecationWarning: the sets module is deprecated doctest:18: DeprecationWarning: ** matplotlib.numerix and all its subpackages are deprecated. They will be removed soon. Please use numpy instead. ** ** 1 items had failures: 1 of 94 in __main__.example_1 ***Test Failed*** 1 failures. ... >> maxima-5.19.1 can be found in Sage sage-4.1.2.alpha1, but being an >> alpha, it is likely to be less stable than a 'stable' release of Sage. >> Note Sage 4.1.2 will be the first Sage to have a recent update of >> Maxima. The previous version, 4.1.1, does not. > > That's #6699 where the change went in. Note that the patch there > fixes similar eigenvector problems in doc/en/constructions/ > linear_algebra.rst and doc/en/tutorial/interfaces.rst, and, for that > matter, sage/interfaces/maxima.py Many Thanks!! I just made a local build with http://trac.sagemath.org/sage_trac/attachment/ticket/6699/maxima_doctests.patch applied, and now the maxima tutorial works correctly. > But actually, the problem is already in 4.1.1, with the previous > Maxima: > > -- > | Sage Version 4.1.1, Release Date: 2009-08-14 | > | Type notebook() for the GUI, and license() for information. | > -- > sage: A = matrix(SR, [[1,2,3],[4,5,6],[7,8,9]]) > sage: A.eigenvectors_right() > UserWarning: Using generic algorithm for an inexact ring, which may > result in garbage from numerical precision issues. > # -*- coding: utf-8 -*- > UserWarning: Using generic algorithm for an inexact ring, which will > probably give incorrect results due to numerical precision issues. > # -*- coding: utf-8 -*- > TypeError: degree() takes exactly one argument (0 given) > sage: maxima_console() > Maxima 5.16.3 http://maxima.sourceforge.net > > For some reason SR eigenvectors were never actually tested, I think - > because they inherit directly from matrix2.pyx! In fact, the error > comes from eigenspaces_left in that file, where G = self.fcp() calls > degree of a symbolic expression, which now requires an argument ! The > symbolic upgrade strikes again... I'll try to have a patch for this > soon. > > - kcrisman Paulo --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Problem with different maxima versions
2009/9/14 Jason Grout : > > Paulo César Pereira de Andrade wrote: >> Hi, >> >> In maxima-5.16.3.p2 as distributed with sage 4.1.1 when doing the >> maxima tutorial, all goes well, but in my rpm, due to using system's >> maxima-5.19.1-2mdv2010.0 I get an error because when reaching the >> cell: >> >> A.eigenvectors() >> >> maxima 5.16.3 returns: >> [[[0,4],[3,1]],[1,0,0,-4],[0,1,0,-2],[0,0,1,-4/3],[1,2,3,4]] >> >> while maxima 5.19.1 returns: >> [[[0,4],[3,1]],[[[1,0,0,-4],[0,1,0,-2],[0,0,1,-4/3]],[[1,2,3,4 >> >> and then, in the next cell it gives a fatal error due to not being >> able to convert a list to rational. >> >> Do you have any idea as to what would be the proper way to correct >> this issue? Preferably without needing to use an older maxima for the >> sage package :-) > > This change was actually motived by a request from the Sage project :). > As such, I'm sure it will be supported in Sage as soon as Sage > upgrades to the newer version of maxima. Many thanks for the fast reply! > As for you for now, you'd need to change the eigenvectors() command in > the matrix code. If you wanted to do so and submit a patch, it would be > greatly appreciated! Hmm, with my limited python knowledge I don't think it is doable :-) I can't find myself in sage/matrix code, and I fear those .pyx/.pxd files... I think I will just point to this email if I receive bug reports about this problem, and leave as is for now, as packaging a full alternate maxima in the sagemath package is overkill... > Thanks, > > Jason > > > > -- > Jason Grout Thanks, Paulo --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Problem with different maxima versions
Hi, In maxima-5.16.3.p2 as distributed with sage 4.1.1 when doing the maxima tutorial, all goes well, but in my rpm, due to using system's maxima-5.19.1-2mdv2010.0 I get an error because when reaching the cell: A.eigenvectors() maxima 5.16.3 returns: [[[0,4],[3,1]],[1,0,0,-4],[0,1,0,-2],[0,0,1,-4/3],[1,2,3,4]] while maxima 5.19.1 returns: [[[0,4],[3,1]],[[[1,0,0,-4],[0,1,0,-2],[0,0,1,-4/3]],[[1,2,3,4 and then, in the next cell it gives a fatal error due to not being able to convert a list to rational. Do you have any idea as to what would be the proper way to correct this issue? Preferably without needing to use an older maxima for the sage package :-) [ I understand this is my problem due to not "always" using the sage spkgs, but I think this is also useful information for sage, and it should at least help others in watching what not to do when adding sagemath to theirs distro... ] When using maxima-5.16.3, as in, cat ~/bin/maxima: #!/bin/sh cd /home/pcpa/sage-4.1.1/local/bin LD_LIBRARY_PATH=/home/pcpa/sage-4.1.1/local/lib:$LD_LIBRARY_PATH ./maxima "$@" and putting $HOME/bin as the first $PATH entry, it works with my rpm package. Thanks, Paulo --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: chapeau for sage's Integer()
2009/9/10 Bill Hart :
>
> This program only takes 0.68s in C using a pretty naive mpz program on
> sage.math. I doubt the memory allocation is really relevant. The
> interpreter overhead is by far the greatest component
>
> Bill.
>
> On 9 Sep, 17:57, Nils Bruin wrote:
>> Inspired by a little experiment we did to see if there is room to
>> improve to ECL's bignum performance, we ran a little experiment
>> computing fibonacci numbers (we wanted to test addition because it was
>> mainly ECL's memory management that was under consideration)
>>
>> with the following defs:
>>
>> def fibo(n):
>> a=1
>> b=1
>> c=0
>> for i in range(n):
>> c=a
>> a=a+b
>> b=c
>> return b
>>
>> def test(n,m):
>> for i in range(m):
>> _=fibo(n)
This is an interesting test. I tested it in the language I
developing, and noticed it doesn't handle this special case very well,
besides simple, it is subtle in how it tests a language memory
management.
Describing how it works in my language:
c = a
(1) if 'c' is a t_mpz, it calls mpz_set(c, a), else, it tags the
object pointed by 'a' as type t_shz (shared), and make 'c' also point
to it
a = a + b
(2) if 'a' is of type t_mpz, it directly stores the result in 'a',
else if 'a' if a shared mpz_t (t_shz), it allocates a new mpz_t and
makes 'a' point to it (the result of the addition is always computed
in a per thread "accumulator")
b = c
(3) same logic as 1.
The interesting fact is that by using shared objects, in this case
it ends up always not changing 'a' in place, because when it's value
was assigned to 'c', it was retyped to t_shz (shared mpz_t). In other
words, it allocates one mpz_t per loop iteration.
I made a simple build, where, if the type of an object is not t_mpz,
when assigned an mpz_t object, it would not make it shared, but always
make a copy, and in that case, it almost triplied the speed in my
interpreter. In other words, it used only 3 mpz_t objects per call to
"fibo".
But the C version (somewhat simulating what a close to perfect high
level language would optimize this example to) is not that faster then
Python. Just for completeness, here are the tests I used (my computer
is not that fast, so I used 400 iterations for fibo 4000):
- C version -
#include
#include
mpz_t *fibo(int n) {
mpz_t *a, *b, *c;
a = malloc(sizeof(mpz_t));
b = malloc(sizeof(mpz_t));
c = malloc(sizeof(mpz_t));
mpz_init_set_ui(*a, 1);
mpz_init_set_ui(*b, 1);
mpz_init(*c);
for (; n > 0; --n) {
mpz_set(*c, *a);
mpz_add(*a, *a, *b);
mpz_set(*b, *c);
}
mpz_clear(*a);
mpz_clear(*c);
free(a);
free(c);
return b;
}
void test(int n, int m) {
mpz_t *_;
for (; m > 0; --m) {
_ = fibo(n);
mpz_clear(*_);
free(_);
}
}
int main(int argc, char *argv[])
{
test(4000, 400);
return 0;
}
-%<-
- Python version -
def fibo(n):
a = 1
b = 1
c = 0
for i in range(n):
c = a
a = a + b
b = c
return b
def test(n, m):
for i in range(m):
_ = fibo(n)
test(4000, 400)
-%<-
- Lisp version -
(defun fibo (n)
(let ((a 1) (b 1) (c 0))
(dotimes (i n)
(setf c a)
(incf a b)
(setf b c))
(return-from fibo b)))
(compile 'fibo)
(defun test (n m)
(let (_)
(dotimes (i m)
(setf _ (fibo n)
(compile 'test)
(test 4000 400)
-%<-
- My Language (TM) version :-)
auto fibo(n) {
auto a = 1, b = 1, c;
for (; n > 0; --n) {
c = a;
a = a + b;
b = c;
}
return b;
}
void test(n, m) {
auto _;
for (; m > 0; --m)
_ = fibo(n);
}
test(4000, 400);
-%<-
One random run in my interpreter:
2.58user 0.04system 0:02.94elapsed
One random run in ecl:
3.69user 0.20system 0:05.09elapsed
One random run in clisp:
2.31user 0.78system 0:03.42elapsed
One random run in sbcl:
0.92user 0.05system 0:02.69elapsed
One random run in python:
1.08user 0.01system 0:01.38elapsed
One random run of the C binary:
0.54user 0.00system 0:00.60elapsed
This is an interesting case, where not attempting to share the mpz_t
is better, and coupled with inplace store of arithmetic it becomes
quite good.
It would be interesting some other kinds of tests also, for example,
while Python was pretty good in this special case, I have seen cases
where it is more then 10 times slower then the language I am
developing, like in a simple factorial, recursive or not, but I
believe it is because of Python using its own bignum library, that
doesn't have optimized multiplication.
I used all iterations with mpz_t objects in the C version for
simplification, as it starts using them at around 1000 iterations,
otherwise, would need to simulate a high level language, that would
check for overflow before switching to use mpz_t's, etc. But if
unrolled to start using mpz_t objects without checking for overflow,
could reduce the time by up to 20%.
--~--~-~--~~~--
[sage-devel] Re: About pexpect version in sage
2009/9/6 William Stein :
>
> 2009/9/5 Paulo César Pereira de Andrade
> :
>>
>> 2009/9/5 William Stein :
>>>
>>> 2009/9/5 Paulo César Pereira de Andrade
>>> :
>>>>
>>>> Hi,
>>>>
>>>> I am not experienced with pexepect, but I played a bit trying to use
>>>> a newer version in sage.
>>>> But since it is one of the core packages of sage (and because it is
>>>> one of the special cases where an older package is used, in my rpm
>>>> package :-), I would like to know what is the state about upgrading it
>>>> to a newer version, or using some alternate interface.
>>>
>>> The only reason I didn't upgrade pexpect long ago is that at some
>>> point it was greatly rewritten/refactored and the result was
>>> *massively* slower than the version in Sage. So I stayed with the
>>> version we were including. Nobody has succeeded in figuring out why
>>> the new pexpect is thousands of times slower.
>>>
>>>>
>>>> The major problems I see are:
>>>
>>> Major problems with upgrading? Or with pexpect in general?
>>>
>>>> 1. pexpect uses a pty, but it is not a fully functional "terminal
>>>> emulator", for example, try any gap command longer then 80 bytes; it
>>>> will get completely wrong.
>>>
>>> That is not true at all.
>>>
>>> sage: a = '2'*90
>>> sage: gap.eval('%s + 1'%a)
>>> '23'
>>>
>>> That's a 90 character command and it is not "completely wrong".
>>
>> Oops, I think I extended one behavior as if it were generalized,
>> should have confused with some test with newer pexpect, sorry. But one
>> way to reproduce the problem can be to do something like:
>>
>> % mkdir -p
>> /tmp/0123456789/0123456789/0123456789/0123456789/0123456789/0123456789/0123456789/.sage
>> <>
>> % sage
>> <>
>> % ls
>> /tmp/0123456789/0123456789/0123456789/0123456789/0123456789/0123456789/0123456789/.sage/gap/
>> README.txt
>> <>
>> % sage
>> <>
>> % ls /tmp/0123456789/.sage/gap
>> README.txt workspace-1328071335
>>
>> This happens because the SaveWorkspace() call had more then 80 characters,
>> and it severely bugs out when trying to build the documentation, because I
>> would
>> set DOT_SAGE to the rpm buildroot, but now it uses a hack to
>> export DOT_SAGE=/tmp/sage$$
>
> Can you please please post this stuff to trac.sagemath.org? I won't
> be able to work on sage development for the next few weeks, and I
> don't want this to get lost in the shuffle.
No problems. I just need a trac account. I think you may have missed
my request because I used the same subject for a post to sage-devel
and one private mail :-)
I can later try to also provide a patch to use latest upstream
pexpect, I had one, but was somewhat trivial, just that it would only
work correctly in the sage terminal interface, while frequently
displaying a lot of noise in the notebook, usually when loading
maxima, singular, or other background process, what should have been a
timing issue.
[ to avoid one possible round trip, my preferred account name would be
pcpa, and I had suggest as the password the google mail identifier of
that private email ]
> William
Thanks,
Paulo
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: About pexpect version in sage
2009/9/5 William Stein :
>
> 2009/9/5 Paulo César Pereira de Andrade
> :
>>
>> Hi,
>>
>> I am not experienced with pexepect, but I played a bit trying to use
>> a newer version in sage.
>> But since it is one of the core packages of sage (and because it is
>> one of the special cases where an older package is used, in my rpm
>> package :-), I would like to know what is the state about upgrading it
>> to a newer version, or using some alternate interface.
>
> The only reason I didn't upgrade pexpect long ago is that at some
> point it was greatly rewritten/refactored and the result was
> *massively* slower than the version in Sage. So I stayed with the
> version we were including. Nobody has succeeded in figuring out why
> the new pexpect is thousands of times slower.
>
>>
>> The major problems I see are:
>
> Major problems with upgrading? Or with pexpect in general?
>
>> 1. pexpect uses a pty, but it is not a fully functional "terminal
>> emulator", for example, try any gap command longer then 80 bytes; it
>> will get completely wrong.
>
> That is not true at all.
>
> sage: a = '2'*90
> sage: gap.eval('%s + 1'%a)
> '23'
>
> That's a 90 character command and it is not "completely wrong".
Oops, I think I extended one behavior as if it were generalized,
should have confused with some test with newer pexpect, sorry. But one
way to reproduce the problem can be to do something like:
% mkdir -p
/tmp/0123456789/0123456789/0123456789/0123456789/0123456789/0123456789/0123456789/.sage
<>
% sage
<>
% ls
/tmp/0123456789/0123456789/0123456789/0123456789/0123456789/0123456789/0123456789/.sage/gap/
README.txt
<>
% sage
<>
% ls /tmp/0123456789/.sage/gap
README.txt workspace-1328071335
This happens because the SaveWorkspace() call had more then 80 characters,
and it severely bugs out when trying to build the documentation, because I would
set DOT_SAGE to the rpm buildroot, but now it uses a hack to
export DOT_SAGE=/tmp/sage$$
> The input size is limited though to about 3000 characters. The eval
> command uses a file when the input is more than 100 characters.
> This is configured in the __init__ method in gap.py. The cutoff could
> be much higher than 100, but experimentally I found that it is faster
> to use a file after about 100 characters.
>
>
>> I found weird behavior at some point, and
>> then, I noticed it when running sage to build documentation, where I
>> would set DOT_SAGE to a long path, and when executing:
>> SaveWorkspace("/some/very/long/pathname/.sage/gap/workspace-hash-of-SAGE_ROOT")
>> it would add a space in the 80th character.
>
> There is a bug there of course, but it is not some generic thing for
> any input longer than 80 characters.
>
> By the way, you might try changing the 100 to 75 as mentioned above
> and see what happens.
>
>> 2. I understand now sage will use ecl, but clisp uses a "magic" to
>> detect it is running interactively, that is to check if "fileno(stdin)
>> == fileno(stdout)", and pexpect just ensures that, so, either one
>> would need to use a patch as suggested in
>> http://sourceforge.net/mailarchive/message.php?msg_name=81329a955d5b59daeeccb0edc0e7b603.squirrel%40webmail.mandriva.com.br
>> or do some trick like 'cat /dev/stdin | clisp "$@" > /dev/stdout"
>
> We dumped clisp from Sage in early May... so I'm not thinking about
> getting clisp to work with Sage anymore.
>
>> 3. Newer/upstream version of pexpect is "almost" functional, but shows
>> the problems in (1.) no only for gap, but for anything, and most
>> worksheet files uses commands longer then 80 bytes.
>
> You should also do speed tests with this new pexpect -- I never
> noticed problems with it working, but with it just being insanely
> slow.
I reverted to pexpect used by sage due to too many noise in the notebook
output, with blanks in the 80th character. But, usually it only happened when
needing to load something like gap or maxima. After repeating the execution
in the notebook, it would work.
>> About gap, there is also another issue. Sage uses the "undocumented"
>> -p option, but that is only used by xgap, and since I packaged xgap,
>> it took me sometime to find out why gap would not work, and it was due
>> to it failing to query the X Window System colormap, depth, etc. I
>> "corrected" that by changing xgap to not be "autoloaded".
>
> Interesting. How did you change xgap to not be autolo
[sage-devel] About pexpect version in sage
Hi,
I am not experienced with pexepect, but I played a bit trying to use
a newer version in sage.
But since it is one of the core packages of sage (and because it is
one of the special cases where an older package is used, in my rpm
package :-), I would like to know what is the state about upgrading it
to a newer version, or using some alternate interface.
The major problems I see are:
1. pexpect uses a pty, but it is not a fully functional "terminal
emulator", for example, try any gap command longer then 80 bytes; it
will get completely wrong. I found weird behavior at some point, and
then, I noticed it when running sage to build documentation, where I
would set DOT_SAGE to a long path, and when executing:
SaveWorkspace("/some/very/long/pathname/.sage/gap/workspace-hash-of-SAGE_ROOT")
it would add a space in the 80th character.
2. I understand now sage will use ecl, but clisp uses a "magic" to
detect it is running interactively, that is to check if "fileno(stdin)
== fileno(stdout)", and pexpect just ensures that, so, either one
would need to use a patch as suggested in
http://sourceforge.net/mailarchive/message.php?msg_name=81329a955d5b59daeeccb0edc0e7b603.squirrel%40webmail.mandriva.com.br
or do some trick like 'cat /dev/stdin | clisp "$@" > /dev/stdout"
3. Newer/upstream version of pexpect is "almost" functional, but shows
the problems in (1.) no only for gap, but for anything, and most
worksheet files uses commands longer then 80 bytes.
About gap, there is also another issue. Sage uses the "undocumented"
-p option, but that is only used by xgap, and since I packaged xgap,
it took me sometime to find out why gap would not work, and it was due
to it failing to query the X Window System colormap, depth, etc. I
"corrected" that by changing xgap to not be "autoloaded".
--
Paulo
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] polybori spkg problems
Hi, While debugging some remaining issues with the sagemath package I am working, it had a bug where it would link both, statically and dynamically with libpolybori and its associated libraries. Interestingly, when LD_PRELOAD'ing libpolybori.so it would not cause some crashes[1], but when preloading it I found out that it has an interesting problem, where, if the preprocessor UNIX is not defined at compile time, it uses stubs for things like popen and pclose, or "non optimal" code for other things. I am reporting the problem mostly because the precompiled sagemath binaries also have the problem: % pwd /home/pcpa/sage-4.1 % objdump -t -T local/lib/libpolybori-0.5.0.so | egrep '\' 0003de40 g F .text 0044 popen 0003de40 gDF .text 0044 Basepopen [I renamed to sage-4.1 the directory where I untarred the Mandriva 2009.0 binaries] Another problem is the fact that sage uses the spkg boost-cropped-1.34.1.spkg, while I am building packages with: % rpm -q libboost-devel libboost-devel-1.39.0-2mdv2010.0 I have attempted some time ago to compile only polybori with boost-cropped-1.34.1.spkg, but the results were not very good... [1] The crashes are interesting, because they are generated usually when running something like "sage -t some/dir", but if running "sage -t some/dir/only/the/file/that/causes/the/crash" it doesn't crash; the crash is libc aborting due to memory errors, either something overrun the free'ed memory, or just a double free. Thanks, Paulo --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: List of doctest failures in current Mandriva sagemath
2009/9/2 Martin Albrecht : > >> > doc/en/constructions/rings.rst +58 >> > sage: R = singular.ring(97, '(a,b,c,d)', 'lp') >> > sage: I = singular.ideal(['a+b+c+d', 'ab+ad+bc+cd', >> > 'abc+abd+acd+bcd', 'abcd-1']) >> > sage: R >> > Expected: >> > // characteristic : 97 >> > // number of vars : 4 >> > // block 1 : ordering lp >> > // : names a b c d >> > // block 2 : ordering C >> > Got: >> > // characteristic : 97 >> > // number of vars : 4 >> > // block 1 : ordering lp >> > // : names abcd >> > // block 2 : ordering C >> > * The sage spkg don't have a patch to separate the names, so I am >> > assuming it is a minor change in singular >> >> looks safe > > Yes, this was fixed in Singular recently, I assume Mandriva only needs to > update to the newest upstream release. I tried again a newer singular, but singular-3-1-0-4, which is the latest one api/abi compatible with sage. I am preferring to package upstream, and then apply sage patches as appropriate. I will check if I can make a simple patch make singular provide the result expected by sage. >> > rings/polynomial/toy_d_basis.py +171 >> > sage: from sage.rings.polynomial.toy_d_basis import gpol >> > sage: P. = PolynomialRing(IntegerRing(), 3, order='lex') >> > sage: f = x^2 - 1 >> > sage: g = 2*x*y - z >> > sage: gpol(f,g) >> > Expected: >> > x^2*y - y >> > Got: >> > x^2*y - x*z + y >> > * Not sure what is the cause, neither if this is an alternate correct >> > result...] >> >> Martin -- any thoughts? > > Here is what gpol does > > a1,a2 = g1.lc(),g2.lc()# a1 = 1, a2 = 2 > a, c1, c2 = xgcd(a1,a2) # (1,0,1) -> this is not unique > t1,t2 = g1.lm(), g2.lm() # x^2, x*y > t = t1.parent().monomial_lcm(t1,t2) # x^2*y > s1,s2 = t//t1, t//t2 # y, x > return c1*s1*g1 + c2*s2*g2 # 0*y*g1 + 1*x*g2 > > I guess xgcd changed (e.g. (1,-1,1)) and thus the result is different. So it > seems also correct. Many thanks for the review. About quaddouble, since only sagemath requires it, I packaged the sage spkg in Mandriva. But the package is kind problematic, as it has only a static library, and the sage spkg fails to build the fortran bindings in x86_64. Anyway, if sage stops using it, then it can be dropped from Mandriva later. Since there is still some time before Mandriva 2010.0, I am also updating the package to ship sage 4.1.1. > Cheers, > Martin Paulo --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] List of doctest failures in current Mandriva sagemath
Hi,
The package I am building uses newer versions of several components,
and while I believe most of these tests probably are correct, I may be
missing some patch, so, if you can confirm it is correct, or is an
alternate correct response, please let me know.
These are not the only errors, but are a sampling of similar errors:
doc/en/constructions/polynomials.rst +45
sage: print gap.eval("R:= PolynomialRing( GF(97))")
Expected:
PolynomialRing(..., [ x_1 ])
Got:
GF(97)[x_1]
* this should be due to using gap 4.4.12, while sage uses gap 4.4.10
doc/en/constructions/rings.rst +58
sage: R = singular.ring(97, '(a,b,c,d)', 'lp')
sage: I = singular.ideal(['a+b+c+d', 'ab+ad+bc+cd',
'abc+abd+acd+bcd', 'abcd-1'])
sage: R
Expected:
// characteristic : 97
// number of vars : 4
//block 1 : ordering lp
// : namesa b c d
//block 2 : ordering C
Got:
// characteristic : 97
// number of vars : 4
//block 1 : ordering lp
// : namesabcd
//block 2 : ordering C
* The sage spkg don't have a patch to separate the names, so I am
assuming it is a minor change in singular
doc/en/tutorial/tour_numtheory.rst +94
sage: x = crt(2, 1, 3, 5); x
Expected:
-4
Got:
11
* This is caused by using pari 2.3.4 while sage uses pari 2.3.3
libs/pari/gen.pyx +6781
sage: y = QQ['yy'].0; _ = pari(y) # pari has variable ordering rules
sage: x = QQ['zz'].0; nf = pari(x^2 + 2).nfinit()
sage: nf.nfroots(y^2 + 2)
Expected:
[-zz, zz]
Got:
[Mod(-zz, zz^2 + 2), Mod(zz, zz^2 + 2)]
* Again, due to using newer version of pari
matrix/matrix_double_dense.pyx +983
sage: m = matrix(RDF, 2, range(6)); m
[0.0 1.0 2.0]
[3.0 4.0 5.0]
sage: U, S, V = m.SVD()
sage: U*S*V.transpose() # random low bits
[7.62194127257e-17 1.0 2.0]
[ 3.0 4.0 5.0]
sage: U
[-0.274721127897 -0.961523947641]
[-0.961523947641 0.274721127897]
sage: S
[7.34846922835 0.0 0.0]
[ 0.0 1.0 0.0]
sage: V
Expected:
[-0.392540507864 0.824163383692 0.408248290464]
[-0.560772154092 0.137360563949 -0.816496580928]
[ -0.72900380032 -0.549442255795 0.408248290464]
Got:
[-0.392540507864 0.824163383692 -0.408248290464]
[-0.560772154092 0.137360563949 0.816496580928]
[ -0.72900380032 -0.549442255795 -0.408248290464]
* This one gives significantly different result, but is not easy to do
an alternate build with sage's version of quaddouble
* I think I will switch to use sage's version. Sage uses quaddouble
2.2.p9 (patchlevel 9), while I packaged upstream
quaddouble 2.2.7
rings/real_rqdf.pyx +463
sage: RQDF(2^60 + 9 )
Expected:
1.152921504606846985e18
Got:
1e+18
* Again should be a quaddouble issue. But I can see that sage result
is correct, while the quaddouble I am using is truncating the result.
rings/polynomial/toy_d_basis.py +171
sage: from sage.rings.polynomial.toy_d_basis import gpol
sage: P. = PolynomialRing(IntegerRing(), 3, order='lex')
sage: f = x^2 - 1
sage: g = 2*x*y - z
sage: gpol(f,g)
Expected:
x^2*y - y
Got:
x^2*y - x*z + y
* Not sure what is the cause, neither if this is an alternate correct result...
calculus/calculus.py +1068
sage: f = log(log(x))/log(x)
sage: forget(); assume(x<-2); lim(f, x=0, taylor=True)
Expected:
limit(log(log(x))/log(x), x, 0)
Got:
0
* This is when using newer maxima
Thanks,
Paulo
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Sagemath 4.1 rpm in Mandriva 2010.0
2009/8/28 Minh Nguyen : > > Hi Paulo, Hi Minh >> The package should be stable, but I am still resolving some issues >> with 'sage -testall', >> as not all components match sage spkgs; there are several errors due to >> python deprecation messages followed by the correct result, or false >> positives >> due to Mandriva using pari 2.3.4 and sage 4.1 using pari 2.3.3; so far, with >> over 125000 tests passing clearly, there are still around 100 that I am >> checking >> to ensure they are not real errors. > > I have never used Mandriva nor do I have access to a Mandriva box. So > you might want to also do "sage -testlong". Thanks for the suggestion, I will do it in a next step. Currently, I am adding the output of sage -testall to the rpm, to ensure it adds enough build requires, but probably I will remove it, as it is over 8mb that nobody will use, or, if interested, one can run sage -testall and check $DOT_SAGE/tmp/test.log. But I am using another computer to actually check for problems, where all dependencies are installed, and run it as "sage -testall --verbose", but I am still checking for a fast guess of problems, and setting SAGE_TIMEOUT and SAGE_TIMEOUT_LONG to small values :-) > -- > Regards > Minh Van Nguyen Paulo --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sagemath 4.1 rpm in Mandriva 2010.0
2009/8/28 William Stein : > > 2009/8/27 Paulo César Pereira de Andrade > : >> >> Hi, >> >> I would like to let people know that there is a sagemath 4.1 package >> for Mandriva cooker, >> and it should be shipped as a contrib package in Mandriva 2010.0. > > Awesome!! Now Mandriva will have the most up to date proper > packaging of Sage for any Linux distro. Debian also has Sage, but it > is a bit out of date right now. > > May I ask roughly how much work this was? Are there changes that we > should make to our spkg's to make things easier for you? I started several months ago, and it was already in my "todo" list for other several months, after sage was on slashdot. About making things easier, I think it would be good to have package.py to understand sage being packaged in a distro, and understand about rpm and dpkg. Also, there are some patches to write files in $DOT_SAGE, in some cases where it would try to write under $SAGE_ROOT, and would fail due to permissions, as $SAGE_ROOT is /usr/share/sage, but has symlinks to /usr/bin, /usr/lib, etc, under $SAGE_LOCAL, so that patching can be kept at a minimum. I did it while doing my normal work on Mandriva, usually working on OEM images, and the first package I built was sage 3.0.x, but it was far from usable, due to several problems that took some time to figure out, for example linbox linking, because Mandriva is using the same schema as most distros, of doing minimal linking, what would cause all kinds of corruptions, usually due to global static c++ objects. I also had trouble trying to use latest stable upstream of some packages, for the sage rpm I just created a /usr/share/sage/site-packages, and set PYTHONPATH to it. These packages include pexpect, networkx and sqlalchemy. Later I may need to add moin to it, but Mandriva's moin package was outdated, so I just updated to the version required by sage. I made some changes to packages in Mandriva also, like adding sage patches to sphinx, so that the samples in the help would work properly, like when running notebook() from sage in a xterm, and opening the tutorial pages. I made very few changes to packages that are not already sage spkg patches; one I remember, is an alternate clisp patch, so that the -I option disables readline, and modified maxima clisp runtime to pass -I to lisp.run if the --disable-readline option is used. >> This is not an official announcement of Mandriva, and rpm sources >> can be viewed at >> http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/sagemath/current/ >> >> The package should be stable, but I am still resolving some issues >> with 'sage -testall', >> as not all components match sage spkgs; there are several errors due to >> python deprecation messages followed by the correct result, or false >> positives >> due to Mandriva using pari 2.3.4 and sage 4.1 using pari 2.3.3; so far, with >> over 125000 tests passing clearly, there are still around 100 that I am >> checking >> to ensure they are not real errors. >> > > When in doubt feel free to post the tests here for comment. Ok. Most the failures so far are due to using a newer matplotlib, that issues a deprecated warning, but still produces the correct value. Other large group of test failures are due to newer pari, and things like xgcd and crt returning a different (but also correct value). Yet another large group is due to using a newer quaddouble package, and having small variations on numbers smaller then 1e-15. I am still investigating a few others, but will post here if I cannot figure what may be wrong :-) > William Paulo --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Sagemath 4.1 rpm in Mandriva 2010.0
Hi, I would like to let people know that there is a sagemath 4.1 package for Mandriva cooker, and it should be shipped as a contrib package in Mandriva 2010.0. This is not an official announcement of Mandriva, and rpm sources can be viewed at http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/sagemath/current/ The package should be stable, but I am still resolving some issues with 'sage -testall', as not all components match sage spkgs; there are several errors due to python deprecation messages followed by the correct result, or false positives due to Mandriva using pari 2.3.4 and sage 4.1 using pari 2.3.3; so far, with over 125000 tests passing clearly, there are still around 100 that I am checking to ensure they are not real errors. Thanks, Paulo --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
