@awass 

At one point you mentioned pasting in the content. I was trying to ascertain the source for that, amongst other things. But now you claim all is *typed* into the Maple GUI. That's a contradiction.

So what keys stroke combination are you using to get the new lines, in the same Execution  Group, I was wondering.  In at least one of your examples there are three lines of code, where the parser is complaining only about the second line split. I was trying to figure out if the typed/pasted input (special character) for a line split is always the same for you.

I say that because this is OSX, and because I've seem some weirdness on OSX and plaintext in Maple before, and because OSX does weird things with LF/CR, I thought I'd try and narrow down exactly what was entered (typed or pasted).

I'll note that I've never seen this exact complaint before, even from other Mac OSX users. Yet it seems like a hint to me, that OSX boxes can have Enter and Return mapped weird, compared to other OSes. My last three comments have been about this. I feel like this conversation is an uphill battle for exact details. I give up.

@awass Yes, it was already clear what sort of thing was in the file.

But that's not what I've been asking.

Since I have no problems ever pasting in what your last Comment shows, I have a slight suspicion that you may be working from a text file that contains some special hidden character.

It's just a guess.

I can only check if I can download the actual text file, rather see its contents reproduced here inline.

@Carl Love I do not use ProcessClock, because I find its behavior unclear and inconsistent. I much prefer to use time[real] when measuring wall-clock performance.

Here is some behavior that I don't see clearly documented or explained. In this first attachment there is evidence that Now(ProcessClock) acts quite a bit like time() in the sense that it is reporting the total (added) CPU time resources of subthreads. I also contrast that with the behavior of time[real]() here.

But in this same worksheet there is an example that seems to illustrate that kernel threads spawned by Threads:-Sleep don't contribute to a matching increment in Now(ProcessClock). Again, this is more like I'd expect from time() than time[real]().

ProcessClock.mw  (I run this with the !!! triple exclam icon in the GUI's main menubar.)

But in this second attachment I simply have some calls to Now(ProcessClock) in separate execution groups. I execute this worksheet by waiting a few seconds, between hitting <Enter> directly, on the input lines. Here I see the results from ProcessClock go up in a manner close to the duration I wait between execution of different statements. So, to me, this seems more like behavior analogous to that of time[real]() rather than time(). But that seems to contradict the earlier evidence to the contrary.

ProcessClock_wall.mw

The behavior of ProcessClock seems inconsistent, and not at all well documented.

@awass I was trying to say that what might be germane (perhaps in an OSX specific way) is a plaintext file who's content matched what you pasted into maple. Not the plaintext 1D or typeset 2D .mw file.

I have a suspicion that what is getting pasted into the Maple GUI may contain the key difference.

@Ramakrishnan Sorry, but I don't understand what you're trying to say.

@Ramakrishnan When I execute your worksheet in my Maple 2018 it runs fine, and t1 gets assigned a numeric value in the first line, and it all seems in order. Please try again. Maybe you're doing something weird.

@Ramakrishnan As I mentioned, the nature of the animation wasn't you main difficulty or issue. You wanted to know how to make it play, programmatically. So I added the SetProperty call and added it to your code (and for which you seem to have thanked Tom).

@wlferguson19 I don't understand what you mean. The pair [x,y] = [sin(3t),cos(3t)] parametrizes a circle, which doesn't intersect itself (leaving alone the originating point, or points following overlap, from discussion).

@wlferguson19 I don't understand what you mean. The period of the path is Pi. It repeats every Pi unit of the parameter. If you make the parameter go from 0 to 2*Pi then the x- and y-coordinates of the intersection points will just be repeated (as will the curve's path).

Download intersect_2Pi2.mw

@nepomukk The sin command uses the result of sign on the argument, but it doesn't offer anything but the default lexicographic ordering of variables to determine that sign.

It is possible to force the issue, with a forced sort and a custom call to sign.

Download signsin.mw

@minhthien2016 

Download intsimp.mw

@awass This might be a clue.

When editing normally within an Execution Group, pressing the <Enter> key executes the statements and pressing <Shift><Enter> inserts a new line and moves the cursor down.

Your problematic examples are in Execution Groups that appear in the .mw file as two adjacent separate XML Equation substructures, which I don't recall seeing before to represent a single statement.

Normally, when one pastes in code containing newlines (LF, \n, U+000A) then all is ok. For example, in the last attempt in your attached worksheet there is such a newline after the Q:=proc(x) and before the sin(x). 

But I suspect that something else is getting pasted in, after the sin(x), that may be causing interpretation by the GUI as two separate statements. (I don't mean a hidden semi-colon, as that seems to come as a consequence of further conversion to 1D, not the original cause.) And this seems to cause the GUI to send the first and second portion to the kernel separately.

The first portion being like,

Q:=proc(x)
  sin(x)

and the second portion being,

end proc;

There was a post a month (or several) ago, in which a Mac OSX user was having trouble due to an unexpected character in a text file. I am wondering whether your issue might be similar. For example, something to do with a difference between a carriage return and a newline.

I have never seen anyone report this problem before. On the one hand, there is some evidence that were some changes to the 2D parser in Maple 2018, but on the other hand this situation doesn't seem a general problem. As a guess, I suspect that it might be a Mac OSX specific issue, with something (CR, LF, etc) being misinterpreted and causing an unintended statement split.

If my guess is right, then diagnosing the problem might require examining the original plaintext (if you copied from that, with the mouse), or examining the file, or knowing which key strokes were using in writing it.

@Joe Riel Oh, right, sure, I would believe that. I just meant that the whole topic relates to kernel-based parameter processing in general, (including, but not only) what happens in the debugger.

@José Goulart I figured that you were using an older version, and that for some reason you wanted to keep it a secret.

I've now changed the header on the Question, to denote the Produce as Maple 18. (You could do that too, in future.)

@Joe Riel I changed it to an Answer, as I too was preparing to mention _npassed .