Prev: Mathematica SIG (Washington DC Area)
Next: Sorting Filenames into HTML Coding
From: David Park on 27 Mar 2010 06:10
It's a bit difficult to understand why you are choosing to implement your
application in a non-standard manner and to put everything in non-standard
places. There are certain advantages to putting an application in the
standard place with the standard structure - chief among these being that
it just works. Having to implement many special settings that seem to be
fuzzily documented in Workbench is putting serious obstacles in your path
while you are trying to learn the basic operations.

In any case, if it is really necessary to use such a non-standard structure
WRI should give you more direct help and not just leave it to everyone to
guess.

How many packages do you have in the application and how involved is the
directory structure? Would it be that bad to flatten out the structure? It
may be possible to keep the structure in Workbench. You can right-click on
the project and choose Properties. Then choose Mathematica/Project Paths.
Then use the Source tab and the Add button. You should be able to add all of
the folders that contain package files. I haven't tried this and don't know
how it works, or if it carries through to the deployed application, or even
if "Source" refers to packages or other things.

There may also be methods to tell Mathematica where to look for your
application. But if this involves setting additional system path locations
with Options Inspector, then any users of your application will also have to
be instructed how to do this. And then actually getting them to do it will
be a bit of a chore.

Again, what is the advantage of moving the application away from
$UserBaseDirectory/Applications. In that location Mathematica will
automatically find it. It will appear on the Installed Add-Ons page, where a
user can bring up the documentation and load the package. A Mathematica
Search will automatically find the files and include them on the search
results, even if the package is not loaded. There are all kinds of nice
things, and I don't know how well they hold up once you move to special
structures and locations.

Why don't you want the documentation incorporated with the application at
the standard place? Do you mean you want to move it out of the application?
The paclet goes with the application. They will have the same name. Even if
you have multiple packages in the application, their exported symbols are
flattened out into one paclet.

If there is a persuasive argument for a non-standard structure, which I
haven't heard yet, then WRI should tell you how it can be implemented. Or
they should tell you that it can't be implemented, which would save a lot of
time.


David Park
djmpark(a)comcast.net
http://home.comcast.net/~djmpark/




From: H. Ke=DFler [mailto:kessler.hannes(a)googlemail.com]

My primary problem is that I would like to create help pages of
Mathematica packages stored in directories which are not at the top
level of my private Mathematica Applications directory. The Workbench
creates hyperlinked help pages for such packages which work inside the
Workbench but not when exported to the corresponding subdirectory of
the Mathematica Applications directory. I checked the example you
provided on your homepage (http://www.dbaileyconsultancy.co.uk/
m_documentation/m_documentation.html). But it seems that this example
also deals with help pages for a package in a directory which is on
the top level of the Mathematica Applications directory. If I am
wrong, please correct me. But I would really appreciate if you can
provide more details how to deal with packages in in deeper
subdirectories of the Mathematica Applications directory, no matter of
using the Workbench or some other approach.

Best regards,
Hannes Kessler

On 25 Mrz., 10:25, David Bailey <d...(a)removedbailey.co.uk> wrote:
> Hannes Kessler wrote:
> > However, I have all my packages (many) in a logical hierarchical
> > directory structure in the private Applications folder. It works fine
> > in Mathematica. Rearranging this package system to a plain directory
> > structure requires a lot of package context editing and a lot of time.
> > That's my problem. In addition, much of the order is lost. For this
> > reason I was hoping that it is possible to add help files to the
> > package system in its present order.
>
> Perhaps the most obvious question is, why do you want to use the
> Workbench - there may be other ways to achieve what you want to do!
>
> I too have things set up to my taste, and I don't want to change the way
> I work to suit the Workbench.
>
> David Baileyhttp://www.dbaileyconsultancy.co.uk



From: David Bailey on 28 Mar 2010 05:06
H. Ke=DFler wrote:
> My primary problem is that I would like to create help pages of
> Mathematica packages stored in directories which are not at the top
> level of my private Mathematica Applications directory. The Workbench
> creates hyperlinked help pages for such packages which work inside the
> Workbench but not when exported to the corresponding subdirectory of
> the Mathematica Applications directory. I checked the example you
> provided on your homepage (http://www.dbaileyconsultancy.co.uk/
> m_documentation/m_documentation.html). But it seems that this example
> also deals with help pages for a package in a directory which is on
> the top level of the Mathematica Applications directory. If I am
> wrong, please correct me. But I would really appreciate if you can
> provide more details how to deal with packages in in deeper
> subdirectories of the Mathematica Applications directory, no matter of
> using the Workbench or some other approach.
>
Although I only tested the procedure described on my website on a
package structured in the standard way, I think you could generalise it
to some extent to deal with a non-standard setup (for example, the
indexing procedure uses complete path names), but there is no guarantee
that Mathematica will not make some assumptions that prevent this working=
..

