![]() 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. Finance, Statistics & Business Analysis.Wolfram Knowledgebase Curated computable knowledge powering Wolfram|Alpha. Wolfram Universal Deployment System Instant deployment across cloud, desktop, mobile, and more. (Thanks to for suggesting an improvement.Wolfram Data Framework Semantic framework for real-world data. It won't select all of them as asked for, but one can locate them, which sometimes I want to do. This creates a palette that allows you to mover a slider to select each initialization cell in turn. The Cells approach allows one to do many things with cells, even if they are not actually selected in the notebook. The cells may be pasted in another notebook. nb = EvaluationNotebook (* change as desired *)ĬopyToClipboard Select, CurrentValue &] The first solution achieves the goal mentioned in a comment: How to copy all the initialization cells. I think the Cells function makes some of these kinds of tasks simpler. Here are a couple of new V9 approaches that use Cells. ![]()
0 Comments
Leave a Reply. |