No conversion works with the context pannel. I compare below to the former user interface.

@Gillee

Below is a screen shot of the GPU graph (from process explorer -> properties of the corresponding mserver.exe task) when excecuting the example from ?cuda.
At the blue line, a restart was pefrormed. The red arrow points to the excecution of

That is supposedly the matrix multiplication performed by the GPU. No increase of GPU usage is visible. Whatever the GPU does, only a fraction close to 0% of its modules are involved not in an efficient way.

I would contact support. Something is not working as intended.

@FDS_ERT 

I spend quite some time on it, but was not sure if that is worth the effort. Thank you for confirming.

@nm @acer @dharr

For the above testcase (and other codes) I have found a workaround on my installation: A first worksheet must be opened before the execution of code can be interrupted in a second worksheet.

The first worksheet can be a blank sheet or the start page. It is not required to enter code in the first worksheet sheet and run it before the code is executed in the second worksheet. It is even possible to close the first worksheet (after starting Maple) without any execution or entering code before a second worksheet is opened in which execution is interruptible.

Is that reproducible on other installations?

I also realized the following: The UI (jawa.exe) provides only one interrupt button that must connect to separate kernels (mserver.exe).

The communication to the first worksheet (magenta, worksheet automatically opened after startup) works apart from interrupting. Input can be entered and output is returned

The second worksheet (blue), is interruptible with the major difference that much less dlls are attributed to this task. Notably, no NVIDIA dlls are attributed to this task (and using the GPU including GPU memory).
Opening a third worksheet does not show any differences to the second worksheet (threads and dll are the same apart from the process ID of the mserver task).

Contrary to what I have feared before (“could be JAVA related”) I am now more inclined to say that the first worksheet is setup differently and MapleSoft should be in the position to fix the interrupt issue.

Edit: loaded NVIDIA dlls in yellow in the thread view before executing anything. (Thread 11284 is active all the time.)

@dharr 
I had a closer look at the interrupt button.

The tool tip pops up with a delay of about one second. The tool tip is displayed right to the tip of the mouse pointer. Left to the pointer there is a faction of the button accessible to interrupt. The tiny buttons do not make it easy to left-shift the mouse pointer to interrupt (one has to stay within the activated button).

@nm 
I was not clear.
Maple 2020 was developed under Oracle.

Maple 2021 under Eclipse

The change was visible on the UI which looked differently. Since then a few UI functions are not working temporaily after start-up from hibernation (palettes do not open). That is annoying and persist with the new UI. However, I think we a dealing here with something new.

@dharr

My current thinking is the following:

I do not think that we are facing performance trade-offs here, because polling the OS for "has this button been pushed" will not slow down computation as there are many more items on the screen that have to be checked frequently for changes. In this case the mouse button will generate an interrupt (click occured) and then the windows manager of the OS will determine if a windows element that can change its state has been at the mouse pointer position. To pass the states between an activated button (the windows element) and the applications the buttons belong to, the system uses handles. Handles can brake for several reasons which depend on system settings (graphics driver, internal or external graphics adapter, memory managment in general).

This worked with the old UI. My hypothesis is that the new UI uses other windows elements than before that do not function as robust as the old ones. Mouseover the interrupt button changes the grey tone of the button and the tool tip shows that the button is activated to receive a "click". However the click does not propagete to Maple in some situations. 
The use of Java complicates the situation because it is a layer between the application (Maple) and the system. Java is supposed to make the application hardware independent. In the worst case we a facing here an issue with the Java IDE (integrated development environement) that Maplesoft cannot fix. For years, since MapleSoft uses the Eclipse IDE, there are menu items that do not work all the time (context menus not opening, e.g. convert to; plot tab on ribbon not visible when a plot is selected, context panel not updating).

@vv 

My default is Maple 2025.2 for screen readers. Unfortunatley such screen reader versions (the old UI) are not shipped anymore with Maple 2026. 
I use Maple 2026 at the moment to check code for compatibilty and to see if AI has benefits. I also want to give the improved new UI second chance. However, if it comes to productive work, I still go back to the former UI. Less clicks, better flow.

I am strongly hoping for improvements.

@acer

If I had a say, fixing that would be priority one. Does the management understand that they are selling a car without reliable brakes for more than a year (if I understand correctly). Does the pride in the product end here?

Anyway, have you turned off the start-up page (as I did)? Maybe this makes a difference. No clue where this can be turned on again.

@Carl Love

Yes, you are right. With respect to functional programming this is probably the most compact code but I did not want to go too far away from the original question of adding a given list.

I only picked the add because it is selfexplaining and it links to `+` and to `%+` . It also does not require op

dabug's question is an intersting one because it touches many Maple aspects which might be (one day) of interest for a Maple starter:

• automatic simplification
• inert functions
• prefix n-ary operator `+` vs infix binary operator +
• The non-existance of Add (which I tried straight away, realising later that such an uppercase construct would create similar output as %add if it was implemented in-line with Maple's inert conventions).
• mathematical functions, Maple functions, operators, functional operators and function names

I also tired to find out whether `+` and add point to the same Maple prodecure. I do not think so because  `+`(L) - add(L) does not simplify to zero.

By the way: Maple AI crashes when asked to explain your code

This is great. It seems that by using terse functional forms we have a way to identify whether the code was written by a human. We can still create code that is alien to machines!

I made the same observation with the example from ?CUDA.

@janhardo 
That way is similar to this way. Both ways define a local intermediate variable that permits to point from passed names to passed values.  I will see which one is better to debug when it comes to coding.
Thank you

@Carl Love 

That is tricky. Defining a local name to have something to refer to local variables created during run time. 

To complete my list of attempts:

• conversion to string -> replacement of "=" with ":=" StringTools -> parse
• local evaln(lhs~params)~:=(rhs~params)
• replacing operators `=` with `:=` 

I think I finally know now why nothing worked.

Thank you very much!

@janhardo 

Yes, but the variable needs to be declared (or has to be named) explicitly.

The " local localSequence; clause" (see ?procedure) does not accept the following

foo2:=
proc(param)
   local lhs(param):=rhs(param);
end proc
Error, `(` unexpected
foo2(a=1);

meaning that it is not possible to declare something undefined on the lhs of ":=" that needs evaluation during runtime (i.e. when foo2 is invoked). An explict name has to be declared after the word "local".

@acer

What an unfortunate sequence of misinterpretations originating from a too broad interpretation of declaration functionality in ?local_scopes which let me write an unclear example. I thought it was clear that the error message of the second call to foo (including the comment and the original title) demonstrated sufficiently that global names were unintendedly assigned to values, instead of values beeing assigned to identical local names.

Many Maple library procedures process expressions with names and leave names (at the level of the procedure call) unassigned (e.g. global names). They must do it differently from what I had in mind. It’s embarrassing that I made all of you spend time on the idea of “passing names to a procedure that should be used as local variable names in the scope of the procedure call”. Maple does not seem to allow this. Other languages do. Perhaps variable variables or dynamic variable assignment would have described this topic better. Can the title be change to something that other users with the same idea/question can easier look-up this topic?

Not as an excuse but for your understanding, I prefer to assign on a global scope level as little names as possible to values. And: algebra first, numeric at the last possible moment where parameters are defined by equations (which are then used in subs or eval calls). Given the rich library of Maple commands, for my purposes, I hardly need to write procedures where Maple provides no solutions. Hence my naivity.

Thank you for the clarifications!

@janhardo  No, it does not make sense. The interpretation of the scope of the assign call is wrong.