Menu
▾
▴
#3523 Frontend + Maxima + SBCL on MacOS fails without stream format configuration
closed
9
2019-02-17
2019-01-28
No
See also thread 39: https://sourceforge.net/p/maxima/support-requests/39/
This is a really important thread to the larger MacOS community and to me, since I spend several hours a week using Maxima for math education worldwide.
Recently I attempted a routine upgrade of Maxima on a Macbook laptop that I use for class to a more recent version. This unexpectedly broke everything.
The MacBook Pro is running OS X El Capitan v10.11.6, which is locked out from the current MacOS Mojave due to an Apple upgrade policy.
I spent an entire night trying to get every Maxima from 5.36 to 5.42 running without success - even compiling from sources. I use the wxMaxima GUI exclusively.
Steps to Reproduce the Error:
1) Download any .dmg from 5.36 - 5.42
2) Install in /Applications according to the README + instructions that remove Apple quarantine.
3) Start wxMaxima
The GUI appears, and reads the user initialization "style.ini" without incident.
In the lower right hand corner a persistent message appears, "Reading Maxima Output"
4) Click Menubar-->Maxima-->Restart Maxima
Message appears in lower right corner, "No connection to Maxima"
Sometimes a message will appear on the GUI proper, "fprintf(stderr, NO MESSAGE)"
After hours of fiddling with firewalls, permissions, etc. I found the enigmatic thread 39 referenced above and entered the line:
(setf sb-impl::default-external-format :utf-8)
into the file
~/.sbclrc file // in other words
/Users/myName/.sbclrc // where myName is my user name
It was only then that the GUI and the Maxima engine could connect and a normal session could be established.
It is remotely possible that creating the .sbclrc file is not what fixed the problem.
I changed many system parameters in the process of trying to fix this, since the cause of the error was so difficult to discover, and the fix itself was esoteric.
On reflection I have made the assumption that the generalization of extended character sets has necessitated the specificaiton of the UTF-8 to be used for I/O between the Maxima kernel and the GUI, but that is pure suppostion on my part.
Compiling Maxima from sources required installation of one of several different Lisp environments, each with its own complexity and set of tradeoffs. It was not clear whether to use brew, or pip, or conda or some other mechanism to produce the cleanest and most austere installation.
A user encountering this bug will first go into the preferences menu and start trying to make sure that the program names and port numbers are correct, but experimentation can corrupt these. On MacOS applications are really just directories suffixed with .app, and discovering which executable is in play is a deep dive, with many perils and possible wrong turns. This can lead to failure to solve the problem because the system-naive user like myself ends up breaking something else that is important in the process.
I think Maxima is one of the most important programs ever written and I appreciate all the work over the years in maintaing and extending it. I started using it in 1981 when Jim Purtillo brought a copy from MIT to the UofI in Champaign. So thank you for keeping it current and effective. It.is.amazing!
See this directory of animations.
http://www.sbcl.org/manual/#The-Default-External-Format tells that SBCL takes the information if to use unicode from the LANG environment variable. That variable tends to be set to <something>.UTF8 on linux systems:</something>
On windows and MacOs systems whose application folder, username or home directory contains non-ascii characters are out of luck by default, instead, except if they use wxMaxima as the front-end: wxMaxima since about 2014 does do an
at start-up in order to make it possible to use greek chars along with the ones the local language provides.
echo $LANG gives me
en_US.UTF-8
So does this mean that something else was causing the problem and I accidentally fixed it?
From: "Gunter Königsmann" peterpall@users.sourceforge.net
Sent: Monday, January 28, 2019 12:26 AM
To: [maxima:bugs]
Subject: [maxima:bugs] #3523 Maxima from 5.36 to 5.42 install fails from missing .sbclrc file
http://www.sbcl.org/manual/#The-Default-External-Format tells that SBCL takes the information if to use unicode from the LANG environment variable. That variable tends to be set to <something>.UTF8 on linux systems:</something>
gunter@marius:~$ echo $LANG
de_DE.UTF-8
On windows and MacOs systems whose application folder, username or home directory contains non-ascii characters are out of luck by default, instead, except if they use wxMaxima as the front-end: wxMaxima since about 2014 does do an
(setf sb-impl::default-external-format :utf-8)
at start-up in order to make it possible to use greek chars along with the ones the local language provides.
[bugs:#3523]https://sourceforge.net/p/maxima/bugs/3523/ Maxima from 5.36 to 5.42 install fails from missing .sbclrc file
Status: open
Group: Includes_proposed_fix
Created: Mon Jan 28, 2019 06:02 AM UTC by Van
Last Updated: Mon Jan 28, 2019 06:02 AM UTC
Owner: Gunter Königsmann
See also thread 39: https://sourceforge.net/p/maxima/support-requests/39/
This is a really important thread to the larger MacOS community and to me, since I spend several hours a week using Maxima for math education worldwide.
Recently I attempted a routine upgrade of Maxima on a Macbook laptop that I use for class to a more recent version. This unexpectedly broke everything.
The MacBook Pro is running OS X El Capitan v10.11.6, which is locked out from the current MacOS Mojave due to an Apple upgrade policy.
I spent an entire night trying to get every Maxima from 5.36 to 5.42 running without success - even compiling from sources. I use the wxMaxima GUI exclusively.
Steps to Reproduce the Error:
1) Download any .dmg from 5.36 - 5.42
2) Install in /Applications according to the README + instructions that remove Apple quarantine.
3) Start wxMaxima
The GUI appears, and reads the user initialization "style.ini" without incident.
In the lower right hand corner a persistent message appears, "Reading Maxima Output"
4) Click Menubar-->Maxima-->Restart Maxima
Message appears in lower right corner, "No connection to Maxima"
Sometimes a message will appear on the GUI proper, "fprintf(stderr, NO MESSAGE)"
After hours of fiddling with firewalls, permissions, etc. I found the enigmatic thread 39 referenced above and entered the line:
(setf sb-impl::default-external-format :utf-8)
into the file
~/.sbclrc file // in other words
/Users/myName/.sbclrc // where myName is my user name
It was only then that the GUI and the Maxima engine could connect and a normal session could be established.
It is remotely possible that creating the .sbclrc file is not what fixed the problem.
I changed many system parameters in the process of trying to fix this, since the cause of the error was so difficult to discover, and the fix itself was esoteric.
On reflection I have made the assumption that the generalization of extended character sets has necessitated the specificaiton of the UTF-8 to be used for I/O between the Maxima kernel and the GUI, but that is pure suppostion on my part.
Compiling Maxima from sources required installation of one of several different Lisp environments, each with its own complexity and set of tradeoffs. It was not clear whether to use brew, or pip, or conda or some other mechanism to produce the cleanest and most austere installation.
A user encountering this bug will first go into the preferences menu and start trying to make sure that the program names and port numbers are correct, but experimentation can corrupt these. On MacOS applications are really just directories suffixed with .app, and discovering which executable is in play is a deep dive, with many perils and possible wrong turns. This can lead to failure to solve the problem because the system-naive user like myself ends up breaking something else that is important in the process.
I think Maxima is one of the most important programs ever written and I appreciate all the work over the years in maintaing and extending it. I started using it in 1981 when Jim Purtillo brought a copy from MIT to the UofI in Champaign. So thank you for keeping it current and effective. It.is.amazing!
See this directory of animationshttps://photos.google.com/share/AF1QipPcNjRJEXWtcweFdC_EQayA2Q9tvUoXnaLaujSnI0qqhGQULanMO8c72yI2jgn-ZA?key=alhPcnhkNUpUd05tRmZHSHdHTG9BQnI0UzV5d2lB.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/maxima/bugs/3523/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Bugs:
#3523Most probably you have found a bug In sbcl. In this case it ldwou be better to fix it in sbcl...
Gunter, I don't see evidence here that there is a bug in SBCL. If there is evidence that there is a bug, please present it, otherwise, I think it is a disservice to Maxima users to make distracting statements.
Why are you so against me? If it is the RAM fragmentation misunderstanding: I really understood the code change in read_matrix() was aimed against that and was proud to have learned something from you.
...and the sporadic test suite failures somehow frighten me. First since they appear on at least three lisps and since if a computer fails seldomly enough to gain the trust of the user computing errors tend to have more dramatic consequences and since the last time someone didn't know about them and marked the tests as "good" I had to spend > 40 hours in order to get the nightly build going again.
In this case http://www.sbcl.org/manual/#The-Default-External-Format states that sbcl's default-external-format will automatically be UTF8 if the LANG variable has the contents it has on the user's computer. But the default-external-format clearly isn't UTF-8 in this case on the user's mac. Which matches my experience on MS Windows (where the default-external-format wasn't UTF-8 when I last tried) and on Linux (on my machine it is UTF-8 even if the LANG variable doesn't end in UTF-8).
Gunter, thank you for all you have done to keep Maxima alive. I really appreciate it.
wxMaxima, in my case, which is just one of the possible frontends for maxima: For maxima it is the others who keep it alive (and who actually do wonders whilst doing so) while I am the bearer of bad tidings if any nightly build fails - most of the cases due to bugs in a compiler, not in maxima, though.
I'm wondering if a similar issue could be affecting using the Maxima kernel from Jupyter notebooks. I've tried twice on MacOS to get that running according to the github instructions and it just didn't work. I think there is great promise for running Maxima from Jupyter, because that places it close to Python applications, ML and AI development. This proximity could help all three, since a rising tide floats all boats. And it insures hardware platform independence. Or I could just wait a year...
From: Robert Dodier robert_dodier@users.sourceforge.net
Sent: Saturday, February 2, 2019 7:41 PM
To: [maxima:bugs]
Subject: [maxima:bugs] Re: #3523 Maxima + SBCL on MacOS fails without stream format configuration
Gunter, I don't see evidence here that there is a bug in SBCL. If there is evidence that there is a bug, please present it, otherwise, I think it is a disservice to Maxima users to make distracting statements.
[bugs:#3523]https://sourceforge.net/p/maxima/bugs/3523/ Maxima + SBCL on MacOS fails without stream format configuration
Status: open
Group: Includes_proposed_fix
Labels: installation macos sbcl
Created: Mon Jan 28, 2019 06:02 AM UTC by Van
Last Updated: Sun Feb 03, 2019 01:33 AM UTC
Owner: Gunter Königsmann
See also thread 39: https://sourceforge.net/p/maxima/support-requests/39/
This is a really important thread to the larger MacOS community and to me, since I spend several hours a week using Maxima for math education worldwide.
Recently I attempted a routine upgrade of Maxima on a Macbook laptop that I use for class to a more recent version. This unexpectedly broke everything.
The MacBook Pro is running OS X El Capitan v10.11.6, which is locked out from the current MacOS Mojave due to an Apple upgrade policy.
I spent an entire night trying to get every Maxima from 5.36 to 5.42 running without success - even compiling from sources. I use the wxMaxima GUI exclusively.
Steps to Reproduce the Error:
1) Download any .dmg from 5.36 - 5.42
2) Install in /Applications according to the README + instructions that remove Apple quarantine.
3) Start wxMaxima
The GUI appears, and reads the user initialization "style.ini" without incident.
In the lower right hand corner a persistent message appears, "Reading Maxima Output"
4) Click Menubar-->Maxima-->Restart Maxima
Message appears in lower right corner, "No connection to Maxima"
Sometimes a message will appear on the GUI proper, "fprintf(stderr, NO MESSAGE)"
After hours of fiddling with firewalls, permissions, etc. I found the enigmatic thread 39 referenced above and entered the line:
(setf sb-impl::default-external-format :utf-8)
into the file
~/.sbclrc file // in other words
/Users/myName/.sbclrc // where myName is my user name
It was only then that the GUI and the Maxima engine could connect and a normal session could be established.
It is remotely possible that creating the .sbclrc file is not what fixed the problem.
I changed many system parameters in the process of trying to fix this, since the cause of the error was so difficult to discover, and the fix itself was esoteric.
On reflection I have made the assumption that the generalization of extended character sets has necessitated the specificaiton of the UTF-8 to be used for I/O between the Maxima kernel and the GUI, but that is pure suppostion on my part.
Compiling Maxima from sources required installation of one of several different Lisp environments, each with its own complexity and set of tradeoffs. It was not clear whether to use brew, or pip, or conda or some other mechanism to produce the cleanest and most austere installation.
A user encountering this bug will first go into the preferences menu and start trying to make sure that the program names and port numbers are correct, but experimentation can corrupt these. On MacOS applications are really just directories suffixed with .app, and discovering which executable is in play is a deep dive, with many perils and possible wrong turns. This can lead to failure to solve the problem because the system-naive user like myself ends up breaking something else that is important in the process.
I think Maxima is one of the most important programs ever written and I appreciate all the work over the years in maintaing and extending it. I started using it in 1981 when Jim Purtillo brought a copy from MIT to the UofI in Champaign. So thank you for keeping it current and effective. It.is.amazing!
See this directory of animationshttps://photos.google.com/share/AF1QipPcNjRJEXWtcweFdC_EQayA2Q9tvUoXnaLaujSnI0qqhGQULanMO8c72yI2jgn-ZA?key=alhPcnhkNUpUd05tRmZHSHdHTG9BQnI0UzV5d2lB.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/maxima/bugs/3523/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Bugs:
#3523On MS Windows Xmaxima and iMaxima are affected, as well as wxMaxima => I guess it to be probable that jupyter is affected, too.
Robert -
Thanks as always for the clarifying remarks.
From: Robert Dodier robert_dodier@users.sourceforge.net
Sent: Saturday, February 2, 2019 7:33 PM
To: [maxima:bugs]
Subject: [maxima:bugs] #3523 Maxima + SBCL on MacOS fails without stream format configuration
Van, I've updated the summary to focus on what appears to be the root of the problem, which is that the stream format must be specified, otherwise Maxima fails.
[bugs:#3523]https://sourceforge.net/p/maxima/bugs/3523/ Maxima + SBCL on MacOS fails without stream format configuration
Status: open
Group: Includes_proposed_fix
Labels: installation macos sbcl
Created: Mon Jan 28, 2019 06:02 AM UTC by Van
Last Updated: Mon Jan 28, 2019 07:20 AM UTC
Owner: Gunter Königsmann
See also thread 39: https://sourceforge.net/p/maxima/support-requests/39/
This is a really important thread to the larger MacOS community and to me, since I spend several hours a week using Maxima for math education worldwide.
Recently I attempted a routine upgrade of Maxima on a Macbook laptop that I use for class to a more recent version. This unexpectedly broke everything.
The MacBook Pro is running OS X El Capitan v10.11.6, which is locked out from the current MacOS Mojave due to an Apple upgrade policy.
I spent an entire night trying to get every Maxima from 5.36 to 5.42 running without success - even compiling from sources. I use the wxMaxima GUI exclusively.
Steps to Reproduce the Error:
1) Download any .dmg from 5.36 - 5.42
2) Install in /Applications according to the README + instructions that remove Apple quarantine.
3) Start wxMaxima
The GUI appears, and reads the user initialization "style.ini" without incident.
In the lower right hand corner a persistent message appears, "Reading Maxima Output"
4) Click Menubar-->Maxima-->Restart Maxima
Message appears in lower right corner, "No connection to Maxima"
Sometimes a message will appear on the GUI proper, "fprintf(stderr, NO MESSAGE)"
After hours of fiddling with firewalls, permissions, etc. I found the enigmatic thread 39 referenced above and entered the line:
(setf sb-impl::default-external-format :utf-8)
into the file
~/.sbclrc file // in other words
/Users/myName/.sbclrc // where myName is my user name
It was only then that the GUI and the Maxima engine could connect and a normal session could be established.
It is remotely possible that creating the .sbclrc file is not what fixed the problem.
I changed many system parameters in the process of trying to fix this, since the cause of the error was so difficult to discover, and the fix itself was esoteric.
On reflection I have made the assumption that the generalization of extended character sets has necessitated the specificaiton of the UTF-8 to be used for I/O between the Maxima kernel and the GUI, but that is pure suppostion on my part.
Compiling Maxima from sources required installation of one of several different Lisp environments, each with its own complexity and set of tradeoffs. It was not clear whether to use brew, or pip, or conda or some other mechanism to produce the cleanest and most austere installation.
A user encountering this bug will first go into the preferences menu and start trying to make sure that the program names and port numbers are correct, but experimentation can corrupt these. On MacOS applications are really just directories suffixed with .app, and discovering which executable is in play is a deep dive, with many perils and possible wrong turns. This can lead to failure to solve the problem because the system-naive user like myself ends up breaking something else that is important in the process.
I think Maxima is one of the most important programs ever written and I appreciate all the work over the years in maintaing and extending it. I started using it in 1981 when Jim Purtillo brought a copy from MIT to the UofI in Champaign. So thank you for keeping it current and effective. It.is.amazing!
See this directory of animationshttps://photos.google.com/share/AF1QipPcNjRJEXWtcweFdC_EQayA2Q9tvUoXnaLaujSnI0qqhGQULanMO8c72yI2jgn-ZA?key=alhPcnhkNUpUd05tRmZHSHdHTG9BQnI0UzV5d2lB.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/maxima/bugs/3523/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Bugs:
#3523Van, I've updated the summary to focus on what appears to be the root of the problem, which is that the stream format must be specified, otherwise Maxima fails.
Change summary and add tag to emphasize that it is a wxMaxima + Maxima problem.
The problem described by the user in my experience makes imaxima and Xmaxima unusable, too => Changed the tags and the title accordingly.
Commit d655a14 puts
(setf sb-impl::*default-external-format* :utf-8)into the code which is executed by Maxima when the program is launched, so, I hope, it is no longer necessary to put that into a init file or anything like that. Closing this report accordingly. If there is any further problem related to this, please open a new bug report.Van, thanks for the bug report. I would like to ask that if you open new bug reports, please use the web interface to reply to comments instead of replying directly to the email updates. The email updates are pasted into each comment reply with the entire history of comments, so that the bug report becomes hard to understand.