Skip to main content
deleted 31 characters in body
Source Link
rm -rf
  • 89.3k
  • 21
  • 297
  • 479

One useful approach might be to use Wolfram Workbench, if you have access to it. Whether you use Workbench or not, a good way to organise your application is to have an overarching package that calls the subsidiary packages. For example, in the large project I am developing at the moment, there is a package for general utilities (data massaging), a package for the main plotting functions (highly customised version of the usual ones), and a package that provides a more general version of one of the plotting functions (DateListBarChart). The general package calls the first two of these, and the general as well as the second package call the third. The general package could be as simple as the following. In fact, this is the main package for my application, with the acronym for my employer changed to XYZ.

(* Mathematica Package *)
(* Created by the Wolfram Workbench May 20, 2010 *)
BeginPackage["XYZ`" ,{"XYZ`DateListBarChart`","XYZ`XYZGraphs`","XYZ`XYZUtilities`"}]
 (* Exported symbols added here with SymbolName::usage *) 
Begin["`Private`"]
 (* Implementation of the package *)
End[]
EndPackage[]

The way one organises these (for deployment) is, on Mac OS X at least, to put them in /Users/username/Library/Mathematica/Applications/. Inside this would be a folder for your main application name (e.g. XYZ), containing the main package, XYZ.m and any subsidary packages. Documentation and Kernel are subfolders of this folder.

You might find some useful tips in Wolfram's white paper on large projects, available from this page.

EDIT - False Alarm

One useful approach might be to use Wolfram Workbench, if you have access to it. Whether you use Workbench or not, a good way to organise your application is to have an overarching package that calls the subsidiary packages. For example, in the large project I am developing at the moment, there is a package for general utilities (data massaging), a package for the main plotting functions (highly customised version of the usual ones), and a package that provides a more general version of one of the plotting functions (DateListBarChart). The general package calls the first two of these, and the general as well as the second package call the third. The general package could be as simple as the following. In fact, this is the main package for my application, with the acronym for my employer changed to XYZ.

(* Mathematica Package *)
(* Created by the Wolfram Workbench May 20, 2010 *)
BeginPackage["XYZ`" ,{"XYZ`DateListBarChart`","XYZ`XYZGraphs`","XYZ`XYZUtilities`"}]
 (* Exported symbols added here with SymbolName::usage *) 
Begin["`Private`"]
 (* Implementation of the package *)
End[]
EndPackage[]

The way one organises these (for deployment) is, on Mac OS X at least, to put them in /Users/username/Library/Mathematica/Applications/. Inside this would be a folder for your main application name (e.g. XYZ), containing the main package, XYZ.m and any subsidary packages. Documentation and Kernel are subfolders of this folder.

You might find some useful tips in Wolfram's white paper on large projects, available from this page.

EDIT - False Alarm

One useful approach might be to use Wolfram Workbench, if you have access to it. Whether you use Workbench or not, a good way to organise your application is to have an overarching package that calls the subsidiary packages. For example, in the large project I am developing at the moment, there is a package for general utilities (data massaging), a package for the main plotting functions (highly customised version of the usual ones), and a package that provides a more general version of one of the plotting functions (DateListBarChart). The general package calls the first two of these, and the general as well as the second package call the third. The general package could be as simple as the following. In fact, this is the main package for my application, with the acronym for my employer changed to XYZ.

(* Mathematica Package *)
(* Created by the Wolfram Workbench May 20, 2010 *)
BeginPackage["XYZ`" ,{"XYZ`DateListBarChart`","XYZ`XYZGraphs`","XYZ`XYZUtilities`"}]
 (* Exported symbols added here with SymbolName::usage *) 
Begin["`Private`"]
 (* Implementation of the package *)
End[]
EndPackage[]

The way one organises these (for deployment) is, on Mac OS X at least, to put them in /Users/username/Library/Mathematica/Applications/. Inside this would be a folder for your main application name (e.g. XYZ), containing the main package, XYZ.m and any subsidary packages. Documentation and Kernel are subfolders of this folder.

You might find some useful tips in Wolfram's white paper on large projects, available from this page.

Post Migrated Here from stackoverflow.com (revisions)
Source Link
Verbeia
  • 34.5k
  • 10
  • 110
  • 225

One useful approach might be to use Wolfram Workbench, if you have access to it. Whether you use Workbench or not, a good way to organise your application is to have an overarching package that calls the subsidiary packages. For example, in the large project I am developing at the moment, there is a package for general utilities (data massaging), a package for the main plotting functions (highly customised version of the usual ones), and a package that provides a more general version of one of the plotting functions (DateListBarChart). The general package calls the first two of these, and the general as well as the second package call the third. The general package could be as simple as the following. In fact, this is the main package for my application, with the acronym for my employer changed to XYZ.

(* Mathematica Package *)
(* Created by the Wolfram Workbench May 20, 2010 *)
BeginPackage["XYZ`" ,{"XYZ`DateListBarChart`","XYZ`XYZGraphs`","XYZ`XYZUtilities`"}]
 (* Exported symbols added here with SymbolName::usage *) 
Begin["`Private`"]
 (* Implementation of the package *)
End[]
EndPackage[]

The way one organises these (for deployment) is, on Mac OS X at least, to put them in /Users/username/Library/Mathematica/Applications/. Inside this would be a folder for your main application name (e.g. XYZ), containing the main package, XYZ.m and any subsidary packages. Documentation and Kernel are subfolders of this folder.

You might find some useful tips in Wolfram's white paper on large projects, available from this page.

EDIT - False Alarm