# Problem with PlayerPro recognizing a proprietary package

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 Grid of 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: .../MathematicaPlayerPro/Applications .../MathematicaPlayerPro/Kernel 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"]

$Failed  I have also tried: Needs["myPackage"] Needs::nocont : Context myPackage was not created when Needs was evaluated.$Failed


Needs["myPackage,"Users/username/Library/MathematicaPlayerPro/Applications/myPackage"]

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 9.0.1.0. 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. - have you used Encode to encode your package files? PlayerPro can only load encoded package files... – Albert Retey Mar 28 '13 at 0:08 @AlbertRetey -- I was just planning to update my question to state that yes, all along I have used Encode on the package in question. – Jagra Mar 28 '13 at 0:17 you'll definitely need to also encode init.m, actually you need to encode every file ending in .m if it needs to be read by PlayerPro... – Albert Retey Mar 28 '13 at 0:22 I just have seen that you're not using init.m in the Kernel subdirectory of the package directory but in the "global" Kernel directory. I don't know whether that does work with PlayerPro. Have you tried to Get["myPackage"] directly in the notebook file? To test these things I'd recommend to first start with a very simple notebook that loads the package and e.g. shows a usage message of one of the package functions or make a simple call to one of those. Remember that you can (unlike in CDF-Player) do shift-return evaluations in PlayerPro... – Albert Retey Mar 28 '13 at 0:27 @AlbertRetey -- Will do, then I'll report back. Thx – Jagra Mar 28 '13 at 0:41 ## 2 Answers The general requirements for a package file to be loaded in PlayerPro are listed in this answer which I think you already know about. My suspection is that your problems are in some detail in your package that might or might not have to do with the fact you are running this in PlayerPro. As usual you should start with something very simple and then add things step by step until your real problem works or you can exactly tell which step led to a problem, otherwise there is just too many small details that can go wrong. I see some potential problems with your calls to Get and Needs, especially you can't mix full path names and context names as in Get["Users/username/Library/MathematicaPlayerPro/Applications/myPackage"]  But the return value of Get["myPackage"]  and the message of Needs["myPackage"]  indicate that you rather have a problem in the content of your package file, maybe some piece of code that doesn't work on PlayerPro as expected. Here is my suggestion for finding out what actually goes wrong: # Load Trivial Example: Get with Full Path start with something very simple. Create a text file with this content: BeginPackage["test"] testfun::usage="testfun does nothing"; EndPackage[];  naming it, e.g. "C:\\Users\\albert.retey\\Desktop\\test.txt" (of course adopt the path name to something valid on your computer). Then evaluate the following in Mathematica: Encode[ "C:\\Users\\albert.retey\\Desktop\\test.txt", "C:\\Users\\albert.retey\\Desktop\\test.m"]  This should create an encoded package, check that it exists and contains something like: (*!1N!*)mcm j<hTJue'P+lKh]7t>X#r/N5>m^c0Q )K,<@X>.5bPbTY_m,n@1#W5cPbTYS)Q6i.XXJ.p1 2!rF:tH|qLWBuAUa'  Now create a new notebook with the following content: Get["C:\\Users\\albert.retey\\Desktop\\test.m"] ?testfun  Evaluating this should show the usage message of testfun as defined in the package. Once that works in Mathematica, open the same notebook with PlayerPro and see whether that works there, too. If you are running PlayerPro on another machine than Mathematica, then don't forget to change the path to the correct value on the target machine before saving the the notebook. # Load Trivial Example: Needs with adjusted$Path

For Needs to work, the package file must create the correct Context, that means the name of the package file and the context given in BeginPackage need to agree, otherwise you'll get the Needs::nocont message. Here is how you can test whether that works for your encoded package file: Create a notebook with this content and save it in the same directory as your encoded package file:

Quit[]
AppendTo[$Path, NotebookDirectory[]]; Needs["test"]  Evaluating this should now work both in Mathematica and PlayerPro. # Load Trivial Package from $UserAddOnsDirectory

For the final deployment, you usually want to put the package file in one of those directories that Mathematica or PlayerPro search for packages instead of tweaking $Path. Basically you can copy your file to any directory listed in $Path, but by convention you should either use the Applications subdirectory of either $UserAddOnsDirectory (for installation for single user) or $AddOnsDirectory (for system wide installation).

To do so, copy the encoded package file into the "Applications" subdirectory of e.g.$UserAddOnsDirectory directory. Doing so, we can load it without giving the full path name of the package file and just use the context name of the package in either Get or Needs. Make sure you use the exact outcome of what $UserAddOnsDirectory gives you evaluated in PlayerPro on the target machine. For me $UserAddOnsDirectory is: "C:\\Users\\albert.retey\\AppData\\Roaming\\MathematicaPlayerPro" and the path to the package file then needs to be: "C:\\Users\\albert.retey\\AppData\\Roaming\\MathematicaPlayerPro\\Applications\\test.m". To test this, create another notebook with the following content: Quit[]; Get["test"] ?testfun  And evaluate it in PlayerPro. Again, you should now see the given usage message. If this doesn't work, make sure the file can be found, e.g. with: FileNames["test.m",$Path]


Again, you need to create a notebook with this content in Mathematica, open that with PlayerPro and evaluate it in PlayerPro. This will also show whether there are more than the expected instances of the test.m file in your \$Path, loading a different package than what you think is also a very common source of errors.

Final note: I tested this with PlayerPro 8.0.4, I can hardly imagine that these things have changed for version 9 of PlayerPro that came out a few days ago, but if the above doesn't work and you are actually using version 9 of PlayerPro, you might want to add that information.

-
As I mentioned in a comment to another answer, after going through all of your suggestions, the init.m file whether encoded or not simply doesn't do its job. Note: I use PlayerPro 9.0.1.0. I'll amend my original question to warn others. Does such an init.m package work for you in an earlier version? One can work around this certainly, but I'd like to understand why it doesn't work. Waiting to hear from Wolfram ;-( –  Jagra Mar 28 '13 at 15:35
@Jagra: From your comment to the other answer I understand that you have now everything running except for the "auto-load" via the "global" Kernel/init.m. Is that correct? I played a little with init.m and also the Autoload directory and it looks like both don't work with PlayerPro. I'll add that to my answer to your other question. At the moment I don't know any possibility to auto-load packages in PlayerPro on Kernel startup -- for a PlayerPro app with a GUI you can use the Initialization option of Manipulate or DynamicModule to load a package during initialization of the GUI. –  Albert Retey Mar 28 '13 at 20:12
Yes, got everything running except the init.m stuff. I hope to hear something back from Premier Support on this. They have escalated the issue to the development group. I'll report back if i get anything. And many thanks for the thoughtful and thought provoking answer. –  Jagra Mar 28 '13 at 20:18
@Jagra: I'd appreciate if you report on the result about the init.m. OTOH I have a feeling that it is not just an incident or bug that both these autoload features don't work, but rather is on purpose for unclear reasons... –  Albert Retey Mar 28 '13 at 20:29

Try placing your encoded package files at the base of your applications directory without the init.m file present.