@Alejandro Jakubi It's a bad regression bug.

It ought not to have happened, as there should be automated unit testing to cover such basic behaviour.

@Alejandro Jakubi It's a bad regression bug.

It ought not to have happened, as there should be automated unit testing to cover such basic behaviour.

As I suggested would be the case, the hard bit was getting the strings escaped correctly.

In a cygwin terminal window running in Windows 7 64bit Pro

  "C:/Program Files/Maple 15/bin.X86_64_WINDOWS/maplew.exe" -c 'read \"\"bar.mpl\"\"'

The above made the Standard GUI read and execute the multiple lines of plaintext Maple source file "bar.mpl".

But while experimenting, I managed to get Standard to do what it's supposed to do, ie. to actually read and inline the source file contents as commands.

  "C:/Program Files/Maple 15/bin.X86_64_WINDOWS/maplew.exe" \"bar.mpl\"

That was entered as a shell command, typed just a seen above. It would just hang, if the argument following the command were just "bar.mpl" instead. With Maple 14, it works with just "bar.mpl". I also tried in a DOS command window, and got similar results for Maple 15 (ie. success with the escaped form, and an orphaned process with the usual form).

Does this not mean that the '-c read...' is not even needed? The usual mechanism can be used, as long as the filename argument is wrapped in \" instead of " alone?

As I suggested would be the case, the hard bit was getting the strings escaped correctly.

In a cygwin terminal window running in Windows 7 64bit Pro

  "C:/Program Files/Maple 15/bin.X86_64_WINDOWS/maplew.exe" -c 'read \"\"bar.mpl\"\"'

The above made the Standard GUI read and execute the multiple lines of plaintext Maple source file "bar.mpl".

But while experimenting, I managed to get Standard to do what it's supposed to do, ie. to actually read and inline the source file contents as commands.

  "C:/Program Files/Maple 15/bin.X86_64_WINDOWS/maplew.exe" \"bar.mpl\"

That was entered as a shell command, typed just a seen above. It would just hang, if the argument following the command were just "bar.mpl" instead. With Maple 14, it works with just "bar.mpl". I also tried in a DOS command window, and got similar results for Maple 15 (ie. success with the escaped form, and an orphaned process with the usual form).

Does this not mean that the '-c read...' is not even needed? The usual mechanism can be used, as long as the filename argument is wrapped in \" instead of " alone?

@craigda I'd suggest trying workarounds in the following order.

T := x -> add( x^k,k=0..5):

T(0),T(3);
                             1, 364

T := proc(x) local X; eval(sum( X^k,k=0..5),X=x): end proc:

T(0),T(3);
                             1, 364

T := x -> eval(sum( ''x''^k,k=0..5)):

T(0),T(3);
                             1, 364

The uneval quotes apporach looks the shakiest. If none of these works for your larger problem, then do consider uploading it here in a worksheet.

@craigda I'd suggest trying workarounds in the following order.

T := x -> add( x^k,k=0..5):

T(0),T(3);
                             1, 364

T := proc(x) local X; eval(sum( X^k,k=0..5),X=x): end proc:

T(0),T(3);
                             1, 364

T := x -> eval(sum( ''x''^k,k=0..5)):

T(0),T(3);
                             1, 364

The uneval quotes apporach looks the shakiest. If none of these works for your larger problem, then do consider uploading it here in a worksheet.

Just because it's Friday.

> twostep:=proc(assignee, expr::uneval)
>   local res;
>   res := eval(expr);
>   print(convert(StringTools:-SubstituteAll(
>           sprintf("%a := %a", assignee, expr = 
>           subsindets(expr,And(name,
>                               satisfies(t->type(eval(t),constant))),
>           z->convert(eval(z),name))),"`",""),name)
>          = res );
>   assign(assignee, res);
>   NULL;
> end proc:

> a:=1:
> b:=3:
> c:=5:

> twostep(h,a+b*c);
                    h := a+b*c = 1+3*5 = 16

> h;
                               16

Just because it's Friday.

> twostep:=proc(assignee, expr::uneval)
>   local res;
>   res := eval(expr);
>   print(convert(StringTools:-SubstituteAll(
>           sprintf("%a := %a", assignee, expr = 
>           subsindets(expr,And(name,
>                               satisfies(t->type(eval(t),constant))),
>           z->convert(eval(z),name))),"`",""),name)
>          = res );
>   assign(assignee, res);
>   NULL;
> end proc:

> a:=1:
> b:=3:
> c:=5:

> twostep(h,a+b*c);
                    h := a+b*c = 1+3*5 = 16

> h;
                               16

@PatrickT What I had in mind was reading the .mpl file, in a script.

Now, all the effort will be in getting the quoting and the escaped quoting just right.

Without being especially correct with regard to quotes, as barebones the idea is:

c:\\somefulldospath\\maplew.exe -c 'read "c:/someplace/somefile.mpl"'

That could be a line in the script, that launches Maple 15 (otherwise broken for this task) and reads the .mpl file as input. Of course, the (possibly escaped0 quoting would have to be careful. And you'd want to use %1 or whatever is the equivalent syntax for your scripting language, as a placeholder instead of somefile.mpl above.

@PatrickT What I had in mind was reading the .mpl file, in a script.

Now, all the effort will be in getting the quoting and the escaped quoting just right.

Without being especially correct with regard to quotes, as barebones the idea is:

c:\\somefulldospath\\maplew.exe -c 'read "c:/someplace/somefile.mpl"'

That could be a line in the script, that launches Maple 15 (otherwise broken for this task) and reads the .mpl file as input. Of course, the (possibly escaped0 quoting would have to be careful. And you'd want to use %1 or whatever is the equivalent syntax for your scripting language, as a placeholder instead of somefile.mpl above.

As long as you don't have much in the way of embedded components, code or startup regions, etc, then the Standard GUI's main menu's "Export As" choice might suffice. It allows for 1D plaintext export as .mpl (where you only have to change the filename extension, in the pop up filemanager, when specifying a name for the output file).

Another workaround for that Maple 15 specific bug (with regard to failing to load a .mpl source file when given as an argument from the command shell) could be to supply the -c option, with the command being a call to read. The drawback of this approach is that the file contents are not echoed in the GUI. Maybe that's a good thing, for some people!?

As long as you don't have much in the way of embedded components, code or startup regions, etc, then the Standard GUI's main menu's "Export As" choice might suffice. It allows for 1D plaintext export as .mpl (where you only have to change the filename extension, in the pop up filemanager, when specifying a name for the output file).

Another workaround for that Maple 15 specific bug (with regard to failing to load a .mpl source file when given as an argument from the command shell) could be to supply the -c option, with the command being a call to read. The drawback of this approach is that the file contents are not echoed in the GUI. Maybe that's a good thing, for some people!?

Could you please upload your two worksheets which contain the differing behaviour, and state explicitly what detail is wrong.

See the green up-arrow, when editing here, for uploading.

In 1D Maple Notation, it could be accomplished by

zip(`*`, [R[DC[total-sek]]], [R[AC[total-sek]]]);

As 2D Math input, it could be done by

The entries of table R indexed by DC[total-sek] and AC[total-sek] are both expression sequences. And wrapping them in [..] brackets makes lists of those sequences, which can then be used as arguments to the zip command.

In 1D Maple Notation, it could be accomplished by

zip(`*`, [R[DC[total-sek]]], [R[AC[total-sek]]]);

As 2D Math input, it could be done by

The entries of table R indexed by DC[total-sek] and AC[total-sek] are both expression sequences. And wrapping them in [..] brackets makes lists of those sequences, which can then be used as arguments to the zip command.