<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Altskripte on KalibriWare - Dokumentation</title>
    <link>https://ctdi.pages.deinstapel.de/kalibriware/dokumentation/docs/entwicklerdokumentation/altskripte/</link>
    <description>Recent content in Altskripte on KalibriWare - Dokumentation</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>de</language>
    <atom:link href="https://ctdi.pages.deinstapel.de/kalibriware/dokumentation/docs/entwicklerdokumentation/altskripte/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Einführung &amp; Ausgangssituation</title>
      <link>https://ctdi.pages.deinstapel.de/kalibriware/dokumentation/docs/entwicklerdokumentation/altskripte/intro/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://ctdi.pages.deinstapel.de/kalibriware/dokumentation/docs/entwicklerdokumentation/altskripte/intro/</guid>
      <description>Einführung Bei der im alten Kalibri integrierten Skriptsprache handelt es sich um eine komplette Eigenentwicklung. Sie kombiniert Ideen aus verschiedenen anderen Sprachen, nimmt dabei aber nur die Nachteile mit und lässt die Vorteile gezielt stehen. Die Skriptsprache ist historisch gewachsen und weist deswegen eine außergewöhnliche Menge an problematischen Designentscheidungen auf. Die Syntax ist überaus komplex, aber gleichzeitig sehr fehleranfällig und schlecht dokumentiert.&#xA;Der dazugehörige Interpreter, welcher sich hauptsächlich in der Datei GPIB.</description>
    </item>
    <item>
      <title>Designentscheidungen</title>
      <link>https://ctdi.pages.deinstapel.de/kalibriware/dokumentation/docs/entwicklerdokumentation/altskripte/design-decisions/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://ctdi.pages.deinstapel.de/kalibriware/dokumentation/docs/entwicklerdokumentation/altskripte/design-decisions/</guid>
      <description>Nicht direkt offensichtliche oder triviale Designentscheidungen, welche getroffen wurden, werden im Folgenden dokumentiert.&#xA;Ausführung der Skripte in Form eines Interpreters in TypeScript Zu Beginn des Projektes wurden verschiedene Ansätze getestet und evaluiert.&#xA;Der erste Ansatz war eine automatische Transpilierung der Altskripte in das neue Skriptformat. Hierzu sollten die Altskripte geparsed und dann mittels Transformationen des AST (Abstract Syntax Tree) transpiliert werden. Es stellte sich jedoch heraus, dass das automatische Parsen des Bestandes an Altskripten ein aussichtloses Unterfangen ist.</description>
    </item>
    <item>
      <title>Architektur und Funktionsweise</title>
      <link>https://ctdi.pages.deinstapel.de/kalibriware/dokumentation/docs/entwicklerdokumentation/altskripte/architecture-and-inner-workings/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://ctdi.pages.deinstapel.de/kalibriware/dokumentation/docs/entwicklerdokumentation/altskripte/architecture-and-inner-workings/</guid>
      <description>Bis auf wenige Ausnahmen ist der Quellcode für den legacy-interpreter in src/legacy-runtime zu finden.&#xA;Zeilenbasierte Behandlung von Skripten und Makros Grundsätzlich arbeitet der Interpreter zeilenbasiert, da dies auch die Operationsweise des alten Kalibri-Skript ist. Jede Zeile wird dabei als einzeler Buffer abgebildet.&#xA;Anbindung an die neue Laufzeitumgebung - legacy-script.ts In der Datei src/script-api/legacy-script.ts wird die Klasse LegacyScriptEngine implementiert. Die LegacyScriptEngine ist ein Wrapper und bindet den Legacy-Interpreter an die neue Laufzeitumgebung an (Ausführung und Fehlerbehandlung).</description>
    </item>
  </channel>
</rss>