Clearly, the best approach would be to try the process out on a toy
package organised in the standard way, then generalise that to a toy
example of your nested structure, and only then move on to your real
problem with some confidence that it would work!

David Bailey
http://www.dbaileyconsultancy.co.uk

From: H. Keßler on 31 Mar 2010 06:25
On 28 Mrz., 11:06, David Bailey <d...(a)removedbailey.co.uk> wrote:
> H. Ke=DFler wrote:
> > My primary problem is that I would like to create help pages of
> > Mathematica packages stored in directories which are not at the top
> > level of my private Mathematica Applications directory. The Workbench
> > creates hyperlinked help pages for such packages which work inside the
> > Workbench but not when exported to the corresponding subdirectory of
> > the Mathematica Applications directory. I checked the example you
> > provided on your homepage (http://www.dbaileyconsultancy.co.uk/
> > m_documentation/m_documentation.html). But it seems that this example
> > also deals with help pages for a package in a directory which is on
> > the top level of the Mathematica Applications directory. If I am
> > wrong, please correct me. But I would really appreciate if you can
> > provide more details how to deal with packages in in deeper
> > subdirectories of the Mathematica Applications directory, no matter of
> > using the Workbench or some other approach.
>
> Although I only tested the procedure described on my website on a
> package structured in the standard way, I think you could generalise it
> to some extent to deal with a non-standard setup (for example, the
> indexing procedure uses complete path names), but there is no guarantee
> that Mathematica will not make some assumptions that prevent this working=
> .
>
> Clearly, the best approach would be to try the process out on a toy
> package organised in the standard way, then generalise that to a toy
> example of your nested structure, and only then move on to your real
> problem with some confidence that it would work!
>
> David Baileyhttp://www.dbaileyconsultancy.co.uk

I've got the workbench to deploy the package files and the
documentation to a folder 2 directory levels below $UserBaseDirectory/
Applications. The PacletInfo file gets deployed to $UserBaseDirectory/
Applications/dir1/dir2/PacletInfo.m, the guides notebooks to
$UserBaseDirectory/Applications/dir1/dir2/Documentation/English/
Guides/..., the application packages themselves to $UserBaseDirectory/
Applications/dir1/dir2/..

But Mathematica does not find the documentation. Perhaps it can find
only PacletInfo.m files in $UserBaseDirectory/Applications/dir1 and
not in deeper directory levels?

When I open a documentation notebook manually, the links in it to
other documentation notebooks dont' work. Such a link looks, for
example, as "paclet:English/ref/someReferencePage". I was not
successfull to modify the links manually.

The workbench documentation is rather unclear on the functionality of
the paclet system. Is it possible to describe in a single PacletInfo.m
file the documentation of several applications? Do you know where to
get more information?

Best regards,
Hannes Kessler

From: Albert Retey on 31 Mar 2010 07:21
Hi,

> I've got the workbench to deploy the package files and the
> documentation to a folder 2 directory levels below $UserBaseDirectory/
> Applications. The PacletInfo file gets deployed to $UserBaseDirectory/
> Applications/dir1/dir2/PacletInfo.m, the guides notebooks to
> $UserBaseDirectory/Applications/dir1/dir2/Documentation/English/
> Guides/..., the application packages themselves to $UserBaseDirectory/
> Applications/dir1/dir2/..
>
> But Mathematica does not find the documentation. Perhaps it can find
> only PacletInfo.m files in $UserBaseDirectory/Applications/dir1 and
> not in deeper directory levels?

I think that this is the problem, you might be able to get things run
with adopting certain pathes, but since everything that is beyond the
standard case is undocumented it is hard work to find out what works and
if so how.

