MaplePrimes - answers and comments on Question, Bug in CodeTools:-EncodeName / DecodeName?

named modules

acer — Fri, 10 Feb 2012 13:26:40 Z

Could you try making your module a named module ? (There seemed to be a hint, in the debugger, at the juncture where it went wrong.)

restart:
with(CodeTools):

M := module m() option package; export f; f := proc() end proc; end module;

         module m () export f; option package; end module

EncodeName(M:-f);

_Inert_ASSIGNEDLOCALNAME("f", "PROC", 0, _Inert_ATTRIBUTE(

  _Inert_EXPSEQ(_Inert_EQUATION(_Inert_NAME("modulename"), 

  _Inert_ASSIGNEDNAME("m", "MODULE", _Inert_ATTRIBUTE(_Inert_NAME(

  "protected", _Inert_ATTRIBUTE(_Inert_NAME("protected")))))), 

  _Inert_NAME("protected", 

  _Inert_ATTRIBUTE(_Inert_NAME("protected"))))))

DecodeName(%);

                              m:-f

I'll have to test, but I wonder whether it would also be ok if the module was being read in from a .mla archive.

acer

archived

acer — Fri, 10 Feb 2012 13:34:45 Z

It also works if the module is being read in from an archive (as suspected).

restart:
with(CodeTools):
M := module() option package; export f; f := proc() end proc; end module:
EncodeName(M:-f):

DecodeName(%);
Error, (in CodeTools:-DecodeName) invalid subscript selector

LibraryTools:-Create("c:/temp/moddy.mla",WRITE);
libname:="c:/temp/moddy.mla",libname:
savelib(M);


restart:
with(CodeTools):
libname:="c:/temp/moddy.mla",libname:

EncodeName(M:-f);
_Inert_ASSIGNEDLOCALNAME("f", "PROC", 0, _Inert_ATTRIBUTE(

  _Inert_EXPSEQ(_Inert_NAME("protected", 

  _Inert_ATTRIBUTE(_Inert_NAME("protected"))), _Inert_EQUATION(

  _Inert_NAME("modulename"), _Inert_ASSIGNEDNAME("M", "MODULE"))))

  )

DecodeName(%);
                              M:-f

And now I read the help page for CodeTools:-Profiling and see that it is mentioned there,

        Due to difficulties in resolving names, it is not possible to profile the member
        functions of a module that is not saved in a repository.  To avoid this, simply
        create a repository using march, set savelibname, and then use savelib to save the
        module.  By adding the new repository to libname, the module is available to use
        and profile.

I now wonder whether creating named modules (in the first place) is another viable workaround to the issue (and if so, obviating the general need to savelib and restart in order to profile module members).

acer

Thanks, it works!

IanLisle — Fri, 10 Feb 2012 17:48:35 Z

Thanks for the pointers. I hadn't spotted that caveat in the Profiling help page, as the exception was being raised in other places like CodeTools:-Profiling:-Coverage:-Print, CodeTools:-DecodeName and the like. I've tried the named module suggestion, and it looks like it's going to work, without the nuisance of putting the module into a repository.

It could be that the two workarounds you suggested are related. The help page for module,named says: "Every module that is saved to a repository is given a name (that under which it was saved) for use by the persistent store." So perhaps the reason why packages in the repository work is that they are named?

In fact we had a third workaround, along the following lines...

m := module() option package; export f; f := proc() end proc; end module;
fcopy := op(m:-f);
[now work with fcopy for profiling purposes]

But named module is cleaner. Thanks again for your help, we now have something we can work with.

Ian.

you're welcome

acer — Fri, 10 Feb 2012 18:35:12 Z

@IanLisle I'm glad that you have a solution.

Yes, I knew of the savelib action's giving a name to the module, which is what made me suspect that one of the approaches might be as adequate as the other.

I will submit a Software Change Request, so that (if this is all true, that both work) the help-pages might indicate creation of a named module as a simpler approach.