[sage-devel] Re: Installing pyopenssl for Sage 7.5.1 under Mac OS X 10.2.1 with xcode 8.2.1 not working
This seems to work with Sage 7.6. Somehow, it must have gotten fixed along
the way.
On Thursday, February 23, 2017 at 1:41:37 PM UTC-8, Dima Pasechnik wrote:
>
> looks like typical (by now) Apple's bug/feature --- using Objective C
> syntax (blocks?) in plain C headers.
>
>
> On Thursday, February 23, 2017 at 9:31:03 PM UTC, Matthias Goerner wrote:
>>
>> This seems to be specific to 10.12.1 and happens both for Sage 7.4 and
>> Sage 7.5.1.
>>
>> On Thursday, February 23, 2017 at 1:05:25 PM UTC-8, Matthias Goerner
>> wrote:
>>>
>>> I am trying to to install pyopenssl with:
>>> sage -i openssl
>>> sage -i -f python2
>>> sage -i pyopenssl
>>> but the last step fails. This seems to be a general problem with Sage
>>> 7.5.1 under Mac OS X 10.2.1 since this was also reported to me by someone
>>> else with the same configuration. The above steps worked with Sage 7.4 a
>>> couple of months ago.
>>>
>>> ...
>>> sage-logger -p 'sage --pip install pyopenssl'
>>> /Applications/SageMath-7.5.1.app/Contents/Resources/sage/logs/pkgs/pyopenssl.log
>>> [pyopenssl] Collecting pyopenssl
>>> [pyopenssl] Using cached pyOpenSSL-16.2.0-py2.py3-none-any.whl
>>> [pyopenssl] Collecting cryptography>=1.3.4 (from pyopenssl)
>>> [pyopenssl] Downloading cryptography-1.7.2.tar.gz (420kB)
>>> [pyopenssl] Requirement already satisfied (use --upgrade to upgrade):
>>> six>=1.5.2 in
>>> /Applications/SageMath-7.5.1.app/Contents/Resources/sage/local/lib/python2.7/site-packages
>>>
>>> (from pyopenssl)
>>> [pyopenssl] Collecting idna>=2.0 (from cryptography>=1.3.4->pyopenssl)
>>> [pyopenssl] Downloading idna-2.2-py2.py3-none-any.whl (55kB)
>>> [pyopenssl] Collecting pyasn1>=0.1.8 (from
>>> cryptography>=1.3.4->pyopenssl)
>>> [pyopenssl] Downloading pyasn1-0.2.2-py2.py3-none-any.whl (51kB)
>>> [pyopenssl] Requirement already satisfied (use --upgrade to upgrade):
>>> setuptools>=11.3 in
>>> /Applications/SageMath-7.5.1.app/Contents/Resources/sage/local/lib/python2.7/site-packages
>>>
>>> (from cryptography>=1.3.4->pyopenssl)
>>> [pyopenssl] Collecting enum34 (from cryptography>=1.3.4->pyopenssl)
>>> [pyopenssl] Using cached enum34-1.1.6-py2-none-any.whl
>>> [pyopenssl] Collecting ipaddress (from cryptography>=1.3.4->pyopenssl)
>>> [pyopenssl] Downloading ipaddress-1.0.18-py2-none-any.whl
>>> [pyopenssl] Collecting cffi>=1.4.1 (from cryptography>=1.3.4->pyopenssl)
>>> [pyopenssl] Using cached cffi-1.9.1-cp27-cp27mu-macosx_10_10_x86_64.whl
>>> [pyopenssl] Collecting pycparser (from
>>> cffi>=1.4.1->cryptography>=1.3.4->pyopenssl)
>>> [pyopenssl] Using cached pycparser-2.17.tar.gz
>>> [pyopenssl] Installing collected packages: idna, pyasn1, enum34,
>>> ipaddress, pycparser, cffi, cryptography, pyopenssl
>>> [pyopenssl] Running setup.py install for pycparser: started
>>> [pyopenssl] Running setup.py install for pycparser: finished with
>>> status 'done'
>>> [pyopenssl] Running setup.py install for cryptography: started
>>> [pyopenssl] Running setup.py install for cryptography: finished with
>>> status 'error'
>>> [pyopenssl] Complete output from command
>>> /Applications/SageMath-7.5.1.app/Contents/Resources/sage/local/bin/python
>>> -u -c "import setuptools,
>>> tokenize;__file__='/private/var/folders/qf/wr6_n5s56m780kv130nznmlcgn/T/pip-build-YqN6_t/cryptography/setup.py';exec(compile(getattr(tokenize,
>>>
>>> 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))"
>>> install --record
>>> /var/folders/qf/wr6_n5s56m780kv130nznmlcgn/T/pip-_Mvdak-record/install-record.txt
>>>
>>> --single-version-externally-managed --compile:
>>> [pyopenssl] running install
>>> [pyopenssl] running build
>>> [pyopenssl] running build_py
>>> [pyopenssl] creating build
>>> [pyopenssl] creating build/lib.macosx-10.9-x86_64-2.7
>>> [pyopenssl] creating build/lib.macosx-10.9-x86_64-2.7/cryptography
>>> [pyopenssl] copying src/cryptography/__about__.py ->
>>> build/lib.macosx-10.9-x86_64-2.7/cryptography
>>> [pyopenssl] copying src/cryptography/__init__.py ->
>>> build/lib.macosx-10.9-x86_64-2.7/cryptography
>>> [pyopenssl] copying src/cryptography/exceptions.py ->
>>> build/lib.macosx-10.9-x86_64-2.7/cryptography
>>> [pyopenssl] copying src/cryptography/fernet.py ->
>>> build/lib.macosx-10.9-x86_64-2.7/cryptography
>>> [pyopenssl] copying src/cryptography/utils.py ->
>>> build/lib.macosx-10.9-x86_64-2.7/cryptography
>>> [pyopenssl] creating
>>> build/lib.macosx-10.9-x86_64-2.7/cryptography/hazmat
>>> [pyopenssl] copying src/cryptography/hazmat/__init__.py ->
>>> build/lib.macosx-10.9-x86_64-2.7/cryptography/hazmat
>>> [pyopenssl] creating
>>> build/lib.macosx-10.9-x86_64-2.7/cryptography/x509
>>> [pyopenssl] copying src/cryptography/x509/__init__.py ->
>>> build/lib.macosx-10.9-x86_64-2.7/cryptography/x509
>>> [pyopenssl] copying src/cryptography/x509/base.py ->
>>> build/lib.macosx-10.9-x86_64-2.7/crypt
Re: [sage-devel] 'make PACKAGE' does not build the toolchain
Feature Use "./sage -i PACKAGE" if you want to build the toolchain first. -- 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] 'make PACKAGE' does not build the toolchain
If I unpack a Sage tarball, what should happen when I run 'make lcalc', for example? Should it be the same as running 'make', but stopping after the lcalc build? Right now, that does not seem to be the case: 'make lcalc' does not build the toolchain target, so on OS X or other systems requiring Sage's gcc, the build is not likely to succeed (depending on the specific target). Is this a bug or just not a feature of 'make TARGET', or am I misunderstanding something? -- 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 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] Better documentation on how to use spyx
There is woefully little about how to properly use these in the Sage documentation. See https://trac.sagemath.org/ticket/22698 if you can help improve this - I was alerted to it via http://stackoverflow.com/questions/43067894/differences-between-sage-and-spyx-in-numerical-evaluation - kcrisman -- 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: jsmol.js
Is there an easy way to make it work in jupyterhub? In jupyter, sage-7.6 works without any problem; for jupyterhub, threejs works but jsmol still doesn't. Thanks for the hard work. I can test any solution. Best, Enrique. El martes, 1 de noviembre de 2016, 20:03:52 (UTC+1), Volker Braun escribió: > > Its not a proper notebook extension; The code is > in src/sage/repl/display/jsmol_iframe.py > > > -- 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] linker options for C code in ext/interpreters and other stuff in sagelib
On Tuesday, March 28, 2017 at 9:13:13 AM UTC+1, François wrote: > > > > On 28/03/2017, at 21:07, Francois Bissey > wrote: > > > >> Does such "#distutils: libraries = blah " automatically imply that > libblah from $SAGE_LOCAL/lib/ will be linked? > >> > > > > Unless you add -L$some_path, it should be the first one tried. If it is > not found or > > incompatible, system paths will be tried. > > Actually, is this for freeBSD? yes it is. > What is the linker used? We may not have the right > mechanism in place for freeBSD. > $ ld -v GNU ld (GNU Binutils) 2.27 > > François -- 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] linker options for C code in ext/interpreters and other stuff in sagelib
> On 28/03/2017, at 21:07, Francois Bissey > wrote: > >> Does such "#distutils: libraries = blah " automatically imply that libblah >> from $SAGE_LOCAL/lib/ will be linked? >> > > Unless you add -L$some_path, it should be the first one tried. If it is not > found or > incompatible, system paths will be tried. Actually, is this for freeBSD? What is the linker used? We may not have the right mechanism in place for freeBSD. François -- 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] linker options for C code in ext/interpreters and other stuff in sagelib
> On 28/03/2017, at 21:04, Dima Pasechnik wrote: > > > > On Tuesday, March 28, 2017 at 8:32:53 AM UTC+1, Jeroen Demeyer wrote: > On 2017-03-27 23:15, François Bissey wrote: > > The generated sage/ext/interpreters/wrapper_cdf.pxd has the following > > statement: > > cimport sage.libs.cypari2.types > > > > That would pull `-lpari`. > > That's not actually true. Just using the *types* from PARI doesn't need > linking against PARI. It's cysignals which pulls -lpari. > > > To add `-lm` you would have to add > > a line > > #distutils: libraries = m > > at the top of the same .pxd file > > Actually, the .pyx file. If something is needed for the .pxd file, the > "# distutils" declaration should be in the .pxd file. But this is not > the case here, so it should be in the .pyx file. > > Thanks. > Does such "#distutils: libraries = blah " automatically imply that libblah > from $SAGE_LOCAL/lib/ will be linked? > Unless you add -L$some_path, it should be the first one tried. If it is not found or incompatible, system paths will be tried. -- 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: linker options for C code in ext/interpreters and other stuff in sagelib
On Tuesday, March 28, 2017 at 8:32:53 AM UTC+1, Jeroen Demeyer wrote: > > On 2017-03-27 23:15, François Bissey wrote: > > The generated sage/ext/interpreters/wrapper_cdf.pxd has the following > > statement: > > cimport sage.libs.cypari2.types > > > > That would pull `-lpari`. > > That's not actually true. Just using the *types* from PARI doesn't need > linking against PARI. It's cysignals which pulls -lpari. > > > To add `-lm` you would have to add > > a line > > #distutils: libraries = m > > at the top of the same .pxd file > > Actually, the .pyx file. If something is needed for the .pxd file, the > "# distutils" declaration should be in the .pxd file. But this is not > the case here, so it should be in the .pyx file. > Thanks. Does such "#distutils: libraries = blah " automatically imply that libblah from $SAGE_LOCAL/lib/ will be linked? -- 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: linker options for C code in ext/interpreters and other stuff in sagelib
On 2017-03-27 23:15, François Bissey wrote: The generated sage/ext/interpreters/wrapper_cdf.pxd has the following statement: cimport sage.libs.cypari2.types That would pull `-lpari`. That's not actually true. Just using the *types* from PARI doesn't need linking against PARI. It's cysignals which pulls -lpari. To add `-lm` you would have to add a line #distutils: libraries = m at the top of the same .pxd file Actually, the .pyx file. If something is needed for the .pxd file, the "# distutils" declaration should be in the .pxd file. But this is not the case here, so it should be in the .pyx file. -- 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.
