Error caused by simplify attempting to interpret Maple initialization-file output

[carl-j-love]

To reproduce the error:

Go to your Maple initialization file. Find a line/command that begins
libname:=
If that line/command ends with a colon, change it to a semicolon. At your system command prompt enter
echo "0" | simplify -

Expected output:

0

Actual output:

An error caused by the attempted evaluation of
ToInert(libname:= ...)..
That is, the program attempts to evaluate, with ToInert, any output generated by the cmaple session. The output of an assignment command is an equivalent assignment command with its right side evaluated. This can't be re-evaluated as an expression (in Maple, assignment statements are not expressions), which would be required to pass it to any function, such as ToInert.

Priority:

I'd guess that the priority for fixing this is relatively low as most initialization files have their output suppressed by ending statements with colons.

Possible ways to fix:

This can be fixed with the command-line flags to the cmaple command. The current flags are -q -t. This suppresses most extraneous output. I suggest also using the -B -b and -s flags. Here is the relevant documentation:

The -B option tells Maple that the default system and toolbox libraries should be added to the libname variable used to specify where Maple looks for code repositories. By default -B is implicitly specified. It is most commonly used in addition to * -b* to append to or rearrange the library search order.

The -b option tells Maple that the following argument specifies the pathname of the directory that contains Maple libraries or the full path of the .lib or .mla file of a single Maple library. This initializes the Maple variable libname. By default, libname is initialized with the pathname of the main Maple library (for example, /usr/local/maple/lib). More than one -b option can be specified. When several -b options are used, the first -b option overrides the default libname setting, and subsequent -b options are appended to libname, forming a Maple expression sequence of directory names. The -B option can be used to avoid overriding Maple system and toolbox libraries.

The -s (suppress initialization) option causes Maple to forgo reading initialization files when initiating a session.

For full documentation of Maple's command-line options, issue
echo "help(maple);" | cmaple -

[JacquesCarette]

I case it wasn't clear, this is a bug that shows up when Hakaru tries to parse Maple output. It might be that this issue has been taken care of, in which case it should be closed. But because it affects the parser, and might show up for others as well, it would be go to tweak the Maple call inside of Hakaru so that it does not accidentally trigger this problem.

[carl-j-love]

A followup to our discussion of this in the weekly meeting: One possibility
is to use the command-line flags to skip the user's Maple initialization
file at first and then execute that file later through a read command,
possibly with the output suppressed. The presenting problem for the bug
report is simply caused by there being any output at all from the
initialization file.

Rather than entirely ignoring an initialization file, I think that it'd be
better to decide which kernelopts, interface, and environment-variable
settings are needed/useful for Hakaru, set those, and let the user maintain
the rest of their desired settings.

On Wed, Sep 28, 2016 at 4:38 PM, Jacques Carette [email protected]
wrote:

I case it wasn't clear, this is a bug that shows up when Hakaru tries to
parse Maple output. It might be that this issue has been taken care of, in
which case it should be closed. But because it affects the parser, and
might show up for others as well, it would be go to tweak the Maple call
inside of Hakaru so that it does not accidentally trigger this problem.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#24 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ASYo9ULchi-s-QesNx18-OWlPkHJkcGkks5qutBKgaJpZM4I5CnS
.

[JacquesCarette]

I disagree with the very last part: Haskell-Hakaru needs to be able to have access to a Maple which operates in a predictable, reliable way. In other words just the "let the user maintain the rest of their settings". Note that this only applies to the Maple which will get called from 'hakaru'. Interactive use of the various Maple libraries we've written can be at whim of users' settings, even if that might break things.

I am also fine with having flags (environment variables, whatever) that override this - but these would be for advanced users only.

[JacquesCarette]

I am kind of thinking of this issue as a "won't fix". [Too bad there is no setting in github to allow some issues to be neither open nor closed].