On Mon, Mar 3, 2014 at 10:40 AM, Volker Braun wrote:
> On Monday, March 3, 2014 6:20:27 PM UTC, kcrisman wrote:
>>
>> a lot of users on Mac/Windows move programs around all the time.
>
>
> Try moving your MS Office install on Windows .Good luck.
Volker's right. Also with Mac's many programs can
On Monday, March 3, 2014 6:20:27 PM UTC, kcrisman wrote:
>
> a lot of users on Mac/Windows move programs around all the time.
>
Try moving your MS Office install on Windows .Good luck.
On Mac one does essentially what I'm proposing. Because of the utter lack
of any package management system, you
On Sunday, March 2, 2014 11:11:10 AM UTC-5, Volker Braun wrote:
>
> On Sunday, March 2, 2014 11:33:22 AM UTC+1, Jeroen Demeyer wrote:
>
>> The problem is that Sage cannot know in advance that you will *not* move
>> the Sage tree.
>
>
> Neither does any other software. If you move an installed pr
On Sunday, March 2, 2014 11:33:22 AM UTC+1, Jeroen Demeyer wrote:
> The problem is that Sage cannot know in advance that you will *not* move
> the Sage tree.
Neither does any other software. If you move an installed program then it
won't work any more, and we shouldn't go around teaching users
> On 2014-03-01 18:37, William Stein wrote:
> > Forcing sage-location, probably because a new package was installed.
> > Updating various hardcoded paths...
> > (Please wait at most a few minutes.)
> > DO NOT INTERRUPT THIS.
> >
> >This is a somewhat disturbing waste of time, right?
On 2014-03-01 18:37, William Stein wrote:
Forcing sage-location, probably because a new package was installed.
Updating various hardcoded paths...
(Please wait at most a few minutes.)
DO NOT INTERRUPT THIS.
This is a somewhat disturbing waste of time, right?
The problem is th
Hi,
A long, long time ago I wrote this sage-location script, which is
meant to be run when you move Sage. It hacks around certain
hard-coded paths, and of course isn't the optimal solution to
anything. But it tends to work. It's 100% designed for binary
distribution of Sage.
In practice I pers
