On Monday, March 21, 2016 at 12:53:54 AM UTC+1, William wrote:
>
> I did *NOT* say that SMC does not using cgroups.The are several
> distinct concepts here:
>
>- cgroups
>- docker containers
>- lxc
>- chroot
>
> Please don't conflate them.
>
Well until not so long ago th
On Sun, Mar 20, 2016 at 4:39 PM, Volker Braun wrote:
> On Sunday, March 20, 2016 at 10:40:56 PM UTC+1, William wrote:
>>
>> That doesn't work since SMC uses normal Linux users, not lxc or docker
>> containers, so they do not have a virtual chroot'd filesystem.
>
>
> Well that explains why massive
On Sun, Mar 20, 2016 at 3:47 PM, Dima Pasechnik wrote:
>
>
> On Sunday, March 20, 2016 at 9:40:56 PM UTC, William wrote:
>>
>> On Fri, Mar 18, 2016 at 4:52 PM, Volker Braun wrote:
>> > On Friday, March 18, 2016 at 6:39:33 PM UTC+1, William wrote:
>> >>
>> >> 3. More generally, for SMC, it's usefu
On Sunday, March 20, 2016 at 10:40:56 PM UTC+1, William wrote:
>
> That doesn't work since SMC uses normal Linux users, not lxc or docker
> containers, so they do not have a virtual chroot'd filesystem.
>
Well that explains why massive parallel compilation can grind everything to
a halt; Withou
On Sunday, March 20, 2016 at 9:40:56 PM UTC, William wrote:
>
> On Fri, Mar 18, 2016 at 4:52 PM, Volker Braun > wrote:
> > On Friday, March 18, 2016 at 6:39:33 PM UTC+1, William wrote:
> >>
> >> 3. More generally, for SMC, it's useful, for the sake of Sage
> >> development, to have a way to
On Fri, Mar 18, 2016 at 4:52 PM, Volker Braun wrote:
> On Friday, March 18, 2016 at 6:39:33 PM UTC+1, William wrote:
>>
>> 3. More generally, for SMC, it's useful, for the sake of Sage
>> development, to have a way to setup a sage dev environment as quickly
>> as possible for user experience reaso
On Fri, Mar 18, 2016 at 2:39 PM, Dima Pasechnik wrote:
>
>
> On Friday, March 18, 2016 at 5:06:59 PM UTC, David Roe wrote:
>>
>>
>>
>> On Fri, Mar 18, 2016 at 12:55 PM, Dima Pasechnik
>> wrote:
>>
>>>
>>>
>>> On Friday, March 18, 2016 at 3:06:04 PM UTC, William wrote:
On Fri, Mar 18, 2
On Friday, March 18, 2016 at 6:39:33 PM UTC+1, William wrote:
>
> 3. More generally, for SMC, it's useful, for the sake of Sage
> development, to have a way to setup a sage dev environment as quickly
> as possible for user experience reasons, and as efficiently as
> possible to better make use o
On Friday, March 18, 2016 at 4:06:04 PM UTC+1, William wrote:
>
> > Also, your use case is a bit weird; Parallel installations on the same
> > server?
>
> It's David's use case for Sage Days 71. It seems to me like a
> reasonable use case for development.
In fact, in that odd case why not co
On Friday, March 18, 2016, Dima Pasechnik wrote:
>
>
> On Friday, March 18, 2016 at 5:33:31 AM UTC, William wrote:
>>
>>
>>
>> On Thursday, March 17, 2016, David Roe wrote:
>>
>>> Here's a use case where the recent changes to relocatability are really
>>> annoying. I'd like 6 sage installs in a
On Fri, Mar 18, 2016 at 11:14 AM, William Stein wrote:
> On Fri, Mar 18, 2016 at 8:11 AM, Volker Braun
> wrote:
> > On Friday, March 18, 2016 at 4:06:04 PM UTC+1, William wrote:
> >>
> >> > Also, your use case is a bit weird; Parallel installations on the same
> >> > server?
> >>
> >> It's David
> William can speak more to the technical details for SMC, but the project
> supposedly has 11GB of RAM, 6 cores (I don't know what kind) and 53GB of
> disk space.
The project lives on a GCE n1-standard-8 VM with Haswell processors in the
us-central1-c zone:
https://cloud.google.com/compute/pri
On Fri, Mar 18, 2016 at 9:55 AM, Dima Pasechnik wrote:
>
>
> On Friday, March 18, 2016 at 3:06:04 PM UTC, William wrote:
>>
>> On Fri, Mar 18, 2016 at 7:59 AM, Volker Braun wrote:
>> > I've had people at workshops trying to compile Sage (never mind using
>> > binaries) and they were SOL because t
On 2016-03-18 18:01, Volker Braun wrote:
I did it once and nobody reviewed it
To be fair, I reviewed it negatively because of potential issues that
you didn't care about.
But it's certainly true that sage-location is mostly redundant.
--
You received this message because you are subscribed
On Fri, Mar 18, 2016 at 8:11 AM, Volker Braun wrote:
> On Friday, March 18, 2016 at 4:06:04 PM UTC+1, William wrote:
>>
>> > Also, your use case is a bit weird; Parallel installations on the same
>> > server?
>>
>> It's David's use case for Sage Days 71. It seems to me like a
>> reasonable use ca
On Fri, Mar 18, 2016 at 10:32 AM, Jeroen Demeyer wrote:
> On 2016-03-18 04:10, David Roe wrote:
>>
>> Here's a use case where the recent changes to relocatability are really
>> annoying. I'd like 6 sage installs in an SMC project so that different
>> groups at Sage Days 71 can work independently.
Here's a use case where the recent changes to relocatability are really
annoying. I'd like 6 sage installs in an SMC project so that different
groups at Sage Days 71 can work independently. So I tried building a copy
from source and then copying it five times.
Unfortunately, the relocation scrip
On Fri, Mar 18, 2016 at 7:49 AM, Volker Braun wrote:
> On Friday, March 18, 2016 at 1:04:57 PM UTC+1, William wrote:
>>
>> Yes definitely. It worked very well for precisely this use case for a
>> decade.
>
>
> It might have worked for you but it certainly didn't work for all users,
> there was a c
On Friday, March 18, 2016 at 3:06:04 PM UTC, William wrote:
>
> On Fri, Mar 18, 2016 at 7:59 AM, Volker Braun > wrote:
> > I've had people at workshops trying to compile Sage (never mind using
> > binaries) and they were SOL because their system bash was linked against
> the
> > wrong versio
On Friday, March 18, 2016 at 5:33:31 AM UTC, William wrote:
>
>
>
> On Thursday, March 17, 2016, David Roe >
> wrote:
>
>> Here's a use case where the recent changes to relocatability are really
>> annoying. I'd like 6 sage installs in an SMC project so that different
>> groups at Sage Days 7
On 2016-03-18 04:10, David Roe wrote:
Here's a use case where the recent changes to relocatability are really
annoying. I'd like 6 sage installs in an SMC project so that different
groups at Sage Days 71 can work independently. So I tried building a
copy from source and then copying it five tim
On Fri, Mar 18, 2016 at 6:45 AM, Dima Pasechnik wrote:
>
>
> On Friday, March 18, 2016 at 1:12:50 PM UTC, William wrote:
>>
>> On Fri, Mar 18, 2016 at 5:42 AM, Dima Pasechnik wrote:
>> >> Yes definitely. It worked very well for precisely this use case for a
>> >> decade.
>> >
>> >
>> > well, it w
On Fri, Mar 18, 2016 at 7:59 AM, Volker Braun wrote:
> I've had people at workshops trying to compile Sage (never mind using
> binaries) and they were SOL because their system bash was linked against the
> wrong version of some library. If you can't compile it you surely can't use
> it 6 times.
D
On Friday, March 18, 2016 at 12:04:57 PM UTC, William wrote:
>
>
>
> On Friday, March 18, 2016, Dima Pasechnik >
> wrote:
>
>>
>>
>> On Friday, March 18, 2016 at 5:33:31 AM UTC, William wrote:
>>>
>>>
>>>
>>> On Thursday, March 17, 2016, David Roe wrote:
>>>
Here's a use case where the rec
I've had people at workshops trying to compile Sage (never mind using
binaries) and they were SOL because their system bash was linked against
the wrong version of some library. If you can't compile it you surely can't
use it 6 times.
Also, your use case is a bit weird; Parallel installations
Most of sage-location can safely be deleted. I did it once and nobody
reviewed it so I'm not that motivated to fix the merge conflicts that since
have accrued.
http://trac.sagemath.org/ticket/19908
On Friday, March 18, 2016 at 5:00:54 PM UTC+1, David Roe wrote:
>
>
> On Fri, Mar 18, 2016 at
On Friday, March 18, 2016 at 1:04:57 PM UTC+1, William wrote:
>
> Yes definitely. It worked very well for precisely this use case for a
> decade.
>
It might have worked for you but it certainly didn't work for all users,
there was a constant influx of random unfixable segfaults that you just
On Friday, March 18, 2016 at 5:06:59 PM UTC, David Roe wrote:
>
>
>
> On Fri, Mar 18, 2016 at 12:55 PM, Dima Pasechnik > wrote:
>
>>
>>
>> On Friday, March 18, 2016 at 3:06:04 PM UTC, William wrote:
>>>
>>> On Fri, Mar 18, 2016 at 7:59 AM, Volker Braun
>>> wrote:
>>> > I've had people at work
On Fri, Mar 18, 2016 at 12:55 PM, Dima Pasechnik wrote:
>
>
> On Friday, March 18, 2016 at 3:06:04 PM UTC, William wrote:
>>
>> On Fri, Mar 18, 2016 at 7:59 AM, Volker Braun
>> wrote:
>> > I've had people at workshops trying to compile Sage (never mind using
>> > binaries) and they were SOL beca
On Fri, Mar 18, 2016 at 5:42 AM, Dima Pasechnik wrote:
>> Yes definitely. It worked very well for precisely this use case for a
>> decade.
>
>
> well, it was quite often a source of trouble (I can point to dozens of
> requests for help caused by LD_... paths issues), and then it has reached
> the
On Thursday, March 17, 2016, David Roe wrote:
> Here's a use case where the recent changes to relocatability are really
> annoying. I'd like 6 sage installs in an SMC project so that different
> groups at Sage Days 71 can work independently. So I tried building a copy
> from source and then cop
On Friday, March 18, 2016 at 1:12:50 PM UTC, William wrote:
>
> On Fri, Mar 18, 2016 at 5:42 AM, Dima Pasechnik > wrote:
> >> Yes definitely. It worked very well for precisely this use case for a
> >> decade.
> >
> >
> > well, it was quite often a source of trouble (I can point to dozens of
On 2016-02-05 00:24, John H Palmieri wrote:
Should the model when building from scratch be
./configure --prefix=/target/location
make
make install
One thing which we could try is to make it such that
./configure --prefix=/target/location
make
installs in /target/location. Like Volker said, w
Should the model when building from scratch be
./configure --prefix=/target/location
make
make install
? If not, should we aim for that? Does "make install" do the right thing
these days? It's marked as "experimental" in Makefile.
And for people downloading pre-built binaries, should there be a
34 matches
Mail list logo
