MuPAD - Dynamic Modules [1]

Help Pages

Andreas Sorgatz (andi@uni-paderborn.de) - 01. Dec. 1996

The following MuPAD functions defines the basic mechanism to access dynamic modules. As a user interface the library package module is available.
[loadmod] -- [unloadmod] -- [external] -- [Appendix]

Funktion:

loadmod --- Loads a module

Call:

loadmod( string )

Arguments:

string -- Character string

Summary:

Analog to function loadlib, loadmod loads the module string. By this a module domain that contains an "info" string and all public module functions is created. If the identifier string was defined before, it is assigned a new value and a warning is printed out. loadmod is a kernel function. It returns the new created module domain.

If string is not a statically linked pseudo module, the module file string.mdm is searched for in the paths given by the MuPAD environment variable READ_PATH, after that in the current working directory and at last in the default MuPAD module directory. If the module string cannot be loaded the current evaluation is aborted and an error message is printed out.

If a file string.mdg is found, it contains so-called generic objects that are loaded and bound at the function environment of the module functions. If an error occures while loading these objects, a warning is printed out and MuPAD retries to load them on every call of the corresponding module function. On a call of loadmod the machine code is only loaded if was not loaded before, if it was preempted by the module manager or if it was explicity unloaded by the user. The module domain will be recreated on every call of loadmod. For this, also the file string.mdg is reloaded and the generic objects are rebound to the module functions.

Example:

>> loadmod("stdmod");

               stdmod

See also:

export, external, info, unloadmod, READ_PATH

Function:

unloadmod --- Unloads a module

Call:

unloadmod( string )
unloadmod( )

Arguments:

string -- Character string

Summary:

unloadmod removes the module string from the main memory. If no argument is given, the module manager tries to unload of modules. All identifiers defined and assigned by the functions loadmod or external remains unchanged are are still valid objects. unloadmod is a kernel function. It returns the element of the type DOM_NULL. Bei Aufruf einer Modulfunktion "uber die obengenannten Bezeichner wird der entsprechende Modulkode vom MuPAD module manager automatisch wieder in den Arbeitsspeicher geladen. Dabei werden, im Gegensatz zur Funktion loadmod, jedoch keine globalen Bezeichner definiert. Tritt beim Ausladen ein Systemfehler auf, so bricht unloadmod die laufende Berechnung mit einer Fehlermeldung ab. Ein Fehlerabbruch erfolgt ebenfalls, wenn versucht wird, ein als statisch definiertes Modul auszuladen.

Example:

>> loadmod("stdmod"):  unloadmod():  stdmod::date();

                "Fri Jun 17 13:06:54 1994"

See also:

external, loadmod

Function:

external --- Creates a module function environment

Aufruf:

external( fstring, mstring )

Arguments:

fstring -- Character string
mstring -- Character string

Summary:

external liefert die Funktionsumgebung (DOM_FUNC_ENV) zur Modulfunktion fstring des Moduls mstring. Die benannte Modulfunktion kann hier"uber ausgef"uhrt werden, ohne da"s das Modul dazu vom Anwender explizit geladen werden mu"s. Der \mupad-Modulmanager lädt den Modulkode im Bedarfsfall stets automatisch, wobei im Gegensatz zur Funktion loadmod keine globalen Bezeichner definiert werden. loadmod ist eine Funktion des Systemkerns. Wenn zu dem Modul die Datei mstring.mdg existiert, so enthält sie MuPAD Objekte, die nun geladen und an die Funktionsumgebung gebunden werden. Tritt beim Laden dieser Objekte ein Fehler auf, so erfolgt eine Warnung, und MuPAD versucht bei jedem Aufruf dieser Modulfunktion, die Objekte erneut zu laden.

Example:

>> modfunc:= external("date","stdmod")();  modfunc();

                           date

                "Fri Jun 17 13:55:18 1994"

See also:

loadmod, unloadmod, READ_PATH

Appendix


Author: Andreas Sorgatz (andi@uni-paderborn.de)
Last update: 02. Dec. 1996