Here is a summary of the issues discovered with rc4, with responses.
>From Nikolaos I. Ioakimidis <ioakimidis@otenet.gr>:
>
> (i) From the Help of XMaxima the options Maxima HomePage,
> Project Page and Bug Reports still do not work (and give an
> error: "couldn't execute c:\windows\command.com. No such
> file or directory") exactly as has been the case with rc1. This
> has to and can be corrected before the final release of 5.9.0.
Fixed by Mike Clarkson.
> (ii) In the tests of Maxima there has been an error in rtestode.mac
> in Problem 43 there in the command
>
> DESOLVE([EQN1, EQN2], [f(x), G(x)])
>
> The error has been that "x+2 contains more than one independent
> variable. . . . ". Perhaps this Problem can be omitted or corrected
> before the final release of 5.9.0. (I do not know whether this error
> is simply due to my own previous commands.)
This problem was caused indirectly by the failure of maxima's compile()
command. It has been fixed by including enough include files for GCC and
by modifying the exact PATH syntax under Windows 98. I did the latter;
thanks to David Billinghurst for suggesting the correct list for the
former.
> (iii) Furthermore, although everything has been perfect with the English
> version of XMaxima, when I prepared the Greek version (cp1253
> encoding for the further support of the Greek characters such as %pi)
> I am now unable to use the icon of Maxima and I have to use Maxima
> from Start -> Run. This is not a serious problem, but I do not know
> why it happened. (I have restarted the computer, but the problem
> remains there, it persists.) The message is: "winkill has caused an
> error in winkill.exe. Winkill will now close". This problem was not
> present with 5.5 beta. Perhaps it should be corrected or I did
> something wrong myself.
I hope that this problem will be fixed by moving to StarKits, as was
suggested elsewhere on the list.
> (iv) Finally, restarting Maxima from File -> Restart of XMaxima
> seems to require about 15 sec, more time than it required with
> 5.5 beta, but this is not important. More important is that after
> restarting the old command prompt, e.g. (C10), and the new
> one, (C1), appear in the same line and this has to be corrected.
> (The presently missing introductory text for Maxima will be
> sufficient for this situation to disappear, I think so.)
This problem has been fixed by changing the default MAXIMA_USERDIR under
Windows 98 to <maxima_prefix>/user. Thanks to paricaud@club-internet.fr
for suggesting this very subtle workaround. I would still like to better
understand what is/was happening here.
>From Valerij Pipin <vpipin@irk.ru>
>
> In taking the given src.rpm I've succesfully rebuild the rpms for my ALTLinux
> system. All tests are passed and I glad to see that itensor works fine for
> all lisps. Though for gcl you have to compile sources at first.
> Some strange thing is happened when I run the "swartz.dem" within xmaxima
> the final plot for the Swarzshild potential is'nt appeared. However, when I
> batch this file from console everything is ok.
There are many problems in the share/demo files for this release. I will
make sure the release notes say this. We will focus on bug fixes in
share/demo files in a later release.
> Just for an experience I install the windows version. It runs satisfactory
> even under the wine. All tests were passed. However was not able to compile
> sources for itensor package within xmaxima.exe to test it. The process hangs
> after input the command for compilation. I use
> :lisp(compile-file "c:\maxima\.......\itensor.lisp")
I hope the above-mentioned compilation fixes solve this problem.
>From Stavros Macrakis <stavros.macrakis@verizon.net>
> There are a few issues I've come across so far, and have entered them
> into the bug database. Summary:
Thank you very much for using the bug database.
> -- Control-B has been defined to open a Batch file; it *also* has the
> classic Emacs behavior (since forever -- it's wired into my fingers) of
> going back one character. That is, if you quit out of the Batch
> operation, you find that you have gone back one character. There are
> many other such glitches.
> https://sourceforge.net/tracker/index.php?func=detail&aid=677799&group_i
> d=4933&atid=104933
I agree that this should be fixed. Unfortunately, I'm afraid it will
have to wait for a later release. I don't think it is a show-stopper.
> -- (apropos "foo") crashed Lisp several times, but I can't reproduce it
> now.
>
> -- Still have case problems. Input: [a,A,b,B,c,C] comes back as [a, A,
> b, B, C, C].
> https://sourceforge.net/tracker/index.php?func=detail&aid=677843&group_i
> d=4933&atid=104933
Although we could fix a couple of individual case problems, I think we
really need to deal with case-sensitivity in a better way. I am putting
off the debate and implementation of the solution for a later release.
This issue is *very* high on my radar.
> Wolfgang Jenkner <wjenkner@inode.at>
>
> > -- Still have case problems. Input: [a,A,b,B,c,C] comes back as [a, A,
> > b, B, C, C].
>
> Not so for Clisp and SBCL.
>
> (C1) [a,A,b,B,c,C];
> (D1) [a, A, b, B, c, C]
>
Sigh. See previous comment.
>From C Y <smustudent1@yahoo.com>
>
> Well, I tried the install on my Windows box at work. I only note a few
> problems, most minor and probably none severe enough to justify a
> further delay.
>
> 1) In the html intro, the maxima logo has a messed up background.
> Probably the thing to do there is make a version of the logo with a
> white background specifically for that page - I think the transparency
> is causing issues.
This doesn't seem to be a widespread problem. Perhaps more details will
show up after more people have tried 5.9.0.
> 2) The file on sourceforge downloaded as a .exe.zip file, which it
> isn't. I had to rename it in the dos prompt. Once I did that it
> worked fine though.
Seems to be an individual browser problem.
> 3) The startup time was extremely long, on the order of 30-40 seconds.
> I know this is a known problem but I'm almost postitive it will be the
> number one bug report filed by people who try out 5.9.0 on Windows and
> will likely be a killer for some. I don't propose holding up the
> release, which is after all a developer release, but we should probably
> be ready for the reports this will generate. Has anyone figured out
> what might be causing it? The most promising thing I recall was a
> report that smaller hard disks didn't have as long a wait, but 5.5beta
> doesn't seem to have that problem. Anyway, thought I'd mention it.
I hope this problem is fixed. See above.
> Vadim V. Zhytnikov <vvzhy@mail.ru>
>
> It would be great to have on Windows
> simple text console Maxima in addition
> to Tcl/Tk xmaxima interface.
> It seems that maxima.bat serves the purpose
> but I noticed that various path variables
> like FILE_SEARCH_PATH aren't properly set
> (in xmaxima they are OK) which somewhat
> limits maxima.bat functionality out of the box.
> So maybe this is a feature request for
> future releases - make maxima.bat fully
> functional and place reference on it in
> Windows menu.
I have plans to fix this problem in general in a later release. In the
meantime, I will mention the limitations in the release note and suggest
setting the environment variable MAXIMA_PREFIX to point to the maxima
directory as a workaround.
>From Vadim V. Zhytnikov <vvzhy@mail.ru>
>
> Finally I realized why compile(f) test fails under
> xmaxima on Linux. Situation here is quite different.
> On Windows
>
> f(x) := x+2; compile(f);
>
> always fails due to some gcc problems.
... which should be fixed now...
> On Linux the above test works
> fine if we execute it manually
> but fails inside Maxima test suite.
> And the reason is very simple.
> To run tests xmaxima make cd into
> tests directory which is not writable
> by ordinary user. Maxima just unable
> to create any intermediate temporary
> files. Maybe this is gcl compiler
> problem - it should create files
> in some temporary directory.
If it is easy to get GCL to use a temporary directory for compilation,
it didn't leap out at me from the documentation. I'll mention the
problem in the release notes.
The entire test suite is a little fragile right now. We'll have to look
at it later.
> Any workarounds?
None simple enough to implement at this late date.
In a previous summary from myself:
>
> Several windows issues have been identified. I need more help to fix
> some of them:
>
> 1) Some numerical tests fail on amd processors. I tried to configure gcl
> for a lowest-common-denominator cpu, but either I misunderstood the
> directions I got, or the directions were wrong. Either way, I think I
> have fixed the problem, but I have no way to test it. (See below.)
I hope this is fixed, but I haven't been able to verify it.
>From paricaud@club-internet.fr
>
> >> 3) The startup time was extremely long, on the order of 30-40 seconds.
> >> I know this is a known problem but I'm almost postitive it will be the
> >> number one bug report filed by people who try out 5.9.0 on Windows and
> >> will likely be a killer for some. I don't propose holding up the
> >> release, which is after all a developer release, but we should probably
> >> be ready for the reports this will generate. Has anyone figured out
> >> what might be causing it? The most promising thing I recall was a
> >> report that smaller hard disks didn't have as long a wait, but 5.5beta
> >> doesn't seem to have that problem. Anyway, thought I'd mention it.
>
> >Again, I haven't seen this on any machine I've tried. Was this issue discussed on the list at some point? Do you have any idea what the problem could be?
>
> On my Windows98 Machine I have also a 50s startup Time.
> But when I set the environment variable MAXIMA_USERDIR to an almost empty directory then startup time is only a few seconds.
> I guess that by default , the MAXIMA_USERDIR is something like "C:" and may be there is during startup a routine which searches each libraries on the whole disk, or something like that.
>
> So it is better to create a maxima.bat file containing:
> set MAXIMA_USERDIR=C:\MAXIMA_USER
> "C:\Program Files\Maxima-5.9.0.rc4\bin\xmaxima.exe"
>
> Or add the following command to autoexec.BAT
> set MAXIMA_USERDIR=C:\MAXIMA_USER
Thank you very much for this observation.
--
James Amundson <amundson@fnal.gov>