Again, if everything works fine, the system should ask you for an administrator id and password then display the 'HTTP server is running on TCP port 8080' message.

If none of the above commands worked, you probably have a problem with your network configuration.Unix users: If you are not 'root', you probably have to select port 8080 for the TCP server because you are probably not allowed to bind to port 80.Win32 users: The TCP layers required by the HTTP server will not work until you install the TCP/IP networking support on your system.

Important: In your browser, you have to connect to the server using http://localhost/ (or http://localhost:8080/ if you specified port 8080 when launching the server) but not any other server name such as the real name of your computer since the access will be rejected unless your HTTP server is already fully configured (which is probably not true if you just downloaded Pliant for the first time).

In order to use the Pliant interpreter start the HTTP server as described above and connect using your favourite browser. Then select the 'The Pliant interpreter' link.

If you select debugging level 2 before pressing 'Execute' button, Pliant will track arithmetic overflow errors and many others but will start and run slower.

Please notice that Pliant does not allow the use of tabs in the source code: you must use spaces instead.

First you have to write your application under /pliant/yourname/anythingyouwantWin32 users: The path for you is \pliant\yourname\anythingyouwant

As an example, your first application can be a single file /pliant/yourname/yourapp.pli containing the following listing:

If your application source code gets long, or calls modules that are not precompiled in the PDEE, the application take a very long time to start. In this case the clear solution is to precompile it, which means creating of kind of executable that will be fast loading instead of recompiling everything each time the application is started. For most applications this will not require any changes in the source code of your application: only the command line used to start the application has to be extended.

The long set of arguments between the simple quotes are the ones that ask Pliant to precompile and store the precompiled version in /pliant/binary/http-debug0.dump file. If you use this long instruction, starting the HTTP server will be still slow the first time, since compiling must still be done once, and very fast after that since Pliant .dump files contain very few relocation instructions and tend to call few external DLLs, so they load very very fast: much faster than the long set of native operating system DLLs involved in classical applications (written in C or C++).

Please notice that the 'debug 0' option (you could also get rid of it is you plan to run at default debugging level) must be part of the precompiling instruction, and must appear before 'precompile' word due to very logical reasons:

the debugging level must be selected before compiling anything.

all the precompiling related informations must be provided in the first (at operating system level) argument: see the example below for the reason.

If you are running a Unix operating system, you could also get your application fast loaded (using precompiling feature) through creating a small executable containing the following code: does not work on some Unix systems because the length of the first line is limited (another stupid feature driven from the past).

There are the various sequences that you can use on Pliant command line:

generic n

sets the maximum number of generic functions (or methods) for a given type. (more details)

debug n

sets the debugging level (see below for more details).

verbose n

sets the verbosity level (see below for more details).

reset

Ask Pliant not to use the default precompiled environment.If you use neither reset nor restore options, then Pliant will automatically assume reset default

restore precompiled_environment_name

Restores a precompiled environment.

module module_name

Loads a Pliant module./pliant is automatically added in front of the module name you specify

backup precompiled_environment_name

Stores a precompiled environment.

precompile precompiled_environment_name

If the precompiled environment exists, then restores it, else compile the modules provided on the command line, then stores the environment for faster start on the next run.

command command

Compiles and executes the provided Pliant command

file_name

Load and execute the Pliant program in file_name
The extra arguments on the command line are available for the application and will not be parsed as Pliant arguments

Pliant has 5 debugging levels. Before executing any Pliant application, you have to choose which level of debugging you want for that particular application: the choice will depend on the stability of the application, the quantity of memory in the computer and the speed constraints on the application. These are a few guidelines:

level

usage

0

No debugging at all.Use this level only for well tested programs that never crash for your usage or if your computer is short on memory.

1

Does not perform any checkup at run time, but records debugging information at compile time, and tries to keep the stack traceable, so if the program is wrong it will crash badly but the debugger might display interesting information.Use this level for everyday usage if your computer is not short on memory.

2

Performs all checks at run time that do not require too much time (more precisely, performs all checkups that can be done in constant time).Always run at least once at this level before reporting a bug.

3

Performs all possible checks at run time: it may be extremely slow.Try to rerun at this level if the previous one did not display an helpful message about the bug you encountered.Also try to run once at this level before releasing your software.

If you use debugging level 3, then you have to also include module /pliant/install/precompile.pli in your command because Pliant is not precompiled at debugging level 3. An example

4

This level is just like running 'lint' on a C program: at run time it will behave like level 3 and at compile time the compiler will display warning messages about everything that looks suspect in your source code.So this level is only useful for testing your own program.

If you use debugging level 4 then you have to also include module /pliant/install/precompile.pli in your command because Pliant is not precompiled at debugging level 4.

If the application crashes, the local variables will also be displayed by the debugger on the processor stack content report.

2

When running at debugging level 2 or more and verbose level 2, all named actions performed by Pliant will be displayed on the last line in order to provide a minimal information in case of a bad failure.