[sage-devel] NTL 11.4.0
A new version of NTL is available. Details here: https://www.shoup.net/ntl/doc/tour-changes.html -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/932b840e-2b9b-4fce-90d5-91bad33c50d8%40googlegroups.com.
Re: [sage-devel] Re: Build failure at matplotlib-2.2.4 and sagenb-1.1.2 on OS X
On Tue, Sep 24, 2019 at 8:54 PM Ben Salisbury wrote: > > Trying "./sage -f libpng" first did not work. But there are new errors this > time! hmm, in the scipy log one sees > ld: library not found for -lSystem coming from gfortran, more precisely, from /Users/salis1bt/sage-git/local/bin/gfortran So it looks as if gfortran you built in the process is broken. What is the output of otool -L /Users/salis1bt/sage-git/local/bin/gfortran ? > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/bdf45658-3498-4642-9010-dd56bbc32e89%40googlegroups.com. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq08ZynUwJsaLkNX187BcdsV4zP%3DPxoLqjaP1dkZaV8apg%40mail.gmail.com.
[sage-devel] Re: Coexistence of py2 and py3
Hi Dima, On 2019-09-24, Dima Pasechnik wrote: > I'm surprised that *.c files created by Cython for pyX may be used for > py(5-X) without many problems. > I'd expect this to break down totally... Indeed. It is surprising that I only got two kinds of spurious errors: In one place, a pickle of a dictionary was unpickled apparently as a string, and sometimes was identical to . But not much else. Anyway, first tests seem to indicate that the problems vanish when changing setup.py so that creation of .c files takes place in different folders for different python versions. Best regards, Simon -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/qmdrkr%242g0s%241%40blaine.gmane.org.
Re: [sage-devel] Re: Build failure at matplotlib-2.2.4 and sagenb-1.1.2 on OS X
by the way, there is https://trac.sagemath.org/ticket/28513 where I proposed a fix for this sort of error -- least the error message is much more clear... On Tue, Sep 24, 2019 at 6:53 PM John H Palmieri wrote: > > > > On Tuesday, September 24, 2019 at 10:12:17 AM UTC-7, Ben Salisbury wrote: >> >> Hi, >> >> I'm attempting to build Sage from the develop branch on a new office >> computer running OS X 10.14.6. I've installed Xcode and Command Line Tools >> (or at least I thought I had), and I'm getting a build failure at >> sagenb-1.1.2. The log files for sagenb-1.1.2 and for matplotlib-2.2.4.p0 >> have been attached. Any ideas on how to fix? >> >> Ben > > > matplotlib is complaining about png, so you could try "./sage -f libpng". (It > should have been installed already, but maybe something went wrong.) Then try > "make" again. > > The sagenb error says things like >> >> >> The full traceback has been saved in >> /var/folders/d0/bbf0zvnn43b4_fhtkznp_yycgp/T/sphinx-err-ZfIXOy.log, if >> you want to report the issue to the developers. > > > Can you post that file? > > By the way, does "git" work from the command-line? How about "gcc"? I just > recently did a system upgrade on OS X, and I had to rerun Xcode to get the > command-line tools to function — it wanted me to click on a licensing > agreement or something like that. > > -- > John > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/04c4706c-f5d1-42a7-b3db-abdceef51b29%40googlegroups.com. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq1zAkmFtNuqvruV%3DEn-eLhb1XPbX5X1ZUiVzKkKBORwpA%40mail.gmail.com.
[sage-devel] Re: Build failure at matplotlib-2.2.4 and sagenb-1.1.2 on OS X
I'll try "./sage -f libpng". In the meantime, I've attached the log file requested. Also: mth153844pe212:~ salis1bt$ git --version git version 2.20.1 (Apple Git-117) mth153844pe212:~ salis1bt$ gcc --version Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx -include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/ include/c++/4.2.1 Apple LLVM version 10.0.1 (clang-1001.0.46.4) Target: x86_64-apple-darwin18.7.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/89658673-6673-4e8f-a961-ee4fa39b314c%40googlegroups.com. # Sphinx version: 1.8.5 # Python version: 2.7.15 (CPython) # Docutils version: 0.14 # Jinja2 version: 2.10 # Last messages: # Running Sphinx v1.8.5 # making output directory... # building [mo]: targets for 0 po files that are out of date # building [html]: targets for 19 source files that are out of date # updating environment: # 19 added, 0 changed, 0 removed # reading sources... [ 5%] index # reading sources... [ 10%] misc/introspect # reading sources... [ 15%] misc/misc # Loaded extensions: # sphinx.ext.mathjax (1.8.5) from /Users/salis1bt/sage-git/local/lib/python2.7/site-packages/sphinx/ext/mathjax.pyc # alabaster (0.7.12) from /Users/salis1bt/sage-git/local/lib/python2.7/site-packages/alabaster/__init__.pyc # sphinx.ext.viewcode (1.8.5) from /Users/salis1bt/sage-git/local/lib/python2.7/site-packages/sphinx/ext/viewcode.pyc # sphinx.ext.autodoc (1.8.5) from /Users/salis1bt/sage-git/local/lib/python2.7/site-packages/sphinx/ext/autodoc/__init__.pyc # sphinx.ext.todo (1.8.5) from /Users/salis1bt/sage-git/local/lib/python2.7/site-packages/sphinx/ext/todo.pyc Traceback (most recent call last): File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/sphinx/cmd/build.py", line 304, in build_main app.build(args.force_all, filenames) File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/sphinx/application.py", line 341, in build self.builder.build_update() File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 347, in build_update len(to_build)) File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 360, in build updated_docnames = set(self.read()) File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 468, in read self._read_serial(docnames) File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 490, in _read_serial self.read_doc(docname) File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 534, in read_doc doctree = read_doc(self.app, self.env, self.env.doc2path(docname)) File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/sphinx/io.py", line 318, in read_doc pub.publish() File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/docutils/core.py", line 217, in publish self.settings) File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/docutils/readers/__init__.py", line 72, in read self.parse() File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/docutils/readers/__init__.py", line 78, in parse self.parser.parse(self.input, document) File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/sphinx/parsers.py", line 88, in parse self.statemachine.run(inputstring, document, inliner=self.inliner) File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 171, in run input_source=document['source']) File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/docutils/statemachine.py", line 239, in run context, state, transitions) File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/docutils/statemachine.py", line 460, in check_line return method(match, context, next_state) File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 2753, in underline self.section(title, source, style, lineno - 1, messages) File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 327, in section self.new_subsection(title, lineno, messages) File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 395, in new_subsection node=section_node, match_titles=True) File "/Users/salis1bt/sage-git/local/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 282, in
[sage-devel] Re: Build failure at matplotlib-2.2.4 and sagenb-1.1.2 on OS X
On Tuesday, September 24, 2019 at 10:12:17 AM UTC-7, Ben Salisbury wrote: > > Hi, > > I'm attempting to build Sage from the develop branch on a new office > computer running OS X 10.14.6. I've installed Xcode and Command Line Tools > (or at least I thought I had), and I'm getting a build failure at > sagenb-1.1.2. The log files for sagenb-1.1.2 and for matplotlib-2.2.4.p0 > have been attached. Any ideas on how to fix? > > Ben > matplotlib is complaining about png, so you could try "./sage -f libpng". (It should have been installed already, but maybe something went wrong.) Then try "make" again. The sagenb error says things like > > The full traceback has been saved in > /var/folders/d0/bbf0zvnn43b4_fhtkznp_yycgp/T/sphinx-err-ZfIXOy.log, if > you want to report the issue to the developers. > Can you post that file? By the way, does "git" work from the command-line? How about "gcc"? I just recently did a system upgrade on OS X, and I had to rerun Xcode to get the command-line tools to function — it wanted me to click on a licensing agreement or something like that. -- John -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/04c4706c-f5d1-42a7-b3db-abdceef51b29%40googlegroups.com.
Re: [sage-devel] Re: Coexistence of py2 and py3
I'm surprised that *.c files created by Cython for pyX may be used for py(5-X) without many problems. I'd expect this to break down totally... Dima On Tue, Sep 24, 2019 at 6:06 PM Simon King wrote: > > Hi Dima, > > On 2019-09-24, Dima Pasechnik wrote: > > Shouldn't coexisting installations like this have different --prefix ? > > Of course. But if I understand correctly, this only affects where stuff > is installed, not where it is built. The situation is as follows: > > - the .c files are created in the source directory, i.e., where the > corresponding .pyx files live. Therefore the .c files are only > re-generated when the .pyx file is touched, but not when the language > level changes. > - the .so files are created in build/lib.linux-x86_64-2.7 resp. -3.7, > hence, the paths do take into account the language level. This is of > course a good idea, but not enough (because of the .c files). > - eventually the .so files are installed in --prefix. > > The .c file can very well depend on the language level. E.g., in the Sage > library, compile time variables are used to tell Cython what code to > use for py2 and what code for py3. > > Hence, IMHO it is clearly a bug that the .c files are not by default > created in a path that depends on the language level. > > But I don't know where that bug should be reported. > > Best regards, > Simon > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/qmdiei%2479ou%241%40blaine.gmane.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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq1mZMcPo27u%2BHzzmzkdqeecRyxEnt1Uiavojd8F1xZycA%40mail.gmail.com.
[sage-devel] Re: Coexistence of py2 and py3
Hi Dima, On 2019-09-24, Dima Pasechnik wrote: > Shouldn't coexisting installations like this have different --prefix ? Of course. But if I understand correctly, this only affects where stuff is installed, not where it is built. The situation is as follows: - the .c files are created in the source directory, i.e., where the corresponding .pyx files live. Therefore the .c files are only re-generated when the .pyx file is touched, but not when the language level changes. - the .so files are created in build/lib.linux-x86_64-2.7 resp. -3.7, hence, the paths do take into account the language level. This is of course a good idea, but not enough (because of the .c files). - eventually the .so files are installed in --prefix. The .c file can very well depend on the language level. E.g., in the Sage library, compile time variables are used to tell Cython what code to use for py2 and what code for py3. Hence, IMHO it is clearly a bug that the .c files are not by default created in a path that depends on the language level. But I don't know where that bug should be reported. Best regards, Simon -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/qmdiei%2479ou%241%40blaine.gmane.org.
[sage-devel] Re: Coexistence of py2 and py3
Hi Vincent,
On 2019-09-24, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> Are you sure that the problem comes from the C files? If you erase
> them between the two installations what do you get?
That's what I'm testing now.
BTW, meanwhile I found that I can prescribe in my setup.py where to
create the .c files (the question in my post was how to do it):
cythonize(...,
build_dir=os.path.join("build","c_files-{}.{}".format(version_info.major,
version_info.minor)))
With this in setup.py, the .c files will be in build/c_files-2.7 resp.
in build/c_files-3.7, whereas (as before) the .so files are in
build/lib.linux-x86_64-2.7 resp. ... -3.7.
I will see if this is enough to solve the problem.
Best regards,
Simon
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/qmdhoe%244633%241%40blaine.gmane.org.
Re: [sage-devel] Coexistence of py2 and py3
Are you sure that the problem comes from the C files? If you erase them between the two installations what do you get? Le 24/09/2019 à 16:33, Dima Pasechnik a écrit : Shouldn't coexisting installations like this have different --prefix ? On Tue, 24 Sep 2019 15:29 Simon King, wrote: Hi! At #28414, I'm trying to upgrade my group cohomology package so that it works both on sage-with-py2 and sage-with-py3. On the laptop where I work on the new package version (I didn't publish the code yet), I have a py2 and a py3 installation of Sage. To build the package without the hassle of recompiling everything, I build the development version of my package by opening a Sage shell in the package's src folder, and then run sage -python setup.py build sage -pip install . --upgrade However, when I do the above in both versions of Sage (py2 and py3), then in the py2 version strange things happen. Namely: In some Cython modules of my package, one has str==unicode, which means that an explicit cast to str results in a unicode, which results in errors when passing it to functions from other modules expecting a str. Dima said on the ticket that he met similar confusions about str and unicode in the past, and he had the impression that it had to do with both Sage versions sharing the same $DOT_SAGE folder. However, the problem persists when I remove $DOT_SAGE. Although `sage -python setup.py build` does create the .so files in different folders for different python versions (namely build/temp.linux-x86_64-2.7 and build/temp.linux-x86_64-3.7), it creates the .c files in THE SAME directory (namely where it finds the corresponding .pyx files). My theory is that the confusion is caused by having the .c files in the same directory. But a duckduckgo search didn't tell me how to prescribe a different directory for the .c files (resp. the solutions I found, such as "python setup.py build --build-lib " didn't seem to work). Can you tell me how to prescribe a folder for the .c files? Best regards, Simon -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/qmd97s%2425hp%241%40blaine.gmane.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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/7f9b1ebc-75f6-fddf-b90f-be642d7b33ae%40gmail.com.
Re: [sage-devel] Coexistence of py2 and py3
Shouldn't coexisting installations like this have different --prefix ? On Tue, 24 Sep 2019 15:29 Simon King, wrote: > Hi! > > At #28414, I'm trying to upgrade my group cohomology package so that it > works both on sage-with-py2 and sage-with-py3. > > On the laptop where I work on the new package version (I didn't publish > the code yet), I have a py2 and a py3 installation of Sage. To build the > package without the hassle of recompiling everything, I build the > development version of my package by opening a Sage shell in the > package's src folder, and then run >sage -python setup.py build >sage -pip install . --upgrade > > However, when I do the above in both versions of Sage (py2 and py3), > then in the py2 version strange things happen. Namely: In some Cython > modules of my package, one has str==unicode, which means that an > explicit cast to str results in a unicode, which results in errors when > passing it to functions from other modules expecting a str. > > Dima said on the ticket that he met similar confusions about str and > unicode in the past, and he had the impression that it had to do with > both Sage versions sharing the same $DOT_SAGE folder. However, the > problem persists when I remove $DOT_SAGE. > > Although `sage -python setup.py build` does create the .so files in > different folders for different python versions (namely > build/temp.linux-x86_64-2.7 and build/temp.linux-x86_64-3.7), it creates > the .c files in THE SAME directory (namely where it finds the corresponding > .pyx files). > > My theory is that the confusion is caused by having the .c files in the > same directory. But a duckduckgo search didn't tell me how to prescribe > a different directory for the .c files (resp. the solutions I found, > such as "python setup.py build --build-lib " didn't > seem to work). > > Can you tell me how to prescribe a folder for the .c files? > > Best regards, > Simon > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/qmd97s%2425hp%241%40blaine.gmane.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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq3A5ommM8p%2Bqs3Pp3ii-gg%2B8z6msxUC%2BWoZEsEYryTutg%40mail.gmail.com.
[sage-devel] Coexistence of py2 and py3
Hi! At #28414, I'm trying to upgrade my group cohomology package so that it works both on sage-with-py2 and sage-with-py3. On the laptop where I work on the new package version (I didn't publish the code yet), I have a py2 and a py3 installation of Sage. To build the package without the hassle of recompiling everything, I build the development version of my package by opening a Sage shell in the package's src folder, and then run sage -python setup.py build sage -pip install . --upgrade However, when I do the above in both versions of Sage (py2 and py3), then in the py2 version strange things happen. Namely: In some Cython modules of my package, one has str==unicode, which means that an explicit cast to str results in a unicode, which results in errors when passing it to functions from other modules expecting a str. Dima said on the ticket that he met similar confusions about str and unicode in the past, and he had the impression that it had to do with both Sage versions sharing the same $DOT_SAGE folder. However, the problem persists when I remove $DOT_SAGE. Although `sage -python setup.py build` does create the .so files in different folders for different python versions (namely build/temp.linux-x86_64-2.7 and build/temp.linux-x86_64-3.7), it creates the .c files in THE SAME directory (namely where it finds the corresponding .pyx files). My theory is that the confusion is caused by having the .c files in the same directory. But a duckduckgo search didn't tell me how to prescribe a different directory for the .c files (resp. the solutions I found, such as "python setup.py build --build-lib " didn't seem to work). Can you tell me how to prescribe a folder for the .c files? Best regards, Simon -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/qmd97s%2425hp%241%40blaine.gmane.org.
[sage-devel] Re: Poll: three.js as the default 3d viewer in Sage
+1 to make threejs the default viewer. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/a1e8db42-e344-45f1-880c-2b97731ae3e3%40googlegroups.com.
