On Fri, Apr 17, 2009 at 12:21 AM, mabshoff <mabsh...@googlemail.com> wrote: > > > > On Apr 17, 12:09 am, Ondrej Certik <ond...@certik.cz> wrote: >> Hi, >> >> why is the notebook trying to execute "sage" that it finds in the >> path, rather than another copy of the sage that it is running? > > Because sage-env assures that the right sage script is called, see > below. > >> The following patches fix that (for SPD): >> >> http://github.com/certik/spd_notebook/commit/f0d66f283c4f398927a7e60c...http://github.com/certik/spd_notebook/commit/43762487aaa0efdfc107b4e0...http://github.com/certik/spd_notebook/commit/d89a444326c723ac7cf993d5...http://github.com/certik/spd_notebook/commit/352be7322447fca9c6ee6845... >> >> so the fixes are easy, but my question is why it was done that way in >> the first place? The problem with that is that if the "sage" in path >> points to a different version of sage than I am using to run the >> notebook, then the wrong sage is going to be used. > > Well, that is because you probably broke something with your > changes :). The "fix" you listed has been proposed in the past, but > was turned down since it isn't a bug per se. SPD is a different > story. > >> I understand the motivation for this, if the second instance of Sage >> is run over ssh on a different machine. It then doesn't make sense to >> execute "SAGE_ROOT + '/sage'", since on the other machine it will most >> likely be a wrong path. But if I am running on the same machine, is >> there any rationale to call a different Sage? > > It cannot happen since sage-env sets PATH and LD_LIBRARY_PATH so that > the sage script from SAGE_ROOT gets picked up, i.e. from sage-env > > PATH="$SAGE_ROOT:$SAGE_LOCAL/bin:$PATH" && export PATH > > If SAGE_ROOT is already set sage aborts:
Ah, so I think I smell where the problem is --- I broke the SAGE_ROOT stuff. When I fix it, which I have to fix anyway, thing should start working. > >> If there is, could I fix it by introducing a variable to notebook() >> that would control this? > > Do you still want to do that? The fewer config options there are the > better it is ;) No, I just didn't know where the problem is. I am breaking stuff from time to time now, but once I figure out how to customize Sage, it should then be really easy to maintain it. I just keep all changes as a set of documented patches in a git "spd" branch and original Sage sources in the master branch, so with each new Sage release, I just update the master branch and then just rebase (or merge, that's probably better to preserve history for debugging) my spd branch. Ondrej --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
