Closed herbs closed 2 years ago
This appears to be a bug in the bash script /usr/local/bin/sage which gets installed by the extra package. The last line of that script, as installed, is
$SYMLINK/local/bin/sage $@
If you change that line (e.g. with sudo nano /usr/local/bin/sage) to read
"$SYMLINK/local/bin/sage" "$@"
then it appears to work.
Can you please verify that this fixes the problem for you?
On Sep 6, 2021, at 9:25 AM, Marc Culler @.***> wrote:
This appears to be a bug in the bash script /usr/local/bin/sage which gets installed by the extra package. The last line of that script, as installed, is $SYMLINK/local/bin/sage $@ If you change that line (e.g. with sudo nano /usr/local/bin/sage) to read "$SYMLINK/local/bin/sage" "$@" then it appears to work.
Can you please verify that this fixes the problem for you?
Howdy,
Nope, it doesn't fix the problem. I get a message from sage itself:
var/tmp/sage-9.4-current/local/bin/sage: line 200: cd: /Users/herbs/Documents/Docs/LatexmkTestFiles/external: No such file or directory
so, for some reason it did a pwd
and is then trying to cd
to the unquoted path to the file.
Good Luck,
Herb Schulz @.***
On Sep 6, 2021, at 9:25 AM, Marc Culler @.***> wrote:
This appears to be a bug in the bash script /usr/local/bin/sage which gets installed by the extra package. The last line of that script, as installed, is $SYMLINK/local/bin/sage $@ If you change that line (e.g. with sudo nano /usr/local/bin/sage) to read "$SYMLINK/local/bin/sage" "$@" then it appears to work.
Can you please verify that this fixes the problem for you?
Howdy,
I actually added quotes in line 200 of the sage script itself. That seemed to fix that problem.
My fancier test file is failing but it seems to be a problem with the internal (? --- I don't think python 3.9 is part of Big Sur unless I don't have it even though I have XCode) python 3.9.
Sigh...
PS: I have no problems with sage 9.2.
Good Luck,
Herb Schulz @.***
Thank you. That is very helpful.
This looks like another instance of the same bug. Line 200 is in a part of the sage script which was modified for the 9.4 app. Those particular changes were not present in the 9.2 app.
I will make these changes in the source code for now. I will wait a bit to see if you find any other issues like this before replacing the disk image. (I think most sage users avoid paths with spaces by instinct, or because once bit twice shy, so this does not get tested much.)
On Sep 6, 2021, at 11:15 AM, Marc Culler @.***> wrote:
Thank you. That is very helpful.
This looks like another instance of the same bug. Line 200 is in a part of the sage script which was modified for the 9.4 app. Those particular changes were not present in the 9.2 app.
I will make these changes in the source code for now. I will wait a bit to see if you find any other issues like this before replacing the disk image. (I think most sage users avoid paths with spaces by instinct, or because once bit twice shy, so this does not get tested much.)
Howdy,
I avoid file names with spaces. I don't understand why the script needs to cd
anywhere since I'm executing while in that directory anyway and not needing to give the full path to the file.
This is all using sagetex. I'm certainly used to avoiding file naming problems since one can occasionally run into problems running some things in the TeX distribution but never before with an outer folder unless I specify the path on the command line.
Now, if I can just figure out what's going on in that test file that causing python 3.9 errors.
Good Luck,
Herb Schulz @.***
The reason is that the sage script needs to set a bash variable to the absolute path of the sage/local directory within Sage.framework. This path must be determined at runtime since it depends on where the app is installed. So it is deduced from the path to the sage executable, which is provided to the script as $0.
No doubt there is a better way of doing this than changing to the directory and setting the variable to the output of pwd but I don't know what it is. If you know, I would be happy to learn about it. I am far from being a bash expert. I suppose I could call python, rather than attempting to do it in bash. I will consider that.
On Sep 6, 2021, at 12:42 PM, Marc Culler @.***> wrote:
The reason is that the sage script needs to set a bash variable to the absolute path of the sage/local directory within Sage.framework. This path must be determined at runtime since it depends on where the app is installed. So it is deduced from the path to the sage executable, which is provided to the script as $0.
No doubt there is a better way of doing this than changing to the directory and setting the variable to the output of pwd but I don't know what it is. If you know, I would be happy to learn about it. I am far from being a bash expert. I suppose I could call python, rather than attempting to do it in bash. I will consider that.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
Howdy,
Now that I'm past the original problem I can ask about a problem with sage 9.4 that I didn't have with 9.2. I actually maintain the use of latexmk engines for TeXShop (a front end for TeX) and have a couple of SageTeX documents in my test suite so I'm not very knowledgable about Sage or Python.
Enclosed a the example.tex file copied from local/share/texmf/tex/latex/sagetex so it's part of the distribution. I've also included a final example.pdf file that was produced by: 1)running example.tex through pdflatex to produce the example.sagetex.sage file (among other things files); 2)running sage example.sagetex.sage
with Sage 9.2 to produce an sout file plust other files and folders; 3)running pdflatex twice more on example.tex, to resolve all references, produces the final pdf. It looks pretty good!!!
If I run sage example.sagetex.sage
on the same, enclosed example.sagetex.sage file with sage 9.4 it fails and I get the console output in the enclosed ConsoleOutput9.4.txt file. I'm at a loss at this point.
Any help you can supply would certainly be appreciated.
Good Luck,
Herb Schulz @.***
Howdy,
Wait... the error message (neglecting other stuff from python) says
TypeError: unable to start maxima because the command '/var/tmp/sage-9.3-current/local/bin/maxima -p /var/tmp/sage-9.4-current/local/lib/python3.9/site-packages/sage/interfaces/sage-maxima.lisp' failed: The command was not found or was not executable: /var/tmp/sage-9.3-current/local/bin/maxima
NOTICE: it looks in /var/tmp/sage-9.3-current which doesn't exist since it's /var/tmp/sage-9.4-current now. That (wrong) path is hard coded somewhere.
Good Luck,
Herb Schulz @.***
On Sep 6, 2021, at 12:42 PM, Marc Culler @.***> wrote:
The reason is that the sage script needs to set a bash variable to the absolute path of the sage/local directory within Sage.framework. This path must be determined at runtime since it depends on where the app is installed. So it is deduced from the path to the sage executable, which is provided to the script as $0.
No doubt there is a better way of doing this than changing to the directory and setting the variable to the output of pwd but I don't know what it is. If you know, I would be happy to learn about it. I am far from being a bash expert. I suppose I could call python, rather than attempting to do it in bash. I will consider that.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
Howdy,
Hmmm... I may have been sending emails to the wrong place!
First: the problem with paths (not the final file name --- that has no spaces and I'm careful about that) is not in the sage script in /usr/local/bin but the internal one in the framework, local/bin/sage, at line 200. There is the command, cd pwd
, which should be cd "pwd
". That fixes that simple problem.
Second: I ran into the much bigger problem once the processing really started. The attempt to execute maxima fails with message:
TypeError: unable to start maxima because the command '/var/tmp/sage-9.3-current/local/bin/maxima -p /var/tmp/sage-9.4-current/local/lib/python3.9/site-packages/sage/interfaces/sage-maxima.lisp' failed: The command was not found or was not executable: /var/tmp/sage-9.3-current/local/bin/maxima
so there is a hard coded name for the symlink, /var/tmp/sage-9.3-current, somewhere in the code.
To test this I changed $SYMLINK in /usr/local/bin to /var/tmp/sage-9.3-current and also changed the name of the existing symlink to that name. Then the run completed successfully.
Good Luck,
Herb Schulz @.***
Howdy,
I jsut downloaded the 9.4 version again and looked at line 200 of .../local/bin/sage (NOT /usr/local/sage). IOt needs to be quoted:
cd "$saved_cwd"
so that any spaces in that path don't get messed up.
Also note that the more major problem I mentioned in a previous email with the hard coded wrong name (9.3 instead of 9.4) for the symlink was assumed when trying to execute maxima.
Good Luck,
Herb Schulz @.***
Interesting. Can you please include the command you used to generate that error?
On Wed, Sep 8, 2021, 9:22 AM herbs @.***> wrote:
Howdy,
Wait... the error message (neglecting other stuff from python) says
TypeError: unable to start maxima because the command '/var/tmp/sage-9.3-current/local/bin/maxima -p /var/tmp/sage-9.4-current/local/lib/python3.9/site-packages/sage/interfaces/sage-maxima.lisp' failed: The command was not found or was not executable: /var/tmp/sage-9.3-current/local/bin/maxima
NOTICE: it looks in /var/tmp/sage-9.3-current which doesn't exist since it's /var/tmp/sage-9.4-current now. That (wrong) path is hard coded somewhere.
Good Luck,
Herb Schulz @.***
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/3-manifolds/Sage_macOS/issues/25#issuecomment-915283833, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ6CPY3IWDOD5J22KT6C6DUA5WRFANCNFSM5DQPIBQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
On Sep 8, 2021, at 11:01 AM, Marc Culler @.***> wrote:
Interesting. Can you please include the command you used to generate that error?
On Wed, Sep 8, 2021, 9:22 AM herbs @.***> wrote:
Howdy,
Wait... the error message (neglecting other stuff from python) says
TypeError: unable to start maxima because the command '/var/tmp/sage-9.3-current/local/bin/maxima -p /var/tmp/sage-9.4-current/local/lib/python3.9/site-packages/sage/interfaces/sage-maxima.lisp' failed: The command was not found or was not executable: /var/tmp/sage-9.3-current/local/bin/maxima
NOTICE: it looks in /var/tmp/sage-9.3-current which doesn't exist since it's /var/tmp/sage-9.4-current now. That (wrong) path is hard coded somewhere.
Good Luck,
Herb Schulz @.***
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/3-manifolds/Sage_macOS/issues/25#issuecomment-915283833, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ6CPY3IWDOD5J22KT6C6DUA5WRFANCNFSM5DQPIBQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
Howdy,
Enclosed a the example.tex file copied from local/share/texmf/tex/latex/sagetex so it's part of the distribution. I've also included a final example.pdf file that was produced by: 1)running example.tex through pdflatex to produce the example.sagetex.sage file (among other things files); 2)running sage example.sagetex.sage
with Sage 9.2 to produce an sout file plust other files and folders; 3)running pdflatex twice more on example.tex, to resolve all references, produces the final pdf. It looks pretty good!!!
If I run sage example.sagetex.sage
on the same, enclosed example.sagetex.sage file with sage 9.4 it fails and I get the console output in the enclosed ConsoleOutput9.4.txt file. I'm at a loss at this point. Note the failure of starting maxima and the first part of the path containing /var/tmp/sage-9.3-current rather than the proper /var/tmp/sage-9.4-current.
Good Luck,
Herb Schulz @.***
Sigh... it looks like my attachment didn't come through.
take a look at .../local/share/texmf/tex/latex/sagetex/example.tex. It produces a call to maxima in the example.sagetex.sage file you get after a first run typesetting, pdflatex example.tex
.
The section of the example.tex file that generated the call to maxima is
Remember, you're using Sage, and can therefore call upon any of the software packages Sage is built out of. \begin{sageblock} f = maxima('sin(x)^2exp(x)') g = f.integrate('x') \end{sageblock} Plot $g(x)$, but don't typeset it. \begin{sagesilent} plot1 = plot(g.sage(),x,-1,2pi) \end{sagesilent}
Hope that helps.
I believe the relevant code in the generated example.sagetex.sage file is
st.blockbegin() try: f = maxima('sin(x)^2*exp(x)') g = f.integrate('x') except: st.goboom(125) st.blockend() st.current_tex_line = 127 st.blockbegin() try:
plot1 = plot(g.sage(),x,-1,2*pi) except: st.goboom(130) st.blockend()
and the run of maxima is what is causing the problem.
OK, I can reproduce this. I will see if I can track down where that 9.3 path could be hiding. Of course I don't create such a thing when I build the 9.4 app, so I am guessing there must be some file in my sage repo that got created when I built the 9.3 app but did not get removed when I ran make distclean before building the 9.4 app.
On Sep 9, 2021, at 9:47 AM, Marc Culler @.***> wrote:
OK, I can reproduce this. I will see if I can track down where that 9.3 path could be hiding. Of course I don't create such a thing when I build the 9.4 app, so I am guessing there must be some file in my sage repo that got created when I built the 9.3 app but did not get removed when I ran make distclean before building the 9.4 app.
Howdy,
Right now I've adapted the /usr/local/sage to produce two identical symlinks, /var/tmp/sage-9.3-current and /var/tmp/sage-9.4-current.
I know there are shell scripts that have shebang lines that start with
which is why I create both links. Maybe there is one that wasn't updated from 9.3.
Good Luck,
Herb Schulz @.***
No, I don't think that is the problem. Shebang lines which do not get rewritten to use /var/tmp will use a path the the repo on my build system which will completely fail when used on any other system. I currently suspect that the make distclean target does not clean up the LaTeX packages built in an earlier run. But I will see ...
I found the problem. The file which does not get cleaned up is
... local/lib/python3.9/site-packages//sage_conf.py
If you make a global replacement of 9.3 -> 9.4 in that file you will find that the sagetex example works with the default /usr/local/sage. (The missing quotes that you found are also needed.)
I will not have access to my build system for about 2 weeks and I need that to carry out the complex signing and notarizing process. So I will fix the sage_conf.py file (and my build script) when I get back. Then I can replace the binary with one that handles this issue correctly.
On Sep 9, 2021, at 11:21 AM, Marc Culler @.***> wrote:
I found the problem. The file which does not get cleaned up is ... local/lib/python3.9/site-packages//sage_conf.py
If you make a global replacement of 9.3 -> 9.4 in that file you will find that the sagetex example works with the default /usr/local/sage. (The missing quotes that you found are also needed.)
I will not have access to my build system for about 2 weeks and I need that to carry out the complex signing and notarizing process. So I will fix the sage_conf.py file (and my build script) when I get back. Then I can replace the binary with one that handles this issue correctly.
Howdy,
That seems to fix it! :-)
Thanks for your effort in this. Let me know when you have a fresh build with the fixes. I'll look forward for to getting an official update.
PS: any chance of getting a Universal build in the future?
Good Luck,
Herb Schulz @.***
Currently the plan is to build an ARM distribution once we have access to an ARM build system. We don't plan to do a universal distribution because the download size is already quite large. So most likely there will be separate Intel and ARM disk images before too long -- maybe after the M1X mac mini is released.
The problem with sage_conf.py turned out to be caused by a bug in my build script, not in the sage build process. It is fixed now in the github repository.
On Sep 9, 2021, at 3:18 PM, Marc Culler @.***> wrote:
The problem with sage_conf.py turned out to be caused by a bug in my build script, not in the sage build process. It is fixed now in the github repository.
Howdy,
Dare I ask? Does that mean you can start a build so there will be an update ``shortly''?
Good Luck,
Herb Schulz @.***
No, I can't do that. But you already have all of the changes that I intend to make.
On Sep 10, 2021, at 8:41 AM, Marc Culler @.***> wrote:
No, I can't do that. But you already have all of the changes that I intend to make.
Howdy,
I didn't expect so.
I've put in the changes and it runs fine now. I'll have patience. :-)
Good Luck,
Herb Schulz @.***
I know this is closed but you asked where sagetex can be found. It's in .../local/share/texmf/tex/latex/sagetex.
This is fixed in the v1.2.1 release, so I am closing the ticket.
At some point the unquoted full path of the input file is passed to sage when run in Terminal so there is a failure to find the file if ANY folder along the path has a space.