 |
 |
 |
|
| Home | Documentation | Writing Weblications ... Contact |
|
To install a weblication, just run sash-install on it. Calling sash-in stall with the -f flag forces the installation, overwriting any previous installations and automatically installing all dependencies (this also avoids the clicking through the installation pop-up windows).
Every time you change your weblication, it needs to be reinstalled. In stalling the weblication involves copying its source files to some location in your .sash directory (this is all transparent to the weblication installer/user), and the runtime runs using these files.
Because Sash is a new technology (which may contain bugs), debugging w eblications may be a little tricky. Bugs may exist in a weblication, in an extension or location, and/or in the runtime. If, however, something isn't working the way that you expect it to don't immediately assume that there is something wrong with Sash.
The easiest way to debug a weblication is with 'printsys' statements. They print something out to the console, so you can monitor the progress of your weblication by printing out statements before and after certain functions have been called. For example:
printsys ("value of x: " + x);
If you're sure that it isn't your weblication's fault, then you have s everal options. If you're not interesting in poking around the Sash source code, please notify the SashXB team of the bug. Send your weblication files and directions on how to reproduce the bug. We would greatly appreciate it if you trimmed down your weblication so that it is as simple as possible. The more specific your description, the easier it will be for us to fix the bug.
If you're feeling brave, take a look at the source code. In general, t he runtime is quite stable, so the first place you should look is at the extensions that you're using. Most of the basic extensions (like core, registry, and filesystem) have been tested a great deal, and are less error-prone than some of the newer extensions (like FTP and Sockets).
Much of the Sash source code contains debug messages. You'll see lines
that say:
DEBUGMSG (something, "Here's a message\n");
This means that the message won't be printed out unless you've set the environment variable 'something' (do this by running 'export D_something=1' from the console). Perhaps if you turn on debug messages for a particular extension you'll figure out what the problem is. You can also add your own debug (or print) statements that will help you to track down your specific bug.
If you enjoy working with GDB, you're in luck. Run sash-gdb on sash-ru ntime, then call 'run' with the name of the WDF file. This is particularly good for tracking down segmentation faults.
Back