![]() I have a tutorial on organizing packages within applications that explains all this at Tutorial on Writing Mathematica Applications. They would not have to set directories or anything else. Mathematica will automatically find it and all other resources, such as style sheets or palettes or documentation that might go with it. The option InitializationCellWarning determines whether you get a dialog box confirming that you. The option InitializationCellEvaluation, set at the notebook level, determines when the initialization cells in a notebook are evaluated. To hide the contents, you close the Section (double click its cell bracket at right of window). Initialization Cell toggles the option InitializationCell between True and False on the selected cell objects. The advantage of that is that now anyone could install your package in their private Applications folder and simply use it. The classic solution is to put the initialization cell (s) into a Section (Alt+4) of their own, titled 'Initialization.' This Section goes either at the start or end of your notebook. Then the BeginPackage statement would look like the following with a binary name: BeginPackage Create a folder there for your particular subject matter. That is in your $UserBaseDirectory/Applicationsįolder. Why are you writing two packages? Why can't both routines be in the same package? It may be worthwhile to have two packages, but make certain you know how to do the simpler thing first.Īlso, Wolfram Research has provided a good place to put packages. Write actual usage messages, SyntaxInformation statements, and other statements that may go with a routine. A better approach is to develop routines within a Mathematica notebook. I think you are just trying to learn about packages, but before you start writing a package you have to have something to put into it. The BeginPackage statements should include backquotes: BeginPackageĪlso the fun1 routine is not actually defined. I've used this in the GrassmannCalculus application without any problem. The Private routines then know all the names and can use them in the private code. Various other initiations can also be done in the init.m file. Then in the init.m file that launches the application all the Public files are read first and then afterwards all the Private files are read. Essentially you break each subpackage into two files - a Public file that declares the exported names and a dummy Private section, and a second Private file with no public exported names. ![]() There is a way to divide an application into subpackages that all have the same Context and that call routines from each other, criss-cross. But also you will have to include the second argument in the BeginPackage statement that declares subsidiary packages that are needed in a tree structure - as David Reiss advises. I don't feel like reproducing all of it right here. Mikel, If you will read my tutorial you will see how to name your packages and have access to them.
0 Comments
Leave a Reply. |