@Ronan Sorry I was not clear.

What I meant to convey was that I think it would be more beneficial longterm if you wrote the procedures directly in plaintext files, instead of writing them in the GUI and exporting as plaintext.

This came up in an earlier Question thread, in which Joe Riel & I listed off some benefits; revision control, syntax highlighting in 3rd party text editors. I could also mention: greater safety from .mw saving corruption, protection from save issues. Some editors also allow escaped system commands while open; I execute scripts that build my .mla's straight from my vim editor, and I suspect Joe does similar from his Maple-mode emacs, and I expect some others do similarly from Eclipse.

@Ronan I think that you should write all these procedures in plaintext 1D Maple Notation, not 2D Input.

If you are using Maple 2022 then the (new) default is adaptive=geometric, which for your example may not produce curves as close to the x-axis near the all the roots.

The result is somewhat better for this example in Maple 2022 if you supply the option,
    adaptive=true
in that plot call.

Try it like this,
   plot(abs(sin(x)/x), x=-2*Pi..10*Pi, adaptive=true, numpoints=400);
if you are using Maple 2022.

@MAXR Please be specific about what coloring you want.

As I mentioned in my answer, one reason that I constructed an interpolating function is so that it could be more easily plotted and colored using just the usual plot3d command.

You can easily see the advanced coloring options for the plot3d command by looking at the Help page with Topic, plot3d,color in your Maple 17 version.

Of course you can also use the basic color and shading options as described on the Help page with topic plot3d,options in your version.

Please do not post duplicate Question threads on this example.

If you make adjustments and fixes to the code, then you could sensibly add your related followup queries here, instead of in a wholly separate Question thread.

@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.