expecco Wiki (Version 25.x) - Benutzerbeiträge [de]

DiagramElements-FreezeValue/en

2026-06-09T02:29:40Z

Cg: /* Any */

== Introduction ==

A so called "''Freeze Value''" is a constant value attached to an input pin.
When executed, that value will be presented to the action. Pins with such a constant input are referred to as "''frozen pins''" in expecco.

The freeze value can be either specified as a literal (textual) constant, or be provided by a variable (from an environment which is visible at the time the step is active).

Be aware, that frozen pin values should normally not be consumed;
i.e. in case the step is executed twice,
the value should still be present for the second incarnation. This is especially important if a step is executed in a loop or triggered by a step which writes multiple values to an output.

Thus, the diagram editor will automatically change the pin's behavior to non-triggering and non-consuming (i.e. make it a "''parameter pin''").
 You can also change the pin's behavior via its context menu ("''Make Parameter Pin''") or with the keyboard shortcut <kbd>CTRL-p</kbd>.

The following describes the data format and syntax used for pin freeze values (which btw. is also used for environment variables).
In general, the text entered as freeze value is parsed by the input pin's datatype, or if it is provided by a variable, that variable's data type.

== Format for Particular Types ==

=== Integer ===
Integer constants can be entered in one of the following formats:

* decimal (for example: "<code>1234</code>" , "<code>-1234</code>)
* with Smalltalk radix prefix: (for example: "<code>16rCAFE</code>" , "<code>16r-AA</code>, "<code>8r100</code>, "<code>2r101010000</code>).
::Any radix between 2 and 36 is allowed.
* with C radix prefix: (for example: "<code>0xCAFE</code>" , "<code>-0xAA</code>, "<code>0b101010000</code>) ("0x" for hex, "0o" for octal and "0b" for binary).
::Notice that the C-octal notation (prefix 0) is not supported (ie. "<code>0377</code>" will be read as 377).

=== Float ===

By default, floats are represented as double-precision IEEE limited precision rationals (64 bit).
You can force single precision floats by using the 'f' exponent indicator (or an 'f' suffix).

* double precision (64bit) floats such as: "<code>123.0</code>", "<code>+123.0</code>", "<code>-123.0</code>", "<code>.123</code>", "<code>123.</code>", "<code>123.0e+2</code>", "<code>123.0e-2</code>"

* single precision (32 bit): "<code>123.0f+2</code>" or "<code>-123.0f</code>"

* extended precision (80+ bit): "<code>123.0q+2</code>" or "<code>-123.0q</code>"

* quadruple precision (128 bit): "<code>123.0Q+2</code>" or "<code>-123.0Q</code>"

Do not expect any speed or other advantages when using single precision floats (depends on the CPU). Actually, expect problems due to larger errors, non-stable series computations etc. Use them only if you need to emulate less precise computations.

Extended precision floats may not be supported by all CPU types (these use the underlying machine's "long double" data type, which is either an 80-bit extended IEEE or a 128-bit quadruple IEEE float (eg. on Sparc CPUs). Not all CPUs do support these and we can not guarantee that future machines will. However, currently all supported architectures do.

Notice that depending on the CPU, quadruple precision arithmetic might be performed by software and will therefore be slow (currently the case for all supported architectures)

=== String ===

If the pin's datatype is <CODE>String</code>, then no leading/trailing single quotes are needed.
 In fact, if there are quotes, these will be part of the string. However, '''quotes are needed''' if the type is not unambiguously a String type (i.e. Any or a Union type).

By default, NO C-style escape sequences are interpreted - i.e. the string is taken "as-is".
 If you want or need control or non-latin1 characters, either enable the "''C-Escapes''" toggle via the freeze-value's popup menu, or freeze it as "C-String", which is a pseudo datatype offered in the freeze as menu.

You can then use the escapes:
* "<code>\n</code>" for a newline character
* "<code>\r</code>" for a return character
* "<code>\t</code>" for a tab
* "<code>\b</code>" for a backspace
* "<code>\xXX</code>" for a single byte hex-character code
* "<code>\uXXXX</code>" for a 32bit hex-character code
* "<code>\\</code>" for the "\" character.
* "<code>\0</code>" for a null character (null byte)

By default, variables of the form "<code>$(xxx)</code>" are expanded from either an expecco variable or the shell environment. Thus,
* "<code>$(HOME)/foo/bar</code>" will expand to the name of a subdirectory "foo/bar" under your home directory (in unix). Or if you have a variable named "HOME" in the expecco environment, to whatever that value is.
This behavior can be disabled via the freeze value's popup menu.

In addition, variables of the form "<code>%(xxx)</code>" are expanded by the value of the input pin named "xxx". This expansion is also controlled by a flag in the popup menu.

Freeze value expansion can be suppressed either at the pin (see the freeze-menu),
or globally via a flag in the project or import library. Global disabling is discouraged and only to be used for backward compatibility (in the rare situation, that an older library depends on such freeze values being unchanged).

Be reminded, that these variable expansions are only done for freeze values. If the value comes from another pin, it is passed unchanged.

=== Bytes (ByteArray) ===

Byte data can be entered in multiple forms:
* Smalltalk format: "<code>#[ 1 2 3 ]</code>" (spaces between byte values)
* JSON format: "<code>[ 1, 2, 3 ]</code>" (commas between byte values)
* C format: "<code>{ 1, 2, 3 }</code>" (braces and commas between byte values)
* hex format: "<code>xxXXxxXX</code>" (two hex characters per byte; no spaces in-between)
* hex format: "<code>xx XX xx XX</code>" (two hex characters per byte; with spaces in-between)

=== Arrays (Sequenceables) ===
given that elements el1, el2, ... elN can be represented as literal constants (i.e. Strings, numbers, bytes or arrays), a sequence of them can be
written as:
* Smalltalk format: "<code>#( el1 el2 ... elN )</code> (with spaces between elements).
* JSON format: "<code>[ el1 , el2 , ... , elN ]</code>

=== Geometric Objects (Points and Rectangles) ===
Points are entered (in Smalltalk syntax) as:
* <code>''x'' @ ''y''</code>
* <code>Point x:''x'' y:''y''</code>
where ''x&'' and ''y'' are numeric constants (typically integers).

Rectangles (in Smalltalk syntax):
* <code>(''xL'' @ ''yT'') extent:(''w'' @ ''h'')</code>
* <code>(''xL'' @ ''yT'') corner:(''xR'' @ ''yB'')</code>
* <code>Rectangle left:''xL'' top:''yT'' width:''wT'' height:''hT''</code>
* <code>Rectangle left:''xL'' top:''yT'' right:''xR'' bottom:''yB''</code>
where ''xL'' and ''y'' are the left and top coordinates, ''xR'' and ''yB'' are the coordinates of the corner (the first pixel outside the rectangle), and ''w'' and ''h'' are the extent (width and height) of the rectangle.

=== Any ===
To distinguish between strings and non-strings, String-constants for an Any-typed pin or a type which accepts both strings and non-strings (i.e. unions), a string value '''must''' be quoted.
 For example:
* <code>1234</code> - will be an integer value
* <code>1234.56</code> - will be a float value
* <code>'1234'</code> - will be a string value
in contrast, a freeze value of a string-typed pin should NOT have quotes around.

== Variable Expansion ==

Inside a freeze value, variable values can be embedded using the "$(...)" notation,
unless the freeze value has the "''No Variable Expansion'' flag set via the freeze value's popup menu).

=== $(...) Expansion ===
In addition to the visible environment variables, the following builtin names are allowed:
* <code>AttachmentsDirectory</code> - the directory, where all attachments of the suite are located.
* <code>Attachments</code> - the same, but a little shorter
* <code>ExecutionDirectory</code> - a temporary directory, which vanishes after the execution
* <code>ExpeccoInstallationDirectory</code> - the directory, where expecco was installed
* <code>ExpeccoLibraryDirectory</code> - the directory, where the libraries delivered with expecco live (first supported in 23.1)
* <code>ExpeccoPluginDirectory</code> - the directory, where expecco's plugins are installed
* <code>ProjectDirectory</code> - the temporary project directory
* <code>HomeDirectory</code> - the user's home directory
* <code>TmpDirectory</code> - a temporary directory (subfolder of the system's tmp directory)
* <code>CurrentDirectory</code> - the "current" directory (see below)
* <code>DocumentsDirectory</code> - the "documents" directory
* <code>DesktopDirectory</code> - the "desktop" directory
* <code>LoginName</code> - your login name (username under Unix/Linux/OSX)
* <code>UserName</code> - your full name (if known, otherwise the login name)

* <''inPinName''> - where inPinName is the name of an input pin of the containing compound action

If the script must run somewhere else, you can provide the path at the block's "''execDir''" input pin (or for shell scripts, you can also specify it in the editor, which is effectively defining the directory as a freeze value). The execution directory pathname (provided at the pin) may contain placeholders in the form "$(''xxx'')", where "''xxx''" is either a shell environment variable, or one of the above listed builtin placeholder variables.

== Popup Menu ==

Of special interest are the entries:

=== JSON Encoded ===
The freeze value's text is a JSON string, and the decoded object is passed to the action as pin-value. Be careful to provide correct syntax here.

 Array:
[ <element1> , <element2> , ... <elementN> ]
Object:
{ "<fieldName1>": <fieldValue1> ,
"<fieldName2>": <fieldValue2> ,
...
"<fieldNameN>": <fieldValueN>
}
Other:
true
false
null
<integer>
<float>

A future version may provide additional syntax checks in this editor.
For now, we assume that most of us will simply copy-paste a JSON string from some other place. Let us know, if that would be a high priority feature in the next version.

=== C-Style Escapes ===
The freeze value's text is a string with C-style escape sequences (see above).

=== No Variable Expansion ===
No variables are expanded inside the freeze value. Use this, to pass strings eg. to shell scripts, which require strings with embedded $(...) sequences.

KI Coding Plugin

2026-06-08T08:18:21Z

Cg: /* Was kann eine lokale KI (z.B. ollama) */

= KI Coding Plugin =

Das KI Coding Plugin bindet einen Large Language Model (LLM) basierten
KI-Assistenten in den Activity-Editor (Aktivitäten-Code), den
Compound-Netzwerk-Editor, den Dokumentations-Editor und in den
ST/X Class Browser ein. Das Plugin unterstützt zwei Anbieter, die im
Einstellungsdialog umschaltbar sind:

* '''Anthropic Claude''' (claude-opus-4-7, claude-sonnet-4-6, claude-haiku-4-5)
* '''OpenAI ChatGPT''' (gpt-4o, gpt-4o-mini, gpt-4.1, gpt-4.1-mini, gpt-4.1-nano, o1, o3)
* '''Ollama''' (codellama:7b, codellama:13b)
Je nach gewähltem Anbieter erscheint die Toolbar-Schaltfläche als
'''"Ask Claude"''' bzw. '''"Ask ChatGPT"'''; das Einstellungs-Tab
heißt '''"AI Coding"'''.

== Aktivitäten-Editor ==

Im Aktivitäten-Code-Editor erscheint in der Toolbar eine Schaltfläche
"Ask Claude" / "Ask ChatGPT" mit folgenden Aktionen:

* Open KI Window — öffnet das eigenständige Chat-Fenster
* Explain code — erklärt den Code der aktuellen Aktivität
* Suggest improvement — schlägt Verbesserungen vor
* Find bugs — sucht nach Fehlern, Race Conditions, nil-Handling-Problemen
* Generate doc-comment — generiert eine Aktivitäts-Dokumentation inklusive Pin-Kommentaren und füllt den Documentation-Tab
* Custom prompt... — freier Prompt; der Aktivitäts-Code wird als Kontext mitgesendet
* Set model ▸ — Untermenü mit den Modellen des aktiven Anbieters (das aktuell aktive ist mit ''(active)'' markiert)
* Set provider ▸ — nur sichtbar, wenn API-Schlüssel für mehr als einen Anbieter konfiguriert sind; Untermenü zum Umschalten zwischen Claude und ChatGPT

Code-Vorschläge können mit '''[Apply]''' (direkt am jeweiligen
Code-Block im Chat oder über die obere Apply-Schaltfläche) in den
Aktivitäts-Body übernommen werden. Vom KI gelieferte Smalltalk/X
Hilfsmethoden (Form: <code>Klasse >> selector</code>) werden nach
Rückfrage in die genannte Klasse compiliert.

== Compound (Netzwerk) Editor ==

Auf der Toolbar von Compound-Worksheets erscheint dieselbe
Schaltfläche, beschränkt auf die für Netze sinnvollen Aktionen
(Open KI Window, Generate doc-comment) — ebenfalls mit den
Untermenüs '''Set model''' und ggf. '''Set provider'''.

== Dokumentations-Editor ==

Der Dokumentations-Tab der Block-Description (Editor für Test-Cases,
Test-Plans und Aktivitäten) trägt dieselbe Toolbar-Schaltfläche
"Ask Claude" / "Ask ChatGPT" mit den Einträgen
'''Open KI Window''', '''Generate doc-comment''' sowie den
Untermenüs '''Set model''' und ggf. '''Set provider'''.
'''Generate doc-comment''' analysiert den aktuellen Block (Name,
vorhandene Beschreibung, Eingangs-/Ausgangs-Pins, Sub-Steps eines
Compound-Netzes, referenzierte Environment-Variablen) und schlägt
eine vollständige Block- und Pin-Dokumentation vor.

Ist der Block schreibgeschützt (importierte Library, RTL-Lizenz),
fragt '''[Apply]''' nach, ob der Block freigeschaltet und die
Dokumentation eingetragen werden soll.

== Class Browser (ST/X) ==

Im Class Browser stehen die Aktionen unter dem '''AI'''-Untermenü
sowie im Selektor-Kontextmenü zur Verfügung. Die Aktionen
operieren auf der aktuell ausgewählten Methode (Klasse + Selektor +
Quelltext werden als Kontext mitgesendet). '''[Apply]''' kann das
Resultat direkt in die Methode der aktiven Klasse einbauen.
Auch hier sind '''Set model''' und ggf. '''Set provider''' als
Untermenüs verfügbar.

== Chat-Fenster ==

Das eigenständige Chat-Fenster trägt den Titel
'''AI Coding [<Produkt> / <Modell>]''' (z.B.
"AI Coding [Claude / claude-opus-4-7]") und zeigt nach jedem Turn
den Tokenverbrauch und die kumulierten Kosten — sofern Preise für
das gewählte Modell hinterlegt sind. Anbieter- und Modellwechsel
im Einstellungsdialog werden live übernommen.

Das Transkript ist als vertikales Panel von "Karten" aufgebaut:

* '''Prosa-Karten''' enthalten den fließenden Text der Antwort; Zeilen werden auf die Fenster-Breite umgebrochen.
* '''Code-Karten''' (eingerahmt) entstehen aus markdown-Code-Blöcken (<code>```...```</code>) und sind als '''Workspace''' editierbar — das Standard-Smalltalk-Popup-Menü bietet doIt / printIt / inspectIt, ein <code>TestCase</code>-<code>simulatedSelf</code> ist gesetzt, so dass <code>self assert:... equals:...</code> direkt ausgeführt werden kann. Lange Blöcke scrollen innerhalb der Karte. Rechts oben sitzen die Schaltflächen '''[Apply]''' (sofern für den Kontext sinnvoll) und '''[⎘ Copy]'''; links wird der Sprachtag (smalltalk, python, …) angezeigt.
* '''Doku-Karten''' (volle Breite, Prosa) entstehen aus dem speziellen <code>```doc</code>-Block, den der Dokumentations-Generator anfordert; Inhalt ist die Vorschlags-Dokumentation für Block- und Pin-Beschreibungen.

Scroll-Lock: solange der Anwender bereits am unteren Ende des
Transkripts steht, folgt die Anzeige neu eintreffenden Karten
automatisch; nach manuellem Hochscrollen bleibt die Position stehen.

Bilder können als Anhang versendet werden (Screenshot oder
PNG/JPG-Datei). Anhänge funktionieren mit beiden Anbietern; bei
OpenAI nur mit vision-fähigen Modellen (gpt-4o-Familie).

== Einstellungen (AI Coding) ==

Im Einstellungsdialog unter '''Plugins → AI Coding''' (bzw. unter
'''Tools → AI Coding''' im Smalltalk-Launcher) werden konfiguriert:

* '''Provider''' — Anthropic oder OpenAI. Beim Wechsel werden API-URL und Default-Modell entsprechend angepasst; der gespeicherte API-Schlüssel des jeweiligen Anbieters wird geladen.
* '''API Key''' — Schlüssel des aktuell gewählten Anbieters. Die Schlüssel werden pro Anbieter getrennt gespeichert (<code>#claudeApiKey_anthropic</code> bzw. <code>#claudeApiKey_openai</code>), so dass zwischen den Anbietern ohne erneute Eingabe gewechselt werden kann. Das Setzen des Schlüssels erfolgt ausschließlich über diesen Dialog.
* '''Model''' — ein Modell aus der Liste des aktiven Anbieters oder ein selbst eingegebener Modellname. Kann auch direkt über das '''Set model'''-Untermenü in den Editor-Toolbars umgeschaltet werden.
* '''Max output tokens''' — maximale Antwortlänge.
* '''API URL''' — nur zu ändern für eigene Proxies / Gateways. Standard: <code>https://api.anthropic.com/v1/messages</code> bzw. <code>https://api.openai.com/v1/chat/completions</code>.

== API-Schlüssel beschaffen ==

* Anthropic: [https://console.anthropic.com console.anthropic.com], Schlüsselformat <code>sk-ant-...</code>.
* OpenAI: [https://platform.openai.com/api-keys platform.openai.com/api-keys], Schlüsselformat <code>sk-...</code> oder <code>sk-proj-...</code>. Voraussetzung ist ein aufgeladenes Konto (Mindestbetrag derzeit USD 5).

== Datenschutz / Datenfluss ==

Bei aktivem Anbieter '''Anthropic''' gehen die Anfragen direkt an
<code>api.anthropic.com</code>, bei '''OpenAI''' direkt an
<code>api.openai.com</code>. Es gibt keinen eXept-seitigen Proxy oder
Zwischenspeicher. Mit dem Aktivitäts-Quelltext bzw. den Methoden-
Quelltexten werden auch Pin-Beschreibungen, Sub-Step-Namen und
referenzierte Environment-Variablen aus dem Block-Description-Modell
als Kontext versendet.

Bei Benutzung von Anthropic API-Tokens - wie hier der Fall - werden laut Anthropic die Daten nicht zum Training des KI-Modells genutzt ([https://privacy.claude.com/de/articles/7996868-werden-meine-daten-fur-das-modelltraining-verwendet Anthropic Erkärung dazu]). Für die Wahrheit dieser Aussage könne wir nicht garantieren und haften.

Wenn Sie sicher sein wollen, daß keine Information Ihr Haus verlässt empfehlen wir eine eigenem geschlossene in-house KI Umgebung, wie sie bei einigen unserer Kunden bereits existiert. Sie dürfen dann selbstverständlich nur die URLs dieser Umgebung konfigurieren. Expecco kommuniziert ausschließlich mit der von Ihnen eingegebenen KI.

== Tipps ==

* '''Mehrere Konversationen''': der Chat ist ein Singleton — eine neue Anfrage über ein Browser-/Editor-Menü startet jedesmal eine '''neue''' Konversation. Folge-Fragen (Klärung, Vertiefung) gehen über das Eingabefeld in derselben Konversation.
* '''Vorsicht:''' Die Größe der übertragenen Daten (auch die aus dem Chatfenster) geht in die Kostenberechnung ein. Deshalb immer eine neue Konversation starten, wenn es um ein neues Thema geht.
* '''Modell wechseln''': Für schnelle Routine-Antworten Sonnet, für schwierige Refactorings Opus. Über das '''Set model'''-Untermenü direkt aus der Toolbar oder über die Settings.
* '''Anbieter wechseln''': Sind Schlüssel für beide Anbieter konfiguriert, schaltet das '''Set provider'''-Untermenü ohne Umweg über den Settings-Dialog um.
* '''Code direkt ausführen''': In Code-Karten kann markierter Smalltalk-Code per doIt / printIt / inspectIt direkt evaluiert werden — praktisch z.B. um vom Modell vorgeschlagene SUnit-Asserts gleich auszuprobieren, ohne den Code erst in einen Workspace zu kopieren.
* '''Custom prompt''' eignet sich gut für „warum macht Methode X es so und nicht so?" oder „schreib mir einen ParameterizedTest dazu mit folgenden Daten: …".

== Tipps für die Arbeit mit claudeCode ==
Wenn Sie claudeCode verwenden, stehen ihnen noch weit mehr Funktionen zur Verfügung: sie können zum Beispiel im claudeCode Terminal eingeben:
* "mach mir eine neue Suite in einem neuen Fenster",
* "Mache eine Aktion zur Berechnung des Umfangs eines Kreises bei gegebenen Radius",
* "Erstelle eine neue Suite mit einem Testfall der folgendes macht:
** 1) webbrowser auf "www.exept.de" öffnen.
** 2) auf das logo oben links klicken.
** 3) webbrowser schliessen.
* welche Funktionalität ist in xxx.ets

(Anm.: es spielt keine Rolle, ob Sie sich in Deutsch oder Englisch unterhalten)

Claude wurde von uns in die Lage versetzt, selbst nach passenden Bibliotheken zu suchen, diese zu importieren, Aktionen zu generieren und den Testplan anzulegen.

Tatsächlich auch, den Test gleich durchzuführen und das Resultat zu analysieren.

Aktuell sind wir am trainieren, so dass claude z.B. selbst entscheidet ob es besser ist, eine fehlende Aktion als Diagramm oder elementa zu definieren. Es ist in der Lage, die Funktionen des unterliegenden Frameworks zu sehen und auch komplexe Aufgaben zu erledigen:
* "Aktion zum Lesen der Jahresumsätze eines Jahres aus der Datenbank"
* extrahiere aus dem xml Dokument alle budget Einträge und liefere die Summe

=== Erfahrungen und Tipps für die Arbeit ===

Sonnet-4 ist gefühlt weit intelligenter als Heiku-4.5,
aber auch weit teurer. Ihr Budget kann sehr schnell schmelzen mit Sonnet. Insbesondere wenn man auf medium oder high Intelligenzlevel arbeitet. Aber Haiku macht auch weit mehr Fehler und man sollte genau hinschauen was er so generiert. Gefühlt war Sonnet selbst im low level besser als Haiku. Aber der Preis...

Folgende konkrete Tipps aus unseren ersten Erfahrungen, diese Liste wird aktualisiert, und kann auch basieren auf unserer eigenen Dummheit. Ist also u.U. mit Vorsicht zu genießen.

* geben Sie Haiku mehr Hinweise, z.B. "schau mal dort, oder nimm das als Beispiel". Sonnet findet selbst viel besser Lösungen.

* kurze Anweisungen, je konkreter desto günstiger.

* Haiku ist weit "fauler". Z.B hat sonnet automatisch eine Dokumentation bei neuen Aktionen angelegt, und diese auch aktualisiert. Haiku hingegen musste man explizit eine Regel dazu anlegen (z.B. mit "wenn du eine Aktion anlegst oder änderst, aktualisiere die Dokumentation")

* Heiku ist dümmer. Regeln die von Sonnet angelegt wurden, können von Haiku u.U. nicht befolgt werden, weil Sonnet weit mehr generalisieren kann.

* sagen Sie beiden sie sollten wenn sie ein Problem haben, nicht lange selbst suchen. sondern nachfragen ob man ihnen einen Tipp geben kann. Wenn Sie das nicht tun, kann es sein dass Sonnet auch eine viertel Stunde nachdenkt und die Dollars schmelzen wie Eis in der Sonne (ist mir passiert, als ein Socket Problem in der Kommunikation auftrat, und er nicht erkannte, das die Antworten von mcp falsch waren, es hat dann selbst alle möglichen Wege gesucht, eine Nachricht abzusetzen, incl. der Erstellung diverser Shell, curl und Python Scripte... obgleich es eigentlich ein Interface dafür gab, das aber einen Fehler hatte). Insbesondere hatte ich dummerweise vorher sinngemäß gesagt er solle, wenn ein Problem auftritt dies und jenes tun, wobei dabei genau dieses Problem wieder auftrat...

* schränken Sie das Modell in seinen Möglichkeiten ein, z.B. sagen sie "editiere nicht die files sondern verwende dazu ein tool", oder "eine expecco Aktion und sag mir vorher welche du nimmst". Sonst kann es passieren dass es anfängt ihre ets zu entpacken um darin nach Strings zu suchen, obgleich es das eigentlich einfacher über das interface machen kann (dieses konkrete Problem wird nicht mehr auftreten aber Sie sehen den Punkt). Da war Sonnet weit intelligenter hat aber auch länger nachgedacht.

* wenn sie feststellen, dass es einen Fehler macht, sagen sie (mehr oder weniger wörtlich) "remember: mach dies nicht, oder um das zu machen tu das."

* sie können diese Erinnerungen sowohl in ihrem UserProfile (also im lokalen Filesystem) als auch in ihren expecco Präferenzen halten. Sagen Sie dazu "remember this in in my expecco memory" oder "remember (in my user memory): bla bla". Erinnerungen kann man auch löschen "forget to ...". Zu Beginn der nächsten session sagen sie "read your expecco memory".

* wechseln sie das Modell oder den level, je nach Komplexität der Aufgabe. Aber bedenken Sie dass Wissen von Session zu Session verloren geht, wenn es nicht erinnert wird. Technisch sind Erinnerungen nichts anderes als das Lesen einer Liste der vormaligen remember Anweisungen. Kosten also auch Tokens. Sie könnten also die Erinnerunge auch einfach neu eintippen ;-)

* auch wenn es so scheint: das "Ding" ist kein Mensch; lassen sie "bitte, danke, oder Begründungen - es sei denn sie dienen der Entscheidung - weg. Tatsächlich erhöhen sie den Tokenverbrauch u.U.

Subjektive Zusammenfassung:
* Haiku ist viel schneller in der Antwort und kostet ein Zehntel. Mit Sonnet war nach 3-4 Std Arbeit mein Limit erreicht und ich durfte Stunden Pause machen. Mit Haiku kann man durcharbeiten. Aber ich brauche auch mindestens doppelt so viel Zeit um haiku anzuleiten und seine Fehler wieder auszubügeln.

== Was kann eine lokale KI (z.B. ollama) ==

Erste Versuche sind eher ernüchternd. Ohne Zugriff auf lokale Quellen 1), mit rein antrainiertem Wissen sind die Modelle vermutlich zu klein. Hier eine Konversation mit gemma3:8b-it-qat (8 Mrd, quantifiziert) auf einem Rechner ohne GPU.
Die Antwortzeiten sind natürlich schlecht, aber mit einer GPU u.U. brauchbar. Wenn Sie im Haus Zugriff auf Rechner mit GPU haben sollten Sie diese unbedingt nutzen (mit möglichst viel RAM, damit die Modelle auch hineinpassen!)

Wichtig: wir sind selbst noch Anfänger und keine [https://en.wikipedia.org/wiki/Susan_Calvin KI Psychologen].
Aber die Erfahrungen werden aktuell in einem Feintuning Prozess in die nächste Release eingebracht.

1) z.B. über mcp tools, welche wir in der aktuellen Version für claudeCode bereits implementiert haben.

=== Installation ===
install ollama
ollama pull gemma3:8b-it-qat ;; gemma3:8b / gemma3:12b usw.
ollama run gemma3:8b-it-qat

=== Sitzung 1 ===
Hinweise: Wichtig, sonst labert Sie das Modell voll!

>>> respond short and concise
Understood

Hinweise: Smalltalk/X wissen hat er nicht, aber VW und Pharo sind ähnlich genug.

>>> you are an expert in smalltalk programming, especially in Smalltalk/X, visualworks and Squeak.

You have come to the right place I have a considerable depth of knowledge regarding Smalltalk...
Angeber- wir werden sehen

>>> what does the smalltalk expression "self at:4 put:'bla' " mean

Sets the character 'b' at index 4 of `self` (assuming `self` is a string).
Falsche Antwort; Smalltalk verwendet 1-basierte Indices, und 'bla' ist ein String

>>> how to compute the area of a circle given radius

```smalltalk
| radius area |
radius := 5.0.
area := radius * radius * PI.
^area
```
nicht schlecht. PI gibt es zwar nicht als globale Variable (richtig wäre "Float pi"), aber dennoch bemerkenswert.

>>> how to extract a substring

`substring:startIndexToEndIndex` (inclusive). E.g., `"hello" substring:2 to:4` yields `"llo"`.
wieder falsch; 1-basierter index, substring:to: möglicherweise in einem anderen Smalltalk vorhanden. Könnte man durchgehen lassen.

>>> alternative?

`copyFrom:to:` (indexes inclusive). `string copyFrom:1 to:3` gives `"ell"`.
besser, aber immer noch falscher Index

>>> what is the result of 'hello' copyFrom:2 to:4

"llo"
war zu erwarten

>>> smalltalk uses 1 based indexing. what is the result

Correct. The result of `'hello' copyFrom:2 to:4` is `"llo"`.
soso. Er sieht ein, dass ich korrigiert habe - dann aber dickköpfig.

>>> in smalltalk the first index is 1 the last is the collection's size. Not as in Python or C.

Precisely. 1-based indexing is core to Smalltalk.
aha, er könnte es wissen; es fehlt ihm aber offensichtlich an Abstraktionsvermögen. Versuchen wir es mit einem Beispiel:

>>> remember: the result of 'hello' copyFrom:2 to4 is 'ell'

You are absolutely right! My apologies. `copyFrom:to:` includes both endpoints, so `'hello' copyFrom:2 to:4` results in `"ell"`. Thanks for the correction. I am still under development and learning nuances like this.
soso, eine Nuance. Und eigentlich hatte ich gesagt, er solle kurz und exact antworten. Die Entschuldigungen kann er sich sparen. Mal sehen:

>>> >> what is the result of 'abcde' copyFrom:2 to:4

"bcd"
na also; geht doch.

=== Sitzung 2 ===

Neuer Versuch; eine neue Session. Gib ihm Grundwissen, das er nicht im Modell hat.
/clear
>>> answer short an concise
Okay.

>>> you are expert in smalltalk programming, especially smalltalk/x, visualworks and pharo

Acknowledged. I'm ready to leverage my knowledge of Smalltalk (including Smalltalk/X, VisualWorks, and Pharo) to assist you. Ask away!

>>> remember: because smalltalk is 1-based indexing, the result of 'hello' copyFrom:2 to4 is 'ell'

Understood. I will keep in mind Smalltalk's 1-based indexing when answering your questions about string manipulation and other operations

>>> what is the result of 'abcde' copyFrom:2 to:4

'bcd'
richtig! 
Hätte ich hinzufügen müssen, daß das nicht nur für Strings gilt? Mal sehen:

>>> given Array #(10 20 30 40) what is the result of array at:3

30
richtig!

Man muss den Context also mit Wissen füllen (fein tuning), dann kommt durchaus sinnvolles heraus. Wir sind dran, das zu evaluieren damit möglicherweise sogar eine lokale KI (allerdings mit GPU) hilfreich unterstützen kann.

== Wahl der Modellgrösse ==

Versuche mit gemma3:270m (sehr klein; 270Mio), gemma3:1b (1 Mrd) und gemma3:4b (4 Mrd). Alle auf lokalem Rechner ohne GPU.
Versuch: Übersetzung einer Bausteindokumentation.

Eingabe: translate to German:
"show a dialog with an informationstring"

Die 270m und 1b Modelle kennen das Geschlecht nicht; sie drücken sich etwas ungeschickt aus:

"Zeigen Sie eine Dialoge mit einer Informationsstring"

Alternativen:
"Zeige einen Dialog mit einer Informationsstring."
"Zeige eine Dialoge mit einer Informationsstring."
"Zeige eine Dialoge mit einer Informationsstring."

bzw (1Mrd).
"Zeig eine Dialog mit einem Informationsstring"

Alternativen:
"Gib ein Dialog mit einem Informationen-String aus"
"Zeige einen Dialog, der eine Informations-Stränge enthält"

Das 4Mrd Modell scheint brauchbar:
"Zeige einen Dialog mit einer Informationsnachricht"

Alternativen:
"Erstelle ein Dialogfenster mit einer Informationsanzeige"
"Zeige ein Dialogfeld mit einer Informationen"

In jedem Fall darf man der KI nicht "blind" vertrauen.

[[Kategorie:Plugin]]
[[Kategorie:Erweiterung]]

KI Coding Plugin

2026-06-08T08:15:40Z

Cg: /* Was kann eine lokale KI (z.B. ollama) */

= KI Coding Plugin =

Das KI Coding Plugin bindet einen Large Language Model (LLM) basierten
KI-Assistenten in den Activity-Editor (Aktivitäten-Code), den
Compound-Netzwerk-Editor, den Dokumentations-Editor und in den
ST/X Class Browser ein. Das Plugin unterstützt zwei Anbieter, die im
Einstellungsdialog umschaltbar sind:

* '''Anthropic Claude''' (claude-opus-4-7, claude-sonnet-4-6, claude-haiku-4-5)
* '''OpenAI ChatGPT''' (gpt-4o, gpt-4o-mini, gpt-4.1, gpt-4.1-mini, gpt-4.1-nano, o1, o3)
* '''Ollama''' (codellama:7b, codellama:13b)
Je nach gewähltem Anbieter erscheint die Toolbar-Schaltfläche als
'''"Ask Claude"''' bzw. '''"Ask ChatGPT"'''; das Einstellungs-Tab
heißt '''"AI Coding"'''.

== Aktivitäten-Editor ==

Im Aktivitäten-Code-Editor erscheint in der Toolbar eine Schaltfläche
"Ask Claude" / "Ask ChatGPT" mit folgenden Aktionen:

* Open KI Window — öffnet das eigenständige Chat-Fenster
* Explain code — erklärt den Code der aktuellen Aktivität
* Suggest improvement — schlägt Verbesserungen vor
* Find bugs — sucht nach Fehlern, Race Conditions, nil-Handling-Problemen
* Generate doc-comment — generiert eine Aktivitäts-Dokumentation inklusive Pin-Kommentaren und füllt den Documentation-Tab
* Custom prompt... — freier Prompt; der Aktivitäts-Code wird als Kontext mitgesendet
* Set model ▸ — Untermenü mit den Modellen des aktiven Anbieters (das aktuell aktive ist mit ''(active)'' markiert)
* Set provider ▸ — nur sichtbar, wenn API-Schlüssel für mehr als einen Anbieter konfiguriert sind; Untermenü zum Umschalten zwischen Claude und ChatGPT

Code-Vorschläge können mit '''[Apply]''' (direkt am jeweiligen
Code-Block im Chat oder über die obere Apply-Schaltfläche) in den
Aktivitäts-Body übernommen werden. Vom KI gelieferte Smalltalk/X
Hilfsmethoden (Form: <code>Klasse >> selector</code>) werden nach
Rückfrage in die genannte Klasse compiliert.

== Compound (Netzwerk) Editor ==

Auf der Toolbar von Compound-Worksheets erscheint dieselbe
Schaltfläche, beschränkt auf die für Netze sinnvollen Aktionen
(Open KI Window, Generate doc-comment) — ebenfalls mit den
Untermenüs '''Set model''' und ggf. '''Set provider'''.

== Dokumentations-Editor ==

Der Dokumentations-Tab der Block-Description (Editor für Test-Cases,
Test-Plans und Aktivitäten) trägt dieselbe Toolbar-Schaltfläche
"Ask Claude" / "Ask ChatGPT" mit den Einträgen
'''Open KI Window''', '''Generate doc-comment''' sowie den
Untermenüs '''Set model''' und ggf. '''Set provider'''.
'''Generate doc-comment''' analysiert den aktuellen Block (Name,
vorhandene Beschreibung, Eingangs-/Ausgangs-Pins, Sub-Steps eines
Compound-Netzes, referenzierte Environment-Variablen) und schlägt
eine vollständige Block- und Pin-Dokumentation vor.

Ist der Block schreibgeschützt (importierte Library, RTL-Lizenz),
fragt '''[Apply]''' nach, ob der Block freigeschaltet und die
Dokumentation eingetragen werden soll.

== Class Browser (ST/X) ==

Im Class Browser stehen die Aktionen unter dem '''AI'''-Untermenü
sowie im Selektor-Kontextmenü zur Verfügung. Die Aktionen
operieren auf der aktuell ausgewählten Methode (Klasse + Selektor +
Quelltext werden als Kontext mitgesendet). '''[Apply]''' kann das
Resultat direkt in die Methode der aktiven Klasse einbauen.
Auch hier sind '''Set model''' und ggf. '''Set provider''' als
Untermenüs verfügbar.

== Chat-Fenster ==

Das eigenständige Chat-Fenster trägt den Titel
'''AI Coding [<Produkt> / <Modell>]''' (z.B.
"AI Coding [Claude / claude-opus-4-7]") und zeigt nach jedem Turn
den Tokenverbrauch und die kumulierten Kosten — sofern Preise für
das gewählte Modell hinterlegt sind. Anbieter- und Modellwechsel
im Einstellungsdialog werden live übernommen.

Das Transkript ist als vertikales Panel von "Karten" aufgebaut:

* '''Prosa-Karten''' enthalten den fließenden Text der Antwort; Zeilen werden auf die Fenster-Breite umgebrochen.
* '''Code-Karten''' (eingerahmt) entstehen aus markdown-Code-Blöcken (<code>```...```</code>) und sind als '''Workspace''' editierbar — das Standard-Smalltalk-Popup-Menü bietet doIt / printIt / inspectIt, ein <code>TestCase</code>-<code>simulatedSelf</code> ist gesetzt, so dass <code>self assert:... equals:...</code> direkt ausgeführt werden kann. Lange Blöcke scrollen innerhalb der Karte. Rechts oben sitzen die Schaltflächen '''[Apply]''' (sofern für den Kontext sinnvoll) und '''[⎘ Copy]'''; links wird der Sprachtag (smalltalk, python, …) angezeigt.
* '''Doku-Karten''' (volle Breite, Prosa) entstehen aus dem speziellen <code>```doc</code>-Block, den der Dokumentations-Generator anfordert; Inhalt ist die Vorschlags-Dokumentation für Block- und Pin-Beschreibungen.

Scroll-Lock: solange der Anwender bereits am unteren Ende des
Transkripts steht, folgt die Anzeige neu eintreffenden Karten
automatisch; nach manuellem Hochscrollen bleibt die Position stehen.

Bilder können als Anhang versendet werden (Screenshot oder
PNG/JPG-Datei). Anhänge funktionieren mit beiden Anbietern; bei
OpenAI nur mit vision-fähigen Modellen (gpt-4o-Familie).

== Einstellungen (AI Coding) ==

Im Einstellungsdialog unter '''Plugins → AI Coding''' (bzw. unter
'''Tools → AI Coding''' im Smalltalk-Launcher) werden konfiguriert:

* '''Provider''' — Anthropic oder OpenAI. Beim Wechsel werden API-URL und Default-Modell entsprechend angepasst; der gespeicherte API-Schlüssel des jeweiligen Anbieters wird geladen.
* '''API Key''' — Schlüssel des aktuell gewählten Anbieters. Die Schlüssel werden pro Anbieter getrennt gespeichert (<code>#claudeApiKey_anthropic</code> bzw. <code>#claudeApiKey_openai</code>), so dass zwischen den Anbietern ohne erneute Eingabe gewechselt werden kann. Das Setzen des Schlüssels erfolgt ausschließlich über diesen Dialog.
* '''Model''' — ein Modell aus der Liste des aktiven Anbieters oder ein selbst eingegebener Modellname. Kann auch direkt über das '''Set model'''-Untermenü in den Editor-Toolbars umgeschaltet werden.
* '''Max output tokens''' — maximale Antwortlänge.
* '''API URL''' — nur zu ändern für eigene Proxies / Gateways. Standard: <code>https://api.anthropic.com/v1/messages</code> bzw. <code>https://api.openai.com/v1/chat/completions</code>.

== API-Schlüssel beschaffen ==

* Anthropic: [https://console.anthropic.com console.anthropic.com], Schlüsselformat <code>sk-ant-...</code>.
* OpenAI: [https://platform.openai.com/api-keys platform.openai.com/api-keys], Schlüsselformat <code>sk-...</code> oder <code>sk-proj-...</code>. Voraussetzung ist ein aufgeladenes Konto (Mindestbetrag derzeit USD 5).

== Datenschutz / Datenfluss ==

Bei aktivem Anbieter '''Anthropic''' gehen die Anfragen direkt an
<code>api.anthropic.com</code>, bei '''OpenAI''' direkt an
<code>api.openai.com</code>. Es gibt keinen eXept-seitigen Proxy oder
Zwischenspeicher. Mit dem Aktivitäts-Quelltext bzw. den Methoden-
Quelltexten werden auch Pin-Beschreibungen, Sub-Step-Namen und
referenzierte Environment-Variablen aus dem Block-Description-Modell
als Kontext versendet.

Bei Benutzung von Anthropic API-Tokens - wie hier der Fall - werden laut Anthropic die Daten nicht zum Training des KI-Modells genutzt ([https://privacy.claude.com/de/articles/7996868-werden-meine-daten-fur-das-modelltraining-verwendet Anthropic Erkärung dazu]). Für die Wahrheit dieser Aussage könne wir nicht garantieren und haften.

Wenn Sie sicher sein wollen, daß keine Information Ihr Haus verlässt empfehlen wir eine eigenem geschlossene in-house KI Umgebung, wie sie bei einigen unserer Kunden bereits existiert. Sie dürfen dann selbstverständlich nur die URLs dieser Umgebung konfigurieren. Expecco kommuniziert ausschließlich mit der von Ihnen eingegebenen KI.

== Tipps ==

* '''Mehrere Konversationen''': der Chat ist ein Singleton — eine neue Anfrage über ein Browser-/Editor-Menü startet jedesmal eine '''neue''' Konversation. Folge-Fragen (Klärung, Vertiefung) gehen über das Eingabefeld in derselben Konversation.
* '''Vorsicht:''' Die Größe der übertragenen Daten (auch die aus dem Chatfenster) geht in die Kostenberechnung ein. Deshalb immer eine neue Konversation starten, wenn es um ein neues Thema geht.
* '''Modell wechseln''': Für schnelle Routine-Antworten Sonnet, für schwierige Refactorings Opus. Über das '''Set model'''-Untermenü direkt aus der Toolbar oder über die Settings.
* '''Anbieter wechseln''': Sind Schlüssel für beide Anbieter konfiguriert, schaltet das '''Set provider'''-Untermenü ohne Umweg über den Settings-Dialog um.
* '''Code direkt ausführen''': In Code-Karten kann markierter Smalltalk-Code per doIt / printIt / inspectIt direkt evaluiert werden — praktisch z.B. um vom Modell vorgeschlagene SUnit-Asserts gleich auszuprobieren, ohne den Code erst in einen Workspace zu kopieren.
* '''Custom prompt''' eignet sich gut für „warum macht Methode X es so und nicht so?" oder „schreib mir einen ParameterizedTest dazu mit folgenden Daten: …".

== Tipps für die Arbeit mit claudeCode ==
Wenn Sie claudeCode verwenden, stehen ihnen noch weit mehr Funktionen zur Verfügung: sie können zum Beispiel im claudeCode Terminal eingeben:
* "mach mir eine neue Suite in einem neuen Fenster",
* "Mache eine Aktion zur Berechnung des Umfangs eines Kreises bei gegebenen Radius",
* "Erstelle eine neue Suite mit einem Testfall der folgendes macht:
** 1) webbrowser auf "www.exept.de" öffnen.
** 2) auf das logo oben links klicken.
** 3) webbrowser schliessen.
* welche Funktionalität ist in xxx.ets

(Anm.: es spielt keine Rolle, ob Sie sich in Deutsch oder Englisch unterhalten)

Claude wurde von uns in die Lage versetzt, selbst nach passenden Bibliotheken zu suchen, diese zu importieren, Aktionen zu generieren und den Testplan anzulegen.

Tatsächlich auch, den Test gleich durchzuführen und das Resultat zu analysieren.

Aktuell sind wir am trainieren, so dass claude z.B. selbst entscheidet ob es besser ist, eine fehlende Aktion als Diagramm oder elementa zu definieren. Es ist in der Lage, die Funktionen des unterliegenden Frameworks zu sehen und auch komplexe Aufgaben zu erledigen:
* "Aktion zum Lesen der Jahresumsätze eines Jahres aus der Datenbank"
* extrahiere aus dem xml Dokument alle budget Einträge und liefere die Summe

=== Erfahrungen und Tipps für die Arbeit ===

Sonnet-4 ist gefühlt weit intelligenter als Heiku-4.5,
aber auch weit teurer. Ihr Budget kann sehr schnell schmelzen mit Sonnet. Insbesondere wenn man auf medium oder high Intelligenzlevel arbeitet. Aber Haiku macht auch weit mehr Fehler und man sollte genau hinschauen was er so generiert. Gefühlt war Sonnet selbst im low level besser als Haiku. Aber der Preis...

Folgende konkrete Tipps aus unseren ersten Erfahrungen, diese Liste wird aktualisiert, und kann auch basieren auf unserer eigenen Dummheit. Ist also u.U. mit Vorsicht zu genießen.

* geben Sie Haiku mehr Hinweise, z.B. "schau mal dort, oder nimm das als Beispiel". Sonnet findet selbst viel besser Lösungen.

* kurze Anweisungen, je konkreter desto günstiger.

* Haiku ist weit "fauler". Z.B hat sonnet automatisch eine Dokumentation bei neuen Aktionen angelegt, und diese auch aktualisiert. Haiku hingegen musste man explizit eine Regel dazu anlegen (z.B. mit "wenn du eine Aktion anlegst oder änderst, aktualisiere die Dokumentation")

* Heiku ist dümmer. Regeln die von Sonnet angelegt wurden, können von Haiku u.U. nicht befolgt werden, weil Sonnet weit mehr generalisieren kann.

* sagen Sie beiden sie sollten wenn sie ein Problem haben, nicht lange selbst suchen. sondern nachfragen ob man ihnen einen Tipp geben kann. Wenn Sie das nicht tun, kann es sein dass Sonnet auch eine viertel Stunde nachdenkt und die Dollars schmelzen wie Eis in der Sonne (ist mir passiert, als ein Socket Problem in der Kommunikation auftrat, und er nicht erkannte, das die Antworten von mcp falsch waren, es hat dann selbst alle möglichen Wege gesucht, eine Nachricht abzusetzen, incl. der Erstellung diverser Shell, curl und Python Scripte... obgleich es eigentlich ein Interface dafür gab, das aber einen Fehler hatte). Insbesondere hatte ich dummerweise vorher sinngemäß gesagt er solle, wenn ein Problem auftritt dies und jenes tun, wobei dabei genau dieses Problem wieder auftrat...

* schränken Sie das Modell in seinen Möglichkeiten ein, z.B. sagen sie "editiere nicht die files sondern verwende dazu ein tool", oder "eine expecco Aktion und sag mir vorher welche du nimmst". Sonst kann es passieren dass es anfängt ihre ets zu entpacken um darin nach Strings zu suchen, obgleich es das eigentlich einfacher über das interface machen kann (dieses konkrete Problem wird nicht mehr auftreten aber Sie sehen den Punkt). Da war Sonnet weit intelligenter hat aber auch länger nachgedacht.

* wenn sie feststellen, dass es einen Fehler macht, sagen sie (mehr oder weniger wörtlich) "remember: mach dies nicht, oder um das zu machen tu das."

* sie können diese Erinnerungen sowohl in ihrem UserProfile (also im lokalen Filesystem) als auch in ihren expecco Präferenzen halten. Sagen Sie dazu "remember this in in my expecco memory" oder "remember (in my user memory): bla bla". Erinnerungen kann man auch löschen "forget to ...". Zu Beginn der nächsten session sagen sie "read your expecco memory".

* wechseln sie das Modell oder den level, je nach Komplexität der Aufgabe. Aber bedenken Sie dass Wissen von Session zu Session verloren geht, wenn es nicht erinnert wird. Technisch sind Erinnerungen nichts anderes als das Lesen einer Liste der vormaligen remember Anweisungen. Kosten also auch Tokens. Sie könnten also die Erinnerunge auch einfach neu eintippen ;-)

* auch wenn es so scheint: das "Ding" ist kein Mensch; lassen sie "bitte, danke, oder Begründungen - es sei denn sie dienen der Entscheidung - weg. Tatsächlich erhöhen sie den Tokenverbrauch u.U.

Subjektive Zusammenfassung:
* Haiku ist viel schneller in der Antwort und kostet ein Zehntel. Mit Sonnet war nach 3-4 Std Arbeit mein Limit erreicht und ich durfte Stunden Pause machen. Mit Haiku kann man durcharbeiten. Aber ich brauche auch mindestens doppelt so viel Zeit um haiku anzuleiten und seine Fehler wieder auszubügeln.

== Was kann eine lokale KI (z.B. ollama) ==

Erste Versuche sind eher ernüchternd. Ohne Zugriff auf lokale Quellen, mit rein antrainiertem Wissen sind die Modelle vermutlich zu klein. Hier eine Konversation mit gemma3:8b-it-qat (8 Mrd, quantifiziert) auf einem Rechner ohne GPU.
Die Antwortzeiten sind natürlich schlecht, aber mit einer GPU u.U. brauchbar. Wenn Sie im Haus Zugriff auf Rechner mit GPU haben sollten Sie diese unbedingt nutzen (mit möglichst viel RAM, damit die Modelle auch hineinpassen!)

Wichtig: wir sind selbst noch Anfänger und keine [https://en.wikipedia.org/wiki/Susan_Calvin KI Psychologen].
Aber die Erfahrungen werden aktuell in einem Feintuning Prozess in die nächste Release eingebracht.

=== Installation ===
install ollama
ollama pull gemma3:8b-it-qat ;; gemma3:8b / gemma3:12b usw.
ollama run gemma3:8b-it-qat

=== Sitzung 1 ===
Hinweise: Wichtig, sonst labert Sie das Modell voll!

>>> respond short and concise
Understood

Hinweise: Smalltalk/X wissen hat er nicht, aber VW und Pharo sind ähnlich genug.

>>> you are an expert in smalltalk programming, especially in Smalltalk/X, visualworks and Squeak.

You have come to the right place I have a considerable depth of knowledge regarding Smalltalk...
Angeber- wir werden sehen

>>> what does the smalltalk expression "self at:4 put:'bla' " mean

Sets the character 'b' at index 4 of `self` (assuming `self` is a string).
Falsche Antwort; Smalltalk verwendet 1-basierte Indices, und 'bla' ist ein String

>>> how to compute the area of a circle given radius

```smalltalk
| radius area |
radius := 5.0.
area := radius * radius * PI.
^area
```
nicht schlecht. PI gibt es zwar nicht als globale Variable (richtig wäre "Float pi"), aber dennoch bemerkenswert.

>>> how to extract a substring

`substring:startIndexToEndIndex` (inclusive). E.g., `"hello" substring:2 to:4` yields `"llo"`.
wieder falsch; 1-basierter index, substring:to: möglicherweise in einem anderen Smalltalk vorhanden. Könnte man durchgehen lassen.

>>> alternative?

`copyFrom:to:` (indexes inclusive). `string copyFrom:1 to:3` gives `"ell"`.
besser, aber immer noch falscher Index

>>> what is the result of 'hello' copyFrom:2 to:4

"llo"
war zu erwarten

>>> smalltalk uses 1 based indexing. what is the result

Correct. The result of `'hello' copyFrom:2 to:4` is `"llo"`.
soso. Er sieht ein, dass ich korrigiert habe - dann aber dickköpfig.

>>> in smalltalk the first index is 1 the last is the collection's size. Not as in Python or C.

Precisely. 1-based indexing is core to Smalltalk.
aha, er könnte es wissen; es fehlt ihm aber offensichtlich an Abstraktionsvermögen. Versuchen wir es mit einem Beispiel:

>>> remember: the result of 'hello' copyFrom:2 to4 is 'ell'

You are absolutely right! My apologies. `copyFrom:to:` includes both endpoints, so `'hello' copyFrom:2 to:4` results in `"ell"`. Thanks for the correction. I am still under development and learning nuances like this.
soso, eine Nuance. Und eigentlich hatte ich gesagt, er solle kurz und exact antworten. Die Entschuldigungen kann er sich sparen. Mal sehen:

>>> >> what is the result of 'abcde' copyFrom:2 to:4

"bcd"
na also; geht doch.

=== Sitzung 2 ===

Neuer Versuch; eine neue Session. Gib ihm Grundwissen, das er nicht im Modell hat.
/clear
>>> answer short an concise
Okay.

>>> you are expert in smalltalk programming, especially smalltalk/x, visualworks and pharo

Acknowledged. I'm ready to leverage my knowledge of Smalltalk (including Smalltalk/X, VisualWorks, and Pharo) to assist you. Ask away!

>>> remember: because smalltalk is 1-based indexing, the result of 'hello' copyFrom:2 to4 is 'ell'

Understood. I will keep in mind Smalltalk's 1-based indexing when answering your questions about string manipulation and other operations

>>> what is the result of 'abcde' copyFrom:2 to:4

'bcd'
richtig! 
Hätte ich hinzufügen müssen, daß das nicht nur für Strings gilt? Mal sehen:

>>> given Array #(10 20 30 40) what is the result of array at:3

30
richtig!

Man muss den Context also mit Wissen füllen (fein tuning), dann kommt durchaus sinnvolles heraus. Wir sind dran, das zu evaluieren damit möglicherweise sogar eine lokale KI (allerdings mit GPU) hilfreich unterstützen kann.

== Wahl der Modellgrösse ==

Versuche mit gemma3:270m (sehr klein; 270Mio), gemma3:1b (1 Mrd) und gemma3:4b (4 Mrd). Alle auf lokalem Rechner ohne GPU.
Versuch: Übersetzung einer Bausteindokumentation.

Eingabe: translate to German:
"show a dialog with an informationstring"

Die 270m und 1b Modelle kennen das Geschlecht nicht; sie drücken sich etwas ungeschickt aus:

"Zeigen Sie eine Dialoge mit einer Informationsstring"

Alternativen:
"Zeige einen Dialog mit einer Informationsstring."
"Zeige eine Dialoge mit einer Informationsstring."
"Zeige eine Dialoge mit einer Informationsstring."

bzw (1Mrd).
"Zeig eine Dialog mit einem Informationsstring"

Alternativen:
"Gib ein Dialog mit einem Informationen-String aus"
"Zeige einen Dialog, der eine Informations-Stränge enthält"

Das 4Mrd Modell scheint brauchbar:
"Zeige einen Dialog mit einer Informationsnachricht"

Alternativen:
"Erstelle ein Dialogfenster mit einer Informationsanzeige"
"Zeige ein Dialogfeld mit einer Informationen"

In jedem Fall darf man der KI nicht "blind" vertrauen.

[[Kategorie:Plugin]]
[[Kategorie:Erweiterung]]

KI Coding Plugin

2026-06-08T08:04:40Z

Cg: /* Tipps für die Arbeit mit claudeCode */

= KI Coding Plugin =

Das KI Coding Plugin bindet einen Large Language Model (LLM) basierten
KI-Assistenten in den Activity-Editor (Aktivitäten-Code), den
Compound-Netzwerk-Editor, den Dokumentations-Editor und in den
ST/X Class Browser ein. Das Plugin unterstützt zwei Anbieter, die im
Einstellungsdialog umschaltbar sind:

* '''Anthropic Claude''' (claude-opus-4-7, claude-sonnet-4-6, claude-haiku-4-5)
* '''OpenAI ChatGPT''' (gpt-4o, gpt-4o-mini, gpt-4.1, gpt-4.1-mini, gpt-4.1-nano, o1, o3)
* '''Ollama''' (codellama:7b, codellama:13b)
Je nach gewähltem Anbieter erscheint die Toolbar-Schaltfläche als
'''"Ask Claude"''' bzw. '''"Ask ChatGPT"'''; das Einstellungs-Tab
heißt '''"AI Coding"'''.

== Aktivitäten-Editor ==

Im Aktivitäten-Code-Editor erscheint in der Toolbar eine Schaltfläche
"Ask Claude" / "Ask ChatGPT" mit folgenden Aktionen:

* Open KI Window — öffnet das eigenständige Chat-Fenster
* Explain code — erklärt den Code der aktuellen Aktivität
* Suggest improvement — schlägt Verbesserungen vor
* Find bugs — sucht nach Fehlern, Race Conditions, nil-Handling-Problemen
* Generate doc-comment — generiert eine Aktivitäts-Dokumentation inklusive Pin-Kommentaren und füllt den Documentation-Tab
* Custom prompt... — freier Prompt; der Aktivitäts-Code wird als Kontext mitgesendet
* Set model ▸ — Untermenü mit den Modellen des aktiven Anbieters (das aktuell aktive ist mit ''(active)'' markiert)
* Set provider ▸ — nur sichtbar, wenn API-Schlüssel für mehr als einen Anbieter konfiguriert sind; Untermenü zum Umschalten zwischen Claude und ChatGPT

Code-Vorschläge können mit '''[Apply]''' (direkt am jeweiligen
Code-Block im Chat oder über die obere Apply-Schaltfläche) in den
Aktivitäts-Body übernommen werden. Vom KI gelieferte Smalltalk/X
Hilfsmethoden (Form: <code>Klasse >> selector</code>) werden nach
Rückfrage in die genannte Klasse compiliert.

== Compound (Netzwerk) Editor ==

Auf der Toolbar von Compound-Worksheets erscheint dieselbe
Schaltfläche, beschränkt auf die für Netze sinnvollen Aktionen
(Open KI Window, Generate doc-comment) — ebenfalls mit den
Untermenüs '''Set model''' und ggf. '''Set provider'''.

== Dokumentations-Editor ==

Der Dokumentations-Tab der Block-Description (Editor für Test-Cases,
Test-Plans und Aktivitäten) trägt dieselbe Toolbar-Schaltfläche
"Ask Claude" / "Ask ChatGPT" mit den Einträgen
'''Open KI Window''', '''Generate doc-comment''' sowie den
Untermenüs '''Set model''' und ggf. '''Set provider'''.
'''Generate doc-comment''' analysiert den aktuellen Block (Name,
vorhandene Beschreibung, Eingangs-/Ausgangs-Pins, Sub-Steps eines
Compound-Netzes, referenzierte Environment-Variablen) und schlägt
eine vollständige Block- und Pin-Dokumentation vor.

Ist der Block schreibgeschützt (importierte Library, RTL-Lizenz),
fragt '''[Apply]''' nach, ob der Block freigeschaltet und die
Dokumentation eingetragen werden soll.

== Class Browser (ST/X) ==

Im Class Browser stehen die Aktionen unter dem '''AI'''-Untermenü
sowie im Selektor-Kontextmenü zur Verfügung. Die Aktionen
operieren auf der aktuell ausgewählten Methode (Klasse + Selektor +
Quelltext werden als Kontext mitgesendet). '''[Apply]''' kann das
Resultat direkt in die Methode der aktiven Klasse einbauen.
Auch hier sind '''Set model''' und ggf. '''Set provider''' als
Untermenüs verfügbar.

== Chat-Fenster ==

Das eigenständige Chat-Fenster trägt den Titel
'''AI Coding [<Produkt> / <Modell>]''' (z.B.
"AI Coding [Claude / claude-opus-4-7]") und zeigt nach jedem Turn
den Tokenverbrauch und die kumulierten Kosten — sofern Preise für
das gewählte Modell hinterlegt sind. Anbieter- und Modellwechsel
im Einstellungsdialog werden live übernommen.

Das Transkript ist als vertikales Panel von "Karten" aufgebaut:

* '''Prosa-Karten''' enthalten den fließenden Text der Antwort; Zeilen werden auf die Fenster-Breite umgebrochen.
* '''Code-Karten''' (eingerahmt) entstehen aus markdown-Code-Blöcken (<code>```...```</code>) und sind als '''Workspace''' editierbar — das Standard-Smalltalk-Popup-Menü bietet doIt / printIt / inspectIt, ein <code>TestCase</code>-<code>simulatedSelf</code> ist gesetzt, so dass <code>self assert:... equals:...</code> direkt ausgeführt werden kann. Lange Blöcke scrollen innerhalb der Karte. Rechts oben sitzen die Schaltflächen '''[Apply]''' (sofern für den Kontext sinnvoll) und '''[⎘ Copy]'''; links wird der Sprachtag (smalltalk, python, …) angezeigt.
* '''Doku-Karten''' (volle Breite, Prosa) entstehen aus dem speziellen <code>```doc</code>-Block, den der Dokumentations-Generator anfordert; Inhalt ist die Vorschlags-Dokumentation für Block- und Pin-Beschreibungen.

Scroll-Lock: solange der Anwender bereits am unteren Ende des
Transkripts steht, folgt die Anzeige neu eintreffenden Karten
automatisch; nach manuellem Hochscrollen bleibt die Position stehen.

Bilder können als Anhang versendet werden (Screenshot oder
PNG/JPG-Datei). Anhänge funktionieren mit beiden Anbietern; bei
OpenAI nur mit vision-fähigen Modellen (gpt-4o-Familie).

== Einstellungen (AI Coding) ==

Im Einstellungsdialog unter '''Plugins → AI Coding''' (bzw. unter
'''Tools → AI Coding''' im Smalltalk-Launcher) werden konfiguriert:

* '''Provider''' — Anthropic oder OpenAI. Beim Wechsel werden API-URL und Default-Modell entsprechend angepasst; der gespeicherte API-Schlüssel des jeweiligen Anbieters wird geladen.
* '''API Key''' — Schlüssel des aktuell gewählten Anbieters. Die Schlüssel werden pro Anbieter getrennt gespeichert (<code>#claudeApiKey_anthropic</code> bzw. <code>#claudeApiKey_openai</code>), so dass zwischen den Anbietern ohne erneute Eingabe gewechselt werden kann. Das Setzen des Schlüssels erfolgt ausschließlich über diesen Dialog.
* '''Model''' — ein Modell aus der Liste des aktiven Anbieters oder ein selbst eingegebener Modellname. Kann auch direkt über das '''Set model'''-Untermenü in den Editor-Toolbars umgeschaltet werden.
* '''Max output tokens''' — maximale Antwortlänge.
* '''API URL''' — nur zu ändern für eigene Proxies / Gateways. Standard: <code>https://api.anthropic.com/v1/messages</code> bzw. <code>https://api.openai.com/v1/chat/completions</code>.

== API-Schlüssel beschaffen ==

* Anthropic: [https://console.anthropic.com console.anthropic.com], Schlüsselformat <code>sk-ant-...</code>.
* OpenAI: [https://platform.openai.com/api-keys platform.openai.com/api-keys], Schlüsselformat <code>sk-...</code> oder <code>sk-proj-...</code>. Voraussetzung ist ein aufgeladenes Konto (Mindestbetrag derzeit USD 5).

== Datenschutz / Datenfluss ==

Bei aktivem Anbieter '''Anthropic''' gehen die Anfragen direkt an
<code>api.anthropic.com</code>, bei '''OpenAI''' direkt an
<code>api.openai.com</code>. Es gibt keinen eXept-seitigen Proxy oder
Zwischenspeicher. Mit dem Aktivitäts-Quelltext bzw. den Methoden-
Quelltexten werden auch Pin-Beschreibungen, Sub-Step-Namen und
referenzierte Environment-Variablen aus dem Block-Description-Modell
als Kontext versendet.

Bei Benutzung von Anthropic API-Tokens - wie hier der Fall - werden laut Anthropic die Daten nicht zum Training des KI-Modells genutzt ([https://privacy.claude.com/de/articles/7996868-werden-meine-daten-fur-das-modelltraining-verwendet Anthropic Erkärung dazu]). Für die Wahrheit dieser Aussage könne wir nicht garantieren und haften.

Wenn Sie sicher sein wollen, daß keine Information Ihr Haus verlässt empfehlen wir eine eigenem geschlossene in-house KI Umgebung, wie sie bei einigen unserer Kunden bereits existiert. Sie dürfen dann selbstverständlich nur die URLs dieser Umgebung konfigurieren. Expecco kommuniziert ausschließlich mit der von Ihnen eingegebenen KI.

== Tipps ==

* '''Mehrere Konversationen''': der Chat ist ein Singleton — eine neue Anfrage über ein Browser-/Editor-Menü startet jedesmal eine '''neue''' Konversation. Folge-Fragen (Klärung, Vertiefung) gehen über das Eingabefeld in derselben Konversation.
* '''Vorsicht:''' Die Größe der übertragenen Daten (auch die aus dem Chatfenster) geht in die Kostenberechnung ein. Deshalb immer eine neue Konversation starten, wenn es um ein neues Thema geht.
* '''Modell wechseln''': Für schnelle Routine-Antworten Sonnet, für schwierige Refactorings Opus. Über das '''Set model'''-Untermenü direkt aus der Toolbar oder über die Settings.
* '''Anbieter wechseln''': Sind Schlüssel für beide Anbieter konfiguriert, schaltet das '''Set provider'''-Untermenü ohne Umweg über den Settings-Dialog um.
* '''Code direkt ausführen''': In Code-Karten kann markierter Smalltalk-Code per doIt / printIt / inspectIt direkt evaluiert werden — praktisch z.B. um vom Modell vorgeschlagene SUnit-Asserts gleich auszuprobieren, ohne den Code erst in einen Workspace zu kopieren.
* '''Custom prompt''' eignet sich gut für „warum macht Methode X es so und nicht so?" oder „schreib mir einen ParameterizedTest dazu mit folgenden Daten: …".

== Tipps für die Arbeit mit claudeCode ==
Wenn Sie claudeCode verwenden, stehen ihnen noch weit mehr Funktionen zur Verfügung: sie können zum Beispiel im claudeCode Terminal eingeben:
* "mach mir eine neue Suite in einem neuen Fenster",
* "Mache eine Aktion zur Berechnung des Umfangs eines Kreises bei gegebenen Radius",
* "Erstelle eine neue Suite mit einem Testfall der folgendes macht:
** 1) webbrowser auf "www.exept.de" öffnen.
** 2) auf das logo oben links klicken.
** 3) webbrowser schliessen.
* welche Funktionalität ist in xxx.ets

(Anm.: es spielt keine Rolle, ob Sie sich in Deutsch oder Englisch unterhalten)

Claude wurde von uns in die Lage versetzt, selbst nach passenden Bibliotheken zu suchen, diese zu importieren, Aktionen zu generieren und den Testplan anzulegen.

Tatsächlich auch, den Test gleich durchzuführen und das Resultat zu analysieren.

Aktuell sind wir am trainieren, so dass claude z.B. selbst entscheidet ob es besser ist, eine fehlende Aktion als Diagramm oder elementa zu definieren. Es ist in der Lage, die Funktionen des unterliegenden Frameworks zu sehen und auch komplexe Aufgaben zu erledigen:
* "Aktion zum Lesen der Jahresumsätze eines Jahres aus der Datenbank"
* extrahiere aus dem xml Dokument alle budget Einträge und liefere die Summe

=== Erfahrungen und Tipps für die Arbeit ===

Sonnet-4 ist gefühlt weit intelligenter als Heiku-4.5,
aber auch weit teurer. Ihr Budget kann sehr schnell schmelzen mit Sonnet. Insbesondere wenn man auf medium oder high Intelligenzlevel arbeitet. Aber Haiku macht auch weit mehr Fehler und man sollte genau hinschauen was er so generiert. Gefühlt war Sonnet selbst im low level besser als Haiku. Aber der Preis...

Folgende konkrete Tipps aus unseren ersten Erfahrungen, diese Liste wird aktualisiert, und kann auch basieren auf unserer eigenen Dummheit. Ist also u.U. mit Vorsicht zu genießen.

* geben Sie Haiku mehr Hinweise, z.B. "schau mal dort, oder nimm das als Beispiel". Sonnet findet selbst viel besser Lösungen.

* kurze Anweisungen, je konkreter desto günstiger.

* Haiku ist weit "fauler". Z.B hat sonnet automatisch eine Dokumentation bei neuen Aktionen angelegt, und diese auch aktualisiert. Haiku hingegen musste man explizit eine Regel dazu anlegen (z.B. mit "wenn du eine Aktion anlegst oder änderst, aktualisiere die Dokumentation")

* Heiku ist dümmer. Regeln die von Sonnet angelegt wurden, können von Haiku u.U. nicht befolgt werden, weil Sonnet weit mehr generalisieren kann.

* sagen Sie beiden sie sollten wenn sie ein Problem haben, nicht lange selbst suchen. sondern nachfragen ob man ihnen einen Tipp geben kann. Wenn Sie das nicht tun, kann es sein dass Sonnet auch eine viertel Stunde nachdenkt und die Dollars schmelzen wie Eis in der Sonne (ist mir passiert, als ein Socket Problem in der Kommunikation auftrat, und er nicht erkannte, das die Antworten von mcp falsch waren, es hat dann selbst alle möglichen Wege gesucht, eine Nachricht abzusetzen, incl. der Erstellung diverser Shell, curl und Python Scripte... obgleich es eigentlich ein Interface dafür gab, das aber einen Fehler hatte). Insbesondere hatte ich dummerweise vorher sinngemäß gesagt er solle, wenn ein Problem auftritt dies und jenes tun, wobei dabei genau dieses Problem wieder auftrat...

* schränken Sie das Modell in seinen Möglichkeiten ein, z.B. sagen sie "editiere nicht die files sondern verwende dazu ein tool", oder "eine expecco Aktion und sag mir vorher welche du nimmst". Sonst kann es passieren dass es anfängt ihre ets zu entpacken um darin nach Strings zu suchen, obgleich es das eigentlich einfacher über das interface machen kann (dieses konkrete Problem wird nicht mehr auftreten aber Sie sehen den Punkt). Da war Sonnet weit intelligenter hat aber auch länger nachgedacht.

* wenn sie feststellen, dass es einen Fehler macht, sagen sie (mehr oder weniger wörtlich) "remember: mach dies nicht, oder um das zu machen tu das."

* sie können diese Erinnerungen sowohl in ihrem UserProfile (also im lokalen Filesystem) als auch in ihren expecco Präferenzen halten. Sagen Sie dazu "remember this in in my expecco memory" oder "remember (in my user memory): bla bla". Erinnerungen kann man auch löschen "forget to ...". Zu Beginn der nächsten session sagen sie "read your expecco memory".

* wechseln sie das Modell oder den level, je nach Komplexität der Aufgabe. Aber bedenken Sie dass Wissen von Session zu Session verloren geht, wenn es nicht erinnert wird. Technisch sind Erinnerungen nichts anderes als das Lesen einer Liste der vormaligen remember Anweisungen. Kosten also auch Tokens. Sie könnten also die Erinnerunge auch einfach neu eintippen ;-)

* auch wenn es so scheint: das "Ding" ist kein Mensch; lassen sie "bitte, danke, oder Begründungen - es sei denn sie dienen der Entscheidung - weg. Tatsächlich erhöhen sie den Tokenverbrauch u.U.

Subjektive Zusammenfassung:
* Haiku ist viel schneller in der Antwort und kostet ein Zehntel. Mit Sonnet war nach 3-4 Std Arbeit mein Limit erreicht und ich durfte Stunden Pause machen. Mit Haiku kann man durcharbeiten. Aber ich brauche auch mindestens doppelt so viel Zeit um haiku anzuleiten und seine Fehler wieder auszubügeln.

== Was kann eine lokale KI (z.B. ollama) ==

Erste Versuche sind eher ernüchternd. Ohne Zugriff auf lokale Quellen, mit rein antrainiertem Wissen sind die Modelle vermutlich zu klein. Hier eine Konversation mit gemma3:8b-it-qat (8 Mrd, quantifiziert) auf einem Rechner ohne GPU.
Die Antwortzeiten sind natürlich schlecht, aber mit einer GPU u.U. brauchbar.

Wichtig: wir sind selbst noch Anfänger und keine [https://en.wikipedia.org/wiki/Susan_Calvin KI Psychologen].

=== Installation ===
install ollama
ollama pull gemma3:8b-it-qat ;; gemma3:8b / gemma3:12b usw.
ollama run gemma3:8b-it-qat

=== Sitzung 1 ===
Hinweise: Wichtig, sonst labert Sie das Modell voll!

>>> respond short and concise
Understood

Hinweise: Smalltalk/X wissen hat er nicht, aber VW und Pharo sind ähnlich genug.

>>> you are an expert in smalltalk programming, especially in Smalltalk/X, visualworks and Squeak.

You have come to the right place I have a considerable depth of knowledge regarding Smalltalk...
Angeber- wir werden sehen

>>> what does the smalltalk expression "self at:4 put:'bla' " mean

Sets the character 'b' at index 4 of `self` (assuming `self` is a string).
Falsche Antwort; Smalltalk verwendet 1-basierte Indices, und 'bla' ist ein String

>>> how to compute the area of a circle given radius

```smalltalk
| radius area |
radius := 5.0.
area := radius * radius * PI.
^area
```
nicht schlecht.

>>> how to extract a substring

`substring:startIndexToEndIndex` (inclusive). E.g., `"hello" substring:2 to:4` yields `"llo"`.
wieder falsch; 1-basierter index, substring:to: möglicherweise in einem anderen Smalltalk vorhanden. Könnte man durchgehen lassen

>>> alternative?

`copyFrom:to:` (indexes inclusive). `string copyFrom:1 to:3` gives `"ell"`.
besser, aber immer noch falscher Index

>>> what is the result of 'hello' copyFrom:2 to:4

"llo"
war zu erwarten

>>> smalltalk uses 1 based indexing. what is the result

Correct. The result of `'hello' copyFrom:2 to:4` is `"llo"`.
soso. Er sieht ein, dass ich korrigiert habe - dann aber dickköpfig.

>>> in smalltalk the first index is 1 the last is the collection's size. Not as in Python or C.

Precisely. 1-based indexing is core to Smalltalk.
aha, er könnte es wissen; es fehlt ihm aber offensichtlich an Abstraktionsvermögen. Versuchen wir es mit einem Beispiel:

>>> remember: the result of 'hello' copyFrom:2 to4 is 'ell'

You are absolutely right! My apologies. `copyFrom:to:` includes both endpoints, so `'hello' copyFrom:2 to:4` results in `"ell"`. Thanks for the correction. I am still under development and learning nuances like this.
soso, eine Nuance. Mal sehen:

>>> >> what is the result of 'abcde' copyFrom:2 to:4

"bcd"
na also; geht doch.

=== Sitzung 2 ===

Neuer Versuch; eine neue Session. Gib ihm Grundwissen, das er nicht im Modell hat.
/clear
>>> answer short an concise
Okay.

>>> you are expert in smalltalk programming, especially smalltalk/x, visualworks and pharo

Acknowledged. I'm ready to leverage my knowledge of Smalltalk (including Smalltalk/X, VisualWorks, and Pharo) to
assist you. Ask away!
>>> remember: because smalltalk is 1-based indexing, the result of 'hello' copyFrom:2 to4 is 'ell'

Understood. I will keep in mind Smalltalk's 1-based indexing when answering your questions about string
manipulation and other operations
>>> what is the result of 'abcde' copyFrom:2 to:4

'bcd'
richtig!

>>> given Array #(10 20 30 40) what is the result of array at:3

30
richtig!

Man muss den Context also mit Wissen füllen, dann kommt durchaus sinnvolles heraus. Wir sind dran, das zu evaluieren damit möglicherweise sogar eine lokale KI (allerdings mit GPU) hilfreich unterstützen kann.

== Wahl der Modellgrösse ==

Versuche mit gemma3:270m (sehr klein; 270Mio), gemma3:1b (1 Mrd) und gemma3:4b (4 Mrd). Alle auf lokalem Rechner ohne GPU.
Versuch: Übersetzung einer Bausteindokumentation.

Eingabe: translate to German:
"show a dialog with an informationstring"

Die 270m und 1b Modelle kennen das Geschlecht nicht; sie drücken sich etwas ungeschickt aus:

"Zeigen Sie eine Dialoge mit einer Informationsstring"

Alternativen:
"Zeige einen Dialog mit einer Informationsstring."
"Zeige eine Dialoge mit einer Informationsstring."
"Zeige eine Dialoge mit einer Informationsstring."

bzw (1Mrd).
"Zeig eine Dialog mit einem Informationsstring"

Alternativen:
"Gib ein Dialog mit einem Informationen-String aus"
"Zeige einen Dialog, der eine Informations-Stränge enthält"

Das 4Mrd Modell scheint brauchbar:
"Zeige einen Dialog mit einer Informationsnachricht"

Alternativen:
"Erstelle ein Dialogfenster mit einer Informationsanzeige"
"Zeige ein Dialogfeld mit einer Informationen"

In jedem Fall darf man der KI nicht "blind" vertrauen.

[[Kategorie:Plugin]]
[[Kategorie:Erweiterung]]

KI Coding Plugin

2026-06-07T10:12:47Z

Cg: /* Wahl der Modellgrösse */

= KI Coding Plugin =

Das KI Coding Plugin bindet einen Large Language Model (LLM) basierten
KI-Assistenten in den Activity-Editor (Aktivitäten-Code), den
Compound-Netzwerk-Editor, den Dokumentations-Editor und in den
ST/X Class Browser ein. Das Plugin unterstützt zwei Anbieter, die im
Einstellungsdialog umschaltbar sind:

* '''Anthropic Claude''' (claude-opus-4-7, claude-sonnet-4-6, claude-haiku-4-5)
* '''OpenAI ChatGPT''' (gpt-4o, gpt-4o-mini, gpt-4.1, gpt-4.1-mini, gpt-4.1-nano, o1, o3)
* '''Ollama''' (codellama:7b, codellama:13b)
Je nach gewähltem Anbieter erscheint die Toolbar-Schaltfläche als
'''"Ask Claude"''' bzw. '''"Ask ChatGPT"'''; das Einstellungs-Tab
heißt '''"AI Coding"'''.

== Aktivitäten-Editor ==

Im Aktivitäten-Code-Editor erscheint in der Toolbar eine Schaltfläche
"Ask Claude" / "Ask ChatGPT" mit folgenden Aktionen:

* Open KI Window — öffnet das eigenständige Chat-Fenster
* Explain code — erklärt den Code der aktuellen Aktivität
* Suggest improvement — schlägt Verbesserungen vor
* Find bugs — sucht nach Fehlern, Race Conditions, nil-Handling-Problemen
* Generate doc-comment — generiert eine Aktivitäts-Dokumentation inklusive Pin-Kommentaren und füllt den Documentation-Tab
* Custom prompt... — freier Prompt; der Aktivitäts-Code wird als Kontext mitgesendet
* Set model ▸ — Untermenü mit den Modellen des aktiven Anbieters (das aktuell aktive ist mit ''(active)'' markiert)
* Set provider ▸ — nur sichtbar, wenn API-Schlüssel für mehr als einen Anbieter konfiguriert sind; Untermenü zum Umschalten zwischen Claude und ChatGPT

Code-Vorschläge können mit '''[Apply]''' (direkt am jeweiligen
Code-Block im Chat oder über die obere Apply-Schaltfläche) in den
Aktivitäts-Body übernommen werden. Vom KI gelieferte Smalltalk/X
Hilfsmethoden (Form: <code>Klasse >> selector</code>) werden nach
Rückfrage in die genannte Klasse compiliert.

== Compound (Netzwerk) Editor ==

Auf der Toolbar von Compound-Worksheets erscheint dieselbe
Schaltfläche, beschränkt auf die für Netze sinnvollen Aktionen
(Open KI Window, Generate doc-comment) — ebenfalls mit den
Untermenüs '''Set model''' und ggf. '''Set provider'''.

== Dokumentations-Editor ==

Der Dokumentations-Tab der Block-Description (Editor für Test-Cases,
Test-Plans und Aktivitäten) trägt dieselbe Toolbar-Schaltfläche
"Ask Claude" / "Ask ChatGPT" mit den Einträgen
'''Open KI Window''', '''Generate doc-comment''' sowie den
Untermenüs '''Set model''' und ggf. '''Set provider'''.
'''Generate doc-comment''' analysiert den aktuellen Block (Name,
vorhandene Beschreibung, Eingangs-/Ausgangs-Pins, Sub-Steps eines
Compound-Netzes, referenzierte Environment-Variablen) und schlägt
eine vollständige Block- und Pin-Dokumentation vor.

Ist der Block schreibgeschützt (importierte Library, RTL-Lizenz),
fragt '''[Apply]''' nach, ob der Block freigeschaltet und die
Dokumentation eingetragen werden soll.

== Class Browser (ST/X) ==

Im Class Browser stehen die Aktionen unter dem '''AI'''-Untermenü
sowie im Selektor-Kontextmenü zur Verfügung. Die Aktionen
operieren auf der aktuell ausgewählten Methode (Klasse + Selektor +
Quelltext werden als Kontext mitgesendet). '''[Apply]''' kann das
Resultat direkt in die Methode der aktiven Klasse einbauen.
Auch hier sind '''Set model''' und ggf. '''Set provider''' als
Untermenüs verfügbar.

== Chat-Fenster ==

Das eigenständige Chat-Fenster trägt den Titel
'''AI Coding [<Produkt> / <Modell>]''' (z.B.
"AI Coding [Claude / claude-opus-4-7]") und zeigt nach jedem Turn
den Tokenverbrauch und die kumulierten Kosten — sofern Preise für
das gewählte Modell hinterlegt sind. Anbieter- und Modellwechsel
im Einstellungsdialog werden live übernommen.

Das Transkript ist als vertikales Panel von "Karten" aufgebaut:

* '''Prosa-Karten''' enthalten den fließenden Text der Antwort; Zeilen werden auf die Fenster-Breite umgebrochen.
* '''Code-Karten''' (eingerahmt) entstehen aus markdown-Code-Blöcken (<code>```...```</code>) und sind als '''Workspace''' editierbar — das Standard-Smalltalk-Popup-Menü bietet doIt / printIt / inspectIt, ein <code>TestCase</code>-<code>simulatedSelf</code> ist gesetzt, so dass <code>self assert:... equals:...</code> direkt ausgeführt werden kann. Lange Blöcke scrollen innerhalb der Karte. Rechts oben sitzen die Schaltflächen '''[Apply]''' (sofern für den Kontext sinnvoll) und '''[⎘ Copy]'''; links wird der Sprachtag (smalltalk, python, …) angezeigt.
* '''Doku-Karten''' (volle Breite, Prosa) entstehen aus dem speziellen <code>```doc</code>-Block, den der Dokumentations-Generator anfordert; Inhalt ist die Vorschlags-Dokumentation für Block- und Pin-Beschreibungen.

Scroll-Lock: solange der Anwender bereits am unteren Ende des
Transkripts steht, folgt die Anzeige neu eintreffenden Karten
automatisch; nach manuellem Hochscrollen bleibt die Position stehen.

Bilder können als Anhang versendet werden (Screenshot oder
PNG/JPG-Datei). Anhänge funktionieren mit beiden Anbietern; bei
OpenAI nur mit vision-fähigen Modellen (gpt-4o-Familie).

== Einstellungen (AI Coding) ==

Im Einstellungsdialog unter '''Plugins → AI Coding''' (bzw. unter
'''Tools → AI Coding''' im Smalltalk-Launcher) werden konfiguriert:

* '''Provider''' — Anthropic oder OpenAI. Beim Wechsel werden API-URL und Default-Modell entsprechend angepasst; der gespeicherte API-Schlüssel des jeweiligen Anbieters wird geladen.
* '''API Key''' — Schlüssel des aktuell gewählten Anbieters. Die Schlüssel werden pro Anbieter getrennt gespeichert (<code>#claudeApiKey_anthropic</code> bzw. <code>#claudeApiKey_openai</code>), so dass zwischen den Anbietern ohne erneute Eingabe gewechselt werden kann. Das Setzen des Schlüssels erfolgt ausschließlich über diesen Dialog.
* '''Model''' — ein Modell aus der Liste des aktiven Anbieters oder ein selbst eingegebener Modellname. Kann auch direkt über das '''Set model'''-Untermenü in den Editor-Toolbars umgeschaltet werden.
* '''Max output tokens''' — maximale Antwortlänge.
* '''API URL''' — nur zu ändern für eigene Proxies / Gateways. Standard: <code>https://api.anthropic.com/v1/messages</code> bzw. <code>https://api.openai.com/v1/chat/completions</code>.

== API-Schlüssel beschaffen ==

* Anthropic: [https://console.anthropic.com console.anthropic.com], Schlüsselformat <code>sk-ant-...</code>.
* OpenAI: [https://platform.openai.com/api-keys platform.openai.com/api-keys], Schlüsselformat <code>sk-...</code> oder <code>sk-proj-...</code>. Voraussetzung ist ein aufgeladenes Konto (Mindestbetrag derzeit USD 5).

== Datenschutz / Datenfluss ==

Bei aktivem Anbieter '''Anthropic''' gehen die Anfragen direkt an
<code>api.anthropic.com</code>, bei '''OpenAI''' direkt an
<code>api.openai.com</code>. Es gibt keinen eXept-seitigen Proxy oder
Zwischenspeicher. Mit dem Aktivitäts-Quelltext bzw. den Methoden-
Quelltexten werden auch Pin-Beschreibungen, Sub-Step-Namen und
referenzierte Environment-Variablen aus dem Block-Description-Modell
als Kontext versendet.

Bei Benutzung von Anthropic API-Tokens - wie hier der Fall - werden laut Anthropic die Daten nicht zum Training des KI-Modells genutzt ([https://privacy.claude.com/de/articles/7996868-werden-meine-daten-fur-das-modelltraining-verwendet Anthropic Erkärung dazu]). Für die Wahrheit dieser Aussage könne wir nicht garantieren und haften.

Wenn Sie sicher sein wollen, daß keine Information Ihr Haus verlässt empfehlen wir eine eigenem geschlossene in-house KI Umgebung, wie sie bei einigen unserer Kunden bereits existiert. Sie dürfen dann selbstverständlich nur die URLs dieser Umgebung konfigurieren. Expecco kommuniziert ausschließlich mit der von Ihnen eingegebenen KI.

== Tipps ==

* '''Mehrere Konversationen''': der Chat ist ein Singleton — eine neue Anfrage über ein Browser-/Editor-Menü startet jedesmal eine '''neue''' Konversation. Folge-Fragen (Klärung, Vertiefung) gehen über das Eingabefeld in derselben Konversation.
* '''Vorsicht:''' Die Größe der übertragenen Daten (auch die aus dem Chatfenster) geht in die Kostenberechnung ein. Deshalb immer eine neue Konversation starten, wenn es um ein neues Thema geht.
* '''Modell wechseln''': Für schnelle Routine-Antworten Sonnet, für schwierige Refactorings Opus. Über das '''Set model'''-Untermenü direkt aus der Toolbar oder über die Settings.
* '''Anbieter wechseln''': Sind Schlüssel für beide Anbieter konfiguriert, schaltet das '''Set provider'''-Untermenü ohne Umweg über den Settings-Dialog um.
* '''Code direkt ausführen''': In Code-Karten kann markierter Smalltalk-Code per doIt / printIt / inspectIt direkt evaluiert werden — praktisch z.B. um vom Modell vorgeschlagene SUnit-Asserts gleich auszuprobieren, ohne den Code erst in einen Workspace zu kopieren.
* '''Custom prompt''' eignet sich gut für „warum macht Methode X es so und nicht so?" oder „schreib mir einen ParameterizedTest dazu mit folgenden Daten: …".

== Tipps für die Arbeit mit claudeCode ==
Wenn Sie claudeCode verwenden, stehen ihnen noch weit mehr Funktionen zur Verfügung: sie können zum Beispiel im claudeCode Terminal eingeben:
* "mach mir eine neue Suite in einem neuen Fenster",
* "Mache eine Aktion zur Berechnung des Umfangs eines Kreises bei gegebenen Radius",
* "Erstelle eine neue suite mit einem Testfall der folgendes macht:
** 1) webbrowser auf "www.exept.de" öffnen.
** 2) auf das logo oben links klicken.
** 3) webbrowser schliessen.
* welche Funktionalität ist in xxx.ets

Claude wurde von uns in die Lage versetzt, selbst nach passenden Bibliotheken zu suchen, diese zu importieren, Aktionen zu Generieren und den Testplan anzulegen.

Tatsächlich auch, den Test gleich durchzuführen und das Resultat zu analysieren.

Aktuell sind wir am trainieren, so dass claude z.B. selbst entscheidet ob es besser ist, eine fehlende Aktion als Diagramm oder als elementare zu definieren. Es ist in der Lage, die Funktionen des unterliegenden Frameworks zu sehen und auch komplexe Aufgaben zu erledigen:
* "aktion zum Lesen der Jahresumsätze eines Jahres aus der Datenbank"
* extrahiere aus dem xml Dokument alle budget Einträge und liefere die Summe

=== Erfahrungen und Tipps für die Arbeit ===

Sonnet-4 ist gefühlt weit intelligenter als Heiku-4.5,
aber auch weit teurer. Ihr Budget kann sehr schnell schmelzen mit Sonnet. Insbesondere wenn man auf medium oder high Intelligenzlevel abeitet. Aber Haiku macht auch weit mehr Fehler und man sollte genau hinschauen was er so generiert. Gefühlt war Sonnet selbst im low level besser als Haiku. Aber der Preis...

Folgende konkrete Tipps aus unseren ersten Erfahrungen, diese Liste wird aktualisiert, und kann auch basieren auf unserer eigenen Dummheit. Ist also u.U.mit Vorsicht zu geniessen.

* geben Sie Haiku Hinweise, z.B. schau mal dort, oder nimm das als Beispiel. Sonnet findet selbst viel besser Lösungen.
* kurze Anweisungen, je konkreter desto günstiger.
* haiku ist weit "fauler". Z.B hat sonnet automatisch eine Dokumentation bei neuen Aktionen angelegt, und diese auch aktualisiert. Haiku hingegen musste man explizit eine Regel dazu anlegen (z.B. mit "wenn du eine aktion anlegst oder änderst, aktualisiere die dokumentation")
* heiku ist dümmer. Regeln die von sonnet angelegt wurden, können von haiku u.U. nicht befolgt werden, weil sonnet weit mehr generalisieren kann.
* sagen sie beiden sie sollten wenn sie ein Problem haben, nicht lange selbst suchen. sondern nachfragen ob man ihnen einen Tipp geben kann. Wenn Sie das nicht tun, kann es sein dass Sonnet auch eine viertel Stunde nachdenkt und die Dollars schmelzen wie Eis in der Sonne (ist mir passiert, als ein Socket Problem in der Kommunikation auftrat, und er nicht erkannte, das die Antworten von mcp falsch waren, es hat dann selbst alle möglichen Wege gesucht, eine Nachricht abzusetzen, incl. der Erstellung diverser Shell, curl und Python Scripte... obgleich es eigentlich ein Interface dafür gab, das aber einen Fehler hatte).
* schränken Sie das Modell in seinen Möglichkeiten ein, z.B. sagen sie "editiere nicht die files sondern verwende dazu ein tool", oder "eine expecco aktion und sag mir vorher welche du nimmst". Sonst kann es passieren dass es anfängt ihre ets zu entpacken um darin nach strings zu suchen, obgleich es das eigentlich einfacher über das interface machen kann (dieses konkrete Problem wird nicht mehr auftreten aber Sie sehen den Punkt). Da war Sonnet weit intelligenter hat aber auch länger nachgedacht.
* wenn sie feststellen, dass es einen Fehler macht, sagen sie (wörtlich) "remember: mach dies nicht, oder um das zu machen tu das."
* sie können diese Erinnerungen sowohl in ihrem UserProfile (also im lokalen Filesystem) als auch in ihren expecco Präferenzen halten. Sagen Sie dazu "remember this in in my expecco memory" oder "remember (in my user memory): bla bla". Erinnerungen kann man auch löschen "forget to ...". Zu Beginn der nächsten session sagen sie "read your expecco memory".
* wechseln sie das Modell oder den level, je nach Komplexität der Aufgabe. Aber bedenken Sie dass Wissen von Session zu Session verloren geht, wenn es nicht erinnert wird. Technisch sind Erinnerungen nichts anderes als das Lesen einer Liste der vormaligen remember Anweisungen. Kosten also auch Tokens. Sie könnten also die Erinnerunge auch einfach neu eintippen ;-)
* auch wenn es so scheint: das "Ding" ist kein Mensch; lassen sie "bitte, danke, oder Begründungen - es sei denn sie dienen der Entscheidung - weg. Tatsächlich erhöhen sie den Tokenverbrauch u.U.

Subjektive Zusammenfassung:
* haiku ist viel schneller in der Antwort und kostet ein Zehntel. Mit Sonnet war nach 3-4 Std Arbeit mein Limit erreicht und ich durfte Stunden Pause machen. Mit Haiku kann man durcharbeiten. Aber ich brauche auch mindestens doppelt so viel Zeit um haiku anzuleiten und seine Fehler wieder auszubügeln.

== Was kann eine lokale KI (z.B. ollama) ==

Erste Versuche sind eher ernüchternd. Ohne Zugriff auf lokale Quellen, mit rein antrainiertem Wissen sind die Modelle vermutlich zu klein. Hier eine Konversation mit gemma3:8b-it-qat (8 Mrd, quantifiziert) auf einem Rechner ohne GPU.
Die Antwortzeiten sind natürlich schlecht, aber mit einer GPU u.U. brauchbar.

Wichtig: wir sind selbst noch Anfänger und keine [https://en.wikipedia.org/wiki/Susan_Calvin KI Psychologen].

=== Installation ===
install ollama
ollama pull gemma3:8b-it-qat ;; gemma3:8b / gemma3:12b usw.
ollama run gemma3:8b-it-qat

=== Sitzung 1 ===
Hinweise: Wichtig, sonst labert Sie das Modell voll!

>>> respond short and concise
Understood

Hinweise: Smalltalk/X wissen hat er nicht, aber VW und Pharo sind ähnlich genug.

>>> you are an expert in smalltalk programming, especially in Smalltalk/X, visualworks and Squeak.

You have come to the right place I have a considerable depth of knowledge regarding Smalltalk...
Angeber- wir werden sehen

>>> what does the smalltalk expression "self at:4 put:'bla' " mean

Sets the character 'b' at index 4 of `self` (assuming `self` is a string).
Falsche Antwort; Smalltalk verwendet 1-basierte Indices, und 'bla' ist ein String

>>> how to compute the area of a circle given radius

```smalltalk
| radius area |
radius := 5.0.
area := radius * radius * PI.
^area
```
nicht schlecht.

>>> how to extract a substring

`substring:startIndexToEndIndex` (inclusive). E.g., `"hello" substring:2 to:4` yields `"llo"`.
wieder falsch; 1-basierter index, substring:to: möglicherweise in einem anderen Smalltalk vorhanden. Könnte man durchgehen lassen

>>> alternative?

`copyFrom:to:` (indexes inclusive). `string copyFrom:1 to:3` gives `"ell"`.
besser, aber immer noch falscher Index

>>> what is the result of 'hello' copyFrom:2 to:4

"llo"
war zu erwarten

>>> smalltalk uses 1 based indexing. what is the result

Correct. The result of `'hello' copyFrom:2 to:4` is `"llo"`.
soso. Er sieht ein, dass ich korrigiert habe - dann aber dickköpfig.

>>> in smalltalk the first index is 1 the last is the collection's size. Not as in Python or C.

Precisely. 1-based indexing is core to Smalltalk.
aha, er könnte es wissen; es fehlt ihm aber offensichtlich an Abstraktionsvermögen. Versuchen wir es mit einem Beispiel:

>>> remember: the result of 'hello' copyFrom:2 to4 is 'ell'

You are absolutely right! My apologies. `copyFrom:to:` includes both endpoints, so `'hello' copyFrom:2 to:4` results in `"ell"`. Thanks for the correction. I am still under development and learning nuances like this.
soso, eine Nuance. Mal sehen:

>>> >> what is the result of 'abcde' copyFrom:2 to:4

"bcd"
na also; geht doch.

=== Sitzung 2 ===

Neuer Versuch; eine neue Session. Gib ihm Grundwissen, das er nicht im Modell hat.
/clear
>>> answer short an concise
Okay.

>>> you are expert in smalltalk programming, especially smalltalk/x, visualworks and pharo

Acknowledged. I'm ready to leverage my knowledge of Smalltalk (including Smalltalk/X, VisualWorks, and Pharo) to
assist you. Ask away!
>>> remember: because smalltalk is 1-based indexing, the result of 'hello' copyFrom:2 to4 is 'ell'

Understood. I will keep in mind Smalltalk's 1-based indexing when answering your questions about string
manipulation and other operations
>>> what is the result of 'abcde' copyFrom:2 to:4

'bcd'
richtig!

>>> given Array #(10 20 30 40) what is the result of array at:3

30
richtig!

Man muss den Context also mit Wissen füllen, dann kommt durchaus sinnvolles heraus. Wir sind dran, das zu evaluieren damit möglicherweise sogar eine lokale KI (allerdings mit GPU) hilfreich unterstützen kann.

== Wahl der Modellgrösse ==

Versuche mit gemma3:270m (sehr klein; 270Mio), gemma3:1b (1 Mrd) und gemma3:4b (4 Mrd). Alle auf lokalem Rechner ohne GPU.
Versuch: Übersetzung einer Bausteindokumentation.

Eingabe: translate to German:
"show a dialog with an informationstring"

Die 270m und 1b Modelle kennen das Geschlecht nicht; sie drücken sich etwas ungeschickt aus:

"Zeigen Sie eine Dialoge mit einer Informationsstring"

Alternativen:
"Zeige einen Dialog mit einer Informationsstring."
"Zeige eine Dialoge mit einer Informationsstring."
"Zeige eine Dialoge mit einer Informationsstring."

bzw (1Mrd).
"Zeig eine Dialog mit einem Informationsstring"

Alternativen:
"Gib ein Dialog mit einem Informationen-String aus"
"Zeige einen Dialog, der eine Informations-Stränge enthält"

Das 4Mrd Modell scheint brauchbar:
"Zeige einen Dialog mit einer Informationsnachricht"

Alternativen:
"Erstelle ein Dialogfenster mit einer Informationsanzeige"
"Zeige ein Dialogfeld mit einer Informationen"

In jedem Fall darf man der KI nicht "blind" vertrauen.

[[Kategorie:Plugin]]
[[Kategorie:Erweiterung]]

KI Coding Plugin

2026-06-07T10:11:51Z

Cg: /* Wahl der Modellgrösse */

= KI Coding Plugin =

Das KI Coding Plugin bindet einen Large Language Model (LLM) basierten
KI-Assistenten in den Activity-Editor (Aktivitäten-Code), den
Compound-Netzwerk-Editor, den Dokumentations-Editor und in den
ST/X Class Browser ein. Das Plugin unterstützt zwei Anbieter, die im
Einstellungsdialog umschaltbar sind:

* '''Anthropic Claude''' (claude-opus-4-7, claude-sonnet-4-6, claude-haiku-4-5)
* '''OpenAI ChatGPT''' (gpt-4o, gpt-4o-mini, gpt-4.1, gpt-4.1-mini, gpt-4.1-nano, o1, o3)
* '''Ollama''' (codellama:7b, codellama:13b)
Je nach gewähltem Anbieter erscheint die Toolbar-Schaltfläche als
'''"Ask Claude"''' bzw. '''"Ask ChatGPT"'''; das Einstellungs-Tab
heißt '''"AI Coding"'''.

== Aktivitäten-Editor ==

Im Aktivitäten-Code-Editor erscheint in der Toolbar eine Schaltfläche
"Ask Claude" / "Ask ChatGPT" mit folgenden Aktionen:

* Open KI Window — öffnet das eigenständige Chat-Fenster
* Explain code — erklärt den Code der aktuellen Aktivität
* Suggest improvement — schlägt Verbesserungen vor
* Find bugs — sucht nach Fehlern, Race Conditions, nil-Handling-Problemen
* Generate doc-comment — generiert eine Aktivitäts-Dokumentation inklusive Pin-Kommentaren und füllt den Documentation-Tab
* Custom prompt... — freier Prompt; der Aktivitäts-Code wird als Kontext mitgesendet
* Set model ▸ — Untermenü mit den Modellen des aktiven Anbieters (das aktuell aktive ist mit ''(active)'' markiert)
* Set provider ▸ — nur sichtbar, wenn API-Schlüssel für mehr als einen Anbieter konfiguriert sind; Untermenü zum Umschalten zwischen Claude und ChatGPT

Code-Vorschläge können mit '''[Apply]''' (direkt am jeweiligen
Code-Block im Chat oder über die obere Apply-Schaltfläche) in den
Aktivitäts-Body übernommen werden. Vom KI gelieferte Smalltalk/X
Hilfsmethoden (Form: <code>Klasse >> selector</code>) werden nach
Rückfrage in die genannte Klasse compiliert.

== Compound (Netzwerk) Editor ==

Auf der Toolbar von Compound-Worksheets erscheint dieselbe
Schaltfläche, beschränkt auf die für Netze sinnvollen Aktionen
(Open KI Window, Generate doc-comment) — ebenfalls mit den
Untermenüs '''Set model''' und ggf. '''Set provider'''.

== Dokumentations-Editor ==

Der Dokumentations-Tab der Block-Description (Editor für Test-Cases,
Test-Plans und Aktivitäten) trägt dieselbe Toolbar-Schaltfläche
"Ask Claude" / "Ask ChatGPT" mit den Einträgen
'''Open KI Window''', '''Generate doc-comment''' sowie den
Untermenüs '''Set model''' und ggf. '''Set provider'''.
'''Generate doc-comment''' analysiert den aktuellen Block (Name,
vorhandene Beschreibung, Eingangs-/Ausgangs-Pins, Sub-Steps eines
Compound-Netzes, referenzierte Environment-Variablen) und schlägt
eine vollständige Block- und Pin-Dokumentation vor.

Ist der Block schreibgeschützt (importierte Library, RTL-Lizenz),
fragt '''[Apply]''' nach, ob der Block freigeschaltet und die
Dokumentation eingetragen werden soll.

== Class Browser (ST/X) ==

Im Class Browser stehen die Aktionen unter dem '''AI'''-Untermenü
sowie im Selektor-Kontextmenü zur Verfügung. Die Aktionen
operieren auf der aktuell ausgewählten Methode (Klasse + Selektor +
Quelltext werden als Kontext mitgesendet). '''[Apply]''' kann das
Resultat direkt in die Methode der aktiven Klasse einbauen.
Auch hier sind '''Set model''' und ggf. '''Set provider''' als
Untermenüs verfügbar.

== Chat-Fenster ==

Das eigenständige Chat-Fenster trägt den Titel
'''AI Coding [<Produkt> / <Modell>]''' (z.B.
"AI Coding [Claude / claude-opus-4-7]") und zeigt nach jedem Turn
den Tokenverbrauch und die kumulierten Kosten — sofern Preise für
das gewählte Modell hinterlegt sind. Anbieter- und Modellwechsel
im Einstellungsdialog werden live übernommen.

Das Transkript ist als vertikales Panel von "Karten" aufgebaut:

* '''Prosa-Karten''' enthalten den fließenden Text der Antwort; Zeilen werden auf die Fenster-Breite umgebrochen.
* '''Code-Karten''' (eingerahmt) entstehen aus markdown-Code-Blöcken (<code>```...```</code>) und sind als '''Workspace''' editierbar — das Standard-Smalltalk-Popup-Menü bietet doIt / printIt / inspectIt, ein <code>TestCase</code>-<code>simulatedSelf</code> ist gesetzt, so dass <code>self assert:... equals:...</code> direkt ausgeführt werden kann. Lange Blöcke scrollen innerhalb der Karte. Rechts oben sitzen die Schaltflächen '''[Apply]''' (sofern für den Kontext sinnvoll) und '''[⎘ Copy]'''; links wird der Sprachtag (smalltalk, python, …) angezeigt.
* '''Doku-Karten''' (volle Breite, Prosa) entstehen aus dem speziellen <code>```doc</code>-Block, den der Dokumentations-Generator anfordert; Inhalt ist die Vorschlags-Dokumentation für Block- und Pin-Beschreibungen.

Scroll-Lock: solange der Anwender bereits am unteren Ende des
Transkripts steht, folgt die Anzeige neu eintreffenden Karten
automatisch; nach manuellem Hochscrollen bleibt die Position stehen.

Bilder können als Anhang versendet werden (Screenshot oder
PNG/JPG-Datei). Anhänge funktionieren mit beiden Anbietern; bei
OpenAI nur mit vision-fähigen Modellen (gpt-4o-Familie).

== Einstellungen (AI Coding) ==

Im Einstellungsdialog unter '''Plugins → AI Coding''' (bzw. unter
'''Tools → AI Coding''' im Smalltalk-Launcher) werden konfiguriert:

* '''Provider''' — Anthropic oder OpenAI. Beim Wechsel werden API-URL und Default-Modell entsprechend angepasst; der gespeicherte API-Schlüssel des jeweiligen Anbieters wird geladen.
* '''API Key''' — Schlüssel des aktuell gewählten Anbieters. Die Schlüssel werden pro Anbieter getrennt gespeichert (<code>#claudeApiKey_anthropic</code> bzw. <code>#claudeApiKey_openai</code>), so dass zwischen den Anbietern ohne erneute Eingabe gewechselt werden kann. Das Setzen des Schlüssels erfolgt ausschließlich über diesen Dialog.
* '''Model''' — ein Modell aus der Liste des aktiven Anbieters oder ein selbst eingegebener Modellname. Kann auch direkt über das '''Set model'''-Untermenü in den Editor-Toolbars umgeschaltet werden.
* '''Max output tokens''' — maximale Antwortlänge.
* '''API URL''' — nur zu ändern für eigene Proxies / Gateways. Standard: <code>https://api.anthropic.com/v1/messages</code> bzw. <code>https://api.openai.com/v1/chat/completions</code>.

== API-Schlüssel beschaffen ==

* Anthropic: [https://console.anthropic.com console.anthropic.com], Schlüsselformat <code>sk-ant-...</code>.
* OpenAI: [https://platform.openai.com/api-keys platform.openai.com/api-keys], Schlüsselformat <code>sk-...</code> oder <code>sk-proj-...</code>. Voraussetzung ist ein aufgeladenes Konto (Mindestbetrag derzeit USD 5).

== Datenschutz / Datenfluss ==

Bei aktivem Anbieter '''Anthropic''' gehen die Anfragen direkt an
<code>api.anthropic.com</code>, bei '''OpenAI''' direkt an
<code>api.openai.com</code>. Es gibt keinen eXept-seitigen Proxy oder
Zwischenspeicher. Mit dem Aktivitäts-Quelltext bzw. den Methoden-
Quelltexten werden auch Pin-Beschreibungen, Sub-Step-Namen und
referenzierte Environment-Variablen aus dem Block-Description-Modell
als Kontext versendet.

Bei Benutzung von Anthropic API-Tokens - wie hier der Fall - werden laut Anthropic die Daten nicht zum Training des KI-Modells genutzt ([https://privacy.claude.com/de/articles/7996868-werden-meine-daten-fur-das-modelltraining-verwendet Anthropic Erkärung dazu]). Für die Wahrheit dieser Aussage könne wir nicht garantieren und haften.

Wenn Sie sicher sein wollen, daß keine Information Ihr Haus verlässt empfehlen wir eine eigenem geschlossene in-house KI Umgebung, wie sie bei einigen unserer Kunden bereits existiert. Sie dürfen dann selbstverständlich nur die URLs dieser Umgebung konfigurieren. Expecco kommuniziert ausschließlich mit der von Ihnen eingegebenen KI.

== Tipps ==

* '''Mehrere Konversationen''': der Chat ist ein Singleton — eine neue Anfrage über ein Browser-/Editor-Menü startet jedesmal eine '''neue''' Konversation. Folge-Fragen (Klärung, Vertiefung) gehen über das Eingabefeld in derselben Konversation.
* '''Vorsicht:''' Die Größe der übertragenen Daten (auch die aus dem Chatfenster) geht in die Kostenberechnung ein. Deshalb immer eine neue Konversation starten, wenn es um ein neues Thema geht.
* '''Modell wechseln''': Für schnelle Routine-Antworten Sonnet, für schwierige Refactorings Opus. Über das '''Set model'''-Untermenü direkt aus der Toolbar oder über die Settings.
* '''Anbieter wechseln''': Sind Schlüssel für beide Anbieter konfiguriert, schaltet das '''Set provider'''-Untermenü ohne Umweg über den Settings-Dialog um.
* '''Code direkt ausführen''': In Code-Karten kann markierter Smalltalk-Code per doIt / printIt / inspectIt direkt evaluiert werden — praktisch z.B. um vom Modell vorgeschlagene SUnit-Asserts gleich auszuprobieren, ohne den Code erst in einen Workspace zu kopieren.
* '''Custom prompt''' eignet sich gut für „warum macht Methode X es so und nicht so?" oder „schreib mir einen ParameterizedTest dazu mit folgenden Daten: …".

== Tipps für die Arbeit mit claudeCode ==
Wenn Sie claudeCode verwenden, stehen ihnen noch weit mehr Funktionen zur Verfügung: sie können zum Beispiel im claudeCode Terminal eingeben:
* "mach mir eine neue Suite in einem neuen Fenster",
* "Mache eine Aktion zur Berechnung des Umfangs eines Kreises bei gegebenen Radius",
* "Erstelle eine neue suite mit einem Testfall der folgendes macht:
** 1) webbrowser auf "www.exept.de" öffnen.
** 2) auf das logo oben links klicken.
** 3) webbrowser schliessen.
* welche Funktionalität ist in xxx.ets

Claude wurde von uns in die Lage versetzt, selbst nach passenden Bibliotheken zu suchen, diese zu importieren, Aktionen zu Generieren und den Testplan anzulegen.

Tatsächlich auch, den Test gleich durchzuführen und das Resultat zu analysieren.

Aktuell sind wir am trainieren, so dass claude z.B. selbst entscheidet ob es besser ist, eine fehlende Aktion als Diagramm oder als elementare zu definieren. Es ist in der Lage, die Funktionen des unterliegenden Frameworks zu sehen und auch komplexe Aufgaben zu erledigen:
* "aktion zum Lesen der Jahresumsätze eines Jahres aus der Datenbank"
* extrahiere aus dem xml Dokument alle budget Einträge und liefere die Summe

=== Erfahrungen und Tipps für die Arbeit ===

Sonnet-4 ist gefühlt weit intelligenter als Heiku-4.5,
aber auch weit teurer. Ihr Budget kann sehr schnell schmelzen mit Sonnet. Insbesondere wenn man auf medium oder high Intelligenzlevel abeitet. Aber Haiku macht auch weit mehr Fehler und man sollte genau hinschauen was er so generiert. Gefühlt war Sonnet selbst im low level besser als Haiku. Aber der Preis...

Folgende konkrete Tipps aus unseren ersten Erfahrungen, diese Liste wird aktualisiert, und kann auch basieren auf unserer eigenen Dummheit. Ist also u.U.mit Vorsicht zu geniessen.

* geben Sie Haiku Hinweise, z.B. schau mal dort, oder nimm das als Beispiel. Sonnet findet selbst viel besser Lösungen.
* kurze Anweisungen, je konkreter desto günstiger.
* haiku ist weit "fauler". Z.B hat sonnet automatisch eine Dokumentation bei neuen Aktionen angelegt, und diese auch aktualisiert. Haiku hingegen musste man explizit eine Regel dazu anlegen (z.B. mit "wenn du eine aktion anlegst oder änderst, aktualisiere die dokumentation")
* heiku ist dümmer. Regeln die von sonnet angelegt wurden, können von haiku u.U. nicht befolgt werden, weil sonnet weit mehr generalisieren kann.
* sagen sie beiden sie sollten wenn sie ein Problem haben, nicht lange selbst suchen. sondern nachfragen ob man ihnen einen Tipp geben kann. Wenn Sie das nicht tun, kann es sein dass Sonnet auch eine viertel Stunde nachdenkt und die Dollars schmelzen wie Eis in der Sonne (ist mir passiert, als ein Socket Problem in der Kommunikation auftrat, und er nicht erkannte, das die Antworten von mcp falsch waren, es hat dann selbst alle möglichen Wege gesucht, eine Nachricht abzusetzen, incl. der Erstellung diverser Shell, curl und Python Scripte... obgleich es eigentlich ein Interface dafür gab, das aber einen Fehler hatte).
* schränken Sie das Modell in seinen Möglichkeiten ein, z.B. sagen sie "editiere nicht die files sondern verwende dazu ein tool", oder "eine expecco aktion und sag mir vorher welche du nimmst". Sonst kann es passieren dass es anfängt ihre ets zu entpacken um darin nach strings zu suchen, obgleich es das eigentlich einfacher über das interface machen kann (dieses konkrete Problem wird nicht mehr auftreten aber Sie sehen den Punkt). Da war Sonnet weit intelligenter hat aber auch länger nachgedacht.
* wenn sie feststellen, dass es einen Fehler macht, sagen sie (wörtlich) "remember: mach dies nicht, oder um das zu machen tu das."
* sie können diese Erinnerungen sowohl in ihrem UserProfile (also im lokalen Filesystem) als auch in ihren expecco Präferenzen halten. Sagen Sie dazu "remember this in in my expecco memory" oder "remember (in my user memory): bla bla". Erinnerungen kann man auch löschen "forget to ...". Zu Beginn der nächsten session sagen sie "read your expecco memory".
* wechseln sie das Modell oder den level, je nach Komplexität der Aufgabe. Aber bedenken Sie dass Wissen von Session zu Session verloren geht, wenn es nicht erinnert wird. Technisch sind Erinnerungen nichts anderes als das Lesen einer Liste der vormaligen remember Anweisungen. Kosten also auch Tokens. Sie könnten also die Erinnerunge auch einfach neu eintippen ;-)
* auch wenn es so scheint: das "Ding" ist kein Mensch; lassen sie "bitte, danke, oder Begründungen - es sei denn sie dienen der Entscheidung - weg. Tatsächlich erhöhen sie den Tokenverbrauch u.U.

Subjektive Zusammenfassung:
* haiku ist viel schneller in der Antwort und kostet ein Zehntel. Mit Sonnet war nach 3-4 Std Arbeit mein Limit erreicht und ich durfte Stunden Pause machen. Mit Haiku kann man durcharbeiten. Aber ich brauche auch mindestens doppelt so viel Zeit um haiku anzuleiten und seine Fehler wieder auszubügeln.

== Was kann eine lokale KI (z.B. ollama) ==

Erste Versuche sind eher ernüchternd. Ohne Zugriff auf lokale Quellen, mit rein antrainiertem Wissen sind die Modelle vermutlich zu klein. Hier eine Konversation mit gemma3:8b-it-qat (8 Mrd, quantifiziert) auf einem Rechner ohne GPU.
Die Antwortzeiten sind natürlich schlecht, aber mit einer GPU u.U. brauchbar.

Wichtig: wir sind selbst noch Anfänger und keine [https://en.wikipedia.org/wiki/Susan_Calvin KI Psychologen].

=== Installation ===
install ollama
ollama pull gemma3:8b-it-qat ;; gemma3:8b / gemma3:12b usw.
ollama run gemma3:8b-it-qat

=== Sitzung 1 ===
Hinweise: Wichtig, sonst labert Sie das Modell voll!

>>> respond short and concise
Understood

Hinweise: Smalltalk/X wissen hat er nicht, aber VW und Pharo sind ähnlich genug.

>>> you are an expert in smalltalk programming, especially in Smalltalk/X, visualworks and Squeak.

You have come to the right place I have a considerable depth of knowledge regarding Smalltalk...
Angeber- wir werden sehen

>>> what does the smalltalk expression "self at:4 put:'bla' " mean

Sets the character 'b' at index 4 of `self` (assuming `self` is a string).
Falsche Antwort; Smalltalk verwendet 1-basierte Indices, und 'bla' ist ein String

>>> how to compute the area of a circle given radius

```smalltalk
| radius area |
radius := 5.0.
area := radius * radius * PI.
^area
```
nicht schlecht.

>>> how to extract a substring

`substring:startIndexToEndIndex` (inclusive). E.g., `"hello" substring:2 to:4` yields `"llo"`.
wieder falsch; 1-basierter index, substring:to: möglicherweise in einem anderen Smalltalk vorhanden. Könnte man durchgehen lassen

>>> alternative?

`copyFrom:to:` (indexes inclusive). `string copyFrom:1 to:3` gives `"ell"`.
besser, aber immer noch falscher Index

>>> what is the result of 'hello' copyFrom:2 to:4

"llo"
war zu erwarten

>>> smalltalk uses 1 based indexing. what is the result

Correct. The result of `'hello' copyFrom:2 to:4` is `"llo"`.
soso. Er sieht ein, dass ich korrigiert habe - dann aber dickköpfig.

>>> in smalltalk the first index is 1 the last is the collection's size. Not as in Python or C.

Precisely. 1-based indexing is core to Smalltalk.
aha, er könnte es wissen; es fehlt ihm aber offensichtlich an Abstraktionsvermögen. Versuchen wir es mit einem Beispiel:

>>> remember: the result of 'hello' copyFrom:2 to4 is 'ell'

You are absolutely right! My apologies. `copyFrom:to:` includes both endpoints, so `'hello' copyFrom:2 to:4` results in `"ell"`. Thanks for the correction. I am still under development and learning nuances like this.
soso, eine Nuance. Mal sehen:

>>> >> what is the result of 'abcde' copyFrom:2 to:4

"bcd"
na also; geht doch.

=== Sitzung 2 ===

Neuer Versuch; eine neue Session. Gib ihm Grundwissen, das er nicht im Modell hat.
/clear
>>> answer short an concise
Okay.

>>> you are expert in smalltalk programming, especially smalltalk/x, visualworks and pharo

Acknowledged. I'm ready to leverage my knowledge of Smalltalk (including Smalltalk/X, VisualWorks, and Pharo) to
assist you. Ask away!
>>> remember: because smalltalk is 1-based indexing, the result of 'hello' copyFrom:2 to4 is 'ell'

Understood. I will keep in mind Smalltalk's 1-based indexing when answering your questions about string
manipulation and other operations
>>> what is the result of 'abcde' copyFrom:2 to:4

'bcd'
richtig!

>>> given Array #(10 20 30 40) what is the result of array at:3

30
richtig!

Man muss den Context also mit Wissen füllen, dann kommt durchaus sinnvolles heraus. Wir sind dran, das zu evaluieren damit möglicherweise sogar eine lokale KI (allerdings mit GPU) hilfreich unterstützen kann.

== Wahl der Modellgrösse ==

Versuche mit gemma3:270m (sehr klein; 270m), gemma3:1b (1 mrd) und gemma3:4b (4 mrd). Alle auf lokalem Rechner ohne GPU.
Versuch: Übersetzung einer Bausteindokumentation.

Eingabe: translate to German:
"show a dialog with an informationstring"

Die 270mio und 1mrd Modelle versagen, und kennen das Geschlecht nicht; sie stammeln:

"Zeigen Sie eine Dialoge mit einer Informationsstring"

Alternativen:
"Zeige einen Dialog mit einer Informationsstring."
"Zeige eine Dialoge mit einer Informationsstring."
"Zeige eine Dialoge mit einer Informationsstring."

bzw (1Mrd).
"Zeig eine Dialog mit einem Informationsstring"

Alternativen:
"Gib ein Dialog mit einem Informationen-String aus"
"Zeige einen Dialog, der eine Informations-Stränge enthält"

Das 4Mrd Modell scheint brauchbar:
"Zeige einen Dialog mit einer Informationsnachricht"

Alternativen:
"Erstelle ein Dialogfenster mit einer Informationsanzeige"
"Zeige ein Dialogfeld mit einer Informationen"

In jedem Fall darf man der KI nicht "blind" vertrauen.

[[Kategorie:Plugin]]
[[Kategorie:Erweiterung]]

KI Coding Plugin

2026-06-07T10:11:26Z

Cg: /* Sitzung 2 */

= KI Coding Plugin =

Das KI Coding Plugin bindet einen Large Language Model (LLM) basierten
KI-Assistenten in den Activity-Editor (Aktivitäten-Code), den
Compound-Netzwerk-Editor, den Dokumentations-Editor und in den
ST/X Class Browser ein. Das Plugin unterstützt zwei Anbieter, die im
Einstellungsdialog umschaltbar sind:

* '''Anthropic Claude''' (claude-opus-4-7, claude-sonnet-4-6, claude-haiku-4-5)
* '''OpenAI ChatGPT''' (gpt-4o, gpt-4o-mini, gpt-4.1, gpt-4.1-mini, gpt-4.1-nano, o1, o3)
* '''Ollama''' (codellama:7b, codellama:13b)
Je nach gewähltem Anbieter erscheint die Toolbar-Schaltfläche als
'''"Ask Claude"''' bzw. '''"Ask ChatGPT"'''; das Einstellungs-Tab
heißt '''"AI Coding"'''.

== Aktivitäten-Editor ==

Im Aktivitäten-Code-Editor erscheint in der Toolbar eine Schaltfläche
"Ask Claude" / "Ask ChatGPT" mit folgenden Aktionen:

* Open KI Window — öffnet das eigenständige Chat-Fenster
* Explain code — erklärt den Code der aktuellen Aktivität
* Suggest improvement — schlägt Verbesserungen vor
* Find bugs — sucht nach Fehlern, Race Conditions, nil-Handling-Problemen
* Generate doc-comment — generiert eine Aktivitäts-Dokumentation inklusive Pin-Kommentaren und füllt den Documentation-Tab
* Custom prompt... — freier Prompt; der Aktivitäts-Code wird als Kontext mitgesendet
* Set model ▸ — Untermenü mit den Modellen des aktiven Anbieters (das aktuell aktive ist mit ''(active)'' markiert)
* Set provider ▸ — nur sichtbar, wenn API-Schlüssel für mehr als einen Anbieter konfiguriert sind; Untermenü zum Umschalten zwischen Claude und ChatGPT

Code-Vorschläge können mit '''[Apply]''' (direkt am jeweiligen
Code-Block im Chat oder über die obere Apply-Schaltfläche) in den
Aktivitäts-Body übernommen werden. Vom KI gelieferte Smalltalk/X
Hilfsmethoden (Form: <code>Klasse >> selector</code>) werden nach
Rückfrage in die genannte Klasse compiliert.

== Compound (Netzwerk) Editor ==

Auf der Toolbar von Compound-Worksheets erscheint dieselbe
Schaltfläche, beschränkt auf die für Netze sinnvollen Aktionen
(Open KI Window, Generate doc-comment) — ebenfalls mit den
Untermenüs '''Set model''' und ggf. '''Set provider'''.

== Dokumentations-Editor ==

Der Dokumentations-Tab der Block-Description (Editor für Test-Cases,
Test-Plans und Aktivitäten) trägt dieselbe Toolbar-Schaltfläche
"Ask Claude" / "Ask ChatGPT" mit den Einträgen
'''Open KI Window''', '''Generate doc-comment''' sowie den
Untermenüs '''Set model''' und ggf. '''Set provider'''.
'''Generate doc-comment''' analysiert den aktuellen Block (Name,
vorhandene Beschreibung, Eingangs-/Ausgangs-Pins, Sub-Steps eines
Compound-Netzes, referenzierte Environment-Variablen) und schlägt
eine vollständige Block- und Pin-Dokumentation vor.

Ist der Block schreibgeschützt (importierte Library, RTL-Lizenz),
fragt '''[Apply]''' nach, ob der Block freigeschaltet und die
Dokumentation eingetragen werden soll.

== Class Browser (ST/X) ==

Im Class Browser stehen die Aktionen unter dem '''AI'''-Untermenü
sowie im Selektor-Kontextmenü zur Verfügung. Die Aktionen
operieren auf der aktuell ausgewählten Methode (Klasse + Selektor +
Quelltext werden als Kontext mitgesendet). '''[Apply]''' kann das
Resultat direkt in die Methode der aktiven Klasse einbauen.
Auch hier sind '''Set model''' und ggf. '''Set provider''' als
Untermenüs verfügbar.

== Chat-Fenster ==

Das eigenständige Chat-Fenster trägt den Titel
'''AI Coding [<Produkt> / <Modell>]''' (z.B.
"AI Coding [Claude / claude-opus-4-7]") und zeigt nach jedem Turn
den Tokenverbrauch und die kumulierten Kosten — sofern Preise für
das gewählte Modell hinterlegt sind. Anbieter- und Modellwechsel
im Einstellungsdialog werden live übernommen.

Das Transkript ist als vertikales Panel von "Karten" aufgebaut:

* '''Prosa-Karten''' enthalten den fließenden Text der Antwort; Zeilen werden auf die Fenster-Breite umgebrochen.
* '''Code-Karten''' (eingerahmt) entstehen aus markdown-Code-Blöcken (<code>```...```</code>) und sind als '''Workspace''' editierbar — das Standard-Smalltalk-Popup-Menü bietet doIt / printIt / inspectIt, ein <code>TestCase</code>-<code>simulatedSelf</code> ist gesetzt, so dass <code>self assert:... equals:...</code> direkt ausgeführt werden kann. Lange Blöcke scrollen innerhalb der Karte. Rechts oben sitzen die Schaltflächen '''[Apply]''' (sofern für den Kontext sinnvoll) und '''[⎘ Copy]'''; links wird der Sprachtag (smalltalk, python, …) angezeigt.
* '''Doku-Karten''' (volle Breite, Prosa) entstehen aus dem speziellen <code>```doc</code>-Block, den der Dokumentations-Generator anfordert; Inhalt ist die Vorschlags-Dokumentation für Block- und Pin-Beschreibungen.

Scroll-Lock: solange der Anwender bereits am unteren Ende des
Transkripts steht, folgt die Anzeige neu eintreffenden Karten
automatisch; nach manuellem Hochscrollen bleibt die Position stehen.

Bilder können als Anhang versendet werden (Screenshot oder
PNG/JPG-Datei). Anhänge funktionieren mit beiden Anbietern; bei
OpenAI nur mit vision-fähigen Modellen (gpt-4o-Familie).

== Einstellungen (AI Coding) ==

Im Einstellungsdialog unter '''Plugins → AI Coding''' (bzw. unter
'''Tools → AI Coding''' im Smalltalk-Launcher) werden konfiguriert:

* '''Provider''' — Anthropic oder OpenAI. Beim Wechsel werden API-URL und Default-Modell entsprechend angepasst; der gespeicherte API-Schlüssel des jeweiligen Anbieters wird geladen.
* '''API Key''' — Schlüssel des aktuell gewählten Anbieters. Die Schlüssel werden pro Anbieter getrennt gespeichert (<code>#claudeApiKey_anthropic</code> bzw. <code>#claudeApiKey_openai</code>), so dass zwischen den Anbietern ohne erneute Eingabe gewechselt werden kann. Das Setzen des Schlüssels erfolgt ausschließlich über diesen Dialog.
* '''Model''' — ein Modell aus der Liste des aktiven Anbieters oder ein selbst eingegebener Modellname. Kann auch direkt über das '''Set model'''-Untermenü in den Editor-Toolbars umgeschaltet werden.
* '''Max output tokens''' — maximale Antwortlänge.
* '''API URL''' — nur zu ändern für eigene Proxies / Gateways. Standard: <code>https://api.anthropic.com/v1/messages</code> bzw. <code>https://api.openai.com/v1/chat/completions</code>.

== API-Schlüssel beschaffen ==

* Anthropic: [https://console.anthropic.com console.anthropic.com], Schlüsselformat <code>sk-ant-...</code>.
* OpenAI: [https://platform.openai.com/api-keys platform.openai.com/api-keys], Schlüsselformat <code>sk-...</code> oder <code>sk-proj-...</code>. Voraussetzung ist ein aufgeladenes Konto (Mindestbetrag derzeit USD 5).

== Datenschutz / Datenfluss ==

Bei aktivem Anbieter '''Anthropic''' gehen die Anfragen direkt an
<code>api.anthropic.com</code>, bei '''OpenAI''' direkt an
<code>api.openai.com</code>. Es gibt keinen eXept-seitigen Proxy oder
Zwischenspeicher. Mit dem Aktivitäts-Quelltext bzw. den Methoden-
Quelltexten werden auch Pin-Beschreibungen, Sub-Step-Namen und
referenzierte Environment-Variablen aus dem Block-Description-Modell
als Kontext versendet.

Bei Benutzung von Anthropic API-Tokens - wie hier der Fall - werden laut Anthropic die Daten nicht zum Training des KI-Modells genutzt ([https://privacy.claude.com/de/articles/7996868-werden-meine-daten-fur-das-modelltraining-verwendet Anthropic Erkärung dazu]). Für die Wahrheit dieser Aussage könne wir nicht garantieren und haften.

Wenn Sie sicher sein wollen, daß keine Information Ihr Haus verlässt empfehlen wir eine eigenem geschlossene in-house KI Umgebung, wie sie bei einigen unserer Kunden bereits existiert. Sie dürfen dann selbstverständlich nur die URLs dieser Umgebung konfigurieren. Expecco kommuniziert ausschließlich mit der von Ihnen eingegebenen KI.

== Tipps ==

* '''Mehrere Konversationen''': der Chat ist ein Singleton — eine neue Anfrage über ein Browser-/Editor-Menü startet jedesmal eine '''neue''' Konversation. Folge-Fragen (Klärung, Vertiefung) gehen über das Eingabefeld in derselben Konversation.
* '''Vorsicht:''' Die Größe der übertragenen Daten (auch die aus dem Chatfenster) geht in die Kostenberechnung ein. Deshalb immer eine neue Konversation starten, wenn es um ein neues Thema geht.
* '''Modell wechseln''': Für schnelle Routine-Antworten Sonnet, für schwierige Refactorings Opus. Über das '''Set model'''-Untermenü direkt aus der Toolbar oder über die Settings.
* '''Anbieter wechseln''': Sind Schlüssel für beide Anbieter konfiguriert, schaltet das '''Set provider'''-Untermenü ohne Umweg über den Settings-Dialog um.
* '''Code direkt ausführen''': In Code-Karten kann markierter Smalltalk-Code per doIt / printIt / inspectIt direkt evaluiert werden — praktisch z.B. um vom Modell vorgeschlagene SUnit-Asserts gleich auszuprobieren, ohne den Code erst in einen Workspace zu kopieren.
* '''Custom prompt''' eignet sich gut für „warum macht Methode X es so und nicht so?" oder „schreib mir einen ParameterizedTest dazu mit folgenden Daten: …".

== Tipps für die Arbeit mit claudeCode ==
Wenn Sie claudeCode verwenden, stehen ihnen noch weit mehr Funktionen zur Verfügung: sie können zum Beispiel im claudeCode Terminal eingeben:
* "mach mir eine neue Suite in einem neuen Fenster",
* "Mache eine Aktion zur Berechnung des Umfangs eines Kreises bei gegebenen Radius",
* "Erstelle eine neue suite mit einem Testfall der folgendes macht:
** 1) webbrowser auf "www.exept.de" öffnen.
** 2) auf das logo oben links klicken.
** 3) webbrowser schliessen.
* welche Funktionalität ist in xxx.ets

Claude wurde von uns in die Lage versetzt, selbst nach passenden Bibliotheken zu suchen, diese zu importieren, Aktionen zu Generieren und den Testplan anzulegen.

Tatsächlich auch, den Test gleich durchzuführen und das Resultat zu analysieren.

Aktuell sind wir am trainieren, so dass claude z.B. selbst entscheidet ob es besser ist, eine fehlende Aktion als Diagramm oder als elementare zu definieren. Es ist in der Lage, die Funktionen des unterliegenden Frameworks zu sehen und auch komplexe Aufgaben zu erledigen:
* "aktion zum Lesen der Jahresumsätze eines Jahres aus der Datenbank"
* extrahiere aus dem xml Dokument alle budget Einträge und liefere die Summe

=== Erfahrungen und Tipps für die Arbeit ===

Sonnet-4 ist gefühlt weit intelligenter als Heiku-4.5,
aber auch weit teurer. Ihr Budget kann sehr schnell schmelzen mit Sonnet. Insbesondere wenn man auf medium oder high Intelligenzlevel abeitet. Aber Haiku macht auch weit mehr Fehler und man sollte genau hinschauen was er so generiert. Gefühlt war Sonnet selbst im low level besser als Haiku. Aber der Preis...

Folgende konkrete Tipps aus unseren ersten Erfahrungen, diese Liste wird aktualisiert, und kann auch basieren auf unserer eigenen Dummheit. Ist also u.U.mit Vorsicht zu geniessen.

* geben Sie Haiku Hinweise, z.B. schau mal dort, oder nimm das als Beispiel. Sonnet findet selbst viel besser Lösungen.
* kurze Anweisungen, je konkreter desto günstiger.
* haiku ist weit "fauler". Z.B hat sonnet automatisch eine Dokumentation bei neuen Aktionen angelegt, und diese auch aktualisiert. Haiku hingegen musste man explizit eine Regel dazu anlegen (z.B. mit "wenn du eine aktion anlegst oder änderst, aktualisiere die dokumentation")
* heiku ist dümmer. Regeln die von sonnet angelegt wurden, können von haiku u.U. nicht befolgt werden, weil sonnet weit mehr generalisieren kann.
* sagen sie beiden sie sollten wenn sie ein Problem haben, nicht lange selbst suchen. sondern nachfragen ob man ihnen einen Tipp geben kann. Wenn Sie das nicht tun, kann es sein dass Sonnet auch eine viertel Stunde nachdenkt und die Dollars schmelzen wie Eis in der Sonne (ist mir passiert, als ein Socket Problem in der Kommunikation auftrat, und er nicht erkannte, das die Antworten von mcp falsch waren, es hat dann selbst alle möglichen Wege gesucht, eine Nachricht abzusetzen, incl. der Erstellung diverser Shell, curl und Python Scripte... obgleich es eigentlich ein Interface dafür gab, das aber einen Fehler hatte).
* schränken Sie das Modell in seinen Möglichkeiten ein, z.B. sagen sie "editiere nicht die files sondern verwende dazu ein tool", oder "eine expecco aktion und sag mir vorher welche du nimmst". Sonst kann es passieren dass es anfängt ihre ets zu entpacken um darin nach strings zu suchen, obgleich es das eigentlich einfacher über das interface machen kann (dieses konkrete Problem wird nicht mehr auftreten aber Sie sehen den Punkt). Da war Sonnet weit intelligenter hat aber auch länger nachgedacht.
* wenn sie feststellen, dass es einen Fehler macht, sagen sie (wörtlich) "remember: mach dies nicht, oder um das zu machen tu das."
* sie können diese Erinnerungen sowohl in ihrem UserProfile (also im lokalen Filesystem) als auch in ihren expecco Präferenzen halten. Sagen Sie dazu "remember this in in my expecco memory" oder "remember (in my user memory): bla bla". Erinnerungen kann man auch löschen "forget to ...". Zu Beginn der nächsten session sagen sie "read your expecco memory".
* wechseln sie das Modell oder den level, je nach Komplexität der Aufgabe. Aber bedenken Sie dass Wissen von Session zu Session verloren geht, wenn es nicht erinnert wird. Technisch sind Erinnerungen nichts anderes als das Lesen einer Liste der vormaligen remember Anweisungen. Kosten also auch Tokens. Sie könnten also die Erinnerunge auch einfach neu eintippen ;-)
* auch wenn es so scheint: das "Ding" ist kein Mensch; lassen sie "bitte, danke, oder Begründungen - es sei denn sie dienen der Entscheidung - weg. Tatsächlich erhöhen sie den Tokenverbrauch u.U.

Subjektive Zusammenfassung:
* haiku ist viel schneller in der Antwort und kostet ein Zehntel. Mit Sonnet war nach 3-4 Std Arbeit mein Limit erreicht und ich durfte Stunden Pause machen. Mit Haiku kann man durcharbeiten. Aber ich brauche auch mindestens doppelt so viel Zeit um haiku anzuleiten und seine Fehler wieder auszubügeln.

== Was kann eine lokale KI (z.B. ollama) ==

Erste Versuche sind eher ernüchternd. Ohne Zugriff auf lokale Quellen, mit rein antrainiertem Wissen sind die Modelle vermutlich zu klein. Hier eine Konversation mit gemma3:8b-it-qat (8 Mrd, quantifiziert) auf einem Rechner ohne GPU.
Die Antwortzeiten sind natürlich schlecht, aber mit einer GPU u.U. brauchbar.

Wichtig: wir sind selbst noch Anfänger und keine [https://en.wikipedia.org/wiki/Susan_Calvin KI Psychologen].

=== Installation ===
install ollama
ollama pull gemma3:8b-it-qat ;; gemma3:8b / gemma3:12b usw.
ollama run gemma3:8b-it-qat

=== Sitzung 1 ===
Hinweise: Wichtig, sonst labert Sie das Modell voll!

>>> respond short and concise
Understood

Hinweise: Smalltalk/X wissen hat er nicht, aber VW und Pharo sind ähnlich genug.

>>> you are an expert in smalltalk programming, especially in Smalltalk/X, visualworks and Squeak.

You have come to the right place I have a considerable depth of knowledge regarding Smalltalk...
Angeber- wir werden sehen

>>> what does the smalltalk expression "self at:4 put:'bla' " mean

Sets the character 'b' at index 4 of `self` (assuming `self` is a string).
Falsche Antwort; Smalltalk verwendet 1-basierte Indices, und 'bla' ist ein String

>>> how to compute the area of a circle given radius

```smalltalk
| radius area |
radius := 5.0.
area := radius * radius * PI.
^area
```
nicht schlecht.

>>> how to extract a substring

`substring:startIndexToEndIndex` (inclusive). E.g., `"hello" substring:2 to:4` yields `"llo"`.
wieder falsch; 1-basierter index, substring:to: möglicherweise in einem anderen Smalltalk vorhanden. Könnte man durchgehen lassen

>>> alternative?

`copyFrom:to:` (indexes inclusive). `string copyFrom:1 to:3` gives `"ell"`.
besser, aber immer noch falscher Index

>>> what is the result of 'hello' copyFrom:2 to:4

"llo"
war zu erwarten

>>> smalltalk uses 1 based indexing. what is the result

Correct. The result of `'hello' copyFrom:2 to:4` is `"llo"`.
soso. Er sieht ein, dass ich korrigiert habe - dann aber dickköpfig.

>>> in smalltalk the first index is 1 the last is the collection's size. Not as in Python or C.

Precisely. 1-based indexing is core to Smalltalk.
aha, er könnte es wissen; es fehlt ihm aber offensichtlich an Abstraktionsvermögen. Versuchen wir es mit einem Beispiel:

>>> remember: the result of 'hello' copyFrom:2 to4 is 'ell'

You are absolutely right! My apologies. `copyFrom:to:` includes both endpoints, so `'hello' copyFrom:2 to:4` results in `"ell"`. Thanks for the correction. I am still under development and learning nuances like this.
soso, eine Nuance. Mal sehen:

>>> >> what is the result of 'abcde' copyFrom:2 to:4

"bcd"
na also; geht doch.

=== Sitzung 2 ===

Neuer Versuch; eine neue Session. Gib ihm Grundwissen, das er nicht im Modell hat.
/clear
>>> answer short an concise
Okay.

>>> you are expert in smalltalk programming, especially smalltalk/x, visualworks and pharo

Acknowledged. I'm ready to leverage my knowledge of Smalltalk (including Smalltalk/X, VisualWorks, and Pharo) to
assist you. Ask away!
>>> remember: because smalltalk is 1-based indexing, the result of 'hello' copyFrom:2 to4 is 'ell'

Understood. I will keep in mind Smalltalk's 1-based indexing when answering your questions about string
manipulation and other operations
>>> what is the result of 'abcde' copyFrom:2 to:4

'bcd'
richtig!

>>> given Array #(10 20 30 40) what is the result of array at:3

30
richtig!

Man muss den Context also mit Wissen füllen, dann kommt durchaus sinnvolles heraus. Wir sind dran, das zu evaluieren damit möglicherweise sogar eine lokale KI (allerdings mit GPU) hilfreich unterstützen kann.

== Wahl der Modellgrösse ==

Versuche mit gemma3:270m (sehr klein; 270m), gemma3:1b (1 mrd) und gemma3:4b (4 mrd). Alle auf lokalem Rechner ohne GPU.
Versuch: Übersetzung einer Bausteindokumentation.

Eingabe: translate to German:
"show a dialog with an informationstring"

Die 270mio und 1mrd Modelle versagen, und kennen das Geschlecht nicht; sie stammeln:

"Zeigen Sie eine Dialoge mit einer Informationsstring"

Alternativen:
"Zeige einen Dialog mit einer Informationsstring."
"Zeige eine Dialoge mit einer Informationsstring."
"Zeige eine Dialoge mit einer Informationsstring."

bzw (1Mrd).
"Zeig eine Dialog mit einem Informationsstring"

Alternativen:
"Gib ein Dialog mit einem Informationen-String aus"
"Zeige einen Dialog, der eine Informations-Stränge enthält"

Das 4Mrd Modell scheint brauchbar:
"Zeige einen Dialog mit einer Informationsnachricht"

Alternativen:
"Erstelle ein Dialogfenster mit einer Informationsanzeige"
"Zeige ein Dialogfeld mit einer Informationen"

In jedem Fall darf man der KI nicht "blind" vertrauen.

[[Kategorie:Plugin]]
[[Kategorie:Erweiterung]]

Smalltalk Syntax Cheat Sheet

2026-06-07T07:15:16Z

Cg: /* Smalltalk Philosophy */

A short, one page summary of what beginners need to know about Smalltalk/X, its syntax and most useful code fragments. As usual, this is only a tiny fraction of what is really awailable, and you should use the builtin class browser to find many more useful functions in the system.

This page was extracted from the "Smalltalk/X Programmers guide - Smalltalk/X Cheat Sheet".
 Smalltalk/X language extensions (w.r.t. other Smalltalk implementations) are marked with '''(*)'''.

== Smalltalk Philosophy ==

A very short summary and introduction to the fundamental principles underlying the Smalltalk language.

* Everything is an '''Object''' this includes the most basic ''things'' like numbers, strings and characters, up to complex objects like windows, editors, compilers, applications etc.

* The world consists of objects which '''communicate by sending messages'''. (in other languages this is also known as ''virtual function call'', but this term is not used in Smalltalk)

* A message looks like an english sentence, and might look like "<code>heyYou doSomething</code>". In this example, the "heyYou" is called the "''receiver of the message''" and "doSomething" is called the "''message selector''"
: You may pass additional parameter objects (arguments) as in: "<code>heyYou doSomethingWith:arg</code>" or multiple arguments as in "<code>heyYou doSomethingWith:arg1 and:arg2</code>".
: In these examples, the selectors are "doSomethingWith:" and "doSomethingWith:and:" respectively (i.e. the concatenation of the so called ''keywords''). They are two different messages with different selectors. In contrast to most other languages, this is '''not''' the same message with different number of arguments, but two completely different messages).

* Messages without argument are called "''unary messages''"; those with arguments are called "''keyword messages''"
: For example "<code>Transcript clear</code>" sends the message "clear" to the Transcript object; a unary message,
: and "<code>Transcript show:'hello'</code>" sends the message "show:" to the Transcript, passing a string argument; a keyword message

* To allow for arithmetic operations, any non-letter character (except for a few) are treated like a message name and written between the receiver and the one and only argument. These are called "''binary messages''".
: For example: <code>"3+4"</code> or <code>"abc,def"</code> (yes, the comma is an operator; it does string concatenation). You can place whitespace anywhere between selectors, keywords and arguemnts (eg. <code>"3 + 4"</code> and <code>"3+4"</code> are the same).

* An object may respond (or "''answer''") by returning a result object. In the above example, "<code>3+4</code>" would answer "7", and "<code>'hello' , 'world'</code>" would answer 'helloworld'

* binary messages have no meaning to the compiler; they all have equal precedence and are evaluated from left to right.
: Admitted, this makes arithmetic a little strange initially; you'll need parentheses as there is not precedence of eg. * over +. The expression "3 + 4 * 5" will be evaluated left to right and answer 35.

* Everything in this world is an object; from low level things like booleans, true, false, integer numbers, floating point numbers characters etc. to the most complex objects.
: Objects can refer to (i.e. hold references) to other objects. Technically, all such references are via pointers. There is no way to directly embed an object into another object, except by reference.

* Every object is associated to a class. Classes define the behavior of their instances. I.e. they define how they respond to messages. The response is implemented by a so called ''method''. That is a piece of code which is executed when a message comes in. A method consist of a number of statements (which are mostly message sends), each separated by a full stop (as in english).
: Inside a method, the receiver object (the object which got the message and is now executing the method) is called the ''receiver'' and refered to by the reserved word "<code>self</code>".

* Classes are themself objects, which respond to messages. Typically class messages would answer new instances, constants or implement utility functionality. There are also class messages to create new classes.

* Class can inherit common functionality (i.e. method implementations) from a superclass. Thus creating a hierarchy of classes. Typical hierarchies are the Number hierarchy, Collections, Streams and UI Widgets.
: Inside a method, the special reserved word "<code>super</code>" also refers to the current receiver, but message sends will ignore any method implemented in the methods class, but instead look for inherited (superclass) methods.

* In Smalltalk, every behavior is defined by corresponding message implementations. This includes control features (i.e. if-then-else, loops and exception handling). All of them are implemented as messages being sent to booleans (<code>ifTrue:</code>/<code>ifFalse:</code>) or blocks (<code>whileTrue:</code>)

* Blocks are objects, which wrap a piece of code. Other languages know them as ''anonymous functions'', ''lambdas'' or ''closures''.<
: But the Smalltalk syntax makes them super easy to use: just write a number of expressions inside square brackets, as in:"<code>[ Transcript show: 10 factorial ]</code>".
: Blocks are real objects - they can be passed as argument in a message send; for example to a boolean: "<code>aBoolean ifTrue: [ Transcript show: 'yes' ]</code>"
: they can be stored in variables and passed around just like any other object
: blocks can receive messages, especially loop messages: "<code>[ a < 10] whileTrue:[ Transcript showCR: a. a := a + 1 ]</code>",
: and they can be returned from a method (''answer from a message'') .

* a small language and a big library the syntax of Smalltalk is tiny and learned in minutes. The library (i.e. the classes you get) is big, flexible and extendable. The IDE is really an "''integrated environment''" as it is both completely implemented in Smalltalk, part of the running system (not outside), immediately updating the running system.

== Syntax ==

==== Comments ====

{| class="wikitable"
|-
| Regular comment
| <code>" this is a comment "</code>
| ''any text between double quotes''
|-
| EOL-Comment (*)
| <code>"/ this is an End-of-Line comment</code>
| ''text from quote-slash to line end''
|-
| Token-Comment (*)
| <code>"<<END a multiline token-comment up to a line starting with 'END' more commented stuff here ... comment ends here END</code>
| ''text up to line beginning with whatever token came after the initial "<<" ''
|}

==== Literal Constants ====

===== Numbers =====

{| class="wikitable"
|-
| Integers</td>
| <code>12345</code> </code>-12345<code>
|
|-
| Large integers
| <code>1234567890123456789012345</code>…
| ''arbitrary number of digits''
|-
| Integers with radix (Smalltalk style)
| <code>16rAFFE</code>, <code>2r010101</code>, <code>8r0777</code>, <code>3r012012</code>, <code>16r-AFFE</code>, <code>2r-010101</code>
| ''prepend the radix (base) any radix from 2..36 is possible (i.e. 3r222 is a ternary number)''
|-
| Integers with radix (C style) (*)
| <code>0xFEED</code> <code>-0xBEAF</code> <code>0b11011</code>,<code>-0b1100</code>
| ''C/Java/JavaScript style: prepend radix indicator ('x', 'b', 'o') One of hex, binary and octal''
|-
| Floats (IEEE double; roughly 17 digits)
| 12.456 1.234e17 -6.9 -6e-10 Float pi Float e
| ''called "Float", but actually hold double precision Common constants can be referred to "by name".''
|-
| Short floats (IEEE single; roughly 8 digits) (*)
| <code>1.234e17f</code> <code>-6e-10f</code>
| <strike>''this is controlled by a ParserFlag (singlePrecisionFloatF), which is currently defaulted to false. Thus, by default, double precision floats are created with the 'f' exponent character.''</strike>
|-
| Long floats (IEEE extended; roughly 20 digits) (*)
| <code>1.234e17q</code> <code>-6q-10q</code>
| ''actual precision depends on the underlying CPU (x86/x86_64: 80bit; Sparc: 128 bit)
|-
| Quad floats; (IEEE quad; roughly 34 digits (*)
| <code>1.234e17Q</code> <code>-6e-10Q</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Octuple floats; roughly 60 digits (*)
| <code>1.234e17QO</code> <code>-6e-10QP</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Large floats; roughly 60 digits by default, but any precision possible (*)
| <code>1.234e17QL</code> <code>-6e-10QL</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Fractions
| <code>(1/3)</code> <code>(17/2)</code> (-3/2)
|
|-
| ScaledDecimals
| <code>1234.53s2</code>
| ''the number after the s specifies the number of digits''
|-
| Complex
| <code>(1.5 + 3i)</code> <code>2i</code> <code>(3.0q + 5.0qi</code>)
|}

===== Characters and Strings =====

{| class="wikitable"
|-
| Characters
| <code>$a</code> <code>Character space</code> <code>Character nl</code> Also: "<code>null</code>", "<code>tab</code>", "<code>return</code>", "<code>bell</code>"... Or: <code>Character codePoint:n</code>
| ''Smalltalk does not support any escape sequence Common constants can be referred to "by name".''
|-
| Strings
| <code>'hello'</code>
| ''traditionally, Smalltalk does not support any escape sequence inside (i.e. they are what Python calls "Raw Strings") But see below...''
|-
| Strings (C Style) (*)
| <code>c'hello\nworld'</code>
| ''supports the common C-escape sequences, such as "\n", "\t", "\xHH", "\uXXXX"''
|-
| Strings (with embedded expressios) (*)
| <code>e'hello {OperatingSystem getLoginName}'</code>
| ''expanded expression strings expressions in braces are evaluated at runtime and sliced into the string (also a C-string). Similar to python's f-strings.''
|-
| Strings (national language translated with embedded expressios) (*)
| <code>i'hello {OperatingSystem getLoginName}'</code>
| ''international strings like above, but the string is also possibly translated to a national language''
|-
| Symbols
| <code>#'hello'</code> <code>#foo</code> <code>#+</code>
| ''symbols are interned strings; two symbols with the same characters are guaranteed to be the identical object (not just equal) without quotes, if only alphaNumeric characters''
|}

===== Arrays and Objects =====
{| class="wikitable"
|-
| Arrays 
| <code>#( el1 el2 ... elN )</code>
| each element is a literal constant
|-
| Byte Arrays
| <code>#[ b1 b2 ... bN ]</code>
| each byte-element an integer constant in 0..255
|-
| Special Number Arrays (*)
| <code>#XX( v1 v2 ... vN )</code>
| XX: is one of  'u8', 's8', 'u16', 's16', 'u32', 's32', 'u64', 's64', 'f32', 'f64'  and each element being an integer or float constant
|-
| Immediate Inline Objects (*)
| <code>#{ foo: fooValue . bar: barValue }</code>
| fooValue and barValue: are constants
|}

==== Lambda Blocks (Closures) ====

{| class="wikitable"
|-
| Without argument
| <code>[ expr1 . expr2 ... exprN ]</code>
| multiple expressions sep'd by period. When evaluated, the value is the value from the last expression, exprN
|-
| One argument
| <code>[ :arg |     expr1 . expr2 ... exprN ]</code>
|-
| Multiple arguments
| <code>[ :a1 :a2 ... :aN |     expr1 . expr2 ... exprN ]</code>
|-
| Local Variables inside a block
| <code>[ :a1 ... :aN |      |local1 local2 |      expr1 ... exprN ]</code>
|}

==== Expressions ====

{| class="wikitable"
|-
| Unary Expression (without argument)
| <code>receiver messageName</code>
|receiver is itself either a constant, a lambda-block, a unary expression or a parenthesized expression
|-
| Keyword Expression (1 arg)
| <code>receiver messageNamePart:argExpression</code>
|whitespace between the colon and the argExpression is optional.
|-
| Keyword Expression (any number of args)
| <code>receiver     messageNamePart1:argExpression1     messageNamePart2:argExpression2     ...     messageNamePartN:argExpressionN</code>
|-
| Binary Expression
| <code>receiver binOP arg</code>
|with binOP being any combination of special characters: * , + , - , % , & , / , \ , | , = , < , > , ? and ,
 I.e. "<code>foo ==> 123</code>" is the binary message "<code>==></code>" sent to <code>foo</code> with <code>123</code> as argument.
 And "<code>foo ? 123</code>" is the binary message "<code>?</code>" sent to <code>foo</code> with <code>123</code> as argument.
|-
| Cascade Expression (multiple messages to the same receiver)
| <code>receiver     message1 ;     message2 ;     ...     messageN</code></td>
|the receiver expression is evaluated, then multiple messages (separated by ";") are sent to this receiver.
|-
| Parentheses for grouping
| <code>( any expression )</code>
|-
| Assignment
| <code>variable := expression</code>
|can be used as expression.
|-
| Computed Array (Brace Construct) (*)
| <code>{ expr1 . expr2 . ... . exprN }</code>
|instantiates a new Array object with elements from the expressions.
|-
| Computed Inline Object (*)
| <code>{ foo: fooExpr . bar: barExpr }</code>
|fooExpr and barExpr: expressions
|-
| Inline string expressions (*)
| <code>e'p1{e1}p2{e2}...pN{eN}pM'</code>
|syntactic sugar for: <code>('p1%1p2%2...pN%NpM' bindWith:e1 with:e2 ... with:eN)</code> where each pI is a string with possible C-escapes and each eI is a Smalltalk expression
|-
| Array Indexing (*)
| <code>coll[idx]</code> <code>coll[idx1][idx2]</code> <code>coll[idx1][idx2][idx3]</code>
|syntactic sugar for: <code>(coll at:idx)</code> where coll must be an indexable collection, and idx of compatible index type. I.e. integer for array-like collections, hash-key for dictionaries, etc. Up to 4 dimensions are (currently supported)
|-
| Collection instantiation (*)
| <code>someClass[sz]</code> <code>someClass[sz][sz]</code> ...
|syntactic sugar for: <code>(someClass new:sz)</code> where someClass must be a collection class I.e. Array[10] creates an empty array with 10 slots. 1, 2, 3 and 4 dimensions are supported
|-

|}

==== Remaining Syntax ====

{| class="wikitable"
|-
| Local variables (in block or method)
| <code>| var1 var2 ... varN |</code>
|variable declarations must be at the beginning, before any expression.
|-
| Separating multiple expressions (sequence)
| <code>expr1 . expr2 . ... exprN</code>
|expressions (statements) are separated by fullstop (period) characters. The last expression may or may not be followed by a fullstop; if there is one, this is treated like a followup empty statement.
|-
| Return from method
| <code>^ expression</code>
|returns from the enclosing method (also if inside a block-closure)
|}

==== Wellknown (Common) Messages ====

{| class="wikitable"
|-
| Conditional Execution
| <code>boolExpr1 ifTrue:[ ... ] ifFalse:[ ... ]</code>
|variations without true-part, without false part and with the order reversed are available.
|-
| While-Loop (test at top)
| <code>[ boolExpr1 ] whileTrue:[ ... ]</code>
|notice the receiver being a block. A <code>whileFalse:</code> variant is also available.
|-
| Do-Loop (test at bottom)
| <code>[ ... ] doWhile:[ boolExpr1 ]</code>
|notice the test being a block. A <code>doUntil:</code> variant is also available.
|-
| For-Loop
| <code>start to:stop do:[:iterVar | ... ]</code>
|evaluates the block (lambda) for each value in start..stop.
|-
| Enumerating Collections
| <code>collection do:[:elementVar | ... ]</code>
|evaluates the block (i.e. lambda) for each element in the collection.
|-
| Evaluating a Lambda Block   without arguments:
  with arguments:
| <code>aBlock value</code><code>aBlock value:expr1 ... value:exprN</code>
|the number of arguments must match the number expected by the lambda (although varArg lambdas are also available)
|-
| Exception Handling
| <code>[ ... ] on:Error do:[:ex | ... ]</code>
|evaluates the first block; if an error is encountered, evaluate the handler
|}

==== Special 'Control Structures' ====

{| class="wikitable"
|-
| Starting another Thread
| <code>p := [ ... ] fork</code>
|the code inside the block will execute in a separate thread
|-
| Creating, configuring and starting another Thread
| <code>p := [ ... ]   newProcess;   name:'my worker';   priority:5;   resume</code>
|the code inside the block will execute in a separate thread
|-
| Terminating a Thread
| <code>p terminate</code>
|with p referring to the thread as created by newProcess or fork
|-
| Interrupting a Thread
| <code>p interruptWith:[ ... ]</code>
|interrupt the thread and let it execute the given code (in its interrupt seervice)
|-
| Exception Handling
| <code>[ ... ]   on:Error do:[:ex |     ...   ]</code>
|the handler will get an exception argument (ex), which contains additional information, and can be told how to deal with the error
|-
| Exception Handling - proceeding
| <code>[ ... ]   on:Error do:[:ex |     ...     ex proceed   ]</code>
|proceed, as if the error did not happen
|-
| Exception Handling - restarting
| <code>[ ... ]   on:Error do:[:ex |     ...     ex restart   ]</code>
|restart the code from the beginning (usually after the handler did some cleanup, such as lazy loading a missing file...)
|-
| Exception Handling - printing
| <code>[ ... ]   on:Error do:[:ex |     ...     ex description     ...   ]</code>
|contains a human readable description of the error
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ensure:[   ...   ]</code>
|the ensure block will be evaluated in any case
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ifCurtailed:[   ...   ]</code>
|the ifCurtailed block will be evaluated only on a non-regular exit (i.e. when an exception was raised, or the operation was aborted or the thread terminated)
|-
| Early exit from Loops
| <code>[:exit |   ...   code with loop   ...   exit value   ... ] valueWithExit</code>
|the block will be left, when exit is evaluated. Often used as argument of ifTrue:, as in cond ifTrue: exit
|-
| Queries
| <code>Query   answer:something   do:[     ...     Query query     ...   ]</code>
|to provide answers way down to whoever is interested. Queries answer nil if no one is there to answer. Queries are usually more specifically used as subclasses of Query
|-
| Notifications
| <code>Notification   handle:[     ...   ]   do:[     ...     Notification notify:someArg     ...   ]</code>
|to provide information way up to whoever is interested Notifications are usually more specifically used as subclasses of Notification
|-
| Observers 1
| <code>foo onChange:#bla evaluate:[...]. ... foo changed:#bla</code>
|observer with generic block to evaluate
|-
| Observers 2
| <code>foo onChangeSend:#xyz to:someone. ... foo changed</code>
|observer with message send
|-
| Observers 3
| <code>foo addDependent:someone. ... foo changed</code>
|observer with send to update method of target
|}

Queries and Notifications can be seen as observers within the calling hierarchy (i.e. information flows up or down the calling hierarchy), whereas the dependency and anChange mechanisms are independent of the control flow (even between different threads)

==== Synchronization and Timers ====
{| class="wikitable"
|-
| Timed Delay
| <code>Delay waitForSeconds:n</code> <code>Delay waitUntil:(Timestamp now + 10 seconds)</code>
|self explaining
|-
| Sempaphore wait
| <code>s := Semaphore new. ... s wait. ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Sempaphore wait with timeout
| <code>s := Semaphore new. ... s waitWithTimeout:(5 seconds). ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Multi Sempaphore wait
| <code>s1 := Semaphore new. s2 := Semaphore new. ... which := (s1 , s2) wait. ... s2 signal</code>
|wait for any of multiple semaphores
|-
| Synchronized Collections
| <code>a := OrderedCollection new asSharedCollection</code>
|will wrap the collection so that add/remove operations are atomic
|}

==== Wellknown Globals ====

{| class="wikitable"
|-
| Logging and Messaging
| <code>Transcript</code> - the console window <code>Stdout</code> - standard output <code>Stderr</code> - standard error <code>Stdin</code> - standard input <code>Logger</code> - redefinable logger (defaults to standard error)
|-
| Common Useful Dialogs
| <code>Dialog</code> - provides many useful utility functions for standard dialogs eg.<code> Dialog warn:'message' Dialog confirm:'question' Dialog request:'question' Dialog requestFilename:'question' ...</code>
|}

==== Most Wellknown Classes ====

{| class="wikitable"
|-
| Numbers
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Number Number]</code>(abstract superclass) <code>[http://live.exept.de/ClassDoc/classDocOf:,Integer Integer]</code>(integral numbers) <code>[http://live.exept.de/ClassDoc/classDocOf:,Float Float]</code>(inexact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Fraction Fraction]</code>(exact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Complex Complex]</code>
|-
| Collections
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Array Array]</code> (fixed size array) <code>[http://live.exept.de/ClassDoc/classDocOf:,OrderedCollection OrderedCollection]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,List List]</code> (variable size) <code>[http://live.exept.de/ClassDoc/classDocOf:,SortedCollection SortedCollection]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Set Set]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Bag Bag]</code> (unordered) <code>[http://live.exept.de/ClassDoc/classDocOf:,Dictionary Dictionary]</code> (mapped collections) <code>[http://live.exept.de/ClassDoc/classDocOf:,BinaryTree BinaryTree]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,AVLTree AVLTree]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,SharedQueue SharedQueue]</code> (shared, synchronized) many more...
|-
| Process Handling
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Process Process]</code> (lightweight thread) <code>[http://live.exept.de/ClassDoc/classDocOf:,OSProcess OSProcess]</code> (heavyweight OS process) <code>[http://live.exept.de/ClassDoc/classDocOf:,Semaphore Semaphore]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,RecursionLock RecursionLock]</code> (synchronization) <code>[http://live.exept.de/ClassDoc/classDocOf:,Monitor Monitor]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,BoltLock BoltLock]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Delay Delay]</code> (time delays)
|-
| Files & Streams
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Filename Filename]</code> (file naming, directory access, mime type) <code>[http://live.exept.de/ClassDoc/classDocOf:,Stream Stream]</code> (basic stream framework)
 <code>[http://live.exept.de/ClassDoc/classDocOf:,ReadStream ReadStream]</code>,<code>WriteStream</code>,<code>[http://live.exept.de/ClassDoc/classDocOf:,EncodedStream EncodedStream]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,ExternalStream ExternalStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,FileStream FileStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Socket Socket]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,PipeStream PipeStream]</code> (OS-cmd streams)
|-
| Low Level Access
| <code>[http://live.exept.de/ClassDoc/classDocOf:,OperatingSystem OperatingSystem]</code> (OS API calls) <code>[http://live.exept.de/ClassDoc/classDocOf:,Smalltalk Smalltalk]</code>(startup, shutdown and globals) <code>[http://live.exept.de/ClassDoc/classDocOf:,ObjectMemory ObjectMemory]</code>(VM access)
|}

== Examples ==

exampleMethod1
|v1 v2|

v1 := 42.
v2 := v1 sqrt.
Transcript showCR: 'the root of the answer to all questions is: %1' with: v2.

using expanded strings, this can be written as:

exampleMethod1_alternative
|v1|

v1 := 42.
Transcript showCR: e'the root of the answer to all questions is: {v1 sqrt}'.

enumerating elements of an array:

exampleMethod2
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr do:[:el |
Transcript showCR: el
]

enumerating elements of an array with additional index:

exampleMethod3
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr doWithIndex:[:el :idx |
Transcript showCR: e'array element at {idx} is {el} and its class is {el class name}\n'
]

dialogs, string-to-number conversion, error handling:

exampleMethod4
|s1 nr1 s2 nr2 rslt|

s1 := Dialog request:'Enter the first number' initialAnswer:1.
s1 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method
s2 := Dialog request:'Enter the second number' initialAnswer:2.
s2 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr1 := Number readFrom:s1 onError:[^ self].
nr2 := Number readFrom:s2 onError:[^ self].

"/ save division
[
rslt := nr1 / nr2
] on: Error do:[:ex |
(Dialog confirm: e'Error encountered: {ex description}\nProceed with zero?')
ifFalse:[^ self]. "/ no; return from method
ex proceedWith:0
].

Dialog information: e'the result is {rslt}'

dialogs, error handling and complex square root:

exampleMethod4
|s nr rslt|

s := Dialog request:'Enter a number (may be negative)' initialAnswer:2.
s isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr := Number readFrom:s onError:[^ self].

"/ square root; catch imaginary result
[
rslt := nr sqrt
] on: ImaginaryResultError do:[:ex |
(Dialog confirm: e'No solution in R; want to see the complex result?')
ifFalse:[^ self]. "/ no; return from method
rslt := Number trapImaginary:[ nr sqrt ].
"/ rslt is now a complex number
].

Dialog information: e'the result is {rslt}'

== Standard ==
The ANSI Smalltalk standard was approved on May 19, 1998. The official name of the document is ANSI INCITS 319-1998 (R2002). You can order a copy of the final standard
from here: [http://www.techstreet.com/cgi-bin/detail?product_id=56122]
or here [http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI+INCITS+319%2D1998+%28R2002%29]. The name of the document is "American National Standard for Information Systems - Programming Languages - Smalltalk".

You can also download the final draft revision for free: standard_v1_9-indexed.pdf and at [https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf].

The final draft is identical to the official standard except that the draft also has a rationale included (and thus, the draft is arguably more useful than the official standard).

Protocol from ANSI Meeting: [http://www.netjam.org/smalltalk/faq/ANSI-meeting.html]

== Common Language Extensions ==
These are also found in other Smalltalk dialects (eg. [[Glossary#VW|VW]] or [[Glossary#Squeak|Squeak]])

* { expr1 . expr2 . ... } Brace Array Construction Each expression is evaluated (left to right), and an Array with the results is created at execution time. Notice that separating full stops are required, as opposed to constant literal arrays, where elements are separated by spaces. The generated Array is mutable (can be modified), whereas a constant array is not.

== Summary of Smalltalk/X Language Extensions ==

These are ST/X specific, and not (as of 2026) implemented in other Smalltalk systems.

=== Comments ===
* "/ End of line comment
* "<<X ... X token delimited comment; X can be any word and a line starting with X ends the comment

=== String Literals ===
* c'...' ''c-strings'' C-like escapes (\n, \t, \xNN, \uNNNN) inside the string are expanded.

* e' ... {expr} ...' ''e-strings'' (expanded epression strings) In addition to C-escapes, embedded expressions are evaluated and their printString is sliced in. Technically, it is converted to ' ... %1 ...' and then expanded using standard String methods.

* i' ... {expr} ...' ''i-strings'' (international strings) similar to e-strings, but the converted string ('... %1 ...') is translated to a national string (via the *.rs file) and then expanded. Allows for different word ordering.

=== Integer Literals ===
* 0xNNNN, 0oNNNN, 0bNNNN C-style hex, octal and binary integers. With arbitrary precision

=== Float Literals ===
* <f>q, <f>Q, etc. Float literal type suffix (q, Q, QD, QL, QO) For a complete list and spec., see the Number documentation.

=== Compact Number Arrays ===
* #u1, #u8, #u16, #u32, #u64 #i8, #i16, #i32, #i64 #f16, #bf16, #f32, #f64 Will generate dense packed vectors (similar to byteArray); format is #X(n1 n2 ... )

Smalltalk Syntax Cheat Sheet

2026-06-07T07:10:46Z

Cg: /* Smalltalk Philosophy */

A short, one page summary of what beginners need to know about Smalltalk/X, its syntax and most useful code fragments. As usual, this is only a tiny fraction of what is really awailable, and you should use the builtin class browser to find many more useful functions in the system.

This page was extracted from the "Smalltalk/X Programmers guide - Smalltalk/X Cheat Sheet".
 Smalltalk/X language extensions (w.r.t. other Smalltalk implementations) are marked with '''(*)'''.

== Smalltalk Philosophy ==

* Everything is an '''Object''' this includes the most basic ''things'' like numbers, strings and characters, up to complex objects like windows, editors, compilers, applications etc.

* The world consists of objects which '''communicate by sending messages'''. (in other languages this is also known as ''virtual function call'', but this term is not used in Smalltalk)

* A message looks like an english sentence, and might look like "<code>heyYou doSomething</code>". In this example, the "heyYou" is called the "''receiver of the message''" and "doSomething" is called the "''message selector''"
: You may pass additional parameter objects (arguments) as in: "<code>heyYou doSomethingWith:arg</code>" or multiple arguments as in "<code>heyYou doSomethingWith:arg1 and:arg2</code>".
: In these examples, the selectors are "doSomethingWith:" and "doSomethingWith:and:" respectively (i.e. the concatenation of the so called ''keywords''). They are two different messages with different selectors. In contrast to most other languages, this is '''not''' the same message with different number of arguments, but two completely different messages).

* Messages without argument are called "''unary messages''"; those with arguments are called "''keyword messages''"
: For example "<code>Transcript clear</code>" sends the message "clear" to the Transcript object; a unary message,
: and "<code>Transcript show:'hello'</code>" sends the message "show:" to the Transcript, passing a string argument; a keyword message

* To allow for arithmetic operations, any non-letter character (except for a few) are treated like a message name and written between the receiver and the one and only argument. These are called "''binary messages''".
: For example: <code>"3+4"</code> or <code>"abc,def"</code> (yes, the comma is an operator; it does string concatenation). You can place whitespace anywhere between selectors, keywords and arguemnts (eg. <code>"3 + 4"</code> and <code>"3+4"</code> are the same).

* An object may respond (or "''answer''") by returning a result object. In the above example, "<code>3+4</code>" would answer "7", and "<code>'hello' , 'world'</code>" would answer 'helloworld'

* binary messages have no meaning to the compiler; they all have equal precedence and are evaluated from left to right.
: Admitted, this makes arithmetic a little strange initially; you'll need parentheses as there is not precedence of eg. * over +. The expression "3 + 4 * 5" will be evaluated left to right and answer 35.

* Everything in this world is an object; from low level things like booleans, true, false, integer numbers, floating point numbers characters etc. to the most complex objects.
: Objects can refer to (i.e. hold references) to other objects. Technically, all such references are via pointers. There is no way to directly embed an object into another object, except by reference.

* Every object is associated to a class. Classes define the behavior of their instances. I.e. they define how they respond to messages. The response is implemented by a so called ''method''. That is a piece of code which is executed when a message comes in. A method consist of a number of statements (which are mostly message sends), each separated by a full stop (as in english).
: Inside a method, the receiver object (the object which got the message and is now executing the method) is called the ''receiver'' and refered to by the reserved word "<code>self</code>".

* Classes are themself objects, which respond to messages. Typically class messages would answer new instances, constants or implement utility functionality. There are also class messages to create new classes.

* Class can inherit common functionality (i.e. method implementations) from a superclass. Thus creating a hierarchy of classes. Typical hierarchies are the Number hierarchy, Collections, Streams and UI Widgets.
: Inside a method, the special reserved word "<code>super</code>" also refers to the current receiver, but message sends will ignore any method implemented in the methods class, but instead look for inherited (superclass) methods.

* In Smalltalk, every behavior is defined by corresponding message implementations. This includes control features (i.e. if-then-else, loops and exception handling). All of them are implemented as messages being sent to booleans (<code>ifTrue:</code>/<code>ifFalse:</code>) or blocks (<code>whileTrue:</code>)

* Blocks are objects, which wrap a piece of code. Other languages know them as ''anonymous functions'', ''lambdas'' or ''closures''.<
: But the Smalltalk syntax makes them super easy to use: just write a number of expressions inside square brackets, as in:"<code>[ Transcript show: 10 factorial ]</code>".
: Blocks are real objects - they can be passed as argument in a message send; for example to a boolean: "<code>aBoolean ifTrue: [ Transcript show: 'yes' ]</code>"
: they can be stored in variables and passed around just like any other object
: blocks can receive messages, especially loop messages: "<code>[ a < 10] whileTrue:[ Transcript showCR: a. a := a + 1 ]</code>",
: and they can be returned from a method (''answer from a message'') .

== Syntax ==

==== Comments ====

{| class="wikitable"
|-
| Regular comment
| <code>" this is a comment "</code>
| ''any text between double quotes''
|-
| EOL-Comment (*)
| <code>"/ this is an End-of-Line comment</code>
| ''text from quote-slash to line end''
|-
| Token-Comment (*)
| <code>"<<END a multiline token-comment up to a line starting with 'END' more commented stuff here ... comment ends here END</code>
| ''text up to line beginning with whatever token came after the initial "<<" ''
|}

==== Literal Constants ====

===== Numbers =====

{| class="wikitable"
|-
| Integers</td>
| <code>12345</code> </code>-12345<code>
|
|-
| Large integers
| <code>1234567890123456789012345</code>…
| ''arbitrary number of digits''
|-
| Integers with radix (Smalltalk style)
| <code>16rAFFE</code>, <code>2r010101</code>, <code>8r0777</code>, <code>3r012012</code>, <code>16r-AFFE</code>, <code>2r-010101</code>
| ''prepend the radix (base) any radix from 2..36 is possible (i.e. 3r222 is a ternary number)''
|-
| Integers with radix (C style) (*)
| <code>0xFEED</code> <code>-0xBEAF</code> <code>0b11011</code>,<code>-0b1100</code>
| ''C/Java/JavaScript style: prepend radix indicator ('x', 'b', 'o') One of hex, binary and octal''
|-
| Floats (IEEE double; roughly 17 digits)
| 12.456 1.234e17 -6.9 -6e-10 Float pi Float e
| ''called "Float", but actually hold double precision Common constants can be referred to "by name".''
|-
| Short floats (IEEE single; roughly 8 digits) (*)
| <code>1.234e17f</code> <code>-6e-10f</code>
| <strike>''this is controlled by a ParserFlag (singlePrecisionFloatF), which is currently defaulted to false. Thus, by default, double precision floats are created with the 'f' exponent character.''</strike>
|-
| Long floats (IEEE extended; roughly 20 digits) (*)
| <code>1.234e17q</code> <code>-6q-10q</code>
| ''actual precision depends on the underlying CPU (x86/x86_64: 80bit; Sparc: 128 bit)
|-
| Quad floats; (IEEE quad; roughly 34 digits (*)
| <code>1.234e17Q</code> <code>-6e-10Q</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Octuple floats; roughly 60 digits (*)
| <code>1.234e17QO</code> <code>-6e-10QP</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Large floats; roughly 60 digits by default, but any precision possible (*)
| <code>1.234e17QL</code> <code>-6e-10QL</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Fractions
| <code>(1/3)</code> <code>(17/2)</code> (-3/2)
|
|-
| ScaledDecimals
| <code>1234.53s2</code>
| ''the number after the s specifies the number of digits''
|-
| Complex
| <code>(1.5 + 3i)</code> <code>2i</code> <code>(3.0q + 5.0qi</code>)
|}

===== Characters and Strings =====

{| class="wikitable"
|-
| Characters
| <code>$a</code> <code>Character space</code> <code>Character nl</code> Also: "<code>null</code>", "<code>tab</code>", "<code>return</code>", "<code>bell</code>"... Or: <code>Character codePoint:n</code>
| ''Smalltalk does not support any escape sequence Common constants can be referred to "by name".''
|-
| Strings
| <code>'hello'</code>
| ''traditionally, Smalltalk does not support any escape sequence inside (i.e. they are what Python calls "Raw Strings") But see below...''
|-
| Strings (C Style) (*)
| <code>c'hello\nworld'</code>
| ''supports the common C-escape sequences, such as "\n", "\t", "\xHH", "\uXXXX"''
|-
| Strings (with embedded expressios) (*)
| <code>e'hello {OperatingSystem getLoginName}'</code>
| ''expanded expression strings expressions in braces are evaluated at runtime and sliced into the string (also a C-string). Similar to python's f-strings.''
|-
| Strings (national language translated with embedded expressios) (*)
| <code>i'hello {OperatingSystem getLoginName}'</code>
| ''international strings like above, but the string is also possibly translated to a national language''
|-
| Symbols
| <code>#'hello'</code> <code>#foo</code> <code>#+</code>
| ''symbols are interned strings; two symbols with the same characters are guaranteed to be the identical object (not just equal) without quotes, if only alphaNumeric characters''
|}

===== Arrays and Objects =====
{| class="wikitable"
|-
| Arrays 
| <code>#( el1 el2 ... elN )</code>
| each element is a literal constant
|-
| Byte Arrays
| <code>#[ b1 b2 ... bN ]</code>
| each byte-element an integer constant in 0..255
|-
| Special Number Arrays (*)
| <code>#XX( v1 v2 ... vN )</code>
| XX: is one of  'u8', 's8', 'u16', 's16', 'u32', 's32', 'u64', 's64', 'f32', 'f64'  and each element being an integer or float constant
|-
| Immediate Inline Objects (*)
| <code>#{ foo: fooValue . bar: barValue }</code>
| fooValue and barValue: are constants
|}

==== Lambda Blocks (Closures) ====

{| class="wikitable"
|-
| Without argument
| <code>[ expr1 . expr2 ... exprN ]</code>
| multiple expressions sep'd by period. When evaluated, the value is the value from the last expression, exprN
|-
| One argument
| <code>[ :arg |     expr1 . expr2 ... exprN ]</code>
|-
| Multiple arguments
| <code>[ :a1 :a2 ... :aN |     expr1 . expr2 ... exprN ]</code>
|-
| Local Variables inside a block
| <code>[ :a1 ... :aN |      |local1 local2 |      expr1 ... exprN ]</code>
|}

==== Expressions ====

{| class="wikitable"
|-
| Unary Expression (without argument)
| <code>receiver messageName</code>
|receiver is itself either a constant, a lambda-block, a unary expression or a parenthesized expression
|-
| Keyword Expression (1 arg)
| <code>receiver messageNamePart:argExpression</code>
|whitespace between the colon and the argExpression is optional.
|-
| Keyword Expression (any number of args)
| <code>receiver     messageNamePart1:argExpression1     messageNamePart2:argExpression2     ...     messageNamePartN:argExpressionN</code>
|-
| Binary Expression
| <code>receiver binOP arg</code>
|with binOP being any combination of special characters: * , + , - , % , & , / , \ , | , = , < , > , ? and ,
 I.e. "<code>foo ==> 123</code>" is the binary message "<code>==></code>" sent to <code>foo</code> with <code>123</code> as argument.
 And "<code>foo ? 123</code>" is the binary message "<code>?</code>" sent to <code>foo</code> with <code>123</code> as argument.
|-
| Cascade Expression (multiple messages to the same receiver)
| <code>receiver     message1 ;     message2 ;     ...     messageN</code></td>
|the receiver expression is evaluated, then multiple messages (separated by ";") are sent to this receiver.
|-
| Parentheses for grouping
| <code>( any expression )</code>
|-
| Assignment
| <code>variable := expression</code>
|can be used as expression.
|-
| Computed Array (Brace Construct) (*)
| <code>{ expr1 . expr2 . ... . exprN }</code>
|instantiates a new Array object with elements from the expressions.
|-
| Computed Inline Object (*)
| <code>{ foo: fooExpr . bar: barExpr }</code>
|fooExpr and barExpr: expressions
|-
| Inline string expressions (*)
| <code>e'p1{e1}p2{e2}...pN{eN}pM'</code>
|syntactic sugar for: <code>('p1%1p2%2...pN%NpM' bindWith:e1 with:e2 ... with:eN)</code> where each pI is a string with possible C-escapes and each eI is a Smalltalk expression
|-
| Array Indexing (*)
| <code>coll[idx]</code> <code>coll[idx1][idx2]</code> <code>coll[idx1][idx2][idx3]</code>
|syntactic sugar for: <code>(coll at:idx)</code> where coll must be an indexable collection, and idx of compatible index type. I.e. integer for array-like collections, hash-key for dictionaries, etc. Up to 4 dimensions are (currently supported)
|-
| Collection instantiation (*)
| <code>someClass[sz]</code> <code>someClass[sz][sz]</code> ...
|syntactic sugar for: <code>(someClass new:sz)</code> where someClass must be a collection class I.e. Array[10] creates an empty array with 10 slots. 1, 2, 3 and 4 dimensions are supported
|-

|}

==== Remaining Syntax ====

{| class="wikitable"
|-
| Local variables (in block or method)
| <code>| var1 var2 ... varN |</code>
|variable declarations must be at the beginning, before any expression.
|-
| Separating multiple expressions (sequence)
| <code>expr1 . expr2 . ... exprN</code>
|expressions (statements) are separated by fullstop (period) characters. The last expression may or may not be followed by a fullstop; if there is one, this is treated like a followup empty statement.
|-
| Return from method
| <code>^ expression</code>
|returns from the enclosing method (also if inside a block-closure)
|}

==== Wellknown (Common) Messages ====

{| class="wikitable"
|-
| Conditional Execution
| <code>boolExpr1 ifTrue:[ ... ] ifFalse:[ ... ]</code>
|variations without true-part, without false part and with the order reversed are available.
|-
| While-Loop (test at top)
| <code>[ boolExpr1 ] whileTrue:[ ... ]</code>
|notice the receiver being a block. A <code>whileFalse:</code> variant is also available.
|-
| Do-Loop (test at bottom)
| <code>[ ... ] doWhile:[ boolExpr1 ]</code>
|notice the test being a block. A <code>doUntil:</code> variant is also available.
|-
| For-Loop
| <code>start to:stop do:[:iterVar | ... ]</code>
|evaluates the block (lambda) for each value in start..stop.
|-
| Enumerating Collections
| <code>collection do:[:elementVar | ... ]</code>
|evaluates the block (i.e. lambda) for each element in the collection.
|-
| Evaluating a Lambda Block   without arguments:
  with arguments:
| <code>aBlock value</code><code>aBlock value:expr1 ... value:exprN</code>
|the number of arguments must match the number expected by the lambda (although varArg lambdas are also available)
|-
| Exception Handling
| <code>[ ... ] on:Error do:[:ex | ... ]</code>
|evaluates the first block; if an error is encountered, evaluate the handler
|}

==== Special 'Control Structures' ====

{| class="wikitable"
|-
| Starting another Thread
| <code>p := [ ... ] fork</code>
|the code inside the block will execute in a separate thread
|-
| Creating, configuring and starting another Thread
| <code>p := [ ... ]   newProcess;   name:'my worker';   priority:5;   resume</code>
|the code inside the block will execute in a separate thread
|-
| Terminating a Thread
| <code>p terminate</code>
|with p referring to the thread as created by newProcess or fork
|-
| Interrupting a Thread
| <code>p interruptWith:[ ... ]</code>
|interrupt the thread and let it execute the given code (in its interrupt seervice)
|-
| Exception Handling
| <code>[ ... ]   on:Error do:[:ex |     ...   ]</code>
|the handler will get an exception argument (ex), which contains additional information, and can be told how to deal with the error
|-
| Exception Handling - proceeding
| <code>[ ... ]   on:Error do:[:ex |     ...     ex proceed   ]</code>
|proceed, as if the error did not happen
|-
| Exception Handling - restarting
| <code>[ ... ]   on:Error do:[:ex |     ...     ex restart   ]</code>
|restart the code from the beginning (usually after the handler did some cleanup, such as lazy loading a missing file...)
|-
| Exception Handling - printing
| <code>[ ... ]   on:Error do:[:ex |     ...     ex description     ...   ]</code>
|contains a human readable description of the error
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ensure:[   ...   ]</code>
|the ensure block will be evaluated in any case
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ifCurtailed:[   ...   ]</code>
|the ifCurtailed block will be evaluated only on a non-regular exit (i.e. when an exception was raised, or the operation was aborted or the thread terminated)
|-
| Early exit from Loops
| <code>[:exit |   ...   code with loop   ...   exit value   ... ] valueWithExit</code>
|the block will be left, when exit is evaluated. Often used as argument of ifTrue:, as in cond ifTrue: exit
|-
| Queries
| <code>Query   answer:something   do:[     ...     Query query     ...   ]</code>
|to provide answers way down to whoever is interested. Queries answer nil if no one is there to answer. Queries are usually more specifically used as subclasses of Query
|-
| Notifications
| <code>Notification   handle:[     ...   ]   do:[     ...     Notification notify:someArg     ...   ]</code>
|to provide information way up to whoever is interested Notifications are usually more specifically used as subclasses of Notification
|-
| Observers 1
| <code>foo onChange:#bla evaluate:[...]. ... foo changed:#bla</code>
|observer with generic block to evaluate
|-
| Observers 2
| <code>foo onChangeSend:#xyz to:someone. ... foo changed</code>
|observer with message send
|-
| Observers 3
| <code>foo addDependent:someone. ... foo changed</code>
|observer with send to update method of target
|}

Queries and Notifications can be seen as observers within the calling hierarchy (i.e. information flows up or down the calling hierarchy), whereas the dependency and anChange mechanisms are independent of the control flow (even between different threads)

==== Synchronization and Timers ====
{| class="wikitable"
|-
| Timed Delay
| <code>Delay waitForSeconds:n</code> <code>Delay waitUntil:(Timestamp now + 10 seconds)</code>
|self explaining
|-
| Sempaphore wait
| <code>s := Semaphore new. ... s wait. ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Sempaphore wait with timeout
| <code>s := Semaphore new. ... s waitWithTimeout:(5 seconds). ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Multi Sempaphore wait
| <code>s1 := Semaphore new. s2 := Semaphore new. ... which := (s1 , s2) wait. ... s2 signal</code>
|wait for any of multiple semaphores
|-
| Synchronized Collections
| <code>a := OrderedCollection new asSharedCollection</code>
|will wrap the collection so that add/remove operations are atomic
|}

==== Wellknown Globals ====

{| class="wikitable"
|-
| Logging and Messaging
| <code>Transcript</code> - the console window <code>Stdout</code> - standard output <code>Stderr</code> - standard error <code>Stdin</code> - standard input <code>Logger</code> - redefinable logger (defaults to standard error)
|-
| Common Useful Dialogs
| <code>Dialog</code> - provides many useful utility functions for standard dialogs eg.<code> Dialog warn:'message' Dialog confirm:'question' Dialog request:'question' Dialog requestFilename:'question' ...</code>
|}

==== Most Wellknown Classes ====

{| class="wikitable"
|-
| Numbers
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Number Number]</code>(abstract superclass) <code>[http://live.exept.de/ClassDoc/classDocOf:,Integer Integer]</code>(integral numbers) <code>[http://live.exept.de/ClassDoc/classDocOf:,Float Float]</code>(inexact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Fraction Fraction]</code>(exact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Complex Complex]</code>
|-
| Collections
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Array Array]</code> (fixed size array) <code>[http://live.exept.de/ClassDoc/classDocOf:,OrderedCollection OrderedCollection]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,List List]</code> (variable size) <code>[http://live.exept.de/ClassDoc/classDocOf:,SortedCollection SortedCollection]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Set Set]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Bag Bag]</code> (unordered) <code>[http://live.exept.de/ClassDoc/classDocOf:,Dictionary Dictionary]</code> (mapped collections) <code>[http://live.exept.de/ClassDoc/classDocOf:,BinaryTree BinaryTree]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,AVLTree AVLTree]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,SharedQueue SharedQueue]</code> (shared, synchronized) many more...
|-
| Process Handling
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Process Process]</code> (lightweight thread) <code>[http://live.exept.de/ClassDoc/classDocOf:,OSProcess OSProcess]</code> (heavyweight OS process) <code>[http://live.exept.de/ClassDoc/classDocOf:,Semaphore Semaphore]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,RecursionLock RecursionLock]</code> (synchronization) <code>[http://live.exept.de/ClassDoc/classDocOf:,Monitor Monitor]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,BoltLock BoltLock]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Delay Delay]</code> (time delays)
|-
| Files & Streams
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Filename Filename]</code> (file naming, directory access, mime type) <code>[http://live.exept.de/ClassDoc/classDocOf:,Stream Stream]</code> (basic stream framework)
 <code>[http://live.exept.de/ClassDoc/classDocOf:,ReadStream ReadStream]</code>,<code>WriteStream</code>,<code>[http://live.exept.de/ClassDoc/classDocOf:,EncodedStream EncodedStream]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,ExternalStream ExternalStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,FileStream FileStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Socket Socket]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,PipeStream PipeStream]</code> (OS-cmd streams)
|-
| Low Level Access
| <code>[http://live.exept.de/ClassDoc/classDocOf:,OperatingSystem OperatingSystem]</code> (OS API calls) <code>[http://live.exept.de/ClassDoc/classDocOf:,Smalltalk Smalltalk]</code>(startup, shutdown and globals) <code>[http://live.exept.de/ClassDoc/classDocOf:,ObjectMemory ObjectMemory]</code>(VM access)
|}

== Examples ==

exampleMethod1
|v1 v2|

v1 := 42.
v2 := v1 sqrt.
Transcript showCR: 'the root of the answer to all questions is: %1' with: v2.

using expanded strings, this can be written as:

exampleMethod1_alternative
|v1|

v1 := 42.
Transcript showCR: e'the root of the answer to all questions is: {v1 sqrt}'.

enumerating elements of an array:

exampleMethod2
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr do:[:el |
Transcript showCR: el
]

enumerating elements of an array with additional index:

exampleMethod3
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr doWithIndex:[:el :idx |
Transcript showCR: e'array element at {idx} is {el} and its class is {el class name}\n'
]

dialogs, string-to-number conversion, error handling:

exampleMethod4
|s1 nr1 s2 nr2 rslt|

s1 := Dialog request:'Enter the first number' initialAnswer:1.
s1 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method
s2 := Dialog request:'Enter the second number' initialAnswer:2.
s2 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr1 := Number readFrom:s1 onError:[^ self].
nr2 := Number readFrom:s2 onError:[^ self].

"/ save division
[
rslt := nr1 / nr2
] on: Error do:[:ex |
(Dialog confirm: e'Error encountered: {ex description}\nProceed with zero?')
ifFalse:[^ self]. "/ no; return from method
ex proceedWith:0
].

Dialog information: e'the result is {rslt}'

dialogs, error handling and complex square root:

exampleMethod4
|s nr rslt|

s := Dialog request:'Enter a number (may be negative)' initialAnswer:2.
s isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr := Number readFrom:s onError:[^ self].

"/ square root; catch imaginary result
[
rslt := nr sqrt
] on: ImaginaryResultError do:[:ex |
(Dialog confirm: e'No solution in R; want to see the complex result?')
ifFalse:[^ self]. "/ no; return from method
rslt := Number trapImaginary:[ nr sqrt ].
"/ rslt is now a complex number
].

Dialog information: e'the result is {rslt}'

== Standard ==
The ANSI Smalltalk standard was approved on May 19, 1998. The official name of the document is ANSI INCITS 319-1998 (R2002). You can order a copy of the final standard
from here: [http://www.techstreet.com/cgi-bin/detail?product_id=56122]
or here [http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI+INCITS+319%2D1998+%28R2002%29]. The name of the document is "American National Standard for Information Systems - Programming Languages - Smalltalk".

You can also download the final draft revision for free: standard_v1_9-indexed.pdf and at [https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf].

The final draft is identical to the official standard except that the draft also has a rationale included (and thus, the draft is arguably more useful than the official standard).

Protocol from ANSI Meeting: [http://www.netjam.org/smalltalk/faq/ANSI-meeting.html]

== Common Language Extensions ==
These are also found in other Smalltalk dialects (eg. [[Glossary#VW|VW]] or [[Glossary#Squeak|Squeak]])

* { expr1 . expr2 . ... } Brace Array Construction Each expression is evaluated (left to right), and an Array with the results is created at execution time. Notice that separating full stops are required, as opposed to constant literal arrays, where elements are separated by spaces. The generated Array is mutable (can be modified), whereas a constant array is not.

== Summary of Smalltalk/X Language Extensions ==

These are ST/X specific, and not (as of 2026) implemented in other Smalltalk systems.

=== Comments ===
* "/ End of line comment
* "<<X ... X token delimited comment; X can be any word and a line starting with X ends the comment

=== String Literals ===
* c'...' ''c-strings'' C-like escapes (\n, \t, \xNN, \uNNNN) inside the string are expanded.

* e' ... {expr} ...' ''e-strings'' (expanded epression strings) In addition to C-escapes, embedded expressions are evaluated and their printString is sliced in. Technically, it is converted to ' ... %1 ...' and then expanded using standard String methods.

* i' ... {expr} ...' ''i-strings'' (international strings) similar to e-strings, but the converted string ('... %1 ...') is translated to a national string (via the *.rs file) and then expanded. Allows for different word ordering.

=== Integer Literals ===
* 0xNNNN, 0oNNNN, 0bNNNN C-style hex, octal and binary integers. With arbitrary precision

=== Float Literals ===
* <f>q, <f>Q, etc. Float literal type suffix (q, Q, QD, QL, QO) For a complete list and spec., see the Number documentation.

=== Compact Number Arrays ===
* #u1, #u8, #u16, #u32, #u64 #i8, #i16, #i32, #i64 #f16, #bf16, #f32, #f64 Will generate dense packed vectors (similar to byteArray); format is #X(n1 n2 ... )

Smalltalk Syntax Cheat Sheet

2026-06-07T06:25:36Z

Cg: /* Numbers */

A short, one page summary of what beginners need to know about Smalltalk/X, its syntax and most useful code fragments. As usual, this is only a tiny fraction of what is really awailable, and you should use the builtin class browser to find many more useful functions in the system.

This page was extracted from the "Smalltalk/X Programmers guide - Smalltalk/X Cheat Sheet".
 Smalltalk/X language extensions (w.r.t. other Smalltalk implementations) are marked with '''(*)'''.

== Smalltalk Philosophy ==

* The world consists of objects which '''communicate by sending messages'''.
: A message looks like an english sentence, and might look like "<code>heyYou doSomething</code>".
: In this example, the "heyYou" is called the "''receiver of the message''"
: You may pass additional parameter objects (arguments) as in: "<code>heyYou doSomethingWith: arg</code>"
: or multiple arguments as in <code>"heyYou doSomethingWith: arg1 and: arg2"</code>
: In these examples, the "<code>heyYou</code>" is called the "''receiver of the message''"
* Messages without argument are called "''unary messages''"; those with arguments are called "''keyword messages''"
: For example "<code>Transcript clear</code>" (sends the message "clear" to the Transcript object),
: and "<code>Transcript show: 'hello'</code>" (sends the message "show:" to the Transcript, passing a string argument),
* To allow for arithmetic operations, any non-letter character (except for a few) are treated like a message name and written between the receiver and the one and only argument. These are called "''binary messages''".
: For example: <code>"3 + 4"</code> or <code>"abc , def"</code> (yes, the comma is an operator; it does string concatenation)
* The object my respond (or "answer") by returning some result object. In the above example, "<code>3+4</code>" would answer "7", and "<code>'hello' , 'world'</code>" would answer 'helloworld'
* binary messages have no meaning to the compiler; they are all equal and simply evaluated from left to right.
: admitted, this makes arithmetic a little strange initially; you'll need parentheses as the is not precidence of eg. * over +. The expression "3 + 4 * 5" will be evaluated left to right and answer 35.
* Everything in this world is an object;
: from low level things like booleans, true, false, integer numbers, floating point numbers characters etc.
: there are containers, which can hold on other objects. Technically, all such references are via pointers.
: there are also very complex objects and structures which implement windows, the user interface, communication interfaces, debuggers and even compilers which allow for code to be defined and installed on the fly.
* Every object is associated to a class. Classes define the behavior of their instances. I.e. they define how they respond to messages. The response is implemented by a so called ''method''. That is a piece of code which is executed when a message comes in. A method consist of a number of statements (which are message sends), each separated by a full stop (as in english).
* Classes are themself objects, which respond to messages. Typically class messages would answer new instances, constants or utility functionality. There are also class messages to create new classes.
* Class can inherit common functionality (i.e. method implementations) from a superclass. Thus creating a hierarchy of classes. Typical hierarchies are the Number hierarchy, Collections, Streams and UI Widgets.
* In Smalltalk, every behavior is defined by corresponding message implementations. This includes control features (i.e. if-then-else, loops and exception handling). All of them are implemented as messages being sent to booleans (ifTrue:/ifFalse:) or blocks (whileTrue:)
* Blocks are special objects, which wrap a piece of code. Other languages know them as anonymous functions or lambdas or closures. But the Smalltalk syntax makes them super easy to use: just write a number of expressions inside square brackets, as in "<code>[ Transcript show: 10 factorial ]</code>".
: blocks can be passed as argument with a message send; for example to a boolean: "<code>aBoolean ifTrue: [ Transcript show: 'yes' ]</code>"
: blocks can be stored in variables and passed arounf just like any other object
: blocks can receive messages, especially loop messages: "<code>[ a < 10] whileTrue:[ Transcript showCR: a. a := a + 1 ]</code>".

== Syntax ==

==== Comments ====

{| class="wikitable"
|-
| Regular comment
| <code>" this is a comment "</code>
| ''any text between double quotes''
|-
| EOL-Comment (*)
| <code>"/ this is an End-of-Line comment</code>
| ''text from quote-slash to line end''
|-
| Token-Comment (*)
| <code>"<<END a multiline token-comment up to a line starting with 'END' more commented stuff here ... comment ends here END</code>
| ''text up to line beginning with whatever token came after the initial "<<" ''
|}

==== Literal Constants ====

===== Numbers =====

{| class="wikitable"
|-
| Integers</td>
| <code>12345</code> </code>-12345<code>
|
|-
| Large integers
| <code>1234567890123456789012345</code>…
| ''arbitrary number of digits''
|-
| Integers with radix (Smalltalk style)
| <code>16rAFFE</code>, <code>2r010101</code>, <code>8r0777</code>, <code>3r012012</code>, <code>16r-AFFE</code>, <code>2r-010101</code>
| ''prepend the radix (base) any radix from 2..36 is possible (i.e. 3r222 is a ternary number)''
|-
| Integers with radix (C style) (*)
| <code>0xFEED</code> <code>-0xBEAF</code> <code>0b11011</code>,<code>-0b1100</code>
| ''C/Java/JavaScript style: prepend radix indicator ('x', 'b', 'o') One of hex, binary and octal''
|-
| Floats (IEEE double; roughly 17 digits)
| 12.456 1.234e17 -6.9 -6e-10 Float pi Float e
| ''called "Float", but actually hold double precision Common constants can be referred to "by name".''
|-
| Short floats (IEEE single; roughly 8 digits) (*)
| <code>1.234e17f</code> <code>-6e-10f</code>
| <strike>''this is controlled by a ParserFlag (singlePrecisionFloatF), which is currently defaulted to false. Thus, by default, double precision floats are created with the 'f' exponent character.''</strike>
|-
| Long floats (IEEE extended; roughly 20 digits) (*)
| <code>1.234e17q</code> <code>-6q-10q</code>
| ''actual precision depends on the underlying CPU (x86/x86_64: 80bit; Sparc: 128 bit)
|-
| Quad floats; (IEEE quad; roughly 34 digits (*)
| <code>1.234e17Q</code> <code>-6e-10Q</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Octuple floats; roughly 60 digits (*)
| <code>1.234e17QO</code> <code>-6e-10QP</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Large floats; roughly 60 digits by default, but any precision possible (*)
| <code>1.234e17QL</code> <code>-6e-10QL</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Fractions
| <code>(1/3)</code> <code>(17/2)</code> (-3/2)
|
|-
| ScaledDecimals
| <code>1234.53s2</code>
| ''the number after the s specifies the number of digits''
|-
| Complex
| <code>(1.5 + 3i)</code> <code>2i</code> <code>(3.0q + 5.0qi</code>)
|}

===== Characters and Strings =====

{| class="wikitable"
|-
| Characters
| <code>$a</code> <code>Character space</code> <code>Character nl</code> Also: "<code>null</code>", "<code>tab</code>", "<code>return</code>", "<code>bell</code>"... Or: <code>Character codePoint:n</code>
| ''Smalltalk does not support any escape sequence Common constants can be referred to "by name".''
|-
| Strings
| <code>'hello'</code>
| ''traditionally, Smalltalk does not support any escape sequence inside (i.e. they are what Python calls "Raw Strings") But see below...''
|-
| Strings (C Style) (*)
| <code>c'hello\nworld'</code>
| ''supports the common C-escape sequences, such as "\n", "\t", "\xHH", "\uXXXX"''
|-
| Strings (with embedded expressios) (*)
| <code>e'hello {OperatingSystem getLoginName}'</code>
| ''expanded expression strings expressions in braces are evaluated at runtime and sliced into the string (also a C-string). Similar to python's f-strings.''
|-
| Strings (national language translated with embedded expressios) (*)
| <code>i'hello {OperatingSystem getLoginName}'</code>
| ''international strings like above, but the string is also possibly translated to a national language''
|-
| Symbols
| <code>#'hello'</code> <code>#foo</code> <code>#+</code>
| ''symbols are interned strings; two symbols with the same characters are guaranteed to be the identical object (not just equal) without quotes, if only alphaNumeric characters''
|}

===== Arrays and Objects =====
{| class="wikitable"
|-
| Arrays 
| <code>#( el1 el2 ... elN )</code>
| each element is a literal constant
|-
| Byte Arrays
| <code>#[ b1 b2 ... bN ]</code>
| each byte-element an integer constant in 0..255
|-
| Special Number Arrays (*)
| <code>#XX( v1 v2 ... vN )</code>
| XX: is one of  'u8', 's8', 'u16', 's16', 'u32', 's32', 'u64', 's64', 'f32', 'f64'  and each element being an integer or float constant
|-
| Immediate Inline Objects (*)
| <code>#{ foo: fooValue . bar: barValue }</code>
| fooValue and barValue: are constants
|}

==== Lambda Blocks (Closures) ====

{| class="wikitable"
|-
| Without argument
| <code>[ expr1 . expr2 ... exprN ]</code>
| multiple expressions sep'd by period. When evaluated, the value is the value from the last expression, exprN
|-
| One argument
| <code>[ :arg |     expr1 . expr2 ... exprN ]</code>
|-
| Multiple arguments
| <code>[ :a1 :a2 ... :aN |     expr1 . expr2 ... exprN ]</code>
|-
| Local Variables inside a block
| <code>[ :a1 ... :aN |      |local1 local2 |      expr1 ... exprN ]</code>
|}

==== Expressions ====

{| class="wikitable"
|-
| Unary Expression (without argument)
| <code>receiver messageName</code>
|receiver is itself either a constant, a lambda-block, a unary expression or a parenthesized expression
|-
| Keyword Expression (1 arg)
| <code>receiver messageNamePart:argExpression</code>
|whitespace between the colon and the argExpression is optional.
|-
| Keyword Expression (any number of args)
| <code>receiver     messageNamePart1:argExpression1     messageNamePart2:argExpression2     ...     messageNamePartN:argExpressionN</code>
|-
| Binary Expression
| <code>receiver binOP arg</code>
|with binOP being any combination of special characters: * , + , - , % , & , / , \ , | , = , < , > , ? and ,
 I.e. "<code>foo ==> 123</code>" is the binary message "<code>==></code>" sent to <code>foo</code> with <code>123</code> as argument.
 And "<code>foo ? 123</code>" is the binary message "<code>?</code>" sent to <code>foo</code> with <code>123</code> as argument.
|-
| Cascade Expression (multiple messages to the same receiver)
| <code>receiver     message1 ;     message2 ;     ...     messageN</code></td>
|the receiver expression is evaluated, then multiple messages (separated by ";") are sent to this receiver.
|-
| Parentheses for grouping
| <code>( any expression )</code>
|-
| Assignment
| <code>variable := expression</code>
|can be used as expression.
|-
| Computed Array (Brace Construct) (*)
| <code>{ expr1 . expr2 . ... . exprN }</code>
|instantiates a new Array object with elements from the expressions.
|-
| Computed Inline Object (*)
| <code>{ foo: fooExpr . bar: barExpr }</code>
|fooExpr and barExpr: expressions
|-
| Inline string expressions (*)
| <code>e'p1{e1}p2{e2}...pN{eN}pM'</code>
|syntactic sugar for: <code>('p1%1p2%2...pN%NpM' bindWith:e1 with:e2 ... with:eN)</code> where each pI is a string with possible C-escapes and each eI is a Smalltalk expression
|-
| Array Indexing (*)
| <code>coll[idx]</code> <code>coll[idx1][idx2]</code> <code>coll[idx1][idx2][idx3]</code>
|syntactic sugar for: <code>(coll at:idx)</code> where coll must be an indexable collection, and idx of compatible index type. I.e. integer for array-like collections, hash-key for dictionaries, etc. Up to 4 dimensions are (currently supported)
|-
| Collection instantiation (*)
| <code>someClass[sz]</code> <code>someClass[sz][sz]</code> ...
|syntactic sugar for: <code>(someClass new:sz)</code> where someClass must be a collection class I.e. Array[10] creates an empty array with 10 slots. 1, 2, 3 and 4 dimensions are supported
|-

|}

==== Remaining Syntax ====

{| class="wikitable"
|-
| Local variables (in block or method)
| <code>| var1 var2 ... varN |</code>
|variable declarations must be at the beginning, before any expression.
|-
| Separating multiple expressions (sequence)
| <code>expr1 . expr2 . ... exprN</code>
|expressions (statements) are separated by fullstop (period) characters. The last expression may or may not be followed by a fullstop; if there is one, this is treated like a followup empty statement.
|-
| Return from method
| <code>^ expression</code>
|returns from the enclosing method (also if inside a block-closure)
|}

==== Wellknown (Common) Messages ====

{| class="wikitable"
|-
| Conditional Execution
| <code>boolExpr1 ifTrue:[ ... ] ifFalse:[ ... ]</code>
|variations without true-part, without false part and with the order reversed are available.
|-
| While-Loop (test at top)
| <code>[ boolExpr1 ] whileTrue:[ ... ]</code>
|notice the receiver being a block. A <code>whileFalse:</code> variant is also available.
|-
| Do-Loop (test at bottom)
| <code>[ ... ] doWhile:[ boolExpr1 ]</code>
|notice the test being a block. A <code>doUntil:</code> variant is also available.
|-
| For-Loop
| <code>start to:stop do:[:iterVar | ... ]</code>
|evaluates the block (lambda) for each value in start..stop.
|-
| Enumerating Collections
| <code>collection do:[:elementVar | ... ]</code>
|evaluates the block (i.e. lambda) for each element in the collection.
|-
| Evaluating a Lambda Block   without arguments:
  with arguments:
| <code>aBlock value</code><code>aBlock value:expr1 ... value:exprN</code>
|the number of arguments must match the number expected by the lambda (although varArg lambdas are also available)
|-
| Exception Handling
| <code>[ ... ] on:Error do:[:ex | ... ]</code>
|evaluates the first block; if an error is encountered, evaluate the handler
|}

==== Special 'Control Structures' ====

{| class="wikitable"
|-
| Starting another Thread
| <code>p := [ ... ] fork</code>
|the code inside the block will execute in a separate thread
|-
| Creating, configuring and starting another Thread
| <code>p := [ ... ]   newProcess;   name:'my worker';   priority:5;   resume</code>
|the code inside the block will execute in a separate thread
|-
| Terminating a Thread
| <code>p terminate</code>
|with p referring to the thread as created by newProcess or fork
|-
| Interrupting a Thread
| <code>p interruptWith:[ ... ]</code>
|interrupt the thread and let it execute the given code (in its interrupt seervice)
|-
| Exception Handling
| <code>[ ... ]   on:Error do:[:ex |     ...   ]</code>
|the handler will get an exception argument (ex), which contains additional information, and can be told how to deal with the error
|-
| Exception Handling - proceeding
| <code>[ ... ]   on:Error do:[:ex |     ...     ex proceed   ]</code>
|proceed, as if the error did not happen
|-
| Exception Handling - restarting
| <code>[ ... ]   on:Error do:[:ex |     ...     ex restart   ]</code>
|restart the code from the beginning (usually after the handler did some cleanup, such as lazy loading a missing file...)
|-
| Exception Handling - printing
| <code>[ ... ]   on:Error do:[:ex |     ...     ex description     ...   ]</code>
|contains a human readable description of the error
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ensure:[   ...   ]</code>
|the ensure block will be evaluated in any case
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ifCurtailed:[   ...   ]</code>
|the ifCurtailed block will be evaluated only on a non-regular exit (i.e. when an exception was raised, or the operation was aborted or the thread terminated)
|-
| Early exit from Loops
| <code>[:exit |   ...   code with loop   ...   exit value   ... ] valueWithExit</code>
|the block will be left, when exit is evaluated. Often used as argument of ifTrue:, as in cond ifTrue: exit
|-
| Queries
| <code>Query   answer:something   do:[     ...     Query query     ...   ]</code>
|to provide answers way down to whoever is interested. Queries answer nil if no one is there to answer. Queries are usually more specifically used as subclasses of Query
|-
| Notifications
| <code>Notification   handle:[     ...   ]   do:[     ...     Notification notify:someArg     ...   ]</code>
|to provide information way up to whoever is interested Notifications are usually more specifically used as subclasses of Notification
|-
| Observers 1
| <code>foo onChange:#bla evaluate:[...]. ... foo changed:#bla</code>
|observer with generic block to evaluate
|-
| Observers 2
| <code>foo onChangeSend:#xyz to:someone. ... foo changed</code>
|observer with message send
|-
| Observers 3
| <code>foo addDependent:someone. ... foo changed</code>
|observer with send to update method of target
|}

Queries and Notifications can be seen as observers within the calling hierarchy (i.e. information flows up or down the calling hierarchy), whereas the dependency and anChange mechanisms are independent of the control flow (even between different threads)

==== Synchronization and Timers ====
{| class="wikitable"
|-
| Timed Delay
| <code>Delay waitForSeconds:n</code> <code>Delay waitUntil:(Timestamp now + 10 seconds)</code>
|self explaining
|-
| Sempaphore wait
| <code>s := Semaphore new. ... s wait. ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Sempaphore wait with timeout
| <code>s := Semaphore new. ... s waitWithTimeout:(5 seconds). ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Multi Sempaphore wait
| <code>s1 := Semaphore new. s2 := Semaphore new. ... which := (s1 , s2) wait. ... s2 signal</code>
|wait for any of multiple semaphores
|-
| Synchronized Collections
| <code>a := OrderedCollection new asSharedCollection</code>
|will wrap the collection so that add/remove operations are atomic
|}

==== Wellknown Globals ====

{| class="wikitable"
|-
| Logging and Messaging
| <code>Transcript</code> - the console window <code>Stdout</code> - standard output <code>Stderr</code> - standard error <code>Stdin</code> - standard input <code>Logger</code> - redefinable logger (defaults to standard error)
|-
| Common Useful Dialogs
| <code>Dialog</code> - provides many useful utility functions for standard dialogs eg.<code> Dialog warn:'message' Dialog confirm:'question' Dialog request:'question' Dialog requestFilename:'question' ...</code>
|}

==== Most Wellknown Classes ====

{| class="wikitable"
|-
| Numbers
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Number Number]</code>(abstract superclass) <code>[http://live.exept.de/ClassDoc/classDocOf:,Integer Integer]</code>(integral numbers) <code>[http://live.exept.de/ClassDoc/classDocOf:,Float Float]</code>(inexact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Fraction Fraction]</code>(exact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Complex Complex]</code>
|-
| Collections
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Array Array]</code> (fixed size array) <code>[http://live.exept.de/ClassDoc/classDocOf:,OrderedCollection OrderedCollection]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,List List]</code> (variable size) <code>[http://live.exept.de/ClassDoc/classDocOf:,SortedCollection SortedCollection]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Set Set]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Bag Bag]</code> (unordered) <code>[http://live.exept.de/ClassDoc/classDocOf:,Dictionary Dictionary]</code> (mapped collections) <code>[http://live.exept.de/ClassDoc/classDocOf:,BinaryTree BinaryTree]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,AVLTree AVLTree]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,SharedQueue SharedQueue]</code> (shared, synchronized) many more...
|-
| Process Handling
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Process Process]</code> (lightweight thread) <code>[http://live.exept.de/ClassDoc/classDocOf:,OSProcess OSProcess]</code> (heavyweight OS process) <code>[http://live.exept.de/ClassDoc/classDocOf:,Semaphore Semaphore]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,RecursionLock RecursionLock]</code> (synchronization) <code>[http://live.exept.de/ClassDoc/classDocOf:,Monitor Monitor]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,BoltLock BoltLock]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Delay Delay]</code> (time delays)
|-
| Files & Streams
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Filename Filename]</code> (file naming, directory access, mime type) <code>[http://live.exept.de/ClassDoc/classDocOf:,Stream Stream]</code> (basic stream framework)
 <code>[http://live.exept.de/ClassDoc/classDocOf:,ReadStream ReadStream]</code>,<code>WriteStream</code>,<code>[http://live.exept.de/ClassDoc/classDocOf:,EncodedStream EncodedStream]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,ExternalStream ExternalStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,FileStream FileStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Socket Socket]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,PipeStream PipeStream]</code> (OS-cmd streams)
|-
| Low Level Access
| <code>[http://live.exept.de/ClassDoc/classDocOf:,OperatingSystem OperatingSystem]</code> (OS API calls) <code>[http://live.exept.de/ClassDoc/classDocOf:,Smalltalk Smalltalk]</code>(startup, shutdown and globals) <code>[http://live.exept.de/ClassDoc/classDocOf:,ObjectMemory ObjectMemory]</code>(VM access)
|}

== Examples ==

exampleMethod1
|v1 v2|

v1 := 42.
v2 := v1 sqrt.
Transcript showCR: 'the root of the answer to all questions is: %1' with: v2.

using expanded strings, this can be written as:

exampleMethod1_alternative
|v1|

v1 := 42.
Transcript showCR: e'the root of the answer to all questions is: {v1 sqrt}'.

enumerating elements of an array:

exampleMethod2
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr do:[:el |
Transcript showCR: el
]

enumerating elements of an array with additional index:

exampleMethod3
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr doWithIndex:[:el :idx |
Transcript showCR: e'array element at {idx} is {el} and its class is {el class name}\n'
]

dialogs, string-to-number conversion, error handling:

exampleMethod4
|s1 nr1 s2 nr2 rslt|

s1 := Dialog request:'Enter the first number' initialAnswer:1.
s1 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method
s2 := Dialog request:'Enter the second number' initialAnswer:2.
s2 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr1 := Number readFrom:s1 onError:[^ self].
nr2 := Number readFrom:s2 onError:[^ self].

"/ save division
[
rslt := nr1 / nr2
] on: Error do:[:ex |
(Dialog confirm: e'Error encountered: {ex description}\nProceed with zero?')
ifFalse:[^ self]. "/ no; return from method
ex proceedWith:0
].

Dialog information: e'the result is {rslt}'

dialogs, error handling and complex square root:

exampleMethod4
|s nr rslt|

s := Dialog request:'Enter a number (may be negative)' initialAnswer:2.
s isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr := Number readFrom:s onError:[^ self].

"/ square root; catch imaginary result
[
rslt := nr sqrt
] on: ImaginaryResultError do:[:ex |
(Dialog confirm: e'No solution in R; want to see the complex result?')
ifFalse:[^ self]. "/ no; return from method
rslt := Number trapImaginary:[ nr sqrt ].
"/ rslt is now a complex number
].

Dialog information: e'the result is {rslt}'

== Standard ==
The ANSI Smalltalk standard was approved on May 19, 1998. The official name of the document is ANSI INCITS 319-1998 (R2002). You can order a copy of the final standard
from here: [http://www.techstreet.com/cgi-bin/detail?product_id=56122]
or here [http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI+INCITS+319%2D1998+%28R2002%29]. The name of the document is "American National Standard for Information Systems - Programming Languages - Smalltalk".

You can also download the final draft revision for free: standard_v1_9-indexed.pdf and at [https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf].

The final draft is identical to the official standard except that the draft also has a rationale included (and thus, the draft is arguably more useful than the official standard).

Protocol from ANSI Meeting: [http://www.netjam.org/smalltalk/faq/ANSI-meeting.html]

== Common Language Extensions ==
These are also found in other Smalltalk dialects (eg. [[Glossary#VW|VW]] or [[Glossary#Squeak|Squeak]])

* { expr1 . expr2 . ... } Brace Array Construction Each expression is evaluated (left to right), and an Array with the results is created at execution time. Notice that separating full stops are required, as opposed to constant literal arrays, where elements are separated by spaces. The generated Array is mutable (can be modified), whereas a constant array is not.

== Summary of Smalltalk/X Language Extensions ==

These are ST/X specific, and not (as of 2026) implemented in other Smalltalk systems.

=== Comments ===
* "/ End of line comment
* "<<X ... X token delimited comment; X can be any word and a line starting with X ends the comment

=== String Literals ===
* c'...' ''c-strings'' C-like escapes (\n, \t, \xNN, \uNNNN) inside the string are expanded.

* e' ... {expr} ...' ''e-strings'' (expanded epression strings) In addition to C-escapes, embedded expressions are evaluated and their printString is sliced in. Technically, it is converted to ' ... %1 ...' and then expanded using standard String methods.

* i' ... {expr} ...' ''i-strings'' (international strings) similar to e-strings, but the converted string ('... %1 ...') is translated to a national string (via the *.rs file) and then expanded. Allows for different word ordering.

=== Integer Literals ===
* 0xNNNN, 0oNNNN, 0bNNNN C-style hex, octal and binary integers. With arbitrary precision

=== Float Literals ===
* <f>q, <f>Q, etc. Float literal type suffix (q, Q, QD, QL, QO) For a complete list and spec., see the Number documentation.

=== Compact Number Arrays ===
* #u1, #u8, #u16, #u32, #u64 #i8, #i16, #i32, #i64 #f16, #bf16, #f32, #f64 Will generate dense packed vectors (similar to byteArray); format is #X(n1 n2 ... )

Smalltalk Syntax Cheat Sheet

2026-06-07T06:22:47Z

Cg: /* Numbers */

A short, one page summary of what beginners need to know about Smalltalk/X, its syntax and most useful code fragments. As usual, this is only a tiny fraction of what is really awailable, and you should use the builtin class browser to find many more useful functions in the system.

This page was extracted from the "Smalltalk/X Programmers guide - Smalltalk/X Cheat Sheet".
 Smalltalk/X language extensions (w.r.t. other Smalltalk implementations) are marked with '''(*)'''.

== Smalltalk Philosophy ==

* The world consists of objects which '''communicate by sending messages'''.
: A message looks like an english sentence, and might look like "<code>heyYou doSomething</code>".
: In this example, the "heyYou" is called the "''receiver of the message''"
: You may pass additional parameter objects (arguments) as in: "<code>heyYou doSomethingWith: arg</code>"
: or multiple arguments as in <code>"heyYou doSomethingWith: arg1 and: arg2"</code>
: In these examples, the "<code>heyYou</code>" is called the "''receiver of the message''"
* Messages without argument are called "''unary messages''"; those with arguments are called "''keyword messages''"
: For example "<code>Transcript clear</code>" (sends the message "clear" to the Transcript object),
: and "<code>Transcript show: 'hello'</code>" (sends the message "show:" to the Transcript, passing a string argument),
* To allow for arithmetic operations, any non-letter character (except for a few) are treated like a message name and written between the receiver and the one and only argument. These are called "''binary messages''".
: For example: <code>"3 + 4"</code> or <code>"abc , def"</code> (yes, the comma is an operator; it does string concatenation)
* The object my respond (or "answer") by returning some result object. In the above example, "<code>3+4</code>" would answer "7", and "<code>'hello' , 'world'</code>" would answer 'helloworld'
* binary messages have no meaning to the compiler; they are all equal and simply evaluated from left to right.
: admitted, this makes arithmetic a little strange initially; you'll need parentheses as the is not precidence of eg. * over +. The expression "3 + 4 * 5" will be evaluated left to right and answer 35.
* Everything in this world is an object;
: from low level things like booleans, true, false, integer numbers, floating point numbers characters etc.
: there are containers, which can hold on other objects. Technically, all such references are via pointers.
: there are also very complex objects and structures which implement windows, the user interface, communication interfaces, debuggers and even compilers which allow for code to be defined and installed on the fly.
* Every object is associated to a class. Classes define the behavior of their instances. I.e. they define how they respond to messages. The response is implemented by a so called ''method''. That is a piece of code which is executed when a message comes in. A method consist of a number of statements (which are message sends), each separated by a full stop (as in english).
* Classes are themself objects, which respond to messages. Typically class messages would answer new instances, constants or utility functionality. There are also class messages to create new classes.
* Class can inherit common functionality (i.e. method implementations) from a superclass. Thus creating a hierarchy of classes. Typical hierarchies are the Number hierarchy, Collections, Streams and UI Widgets.
* In Smalltalk, every behavior is defined by corresponding message implementations. This includes control features (i.e. if-then-else, loops and exception handling). All of them are implemented as messages being sent to booleans (ifTrue:/ifFalse:) or blocks (whileTrue:)
* Blocks are special objects, which wrap a piece of code. Other languages know them as anonymous functions or lambdas or closures. But the Smalltalk syntax makes them super easy to use: just write a number of expressions inside square brackets, as in "<code>[ Transcript show: 10 factorial ]</code>".
: blocks can be passed as argument with a message send; for example to a boolean: "<code>aBoolean ifTrue: [ Transcript show: 'yes' ]</code>"
: blocks can be stored in variables and passed arounf just like any other object
: blocks can receive messages, especially loop messages: "<code>[ a < 10] whileTrue:[ Transcript showCR: a. a := a + 1 ]</code>".

== Syntax ==

==== Comments ====

{| class="wikitable"
|-
| Regular comment
| <code>" this is a comment "</code>
| ''any text between double quotes''
|-
| EOL-Comment (*)
| <code>"/ this is an End-of-Line comment</code>
| ''text from quote-slash to line end''
|-
| Token-Comment (*)
| <code>"<<END a multiline token-comment up to a line starting with 'END' more commented stuff here ... comment ends here END</code>
| ''text up to line beginning with whatever token came after the initial "<<" ''
|}

==== Literal Constants ====

===== Numbers =====

{| class="wikitable"
|-
| Integers</td>
| <code>12345</code> </code>-12345<code>
|
|-
| Large integers
| <code>1234567890123456789012345</code>…
| ''arbitrary number of digits''
|-
| Integers with radix (Smalltalk style)
| <code>16rAFFE</code>, <code>2r010101</code>, <code>8r0777</code>, <code>3r012012</code>, <code>16r-AFFE</code>, <code>2r-010101</code>
| ''prepend the radix (base) any radix from 2..36 is possible (i.e. 3r222 is a ternary number)''
|-
| Integers with radix (C style) (*)
| <code>0xFEED</code> <code>-0xBEAF</code> <code>0b11011</code>,<code>-0b1100</code>
| ''C/Java/JavaScript style: prepend radix indicator ('x', 'b', 'o') One of hex, binary and octal''
|-
| Floats (IEEE double; roughly 17 digits)
| 12.456 1.234e17 -6.9 -6e-10 Float pi Float e
| ''called "Float", but actually hold double precision Common constants can be referred to "by name".''
|-
| Short floats (IEEE single; roughly 8 digits) (*)
| <code>1.234e17f</code> <code>-6e-10f</code>
| <strike>''this is controlled by a ParserFlag (singlePrecisionFloatF), which is currently defaulted to false. Thus, by default, double precision floats are created with the 'f' exponent character.''</strike>
|-
| Long floats (IEEE extended; roughly 20 digits) (*)
| <code>1.234e17q</code> <code>-6q-10q</code>
| ''actual precision depends on the underlying CPU (x86/x86_64: 80bit; Sparc: 128 bit)
|-
| Quad floats; (IEEE quad; roughly 34 digits (*)
| <code>1.234e17Q</code> <code>-6e-10Q</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Octuple floats; roughly 60 digits (*)
| <code>1.234e17QO</code> <code>-6e-10QP</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Large floats; roughly 60 digits by default, but any precision possible (*)
| <code>1.234e17QL</code> <code>-6e-10QL</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Fractions
| <code>(1/3)</code> <code>(17/2)</code>
|
|-
| ScaledDecimals
| <code>1234.53s2</code>
| ''the number after the s specifies the number of digits''
|}

===== Characters and Strings =====

{| class="wikitable"
|-
| Characters
| <code>$a</code> <code>Character space</code> <code>Character nl</code> Also: "<code>null</code>", "<code>tab</code>", "<code>return</code>", "<code>bell</code>"... Or: <code>Character codePoint:n</code>
| ''Smalltalk does not support any escape sequence Common constants can be referred to "by name".''
|-
| Strings
| <code>'hello'</code>
| ''traditionally, Smalltalk does not support any escape sequence inside (i.e. they are what Python calls "Raw Strings") But see below...''
|-
| Strings (C Style) (*)
| <code>c'hello\nworld'</code>
| ''supports the common C-escape sequences, such as "\n", "\t", "\xHH", "\uXXXX"''
|-
| Strings (with embedded expressios) (*)
| <code>e'hello {OperatingSystem getLoginName}'</code>
| ''expanded expression strings expressions in braces are evaluated at runtime and sliced into the string (also a C-string). Similar to python's f-strings.''
|-
| Strings (national language translated with embedded expressios) (*)
| <code>i'hello {OperatingSystem getLoginName}'</code>
| ''international strings like above, but the string is also possibly translated to a national language''
|-
| Symbols
| <code>#'hello'</code> <code>#foo</code> <code>#+</code>
| ''symbols are interned strings; two symbols with the same characters are guaranteed to be the identical object (not just equal) without quotes, if only alphaNumeric characters''
|}

===== Arrays and Objects =====
{| class="wikitable"
|-
| Arrays 
| <code>#( el1 el2 ... elN )</code>
| each element is a literal constant
|-
| Byte Arrays
| <code>#[ b1 b2 ... bN ]</code>
| each byte-element an integer constant in 0..255
|-
| Special Number Arrays (*)
| <code>#XX( v1 v2 ... vN )</code>
| XX: is one of  'u8', 's8', 'u16', 's16', 'u32', 's32', 'u64', 's64', 'f32', 'f64'  and each element being an integer or float constant
|-
| Immediate Inline Objects (*)
| <code>#{ foo: fooValue . bar: barValue }</code>
| fooValue and barValue: are constants
|}

==== Lambda Blocks (Closures) ====

{| class="wikitable"
|-
| Without argument
| <code>[ expr1 . expr2 ... exprN ]</code>
| multiple expressions sep'd by period. When evaluated, the value is the value from the last expression, exprN
|-
| One argument
| <code>[ :arg |     expr1 . expr2 ... exprN ]</code>
|-
| Multiple arguments
| <code>[ :a1 :a2 ... :aN |     expr1 . expr2 ... exprN ]</code>
|-
| Local Variables inside a block
| <code>[ :a1 ... :aN |      |local1 local2 |      expr1 ... exprN ]</code>
|}

==== Expressions ====

{| class="wikitable"
|-
| Unary Expression (without argument)
| <code>receiver messageName</code>
|receiver is itself either a constant, a lambda-block, a unary expression or a parenthesized expression
|-
| Keyword Expression (1 arg)
| <code>receiver messageNamePart:argExpression</code>
|whitespace between the colon and the argExpression is optional.
|-
| Keyword Expression (any number of args)
| <code>receiver     messageNamePart1:argExpression1     messageNamePart2:argExpression2     ...     messageNamePartN:argExpressionN</code>
|-
| Binary Expression
| <code>receiver binOP arg</code>
|with binOP being any combination of special characters: * , + , - , % , & , / , \ , | , = , < , > , ? and ,
 I.e. "<code>foo ==> 123</code>" is the binary message "<code>==></code>" sent to <code>foo</code> with <code>123</code> as argument.
 And "<code>foo ? 123</code>" is the binary message "<code>?</code>" sent to <code>foo</code> with <code>123</code> as argument.
|-
| Cascade Expression (multiple messages to the same receiver)
| <code>receiver     message1 ;     message2 ;     ...     messageN</code></td>
|the receiver expression is evaluated, then multiple messages (separated by ";") are sent to this receiver.
|-
| Parentheses for grouping
| <code>( any expression )</code>
|-
| Assignment
| <code>variable := expression</code>
|can be used as expression.
|-
| Computed Array (Brace Construct) (*)
| <code>{ expr1 . expr2 . ... . exprN }</code>
|instantiates a new Array object with elements from the expressions.
|-
| Computed Inline Object (*)
| <code>{ foo: fooExpr . bar: barExpr }</code>
|fooExpr and barExpr: expressions
|-
| Inline string expressions (*)
| <code>e'p1{e1}p2{e2}...pN{eN}pM'</code>
|syntactic sugar for: <code>('p1%1p2%2...pN%NpM' bindWith:e1 with:e2 ... with:eN)</code> where each pI is a string with possible C-escapes and each eI is a Smalltalk expression
|-
| Array Indexing (*)
| <code>coll[idx]</code> <code>coll[idx1][idx2]</code> <code>coll[idx1][idx2][idx3]</code>
|syntactic sugar for: <code>(coll at:idx)</code> where coll must be an indexable collection, and idx of compatible index type. I.e. integer for array-like collections, hash-key for dictionaries, etc. Up to 4 dimensions are (currently supported)
|-
| Collection instantiation (*)
| <code>someClass[sz]</code> <code>someClass[sz][sz]</code> ...
|syntactic sugar for: <code>(someClass new:sz)</code> where someClass must be a collection class I.e. Array[10] creates an empty array with 10 slots. 1, 2, 3 and 4 dimensions are supported
|-

|}

==== Remaining Syntax ====

{| class="wikitable"
|-
| Local variables (in block or method)
| <code>| var1 var2 ... varN |</code>
|variable declarations must be at the beginning, before any expression.
|-
| Separating multiple expressions (sequence)
| <code>expr1 . expr2 . ... exprN</code>
|expressions (statements) are separated by fullstop (period) characters. The last expression may or may not be followed by a fullstop; if there is one, this is treated like a followup empty statement.
|-
| Return from method
| <code>^ expression</code>
|returns from the enclosing method (also if inside a block-closure)
|}

==== Wellknown (Common) Messages ====

{| class="wikitable"
|-
| Conditional Execution
| <code>boolExpr1 ifTrue:[ ... ] ifFalse:[ ... ]</code>
|variations without true-part, without false part and with the order reversed are available.
|-
| While-Loop (test at top)
| <code>[ boolExpr1 ] whileTrue:[ ... ]</code>
|notice the receiver being a block. A <code>whileFalse:</code> variant is also available.
|-
| Do-Loop (test at bottom)
| <code>[ ... ] doWhile:[ boolExpr1 ]</code>
|notice the test being a block. A <code>doUntil:</code> variant is also available.
|-
| For-Loop
| <code>start to:stop do:[:iterVar | ... ]</code>
|evaluates the block (lambda) for each value in start..stop.
|-
| Enumerating Collections
| <code>collection do:[:elementVar | ... ]</code>
|evaluates the block (i.e. lambda) for each element in the collection.
|-
| Evaluating a Lambda Block   without arguments:
  with arguments:
| <code>aBlock value</code><code>aBlock value:expr1 ... value:exprN</code>
|the number of arguments must match the number expected by the lambda (although varArg lambdas are also available)
|-
| Exception Handling
| <code>[ ... ] on:Error do:[:ex | ... ]</code>
|evaluates the first block; if an error is encountered, evaluate the handler
|}

==== Special 'Control Structures' ====

{| class="wikitable"
|-
| Starting another Thread
| <code>p := [ ... ] fork</code>
|the code inside the block will execute in a separate thread
|-
| Creating, configuring and starting another Thread
| <code>p := [ ... ]   newProcess;   name:'my worker';   priority:5;   resume</code>
|the code inside the block will execute in a separate thread
|-
| Terminating a Thread
| <code>p terminate</code>
|with p referring to the thread as created by newProcess or fork
|-
| Interrupting a Thread
| <code>p interruptWith:[ ... ]</code>
|interrupt the thread and let it execute the given code (in its interrupt seervice)
|-
| Exception Handling
| <code>[ ... ]   on:Error do:[:ex |     ...   ]</code>
|the handler will get an exception argument (ex), which contains additional information, and can be told how to deal with the error
|-
| Exception Handling - proceeding
| <code>[ ... ]   on:Error do:[:ex |     ...     ex proceed   ]</code>
|proceed, as if the error did not happen
|-
| Exception Handling - restarting
| <code>[ ... ]   on:Error do:[:ex |     ...     ex restart   ]</code>
|restart the code from the beginning (usually after the handler did some cleanup, such as lazy loading a missing file...)
|-
| Exception Handling - printing
| <code>[ ... ]   on:Error do:[:ex |     ...     ex description     ...   ]</code>
|contains a human readable description of the error
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ensure:[   ...   ]</code>
|the ensure block will be evaluated in any case
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ifCurtailed:[   ...   ]</code>
|the ifCurtailed block will be evaluated only on a non-regular exit (i.e. when an exception was raised, or the operation was aborted or the thread terminated)
|-
| Early exit from Loops
| <code>[:exit |   ...   code with loop   ...   exit value   ... ] valueWithExit</code>
|the block will be left, when exit is evaluated. Often used as argument of ifTrue:, as in cond ifTrue: exit
|-
| Queries
| <code>Query   answer:something   do:[     ...     Query query     ...   ]</code>
|to provide answers way down to whoever is interested. Queries answer nil if no one is there to answer. Queries are usually more specifically used as subclasses of Query
|-
| Notifications
| <code>Notification   handle:[     ...   ]   do:[     ...     Notification notify:someArg     ...   ]</code>
|to provide information way up to whoever is interested Notifications are usually more specifically used as subclasses of Notification
|-
| Observers 1
| <code>foo onChange:#bla evaluate:[...]. ... foo changed:#bla</code>
|observer with generic block to evaluate
|-
| Observers 2
| <code>foo onChangeSend:#xyz to:someone. ... foo changed</code>
|observer with message send
|-
| Observers 3
| <code>foo addDependent:someone. ... foo changed</code>
|observer with send to update method of target
|}

Queries and Notifications can be seen as observers within the calling hierarchy (i.e. information flows up or down the calling hierarchy), whereas the dependency and anChange mechanisms are independent of the control flow (even between different threads)

==== Synchronization and Timers ====
{| class="wikitable"
|-
| Timed Delay
| <code>Delay waitForSeconds:n</code> <code>Delay waitUntil:(Timestamp now + 10 seconds)</code>
|self explaining
|-
| Sempaphore wait
| <code>s := Semaphore new. ... s wait. ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Sempaphore wait with timeout
| <code>s := Semaphore new. ... s waitWithTimeout:(5 seconds). ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Multi Sempaphore wait
| <code>s1 := Semaphore new. s2 := Semaphore new. ... which := (s1 , s2) wait. ... s2 signal</code>
|wait for any of multiple semaphores
|-
| Synchronized Collections
| <code>a := OrderedCollection new asSharedCollection</code>
|will wrap the collection so that add/remove operations are atomic
|}

==== Wellknown Globals ====

{| class="wikitable"
|-
| Logging and Messaging
| <code>Transcript</code> - the console window <code>Stdout</code> - standard output <code>Stderr</code> - standard error <code>Stdin</code> - standard input <code>Logger</code> - redefinable logger (defaults to standard error)
|-
| Common Useful Dialogs
| <code>Dialog</code> - provides many useful utility functions for standard dialogs eg.<code> Dialog warn:'message' Dialog confirm:'question' Dialog request:'question' Dialog requestFilename:'question' ...</code>
|}

==== Most Wellknown Classes ====

{| class="wikitable"
|-
| Numbers
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Number Number]</code>(abstract superclass) <code>[http://live.exept.de/ClassDoc/classDocOf:,Integer Integer]</code>(integral numbers) <code>[http://live.exept.de/ClassDoc/classDocOf:,Float Float]</code>(inexact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Fraction Fraction]</code>(exact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Complex Complex]</code>
|-
| Collections
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Array Array]</code> (fixed size array) <code>[http://live.exept.de/ClassDoc/classDocOf:,OrderedCollection OrderedCollection]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,List List]</code> (variable size) <code>[http://live.exept.de/ClassDoc/classDocOf:,SortedCollection SortedCollection]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Set Set]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Bag Bag]</code> (unordered) <code>[http://live.exept.de/ClassDoc/classDocOf:,Dictionary Dictionary]</code> (mapped collections) <code>[http://live.exept.de/ClassDoc/classDocOf:,BinaryTree BinaryTree]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,AVLTree AVLTree]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,SharedQueue SharedQueue]</code> (shared, synchronized) many more...
|-
| Process Handling
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Process Process]</code> (lightweight thread) <code>[http://live.exept.de/ClassDoc/classDocOf:,OSProcess OSProcess]</code> (heavyweight OS process) <code>[http://live.exept.de/ClassDoc/classDocOf:,Semaphore Semaphore]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,RecursionLock RecursionLock]</code> (synchronization) <code>[http://live.exept.de/ClassDoc/classDocOf:,Monitor Monitor]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,BoltLock BoltLock]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Delay Delay]</code> (time delays)
|-
| Files & Streams
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Filename Filename]</code> (file naming, directory access, mime type) <code>[http://live.exept.de/ClassDoc/classDocOf:,Stream Stream]</code> (basic stream framework)
 <code>[http://live.exept.de/ClassDoc/classDocOf:,ReadStream ReadStream]</code>,<code>WriteStream</code>,<code>[http://live.exept.de/ClassDoc/classDocOf:,EncodedStream EncodedStream]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,ExternalStream ExternalStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,FileStream FileStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Socket Socket]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,PipeStream PipeStream]</code> (OS-cmd streams)
|-
| Low Level Access
| <code>[http://live.exept.de/ClassDoc/classDocOf:,OperatingSystem OperatingSystem]</code> (OS API calls) <code>[http://live.exept.de/ClassDoc/classDocOf:,Smalltalk Smalltalk]</code>(startup, shutdown and globals) <code>[http://live.exept.de/ClassDoc/classDocOf:,ObjectMemory ObjectMemory]</code>(VM access)
|}

== Examples ==

exampleMethod1
|v1 v2|

v1 := 42.
v2 := v1 sqrt.
Transcript showCR: 'the root of the answer to all questions is: %1' with: v2.

using expanded strings, this can be written as:

exampleMethod1_alternative
|v1|

v1 := 42.
Transcript showCR: e'the root of the answer to all questions is: {v1 sqrt}'.

enumerating elements of an array:

exampleMethod2
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr do:[:el |
Transcript showCR: el
]

enumerating elements of an array with additional index:

exampleMethod3
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr doWithIndex:[:el :idx |
Transcript showCR: e'array element at {idx} is {el} and its class is {el class name}\n'
]

dialogs, string-to-number conversion, error handling:

exampleMethod4
|s1 nr1 s2 nr2 rslt|

s1 := Dialog request:'Enter the first number' initialAnswer:1.
s1 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method
s2 := Dialog request:'Enter the second number' initialAnswer:2.
s2 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr1 := Number readFrom:s1 onError:[^ self].
nr2 := Number readFrom:s2 onError:[^ self].

"/ save division
[
rslt := nr1 / nr2
] on: Error do:[:ex |
(Dialog confirm: e'Error encountered: {ex description}\nProceed with zero?')
ifFalse:[^ self]. "/ no; return from method
ex proceedWith:0
].

Dialog information: e'the result is {rslt}'

dialogs, error handling and complex square root:

exampleMethod4
|s nr rslt|

s := Dialog request:'Enter a number (may be negative)' initialAnswer:2.
s isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr := Number readFrom:s onError:[^ self].

"/ square root; catch imaginary result
[
rslt := nr sqrt
] on: ImaginaryResultError do:[:ex |
(Dialog confirm: e'No solution in R; want to see the complex result?')
ifFalse:[^ self]. "/ no; return from method
rslt := Number trapImaginary:[ nr sqrt ].
"/ rslt is now a complex number
].

Dialog information: e'the result is {rslt}'

== Standard ==
The ANSI Smalltalk standard was approved on May 19, 1998. The official name of the document is ANSI INCITS 319-1998 (R2002). You can order a copy of the final standard
from here: [http://www.techstreet.com/cgi-bin/detail?product_id=56122]
or here [http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI+INCITS+319%2D1998+%28R2002%29]. The name of the document is "American National Standard for Information Systems - Programming Languages - Smalltalk".

You can also download the final draft revision for free: standard_v1_9-indexed.pdf and at [https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf].

The final draft is identical to the official standard except that the draft also has a rationale included (and thus, the draft is arguably more useful than the official standard).

Protocol from ANSI Meeting: [http://www.netjam.org/smalltalk/faq/ANSI-meeting.html]

== Common Language Extensions ==
These are also found in other Smalltalk dialects (eg. [[Glossary#VW|VW]] or [[Glossary#Squeak|Squeak]])

* { expr1 . expr2 . ... } Brace Array Construction Each expression is evaluated (left to right), and an Array with the results is created at execution time. Notice that separating full stops are required, as opposed to constant literal arrays, where elements are separated by spaces. The generated Array is mutable (can be modified), whereas a constant array is not.

== Summary of Smalltalk/X Language Extensions ==

These are ST/X specific, and not (as of 2026) implemented in other Smalltalk systems.

=== Comments ===
* "/ End of line comment
* "<<X ... X token delimited comment; X can be any word and a line starting with X ends the comment

=== String Literals ===
* c'...' ''c-strings'' C-like escapes (\n, \t, \xNN, \uNNNN) inside the string are expanded.

* e' ... {expr} ...' ''e-strings'' (expanded epression strings) In addition to C-escapes, embedded expressions are evaluated and their printString is sliced in. Technically, it is converted to ' ... %1 ...' and then expanded using standard String methods.

* i' ... {expr} ...' ''i-strings'' (international strings) similar to e-strings, but the converted string ('... %1 ...') is translated to a national string (via the *.rs file) and then expanded. Allows for different word ordering.

=== Integer Literals ===
* 0xNNNN, 0oNNNN, 0bNNNN C-style hex, octal and binary integers. With arbitrary precision

=== Float Literals ===
* <f>q, <f>Q, etc. Float literal type suffix (q, Q, QD, QL, QO) For a complete list and spec., see the Number documentation.

=== Compact Number Arrays ===
* #u1, #u8, #u16, #u32, #u64 #i8, #i16, #i32, #i64 #f16, #bf16, #f32, #f64 Will generate dense packed vectors (similar to byteArray); format is #X(n1 n2 ... )

Smalltalk Syntax Cheat Sheet

2026-06-07T06:22:05Z

Cg: /* Comments */

A short, one page summary of what beginners need to know about Smalltalk/X, its syntax and most useful code fragments. As usual, this is only a tiny fraction of what is really awailable, and you should use the builtin class browser to find many more useful functions in the system.

This page was extracted from the "Smalltalk/X Programmers guide - Smalltalk/X Cheat Sheet".
 Smalltalk/X language extensions (w.r.t. other Smalltalk implementations) are marked with '''(*)'''.

== Smalltalk Philosophy ==

* The world consists of objects which '''communicate by sending messages'''.
: A message looks like an english sentence, and might look like "<code>heyYou doSomething</code>".
: In this example, the "heyYou" is called the "''receiver of the message''"
: You may pass additional parameter objects (arguments) as in: "<code>heyYou doSomethingWith: arg</code>"
: or multiple arguments as in <code>"heyYou doSomethingWith: arg1 and: arg2"</code>
: In these examples, the "<code>heyYou</code>" is called the "''receiver of the message''"
* Messages without argument are called "''unary messages''"; those with arguments are called "''keyword messages''"
: For example "<code>Transcript clear</code>" (sends the message "clear" to the Transcript object),
: and "<code>Transcript show: 'hello'</code>" (sends the message "show:" to the Transcript, passing a string argument),
* To allow for arithmetic operations, any non-letter character (except for a few) are treated like a message name and written between the receiver and the one and only argument. These are called "''binary messages''".
: For example: <code>"3 + 4"</code> or <code>"abc , def"</code> (yes, the comma is an operator; it does string concatenation)
* The object my respond (or "answer") by returning some result object. In the above example, "<code>3+4</code>" would answer "7", and "<code>'hello' , 'world'</code>" would answer 'helloworld'
* binary messages have no meaning to the compiler; they are all equal and simply evaluated from left to right.
: admitted, this makes arithmetic a little strange initially; you'll need parentheses as the is not precidence of eg. * over +. The expression "3 + 4 * 5" will be evaluated left to right and answer 35.
* Everything in this world is an object;
: from low level things like booleans, true, false, integer numbers, floating point numbers characters etc.
: there are containers, which can hold on other objects. Technically, all such references are via pointers.
: there are also very complex objects and structures which implement windows, the user interface, communication interfaces, debuggers and even compilers which allow for code to be defined and installed on the fly.
* Every object is associated to a class. Classes define the behavior of their instances. I.e. they define how they respond to messages. The response is implemented by a so called ''method''. That is a piece of code which is executed when a message comes in. A method consist of a number of statements (which are message sends), each separated by a full stop (as in english).
* Classes are themself objects, which respond to messages. Typically class messages would answer new instances, constants or utility functionality. There are also class messages to create new classes.
* Class can inherit common functionality (i.e. method implementations) from a superclass. Thus creating a hierarchy of classes. Typical hierarchies are the Number hierarchy, Collections, Streams and UI Widgets.
* In Smalltalk, every behavior is defined by corresponding message implementations. This includes control features (i.e. if-then-else, loops and exception handling). All of them are implemented as messages being sent to booleans (ifTrue:/ifFalse:) or blocks (whileTrue:)
* Blocks are special objects, which wrap a piece of code. Other languages know them as anonymous functions or lambdas or closures. But the Smalltalk syntax makes them super easy to use: just write a number of expressions inside square brackets, as in "<code>[ Transcript show: 10 factorial ]</code>".
: blocks can be passed as argument with a message send; for example to a boolean: "<code>aBoolean ifTrue: [ Transcript show: 'yes' ]</code>"
: blocks can be stored in variables and passed arounf just like any other object
: blocks can receive messages, especially loop messages: "<code>[ a < 10] whileTrue:[ Transcript showCR: a. a := a + 1 ]</code>".

== Syntax ==

==== Comments ====

{| class="wikitable"
|-
| Regular comment
| <code>" this is a comment "</code>
| ''any text between double quotes''
|-
| EOL-Comment (*)
| <code>"/ this is an End-of-Line comment</code>
| ''text from quote-slash to line end''
|-
| Token-Comment (*)
| <code>"<<END a multiline token-comment up to a line starting with 'END' more commented stuff here ... comment ends here END</code>
| ''text up to line beginning with whatever token came after the initial "<<" ''
|}

==== Literal Constants ====

===== Numbers =====

{| class="wikitable"
|-
| Integers</td>
| <code>12345</code> </code>-12345<code>
|
|-
| Large integers
| <code>1234567890123456789012345</code>…
| ''arbitrary number of digits''
|-
| Integers with radix (Smalltalk style)
| <code>16rAFFE</code>, <code>2r010101</code>, <code>8r0777</code>, <code>3r012012</code>, <code>16r-AFFE</code>, <code>2r-010101</code>
| ''prepend the radix (base) any radix from 2..36 is possible (i.e. 3r222 is a ternary number)''
|-
| Integers with radix (C style) (*)
| <code>0xFEED</code> <code>-0xBEAF</code> <code>0b11011</code>,<code>-0b1100</code>
| ''C/Java/JavaScript style: prepend radix indicator ('x', 'b', 'o') One of hex, binary and octal''
|-
| Floats (IEEE double; roughly 17 digits)
| 12.456 1.234e17 -6.9 -6e-10 Float pi Float e
| ''called "Float", but actually hold double precision Common constants can be referred to "by name".''
|-
| Short floats (IEEE single; roughly 8 digits) (*)
| <code>1.234e17f</code> <code>-6e-10f</code>
| <strike>''this is controlled by a ParserFlag (singlePrecisionFloatF), which is currently defaulted to false. Thus, by default, double precision floats are created with the 'f' exponent character.''</strike>
|-
| Long floats (IEEE extended; roughly 20 digits) (*)
| <code>1.234e17q</code> <code>-6q-10q</code>
| ''actual precision depends on the underlying CPU (x86/x86_64: 80bit; Sparc: 128 bit)
|-
| Quad floats; (IEEE quad; roughly 34 digits (*)
| <code>1.234e17Q</code> <code>-6e-10Q</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Octuple floats; roughly 60 digits (*)
| <code>1.234e17QO</code> <code>-6e-10QP</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Large floats; roughly 60 digits by default, but any precision possible (*)
| <code>1.234e17QL</code> <code>-6e-10QL</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Fractions
| <code>(1/3)</code> <code>(17/2)</code>
|
|-
| ScaledDecimals
| <code>1234.53s2</code>
| the number after the s specifies the number of digits
|}

===== Characters and Strings =====

{| class="wikitable"
|-
| Characters
| <code>$a</code> <code>Character space</code> <code>Character nl</code> Also: "<code>null</code>", "<code>tab</code>", "<code>return</code>", "<code>bell</code>"... Or: <code>Character codePoint:n</code>
| ''Smalltalk does not support any escape sequence Common constants can be referred to "by name".''
|-
| Strings
| <code>'hello'</code>
| ''traditionally, Smalltalk does not support any escape sequence inside (i.e. they are what Python calls "Raw Strings") But see below...''
|-
| Strings (C Style) (*)
| <code>c'hello\nworld'</code>
| ''supports the common C-escape sequences, such as "\n", "\t", "\xHH", "\uXXXX"''
|-
| Strings (with embedded expressios) (*)
| <code>e'hello {OperatingSystem getLoginName}'</code>
| ''expanded expression strings expressions in braces are evaluated at runtime and sliced into the string (also a C-string). Similar to python's f-strings.''
|-
| Strings (national language translated with embedded expressios) (*)
| <code>i'hello {OperatingSystem getLoginName}'</code>
| ''international strings like above, but the string is also possibly translated to a national language''
|-
| Symbols
| <code>#'hello'</code> <code>#foo</code> <code>#+</code>
| ''symbols are interned strings; two symbols with the same characters are guaranteed to be the identical object (not just equal) without quotes, if only alphaNumeric characters''
|}

===== Arrays and Objects =====
{| class="wikitable"
|-
| Arrays 
| <code>#( el1 el2 ... elN )</code>
| each element is a literal constant
|-
| Byte Arrays
| <code>#[ b1 b2 ... bN ]</code>
| each byte-element an integer constant in 0..255
|-
| Special Number Arrays (*)
| <code>#XX( v1 v2 ... vN )</code>
| XX: is one of  'u8', 's8', 'u16', 's16', 'u32', 's32', 'u64', 's64', 'f32', 'f64'  and each element being an integer or float constant
|-
| Immediate Inline Objects (*)
| <code>#{ foo: fooValue . bar: barValue }</code>
| fooValue and barValue: are constants
|}

==== Lambda Blocks (Closures) ====

{| class="wikitable"
|-
| Without argument
| <code>[ expr1 . expr2 ... exprN ]</code>
| multiple expressions sep'd by period. When evaluated, the value is the value from the last expression, exprN
|-
| One argument
| <code>[ :arg |     expr1 . expr2 ... exprN ]</code>
|-
| Multiple arguments
| <code>[ :a1 :a2 ... :aN |     expr1 . expr2 ... exprN ]</code>
|-
| Local Variables inside a block
| <code>[ :a1 ... :aN |      |local1 local2 |      expr1 ... exprN ]</code>
|}

==== Expressions ====

{| class="wikitable"
|-
| Unary Expression (without argument)
| <code>receiver messageName</code>
|receiver is itself either a constant, a lambda-block, a unary expression or a parenthesized expression
|-
| Keyword Expression (1 arg)
| <code>receiver messageNamePart:argExpression</code>
|whitespace between the colon and the argExpression is optional.
|-
| Keyword Expression (any number of args)
| <code>receiver     messageNamePart1:argExpression1     messageNamePart2:argExpression2     ...     messageNamePartN:argExpressionN</code>
|-
| Binary Expression
| <code>receiver binOP arg</code>
|with binOP being any combination of special characters: * , + , - , % , & , / , \ , | , = , < , > , ? and ,
 I.e. "<code>foo ==> 123</code>" is the binary message "<code>==></code>" sent to <code>foo</code> with <code>123</code> as argument.
 And "<code>foo ? 123</code>" is the binary message "<code>?</code>" sent to <code>foo</code> with <code>123</code> as argument.
|-
| Cascade Expression (multiple messages to the same receiver)
| <code>receiver     message1 ;     message2 ;     ...     messageN</code></td>
|the receiver expression is evaluated, then multiple messages (separated by ";") are sent to this receiver.
|-
| Parentheses for grouping
| <code>( any expression )</code>
|-
| Assignment
| <code>variable := expression</code>
|can be used as expression.
|-
| Computed Array (Brace Construct) (*)
| <code>{ expr1 . expr2 . ... . exprN }</code>
|instantiates a new Array object with elements from the expressions.
|-
| Computed Inline Object (*)
| <code>{ foo: fooExpr . bar: barExpr }</code>
|fooExpr and barExpr: expressions
|-
| Inline string expressions (*)
| <code>e'p1{e1}p2{e2}...pN{eN}pM'</code>
|syntactic sugar for: <code>('p1%1p2%2...pN%NpM' bindWith:e1 with:e2 ... with:eN)</code> where each pI is a string with possible C-escapes and each eI is a Smalltalk expression
|-
| Array Indexing (*)
| <code>coll[idx]</code> <code>coll[idx1][idx2]</code> <code>coll[idx1][idx2][idx3]</code>
|syntactic sugar for: <code>(coll at:idx)</code> where coll must be an indexable collection, and idx of compatible index type. I.e. integer for array-like collections, hash-key for dictionaries, etc. Up to 4 dimensions are (currently supported)
|-
| Collection instantiation (*)
| <code>someClass[sz]</code> <code>someClass[sz][sz]</code> ...
|syntactic sugar for: <code>(someClass new:sz)</code> where someClass must be a collection class I.e. Array[10] creates an empty array with 10 slots. 1, 2, 3 and 4 dimensions are supported
|-

|}

==== Remaining Syntax ====

{| class="wikitable"
|-
| Local variables (in block or method)
| <code>| var1 var2 ... varN |</code>
|variable declarations must be at the beginning, before any expression.
|-
| Separating multiple expressions (sequence)
| <code>expr1 . expr2 . ... exprN</code>
|expressions (statements) are separated by fullstop (period) characters. The last expression may or may not be followed by a fullstop; if there is one, this is treated like a followup empty statement.
|-
| Return from method
| <code>^ expression</code>
|returns from the enclosing method (also if inside a block-closure)
|}

==== Wellknown (Common) Messages ====

{| class="wikitable"
|-
| Conditional Execution
| <code>boolExpr1 ifTrue:[ ... ] ifFalse:[ ... ]</code>
|variations without true-part, without false part and with the order reversed are available.
|-
| While-Loop (test at top)
| <code>[ boolExpr1 ] whileTrue:[ ... ]</code>
|notice the receiver being a block. A <code>whileFalse:</code> variant is also available.
|-
| Do-Loop (test at bottom)
| <code>[ ... ] doWhile:[ boolExpr1 ]</code>
|notice the test being a block. A <code>doUntil:</code> variant is also available.
|-
| For-Loop
| <code>start to:stop do:[:iterVar | ... ]</code>
|evaluates the block (lambda) for each value in start..stop.
|-
| Enumerating Collections
| <code>collection do:[:elementVar | ... ]</code>
|evaluates the block (i.e. lambda) for each element in the collection.
|-
| Evaluating a Lambda Block   without arguments:
  with arguments:
| <code>aBlock value</code><code>aBlock value:expr1 ... value:exprN</code>
|the number of arguments must match the number expected by the lambda (although varArg lambdas are also available)
|-
| Exception Handling
| <code>[ ... ] on:Error do:[:ex | ... ]</code>
|evaluates the first block; if an error is encountered, evaluate the handler
|}

==== Special 'Control Structures' ====

{| class="wikitable"
|-
| Starting another Thread
| <code>p := [ ... ] fork</code>
|the code inside the block will execute in a separate thread
|-
| Creating, configuring and starting another Thread
| <code>p := [ ... ]   newProcess;   name:'my worker';   priority:5;   resume</code>
|the code inside the block will execute in a separate thread
|-
| Terminating a Thread
| <code>p terminate</code>
|with p referring to the thread as created by newProcess or fork
|-
| Interrupting a Thread
| <code>p interruptWith:[ ... ]</code>
|interrupt the thread and let it execute the given code (in its interrupt seervice)
|-
| Exception Handling
| <code>[ ... ]   on:Error do:[:ex |     ...   ]</code>
|the handler will get an exception argument (ex), which contains additional information, and can be told how to deal with the error
|-
| Exception Handling - proceeding
| <code>[ ... ]   on:Error do:[:ex |     ...     ex proceed   ]</code>
|proceed, as if the error did not happen
|-
| Exception Handling - restarting
| <code>[ ... ]   on:Error do:[:ex |     ...     ex restart   ]</code>
|restart the code from the beginning (usually after the handler did some cleanup, such as lazy loading a missing file...)
|-
| Exception Handling - printing
| <code>[ ... ]   on:Error do:[:ex |     ...     ex description     ...   ]</code>
|contains a human readable description of the error
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ensure:[   ...   ]</code>
|the ensure block will be evaluated in any case
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ifCurtailed:[   ...   ]</code>
|the ifCurtailed block will be evaluated only on a non-regular exit (i.e. when an exception was raised, or the operation was aborted or the thread terminated)
|-
| Early exit from Loops
| <code>[:exit |   ...   code with loop   ...   exit value   ... ] valueWithExit</code>
|the block will be left, when exit is evaluated. Often used as argument of ifTrue:, as in cond ifTrue: exit
|-
| Queries
| <code>Query   answer:something   do:[     ...     Query query     ...   ]</code>
|to provide answers way down to whoever is interested. Queries answer nil if no one is there to answer. Queries are usually more specifically used as subclasses of Query
|-
| Notifications
| <code>Notification   handle:[     ...   ]   do:[     ...     Notification notify:someArg     ...   ]</code>
|to provide information way up to whoever is interested Notifications are usually more specifically used as subclasses of Notification
|-
| Observers 1
| <code>foo onChange:#bla evaluate:[...]. ... foo changed:#bla</code>
|observer with generic block to evaluate
|-
| Observers 2
| <code>foo onChangeSend:#xyz to:someone. ... foo changed</code>
|observer with message send
|-
| Observers 3
| <code>foo addDependent:someone. ... foo changed</code>
|observer with send to update method of target
|}

Queries and Notifications can be seen as observers within the calling hierarchy (i.e. information flows up or down the calling hierarchy), whereas the dependency and anChange mechanisms are independent of the control flow (even between different threads)

==== Synchronization and Timers ====
{| class="wikitable"
|-
| Timed Delay
| <code>Delay waitForSeconds:n</code> <code>Delay waitUntil:(Timestamp now + 10 seconds)</code>
|self explaining
|-
| Sempaphore wait
| <code>s := Semaphore new. ... s wait. ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Sempaphore wait with timeout
| <code>s := Semaphore new. ... s waitWithTimeout:(5 seconds). ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Multi Sempaphore wait
| <code>s1 := Semaphore new. s2 := Semaphore new. ... which := (s1 , s2) wait. ... s2 signal</code>
|wait for any of multiple semaphores
|-
| Synchronized Collections
| <code>a := OrderedCollection new asSharedCollection</code>
|will wrap the collection so that add/remove operations are atomic
|}

==== Wellknown Globals ====

{| class="wikitable"
|-
| Logging and Messaging
| <code>Transcript</code> - the console window <code>Stdout</code> - standard output <code>Stderr</code> - standard error <code>Stdin</code> - standard input <code>Logger</code> - redefinable logger (defaults to standard error)
|-
| Common Useful Dialogs
| <code>Dialog</code> - provides many useful utility functions for standard dialogs eg.<code> Dialog warn:'message' Dialog confirm:'question' Dialog request:'question' Dialog requestFilename:'question' ...</code>
|}

==== Most Wellknown Classes ====

{| class="wikitable"
|-
| Numbers
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Number Number]</code>(abstract superclass) <code>[http://live.exept.de/ClassDoc/classDocOf:,Integer Integer]</code>(integral numbers) <code>[http://live.exept.de/ClassDoc/classDocOf:,Float Float]</code>(inexact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Fraction Fraction]</code>(exact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Complex Complex]</code>
|-
| Collections
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Array Array]</code> (fixed size array) <code>[http://live.exept.de/ClassDoc/classDocOf:,OrderedCollection OrderedCollection]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,List List]</code> (variable size) <code>[http://live.exept.de/ClassDoc/classDocOf:,SortedCollection SortedCollection]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Set Set]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Bag Bag]</code> (unordered) <code>[http://live.exept.de/ClassDoc/classDocOf:,Dictionary Dictionary]</code> (mapped collections) <code>[http://live.exept.de/ClassDoc/classDocOf:,BinaryTree BinaryTree]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,AVLTree AVLTree]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,SharedQueue SharedQueue]</code> (shared, synchronized) many more...
|-
| Process Handling
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Process Process]</code> (lightweight thread) <code>[http://live.exept.de/ClassDoc/classDocOf:,OSProcess OSProcess]</code> (heavyweight OS process) <code>[http://live.exept.de/ClassDoc/classDocOf:,Semaphore Semaphore]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,RecursionLock RecursionLock]</code> (synchronization) <code>[http://live.exept.de/ClassDoc/classDocOf:,Monitor Monitor]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,BoltLock BoltLock]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Delay Delay]</code> (time delays)
|-
| Files & Streams
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Filename Filename]</code> (file naming, directory access, mime type) <code>[http://live.exept.de/ClassDoc/classDocOf:,Stream Stream]</code> (basic stream framework)
 <code>[http://live.exept.de/ClassDoc/classDocOf:,ReadStream ReadStream]</code>,<code>WriteStream</code>,<code>[http://live.exept.de/ClassDoc/classDocOf:,EncodedStream EncodedStream]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,ExternalStream ExternalStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,FileStream FileStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Socket Socket]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,PipeStream PipeStream]</code> (OS-cmd streams)
|-
| Low Level Access
| <code>[http://live.exept.de/ClassDoc/classDocOf:,OperatingSystem OperatingSystem]</code> (OS API calls) <code>[http://live.exept.de/ClassDoc/classDocOf:,Smalltalk Smalltalk]</code>(startup, shutdown and globals) <code>[http://live.exept.de/ClassDoc/classDocOf:,ObjectMemory ObjectMemory]</code>(VM access)
|}

== Examples ==

exampleMethod1
|v1 v2|

v1 := 42.
v2 := v1 sqrt.
Transcript showCR: 'the root of the answer to all questions is: %1' with: v2.

using expanded strings, this can be written as:

exampleMethod1_alternative
|v1|

v1 := 42.
Transcript showCR: e'the root of the answer to all questions is: {v1 sqrt}'.

enumerating elements of an array:

exampleMethod2
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr do:[:el |
Transcript showCR: el
]

enumerating elements of an array with additional index:

exampleMethod3
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr doWithIndex:[:el :idx |
Transcript showCR: e'array element at {idx} is {el} and its class is {el class name}\n'
]

dialogs, string-to-number conversion, error handling:

exampleMethod4
|s1 nr1 s2 nr2 rslt|

s1 := Dialog request:'Enter the first number' initialAnswer:1.
s1 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method
s2 := Dialog request:'Enter the second number' initialAnswer:2.
s2 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr1 := Number readFrom:s1 onError:[^ self].
nr2 := Number readFrom:s2 onError:[^ self].

"/ save division
[
rslt := nr1 / nr2
] on: Error do:[:ex |
(Dialog confirm: e'Error encountered: {ex description}\nProceed with zero?')
ifFalse:[^ self]. "/ no; return from method
ex proceedWith:0
].

Dialog information: e'the result is {rslt}'

dialogs, error handling and complex square root:

exampleMethod4
|s nr rslt|

s := Dialog request:'Enter a number (may be negative)' initialAnswer:2.
s isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr := Number readFrom:s onError:[^ self].

"/ square root; catch imaginary result
[
rslt := nr sqrt
] on: ImaginaryResultError do:[:ex |
(Dialog confirm: e'No solution in R; want to see the complex result?')
ifFalse:[^ self]. "/ no; return from method
rslt := Number trapImaginary:[ nr sqrt ].
"/ rslt is now a complex number
].

Dialog information: e'the result is {rslt}'

== Standard ==
The ANSI Smalltalk standard was approved on May 19, 1998. The official name of the document is ANSI INCITS 319-1998 (R2002). You can order a copy of the final standard
from here: [http://www.techstreet.com/cgi-bin/detail?product_id=56122]
or here [http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI+INCITS+319%2D1998+%28R2002%29]. The name of the document is "American National Standard for Information Systems - Programming Languages - Smalltalk".

You can also download the final draft revision for free: standard_v1_9-indexed.pdf and at [https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf].

The final draft is identical to the official standard except that the draft also has a rationale included (and thus, the draft is arguably more useful than the official standard).

Protocol from ANSI Meeting: [http://www.netjam.org/smalltalk/faq/ANSI-meeting.html]

== Common Language Extensions ==
These are also found in other Smalltalk dialects (eg. [[Glossary#VW|VW]] or [[Glossary#Squeak|Squeak]])

* { expr1 . expr2 . ... } Brace Array Construction Each expression is evaluated (left to right), and an Array with the results is created at execution time. Notice that separating full stops are required, as opposed to constant literal arrays, where elements are separated by spaces. The generated Array is mutable (can be modified), whereas a constant array is not.

== Summary of Smalltalk/X Language Extensions ==

These are ST/X specific, and not (as of 2026) implemented in other Smalltalk systems.

=== Comments ===
* "/ End of line comment
* "<<X ... X token delimited comment; X can be any word and a line starting with X ends the comment

=== String Literals ===
* c'...' ''c-strings'' C-like escapes (\n, \t, \xNN, \uNNNN) inside the string are expanded.

* e' ... {expr} ...' ''e-strings'' (expanded epression strings) In addition to C-escapes, embedded expressions are evaluated and their printString is sliced in. Technically, it is converted to ' ... %1 ...' and then expanded using standard String methods.

* i' ... {expr} ...' ''i-strings'' (international strings) similar to e-strings, but the converted string ('... %1 ...') is translated to a national string (via the *.rs file) and then expanded. Allows for different word ordering.

=== Integer Literals ===
* 0xNNNN, 0oNNNN, 0bNNNN C-style hex, octal and binary integers. With arbitrary precision

=== Float Literals ===
* <f>q, <f>Q, etc. Float literal type suffix (q, Q, QD, QL, QO) For a complete list and spec., see the Number documentation.

=== Compact Number Arrays ===
* #u1, #u8, #u16, #u32, #u64 #i8, #i16, #i32, #i64 #f16, #bf16, #f32, #f64 Will generate dense packed vectors (similar to byteArray); format is #X(n1 n2 ... )

Smalltalk Syntax Cheat Sheet

2026-06-07T06:20:38Z

Cg: /* Smalltalk/X Language Extensions */

A short, one page summary of what beginners need to know about Smalltalk/X, its syntax and most useful code fragments. As usual, this is only a tiny fraction of what is really awailable, and you should use the builtin class browser to find many more useful functions in the system.

This page was extracted from the "Smalltalk/X Programmers guide - Smalltalk/X Cheat Sheet".
 Smalltalk/X language extensions (w.r.t. other Smalltalk implementations) are marked with '''(*)'''.

== Smalltalk Philosophy ==

* The world consists of objects which '''communicate by sending messages'''.
: A message looks like an english sentence, and might look like "<code>heyYou doSomething</code>".
: In this example, the "heyYou" is called the "''receiver of the message''"
: You may pass additional parameter objects (arguments) as in: "<code>heyYou doSomethingWith: arg</code>"
: or multiple arguments as in <code>"heyYou doSomethingWith: arg1 and: arg2"</code>
: In these examples, the "<code>heyYou</code>" is called the "''receiver of the message''"
* Messages without argument are called "''unary messages''"; those with arguments are called "''keyword messages''"
: For example "<code>Transcript clear</code>" (sends the message "clear" to the Transcript object),
: and "<code>Transcript show: 'hello'</code>" (sends the message "show:" to the Transcript, passing a string argument),
* To allow for arithmetic operations, any non-letter character (except for a few) are treated like a message name and written between the receiver and the one and only argument. These are called "''binary messages''".
: For example: <code>"3 + 4"</code> or <code>"abc , def"</code> (yes, the comma is an operator; it does string concatenation)
* The object my respond (or "answer") by returning some result object. In the above example, "<code>3+4</code>" would answer "7", and "<code>'hello' , 'world'</code>" would answer 'helloworld'
* binary messages have no meaning to the compiler; they are all equal and simply evaluated from left to right.
: admitted, this makes arithmetic a little strange initially; you'll need parentheses as the is not precidence of eg. * over +. The expression "3 + 4 * 5" will be evaluated left to right and answer 35.
* Everything in this world is an object;
: from low level things like booleans, true, false, integer numbers, floating point numbers characters etc.
: there are containers, which can hold on other objects. Technically, all such references are via pointers.
: there are also very complex objects and structures which implement windows, the user interface, communication interfaces, debuggers and even compilers which allow for code to be defined and installed on the fly.
* Every object is associated to a class. Classes define the behavior of their instances. I.e. they define how they respond to messages. The response is implemented by a so called ''method''. That is a piece of code which is executed when a message comes in. A method consist of a number of statements (which are message sends), each separated by a full stop (as in english).
* Classes are themself objects, which respond to messages. Typically class messages would answer new instances, constants or utility functionality. There are also class messages to create new classes.
* Class can inherit common functionality (i.e. method implementations) from a superclass. Thus creating a hierarchy of classes. Typical hierarchies are the Number hierarchy, Collections, Streams and UI Widgets.
* In Smalltalk, every behavior is defined by corresponding message implementations. This includes control features (i.e. if-then-else, loops and exception handling). All of them are implemented as messages being sent to booleans (ifTrue:/ifFalse:) or blocks (whileTrue:)
* Blocks are special objects, which wrap a piece of code. Other languages know them as anonymous functions or lambdas or closures. But the Smalltalk syntax makes them super easy to use: just write a number of expressions inside square brackets, as in "<code>[ Transcript show: 10 factorial ]</code>".
: blocks can be passed as argument with a message send; for example to a boolean: "<code>aBoolean ifTrue: [ Transcript show: 'yes' ]</code>"
: blocks can be stored in variables and passed arounf just like any other object
: blocks can receive messages, especially loop messages: "<code>[ a < 10] whileTrue:[ Transcript showCR: a. a := a + 1 ]</code>".

== Syntax ==

==== Comments ====

{| class="wikitable"
|-
| Regular comment
| <code>" this is a comment "</code>
| ''any text between double quotes''
|-
| EOL-Comment (*)
| <code>"/ this is an End-of-Line comment</code>
| ''text from quote-slash to line end''
|-
| Token-Comment (*)
| <code>"<<END a multiline token-comment up to a line starting with 'END' more commented stuff here ... comment ends here END</code>
| ''text up to line beginning with whatever token came after the initial "<<" ''
|}

==== Literal Constants ====

===== Numbers =====

{| class="wikitable"
|-
| Integers</td>
| <code>12345</code> </code>-12345<code>
|
|-
| Large integers
| <code>1234567890123456789012345</code>…
| ''arbitrary number of digits''
|-
| Integers with radix (Smalltalk style)
| <code>16rAFFE</code>, <code>2r010101</code>, <code>8r0777</code>, <code>3r012012</code>, <code>16r-AFFE</code>, <code>2r-010101</code>
| ''prepend the radix (base) any radix from 2..36 is possible (i.e. 3r222 is a ternary number)''
|-
| Integers with radix (C style) (*)
| <code>0xFEED</code> <code>-0xBEAF</code> <code>0b11011</code>,<code>-0b1100</code>
| ''C/Java/JavaScript style: prepend radix indicator ('x', 'b', 'o') One of hex, binary and octal''
|-
| Floats (IEEE double; roughly 17 digits)
| 12.456 1.234e17 -6.9 -6e-10 Float pi Float e
| ''called "Float", but actually hold double precision Common constants can be referred to "by name".''
|-
| Short floats (IEEE single; roughly 8 digits) (*)
| <code>1.234e17f</code> <code>-6e-10f</code>
| <strike>''this is controlled by a ParserFlag (singlePrecisionFloatF), which is currently defaulted to false. Thus, by default, double precision floats are created with the 'f' exponent character.''</strike>
|-
| Long floats (IEEE extended; roughly 20 digits) (*)
| <code>1.234e17q</code> <code>-6q-10q</code>
| ''actual precision depends on the underlying CPU (x86/x86_64: 80bit; Sparc: 128 bit)
|-
| Quad floats; (IEEE quad; roughly 34 digits (*)
| <code>1.234e17Q</code> <code>-6e-10Q</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Octuple floats; roughly 60 digits (*)
| <code>1.234e17QO</code> <code>-6e-10QP</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Large floats; roughly 60 digits by default, but any precision possible (*)
| <code>1.234e17QL</code> <code>-6e-10QL</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Fractions
| <code>(1/3)</code> <code>(17/2)</code>
|
|-
| ScaledDecimals
| <code>1234.53s2</code>
| the number after the s specifies the number of digits
|}

===== Characters and Strings =====

{| class="wikitable"
|-
| Characters
| <code>$a</code> <code>Character space</code> <code>Character nl</code> Also: "<code>null</code>", "<code>tab</code>", "<code>return</code>", "<code>bell</code>"... Or: <code>Character codePoint:n</code>
| ''Smalltalk does not support any escape sequence Common constants can be referred to "by name".''
|-
| Strings
| <code>'hello'</code>
| ''traditionally, Smalltalk does not support any escape sequence inside (i.e. they are what Python calls "Raw Strings") But see below...''
|-
| Strings (C Style) (*)
| <code>c'hello\nworld'</code>
| ''supports the common C-escape sequences, such as "\n", "\t", "\xHH", "\uXXXX"''
|-
| Strings (with embedded expressios) (*)
| <code>e'hello {OperatingSystem getLoginName}'</code>
| ''expanded expression strings expressions in braces are evaluated at runtime and sliced into the string (also a C-string). Similar to python's f-strings.''
|-
| Strings (national language translated with embedded expressios) (*)
| <code>i'hello {OperatingSystem getLoginName}'</code>
| ''international strings like above, but the string is also possibly translated to a national language''
|-
| Symbols
| <code>#'hello'</code> <code>#foo</code> <code>#+</code>
| ''symbols are interned strings; two symbols with the same characters are guaranteed to be the identical object (not just equal) without quotes, if only alphaNumeric characters''
|}

===== Arrays and Objects =====
{| class="wikitable"
|-
| Arrays 
| <code>#( el1 el2 ... elN )</code>
| each element is a literal constant
|-
| Byte Arrays
| <code>#[ b1 b2 ... bN ]</code>
| each byte-element an integer constant in 0..255
|-
| Special Number Arrays (*)
| <code>#XX( v1 v2 ... vN )</code>
| XX: is one of  'u8', 's8', 'u16', 's16', 'u32', 's32', 'u64', 's64', 'f32', 'f64'  and each element being an integer or float constant
|-
| Immediate Inline Objects (*)
| <code>#{ foo: fooValue . bar: barValue }</code>
| fooValue and barValue: are constants
|}

==== Lambda Blocks (Closures) ====

{| class="wikitable"
|-
| Without argument
| <code>[ expr1 . expr2 ... exprN ]</code>
| multiple expressions sep'd by period. When evaluated, the value is the value from the last expression, exprN
|-
| One argument
| <code>[ :arg |     expr1 . expr2 ... exprN ]</code>
|-
| Multiple arguments
| <code>[ :a1 :a2 ... :aN |     expr1 . expr2 ... exprN ]</code>
|-
| Local Variables inside a block
| <code>[ :a1 ... :aN |      |local1 local2 |      expr1 ... exprN ]</code>
|}

==== Expressions ====

{| class="wikitable"
|-
| Unary Expression (without argument)
| <code>receiver messageName</code>
|receiver is itself either a constant, a lambda-block, a unary expression or a parenthesized expression
|-
| Keyword Expression (1 arg)
| <code>receiver messageNamePart:argExpression</code>
|whitespace between the colon and the argExpression is optional.
|-
| Keyword Expression (any number of args)
| <code>receiver     messageNamePart1:argExpression1     messageNamePart2:argExpression2     ...     messageNamePartN:argExpressionN</code>
|-
| Binary Expression
| <code>receiver binOP arg</code>
|with binOP being any combination of special characters: * , + , - , % , & , / , \ , | , = , < , > , ? and ,
 I.e. "<code>foo ==> 123</code>" is the binary message "<code>==></code>" sent to <code>foo</code> with <code>123</code> as argument.
 And "<code>foo ? 123</code>" is the binary message "<code>?</code>" sent to <code>foo</code> with <code>123</code> as argument.
|-
| Cascade Expression (multiple messages to the same receiver)
| <code>receiver     message1 ;     message2 ;     ...     messageN</code></td>
|the receiver expression is evaluated, then multiple messages (separated by ";") are sent to this receiver.
|-
| Parentheses for grouping
| <code>( any expression )</code>
|-
| Assignment
| <code>variable := expression</code>
|can be used as expression.
|-
| Computed Array (Brace Construct) (*)
| <code>{ expr1 . expr2 . ... . exprN }</code>
|instantiates a new Array object with elements from the expressions.
|-
| Computed Inline Object (*)
| <code>{ foo: fooExpr . bar: barExpr }</code>
|fooExpr and barExpr: expressions
|-
| Inline string expressions (*)
| <code>e'p1{e1}p2{e2}...pN{eN}pM'</code>
|syntactic sugar for: <code>('p1%1p2%2...pN%NpM' bindWith:e1 with:e2 ... with:eN)</code> where each pI is a string with possible C-escapes and each eI is a Smalltalk expression
|-
| Array Indexing (*)
| <code>coll[idx]</code> <code>coll[idx1][idx2]</code> <code>coll[idx1][idx2][idx3]</code>
|syntactic sugar for: <code>(coll at:idx)</code> where coll must be an indexable collection, and idx of compatible index type. I.e. integer for array-like collections, hash-key for dictionaries, etc. Up to 4 dimensions are (currently supported)
|-
| Collection instantiation (*)
| <code>someClass[sz]</code> <code>someClass[sz][sz]</code> ...
|syntactic sugar for: <code>(someClass new:sz)</code> where someClass must be a collection class I.e. Array[10] creates an empty array with 10 slots. 1, 2, 3 and 4 dimensions are supported
|-

|}

==== Remaining Syntax ====

{| class="wikitable"
|-
| Local variables (in block or method)
| <code>| var1 var2 ... varN |</code>
|variable declarations must be at the beginning, before any expression.
|-
| Separating multiple expressions (sequence)
| <code>expr1 . expr2 . ... exprN</code>
|expressions (statements) are separated by fullstop (period) characters. The last expression may or may not be followed by a fullstop; if there is one, this is treated like a followup empty statement.
|-
| Return from method
| <code>^ expression</code>
|returns from the enclosing method (also if inside a block-closure)
|}

==== Wellknown (Common) Messages ====

{| class="wikitable"
|-
| Conditional Execution
| <code>boolExpr1 ifTrue:[ ... ] ifFalse:[ ... ]</code>
|variations without true-part, without false part and with the order reversed are available.
|-
| While-Loop (test at top)
| <code>[ boolExpr1 ] whileTrue:[ ... ]</code>
|notice the receiver being a block. A <code>whileFalse:</code> variant is also available.
|-
| Do-Loop (test at bottom)
| <code>[ ... ] doWhile:[ boolExpr1 ]</code>
|notice the test being a block. A <code>doUntil:</code> variant is also available.
|-
| For-Loop
| <code>start to:stop do:[:iterVar | ... ]</code>
|evaluates the block (lambda) for each value in start..stop.
|-
| Enumerating Collections
| <code>collection do:[:elementVar | ... ]</code>
|evaluates the block (i.e. lambda) for each element in the collection.
|-
| Evaluating a Lambda Block   without arguments:
  with arguments:
| <code>aBlock value</code><code>aBlock value:expr1 ... value:exprN</code>
|the number of arguments must match the number expected by the lambda (although varArg lambdas are also available)
|-
| Exception Handling
| <code>[ ... ] on:Error do:[:ex | ... ]</code>
|evaluates the first block; if an error is encountered, evaluate the handler
|}

==== Special 'Control Structures' ====

{| class="wikitable"
|-
| Starting another Thread
| <code>p := [ ... ] fork</code>
|the code inside the block will execute in a separate thread
|-
| Creating, configuring and starting another Thread
| <code>p := [ ... ]   newProcess;   name:'my worker';   priority:5;   resume</code>
|the code inside the block will execute in a separate thread
|-
| Terminating a Thread
| <code>p terminate</code>
|with p referring to the thread as created by newProcess or fork
|-
| Interrupting a Thread
| <code>p interruptWith:[ ... ]</code>
|interrupt the thread and let it execute the given code (in its interrupt seervice)
|-
| Exception Handling
| <code>[ ... ]   on:Error do:[:ex |     ...   ]</code>
|the handler will get an exception argument (ex), which contains additional information, and can be told how to deal with the error
|-
| Exception Handling - proceeding
| <code>[ ... ]   on:Error do:[:ex |     ...     ex proceed   ]</code>
|proceed, as if the error did not happen
|-
| Exception Handling - restarting
| <code>[ ... ]   on:Error do:[:ex |     ...     ex restart   ]</code>
|restart the code from the beginning (usually after the handler did some cleanup, such as lazy loading a missing file...)
|-
| Exception Handling - printing
| <code>[ ... ]   on:Error do:[:ex |     ...     ex description     ...   ]</code>
|contains a human readable description of the error
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ensure:[   ...   ]</code>
|the ensure block will be evaluated in any case
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ifCurtailed:[   ...   ]</code>
|the ifCurtailed block will be evaluated only on a non-regular exit (i.e. when an exception was raised, or the operation was aborted or the thread terminated)
|-
| Early exit from Loops
| <code>[:exit |   ...   code with loop   ...   exit value   ... ] valueWithExit</code>
|the block will be left, when exit is evaluated. Often used as argument of ifTrue:, as in cond ifTrue: exit
|-
| Queries
| <code>Query   answer:something   do:[     ...     Query query     ...   ]</code>
|to provide answers way down to whoever is interested. Queries answer nil if no one is there to answer. Queries are usually more specifically used as subclasses of Query
|-
| Notifications
| <code>Notification   handle:[     ...   ]   do:[     ...     Notification notify:someArg     ...   ]</code>
|to provide information way up to whoever is interested Notifications are usually more specifically used as subclasses of Notification
|-
| Observers 1
| <code>foo onChange:#bla evaluate:[...]. ... foo changed:#bla</code>
|observer with generic block to evaluate
|-
| Observers 2
| <code>foo onChangeSend:#xyz to:someone. ... foo changed</code>
|observer with message send
|-
| Observers 3
| <code>foo addDependent:someone. ... foo changed</code>
|observer with send to update method of target
|}

Queries and Notifications can be seen as observers within the calling hierarchy (i.e. information flows up or down the calling hierarchy), whereas the dependency and anChange mechanisms are independent of the control flow (even between different threads)

==== Synchronization and Timers ====
{| class="wikitable"
|-
| Timed Delay
| <code>Delay waitForSeconds:n</code> <code>Delay waitUntil:(Timestamp now + 10 seconds)</code>
|self explaining
|-
| Sempaphore wait
| <code>s := Semaphore new. ... s wait. ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Sempaphore wait with timeout
| <code>s := Semaphore new. ... s waitWithTimeout:(5 seconds). ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Multi Sempaphore wait
| <code>s1 := Semaphore new. s2 := Semaphore new. ... which := (s1 , s2) wait. ... s2 signal</code>
|wait for any of multiple semaphores
|-
| Synchronized Collections
| <code>a := OrderedCollection new asSharedCollection</code>
|will wrap the collection so that add/remove operations are atomic
|}

==== Wellknown Globals ====

{| class="wikitable"
|-
| Logging and Messaging
| <code>Transcript</code> - the console window <code>Stdout</code> - standard output <code>Stderr</code> - standard error <code>Stdin</code> - standard input <code>Logger</code> - redefinable logger (defaults to standard error)
|-
| Common Useful Dialogs
| <code>Dialog</code> - provides many useful utility functions for standard dialogs eg.<code> Dialog warn:'message' Dialog confirm:'question' Dialog request:'question' Dialog requestFilename:'question' ...</code>
|}

==== Most Wellknown Classes ====

{| class="wikitable"
|-
| Numbers
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Number Number]</code>(abstract superclass) <code>[http://live.exept.de/ClassDoc/classDocOf:,Integer Integer]</code>(integral numbers) <code>[http://live.exept.de/ClassDoc/classDocOf:,Float Float]</code>(inexact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Fraction Fraction]</code>(exact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Complex Complex]</code>
|-
| Collections
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Array Array]</code> (fixed size array) <code>[http://live.exept.de/ClassDoc/classDocOf:,OrderedCollection OrderedCollection]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,List List]</code> (variable size) <code>[http://live.exept.de/ClassDoc/classDocOf:,SortedCollection SortedCollection]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Set Set]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Bag Bag]</code> (unordered) <code>[http://live.exept.de/ClassDoc/classDocOf:,Dictionary Dictionary]</code> (mapped collections) <code>[http://live.exept.de/ClassDoc/classDocOf:,BinaryTree BinaryTree]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,AVLTree AVLTree]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,SharedQueue SharedQueue]</code> (shared, synchronized) many more...
|-
| Process Handling
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Process Process]</code> (lightweight thread) <code>[http://live.exept.de/ClassDoc/classDocOf:,OSProcess OSProcess]</code> (heavyweight OS process) <code>[http://live.exept.de/ClassDoc/classDocOf:,Semaphore Semaphore]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,RecursionLock RecursionLock]</code> (synchronization) <code>[http://live.exept.de/ClassDoc/classDocOf:,Monitor Monitor]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,BoltLock BoltLock]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Delay Delay]</code> (time delays)
|-
| Files & Streams
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Filename Filename]</code> (file naming, directory access, mime type) <code>[http://live.exept.de/ClassDoc/classDocOf:,Stream Stream]</code> (basic stream framework)
 <code>[http://live.exept.de/ClassDoc/classDocOf:,ReadStream ReadStream]</code>,<code>WriteStream</code>,<code>[http://live.exept.de/ClassDoc/classDocOf:,EncodedStream EncodedStream]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,ExternalStream ExternalStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,FileStream FileStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Socket Socket]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,PipeStream PipeStream]</code> (OS-cmd streams)
|-
| Low Level Access
| <code>[http://live.exept.de/ClassDoc/classDocOf:,OperatingSystem OperatingSystem]</code> (OS API calls) <code>[http://live.exept.de/ClassDoc/classDocOf:,Smalltalk Smalltalk]</code>(startup, shutdown and globals) <code>[http://live.exept.de/ClassDoc/classDocOf:,ObjectMemory ObjectMemory]</code>(VM access)
|}

== Examples ==

exampleMethod1
|v1 v2|

v1 := 42.
v2 := v1 sqrt.
Transcript showCR: 'the root of the answer to all questions is: %1' with: v2.

using expanded strings, this can be written as:

exampleMethod1_alternative
|v1|

v1 := 42.
Transcript showCR: e'the root of the answer to all questions is: {v1 sqrt}'.

enumerating elements of an array:

exampleMethod2
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr do:[:el |
Transcript showCR: el
]

enumerating elements of an array with additional index:

exampleMethod3
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr doWithIndex:[:el :idx |
Transcript showCR: e'array element at {idx} is {el} and its class is {el class name}\n'
]

dialogs, string-to-number conversion, error handling:

exampleMethod4
|s1 nr1 s2 nr2 rslt|

s1 := Dialog request:'Enter the first number' initialAnswer:1.
s1 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method
s2 := Dialog request:'Enter the second number' initialAnswer:2.
s2 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr1 := Number readFrom:s1 onError:[^ self].
nr2 := Number readFrom:s2 onError:[^ self].

"/ save division
[
rslt := nr1 / nr2
] on: Error do:[:ex |
(Dialog confirm: e'Error encountered: {ex description}\nProceed with zero?')
ifFalse:[^ self]. "/ no; return from method
ex proceedWith:0
].

Dialog information: e'the result is {rslt}'

dialogs, error handling and complex square root:

exampleMethod4
|s nr rslt|

s := Dialog request:'Enter a number (may be negative)' initialAnswer:2.
s isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr := Number readFrom:s onError:[^ self].

"/ square root; catch imaginary result
[
rslt := nr sqrt
] on: ImaginaryResultError do:[:ex |
(Dialog confirm: e'No solution in R; want to see the complex result?')
ifFalse:[^ self]. "/ no; return from method
rslt := Number trapImaginary:[ nr sqrt ].
"/ rslt is now a complex number
].

Dialog information: e'the result is {rslt}'

== Standard ==
The ANSI Smalltalk standard was approved on May 19, 1998. The official name of the document is ANSI INCITS 319-1998 (R2002). You can order a copy of the final standard
from here: [http://www.techstreet.com/cgi-bin/detail?product_id=56122]
or here [http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI+INCITS+319%2D1998+%28R2002%29]. The name of the document is "American National Standard for Information Systems - Programming Languages - Smalltalk".

You can also download the final draft revision for free: standard_v1_9-indexed.pdf and at [https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf].

The final draft is identical to the official standard except that the draft also has a rationale included (and thus, the draft is arguably more useful than the official standard).

Protocol from ANSI Meeting: [http://www.netjam.org/smalltalk/faq/ANSI-meeting.html]

== Common Language Extensions ==
These are also found in other Smalltalk dialects (eg. [[Glossary#VW|VW]] or [[Glossary#Squeak|Squeak]])

* { expr1 . expr2 . ... } Brace Array Construction Each expression is evaluated (left to right), and an Array with the results is created at execution time. Notice that separating full stops are required, as opposed to constant literal arrays, where elements are separated by spaces. The generated Array is mutable (can be modified), whereas a constant array is not.

== Summary of Smalltalk/X Language Extensions ==

These are ST/X specific, and not (as of 2026) implemented in other Smalltalk systems.

=== Comments ===
* "/ End of line comment
* "<<X ... X token delimited comment

=== String Literals ===
* c'...' ''c-strings'' C-like escapes (\n, \t, \xNN, \uNNNN) inside the string are expanded.

* e' ... {expr} ...' ''e-strings'' (expanded epression strings) In addition to C-escapes, embedded expressions are evaluated and their printString is sliced in. Technically, it is converted to ' ... %1 ...' and then expanded using standard String methods.

* i' ... {expr} ...' ''i-strings'' (international strings) similar to e-strings, but the converted string ('... %1 ...') is translated to a national string (via the *.rs file) and then expanded. Allows for different word ordering.

=== Integer Literals ===
* 0xNNNN, 0oNNNN, 0bNNNN C-style hex, octal and binary integers. With arbitrary precision

=== Float Literals ===
* <f>q, <f>Q, etc. Float literal type suffix (q, Q, QD, QL, QO) For a complete list and spec., see the Number documentation.

=== Compact Number Arrays ===
* #u1, #u8, #u16, #u32, #u64 #i8, #i16, #i32, #i64 #f16, #bf16, #f32, #f64 Will generate dense packed vectors (similar to byteArray); format is #X(n1 n2 ... )

Smalltalk Syntax Cheat Sheet

2026-06-07T06:18:25Z

Cg: /* Characters and Strings */

A short, one page summary of what beginners need to know about Smalltalk/X, its syntax and most useful code fragments. As usual, this is only a tiny fraction of what is really awailable, and you should use the builtin class browser to find many more useful functions in the system.

This page was extracted from the "Smalltalk/X Programmers guide - Smalltalk/X Cheat Sheet".
 Smalltalk/X language extensions (w.r.t. other Smalltalk implementations) are marked with '''(*)'''.

== Smalltalk Philosophy ==

* The world consists of objects which '''communicate by sending messages'''.
: A message looks like an english sentence, and might look like "<code>heyYou doSomething</code>".
: In this example, the "heyYou" is called the "''receiver of the message''"
: You may pass additional parameter objects (arguments) as in: "<code>heyYou doSomethingWith: arg</code>"
: or multiple arguments as in <code>"heyYou doSomethingWith: arg1 and: arg2"</code>
: In these examples, the "<code>heyYou</code>" is called the "''receiver of the message''"
* Messages without argument are called "''unary messages''"; those with arguments are called "''keyword messages''"
: For example "<code>Transcript clear</code>" (sends the message "clear" to the Transcript object),
: and "<code>Transcript show: 'hello'</code>" (sends the message "show:" to the Transcript, passing a string argument),
* To allow for arithmetic operations, any non-letter character (except for a few) are treated like a message name and written between the receiver and the one and only argument. These are called "''binary messages''".
: For example: <code>"3 + 4"</code> or <code>"abc , def"</code> (yes, the comma is an operator; it does string concatenation)
* The object my respond (or "answer") by returning some result object. In the above example, "<code>3+4</code>" would answer "7", and "<code>'hello' , 'world'</code>" would answer 'helloworld'
* binary messages have no meaning to the compiler; they are all equal and simply evaluated from left to right.
: admitted, this makes arithmetic a little strange initially; you'll need parentheses as the is not precidence of eg. * over +. The expression "3 + 4 * 5" will be evaluated left to right and answer 35.
* Everything in this world is an object;
: from low level things like booleans, true, false, integer numbers, floating point numbers characters etc.
: there are containers, which can hold on other objects. Technically, all such references are via pointers.
: there are also very complex objects and structures which implement windows, the user interface, communication interfaces, debuggers and even compilers which allow for code to be defined and installed on the fly.
* Every object is associated to a class. Classes define the behavior of their instances. I.e. they define how they respond to messages. The response is implemented by a so called ''method''. That is a piece of code which is executed when a message comes in. A method consist of a number of statements (which are message sends), each separated by a full stop (as in english).
* Classes are themself objects, which respond to messages. Typically class messages would answer new instances, constants or utility functionality. There are also class messages to create new classes.
* Class can inherit common functionality (i.e. method implementations) from a superclass. Thus creating a hierarchy of classes. Typical hierarchies are the Number hierarchy, Collections, Streams and UI Widgets.
* In Smalltalk, every behavior is defined by corresponding message implementations. This includes control features (i.e. if-then-else, loops and exception handling). All of them are implemented as messages being sent to booleans (ifTrue:/ifFalse:) or blocks (whileTrue:)
* Blocks are special objects, which wrap a piece of code. Other languages know them as anonymous functions or lambdas or closures. But the Smalltalk syntax makes them super easy to use: just write a number of expressions inside square brackets, as in "<code>[ Transcript show: 10 factorial ]</code>".
: blocks can be passed as argument with a message send; for example to a boolean: "<code>aBoolean ifTrue: [ Transcript show: 'yes' ]</code>"
: blocks can be stored in variables and passed arounf just like any other object
: blocks can receive messages, especially loop messages: "<code>[ a < 10] whileTrue:[ Transcript showCR: a. a := a + 1 ]</code>".

== Syntax ==

==== Comments ====

{| class="wikitable"
|-
| Regular comment
| <code>" this is a comment "</code>
| ''any text between double quotes''
|-
| EOL-Comment (*)
| <code>"/ this is an End-of-Line comment</code>
| ''text from quote-slash to line end''
|-
| Token-Comment (*)
| <code>"<<END a multiline token-comment up to a line starting with 'END' more commented stuff here ... comment ends here END</code>
| ''text up to line beginning with whatever token came after the initial "<<" ''
|}

==== Literal Constants ====

===== Numbers =====

{| class="wikitable"
|-
| Integers</td>
| <code>12345</code> </code>-12345<code>
|
|-
| Large integers
| <code>1234567890123456789012345</code>…
| ''arbitrary number of digits''
|-
| Integers with radix (Smalltalk style)
| <code>16rAFFE</code>, <code>2r010101</code>, <code>8r0777</code>, <code>3r012012</code>, <code>16r-AFFE</code>, <code>2r-010101</code>
| ''prepend the radix (base) any radix from 2..36 is possible (i.e. 3r222 is a ternary number)''
|-
| Integers with radix (C style) (*)
| <code>0xFEED</code> <code>-0xBEAF</code> <code>0b11011</code>,<code>-0b1100</code>
| ''C/Java/JavaScript style: prepend radix indicator ('x', 'b', 'o') One of hex, binary and octal''
|-
| Floats (IEEE double; roughly 17 digits)
| 12.456 1.234e17 -6.9 -6e-10 Float pi Float e
| ''called "Float", but actually hold double precision Common constants can be referred to "by name".''
|-
| Short floats (IEEE single; roughly 8 digits) (*)
| <code>1.234e17f</code> <code>-6e-10f</code>
| <strike>''this is controlled by a ParserFlag (singlePrecisionFloatF), which is currently defaulted to false. Thus, by default, double precision floats are created with the 'f' exponent character.''</strike>
|-
| Long floats (IEEE extended; roughly 20 digits) (*)
| <code>1.234e17q</code> <code>-6q-10q</code>
| ''actual precision depends on the underlying CPU (x86/x86_64: 80bit; Sparc: 128 bit)
|-
| Quad floats; (IEEE quad; roughly 34 digits (*)
| <code>1.234e17Q</code> <code>-6e-10Q</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Octuple floats; roughly 60 digits (*)
| <code>1.234e17QO</code> <code>-6e-10QP</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Large floats; roughly 60 digits by default, but any precision possible (*)
| <code>1.234e17QL</code> <code>-6e-10QL</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Fractions
| <code>(1/3)</code> <code>(17/2)</code>
|
|-
| ScaledDecimals
| <code>1234.53s2</code>
| the number after the s specifies the number of digits
|}

===== Characters and Strings =====

{| class="wikitable"
|-
| Characters
| <code>$a</code> <code>Character space</code> <code>Character nl</code> Also: "<code>null</code>", "<code>tab</code>", "<code>return</code>", "<code>bell</code>"... Or: <code>Character codePoint:n</code>
| ''Smalltalk does not support any escape sequence Common constants can be referred to "by name".''
|-
| Strings
| <code>'hello'</code>
| ''traditionally, Smalltalk does not support any escape sequence inside (i.e. they are what Python calls "Raw Strings") But see below...''
|-
| Strings (C Style) (*)
| <code>c'hello\nworld'</code>
| ''supports the common C-escape sequences, such as "\n", "\t", "\xHH", "\uXXXX"''
|-
| Strings (with embedded expressios) (*)
| <code>e'hello {OperatingSystem getLoginName}'</code>
| ''expanded expression strings expressions in braces are evaluated at runtime and sliced into the string (also a C-string). Similar to python's f-strings.''
|-
| Strings (national language translated with embedded expressios) (*)
| <code>i'hello {OperatingSystem getLoginName}'</code>
| ''international strings like above, but the string is also possibly translated to a national language''
|-
| Symbols
| <code>#'hello'</code> <code>#foo</code> <code>#+</code>
| ''symbols are interned strings; two symbols with the same characters are guaranteed to be the identical object (not just equal) without quotes, if only alphaNumeric characters''
|}

===== Arrays and Objects =====
{| class="wikitable"
|-
| Arrays 
| <code>#( el1 el2 ... elN )</code>
| each element is a literal constant
|-
| Byte Arrays
| <code>#[ b1 b2 ... bN ]</code>
| each byte-element an integer constant in 0..255
|-
| Special Number Arrays (*)
| <code>#XX( v1 v2 ... vN )</code>
| XX: is one of  'u8', 's8', 'u16', 's16', 'u32', 's32', 'u64', 's64', 'f32', 'f64'  and each element being an integer or float constant
|-
| Immediate Inline Objects (*)
| <code>#{ foo: fooValue . bar: barValue }</code>
| fooValue and barValue: are constants
|}

==== Lambda Blocks (Closures) ====

{| class="wikitable"
|-
| Without argument
| <code>[ expr1 . expr2 ... exprN ]</code>
| multiple expressions sep'd by period. When evaluated, the value is the value from the last expression, exprN
|-
| One argument
| <code>[ :arg |     expr1 . expr2 ... exprN ]</code>
|-
| Multiple arguments
| <code>[ :a1 :a2 ... :aN |     expr1 . expr2 ... exprN ]</code>
|-
| Local Variables inside a block
| <code>[ :a1 ... :aN |      |local1 local2 |      expr1 ... exprN ]</code>
|}

==== Expressions ====

{| class="wikitable"
|-
| Unary Expression (without argument)
| <code>receiver messageName</code>
|receiver is itself either a constant, a lambda-block, a unary expression or a parenthesized expression
|-
| Keyword Expression (1 arg)
| <code>receiver messageNamePart:argExpression</code>
|whitespace between the colon and the argExpression is optional.
|-
| Keyword Expression (any number of args)
| <code>receiver     messageNamePart1:argExpression1     messageNamePart2:argExpression2     ...     messageNamePartN:argExpressionN</code>
|-
| Binary Expression
| <code>receiver binOP arg</code>
|with binOP being any combination of special characters: * , + , - , % , & , / , \ , | , = , < , > , ? and ,
 I.e. "<code>foo ==> 123</code>" is the binary message "<code>==></code>" sent to <code>foo</code> with <code>123</code> as argument.
 And "<code>foo ? 123</code>" is the binary message "<code>?</code>" sent to <code>foo</code> with <code>123</code> as argument.
|-
| Cascade Expression (multiple messages to the same receiver)
| <code>receiver     message1 ;     message2 ;     ...     messageN</code></td>
|the receiver expression is evaluated, then multiple messages (separated by ";") are sent to this receiver.
|-
| Parentheses for grouping
| <code>( any expression )</code>
|-
| Assignment
| <code>variable := expression</code>
|can be used as expression.
|-
| Computed Array (Brace Construct) (*)
| <code>{ expr1 . expr2 . ... . exprN }</code>
|instantiates a new Array object with elements from the expressions.
|-
| Computed Inline Object (*)
| <code>{ foo: fooExpr . bar: barExpr }</code>
|fooExpr and barExpr: expressions
|-
| Inline string expressions (*)
| <code>e'p1{e1}p2{e2}...pN{eN}pM'</code>
|syntactic sugar for: <code>('p1%1p2%2...pN%NpM' bindWith:e1 with:e2 ... with:eN)</code> where each pI is a string with possible C-escapes and each eI is a Smalltalk expression
|-
| Array Indexing (*)
| <code>coll[idx]</code> <code>coll[idx1][idx2]</code> <code>coll[idx1][idx2][idx3]</code>
|syntactic sugar for: <code>(coll at:idx)</code> where coll must be an indexable collection, and idx of compatible index type. I.e. integer for array-like collections, hash-key for dictionaries, etc. Up to 4 dimensions are (currently supported)
|-
| Collection instantiation (*)
| <code>someClass[sz]</code> <code>someClass[sz][sz]</code> ...
|syntactic sugar for: <code>(someClass new:sz)</code> where someClass must be a collection class I.e. Array[10] creates an empty array with 10 slots. 1, 2, 3 and 4 dimensions are supported
|-

|}

==== Remaining Syntax ====

{| class="wikitable"
|-
| Local variables (in block or method)
| <code>| var1 var2 ... varN |</code>
|variable declarations must be at the beginning, before any expression.
|-
| Separating multiple expressions (sequence)
| <code>expr1 . expr2 . ... exprN</code>
|expressions (statements) are separated by fullstop (period) characters. The last expression may or may not be followed by a fullstop; if there is one, this is treated like a followup empty statement.
|-
| Return from method
| <code>^ expression</code>
|returns from the enclosing method (also if inside a block-closure)
|}

==== Wellknown (Common) Messages ====

{| class="wikitable"
|-
| Conditional Execution
| <code>boolExpr1 ifTrue:[ ... ] ifFalse:[ ... ]</code>
|variations without true-part, without false part and with the order reversed are available.
|-
| While-Loop (test at top)
| <code>[ boolExpr1 ] whileTrue:[ ... ]</code>
|notice the receiver being a block. A <code>whileFalse:</code> variant is also available.
|-
| Do-Loop (test at bottom)
| <code>[ ... ] doWhile:[ boolExpr1 ]</code>
|notice the test being a block. A <code>doUntil:</code> variant is also available.
|-
| For-Loop
| <code>start to:stop do:[:iterVar | ... ]</code>
|evaluates the block (lambda) for each value in start..stop.
|-
| Enumerating Collections
| <code>collection do:[:elementVar | ... ]</code>
|evaluates the block (i.e. lambda) for each element in the collection.
|-
| Evaluating a Lambda Block   without arguments:
  with arguments:
| <code>aBlock value</code><code>aBlock value:expr1 ... value:exprN</code>
|the number of arguments must match the number expected by the lambda (although varArg lambdas are also available)
|-
| Exception Handling
| <code>[ ... ] on:Error do:[:ex | ... ]</code>
|evaluates the first block; if an error is encountered, evaluate the handler
|}

==== Special 'Control Structures' ====

{| class="wikitable"
|-
| Starting another Thread
| <code>p := [ ... ] fork</code>
|the code inside the block will execute in a separate thread
|-
| Creating, configuring and starting another Thread
| <code>p := [ ... ]   newProcess;   name:'my worker';   priority:5;   resume</code>
|the code inside the block will execute in a separate thread
|-
| Terminating a Thread
| <code>p terminate</code>
|with p referring to the thread as created by newProcess or fork
|-
| Interrupting a Thread
| <code>p interruptWith:[ ... ]</code>
|interrupt the thread and let it execute the given code (in its interrupt seervice)
|-
| Exception Handling
| <code>[ ... ]   on:Error do:[:ex |     ...   ]</code>
|the handler will get an exception argument (ex), which contains additional information, and can be told how to deal with the error
|-
| Exception Handling - proceeding
| <code>[ ... ]   on:Error do:[:ex |     ...     ex proceed   ]</code>
|proceed, as if the error did not happen
|-
| Exception Handling - restarting
| <code>[ ... ]   on:Error do:[:ex |     ...     ex restart   ]</code>
|restart the code from the beginning (usually after the handler did some cleanup, such as lazy loading a missing file...)
|-
| Exception Handling - printing
| <code>[ ... ]   on:Error do:[:ex |     ...     ex description     ...   ]</code>
|contains a human readable description of the error
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ensure:[   ...   ]</code>
|the ensure block will be evaluated in any case
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ifCurtailed:[   ...   ]</code>
|the ifCurtailed block will be evaluated only on a non-regular exit (i.e. when an exception was raised, or the operation was aborted or the thread terminated)
|-
| Early exit from Loops
| <code>[:exit |   ...   code with loop   ...   exit value   ... ] valueWithExit</code>
|the block will be left, when exit is evaluated. Often used as argument of ifTrue:, as in cond ifTrue: exit
|-
| Queries
| <code>Query   answer:something   do:[     ...     Query query     ...   ]</code>
|to provide answers way down to whoever is interested. Queries answer nil if no one is there to answer. Queries are usually more specifically used as subclasses of Query
|-
| Notifications
| <code>Notification   handle:[     ...   ]   do:[     ...     Notification notify:someArg     ...   ]</code>
|to provide information way up to whoever is interested Notifications are usually more specifically used as subclasses of Notification
|-
| Observers 1
| <code>foo onChange:#bla evaluate:[...]. ... foo changed:#bla</code>
|observer with generic block to evaluate
|-
| Observers 2
| <code>foo onChangeSend:#xyz to:someone. ... foo changed</code>
|observer with message send
|-
| Observers 3
| <code>foo addDependent:someone. ... foo changed</code>
|observer with send to update method of target
|}

Queries and Notifications can be seen as observers within the calling hierarchy (i.e. information flows up or down the calling hierarchy), whereas the dependency and anChange mechanisms are independent of the control flow (even between different threads)

==== Synchronization and Timers ====
{| class="wikitable"
|-
| Timed Delay
| <code>Delay waitForSeconds:n</code> <code>Delay waitUntil:(Timestamp now + 10 seconds)</code>
|self explaining
|-
| Sempaphore wait
| <code>s := Semaphore new. ... s wait. ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Sempaphore wait with timeout
| <code>s := Semaphore new. ... s waitWithTimeout:(5 seconds). ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Multi Sempaphore wait
| <code>s1 := Semaphore new. s2 := Semaphore new. ... which := (s1 , s2) wait. ... s2 signal</code>
|wait for any of multiple semaphores
|-
| Synchronized Collections
| <code>a := OrderedCollection new asSharedCollection</code>
|will wrap the collection so that add/remove operations are atomic
|}

==== Wellknown Globals ====

{| class="wikitable"
|-
| Logging and Messaging
| <code>Transcript</code> - the console window <code>Stdout</code> - standard output <code>Stderr</code> - standard error <code>Stdin</code> - standard input <code>Logger</code> - redefinable logger (defaults to standard error)
|-
| Common Useful Dialogs
| <code>Dialog</code> - provides many useful utility functions for standard dialogs eg.<code> Dialog warn:'message' Dialog confirm:'question' Dialog request:'question' Dialog requestFilename:'question' ...</code>
|}

==== Most Wellknown Classes ====

{| class="wikitable"
|-
| Numbers
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Number Number]</code>(abstract superclass) <code>[http://live.exept.de/ClassDoc/classDocOf:,Integer Integer]</code>(integral numbers) <code>[http://live.exept.de/ClassDoc/classDocOf:,Float Float]</code>(inexact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Fraction Fraction]</code>(exact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Complex Complex]</code>
|-
| Collections
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Array Array]</code> (fixed size array) <code>[http://live.exept.de/ClassDoc/classDocOf:,OrderedCollection OrderedCollection]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,List List]</code> (variable size) <code>[http://live.exept.de/ClassDoc/classDocOf:,SortedCollection SortedCollection]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Set Set]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Bag Bag]</code> (unordered) <code>[http://live.exept.de/ClassDoc/classDocOf:,Dictionary Dictionary]</code> (mapped collections) <code>[http://live.exept.de/ClassDoc/classDocOf:,BinaryTree BinaryTree]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,AVLTree AVLTree]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,SharedQueue SharedQueue]</code> (shared, synchronized) many more...
|-
| Process Handling
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Process Process]</code> (lightweight thread) <code>[http://live.exept.de/ClassDoc/classDocOf:,OSProcess OSProcess]</code> (heavyweight OS process) <code>[http://live.exept.de/ClassDoc/classDocOf:,Semaphore Semaphore]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,RecursionLock RecursionLock]</code> (synchronization) <code>[http://live.exept.de/ClassDoc/classDocOf:,Monitor Monitor]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,BoltLock BoltLock]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Delay Delay]</code> (time delays)
|-
| Files & Streams
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Filename Filename]</code> (file naming, directory access, mime type) <code>[http://live.exept.de/ClassDoc/classDocOf:,Stream Stream]</code> (basic stream framework)
 <code>[http://live.exept.de/ClassDoc/classDocOf:,ReadStream ReadStream]</code>,<code>WriteStream</code>,<code>[http://live.exept.de/ClassDoc/classDocOf:,EncodedStream EncodedStream]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,ExternalStream ExternalStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,FileStream FileStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Socket Socket]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,PipeStream PipeStream]</code> (OS-cmd streams)
|-
| Low Level Access
| <code>[http://live.exept.de/ClassDoc/classDocOf:,OperatingSystem OperatingSystem]</code> (OS API calls) <code>[http://live.exept.de/ClassDoc/classDocOf:,Smalltalk Smalltalk]</code>(startup, shutdown and globals) <code>[http://live.exept.de/ClassDoc/classDocOf:,ObjectMemory ObjectMemory]</code>(VM access)
|}

== Examples ==

exampleMethod1
|v1 v2|

v1 := 42.
v2 := v1 sqrt.
Transcript showCR: 'the root of the answer to all questions is: %1' with: v2.

using expanded strings, this can be written as:

exampleMethod1_alternative
|v1|

v1 := 42.
Transcript showCR: e'the root of the answer to all questions is: {v1 sqrt}'.

enumerating elements of an array:

exampleMethod2
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr do:[:el |
Transcript showCR: el
]

enumerating elements of an array with additional index:

exampleMethod3
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr doWithIndex:[:el :idx |
Transcript showCR: e'array element at {idx} is {el} and its class is {el class name}\n'
]

dialogs, string-to-number conversion, error handling:

exampleMethod4
|s1 nr1 s2 nr2 rslt|

s1 := Dialog request:'Enter the first number' initialAnswer:1.
s1 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method
s2 := Dialog request:'Enter the second number' initialAnswer:2.
s2 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr1 := Number readFrom:s1 onError:[^ self].
nr2 := Number readFrom:s2 onError:[^ self].

"/ save division
[
rslt := nr1 / nr2
] on: Error do:[:ex |
(Dialog confirm: e'Error encountered: {ex description}\nProceed with zero?')
ifFalse:[^ self]. "/ no; return from method
ex proceedWith:0
].

Dialog information: e'the result is {rslt}'

dialogs, error handling and complex square root:

exampleMethod4
|s nr rslt|

s := Dialog request:'Enter a number (may be negative)' initialAnswer:2.
s isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr := Number readFrom:s onError:[^ self].

"/ square root; catch imaginary result
[
rslt := nr sqrt
] on: ImaginaryResultError do:[:ex |
(Dialog confirm: e'No solution in R; want to see the complex result?')
ifFalse:[^ self]. "/ no; return from method
rslt := Number trapImaginary:[ nr sqrt ].
"/ rslt is now a complex number
].

Dialog information: e'the result is {rslt}'

== Standard ==
The ANSI Smalltalk standard was approved on May 19, 1998. The official name of the document is ANSI INCITS 319-1998 (R2002). You can order a copy of the final standard
from here: [http://www.techstreet.com/cgi-bin/detail?product_id=56122]
or here [http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI+INCITS+319%2D1998+%28R2002%29]. The name of the document is "American National Standard for Information Systems - Programming Languages - Smalltalk".

You can also download the final draft revision for free: standard_v1_9-indexed.pdf and at [https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf].

The final draft is identical to the official standard except that the draft also has a rationale included (and thus, the draft is arguably more useful than the official standard).

Protocol from ANSI Meeting: [http://www.netjam.org/smalltalk/faq/ANSI-meeting.html]

== Common Language Extensions ==
These are also found in other Smalltalk dialects (eg. [[Glossary#VW|VW]] or [[Glossary#Squeak|Squeak]])

* { expr1 . expr2 . ... } Brace Array Construction Each expression is evaluated (left to right), and an Array with the results is created at execution time. Notice that separating full stops are required, as opposed to constant literal arrays, where elements are separated by spaces. The generated Array is mutable (can be modified), whereas a constant array is not.

== Smalltalk/X Language Extensions ==

These are ST/X specific, and not (as of 2026) implemented in other Smalltalk systems.

=== String Literals ===
* c'...' ''c-strings'' C-like escapes (\n, \t, \xNN, \uNNNN) inside the string are expanded.

* e' ... {expr} ...' ''e-strings'' (expanded epression strings) In addition to C-escapes, embedded expressions are evaluated and their printString is sliced in. Technically, it is converted to ' ... %1 ...' and then expanded using standard String methods.

* i' ... {expr} ...' ''i-strings'' (international strings) similar to e-strings, but the converted string ('... %1 ...') is translated to a national string (via the *.rs file) and then expanded. Allows for different word ordering.

=== Integer Literals ===
* 0xNNNN, 0oNNNN, 0bNNNN C-style hex, octal and binary integers. With arbitrary precision

=== Float Literals ===
* <f>q, <f>Q, etc. Float literal type suffix (q, Q, QD, QL, QO) For a complete list and spec., see the Number documentation.

=== Compact Number Arrays ===
* #u1, #u8, #u16, #u32, #u64 #i8, #i16, #i32, #i64 #f16, #bf16, #f32, #f64 Will generate dense packed vectors (similar to byteArray); format is #X(n1 n2 ... )

Smalltalk Syntax Cheat Sheet

2026-06-07T06:15:35Z

Cg: /* Numbers */

A short, one page summary of what beginners need to know about Smalltalk/X, its syntax and most useful code fragments. As usual, this is only a tiny fraction of what is really awailable, and you should use the builtin class browser to find many more useful functions in the system.

This page was extracted from the "Smalltalk/X Programmers guide - Smalltalk/X Cheat Sheet".
 Smalltalk/X language extensions (w.r.t. other Smalltalk implementations) are marked with '''(*)'''.

== Smalltalk Philosophy ==

* The world consists of objects which '''communicate by sending messages'''.
: A message looks like an english sentence, and might look like "<code>heyYou doSomething</code>".
: In this example, the "heyYou" is called the "''receiver of the message''"
: You may pass additional parameter objects (arguments) as in: "<code>heyYou doSomethingWith: arg</code>"
: or multiple arguments as in <code>"heyYou doSomethingWith: arg1 and: arg2"</code>
: In these examples, the "<code>heyYou</code>" is called the "''receiver of the message''"
* Messages without argument are called "''unary messages''"; those with arguments are called "''keyword messages''"
: For example "<code>Transcript clear</code>" (sends the message "clear" to the Transcript object),
: and "<code>Transcript show: 'hello'</code>" (sends the message "show:" to the Transcript, passing a string argument),
* To allow for arithmetic operations, any non-letter character (except for a few) are treated like a message name and written between the receiver and the one and only argument. These are called "''binary messages''".
: For example: <code>"3 + 4"</code> or <code>"abc , def"</code> (yes, the comma is an operator; it does string concatenation)
* The object my respond (or "answer") by returning some result object. In the above example, "<code>3+4</code>" would answer "7", and "<code>'hello' , 'world'</code>" would answer 'helloworld'
* binary messages have no meaning to the compiler; they are all equal and simply evaluated from left to right.
: admitted, this makes arithmetic a little strange initially; you'll need parentheses as the is not precidence of eg. * over +. The expression "3 + 4 * 5" will be evaluated left to right and answer 35.
* Everything in this world is an object;
: from low level things like booleans, true, false, integer numbers, floating point numbers characters etc.
: there are containers, which can hold on other objects. Technically, all such references are via pointers.
: there are also very complex objects and structures which implement windows, the user interface, communication interfaces, debuggers and even compilers which allow for code to be defined and installed on the fly.
* Every object is associated to a class. Classes define the behavior of their instances. I.e. they define how they respond to messages. The response is implemented by a so called ''method''. That is a piece of code which is executed when a message comes in. A method consist of a number of statements (which are message sends), each separated by a full stop (as in english).
* Classes are themself objects, which respond to messages. Typically class messages would answer new instances, constants or utility functionality. There are also class messages to create new classes.
* Class can inherit common functionality (i.e. method implementations) from a superclass. Thus creating a hierarchy of classes. Typical hierarchies are the Number hierarchy, Collections, Streams and UI Widgets.
* In Smalltalk, every behavior is defined by corresponding message implementations. This includes control features (i.e. if-then-else, loops and exception handling). All of them are implemented as messages being sent to booleans (ifTrue:/ifFalse:) or blocks (whileTrue:)
* Blocks are special objects, which wrap a piece of code. Other languages know them as anonymous functions or lambdas or closures. But the Smalltalk syntax makes them super easy to use: just write a number of expressions inside square brackets, as in "<code>[ Transcript show: 10 factorial ]</code>".
: blocks can be passed as argument with a message send; for example to a boolean: "<code>aBoolean ifTrue: [ Transcript show: 'yes' ]</code>"
: blocks can be stored in variables and passed arounf just like any other object
: blocks can receive messages, especially loop messages: "<code>[ a < 10] whileTrue:[ Transcript showCR: a. a := a + 1 ]</code>".

== Syntax ==

==== Comments ====

{| class="wikitable"
|-
| Regular comment
| <code>" this is a comment "</code>
| ''any text between double quotes''
|-
| EOL-Comment (*)
| <code>"/ this is an End-of-Line comment</code>
| ''text from quote-slash to line end''
|-
| Token-Comment (*)
| <code>"<<END a multiline token-comment up to a line starting with 'END' more commented stuff here ... comment ends here END</code>
| ''text up to line beginning with whatever token came after the initial "<<" ''
|}

==== Literal Constants ====

===== Numbers =====

{| class="wikitable"
|-
| Integers</td>
| <code>12345</code> </code>-12345<code>
|
|-
| Large integers
| <code>1234567890123456789012345</code>…
| ''arbitrary number of digits''
|-
| Integers with radix (Smalltalk style)
| <code>16rAFFE</code>, <code>2r010101</code>, <code>8r0777</code>, <code>3r012012</code>, <code>16r-AFFE</code>, <code>2r-010101</code>
| ''prepend the radix (base) any radix from 2..36 is possible (i.e. 3r222 is a ternary number)''
|-
| Integers with radix (C style) (*)
| <code>0xFEED</code> <code>-0xBEAF</code> <code>0b11011</code>,<code>-0b1100</code>
| ''C/Java/JavaScript style: prepend radix indicator ('x', 'b', 'o') One of hex, binary and octal''
|-
| Floats (IEEE double; roughly 17 digits)
| 12.456 1.234e17 -6.9 -6e-10 Float pi Float e
| ''called "Float", but actually hold double precision Common constants can be referred to "by name".''
|-
| Short floats (IEEE single; roughly 8 digits) (*)
| <code>1.234e17f</code> <code>-6e-10f</code>
| <strike>''this is controlled by a ParserFlag (singlePrecisionFloatF), which is currently defaulted to false. Thus, by default, double precision floats are created with the 'f' exponent character.''</strike>
|-
| Long floats (IEEE extended; roughly 20 digits) (*)
| <code>1.234e17q</code> <code>-6q-10q</code>
| ''actual precision depends on the underlying CPU (x86/x86_64: 80bit; Sparc: 128 bit)
|-
| Quad floats; (IEEE quad; roughly 34 digits (*)
| <code>1.234e17Q</code> <code>-6e-10Q</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Octuple floats; roughly 60 digits (*)
| <code>1.234e17QO</code> <code>-6e-10QP</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Large floats; roughly 60 digits by default, but any precision possible (*)
| <code>1.234e17QL</code> <code>-6e-10QL</code>
| ''computed in software; therefore slower; <strike>this is not yet officially released.</strike>
|-
| Fractions
| <code>(1/3)</code> <code>(17/2)</code>
|
|-
| ScaledDecimals
| <code>1234.53s2</code>
| the number after the s specifies the number of digits
|}

===== Characters and Strings =====

{| class="wikitable"
|-
| Characters
| <code>$a</code> <code>Character space</code> <code>Character nl</code> Also: "<code>null</code>", "<code>tab</code>", "<code>return</code>", "<code>bell</code>"... Or: <code>Character codePoint:n</code>
| Smalltalk does not support any escape sequence Common constants can be referred to "''by name''".
|-
| Strings
| <code>'hello'</code>
| traditionally, Smalltalk does not support any escape sequence inside (i.e. they are what Python calls "''Raw Strings''") But see below...
|-
| Strings (C Style) (*)
| <code>c'hello\nworld'</code>
| supports the common escape sequences, such as "\n", "\t", "\xHH", "\uXXXX"
|-
| Strings (with embedded expressios) (*)
| <code>e'hello {OperatingSystem getLoginName}'</code>
| expanded strings expressions in braces are evaluated at runtime and sliced into the string (also a C-string). Similar to python's f-strings.
|-
| Strings (national language translated with embedded expressios) (*)
| <code>i'hello {OperatingSystem getLoginName}'</code>
| international strings like above, but the string is also possibly translated to a national language
|-
| Symbols
| <code>#'hello'</code> <code>#foo</code> <code>#+</code>
| symbols are interned strings; two symbols with the same characters are guaranteed to be the identical object (not just equal) without quotes, if only alphaNumeric characters
|}

===== Arrays and Objects =====
{| class="wikitable"
|-
| Arrays 
| <code>#( el1 el2 ... elN )</code>
| each element is a literal constant
|-
| Byte Arrays
| <code>#[ b1 b2 ... bN ]</code>
| each byte-element an integer constant in 0..255
|-
| Special Number Arrays (*)
| <code>#XX( v1 v2 ... vN )</code>
| XX: is one of  'u8', 's8', 'u16', 's16', 'u32', 's32', 'u64', 's64', 'f32', 'f64'  and each element being an integer or float constant
|-
| Immediate Inline Objects (*)
| <code>#{ foo: fooValue . bar: barValue }</code>
| fooValue and barValue: are constants
|}

==== Lambda Blocks (Closures) ====

{| class="wikitable"
|-
| Without argument
| <code>[ expr1 . expr2 ... exprN ]</code>
| multiple expressions sep'd by period. When evaluated, the value is the value from the last expression, exprN
|-
| One argument
| <code>[ :arg |     expr1 . expr2 ... exprN ]</code>
|-
| Multiple arguments
| <code>[ :a1 :a2 ... :aN |     expr1 . expr2 ... exprN ]</code>
|-
| Local Variables inside a block
| <code>[ :a1 ... :aN |      |local1 local2 |      expr1 ... exprN ]</code>
|}

==== Expressions ====

{| class="wikitable"
|-
| Unary Expression (without argument)
| <code>receiver messageName</code>
|receiver is itself either a constant, a lambda-block, a unary expression or a parenthesized expression
|-
| Keyword Expression (1 arg)
| <code>receiver messageNamePart:argExpression</code>
|whitespace between the colon and the argExpression is optional.
|-
| Keyword Expression (any number of args)
| <code>receiver     messageNamePart1:argExpression1     messageNamePart2:argExpression2     ...     messageNamePartN:argExpressionN</code>
|-
| Binary Expression
| <code>receiver binOP arg</code>
|with binOP being any combination of special characters: * , + , - , % , & , / , \ , | , = , < , > , ? and ,
 I.e. "<code>foo ==> 123</code>" is the binary message "<code>==></code>" sent to <code>foo</code> with <code>123</code> as argument.
 And "<code>foo ? 123</code>" is the binary message "<code>?</code>" sent to <code>foo</code> with <code>123</code> as argument.
|-
| Cascade Expression (multiple messages to the same receiver)
| <code>receiver     message1 ;     message2 ;     ...     messageN</code></td>
|the receiver expression is evaluated, then multiple messages (separated by ";") are sent to this receiver.
|-
| Parentheses for grouping
| <code>( any expression )</code>
|-
| Assignment
| <code>variable := expression</code>
|can be used as expression.
|-
| Computed Array (Brace Construct) (*)
| <code>{ expr1 . expr2 . ... . exprN }</code>
|instantiates a new Array object with elements from the expressions.
|-
| Computed Inline Object (*)
| <code>{ foo: fooExpr . bar: barExpr }</code>
|fooExpr and barExpr: expressions
|-
| Inline string expressions (*)
| <code>e'p1{e1}p2{e2}...pN{eN}pM'</code>
|syntactic sugar for: <code>('p1%1p2%2...pN%NpM' bindWith:e1 with:e2 ... with:eN)</code> where each pI is a string with possible C-escapes and each eI is a Smalltalk expression
|-
| Array Indexing (*)
| <code>coll[idx]</code> <code>coll[idx1][idx2]</code> <code>coll[idx1][idx2][idx3]</code>
|syntactic sugar for: <code>(coll at:idx)</code> where coll must be an indexable collection, and idx of compatible index type. I.e. integer for array-like collections, hash-key for dictionaries, etc. Up to 4 dimensions are (currently supported)
|-
| Collection instantiation (*)
| <code>someClass[sz]</code> <code>someClass[sz][sz]</code> ...
|syntactic sugar for: <code>(someClass new:sz)</code> where someClass must be a collection class I.e. Array[10] creates an empty array with 10 slots. 1, 2, 3 and 4 dimensions are supported
|-

|}

==== Remaining Syntax ====

{| class="wikitable"
|-
| Local variables (in block or method)
| <code>| var1 var2 ... varN |</code>
|variable declarations must be at the beginning, before any expression.
|-
| Separating multiple expressions (sequence)
| <code>expr1 . expr2 . ... exprN</code>
|expressions (statements) are separated by fullstop (period) characters. The last expression may or may not be followed by a fullstop; if there is one, this is treated like a followup empty statement.
|-
| Return from method
| <code>^ expression</code>
|returns from the enclosing method (also if inside a block-closure)
|}

==== Wellknown (Common) Messages ====

{| class="wikitable"
|-
| Conditional Execution
| <code>boolExpr1 ifTrue:[ ... ] ifFalse:[ ... ]</code>
|variations without true-part, without false part and with the order reversed are available.
|-
| While-Loop (test at top)
| <code>[ boolExpr1 ] whileTrue:[ ... ]</code>
|notice the receiver being a block. A <code>whileFalse:</code> variant is also available.
|-
| Do-Loop (test at bottom)
| <code>[ ... ] doWhile:[ boolExpr1 ]</code>
|notice the test being a block. A <code>doUntil:</code> variant is also available.
|-
| For-Loop
| <code>start to:stop do:[:iterVar | ... ]</code>
|evaluates the block (lambda) for each value in start..stop.
|-
| Enumerating Collections
| <code>collection do:[:elementVar | ... ]</code>
|evaluates the block (i.e. lambda) for each element in the collection.
|-
| Evaluating a Lambda Block   without arguments:
  with arguments:
| <code>aBlock value</code><code>aBlock value:expr1 ... value:exprN</code>
|the number of arguments must match the number expected by the lambda (although varArg lambdas are also available)
|-
| Exception Handling
| <code>[ ... ] on:Error do:[:ex | ... ]</code>
|evaluates the first block; if an error is encountered, evaluate the handler
|}

==== Special 'Control Structures' ====

{| class="wikitable"
|-
| Starting another Thread
| <code>p := [ ... ] fork</code>
|the code inside the block will execute in a separate thread
|-
| Creating, configuring and starting another Thread
| <code>p := [ ... ]   newProcess;   name:'my worker';   priority:5;   resume</code>
|the code inside the block will execute in a separate thread
|-
| Terminating a Thread
| <code>p terminate</code>
|with p referring to the thread as created by newProcess or fork
|-
| Interrupting a Thread
| <code>p interruptWith:[ ... ]</code>
|interrupt the thread and let it execute the given code (in its interrupt seervice)
|-
| Exception Handling
| <code>[ ... ]   on:Error do:[:ex |     ...   ]</code>
|the handler will get an exception argument (ex), which contains additional information, and can be told how to deal with the error
|-
| Exception Handling - proceeding
| <code>[ ... ]   on:Error do:[:ex |     ...     ex proceed   ]</code>
|proceed, as if the error did not happen
|-
| Exception Handling - restarting
| <code>[ ... ]   on:Error do:[:ex |     ...     ex restart   ]</code>
|restart the code from the beginning (usually after the handler did some cleanup, such as lazy loading a missing file...)
|-
| Exception Handling - printing
| <code>[ ... ]   on:Error do:[:ex |     ...     ex description     ...   ]</code>
|contains a human readable description of the error
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ensure:[   ...   ]</code>
|the ensure block will be evaluated in any case
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ifCurtailed:[   ...   ]</code>
|the ifCurtailed block will be evaluated only on a non-regular exit (i.e. when an exception was raised, or the operation was aborted or the thread terminated)
|-
| Early exit from Loops
| <code>[:exit |   ...   code with loop   ...   exit value   ... ] valueWithExit</code>
|the block will be left, when exit is evaluated. Often used as argument of ifTrue:, as in cond ifTrue: exit
|-
| Queries
| <code>Query   answer:something   do:[     ...     Query query     ...   ]</code>
|to provide answers way down to whoever is interested. Queries answer nil if no one is there to answer. Queries are usually more specifically used as subclasses of Query
|-
| Notifications
| <code>Notification   handle:[     ...   ]   do:[     ...     Notification notify:someArg     ...   ]</code>
|to provide information way up to whoever is interested Notifications are usually more specifically used as subclasses of Notification
|-
| Observers 1
| <code>foo onChange:#bla evaluate:[...]. ... foo changed:#bla</code>
|observer with generic block to evaluate
|-
| Observers 2
| <code>foo onChangeSend:#xyz to:someone. ... foo changed</code>
|observer with message send
|-
| Observers 3
| <code>foo addDependent:someone. ... foo changed</code>
|observer with send to update method of target
|}

Queries and Notifications can be seen as observers within the calling hierarchy (i.e. information flows up or down the calling hierarchy), whereas the dependency and anChange mechanisms are independent of the control flow (even between different threads)

==== Synchronization and Timers ====
{| class="wikitable"
|-
| Timed Delay
| <code>Delay waitForSeconds:n</code> <code>Delay waitUntil:(Timestamp now + 10 seconds)</code>
|self explaining
|-
| Sempaphore wait
| <code>s := Semaphore new. ... s wait. ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Sempaphore wait with timeout
| <code>s := Semaphore new. ... s waitWithTimeout:(5 seconds). ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Multi Sempaphore wait
| <code>s1 := Semaphore new. s2 := Semaphore new. ... which := (s1 , s2) wait. ... s2 signal</code>
|wait for any of multiple semaphores
|-
| Synchronized Collections
| <code>a := OrderedCollection new asSharedCollection</code>
|will wrap the collection so that add/remove operations are atomic
|}

==== Wellknown Globals ====

{| class="wikitable"
|-
| Logging and Messaging
| <code>Transcript</code> - the console window <code>Stdout</code> - standard output <code>Stderr</code> - standard error <code>Stdin</code> - standard input <code>Logger</code> - redefinable logger (defaults to standard error)
|-
| Common Useful Dialogs
| <code>Dialog</code> - provides many useful utility functions for standard dialogs eg.<code> Dialog warn:'message' Dialog confirm:'question' Dialog request:'question' Dialog requestFilename:'question' ...</code>
|}

==== Most Wellknown Classes ====

{| class="wikitable"
|-
| Numbers
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Number Number]</code>(abstract superclass) <code>[http://live.exept.de/ClassDoc/classDocOf:,Integer Integer]</code>(integral numbers) <code>[http://live.exept.de/ClassDoc/classDocOf:,Float Float]</code>(inexact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Fraction Fraction]</code>(exact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Complex Complex]</code>
|-
| Collections
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Array Array]</code> (fixed size array) <code>[http://live.exept.de/ClassDoc/classDocOf:,OrderedCollection OrderedCollection]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,List List]</code> (variable size) <code>[http://live.exept.de/ClassDoc/classDocOf:,SortedCollection SortedCollection]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Set Set]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Bag Bag]</code> (unordered) <code>[http://live.exept.de/ClassDoc/classDocOf:,Dictionary Dictionary]</code> (mapped collections) <code>[http://live.exept.de/ClassDoc/classDocOf:,BinaryTree BinaryTree]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,AVLTree AVLTree]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,SharedQueue SharedQueue]</code> (shared, synchronized) many more...
|-
| Process Handling
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Process Process]</code> (lightweight thread) <code>[http://live.exept.de/ClassDoc/classDocOf:,OSProcess OSProcess]</code> (heavyweight OS process) <code>[http://live.exept.de/ClassDoc/classDocOf:,Semaphore Semaphore]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,RecursionLock RecursionLock]</code> (synchronization) <code>[http://live.exept.de/ClassDoc/classDocOf:,Monitor Monitor]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,BoltLock BoltLock]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Delay Delay]</code> (time delays)
|-
| Files & Streams
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Filename Filename]</code> (file naming, directory access, mime type) <code>[http://live.exept.de/ClassDoc/classDocOf:,Stream Stream]</code> (basic stream framework)
 <code>[http://live.exept.de/ClassDoc/classDocOf:,ReadStream ReadStream]</code>,<code>WriteStream</code>,<code>[http://live.exept.de/ClassDoc/classDocOf:,EncodedStream EncodedStream]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,ExternalStream ExternalStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,FileStream FileStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Socket Socket]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,PipeStream PipeStream]</code> (OS-cmd streams)
|-
| Low Level Access
| <code>[http://live.exept.de/ClassDoc/classDocOf:,OperatingSystem OperatingSystem]</code> (OS API calls) <code>[http://live.exept.de/ClassDoc/classDocOf:,Smalltalk Smalltalk]</code>(startup, shutdown and globals) <code>[http://live.exept.de/ClassDoc/classDocOf:,ObjectMemory ObjectMemory]</code>(VM access)
|}

== Examples ==

exampleMethod1
|v1 v2|

v1 := 42.
v2 := v1 sqrt.
Transcript showCR: 'the root of the answer to all questions is: %1' with: v2.

using expanded strings, this can be written as:

exampleMethod1_alternative
|v1|

v1 := 42.
Transcript showCR: e'the root of the answer to all questions is: {v1 sqrt}'.

enumerating elements of an array:

exampleMethod2
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr do:[:el |
Transcript showCR: el
]

enumerating elements of an array with additional index:

exampleMethod3
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr doWithIndex:[:el :idx |
Transcript showCR: e'array element at {idx} is {el} and its class is {el class name}\n'
]

dialogs, string-to-number conversion, error handling:

exampleMethod4
|s1 nr1 s2 nr2 rslt|

s1 := Dialog request:'Enter the first number' initialAnswer:1.
s1 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method
s2 := Dialog request:'Enter the second number' initialAnswer:2.
s2 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr1 := Number readFrom:s1 onError:[^ self].
nr2 := Number readFrom:s2 onError:[^ self].

"/ save division
[
rslt := nr1 / nr2
] on: Error do:[:ex |
(Dialog confirm: e'Error encountered: {ex description}\nProceed with zero?')
ifFalse:[^ self]. "/ no; return from method
ex proceedWith:0
].

Dialog information: e'the result is {rslt}'

dialogs, error handling and complex square root:

exampleMethod4
|s nr rslt|

s := Dialog request:'Enter a number (may be negative)' initialAnswer:2.
s isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr := Number readFrom:s onError:[^ self].

"/ square root; catch imaginary result
[
rslt := nr sqrt
] on: ImaginaryResultError do:[:ex |
(Dialog confirm: e'No solution in R; want to see the complex result?')
ifFalse:[^ self]. "/ no; return from method
rslt := Number trapImaginary:[ nr sqrt ].
"/ rslt is now a complex number
].

Dialog information: e'the result is {rslt}'

== Standard ==
The ANSI Smalltalk standard was approved on May 19, 1998. The official name of the document is ANSI INCITS 319-1998 (R2002). You can order a copy of the final standard
from here: [http://www.techstreet.com/cgi-bin/detail?product_id=56122]
or here [http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI+INCITS+319%2D1998+%28R2002%29]. The name of the document is "American National Standard for Information Systems - Programming Languages - Smalltalk".

You can also download the final draft revision for free: standard_v1_9-indexed.pdf and at [https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf].

The final draft is identical to the official standard except that the draft also has a rationale included (and thus, the draft is arguably more useful than the official standard).

Protocol from ANSI Meeting: [http://www.netjam.org/smalltalk/faq/ANSI-meeting.html]

== Common Language Extensions ==
These are also found in other Smalltalk dialects (eg. [[Glossary#VW|VW]] or [[Glossary#Squeak|Squeak]])

* { expr1 . expr2 . ... } Brace Array Construction Each expression is evaluated (left to right), and an Array with the results is created at execution time. Notice that separating full stops are required, as opposed to constant literal arrays, where elements are separated by spaces. The generated Array is mutable (can be modified), whereas a constant array is not.

== Smalltalk/X Language Extensions ==

These are ST/X specific, and not (as of 2026) implemented in other Smalltalk systems.

=== String Literals ===
* c'...' ''c-strings'' C-like escapes (\n, \t, \xNN, \uNNNN) inside the string are expanded.

* e' ... {expr} ...' ''e-strings'' (expanded epression strings) In addition to C-escapes, embedded expressions are evaluated and their printString is sliced in. Technically, it is converted to ' ... %1 ...' and then expanded using standard String methods.

* i' ... {expr} ...' ''i-strings'' (international strings) similar to e-strings, but the converted string ('... %1 ...') is translated to a national string (via the *.rs file) and then expanded. Allows for different word ordering.

=== Integer Literals ===
* 0xNNNN, 0oNNNN, 0bNNNN C-style hex, octal and binary integers. With arbitrary precision

=== Float Literals ===
* <f>q, <f>Q, etc. Float literal type suffix (q, Q, QD, QL, QO) For a complete list and spec., see the Number documentation.

=== Compact Number Arrays ===
* #u1, #u8, #u16, #u32, #u64 #i8, #i16, #i32, #i64 #f16, #bf16, #f32, #f64 Will generate dense packed vectors (similar to byteArray); format is #X(n1 n2 ... )

Smalltalk Syntax Cheat Sheet

2026-06-07T06:06:56Z

Cg: /* Characters and Strings */

A short, one page summary of what beginners need to know about Smalltalk/X, its syntax and most useful code fragments. As usual, this is only a tiny fraction of what is really awailable, and you should use the builtin class browser to find many more useful functions in the system.

This page was extracted from the "Smalltalk/X Programmers guide - Smalltalk/X Cheat Sheet".
 Smalltalk/X language extensions (w.r.t. other Smalltalk implementations) are marked with '''(*)'''.

== Smalltalk Philosophy ==

* The world consists of objects which '''communicate by sending messages'''.
: A message looks like an english sentence, and might look like "<code>heyYou doSomething</code>".
: In this example, the "heyYou" is called the "''receiver of the message''"
: You may pass additional parameter objects (arguments) as in: "<code>heyYou doSomethingWith: arg</code>"
: or multiple arguments as in <code>"heyYou doSomethingWith: arg1 and: arg2"</code>
: In these examples, the "<code>heyYou</code>" is called the "''receiver of the message''"
* Messages without argument are called "''unary messages''"; those with arguments are called "''keyword messages''"
: For example "<code>Transcript clear</code>" (sends the message "clear" to the Transcript object),
: and "<code>Transcript show: 'hello'</code>" (sends the message "show:" to the Transcript, passing a string argument),
* To allow for arithmetic operations, any non-letter character (except for a few) are treated like a message name and written between the receiver and the one and only argument. These are called "''binary messages''".
: For example: <code>"3 + 4"</code> or <code>"abc , def"</code> (yes, the comma is an operator; it does string concatenation)
* The object my respond (or "answer") by returning some result object. In the above example, "<code>3+4</code>" would answer "7", and "<code>'hello' , 'world'</code>" would answer 'helloworld'
* binary messages have no meaning to the compiler; they are all equal and simply evaluated from left to right.
: admitted, this makes arithmetic a little strange initially; you'll need parentheses as the is not precidence of eg. * over +. The expression "3 + 4 * 5" will be evaluated left to right and answer 35.
* Everything in this world is an object;
: from low level things like booleans, true, false, integer numbers, floating point numbers characters etc.
: there are containers, which can hold on other objects. Technically, all such references are via pointers.
: there are also very complex objects and structures which implement windows, the user interface, communication interfaces, debuggers and even compilers which allow for code to be defined and installed on the fly.
* Every object is associated to a class. Classes define the behavior of their instances. I.e. they define how they respond to messages. The response is implemented by a so called ''method''. That is a piece of code which is executed when a message comes in. A method consist of a number of statements (which are message sends), each separated by a full stop (as in english).
* Classes are themself objects, which respond to messages. Typically class messages would answer new instances, constants or utility functionality. There are also class messages to create new classes.
* Class can inherit common functionality (i.e. method implementations) from a superclass. Thus creating a hierarchy of classes. Typical hierarchies are the Number hierarchy, Collections, Streams and UI Widgets.
* In Smalltalk, every behavior is defined by corresponding message implementations. This includes control features (i.e. if-then-else, loops and exception handling). All of them are implemented as messages being sent to booleans (ifTrue:/ifFalse:) or blocks (whileTrue:)
* Blocks are special objects, which wrap a piece of code. Other languages know them as anonymous functions or lambdas or closures. But the Smalltalk syntax makes them super easy to use: just write a number of expressions inside square brackets, as in "<code>[ Transcript show: 10 factorial ]</code>".
: blocks can be passed as argument with a message send; for example to a boolean: "<code>aBoolean ifTrue: [ Transcript show: 'yes' ]</code>"
: blocks can be stored in variables and passed arounf just like any other object
: blocks can receive messages, especially loop messages: "<code>[ a < 10] whileTrue:[ Transcript showCR: a. a := a + 1 ]</code>".

== Syntax ==

==== Comments ====

{| class="wikitable"
|-
| Regular comment
| <code>" this is a comment "</code>
| ''any text between double quotes''
|-
| EOL-Comment (*)
| <code>"/ this is an End-of-Line comment</code>
| ''text from quote-slash to line end''
|-
| Token-Comment (*)
| <code>"<<END a multiline token-comment up to a line starting with 'END' more commented stuff here ... comment ends here END</code>
| ''text up to line beginning with whatever token came after the initial "<<" ''
|}

==== Literal Constants ====

===== Numbers =====

{| class="wikitable"
|-
| Integers</td>
| <code>12345</code> </code>-12345<code>
|
|-
| Large integers
| <code>1234567890123456789012345</code>…
| ''arbitrary number of digits''
|-
| Integers with radix (Smalltalk style)
| <code>16rAFFE</code>, <code>2r010101</code>, <code>8r0777</code>, <code>3r012012</code>, <code>16r-AFFE</code>, <code>2r-010101</code>
| ''prepend the radix (base) any radix from 2..36 is possible (i.e. 3r222 is a ternary number)''
|-
| Integers with radix (C style) (*)
| <code>0xFEED</code> <code>-0xBEAF</code> <code>0b11011</code>,<code>-0b1100</code>
| ''C/Java/JavaScript style: prepend radix indicator ('x', 'b', 'o') One of hex, binary and octal''
|-
| Floats (IEEE double; roughly 17 digits)
| 12.456 1.234e17 -6.9 -6e-10 Float pi Float e
| ''called "Float", but actually hold double precision'' Common constants can be referred to "by name".
|-
| Short floats (IEEE single; roughly 8 digits) (*)
| <code>1.234f17</code> <code>-6f-10</code>
| this is controlled by a ParserFlag (singlePrecisionFloatF), which is currently defaulted to false. Thus, by default, double precision floats are created with the 'f' exponent character.
|-
| Long floats (IEEE quad; roughly 20 digits) (*)
| <code>1.234q17</code> <code>-6q-10</code>
| ''actual precision depends on the underlying CPU (on x86/x86_64: only 80bit)
|-
| Quad floats; roughly 34 digits (*)
| <code>1.234Q17</code> <code>-6Q-10</code>
| ''computed in software; therefore slower; this is not yet officially released.
|-
| Large floats; roughly 60 digits (*)
| <code>1.234QL17</code> <code>-6QL-10</code>
| ''computed in software; therefore slower; this is not yet officially released.
|-
| Fractions
| <code>(1/3)</code> <code>(17/2)</code>
|
|-
| ScaledDecimals
| <code>1234.53s2</code>
| the number after the s specifies the number of digits
|}

===== Characters and Strings =====

{| class="wikitable"
|-
| Characters
| <code>$a</code> <code>Character space</code> <code>Character nl</code> Also: "<code>null</code>", "<code>tab</code>", "<code>return</code>", "<code>bell</code>"... Or: <code>Character codePoint:n</code>
| Smalltalk does not support any escape sequence Common constants can be referred to "''by name''".
|-
| Strings
| <code>'hello'</code>
| traditionally, Smalltalk does not support any escape sequence inside (i.e. they are what Python calls "''Raw Strings''") But see below...
|-
| Strings (C Style) (*)
| <code>c'hello\nworld'</code>
| supports the common escape sequences, such as "\n", "\t", "\xHH", "\uXXXX"
|-
| Strings (with embedded expressios) (*)
| <code>e'hello {OperatingSystem getLoginName}'</code>
| expanded strings expressions in braces are evaluated at runtime and sliced into the string (also a C-string). Similar to python's f-strings.
|-
| Strings (national language translated with embedded expressios) (*)
| <code>i'hello {OperatingSystem getLoginName}'</code>
| international strings like above, but the string is also possibly translated to a national language
|-
| Symbols
| <code>#'hello'</code> <code>#foo</code> <code>#+</code>
| symbols are interned strings; two symbols with the same characters are guaranteed to be the identical object (not just equal) without quotes, if only alphaNumeric characters
|}

===== Arrays and Objects =====
{| class="wikitable"
|-
| Arrays 
| <code>#( el1 el2 ... elN )</code>
| each element is a literal constant
|-
| Byte Arrays
| <code>#[ b1 b2 ... bN ]</code>
| each byte-element an integer constant in 0..255
|-
| Special Number Arrays (*)
| <code>#XX( v1 v2 ... vN )</code>
| XX: is one of  'u8', 's8', 'u16', 's16', 'u32', 's32', 'u64', 's64', 'f32', 'f64'  and each element being an integer or float constant
|-
| Immediate Inline Objects (*)
| <code>#{ foo: fooValue . bar: barValue }</code>
| fooValue and barValue: are constants
|}

==== Lambda Blocks (Closures) ====

{| class="wikitable"
|-
| Without argument
| <code>[ expr1 . expr2 ... exprN ]</code>
| multiple expressions sep'd by period. When evaluated, the value is the value from the last expression, exprN
|-
| One argument
| <code>[ :arg |     expr1 . expr2 ... exprN ]</code>
|-
| Multiple arguments
| <code>[ :a1 :a2 ... :aN |     expr1 . expr2 ... exprN ]</code>
|-
| Local Variables inside a block
| <code>[ :a1 ... :aN |      |local1 local2 |      expr1 ... exprN ]</code>
|}

==== Expressions ====

{| class="wikitable"
|-
| Unary Expression (without argument)
| <code>receiver messageName</code>
|receiver is itself either a constant, a lambda-block, a unary expression or a parenthesized expression
|-
| Keyword Expression (1 arg)
| <code>receiver messageNamePart:argExpression</code>
|whitespace between the colon and the argExpression is optional.
|-
| Keyword Expression (any number of args)
| <code>receiver     messageNamePart1:argExpression1     messageNamePart2:argExpression2     ...     messageNamePartN:argExpressionN</code>
|-
| Binary Expression
| <code>receiver binOP arg</code>
|with binOP being any combination of special characters: * , + , - , % , & , / , \ , | , = , < , > , ? and ,
 I.e. "<code>foo ==> 123</code>" is the binary message "<code>==></code>" sent to <code>foo</code> with <code>123</code> as argument.
 And "<code>foo ? 123</code>" is the binary message "<code>?</code>" sent to <code>foo</code> with <code>123</code> as argument.
|-
| Cascade Expression (multiple messages to the same receiver)
| <code>receiver     message1 ;     message2 ;     ...     messageN</code></td>
|the receiver expression is evaluated, then multiple messages (separated by ";") are sent to this receiver.
|-
| Parentheses for grouping
| <code>( any expression )</code>
|-
| Assignment
| <code>variable := expression</code>
|can be used as expression.
|-
| Computed Array (Brace Construct) (*)
| <code>{ expr1 . expr2 . ... . exprN }</code>
|instantiates a new Array object with elements from the expressions.
|-
| Computed Inline Object (*)
| <code>{ foo: fooExpr . bar: barExpr }</code>
|fooExpr and barExpr: expressions
|-
| Inline string expressions (*)
| <code>e'p1{e1}p2{e2}...pN{eN}pM'</code>
|syntactic sugar for: <code>('p1%1p2%2...pN%NpM' bindWith:e1 with:e2 ... with:eN)</code> where each pI is a string with possible C-escapes and each eI is a Smalltalk expression
|-
| Array Indexing (*)
| <code>coll[idx]</code> <code>coll[idx1][idx2]</code> <code>coll[idx1][idx2][idx3]</code>
|syntactic sugar for: <code>(coll at:idx)</code> where coll must be an indexable collection, and idx of compatible index type. I.e. integer for array-like collections, hash-key for dictionaries, etc. Up to 4 dimensions are (currently supported)
|-
| Collection instantiation (*)
| <code>someClass[sz]</code> <code>someClass[sz][sz]</code> ...
|syntactic sugar for: <code>(someClass new:sz)</code> where someClass must be a collection class I.e. Array[10] creates an empty array with 10 slots. 1, 2, 3 and 4 dimensions are supported
|-

|}

==== Remaining Syntax ====

{| class="wikitable"
|-
| Local variables (in block or method)
| <code>| var1 var2 ... varN |</code>
|variable declarations must be at the beginning, before any expression.
|-
| Separating multiple expressions (sequence)
| <code>expr1 . expr2 . ... exprN</code>
|expressions (statements) are separated by fullstop (period) characters. The last expression may or may not be followed by a fullstop; if there is one, this is treated like a followup empty statement.
|-
| Return from method
| <code>^ expression</code>
|returns from the enclosing method (also if inside a block-closure)
|}

==== Wellknown (Common) Messages ====

{| class="wikitable"
|-
| Conditional Execution
| <code>boolExpr1 ifTrue:[ ... ] ifFalse:[ ... ]</code>
|variations without true-part, without false part and with the order reversed are available.
|-
| While-Loop (test at top)
| <code>[ boolExpr1 ] whileTrue:[ ... ]</code>
|notice the receiver being a block. A <code>whileFalse:</code> variant is also available.
|-
| Do-Loop (test at bottom)
| <code>[ ... ] doWhile:[ boolExpr1 ]</code>
|notice the test being a block. A <code>doUntil:</code> variant is also available.
|-
| For-Loop
| <code>start to:stop do:[:iterVar | ... ]</code>
|evaluates the block (lambda) for each value in start..stop.
|-
| Enumerating Collections
| <code>collection do:[:elementVar | ... ]</code>
|evaluates the block (i.e. lambda) for each element in the collection.
|-
| Evaluating a Lambda Block   without arguments:
  with arguments:
| <code>aBlock value</code><code>aBlock value:expr1 ... value:exprN</code>
|the number of arguments must match the number expected by the lambda (although varArg lambdas are also available)
|-
| Exception Handling
| <code>[ ... ] on:Error do:[:ex | ... ]</code>
|evaluates the first block; if an error is encountered, evaluate the handler
|}

==== Special 'Control Structures' ====

{| class="wikitable"
|-
| Starting another Thread
| <code>p := [ ... ] fork</code>
|the code inside the block will execute in a separate thread
|-
| Creating, configuring and starting another Thread
| <code>p := [ ... ]   newProcess;   name:'my worker';   priority:5;   resume</code>
|the code inside the block will execute in a separate thread
|-
| Terminating a Thread
| <code>p terminate</code>
|with p referring to the thread as created by newProcess or fork
|-
| Interrupting a Thread
| <code>p interruptWith:[ ... ]</code>
|interrupt the thread and let it execute the given code (in its interrupt seervice)
|-
| Exception Handling
| <code>[ ... ]   on:Error do:[:ex |     ...   ]</code>
|the handler will get an exception argument (ex), which contains additional information, and can be told how to deal with the error
|-
| Exception Handling - proceeding
| <code>[ ... ]   on:Error do:[:ex |     ...     ex proceed   ]</code>
|proceed, as if the error did not happen
|-
| Exception Handling - restarting
| <code>[ ... ]   on:Error do:[:ex |     ...     ex restart   ]</code>
|restart the code from the beginning (usually after the handler did some cleanup, such as lazy loading a missing file...)
|-
| Exception Handling - printing
| <code>[ ... ]   on:Error do:[:ex |     ...     ex description     ...   ]</code>
|contains a human readable description of the error
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ensure:[   ...   ]</code>
|the ensure block will be evaluated in any case
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ifCurtailed:[   ...   ]</code>
|the ifCurtailed block will be evaluated only on a non-regular exit (i.e. when an exception was raised, or the operation was aborted or the thread terminated)
|-
| Early exit from Loops
| <code>[:exit |   ...   code with loop   ...   exit value   ... ] valueWithExit</code>
|the block will be left, when exit is evaluated. Often used as argument of ifTrue:, as in cond ifTrue: exit
|-
| Queries
| <code>Query   answer:something   do:[     ...     Query query     ...   ]</code>
|to provide answers way down to whoever is interested. Queries answer nil if no one is there to answer. Queries are usually more specifically used as subclasses of Query
|-
| Notifications
| <code>Notification   handle:[     ...   ]   do:[     ...     Notification notify:someArg     ...   ]</code>
|to provide information way up to whoever is interested Notifications are usually more specifically used as subclasses of Notification
|-
| Observers 1
| <code>foo onChange:#bla evaluate:[...]. ... foo changed:#bla</code>
|observer with generic block to evaluate
|-
| Observers 2
| <code>foo onChangeSend:#xyz to:someone. ... foo changed</code>
|observer with message send
|-
| Observers 3
| <code>foo addDependent:someone. ... foo changed</code>
|observer with send to update method of target
|}

Queries and Notifications can be seen as observers within the calling hierarchy (i.e. information flows up or down the calling hierarchy), whereas the dependency and anChange mechanisms are independent of the control flow (even between different threads)

==== Synchronization and Timers ====
{| class="wikitable"
|-
| Timed Delay
| <code>Delay waitForSeconds:n</code> <code>Delay waitUntil:(Timestamp now + 10 seconds)</code>
|self explaining
|-
| Sempaphore wait
| <code>s := Semaphore new. ... s wait. ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Sempaphore wait with timeout
| <code>s := Semaphore new. ... s waitWithTimeout:(5 seconds). ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Multi Sempaphore wait
| <code>s1 := Semaphore new. s2 := Semaphore new. ... which := (s1 , s2) wait. ... s2 signal</code>
|wait for any of multiple semaphores
|-
| Synchronized Collections
| <code>a := OrderedCollection new asSharedCollection</code>
|will wrap the collection so that add/remove operations are atomic
|}

==== Wellknown Globals ====

{| class="wikitable"
|-
| Logging and Messaging
| <code>Transcript</code> - the console window <code>Stdout</code> - standard output <code>Stderr</code> - standard error <code>Stdin</code> - standard input <code>Logger</code> - redefinable logger (defaults to standard error)
|-
| Common Useful Dialogs
| <code>Dialog</code> - provides many useful utility functions for standard dialogs eg.<code> Dialog warn:'message' Dialog confirm:'question' Dialog request:'question' Dialog requestFilename:'question' ...</code>
|}

==== Most Wellknown Classes ====

{| class="wikitable"
|-
| Numbers
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Number Number]</code>(abstract superclass) <code>[http://live.exept.de/ClassDoc/classDocOf:,Integer Integer]</code>(integral numbers) <code>[http://live.exept.de/ClassDoc/classDocOf:,Float Float]</code>(inexact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Fraction Fraction]</code>(exact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Complex Complex]</code>
|-
| Collections
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Array Array]</code> (fixed size array) <code>[http://live.exept.de/ClassDoc/classDocOf:,OrderedCollection OrderedCollection]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,List List]</code> (variable size) <code>[http://live.exept.de/ClassDoc/classDocOf:,SortedCollection SortedCollection]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Set Set]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Bag Bag]</code> (unordered) <code>[http://live.exept.de/ClassDoc/classDocOf:,Dictionary Dictionary]</code> (mapped collections) <code>[http://live.exept.de/ClassDoc/classDocOf:,BinaryTree BinaryTree]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,AVLTree AVLTree]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,SharedQueue SharedQueue]</code> (shared, synchronized) many more...
|-
| Process Handling
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Process Process]</code> (lightweight thread) <code>[http://live.exept.de/ClassDoc/classDocOf:,OSProcess OSProcess]</code> (heavyweight OS process) <code>[http://live.exept.de/ClassDoc/classDocOf:,Semaphore Semaphore]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,RecursionLock RecursionLock]</code> (synchronization) <code>[http://live.exept.de/ClassDoc/classDocOf:,Monitor Monitor]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,BoltLock BoltLock]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Delay Delay]</code> (time delays)
|-
| Files & Streams
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Filename Filename]</code> (file naming, directory access, mime type) <code>[http://live.exept.de/ClassDoc/classDocOf:,Stream Stream]</code> (basic stream framework)
 <code>[http://live.exept.de/ClassDoc/classDocOf:,ReadStream ReadStream]</code>,<code>WriteStream</code>,<code>[http://live.exept.de/ClassDoc/classDocOf:,EncodedStream EncodedStream]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,ExternalStream ExternalStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,FileStream FileStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Socket Socket]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,PipeStream PipeStream]</code> (OS-cmd streams)
|-
| Low Level Access
| <code>[http://live.exept.de/ClassDoc/classDocOf:,OperatingSystem OperatingSystem]</code> (OS API calls) <code>[http://live.exept.de/ClassDoc/classDocOf:,Smalltalk Smalltalk]</code>(startup, shutdown and globals) <code>[http://live.exept.de/ClassDoc/classDocOf:,ObjectMemory ObjectMemory]</code>(VM access)
|}

== Examples ==

exampleMethod1
|v1 v2|

v1 := 42.
v2 := v1 sqrt.
Transcript showCR: 'the root of the answer to all questions is: %1' with: v2.

using expanded strings, this can be written as:

exampleMethod1_alternative
|v1|

v1 := 42.
Transcript showCR: e'the root of the answer to all questions is: {v1 sqrt}'.

enumerating elements of an array:

exampleMethod2
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr do:[:el |
Transcript showCR: el
]

enumerating elements of an array with additional index:

exampleMethod3
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr doWithIndex:[:el :idx |
Transcript showCR: e'array element at {idx} is {el} and its class is {el class name}\n'
]

dialogs, string-to-number conversion, error handling:

exampleMethod4
|s1 nr1 s2 nr2 rslt|

s1 := Dialog request:'Enter the first number' initialAnswer:1.
s1 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method
s2 := Dialog request:'Enter the second number' initialAnswer:2.
s2 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr1 := Number readFrom:s1 onError:[^ self].
nr2 := Number readFrom:s2 onError:[^ self].

"/ save division
[
rslt := nr1 / nr2
] on: Error do:[:ex |
(Dialog confirm: e'Error encountered: {ex description}\nProceed with zero?')
ifFalse:[^ self]. "/ no; return from method
ex proceedWith:0
].

Dialog information: e'the result is {rslt}'

dialogs, error handling and complex square root:

exampleMethod4
|s nr rslt|

s := Dialog request:'Enter a number (may be negative)' initialAnswer:2.
s isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr := Number readFrom:s onError:[^ self].

"/ square root; catch imaginary result
[
rslt := nr sqrt
] on: ImaginaryResultError do:[:ex |
(Dialog confirm: e'No solution in R; want to see the complex result?')
ifFalse:[^ self]. "/ no; return from method
rslt := Number trapImaginary:[ nr sqrt ].
"/ rslt is now a complex number
].

Dialog information: e'the result is {rslt}'

== Standard ==
The ANSI Smalltalk standard was approved on May 19, 1998. The official name of the document is ANSI INCITS 319-1998 (R2002). You can order a copy of the final standard
from here: [http://www.techstreet.com/cgi-bin/detail?product_id=56122]
or here [http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI+INCITS+319%2D1998+%28R2002%29]. The name of the document is "American National Standard for Information Systems - Programming Languages - Smalltalk".

You can also download the final draft revision for free: standard_v1_9-indexed.pdf and at [https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf].

The final draft is identical to the official standard except that the draft also has a rationale included (and thus, the draft is arguably more useful than the official standard).

Protocol from ANSI Meeting: [http://www.netjam.org/smalltalk/faq/ANSI-meeting.html]

== Common Language Extensions ==
These are also found in other Smalltalk dialects (eg. [[Glossary#VW|VW]] or [[Glossary#Squeak|Squeak]])

* { expr1 . expr2 . ... } Brace Array Construction Each expression is evaluated (left to right), and an Array with the results is created at execution time. Notice that separating full stops are required, as opposed to constant literal arrays, where elements are separated by spaces. The generated Array is mutable (can be modified), whereas a constant array is not.

== Smalltalk/X Language Extensions ==

These are ST/X specific, and not (as of 2026) implemented in other Smalltalk systems.

=== String Literals ===
* c'...' ''c-strings'' C-like escapes (\n, \t, \xNN, \uNNNN) inside the string are expanded.

* e' ... {expr} ...' ''e-strings'' (expanded epression strings) In addition to C-escapes, embedded expressions are evaluated and their printString is sliced in. Technically, it is converted to ' ... %1 ...' and then expanded using standard String methods.

* i' ... {expr} ...' ''i-strings'' (international strings) similar to e-strings, but the converted string ('... %1 ...') is translated to a national string (via the *.rs file) and then expanded. Allows for different word ordering.

=== Integer Literals ===
* 0xNNNN, 0oNNNN, 0bNNNN C-style hex, octal and binary integers. With arbitrary precision

=== Float Literals ===
* <f>q, <f>Q, etc. Float literal type suffix (q, Q, QD, QL, QO) For a complete list and spec., see the Number documentation.

=== Compact Number Arrays ===
* #u1, #u8, #u16, #u32, #u64 #i8, #i16, #i32, #i64 #f16, #bf16, #f32, #f64 Will generate dense packed vectors (similar to byteArray); format is #X(n1 n2 ... )

Smalltalk Syntax Cheat Sheet

2026-06-07T06:05:48Z

Cg: /* Characters and Strings */

A short, one page summary of what beginners need to know about Smalltalk/X, its syntax and most useful code fragments. As usual, this is only a tiny fraction of what is really awailable, and you should use the builtin class browser to find many more useful functions in the system.

This page was extracted from the "Smalltalk/X Programmers guide - Smalltalk/X Cheat Sheet".
 Smalltalk/X language extensions (w.r.t. other Smalltalk implementations) are marked with '''(*)'''.

== Smalltalk Philosophy ==

* The world consists of objects which '''communicate by sending messages'''.
: A message looks like an english sentence, and might look like "<code>heyYou doSomething</code>".
: In this example, the "heyYou" is called the "''receiver of the message''"
: You may pass additional parameter objects (arguments) as in: "<code>heyYou doSomethingWith: arg</code>"
: or multiple arguments as in <code>"heyYou doSomethingWith: arg1 and: arg2"</code>
: In these examples, the "<code>heyYou</code>" is called the "''receiver of the message''"
* Messages without argument are called "''unary messages''"; those with arguments are called "''keyword messages''"
: For example "<code>Transcript clear</code>" (sends the message "clear" to the Transcript object),
: and "<code>Transcript show: 'hello'</code>" (sends the message "show:" to the Transcript, passing a string argument),
* To allow for arithmetic operations, any non-letter character (except for a few) are treated like a message name and written between the receiver and the one and only argument. These are called "''binary messages''".
: For example: <code>"3 + 4"</code> or <code>"abc , def"</code> (yes, the comma is an operator; it does string concatenation)
* The object my respond (or "answer") by returning some result object. In the above example, "<code>3+4</code>" would answer "7", and "<code>'hello' , 'world'</code>" would answer 'helloworld'
* binary messages have no meaning to the compiler; they are all equal and simply evaluated from left to right.
: admitted, this makes arithmetic a little strange initially; you'll need parentheses as the is not precidence of eg. * over +. The expression "3 + 4 * 5" will be evaluated left to right and answer 35.
* Everything in this world is an object;
: from low level things like booleans, true, false, integer numbers, floating point numbers characters etc.
: there are containers, which can hold on other objects. Technically, all such references are via pointers.
: there are also very complex objects and structures which implement windows, the user interface, communication interfaces, debuggers and even compilers which allow for code to be defined and installed on the fly.
* Every object is associated to a class. Classes define the behavior of their instances. I.e. they define how they respond to messages. The response is implemented by a so called ''method''. That is a piece of code which is executed when a message comes in. A method consist of a number of statements (which are message sends), each separated by a full stop (as in english).
* Classes are themself objects, which respond to messages. Typically class messages would answer new instances, constants or utility functionality. There are also class messages to create new classes.
* Class can inherit common functionality (i.e. method implementations) from a superclass. Thus creating a hierarchy of classes. Typical hierarchies are the Number hierarchy, Collections, Streams and UI Widgets.
* In Smalltalk, every behavior is defined by corresponding message implementations. This includes control features (i.e. if-then-else, loops and exception handling). All of them are implemented as messages being sent to booleans (ifTrue:/ifFalse:) or blocks (whileTrue:)
* Blocks are special objects, which wrap a piece of code. Other languages know them as anonymous functions or lambdas or closures. But the Smalltalk syntax makes them super easy to use: just write a number of expressions inside square brackets, as in "<code>[ Transcript show: 10 factorial ]</code>".
: blocks can be passed as argument with a message send; for example to a boolean: "<code>aBoolean ifTrue: [ Transcript show: 'yes' ]</code>"
: blocks can be stored in variables and passed arounf just like any other object
: blocks can receive messages, especially loop messages: "<code>[ a < 10] whileTrue:[ Transcript showCR: a. a := a + 1 ]</code>".

== Syntax ==

==== Comments ====

{| class="wikitable"
|-
| Regular comment
| <code>" this is a comment "</code>
| ''any text between double quotes''
|-
| EOL-Comment (*)
| <code>"/ this is an End-of-Line comment</code>
| ''text from quote-slash to line end''
|-
| Token-Comment (*)
| <code>"<<END a multiline token-comment up to a line starting with 'END' more commented stuff here ... comment ends here END</code>
| ''text up to line beginning with whatever token came after the initial "<<" ''
|}

==== Literal Constants ====

===== Numbers =====

{| class="wikitable"
|-
| Integers</td>
| <code>12345</code> </code>-12345<code>
|
|-
| Large integers
| <code>1234567890123456789012345</code>…
| ''arbitrary number of digits''
|-
| Integers with radix (Smalltalk style)
| <code>16rAFFE</code>, <code>2r010101</code>, <code>8r0777</code>, <code>3r012012</code>, <code>16r-AFFE</code>, <code>2r-010101</code>
| ''prepend the radix (base) any radix from 2..36 is possible (i.e. 3r222 is a ternary number)''
|-
| Integers with radix (C style) (*)
| <code>0xFEED</code> <code>-0xBEAF</code> <code>0b11011</code>,<code>-0b1100</code>
| ''C/Java/JavaScript style: prepend radix indicator ('x', 'b', 'o') One of hex, binary and octal''
|-
| Floats (IEEE double; roughly 17 digits)
| 12.456 1.234e17 -6.9 -6e-10 Float pi Float e
| ''called "Float", but actually hold double precision'' Common constants can be referred to "by name".
|-
| Short floats (IEEE single; roughly 8 digits) (*)
| <code>1.234f17</code> <code>-6f-10</code>
| this is controlled by a ParserFlag (singlePrecisionFloatF), which is currently defaulted to false. Thus, by default, double precision floats are created with the 'f' exponent character.
|-
| Long floats (IEEE quad; roughly 20 digits) (*)
| <code>1.234q17</code> <code>-6q-10</code>
| ''actual precision depends on the underlying CPU (on x86/x86_64: only 80bit)
|-
| Quad floats; roughly 34 digits (*)
| <code>1.234Q17</code> <code>-6Q-10</code>
| ''computed in software; therefore slower; this is not yet officially released.
|-
| Large floats; roughly 60 digits (*)
| <code>1.234QL17</code> <code>-6QL-10</code>
| ''computed in software; therefore slower; this is not yet officially released.
|-
| Fractions
| <code>(1/3)</code> <code>(17/2)</code>
|
|-
| ScaledDecimals
| <code>1234.53s2</code>
| the number after the s specifies the number of digits
|}

===== Characters and Strings =====

{| class="wikitable"
|-
| Characters
| <code>$a</code> <code>Character space</code> <code>Character nl</code> Also: "<code>null</code>", "<code>tab</code>", "<code>return</code>", "<code>bell</code>"... Or: <code>Character codePoint:n</code>
| Smalltalk does not support any escape sequence Common constants can be referred to "''by name''".
|-
| Strings
| <code>'hello'</code>
| traditionally, Smalltalk does not support any escape sequence inside (i.e. they are what Python calls "''Raw Strings''") But see below...
|-
| Strings (C Style) (*)
| <code>c'hello\nworld'</code>
| supports the common escape sequences, such as "\n", "\t", "\xHH", "\uXXXX"
|-
| Strings (With Embedded Expressios) (*)
| <code>e'hello {OperatingSystem getLoginName}'</code>
| expanded strings expressions in braces are evaluated at runtime and sliced into the string (also a C-string). Similar to python's f-strings.
|-
| Strings (Language translated with Embedded Expressios) (*)
| <code>i'hello {OperatingSystem getLoginName}'</code>
| international strings like above, but the string is also possibly translated to a national language
|-
| Symbols
| <code>#'hello'</code> <code>#foo</code> <code>#+</code>
| symbols are interned strings; two symbols with the same characters are guaranteed to be the identical object (not just equal) without quotes, if only alphaNumeric characters
|}

===== Arrays and Objects =====
{| class="wikitable"
|-
| Arrays 
| <code>#( el1 el2 ... elN )</code>
| each element is a literal constant
|-
| Byte Arrays
| <code>#[ b1 b2 ... bN ]</code>
| each byte-element an integer constant in 0..255
|-
| Special Number Arrays (*)
| <code>#XX( v1 v2 ... vN )</code>
| XX: is one of  'u8', 's8', 'u16', 's16', 'u32', 's32', 'u64', 's64', 'f32', 'f64'  and each element being an integer or float constant
|-
| Immediate Inline Objects (*)
| <code>#{ foo: fooValue . bar: barValue }</code>
| fooValue and barValue: are constants
|}

==== Lambda Blocks (Closures) ====

{| class="wikitable"
|-
| Without argument
| <code>[ expr1 . expr2 ... exprN ]</code>
| multiple expressions sep'd by period. When evaluated, the value is the value from the last expression, exprN
|-
| One argument
| <code>[ :arg |     expr1 . expr2 ... exprN ]</code>
|-
| Multiple arguments
| <code>[ :a1 :a2 ... :aN |     expr1 . expr2 ... exprN ]</code>
|-
| Local Variables inside a block
| <code>[ :a1 ... :aN |      |local1 local2 |      expr1 ... exprN ]</code>
|}

==== Expressions ====

{| class="wikitable"
|-
| Unary Expression (without argument)
| <code>receiver messageName</code>
|receiver is itself either a constant, a lambda-block, a unary expression or a parenthesized expression
|-
| Keyword Expression (1 arg)
| <code>receiver messageNamePart:argExpression</code>
|whitespace between the colon and the argExpression is optional.
|-
| Keyword Expression (any number of args)
| <code>receiver     messageNamePart1:argExpression1     messageNamePart2:argExpression2     ...     messageNamePartN:argExpressionN</code>
|-
| Binary Expression
| <code>receiver binOP arg</code>
|with binOP being any combination of special characters: * , + , - , % , & , / , \ , | , = , < , > , ? and ,
 I.e. "<code>foo ==> 123</code>" is the binary message "<code>==></code>" sent to <code>foo</code> with <code>123</code> as argument.
 And "<code>foo ? 123</code>" is the binary message "<code>?</code>" sent to <code>foo</code> with <code>123</code> as argument.
|-
| Cascade Expression (multiple messages to the same receiver)
| <code>receiver     message1 ;     message2 ;     ...     messageN</code></td>
|the receiver expression is evaluated, then multiple messages (separated by ";") are sent to this receiver.
|-
| Parentheses for grouping
| <code>( any expression )</code>
|-
| Assignment
| <code>variable := expression</code>
|can be used as expression.
|-
| Computed Array (Brace Construct) (*)
| <code>{ expr1 . expr2 . ... . exprN }</code>
|instantiates a new Array object with elements from the expressions.
|-
| Computed Inline Object (*)
| <code>{ foo: fooExpr . bar: barExpr }</code>
|fooExpr and barExpr: expressions
|-
| Inline string expressions (*)
| <code>e'p1{e1}p2{e2}...pN{eN}pM'</code>
|syntactic sugar for: <code>('p1%1p2%2...pN%NpM' bindWith:e1 with:e2 ... with:eN)</code> where each pI is a string with possible C-escapes and each eI is a Smalltalk expression
|-
| Array Indexing (*)
| <code>coll[idx]</code> <code>coll[idx1][idx2]</code> <code>coll[idx1][idx2][idx3]</code>
|syntactic sugar for: <code>(coll at:idx)</code> where coll must be an indexable collection, and idx of compatible index type. I.e. integer for array-like collections, hash-key for dictionaries, etc. Up to 4 dimensions are (currently supported)
|-
| Collection instantiation (*)
| <code>someClass[sz]</code> <code>someClass[sz][sz]</code> ...
|syntactic sugar for: <code>(someClass new:sz)</code> where someClass must be a collection class I.e. Array[10] creates an empty array with 10 slots. 1, 2, 3 and 4 dimensions are supported
|-

|}

==== Remaining Syntax ====

{| class="wikitable"
|-
| Local variables (in block or method)
| <code>| var1 var2 ... varN |</code>
|variable declarations must be at the beginning, before any expression.
|-
| Separating multiple expressions (sequence)
| <code>expr1 . expr2 . ... exprN</code>
|expressions (statements) are separated by fullstop (period) characters. The last expression may or may not be followed by a fullstop; if there is one, this is treated like a followup empty statement.
|-
| Return from method
| <code>^ expression</code>
|returns from the enclosing method (also if inside a block-closure)
|}

==== Wellknown (Common) Messages ====

{| class="wikitable"
|-
| Conditional Execution
| <code>boolExpr1 ifTrue:[ ... ] ifFalse:[ ... ]</code>
|variations without true-part, without false part and with the order reversed are available.
|-
| While-Loop (test at top)
| <code>[ boolExpr1 ] whileTrue:[ ... ]</code>
|notice the receiver being a block. A <code>whileFalse:</code> variant is also available.
|-
| Do-Loop (test at bottom)
| <code>[ ... ] doWhile:[ boolExpr1 ]</code>
|notice the test being a block. A <code>doUntil:</code> variant is also available.
|-
| For-Loop
| <code>start to:stop do:[:iterVar | ... ]</code>
|evaluates the block (lambda) for each value in start..stop.
|-
| Enumerating Collections
| <code>collection do:[:elementVar | ... ]</code>
|evaluates the block (i.e. lambda) for each element in the collection.
|-
| Evaluating a Lambda Block   without arguments:
  with arguments:
| <code>aBlock value</code><code>aBlock value:expr1 ... value:exprN</code>
|the number of arguments must match the number expected by the lambda (although varArg lambdas are also available)
|-
| Exception Handling
| <code>[ ... ] on:Error do:[:ex | ... ]</code>
|evaluates the first block; if an error is encountered, evaluate the handler
|}

==== Special 'Control Structures' ====

{| class="wikitable"
|-
| Starting another Thread
| <code>p := [ ... ] fork</code>
|the code inside the block will execute in a separate thread
|-
| Creating, configuring and starting another Thread
| <code>p := [ ... ]   newProcess;   name:'my worker';   priority:5;   resume</code>
|the code inside the block will execute in a separate thread
|-
| Terminating a Thread
| <code>p terminate</code>
|with p referring to the thread as created by newProcess or fork
|-
| Interrupting a Thread
| <code>p interruptWith:[ ... ]</code>
|interrupt the thread and let it execute the given code (in its interrupt seervice)
|-
| Exception Handling
| <code>[ ... ]   on:Error do:[:ex |     ...   ]</code>
|the handler will get an exception argument (ex), which contains additional information, and can be told how to deal with the error
|-
| Exception Handling - proceeding
| <code>[ ... ]   on:Error do:[:ex |     ...     ex proceed   ]</code>
|proceed, as if the error did not happen
|-
| Exception Handling - restarting
| <code>[ ... ]   on:Error do:[:ex |     ...     ex restart   ]</code>
|restart the code from the beginning (usually after the handler did some cleanup, such as lazy loading a missing file...)
|-
| Exception Handling - printing
| <code>[ ... ]   on:Error do:[:ex |     ...     ex description     ...   ]</code>
|contains a human readable description of the error
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ensure:[   ...   ]</code>
|the ensure block will be evaluated in any case
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ifCurtailed:[   ...   ]</code>
|the ifCurtailed block will be evaluated only on a non-regular exit (i.e. when an exception was raised, or the operation was aborted or the thread terminated)
|-
| Early exit from Loops
| <code>[:exit |   ...   code with loop   ...   exit value   ... ] valueWithExit</code>
|the block will be left, when exit is evaluated. Often used as argument of ifTrue:, as in cond ifTrue: exit
|-
| Queries
| <code>Query   answer:something   do:[     ...     Query query     ...   ]</code>
|to provide answers way down to whoever is interested. Queries answer nil if no one is there to answer. Queries are usually more specifically used as subclasses of Query
|-
| Notifications
| <code>Notification   handle:[     ...   ]   do:[     ...     Notification notify:someArg     ...   ]</code>
|to provide information way up to whoever is interested Notifications are usually more specifically used as subclasses of Notification
|-
| Observers 1
| <code>foo onChange:#bla evaluate:[...]. ... foo changed:#bla</code>
|observer with generic block to evaluate
|-
| Observers 2
| <code>foo onChangeSend:#xyz to:someone. ... foo changed</code>
|observer with message send
|-
| Observers 3
| <code>foo addDependent:someone. ... foo changed</code>
|observer with send to update method of target
|}

Queries and Notifications can be seen as observers within the calling hierarchy (i.e. information flows up or down the calling hierarchy), whereas the dependency and anChange mechanisms are independent of the control flow (even between different threads)

==== Synchronization and Timers ====
{| class="wikitable"
|-
| Timed Delay
| <code>Delay waitForSeconds:n</code> <code>Delay waitUntil:(Timestamp now + 10 seconds)</code>
|self explaining
|-
| Sempaphore wait
| <code>s := Semaphore new. ... s wait. ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Sempaphore wait with timeout
| <code>s := Semaphore new. ... s waitWithTimeout:(5 seconds). ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Multi Sempaphore wait
| <code>s1 := Semaphore new. s2 := Semaphore new. ... which := (s1 , s2) wait. ... s2 signal</code>
|wait for any of multiple semaphores
|-
| Synchronized Collections
| <code>a := OrderedCollection new asSharedCollection</code>
|will wrap the collection so that add/remove operations are atomic
|}

==== Wellknown Globals ====

{| class="wikitable"
|-
| Logging and Messaging
| <code>Transcript</code> - the console window <code>Stdout</code> - standard output <code>Stderr</code> - standard error <code>Stdin</code> - standard input <code>Logger</code> - redefinable logger (defaults to standard error)
|-
| Common Useful Dialogs
| <code>Dialog</code> - provides many useful utility functions for standard dialogs eg.<code> Dialog warn:'message' Dialog confirm:'question' Dialog request:'question' Dialog requestFilename:'question' ...</code>
|}

==== Most Wellknown Classes ====

{| class="wikitable"
|-
| Numbers
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Number Number]</code>(abstract superclass) <code>[http://live.exept.de/ClassDoc/classDocOf:,Integer Integer]</code>(integral numbers) <code>[http://live.exept.de/ClassDoc/classDocOf:,Float Float]</code>(inexact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Fraction Fraction]</code>(exact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Complex Complex]</code>
|-
| Collections
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Array Array]</code> (fixed size array) <code>[http://live.exept.de/ClassDoc/classDocOf:,OrderedCollection OrderedCollection]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,List List]</code> (variable size) <code>[http://live.exept.de/ClassDoc/classDocOf:,SortedCollection SortedCollection]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Set Set]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Bag Bag]</code> (unordered) <code>[http://live.exept.de/ClassDoc/classDocOf:,Dictionary Dictionary]</code> (mapped collections) <code>[http://live.exept.de/ClassDoc/classDocOf:,BinaryTree BinaryTree]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,AVLTree AVLTree]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,SharedQueue SharedQueue]</code> (shared, synchronized) many more...
|-
| Process Handling
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Process Process]</code> (lightweight thread) <code>[http://live.exept.de/ClassDoc/classDocOf:,OSProcess OSProcess]</code> (heavyweight OS process) <code>[http://live.exept.de/ClassDoc/classDocOf:,Semaphore Semaphore]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,RecursionLock RecursionLock]</code> (synchronization) <code>[http://live.exept.de/ClassDoc/classDocOf:,Monitor Monitor]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,BoltLock BoltLock]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Delay Delay]</code> (time delays)
|-
| Files & Streams
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Filename Filename]</code> (file naming, directory access, mime type) <code>[http://live.exept.de/ClassDoc/classDocOf:,Stream Stream]</code> (basic stream framework)
 <code>[http://live.exept.de/ClassDoc/classDocOf:,ReadStream ReadStream]</code>,<code>WriteStream</code>,<code>[http://live.exept.de/ClassDoc/classDocOf:,EncodedStream EncodedStream]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,ExternalStream ExternalStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,FileStream FileStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Socket Socket]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,PipeStream PipeStream]</code> (OS-cmd streams)
|-
| Low Level Access
| <code>[http://live.exept.de/ClassDoc/classDocOf:,OperatingSystem OperatingSystem]</code> (OS API calls) <code>[http://live.exept.de/ClassDoc/classDocOf:,Smalltalk Smalltalk]</code>(startup, shutdown and globals) <code>[http://live.exept.de/ClassDoc/classDocOf:,ObjectMemory ObjectMemory]</code>(VM access)
|}

== Examples ==

exampleMethod1
|v1 v2|

v1 := 42.
v2 := v1 sqrt.
Transcript showCR: 'the root of the answer to all questions is: %1' with: v2.

using expanded strings, this can be written as:

exampleMethod1_alternative
|v1|

v1 := 42.
Transcript showCR: e'the root of the answer to all questions is: {v1 sqrt}'.

enumerating elements of an array:

exampleMethod2
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr do:[:el |
Transcript showCR: el
]

enumerating elements of an array with additional index:

exampleMethod3
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr doWithIndex:[:el :idx |
Transcript showCR: e'array element at {idx} is {el} and its class is {el class name}\n'
]

dialogs, string-to-number conversion, error handling:

exampleMethod4
|s1 nr1 s2 nr2 rslt|

s1 := Dialog request:'Enter the first number' initialAnswer:1.
s1 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method
s2 := Dialog request:'Enter the second number' initialAnswer:2.
s2 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr1 := Number readFrom:s1 onError:[^ self].
nr2 := Number readFrom:s2 onError:[^ self].

"/ save division
[
rslt := nr1 / nr2
] on: Error do:[:ex |
(Dialog confirm: e'Error encountered: {ex description}\nProceed with zero?')
ifFalse:[^ self]. "/ no; return from method
ex proceedWith:0
].

Dialog information: e'the result is {rslt}'

dialogs, error handling and complex square root:

exampleMethod4
|s nr rslt|

s := Dialog request:'Enter a number (may be negative)' initialAnswer:2.
s isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr := Number readFrom:s onError:[^ self].

"/ square root; catch imaginary result
[
rslt := nr sqrt
] on: ImaginaryResultError do:[:ex |
(Dialog confirm: e'No solution in R; want to see the complex result?')
ifFalse:[^ self]. "/ no; return from method
rslt := Number trapImaginary:[ nr sqrt ].
"/ rslt is now a complex number
].

Dialog information: e'the result is {rslt}'

== Standard ==
The ANSI Smalltalk standard was approved on May 19, 1998. The official name of the document is ANSI INCITS 319-1998 (R2002). You can order a copy of the final standard
from here: [http://www.techstreet.com/cgi-bin/detail?product_id=56122]
or here [http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI+INCITS+319%2D1998+%28R2002%29]. The name of the document is "American National Standard for Information Systems - Programming Languages - Smalltalk".

You can also download the final draft revision for free: standard_v1_9-indexed.pdf and at [https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf].

The final draft is identical to the official standard except that the draft also has a rationale included (and thus, the draft is arguably more useful than the official standard).

Protocol from ANSI Meeting: [http://www.netjam.org/smalltalk/faq/ANSI-meeting.html]

== Common Language Extensions ==
These are also found in other Smalltalk dialects (eg. [[Glossary#VW|VW]] or [[Glossary#Squeak|Squeak]])

* { expr1 . expr2 . ... } Brace Array Construction Each expression is evaluated (left to right), and an Array with the results is created at execution time. Notice that separating full stops are required, as opposed to constant literal arrays, where elements are separated by spaces. The generated Array is mutable (can be modified), whereas a constant array is not.

== Smalltalk/X Language Extensions ==

These are ST/X specific, and not (as of 2026) implemented in other Smalltalk systems.

=== String Literals ===
* c'...' ''c-strings'' C-like escapes (\n, \t, \xNN, \uNNNN) inside the string are expanded.

* e' ... {expr} ...' ''e-strings'' (expanded epression strings) In addition to C-escapes, embedded expressions are evaluated and their printString is sliced in. Technically, it is converted to ' ... %1 ...' and then expanded using standard String methods.

* i' ... {expr} ...' ''i-strings'' (international strings) similar to e-strings, but the converted string ('... %1 ...') is translated to a national string (via the *.rs file) and then expanded. Allows for different word ordering.

=== Integer Literals ===
* 0xNNNN, 0oNNNN, 0bNNNN C-style hex, octal and binary integers. With arbitrary precision

=== Float Literals ===
* <f>q, <f>Q, etc. Float literal type suffix (q, Q, QD, QL, QO) For a complete list and spec., see the Number documentation.

=== Compact Number Arrays ===
* #u1, #u8, #u16, #u32, #u64 #i8, #i16, #i32, #i64 #f16, #bf16, #f32, #f64 Will generate dense packed vectors (similar to byteArray); format is #X(n1 n2 ... )

Smalltalk Syntax Cheat Sheet

2026-06-07T05:47:20Z

Cg: /* Characters and Strings */

A short, one page summary of what beginners need to know about Smalltalk/X, its syntax and most useful code fragments. As usual, this is only a tiny fraction of what is really awailable, and you should use the builtin class browser to find many more useful functions in the system.

This page was extracted from the "Smalltalk/X Programmers guide - Smalltalk/X Cheat Sheet".
 Smalltalk/X language extensions (w.r.t. other Smalltalk implementations) are marked with '''(*)'''.

== Smalltalk Philosophy ==

* The world consists of objects which '''communicate by sending messages'''.
: A message looks like an english sentence, and might look like "<code>heyYou doSomething</code>".
: In this example, the "heyYou" is called the "''receiver of the message''"
: You may pass additional parameter objects (arguments) as in: "<code>heyYou doSomethingWith: arg</code>"
: or multiple arguments as in <code>"heyYou doSomethingWith: arg1 and: arg2"</code>
: In these examples, the "<code>heyYou</code>" is called the "''receiver of the message''"
* Messages without argument are called "''unary messages''"; those with arguments are called "''keyword messages''"
: For example "<code>Transcript clear</code>" (sends the message "clear" to the Transcript object),
: and "<code>Transcript show: 'hello'</code>" (sends the message "show:" to the Transcript, passing a string argument),
* To allow for arithmetic operations, any non-letter character (except for a few) are treated like a message name and written between the receiver and the one and only argument. These are called "''binary messages''".
: For example: <code>"3 + 4"</code> or <code>"abc , def"</code> (yes, the comma is an operator; it does string concatenation)
* The object my respond (or "answer") by returning some result object. In the above example, "<code>3+4</code>" would answer "7", and "<code>'hello' , 'world'</code>" would answer 'helloworld'
* binary messages have no meaning to the compiler; they are all equal and simply evaluated from left to right.
: admitted, this makes arithmetic a little strange initially; you'll need parentheses as the is not precidence of eg. * over +. The expression "3 + 4 * 5" will be evaluated left to right and answer 35.
* Everything in this world is an object;
: from low level things like booleans, true, false, integer numbers, floating point numbers characters etc.
: there are containers, which can hold on other objects. Technically, all such references are via pointers.
: there are also very complex objects and structures which implement windows, the user interface, communication interfaces, debuggers and even compilers which allow for code to be defined and installed on the fly.
* Every object is associated to a class. Classes define the behavior of their instances. I.e. they define how they respond to messages. The response is implemented by a so called ''method''. That is a piece of code which is executed when a message comes in. A method consist of a number of statements (which are message sends), each separated by a full stop (as in english).
* Classes are themself objects, which respond to messages. Typically class messages would answer new instances, constants or utility functionality. There are also class messages to create new classes.
* Class can inherit common functionality (i.e. method implementations) from a superclass. Thus creating a hierarchy of classes. Typical hierarchies are the Number hierarchy, Collections, Streams and UI Widgets.
* In Smalltalk, every behavior is defined by corresponding message implementations. This includes control features (i.e. if-then-else, loops and exception handling). All of them are implemented as messages being sent to booleans (ifTrue:/ifFalse:) or blocks (whileTrue:)
* Blocks are special objects, which wrap a piece of code. Other languages know them as anonymous functions or lambdas or closures. But the Smalltalk syntax makes them super easy to use: just write a number of expressions inside square brackets, as in "<code>[ Transcript show: 10 factorial ]</code>".
: blocks can be passed as argument with a message send; for example to a boolean: "<code>aBoolean ifTrue: [ Transcript show: 'yes' ]</code>"
: blocks can be stored in variables and passed arounf just like any other object
: blocks can receive messages, especially loop messages: "<code>[ a < 10] whileTrue:[ Transcript showCR: a. a := a + 1 ]</code>".

== Syntax ==

==== Comments ====

{| class="wikitable"
|-
| Regular comment
| <code>" this is a comment "</code>
| ''any text between double quotes''
|-
| EOL-Comment (*)
| <code>"/ this is an End-of-Line comment</code>
| ''text from quote-slash to line end''
|-
| Token-Comment (*)
| <code>"<<END a multiline token-comment up to a line starting with 'END' more commented stuff here ... comment ends here END</code>
| ''text up to line beginning with whatever token came after the initial "<<" ''
|}

==== Literal Constants ====

===== Numbers =====

{| class="wikitable"
|-
| Integers</td>
| <code>12345</code> </code>-12345<code>
|
|-
| Large integers
| <code>1234567890123456789012345</code>…
| ''arbitrary number of digits''
|-
| Integers with radix (Smalltalk style)
| <code>16rAFFE</code>, <code>2r010101</code>, <code>8r0777</code>, <code>3r012012</code>, <code>16r-AFFE</code>, <code>2r-010101</code>
| ''prepend the radix (base) any radix from 2..36 is possible (i.e. 3r222 is a ternary number)''
|-
| Integers with radix (C style) (*)
| <code>0xFEED</code> <code>-0xBEAF</code> <code>0b11011</code>,<code>-0b1100</code>
| ''C/Java/JavaScript style: prepend radix indicator ('x', 'b', 'o') One of hex, binary and octal''
|-
| Floats (IEEE double; roughly 17 digits)
| 12.456 1.234e17 -6.9 -6e-10 Float pi Float e
| ''called "Float", but actually hold double precision'' Common constants can be referred to "by name".
|-
| Short floats (IEEE single; roughly 8 digits) (*)
| <code>1.234f17</code> <code>-6f-10</code>
| this is controlled by a ParserFlag (singlePrecisionFloatF), which is currently defaulted to false. Thus, by default, double precision floats are created with the 'f' exponent character.
|-
| Long floats (IEEE quad; roughly 20 digits) (*)
| <code>1.234q17</code> <code>-6q-10</code>
| ''actual precision depends on the underlying CPU (on x86/x86_64: only 80bit)
|-
| Quad floats; roughly 34 digits (*)
| <code>1.234Q17</code> <code>-6Q-10</code>
| ''computed in software; therefore slower; this is not yet officially released.
|-
| Large floats; roughly 60 digits (*)
| <code>1.234QL17</code> <code>-6QL-10</code>
| ''computed in software; therefore slower; this is not yet officially released.
|-
| Fractions
| <code>(1/3)</code> <code>(17/2)</code>
|
|-
| ScaledDecimals
| <code>1234.53s2</code>
| the number after the s specifies the number of digits
|}

===== Characters and Strings =====

{| class="wikitable"
|-
| Characters
| <code>$a</code> <code>Character space</code> <code>Character nl</code> Also: "<code>null</code>", "<code>tab</code>", "<code>return</code>", "<code>bell</code>"... Or: <code>Character codePoint:n</code>
| ''traditionally, Smalltalk does not support any escape sequence'' Common constants can be referred to "by name".
|-
| Strings
| <code>'hello'</code>
| ''traditionally, Smalltalk does not support any escape sequence inside'' (I.e. they are what Python calls ''Raw Strings'') But see below...
|-
| Strings (C Style) (*)
| <code>c'hello\nworld'</code>
| ''supports the common escape sequences, such as "\n", "\t", "\xHH" ''
|-
| Strings (With Embedded Expressios) (*)
| <code>e'hello {OperatingSystem getLoginName}'</code>
| ''expressions in braces are evaluated at runtime and sliced into the string (also a C-string)''. Similar to python's f-strings.
|-
| Strings (Language translated with Embedded Expressios) (*)
| <code>i'hello {OperatingSystem getLoginName}'</code>
| ''like above, but the string is also possibly translated to a national language''
|-
| Symbols
| <code>#'hello'</code> <code>#foo</code>
| without quotes, if only alphaNumeric characters
|}

===== Arrays and Objects =====
{| class="wikitable"
|-
| Arrays 
| <code>#( el1 el2 ... elN )</code>
| each element is a literal constant
|-
| Byte Arrays
| <code>#[ b1 b2 ... bN ]</code>
| each byte-element an integer constant in 0..255
|-
| Special Number Arrays (*)
| <code>#XX( v1 v2 ... vN )</code>
| XX: is one of  'u8', 's8', 'u16', 's16', 'u32', 's32', 'u64', 's64', 'f32', 'f64'  and each element being an integer or float constant
|-
| Immediate Inline Objects (*)
| <code>#{ foo: fooValue . bar: barValue }</code>
| fooValue and barValue: are constants
|}

==== Lambda Blocks (Closures) ====

{| class="wikitable"
|-
| Without argument
| <code>[ expr1 . expr2 ... exprN ]</code>
| multiple expressions sep'd by period. When evaluated, the value is the value from the last expression, exprN
|-
| One argument
| <code>[ :arg |     expr1 . expr2 ... exprN ]</code>
|-
| Multiple arguments
| <code>[ :a1 :a2 ... :aN |     expr1 . expr2 ... exprN ]</code>
|-
| Local Variables inside a block
| <code>[ :a1 ... :aN |      |local1 local2 |      expr1 ... exprN ]</code>
|}

==== Expressions ====

{| class="wikitable"
|-
| Unary Expression (without argument)
| <code>receiver messageName</code>
|receiver is itself either a constant, a lambda-block, a unary expression or a parenthesized expression
|-
| Keyword Expression (1 arg)
| <code>receiver messageNamePart:argExpression</code>
|whitespace between the colon and the argExpression is optional.
|-
| Keyword Expression (any number of args)
| <code>receiver     messageNamePart1:argExpression1     messageNamePart2:argExpression2     ...     messageNamePartN:argExpressionN</code>
|-
| Binary Expression
| <code>receiver binOP arg</code>
|with binOP being any combination of special characters: * , + , - , % , & , / , \ , | , = , < , > , ? and ,
 I.e. "<code>foo ==> 123</code>" is the binary message "<code>==></code>" sent to <code>foo</code> with <code>123</code> as argument.
 And "<code>foo ? 123</code>" is the binary message "<code>?</code>" sent to <code>foo</code> with <code>123</code> as argument.
|-
| Cascade Expression (multiple messages to the same receiver)
| <code>receiver     message1 ;     message2 ;     ...     messageN</code></td>
|the receiver expression is evaluated, then multiple messages (separated by ";") are sent to this receiver.
|-
| Parentheses for grouping
| <code>( any expression )</code>
|-
| Assignment
| <code>variable := expression</code>
|can be used as expression.
|-
| Computed Array (Brace Construct) (*)
| <code>{ expr1 . expr2 . ... . exprN }</code>
|instantiates a new Array object with elements from the expressions.
|-
| Computed Inline Object (*)
| <code>{ foo: fooExpr . bar: barExpr }</code>
|fooExpr and barExpr: expressions
|-
| Inline string expressions (*)
| <code>e'p1{e1}p2{e2}...pN{eN}pM'</code>
|syntactic sugar for: <code>('p1%1p2%2...pN%NpM' bindWith:e1 with:e2 ... with:eN)</code> where each pI is a string with possible C-escapes and each eI is a Smalltalk expression
|-
| Array Indexing (*)
| <code>coll[idx]</code> <code>coll[idx1][idx2]</code> <code>coll[idx1][idx2][idx3]</code>
|syntactic sugar for: <code>(coll at:idx)</code> where coll must be an indexable collection, and idx of compatible index type. I.e. integer for array-like collections, hash-key for dictionaries, etc. Up to 4 dimensions are (currently supported)
|-
| Collection instantiation (*)
| <code>someClass[sz]</code> <code>someClass[sz][sz]</code> ...
|syntactic sugar for: <code>(someClass new:sz)</code> where someClass must be a collection class I.e. Array[10] creates an empty array with 10 slots. 1, 2, 3 and 4 dimensions are supported
|-

|}

==== Remaining Syntax ====

{| class="wikitable"
|-
| Local variables (in block or method)
| <code>| var1 var2 ... varN |</code>
|variable declarations must be at the beginning, before any expression.
|-
| Separating multiple expressions (sequence)
| <code>expr1 . expr2 . ... exprN</code>
|expressions (statements) are separated by fullstop (period) characters. The last expression may or may not be followed by a fullstop; if there is one, this is treated like a followup empty statement.
|-
| Return from method
| <code>^ expression</code>
|returns from the enclosing method (also if inside a block-closure)
|}

==== Wellknown (Common) Messages ====

{| class="wikitable"
|-
| Conditional Execution
| <code>boolExpr1 ifTrue:[ ... ] ifFalse:[ ... ]</code>
|variations without true-part, without false part and with the order reversed are available.
|-
| While-Loop (test at top)
| <code>[ boolExpr1 ] whileTrue:[ ... ]</code>
|notice the receiver being a block. A <code>whileFalse:</code> variant is also available.
|-
| Do-Loop (test at bottom)
| <code>[ ... ] doWhile:[ boolExpr1 ]</code>
|notice the test being a block. A <code>doUntil:</code> variant is also available.
|-
| For-Loop
| <code>start to:stop do:[:iterVar | ... ]</code>
|evaluates the block (lambda) for each value in start..stop.
|-
| Enumerating Collections
| <code>collection do:[:elementVar | ... ]</code>
|evaluates the block (i.e. lambda) for each element in the collection.
|-
| Evaluating a Lambda Block   without arguments:
  with arguments:
| <code>aBlock value</code><code>aBlock value:expr1 ... value:exprN</code>
|the number of arguments must match the number expected by the lambda (although varArg lambdas are also available)
|-
| Exception Handling
| <code>[ ... ] on:Error do:[:ex | ... ]</code>
|evaluates the first block; if an error is encountered, evaluate the handler
|}

==== Special 'Control Structures' ====

{| class="wikitable"
|-
| Starting another Thread
| <code>p := [ ... ] fork</code>
|the code inside the block will execute in a separate thread
|-
| Creating, configuring and starting another Thread
| <code>p := [ ... ]   newProcess;   name:'my worker';   priority:5;   resume</code>
|the code inside the block will execute in a separate thread
|-
| Terminating a Thread
| <code>p terminate</code>
|with p referring to the thread as created by newProcess or fork
|-
| Interrupting a Thread
| <code>p interruptWith:[ ... ]</code>
|interrupt the thread and let it execute the given code (in its interrupt seervice)
|-
| Exception Handling
| <code>[ ... ]   on:Error do:[:ex |     ...   ]</code>
|the handler will get an exception argument (ex), which contains additional information, and can be told how to deal with the error
|-
| Exception Handling - proceeding
| <code>[ ... ]   on:Error do:[:ex |     ...     ex proceed   ]</code>
|proceed, as if the error did not happen
|-
| Exception Handling - restarting
| <code>[ ... ]   on:Error do:[:ex |     ...     ex restart   ]</code>
|restart the code from the beginning (usually after the handler did some cleanup, such as lazy loading a missing file...)
|-
| Exception Handling - printing
| <code>[ ... ]   on:Error do:[:ex |     ...     ex description     ...   ]</code>
|contains a human readable description of the error
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ensure:[   ...   ]</code>
|the ensure block will be evaluated in any case
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ifCurtailed:[   ...   ]</code>
|the ifCurtailed block will be evaluated only on a non-regular exit (i.e. when an exception was raised, or the operation was aborted or the thread terminated)
|-
| Early exit from Loops
| <code>[:exit |   ...   code with loop   ...   exit value   ... ] valueWithExit</code>
|the block will be left, when exit is evaluated. Often used as argument of ifTrue:, as in cond ifTrue: exit
|-
| Queries
| <code>Query   answer:something   do:[     ...     Query query     ...   ]</code>
|to provide answers way down to whoever is interested. Queries answer nil if no one is there to answer. Queries are usually more specifically used as subclasses of Query
|-
| Notifications
| <code>Notification   handle:[     ...   ]   do:[     ...     Notification notify:someArg     ...   ]</code>
|to provide information way up to whoever is interested Notifications are usually more specifically used as subclasses of Notification
|-
| Observers 1
| <code>foo onChange:#bla evaluate:[...]. ... foo changed:#bla</code>
|observer with generic block to evaluate
|-
| Observers 2
| <code>foo onChangeSend:#xyz to:someone. ... foo changed</code>
|observer with message send
|-
| Observers 3
| <code>foo addDependent:someone. ... foo changed</code>
|observer with send to update method of target
|}

Queries and Notifications can be seen as observers within the calling hierarchy (i.e. information flows up or down the calling hierarchy), whereas the dependency and anChange mechanisms are independent of the control flow (even between different threads)

==== Synchronization and Timers ====
{| class="wikitable"
|-
| Timed Delay
| <code>Delay waitForSeconds:n</code> <code>Delay waitUntil:(Timestamp now + 10 seconds)</code>
|self explaining
|-
| Sempaphore wait
| <code>s := Semaphore new. ... s wait. ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Sempaphore wait with timeout
| <code>s := Semaphore new. ... s waitWithTimeout:(5 seconds). ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Multi Sempaphore wait
| <code>s1 := Semaphore new. s2 := Semaphore new. ... which := (s1 , s2) wait. ... s2 signal</code>
|wait for any of multiple semaphores
|-
| Synchronized Collections
| <code>a := OrderedCollection new asSharedCollection</code>
|will wrap the collection so that add/remove operations are atomic
|}

==== Wellknown Globals ====

{| class="wikitable"
|-
| Logging and Messaging
| <code>Transcript</code> - the console window <code>Stdout</code> - standard output <code>Stderr</code> - standard error <code>Stdin</code> - standard input <code>Logger</code> - redefinable logger (defaults to standard error)
|-
| Common Useful Dialogs
| <code>Dialog</code> - provides many useful utility functions for standard dialogs eg.<code> Dialog warn:'message' Dialog confirm:'question' Dialog request:'question' Dialog requestFilename:'question' ...</code>
|}

==== Most Wellknown Classes ====

{| class="wikitable"
|-
| Numbers
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Number Number]</code>(abstract superclass) <code>[http://live.exept.de/ClassDoc/classDocOf:,Integer Integer]</code>(integral numbers) <code>[http://live.exept.de/ClassDoc/classDocOf:,Float Float]</code>(inexact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Fraction Fraction]</code>(exact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Complex Complex]</code>
|-
| Collections
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Array Array]</code> (fixed size array) <code>[http://live.exept.de/ClassDoc/classDocOf:,OrderedCollection OrderedCollection]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,List List]</code> (variable size) <code>[http://live.exept.de/ClassDoc/classDocOf:,SortedCollection SortedCollection]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Set Set]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Bag Bag]</code> (unordered) <code>[http://live.exept.de/ClassDoc/classDocOf:,Dictionary Dictionary]</code> (mapped collections) <code>[http://live.exept.de/ClassDoc/classDocOf:,BinaryTree BinaryTree]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,AVLTree AVLTree]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,SharedQueue SharedQueue]</code> (shared, synchronized) many more...
|-
| Process Handling
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Process Process]</code> (lightweight thread) <code>[http://live.exept.de/ClassDoc/classDocOf:,OSProcess OSProcess]</code> (heavyweight OS process) <code>[http://live.exept.de/ClassDoc/classDocOf:,Semaphore Semaphore]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,RecursionLock RecursionLock]</code> (synchronization) <code>[http://live.exept.de/ClassDoc/classDocOf:,Monitor Monitor]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,BoltLock BoltLock]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Delay Delay]</code> (time delays)
|-
| Files & Streams
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Filename Filename]</code> (file naming, directory access, mime type) <code>[http://live.exept.de/ClassDoc/classDocOf:,Stream Stream]</code> (basic stream framework)
 <code>[http://live.exept.de/ClassDoc/classDocOf:,ReadStream ReadStream]</code>,<code>WriteStream</code>,<code>[http://live.exept.de/ClassDoc/classDocOf:,EncodedStream EncodedStream]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,ExternalStream ExternalStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,FileStream FileStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Socket Socket]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,PipeStream PipeStream]</code> (OS-cmd streams)
|-
| Low Level Access
| <code>[http://live.exept.de/ClassDoc/classDocOf:,OperatingSystem OperatingSystem]</code> (OS API calls) <code>[http://live.exept.de/ClassDoc/classDocOf:,Smalltalk Smalltalk]</code>(startup, shutdown and globals) <code>[http://live.exept.de/ClassDoc/classDocOf:,ObjectMemory ObjectMemory]</code>(VM access)
|}

== Examples ==

exampleMethod1
|v1 v2|

v1 := 42.
v2 := v1 sqrt.
Transcript showCR: 'the root of the answer to all questions is: %1' with: v2.

using expanded strings, this can be written as:

exampleMethod1_alternative
|v1|

v1 := 42.
Transcript showCR: e'the root of the answer to all questions is: {v1 sqrt}'.

enumerating elements of an array:

exampleMethod2
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr do:[:el |
Transcript showCR: el
]

enumerating elements of an array with additional index:

exampleMethod3
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr doWithIndex:[:el :idx |
Transcript showCR: e'array element at {idx} is {el} and its class is {el class name}\n'
]

dialogs, string-to-number conversion, error handling:

exampleMethod4
|s1 nr1 s2 nr2 rslt|

s1 := Dialog request:'Enter the first number' initialAnswer:1.
s1 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method
s2 := Dialog request:'Enter the second number' initialAnswer:2.
s2 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr1 := Number readFrom:s1 onError:[^ self].
nr2 := Number readFrom:s2 onError:[^ self].

"/ save division
[
rslt := nr1 / nr2
] on: Error do:[:ex |
(Dialog confirm: e'Error encountered: {ex description}\nProceed with zero?')
ifFalse:[^ self]. "/ no; return from method
ex proceedWith:0
].

Dialog information: e'the result is {rslt}'

dialogs, error handling and complex square root:

exampleMethod4
|s nr rslt|

s := Dialog request:'Enter a number (may be negative)' initialAnswer:2.
s isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr := Number readFrom:s onError:[^ self].

"/ square root; catch imaginary result
[
rslt := nr sqrt
] on: ImaginaryResultError do:[:ex |
(Dialog confirm: e'No solution in R; want to see the complex result?')
ifFalse:[^ self]. "/ no; return from method
rslt := Number trapImaginary:[ nr sqrt ].
"/ rslt is now a complex number
].

Dialog information: e'the result is {rslt}'

== Standard ==
The ANSI Smalltalk standard was approved on May 19, 1998. The official name of the document is ANSI INCITS 319-1998 (R2002). You can order a copy of the final standard
from here: [http://www.techstreet.com/cgi-bin/detail?product_id=56122]
or here [http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI+INCITS+319%2D1998+%28R2002%29]. The name of the document is "American National Standard for Information Systems - Programming Languages - Smalltalk".

You can also download the final draft revision for free: standard_v1_9-indexed.pdf and at [https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf].

The final draft is identical to the official standard except that the draft also has a rationale included (and thus, the draft is arguably more useful than the official standard).

Protocol from ANSI Meeting: [http://www.netjam.org/smalltalk/faq/ANSI-meeting.html]

== Common Language Extensions ==
These are also found in other Smalltalk dialects (eg. [[Glossary#VW|VW]] or [[Glossary#Squeak|Squeak]])

* { expr1 . expr2 . ... } Brace Array Construction Each expression is evaluated (left to right), and an Array with the results is created at execution time. Notice that separating full stops are required, as opposed to constant literal arrays, where elements are separated by spaces. The generated Array is mutable (can be modified), whereas a constant array is not.

== Smalltalk/X Language Extensions ==

These are ST/X specific, and not (as of 2026) implemented in other Smalltalk systems.

=== String Literals ===
* c'...' ''c-strings'' C-like escapes (\n, \t, \xNN, \uNNNN) inside the string are expanded.

* e' ... {expr} ...' ''e-strings'' (expanded epression strings) In addition to C-escapes, embedded expressions are evaluated and their printString is sliced in. Technically, it is converted to ' ... %1 ...' and then expanded using standard String methods.

* i' ... {expr} ...' ''i-strings'' (international strings) similar to e-strings, but the converted string ('... %1 ...') is translated to a national string (via the *.rs file) and then expanded. Allows for different word ordering.

=== Integer Literals ===
* 0xNNNN, 0oNNNN, 0bNNNN C-style hex, octal and binary integers. With arbitrary precision

=== Float Literals ===
* <f>q, <f>Q, etc. Float literal type suffix (q, Q, QD, QL, QO) For a complete list and spec., see the Number documentation.

=== Compact Number Arrays ===
* #u1, #u8, #u16, #u32, #u64 #i8, #i16, #i32, #i64 #f16, #bf16, #f32, #f64 Will generate dense packed vectors (similar to byteArray); format is #X(n1 n2 ... )

Smalltalk Syntax Cheat Sheet

2026-06-07T05:45:26Z

Cg: /* Float Literals */

A short, one page summary of what beginners need to know about Smalltalk/X, its syntax and most useful code fragments. As usual, this is only a tiny fraction of what is really awailable, and you should use the builtin class browser to find many more useful functions in the system.

This page was extracted from the "Smalltalk/X Programmers guide - Smalltalk/X Cheat Sheet".
 Smalltalk/X language extensions (w.r.t. other Smalltalk implementations) are marked with '''(*)'''.

== Smalltalk Philosophy ==

* The world consists of objects which '''communicate by sending messages'''.
: A message looks like an english sentence, and might look like "<code>heyYou doSomething</code>".
: In this example, the "heyYou" is called the "''receiver of the message''"
: You may pass additional parameter objects (arguments) as in: "<code>heyYou doSomethingWith: arg</code>"
: or multiple arguments as in <code>"heyYou doSomethingWith: arg1 and: arg2"</code>
: In these examples, the "<code>heyYou</code>" is called the "''receiver of the message''"
* Messages without argument are called "''unary messages''"; those with arguments are called "''keyword messages''"
: For example "<code>Transcript clear</code>" (sends the message "clear" to the Transcript object),
: and "<code>Transcript show: 'hello'</code>" (sends the message "show:" to the Transcript, passing a string argument),
* To allow for arithmetic operations, any non-letter character (except for a few) are treated like a message name and written between the receiver and the one and only argument. These are called "''binary messages''".
: For example: <code>"3 + 4"</code> or <code>"abc , def"</code> (yes, the comma is an operator; it does string concatenation)
* The object my respond (or "answer") by returning some result object. In the above example, "<code>3+4</code>" would answer "7", and "<code>'hello' , 'world'</code>" would answer 'helloworld'
* binary messages have no meaning to the compiler; they are all equal and simply evaluated from left to right.
: admitted, this makes arithmetic a little strange initially; you'll need parentheses as the is not precidence of eg. * over +. The expression "3 + 4 * 5" will be evaluated left to right and answer 35.
* Everything in this world is an object;
: from low level things like booleans, true, false, integer numbers, floating point numbers characters etc.
: there are containers, which can hold on other objects. Technically, all such references are via pointers.
: there are also very complex objects and structures which implement windows, the user interface, communication interfaces, debuggers and even compilers which allow for code to be defined and installed on the fly.
* Every object is associated to a class. Classes define the behavior of their instances. I.e. they define how they respond to messages. The response is implemented by a so called ''method''. That is a piece of code which is executed when a message comes in. A method consist of a number of statements (which are message sends), each separated by a full stop (as in english).
* Classes are themself objects, which respond to messages. Typically class messages would answer new instances, constants or utility functionality. There are also class messages to create new classes.
* Class can inherit common functionality (i.e. method implementations) from a superclass. Thus creating a hierarchy of classes. Typical hierarchies are the Number hierarchy, Collections, Streams and UI Widgets.
* In Smalltalk, every behavior is defined by corresponding message implementations. This includes control features (i.e. if-then-else, loops and exception handling). All of them are implemented as messages being sent to booleans (ifTrue:/ifFalse:) or blocks (whileTrue:)
* Blocks are special objects, which wrap a piece of code. Other languages know them as anonymous functions or lambdas or closures. But the Smalltalk syntax makes them super easy to use: just write a number of expressions inside square brackets, as in "<code>[ Transcript show: 10 factorial ]</code>".
: blocks can be passed as argument with a message send; for example to a boolean: "<code>aBoolean ifTrue: [ Transcript show: 'yes' ]</code>"
: blocks can be stored in variables and passed arounf just like any other object
: blocks can receive messages, especially loop messages: "<code>[ a < 10] whileTrue:[ Transcript showCR: a. a := a + 1 ]</code>".

== Syntax ==

==== Comments ====

{| class="wikitable"
|-
| Regular comment
| <code>" this is a comment "</code>
| ''any text between double quotes''
|-
| EOL-Comment (*)
| <code>"/ this is an End-of-Line comment</code>
| ''text from quote-slash to line end''
|-
| Token-Comment (*)
| <code>"<<END a multiline token-comment up to a line starting with 'END' more commented stuff here ... comment ends here END</code>
| ''text up to line beginning with whatever token came after the initial "<<" ''
|}

==== Literal Constants ====

===== Numbers =====

{| class="wikitable"
|-
| Integers</td>
| <code>12345</code> </code>-12345<code>
|
|-
| Large integers
| <code>1234567890123456789012345</code>…
| ''arbitrary number of digits''
|-
| Integers with radix (Smalltalk style)
| <code>16rAFFE</code>, <code>2r010101</code>, <code>8r0777</code>, <code>3r012012</code>, <code>16r-AFFE</code>, <code>2r-010101</code>
| ''prepend the radix (base) any radix from 2..36 is possible (i.e. 3r222 is a ternary number)''
|-
| Integers with radix (C style) (*)
| <code>0xFEED</code> <code>-0xBEAF</code> <code>0b11011</code>,<code>-0b1100</code>
| ''C/Java/JavaScript style: prepend radix indicator ('x', 'b', 'o') One of hex, binary and octal''
|-
| Floats (IEEE double; roughly 17 digits)
| 12.456 1.234e17 -6.9 -6e-10 Float pi Float e
| ''called "Float", but actually hold double precision'' Common constants can be referred to "by name".
|-
| Short floats (IEEE single; roughly 8 digits) (*)
| <code>1.234f17</code> <code>-6f-10</code>
| this is controlled by a ParserFlag (singlePrecisionFloatF), which is currently defaulted to false. Thus, by default, double precision floats are created with the 'f' exponent character.
|-
| Long floats (IEEE quad; roughly 20 digits) (*)
| <code>1.234q17</code> <code>-6q-10</code>
| ''actual precision depends on the underlying CPU (on x86/x86_64: only 80bit)
|-
| Quad floats; roughly 34 digits (*)
| <code>1.234Q17</code> <code>-6Q-10</code>
| ''computed in software; therefore slower; this is not yet officially released.
|-
| Large floats; roughly 60 digits (*)
| <code>1.234QL17</code> <code>-6QL-10</code>
| ''computed in software; therefore slower; this is not yet officially released.
|-
| Fractions
| <code>(1/3)</code> <code>(17/2)</code>
|
|-
| ScaledDecimals
| <code>1234.53s2</code>
| the number after the s specifies the number of digits
|}

===== Characters and Strings =====

{| class="wikitable"
|-
| Characters
| <code>$a</code> <code>Character space</code> <code>Character nl</code> Also: "<code>null</code>", "<code>tab</code>", "<code>return</code>", "<code>bell</code>"... Or: <code>Character codePoint:n</code>
| ''traditionally, Smalltalk does not support any escape sequence'' Common constants can be referred to "by name".
|-
| Strings
| <code>'hello'</code>
| ''traditionally, Smalltalk does not support any escape sequence inside'' (I.e. they are what Python calls ''Raw Strings'') But see below...
|-
| Strings (C Style) (*)
| <code>c'hello\nworld'</code>
| ''supports the common escape sequences, such as "\n", "\t", "\xHH" ''
|-
| Strings (With Embedded Expressios) (*)
| <code>e'hello {OperatingSystem getLoginName}'</code>
| ''expressions in braces are evaluated at runtime and sliced into the string (also a C-string)''
|-
| Strings (Language translated with Embedded Expressios) (*)
| <code>i'hello {OperatingSystem getLoginName}'</code>
| ''like above, but the string is also possibly translated to a national language''
|-
| Symbols
| <code>#'hello'</code> <code>#foo</code>
| without quotes, if only alphaNumeric characters
|}

===== Arrays and Objects =====
{| class="wikitable"
|-
| Arrays 
| <code>#( el1 el2 ... elN )</code>
| each element is a literal constant
|-
| Byte Arrays
| <code>#[ b1 b2 ... bN ]</code>
| each byte-element an integer constant in 0..255
|-
| Special Number Arrays (*)
| <code>#XX( v1 v2 ... vN )</code>
| XX: is one of  'u8', 's8', 'u16', 's16', 'u32', 's32', 'u64', 's64', 'f32', 'f64'  and each element being an integer or float constant
|-
| Immediate Inline Objects (*)
| <code>#{ foo: fooValue . bar: barValue }</code>
| fooValue and barValue: are constants
|}

==== Lambda Blocks (Closures) ====

{| class="wikitable"
|-
| Without argument
| <code>[ expr1 . expr2 ... exprN ]</code>
| multiple expressions sep'd by period. When evaluated, the value is the value from the last expression, exprN
|-
| One argument
| <code>[ :arg |     expr1 . expr2 ... exprN ]</code>
|-
| Multiple arguments
| <code>[ :a1 :a2 ... :aN |     expr1 . expr2 ... exprN ]</code>
|-
| Local Variables inside a block
| <code>[ :a1 ... :aN |      |local1 local2 |      expr1 ... exprN ]</code>
|}

==== Expressions ====

{| class="wikitable"
|-
| Unary Expression (without argument)
| <code>receiver messageName</code>
|receiver is itself either a constant, a lambda-block, a unary expression or a parenthesized expression
|-
| Keyword Expression (1 arg)
| <code>receiver messageNamePart:argExpression</code>
|whitespace between the colon and the argExpression is optional.
|-
| Keyword Expression (any number of args)
| <code>receiver     messageNamePart1:argExpression1     messageNamePart2:argExpression2     ...     messageNamePartN:argExpressionN</code>
|-
| Binary Expression
| <code>receiver binOP arg</code>
|with binOP being any combination of special characters: * , + , - , % , & , / , \ , | , = , < , > , ? and ,
 I.e. "<code>foo ==> 123</code>" is the binary message "<code>==></code>" sent to <code>foo</code> with <code>123</code> as argument.
 And "<code>foo ? 123</code>" is the binary message "<code>?</code>" sent to <code>foo</code> with <code>123</code> as argument.
|-
| Cascade Expression (multiple messages to the same receiver)
| <code>receiver     message1 ;     message2 ;     ...     messageN</code></td>
|the receiver expression is evaluated, then multiple messages (separated by ";") are sent to this receiver.
|-
| Parentheses for grouping
| <code>( any expression )</code>
|-
| Assignment
| <code>variable := expression</code>
|can be used as expression.
|-
| Computed Array (Brace Construct) (*)
| <code>{ expr1 . expr2 . ... . exprN }</code>
|instantiates a new Array object with elements from the expressions.
|-
| Computed Inline Object (*)
| <code>{ foo: fooExpr . bar: barExpr }</code>
|fooExpr and barExpr: expressions
|-
| Inline string expressions (*)
| <code>e'p1{e1}p2{e2}...pN{eN}pM'</code>
|syntactic sugar for: <code>('p1%1p2%2...pN%NpM' bindWith:e1 with:e2 ... with:eN)</code> where each pI is a string with possible C-escapes and each eI is a Smalltalk expression
|-
| Array Indexing (*)
| <code>coll[idx]</code> <code>coll[idx1][idx2]</code> <code>coll[idx1][idx2][idx3]</code>
|syntactic sugar for: <code>(coll at:idx)</code> where coll must be an indexable collection, and idx of compatible index type. I.e. integer for array-like collections, hash-key for dictionaries, etc. Up to 4 dimensions are (currently supported)
|-
| Collection instantiation (*)
| <code>someClass[sz]</code> <code>someClass[sz][sz]</code> ...
|syntactic sugar for: <code>(someClass new:sz)</code> where someClass must be a collection class I.e. Array[10] creates an empty array with 10 slots. 1, 2, 3 and 4 dimensions are supported
|-

|}

==== Remaining Syntax ====

{| class="wikitable"
|-
| Local variables (in block or method)
| <code>| var1 var2 ... varN |</code>
|variable declarations must be at the beginning, before any expression.
|-
| Separating multiple expressions (sequence)
| <code>expr1 . expr2 . ... exprN</code>
|expressions (statements) are separated by fullstop (period) characters. The last expression may or may not be followed by a fullstop; if there is one, this is treated like a followup empty statement.
|-
| Return from method
| <code>^ expression</code>
|returns from the enclosing method (also if inside a block-closure)
|}

==== Wellknown (Common) Messages ====

{| class="wikitable"
|-
| Conditional Execution
| <code>boolExpr1 ifTrue:[ ... ] ifFalse:[ ... ]</code>
|variations without true-part, without false part and with the order reversed are available.
|-
| While-Loop (test at top)
| <code>[ boolExpr1 ] whileTrue:[ ... ]</code>
|notice the receiver being a block. A <code>whileFalse:</code> variant is also available.
|-
| Do-Loop (test at bottom)
| <code>[ ... ] doWhile:[ boolExpr1 ]</code>
|notice the test being a block. A <code>doUntil:</code> variant is also available.
|-
| For-Loop
| <code>start to:stop do:[:iterVar | ... ]</code>
|evaluates the block (lambda) for each value in start..stop.
|-
| Enumerating Collections
| <code>collection do:[:elementVar | ... ]</code>
|evaluates the block (i.e. lambda) for each element in the collection.
|-
| Evaluating a Lambda Block   without arguments:
  with arguments:
| <code>aBlock value</code><code>aBlock value:expr1 ... value:exprN</code>
|the number of arguments must match the number expected by the lambda (although varArg lambdas are also available)
|-
| Exception Handling
| <code>[ ... ] on:Error do:[:ex | ... ]</code>
|evaluates the first block; if an error is encountered, evaluate the handler
|}

==== Special 'Control Structures' ====

{| class="wikitable"
|-
| Starting another Thread
| <code>p := [ ... ] fork</code>
|the code inside the block will execute in a separate thread
|-
| Creating, configuring and starting another Thread
| <code>p := [ ... ]   newProcess;   name:'my worker';   priority:5;   resume</code>
|the code inside the block will execute in a separate thread
|-
| Terminating a Thread
| <code>p terminate</code>
|with p referring to the thread as created by newProcess or fork
|-
| Interrupting a Thread
| <code>p interruptWith:[ ... ]</code>
|interrupt the thread and let it execute the given code (in its interrupt seervice)
|-
| Exception Handling
| <code>[ ... ]   on:Error do:[:ex |     ...   ]</code>
|the handler will get an exception argument (ex), which contains additional information, and can be told how to deal with the error
|-
| Exception Handling - proceeding
| <code>[ ... ]   on:Error do:[:ex |     ...     ex proceed   ]</code>
|proceed, as if the error did not happen
|-
| Exception Handling - restarting
| <code>[ ... ]   on:Error do:[:ex |     ...     ex restart   ]</code>
|restart the code from the beginning (usually after the handler did some cleanup, such as lazy loading a missing file...)
|-
| Exception Handling - printing
| <code>[ ... ]   on:Error do:[:ex |     ...     ex description     ...   ]</code>
|contains a human readable description of the error
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ensure:[   ...   ]</code>
|the ensure block will be evaluated in any case
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ifCurtailed:[   ...   ]</code>
|the ifCurtailed block will be evaluated only on a non-regular exit (i.e. when an exception was raised, or the operation was aborted or the thread terminated)
|-
| Early exit from Loops
| <code>[:exit |   ...   code with loop   ...   exit value   ... ] valueWithExit</code>
|the block will be left, when exit is evaluated. Often used as argument of ifTrue:, as in cond ifTrue: exit
|-
| Queries
| <code>Query   answer:something   do:[     ...     Query query     ...   ]</code>
|to provide answers way down to whoever is interested. Queries answer nil if no one is there to answer. Queries are usually more specifically used as subclasses of Query
|-
| Notifications
| <code>Notification   handle:[     ...   ]   do:[     ...     Notification notify:someArg     ...   ]</code>
|to provide information way up to whoever is interested Notifications are usually more specifically used as subclasses of Notification
|-
| Observers 1
| <code>foo onChange:#bla evaluate:[...]. ... foo changed:#bla</code>
|observer with generic block to evaluate
|-
| Observers 2
| <code>foo onChangeSend:#xyz to:someone. ... foo changed</code>
|observer with message send
|-
| Observers 3
| <code>foo addDependent:someone. ... foo changed</code>
|observer with send to update method of target
|}

Queries and Notifications can be seen as observers within the calling hierarchy (i.e. information flows up or down the calling hierarchy), whereas the dependency and anChange mechanisms are independent of the control flow (even between different threads)

==== Synchronization and Timers ====
{| class="wikitable"
|-
| Timed Delay
| <code>Delay waitForSeconds:n</code> <code>Delay waitUntil:(Timestamp now + 10 seconds)</code>
|self explaining
|-
| Sempaphore wait
| <code>s := Semaphore new. ... s wait. ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Sempaphore wait with timeout
| <code>s := Semaphore new. ... s waitWithTimeout:(5 seconds). ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Multi Sempaphore wait
| <code>s1 := Semaphore new. s2 := Semaphore new. ... which := (s1 , s2) wait. ... s2 signal</code>
|wait for any of multiple semaphores
|-
| Synchronized Collections
| <code>a := OrderedCollection new asSharedCollection</code>
|will wrap the collection so that add/remove operations are atomic
|}

==== Wellknown Globals ====

{| class="wikitable"
|-
| Logging and Messaging
| <code>Transcript</code> - the console window <code>Stdout</code> - standard output <code>Stderr</code> - standard error <code>Stdin</code> - standard input <code>Logger</code> - redefinable logger (defaults to standard error)
|-
| Common Useful Dialogs
| <code>Dialog</code> - provides many useful utility functions for standard dialogs eg.<code> Dialog warn:'message' Dialog confirm:'question' Dialog request:'question' Dialog requestFilename:'question' ...</code>
|}

==== Most Wellknown Classes ====

{| class="wikitable"
|-
| Numbers
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Number Number]</code>(abstract superclass) <code>[http://live.exept.de/ClassDoc/classDocOf:,Integer Integer]</code>(integral numbers) <code>[http://live.exept.de/ClassDoc/classDocOf:,Float Float]</code>(inexact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Fraction Fraction]</code>(exact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Complex Complex]</code>
|-
| Collections
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Array Array]</code> (fixed size array) <code>[http://live.exept.de/ClassDoc/classDocOf:,OrderedCollection OrderedCollection]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,List List]</code> (variable size) <code>[http://live.exept.de/ClassDoc/classDocOf:,SortedCollection SortedCollection]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Set Set]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Bag Bag]</code> (unordered) <code>[http://live.exept.de/ClassDoc/classDocOf:,Dictionary Dictionary]</code> (mapped collections) <code>[http://live.exept.de/ClassDoc/classDocOf:,BinaryTree BinaryTree]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,AVLTree AVLTree]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,SharedQueue SharedQueue]</code> (shared, synchronized) many more...
|-
| Process Handling
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Process Process]</code> (lightweight thread) <code>[http://live.exept.de/ClassDoc/classDocOf:,OSProcess OSProcess]</code> (heavyweight OS process) <code>[http://live.exept.de/ClassDoc/classDocOf:,Semaphore Semaphore]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,RecursionLock RecursionLock]</code> (synchronization) <code>[http://live.exept.de/ClassDoc/classDocOf:,Monitor Monitor]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,BoltLock BoltLock]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Delay Delay]</code> (time delays)
|-
| Files & Streams
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Filename Filename]</code> (file naming, directory access, mime type) <code>[http://live.exept.de/ClassDoc/classDocOf:,Stream Stream]</code> (basic stream framework)
 <code>[http://live.exept.de/ClassDoc/classDocOf:,ReadStream ReadStream]</code>,<code>WriteStream</code>,<code>[http://live.exept.de/ClassDoc/classDocOf:,EncodedStream EncodedStream]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,ExternalStream ExternalStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,FileStream FileStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Socket Socket]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,PipeStream PipeStream]</code> (OS-cmd streams)
|-
| Low Level Access
| <code>[http://live.exept.de/ClassDoc/classDocOf:,OperatingSystem OperatingSystem]</code> (OS API calls) <code>[http://live.exept.de/ClassDoc/classDocOf:,Smalltalk Smalltalk]</code>(startup, shutdown and globals) <code>[http://live.exept.de/ClassDoc/classDocOf:,ObjectMemory ObjectMemory]</code>(VM access)
|}

== Examples ==

exampleMethod1
|v1 v2|

v1 := 42.
v2 := v1 sqrt.
Transcript showCR: 'the root of the answer to all questions is: %1' with: v2.

using expanded strings, this can be written as:

exampleMethod1_alternative
|v1|

v1 := 42.
Transcript showCR: e'the root of the answer to all questions is: {v1 sqrt}'.

enumerating elements of an array:

exampleMethod2
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr do:[:el |
Transcript showCR: el
]

enumerating elements of an array with additional index:

exampleMethod3
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr doWithIndex:[:el :idx |
Transcript showCR: e'array element at {idx} is {el} and its class is {el class name}\n'
]

dialogs, string-to-number conversion, error handling:

exampleMethod4
|s1 nr1 s2 nr2 rslt|

s1 := Dialog request:'Enter the first number' initialAnswer:1.
s1 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method
s2 := Dialog request:'Enter the second number' initialAnswer:2.
s2 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr1 := Number readFrom:s1 onError:[^ self].
nr2 := Number readFrom:s2 onError:[^ self].

"/ save division
[
rslt := nr1 / nr2
] on: Error do:[:ex |
(Dialog confirm: e'Error encountered: {ex description}\nProceed with zero?')
ifFalse:[^ self]. "/ no; return from method
ex proceedWith:0
].

Dialog information: e'the result is {rslt}'

dialogs, error handling and complex square root:

exampleMethod4
|s nr rslt|

s := Dialog request:'Enter a number (may be negative)' initialAnswer:2.
s isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr := Number readFrom:s onError:[^ self].

"/ square root; catch imaginary result
[
rslt := nr sqrt
] on: ImaginaryResultError do:[:ex |
(Dialog confirm: e'No solution in R; want to see the complex result?')
ifFalse:[^ self]. "/ no; return from method
rslt := Number trapImaginary:[ nr sqrt ].
"/ rslt is now a complex number
].

Dialog information: e'the result is {rslt}'

== Standard ==
The ANSI Smalltalk standard was approved on May 19, 1998. The official name of the document is ANSI INCITS 319-1998 (R2002). You can order a copy of the final standard
from here: [http://www.techstreet.com/cgi-bin/detail?product_id=56122]
or here [http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI+INCITS+319%2D1998+%28R2002%29]. The name of the document is "American National Standard for Information Systems - Programming Languages - Smalltalk".

You can also download the final draft revision for free: standard_v1_9-indexed.pdf and at [https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf].

The final draft is identical to the official standard except that the draft also has a rationale included (and thus, the draft is arguably more useful than the official standard).

Protocol from ANSI Meeting: [http://www.netjam.org/smalltalk/faq/ANSI-meeting.html]

== Common Language Extensions ==
These are also found in other Smalltalk dialects (eg. [[Glossary#VW|VW]] or [[Glossary#Squeak|Squeak]])

* { expr1 . expr2 . ... } Brace Array Construction Each expression is evaluated (left to right), and an Array with the results is created at execution time. Notice that separating full stops are required, as opposed to constant literal arrays, where elements are separated by spaces. The generated Array is mutable (can be modified), whereas a constant array is not.

== Smalltalk/X Language Extensions ==

These are ST/X specific, and not (as of 2026) implemented in other Smalltalk systems.

=== String Literals ===
* c'...' ''c-strings'' C-like escapes (\n, \t, \xNN, \uNNNN) inside the string are expanded.

* e' ... {expr} ...' ''e-strings'' (expanded epression strings) In addition to C-escapes, embedded expressions are evaluated and their printString is sliced in. Technically, it is converted to ' ... %1 ...' and then expanded using standard String methods.

* i' ... {expr} ...' ''i-strings'' (international strings) similar to e-strings, but the converted string ('... %1 ...') is translated to a national string (via the *.rs file) and then expanded. Allows for different word ordering.

=== Integer Literals ===
* 0xNNNN, 0oNNNN, 0bNNNN C-style hex, octal and binary integers. With arbitrary precision

=== Float Literals ===
* <f>q, <f>Q, etc. Float literal type suffix (q, Q, QD, QL, QO) For a complete list and spec., see the Number documentation.

=== Compact Number Arrays ===
* #u1, #u8, #u16, #u32, #u64 #i8, #i16, #i32, #i64 #f16, #bf16, #f32, #f64 Will generate dense packed vectors (similar to byteArray); format is #X(n1 n2 ... )

Smalltalk Syntax Cheat Sheet

2026-06-07T05:44:19Z

Cg: /* Standard */

A short, one page summary of what beginners need to know about Smalltalk/X, its syntax and most useful code fragments. As usual, this is only a tiny fraction of what is really awailable, and you should use the builtin class browser to find many more useful functions in the system.

This page was extracted from the "Smalltalk/X Programmers guide - Smalltalk/X Cheat Sheet".
 Smalltalk/X language extensions (w.r.t. other Smalltalk implementations) are marked with '''(*)'''.

== Smalltalk Philosophy ==

* The world consists of objects which '''communicate by sending messages'''.
: A message looks like an english sentence, and might look like "<code>heyYou doSomething</code>".
: In this example, the "heyYou" is called the "''receiver of the message''"
: You may pass additional parameter objects (arguments) as in: "<code>heyYou doSomethingWith: arg</code>"
: or multiple arguments as in <code>"heyYou doSomethingWith: arg1 and: arg2"</code>
: In these examples, the "<code>heyYou</code>" is called the "''receiver of the message''"
* Messages without argument are called "''unary messages''"; those with arguments are called "''keyword messages''"
: For example "<code>Transcript clear</code>" (sends the message "clear" to the Transcript object),
: and "<code>Transcript show: 'hello'</code>" (sends the message "show:" to the Transcript, passing a string argument),
* To allow for arithmetic operations, any non-letter character (except for a few) are treated like a message name and written between the receiver and the one and only argument. These are called "''binary messages''".
: For example: <code>"3 + 4"</code> or <code>"abc , def"</code> (yes, the comma is an operator; it does string concatenation)
* The object my respond (or "answer") by returning some result object. In the above example, "<code>3+4</code>" would answer "7", and "<code>'hello' , 'world'</code>" would answer 'helloworld'
* binary messages have no meaning to the compiler; they are all equal and simply evaluated from left to right.
: admitted, this makes arithmetic a little strange initially; you'll need parentheses as the is not precidence of eg. * over +. The expression "3 + 4 * 5" will be evaluated left to right and answer 35.
* Everything in this world is an object;
: from low level things like booleans, true, false, integer numbers, floating point numbers characters etc.
: there are containers, which can hold on other objects. Technically, all such references are via pointers.
: there are also very complex objects and structures which implement windows, the user interface, communication interfaces, debuggers and even compilers which allow for code to be defined and installed on the fly.
* Every object is associated to a class. Classes define the behavior of their instances. I.e. they define how they respond to messages. The response is implemented by a so called ''method''. That is a piece of code which is executed when a message comes in. A method consist of a number of statements (which are message sends), each separated by a full stop (as in english).
* Classes are themself objects, which respond to messages. Typically class messages would answer new instances, constants or utility functionality. There are also class messages to create new classes.
* Class can inherit common functionality (i.e. method implementations) from a superclass. Thus creating a hierarchy of classes. Typical hierarchies are the Number hierarchy, Collections, Streams and UI Widgets.
* In Smalltalk, every behavior is defined by corresponding message implementations. This includes control features (i.e. if-then-else, loops and exception handling). All of them are implemented as messages being sent to booleans (ifTrue:/ifFalse:) or blocks (whileTrue:)
* Blocks are special objects, which wrap a piece of code. Other languages know them as anonymous functions or lambdas or closures. But the Smalltalk syntax makes them super easy to use: just write a number of expressions inside square brackets, as in "<code>[ Transcript show: 10 factorial ]</code>".
: blocks can be passed as argument with a message send; for example to a boolean: "<code>aBoolean ifTrue: [ Transcript show: 'yes' ]</code>"
: blocks can be stored in variables and passed arounf just like any other object
: blocks can receive messages, especially loop messages: "<code>[ a < 10] whileTrue:[ Transcript showCR: a. a := a + 1 ]</code>".

== Syntax ==

==== Comments ====

{| class="wikitable"
|-
| Regular comment
| <code>" this is a comment "</code>
| ''any text between double quotes''
|-
| EOL-Comment (*)
| <code>"/ this is an End-of-Line comment</code>
| ''text from quote-slash to line end''
|-
| Token-Comment (*)
| <code>"<<END a multiline token-comment up to a line starting with 'END' more commented stuff here ... comment ends here END</code>
| ''text up to line beginning with whatever token came after the initial "<<" ''
|}

==== Literal Constants ====

===== Numbers =====

{| class="wikitable"
|-
| Integers</td>
| <code>12345</code> </code>-12345<code>
|
|-
| Large integers
| <code>1234567890123456789012345</code>…
| ''arbitrary number of digits''
|-
| Integers with radix (Smalltalk style)
| <code>16rAFFE</code>, <code>2r010101</code>, <code>8r0777</code>, <code>3r012012</code>, <code>16r-AFFE</code>, <code>2r-010101</code>
| ''prepend the radix (base) any radix from 2..36 is possible (i.e. 3r222 is a ternary number)''
|-
| Integers with radix (C style) (*)
| <code>0xFEED</code> <code>-0xBEAF</code> <code>0b11011</code>,<code>-0b1100</code>
| ''C/Java/JavaScript style: prepend radix indicator ('x', 'b', 'o') One of hex, binary and octal''
|-
| Floats (IEEE double; roughly 17 digits)
| 12.456 1.234e17 -6.9 -6e-10 Float pi Float e
| ''called "Float", but actually hold double precision'' Common constants can be referred to "by name".
|-
| Short floats (IEEE single; roughly 8 digits) (*)
| <code>1.234f17</code> <code>-6f-10</code>
| this is controlled by a ParserFlag (singlePrecisionFloatF), which is currently defaulted to false. Thus, by default, double precision floats are created with the 'f' exponent character.
|-
| Long floats (IEEE quad; roughly 20 digits) (*)
| <code>1.234q17</code> <code>-6q-10</code>
| ''actual precision depends on the underlying CPU (on x86/x86_64: only 80bit)
|-
| Quad floats; roughly 34 digits (*)
| <code>1.234Q17</code> <code>-6Q-10</code>
| ''computed in software; therefore slower; this is not yet officially released.
|-
| Large floats; roughly 60 digits (*)
| <code>1.234QL17</code> <code>-6QL-10</code>
| ''computed in software; therefore slower; this is not yet officially released.
|-
| Fractions
| <code>(1/3)</code> <code>(17/2)</code>
|
|-
| ScaledDecimals
| <code>1234.53s2</code>
| the number after the s specifies the number of digits
|}

===== Characters and Strings =====

{| class="wikitable"
|-
| Characters
| <code>$a</code> <code>Character space</code> <code>Character nl</code> Also: "<code>null</code>", "<code>tab</code>", "<code>return</code>", "<code>bell</code>"... Or: <code>Character codePoint:n</code>
| ''traditionally, Smalltalk does not support any escape sequence'' Common constants can be referred to "by name".
|-
| Strings
| <code>'hello'</code>
| ''traditionally, Smalltalk does not support any escape sequence inside'' (I.e. they are what Python calls ''Raw Strings'') But see below...
|-
| Strings (C Style) (*)
| <code>c'hello\nworld'</code>
| ''supports the common escape sequences, such as "\n", "\t", "\xHH" ''
|-
| Strings (With Embedded Expressios) (*)
| <code>e'hello {OperatingSystem getLoginName}'</code>
| ''expressions in braces are evaluated at runtime and sliced into the string (also a C-string)''
|-
| Strings (Language translated with Embedded Expressios) (*)
| <code>i'hello {OperatingSystem getLoginName}'</code>
| ''like above, but the string is also possibly translated to a national language''
|-
| Symbols
| <code>#'hello'</code> <code>#foo</code>
| without quotes, if only alphaNumeric characters
|}

===== Arrays and Objects =====
{| class="wikitable"
|-
| Arrays 
| <code>#( el1 el2 ... elN )</code>
| each element is a literal constant
|-
| Byte Arrays
| <code>#[ b1 b2 ... bN ]</code>
| each byte-element an integer constant in 0..255
|-
| Special Number Arrays (*)
| <code>#XX( v1 v2 ... vN )</code>
| XX: is one of  'u8', 's8', 'u16', 's16', 'u32', 's32', 'u64', 's64', 'f32', 'f64'  and each element being an integer or float constant
|-
| Immediate Inline Objects (*)
| <code>#{ foo: fooValue . bar: barValue }</code>
| fooValue and barValue: are constants
|}

==== Lambda Blocks (Closures) ====

{| class="wikitable"
|-
| Without argument
| <code>[ expr1 . expr2 ... exprN ]</code>
| multiple expressions sep'd by period. When evaluated, the value is the value from the last expression, exprN
|-
| One argument
| <code>[ :arg |     expr1 . expr2 ... exprN ]</code>
|-
| Multiple arguments
| <code>[ :a1 :a2 ... :aN |     expr1 . expr2 ... exprN ]</code>
|-
| Local Variables inside a block
| <code>[ :a1 ... :aN |      |local1 local2 |      expr1 ... exprN ]</code>
|}

==== Expressions ====

{| class="wikitable"
|-
| Unary Expression (without argument)
| <code>receiver messageName</code>
|receiver is itself either a constant, a lambda-block, a unary expression or a parenthesized expression
|-
| Keyword Expression (1 arg)
| <code>receiver messageNamePart:argExpression</code>
|whitespace between the colon and the argExpression is optional.
|-
| Keyword Expression (any number of args)
| <code>receiver     messageNamePart1:argExpression1     messageNamePart2:argExpression2     ...     messageNamePartN:argExpressionN</code>
|-
| Binary Expression
| <code>receiver binOP arg</code>
|with binOP being any combination of special characters: * , + , - , % , & , / , \ , | , = , < , > , ? and ,
 I.e. "<code>foo ==> 123</code>" is the binary message "<code>==></code>" sent to <code>foo</code> with <code>123</code> as argument.
 And "<code>foo ? 123</code>" is the binary message "<code>?</code>" sent to <code>foo</code> with <code>123</code> as argument.
|-
| Cascade Expression (multiple messages to the same receiver)
| <code>receiver     message1 ;     message2 ;     ...     messageN</code></td>
|the receiver expression is evaluated, then multiple messages (separated by ";") are sent to this receiver.
|-
| Parentheses for grouping
| <code>( any expression )</code>
|-
| Assignment
| <code>variable := expression</code>
|can be used as expression.
|-
| Computed Array (Brace Construct) (*)
| <code>{ expr1 . expr2 . ... . exprN }</code>
|instantiates a new Array object with elements from the expressions.
|-
| Computed Inline Object (*)
| <code>{ foo: fooExpr . bar: barExpr }</code>
|fooExpr and barExpr: expressions
|-
| Inline string expressions (*)
| <code>e'p1{e1}p2{e2}...pN{eN}pM'</code>
|syntactic sugar for: <code>('p1%1p2%2...pN%NpM' bindWith:e1 with:e2 ... with:eN)</code> where each pI is a string with possible C-escapes and each eI is a Smalltalk expression
|-
| Array Indexing (*)
| <code>coll[idx]</code> <code>coll[idx1][idx2]</code> <code>coll[idx1][idx2][idx3]</code>
|syntactic sugar for: <code>(coll at:idx)</code> where coll must be an indexable collection, and idx of compatible index type. I.e. integer for array-like collections, hash-key for dictionaries, etc. Up to 4 dimensions are (currently supported)
|-
| Collection instantiation (*)
| <code>someClass[sz]</code> <code>someClass[sz][sz]</code> ...
|syntactic sugar for: <code>(someClass new:sz)</code> where someClass must be a collection class I.e. Array[10] creates an empty array with 10 slots. 1, 2, 3 and 4 dimensions are supported
|-

|}

==== Remaining Syntax ====

{| class="wikitable"
|-
| Local variables (in block or method)
| <code>| var1 var2 ... varN |</code>
|variable declarations must be at the beginning, before any expression.
|-
| Separating multiple expressions (sequence)
| <code>expr1 . expr2 . ... exprN</code>
|expressions (statements) are separated by fullstop (period) characters. The last expression may or may not be followed by a fullstop; if there is one, this is treated like a followup empty statement.
|-
| Return from method
| <code>^ expression</code>
|returns from the enclosing method (also if inside a block-closure)
|}

==== Wellknown (Common) Messages ====

{| class="wikitable"
|-
| Conditional Execution
| <code>boolExpr1 ifTrue:[ ... ] ifFalse:[ ... ]</code>
|variations without true-part, without false part and with the order reversed are available.
|-
| While-Loop (test at top)
| <code>[ boolExpr1 ] whileTrue:[ ... ]</code>
|notice the receiver being a block. A <code>whileFalse:</code> variant is also available.
|-
| Do-Loop (test at bottom)
| <code>[ ... ] doWhile:[ boolExpr1 ]</code>
|notice the test being a block. A <code>doUntil:</code> variant is also available.
|-
| For-Loop
| <code>start to:stop do:[:iterVar | ... ]</code>
|evaluates the block (lambda) for each value in start..stop.
|-
| Enumerating Collections
| <code>collection do:[:elementVar | ... ]</code>
|evaluates the block (i.e. lambda) for each element in the collection.
|-
| Evaluating a Lambda Block   without arguments:
  with arguments:
| <code>aBlock value</code><code>aBlock value:expr1 ... value:exprN</code>
|the number of arguments must match the number expected by the lambda (although varArg lambdas are also available)
|-
| Exception Handling
| <code>[ ... ] on:Error do:[:ex | ... ]</code>
|evaluates the first block; if an error is encountered, evaluate the handler
|}

==== Special 'Control Structures' ====

{| class="wikitable"
|-
| Starting another Thread
| <code>p := [ ... ] fork</code>
|the code inside the block will execute in a separate thread
|-
| Creating, configuring and starting another Thread
| <code>p := [ ... ]   newProcess;   name:'my worker';   priority:5;   resume</code>
|the code inside the block will execute in a separate thread
|-
| Terminating a Thread
| <code>p terminate</code>
|with p referring to the thread as created by newProcess or fork
|-
| Interrupting a Thread
| <code>p interruptWith:[ ... ]</code>
|interrupt the thread and let it execute the given code (in its interrupt seervice)
|-
| Exception Handling
| <code>[ ... ]   on:Error do:[:ex |     ...   ]</code>
|the handler will get an exception argument (ex), which contains additional information, and can be told how to deal with the error
|-
| Exception Handling - proceeding
| <code>[ ... ]   on:Error do:[:ex |     ...     ex proceed   ]</code>
|proceed, as if the error did not happen
|-
| Exception Handling - restarting
| <code>[ ... ]   on:Error do:[:ex |     ...     ex restart   ]</code>
|restart the code from the beginning (usually after the handler did some cleanup, such as lazy loading a missing file...)
|-
| Exception Handling - printing
| <code>[ ... ]   on:Error do:[:ex |     ...     ex description     ...   ]</code>
|contains a human readable description of the error
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ensure:[   ...   ]</code>
|the ensure block will be evaluated in any case
|-
| Ensure/Unwind Protect
| <code>[ ... ]   ifCurtailed:[   ...   ]</code>
|the ifCurtailed block will be evaluated only on a non-regular exit (i.e. when an exception was raised, or the operation was aborted or the thread terminated)
|-
| Early exit from Loops
| <code>[:exit |   ...   code with loop   ...   exit value   ... ] valueWithExit</code>
|the block will be left, when exit is evaluated. Often used as argument of ifTrue:, as in cond ifTrue: exit
|-
| Queries
| <code>Query   answer:something   do:[     ...     Query query     ...   ]</code>
|to provide answers way down to whoever is interested. Queries answer nil if no one is there to answer. Queries are usually more specifically used as subclasses of Query
|-
| Notifications
| <code>Notification   handle:[     ...   ]   do:[     ...     Notification notify:someArg     ...   ]</code>
|to provide information way up to whoever is interested Notifications are usually more specifically used as subclasses of Notification
|-
| Observers 1
| <code>foo onChange:#bla evaluate:[...]. ... foo changed:#bla</code>
|observer with generic block to evaluate
|-
| Observers 2
| <code>foo onChangeSend:#xyz to:someone. ... foo changed</code>
|observer with message send
|-
| Observers 3
| <code>foo addDependent:someone. ... foo changed</code>
|observer with send to update method of target
|}

Queries and Notifications can be seen as observers within the calling hierarchy (i.e. information flows up or down the calling hierarchy), whereas the dependency and anChange mechanisms are independent of the control flow (even between different threads)

==== Synchronization and Timers ====
{| class="wikitable"
|-
| Timed Delay
| <code>Delay waitForSeconds:n</code> <code>Delay waitUntil:(Timestamp now + 10 seconds)</code>
|self explaining
|-
| Sempaphore wait
| <code>s := Semaphore new. ... s wait. ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Sempaphore wait with timeout
| <code>s := Semaphore new. ... s waitWithTimeout:(5 seconds). ... s signal</code>
|obviously, the signalling must be evaluated by another thread
|-
| Multi Sempaphore wait
| <code>s1 := Semaphore new. s2 := Semaphore new. ... which := (s1 , s2) wait. ... s2 signal</code>
|wait for any of multiple semaphores
|-
| Synchronized Collections
| <code>a := OrderedCollection new asSharedCollection</code>
|will wrap the collection so that add/remove operations are atomic
|}

==== Wellknown Globals ====

{| class="wikitable"
|-
| Logging and Messaging
| <code>Transcript</code> - the console window <code>Stdout</code> - standard output <code>Stderr</code> - standard error <code>Stdin</code> - standard input <code>Logger</code> - redefinable logger (defaults to standard error)
|-
| Common Useful Dialogs
| <code>Dialog</code> - provides many useful utility functions for standard dialogs eg.<code> Dialog warn:'message' Dialog confirm:'question' Dialog request:'question' Dialog requestFilename:'question' ...</code>
|}

==== Most Wellknown Classes ====

{| class="wikitable"
|-
| Numbers
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Number Number]</code>(abstract superclass) <code>[http://live.exept.de/ClassDoc/classDocOf:,Integer Integer]</code>(integral numbers) <code>[http://live.exept.de/ClassDoc/classDocOf:,Float Float]</code>(inexact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Fraction Fraction]</code>(exact) <code>[http://live.exept.de/ClassDoc/classDocOf:,Complex Complex]</code>
|-
| Collections
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Array Array]</code> (fixed size array) <code>[http://live.exept.de/ClassDoc/classDocOf:,OrderedCollection OrderedCollection]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,List List]</code> (variable size) <code>[http://live.exept.de/ClassDoc/classDocOf:,SortedCollection SortedCollection]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Set Set]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Bag Bag]</code> (unordered) <code>[http://live.exept.de/ClassDoc/classDocOf:,Dictionary Dictionary]</code> (mapped collections) <code>[http://live.exept.de/ClassDoc/classDocOf:,BinaryTree BinaryTree]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,AVLTree AVLTree]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,SharedQueue SharedQueue]</code> (shared, synchronized) many more...
|-
| Process Handling
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Process Process]</code> (lightweight thread) <code>[http://live.exept.de/ClassDoc/classDocOf:,OSProcess OSProcess]</code> (heavyweight OS process) <code>[http://live.exept.de/ClassDoc/classDocOf:,Semaphore Semaphore]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,RecursionLock RecursionLock]</code> (synchronization) <code>[http://live.exept.de/ClassDoc/classDocOf:,Monitor Monitor]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,BoltLock BoltLock]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,Delay Delay]</code> (time delays)
|-
| Files & Streams
| <code>[http://live.exept.de/ClassDoc/classDocOf:,Filename Filename]</code> (file naming, directory access, mime type) <code>[http://live.exept.de/ClassDoc/classDocOf:,Stream Stream]</code> (basic stream framework)
 <code>[http://live.exept.de/ClassDoc/classDocOf:,ReadStream ReadStream]</code>,<code>WriteStream</code>,<code>[http://live.exept.de/ClassDoc/classDocOf:,EncodedStream EncodedStream]</code> <code>[http://live.exept.de/ClassDoc/classDocOf:,ExternalStream ExternalStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,FileStream FileStream]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,Socket Socket]</code>, <code>[http://live.exept.de/ClassDoc/classDocOf:,PipeStream PipeStream]</code> (OS-cmd streams)
|-
| Low Level Access
| <code>[http://live.exept.de/ClassDoc/classDocOf:,OperatingSystem OperatingSystem]</code> (OS API calls) <code>[http://live.exept.de/ClassDoc/classDocOf:,Smalltalk Smalltalk]</code>(startup, shutdown and globals) <code>[http://live.exept.de/ClassDoc/classDocOf:,ObjectMemory ObjectMemory]</code>(VM access)
|}

== Examples ==

exampleMethod1
|v1 v2|

v1 := 42.
v2 := v1 sqrt.
Transcript showCR: 'the root of the answer to all questions is: %1' with: v2.

using expanded strings, this can be written as:

exampleMethod1_alternative
|v1|

v1 := 42.
Transcript showCR: e'the root of the answer to all questions is: {v1 sqrt}'.

enumerating elements of an array:

exampleMethod2
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr do:[:el |
Transcript showCR: el
]

enumerating elements of an array with additional index:

exampleMethod3
|arr|

arr := #( 1 2.0 'three' (4 4 4 4) ).
arr doWithIndex:[:el :idx |
Transcript showCR: e'array element at {idx} is {el} and its class is {el class name}\n'
]

dialogs, string-to-number conversion, error handling:

exampleMethod4
|s1 nr1 s2 nr2 rslt|

s1 := Dialog request:'Enter the first number' initialAnswer:1.
s1 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method
s2 := Dialog request:'Enter the second number' initialAnswer:2.
s2 isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr1 := Number readFrom:s1 onError:[^ self].
nr2 := Number readFrom:s2 onError:[^ self].

"/ save division
[
rslt := nr1 / nr2
] on: Error do:[:ex |
(Dialog confirm: e'Error encountered: {ex description}\nProceed with zero?')
ifFalse:[^ self]. "/ no; return from method
ex proceedWith:0
].

Dialog information: e'the result is {rslt}'

dialogs, error handling and complex square root:

exampleMethod4
|s nr rslt|

s := Dialog request:'Enter a number (may be negative)' initialAnswer:2.
s isNil ifTrue:[ ^ self ]. "/ cancelled - return from method

"/ convert; on error return from method
nr := Number readFrom:s onError:[^ self].

"/ square root; catch imaginary result
[
rslt := nr sqrt
] on: ImaginaryResultError do:[:ex |
(Dialog confirm: e'No solution in R; want to see the complex result?')
ifFalse:[^ self]. "/ no; return from method
rslt := Number trapImaginary:[ nr sqrt ].
"/ rslt is now a complex number
].

Dialog information: e'the result is {rslt}'

== Standard ==
The ANSI Smalltalk standard was approved on May 19, 1998. The official name of the document is ANSI INCITS 319-1998 (R2002). You can order a copy of the final standard
from here: [http://www.techstreet.com/cgi-bin/detail?product_id=56122]
or here [http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI+INCITS+319%2D1998+%28R2002%29]. The name of the document is "American National Standard for Information Systems - Programming Languages - Smalltalk".

You can also download the final draft revision for free: standard_v1_9-indexed.pdf and at [https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf].

The final draft is identical to the official standard except that the draft also has a rationale included (and thus, the draft is arguably more useful than the official standard).

Protocol from ANSI Meeting: [http://www.netjam.org/smalltalk/faq/ANSI-meeting.html]

== Common Language Extensions ==
These are also found in other Smalltalk dialects (eg. [[Glossary#VW|VW]] or [[Glossary#Squeak|Squeak]])

* { expr1 . expr2 . ... } Brace Array Construction Each expression is evaluated (left to right), and an Array with the results is created at execution time. Notice that separating full stops are required, as opposed to constant literal arrays, where elements are separated by spaces. The generated Array is mutable (can be modified), whereas a constant array is not.

== Smalltalk/X Language Extensions ==

These are ST/X specific, and not (as of 2026) implemented in other Smalltalk systems.

=== String Literals ===
* c'...' ''c-strings'' C-like escapes (\n, \t, \xNN, \uNNNN) inside the string are expanded.

* e' ... {expr} ...' ''e-strings'' (expanded epression strings) In addition to C-escapes, embedded expressions are evaluated and their printString is sliced in. Technically, it is converted to ' ... %1 ...' and then expanded using standard String methods.

* i' ... {expr} ...' ''i-strings'' (international strings) similar to e-strings, but the converted string ('... %1 ...') is translated to a national string (via the *.rs file) and then expanded. Allows for different word ordering.

=== Integer Literals ===
* 0xNNNN, 0oNNNN, 0bNNNN C-style hex, octal and binary integers. With arbitrary precision

=== Float Literals ===
* Nq, NQ, etc. Float literal type suffix (q, Q, QD, QL, QO)- For a complete list and spec., see the Number documentation.

=== Compact Number Arrays ===
* #u1, #u8, #u16, #u32, #u64 #i8, #i16, #i32, #i64 #f16, #bf16, #f32, #f64 Will generate dense packed vectors (similar to byteArray); format is #X(n1 n2 ... )

Common Keyboard Shortcuts/en

2026-06-06T10:31:47Z

Cg: /* Customizing Keyboard Shortcuts */

In general, keyboard shortcuts perform functions which are also available on popup menus of the individual UI components, and these popup menu are usually context/selection menus. This means, that they typically offer operations on the current selected element within that view. In contrast to eg. Mac OSX, the keyboard shortcuts are context sensitive, and depend on the current focus window. This means that the same shortcut may perform different operations depending on which component has the keyboard focus.

All editing functions can be undone via the "''Undo''" (<kbd>Ctrl-z</kbd>) menu function, in case you pressed the wrong key or inside another component.

Notice that the <kbd>Alt</kbd> key is labelled <kbd>Cmd</kbd> on some keyboards (and also inside the <code>"keyboard.rc"</code> file and the settings dialog.

=== Navigating ===

Cursor keys navigate character-wise or word-wise (if <kbd>CTRL</kbd> is pressed)

* '''<kbd>Ctrl-CursorRight</kbd>''' - "''Next Word''" Moves the cursor to the next word.

* '''<kbd>Ctrl-CursorLeft</kbd>''' - "''Previous Word''" Moves the cursor to the previous word.

=== Selecting ===

* '''<kbd>Alt-w</kbd>''' - "''Select Next Word''".

* '''<kbd>Shift-CursorKey</kbd>''' - "''Expand the Selection''".

=== General Editing ===

These shortcuts usually work in any view (i.e. project tree view, diagram- and text editors).
Specific operations are found below.

* '''<kbd>Ctrl-c</kbd>''' - "''Copy''". Copies the selection into the clipboard. The object to be copied depends on the context and selection: - in a text editor, the text-selection is copied. - in the diagram editor, the selected element(s) are copied - in the navigation tree, the selected tree items are copied.

* '''<kbd>Ctrl-v</kbd>''' - "''Paste''" Pastes the clipboard object. This is not always possible, and sometimes simply ignored (for example, if a tree-item is copied and tried to be pasted into a text editor).

* '''<kbd>Ctrl-x</kbd>''' - "''Cut''" Deletes the selection and puts it into the clipboard (for later pasting)

* '''<kbd>Del</kbd>''' - "''Delete''" Deletes but does NOT put the deleted object into the clipboard. In a text editor, the selected text is deleted, or if nothing is selected, the next character (after the cursor) is deleted. With <kbd>CTRL</KBD>, the next word is deleted.

* '''<kbd>Backspace</kbd>''' - "''Delete''" Deletes but does NOT put the deleted object into the clipboard. In a text editor, the selected text is deleted, or if nothing is selected, the previous character (before the cursor) is deleted. With <kbd>CTRL</KBD>, the previous word is deleted.

* '''<kbd>Ctrl-z</kbd>''' - "''Undo''" Undoes the last operation. This is a multi-undo. This is the same function as performed by the undo toolbar menu button. This button shows a tooltip, which describes what would be undone if pressed. If you are uncertain, what would be undone, place the mouse over this toolbar button (without pressing) and read the tooltip. Undo for complex operations (tree manipulations, imports etc. are performed via a toolbar button, which shows the kind of operation to be undone in its tooltip).

* '''<kbd>Ctrl-y</kbd>''' - "''Redo''" Undoes the last undo operation. Currently, this works only in text editor windows (i.e. be careful in the diagram editor).

* '''<kbd>Ctrl-f</kbd>''' - "''Find''" Opens a dialog to enter a search string and various options for search (pattern-matching search, wrap at end, etc.). In a text editor, a replace string can be entered for search and replace.

* '''<kbd>F2</kbd>''' - "''Rename''" In the tree or diagram editor, lets you rename the selected element. In a code editor, it renames a variable.

=== Tree/List Organisation ===

The tree interprets certain shortcuts differently than other views.

* '''<kbd>Ctrl-↓</kbd>''' (= Ctrl-CursorDown) - "''Move Down''" This moves the selected item(s) down in the navigation tree or a testplan's list of test cases. In a diagram editor, if a step's pin is selected in the diagram editor, this is moved towards the bottom.

* '''<kbd>Ctrl-↑</kbd>''' (= Ctrl-CursorUp) - "''Move Up''" This moves the selected item up in the navigation tree or a testplan's list of test cases. In a diagram editor, if a step's pin is selected in the diagram editor, this is moved towards the top.

* '''<kbd>Ctrl-←</kbd>''' (= Ctrl-CursorLeft) - "''Move Out''" In the navigation tree, this moves the selected item out of its containing (parent) item and places it below the parent in the list.

* '''<kbd>Ctrl-→</kbd>''' (= Ctrl-CursorRight) - "''Move In''" In the navigation tree, this moves the selected item into the tree item right above it. I.e. it makes it a child element of the other item.

* '''<kbd>Ctrl-Shift-↓</kbd>''' (= Ctrl-Shift-CursorDown) - "''Move to Bottom''" This moves the selected item(s) down in the navigation tree to the end of the children list.

* '''<kbd>Ctrl-Shift-↑</kbd>''' (= Ctrl-Shift-CursorUp] - "''Move to Top''" This moves the selected item up in the navigation tree to the beginning of the children list.

=== Element Creation (Diagram Editor) ===

* '''<kbd>Ctrl-n</kbd>''' - "''New Step''" In the diagram editor: opens a dialog to create a new step. The dialog lets you choose the action which is to be instantiated. If a pin is selected, the dialog filters are preset to only show action blocks with correspondingly typed pins. In the scheme editor: adds a new input or output pin, depending on the currently selected pin's type.

* '''<kbd>Ctrl-r</kbd>''' - "''Replace''" In the diagram editor, this opens a dialog to choose another action which is to replace the selected action.

* '''<kbd>Ctrl-g</kbd>''' - "''Graphic''" In the diagram editor, this opens a dialog to choose an image which is added as annotation (useful to mark areas of the diagram as "Under Construction" or "Attention Here".

* '''<kbd>Ctrl-i</kbd>''' - "''New InputPin''". In the scheme editor, this adds a new input pin - same as clicking on the "''Add Input Pin''" button.

* '''<kbd>Ctrl-o</kbd>''' - "''New OutputPin''". In the scheme editor, this adds a new output pin - same as clicking on the "''Add Output Pin''" button.

More editing functions are found in every text editor's, lists or diagram's right-button menu; some of which do have keyboard shortcuts.

=== Code Editor ===

For a full list, see [[Code_Editor/en#Editor_Functions_and_Keyboard_Shortcuts|"Editor Functions and Keyboard Shortcuts"]].

* '''<kbd>Ctrl-g</kbd>''' - "''Goto Line''" In text editors: to position the cursor to an entered line number. If the entered number has a sign (+/-), the positioning is relative to the current line. In a diagram editor, a graphic annotation is inserted (see below)

* '''<kbd>Alt-f</kbd>''' - "''Forward Search''" Searches for the next occurrence of the previous search string.

* '''<kbd>Alt-b</kbd>''' - "''Backward Search''" Searches for the previous occurrence of the previous search string.

* '''<kbd>F8</kbd>''' - "''Again''" Repeats the last cut or replace operation in a text editor. For example, to replace a string by another string, first select it, type in the new word, then press <kbd>F8</kbd> to search for the next occurrence and replace again. If the previous operation was a "cut" or "delete", then <kbd>F8</kbd> searches for the next occurrence and deletes that again.

* '''<kbd>F4</kbd>''' - "''Comment''" In an elementary code editor, comments the selection or the current cursor line

* '''<kbd>F5</kbd>''' - "''Uncomment''" In an elementary code editor, uncomments the selection or the current cursor line

* '''<kbd>F6</kbd>''' - "''Toggle Case''" toggles the selection between titlecase, uppercase and lowercase (press multiple times)

* '''<kbd>F9</kbd>''' - "''Undent by 4''" remove the left 4 spaces of the selected line range, or the cursor line (if no lines are seleted). Undent is also possible by selecting a number of lines and pressing <kbd>Shift-Tab</kbd>.

* '''<kbd>F10</kbd>''' - "''Indent by 4''" add 4 spaces to the left of the selected line range, or the cursor line. Indent is also possible by selecting a number of lines and pressing <kbd>Tab</kbd>.

* '''<kbd>F11</kbd>''' - "''Undent by 1''"

* '''<kbd>F12</kbd>''' - "''Indent by 1''"

* '''<kbd>Ctrl-d;</kbd>''' - "''DoIt''" This works in code editors for Smalltalk or the builtin JavaScript actions. It takes the currently selected piece of text and immediately executes it as a program. The result is silently discarded (see below for more). If no text is currently selected, the current cursor line is taken as input. See the "[[Smalltalk Syntax Cheat Sheet]]" for a short syntax summary.

* '''<kbd>Ctrl-p;</kbd>''' - "''PrintIt''" Simular to the above, but the result is pasted after the selection. As an example, in a code editor, type "<code>45 degrees sin</code>" (without the double quotes), select it, and press <kbd>PrintIt</kbd>. The result will be pasted after the selection. This also works in a workspace/notepad window.

* '''<kbd>Ctrl-q;</kbd>''' - "''InspectIt''" Simular to the above, but an inspector window is opened on the result.

* '''<kbd>Ctrl-B;</kbd>''' (Ctrl-Shift-B) - "''BrowseIt''" Simular to the above, but a class browser is opened on the result's class, showing all operations (methods) which are implemented by this object.

* '''<kbd>Ctrl-I;</kbd>''' (Ctrl-Shift-I) - "''Implementors''" Extracts a Smalltalk message name (i.e. the name of an operation) and opens a browser on all methods in the system which implement that message.

=== Other ===

* '''<kbd>Ctrl-+</kbd>''' (= Ctrl-plus) - "''Zoom In''" Text in the current focus view is shown in a larger font; diagrams are magnified

* '''<kbd>Ctrl--</kbd>''' (= Ctrl-minus) - "''Zoom Out''" Text in the current focus view is shown in a smaller font; diagrams are shrunk

* '''<kbd>Ctrl-Shift-+</kbd>''' (= Ctrl-Shift-plus) - "''Zoom In All''" Zoom-In all components of the expecco window

* '''<kbd>Ctrl-Shift--</kbd>''' (= Ctrl-Shift-minus) - "''Zoom Out All''" Zoom-Out all components of the expecco window.

=== Customizing Keyboard Shortcuts ===

When expecco starts, it looks for a file named "<code>keyboard.rc</code>" in the "<code>bin</code>" folder (where the expecco executable is installed). All keyboard shortcuts are defined in this script file by associating symbolic operations (like "''Accept''" or "''FindNext''" to real key combinations like "<kbd>Ctrls</kbd>" or "<kbd>Cmdf</kbd>". Case matters, so "<kbd>Ctrlt</kbd>" and "<kbd>CtrlT</kbd>" define unshifted and shifted <kbd>CTRL+t</kbd> combinations.
 To customize the keyboard shortcuts, take the code there as a guide.

These definitions are the default settings; however, individual users may as well change or add personal preferences
via the "''Extras''" → "''Settings''" → "''Keyboard''" dialog.

If you see grey symbolic shortcuts in a popup or pulldown menu, these are non-associated functions, for which no such association was present in the keyboard map.

Common Keyboard Shortcuts/en

2026-06-06T10:31:19Z

Cg:

In general, keyboard shortcuts perform functions which are also available on popup menus of the individual UI components, and these popup menu are usually context/selection menus. This means, that they typically offer operations on the current selected element within that view. In contrast to eg. Mac OSX, the keyboard shortcuts are context sensitive, and depend on the current focus window. This means that the same shortcut may perform different operations depending on which component has the keyboard focus.

All editing functions can be undone via the "''Undo''" (<kbd>Ctrl-z</kbd>) menu function, in case you pressed the wrong key or inside another component.

Notice that the <kbd>Alt</kbd> key is labelled <kbd>Cmd</kbd> on some keyboards (and also inside the <code>"keyboard.rc"</code> file and the settings dialog.

=== Navigating ===

Cursor keys navigate character-wise or word-wise (if <kbd>CTRL</kbd> is pressed)

* '''<kbd>Ctrl-CursorRight</kbd>''' - "''Next Word''" Moves the cursor to the next word.

* '''<kbd>Ctrl-CursorLeft</kbd>''' - "''Previous Word''" Moves the cursor to the previous word.

=== Selecting ===

* '''<kbd>Alt-w</kbd>''' - "''Select Next Word''".

* '''<kbd>Shift-CursorKey</kbd>''' - "''Expand the Selection''".

=== General Editing ===

These shortcuts usually work in any view (i.e. project tree view, diagram- and text editors).
Specific operations are found below.

* '''<kbd>Ctrl-c</kbd>''' - "''Copy''". Copies the selection into the clipboard. The object to be copied depends on the context and selection: - in a text editor, the text-selection is copied. - in the diagram editor, the selected element(s) are copied - in the navigation tree, the selected tree items are copied.

* '''<kbd>Ctrl-v</kbd>''' - "''Paste''" Pastes the clipboard object. This is not always possible, and sometimes simply ignored (for example, if a tree-item is copied and tried to be pasted into a text editor).

* '''<kbd>Ctrl-x</kbd>''' - "''Cut''" Deletes the selection and puts it into the clipboard (for later pasting)

* '''<kbd>Del</kbd>''' - "''Delete''" Deletes but does NOT put the deleted object into the clipboard. In a text editor, the selected text is deleted, or if nothing is selected, the next character (after the cursor) is deleted. With <kbd>CTRL</KBD>, the next word is deleted.

* '''<kbd>Backspace</kbd>''' - "''Delete''" Deletes but does NOT put the deleted object into the clipboard. In a text editor, the selected text is deleted, or if nothing is selected, the previous character (before the cursor) is deleted. With <kbd>CTRL</KBD>, the previous word is deleted.

* '''<kbd>Ctrl-z</kbd>''' - "''Undo''" Undoes the last operation. This is a multi-undo. This is the same function as performed by the undo toolbar menu button. This button shows a tooltip, which describes what would be undone if pressed. If you are uncertain, what would be undone, place the mouse over this toolbar button (without pressing) and read the tooltip. Undo for complex operations (tree manipulations, imports etc. are performed via a toolbar button, which shows the kind of operation to be undone in its tooltip).

* '''<kbd>Ctrl-y</kbd>''' - "''Redo''" Undoes the last undo operation. Currently, this works only in text editor windows (i.e. be careful in the diagram editor).

* '''<kbd>Ctrl-f</kbd>''' - "''Find''" Opens a dialog to enter a search string and various options for search (pattern-matching search, wrap at end, etc.). In a text editor, a replace string can be entered for search and replace.

* '''<kbd>F2</kbd>''' - "''Rename''" In the tree or diagram editor, lets you rename the selected element. In a code editor, it renames a variable.

=== Tree/List Organisation ===

The tree interprets certain shortcuts differently than other views.

* '''<kbd>Ctrl-↓</kbd>''' (= Ctrl-CursorDown) - "''Move Down''" This moves the selected item(s) down in the navigation tree or a testplan's list of test cases. In a diagram editor, if a step's pin is selected in the diagram editor, this is moved towards the bottom.

* '''<kbd>Ctrl-↑</kbd>''' (= Ctrl-CursorUp) - "''Move Up''" This moves the selected item up in the navigation tree or a testplan's list of test cases. In a diagram editor, if a step's pin is selected in the diagram editor, this is moved towards the top.

* '''<kbd>Ctrl-←</kbd>''' (= Ctrl-CursorLeft) - "''Move Out''" In the navigation tree, this moves the selected item out of its containing (parent) item and places it below the parent in the list.

* '''<kbd>Ctrl-→</kbd>''' (= Ctrl-CursorRight) - "''Move In''" In the navigation tree, this moves the selected item into the tree item right above it. I.e. it makes it a child element of the other item.

* '''<kbd>Ctrl-Shift-↓</kbd>''' (= Ctrl-Shift-CursorDown) - "''Move to Bottom''" This moves the selected item(s) down in the navigation tree to the end of the children list.

* '''<kbd>Ctrl-Shift-↑</kbd>''' (= Ctrl-Shift-CursorUp] - "''Move to Top''" This moves the selected item up in the navigation tree to the beginning of the children list.

=== Element Creation (Diagram Editor) ===

* '''<kbd>Ctrl-n</kbd>''' - "''New Step''" In the diagram editor: opens a dialog to create a new step. The dialog lets you choose the action which is to be instantiated. If a pin is selected, the dialog filters are preset to only show action blocks with correspondingly typed pins. In the scheme editor: adds a new input or output pin, depending on the currently selected pin's type.

* '''<kbd>Ctrl-r</kbd>''' - "''Replace''" In the diagram editor, this opens a dialog to choose another action which is to replace the selected action.

* '''<kbd>Ctrl-g</kbd>''' - "''Graphic''" In the diagram editor, this opens a dialog to choose an image which is added as annotation (useful to mark areas of the diagram as "Under Construction" or "Attention Here".

* '''<kbd>Ctrl-i</kbd>''' - "''New InputPin''". In the scheme editor, this adds a new input pin - same as clicking on the "''Add Input Pin''" button.

* '''<kbd>Ctrl-o</kbd>''' - "''New OutputPin''". In the scheme editor, this adds a new output pin - same as clicking on the "''Add Output Pin''" button.

More editing functions are found in every text editor's, lists or diagram's right-button menu; some of which do have keyboard shortcuts.

=== Code Editor ===

For a full list, see [[Code_Editor/en#Editor_Functions_and_Keyboard_Shortcuts|"Editor Functions and Keyboard Shortcuts"]].

* '''<kbd>Ctrl-g</kbd>''' - "''Goto Line''" In text editors: to position the cursor to an entered line number. If the entered number has a sign (+/-), the positioning is relative to the current line. In a diagram editor, a graphic annotation is inserted (see below)

* '''<kbd>Alt-f</kbd>''' - "''Forward Search''" Searches for the next occurrence of the previous search string.

* '''<kbd>Alt-b</kbd>''' - "''Backward Search''" Searches for the previous occurrence of the previous search string.

* '''<kbd>F8</kbd>''' - "''Again''" Repeats the last cut or replace operation in a text editor. For example, to replace a string by another string, first select it, type in the new word, then press <kbd>F8</kbd> to search for the next occurrence and replace again. If the previous operation was a "cut" or "delete", then <kbd>F8</kbd> searches for the next occurrence and deletes that again.

* '''<kbd>F4</kbd>''' - "''Comment''" In an elementary code editor, comments the selection or the current cursor line

* '''<kbd>F5</kbd>''' - "''Uncomment''" In an elementary code editor, uncomments the selection or the current cursor line

* '''<kbd>F6</kbd>''' - "''Toggle Case''" toggles the selection between titlecase, uppercase and lowercase (press multiple times)

* '''<kbd>F9</kbd>''' - "''Undent by 4''" remove the left 4 spaces of the selected line range, or the cursor line (if no lines are seleted). Undent is also possible by selecting a number of lines and pressing <kbd>Shift-Tab</kbd>.

* '''<kbd>F10</kbd>''' - "''Indent by 4''" add 4 spaces to the left of the selected line range, or the cursor line. Indent is also possible by selecting a number of lines and pressing <kbd>Tab</kbd>.

* '''<kbd>F11</kbd>''' - "''Undent by 1''"

* '''<kbd>F12</kbd>''' - "''Indent by 1''"

* '''<kbd>Ctrl-d;</kbd>''' - "''DoIt''" This works in code editors for Smalltalk or the builtin JavaScript actions. It takes the currently selected piece of text and immediately executes it as a program. The result is silently discarded (see below for more). If no text is currently selected, the current cursor line is taken as input. See the "[[Smalltalk Syntax Cheat Sheet]]" for a short syntax summary.

* '''<kbd>Ctrl-p;</kbd>''' - "''PrintIt''" Simular to the above, but the result is pasted after the selection. As an example, in a code editor, type "<code>45 degrees sin</code>" (without the double quotes), select it, and press <kbd>PrintIt</kbd>. The result will be pasted after the selection. This also works in a workspace/notepad window.

* '''<kbd>Ctrl-q;</kbd>''' - "''InspectIt''" Simular to the above, but an inspector window is opened on the result.

* '''<kbd>Ctrl-B;</kbd>''' (Ctrl-Shift-B) - "''BrowseIt''" Simular to the above, but a class browser is opened on the result's class, showing all operations (methods) which are implemented by this object.

* '''<kbd>Ctrl-I;</kbd>''' (Ctrl-Shift-I) - "''Implementors''" Extracts a Smalltalk message name (i.e. the name of an operation) and opens a browser on all methods in the system which implement that message.

=== Other ===

* '''<kbd>Ctrl-+</kbd>''' (= Ctrl-plus) - "''Zoom In''" Text in the current focus view is shown in a larger font; diagrams are magnified

* '''<kbd>Ctrl--</kbd>''' (= Ctrl-minus) - "''Zoom Out''" Text in the current focus view is shown in a smaller font; diagrams are shrunk

* '''<kbd>Ctrl-Shift-+</kbd>''' (= Ctrl-Shift-plus) - "''Zoom In All''" Zoom-In all components of the expecco window

* '''<kbd>Ctrl-Shift--</kbd>''' (= Ctrl-Shift-minus) - "''Zoom Out All''" Zoom-Out all components of the expecco window.

=== Customizing Keyboard Shortcuts ===

When expecco starts, it looks for a file named "<code>keyboard.rc</code>" in the "<code>bin</code>" folder (where the expecco executable is installed). All keyboard shortcuts are defined in this script file by associating symbolic operations (like "''Accept''" or "''FindNext''" to real key combinations like "<kbd>Ctrls</kbd>" or "<kbd>Cmdf</kbd>". Case matters, so "<kbd>Ctrlt</kbd>" and "<kbd>CtrlT</kbd>" define unshifted and shifted <kbd>CTRL+t<kbd> combinations.
 To customize the keyboard shortcuts, take the code there as a guide.

These definitions are the default settings; however, individual users may as well change or add personal preferences
via the "''Extras''" → "''Settings''" → "''Keyboard''" dialog.

If you see grey symbolic shortcuts in a popup or pulldown menu, these are non-associated functions, for which no such association was present in the keyboard map.

Common Keyboard Shortcuts/en

2026-06-06T10:28:48Z

Cg: /* Customizing Keyboard Shortcuts */

In general, keyboard shortcuts perform functions which are also available on popup menus of the individual UI components, and these popup menu are usually context/selection menus. This means, that they typically offer operations on the current selected element within that view. In contrast to eg. Mac OSX, the keyboard shortcuts are context sensitive, and depend on the current focus window. This means that the same shortcut may perform different operations depending on which component has the keyboard focus.

All editing functions can be undone via the "''Undo''" (<kbd>Ctrl-z</kbd>) menu function, in case you pressed the wrong key or inside another component.

Notice that the <kbd>Alt</kbd> key is labelled <kbd>Cmd</kbd> on some keyboards (and also inside the <code>"keyboard.rc"</code> file and the settings dialog.

=== Navigating ===

Cursor keys navigate character-wise or word-wise (if <kbd>CTRL</kbd> is pressed)

* '''<kbd>Ctrl-CursorRight</kbd>''' - "''Next Word''" Moves the cursor to the next word.

* '''<kbd>Ctrl-CursorLeft</kbd>''' - "''Previous Word''" Moves the cursor to the previous word.

=== Selecting ===

* '''<kbd>Alt-w</kbd>''' - "''Select Next Word''".

* '''<kbd>Shift-CursorKey</kbd>''' - "''Expand the Selection''".

=== General Editing ===

These shortcuts usually work in any view (i.e. project tree view, diagram- and text editors).
Specific operations are found below.

* '''<kbd>Ctrl-c</kbd>''' - "''Copy''". Copies the selection into the clipboard. The object to be copied depends on the context and selection: - in a text editor, the text-selection is copied. - in the diagram editor, the selected element(s) are copied - in the navigation tree, the selected tree items are copied.

* '''<kbd>Ctrl-v</kbd>''' - "''Paste''" Pastes the clipboard object. This is not always possible, and sometimes simply ignored (for example, if a tree-item is copied and tried to be pasted into a text editor).

* '''<kbd>Ctrl-x</kbd>''' - "''Cut''" Deletes the selection and puts it into the clipboard (for later pasting)

* '''<kbd>Del</kbd>''' - "''Delete''" Deletes but does NOT put the deleted object into the clipboard. In a text editor, the selected text is deleted, or if nothing is selected, the next character (after the cursor) is deleted. With <kbd>CTRL</KBD>, the next word is deleted.

* '''<kbd>Backspace</kbd>''' - "''Delete''" Deletes but does NOT put the deleted object into the clipboard. In a text editor, the selected text is deleted, or if nothing is selected, the previous character (before the cursor) is deleted. With <kbd>CTRL</KBD>, the previous word is deleted.

* '''<kbd>Ctrl-z</kbd>''' - "''Undo''" Undoes the last operation. This is a multi-undo. This is the same function as performed by the undo toolbar menu button. This button shows a tooltip, which describes what would be undone if pressed. If you are uncertain, what would be undone, place the mouse over this toolbar button (without pressing) and read the tooltip. Undo for complex operations (tree manipulations, imports etc. are performed via a toolbar button, which shows the kind of operation to be undone in its tooltip).

* '''<kbd>Ctrl-y</kbd>''' - "''Redo''" Undoes the last undo operation. Currently, this works only in text editor windows (i.e. be careful in the diagram editor).

* '''<kbd>Ctrl-f</kbd>''' - "''Find''" Opens a dialog to enter a search string and various options for search (pattern-matching search, wrap at end, etc.). In a text editor, a replace string can be entered for search and replace.

* '''<kbd>F2</kbd>''' - "''Rename''" In the tree or diagram editor, lets you rename the selected element. In a code editor, it renames a variable.

=== Tree/List Organisation ===

The tree interprets certain shortcuts differently than other views.

* '''<kbd>Ctrl-↓</kbd>''' (= Ctrl-CursorDown) - "''Move Down''" This moves the selected item(s) down in the navigation tree or a testplan's list of test cases. In a diagram editor, if a step's pin is selected in the diagram editor, this is moved towards the bottom.

* '''<kbd>Ctrl-↑</kbd>''' (= Ctrl-CursorUp) - "''Move Up''" This moves the selected item up in the navigation tree or a testplan's list of test cases. In a diagram editor, if a step's pin is selected in the diagram editor, this is moved towards the top.

* '''<kbd>Ctrl-←</kbd>''' (= Ctrl-CursorLeft) - "''Move Out''" In the navigation tree, this moves the selected item out of its containing (parent) item and places it below the parent in the list.

* '''<kbd>Ctrl-→</kbd>''' (= Ctrl-CursorRight) - "''Move In''" In the navigation tree, this moves the selected item into the tree item right above it. I.e. it makes it a child element of the other item.

* '''<kbd>Ctrl-Shift-↓</kbd>''' (= Ctrl-Shift-CursorDown) - "''Move to Bottom''" This moves the selected item(s) down in the navigation tree to the end of the children list.

* '''<kbd>Ctrl-Shift-↑</kbd>''' (= Ctrl-Shift-CursorUp] - "''Move to Top''" This moves the selected item up in the navigation tree to the beginning of the children list.

=== Element Creation (Diagram Editor) ===

* '''<kbd>Ctrl-n</kbd>''' - "''New Step''" In the diagram editor: opens a dialog to create a new step. The dialog lets you choose the action which is to be instantiated. If a pin is selected, the dialog filters are preset to only show action blocks with correspondingly typed pins. In the scheme editor: adds a new input or output pin, depending on the currently selected pin's type.

* '''<kbd>Ctrl-r</kbd>''' - "''Replace''" In the diagram editor, this opens a dialog to choose another action which is to replace the selected action.

* '''<kbd>Ctrl-g</kbd>''' - "''Graphic''" In the diagram editor, this opens a dialog to choose an image which is added as annotation (useful to mark areas of the diagram as "Under Construction" or "Attention Here".

* '''<kbd>Ctrl-i</kbd>''' - "''New InputPin''". In the scheme editor, this adds a new input pin - same as clicking on the "''Add Input Pin''" button.

* '''<kbd>Ctrl-o</kbd>''' - "''New OutputPin''". In the scheme editor, this adds a new output pin - same as clicking on the "''Add Output Pin''" button.

More editing functions are found in every text editor's, lists or diagram's right-button menu; some of which do have keyboard shortcuts.

=== Code Editor ===

For a full list, see [[Code_Editor/en#Editor_Functions_and_Keyboard_Shortcuts|"Editor Functions and Keyboard Shortcuts"]].

* '''<kbd>Ctrl-g</kbd>''' - "''Goto Line''" In text editors: to position the cursor to an entered line number. If the entered number has a sign (+/-), the positioning is relative to the current line. In a diagram editor, a graphic annotation is inserted (see below)

* '''<kbd>Alt-f</kbd>''' - "''Forward Search''" Searches for the next occurrence of the previous search string.

* '''<kbd>Alt-b</kbd>''' - "''Backward Search''" Searches for the previous occurrence of the previous search string.

* '''<kbd>F8</kbd>''' - "''Again''" Repeats the last cut or replace operation in a text editor. For example, to replace a string by another string, first select it, type in the new word, then press <kbd>F8</kbd> to search for the next occurrence and replace again. If the previous operation was a "cut" or "delete", then <kbd>F8</kbd> searches for the next occurrence and deletes that again.

* '''<kbd>F4</kbd>''' - "''Comment''" In an elementary code editor, comments the selection or the current cursor line

* '''<kbd>F5</kbd>''' - "''Uncomment''" In an elementary code editor, uncomments the selection or the current cursor line

* '''<kbd>F6</kbd>''' - "''Toggle Case''" toggles the selection between titlecase, uppercase and lowercase (press multiple times)

* '''<kbd>F9</kbd>''' - "''Undent by 4''" remove the left 4 spaces of the selected line range, or the cursor line (if no lines are seleted). Undent is also possible by selecting a number of lines and pressing <kbd>Shift-Tab</kbd>.

* '''<kbd>F10</kbd>''' - "''Indent by 4''" add 4 spaces to the left of the selected line range, or the cursor line. Indent is also possible by selecting a number of lines and pressing <kbd>Tab</kbd>.

* '''<kbd>F11</kbd>''' - "''Undent by 1''"

* '''<kbd>F12</kbd>''' - "''Indent by 1''"

* '''<kbd>Ctrl-d;</kbd>''' - "''DoIt''" This works in code editors for Smalltalk or the builtin JavaScript actions. It takes the currently selected piece of text and immediately executes it as a program. The result is silently discarded (see below for more). If no text is currently selected, the current cursor line is taken as input. See the "[[Smalltalk Syntax Cheat Sheet]]" for a short syntax summary.

* '''<kbd>Ctrl-p;</kbd>''' - "''PrintIt''" Simular to the above, but the result is pasted after the selection. As an example, in a code editor, type "<code>45 degrees sin</code>" (without the double quotes), select it, and press <kbd>PrintIt</kbd>. The result will be pasted after the selection. This also works in a workspace/notepad window.

* '''<kbd>Ctrl-q;</kbd>''' - "''InspectIt''" Simular to the above, but an inspector window is opened on the result.

* '''<kbd>Ctrl-B;</kbd>''' (Ctrl-Shift-B) - "''BrowseIt''" Simular to the above, but a class browser is opened on the result's class, showing all operations (methods) which are implemented by this object.

* '''<kbd>Ctrl-I;</kbd>''' (Ctrl-Shift-I) - "''Implementors''" Extracts a Smalltalk message name (i.e. the name of an operation) and opens a browser on all methods in the system which implement that message.

=== Other ===

* '''<kbd>Ctrl-+</kbd>''' (= Ctrl-plus) - "''Zoom In''" Text in the current focus view is shown in a larger font; diagrams are magnified

* '''<kbd>Ctrl--</kbd>''' (= Ctrl-minus) - "''Zoom Out''" Text in the current focus view is shown in a smaller font; diagrams are shrunk

* '''<kbd>Ctrl-Shift-+</kbd>''' (= Ctrl-Shift-plus) - "''Zoom In All''" Zoom-In all components of the expecco window

* '''<kbd>Ctrl-Shift--</kbd>''' (= Ctrl-Shift-minus) - "''Zoom Out All''" Zoom-Out all components of the expecco window.

=== Customizing Keyboard Shortcuts ===

When expecco starts, it looks for a file named "<code>keyboard.rc</code>" in the "<code>bin</code>" folder (where the expecco executable is installed). All keyboard shortcuts are defined in this script file by associating symbolic operations (like "''Accept''" or "''FindNext''" to real key combinations like "<code>Ctrls</code>" or "<code>Cmdf</code>". Case matters, so "<code>Ctrlt</code>" and "<code>CtrlT</code>" define unshifted and shifted CTRL+t combinations.
 To customize the keyboard shortcuts, take the code there as a guide.

These definitions are the default settings; however, individual users may as well change or add personal preferences
via the "''Extras''" → "''Settings''" → "''Keyboard''" dialog.

If you see grey symbolic shortcuts in a popup or pulldown menu, these are non-associated functions, for which no such association was present in the keyboard map.

Glossary/en

2026-06-06T08:45:19Z

Cg: /* VisualWorks */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints, debugging with single stepping and object inspectors.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another. Any input/output must be either through files or encoded/decoded and passed via stdin/stdout.

== SFTP (Secure File Transfer) ==
A mechanism to transfer files via an encrypted and authenticated channel to another machine. Expecco includes a pure Smalltalk implementation which does not depend on any tools provided by the operating system (but of course, these could also be used). See "[[Remote_Access/en|Remote Access]]" documentation.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support. "''just-in-time''" means that code which is added dynamically at execution time will be compiled to machine code when that code is called for the first time; "''ahead-of-time''" means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called. Ahead of time compilation avoids the pause times (reduces the startup/''warmup'' time) and gives more deterministic function call times. Both present in pure just-in-time compiled systems. ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, any API, feature or mechanism present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system). See "[[Remote_Access/en|Remote Access]]" documentation

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X". See above.

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. Every well behaving program will send error messages to stderr and regular output to stdout, making it possible to divert these to different destinations. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. Every well behaving program will send error messages to stderr and regular output to stdout, making it possible to divert these to different destinations. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "<code>{ expr1 . expr2 . ... exprN }</code>" or the expanded expression string "<code> e'...{expr}..'</code>" are syntactic sugar for Array-instantiation "<code>(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself</code>" or a call to the string expansion method. Btw: you don't have to understand this, to use expecco.

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. In addition to support searching and grouping, additional other behavior can be controlled by tags. For example, you can define an icon or color to be shown in the left project tree if the item has a particular tag. You can also use tags to control the execution, for filtering log entries or to control the generation of logs.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They can be created when suites are imported from an external tool, stored with the suite and passed back transparently to the tool, supporting round trip import/export without loosing information which expecco does not need. Tagged values can be attached to every element in the project tree or a diagram (i.e. actions, types, steps, pins etc.).
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualAge ==
[https://en.wkipedia.org/wiki/VisualAge VisualAge] ("''VA Smalltalk''") is the brand name of a [https://en.wkipedia.org/wiki/Smalltalk Smalltalk] language implementation ("''dialect''") and environment originally developed by OTI, then taken over by IBM (aka "''IBM Smalltalk''") and now Instantiations Inc.

== VisualWorks ==
[https://en.wkipedia.org/wiki/VisualWorks VisualWorks] (or "''VW''" / "''VW-Smalltalk''") is the brand name of a Smalltalk programming language environment ("''dialect''") from ParcPlace Systems, now Cincom, a US based company. VisualWorks is an ANSI compatible [https://en.wkipedia.org/wiki/Smalltalk Smalltalk], and a direct descendent of the original Smalltalk80 system from Xerox Parc. It shares many APIs with Smalltalk/X, and VisualWorks documentation is mostly also valid for ST/X (differences are in the namespace notation and ST/X language extensions). Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco via an extension plugin.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T08:44:34Z

Cg: /* VisualWorks */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints, debugging with single stepping and object inspectors.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another. Any input/output must be either through files or encoded/decoded and passed via stdin/stdout.

== SFTP (Secure File Transfer) ==
A mechanism to transfer files via an encrypted and authenticated channel to another machine. Expecco includes a pure Smalltalk implementation which does not depend on any tools provided by the operating system (but of course, these could also be used). See "[[Remote_Access/en|Remote Access]]" documentation.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support. "''just-in-time''" means that code which is added dynamically at execution time will be compiled to machine code when that code is called for the first time; "''ahead-of-time''" means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called. Ahead of time compilation avoids the pause times (reduces the startup/''warmup'' time) and gives more deterministic function call times. Both present in pure just-in-time compiled systems. ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, any API, feature or mechanism present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system). See "[[Remote_Access/en|Remote Access]]" documentation

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X". See above.

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. Every well behaving program will send error messages to stderr and regular output to stdout, making it possible to divert these to different destinations. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. Every well behaving program will send error messages to stderr and regular output to stdout, making it possible to divert these to different destinations. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "<code>{ expr1 . expr2 . ... exprN }</code>" or the expanded expression string "<code> e'...{expr}..'</code>" are syntactic sugar for Array-instantiation "<code>(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself</code>" or a call to the string expansion method. Btw: you don't have to understand this, to use expecco.

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. In addition to support searching and grouping, additional other behavior can be controlled by tags. For example, you can define an icon or color to be shown in the left project tree if the item has a particular tag. You can also use tags to control the execution, for filtering log entries or to control the generation of logs.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They can be created when suites are imported from an external tool, stored with the suite and passed back transparently to the tool, supporting round trip import/export without loosing information which expecco does not need. Tagged values can be attached to every element in the project tree or a diagram (i.e. actions, types, steps, pins etc.).
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualAge ==
[https://en.wkipedia.org/wiki/VisualAge VisualAge] ("''VA Smalltalk''") is the brand name of a [https://en.wkipedia.org/wiki/Smalltalk Smalltalk] language implementation ("''dialect''") and environment originally developed by OTI, then taken over by IBM (aka "''IBM Smalltalk''") and now Instantiations Inc.

== VisualWorks ==
[https://en.wkipedia.org/wiki/VisualWorks VisualWorks] (or "''VW''" / "''VW-Smalltalk''") is the brand name of a Smalltalk programming language environment ("''dialect''") from ParcPlace Systems, now Cincom, a US based company. VisualWorks is an ANSI compatible [https://en.wkipedia.org/wiki/Smalltalk Smalltalk], is a direct descendent of the original Smalltalk80 system from Xerox Parc. It shares many APIs with Smalltalk/X, and VisualWorks documentation is mostly also valid for ST/X (differences are in the namespace notation and ST/X language extensions). Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco via an extension plugin.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T08:37:40Z

Cg: /* VisualAge */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints, debugging with single stepping and object inspectors.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another. Any input/output must be either through files or encoded/decoded and passed via stdin/stdout.

== SFTP (Secure File Transfer) ==
A mechanism to transfer files via an encrypted and authenticated channel to another machine. Expecco includes a pure Smalltalk implementation which does not depend on any tools provided by the operating system (but of course, these could also be used). See "[[Remote_Access/en|Remote Access]]" documentation.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support. "''just-in-time''" means that code which is added dynamically at execution time will be compiled to machine code when that code is called for the first time; "''ahead-of-time''" means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called. Ahead of time compilation avoids the pause times (reduces the startup/''warmup'' time) and gives more deterministic function call times. Both present in pure just-in-time compiled systems. ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, any API, feature or mechanism present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system). See "[[Remote_Access/en|Remote Access]]" documentation

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X". See above.

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. Every well behaving program will send error messages to stderr and regular output to stdout, making it possible to divert these to different destinations. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. Every well behaving program will send error messages to stderr and regular output to stdout, making it possible to divert these to different destinations. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "<code>{ expr1 . expr2 . ... exprN }</code>" or the expanded expression string "<code> e'...{expr}..'</code>" are syntactic sugar for Array-instantiation "<code>(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself</code>" or a call to the string expansion method. Btw: you don't have to understand this, to use expecco.

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. In addition to support searching and grouping, additional other behavior can be controlled by tags. For example, you can define an icon or color to be shown in the left project tree if the item has a particular tag. You can also use tags to control the execution, for filtering log entries or to control the generation of logs.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They can be created when suites are imported from an external tool, stored with the suite and passed back transparently to the tool, supporting round trip import/export without loosing information which expecco does not need. Tagged values can be attached to every element in the project tree or a diagram (i.e. actions, types, steps, pins etc.).
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualAge ==
[https://en.wkipedia.org/wiki/VisualAge VisualAge] ("''VA Smalltalk''") is the brand name of a [https://en.wkipedia.org/wiki/Smalltalk Smalltalk] language implementation ("''dialect''") and environment originally developed by OTI, then taken over by IBM (aka "''IBM Smalltalk''") and now Instantiations Inc.

== VisualWorks ==
VisualWorks [https://en.wkipedia.org/wiki/VisualWorks] ("''VW''") is the brand name of a Smalltalk programming language environment ("''dialect''") from Cincom, a US based company. VisualWorks is an ANSI compatible [https://en.wkipedia.org/wiki/Smalltalk Smalltalk], sharing many of its APIs with Smalltalk/X, and VisualWorks documentation is mostly also valid for ST/X (differences are in the namespace notation and ST/X language extensions). Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco via an extension plugin.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T08:36:06Z

Cg: /* VisualWorks */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints, debugging with single stepping and object inspectors.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another. Any input/output must be either through files or encoded/decoded and passed via stdin/stdout.

== SFTP (Secure File Transfer) ==
A mechanism to transfer files via an encrypted and authenticated channel to another machine. Expecco includes a pure Smalltalk implementation which does not depend on any tools provided by the operating system (but of course, these could also be used). See "[[Remote_Access/en|Remote Access]]" documentation.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support. "''just-in-time''" means that code which is added dynamically at execution time will be compiled to machine code when that code is called for the first time; "''ahead-of-time''" means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called. Ahead of time compilation avoids the pause times (reduces the startup/''warmup'' time) and gives more deterministic function call times. Both present in pure just-in-time compiled systems. ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, any API, feature or mechanism present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system). See "[[Remote_Access/en|Remote Access]]" documentation

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X". See above.

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. Every well behaving program will send error messages to stderr and regular output to stdout, making it possible to divert these to different destinations. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. Every well behaving program will send error messages to stderr and regular output to stdout, making it possible to divert these to different destinations. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "<code>{ expr1 . expr2 . ... exprN }</code>" or the expanded expression string "<code> e'...{expr}..'</code>" are syntactic sugar for Array-instantiation "<code>(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself</code>" or a call to the string expansion method. Btw: you don't have to understand this, to use expecco.

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. In addition to support searching and grouping, additional other behavior can be controlled by tags. For example, you can define an icon or color to be shown in the left project tree if the item has a particular tag. You can also use tags to control the execution, for filtering log entries or to control the generation of logs.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They can be created when suites are imported from an external tool, stored with the suite and passed back transparently to the tool, supporting round trip import/export without loosing information which expecco does not need. Tagged values can be attached to every element in the project tree or a diagram (i.e. actions, types, steps, pins etc.).
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualAge ==
[https://en.wkipedia.org/wiki/VisualAge VisualAge] ("''VA Smalltalk''") is the brand name of a [https://en.wkipedia.org/wiki/Smalltalk Smalltalk] language implementation and environment originally develloped by OTI, then taken over by IBM and now Instantiations.

== VisualWorks ==
VisualWorks [https://en.wkipedia.org/wiki/VisualWorks] ("''VW''") is the brand name of a Smalltalk programming language environment ("''dialect''") from Cincom, a US based company. VisualWorks is an ANSI compatible [https://en.wkipedia.org/wiki/Smalltalk Smalltalk], sharing many of its APIs with Smalltalk/X, and VisualWorks documentation is mostly also valid for ST/X (differences are in the namespace notation and ST/X language extensions). Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco via an extension plugin.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T08:18:32Z

Cg: /* VisualWorks */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints, debugging with single stepping and object inspectors.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another. Any input/output must be either through files or encoded/decoded and passed via stdin/stdout.

== SFTP (Secure File Transfer) ==
A mechanism to transfer files via an encrypted and authenticated channel to another machine. Expecco includes a pure Smalltalk implementation which does not depend on any tools provided by the operating system (but of course, these could also be used). See "[[Remote_Access/en|Remote Access]]" documentation.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support. "''just-in-time''" means that code which is added dynamically at execution time will be compiled to machine code when that code is called for the first time; "''ahead-of-time''" means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called. Ahead of time compilation avoids the pause times (reduces the startup/''warmup'' time) and gives more deterministic function call times. Both present in pure just-in-time compiled systems. ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, any API, feature or mechanism present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system). See "[[Remote_Access/en|Remote Access]]" documentation

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X". See above.

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. Every well behaving program will send error messages to stderr and regular output to stdout, making it possible to divert these to different destinations. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. Every well behaving program will send error messages to stderr and regular output to stdout, making it possible to divert these to different destinations. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "<code>{ expr1 . expr2 . ... exprN }</code>" or the expanded expression string "<code> e'...{expr}..'</code>" are syntactic sugar for Array-instantiation "<code>(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself</code>" or a call to the string expansion method. Btw: you don't have to understand this, to use expecco.

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. In addition to support searching and grouping, additional other behavior can be controlled by tags. For example, you can define an icon or color to be shown in the left project tree if the item has a particular tag. You can also use tags to control the execution, for filtering log entries or to control the generation of logs.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They can be created when suites are imported from an external tool, stored with the suite and passed back transparently to the tool, supporting round trip import/export without loosing information which expecco does not need. Tagged values can be attached to every element in the project tree or a diagram (i.e. actions, types, steps, pins etc.).
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment ("''dialect''") from Cincom, a US based company. VisualWorks is an ANSI compatible Smalltalk, sharing many of its APIs with Smalltalk/X, and VisualWorks documentation is mostly also valid for ST/X (differences are in the namespace notation and ST/X language extensions). Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco via an extension plugin.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T08:11:50Z

Cg: /* Node Elementary Action Block */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints, debugging with single stepping and object inspectors.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another. Any input/output must be either through files or encoded/decoded and passed via stdin/stdout.

== SFTP (Secure File Transfer) ==
A mechanism to transfer files via an encrypted and authenticated channel to another machine. Expecco includes a pure Smalltalk implementation which does not depend on any tools provided by the operating system (but of course, these could also be used). See "[[Remote_Access/en|Remote Access]]" documentation.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support. "''just-in-time''" means that code which is added dynamically at execution time will be compiled to machine code when that code is called for the first time; "''ahead-of-time''" means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called. Ahead of time compilation avoids the pause times (reduces the startup/''warmup'' time) and gives more deterministic function call times. Both present in pure just-in-time compiled systems. ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, any API, feature or mechanism present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system). See "[[Remote_Access/en|Remote Access]]" documentation

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X". See above.

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. Every well behaving program will send error messages to stderr and regular output to stdout, making it possible to divert these to different destinations. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. Every well behaving program will send error messages to stderr and regular output to stdout, making it possible to divert these to different destinations. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "<code>{ expr1 . expr2 . ... exprN }</code>" or the expanded expression string "<code> e'...{expr}..'</code>" are syntactic sugar for Array-instantiation "<code>(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself</code>" or a call to the string expansion method. Btw: you don't have to understand this, to use expecco.

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. In addition to support searching and grouping, additional other behavior can be controlled by tags. For example, you can define an icon or color to be shown in the left project tree if the item has a particular tag. You can also use tags to control the execution, for filtering log entries or to control the generation of logs.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They can be created when suites are imported from an external tool, stored with the suite and passed back transparently to the tool, supporting round trip import/export without loosing information which expecco does not need. Tagged values can be attached to every element in the project tree or a diagram (i.e. actions, types, steps, pins etc.).
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment from Cincom, a US based company. Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T08:10:11Z

Cg: /* Script Actions */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints and debugging with single stepping.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another. Any input/output must be either through files or encoded/decoded and passed via stdin/stdout.

== SFTP (Secure File Transfer) ==
A mechanism to transfer files via an encrypted and authenticated channel to another machine. Expecco includes a pure Smalltalk implementation which does not depend on any tools provided by the operating system (but of course, these could also be used). See "[[Remote_Access/en|Remote Access]]" documentation.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support. "''just-in-time''" means that code which is added dynamically at execution time will be compiled to machine code when that code is called for the first time; "''ahead-of-time''" means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called. Ahead of time compilation avoids the pause times (reduces the startup/''warmup'' time) and gives more deterministic function call times. Both present in pure just-in-time compiled systems. ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, any API, feature or mechanism present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system). See "[[Remote_Access/en|Remote Access]]" documentation

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X". See above.

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. Every well behaving program will send error messages to stderr and regular output to stdout, making it possible to divert these to different destinations. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. Every well behaving program will send error messages to stderr and regular output to stdout, making it possible to divert these to different destinations. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "<code>{ expr1 . expr2 . ... exprN }</code>" or the expanded expression string "<code> e'...{expr}..'</code>" are syntactic sugar for Array-instantiation "<code>(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself</code>" or a call to the string expansion method. Btw: you don't have to understand this, to use expecco.

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. In addition to support searching and grouping, additional other behavior can be controlled by tags. For example, you can define an icon or color to be shown in the left project tree if the item has a particular tag. You can also use tags to control the execution, for filtering log entries or to control the generation of logs.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They can be created when suites are imported from an external tool, stored with the suite and passed back transparently to the tool, supporting round trip import/export without loosing information which expecco does not need. Tagged values can be attached to every element in the project tree or a diagram (i.e. actions, types, steps, pins etc.).
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment from Cincom, a US based company. Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T08:06:18Z

Cg: /* Stdout */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints and debugging with single stepping.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another.

== SFTP (Secure File Transfer) ==
A mechanism to transfer files via an encrypted and authenticated channel to another machine. Expecco includes a pure Smalltalk implementation which does not depend on any tools provided by the operating system (but of course, these could also be used). See "[[Remote_Access/en|Remote Access]]" documentation.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support. "''just-in-time''" means that code which is added dynamically at execution time will be compiled to machine code when that code is called for the first time; "''ahead-of-time''" means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called. Ahead of time compilation avoids the pause times (reduces the startup/''warmup'' time) and gives more deterministic function call times. Both present in pure just-in-time compiled systems. ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, any API, feature or mechanism present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system). See "[[Remote_Access/en|Remote Access]]" documentation

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X". See above.

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. Every well behaving program will send error messages to stderr and regular output to stdout, making it possible to divert these to different destinations. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. Every well behaving program will send error messages to stderr and regular output to stdout, making it possible to divert these to different destinations. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "<code>{ expr1 . expr2 . ... exprN }</code>" or the expanded expression string "<code> e'...{expr}..'</code>" are syntactic sugar for Array-instantiation "<code>(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself</code>" or a call to the string expansion method. Btw: you don't have to understand this, to use expecco.

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. In addition to support searching and grouping, additional other behavior can be controlled by tags. For example, you can define an icon or color to be shown in the left project tree if the item has a particular tag. You can also use tags to control the execution, for filtering log entries or to control the generation of logs.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They can be created when suites are imported from an external tool, stored with the suite and passed back transparently to the tool, supporting round trip import/export without loosing information which expecco does not need. Tagged values can be attached to every element in the project tree or a diagram (i.e. actions, types, steps, pins etc.).
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment from Cincom, a US based company. Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T08:05:48Z

Cg: /* Stderr */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints and debugging with single stepping.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another.

== SFTP (Secure File Transfer) ==
A mechanism to transfer files via an encrypted and authenticated channel to another machine. Expecco includes a pure Smalltalk implementation which does not depend on any tools provided by the operating system (but of course, these could also be used). See "[[Remote_Access/en|Remote Access]]" documentation.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support. "''just-in-time''" means that code which is added dynamically at execution time will be compiled to machine code when that code is called for the first time; "''ahead-of-time''" means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called. Ahead of time compilation avoids the pause times (reduces the startup/''warmup'' time) and gives more deterministic function call times. Both present in pure just-in-time compiled systems. ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, any API, feature or mechanism present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system). See "[[Remote_Access/en|Remote Access]]" documentation

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X". See above.

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. Every well behaving program will send error messages to stderr and regular output to stdout, making it possible to divert these to different destinations. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "<code>{ expr1 . expr2 . ... exprN }</code>" or the expanded expression string "<code> e'...{expr}..'</code>" are syntactic sugar for Array-instantiation "<code>(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself</code>" or a call to the string expansion method. Btw: you don't have to understand this, to use expecco.

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. In addition to support searching and grouping, additional other behavior can be controlled by tags. For example, you can define an icon or color to be shown in the left project tree if the item has a particular tag. You can also use tags to control the execution, for filtering log entries or to control the generation of logs.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They can be created when suites are imported from an external tool, stored with the suite and passed back transparently to the tool, supporting round trip import/export without loosing information which expecco does not need. Tagged values can be attached to every element in the project tree or a diagram (i.e. actions, types, steps, pins etc.).
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment from Cincom, a US based company. Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T08:01:36Z

Cg: /* Tag */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints and debugging with single stepping.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another.

== SFTP (Secure File Transfer) ==
A mechanism to transfer files via an encrypted and authenticated channel to another machine. Expecco includes a pure Smalltalk implementation which does not depend on any tools provided by the operating system (but of course, these could also be used). See "[[Remote_Access/en|Remote Access]]" documentation.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support. "''just-in-time''" means that code which is added dynamically at execution time will be compiled to machine code when that code is called for the first time; "''ahead-of-time''" means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called. Ahead of time compilation avoids the pause times (reduces the startup/''warmup'' time) and gives more deterministic function call times. Both present in pure just-in-time compiled systems. ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, any API, feature or mechanism present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system). See "[[Remote_Access/en|Remote Access]]" documentation

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X". See above.

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "<code>{ expr1 . expr2 . ... exprN }</code>" or the expanded expression string "<code> e'...{expr}..'</code>" are syntactic sugar for Array-instantiation "<code>(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself</code>" or a call to the string expansion method. Btw: you don't have to understand this, to use expecco.

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. In addition to support searching and grouping, additional other behavior can be controlled by tags. For example, you can define an icon or color to be shown in the left project tree if the item has a particular tag. You can also use tags to control the execution, for filtering log entries or to control the generation of logs.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They can be created when suites are imported from an external tool, stored with the suite and passed back transparently to the tool, supporting round trip import/export without loosing information which expecco does not need. Tagged values can be attached to every element in the project tree or a diagram (i.e. actions, types, steps, pins etc.).
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment from Cincom, a US based company. Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T07:57:46Z

Cg: /* Tagged Value */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints and debugging with single stepping.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another.

== SFTP (Secure File Transfer) ==
A mechanism to transfer files via an encrypted and authenticated channel to another machine. Expecco includes a pure Smalltalk implementation which does not depend on any tools provided by the operating system (but of course, these could also be used). See "[[Remote_Access/en|Remote Access]]" documentation.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support. "''just-in-time''" means that code which is added dynamically at execution time will be compiled to machine code when that code is called for the first time; "''ahead-of-time''" means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called. Ahead of time compilation avoids the pause times (reduces the startup/''warmup'' time) and gives more deterministic function call times. Both present in pure just-in-time compiled systems. ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, any API, feature or mechanism present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system). See "[[Remote_Access/en|Remote Access]]" documentation

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X". See above.

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "<code>{ expr1 . expr2 . ... exprN }</code>" or the expanded expression string "<code> e'...{expr}..'</code>" are syntactic sugar for Array-instantiation "<code>(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself</code>" or a call to the string expansion method. Btw: you don't have to understand this, to use expecco.

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. For example, you can define an icon to be shown in the left project tree if the item has a particular tag.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They can be created when suites are imported from an external tool, stored with the suite and passed back transparently to the tool, supporting round trip import/export without loosing information which expecco does not need. Tagged values can be attached to every element in the project tree or a diagram (i.e. actions, types, steps, pins etc.).
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment from Cincom, a US based company. Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T07:54:16Z

Cg: /* Syntactic Sugar */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints and debugging with single stepping.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another.

== SFTP (Secure File Transfer) ==
A mechanism to transfer files via an encrypted and authenticated channel to another machine. Expecco includes a pure Smalltalk implementation which does not depend on any tools provided by the operating system (but of course, these could also be used). See "[[Remote_Access/en|Remote Access]]" documentation.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support. "''just-in-time''" means that code which is added dynamically at execution time will be compiled to machine code when that code is called for the first time; "''ahead-of-time''" means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called. Ahead of time compilation avoids the pause times (reduces the startup/''warmup'' time) and gives more deterministic function call times. Both present in pure just-in-time compiled systems. ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, any API, feature or mechanism present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system). See "[[Remote_Access/en|Remote Access]]" documentation

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X". See above.

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "<code>{ expr1 . expr2 . ... exprN }</code>" or the expanded expression string "<code> e'...{expr}..'</code>" are syntactic sugar for Array-instantiation "<code>(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself</code>" or a call to the string expansion method. Btw: you don't have to understand this, to use expecco.

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. For example, you can define an icon to be shown in the left project tree if the item has a particular tag.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They are created when suites are imported from some external tools, stored with the suite and passed back transparently to the tool.
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment from Cincom, a US based company. Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T07:49:54Z

Cg: /* ST/X */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints and debugging with single stepping.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another.

== SFTP (Secure File Transfer) ==
A mechanism to transfer files via an encrypted and authenticated channel to another machine. Expecco includes a pure Smalltalk implementation which does not depend on any tools provided by the operating system (but of course, these could also be used). See "[[Remote_Access/en|Remote Access]]" documentation.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support. "''just-in-time''" means that code which is added dynamically at execution time will be compiled to machine code when that code is called for the first time; "''ahead-of-time''" means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called. Ahead of time compilation avoids the pause times (reduces the startup/''warmup'' time) and gives more deterministic function call times. Both present in pure just-in-time compiled systems. ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, any API, feature or mechanism present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system). See "[[Remote_Access/en|Remote Access]]" documentation

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X". See above.

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "{ expr1 . expr2 . ... exprN }" is syntactic sugar for Array-instantiation "(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself" (btw: you don't have to understand this, to use expecco).

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. For example, you can define an icon to be shown in the left project tree if the item has a particular tag.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They are created when suites are imported from some external tools, stored with the suite and passed back transparently to the tool.
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment from Cincom, a US based company. Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T07:49:20Z

Cg: /* Smalltalk/X */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints and debugging with single stepping.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another.

== SFTP (Secure File Transfer) ==
A mechanism to transfer files via an encrypted and authenticated channel to another machine. Expecco includes a pure Smalltalk implementation which does not depend on any tools provided by the operating system (but of course, these could also be used). See "[[Remote_Access/en|Remote Access]]" documentation.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support. "''just-in-time''" means that code which is added dynamically at execution time will be compiled to machine code when that code is called for the first time; "''ahead-of-time''" means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called. Ahead of time compilation avoids the pause times (reduces the startup/''warmup'' time) and gives more deterministic function call times. Both present in pure just-in-time compiled systems. ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, any API, feature or mechanism present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system). See "[[Remote_Access/en|Remote Access]]" documentation

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X"

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "{ expr1 . expr2 . ... exprN }" is syntactic sugar for Array-instantiation "(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself" (btw: you don't have to understand this, to use expecco).

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. For example, you can define an icon to be shown in the left project tree if the item has a particular tag.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They are created when suites are imported from some external tools, stored with the suite and passed back transparently to the tool.
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment from Cincom, a US based company. Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T07:47:57Z

Cg: /* Smalltalk/X */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints and debugging with single stepping.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another.

== SFTP (Secure File Transfer) ==
A mechanism to transfer files via an encrypted and authenticated channel to another machine. Expecco includes a pure Smalltalk implementation which does not depend on any tools provided by the operating system (but of course, these could also be used). See "[[Remote_Access/en|Remote Access]]" documentation.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support. "just-in-time" means that code which is added dynamically at execution time will be compiled to machine code when that code is called for the first time; "ahead-of-time" means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called. Ahead of time compilation avoids the pause times (reduces the startup time) and gives more deterministic function call times. Both present in pure just-in-time compiled systems. ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, any API, feature or mechanism present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system). See "[[Remote_Access/en|Remote Access]]" documentation

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X"

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "{ expr1 . expr2 . ... exprN }" is syntactic sugar for Array-instantiation "(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself" (btw: you don't have to understand this, to use expecco).

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. For example, you can define an icon to be shown in the left project tree if the item has a particular tag.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They are created when suites are imported from some external tools, stored with the suite and passed back transparently to the tool.
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment from Cincom, a US based company. Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T07:47:03Z

Cg: /* Smalltalk/X */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints and debugging with single stepping.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another.

== SFTP (Secure File Transfer) ==
A mechanism to transfer files via an encrypted and authenticated channel to another machine. Expecco includes a pure Smalltalk implementation which does not depend on any tools provided by the operating system (but of course, these could also be used). See "[[Remote_Access/en|Remote Access]]" documentation.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support. "just-in-time" means that code which is added dynamically at execution time will be compiled to machine code when that code is called for the first time; "ahead-of-time" means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called. Ahead of time compilation avoids the pause times (reduces the startup time) and gives more deterministic function call times. Both being seen in pure just-in-time compiled systems. ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, any API, feature or mechanism present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system). See "[[Remote_Access/en|Remote Access]]" documentation

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X"

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "{ expr1 . expr2 . ... exprN }" is syntactic sugar for Array-instantiation "(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself" (btw: you don't have to understand this, to use expecco).

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. For example, you can define an icon to be shown in the left project tree if the item has a particular tag.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They are created when suites are imported from some external tools, stored with the suite and passed back transparently to the tool.
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment from Cincom, a US based company. Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T07:39:08Z

Cg: /* Shell/Batch Script Elementary Block */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints and debugging with single stepping.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another.

== SFTP (Secure File Transfer) ==
A mechanism to transfer files via an encrypted and authenticated channel to another machine. Expecco includes a pure Smalltalk implementation which does not depend on any tools provided by the operating system (but of course, these could also be used). See "[[Remote_Access/en|Remote Access]]" documentation.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support (ahead-of-time means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called). ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, APIS, features or mechanisms present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system). See "[[Remote_Access/en|Remote Access]]" documentation

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X"

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "{ expr1 . expr2 . ... exprN }" is syntactic sugar for Array-instantiation "(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself" (btw: you don't have to understand this, to use expecco).

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. For example, you can define an icon to be shown in the left project tree if the item has a particular tag.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They are created when suites are imported from some external tools, stored with the suite and passed back transparently to the tool.
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment from Cincom, a US based company. Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T07:36:08Z

Cg: /* SSH (Secure Shell) */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints and debugging with single stepping.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support (ahead-of-time means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called). ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, APIS, features or mechanisms present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system). See "[[Remote_Access/en|Remote Access]]" documentation

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X"

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "{ expr1 . expr2 . ... exprN }" is syntactic sugar for Array-instantiation "(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself" (btw: you don't have to understand this, to use expecco).

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. For example, you can define an icon to be shown in the left project tree if the item has a particular tag.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They are created when suites are imported from some external tools, stored with the suite and passed back transparently to the tool.
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment from Cincom, a US based company. Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T07:35:30Z

Cg: /* SSL (Secure Socket Layer) */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints and debugging with single stepping.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support (ahead-of-time means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called). ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, APIS, features or mechanisms present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system).

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system. See "[[Remote_Access/en|Remote Access]]" documentation.

== ST/X==
Short for "Smalltalk/X"

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "{ expr1 . expr2 . ... exprN }" is syntactic sugar for Array-instantiation "(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself" (btw: you don't have to understand this, to use expecco).

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. For example, you can define an icon to be shown in the left project tree if the item has a particular tag.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They are created when suites are imported from some external tools, stored with the suite and passed back transparently to the tool.
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment from Cincom, a US based company. Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T07:29:30Z

Cg: /* SSL (Secure Socket Layer) */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints and debugging with single stepping.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support (ahead-of-time means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called). ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, APIS, features or mechanisms present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSH (Secure Shell) ==
Remote access to another machine via an encrypted communiation channel (Secure Socket).
Typically used to login to a remote machine or to interact with a remote command line interpreter.
Expecco includes a pure Smalltalk implementation which does not depend on any extra features to be installed (but of course, you can also use any tools provided by the operating system).

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows and does not need any extra features provided by the operating system.

== ST/X==
Short for "Smalltalk/X"

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "{ expr1 . expr2 . ... exprN }" is syntactic sugar for Array-instantiation "(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself" (btw: you don't have to understand this, to use expecco).

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. For example, you can define an icon to be shown in the left project tree if the item has a particular tag.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They are created when suites are imported from some external tools, stored with the suite and passed back transparently to the tool.
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment from Cincom, a US based company. Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T07:25:34Z

Cg: /* Pin - Triggering Pin */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints and debugging with single stepping.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Project ==
This term is also occasionally used to refer to a test suite within this documentation and also appears in user interface. The reason is that expecco can also be used for pure automation purposes which are not specific tests. You can think of a test seuite being a project doing tests. Technically they are the same: a number of items packed together into a .ets file.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support (ahead-of-time means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called). ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, APIS, features or mechanisms present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows.

== ST/X==
Short for "Smalltalk/X"

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "{ expr1 . expr2 . ... exprN }" is syntactic sugar for Array-instantiation "(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself" (btw: you don't have to understand this, to use expecco).

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. For example, you can define an icon to be shown in the left project tree if the item has a particular tag.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They are created when suites are imported from some external tools, stored with the suite and passed back transparently to the tool.
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment from Cincom, a US based company. Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T07:20:48Z

Cg: /* Smalltalk/X */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints and debugging with single stepping.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support (ahead-of-time means that dlls with compiled machine code can be built, and Smalltalk code is already compiled to machine code when the application starts, as opposed to being dynamically compiled when first called). ST/X is the base on which expecco and expeccoALM / AIDYMO are built.
 Because if this, APIS, features or mechanisms present in ST/X will also be in expecco and may be called from elementary Smalltalk code.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows.

== ST/X==
Short for "Smalltalk/X"

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "{ expr1 . expr2 . ... exprN }" is syntactic sugar for Array-instantiation "(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself" (btw: you don't have to understand this, to use expecco).

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. For example, you can define an icon to be shown in the left project tree if the item has a particular tag.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They are created when suites are imported from some external tools, stored with the suite and passed back transparently to the tool.
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment from Cincom, a US based company. Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Glossary/en

2026-06-06T07:16:16Z

Cg: /* Stderr */

== Action, Step and Activity ==
In expecco, an "''Action Block''" (or "''Action''" or "''Block''" for short) refers to the definition of how an action is done. It is therefore also called occasionally "''Action Definition''". In the application, action definitions are found in a tree like organization at the left of the window.
Actions can be specified in multiple ways:
* as an activity diagram, with interconnected steps
* as a list of sequentially executed steps (either as keyword list action or in a test plan)
* as a piece of code in a programming language
* as a remote procedure call (service call)

Actions with an activity diagram are called "''Compound Actions''", and their elements are called "''Steps''".

Actions with a sequence list are called "''Keyword Actions''". Test plans are also a kind of sequence list, but provide additional control for execution (looping, skipping, selecting etc.). Although their elements are also technically steps, they are typically named "Test Steps", "Test Cases" or "Test Plan Items".
 All other actions are called "'Elementary Actions''".

A step is an action being placed (instantiated) in either an activity diagram or a sequence list.
Notice that the same action can be placed into multiple other compound actions, keyword actions or test plans. Thus, an action definition can be resused (possibly with different parameters) in multiple places.

When a step receives its required input values, it starts executing. For this, a so called "''Activity''" is created, which executes the step's action. Conceptionally, a thread (lightweight process) is created, which executes the step's action with the given parameters (1). Also notice, that multiple activities can be active in parallel, even executing the same step at the same time.

Notice that in the literature, the meaning of "Action", "Step" and "Activity" is often unclear, and the exact definition is often unclear.

See also: [[Tree Elements/en#Action_Blocks|Action Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

1) technically a thread pool is used, and a free one is chosen to execute it.

== Activity Log ==
Whenever expecco executes some action (block), all of its input and output values are recorded in an activity log.
In addition, explicit and implicit log-messages may be generated (implicit by the execution engine, explicit by calls to "logInfo", "logWarning" etc. or action steps). In addition, the start- and execution times are recorded.

== AIDYMO==
Central management system for Automation. Was previously known as expeccoALM.

== Black Box Test ==
In a [https://en.wikipedia.org/wiki/Black-box_testing "''Black Box Test''"], the test-machine and test-application are completely separated from the System Under Test (SUT). No knowledge about the internals (data structures, object model etc.) of the SUT is known when testing. The test only operates against official external interfaces, such as input/output, data and configuration files, command line interfaces, GUI interfaces or communication protocols.

The opposite being a [[#White Box Test|"White Box Test"]], which executes inside the SUT and has full access to all internal details (i.e. functions, data objects etc.).

Expecco supports both, "Black Box" by various libraries which provide interfaces to commonly used external interfaces, and "White Box" via code injection mechanisms, such as "Groovy", "Python" or "VisualBasic".

Mixed mode testing is called [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing" (wikipedia)].
 See also: [[#White Box Test|White Box Test]], [[#Gray Box Test|Gray Box Test]]

== Bridged Actions ==

Expecco uses "''bridges''" to implement action blocks written in different programming languages.
A bridge has two sides, one inside expecco, another inside the external scripting language interpreter, which typically communicate via a socket interprocess communication mechanism.
Whenever a bridged action block is to be executed, expecco packs the arguments and additional call information into a message and sends it over to the other bridge side. There, the function's code is executed and a result returned as message back to expecco.

The bridge remains alive, as long as expecco is alive, or the bridge connection is closed explicitly (by the testsuite or via a menu function).

All bridges support code injection, which means that action blocks can be edited inside expecco and are forwarded and installed automatically, when first called. This makes the handling of bridged actions almost transparent and identical to the way in which internal actions (Smalltalk and JavaScript) are handled. For some languages, expecco even includes a debugger with breakpoint-, single step and data inspection features.
Currently, bridges are provided for Java/Groovy, Node.js, DotNET/CLR, Python, remote Smalltalk and C/C++.

== [[CompoundBlock Element|Compound Action Block]] ==
An action block which is defined by an activity diagram. Its execution semantics are defined by a network of interconnected steps. These themselves can be compound- or elementary steps.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Compound Step]] ==
A step inside an activity diagram, whose action definition is a compound action block. When triggered, such a step will execute another activity diagram.
 See [[CompoundBlock Element/en|Compound Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== ".csf" File ==
"''Connection Settings Files''" are used by the [[Mobile Testing Plugin/en|Mobile Testing]] and [[Selenium WebDriver Plugin/en|Selenium WebDriver]] interfaces. The file is a text file contain lines with key-value pairs in the format:
key: value
each pair specifies an attribute or required capability of the connection.
Typically, these are generated via the [[Expecco GUI Tests Extension Reference/en|GUI browser's]] "''Connection''" dialog and kept as attachments inside the suite.

== ".csv" File ==
"''Comma Separated Values Files''" are files as generated by Excel and other Spreadsheet programs, by databases and many other record-oriented programs for data interchange. These files represent data records as textual (i.e. human readable) text lines, where the columns (fields) are usually separated by commas (although often semicolon is used as field separator). The very first line of a "csv" file contains the column names.
Expecco can read and write "csv" files, eg. for parameter sets or via action blocks. It is also possible to give a CSV file to the command line, to preset top-level environment variables from it.

== Dead Key ==
Prefix key used to enter diacritic characters (eg. Umlaut and accents). If enabled, the keyboard characters <">, <'>, <^> and <`> will be ''dead'' until a followup character is typed. Then a new character is composed (eg. <ä> from <"> and <a>).
If followed by a space or the dead key, the dead key is entered. If the combination is invalid, two characters will be entered. Thus, to enter the dead key character alone, press a space as second character (or press the dead key twice).
Because dead key processing can be inconvenient when entering program source code, they are disabled by default. This default can be changed in the settings dialog under "''Look and Feel''" - "''Keyboard Settings''". In addition, edit text windows provide a popup menu entry to enable/disable deadkey processing as a per editor. See also [https://en.wikipedia.org/wiki/Dead_key wikipedia].

== DLL (Dynamic Link Library) ==
Are dynamically loadable programs or libraries. In the Unix world, these are typically called "shared objects".
Expecco can call into such libraries using elementary DLL-call blocks. These should be used to call driver or utility functions inside a dll, especially if you do not have access to the function's source code or header definition files.
 
See more in [[ElementaryBlock_Element/en#DLL-Calls | Elementary Blocks - DLL Calls]].

== DUT (Device Under Test) ==
See [[#SUT_.28System_Under_Test.29 | System Under Test]] in this document.

== [[ElementaryBlock Element|Elementary Block]] ==
An non-compound action block. I.e. any action which is not defined by an activity diagram or keyword list, but either builtin (well known to expecco), a call to an external function or application, or defined programmatically as a piece of textual program code in one of the supported programming languages.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== [[DiagramElements-Step|Elementary Step]] ==
A step inside an activity diagram, whose action definition is an elementary block. When triggered, such a step will execute either a builtin function, an existing function inside a DLL, another program or a piece of code written in one of the programming languages supported by expecco.
 See [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Environment ==
Variables are bundled together in so called ''Environments'', which are technically collections of key-value pairs (Dictionary/HashTable). Environments can be attached to individual compound actions, to individual testcases, to a testplan and are also attached to the suite. There are also temporary environments attached to the current execution, the current browser window and the current expecco session.

During execution, environments are linked to form a parent-child hierarchy, and variables are fetched along this hierarchy. Thus, variables declared at the block level may shadow variables at the testplan-level, which may shadow variables declared in the current testsuite.
 Typically, the top-level suite's environment (so called "''ProjectEnvironment''") is used most of the time.

It should be noted, that command line shell variables are also held in a so called "environment". In this Wiki, this will be named "shell environment" to avoid confusion. However, it should be noted, that the expecco top-level environment will allow for the shell environment to be referenced (as "$(xxx)").

== Environment Freeze Value ==
A variable attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a value from an environment variable.

== ".elf" File ==

"<code>elf</code>" stands for "''Expecco Log File''" and is the native format in which result files are written. "<code>elf</code>" files contain all of the execution, trace and data-flow information and the original suite as executed. "<code>elf</code>"-files can be reloaded at any time into the expecco UI, values of that run be inspected and it is even possible to reexecute the original test. Also, any of the other reports can be regenerated, possibly with different report options (i.e. detail). Technically, "<code>elf</code>" files are zip-containers containing traces, logs and the original test suite in XML-format, and any attachments (screen shots, measurement data etc.) in whatever format they were written (images usually as PNG). They can be read and processed by third party tools (i.e. unzipped, and then processed with an XSL/XSLT ruleset to generate custom reports or to transport the result to any other XML-capable QM system).

== ".ets" File ==
"<code>ets</code>" stands for [[#TestSuite Element |"''Expecco Test Suite''"]]. These are technically zip-containers, containing the test suite in XML-format and any attachments in whatever format they where imported or generated. In addition, an index (manifest) is present, which allows for fast access to certain information without a need to read the whole zip archive. Also, signatures ensure that the manifest and remaining contents are in sync. Therefore, "<code>.ets</code>" files should not be manipulated manually, as the consistency of the suite may be harmed.

== expecco ==
Does the name "expecco" mean anything?
No, but it is a pun on the latin word "peccare"/"peccō" which means "to make a mistake", "an error" or "to sin". So ex-pecco is our answer to get rid of those.

== FMI (Functional Mockup Interface) ==
see FMU below

== FMU (Functional Mockup Units) ==
Functional Mockup Units are packaged simulation components, typically written in C (but not required to be), which can be loaded into a simulation framework. FMUs implement a standardized interface (FMI V2.0 / FMI V3.0) and are popular in areas of factory automation, automotive and robotics (see fmi-standard.org https://fmi-standard.org). Starting with release 23, Expecco supports loading, executing and interacting with FMU running both on the local or a remote host.

== Freeze Value ==
A fix (static) value attached to an action step's input pin. Instead of being provided via a connection from another output pin, this provides a constant value to an action step's input.
Notice that starting with expecco release 19.2, variable references can be embedded inside a String-Freeze-Value using the "<code>$(xxx)</code>" notation, where "''xxx''" is the name of a variable or input pin of the enclosing compound action. See also [[#Environment Freeze Value | Environment Freeze Value]] in this document.

== FTP (File Transfer Protocol) ==
A [https://datatracker.ietf.org/doc/html/rfc959 standardized protocol] to transfer files between machines.

== Functional ID (FID) ==
A UUID attached to every action block inside expecco. This identifier is assigned once and never changed again. Inside expecco, actions are referred to via their FID or Version ID, independent of their name. Actions with the same FID are considered to be (possibly different versions) of the same action.

== Gray Box Test ==
Some knowledge about internal interfaces of the System Under Test are known. For example, data structures or function entries inside the SUT are exploited and used. The categorization of a test as white- or gray box test is vague - there is often no clear line of separation between them.
 See also [[#Black Box Test|Black Box Test]], [[#White Box Test|White Box Test]], [https://en.wikipedia.org/wiki/Gray_box_testing "Gray Box Testing"] in Wikipedia.

== Groovy ==
A language interpreter which runs on top of a Java Virtual Machine (JVM), with a syntax very similar and almost compatible to Java. Used in expecco to call into Java interfaces or define required callback and listener classes, in case the SUT or the interface to the SUT require those.

Groovy code is compiled to bytecode inside the JVM, which is further Just-in-Time compiled to fast machine code within the target JVM. Thus, it can interface to any Java code (from jar or class files) and it executes at full Java speed.

Expecco allows for Groovy code to be executed both on the local machine (the one on which expecco itself is running) and on remote machines which are reachable via a TCP/IP connection. Multiple of these connections are possible and handled simultaneously in parallel, making it possible to interact with many hosts in a distributed system or when testing both ends of a communication protocol.
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== Groovy Elementary Block ==
An action block which is defined by an execute function which is written in the Groovy language. The block's code will be executed by a Groovy interpreter on a Java Virtual Machine (JVM). The JVM may run either on the local or on a remote machine. Expecco uses code injection techniques to implant the code into the SUT dynamically at run time. Except for sealed systems, it is normally not required to specially instrument or otherwise recompile the code in the SUT.
 You have to install "java" from the official website (due to legal reasons, we cannot provide a java interpreter with the expecco installer).
 See [[Expecco API/en#Groovy Elementary Blocks|"Groovy Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elemens'']] documentation.
== GUI (Graphical User Interface) ==
GUI tests and GUI automation refers to processes which control an/or verify an application which has a graphical user interface, such as a Windows, XWindow, Java, JavaSwing, JavaFX, VNC, QT etc. interface. This also includes mobile devices such as iPhone (IOS) and Android devices.

== GUID (Global Unique Identifier) ==
A synonym for [[#UUID (Universal Unique Identifier) | UUID]].

== Inconclusive State / Test Outcome ==
See [[#Verdict| "Verdict"]] in this document.
== IPC ==
Short for interprocess communication. Typically a socket, pipe or shared memory.

== IronPython Elementary Action Block ==
Bridged IronPython actions are supported by expecco. IronPython is a python interpreter which runs inside a DOTNET CLR (Common Language Runtime) environment, and has therefore full access to any .NET framework/assembly. It can be used if .NET interfaces are needed, both under native Windows and under Mono (linux/unix/osx).
 You have to install "IronPython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== JavaScript Elementary Action Block ==
An action block which is defined by an execute function which is written in a JavaScript like language. The block's code will be executed inside expecco itself (as opposed to Node-Action-Blocks, which are executed by an external interpreter).
 See [[Expecco API/en#JavaScript Elementary Blocks|"JavaScript Elementary Blocks"]] in the ''Expecco API Document'' and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements|''Tree Elements'']] documentation.

== JSON ==
JSON is a common format to exchange structured data, which originated in JavaScript but is now very common and supported by many applications and in almost any programming language. JSON can represent simple (non recursive) objects as textual (i.e. human readable) text, organized as a nested object hierarchy with key-value associations.
Expecco can read and write JSON both via calls from elementary code and by use of actions from the standard library.
 Because JSON is often used in many other apps, expecco also provides the JSON representation in its data inspector, for easy copy-paste.

== ".json" File ==
A file containing JSON encoded data. Often used for configuration data.
 Expecco can read and write "json" files, eg. for parameter sets or via action blocks. It is also possible to give a JSON file to the command line, to preset top-level environment variables from it.

== Jython Elementary Action Block ==
Bridged Jython actions are supported by expecco. Jython is a python interpreter which runs inside a JVM (Java Virtual Machine), and has therefore full access to any Java framework. It can be used as an alternative to Groovy, if Java interfaces are needed.
 You have to install "jython" from the official website.
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== Node Elementary Action Block ==
Node.js (or "''NodeJS''" or simply "''Node''") is a language interpreter for JavaScript, which is used in cloud computing, Alexa, IOT and other internet applications. Node is rapidly gaining interest and many packages are already available, covering a wide range of protocols, file formats and interfaces. Both bridged and scripted Node.js actions are supported, and expecco includes good support for bridged Node.js action blocks, including breakpoints and debugging with single stepping.
 You have to install "node" and "npm" from the official website: [https://nodejs.org/en/download/ https://nodejs.org/en/download].
 See [[Expecco API/en#Node.js_.28Bridged.29_Elementary_Blocks|"NodeJS Elementary Blocks"]] in the Expecco API document and [[ElementaryBlock Element/en|Elementary Block]] in the [[Tree Elements]] documentation.

== OCR (Optical Character Recognition) ==
Algorithm which (tries to) extract text from a bitmap image. Expecco can use OCR to extract data from screen- and other images,
and also to automate screen interaction if no higher level UI-interface can be used (see GUI Browser).
Both commercial and free OCR frameworks can be used and configured.
Currently a good choice is the free tesseract OCR framework (see [[Installing_additional_Frameworks/en#OCR_.28Optical_Character_Recognition.29 |Installation notes]] and [[Settings_ExternalToolsSettings/en#External_OCR_Tools_Settings | Configuration notes]].

== OPC-UA (Open Platform Communications Unified Architecture) ==
Is an industry standard for communication in factory automation and machine control.
See [https://opcfoundation.org/about/opc-technologies/opc-ua https://opcfoundation.org/about/opc-technologies/opc-ua/].

== Pin - Consuming Pin ==
An input pin of a step, which does consume its input value when the step starts to execute.
Technically, this takes the next input value from the queued values pending in the input-basket.
Consuming pins are used when an input pin gets its value from another step's output pin.

== Pin - Mailbox (or Telegram) Pin ==
An input pin of a step, which is delivered to an activity even when it is already executing. Normal pins take their value from an input basket associated with the input pin, and values which arrive after the start of the activity will be held in the basket (queued) for the next activation.
In contrast, mailbox pins do not enqueue their incoming values, but instead deliver them immediately to the activity - if it is already running. If the activity is not running, mailbox pins behave like regular unbuffered pins, being triggering or not (but typically, they are triggering). Mailbox baskets are typically used to cancel or break out of a loop, eg. in a service providing action block. I.e. they can be used to implement a cancel-pin function, where internal cleanup actions are still needed.

== Pin - Parameter Pin ==
An input pin of a step, which does not consume its input value and which does not trigger the step.
Used for constants and parameters, especially if the step is to be used in a loop.

== Pin - Triggering Pin ==
An input pin of a step, which triggers the execution of a step.
A step will only start to execute, when all of its triggering pins have received a value.

== Python Elementary Action Block ==
Both bridged and scripted Python actions are supported by expecco, and also both Python2.x and Python3.x can be used inside the same suite (in addition to Jython and IronPython).
 You have to install "python" and "pip" from the official website: [https://www.python.org/downloads https://www.python.org/downloads]. (see also [[Installing_additional_Frameworks/en#Python_Installation|Installing Additional Frameworks]])
 See [[Expecco_API/en#Bridged_Python_Elementary_Blocks|"Bridged Python Elementary Blocks"]] in the Expecco API document.

== R Script Action Block ==
R is a programming language which emphasizes on statistics, math and graph plotting.
 You have to install "r" from the official website (see [[Installing_additional_Frameworks/en#R_Installation|Installing Additional Frameworks]]).

== RPC (Remote Procedure Call) ==
A mechanism by which expecco calls into an external program, such as a Python, NodeJS or C program.
When a remote procedure call is performed, the name of the operation plus any arguments are packed into a message, transferred to the partner, executed there and finally any results packed again into an answer and transferred back to expecco. Thus there is some overhead and the execution is slower than if directly performed by expecco. Typically a no-operation round trip executes in the order of micro- or even milliseconds, whereas internal operations execute in the order of nano- or microseconds. I.e. roughly 1000 times faster. However, if the actual processing takes long compared to the transmission overhead, or if the partner has exclusive access to some device or software framework, a remote procedure call might be the only mechanism, by which a task can be accomplished.

== REST (Representational State Transfer) ==
REST is a remote procedure call mechanism based on JSON encoded packages which are typically (but not required to be) transmitted via HTTP. REST was created (probably) out of frustration of SOAP's complexity.

== Ruby Elementary Action Block ==
Both bridged and scripted Ruby actions are supported by expecco.
 You have to install "ruby" from the official website [https://rubyinstaller.org/downloads https://rubyinstaller.org/downloads].
 See [[Expecco_API/en#Bridged_Ruby_Elementary_Blocks|"Bridged Ruby Elementary Blocks"]] in the Expecco API document.

== Script Actions ==

Script actions are actions written in one of the supported scripting languages, including Shell, Batch, Powershell, Node.js, Python, Ruby, GnuPlot, R, TCL, Go and others.
In contrast to "''bridged actions''", these are called as host-commands, where a new interpreter is
started for every action invokation. This has the advantage, that any existing script can be
easily used/embedded into a testsuite, but the disadvantage that the action's execution is somewhat slowed down due to the startup/shutdown times of the external interpreter, and that no state (open files, connections, objects etc.) can be passed from one action to another.

== Shell/Batch Script Elementary Block ==
An action block which is defined by a shell (or batch) script which is written in a shell command-line-interpreter language. The block's code will be executed outside expecco, by a script interpreter.
See [[ElementaryBlock_Element#Shell Script Blocks|"ShellScript Elementary Blocks"]] in the expecco [[ElementaryBlock_Element | elementary block documentation]].

== Smalltalk Programming Language ==
A pure object oriented language, with sophisticated reflection and meta programming features. See [https://en.wikipedia.org/wiki/Smalltalk Smalltalk in Wikipedia]

== Smalltalk Elementary Block ==
An action block which is defined by an execute function which is written in the Smalltalk language. The block's code is usually executed inside expecco itself, but it is also possible to define bridged Smalltalk actions, which execute inside another Smalltalk process (local or remote).
See [[Expecco_API#Smalltalk_Elementary_Blocks|"Smalltalk Elementary Blocks"]] in the Expecco API Documentation.

== Smalltalk/X ==
[https://www.smalltalk-x.de Smalltalk/X] ("''ST/X''") is the brand name of a Smalltalk programming language environment from exept / Claus Gittinger. Smalltalk/X is an ANSI compatible [https://en.wikipedia.org/wiki/Smalltalk Smalltalk] implementation with some extensions and both just-in-time and ahead-of-time compilation support (ahead-of-time means that dlls with compiled machine code can be built). ST/X is the base on which expecco and expeccoALM/AIDYMO are built.

== SOAP (Simple Object Access Protocol) ==
SOAP is a remote procedure call mechanism based on XML encoded packages which are typically (but not required to be) transmitted via HTTP. The name is a euphemism: SOAP is not (no longer) simple: to be used with ease, a huge XML framework lies underneath, which extracts details for a call from a specification written in WSDL (which is also XML with a complex structure, incl. datatype definitions).

== SSDP (Simple Service Discovery Protocol) ==
Also known as UPnP, the SSDP protocol announces the availability of services via broadcast UDP packages. See [https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol Wikipedia SSDP].

== SSL (Secure Socket Layer)==
Encrypted and authenticated communication. Expecco includes a pure Smalltalk implementation which is safe from buffer overflows.

== ST/X==
Short for "Smalltalk/X"

== Stderr ==
Short for "Standard Error". This is any program's standard error output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stderr to the expecco Transcript (which is the expecco console). There, this will be prefixed by "2:" and colorized in red (to indicate that this is text from stderr, as opposed to stdout). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== Stdin ==
Short for "Standard Input". This is any program's standard input stream. If running in a console window, your typed input is available to the program via this stream. If running without a console window, the program will typically detect an End of File (EOF) condition when reading.
If expecco starts other programs, you have the option of providing input to the program; either on the very lowest programatic level or via an input pin in an action step.

== Stdout ==
Short for "Standard Output". This is any program's standard output stream. If running in a console window, this is typically displayed there. If running without a console window it may be lost or redirected into a logfile.
If expecco starts other programs, you have the option of redirecting their stdout to the expecco Transcript (which is the expecco console). There, this will be prefixed by "1:" and colorized in blue (to indicate that this is text from stdout, as opposed to stderr). The setting is found in "''Extras''" → "''Settings''" → "''Execution''" → "''Tracing''" → "''Show Stdout/Stderr in Transcript''".

== SUT (System Under Test) ==
The tested system.

Expecco interacts with this either in a pure [[#Black Box Test | Black Box]] fashion (i.e. only talking to external interfaces), or [[#Gray Box Test|Gray Box]] or [[#White Box Test|White Box]] fashion (some or a lot of knowledge about internals of the SUT are known).

Technically, Black Box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.

White Box tests can access data structures and interfaces internal to the SUT.

In expecco, White Box Tests are done by implanting code into the SUT. Depending on the type of technology and environment used, this code injection (or instrumentation) may be possible dynamically (Java, .NET, Python, Node.js) or has to be done statically by linking expecco-support libraries to the program (C, C++). Static binding is typically required for embedded devices, where the code is stored in non-writable memory.

Some companies (especially if hardware is involved) use the alternative term "DUT" (for "''Device under Test''") instead.

== Syntactic Sugar ==
A feature of (typically) a programming language, which does not give you more semantic features (aka "''functionality''"), but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "Groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively. In the Smalltalk programming language, the brace-construct "{ expr1 . expr2 . ... exprN }" is syntactic sugar for Array-instantiation "(Array new:sz) at:1 put:expr1; ... at:n put:exprN; yourself" (btw: you don't have to understand this, to use expecco).

== Tag ==
A token (word) attached to an element. Multiple tags can be attached and are used to search, group or otherwise mark tree items, steps and other elements of the test suite. For example, you can define an icon to be shown in the left project tree if the item has a particular tag.

== Tagged Value ==
A tuple consisting of a token plus value, and an optional type. Similar to tags, these can be attached to an element. Expecco does not use tagged values (*). They are created when suites are imported from some external tools, stored with the suite and passed back transparently to the tool.
 *) this may no longer be true, by the time of reading.

== Testplan Element ==
A "''Test Plan''" or "''Testplan''" is an item in the project tree, which contains a list of test case items to be executed in sequence. A test plan's items are called "''Test Cases''" and each is implemented by an action (elementary or compound). It is also possible to drag another test plan as item into a test plan, to combine multiple tests plans into master test plans. A suite may therefore contain multiple test plans. When started without user interaction, the test plan(s) to be executed can be chosen via the command line or via a remote service request.

== [[TestSuite Element | Testsuite Element]] ==
"''Test suite''" or occasionally "''Testsuite''" is the term used for a packaged test project. It contains a collection of [[Tree_Elements| Tree Elements]] like test plans, blocks and datatypes as well as optional resources, attachments and documentation.

Test suites can be imported into other test suites and can therefore be used as libraries for reuse. When a suite is imported into another suite, all of the imported elements are visible and usable inside the importing suite.

Typically, suites are organized in a hierarchical fashion, and low-level functions (device control and access, protocols, data format handling etc.) are packaged into separate libraries, which are used by higher level component test and support actions, which are then further reused by system-, acceptance or end-to-end test scenarios.

== Transcript ==
The "''Transcript Window''" is the expecco console window, which can be opened via "''Extras''" → "''Tools''" → "''Transcript''". If open, both information messages from expecco and explicit Transcript action messages will appear there. The standard library provides a number of action blocks eg. to send messages and to clear the transcript window. Messages can also be sent to it from elementary code (both internal and bridged). If not open, those messages will be sent to "stderr" instead.

== UI (User Interface) ==
Ususally a synonym for GUI (Graphical User Interface)

== UUID (Universal Unique Identifier) ==
An identifier (aka name) which is generated to be globally unique (with very very high probability, to be precise). These are generated and attached to elements of the suite (actions, types, etc.) to ensure that expecco will always be able to correctly identify if two elements from different suites (and/or different people) represent the same thing or not.
 Technically, they are generated by generating a big number, containing a microsecond timestamp, the network address and a big random number, so that two separately generated UUIDs are very very likely to be different. Internally, expecco uses these IDs to reference other elements, thus being tolerant against name changes, layout changes and structure changes (added pins, for example), etc. Also, expecco can quickly determine if two objects (suites, actions, steps, runs, etc.) represent the same object or not.

Be aware that expecco treats two projects (as loaded from an ETS file) as two versions of the same project iff they have the same functional ID (but different version IDs). Thus, simply saving a project under a different name does not create a new project, and the two cannot be imported both into another project.

== Verdict ==

The execution's summary-outcome-status from running a test plan, test case or action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always return one of 4 values as a summary status:
* '''PASSED''' (green) if all went well, and the execution did not encounter any problems
* '''FAIL''' (red) the execution detected an error in the [[#SUT (System Under Test)| System Under Test (SUT)]].
:For example, it measured a wrong/unexpected value, detected invalid behavior, invalid protocol behavior etc.
:Usually, this means that the developer of the tested system is to be informed.
* '''ERROR''' (dark red) the test itself ran into some error.
:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks. An ERROR state does not provide information about the SUT's state; instead, the test has a problem.
:For example, if a file containing test-data could not be found or a division by zero or an index out of bounds error occurred etc.
:Usually, this means that the developer of the test is to be informed.
* '''INCONCLUSIVE''' (gray) the test had no chance to perform its testing operation(s).
:For example, if a machine could not be reached in the network, if it was not powered up or if a resource (operator, measurement device, test-device etc.) was not available, etc. Also, tests or actions which have not been executed (eg. skipped) are marked as inconclusive.
:Usually, this means that the test manager is to be informed.

The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASSED state:
* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
* for an ERROR, the test-developer/analyst has to be informed to fix the problem in the test-case
* for INCONCLUSIVE, the test-manager, network administrator or test-lab-manager has to check for the availability of required devices , connections, power supply etc.
:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict.
 If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (e.g. when running under the control of Jenkins, QC, Polarion etc.)

If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

== VersionID (VID) ==
Every item within expecco (action, type, testcase, testplan, the suite itself etc.) has an associated unique identifier, which is guaranteed to be world-wide unique (a so called "''UUID''"). This guarantees, that these objects can be uniquely identified, even if renamed, or if the same name is used for an action, type etc. in two different test suites. Thus, two suites can always be merged and suites can always be imported without name conflicts.. expecco will internally always refer to any object by its ID, never by its name. The versionID is updated with every change made to an object. Thus it is guaranteed, that no two different objects have the same ID. And vice versa, that the equality (actually identity) can always be checked via the ID.

== VisualWorks ==
VisualWorks ("''VW''") is the brand name of a Smalltalk programming language environment from Cincom, a US based company. Starting with expecco 20.2, VisualWorks bridged blocks and VisualWorks GUI tests are supported by expecco.

== White Box Test ==
Designates a test which executes within the ''System Under Test'' and/or uses or refers to (but also depends on) the internals of the [[#SUT|SUT (System Under Test)]]. The test directly creates or manipulates data objects inside the SUT and/or calls internal functions. Most unit tests are typically implemented as white box tests (but not required to be so).

White Box Tests have both advantages and disadvantages.

*+ because they know the internals, more of internal details can be tested, and more of existing internal utilities can be used as utility in the test. For example, data definitions, data structures, functions and interfaces etc. can be accessed from the test system. Depending on the type of test and the available frameworks which can be "white-boxed", this may save a lot of test-development time, because those interfaces need not be reimplemented in the test system.

*- because they know the internals, they are also more reliant on them, and may also suffer from bugs in the internal frameworks. For one, if data structures and internal interfaces change, the white box test usually has to change with it. Whereas external interfaces usually remain more stable - especially if they are based on communication or data format standards. The other downside is that if internal interfaces of the SUT are heavily used, bugs in them are also injected into the test system. This may make some of the bugs invisible and undetectable to the test system. For example, if a communication data structure (say, a message or document format) is always accessed via a white-boxed SUT interface, but never actually tested physically, any bug in that framework will go unnoticed to both the SUT and to the test system. Both the SUT and the test system may see perfect data, while the data sent to the outside world may still be completely bogus.

In a real world test system, you would usually use a combination of whitebox and blackbox tests. The level of insider-knowledge of the whitebox test depends on the type of SUT, the risk analysis and trust in the frameworks being used.

It is common, that modules and components are first tested by the developers using Unit Tests (which are usually White Box Tests) and then passed on to integrators to check the interaction between modules using Black Box Tests.
But there is no sharp boundary and often a mix of both is needed in practice (aka "Grey Box Tests").

See also: [[#Black Box Test|Black Box Test]], [[#Gray Box Test|Gray Box Test]],
[https://en.wikipedia.org/wiki/White-box_testing "White-box_testing" (wikipedia) ]

== Workspace (or Notepad) ==

This is a [[Tools_Notepad/en | tool]] which is found in "''Extras''" → "''Tools''" → "''Notepad''". The name is a bit misleading and this should not be confused with the Windows "Notepad" application (therefore, it is also named "Workspace" in the documentation, although this again may lead to confusion, as "workspace" is often used with a different meaning in other contexts, such as the Eclipse IDE).

In expecco, a ''Workspace'' is a little text editor, which can also evaluate snippets written in either Smalltalk or JavaScript. It also provides a number of bulk string processing operations in its edit menu.

Whenever you have to manipulate text, a workspace is a useful edit-tool to perform such tasks (of course, you can use any other editor, if you prefer so, but startup times of external editors are often much longer, than the time it takes expecco to open its internal tools).

[[Tools_Notepad/en | Workspaces]] and all other editors in expecco (incl. the FileBrowser, Data Inspector and Elementary Action code editors) are all based on a common editor base class and have common behavior. Take a look at the popup menu to see what functionality is provided: beside the usual stuff, it can sort text, by columns, filter lines, transform lines and many more.

Especially useful are the "''Open FileBrowser''" and "''Open URL''" menu functions (found deeper down in the "''Tools''" submenu). Whenever you find a filename or URL in some text, these will quickly open the document for you.

= Abbreviations =

Commonly used abbreviations in this documentation Wiki are:

* ALM - Application Lifecycle Management
* B2B - Business to Business
* BD - (Action-) Block Description
* CB - Compound Block
* ".csf" - Connection Settings File (file suffix)
* ".csv" - Comma Separated Values File (file suffix)
* DCE - Distributed Computing Environment (an RPC mechanism)
* DLL - Dynamic Link Library (a synonym for "SO" = Shared Object); also a file suffix ".dll"
* DUT - Device Under Test
* EB - Elementary Block
* ".elf" - Expecco Log File (file suffix)
* ".ets" - Expecco Test Suite (file suffix)
* FID - Functional ID
* FTP - File Transfer Protocol (a standard internet protocol)
* GUI - Graphical User Interface; also sometimes simply "UI"
* HTTP - Hypertext Transfer Protocol (web page transfer protocol)
* QM - Quality Management
* RPC - Remote Procedure Call
* ".png" - a bitmap image file format (file suffix)
* SO - Shared Object (a synonym for DLL); also as file suffix ".so"
* SOAP - Simple Object Access Protocol (a not so simple protocol)
* SSDP - Simple Service Discovery Protocol
* SUT - System Under Test
* UI - User Interface (often actually meaning: Graphical-UI)
* URL - Unified Resource Locator (typically used with web-Browsers)
* UUID - Universal Unique Identifier
* VID - Version ID

Remote Access/en

2026-06-06T07:13:14Z

Cg: /* SSH and SFTP */

{{Languages|Remote Access/en|label=English}}

'''Remote access''' is the ability to drive a remote computer or
network from this expecco image — opening shells, running commands,
moving files, or driving a test target. Three protocol families are
supported, listed in current-recommended order:

* '''SSH and SFTP''' (recommended) — encrypted shell + secure file transfer over an SSH-2 tunnel. Pure-Smalltalk implementation in <code>exept:libcrypt/ssh</code>; no external dependency on OpenSSL or libssh. Use this for anything that touches credentials or sensitive payloads.
* '''Local Command Shell''' — fork + exec on the local machine. Used for local-tool integration and for the local end of a remote workflow that bridges via another protocol.
* '''Telnet''' (legacy) — plain-text terminal session. No encryption, passwords on the wire in clear. Use only when the target hardware has no other option.

= SSH and SFTP =

The SSH stack covers the full SSH-2 protocol (RFC 4251–4254,
RFC 5656, RFC 8709, RFC 8731) plus OpenSSH's chacha20-poly1305
transport cipher and the SFTP v3 file-transfer subsystem
(draft-ietf-secsh-filexfer-02). Two layers:

* '''<code>SSH::Client</code>''' — programmatic SSH access (remote <code>exec</code>, TTY shell, agent forwarding, ProxyJump bastion).
* '''<code>SSH::SftpFilename</code>''' — a <code>Filename</code> subclass that lets the rest of ST/X treat a remote SFTP path the same way it treats a local file.

The rest of this section is organised user-task-first: what the user
sees and does, the expecco-library hooks below that, then the
implementation detail at the end for the curious.

== From the FileBrowserV2 ==

Open the location dropdown and paste an <code>sftp://</code> URL.
The browser tab populates as if it were a local path. Tree
expansion, column sort (name / size / mtime), preview, and
double-click-to-open-in-editor all behave normally. The first
click on a host takes ~200–500 ms (TCP + KEX + auth); subsequent
clicks reuse the pooled connection.

URL syntax:

<pre>
sftp://[user@]host[:port]/remote/path
</pre>

User defaults to the local login name, port to 22, path to
<code>/</code>.

The '''Refresh''' button in the toolbar (the round-arrow icon
between ''Forward'' and ''DirectoryUp'') re-reads both the
directory tree and the contents pane on demand. Works uniformly
for local and SFTP paths; for SFTP it also flushes the per-file
STAT cache, so changes made directly on the remote side become
visible immediately rather than waiting for the 5-second cache TTL
to expire.

The small arrow next to the Refresh icon opens a dropdown with a
single checkbox, '''Automatic Refresh''', controlling the
background polling task that walks every expanded tree item to
detect external changes. The default depends on the current root:

* Local filesystem → '''on''' (10-second cycle, matches the long-standing behaviour).
* SFTP → '''off'''. Each cycle costs one STAT round-trip per child, which is fine for a handful of local directories but painful over the network. Click Refresh manually when you need to pick up remote changes.

When you navigate between local and SFTP roots the toggle flips
automatically — but only if you haven't overridden it for
the previous root. An explicit user choice is preserved across
navigations.

The Tools menu offers four browser actions, three of them gated on
the SSH library being loaded:

* '''Generate SSH Key Pair...''' — opens the same key-generation dialog described under [[#Generating an SSH key pair]] below.
* '''SSH Connect...''' — opens an interactive VT100 terminal to a remote host.
* '''SFTP Connect...''' — points this browser tab at a remote filesystem via SFTP.
* '''Filesystem Info...''' — shows size, free space and usage of the filesystem holding the currently displayed directory. Works uniformly for local paths and SFTP paths; for SFTP it requires the server to advertise the <code>statvfs@openssh.com</code> extension (every modern OpenSSH does). Sizes are reported in IEC binary units (MiB, GiB, TiB) — the largest unit yielding a value ≥ 1 is chosen, so a TB-scale volume reads as ''X TiB'' rather than ''10240 GiB''.

== From expecco actions ==

The Expecco RemoteAccess plugin
([[Expecco::RemoteAccessImportPlugin]]) exposes the following test
actions to the expecco action palette:

* '''CmdShell - Open SSH Remote Connection''' — opens an SSH session via the platform's <code>ssh</code> binary (PuTTY's
<code>plink</code> on Windows).
* '''CmdShell - Open SSH Remote Connection and PublicKey''' — same but with explicit public-key authentication.

To run these you need a configured keypair (private key on this
machine, public key in the remote host's
<code>~/.ssh/authorized_keys</code>). Generate one via the dialog
below or via <code>ssh-keygen</code>.

The plugin also adds a settings page at '''Extras → Settings →
Plugins → Remote Access — SSH Keys''' carrying a single
'''Generate SSH Key Pair...''' button that opens the same dialog.

== Generating an SSH key pair ==

=== The dialog (FileBrowserV2 / settings page) ===

The dialog asks for all parameters in one form:

* '''Comment''' — embedded in the generated key (defaults to
<code>stx@<hostname></code>).
* '''Storage''':
** ''Save to disk file only'' — writes <code>~/.ssh/id_ed25519_stx</code> (or wherever) plus a matching <code>.pub</code> companion.
** ''Save to disk AND load into ssh-agent'' — writes the file and also hands the key to the running ssh-agent.
** ''Load into ssh-agent only'' — key lives in agent memory only; gone on agent restart.
* '''Private key file''' — full path; disabled in agent-only mode.
* '''Passphrase / Confirm''' — empty leaves the on-disk file unencrypted (agent-only mode ignores the passphrase, since the OpenSSH agent wire protocol carries only the decrypted key).

On '''Generate''', the public-key line (the same
<code>ssh-ed25519 AAAA... comment</code> string ssh-keygen
emits) is copied to the system clipboard for pasting into the
remote host's <code>~/.ssh/authorized_keys</code>.

=== From a workspace ===

For headless deployments, sandboxed builds, or scripts,
<code>SSH::Client</code> exposes a pure-Smalltalk key generator
that produces output bit-compatible with
<code>ssh-keygen -t ed25519</code>:

<pre>
| seed comment priv |
seed := SSH::Client generateEd25519Seed.
comment := 'stx@', OperatingSystem getHostName.

"/ Save passphrase-encrypted to disk"
priv := (Filename homeDirectory / '.ssh' / 'id_ed25519_stx') pathName.
SSH::Client
saveOpenSshEd25519Seed:seed
toFile:priv
comment:comment
passphrase:'choose-something-long'.

"/ AND load into the running agent"
SSH::Client addEd25519SeedToAgent:seed comment:comment.

"/ Print the public-key line to paste into authorized_keys"
Transcript showCR:
(SSH::Client authorizedKeysLineForEd25519Seed:seed comment:comment).
</pre>

Keys generated this way are interoperable with OpenSSH's own
tooling (<code>ssh-keygen -y -f ...</code> re-derives the public
key, <code>ssh-keygen -p -f ...</code> changes the passphrase,
etc.).

=== Using the shell tools instead ===

The traditional path also works:

<pre>
ssh-keygen -t ed25519 -C "stx@your.host"
ssh-copy-id user@remotehost
ssh-add ~/.ssh/id_ed25519
</pre>

== Preparing ssh-agent ==

The agent path is strongly preferred over reading raw keyfiles: it
keeps encrypted private keys unlocked once per session, and handles
identities (hardware-token-backed keys, KeePassXC entries) that
ST/X should never see directly.

ST/X picks the agent path automatically when
<code>$SSH_AUTH_SOCK</code> is set in the process environment
'''at the time stx is launched'''. Setting it later from a
workspace does not help.

=== Linux / macOS ===

Most desktop distributions launch an agent automatically as part of
the session (gnome-keyring on GNOME, ssh-agent.service on systemd,
KWallet on KDE). Verify in a terminal:

<pre>
echo $SSH_AUTH_SOCK # /run/user/1000/keyring/ssh or similar
ssh-add -l # lists loaded identities
ssh-add ~/.ssh/id_ed25519 # load yours if not loaded
</pre>

If no agent runs at all, add this snippet to your shell rc:

<pre>
# ~/.bashrc or ~/.zshrc
if [ -z "$SSH_AUTH_SOCK" ]; then
eval "$(ssh-agent -s)" > /dev/null
fi
</pre>

ST/X must be launched from a shell that has seen this rc — a
desktop launcher started from the file manager does NOT inherit
the variable. Wrap the stx start command in a small script under
<code>~/.local/bin/</code> that sources the rc first.

The Remote Access settings page ('''Extras → Settings → Plugins
→ Remote Access — SSH Keys''') shows whether the running image
sees an agent.

==== Permanent setup via systemd ====

For a truly cross-session agent (survives desktop logouts, comes
up automatically at next login), enable the per-user systemd
unit shipped with most distros' <code>openssh-clients</code>
package:

<pre>
systemctl --user enable --now ssh-agent.service
</pre>

Then point <code>SSH_AUTH_SOCK</code> at the user-service socket
in your shell rc (this replaces the <code>eval $(ssh-agent -s)</code>
snippet above):

<pre>
export SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"
</pre>

==== Auto-loading keys on first use ====

To skip the manual <code>ssh-add</code> step, let OpenSSH load
keys into the agent automatically the first time they are needed.
Add to <code>~/.ssh/config</code>:

<pre>
Host *
AddKeysToAgent yes
IdentityFile ~/.ssh/id_ed25519
</pre>

The first SSH connection then prompts for the key passphrase
once and hands the unlocked key to the agent; subsequent
connections use the cached identity without prompting.

=== Windows ===

Windows 10+ ships native OpenSSH including an agent service.
One-time setup:

# Open '''Services''' (<code>services.msc</code>) as Administrator.
# Find '''OpenSSH Authentication Agent''', set Startup Type to '''Automatic''', click '''Start'''.
# In PowerShell: <code>ssh-add $HOME\.ssh\id_ed25519</code>.
# Verify: <code>ssh-add -l</code>.

The Windows OpenSSH agent listens on a named pipe
(<code>\\.\pipe\openssh-ssh-agent</code>), not a Unix socket. ST/X
supports both transports, but Windows ssh-add does '''not''' set
<code>SSH_AUTH_SOCK</code> for you. Add it manually:

# Press {{Key|Win}} → type "environment" → "Edit the system environment variables".
# '''Environment Variables''' → under '''User variables''', '''New'''.
# Name: <code>SSH_AUTH_SOCK</code>
# Value: <code>\\.\pipe\openssh-ssh-agent</code>
# Log out and back in (or restart stx) so the new env propagates.

==== PowerShell quick-setup ====

The same setup from an '''elevated''' PowerShell prompt, for
scripts or unattended provisioning:

<pre>
# Start the agent now AND on every reboot (permanent).
Set-Service -Name ssh-agent -StartupType Automatic
Start-Service ssh-agent

# Persist SSH_AUTH_SOCK for the user (survives reboots).
[Environment]::SetEnvironmentVariable(
'SSH_AUTH_SOCK',
'\\.\pipe\openssh-ssh-agent',
'User')

# Load a key (prompts for the passphrase if the file is encrypted).
ssh-add $HOME\.ssh\id_ed25519
</pre>

For a one-shot agent start without making it persistent (e.g.
single-session test), drop the <code>Set-Service</code> line and
just run <code>Start-Service ssh-agent</code>. The env-var line
can also be omitted if <code>SSH_AUTH_SOCK</code> is only needed
in the current shell — use <code>$env:SSH_AUTH_SOCK = '...'</code>
instead for that session-local form.

On stripped-down Windows installs the ssh-agent service may not
be present. Add it once via '''Settings → Apps → Optional
features → OpenSSH Client'''.

Alternative agents:

* '''PuTTY pageant''' — uses its own protocol; NOT supported by ST/X's SSH::Agent. Migrate the keys to OpenSSH.
* '''Git for Windows ssh-agent''' — works; point
<code>SSH_AUTH_SOCK</code> at the socket it publishes.
* '''WSL 2''' — a ST/X inside WSL sees WSL's Linux agent normally; a ST/X on the Windows side does not. Bridging needs a helper like <code>npiperelay</code> + <code>socat</code>.

Verify in the Remote Access settings page
('''Extras → Settings → Plugins → Remote Access — SSH Keys''') —
the agent indicator there reports whether the running image sees
the agent.

==== Auto-loading keys on first use ====

Windows OpenSSH does '''not''' persist agent-loaded keys across
agent restarts. To avoid running <code>ssh-add</code> manually
after each reboot, add the same lazy-load configuration to
<code>%USERPROFILE%\.ssh\config</code>:

<pre>
Host *
AddKeysToAgent yes
IdentityFile ~/.ssh/id_ed25519
</pre>

OpenSSH then loads the key into the agent on first use (prompts
for the passphrase once) and reuses it for the rest of the
session.

== Configuration ==

All tunables are class-side on <code>SSH::SftpFilename</code>:

{| class="wikitable"
! Accessor !! Default !! What it controls
|-
| <code>#idleEvictionSeconds:</code> || 240 (4 min) || How long a pooled
connection sits idle before the next access proactively closes +
reopens it. Just under typical sshd
<code>ClientAliveInterval × ClientAliveCountMax</code> so we recycle
before the server TCP-RESETs us. Pass <code>nil</code> to restore
the default.
|-
| <code>#attrsCacheTtlSeconds:</code> || 5 || Max age (s) of a
cached STAT before <code>#ensureAttrs</code> refetches. Parent
listDir always re-stamps fresh attrs onto children, so navigating
an open directory does not pay the TTL. Set to <code>0</code> to
disable caching.
|-
| <code>#closeAllConnections</code> || (action) || Tears down every
pooled connection. Useful after a known-bad network event, before
a deliberate identity swap, or as part of a clean image shutdown.
|}

== Diagnostics ==

=== SemaphoreMonitor ===

Open <code>SemaphoreMonitor</code> from the Launcher's "Status"
sub-menu. Per-host SFTP mutex appears as
<code>SFTP/<user@host:port></code>; the pool-wide mutex as
<code>SFTP/pool</code>. Right-click a row:

* '''Copy Waiters Stack to Clipboard''' — dumps the last-owner's walkback plus each waiter's, formatted as plain text. Use when a process is wedged in <code>readWait</code> inside
<code>withSftpClientDo:</code> and you need to see which SFTP
request it is on.
* '''Copy List to Clipboard''' — the whole table, for an email-this-to-someone diagnosis.
* '''Detect Deadlocks''' — DFS over the wait-for graph, reports cycles.

=== Logger ===

The SSH stack logs interesting events:

* <code>warning:</code> on auto-reconnect after a dead connection.
* <code>warning:</code> when a pool entry is idle-evicted.
* <code>warning:</code> when an SSH key file cannot be parsed (e.g. legacy PEM, encrypted-without-agent) — the file is skipped, others tried.

== Limitations ==

* '''SFTP v3 only.''' No SETSTAT (no remote chmod / chown / utime), no SSH_FXP_READLINK exposed (<code>#isSymbolicLink</code> always
<code>false</code>, <code>#linkInfo</code> returns the regular
stat info). Several SFTPv5+ niceties are nevertheless picked up
via OpenSSH SSH_FXP_EXTENDED requests — see
[[#OpenSSH SFTP extensions]] below.
* '''Per-host serialisation.''' Two concurrent operations on the same host queue through the host mutex. See [[#Future work]].
* '''<code>#renameTo:</code> fallback has a TOCTOU window.''' On servers that advertise <code>posix-rename@openssh.com</code> (every modern OpenSSH does), overwrite is atomic; on the rare server that does not, the receiver is emulated as delete-then-rename and another process can race in between.
* '''<code>#isNonEmptyDirectory</code> is heuristic.''' Always returns <code>#isDirectory</code> (the accurate answer would cost three round-trips per directory icon, which made the original tree expansion unbearably slow).

== Implementation details ==

For readers wanting the architecture. Five classes, top-down:

{| class="wikitable"
! Class !! Role
|-
| <code>SSH::SftpFilename</code> || Filename subclass; the public
API. Maps <code>sftp://...</code> URLs to remote files; exposes
<code>directoryContents</code>, <code>readingFileDo:</code>,
<code>renameTo:</code> etc.
|-
| <code>SSH::SftpClient</code> || SFTP-v3 protocol
(request/response codec, listDir, stat, open, read, write, mkdir).
Driven by SftpFilename.
|-
| <code>SSH::Channel</code> || SSH channel multiplexer
(CHANNEL_OPEN, DATA, EOF, CLOSE, WINDOW_ADJUST). One logical
session per Channel instance.
|-
| <code>SSH::Client</code> || High-level SSH client: opens the
transport, runs KEX, host-key check, userauth, then dispenses
Channels.
|-
| <code>SSH::Transport</code> || Wire layer. Banner + KEXINIT
exchange, ChaCha20-Poly1305 packet framing, sendSeq / recvSeq,
heartbeat, SSH_MSG_DISCONNECT.
|}

=== OpenSSH SFTP extensions ===

SFTP v3 (RFC draft-ietf-secsh-filexfer-02) is intentionally minimal.
OpenSSH ships an open-ended extension mechanism: the server lists
extension names it understands in its <code>SSH_FXP_VERSION</code>
reply, and the client invokes them via
<code>SSH_FXP_EXTENDED(200)</code> packets carrying the extension
name as the first string. Each extension is feature-detected via
<code>SSH::SftpClient>>supportsExtension:</code>; callers fall
back when the server doesn't advertise it.

The stack uses four of the OpenSSH extensions today:

* <code>posix-rename@openssh.com</code> — atomic rename-with-overwrite. Picked up automatically by
<code>SftpFilename>>renameTo:</code>; the delete-then-rename
fallback only fires on servers that lack it.
* <code>hardlink@openssh.com</code> — create a POSIX hard link. Exposed as <code>SftpFilename>>createHardLinkAs:</code>.
* <code>statvfs@openssh.com</code> — POSIX
<code>statvfs(3)</code>-shape filesystem stats. Exposed as
<code>SftpFilename>>fileSystemInfo</code>; the result is
shape-compatible with <code>OperatingSystem getDiskInfoOf:</code>
so callers can treat local and remote uniformly. Drives the
'''Tools → Filesystem Info...''' menu entry described at the
top of this page.
* <code>fsync@openssh.com</code> — flush server-side write buffer to disk on an open handle. Available on the low-level
<code>SftpClient>>fsyncHandle:</code>; not yet plumbed
into a Filename-level "durable write" API.

The remaining OpenSSH extensions
(<code>lsetstat@openssh.com</code>, <code>fstatvfs@openssh.com</code>)
are recognised in the advertised-extensions list but not wrapped at
Filename level — there's no Filename-side caller for them yet.

=== Connection pooling ===

Every <code>SftpFilename</code> instance pointing at the same
<code>user@host:port</code> triple shares one
<code>SSH::Client</code> plus one <code>SSH::SftpClient</code>.
Pool is class-side, guarded by a single
<code>ConnectionPoolMutex</code>:

* '''Lazy bring-up''' — TCP + KEX + userauth + SFTP INIT happens on the first SFTP operation, not on <code>forUrl:</code>.
* '''Per-host serialisation''' — SFTP requests on a given host are serialised through a <code>RecursionLock</code> named
<code>SFTP/<user@host:port></code> (visible in
SemaphoreMonitor).
* '''Idle eviction''' — unused for longer than
<code>idleEvictionSeconds</code>, the entry is proactively
closed + reopened on the next access.
* '''Auto-reconnect''' — a transport-level failure (broken pipe, EOF, MNU on nil socket) evicts the dead pool entry, opens a fresh client, retries the request '''once'''. Application-level SFTP STATUS errors propagate immediately.

== Future work ==

Tracked but not yet implemented:

* '''Multi-channel parallelism per host''' — today one TCP + one SFTP channel per host means N concurrent requests serialise. Pipelining over multiple SshClients in the pool (preferred), or a transport-level reader process demultiplexing to per-channel inboxes, would let the tree pane keep listing while the content pane reads a large file.
* '''Accurate <code>#isNonEmptyDirectory</code>''' via OPEN_DIR + READ_DIR (first batch only) + CLOSE — three RTTs per probe; needs SftpClient to pipeline requests before this pays off.
* '''SFTP v5/v6 negotiation''' for extended attrs and FTP-style canonicalisation. (Atomic-overwrite rename is already handled via the OpenSSH <code>posix-rename@openssh.com</code> extension; see [[#OpenSSH SFTP extensions]].)

= Command Shell =

Local command shell on this expecco machine. Typical applications:
local command-line, running a local helper tool, bridging a
remote workflow to a local utility.

The Expecco RemoteAccess plugin exposes:

* '''CmdShell - Open'''
* '''CmdShell - Close'''

No credentials, no network — runs as the expecco process's own
user. Output streams to expecco's log.

= Telnet =

[[File:Warning.svg|24px|Warning]] '''Telnet is a legacy protocol
with no encryption.''' Passwords are transmitted in plain text on
the wire; anyone on the network path can read them. Use Telnet
ONLY when the target device has no other option (typically: old
industrial controllers, lab instruments, embedded measurement
equipment without an SSH stack). For everything else use
[[#SSH and SFTP]].

The expecco plugin exposes:

* '''Telnet - Open Remote Connection With Login'''
* '''Telnet - Execute Remote Command'''
* '''Example - Remote Device Control via Telnet''' (internal demo)

The Telnet protocol (RFC 854) is a bidirectional 8-bit byte stream
over TCP, with in-band control sequences for terminal options.
A connection is established to a target host:port; after optional
in-band login, both sides can send data.

= See also =

* [[SSH Client/en|SSH::Client]] — the SSH layer (exec, TTY, agent forwarding, ProxyJump).
* [[FileBrowserV2/en|FileBrowserV2]] — the main UI client of this stack.
* [[ClaudeCode plugin/en|Claude Code]] — uses the same SSH stack for its HTTPS transport.
* [[Wikipedia:Secure Shell|RFC 4251 (SSH-2 Architecture)]]
* [[Wikipedia:Telnet|RFC 854 (Telnet Protocol)]]

[[Category:Plugins]]
[[Category:Network]]
[[Category:SSH]]

Remote Access/en

2026-06-06T07:06:17Z

Cg: /* SSH and SFTP */

{{Languages|Remote Access/en|label=English}}

'''Remote access''' is the ability to drive a remote computer or
network from this expecco image — opening shells, running commands,
moving files, or driving a test target. Three protocol families are
supported, listed in current-recommended order:

* '''SSH and SFTP''' (recommended) — encrypted shell + secure file transfer over an SSH-2 tunnel. Pure-Smalltalk implementation in <code>exept:libcrypt/ssh</code>; no external dependency on OpenSSL or libssh. Use this for anything that touches credentials or sensitive payloads.
* '''Local Command Shell''' — fork + exec on the local machine. Used for local-tool integration and for the local end of a remote workflow that bridges via another protocol.
* '''Telnet''' (legacy) — plain-text terminal session. No encryption, passwords on the wire in clear. Use only when the target hardware has no other option.

= SSH and SFTP =

The SSH stack covers the full SSH-2 protocol (RFC 4251–4254,
RFC 5656, RFC 8709, RFC 8731) plus OpenSSH's chacha20-poly1305
transport cipher and the SFTP v3 file-transfer subsystem
(draft-ietf-secsh-filexfer-02). Two layers:

* '''<code>SSH::Client</code>''' — programmatic SSH access (remote
<code>exec</code>, TTY shell, agent forwarding, ProxyJump bastion).
* '''<code>SSH::SftpFilename</code>''' — a <code>Filename</code> subclass that lets the rest of ST/X treat a remote SFTP path the same way it treats a local file.

The rest of this section is organised user-task-first: what the user
sees and does, the expecco-library hooks below that, then the
implementation detail at the end for the curious.

== From the FileBrowserV2 ==

Open the location dropdown and paste an <code>sftp://</code> URL.
The browser tab populates as if it were a local path. Tree
expansion, column sort (name / size / mtime), preview, and
double-click-to-open-in-editor all behave normally. The first
click on a host takes ~200–500 ms (TCP + KEX + auth); subsequent
clicks reuse the pooled connection.

URL syntax:

<pre>
sftp://[user@]host[:port]/remote/path
</pre>

User defaults to the local login name, port to 22, path to
<code>/</code>.

The '''Refresh''' button in the toolbar (the round-arrow icon
between ''Forward'' and ''DirectoryUp'') re-reads both the
directory tree and the contents pane on demand. Works uniformly
for local and SFTP paths; for SFTP it also flushes the per-file
STAT cache, so changes made directly on the remote side become
visible immediately rather than waiting for the 5-second cache TTL
to expire.

The small arrow next to the Refresh icon opens a dropdown with a
single checkbox, '''Automatic Refresh''', controlling the
background polling task that walks every expanded tree item to
detect external changes. The default depends on the current root:

* Local filesystem → '''on''' (10-second cycle, matches the long-standing behaviour).
* SFTP → '''off'''. Each cycle costs one STAT round-trip per child, which is fine for a handful of local directories but painful over the network. Click Refresh manually when you need to pick up remote changes.

When you navigate between local and SFTP roots the toggle flips
automatically — but only if you haven't overridden it for
the previous root. An explicit user choice is preserved across
navigations.

The Tools menu offers four browser actions, three of them gated on
the SSH library being loaded:

* '''Generate SSH Key Pair...''' — opens the same key-generation dialog described under [[#Generating an SSH key pair]] below.
* '''SSH Connect...''' — opens an interactive VT100 terminal to a remote host.
* '''SFTP Connect...''' — points this browser tab at a remote filesystem via SFTP.
* '''Filesystem Info...''' — shows size, free space and usage of the filesystem holding the currently displayed directory. Works uniformly for local paths and SFTP paths; for SFTP it requires the server to advertise the <code>statvfs@openssh.com</code> extension (every modern OpenSSH does). Sizes are reported in IEC binary units (MiB, GiB, TiB) — the largest unit yielding a value ≥ 1 is chosen, so a TB-scale volume reads as ''X TiB'' rather than ''10240 GiB''.

== From expecco actions ==

The Expecco RemoteAccess plugin
([[Expecco::RemoteAccessImportPlugin]]) exposes the following test
actions to the expecco action palette:

* '''CmdShell - Open SSH Remote Connection''' — opens an SSH session via the platform's <code>ssh</code> binary (PuTTY's
<code>plink</code> on Windows).
* '''CmdShell - Open SSH Remote Connection and PublicKey''' — same but with explicit public-key authentication.

To run these you need a configured keypair (private key on this
machine, public key in the remote host's
<code>~/.ssh/authorized_keys</code>). Generate one via the dialog
below or via <code>ssh-keygen</code>.

The plugin also adds a settings page at '''Extras → Settings →
Plugins → Remote Access — SSH Keys''' carrying a single
'''Generate SSH Key Pair...''' button that opens the same dialog.

== Generating an SSH key pair ==

=== The dialog (FileBrowserV2 / settings page) ===

The dialog asks for all parameters in one form:

* '''Comment''' — embedded in the generated key (defaults to
<code>stx@<hostname></code>).
* '''Storage''':
** ''Save to disk file only'' — writes <code>~/.ssh/id_ed25519_stx</code> (or wherever) plus a matching <code>.pub</code> companion.
** ''Save to disk AND load into ssh-agent'' — writes the file and also hands the key to the running ssh-agent.
** ''Load into ssh-agent only'' — key lives in agent memory only; gone on agent restart.
* '''Private key file''' — full path; disabled in agent-only mode.
* '''Passphrase / Confirm''' — empty leaves the on-disk file unencrypted (agent-only mode ignores the passphrase, since the OpenSSH agent wire protocol carries only the decrypted key).

On '''Generate''', the public-key line (the same
<code>ssh-ed25519 AAAA... comment</code> string ssh-keygen
emits) is copied to the system clipboard for pasting into the
remote host's <code>~/.ssh/authorized_keys</code>.

=== From a workspace ===

For headless deployments, sandboxed builds, or scripts,
<code>SSH::Client</code> exposes a pure-Smalltalk key generator
that produces output bit-compatible with
<code>ssh-keygen -t ed25519</code>:

<pre>
| seed comment priv |
seed := SSH::Client generateEd25519Seed.
comment := 'stx@', OperatingSystem getHostName.

"/ Save passphrase-encrypted to disk"
priv := (Filename homeDirectory / '.ssh' / 'id_ed25519_stx') pathName.
SSH::Client
saveOpenSshEd25519Seed:seed
toFile:priv
comment:comment
passphrase:'choose-something-long'.

"/ AND load into the running agent"
SSH::Client addEd25519SeedToAgent:seed comment:comment.

"/ Print the public-key line to paste into authorized_keys"
Transcript showCR:
(SSH::Client authorizedKeysLineForEd25519Seed:seed comment:comment).
</pre>

Keys generated this way are interoperable with OpenSSH's own
tooling (<code>ssh-keygen -y -f ...</code> re-derives the public
key, <code>ssh-keygen -p -f ...</code> changes the passphrase,
etc.).

=== Using the shell tools instead ===

The traditional path also works:

<pre>
ssh-keygen -t ed25519 -C "stx@your.host"
ssh-copy-id user@remotehost
ssh-add ~/.ssh/id_ed25519
</pre>

== Preparing ssh-agent ==

The agent path is strongly preferred over reading raw keyfiles: it
keeps encrypted private keys unlocked once per session, and handles
identities (hardware-token-backed keys, KeePassXC entries) that
ST/X should never see directly.

ST/X picks the agent path automatically when
<code>$SSH_AUTH_SOCK</code> is set in the process environment
'''at the time stx is launched'''. Setting it later from a
workspace does not help.

=== Linux / macOS ===

Most desktop distributions launch an agent automatically as part of
the session (gnome-keyring on GNOME, ssh-agent.service on systemd,
KWallet on KDE). Verify in a terminal:

<pre>
echo $SSH_AUTH_SOCK # /run/user/1000/keyring/ssh or similar
ssh-add -l # lists loaded identities
ssh-add ~/.ssh/id_ed25519 # load yours if not loaded
</pre>

If no agent runs at all, add this snippet to your shell rc:

<pre>
# ~/.bashrc or ~/.zshrc
if [ -z "$SSH_AUTH_SOCK" ]; then
eval "$(ssh-agent -s)" > /dev/null
fi
</pre>

ST/X must be launched from a shell that has seen this rc — a
desktop launcher started from the file manager does NOT inherit
the variable. Wrap the stx start command in a small script under
<code>~/.local/bin/</code> that sources the rc first.

The Remote Access settings page ('''Extras → Settings → Plugins
→ Remote Access — SSH Keys''') shows whether the running image
sees an agent.

==== Permanent setup via systemd ====

For a truly cross-session agent (survives desktop logouts, comes
up automatically at next login), enable the per-user systemd
unit shipped with most distros' <code>openssh-clients</code>
package:

<pre>
systemctl --user enable --now ssh-agent.service
</pre>

Then point <code>SSH_AUTH_SOCK</code> at the user-service socket
in your shell rc (this replaces the <code>eval $(ssh-agent -s)</code>
snippet above):

<pre>
export SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"
</pre>

==== Auto-loading keys on first use ====

To skip the manual <code>ssh-add</code> step, let OpenSSH load
keys into the agent automatically the first time they are needed.
Add to <code>~/.ssh/config</code>:

<pre>
Host *
AddKeysToAgent yes
IdentityFile ~/.ssh/id_ed25519
</pre>

The first SSH connection then prompts for the key passphrase
once and hands the unlocked key to the agent; subsequent
connections use the cached identity without prompting.

=== Windows ===

Windows 10+ ships native OpenSSH including an agent service.
One-time setup:

# Open '''Services''' (<code>services.msc</code>) as Administrator.
# Find '''OpenSSH Authentication Agent''', set Startup Type to '''Automatic''', click '''Start'''.
# In PowerShell: <code>ssh-add $HOME\.ssh\id_ed25519</code>.
# Verify: <code>ssh-add -l</code>.

The Windows OpenSSH agent listens on a named pipe
(<code>\\.\pipe\openssh-ssh-agent</code>), not a Unix socket. ST/X
supports both transports, but Windows ssh-add does '''not''' set
<code>SSH_AUTH_SOCK</code> for you. Add it manually:

# Press {{Key|Win}} → type "environment" → "Edit the system environment variables".
# '''Environment Variables''' → under '''User variables''', '''New'''.
# Name: <code>SSH_AUTH_SOCK</code>
# Value: <code>\\.\pipe\openssh-ssh-agent</code>
# Log out and back in (or restart stx) so the new env propagates.

==== PowerShell quick-setup ====

The same setup from an '''elevated''' PowerShell prompt, for
scripts or unattended provisioning:

<pre>
# Start the agent now AND on every reboot (permanent).
Set-Service -Name ssh-agent -StartupType Automatic
Start-Service ssh-agent

# Persist SSH_AUTH_SOCK for the user (survives reboots).
[Environment]::SetEnvironmentVariable(
'SSH_AUTH_SOCK',
'\\.\pipe\openssh-ssh-agent',
'User')

# Load a key (prompts for the passphrase if the file is encrypted).
ssh-add $HOME\.ssh\id_ed25519
</pre>

For a one-shot agent start without making it persistent (e.g.
single-session test), drop the <code>Set-Service</code> line and
just run <code>Start-Service ssh-agent</code>. The env-var line
can also be omitted if <code>SSH_AUTH_SOCK</code> is only needed
in the current shell — use <code>$env:SSH_AUTH_SOCK = '...'</code>
instead for that session-local form.

On stripped-down Windows installs the ssh-agent service may not
be present. Add it once via '''Settings → Apps → Optional
features → OpenSSH Client'''.

Alternative agents:

* '''PuTTY pageant''' — uses its own protocol; NOT supported by ST/X's SSH::Agent. Migrate the keys to OpenSSH.
* '''Git for Windows ssh-agent''' — works; point
<code>SSH_AUTH_SOCK</code> at the socket it publishes.
* '''WSL 2''' — a ST/X inside WSL sees WSL's Linux agent normally; a ST/X on the Windows side does not. Bridging needs a helper like <code>npiperelay</code> + <code>socat</code>.

Verify in the Remote Access settings page
('''Extras → Settings → Plugins → Remote Access — SSH Keys''') —
the agent indicator there reports whether the running image sees
the agent.

==== Auto-loading keys on first use ====

Windows OpenSSH does '''not''' persist agent-loaded keys across
agent restarts. To avoid running <code>ssh-add</code> manually
after each reboot, add the same lazy-load configuration to
<code>%USERPROFILE%\.ssh\config</code>:

<pre>
Host *
AddKeysToAgent yes
IdentityFile ~/.ssh/id_ed25519
</pre>

OpenSSH then loads the key into the agent on first use (prompts
for the passphrase once) and reuses it for the rest of the
session.

== Configuration ==

All tunables are class-side on <code>SSH::SftpFilename</code>:

{| class="wikitable"
! Accessor !! Default !! What it controls
|-
| <code>#idleEvictionSeconds:</code> || 240 (4 min) || How long a pooled
connection sits idle before the next access proactively closes +
reopens it. Just under typical sshd
<code>ClientAliveInterval × ClientAliveCountMax</code> so we recycle
before the server TCP-RESETs us. Pass <code>nil</code> to restore
the default.
|-
| <code>#attrsCacheTtlSeconds:</code> || 5 || Max age (s) of a
cached STAT before <code>#ensureAttrs</code> refetches. Parent
listDir always re-stamps fresh attrs onto children, so navigating
an open directory does not pay the TTL. Set to <code>0</code> to
disable caching.
|-
| <code>#closeAllConnections</code> || (action) || Tears down every
pooled connection. Useful after a known-bad network event, before
a deliberate identity swap, or as part of a clean image shutdown.
|}

== Diagnostics ==

=== SemaphoreMonitor ===

Open <code>SemaphoreMonitor</code> from the Launcher's "Status"
sub-menu. Per-host SFTP mutex appears as
<code>SFTP/<user@host:port></code>; the pool-wide mutex as
<code>SFTP/pool</code>. Right-click a row:

* '''Copy Waiters Stack to Clipboard''' — dumps the last-owner's walkback plus each waiter's, formatted as plain text. Use when a process is wedged in <code>readWait</code> inside
<code>withSftpClientDo:</code> and you need to see which SFTP
request it is on.
* '''Copy List to Clipboard''' — the whole table, for an email-this-to-someone diagnosis.
* '''Detect Deadlocks''' — DFS over the wait-for graph, reports cycles.

=== Logger ===

The SSH stack logs interesting events:

* <code>warning:</code> on auto-reconnect after a dead connection.
* <code>warning:</code> when a pool entry is idle-evicted.
* <code>warning:</code> when an SSH key file cannot be parsed (e.g. legacy PEM, encrypted-without-agent) — the file is skipped, others tried.

== Limitations ==

* '''SFTP v3 only.''' No SETSTAT (no remote chmod / chown / utime), no SSH_FXP_READLINK exposed (<code>#isSymbolicLink</code> always
<code>false</code>, <code>#linkInfo</code> returns the regular
stat info). Several SFTPv5+ niceties are nevertheless picked up
via OpenSSH SSH_FXP_EXTENDED requests — see
[[#OpenSSH SFTP extensions]] below.
* '''Per-host serialisation.''' Two concurrent operations on the same host queue through the host mutex. See [[#Future work]].
* '''<code>#renameTo:</code> fallback has a TOCTOU window.''' On servers that advertise <code>posix-rename@openssh.com</code> (every modern OpenSSH does), overwrite is atomic; on the rare server that does not, the receiver is emulated as delete-then-rename and another process can race in between.
* '''<code>#isNonEmptyDirectory</code> is heuristic.''' Always returns <code>#isDirectory</code> (the accurate answer would cost three round-trips per directory icon, which made the original tree expansion unbearably slow).

== Implementation details ==

For readers wanting the architecture. Five classes, top-down:

{| class="wikitable"
! Class !! Role
|-
| <code>SSH::SftpFilename</code> || Filename subclass; the public
API. Maps <code>sftp://...</code> URLs to remote files; exposes
<code>directoryContents</code>, <code>readingFileDo:</code>,
<code>renameTo:</code> etc.
|-
| <code>SSH::SftpClient</code> || SFTP-v3 protocol
(request/response codec, listDir, stat, open, read, write, mkdir).
Driven by SftpFilename.
|-
| <code>SSH::Channel</code> || SSH channel multiplexer
(CHANNEL_OPEN, DATA, EOF, CLOSE, WINDOW_ADJUST). One logical
session per Channel instance.
|-
| <code>SSH::Client</code> || High-level SSH client: opens the
transport, runs KEX, host-key check, userauth, then dispenses
Channels.
|-
| <code>SSH::Transport</code> || Wire layer. Banner + KEXINIT
exchange, ChaCha20-Poly1305 packet framing, sendSeq / recvSeq,
heartbeat, SSH_MSG_DISCONNECT.
|}

=== OpenSSH SFTP extensions ===

SFTP v3 (RFC draft-ietf-secsh-filexfer-02) is intentionally minimal.
OpenSSH ships an open-ended extension mechanism: the server lists
extension names it understands in its <code>SSH_FXP_VERSION</code>
reply, and the client invokes them via
<code>SSH_FXP_EXTENDED(200)</code> packets carrying the extension
name as the first string. Each extension is feature-detected via
<code>SSH::SftpClient>>supportsExtension:</code>; callers fall
back when the server doesn't advertise it.

The stack uses four of the OpenSSH extensions today:

* <code>posix-rename@openssh.com</code> — atomic rename-with-overwrite. Picked up automatically by
<code>SftpFilename>>renameTo:</code>; the delete-then-rename
fallback only fires on servers that lack it.
* <code>hardlink@openssh.com</code> — create a POSIX hard link. Exposed as <code>SftpFilename>>createHardLinkAs:</code>.
* <code>statvfs@openssh.com</code> — POSIX
<code>statvfs(3)</code>-shape filesystem stats. Exposed as
<code>SftpFilename>>fileSystemInfo</code>; the result is
shape-compatible with <code>OperatingSystem getDiskInfoOf:</code>
so callers can treat local and remote uniformly. Drives the
'''Tools → Filesystem Info...''' menu entry described at the
top of this page.
* <code>fsync@openssh.com</code> — flush server-side write buffer to disk on an open handle. Available on the low-level
<code>SftpClient>>fsyncHandle:</code>; not yet plumbed
into a Filename-level "durable write" API.

The remaining OpenSSH extensions
(<code>lsetstat@openssh.com</code>, <code>fstatvfs@openssh.com</code>)
are recognised in the advertised-extensions list but not wrapped at
Filename level — there's no Filename-side caller for them yet.

=== Connection pooling ===

Every <code>SftpFilename</code> instance pointing at the same
<code>user@host:port</code> triple shares one
<code>SSH::Client</code> plus one <code>SSH::SftpClient</code>.
Pool is class-side, guarded by a single
<code>ConnectionPoolMutex</code>:

* '''Lazy bring-up''' — TCP + KEX + userauth + SFTP INIT happens on the first SFTP operation, not on <code>forUrl:</code>.
* '''Per-host serialisation''' — SFTP requests on a given host are serialised through a <code>RecursionLock</code> named
<code>SFTP/<user@host:port></code> (visible in
SemaphoreMonitor).
* '''Idle eviction''' — unused for longer than
<code>idleEvictionSeconds</code>, the entry is proactively
closed + reopened on the next access.
* '''Auto-reconnect''' — a transport-level failure (broken pipe, EOF, MNU on nil socket) evicts the dead pool entry, opens a fresh client, retries the request '''once'''. Application-level SFTP STATUS errors propagate immediately.

== Future work ==

Tracked but not yet implemented:

* '''Multi-channel parallelism per host''' — today one TCP + one SFTP channel per host means N concurrent requests serialise. Pipelining over multiple SshClients in the pool (preferred), or a transport-level reader process demultiplexing to per-channel inboxes, would let the tree pane keep listing while the content pane reads a large file.
* '''Accurate <code>#isNonEmptyDirectory</code>''' via OPEN_DIR + READ_DIR (first batch only) + CLOSE — three RTTs per probe; needs SftpClient to pipeline requests before this pays off.
* '''SFTP v5/v6 negotiation''' for extended attrs and FTP-style canonicalisation. (Atomic-overwrite rename is already handled via the OpenSSH <code>posix-rename@openssh.com</code> extension; see [[#OpenSSH SFTP extensions]].)

= Command Shell =

Local command shell on this expecco machine. Typical applications:
local command-line, running a local helper tool, bridging a
remote workflow to a local utility.

The Expecco RemoteAccess plugin exposes:

* '''CmdShell - Open'''
* '''CmdShell - Close'''

No credentials, no network — runs as the expecco process's own
user. Output streams to expecco's log.

= Telnet =

[[File:Warning.svg|24px|Warning]] '''Telnet is a legacy protocol
with no encryption.''' Passwords are transmitted in plain text on
the wire; anyone on the network path can read them. Use Telnet
ONLY when the target device has no other option (typically: old
industrial controllers, lab instruments, embedded measurement
equipment without an SSH stack). For everything else use
[[#SSH and SFTP]].

The expecco plugin exposes:

* '''Telnet - Open Remote Connection With Login'''
* '''Telnet - Execute Remote Command'''
* '''Example - Remote Device Control via Telnet''' (internal demo)

The Telnet protocol (RFC 854) is a bidirectional 8-bit byte stream
over TCP, with in-band control sequences for terminal options.
A connection is established to a target host:port; after optional
in-band login, both sides can send data.

= See also =

* [[SSH Client/en|SSH::Client]] — the SSH layer (exec, TTY, agent forwarding, ProxyJump).
* [[FileBrowserV2/en|FileBrowserV2]] — the main UI client of this stack.
* [[ClaudeCode plugin/en|Claude Code]] — uses the same SSH stack for its HTTPS transport.
* [[Wikipedia:Secure Shell|RFC 4251 (SSH-2 Architecture)]]
* [[Wikipedia:Telnet|RFC 854 (Telnet Protocol)]]

[[Category:Plugins]]
[[Category:Network]]
[[Category:SSH]]

KI Coding Plugin

2026-06-04T11:23:22Z

Cg: /* Was kann eine lokale KI (z.B. ollama) */

= KI Coding Plugin =

Das KI Coding Plugin bindet einen Large Language Model (LLM) basierten
KI-Assistenten in den Activity-Editor (Aktivitäten-Code), den
Compound-Netzwerk-Editor, den Dokumentations-Editor und in den
ST/X Class Browser ein. Das Plugin unterstützt zwei Anbieter, die im
Einstellungsdialog umschaltbar sind:

* '''Anthropic Claude''' (claude-opus-4-7, claude-sonnet-4-6, claude-haiku-4-5)
* '''OpenAI ChatGPT''' (gpt-4o, gpt-4o-mini, gpt-4.1, gpt-4.1-mini, gpt-4.1-nano, o1, o3)
* '''Ollama''' (codellama:7b, codellama:13b)
Je nach gewähltem Anbieter erscheint die Toolbar-Schaltfläche als
'''"Ask Claude"''' bzw. '''"Ask ChatGPT"'''; das Einstellungs-Tab
heißt '''"AI Coding"'''.

== Aktivitäten-Editor ==

Im Aktivitäten-Code-Editor erscheint in der Toolbar eine Schaltfläche
"Ask Claude" / "Ask ChatGPT" mit folgenden Aktionen:

* Open KI Window — öffnet das eigenständige Chat-Fenster
* Explain code — erklärt den Code der aktuellen Aktivität
* Suggest improvement — schlägt Verbesserungen vor
* Find bugs — sucht nach Fehlern, Race Conditions, nil-Handling-Problemen
* Generate doc-comment — generiert eine Aktivitäts-Dokumentation inklusive Pin-Kommentaren und füllt den Documentation-Tab
* Custom prompt... — freier Prompt; der Aktivitäts-Code wird als Kontext mitgesendet
* Set model ▸ — Untermenü mit den Modellen des aktiven Anbieters (das aktuell aktive ist mit ''(active)'' markiert)
* Set provider ▸ — nur sichtbar, wenn API-Schlüssel für mehr als einen Anbieter konfiguriert sind; Untermenü zum Umschalten zwischen Claude und ChatGPT

Code-Vorschläge können mit '''[Apply]''' (direkt am jeweiligen
Code-Block im Chat oder über die obere Apply-Schaltfläche) in den
Aktivitäts-Body übernommen werden. Vom KI gelieferte Smalltalk/X
Hilfsmethoden (Form: <code>Klasse >> selector</code>) werden nach
Rückfrage in die genannte Klasse compiliert.

== Compound (Netzwerk) Editor ==

Auf der Toolbar von Compound-Worksheets erscheint dieselbe
Schaltfläche, beschränkt auf die für Netze sinnvollen Aktionen
(Open KI Window, Generate doc-comment) — ebenfalls mit den
Untermenüs '''Set model''' und ggf. '''Set provider'''.

== Dokumentations-Editor ==

Der Dokumentations-Tab der Block-Description (Editor für Test-Cases,
Test-Plans und Aktivitäten) trägt dieselbe Toolbar-Schaltfläche
"Ask Claude" / "Ask ChatGPT" mit den Einträgen
'''Open KI Window''', '''Generate doc-comment''' sowie den
Untermenüs '''Set model''' und ggf. '''Set provider'''.
'''Generate doc-comment''' analysiert den aktuellen Block (Name,
vorhandene Beschreibung, Eingangs-/Ausgangs-Pins, Sub-Steps eines
Compound-Netzes, referenzierte Environment-Variablen) und schlägt
eine vollständige Block- und Pin-Dokumentation vor.

Ist der Block schreibgeschützt (importierte Library, RTL-Lizenz),
fragt '''[Apply]''' nach, ob der Block freigeschaltet und die
Dokumentation eingetragen werden soll.

== Class Browser (ST/X) ==

Im Class Browser stehen die Aktionen unter dem '''AI'''-Untermenü
sowie im Selektor-Kontextmenü zur Verfügung. Die Aktionen
operieren auf der aktuell ausgewählten Methode (Klasse + Selektor +
Quelltext werden als Kontext mitgesendet). '''[Apply]''' kann das
Resultat direkt in die Methode der aktiven Klasse einbauen.
Auch hier sind '''Set model''' und ggf. '''Set provider''' als
Untermenüs verfügbar.

== Chat-Fenster ==

Das eigenständige Chat-Fenster trägt den Titel
'''AI Coding [<Produkt> / <Modell>]''' (z.B.
"AI Coding [Claude / claude-opus-4-7]") und zeigt nach jedem Turn
den Tokenverbrauch und die kumulierten Kosten — sofern Preise für
das gewählte Modell hinterlegt sind. Anbieter- und Modellwechsel
im Einstellungsdialog werden live übernommen.

Das Transkript ist als vertikales Panel von "Karten" aufgebaut:

* '''Prosa-Karten''' enthalten den fließenden Text der Antwort; Zeilen werden auf die Fenster-Breite umgebrochen.
* '''Code-Karten''' (eingerahmt) entstehen aus markdown-Code-Blöcken (<code>```...```</code>) und sind als '''Workspace''' editierbar — das Standard-Smalltalk-Popup-Menü bietet doIt / printIt / inspectIt, ein <code>TestCase</code>-<code>simulatedSelf</code> ist gesetzt, so dass <code>self assert:... equals:...</code> direkt ausgeführt werden kann. Lange Blöcke scrollen innerhalb der Karte. Rechts oben sitzen die Schaltflächen '''[Apply]''' (sofern für den Kontext sinnvoll) und '''[⎘ Copy]'''; links wird der Sprachtag (smalltalk, python, …) angezeigt.
* '''Doku-Karten''' (volle Breite, Prosa) entstehen aus dem speziellen <code>```doc</code>-Block, den der Dokumentations-Generator anfordert; Inhalt ist die Vorschlags-Dokumentation für Block- und Pin-Beschreibungen.

Scroll-Lock: solange der Anwender bereits am unteren Ende des
Transkripts steht, folgt die Anzeige neu eintreffenden Karten
automatisch; nach manuellem Hochscrollen bleibt die Position stehen.

Bilder können als Anhang versendet werden (Screenshot oder
PNG/JPG-Datei). Anhänge funktionieren mit beiden Anbietern; bei
OpenAI nur mit vision-fähigen Modellen (gpt-4o-Familie).

== Einstellungen (AI Coding) ==

Im Einstellungsdialog unter '''Plugins → AI Coding''' (bzw. unter
'''Tools → AI Coding''' im Smalltalk-Launcher) werden konfiguriert:

* '''Provider''' — Anthropic oder OpenAI. Beim Wechsel werden API-URL und Default-Modell entsprechend angepasst; der gespeicherte API-Schlüssel des jeweiligen Anbieters wird geladen.
* '''API Key''' — Schlüssel des aktuell gewählten Anbieters. Die Schlüssel werden pro Anbieter getrennt gespeichert (<code>#claudeApiKey_anthropic</code> bzw. <code>#claudeApiKey_openai</code>), so dass zwischen den Anbietern ohne erneute Eingabe gewechselt werden kann. Das Setzen des Schlüssels erfolgt ausschließlich über diesen Dialog.
* '''Model''' — ein Modell aus der Liste des aktiven Anbieters oder ein selbst eingegebener Modellname. Kann auch direkt über das '''Set model'''-Untermenü in den Editor-Toolbars umgeschaltet werden.
* '''Max output tokens''' — maximale Antwortlänge.
* '''API URL''' — nur zu ändern für eigene Proxies / Gateways. Standard: <code>https://api.anthropic.com/v1/messages</code> bzw. <code>https://api.openai.com/v1/chat/completions</code>.

== API-Schlüssel beschaffen ==

* Anthropic: [https://console.anthropic.com console.anthropic.com], Schlüsselformat <code>sk-ant-...</code>.
* OpenAI: [https://platform.openai.com/api-keys platform.openai.com/api-keys], Schlüsselformat <code>sk-...</code> oder <code>sk-proj-...</code>. Voraussetzung ist ein aufgeladenes Konto (Mindestbetrag derzeit USD 5).

== Datenschutz / Datenfluss ==

Bei aktivem Anbieter '''Anthropic''' gehen die Anfragen direkt an
<code>api.anthropic.com</code>, bei '''OpenAI''' direkt an
<code>api.openai.com</code>. Es gibt keinen eXept-seitigen Proxy oder
Zwischenspeicher. Mit dem Aktivitäts-Quelltext bzw. den Methoden-
Quelltexten werden auch Pin-Beschreibungen, Sub-Step-Namen und
referenzierte Environment-Variablen aus dem Block-Description-Modell
als Kontext versendet.

Bei Benutzung von Anthropic API-Tokens - wie hier der Fall - werden laut Anthropic die Daten nicht zum Training des KI-Modells genutzt ([https://privacy.claude.com/de/articles/7996868-werden-meine-daten-fur-das-modelltraining-verwendet Anthropic Erkärung dazu]). Für die Wahrheit dieser Aussage könne wir nicht garantieren und haften.

Wenn Sie sicher sein wollen, daß keine Information Ihr Haus verlässt empfehlen wir eine eigenem geschlossene in-house KI Umgebung, wie sie bei einigen unserer Kunden bereits existiert. Sie dürfen dann selbstverständlich nur die URLs dieser Umgebung konfigurieren. Expecco kommuniziert ausschließlich mit der von Ihnen eingegebenen KI.

== Tipps ==

* '''Mehrere Konversationen''': der Chat ist ein Singleton — eine neue Anfrage über ein Browser-/Editor-Menü startet jedesmal eine '''neue''' Konversation. Folge-Fragen (Klärung, Vertiefung) gehen über das Eingabefeld in derselben Konversation.
* '''Vorsicht:''' Die Größe der übertragenen Daten (auch die aus dem Chatfenster) geht in die Kostenberechnung ein. Deshalb immer eine neue Konversation starten, wenn es um ein neues Thema geht.
* '''Modell wechseln''': Für schnelle Routine-Antworten Sonnet, für schwierige Refactorings Opus. Über das '''Set model'''-Untermenü direkt aus der Toolbar oder über die Settings.
* '''Anbieter wechseln''': Sind Schlüssel für beide Anbieter konfiguriert, schaltet das '''Set provider'''-Untermenü ohne Umweg über den Settings-Dialog um.
* '''Code direkt ausführen''': In Code-Karten kann markierter Smalltalk-Code per doIt / printIt / inspectIt direkt evaluiert werden — praktisch z.B. um vom Modell vorgeschlagene SUnit-Asserts gleich auszuprobieren, ohne den Code erst in einen Workspace zu kopieren.
* '''Custom prompt''' eignet sich gut für „warum macht Methode X es so und nicht so?" oder „schreib mir einen ParameterizedTest dazu mit folgenden Daten: …".

== Tipps für die Arbeit mit claudeCode ==
Wenn Sie claudeCode verwenden, stehen ihnen noch weit mehr Funktionen zur Verfügung: sie können zum Beispiel im claudeCode Terminal eingeben:
* "mach mir eine neue Suite in einem neuen Fenster",
* "Mache eine Aktion zur Berechnung des Umfangs eines Kreises bei gegebenen Radius",
* "Erstelle eine neue suite mit einem Testfall der folgendes macht:
** 1) webbrowser auf "www.exept.de" öffnen.
** 2) auf das logo oben links klicken.
** 3) webbrowser schliessen.
* welche Funktionalität ist in xxx.ets

Claude wurde von uns in die Lage versetzt, selbst nach passenden Bibliotheken zu suchen, diese zu importieren, Aktionen zu Generieren und den Testplan anzulegen.

Tatsächlich auch, den Test gleich durchzuführen und das Resultat zu analysieren.

Aktuell sind wir am trainieren, so dass claude z.B. selbst entscheidet ob es besser ist, eine fehlende Aktion als Diagramm oder als elementare zu definieren. Es ist in der Lage, die Funktionen des unterliegenden Frameworks zu sehen und auch komplexe Aufgaben zu erledigen:
* "aktion zum Lesen der Jahresumsätze eines Jahres aus der Datenbank"
* extrahiere aus dem xml Dokument alle budget Einträge und liefere die Summe

=== Erfahrungen und Tipps für die Arbeit ===

Sonnet-4 ist gefühlt weit intelligenter als Heiku-4.5,
aber auch weit teurer. Ihr Budget kann sehr schnell schmelzen mit Sonnet. Insbesondere wenn man auf medium oder high Intelligenzlevel abeitet. Aber Haiku macht auch weit mehr Fehler und man sollte genau hinschauen was er so generiert. Gefühlt war Sonnet selbst im low level besser als Haiku. Aber der Preis...

Folgende konkrete Tipps aus unseren ersten Erfahrungen, diese Liste wird aktualisiert, und kann auch basieren auf unserer eigenen Dummheit. Ist also u.U.mit Vorsicht zu geniessen.

* geben Sie Haiku Hinweise, z.B. schau mal dort, oder nimm das als Beispiel. Sonnet findet selbst viel besser Lösungen.
* kurze Anweisungen, je konkreter desto günstiger.
* haiku ist weit "fauler". Z.B hat sonnet automatisch eine Dokumentation bei neuen Aktionen angelegt, und diese auch aktualisiert. Haiku hingegen musste man explizit eine Regel dazu anlegen (z.B. mit "wenn du eine aktion anlegst oder änderst, aktualisiere die dokumentation")
* heiku ist dümmer. Regeln die von sonnet angelegt wurden, können von haiku u.U. nicht befolgt werden, weil sonnet weit mehr generalisieren kann.
* sagen sie beiden sie sollten wenn sie ein Problem haben, nicht lange selbst suchen. sondern nachfragen ob man ihnen einen Tipp geben kann. Wenn Sie das nicht tun, kann es sein dass Sonnet auch eine viertel Stunde nachdenkt und die Dollars schmelzen wie Eis in der Sonne (ist mir passiert, als ein Socket Problem in der Kommunikation auftrat, und er nicht erkannte, das die Antworten von mcp falsch waren, es hat dann selbst alle möglichen Wege gesucht, eine Nachricht abzusetzen, incl. der Erstellung diverser Shell, curl und Python Scripte... obgleich es eigentlich ein Interface dafür gab, das aber einen Fehler hatte).
* schränken Sie das Modell in seinen Möglichkeiten ein, z.B. sagen sie "editiere nicht die files sondern verwende dazu ein tool", oder "eine expecco aktion und sag mir vorher welche du nimmst". Sonst kann es passieren dass es anfängt ihre ets zu entpacken um darin nach strings zu suchen, obgleich es das eigentlich einfacher über das interface machen kann (dieses konkrete Problem wird nicht mehr auftreten aber Sie sehen den Punkt). Da war Sonnet weit intelligenter hat aber auch länger nachgedacht.
* wenn sie feststellen, dass es einen Fehler macht, sagen sie (wörtlich) "remember: mach dies nicht, oder um das zu machen tu das."
* sie können diese Erinnerungen sowohl in ihrem UserProfile (also im lokalen Filesystem) als auch in ihren expecco Präferenzen halten. Sagen Sie dazu "remember this in in my expecco memory" oder "remember (in my user memory): bla bla". Erinnerungen kann man auch löschen "forget to ...". Zu Beginn der nächsten session sagen sie "read your expecco memory".
* wechseln sie das Modell oder den level, je nach Komplexität der Aufgabe. Aber bedenken Sie dass Wissen von Session zu Session verloren geht, wenn es nicht erinnert wird. Technisch sind Erinnerungen nichts anderes als das Lesen einer Liste der vormaligen remember Anweisungen. Kosten also auch Tokens. Sie könnten also die Erinnerunge auch einfach neu eintippen ;-)
* auch wenn es so scheint: das "Ding" ist kein Mensch; lassen sie "bitte, danke, oder Begründungen - es sei denn sie dienen der Entscheidung - weg. Tatsächlich erhöhen sie den Tokenverbrauch u.U.

Subjektive Zusammenfassung:
* haiku ist viel schneller in der Antwort und kostet ein Zehntel. Mit Sonnet war nach 3-4 Std Arbeit mein Limit erreicht und ich durfte Stunden Pause machen. Mit Haiku kann man durcharbeiten. Aber ich brauche auch mindestens doppelt so viel Zeit um haiku anzuleiten und seine Fehler wieder auszubügeln.

== Was kann eine lokale KI (z.B. ollama) ==

Erste Versuche sind eher ernüchternd. Ohne Zugriff auf lokale Quellen, mit rein antrainiertem Wissen sind die Modelle vermutlich zu klein. Hier eine Konversation mit gemma3:8b-it-qat (8 Mrd, quantifiziert) auf einem Rechner ohne GPU.
Die Antwortzeiten sind natürlich schlecht, aber mit einer GPU u.U. brauchbar.

Wichtig: wir sind selbst noch Anfänger und keine [https://en.wikipedia.org/wiki/Susan_Calvin KI Psychologen].

=== Installation ===
install ollama
ollama pull gemma3:8b-it-qat ;; gemma3:8b / gemma3:12b usw.
ollama run gemma3:8b-it-qat

=== Sitzung 1 ===
Hinweise: Wichtig, sonst labert Sie das Modell voll!

>>> respond short and concise
Understood

Hinweise: Smalltalk/X wissen hat er nicht, aber VW und Pharo sind ähnlich genug.

>>> you are an expert in smalltalk programming, especially in Smalltalk/X, visualworks and Squeak.

You have come to the right place I have a considerable depth of knowledge regarding Smalltalk...
Angeber- wir werden sehen

>>> what does the smalltalk expression "self at:4 put:'bla' " mean

Sets the character 'b' at index 4 of `self` (assuming `self` is a string).
Falsche Antwort; Smalltalk verwendet 1-basierte Indices, und 'bla' ist ein String

>>> how to compute the area of a circle given radius

```smalltalk
| radius area |
radius := 5.0.
area := radius * radius * PI.
^area
```
nicht schlecht.

>>> how to extract a substring

`substring:startIndexToEndIndex` (inclusive). E.g., `"hello" substring:2 to:4` yields `"llo"`.
wieder falsch; 1-basierter index, substring:to: möglicherweise in einem anderen Smalltalk vorhanden. Könnte man durchgehen lassen

>>> alternative?

`copyFrom:to:` (indexes inclusive). `string copyFrom:1 to:3` gives `"ell"`.
besser, aber immer noch falscher Index

>>> what is the result of 'hello' copyFrom:2 to:4

"llo"
war zu erwarten

>>> smalltalk uses 1 based indexing. what is the result

Correct. The result of `'hello' copyFrom:2 to:4` is `"llo"`.
soso. Er sieht ein, dass ich korrigiert habe - dann aber dickköpfig.

>>> in smalltalk the first index is 1 the last is the collection's size. Not as in Python or C.

Precisely. 1-based indexing is core to Smalltalk.
aha, er könnte es wissen; es fehlt ihm aber offensichtlich an Abstraktionsvermögen. Versuchen wir es mit einem Beispiel:

>>> remember: the result of 'hello' copyFrom:2 to4 is 'ell'

You are absolutely right! My apologies. `copyFrom:to:` includes both endpoints, so `'hello' copyFrom:2 to:4` results in `"ell"`. Thanks for the correction. I am still under development and learning nuances like this.
soso, eine Nuance. Mal sehen:

>>> >> what is the result of 'abcde' copyFrom:2 to:4

"bcd"
na also; geht doch.

=== Sitzung 2 ===

Neuer Versuch; eine neue Session. Gib ihm Grundwissen, das er nicht im Modell hat.
/clear
>>> answer short an concise
Okay.

>>> you are expert in smalltalk programming, especially smalltalk/x, visualworks and pharo

Acknowledged. I'm ready to leverage my knowledge of Smalltalk (including Smalltalk/X, VisualWorks, and Pharo) to
assist you. Ask away!
>>> remember: because smalltalk is 1-based indexing, the result of 'hello' copyFrom:2 to4 is 'ell'

Understood. I will keep in mind Smalltalk's 1-based indexing when answering your questions about string
manipulation and other operations
>>> what is the result of 'abcde' copyFrom:2 to:4

'bcd'
richtig!

>>> given Array #(10 20 30 40) what is the result of array at:3

30
richtig!

Man muss den Context also mit Wissen füllen, dann kommt durchaus sinnvolles heraus. Wir sind dran, das zu evaluieren damit möglicherweise sogar eine lokale KI (allerdings mit GPU) hilfreich unterstützen kann.
[[Kategorie:Plugin]]
[[Kategorie:Erweiterung]]

KI Coding Plugin

2026-06-04T10:44:46Z

Cg: /* Was kann eine lokale KI (z.B. ollama) */

= KI Coding Plugin =

Das KI Coding Plugin bindet einen Large Language Model (LLM) basierten
KI-Assistenten in den Activity-Editor (Aktivitäten-Code), den
Compound-Netzwerk-Editor, den Dokumentations-Editor und in den
ST/X Class Browser ein. Das Plugin unterstützt zwei Anbieter, die im
Einstellungsdialog umschaltbar sind:

* '''Anthropic Claude''' (claude-opus-4-7, claude-sonnet-4-6, claude-haiku-4-5)
* '''OpenAI ChatGPT''' (gpt-4o, gpt-4o-mini, gpt-4.1, gpt-4.1-mini, gpt-4.1-nano, o1, o3)
* '''Ollama''' (codellama:7b, codellama:13b)
Je nach gewähltem Anbieter erscheint die Toolbar-Schaltfläche als
'''"Ask Claude"''' bzw. '''"Ask ChatGPT"'''; das Einstellungs-Tab
heißt '''"AI Coding"'''.

== Aktivitäten-Editor ==

Im Aktivitäten-Code-Editor erscheint in der Toolbar eine Schaltfläche
"Ask Claude" / "Ask ChatGPT" mit folgenden Aktionen:

* Open KI Window — öffnet das eigenständige Chat-Fenster
* Explain code — erklärt den Code der aktuellen Aktivität
* Suggest improvement — schlägt Verbesserungen vor
* Find bugs — sucht nach Fehlern, Race Conditions, nil-Handling-Problemen
* Generate doc-comment — generiert eine Aktivitäts-Dokumentation inklusive Pin-Kommentaren und füllt den Documentation-Tab
* Custom prompt... — freier Prompt; der Aktivitäts-Code wird als Kontext mitgesendet
* Set model ▸ — Untermenü mit den Modellen des aktiven Anbieters (das aktuell aktive ist mit ''(active)'' markiert)
* Set provider ▸ — nur sichtbar, wenn API-Schlüssel für mehr als einen Anbieter konfiguriert sind; Untermenü zum Umschalten zwischen Claude und ChatGPT

Code-Vorschläge können mit '''[Apply]''' (direkt am jeweiligen
Code-Block im Chat oder über die obere Apply-Schaltfläche) in den
Aktivitäts-Body übernommen werden. Vom KI gelieferte Smalltalk/X
Hilfsmethoden (Form: <code>Klasse >> selector</code>) werden nach
Rückfrage in die genannte Klasse compiliert.

== Compound (Netzwerk) Editor ==

Auf der Toolbar von Compound-Worksheets erscheint dieselbe
Schaltfläche, beschränkt auf die für Netze sinnvollen Aktionen
(Open KI Window, Generate doc-comment) — ebenfalls mit den
Untermenüs '''Set model''' und ggf. '''Set provider'''.

== Dokumentations-Editor ==

Der Dokumentations-Tab der Block-Description (Editor für Test-Cases,
Test-Plans und Aktivitäten) trägt dieselbe Toolbar-Schaltfläche
"Ask Claude" / "Ask ChatGPT" mit den Einträgen
'''Open KI Window''', '''Generate doc-comment''' sowie den
Untermenüs '''Set model''' und ggf. '''Set provider'''.
'''Generate doc-comment''' analysiert den aktuellen Block (Name,
vorhandene Beschreibung, Eingangs-/Ausgangs-Pins, Sub-Steps eines
Compound-Netzes, referenzierte Environment-Variablen) und schlägt
eine vollständige Block- und Pin-Dokumentation vor.

Ist der Block schreibgeschützt (importierte Library, RTL-Lizenz),
fragt '''[Apply]''' nach, ob der Block freigeschaltet und die
Dokumentation eingetragen werden soll.

== Class Browser (ST/X) ==

Im Class Browser stehen die Aktionen unter dem '''AI'''-Untermenü
sowie im Selektor-Kontextmenü zur Verfügung. Die Aktionen
operieren auf der aktuell ausgewählten Methode (Klasse + Selektor +
Quelltext werden als Kontext mitgesendet). '''[Apply]''' kann das
Resultat direkt in die Methode der aktiven Klasse einbauen.
Auch hier sind '''Set model''' und ggf. '''Set provider''' als
Untermenüs verfügbar.

== Chat-Fenster ==

Das eigenständige Chat-Fenster trägt den Titel
'''AI Coding [<Produkt> / <Modell>]''' (z.B.
"AI Coding [Claude / claude-opus-4-7]") und zeigt nach jedem Turn
den Tokenverbrauch und die kumulierten Kosten — sofern Preise für
das gewählte Modell hinterlegt sind. Anbieter- und Modellwechsel
im Einstellungsdialog werden live übernommen.

Das Transkript ist als vertikales Panel von "Karten" aufgebaut:

* '''Prosa-Karten''' enthalten den fließenden Text der Antwort; Zeilen werden auf die Fenster-Breite umgebrochen.
* '''Code-Karten''' (eingerahmt) entstehen aus markdown-Code-Blöcken (<code>```...```</code>) und sind als '''Workspace''' editierbar — das Standard-Smalltalk-Popup-Menü bietet doIt / printIt / inspectIt, ein <code>TestCase</code>-<code>simulatedSelf</code> ist gesetzt, so dass <code>self assert:... equals:...</code> direkt ausgeführt werden kann. Lange Blöcke scrollen innerhalb der Karte. Rechts oben sitzen die Schaltflächen '''[Apply]''' (sofern für den Kontext sinnvoll) und '''[⎘ Copy]'''; links wird der Sprachtag (smalltalk, python, …) angezeigt.
* '''Doku-Karten''' (volle Breite, Prosa) entstehen aus dem speziellen <code>```doc</code>-Block, den der Dokumentations-Generator anfordert; Inhalt ist die Vorschlags-Dokumentation für Block- und Pin-Beschreibungen.

Scroll-Lock: solange der Anwender bereits am unteren Ende des
Transkripts steht, folgt die Anzeige neu eintreffenden Karten
automatisch; nach manuellem Hochscrollen bleibt die Position stehen.

Bilder können als Anhang versendet werden (Screenshot oder
PNG/JPG-Datei). Anhänge funktionieren mit beiden Anbietern; bei
OpenAI nur mit vision-fähigen Modellen (gpt-4o-Familie).

== Einstellungen (AI Coding) ==

Im Einstellungsdialog unter '''Plugins → AI Coding''' (bzw. unter
'''Tools → AI Coding''' im Smalltalk-Launcher) werden konfiguriert:

* '''Provider''' — Anthropic oder OpenAI. Beim Wechsel werden API-URL und Default-Modell entsprechend angepasst; der gespeicherte API-Schlüssel des jeweiligen Anbieters wird geladen.
* '''API Key''' — Schlüssel des aktuell gewählten Anbieters. Die Schlüssel werden pro Anbieter getrennt gespeichert (<code>#claudeApiKey_anthropic</code> bzw. <code>#claudeApiKey_openai</code>), so dass zwischen den Anbietern ohne erneute Eingabe gewechselt werden kann. Das Setzen des Schlüssels erfolgt ausschließlich über diesen Dialog.
* '''Model''' — ein Modell aus der Liste des aktiven Anbieters oder ein selbst eingegebener Modellname. Kann auch direkt über das '''Set model'''-Untermenü in den Editor-Toolbars umgeschaltet werden.
* '''Max output tokens''' — maximale Antwortlänge.
* '''API URL''' — nur zu ändern für eigene Proxies / Gateways. Standard: <code>https://api.anthropic.com/v1/messages</code> bzw. <code>https://api.openai.com/v1/chat/completions</code>.

== API-Schlüssel beschaffen ==

* Anthropic: [https://console.anthropic.com console.anthropic.com], Schlüsselformat <code>sk-ant-...</code>.
* OpenAI: [https://platform.openai.com/api-keys platform.openai.com/api-keys], Schlüsselformat <code>sk-...</code> oder <code>sk-proj-...</code>. Voraussetzung ist ein aufgeladenes Konto (Mindestbetrag derzeit USD 5).

== Datenschutz / Datenfluss ==

Bei aktivem Anbieter '''Anthropic''' gehen die Anfragen direkt an
<code>api.anthropic.com</code>, bei '''OpenAI''' direkt an
<code>api.openai.com</code>. Es gibt keinen eXept-seitigen Proxy oder
Zwischenspeicher. Mit dem Aktivitäts-Quelltext bzw. den Methoden-
Quelltexten werden auch Pin-Beschreibungen, Sub-Step-Namen und
referenzierte Environment-Variablen aus dem Block-Description-Modell
als Kontext versendet.

Bei Benutzung von Anthropic API-Tokens - wie hier der Fall - werden laut Anthropic die Daten nicht zum Training des KI-Modells genutzt ([https://privacy.claude.com/de/articles/7996868-werden-meine-daten-fur-das-modelltraining-verwendet Anthropic Erkärung dazu]). Für die Wahrheit dieser Aussage könne wir nicht garantieren und haften.

Wenn Sie sicher sein wollen, daß keine Information Ihr Haus verlässt empfehlen wir eine eigenem geschlossene in-house KI Umgebung, wie sie bei einigen unserer Kunden bereits existiert. Sie dürfen dann selbstverständlich nur die URLs dieser Umgebung konfigurieren. Expecco kommuniziert ausschließlich mit der von Ihnen eingegebenen KI.

== Tipps ==

* '''Mehrere Konversationen''': der Chat ist ein Singleton — eine neue Anfrage über ein Browser-/Editor-Menü startet jedesmal eine '''neue''' Konversation. Folge-Fragen (Klärung, Vertiefung) gehen über das Eingabefeld in derselben Konversation.
* '''Vorsicht:''' Die Größe der übertragenen Daten (auch die aus dem Chatfenster) geht in die Kostenberechnung ein. Deshalb immer eine neue Konversation starten, wenn es um ein neues Thema geht.
* '''Modell wechseln''': Für schnelle Routine-Antworten Sonnet, für schwierige Refactorings Opus. Über das '''Set model'''-Untermenü direkt aus der Toolbar oder über die Settings.
* '''Anbieter wechseln''': Sind Schlüssel für beide Anbieter konfiguriert, schaltet das '''Set provider'''-Untermenü ohne Umweg über den Settings-Dialog um.
* '''Code direkt ausführen''': In Code-Karten kann markierter Smalltalk-Code per doIt / printIt / inspectIt direkt evaluiert werden — praktisch z.B. um vom Modell vorgeschlagene SUnit-Asserts gleich auszuprobieren, ohne den Code erst in einen Workspace zu kopieren.
* '''Custom prompt''' eignet sich gut für „warum macht Methode X es so und nicht so?" oder „schreib mir einen ParameterizedTest dazu mit folgenden Daten: …".

== Tipps für die Arbeit mit claudeCode ==
Wenn Sie claudeCode verwenden, stehen ihnen noch weit mehr Funktionen zur Verfügung: sie können zum Beispiel im claudeCode Terminal eingeben:
* "mach mir eine neue Suite in einem neuen Fenster",
* "Mache eine Aktion zur Berechnung des Umfangs eines Kreises bei gegebenen Radius",
* "Erstelle eine neue suite mit einem Testfall der folgendes macht:
** 1) webbrowser auf "www.exept.de" öffnen.
** 2) auf das logo oben links klicken.
** 3) webbrowser schliessen.
* welche Funktionalität ist in xxx.ets

Claude wurde von uns in die Lage versetzt, selbst nach passenden Bibliotheken zu suchen, diese zu importieren, Aktionen zu Generieren und den Testplan anzulegen.

Tatsächlich auch, den Test gleich durchzuführen und das Resultat zu analysieren.

Aktuell sind wir am trainieren, so dass claude z.B. selbst entscheidet ob es besser ist, eine fehlende Aktion als Diagramm oder als elementare zu definieren. Es ist in der Lage, die Funktionen des unterliegenden Frameworks zu sehen und auch komplexe Aufgaben zu erledigen:
* "aktion zum Lesen der Jahresumsätze eines Jahres aus der Datenbank"
* extrahiere aus dem xml Dokument alle budget Einträge und liefere die Summe

=== Erfahrungen und Tipps für die Arbeit ===

Sonnet-4 ist gefühlt weit intelligenter als Heiku-4.5,
aber auch weit teurer. Ihr Budget kann sehr schnell schmelzen mit Sonnet. Insbesondere wenn man auf medium oder high Intelligenzlevel abeitet. Aber Haiku macht auch weit mehr Fehler und man sollte genau hinschauen was er so generiert. Gefühlt war Sonnet selbst im low level besser als Haiku. Aber der Preis...

Folgende konkrete Tipps aus unseren ersten Erfahrungen, diese Liste wird aktualisiert, und kann auch basieren auf unserer eigenen Dummheit. Ist also u.U.mit Vorsicht zu geniessen.

* geben Sie Haiku Hinweise, z.B. schau mal dort, oder nimm das als Beispiel. Sonnet findet selbst viel besser Lösungen.
* kurze Anweisungen, je konkreter desto günstiger.
* haiku ist weit "fauler". Z.B hat sonnet automatisch eine Dokumentation bei neuen Aktionen angelegt, und diese auch aktualisiert. Haiku hingegen musste man explizit eine Regel dazu anlegen (z.B. mit "wenn du eine aktion anlegst oder änderst, aktualisiere die dokumentation")
* heiku ist dümmer. Regeln die von sonnet angelegt wurden, können von haiku u.U. nicht befolgt werden, weil sonnet weit mehr generalisieren kann.
* sagen sie beiden sie sollten wenn sie ein Problem haben, nicht lange selbst suchen. sondern nachfragen ob man ihnen einen Tipp geben kann. Wenn Sie das nicht tun, kann es sein dass Sonnet auch eine viertel Stunde nachdenkt und die Dollars schmelzen wie Eis in der Sonne (ist mir passiert, als ein Socket Problem in der Kommunikation auftrat, und er nicht erkannte, das die Antworten von mcp falsch waren, es hat dann selbst alle möglichen Wege gesucht, eine Nachricht abzusetzen, incl. der Erstellung diverser Shell, curl und Python Scripte... obgleich es eigentlich ein Interface dafür gab, das aber einen Fehler hatte).
* schränken Sie das Modell in seinen Möglichkeiten ein, z.B. sagen sie "editiere nicht die files sondern verwende dazu ein tool", oder "eine expecco aktion und sag mir vorher welche du nimmst". Sonst kann es passieren dass es anfängt ihre ets zu entpacken um darin nach strings zu suchen, obgleich es das eigentlich einfacher über das interface machen kann (dieses konkrete Problem wird nicht mehr auftreten aber Sie sehen den Punkt). Da war Sonnet weit intelligenter hat aber auch länger nachgedacht.
* wenn sie feststellen, dass es einen Fehler macht, sagen sie (wörtlich) "remember: mach dies nicht, oder um das zu machen tu das."
* sie können diese Erinnerungen sowohl in ihrem UserProfile (also im lokalen Filesystem) als auch in ihren expecco Präferenzen halten. Sagen Sie dazu "remember this in in my expecco memory" oder "remember (in my user memory): bla bla". Erinnerungen kann man auch löschen "forget to ...". Zu Beginn der nächsten session sagen sie "read your expecco memory".
* wechseln sie das Modell oder den level, je nach Komplexität der Aufgabe. Aber bedenken Sie dass Wissen von Session zu Session verloren geht, wenn es nicht erinnert wird. Technisch sind Erinnerungen nichts anderes als das Lesen einer Liste der vormaligen remember Anweisungen. Kosten also auch Tokens. Sie könnten also die Erinnerunge auch einfach neu eintippen ;-)
* auch wenn es so scheint: das "Ding" ist kein Mensch; lassen sie "bitte, danke, oder Begründungen - es sei denn sie dienen der Entscheidung - weg. Tatsächlich erhöhen sie den Tokenverbrauch u.U.

Subjektive Zusammenfassung:
* haiku ist viel schneller in der Antwort und kostet ein Zehntel. Mit Sonnet war nach 3-4 Std Arbeit mein Limit erreicht und ich durfte Stunden Pause machen. Mit Haiku kann man durcharbeiten. Aber ich brauche auch mindestens doppelt so viel Zeit um haiku anzuleiten und seine Fehler wieder auszubügeln.

== Was kann eine lokale KI (z.B. ollama) ==

Erste Versuche sind eher ernüchternd. Ohne Zugriff auf lokale Quellen, mit rein antrainiertem Wissen sind die Modelle vermutlich zu klein. Hier eine Konversation mit gemma3:8b-it-qat (8 Mrd, quantifiziert) auf einem Rechner ohne GPU.
Die Antwortzeiten sind natürlich schlecht, aber mit einer GPU u.U. brauchbar.

install ollama
ollama run gemma3:8b-it-qat

Hinweise: Wichtig, sonst labert Sie das Modell voll!

>>> respond short and concise
Understood

>>> you are an expert in smalltalk programming, especially in Smalltalk/X, visualworks and Squeak.

You have come to the right place I have a considerable depth of knowledge regarding Smalltalk...
Angeber- wir werden sehen

>>> what does the smalltalk expression "self at:4 put:'bla' " mean

Sets the character 'b' at index 4 of `self` (assuming `self` is a string).
Falsche Antwort; Smalltalk verwendet 1-basierte Indices, und 'bla' ist ein String

>>> how to compute the area of a circle given radius

```smalltalk
| radius area |
radius := 5.0.
area := radius * radius * PI.
^area
```
nicht schlecht.

>>> how to extract a substring

`substring:startIndexToEndIndex` (inclusive). E.g., `"hello" substring:2 to:4` yields `"llo"`.
wieder falsch; 1-basierter index, substring:to: möglicherweise in einem anderen Smalltalk vorhanden. Könnte man durchgehen lassen

>>> alternative?

`copyFrom:to:` (indexes inclusive). `string copyFrom:1 to:3` gives `"ell"`.
besser, aber immer noch falscher Index

>>> what is the result of 'hello' copyFrom:2 to:4

"llo"
war zu erwarten

>>> smalltalk uses 1 based indexing. what is the result

Correct. The result of `'hello' copyFrom:2 to:4` is `"llo"`.
soso. Correct. Dann aber dickköpfig.

>>> in smalltalk the first index is 1 the last is the collection's size. Not as in Python or C.

Precisely. 1-based indexing is core to Smalltalk.
aha, er könnte es wissen; es fehlt ihm aber offensichtlich an Abstraktionsvermögen. Versuchen wir es mit einem Beispiel:

>>> remember: the result of 'hello' copyFrom:2 to4 is 'ell'

You are absolutely right! My apologies. `copyFrom:to:` includes both endpoints, so `'hello' copyFrom:2 to:4`
results in `"ell"`. Thanks for the correction. I am still under development and learning nuances like this.
soso, eine Nuance. Mal sehen:

>>> >> what is the result of 'abcde' copyFrom:2 to:4

"bcd"
na also. geht doch.

Neuer Versuch; eine neue Session. Gib ihm Grundwissen, das er nicht im Modell hat.
/clear
>>> answer short an concise
Okay.
>>> you are expert in smalltalk programming, especially smalltalk/x, visualworks and pharo
Acknowledged. I'm ready to leverage my knowledge of Smalltalk (including Smalltalk/X, VisualWorks, and Pharo) to
assist you. Ask away!
>>> remember: because smalltalk is 1-based indexing, the result of 'hello' copyFrom:2 to4 is 'ell'
Understood. I will keep in mind Smalltalk's 1-based indexing when answering your questions about string
manipulation and other operations
>>> what is the result of 'abcde' copyFrom:2 to:4
'bcd'
>>> given Array #(10 20 30 40) what is the result of array at:3
30

Man muss den Context also mit Wissen füllen, dann kommt durchaus sinnvolles heraus. Wir sind dran, das zu evaluieren damit möglicherweise sogar eine lokale KI (allerdings mit GPU) hilfreich unterstützen kann.
[[Kategorie:Plugin]]
[[Kategorie:Erweiterung]]