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 li
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 st
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 pro
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
virtualiz
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?
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)
>
>
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 o
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. Onl
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 t
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/s
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
11 matches
Mail list logo
