Bug 209992 - wxMaxima doesn't connect with maxima process correctly in second invocation
wxMaxima doesn't connect with maxima process correctly in second invocation
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: wxMaxima (Show other bugs)
5
All Linux
medium Severity high
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-09 07:31 EDT by Alex Lancaster
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-09 09:41:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for invalid maxima=... entry in ~/.wxMaxima (372 bytes, patch)
2006-10-09 09:42 EDT, Rex Dieter
no flags Details | Diff

  None (edit)
Description Alex Lancaster 2006-10-09 07:31:27 EDT
Description of problem:
wxMaxima doesn't connect with maxima process correctly in second invocation

Version-Release number of selected component (if applicable):
wxMaxima-0.7.0a-1.fc5

How reproducible:
Always

Steps to Reproduce:
1. start from a clean installation (remove old ~/.wxMaxima if it exists)
2. wxmaxima
3. try an example, it works
4. quit
5. wxmaxima
6. enter "1+1;" (or any expression)

Actual results:
get "Not connected to maxima!" message.  Upon the second startup (step 5) you
see "Maxima process terminated"

Expected results:
You would be able to enter the expression

Additional info:
I notice that the problem appears to be in the ~/.wxMaxima file.  After step 4,
the ~/.wxMaxima file contains "maxima=1".  If I remove or change the line to
"maxima=0" it works.  This may well be an upstream issue.
Comment 1 Alex Lancaster 2006-10-09 07:37:39 EDT
(In reply to comment #0)

> or change the line to "maxima=0" it works.  

Actually this is not sufficient.  The "maxima=" line needs to be removed completely.
Comment 2 Alex Lancaster 2006-10-09 07:44:07 EDT
There appears to be a discussion of this problem at:

https://sourceforge.net/forum/forum.php?thread_id=1583157&forum_id=435775

I'm using the maxima-runtime-clisp-5.10.0-4.fc5 as the backend for the record.
Comment 3 Alex Lancaster 2006-10-09 07:49:59 EDT
The solution here:

https://sourceforge.net/forum/message.php?msg_id=3943502

worked for me.  Perhaps the package could somehow work around this bug by
setting the maxima= parameter manually?
Comment 4 Rex Dieter 2006-10-09 08:07:33 EDT
> Perhaps the package could somehow work around this bug by
> setting the maxima= parameter manually?

dunno how we'd do that, how to know which maxima-runtime is currently in use?
Comment 5 Rex Dieter 2006-10-09 08:17:56 EDT
Clearly upstream bug, new in wxMaxima-0.7.0a (0.7.0 didn't have this prob)
.wxMaxima *should* contain (something like)
maxima=maxima
or
maxima=/usr/bin/maxima
Comment 6 Rex Dieter 2006-10-09 09:41:57 EDT
OK, found the bug.

%changelog
* Mon Oct 09 2006 Rex Dieter <rexdieter[AT]users.sf.net> 0.7.0a-2
- patch for proper maxima= entry in ~/.wxMaxima (#209992)
Comment 7 Rex Dieter 2006-10-09 09:42:49 EDT
Created attachment 138038 [details]
patch for invalid maxima=... entry in ~/.wxMaxima

Note You need to log in before you can comment on or make changes to this bug.