@Ronan There is no reason to save in .mws format. Using 1D input doesn't require that. It's related to that warning about the format.

@ecterrab It can still be important to know that the OP was using a Physics update (without the prior lack of knowledge that he might move to, say Maple 2022.2).

One point is that any proposed solution developed by a responder for any stock Maple 2022 point release might conceivably run differently on the OP's system (with its Physics update). Therefore a responder might need to mimic the very same environment, or risk wasting time.

@ecterrab This Question was posted on October 22, 2022, and (at that date) its attachment was last saved in Maple 2022.1.

The update Maple 2022.2 was only released to the public on October 28, 2022.

Using stock Maple 2022.1, without Physics updates separately installed, the attachment does not execute as the OP's sheet shows inlined in the Question.

That is why I asked about whether he had installed a Physics update. It was indeed relevent to what was originally posted.

For example,

Download Unit_of_t_M2022.1.mw

Using the later Maple 2022.2 updated point-release then I see the same Warning as you showed, and as was in the original Question.

@zenterix Irrespective of your present Question's issues, using savelib and savelibdir is not great methodology -- especially if you are new to all this.

I suggest thar you use LibraryTools commands instead, and always explicitly reference the .mla (including, but not only by, its fully qualified location).

@Carl Love I agree with what you've written here (including what both you and dharr have written about tables).

But I'd like to respond about whattype. I like that wording you used: it is not useful because it doesn't always tell the "complete story".

I can hardly imagine using whattype for serious Maple coding. In some sense it's worse than useless, because it's existence lulls users into poor programming technique alongside the occasional lack of specificity in its return values.

Something can be more than one type, and last name evaluation can hide even that. Also, the type system is not really hierarchical. In consequence of that a Maple program should not ask what type something is, instead of checking explictly whether it is each of some collection of types.

@mmcdara Do you really need the symbolic integration?

The following numeric integration is pretty quick, 0.5sec to compute plot `p` on my machine, and about 7sec if I don't force the quadrature method.

Download DoesThisWork_ac.mw

[edit] Actually, it can be produced even quicker, about 0.11sec on my machine using Maple 2015.2. (I omit the final plot below, which looks the same.)

Download DoesThisWork_acc.mw

@Ronan 

For the kernel&GUI to pick up the location automatically it should be like:

   toolbox/foobar/lib/blah.mla

It looks like the following is automatically found ok, and indeed it is of that form:

toolbox/personal/lib/RationalTrigonometry.mla

But the following is not of that form, and indeed you showed it not getting found automatically after restart:

toolbox/personal/AlgCalc/AlgCalc.mla

So you ought to be able to adjust the folder name accordingly.

By "automatically" I mean that the location is automatically added to `libname`, upon launch/restart.

@tomleslie I get the following in Maple 2022.2, which corresponds to the what the OP described.

I don't have any additional Physics package update installed.

Download dunder.mw

I I re-execute your backT2.mw file in my Maple 2022.2 then the output changes and the backtick problem appears.

My understanding is that Edgardo had corrected this issue previously (ie. prior to today) in a Physics package update. So if you have such installed you might already have a fix.

@tomleslie The OP is objecting to the presence of the backticks in the pretty-printed output of `X__a,b`.

The OP clearly has not mentioned any problem with entering these names as input.

Your worksheet was last saved in Maple 2022.1, in which version the output rendering problem being discussed does not occur.

The OP's problem occurs in Maple 2022.2 (with default settings, eg. typesetting=extended).

@Ronan If you did not create the AlgCalc.mla archive file then a call to savelib can inadvertantly store your modules/procedures in an unintended (other) .mla file in the libname path that just happens to be user-writable.

You may have inadvertantly stored your modules/procedures in some other .mla files from add-on packages that you installed -- that might have been the first writable and extant .mla files found during the savelib attempt.

That's why in my original Answer above I put a link to the LibraryTools package's Save command. You can first use that package's Create command (once) to create a .mla archive file, and then use its Save command to store modules/procedures in it.

I happen to know how to use march and savelib, but there are pitfalls (and the documentation of savelib is very poor), and I don't recommend that anyone who's not an expert use them. Such difficulties are part reason why LibraryTools was made.

But ignore all mention or use of savelibname, which was a sorry attempt at making savelib problems less common.

ps. If there is actually no writable .mla archive present then savelib can litter a directory in the libname path with .m files.

This appears to be a regression in behaviour, newly introduced between Maple 2022.1 and Maple2022.2.

I am going to submit a bug report.

It is possible to workaround the issue by changing from extended to standard typesetting mode (when output is pretty-printed).

   interface(typesetting=standard):

I worry that may not be wholly satisfactory, since typesetting=extended is the default in recent releases, and you may find other things not to your liking if you change that setting.

@Christopher2222 I don't understand what "paper" has to do with it. My answer was about mathematical correctness. Maple's 2D math pretty-printing is not what we're discussing.

If I wrote sqrt(c/m) or sqrt(c)/sqrt(m) after having computed a result of sqrt(m*c)/m then that would be incorrect and wrong unless there were something special about the variables which justified the replacement.

There are values of m & c for which  expression sqrt(c)/sqrt(m) is not mathematically equivalent to sqrt(m*c)/m. There are real values where they're not equal. Worse still, there is a set of nonzero measure in RxR where they're not equal.

Plot the real and imaginary components of those expressions, and see for yourself.

@C_R Your question has built into its very words the idea that sqrt(c/m) is a simplification of sqrt(m*c)/m.

Even when the equivalence is true (ie, under some conditions) it is not obvious that the sqrt(c/m) is necessarily mathematically simpler than sqrt(m*c)/m. Yes, it may consist of less operations or leaves of computation. But there can be more to simplicity than mere brevity. Sometimes it can matter more which forms are more useful in terms of subsequent manipulation, and that in turn can even depend on the characteristics of the Computer Algebra System in question.

[edit] Sometimes assumptions might be part of some context, eg. `m` representing mass. In such situations it's not unnatural for the onus to be on the user to somehow convey that. Would you call that too as, "trial and error"?

By the way, next Wednesday & Thursday, Nov 2-3, is the Maple Conference 2022, hosted by Maplesoft.

The conference program shows a talk on the Thursday titled, "Maple Programming: An Overview on Creating Packages", Paul DeMarco, Senior Director, Maple Development.

@Ronan Put the code with the $include directives in a plaintext .mpl file. Then use the read command on that single file.

ps. It seems weirdly and unnecessarily roundabout to write the procedure such as your SignedArea in a Maple worksheet, then use commands in the worksheet that store/export it as a .mpl file. I'd rather write my source in plaintext files to begin with, so that I could use decent revision control, a code editor of my choice, etc. I could read them into any session as I wanted, while prototyping functionality. Once satisfied I could write a module (again: itself authored in a plaintext file, with $include directives for its member procedures) and either read that in or store it all in a .mla archive. It seems to me that you are having difficulty in letting go of the habit of having your long-term build methodology use the GUI for lower level steps.

The proposed idea is to have a long-term build methodology that is purely textfile based. In the end it could all be loaded (and optionally stored to .mla) by calling read on one master build .mpl plaintext file. That single read call could be made in the GUI, or from a shell (running command line interface of Maple, interactively or as a batch/script execution which I suspect is what Joe meant elsewhere as you cited).

Sorry, I don't have time just now to write in more detail, or to reconfigure your whole example.