This question follows on from my earlier question Can Wolfram's Player Pro Use Proprietary Packages.
That question appeared to have established that, yes, PlayerPro can use proprietary packages.
Hmmm....? I've got two problems (to start) one of which I'll describe here and the second in a separate question.
I purchased a PlayerPro license ($200 USD) for OS X to evaluate what it really can and does do. I installed it on a machine that had no other Mathematica installation. I tested its installation and functionality by running a couple of simple completely self-contained
CDFs on it without any trouble.
I then transferred copies of three files to the PlayerPro equipped machine and located them in the following directories:
/Users/username/Library/MathematicaPlayerPro/Applications.myPackage.m /Users/username/Library/MathematicaPlayerPro/Applications.myNotebook.nb /Users/username/Library/MathematicaPlayerPro/Kernel.init.m
myPackage.m holds proprietary functions.
myNotebook.nb provides a
InputFields and a
Button to execute code contained in myPackage.m. All of its code resides in an initialization cell (but that starts to get into my next question).
init.m contains the following code:
(** User Mathematica initialization file **) Get["myPackage`"]
The comparable deployment on my machine running Mathematica works perfectly.
On the PlayerPro machine, not so much.
I have shut down and restarted PlayerPro and the problem persists. I have rebooted the machine, launched PlayerPro and the problem persists.
Upon opening myNotebook.nb, I can see plainly that none of the function names from myPackage.m have run. They all remain blue. The package has not loaded automatically. As the notebook depends almost entirely on the code in the package nothing in it executes.
Neither does it appear that the initialization cell runs.
I then went into:
PlayerPro >>> Preferences >>> System >>> Edit Trusted Directories
and specifically added the:
directories, restarted, rebooted, still nothing.
Does anyone have any ideas of how to get this working?
I've actually phoned Premier Support about this. The did not have a ready answer. If I hear anything useful from them I'll post it.
Update 1: I have used
Encode to encode the package in question.
I have made the assumption that the
init.m package would not require encoding. Perhaps that assumption needs reexamination.
Update 2: Encoding
init.m has no affect.
Update 3: I created a notebook to test the following two lines of code for loading the package:
Get["myPackage`"] $Failed Get["Users/username/Library/MathematicaPlayerPro/Applications/myPackage`"] Get::noopen : Cannot open Users/username/Library/MathematicaPlayerPro/Applications/myPackage` $Failed
I have also tried:
Needs["myPackage`"] Needs::nocont : Context myPackage` was not created when Needs was evaluated. $Failed
Get::noopen : Cannot open Users/username/Library/MathematicaPlayerPro/Applications/myPackage` Needs::nocont : Context myPackage` was not created when Needs was evaluated. $Failed
Update 4: Premier Support suggested some of the same things that Albert does in his answer below (still working through all of Albert's suggestions). They did discover something peculiar with PlayerPro:
I know that the main difference between this procedure and what you may have been doing with your package is that you have your Needs/Get statement inside of the PlayerPro init.m file. I did try doing the same, and found that it did not load the package. I will check on this issue with our developers to get more information.
Update 5: Sorry for all these updates, but this now appears like a bug in (at least) PlayerPro 126.96.36.199. The init.m file whether encoded or not simply doesn't do its job, at least not in anyway similar to how it works in full blown Mathematica.
I have successfully found a workaround (but not a happy one), with the generous assistance of both answers made to this question. Still, having Wolfram provide either a fix or at least a readily available explanation of why it differs in PlayerPro from Mathematica would save a lot time and frustration.