@acer 

yes! thanks for this workaround. This saves me lots of time having to scan over messages that A is not declared. Since I use  this all over the place. All my objects I use are defined in the top module and all child modules use A:- to access them. As I said in comment below, it is only when using A:- inside Object(....) does mint issue this message. Using A:- everywhere else, this message do not show up.

Now the message 

These names were used as global names but were not declared:  A

no longer shows. This way I can only see real cases where the name is really not declared.

Good workaround. I will have to test it in my real code. I assume it will still work as before ofcourse. I see no reason why it will not. 

For any future reader. I found that any where, where A:- is used as argument to function, or as argument to if this problem shows in mint. For example

Object(A:-....)
timelimit(A:-time_limit_value,.....)
if A:-flag_set then ....
etc...

When using A:- not inside argument or not as argument to if then mint do not give the message. For example, this does not issue any message   local o::A:-some_name;  or normal use as in A:-foo()

So I just replaced the above  by

Object('A':-....)
timelimit('A':-time_limit_value,.....)
if 'A':-flag_set then ....
etc...

And all these mint message as gone. This make it much easier to now see real issues with using name not declared using mint.

I do not know why mint does this, as it clearly should see that the name A is declared above. But this workaround is easy to do, so issue closed for me.

Here is a MWE showing the problem again using if

A:=module()
    export my_flag::truefalse:=false;

    export B := module()    
       export foo := proc()
            if A:-my_flag then 
                print("flag is on");
            else
                print("flag is off");
            fi;       
       end proc;

    end module;
end module;

Calling mint on the above gives

Nested Procedure foo() on lines 5 to 11
 These names were used as global names but were not declared:  A

Changing A:- to 'A':- the mint message is gone. mint needs to be improved.

Thanks to all the help from everyone.

@Carl Love 

My point is that mint should see that "A" is declared. It is after all the name of the module which B module is inside.

The whole point of mint is to alert the user about issues. I search for "These names were used as global names" to look for variables I forgot to declare. I keep seeing these false ones, which makes finding real ones hard since the output of mint is very long and I waste lost of time skipping over these message to find ones with real problem. i.e. using a name not actually declared, such as a name inside a proc I forgot to declare local.

                     it is up to you to decide whether A has been used appropriately. 

Ok, so you are saying a user has to go over 1,000's of these messages and keep saying, yes, this variable is declared, yes, this variable is declared, ,yes, this variable is declared, ,yes, this variable is declared, ...   and so on.   What is then the point of using mint in this case.

I would expect Maple, which is supposed to be more strongly typed system to see that A is declared in this example.

Note also this hapens ONLY when using Object(A:-the_name);  If I remove this, then mint does not issue such a message at all, even though I am using A:- everywhere else.

A:=module()

    export module foo_type()
       option object;
       export name::string:="";
    end module;

    export B := module()    
       export step := proc()::A:-foo_type;                 
       local o::A:-foo_type;   
          1;
       end proc;

    end module;
end module;

And now mint command gives

>/home/me/maple2025/bin.X86_64_LINUX/mint A.mpl
    |\^/|      Maple 2025 Diagnostic Program
._|\|   |/|_.  Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2025
 \  MINT   /   All rights reserved. Maple is a trademark of
 <____ ____>   Waterloo Maple Inc.
      |        
Nested Procedure step() on lines 10 to 16
  These local variables were never used:  o::A:-foo_type
Module A() on lines 1 to 19
  These exported variables were never used:  foo_type
>

You see, the message 

These names were used as global names but were not declared:  A

No longer shows even though I am still using A:- in the B module. This makes no sense.

And why is Maplemint not showing this same message? I do not use maplemint, just showed it here to show the difference.

@aroche 

Thanks for the fix and the new SupprtTools.

But when I tested it on Linux Maple 2025, I still get two of the cases that fail with internal exception (not timeout, but other internal Maple exceptions).

These are #10708 and #6764, that you show as they timedout ok on your worksheet. But for me, these do not timeout but instead generate different exceptions.

Would you know why I am not getting timeout but exception instead and you are getting timeout ok?

Could being on Linux makes difference? I do have Physics updated package installed and it is on the libname path just in case this makes any difference.

Please see worksheet below.

Download collection_of_problems_maple_2025_v2.mw

@aroche 

Thanks. PackageTools:-Install(4797495082876928); worked !

But on a side note, please please folks at Maplesoft, do not use SPACES in folder names. This is very bad pratice.

spaces in folder names causes many known problems. WHat is wrong with using 

    Maple_Customer_Support_Updates 

?

Just google why spaces are bad in folder and file names

And what-technical-reasons-exist-for-not-using-space-characters-in-file-names

I can't believe a large commerical software company that has been around for almost 50 years does not know this yet.

But thanks for the correction in command. I will test the new one.

I am on Linux using Maple 2025. When I did

PackageTools:-Install(5137472255164416);

It gives error 

Is this expected? I thought to check before trying again with the overwrite=true. Is the above because I have Physics update installed?

Physics:-Version()

The "Physics Updates" version in the MapleCloud is 1861 and is 

   the same as the version installed in this computer, created 

   2025, April 10, 15:58 hours Pacific Time.

