@C_R 

How did you manage to show the JDK version column there in task manager? I can't see how to show this on my task manager;

I do not think I have any other windows application that uses JDK, at least for GUI that I know above. Matlab does not, Mathematica does not. Scientific work place does not. notepad++ that I use does not. Word does not.

It is only Maple that I know uses Java for GUI. 

This is a brand new windows 10 installation, so I think everything is up-to-date. I took the PC to best buy and they installed windows 10 fresh since my C drive died and everything is new. But I will double check again that graphics drivers are update to date or not.

@Ronan 

Displays show the right monitor as primary (the one I get shaking on) because it says "1" on it. the  left monitor says "2". Is this right? This makes the right one the primary? And when I scroll down it has the checkmark set on it. So the right monitor is the primary. I also checked by clicking "DETECT" and it is correct.  

I will try swapping them by making the left monitor primary instead as you suggested and reboot windows and see if this fixes it.  

if you google using this search 

                              "maple" "book" "dynamics systems"

gives number of links to books on dynamics systems with Maple code.

A free version of the book Dynamical Systems with Applications using Maple is here

@ecterrab 

Thanks for looking  into this. This is brand new windows 10 installation and have nothing at all in my Maple ini files. I have not touched or changed anything related to Maple .ini files.

I just tried command line, and it gives same exact error:

Now I run it (right click on image and say open in new TAB to see it magnified)

I think the Physics update I made did not go through. But I actually did another Physics:-Version(latest) after that just in case, and it told me I have latest physics.

My guess now is that it only updated the Physics version number, but the bits themselves with your fix were not installed physically on my PC.

This explains why version number is up-to-date but date is still old and the bug is still there.

I will try to check where Physics updates go to on disk and see if I can spot something. 

Btw, is there an option to force Physis to update even though it says I am using latest version? something like

           Physics:-Version(latest,force_update)

Or a way to safely remove  latest version of Physics so I can try to install it again? If it was problem with update this should fix it hopefully.

Update

I think I found the problem. As I suspected, Maple only updated the version number but not the actual Physics update !

Here is screen shot. Notice the date on the files

So I think it was just installation problem. I just need now to find how to tell Maple to reinstall again latest Physics version. When I open the file version.txt is says

package-title: Physics Updates
cloud-id: 5137472255164416
cloud-version: 1780
cloud-link: https://maple.cloud
install-date: 2024-08-06 20:17

But Physics update.mapl is still the July 25 version !

It seem Physics updates the version number first, then next it downloads the actuall updates.

If this fails for some reason we end up with an inconsistent state where version number is updated but the bits on disk are not.

These two steps (updating the version number file and updating the actualy library) should be done as one single transaction. So if one fails, then both are not updated.  

Update 2

I found why. I just did Physics:-Version(1779);  then close all Maple. Started it again. Then did Physics:-Version(latest); and got same message as before. Sorry I forgot to mention it

Now close all of Maple. Start again

You see? It says it is using V 1780. But actually it never updated it due to the above error. On disk I just looked at , it is stll showing the Maple Physics dated July 25 version. 

It did however update the version.txt file.

So the problem is because Maple Physics did not update due to the above error. 

I will try rebooting the PC and try again and see if this fixes whatever the problem is with Physics update.

I am not using firewall or anything. Normal Windows 10 installation. direct connection to internet with cable modem.

I think the Physics update should not update the version.txt file before it updates the Physics library. It should do it after that and only if updating Physics library was successful.

@Thomas Richard 

I forgot to also mention that when this happens, i.e. shufflings starts, which I noticed happens only on my right monitor, then if I move the Maple window to the left monitor, the shuffling stops and Maple go back to normal.

When I move the window back to the right monitor, the shuffling starts again !

I had these two monitors for years and Maple always worked OK on them. This only happens on Maple 2024.1.

I just checked, they both have same resolution and same refresh rate. I have not touched or changed anything of this. They both 36 in wide monitors. 

If the problem with the graphics adaptor, then I would see this in other applications, right? But it is only Maple which does this. But restarting Maple fixes it for few hrs until it happens again.

@vv 

I also did not know about these two examples you show. But they fall into the same question I have here.  Which is:

Why limit says there is no limit on its own and needs additional post-processing to make limit work, and how is a user supposed to know this.

I have always thought that if limit returned unevaluated then limit do not exist.   Now I find the limit can exist but one needs to do additional calls to find out.

I always thought that if Limit fails, then limit do not exist. Period. Now I find limit can exist but need to simplify or some conversion and so on. 

So my question here is asking, why limit on its own does not find the limit if it exists by trying different approaches itself?

Note that I am NOT adding assumptions in the post-processing call, which can provide more information to limit to make it give different result.

I am simply calling simplify on the result. This made limit evaluate. Simplify provides no more information to limit than it had.

So now I have to call simplify or expand or convert and may be 10 other post-processing calls each time after calling limit just to see if limit actually exist or not.

This for me is wrong design of limit. 

@vv 

Because this is separate and different question.  

This is asking why one needs to use simplify to make limit work and evaluate.

The other question asked why Limit did not work.

I find it hard to see how you think these are the same question. Just because the question is using same example, does not mean they are asking same thing.

At stackexchange this how things works. When one has a follow up and new question on a subject they asked (limit in this case), they are asked to open new question. No one there likes one to update their question and ask something more once the question is asked.

@ecterrab 

Thanks. But for some reason, I still get division by zero on my end. 

Download divide_by_zero_maple_V2_2024_1_august_6_2024.mw

I am on windows 10. I think you mentioned once that you use Mac, right? Could this make a difference? 

I closed Maple and opened twice, same result.  btw, I do not know why Physics:-Version() says that it was created on July 25,2024. Should not the date of V1780 be today August 6,2024? May be the update did not actually go through but only the version changed? I do not know.

I updated using the same way I always do, Physics:-Version(latest);  then closed all of Maple.

@Mariusz Iwaniuk 

Thanks., Easier workaround I found is to just call simplify on the original result which still had limit stuck in it. This causes limit to now evaluate. Strange behavior. Asked separate question on this.

@C_R 

Would you know by any chance a setting in Maple to make it work like the old way? This should be something that Maple can control. I mean cursor do not just jump to random location on its own. Somewhere in the Maple GUI code base should be setting or a way to control this. Unless this is Java own problem which Maple uses.

@Scot Gould 

smart plot in 2024.1 produces empty plot and also the worksheet is completely frozen after that. i.e. not able to issue any command. No response to anything I type afterwords. This is windows 10.

Download frozen_worksheet_after_smartplot.mw

@C_R 

"When exactly do you get this message? "

It happened this time when I opened a new worksheet and typed in command and hit evaluate.

I did not change any kernel options in this worksheet or do anything else. Since it is new worksheet, and I have option to use new engine with each worksheet, I assume Maple was trying to connect to either existing unused mserver.exe or start and connect to new one. And this is where this delay comes from.

Ive seen this before but it is very rare, so not a big deal for me. But this time it took long enough time that I was able to take screen shot of it while it was waiting.

@ecterrab 

Thanks for the quick fix. Confirmed OK.

Will also run more tests.

@ecterrab 

while when you set typesetting = standard (which is not Maple's default), that intercept mechanism is not present. 

But why it is not present? It was in Maple 2023. This issue is new in Maple 2024. I do not want to see such large display on the screen either.

How are users supposed to know that when using typesetting=standard, then accedential large output generated will end up hanging all of Maple?

Also the reason I changed long time ago to using standard is because of this known issue in display sometimes when using extended.

Download wrong_display_when_using_extended_maple_2024.mw

@acer 

When I removed the timelimit warapper around dsolve, then 

interface(typesetting=extended):
dsolve(ode);

returned back FAST, about 5 seconds, with the display `[Length of output exceeds limit of 1000000]`

When I did

interface(typesetting=standard):
dsolve(ode);

The result returned back but now it took 5 minutes and I do not get the `[Length of output exceeds limit of 1000000]` as before but now I get the actual large output. But Maple did not hang/freeze.  

So it looks also like Length of output calculation is affected by typesetting level. THis should not be the case.  The longer time must be because GUI was working on displying the result and not because dsolve() itself. 

Here is the updated worksheet. something is wrong somewhere. I will stop using typesetting=standard for now.

Will only post link to the worksheet, since output is very large,

maple_lock_up_july_17_2024_V_3.mw