@vv 

OK. So how to make it give the shorter output first time it is called/used? do I need to clear something before calling it? I used infolevel=2 to get the shorter output. The program can't call dsolve twice each time in order to make sure it gets the smaller infolevel output. That will be too inefficient.

@acer 

Thanks but I still get that extra line Typesetting:-mprintslash in my ouput using your updated version.

It is no problem. Since the output now are on each line separated OK by CR, I can read the file back and delete out the lines that has  Typesetting:-mprintslash in them.

This looks like a bug to me but may be specific to windows.

@acer 

I tried your code. I see the newlines are now inserted OK in the file which is good. But there is still that duplicate entry of the solution in the file which does not show in the worksheet.  Here is screen shot of the textfile output_of_dsolve.txt after I open it in a text editor

I typed exactly the code you show without any changes and without any typesetting changes. 

@dharr 

On my system (maple 2021.2 windows 10) setting interface(typesetting=standard): shows 

   `Typesetting:-mprintslash([sol := y(x) = -cos(x)+_C1], [y(x) = -cos(x)+_C1])

in the text file. So there is still something else that needs to be set to get rid of this Typesetting:-mprintslash ?

Do you know when the new version of Maple will be released? 

I hope not before Maple finally fixes its timelimit() command so that it terminates as expected and not hang (or take much longer than expected)

@acer 

I do not understand what you mean by " how you need to use it." . Use what?

I set kernelopts('assertlevel'=2): before to help catch any errors in my application (for example wrong return value type and so on) so that Maple catch these.

Without this setting some errors in my application might go unoticed.

@acer 

 "But I need to use kernelopts('assertlevel'=2): in my program" doesn't explain how you need to use it.

I mean I set  kernelopts('assertlevel'=2) before I call my main function which starts the application. I do this in the worksheet itself, before I make the call. The code of the application is in a library mla.

@Joe Riel 

Thanks. But may be your parser could be more useful if it accepts instead the following

  _("3*y''(x)+2*y'(x)+y(x)")

Also there seems to be a small bug

z := _("3*y''+2*y'+y=0",t);

Gives

I do not understand though why Maple can not parse 2D input from file. It can do it if one types it in inside the document mode? So the code must be there to do it.

It just need to now read the same input from file? 

May be Maple in the future can have new file extension (.mpx ?) or new switch used to tell it the input is 2D math from plain text file so that it does not confuse the current parser that reads standard .mpl files having to decide each time about the math.

Using strings to write code inside it is probably not something I would want to do.  I'll wait for some future version to see if Maple will support it directly.  But thanks for the input code. It is useful to learn from.

@vv 

But this approach does not really work in practice. I have 10's of thousands of ode's with different dependent variables not just y. They could be z(t)  or w(t) and so on. It does not make sense to define such functions for each letter..

It would be better if Maple would read 2D directly from input files.

@vv 

Thanks for the workaround, but I prefer not to use eval for defining/setting initial/boundary conditions. It can cause problems. According to an experienced Maple programmer:

"The only form of derivative for initial and boundary conditions containing derivatives that's consistently supported by the documentation is D. If some component accepts another form, that's merely grace (to use Preben's word) or a bonus (to use Vv's word). So it's only at the highest level of evaluation---inside the mind of the programmer---that they could be considered equal."

From  what is the difference between D(y)(0)=C1 and eval(diff(y(t),t),t=0)=C1;

@Joe Riel 

Yes, I did try it. But it did not "work". By this I mean, the debugger did not STOP at the line where the exception was caused. WHich is what I assume should have happened. Here is a MWE

restart;

A:=module()
  local B:=module()
     export foo:=proc()
        print("in A:-B:-foo()");
     end proc;
 end module;
end module;

C:=module()
  export foo:=proc()
    local n:=1;
    DEBUG();
    #this now will cause an exception since A module above does not export B
    #when I stop here in debugger, then typed 
    #     stoperror(traperror["module"]);
    #but it did not actually stop on this line (or line after) when 
    #hitting the NEXT button. Is it supposed to have stopped here?
    A:-B:-foo(); 
    n:=n+1;
 end proc;
end module;

And now in the worksheet I typed

          C:-foo();

now the debugger came up. Then I typed in the debugger

         stoperror(traperror["module"]);

The clicked on the NEXT button in the debugger.   All what I got is end of the sessions and back to the worksheet

        C:-foo();
        Error, (in foo) module does not export `B`

If I understand what you meant, is that the debugger is supposed to STOP at the call where this exception happend so I can where it happend. right? if so, this is not what happens.

So this did not tell me really which line the problem was at.

Maple 2021.2 on windows.

@Joe Riel 

Thanks. But I do not know what the cause of the exception before it happened. The example I posted was just an exampleof 1/0.

The exception could be generated for many other reasons. In the case I am looking at , it is 

             Error, module does not export `%1`, name_of_module_here

I just did (in the debugger) 

stoperror("all")

also to try. This did not work. I ended up insid the top level catch: clause as before which only tells me the message. Same when I tried stoperror all

I want to know the exact location where this exception was generated.

I tried your suggestion of 

stoperror(traperror);

in the debugegr before I hit continue, but this now stops at many places in the Maple own code which I am not interested in and had to keep jumping over that.

So is there no way, from the catch: location, to print the stack showing where the exception was generated?  

As I said, I can find the location by stepping in the debugger, until I hit it, but this takes time. But I just found it and fixed it. Took 10 minutes to step line by line until I found the error in the name.

It would be nice if Maple had a way to view exceptions like with Ada   https://www.adacore.com/gems/gem-142-exceptions    but may be this is asking too much from a dynamic CAS langauge :)  

There are more example of printing exception stack trace at https://stackoverflow.com/questions/6822968/print-the-stack-trace-of-an-exception

you must have something wrong in your set up somewhere. It works OK for me on Maple 2021.

I can't imagine it would make a difference for int if you use lower case letter or upper case letter in any Maple version. 
 

There is slight difference in how the terms are written in second case due to typographical letter ordering sorting but they are mathematically the same. 

Download int_ok.mw

It will also help if you explain what do you mean when you say Wrong Integral  i.e. why it is wrong, and where it is wrong. 

@Joe Riel 

Thanks Joe. I am really looking forward for using your emacs interface once you have it updated. I spend a lot of time in the debugger and a better interface will make debugging much easier.

I use Maple on windows not linux but emacs can be used on windows also.

@Preben Alsholm 

OK, fair enough., Adding NULL fixed the error. But I still do not understand why.  Since in the map, the output of the proc f() is not used at all. 

           map(Z->f(Z),r);

so each time f() is called, the return list (which happened to be current value of L) is discarded by map. its current value remain the global variable L. Return value from f() is not used inside map.

So who is adding different length lists?  And where is that happing? map() itself has no idea that L is being used in first place. it just calls f().