@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

@Carl Love 

Thanks. I also do not like aliases at all and never ever use them in Maple or any other language that allows them. They cause more problems than they solve. 

I changed all my code now to go back to old _C1 style. I added this one line at the top my my worksheet

dsolve(diff(y(x),x)=0,arbitraryconstants = traditional);

As the very first thing, and now things are working OK.

If I knew c__1 was an alias, I would have done this long time ago.  I overlooked this in help. I thought these were a brand new symbols that completely replace the old _C1 ones 

My fault for not knowing this difference more clearly. 

To show the kind of problems I was having when using subscripted, here is one example. In this, I have my own solution that I wrote, using subscripted symbols as the constant of integration.

When telling dsolve to use subscripted, odetest hangs. When telling dsolve to use traditional, odetest does not hang.

May you can see why. I can't. I asked Maple support to explain this, but never heard back from them.

If you can see why the second case hangs, it will be useful to know.

But since now I am back to using traditional for everything, this problem is gone. I am posting this example as a reference to kind of problems I started to see when I switched to subscripted.

Download test_timeout_sheet.mw

@C_R 

btw, your Maple build is is 1828976  but I am using Maple 2024.1 and it says build id is 1835466 which is different from what you show.

So you are using different Maple?. I thought you are using Maple 2024.1?  So that is why it does not hang for you but it does for me.

If you have Maple 2024.1 build id 1835466 then you can try that and see. 

@Axel Vogt 

FYI,

I did the same on Maple 2024.1 as you did. Saved it to MWS. But when I do print(e) Maple still hanged.

windows 10.

@C_R 

Which OS are you using, windows or mac or Linux?

For me, print(e) hangs Maple each time. I do not get the [Length of output....] message at all. As you see, it is set in options. I have not changed this.

Maple 2024.1 on windows 10.

I do not know why it hangs for me and not you for print(e). Are you saying it could be graphics card issue/setting?? That is very strange. Why would graphics card setting cause Maple frontend to hang?

As for the timelimit(), yes, this hangs all the time. I have to change my code now to check for length of expressio before calling expand. But timelimit should not hang.