The interaction with the charon-suite plugins is completely separated from the main tuchulcha application.

The modules are invoked by an application named tuchulcha-run. This application is called as a background process by tuchulcha when updating metadata (general or dynamic) or executing a workflow.

Dialog Window

Before starting do describe the processes in detail, the common properties of the so called log dialog are discussed. This dialog widget is responsible for communication with the tuchulcha-run process.

The info line at top shows the name of the executable used as background process (useful to attach a debugger), the used log file and (on unix systems) the process ID.

The log display widget shows the output of the background process. The log output is highlighted with a simple markup, interpreting the prefixes (DD),(II),(WW),(EE) as debug, info, warning and error lines. Debug lines may be suppressed from beeing displayed in the options tool box.

It is possible to copy some content of the log view into the clipboard by selecting some rows and pressing CTRL+C. Both, plain text and highlighted html will be copied, if the editor you paste it supports it (e.g. libre office, thunderbird), it will be pasted with highlighting.

The content below the log window depends on the dialog purpose, e.g. on Updating Plugin Metadata, a summary widget is shown.

At the bottom, there is a tool box providing a search bar to find specific lines in the log output and an options tool box.

Additionally, it is possible to save the displayed log file to disk, either in plain-text format (just copy the buffered logfile to the given location) or in highlighted html format. Highlighting is done the same way as displayed in the log view. In both formats, the full log file is written, ignoring the max view buffer and ignore debug output settings described below.

In this options section it is possible to enable/disable display of debug log lines (starting with (DD)) and to set the size of the display buffer. Setting this to unlimited (0) may slow down execution and displaying when working with workflows producing large amounts of output.

At the very bottom of the dialog, there are the close/abort buttons. If the execution of the process finished, the abort button changes into a close button. Additionally, the progress bar at the left ob the buttons is hidden. In this case, it should be safe to close the dialog which also terminates the background process.

If the process is still running, it is possible to enforce termination of this process using the abort button. In this case, a terminate signal is sent to the process. If this does not work, it is terminated the hard way (using SIGKILL) after confirmation by the user.

Updating Plugin Metadata

Updating the plugin information means querying the plugin library files (.dll, .so or .dylib files depending on the system platform) and to load the information about plugin names, input/output slots, parameters and their documentation. The paths, where the plugins are located may be specified in the Options Dialog. Updating is needed when new plugins have been added/removed or the paths have been changed.

Update Plugins may be invoked from the tool bar, the menu bar or via the shortcut F5.

Update Dialog

Update Dialog Screenshot

In addition to the general log-view content, a summary table shows the status of each of the scanned module files. The first column shows the file name, the second the module name and the third one the module status.

Possible status values
status	meaning
passed	plugin usable
warnings	plugin usable but warnings occurred
no plugin	no plugin file
failed	plugin file not usable

If warnings/errors occurred, it is useful to read the corresponding log output. Clicking on a line in the summary widget automatically scrolls to the corresponding log lines.

Note: Jumping to the corresponding log line only works it that log line is actually visible. If this is not the case, enable the display of debug log lines.

Common Reasons for Errors or Warnings during Updating

Missing Dependencies

The most frequent reason that a plugin file crashes is because of missing dependencies, i.e. used shared libraries that are not where they should be.

On unix systems, this may be resolved by adjusting the library search paths, either by recompiling the failing plugin with different RPATH settings or by adjusting the LD_LIBRARY_PATH environmental variable. The non-found shared library is usually displayed in the crash message.

On Windows systems, there is a tool called Dependency Walker which is able to display which dll files could not be found. Make sure that you use the 32bit verion on 32bit plugins and the 64bit version on 64bit plugins. By copying the missing dll files in the same folder as the plugin dll, this problem may be resolved.

Version Check

If enabled in the Options Dialog, the version of charon-core that has been used to compile the plugin file is compared with the version of charon-core that is used by tuchulcha. If these versions differ, it is very likely that the plugins show strange behavior or do not work at all.

In this case it is recommended to recompile the plugin with the latest version of charon-core and use the latest version of tuchulcha as well.

Setting the version check level to "warnings only", the modules with failing version check are not discarded and may so be used even on version mismatch. Do this at your own risk.

Running Workflows

Workflow execution may be invoked from the tool bar, the menu bar or via the shortcut F3.

Execution Dialog

Execute Dialog Screenshot

During the execution of the workflow, the log widget shows the current output of the execution process. To keep track of the execution, it is useful to activate the option "scroll down on new output" from the options tool box. To search the log, while output is still generated, this option should be disabled.

The currently executed node is highlighted in the Worflow Widget.

When the execution finished, a info box shows up below the log widget. All module files stay loaded and all module instances stay in memory until the run dialog is closed. This way, e.g. display widgets stay on screen and keep responsible.