@acer 

Certainly, the output of:

> kernelopts(opaquemodules=false):
> Typesetting:-UnicodeToEntity;

does not contain this character.

@Markiyan Hirnyk 

Interesting, I have received none since the last forum update (and there should be some).

@nm 

As said above, it is in "View".

@nm 

Indeed, one of the icon buttons does the trick. But in most cases I never remember which one. And their icons (the graphics) are quite unhelpful for me in saying what they are for. So, I prefer going through the menu.

In my opinion, if I have to hover every icon and read its popup to know what they are for, something is wrong with their graphic design.

Look at some threads on this subject (included linked threads therein appear broken, hopefully temporally, because of the recent forum "improvement"):

Maplesoft open source?

GPLing or otherwise liberating Maple

@Alexander zhang 

Cartesian coordinates for a sphere is not the best choice...zz:=sqrt(p^2-x^2-y^2) covers the half of the sphere with z>=0.

@Alexander zhang 

It's zero because of spherical symmetry. For each point on the sphere of radius p with y=y1>0, there is a point with y=-y1. So their contributions add up to 0.

@acer 

The issue of the OP was actually handling the output from a repetition statement (for loop). That output cannot be saved as is to a name and then save/savelibed, I think. Some change to the code would be needed, like storing the results into a container data structure (a list say).

@acer 

Yes, perhaps this could be a useful side of the presence of "." in libname since Maple 16.

Do you say that nonencoded data would produce an error/result an invalid worksheet? As I see in mw worksheets saved by Maple 9.5, little or no encoding is being used in output regions. Yet, they open fine in Maple 17 Standard GUI.

Actually, I use the CLI through Medit, an IDE-like editor. See a screenshot, where output is sent to an output frame, which has a slider (on the right, hidden by the plot window). So, if needed, I can scroll input and output up and down, even while running. And stop by pressing the red Stop button. Also, no risk of loosing my input file.

Actually, I use the CLI through Medit, an IDE-like editor. See a screenshot, where output is sent to an output frame, which has a slider (on the right, hidden by the plot window). So, if needed, I can scroll input and output up and down, even while running. And stop by pressing the red Stop button. Also, no risk of loosing my input file.

This is a bug observable already in Maple 13.02. It works fine in Maple 12.02 and earlier:

> s:=HFloat(-infinity):
> type(s, pos_infinity); 
                                     false
> type(s,positive);
                                     false

I agree, MaplePrime is frequently too slow in loading thread pages. One observation is that along the process of loading a page, it makes a lot of connections to diverse servers. May be that most of them have no good justification and could be removed making the process faster. Another factor is related to pages displaying math content, in particular generated by Standard GUI documents (ie using 2D input). They involve a lot of bitmap files which may make the load process extremely slow (besides typesetting horrible most of the times).

@awass 

It depends on what kind of display you want to get. One posible scenario: you run your computation in the CLI in batch mode, using a .mpl (text) file as input, and send the output to an .out (text) file. Open the .out file with a text editor and select/copy part or all the file. Then open the Standard GUI and paste in 1D-input worksheet mode. You get every selected text line as an input line in the GUI. So, all the results are "displayed", but CLI output is not displayed as GUI output, etc. Similarly, you can open it as plain text.

The Standard GUI worksheet internal representation uses XML. And there is an XMLTools package for its manipulation. I guess that 1D (lprinted) output from the CLI could be transformed programatically into Standard GUI output format, namely generating a .mw worksheet by a script.

@awass 

I think that the unresponsivness of the Standard GUI is much related to its design based on Java, namely running on a virtual machine. And that design probably explains also much of its slowness. This is unlike the old GUI design that was a native application. So, because of the current state of affairs with Maple interfaces, I prefer using the CLI unless I need some specific GUI feature.