If this error is expected first time, you might want to mention this in your post also so others are aware they can see it.

Update:

I did PackageTools:-Install(5137472255164416,overwrite=true); then closed all of Maple and restarted it, but when I type SupportTools:-Version() in new worksheet, it says

                 Error, `SupportTools` does not evaluate to a module

And ?SupportTools does not bring up anything.

Does this mean it was not installed? I am using Maple 2025 on Linux. 

Should I try the command PackageTools:-Install(5137472255164416,overwrite=true); again?

update

I tried the command above again, but it keeps saying Error, `SupportTools` does not evaluate to a module
Here is worksheet

Download support_tools_install_april_22_2025.mw

ps. I just noticed the number you show to use, is same as PhysicsUpdates number given in this post The-2025-Maplesoft-Physics-Updates-And-Its-Future

But this installs the Physics Updates, which I already have installed in Maple 2025.  So I am confused now. Why then does your post say

"In Maple 2025.0, the SupportTools package is not installed by default. For the first installation, you can also run the command
PackageTools:-Install(5137472255164416); instead of installing it from the Maple Cloud."

While the post about Physics update says

"On that note, the first release of the Physics Updates for Maple 2025—focused solely on the Physics package—went out today as version 1854. To install it, the first time open Maple 2025 and use the Maplecloud toolbar -> Packages, or else input PackageTools:-Install(5137472255164416). "

Is SupportTools same as PhysicsUpdate now?

fyi, what is symplify  command? There is no such command in Maple 2025. I assume these are all typos in your plain text input and you meant to write simplify.

what should the result of simplification be? (just to be clear). This is what another software gives

Is this what you are expecting from Maple also?

@Alfred_F 

Thanks.  Could you share the other initial condition that gave solution? I'd like to add that also to my test suite for Abel ode's.

@aroche 

Thanks for looking into it. You must be using internal development version, as Maple 2025 only finds the first solution y=x^(2/3) using Lie symmetry.

Fyi, the division by zero also shows up using Chini. I noticed looking at the trace, when asking for only the general solution, Maple used Chini and not Abel.

But then when asking it to explicitly use Chini with the IC now added, it also gives divison by zero also. Looks like same issue. 

Download dsolve_division_by_zero_chini_april_17_2025.mw

@mmcdara 

I prefer Maple to concentrate only on symbolics. That is what it is best at. For numerics, there are many others and also better options.  

But Maple seems these days to want to be the jack of all trades and master of none.

By trying to chase all that is fashionable today, It will end up losing market share in all areas.

There are still many things Maple does not do in symbolics or can do better. Also its debugger is hard to use and have not been updated for decades.

I can make a list of 100 things Maple can do better in symbolics or missing features in symbolics. One quick one is symbolic series solution to ode using asymptotic expansion when expansion point is irregular singular point.

No need to waste time on numerical solvers which no one will use because other software is better at it.

It is much much harder to be good at symbolic computation than numerics. That is why there are really only two major CAS software out there. For numerical software, there are 100's.

So concentrate on what you are good at and make it better.

Ok, enough rambling. 

I have not seen this myself. I use worksheet and not document mode. And use Maple 1D for input. Do not know if this makes difference.

But this is definitly looks like some kind of java swing unicode characters rendering issue. The Maple front end uses Java. May be 2D math for input makes it show more also.

I spend 90% of my time using notepad++ to write Maple code, in plain text .mpl files, and use worksheets just to run tests and try things and for using the debugger, so may be this is why I did not see this.

It is good idea to report it to Maplesoft even though you can not make example to reproduce it.

I use worksheet mode myself, and tried your input. Closed and opened the worksheet. I see no difference. Output is in 2D and input is Maple 1D as I have it setup.

This screen shot shows the worksheet after closing it and reopening it: This is on linux, not windows.

@Alfred_F 

When I asked google AI on this, it said

"No, a Frobenius series does not necessarily have to converge uniformly. While Frobenius series can converge pointwise, they may not converge uniformly in all cases."

But without using the limit, how else will one find the constants of integration? Are you saying the series must be assumed to have  uniform convergence to use the limit as above?  Can't just plugin in x=0, as that gives division by zero.

I assume Maple also used the limit internally to solve for C2 in this example and give the answer it did. How else could it have found the solution it did otherwise? 

@Alfred_F 

This is how I solved it, which I assume same how Maple does it internally. The solution with no IC is 

ode:=x*diff(y(x),x$2)+y(x)=0;
Order:=4;
sol_with_no_IC:=dsolve(ode,y(x),'series');

Lets write the above as   y=c1*y1 + c2*y2

At x=0 the above becomes

          1 = c1*limit(y1,x=0) + c2* limit(y2,x=0)

Asking Maple for limits above, it says limit(y1,x=0)=0 and  limit(y2,x=0)=1. Hence we have

          1 = c2

general series solution now becomes

            y=c1*y1 + y2

And this is what Maple gives.

Download maple_sol_april_13_2025.mw

@Alfred_F 

Maple's solution is correct. I solved this by hand and get same exact solution as Maple using same IC ofcourse.

The problem is not that the solution being correct or not. It is why odetest fail to verify it.

Since Maple generated this solution, it seems strange that Maple is saying it is unable to compute series to verify the solution !