of many unix utilities to win32. I use them rather frequently, and sometimes  in shell (sh) scripts.  So, could it be that those scripts can work also natively in Windows.

During the years when I was "ambassador" of Maplesoft in Argentina, it was typical after a while of talk with an experienced user of Maple, that he/she "throws"  in a  sudden and violent manner his/her  set  of bugs  as a kind of discharge  of many frustrations. 

I have no evidence that any of them has ever reported these bugs to Maplesoft (probably very few if any did it). And though in every case I have asked them to give me the details for analysing myself and forwarding to support, they never did it either.

During the years when I was "ambassador" of Maplesoft in Argentina, it was typical after a while of talk with an experienced user of Maple, that he/she "throws"  in a  sudden and violent manner his/her  set  of bugs  as a kind of discharge  of many frustrations. 

I have no evidence that any of them has ever reported these bugs to Maplesoft (probably very few if any did it). And though in every case I have asked them to give me the details for analysing myself and forwarding to support, they never did it either.

One way is to read or search MaplePrimes...

solving-equations-expanding-brackets

cananybodyhelpmesolvetranscendentalequationmaple

labelingttyeyesonly

I wonder whether an equivalent stuff is not already implemented in the code of the 'MathML' export commands. Eg:

MathML[ExportPresentation](Int(1/(x^2+1), x));

Produces a code that inserted in this online converter produces a correct output.

So, may be that via mathml the pieces are already available.

On the other hand, the code for 'MathML' export, if available, could perhaps be adapted for direct export to LaTeX.

I agree basically with you description of the current situation (not with the wording). But as it puts the burden of the solution on the user, is not satisfactory.  And as an improvement of the library seems currently technically feasible, it would be very convenient for the users that it were done as soon as possible.

I do observe rather frequently that users have problems because of name clashes with command options, when packages are loaded. And the probability of name clashes increases with time as new packages are added to the system. 

Indeed, in the mean time, this "hack" should be better documented. But I do not expect that even an improved documentation on this issue do more than mitigate   this problem.

There are (perhaps many) unprotected option names for which clashes may occur, just taking into account those names in the standard library. It should not be necessary to use this hacker syntax as in:

':-Explicit'

because, among other reasons, this is not how options are documented to be used.

I have been told by a developer how (potentially) this workaround should not be needed  if keyword parameters were used:

with(plottools):
point;
                           plottools:-point

proc(a, {point::numeric := 0}) "point" = point end(point = 5);                             
                             "point" = 5

But, apparently, this would imply a massive update of the library...

Apparently, this is the only purpose of this argument in this line in 'solve':

11   `solve/split` := member('split',Args,'i') and 2 < i;

And then 'SolveTools' routines use its value.

So, this variable has not to be protected:

restart:
protect(`solve/split`);
solve({z*x^3-7*y*z,z*x*y-x+z^3*y^2-4,z*x^2-x*z^5-1},{z,x,y},split);

Error, (in solve) attempting to assign to `solve/split` which is protected

What I see in the code is that the option 'split'  "selfremoves" from the argument list of 'solve'. Eg:

p:=x^2-a:
trace(solve):
solve(p,{x,y,z},split);
{--> enter solve, args = x^2-a, {x, y, z}, split
                            2
                  Args := [x  - a, {x, y, z}, split]

                      Variables_is_list := false

                         solve/split := true
                               2
                     Args := [x  - a, {x, y, z}]

For this purpose, a global variable is used:

`solve/split`;
                                 true

It has always been right and remains unchanged since my registration in 2005.

On the other hand, email notifications sent to a wrong email address should bounce. That would be easy to check by the system manager. Will has never told me about that.

I wonder whether my notifications are being sent.

At a point it tries to calculate:

`simplify/power`((1+limit(-x/(p-1)/(x^p),x = infinity)*p
-limit(-x/(p-1)/(x^p),x = infinity))/(p-1));

and simply takes the limits inside the brackets.

This was observed using eg:

infolevel[all]:=3;
trace(int):
trace(`int/cook/nogo1`):
trace(`int/elliptic`):
trace(`simplify/trig`):
trace(`simplify/power`):
trace(`simplify/RootOf`):
printlevel:=5:

I have no experience on these subjects myself, but I have recently read Tim Daly praising git.

One point is whether the integral should be given in piecewise or equivalent form (eg a list). Ie something like this "fabrication":

I1 := Int( 1/x^p, x=1..infinity );
v:=value( I1 );
v1:=subsop(1=limit(op(1,v),p=1),v);
piecewise(p<>1,v,p=1,eval(v1,1));

{                   (-p + 1)
{                  x         - 1
{      lim       - -------------        p <> 1
{ x -> infinity        p - 1
{
{           lim       ln(x)             p = 1
{      x -> infinity

that I am not receiving the notifications that I should receive, eg from this thread to which I am subscribed.

Again, I never received any email notification from  MaplePrimes, before or after the last update.