> When I open a documentation notebook manually, the links in it to
> other documentation notebooks dont' work. Such a link looks, for
> example, as "paclet:English/ref/someReferencePage". I was not
> successfull to modify the links manually.
>
> The workbench documentation is rather unclear on the functionality of
> the paclet system. Is it possible to describe in a single PacletInfo.m
> file the documentation of several applications? Do you know where to
> get more information?

I am quite sure that all these things could in principle be possible in
one way or another: after all the mathematica documentation itself has a
deeper structure than what the workbench supports. But since nothing is
documented and the "global" PacletInfo isn't a plain text .m-file but a
binary database (PacletInfo.db) it is hardly possible to make use of
these features and everything might change in a future version. So my
conclusion is: you can either adopt your stuff to the structure that is
supported by the workbench or don't use it at all. Struggling with all
the details seems to be more work than rearranging the structure of
existing packages...

There is at least one more argument to not use a deeper directory
structure for your packages at this time: In version 7 the documentation
center lets the user uninstall a package with just a mouse click. AFAIK
this will just delete the corresponding directory and if that contains
more than one package/application, all of them will be deleted.

hth,

albert

From: David Park on 1 Apr 2010 07:01
One Application ==== One Paclet ==== One Folder directly in
$UserBaseDirectory/Applications.

PacletInfo.m should be at the top level.

The application may contain many packages and many documentation pages.

It's possible that SOME of the resources for the project, such as packages
or some ancillary documentation notebooks, perhaps for each package, could
be at deeper levels within the project. You might have to set Properties,
Project Paths. Any Guide pages should be in the standard place. But you
could make a Guide page with hand constructed links to your own set of
notebooks.

Having an application with hundreds of packages in a nested structure seems
a little dubious to me. It creates an extensive management problem.


David Park
djmpark(a)comcast.net
http://home.comcast.net/~djmpark/




From: H. Ke=DFler [mailto:kessler.hannes(a)googlemail.com]

On 28 Mrz., 11:06, David Bailey <d...(a)removedbailey.co.uk> wrote:
> H. Ke==DFler wrote:
> > My primary problem is that I would like to create help pages of
> > Mathematica packages stored in directories which are not at the top
> > level of my private Mathematica Applications directory. The Workbench
> > creates hyperlinked help pages for such packages which work inside the
> > Workbench but not when exported to the corresponding subdirectory of
> > the Mathematica Applications directory. I checked the example you
> > provided on your homepage (http://www.dbaileyconsultancy.co.uk/
> > m_documentation/m_documentation.html). But it seems that this example
> > also deals with help pages for a package in a directory which is on
> > the top level of the Mathematica Applications directory. If I am
> > wrong, please correct me. But I would really appreciate if you can
> > provide more details how to deal with packages in in deeper
> > subdirectories of the Mathematica Applications directory, no matter of
> > using the Workbench or some other approach.
>
> Although I only tested the procedure described on my website on a
> package structured in the standard way, I think you could generalise it
> to some extent to deal with a non-standard setup (for example, the
> indexing procedure uses complete path names), but there is no guarantee
> that Mathematica will not make some assumptions that prevent this working=
==
> .
>
> Clearly, the best approach would be to try the process out on a toy
> package organised in the standard way, then generalise that to a toy
> example of your nested structure, and only then move on to your real
> problem with some confidence that it would work!
>
> David Baileyhttp://www.dbaileyconsultancy.co.uk

I've got the workbench to deploy the package files and the
documentation to a folder 2 directory levels below $UserBaseDirectory/
Applications. The PacletInfo file gets deployed to $UserBaseDirectory/
Applications/dir1/dir2/PacletInfo.m, the guides notebooks to
$UserBaseDirectory/Applications/dir1/dir2/Documentation/English/
Guides/..., the application packages themselves to $UserBaseDirectory/
Applications/dir1/dir2/..

But Mathematica does not find the documentation. Perhaps it can find
only PacletInfo.m files in $UserBaseDirectory/Applications/dir1 and
not in deeper directory levels?

When I open a documentation notebook manually, the links in it to
other documentation notebooks dont' work. Such a link looks, for
example, as "paclet:English/ref/someReferencePage". I was not
successfull to modify the links manually.

The workbench documentation is rather unclear on the functionality of
the paclet system. Is it possible to describe in a single PacletInfo.m
file the documentation of several applications? Do you know where to
get more information?

Best regards,
Hannes Kessler


First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Mathematica SIG (Washington DC Area)
Next: Sorting Filenames into HTML Coding