This section gives concise but essential information on ScienceSuit environment which is essential to correctly use the software.
The directory structure is shown in the following figure:
ScienceSuit: The installation directory.
apps: All apps must be in this folder.
datafiles: Contains databases for fluids, microorganisms.
The sub-directory scripthelpfiles contains context-based help files.
home: User's folder. Any files can be placed in this directory.
The sub-directory autoload must only contain script files and these files will be loaded according to startup sequence.
sys: Belongs to system and contains system files. init.lua and the sub-folder std are essential to run the system correctly. It is highly recommended not to place any scripts in this folder or not to edit any files unless you really know what you are doing.
temp: Belongs to system and the system uses this folder to create temporary folders/files. Please do not delete this folder. If for some reason any sub-directories remain, these can be deleted as long as there are no instances of ScienceSuit running and you are sure you have already saved everything you wanted (if something goes wrong, the sub-directories can be used to recover your data).
History file: The commands run via the command-line are kept in a file, namely history.shist, which is under the root directory.
Lock file: When a project is opened, the system creates a lock file (.lock) in the same directory with the same filename as the project file. The lock file is automatically deleted when the project is closed.
Log file: When ScienceSuit starts, actions taken by system during start-up are appended to a log file called syslog.log which is under the home directory.
Settings file: The global settings are written to / read from the settings.sconfig file which is under the home directory.
When you start a new project or open an existing project, a snapshot directory is created under the temp folder with the same name of the project or as "Unsaved Project" along with the current date appended to the name of the folder. When a project is opened, the snapshot directory contains the unpacked contents of the .sproj file and when a new project is started, it is empty.
Once you commit, the committed work is written to the snapshot directory rather than directly to the project file. Saving the project is equivalent to re-packing a copy of the snapshot directory as the project file. The generated (re-packed) project file replaces the existing one as you save. The following example gives a clear picture of the process:
|User opens C:\MyProject.sproj file|
|System creates MyProject --25133209 folder under the temp directory and unpacks contents of MyProject.sproj|
|User commits some work (data is written to MyProject --25133209)|
|User clicks save|
|System packs the contents of MyProject --25133209
Creates MyProject.sproj under the temp directory
Replaces C:\MyProject.sproj with temp\MyProject.sproj.
If replacement is successful, system deletes temp\MyProject.sproj file.
|User closes the project|
|System deletes MyProject --25133209 folder|
The sequence in the red-dashed region can be repeated many times during a run.
You might be wondering why instead of a two step process, only one single step save was not implemented. Among the several some of the advantages of implementing a commit and save mechanism is as follows:
Very simple! For example, in order to commit your work for the workbook, go to Workbook page and click the commit button as shown:
Once a commit has been made, "Unsaved Commits" message will appear at the toolbar. Right-clicking on this part of the toolbar will show the following context menu:
Clicking on the "Show Committers" menu will show the following frame:
Here, you will be able to see from which parts of the framework commits have been made. In this example, only a single commit has been made from Workbook at 19:43:00.
In order to save your commits, you can use either the save button at the home ribbon page or the save button that will appear, when there are unsaved commits, at the toolbar as shown below:
When you start ScienceSuit, the following screen will be displayed:
The screen is conceptually partitioned into three parts: i) The banner, ii) the buttons, iii) Recent Projects
The banner: Depending on the time of the day a greeting message and the version information is displayed.
The Buttons: New Project and Open Project.
Recent Projects: A list of the recent projects. Please note that, before displaying the recent projects, the system checks whether each recent project is still available in its particular location.
Until v1.8.6 only a single-instance of ScienceSuit with multiple workbooks could be run. However, as of v1.8.6 multiple instances of ScienceSuit can be run at the same time and each instance is considered as a separate project and therefore each instance runs independently.
*instance: Running ScienceSuit.exe creates an instance of ScienceSuit. In single-instance environment, when an instance is running, the second was not allowed. However, in multiple instance environment, an instance is created each time ScienceSuit.exe is run.
The following resources are shared by each instance of ScienceSuit:
These are the identifiers which you are either prohibited to use or should definitely not use as variable names.
The identifiers reserved by Lua (please see section 3.1) cannot be used as variable names. The internal Lua engine will issue an error if you do so. The reserved identifiers are (from the Lua manual):
and break do else elseif end
false for function goto if in
local nil not or repeat return then true until while
For example, in the following we attempt to use and and if as variable names:
[string " and=3"]:1: unexpected symbol near 'and'
[string " if=2"]:1: unexpected symbol near 'if'
It is clearly seen that, Lua will issue an error should we attempt to use reserved words as variable names.
The identifiers used by ScienceSuit system, should not be used as variable names. These are:
A) Library names and constants: std iup SYSTEM
B) Class (data structure) names: Array, Database, Food, Matrix, Vector...
--Now we are assigning a value to std
>>std="Assigning a string value"
--calling std.sum again
[string "return std.sum(t)"]:1: attempt to call a nil value (field 'sum')
Please note that, unlike Lua's reserved names, assigning a value to std is accepted by Lua as expected. However, assigning a value to std has overridden the std library and as of this point std library is not available anymore. Therefore, calling std.sum caused an error.
Considering the reserved words by Lua (1) and ScienceSuit (2), a simple guideline when declaring variables is:
The following sequence is followed to initiliaze an instance of ScienceSuit: