[sage-devel] Re: lib*.so conflict
On Wednesday, August 30, 2017 at 6:14:06 PM UTC+1, Richard_L wrote: > > As I observed on the sage-release Sage.8.1.beta3 thread, a library > conflict causes 'make ptestlong' to fail under openSUSE LEAP 42.2. > Reworking the offending symlink in the sage installation to point to the > system library fixes the problem. The two copies of "libreadline.so.6.3" > are NOT identical. Running 'nm -D --defined-only' against each file, and > stripping out the symbol values, I was able to diff the two, revealing > discrepancies both in symbol types and symbol names. (Log attached.) > > Question: Why does sage install shared-object libraries when working > versions of same are already on the system? > it is one of the curses/blessings of a distribution-like system like Sage; it is easier and more reliable, generally speaking, to rely on a particular version of a library/package than to work around bugs/(mis)features of a system-wide installed library/package. Normally speaking, such a library clash that you see should not happen. Do you have something special in your setup that causes this mis-linking? (say, set LD_LIBRARY_PATH...) > - Richard > -- 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] English translation of "Calcul Mathématique avec Sage" and Python 3
On Wed, Aug 30, 2017 at 2:14 PM, Jeroen Demeyer wrote: > On 2017-08-28 12:45, Nicolas M. Thiery wrote: >> >> - Are there plans to enforce the above future imports to our doctests? In >>particular unicode_literals which seems more problematic? > > > TL;DR: I do not consider it a problem that stuff breaks with "from > __future__ import unicode_literals". > > The other __future__ imports (namely absolute_import, division and > print_function) make certain code behave just like in Python 3. That's good > in any case for portability. > > unicode_literals on the other hand creates a "mixed" environment, which is > not the same as Python 2 nor the same as Python 3. With unicode_literals, > it's only string *literals* which become unicode, but other strings still > behave like plain old strings. I would say that unicode_literals does have > its uses (if you want to do text processing in unicode both in Python 2 and > in Python 3), but it's not something that should be turned on blindly. Agreed--for certain modules it's very useful, but it harms users on Python 2 because suddenly lots of strings have the u"" prefix for some reason (that they don't understand, necessarily) and the overall experience is disruptive and not backwards compatible. I usually try to eschew the as much as possible on Python 2 except where explicitly needed (e.g. non-ASCII text), but otherwise keep as the default string type on both Python 2 and Python 3 (even though these are very different types despite having the same name ;) -- 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] English translation of "Calcul Mathématique avec Sage" and Python 3
On Thu, Aug 31, 2017 at 11:27 AM, Erik Bray wrote: > On Wed, Aug 30, 2017 at 2:14 PM, Jeroen Demeyer > wrote: >> On 2017-08-28 12:45, Nicolas M. Thiery wrote: >>> >>> - Are there plans to enforce the above future imports to our doctests? In >>>particular unicode_literals which seems more problematic? >> >> >> TL;DR: I do not consider it a problem that stuff breaks with "from >> __future__ import unicode_literals". >> >> The other __future__ imports (namely absolute_import, division and >> print_function) make certain code behave just like in Python 3. That's good >> in any case for portability. >> >> unicode_literals on the other hand creates a "mixed" environment, which is >> not the same as Python 2 nor the same as Python 3. With unicode_literals, >> it's only string *literals* which become unicode, but other strings still >> behave like plain old strings. I would say that unicode_literals does have >> its uses (if you want to do text processing in unicode both in Python 2 and >> in Python 3), but it's not something that should be turned on blindly. > > Agreed--for certain modules it's very useful, but it harms users on > Python 2 because suddenly lots of strings have the u"" prefix for some > reason (that they don't understand, necessarily) and the overall > experience is disruptive and not backwards compatible. > > I usually try to eschew the as much as possible on > Python 2 except where explicitly needed (e.g. non-ASCII text), but > otherwise keep as the default string type on both Python > 2 and Python 3 (even though these are very different types despite > having the same name ;) In fact, I just remembered there was a thread about this a few months ago on python-dev. Even Guido concluded that unicode_literals does more harm than good (I'd still say it's useful in some cases. I think the conclusion of that discussion was to add an admonition against it in the docs :) https://mail.python.org/pipermail/python-dev/2016-December/147009.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 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] RFC: Draft blog post on Sage for Windows
In the long section "Rationale for Cygwin and possible alternatives", I would add subsections for each alternative. [hardware-assisted virtualization] typically does not come enabled by default (as a security measure) Is that really true? What is non-secure about hardware-assisted virtualization? the main problem is that 32-bit Windows applications have a user address space limited to just 2 GB (or 3 GB with a special boot flag). This is in fact not enough to fit all of Sage into memory at once. Do you know how this compares to 32-bit Linux? I would expect a similar limit there. -- 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] RFC: Draft blog post on Sage for Windows
On Thu, 31 Aug 2017, Jeroen Demeyer wrote: the main problem is that 32-bit Windows applications have a user address space limited to just 2 GB (or 3 GB with a special boot flag). This is in fact not enough to fit all of Sage into memory at once. Is this still true by default with PAE enabled? Do you know how this compares to 32-bit Linux? I would expect a similar limit there. Isn't that just CONFIG_PAGE_OFFSET, which defaults to 3GB, but can be changed when configuring kernel before compilation (at least manually, I think that make menuconfig has only options for 2 GB and 3 GB)? -- Jori Mäntysalo
Re: [sage-devel] RFC: Draft blog post on Sage for Windows
On Thu, Aug 31, 2017 at 1:15 PM, Jeroen Demeyer wrote: > In the long section "Rationale for Cygwin and possible alternatives", I > would add subsections for each alternative. Will do. >> [hardware-assisted virtualization] typically does not come enabled by >> default (as a security measure) > > > Is that really true? What is non-secure about hardware-assisted > virtualization? That's actually a good question. I don't have a specific citation for the claim that the default setting is for "security", so maybe I'll just remove the parenthetical. That said, there have been hypervisor-related exploits (see https://en.wikipedia.org/wiki/Blue_Pill_(software)) and so ISTM safer to disable by default for the average user, and assume that if they know what they're doing enough to explicitly want to run a hypervisor then they're sophisticated enough to twiddle a BIOS setting. >> the main problem is that 32-bit Windows applications have a user address >> space limited to just 2 GB (or 3 GB with a special boot flag). This is in >> fact not enough to fit all of Sage into memory at once. > > > Do you know how this compares to 32-bit Linux? I would expect a similar > limit there. This is less of a problem on Linux. I was light on the technical details here but the point is that on Cygwin *every* DLL needs to be given its own pre-assigned, non-overlapping address space so that they don't have to be relocated at load time (this breaks Cygwin's fork). So while it's true that you could run out of memory on Linux as well, the problem here is that on Cygwin you'll run into problems even before running out of memory. -- 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: lib*.so conflict
No. LD_LIBRARY_PATH is not set. The curious thing is that there are 29 lib*.so in the sage/local/lib folder that are in common with the system /lib64 folder, although not necessarily of the same version/sub-version. Only libreadline.so gives trouble during make ptestall. NB! Just grep'd all of ~/Development/sage/ for the string "no version information". I find 6427 similar messages involving libreadline in the pkg logs. The messages are distributed across logs/pkgs/arb-2.8.1.p1.log: 1566 logs/pkgs/flint-2.5.2.p1.log: 4614 logs/pkgs/r-3.4.0.p0.log: 241 logs/pkgs/rpy2-2.8.2.p0.log: 6 So, although the installation script complains mightily, it chugs along and gives an apparently healthy installation! Tnx, - Richard On Thursday, August 31, 2017 at 1:07:50 AM UTC-7, Dima Pasechnik wrote: > > > it is one of the curses/blessings of a distribution-like system like Sage; > it is easier and more reliable, generally speaking, to rely on a particular > version of a library/package than to work around bugs/(mis)features of a > system-wide installed library/package. > > Normally speaking, such a library clash that you see should not happen. > Do you have something special in your setup that causes this mis-linking? > (say, set LD_LIBRARY_PATH...) > > > -- 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: lib*.so conflict
On Thursday, August 31, 2017 at 4:03:48 PM UTC+1, Richard_L wrote: > > No. LD_LIBRARY_PATH is not set. > The curious thing is that there are 29 lib*.so in the sage/local/lib > folder that are in common with the system /lib64 folder, although not > necessarily of the same version/sub-version. Only libreadline.so gives > trouble during make ptestall. > > NB! Just grep'd all of ~/Development/sage/ for the string "no version > information". I find 6427 similar messages involving libreadline in the pkg > logs. The messages are distributed across > logs/pkgs/arb-2.8.1.p1.log: 1566 > logs/pkgs/flint-2.5.2.p1.log: 4614 > these two have funky hand-written ./configure scripts, no wonder. But they don't use readline, so we can ingore them. > logs/pkgs/r-3.4.0.p0.log: 241 > logs/pkgs/rpy2-2.8.2.p0.log: 6 > my bet is that one of these two (or both). Were libR.so and rpy's extension module linked against the correct libreadline in the 1st place? I.e. what's the output of ldd local/lib/R/lib/libR.so ldd local/lib/python2.7/site-packages/rpy2/rinterface/_rpy_device.so ---assuming you execute it from SAGE_ROOT directory. (you probably might need to undo your hack to find out) It might also help to be able to have a look at logs/pkgs/rpy2-2.8.2.p0.log and logs/pkgs/r-3.4.0.p0.log (versions numbers might differ in the latter two...) > > > So, although the installation script complains mightily, it chugs along > and gives an apparently healthy installation! > > Tnx, > - Richard > > On Thursday, August 31, 2017 at 1:07:50 AM UTC-7, Dima Pasechnik wrote: >> >> >> it is one of the curses/blessings of a distribution-like system like >> Sage; it is easier and more reliable, generally speaking, to rely on a >> particular version of a library/package than to work around >> bugs/(mis)features of a system-wide installed library/package. >> >> Normally speaking, such a library clash that you see should not happen. >> Do you have something special in your setup that causes this mis-linking? >> (say, set LD_LIBRARY_PATH...) >> >> >> -- 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: RFC: Draft blog post on Sage for Windows
This is great. I would add that you are right that 32-bit on Cygwin is probably never going to be stable - I spent countless hours rebasing while attempting to help with that. The only thing I would add is that you may want to add something brief on exactly how people use the filesystem with the installer (e.g. where to save Jupyter notebooks or images); it is one of the most common questions we get on ask.sagemath regarding Windows with the Linux VM. (It may not be appropriate for this post, but adding info to an easily accessible how-to manual on how to get stuff off a VM into a normal filesystem would be great too.) - 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.
[sage-devel] Re: lib*.so conflict
Both r-3.4.0.p0.log and rpy2-2.8.2.p0.log show sh: /home/rllozes/Development/sage/local/lib/libreadline.so.6: no version information available (required by sh) With or without restoring my hacked symlink to its original state, ldd local/lib/R/lib/libR.so and ldd local/lib/python2.7/site-packages/rpy2/rinterface/_rpy_device.so both report libreadline.so.6 => /home/rllozes/Development/sage/local/lib/libreadline.so.6 . But we must keep in mind that ~/Development/sage/local/lib/libreadline.so.6 is a symlink, resolving to ~/Development/sage/local/lib/libreadline.so.6.3 originally, and to /lib64/libreadline.so.6.3 after hacking. - Richard -- 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: lib*.so conflict
What does happen if you remove your system-wide (?) R installation, does it have any effect? I suspect it either interferes with running Sage (tests), or with building Sage's R and Rpy... On Thursday, August 31, 2017 at 9:37:26 PM UTC+1, Richard_L wrote: > > Both r-3.4.0.p0.log and rpy2-2.8.2.p0.log show >sh: /home/rllozes/Development/sage/local/lib/libreadline.so.6: no > version information available (required by sh) > > With or without restoring my hacked symlink to its original state, > ldd local/lib/R/lib/libR.so and > ldd local/lib/python2.7/site-packages/rpy2/rinterface/_rpy_device.so > both report > libreadline.so.6 => > /home/rllozes/Development/sage/local/lib/libreadline.so.6 . > But we must keep in mind that > ~/Development/sage/local/lib/libreadline.so.6 is a symlink, resolving to > ~/Development/sage/local/lib/libreadline.so.6.3 originally, and to > /lib64/libreadline.so.6.3 after hacking. > > - Richard > > > > -- 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.
