Re: [sage-devel] misleading comment on cygwin binaries
On 8/14/18 5:43 PM, Erik Bray wrote: Isn't that just the normal message when running `sage -sh`? Indeed! I thought it was some cygwin special but it is in $SAGE_ROOT/src/bin/sage at lines 735-742. I never even read it that closely. Why *does* it say that? I install packages and run make from within the sage subshell all the time. Especially when it comes to optional packages (which should maybe be the only kind actually supported by sage -i) there should be little danger. What about removing all this then? The only danger is if you somehow break the python in Sage. I've actually been thinking about that lately and I don't think it should ever be used by sage_bootstrap. I think it should always try to find the system Python instead. It is unlikely that you break Python with a "pip install" or "sage -i". If you do something else in "sage -sh" I assume you are advanced enough user to figure things out. Vincent On Tue, Aug 14, 2018, 21:17 Vincent Delecroix <20100.delecr...@gmail.com> wrote: Dear all (I guess mostly Erik), When a sage shell is launched on windows (ie the sage -sh environment in cygwin) the following message is displayed """ Starting subshell with Sage environment variables set. Don't forget to exit when you are done. Beware: * Do not do anything with other copies of Sage on your system. * Do not use this for installing Sage packages using "sage -i" or for running "make" at Sage's root directory. These should be done outside the Sage shell. """ Many people at Sage days 96 cut the second item as "Do not use this for installing Sage packages" and they did not even tried to "pip install" the Python package I asked them to install (I gave them the full command to be run). Would that be possible to simply disable "sage -i"? Vincent PS: Erik, once more, thank you for this cygwin version that is wonderful to get more Sage users!! -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] misleading comment on cygwin binaries
Isn't that just the normal message when running `sage -sh`? I never even read it that closely. Why *does* it say that? I install packages and run make from within the sage subshell all the time. Especially when it comes to optional packages (which should maybe be the only kind actually supported by sage -i) there should be little danger. The only danger is if you somehow break the python in Sage. I've actually been thinking about that lately and I don't think it should ever be used by sage_bootstrap. I think it should always try to find the system Python instead. On Tue, Aug 14, 2018, 21:17 Vincent Delecroix <20100.delecr...@gmail.com> wrote: > Dear all (I guess mostly Erik), > > When a sage shell is launched on windows (ie the sage -sh environment in > cygwin) the following message is displayed > > """ > Starting subshell with Sage environment variables set. Don't forget > to exit when you are done. Beware: > * Do not do anything with other copies of Sage on your system. > * Do not use this for installing Sage packages using "sage -i" or for > running "make" at Sage's root directory. These should be done > outside the Sage shell. > """ > > Many people at Sage days 96 cut the second item as > "Do not use this for installing Sage packages" and they did not > even tried to "pip install" the Python package I asked them to > install (I gave them the full command to be run). > > Would that be possible to simply disable "sage -i"? > > Vincent > > PS: Erik, once more, thank you for this cygwin version that is > wonderful to get more Sage users!! > > -- > 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 https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] misleading comment on cygwin binaries
Dear all (I guess mostly Erik), When a sage shell is launched on windows (ie the sage -sh environment in cygwin) the following message is displayed """ Starting subshell with Sage environment variables set. Don't forget to exit when you are done. Beware: * Do not do anything with other copies of Sage on your system. * Do not use this for installing Sage packages using "sage -i" or for running "make" at Sage's root directory. These should be done outside the Sage shell. """ Many people at Sage days 96 cut the second item as "Do not use this for installing Sage packages" and they did not even tried to "pip install" the Python package I asked them to install (I gave them the full command to be run). Would that be possible to simply disable "sage -i"? Vincent PS: Erik, once more, thank you for this cygwin version that is wonderful to get more Sage users!! -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Dropping support for old-style .spkgs?
On 08/14/2018 12:54 PM, Erik Bray wrote: > > Why would they do even that? It's just a data package. For the > purposes of upstream packaging it doesn't need a configure.ac. It can > just be a bundle of files. But I still don't see what that solves. > Good luck getting 30 GB of obscure math data upstreamed to an > arbitrary number of OS packagers... >From the Gentoo perspective: the existence of ./configure means that the default build process will put everything in the right place without me having to figure out where that is and copy/paste it. And the "package" is nothing but a tiny text file until somebody installs it. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] issue with cos(pi/2) and sin(pi)
Because float(pi/2) is not exactly pi/2:
sage: n(pi/2 - float(pi/2), 53)
0.000
sage: n(pi/2 - float(pi/2), 54) # also for perc > 54 of course
1.11022302462516e-16
This does mean that:
sage: float(cos(pi/2))
0.0
sage: float(sin(pi))
0.0
Regards,
TB
On 14/08/18 21:02, david.coud...@inria.fr wrote:
I looking for a smart way to fix the following issue that we have when
plotting graphs (see #22050 and #24512 for instance):
cos(pi/2) is not 0 and sin(pi) is not 0 !
|
sage:G =Graph(4)
sage:_circle_embedding(G,G.vertices())
sage:G._pos
{0:(1.0,0.0),
1:(6.123233995736766e-17,1.0),# here we have cos(pi/2)
2:(-1.0,1.2246467991473532e-16),# here we sin(pi)
3:(-1.8369701987210297e-16,-1.0)}# here cos(3*pi/2)
|
In a sage session, we have:
|
sage:cos(pi/2)
0
sage:sin(pi)
0
sage:cos(float(pi/2))
6.123233995736766e-17
sage:sin(float(pi))
1.2246467991473532e-16
|
Any proposal is more than welcome ;)
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] issue with cos(pi/2) and sin(pi)
I looking for a smart way to fix the following issue that we have when
plotting graphs (see #22050 and #24512 for instance):
cos(pi/2) is not 0 and sin(pi) is not 0 !
sage: G = Graph(4)
sage: _circle_embedding(G, G.vertices())
sage: G._pos
{0: (1.0, 0.0),
1: (6.123233995736766e-17, 1.0), # here we have cos(pi/2)
2: (-1.0, 1.2246467991473532e-16), # here we sin(pi)
3: (-1.8369701987210297e-16, -1.0)} # here cos(3*pi/2)
In a sage session, we have:
sage: cos(pi/2)
0
sage: sin(pi)
0
sage: cos(float(pi/2))
6.123233995736766e-17
sage: sin(float(pi))
1.2246467991473532e-16
Any proposal is more than welcome ;)
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Broken 8.3 build
Thank you very much for replying! I actually discovered this fact late last night! I might have realized it sooner, but I have been trying out different configurations on a new laptop, and I had successfully compiled Sage when I had MiniConda installed. Fresh install without MiniConda, and I guess I had no Python 2.7 as a result, even though I had Python 3.6. Anyway, thanks again. Robert On Tuesday, August 14, 2018 at 2:08:36 AM UTC-7, Dima Pasechnik wrote: > > You need a system-wide python installed. Indeed, patch.log says: > > > Found local metadata for patch-2.7.5 > /usr/bin/env: 'python': No such file or directory > > Error downloading patch-2.7.5.tar.gz > > > So you need to run > > sudo apt-get install python > > python is not mentioned in > http://doc.sagemath.org/html/en/installation/source.html#system-specific-requirements > but is mentioned in > http://doc.sagemath.org/html/en/installation/source.html#command-line-tools > > I guess it's very unusual not to have any python on the box nowadays... > > On Tuesday, August 14, 2018 at 10:10:11 AM UTC+3, rob.w...@gmail.com > wrote: >> >> I have a Dell G7 with Lubuntu 18.04 and MAKE='make -j9' make returned as >> shown below. >> Thanks for your help. >> >> >> make[1]: Entering directory '/home/rob/sage-8.3/build/make' >> sage-logger -p 'sage-spkg patch-2.7.5' >> '/home/rob/sage-8.3/logs/pkgs/patch-2.7.5.log' >> [patch-2.7.5] Found local metadata for patch-2.7.5 >> [patch-2.7.5] /usr/bin/env: 'python': No such file or directory >> [patch-2.7.5] >> >> [patch-2.7.5] Error downloading patch-2.7.5.tar.gz >> [patch-2.7.5] >> >> [patch-2.7.5] Please email sage-devel ( >> http://groups.google.com/group/sage-devel) >> [patch-2.7.5] explaining the problem and including the log file >> [patch-2.7.5] /home/rob/sage-8.3/logs/pkgs/patch-2.7.5.log >> [patch-2.7.5] Describe your computer, operating system, etc. >> [patch-2.7.5] >> >> Makefile:2058: recipe for target >> '/home/rob/sage-8.3/local/var/lib/sage/installed/patch-2.7.5' failed >> make[1]: *** >> [/home/rob/sage-8.3/local/var/lib/sage/installed/patch-2.7.5] Error 1 >> make[1]: Leaving directory '/home/rob/sage-8.3/build/make' >> >> real 0m0.056s >> user 0m0.061s >> sys 0m0.003s >> *** >> Error building Sage. >> >> The following package(s) may have failed to build (not necessarily >> during this run of 'make base-toolchain'): >> >> * package: patch-2.7.5 >> log file: /home/rob/sage-8.3/logs/pkgs/patch-2.7.5.log >> build directory: /home/rob/sage-8.3/local/var/tmp/sage/build/patch-2.7.5 >> >> The build directory may contain configuration files and other potentially >> helpful information. WARNING: if you now run 'make' again, the build >> directory will, by default, be deleted. Set the environment variable >> SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this. >> >> Makefile:31: recipe for target 'base-toolchain' failed >> make: *** [base-toolchain] Error 1 >> >> >> -- >> The Great Secret? >> "It is, and It isn't." >> > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Dropping support for old-style .spkgs?
On Tue, Aug 14, 2018 at 6:41 PM Michael Orlitzky wrote: > > On 08/14/2018 12:22 PM, Erik Bray wrote: > > > > I'm not sure what you mean in this case by "system package". > > > > Have the upstream authors create a (basically empty) configure.ac file, > call it version 1.0.0, and release a tarball. Why would they do even that? It's just a data package. For the purposes of upstream packaging it doesn't need a configure.ac. It can just be a bundle of files. But I still don't see what that solves. Good luck getting 30 GB of obscure math data upstreamed to an arbitrary number of OS packagers... -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Start a Sage session from a session of its own Python interpreter ?
On Tue, Aug 14, 2018 at 5:57 PM Emmanuel Charpentier wrote: > > > > Le mardi 14 août 2018 17:20:26 UTC+2, Erik Bray a écrit : >> >> On Tue, Aug 14, 2018 at 4:20 PM William Stein wrote: >> > >> > On Tue, Aug 14, 2018 at 6:57 AM, Emmanuel Charpentier >> > wrote: >> > >> On Tue, Aug 14, 2018 at 3:21 PM Erik Bray wrote: >> > >> > On Mon, Aug 13, 2018 at 7:07 PM Emmanuel Charpentier >> > >> They might >> > >> also be amenable to a patch. It might not even need to be >> > >> Sage-specific; for example maybe it would be good to have an interface >> > >> transforming inputs prior to passing to the Python interpreter (as >> > >> IPython provides, allowing us to slip in Sage's preparse()). >> > > >> > > >> > > I'll have to read (a lot), and possibly write some trial code before I >> > > can >> > > know what I don't know/understand... (in other words, I'm too ignorant to >> > > assess the magnitude of my ignorance...). >> > > >> > > Possible alternative : would it be possible to write a dedicated wrapper >> > > library with the same interface as the standard (?) python library doing >> > > this preprocessing, thus offering to Python-enabled programs (many >> > > exist, it >> > > seems...) an interface they can use directly ? Outside reticulate, I >> > > have a >> > > few possibilities in mind (among them Pythontex, which might benefit from >> > > such an addition...). >> > >> > +1 ! Making "the Sage preparser" actually a standard Python library >> > (on pypi, etc.) that Sage depends on >> > is one of the things I've long wished would happen. It would be >> > fantastic to optionally provide our preparser >> > functionality outside of Sage. E.g., imagine somebody using sympy and >> > having the option to use a configured-for-sympy version of the >> > preparser, for easier entry of formulas. >> > >> > I've cc'd Robert Bradshaw, in case he has any thoughts, since he and I >> > mostly wrote the preparser. >> >> I don't know if that would be all that useful, at least not for >> Emmanuel's case of using the reticulate R package. A lot of what the >> the sage preparser does is ''very'' Sage-specific. > > > It would solve my use case, for one... How do you think having the Sage preparser available as a stand-alone package would solve your use case? As it is, you can already wrap every line of code that reticulate passes to sage with: from sage.repl.preparse import preparse; preparse(line) that's more or less what's needed here. Having in a separate package (though maybe useful for other reasons) does not help you here, because what you really need is a reasonable interface for inserting a pre-parser between your input and the Python interpreter. >> Perhaps if it were refactored into a class and aspects of it were made >> more customizable I could see how it could be useful in conjunction >> with other packages. But it's still not that useful at all outside >> the context of an IPython interpreter that has the necessary hooks to >> transform code before passing it to the Python interpreter. > > > Indeed, what you obtain is a "Python-like" interpreter, which could differ > *considerably* fro what Python is supposed to be... > > For example, we could have, say, macroes ;-)... or even explicit blocks > delimited with curly braces ;-] : two non-features of Python that make me > still thoink that Lisp had its points... Yes, there's nothing stopping anyone from designing a super-set of Python (or a completely different language) and providing a transpiler to pure Python. That's what Sage's preparse already does. See also much of the modern JavaScript community and Babel. See also Cython (which does NOT transpile to Python, but rather to CPython API calls which is always another possibility, albeit much harder...) >> Now, if the interpreter had a *built in* hook that would allow >> arbitrary preparsing on inputs that would be very powerful (and >> dangerous). > > > With great power... > >> >> But short of that, any program that wants to be able to >> run Python statements (i.e. in something like reticulate, or any other >> program that wraps a Python interpreter) has to provide its own >> interface for pre-processing inputs to the Python interpreter, and >> that's fine too. > > > Except that this leaves me with the task of reinventing the wheel... Given my > (non-)talents, there are some non-negligible hazards of ending up with > something describing a seriously hypotrochoidal orbit (and frequent axle > fractures)... I'm not really sure what you're saying here. All I'm saying is that if you want the Sage preparser to work in reticulate, it needs to provide a place that you can insert a pre-processor of some kind (which is little more than "string in, string out"). That's something I'd suggest raising with the reticulate developers, though you can to some extent provide it yourself. For example, whereas reticulate provides py_run_string, you can provide sage_run_string <- function(code,
Re: [sage-devel] Dropping support for old-style .spkgs?
On 08/14/2018 12:22 PM, Erik Bray wrote: > > I'm not sure what you mean in this case by "system package". > Have the upstream authors create a (basically empty) configure.ac file, call it version 1.0.0, and release a tarball. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Dropping support for old-style .spkgs?
On Sun, Aug 12, 2018 at 1:21 AM Michael Orlitzky wrote: > > On 08/10/2018 11:50 AM, Erik Bray wrote: > >> > >> While we are at it: it would be awesome if installation of this > >> package after upgrade was faster. "Installation" just means unpacking > >> files and copying them somewhere, but it takes something like 45 > >> minutes. Some time ago I asked to use parallel decompressor if it is > >> available in the system, which helped a lot, but then it stopped again. > > > > ... > > > > That said, I don't believe it should really be a Sage package in the > > first place. > > If anything, it should be a standalone (system) package. We could then > point sage at the pile of data with a ./configure flag. No need to > "upgrade" the sage copy of the same stuff every time. I'm not sure what you mean in this case by "system package". As I see it it's just a bunch of files that could be unpacked anywhere, and any code that uses it could be pointed to it with an argument and/or environment variable, perhaps with a sensible default (in fact, this is more or less what's already done, and the packaging as an "spkg" is just a convenience to make sure it's unpacked automatically to the correct default location). I'm not even against it remaining as a new-style spkg; it would just have to be repackaged as a .tar., and we would need to make sure that sage-download-file can find files under http://files.sagemath.org/spkg/huge/ -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] sage --version not printing anything
On 8/14/18 11:37 AM, Erik Bray wrote: On Sat, Aug 11, 2018 at 11:54 PM Vincent Delecroix <20100.delecr...@gmail.com> wrote: On 8/11/18 2:00 PM, 'Justin C. Walker' via sage-devel wrote: On Aug 11, 2018, at 11:43 , Vincent Delecroix <20100.delecr...@gmail.com> wrote: Hello, After some effort, I built 8.4.beta0 though "sage --version" is not printing anything (nor --dumpversion). Is it only on my computer? Can you check with other versions as well? I tried this on two different versions of macOS (10.11.6, 10.13.6). Both work as expected. Some default questions (I assume “sage” refers to 8.4-b0): - got VERSION.txt? - got $SAGE_LOCAL/bin/sage-version.h? - are the contents of these files correct? I also assume you’ve checked this sort of thing, but never hurts to ask. Yes, files are there. Not sure whether they are "correct" though. $ cat VERSION.txt SageMath version 8.4.beta0, Release Date: 2018-08-05 $ cat local/bin/sage-version.sh # Sage version information for shell scripts # This file is auto-generated by the sage-update-version script, do not edit! SAGE_VERSION='8.4.beta0' SAGE_RELEASE_DATE='2018-08-05' SAGE_VERSION_BANNER='SageMath version 8.4.beta0, Release Date: 2018-08-05' Oh, it looks like https://trac.sagemath.org/ticket/25150 finally got merged. In that case VERSION.txt shouldn't have anything to do with it. Hmm--try deleting $SAGE_LOCAL/bin/sage-version.sh and see if that fixes it. Thanks Erik for the suggestion. Actually, I had to recompile stuff in Sage and it appeared that version started to work again... mystery. Vincent -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Start a Sage session from a session of its own Python interpreter ?
Le mardi 14 août 2018 17:20:26 UTC+2, Erik Bray a écrit : > > On Tue, Aug 14, 2018 at 4:20 PM William Stein > wrote: > > > > On Tue, Aug 14, 2018 at 6:57 AM, Emmanuel Charpentier > > > wrote: > > >> On Tue, Aug 14, 2018 at 3:21 PM Erik Bray > wrote: > > >> > On Mon, Aug 13, 2018 at 7:07 PM Emmanuel Charpentier > > >> They might > > >> also be amenable to a patch. It might not even need to be > > >> Sage-specific; for example maybe it would be good to have an > interface > > >> transforming inputs prior to passing to the Python interpreter (as > > >> IPython provides, allowing us to slip in Sage's preparse()). > > > > > > > > > I'll have to read (a lot), and possibly write some trial code before I > can > > > know what I don't know/understand... (in other words, I'm too ignorant > to > > > assess the magnitude of my ignorance...). > > > > > > Possible alternative : would it be possible to write a dedicated > wrapper > > > library with the same interface as the standard (?) python library > doing > > > this preprocessing, thus offering to Python-enabled programs (many > exist, it > > > seems...) an interface they can use directly ? Outside reticulate, I > have a > > > few possibilities in mind (among them Pythontex, which might benefit > from > > > such an addition...). > > > > +1 ! Making "the Sage preparser" actually a standard Python library > > (on pypi, etc.) that Sage depends on > > is one of the things I've long wished would happen. It would be > > fantastic to optionally provide our preparser > > functionality outside of Sage. E.g., imagine somebody using sympy and > > having the option to use a configured-for-sympy version of the > > preparser, for easier entry of formulas. > > > > I've cc'd Robert Bradshaw, in case he has any thoughts, since he and I > > mostly wrote the preparser. > > I don't know if that would be all that useful, at least not for > Emmanuel's case of using the reticulate R package. A lot of what the > the sage preparser does is ''very'' Sage-specific. > It would solve my use case, for one... Perhaps if it were refactored into a class and aspects of it were made > more customizable I could see how it could be useful in conjunction > with other packages. But it's still not that useful at all outside > the context of an IPython interpreter that has the necessary hooks to > transform code before passing it to the Python interpreter. > Indeed, what you obtain is a "Python-like" interpreter, which could differ *considerably* fro what Python is supposed to be... For example, we could have, say, macroes ;-)... or even explicit blocks delimited with curly braces ;-] : two non-features of Python that make me still thoink that Lisp had its points... > Now, if the interpreter had a *built in* hook that would allow > arbitrary preparsing on inputs that would be very powerful (and > dangerous). With great power... > But short of that, any program that wants to be able to > run Python statements (i.e. in something like reticulate, or any other > program that wraps a Python interpreter) has to provide its own > interface for pre-processing inputs to the Python interpreter, and > that's fine too. > Except that this leaves me with the task of reinventing the wheel... Given my (non-)talents, there are some non-negligible hazards of ending up with something describing a seriously hypotrochoidal orbit (and frequent axle fractures)... -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] sage --version not printing anything
On Sat, Aug 11, 2018 at 11:54 PM Vincent Delecroix <20100.delecr...@gmail.com> wrote: > > On 8/11/18 2:00 PM, 'Justin C. Walker' via sage-devel wrote: > > > > > >> On Aug 11, 2018, at 11:43 , Vincent Delecroix <20100.delecr...@gmail.com> > >> wrote: > >> > >> Hello, > >> > >> After some effort, I built 8.4.beta0 though "sage --version" is not > >> printing anything (nor --dumpversion). Is it only on my computer? Can > >> you check with other versions as well? > > > > I tried this on two different versions of macOS (10.11.6, 10.13.6). Both > > work as expected. > > > > Some default questions (I assume “sage” refers to 8.4-b0): > > - got VERSION.txt? > > - got $SAGE_LOCAL/bin/sage-version.h? > > - are the contents of these files correct? > > > > I also assume you’ve checked this sort of thing, but never hurts to ask. > > Yes, files are there. Not sure whether they are "correct" though. > > $ cat VERSION.txt > SageMath version 8.4.beta0, Release Date: 2018-08-05 > > $ cat local/bin/sage-version.sh > # Sage version information for shell scripts > # This file is auto-generated by the sage-update-version script, do not > edit! > SAGE_VERSION='8.4.beta0' > SAGE_RELEASE_DATE='2018-08-05' > SAGE_VERSION_BANNER='SageMath version 8.4.beta0, Release Date: 2018-08-05' Oh, it looks like https://trac.sagemath.org/ticket/25150 finally got merged. In that case VERSION.txt shouldn't have anything to do with it. Hmm--try deleting $SAGE_LOCAL/bin/sage-version.sh and see if that fixes it. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] GNU/Linux debian sid/testing: "Error building Sage" 8.3 from git
Hi
On Tue, 14 Aug 2018 at 16:44, 'Julien Puydt' via sage-devel <
sage-devel@googlegroups.com> wrote:
> I have no clue what "testing/sid" might be... since as far as I know
> "sid==unstable"
>
Testing is usually about 10-20 days behind unstable ("sid").
Testing will also become the new stable, so uses "buster" already.
If your sources.list has "buster", you will become stable; if it has
"testing" you will continue ahead of buster once it becomes stable.
In any case testing/sid is not something, but testing and sid are very
close.
Regards,
Jan
--
.~.
/V\ Jan Groenewald
/( )\www.aims.ac.za
^^-^^
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] PEP idea: unary division
On Sun, Aug 12, 2018 at 11:31 PM Saul Schleimer wrote: > > Dear all - > > Just for the record, I started using flipper in sage and immediately got > bitten by this. I'll vote for ~n meaning some version of bit flipping > (preferably python's). Another possibility--since we're talking about preparsers lately, is to support a unary division operator just in Sage. > On Monday, June 6, 2016 at 6:13:19 AM UTC-4, Jeroen Demeyer wrote: >> >> On 2016-06-06 10:39, Erik Bray wrote: >> > But then you have to deal with the usual mess of ensuring that >> > the __rdiv__ method handles division for those objects. >> >> FYI: __rdiv__ does not exist in Cython (__div__ is always used), so >> there is not so much mess. > > -- > 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 https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Start a Sage session from a session of its own Python interpreter ?
On Tue, Aug 14, 2018 at 4:20 PM William Stein wrote: > > On Tue, Aug 14, 2018 at 6:57 AM, Emmanuel Charpentier > wrote: > >> On Tue, Aug 14, 2018 at 3:21 PM Erik Bray wrote: > >> > On Mon, Aug 13, 2018 at 7:07 PM Emmanuel Charpentier > >> They might > >> also be amenable to a patch. It might not even need to be > >> Sage-specific; for example maybe it would be good to have an interface > >> transforming inputs prior to passing to the Python interpreter (as > >> IPython provides, allowing us to slip in Sage's preparse()). > > > > > > I'll have to read (a lot), and possibly write some trial code before I can > > know what I don't know/understand... (in other words, I'm too ignorant to > > assess the magnitude of my ignorance...). > > > > Possible alternative : would it be possible to write a dedicated wrapper > > library with the same interface as the standard (?) python library doing > > this preprocessing, thus offering to Python-enabled programs (many exist, it > > seems...) an interface they can use directly ? Outside reticulate, I have a > > few possibilities in mind (among them Pythontex, which might benefit from > > such an addition...). > > +1 ! Making "the Sage preparser" actually a standard Python library > (on pypi, etc.) that Sage depends on > is one of the things I've long wished would happen. It would be > fantastic to optionally provide our preparser > functionality outside of Sage. E.g., imagine somebody using sympy and > having the option to use a configured-for-sympy version of the > preparser, for easier entry of formulas. > > I've cc'd Robert Bradshaw, in case he has any thoughts, since he and I > mostly wrote the preparser. I don't know if that would be all that useful, at least not for Emmanuel's case of using the reticulate R package. A lot of what the the sage preparser does is ''very'' Sage-specific. Perhaps if it were refactored into a class and aspects of it were made more customizable I could see how it could be useful in conjunction with other packages. But it's still not that useful at all outside the context of an IPython interpreter that has the necessary hooks to transform code before passing it to the Python interpreter. Now, if the interpreter had a *built in* hook that would allow arbitrary preparsing on inputs that would be very powerful (and dangerous). But short of that, any program that wants to be able to run Python statements (i.e. in something like reticulate, or any other program that wraps a Python interpreter) has to provide its own interface for pre-processing inputs to the Python interpreter, and that's fine too. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] GNU/Linux debian sid/testing: "Error building Sage" 8.3 from git
On Tue, Aug 14, 2018 at 5:02 PM Jörg-Volker wrote: > > > > On Tuesday, August 14, 2018 at 4:44:58 PM UTC+2, Snark wrote: >> >> Hi, >> >> Le 14/08/2018 à 11:20, Jörg-Volker a écrit : >> > >> > Hi, >> > trying to build Sage 8.3 on my GNU/Linux debian testing/sid system with >> > local gcc suite version 8.2.0 fails while compiling scipy. This is on a >> > desktop computer with 4 cores (8 threads) and 32 GB RAM. >> >> I have no clue what "testing/sid" might be... since as far as I know >> "sid==unstable" >> > It's a mixture of sid and testing. Mainly sid packages but also a few from > testing. If you could explain exactly how to reproduce your environment (e.g. in a Docker container) then I could have a look at it. Otherwise the best I think anyone can do is make random guesses. >> > The build command was >> > >> > MAKE='make -j8' SAGE_INSTALL_GCC=no SAGE_BUILD_DIR=/tmp/sage-b make >> > build >> > >> > >> > The relevant log file shows >> > >> > Traceback (most recent call last): >> >File "", line 1, in >> >File "/tmp/.cache-walt/pip-9Uwgks-build/setup.py", line 416, in >> > >> > setup_package() >> >File "/tmp/.cache-walt/pip-9Uwgks-build/setup.py", line 396, in >> > setup_package >> > from numpy.distutils.core import setup >> >File >> > >> > "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/__init__.py", >> > line 142, in >> > from . import add_newdocs >> >File >> > >> > "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/add_newdocs.py", >> > line 13, in >> > from numpy.lib import add_newdoc >> >File >> > >> > "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/lib/__init__.py", >> > line 8, in >> > from .type_check import * >> >File >> > >> > "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/lib/type_check.py", >> > line 11, in >> > import numpy.core.numeric as _nx >> >File >> > >> > "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/core/__init__.py", >> > line 26, in >> > raise ImportError(msg) >> > ImportError: >> > Importing the multiarray numpy extension module failed. Most >> > likely you are trying to import a failed build of numpy. >> > If you're working with a numpy git repo, try `git clean -xdf` >> > (removes all >> > files not under version control). Otherwise reinstall numpy. >> > >> > Original error was: /usr/lib/x86_64-linux-gnu/libblas.so.3: >> > undefined symbol: sgemv_thread_n >> > >> > Running setup.py install for scipy: finished with status 'error' >> > >> > The system has OpenBLAS installed but with a newer version 0.3.2. >> > >> > Any ideas? >> > >> > I've built previous versions of Sage on this system before (with gcc >> > 7.3.0). >> > >> >> Notice that there is a sagemath 8.3 in preparation for Debian, see : >> https://people.debian.org/~thansen/debian-sage-status.html >> >> so perhaps you could lend a hand making it to unstable? > > I'll take a look at it. >> >> >> jpuydt on irc.debian.org > > Regards, > Jörg. > > -- > 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 https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] GNU/Linux debian sid/testing: "Error building Sage" 8.3 from git
On Tuesday, August 14, 2018 at 4:44:58 PM UTC+2, Snark wrote: > > Hi, > > Le 14/08/2018 à 11:20, Jörg-Volker a écrit : > > > > Hi, > > trying to build Sage 8.3 on my GNU/Linux debian testing/sid system with > > local gcc suite version 8.2.0 fails while compiling scipy. This is on a > > desktop computer with 4 cores (8 threads) and 32 GB RAM. > > I have no clue what "testing/sid" might be... since as far as I know > "sid==unstable" > > It's a mixture of sid and testing. Mainly sid packages but also a few from testing. > > The build command was > > > > MAKE='make -j8' SAGE_INSTALL_GCC=no SAGE_BUILD_DIR=/tmp/sage-b make > > build > > > > > > The relevant log file shows > > > > Traceback (most recent call last): > >File "", line 1, in > >File "/tmp/.cache-walt/pip-9Uwgks-build/setup.py", line 416, > in > > setup_package() > >File "/tmp/.cache-walt/pip-9Uwgks-build/setup.py", line 396, > in setup_package > > from numpy.distutils.core import setup > >File > > > "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/__init__.py", > line 142, in > > from . import add_newdocs > >File > > > "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/add_newdocs.py", > > line 13, in > > from numpy.lib import add_newdoc > >File > > > "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/lib/__init__.py", > > line 8, in > > from .type_check import * > >File > > > "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/lib/type_check.py", > > line 11, in > > import numpy.core.numeric as _nx > >File > > > "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/core/__init__.py", > > line 26, in > > raise ImportError(msg) > > ImportError: > > Importing the multiarray numpy extension module failed. Most > > likely you are trying to import a failed build of numpy. > > If you're working with a numpy git repo, try `git clean -xdf` > (removes all > > files not under version control). Otherwise reinstall numpy. > > > > Original error was: /usr/lib/x86_64-linux-gnu/libblas.so.3: > undefined symbol: sgemv_thread_n > > > > Running setup.py install for scipy: finished with status > 'error' > > > > The system has OpenBLAS installed but with a newer version 0.3.2. > > > > Any ideas? > > > > I've built previous versions of Sage on this system before (with gcc > 7.3.0). > > > > Notice that there is a sagemath 8.3 in preparation for Debian, see : > https://people.debian.org/~thansen/debian-sage-status.html > > so perhaps you could lend a hand making it to unstable? > I'll take a look at it. > > jpuydt on irc.debian.org Regards, Jörg. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: GNU/Linux debian sid/testing: "Error building Sage" 8.3 from git
On Tuesday, August 14, 2018 at 4:39:52 PM UTC+2, Jörg-Volker wrote: > > > > On Tuesday, August 14, 2018 at 1:49:11 PM UTC+2, Erik Bray wrote: >> >> On Tue, Aug 14, 2018 at 12:48 PM Jörg-Volker wrote: >> > >> > On Tuesday, August 14, 2018 at 11:44:17 AM UTC+2, Dima Pasechnik wrote: >> >> >> >> I don't recall any reports on using gcc 8 to build Sage, so you are >> probably on your own here. >> >> The error message suggests that in fact building numpy failed. >> >> Could you post the corresponding log? >> > >> > >> > Thanks for looking into this. I append the numpy build log. To me it >> seems o.k. >> >> I suspect something went wrong even earlier, such as in the openblas >> build. It seems like it's trying to use the system's libblas: >> >> Original error was: /usr/lib/x86_64-linux-gnu/libblas.so.3: >> undefined symbol: sgemv_thread_n >> >> which it shouldn't be doing. >> > The build of openblas went fine. > Looking at the resulting .so files of the numpy build I see > >> ldd local/lib/python2.7/site-packages/numpy/linalg/lapack_lite.so >> linux-vdso.so.1 (0x7ffe77cfd000) >> libopenblas.so.0 => /tmp/sage/sage.git-8.3/local/lib/libopenblas.so.0 >> (0x7f8ee9a54000) >> liblapack.so.3 => /usr/lib/x86_64-linux-gnu/liblapack.so.3 >> (0x7f8ee93a9000) >> libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 >> (0x7f8ee934d000) >> libpython2.7.so.1.0 => >> /tmp/sage/sage.git-8.3/local/lib/libpython2.7.so.1.0 (0x7f8ee9147000) >> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 >> (0x7f8ee9126000) >> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8ee8f69000) >> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f8ee8dd3000) >> libgfortran.so.5 => /usr/lib/x86_64-linux-gnu/libgfortran.so.5 >> (0x7f8ee8b65000) >> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f8ee8b6) >> libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 >> (0x7f8ee8b5b000) >> /lib64/ld-linux-x86-64.so.2 (0x7f8eea65a000) >> libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 >> (0x7f8ee8b1a000) >> libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f8ee88fa000) >> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 >> (0x7f8ee88e) >> > This library is linked against the system libraries libblas.so and > liblapack.so, but also against > /tmp/sage/sage.git-8.3/local/lib/libopenblas.so.0 which does not match the > version of the system library /usr/lib/x86_64-linux-gnu/libblas.so.3 > The system libraries all belong to the system openblas package > (libopenblas-base for debian). The lapack library is missing in > $SAGE_ROOT/local/lib/. > > In my previous sage 8.2 installation the numpy so-file > linalg/lapack_lite.so is not linked against liblapack.so nor against > libblas.so, only against the local libopenblas.so.0 of sage 8.2. > > Any idea? > Regards, > Jörg. > > By the way, the same mismatch has happened with the R library lapack.so: > ldd ./local/lib/R/modules/lapack.so > linux-vdso.so.1 (0x7ffe99dc) > libR.so => /usr/lib/libR.so (0x7faf528ed000) > libopenblas.so.0 => /tmp/sage/sage.git-8.3/local/lib/libopenblas.so.0 > (0x7faf51cef000) > libgfortran.so.5 => /usr/lib/x86_64-linux-gnu/libgfortran.so.5 > (0x7faf51a81000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7faf518ed000) > libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 > (0x7faf518ac000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7faf516ef000) > libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 > (0x7faf51691000) > ... > This is the same in my previous sage installation version 8.2. But I didn't notice since I have not used R within sage. Regards, Jörg. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] GNU/Linux debian sid/testing: "Error building Sage" 8.3 from git
Hi, Le 14/08/2018 à 11:20, Jörg-Volker a écrit : Hi, trying to build Sage 8.3 on my GNU/Linux debian testing/sid system with local gcc suite version 8.2.0 fails while compiling scipy. This is on a desktop computer with 4 cores (8 threads) and 32 GB RAM. I have no clue what "testing/sid" might be... since as far as I know "sid==unstable" The build command was MAKE='make -j8' SAGE_INSTALL_GCC=no SAGE_BUILD_DIR=/tmp/sage-b make build The relevant log file shows Traceback (most recent call last): File "", line 1, in File "/tmp/.cache-walt/pip-9Uwgks-build/setup.py", line 416, in setup_package() File "/tmp/.cache-walt/pip-9Uwgks-build/setup.py", line 396, in setup_package from numpy.distutils.core import setup File "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/__init__.py", line 142, in from . import add_newdocs File "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/add_newdocs.py", line 13, in from numpy.lib import add_newdoc File "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/lib/__init__.py", line 8, in from .type_check import * File "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/lib/type_check.py", line 11, in import numpy.core.numeric as _nx File "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/core/__init__.py", line 26, in raise ImportError(msg) ImportError: Importing the multiarray numpy extension module failed. Most likely you are trying to import a failed build of numpy. If you're working with a numpy git repo, try `git clean -xdf` (removes all files not under version control). Otherwise reinstall numpy. Original error was: /usr/lib/x86_64-linux-gnu/libblas.so.3: undefined symbol: sgemv_thread_n Running setup.py install for scipy: finished with status 'error' The system has OpenBLAS installed but with a newer version 0.3.2. Any ideas? I've built previous versions of Sage on this system before (with gcc 7.3.0). Notice that there is a sagemath 8.3 in preparation for Debian, see : https://people.debian.org/~thansen/debian-sage-status.html so perhaps you could lend a hand making it to unstable? jpuydt on irc.debian.org -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: GNU/Linux debian sid/testing: "Error building Sage" 8.3 from git
On Tuesday, August 14, 2018 at 1:49:11 PM UTC+2, Erik Bray wrote: > > On Tue, Aug 14, 2018 at 12:48 PM Jörg-Volker > wrote: > > > > On Tuesday, August 14, 2018 at 11:44:17 AM UTC+2, Dima Pasechnik wrote: > >> > >> I don't recall any reports on using gcc 8 to build Sage, so you are > probably on your own here. > >> The error message suggests that in fact building numpy failed. > >> Could you post the corresponding log? > > > > > > Thanks for looking into this. I append the numpy build log. To me it > seems o.k. > > I suspect something went wrong even earlier, such as in the openblas > build. It seems like it's trying to use the system's libblas: > > Original error was: /usr/lib/x86_64-linux-gnu/libblas.so.3: > undefined symbol: sgemv_thread_n > > which it shouldn't be doing. > The build of openblas went fine. Looking at the resulting .so files of the numpy build I see > ldd local/lib/python2.7/site-packages/numpy/linalg/lapack_lite.so > linux-vdso.so.1 (0x7ffe77cfd000) > libopenblas.so.0 => /tmp/sage/sage.git-8.3/local/lib/libopenblas.so.0 > (0x7f8ee9a54000) > liblapack.so.3 => /usr/lib/x86_64-linux-gnu/liblapack.so.3 > (0x7f8ee93a9000) > libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 > (0x7f8ee934d000) > libpython2.7.so.1.0 => > /tmp/sage/sage.git-8.3/local/lib/libpython2.7.so.1.0 (0x7f8ee9147000) > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > (0x7f8ee9126000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8ee8f69000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f8ee8dd3000) > libgfortran.so.5 => /usr/lib/x86_64-linux-gnu/libgfortran.so.5 > (0x7f8ee8b65000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f8ee8b6) > libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f8ee8b5b000) > /lib64/ld-linux-x86-64.so.2 (0x7f8eea65a000) > libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 > (0x7f8ee8b1a000) > libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f8ee88fa000) > libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 > (0x7f8ee88e) > This library is linked against the system libraries libblas.so and liblapack.so, but also against /tmp/sage/sage.git-8.3/local/lib/libopenblas.so.0 which does not match the version of the system library /usr/lib/x86_64-linux-gnu/libblas.so.3 The system libraries all belong to the system openblas package (libopenblas-base for debian). The lapack library is missing in $SAGE_ROOT/local/lib/. In my previous sage 8.2 installation the numpy so-file linalg/lapack_lite.so is not linked against liblapack.so nor against libblas.so, only against the local libopenblas.so.0 of sage 8.2. Any idea? Regards, Jörg. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Start a Sage session from a session of its own Python interpreter ?
On Tue, Aug 14, 2018 at 6:57 AM, Emmanuel Charpentier wrote: >> On Tue, Aug 14, 2018 at 3:21 PM Erik Bray wrote: >> > On Mon, Aug 13, 2018 at 7:07 PM Emmanuel Charpentier >> They might >> also be amenable to a patch. It might not even need to be >> Sage-specific; for example maybe it would be good to have an interface >> transforming inputs prior to passing to the Python interpreter (as >> IPython provides, allowing us to slip in Sage's preparse()). > > > I'll have to read (a lot), and possibly write some trial code before I can > know what I don't know/understand... (in other words, I'm too ignorant to > assess the magnitude of my ignorance...). > > Possible alternative : would it be possible to write a dedicated wrapper > library with the same interface as the standard (?) python library doing > this preprocessing, thus offering to Python-enabled programs (many exist, it > seems...) an interface they can use directly ? Outside reticulate, I have a > few possibilities in mind (among them Pythontex, which might benefit from > such an addition...). +1 ! Making "the Sage preparser" actually a standard Python library (on pypi, etc.) that Sage depends on is one of the things I've long wished would happen. It would be fantastic to optionally provide our preparser functionality outside of Sage. E.g., imagine somebody using sympy and having the option to use a configured-for-sympy version of the preparser, for easier entry of formulas. I've cc'd Robert Bradshaw, in case he has any thoughts, since he and I mostly wrote the preparser. -- William -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Start a Sage session from a session of its own Python interpreter ?
Dear Erik, Thank you *ery* *much*. Comments below... Le mardi 14 août 2018 15:45:00 UTC+2, Erik Bray a écrit : > > On Tue, Aug 14, 2018 at 3:21 PM Erik Bray > wrote: > > > > On Mon, Aug 13, 2018 at 7:07 PM Emmanuel Charpentier > > > wrote: > > > > > > Motivation : see this ask.sagemath.org question. > > > Tl;dr : I want to call sage from the R reticulate package in order to > create mixed text/R/Sage documents. > > > > > > I am aware that Sagetex allows this, at least when using Sage's R in a > \LaTeX document. > > > But this solution doesn't extend to noweb Markdown documents, which > are more and more in demand (Web pages, ebooks, other interactive gadgets). > > > I have checked that the \LaTeX--> Markdown/whatever conversion > currently doable with pandoc or similar tools is cumbersome to the extreme > and/or loses a lot of information. > > > > > > Done so far : when used as the "Python" interpreter, Sage starts a > Python session of its own interpreter (i. e. doesn't start the usual > IPython session). The various environment variables are correctly defined. > > > > > > Thanks to Thierry Monteil, I have been able to create this Sage > IPython session, with correct initialization (preparsing, imports, etc...). > I have checked that this session can access R objects, and that the R > session can access objects created in Sage. > > > > > > But this is insufficient : > > > > > > The Sage session does not (re-)starts automatically : one has to > explicitly call IPython.embed(). Not a problem when tran manually ; > problematic for the intended use (creating Sage code chunks in a noweb > document). > > > To get back to R, you have to exit twice : from the IPython session > then from the Python session. Again not a problem in interactive use, again > a serious problem for the intended use. > > > > > > So the question is : how can one *replace* the Python REPL with > Sage's ? A serious look at $SAGE_ROOT/src/sage/repl/ipython_extension.py > wasn't specially enlightening... > > > > > > Any ideas ? > > > > > > [ Note that this answer is necessary to the "right" function, but not > sufficient : the name of the Python object interfacing Python to the > *calling* R session is, unfortunately "r". Which is the standard name we > have picked for our *called* R interpreter... So some r-handling will be > necessary from reticulate's side. Keeping the distinction between those may > be necessary (e. g. : reusing old code...). > > > But I feel that asking for a patch has better chances if we "do our > homework first", by solving *our* side of the problem *before* asking for > help... ] > > > > Did you try my suggestion of just setting > `use_python(/path/to/sage-ipython)`? > > I'm not an R expert, so take with a grain of salt, but I spent a few > minutes reading the sources for reticulate and understanding how it > works, That was my next step... > and I don't think my above suggestion will help you much (nor > will most of the things you've tried). > > It mostly just uses the interpreter path passed to use_python() to run > a little Python script that it then uses to determine a few more > things about the Python in question. Most importantly, it calls that > Python to determine the correct libpython shared library to use. It > then dlopens() the appropriate libpython, and from then on uses the > Python C API to initialize and communicate with a Python interpreter > (including bringing up the REPL, as necessary). Most Python code you > send through it is just passed directly to the Python interpreter > through the C API, so of course things like the Sage preparsing won't > work, etc. > > Sure, you can drop into an interactive REPL, and call IPython.embed(), > and you'll get an IPython REPL and all the trappings thereof, but that > will only work for interactive use. > > I noticed that reticulate also comes with helper functions like > use_virtualenv() and use_condaenv(). It might be useful to add a > similar use_sageenv(), which would set the appropriate environment > variables (SAGE_ROOT, etc.) and tell reticulate to use Sage's Python. > But then to get things like preparsing working you'll have to write > wrappers around most of reticulate's other APIs as well. Nice idea. I'l have first to learn what is a "Python environment...". > They might > also be amenable to a patch. It might not even need to be > Sage-specific; for example maybe it would be good to have an interface > transforming inputs prior to passing to the Python interpreter (as > IPython provides, allowing us to slip in Sage's preparse()). > I'll have to read (a lot), and possibly write some trial code before I can know what I don't know/understand... (in other words, I'm too ignorant to assess the magnitude of my ignorance...). Possible alternative : would it be possible to write a dedicated wrapper library with the same interface as the standard
Re: [sage-devel] Start a Sage session from a session of its own Python interpreter ?
Le mardi 14 août 2018 15:21:48 UTC+2, Erik Bray a écrit : > > On Mon, Aug 13, 2018 at 7:07 PM Emmanuel Charpentier > > wrote: > > > > Motivation : see this ask.sagemath.org question. > > Tl;dr : I want to call sage from the R reticulate package in order to > create mixed text/R/Sage documents. > > > > I am aware that Sagetex allows this, at least when using Sage's R in a > \LaTeX document. > > But this solution doesn't extend to noweb Markdown documents, which are > more and more in demand (Web pages, ebooks, other interactive gadgets). > > I have checked that the \LaTeX--> Markdown/whatever conversion currently > doable with pandoc or similar tools is cumbersome to the extreme and/or > loses a lot of information. > > > > Done so far : when used as the "Python" interpreter, Sage starts a > Python session of its own interpreter (i. e. doesn't start the usual > IPython session). The various environment variables are correctly defined. > > > > Thanks to Thierry Monteil, I have been able to create this Sage IPython > session, with correct initialization (preparsing, imports, etc...). I have > checked that this session can access R objects, and that the R session can > access objects created in Sage. > > > > But this is insufficient : > > > > The Sage session does not (re-)starts automatically : one has to > explicitly call IPython.embed(). Not a problem when tran manually ; > problematic for the intended use (creating Sage code chunks in a noweb > document). > > To get back to R, you have to exit twice : from the IPython session then > from the Python session. Again not a problem in interactive use, again a > serious problem for the intended use. > > > > So the question is : how can one *replace* the Python REPL with Sage's > ? A serious look at $SAGE_ROOT/src/sage/repl/ipython_extension.py wasn't > specially enlightening... > > > > Any ideas ? > > > > [ Note that this answer is necessary to the "right" function, but not > sufficient : the name of the Python object interfacing Python to the > *calling* R session is, unfortunately "r". Which is the standard name we > have picked for our *called* R interpreter... So some r-handling will be > necessary from reticulate's side. Keeping the distinction between those may > be necessary (e. g. : reusing old code...). > > But I feel that asking for a patch has better chances if we "do our > homework first", by solving *our* side of the problem *before* asking for > help... ] > > Did you try my suggestion of just setting > `use_python(/path/to/sage-ipython)`? > Yes, I did, with the same results : I can (more or less easily) get a working Sage (i. e. access at least to SR and associated functins), but no preparser. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Start a Sage session from a session of its own Python interpreter ?
On Tue, Aug 14, 2018 at 3:21 PM Erik Bray wrote: > > On Mon, Aug 13, 2018 at 7:07 PM Emmanuel Charpentier > wrote: > > > > Motivation : see this ask.sagemath.org question. > > Tl;dr : I want to call sage from the R reticulate package in order to > > create mixed text/R/Sage documents. > > > > I am aware that Sagetex allows this, at least when using Sage's R in a > > \LaTeX document. > > But this solution doesn't extend to noweb Markdown documents, which are > > more and more in demand (Web pages, ebooks, other interactive gadgets). > > I have checked that the \LaTeX--> Markdown/whatever conversion currently > > doable with pandoc or similar tools is cumbersome to the extreme and/or > > loses a lot of information. > > > > Done so far : when used as the "Python" interpreter, Sage starts a Python > > session of its own interpreter (i. e. doesn't start the usual IPython > > session). The various environment variables are correctly defined. > > > > Thanks to Thierry Monteil, I have been able to create this Sage IPython > > session, with correct initialization (preparsing, imports, etc...). I have > > checked that this session can access R objects, and that the R session can > > access objects created in Sage. > > > > But this is insufficient : > > > > The Sage session does not (re-)starts automatically : one has to explicitly > > call IPython.embed(). Not a problem when tran manually ; problematic for > > the intended use (creating Sage code chunks in a noweb document). > > To get back to R, you have to exit twice : from the IPython session then > > from the Python session. Again not a problem in interactive use, again a > > serious problem for the intended use. > > > > So the question is : how can one *replace* the Python REPL with Sage's ? A > > serious look at $SAGE_ROOT/src/sage/repl/ipython_extension.py wasn't > > specially enlightening... > > > > Any ideas ? > > > > [ Note that this answer is necessary to the "right" function, but not > > sufficient : the name of the Python object interfacing Python to the > > *calling* R session is, unfortunately "r". Which is the standard name we > > have picked for our *called* R interpreter... So some r-handling will be > > necessary from reticulate's side. Keeping the distinction between those may > > be necessary (e. g. : reusing old code...). > > But I feel that asking for a patch has better chances if we "do our > > homework first", by solving *our* side of the problem *before* asking for > > help... ] > > Did you try my suggestion of just setting `use_python(/path/to/sage-ipython)`? I'm not an R expert, so take with a grain of salt, but I spent a few minutes reading the sources for reticulate and understanding how it works, and I don't think my above suggestion will help you much (nor will most of the things you've tried). It mostly just uses the interpreter path passed to use_python() to run a little Python script that it then uses to determine a few more things about the Python in question. Most importantly, it calls that Python to determine the correct libpython shared library to use. It then dlopens() the appropriate libpython, and from then on uses the Python C API to initialize and communicate with a Python interpreter (including bringing up the REPL, as necessary). Most Python code you send through it is just passed directly to the Python interpreter through the C API, so of course things like the Sage preparsing won't work, etc. Sure, you can drop into an interactive REPL, and call IPython.embed(), and you'll get an IPython REPL and all the trappings thereof, but that will only work for interactive use. I noticed that reticulate also comes with helper functions like use_virtualenv() and use_condaenv(). It might be useful to add a similar use_sageenv(), which would set the appropriate environment variables (SAGE_ROOT, etc.) and tell reticulate to use Sage's Python. But then to get things like preparsing working you'll have to write wrappers around most of reticulate's other APIs as well. They might also be amenable to a patch. It might not even need to be Sage-specific; for example maybe it would be good to have an interface transforming inputs prior to passing to the Python interpreter (as IPython provides, allowing us to slip in Sage's preparse()). -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Start a Sage session from a session of its own Python interpreter ?
On Mon, Aug 13, 2018 at 7:07 PM Emmanuel Charpentier wrote: > > Motivation : see this ask.sagemath.org question. > Tl;dr : I want to call sage from the R reticulate package in order to create > mixed text/R/Sage documents. > > I am aware that Sagetex allows this, at least when using Sage's R in a \LaTeX > document. > But this solution doesn't extend to noweb Markdown documents, which are more > and more in demand (Web pages, ebooks, other interactive gadgets). > I have checked that the \LaTeX--> Markdown/whatever conversion currently > doable with pandoc or similar tools is cumbersome to the extreme and/or loses > a lot of information. > > Done so far : when used as the "Python" interpreter, Sage starts a Python > session of its own interpreter (i. e. doesn't start the usual IPython > session). The various environment variables are correctly defined. > > Thanks to Thierry Monteil, I have been able to create this Sage IPython > session, with correct initialization (preparsing, imports, etc...). I have > checked that this session can access R objects, and that the R session can > access objects created in Sage. > > But this is insufficient : > > The Sage session does not (re-)starts automatically : one has to explicitly > call IPython.embed(). Not a problem when tran manually ; problematic for the > intended use (creating Sage code chunks in a noweb document). > To get back to R, you have to exit twice : from the IPython session then from > the Python session. Again not a problem in interactive use, again a serious > problem for the intended use. > > So the question is : how can one *replace* the Python REPL with Sage's ? A > serious look at $SAGE_ROOT/src/sage/repl/ipython_extension.py wasn't > specially enlightening... > > Any ideas ? > > [ Note that this answer is necessary to the "right" function, but not > sufficient : the name of the Python object interfacing Python to the > *calling* R session is, unfortunately "r". Which is the standard name we have > picked for our *called* R interpreter... So some r-handling will be necessary > from reticulate's side. Keeping the distinction between those may be > necessary (e. g. : reusing old code...). > But I feel that asking for a patch has better chances if we "do our homework > first", by solving *our* side of the problem *before* asking for help... ] Did you try my suggestion of just setting `use_python(/path/to/sage-ipython)`? -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: GNU/Linux debian sid/testing: "Error building Sage" 8.3 from git
On Tue, Aug 14, 2018 at 12:48 PM Jörg-Volker wrote: > > On Tuesday, August 14, 2018 at 11:44:17 AM UTC+2, Dima Pasechnik wrote: >> >> I don't recall any reports on using gcc 8 to build Sage, so you are probably >> on your own here. >> The error message suggests that in fact building numpy failed. >> Could you post the corresponding log? > > > Thanks for looking into this. I append the numpy build log. To me it seems > o.k. I suspect something went wrong even earlier, such as in the openblas build. It seems like it's trying to use the system's libblas: Original error was: /usr/lib/x86_64-linux-gnu/libblas.so.3: undefined symbol: sgemv_thread_n which it shouldn't be doing. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: GNU/Linux debian sid/testing: "Error building Sage" 8.3 from git
I don't recall any reports on using gcc 8 to build Sage, so you are probably on your own here. The error message suggests that in fact building numpy failed. Could you post the corresponding log? On Tuesday, August 14, 2018 at 12:20:36 PM UTC+3, Jörg-Volker wrote: > > > Hi, > trying to build Sage 8.3 on my GNU/Linux debian testing/sid system with > local gcc suite version 8.2.0 fails while compiling scipy. This is on a > desktop computer with 4 cores (8 threads) and 32 GB RAM. > > The build command was > > MAKE='make -j8' SAGE_INSTALL_GCC=no SAGE_BUILD_DIR=/tmp/sage-b make build >> > > The relevant log file shows > > Traceback (most recent call last): >> File "", line 1, in >> File "*/tmp/*.cache-walt/pip-9Uwgks-build/setup.py", line 416, in >> >> setup_package() >> File "*/tmp/*.cache-walt/pip-9Uwgks-build/setup.py", line 396, in >> setup_package >> from numpy.distutils.core import setup >> File >> "*/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/*__init__.py", >> line 142, in >> from . import add_newdocs >> File >> "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/add_newdocs.py", >> line 13, in >> from numpy.lib import add_newdoc >> File >> "*/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/lib/*__init__.py", >> line 8, in >> from .type_check import * >> File >> "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/lib/type_check.py", >> line 11, in >> import numpy.core.numeric as _nx >> File >> "*/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/core/*__init__.py", >> line 26, in >> raise ImportError(msg) >> ImportError: >> Importing the multiarray numpy extension module failed. Most >> likely you are trying to import a failed build of numpy. >> If you're working with a numpy git repo, try `git clean -xdf` (removes >> all >> files not under version control). Otherwise reinstall numpy. >> >> Original error was: /usr/lib/x86_64-linux-gnu/libblas.so.3: undefined >> symbol: sgemv_thread_n >> >> Running setup.py install for scipy: finished with status 'error' >> >> > > The system has OpenBLAS installed but with a newer version 0.3.2. > > > > Any ideas? > > > > I've built previous versions of Sage on this system before (with gcc 7.3.0). > > > > Regards, > Jörg. > > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] GNU/Linux debian sid/testing: "Error building Sage" 8.3 from git
Hi, trying to build Sage 8.3 on my GNU/Linux debian testing/sid system with local gcc suite version 8.2.0 fails while compiling scipy. This is on a desktop computer with 4 cores (8 threads) and 32 GB RAM. The build command was MAKE='make -j8' SAGE_INSTALL_GCC=no SAGE_BUILD_DIR=/tmp/sage-b make build > The relevant log file shows Traceback (most recent call last): > File "", line 1, in > File "*/tmp/*.cache-walt/pip-9Uwgks-build/setup.py", line 416, in > > setup_package() > File "*/tmp/*.cache-walt/pip-9Uwgks-build/setup.py", line 396, in > setup_package > from numpy.distutils.core import setup > File > "*/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/*__init__.py", > line 142, in > from . import add_newdocs > File > "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/add_newdocs.py", > line 13, in > from numpy.lib import add_newdoc > File > "*/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/lib/*__init__.py", > line 8, in > from .type_check import * > File > "/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/lib/type_check.py", > line 11, in > import numpy.core.numeric as _nx > File > "*/tmp/sage/sage.git-8.3/local/lib/python2.7/site-packages/numpy/core/*__init__.py", > line 26, in > raise ImportError(msg) > ImportError: > Importing the multiarray numpy extension module failed. Most > likely you are trying to import a failed build of numpy. > If you're working with a numpy git repo, try `git clean -xdf` (removes all > files not under version control). Otherwise reinstall numpy. > > Original error was: /usr/lib/x86_64-linux-gnu/libblas.so.3: undefined > symbol: sgemv_thread_n > > Running setup.py install for scipy: finished with status 'error' > > The system has OpenBLAS installed but with a newer version 0.3.2. Any ideas? I've built previous versions of Sage on this system before (with gcc 7.3.0). Regards, Jörg. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. Found local metadata for scipy-0.19.1 Using cached file /tmp/sage/sage.git-8.3/upstream/scipy-0.19.1.tar.gz scipy-0.19.1 Setting up build directory for scipy-0.19.1 Finished extraction No patch files found in ../patches Host system: Linux uruz 4.17.12 #2 SMP Fri Aug 3 09:43:08 CEST 2018 x86_64 GNU/Linux C compiler: gcc C compiler version: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 8.2.0 (Debian 8.2.0-2) No record that 'scipy' was ever installed; skipping uninstall Note: CFLAGS, CXXFLAGS and SHAREDFLAGS are taken from distutils, so their current settings are ignored. Installing scipy-0.19.1 Installing package scipy using pip2 Waiting for shared lock to run pip2 install --ignore-installed --verbose --no-deps --no-index --isolated . ... ok Ignoring indexes: https://pypi.python.org/simple Processing /tmp/sage-b/scipy-0.19.1/src Running setup.py (path:/tmp/.cache-walt/pip-9Uwgks-build/setup.py) egg_info for package from file:///tmp/sage-b/scipy-0.19.1/src Running command python setup.py egg_info running egg_info creating
[sage-devel] Re: OS X build attempt: Error building openblas-0.2.20.p2
see https://groups.google.com/d/msg/sage-devel/3p0aucx_hjI/ddff2Ms_BwAJ (I guess it's a rogue g77 to blame) On Tuesday, August 14, 2018 at 10:10:11 AM UTC+3, Bernie Walp wrote: > > On macOS High Sierra ver. 10.13.6, my attempt to build Sage 8.3 fails with > "Error building openblas-0.2.20.p2". The log is attached. > > Surely I'm missing something simple? > > Thanks, > B.W. > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Broken 8.3 build
You need a system-wide python installed. Indeed, patch.log says: Found local metadata for patch-2.7.5 /usr/bin/env: 'python': No such file or directory Error downloading patch-2.7.5.tar.gz So you need to run sudo apt-get install python python is not mentioned in http://doc.sagemath.org/html/en/installation/source.html#system-specific-requirements but is mentioned in http://doc.sagemath.org/html/en/installation/source.html#command-line-tools I guess it's very unusual not to have any python on the box nowadays... On Tuesday, August 14, 2018 at 10:10:11 AM UTC+3, rob.w...@gmail.com wrote: > > I have a Dell G7 with Lubuntu 18.04 and MAKE='make -j9' make returned as > shown below. > Thanks for your help. > > > make[1]: Entering directory '/home/rob/sage-8.3/build/make' > sage-logger -p 'sage-spkg patch-2.7.5' > '/home/rob/sage-8.3/logs/pkgs/patch-2.7.5.log' > [patch-2.7.5] Found local metadata for patch-2.7.5 > [patch-2.7.5] /usr/bin/env: 'python': No such file or directory > [patch-2.7.5] > > [patch-2.7.5] Error downloading patch-2.7.5.tar.gz > [patch-2.7.5] > > [patch-2.7.5] Please email sage-devel ( > http://groups.google.com/group/sage-devel) > [patch-2.7.5] explaining the problem and including the log file > [patch-2.7.5] /home/rob/sage-8.3/logs/pkgs/patch-2.7.5.log > [patch-2.7.5] Describe your computer, operating system, etc. > [patch-2.7.5] > > Makefile:2058: recipe for target > '/home/rob/sage-8.3/local/var/lib/sage/installed/patch-2.7.5' failed > make[1]: *** [/home/rob/sage-8.3/local/var/lib/sage/installed/patch-2.7.5] > Error 1 > make[1]: Leaving directory '/home/rob/sage-8.3/build/make' > > real 0m0.056s > user 0m0.061s > sys 0m0.003s > *** > Error building Sage. > > The following package(s) may have failed to build (not necessarily > during this run of 'make base-toolchain'): > > * package: patch-2.7.5 > log file: /home/rob/sage-8.3/logs/pkgs/patch-2.7.5.log > build directory: /home/rob/sage-8.3/local/var/tmp/sage/build/patch-2.7.5 > > The build directory may contain configuration files and other potentially > helpful information. WARNING: if you now run 'make' again, the build > directory will, by default, be deleted. Set the environment variable > SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this. > > Makefile:31: recipe for target 'base-toolchain' failed > make: *** [base-toolchain] Error 1 > > > -- > The Great Secret? > "It is, and It isn't." > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: OS X build: "sorry, unimplemented: 64-bit mode not compiled in"
It seems that you have g77 installed and in your PATH, and it does not work with openblas. In the line causing the error: g77 -O2 -Wall -m64 -fPIC -c -o lsametst.o lsametst.f I would expect gfortran instead of g77. Have you got gfrortan Sage package installed? (do you have logs/pkgs/gfortran* present?) On Tuesday, August 14, 2018 at 10:10:11 AM UTC+3, Bernie Walp wrote: > > Attempts to build Sage 8.3 in macOS "High Sierra" ver. 10.13.6 produce the > message "Error building openblas-0.2.20.p2" and also this: > > lsame.f:0: sorry, unimplemented: 64-bit mode not compiled in > lsametst.f:0: sorry, unimplemented: 64-bit mode not compiled in > > The log is attached. I'd be grateful for any advice. Thank you. > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Broken 8.3 build
I have a Dell G7 with Lubuntu 18.04 and MAKE='make -j9' make returned as shown below. Thanks for your help. make[1]: Entering directory '/home/rob/sage-8.3/build/make' sage-logger -p 'sage-spkg patch-2.7.5' '/home/rob/sage-8.3/logs/pkgs/patch-2.7.5.log' [patch-2.7.5] Found local metadata for patch-2.7.5 [patch-2.7.5] /usr/bin/env: 'python': No such file or directory [patch-2.7.5] [patch-2.7.5] Error downloading patch-2.7.5.tar.gz [patch-2.7.5] [patch-2.7.5] Please email sage-devel (http://groups.google.com/group/sage-devel) [patch-2.7.5] explaining the problem and including the log file [patch-2.7.5] /home/rob/sage-8.3/logs/pkgs/patch-2.7.5.log [patch-2.7.5] Describe your computer, operating system, etc. [patch-2.7.5] Makefile:2058: recipe for target '/home/rob/sage-8.3/local/var/lib/sage/installed/patch-2.7.5' failed make[1]: *** [/home/rob/sage-8.3/local/var/lib/sage/installed/patch-2.7.5] Error 1 make[1]: Leaving directory '/home/rob/sage-8.3/build/make' real 0m0.056s user 0m0.061s sys 0m0.003s *** Error building Sage. The following package(s) may have failed to build (not necessarily during this run of 'make base-toolchain'): * package: patch-2.7.5 log file: /home/rob/sage-8.3/logs/pkgs/patch-2.7.5.log build directory: /home/rob/sage-8.3/local/var/tmp/sage/build/patch-2.7.5 The build directory may contain configuration files and other potentially helpful information. WARNING: if you now run 'make' again, the build directory will, by default, be deleted. Set the environment variable SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this. Makefile:31: recipe for target 'base-toolchain' failed make: *** [base-toolchain] Error 1 -- The Great Secret? "It is, and It isn't." -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. *** ALL ENVIRONMENT VARIABLES BEFORE BUILD: *** COLORTERM=truecolor CONFIGURED_CC=gcc CONFIGURED_CXX=g++ CONFIGURED_FC=gfortran CONFIGURED_OBJC=gcc CONFIGURED_OBJCXX=g++ DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DESKTOP_SESSION=Lubuntu DISPLAY=:0.0 GDM_LANG=en_US GDMSESSION=Lubuntu GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1 GTK_OVERLAY_SCROLLING=0 HOME=/home/rob LANG=en_US.UTF-8 LANGUAGE=en_US LESSCLOSE=/usr/bin/lesspipe %s %s LESSOPEN=| /usr/bin/lesspipe %s LOGNAME=rob LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36: _LXSESSION_PID=881 MAKEFLAGS= V=1 MAKELEVEL=1 MAKE=make -j9 MAKE_TERMERR=/dev/pts/0 MAKE_TERMOUT=/dev/pts/0 MFLAGS= OLDPWD=/home/rob/sage-8.3 PATH=/home/rob/sage-8.3/build/bin:/home/rob/sage-8.3/src/bin:/home/rob/sage-8.3/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games PWD=/home/rob/sage-8.3/build/make PYTHONPATH=/home/rob/sage-8.3/local QT_PLATFORM_PLUGIN=lxqt QT_QPA_PLATFORMTHEME=lxqt QT_STYLE_OVERRIDE=gtk SAGE_EXTCODE=/home/rob/sage-8.3/local/share/sage/ext SAGE_LOCAL=/home/rob/sage-8.3/local
