This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
dev:proposals:xatc [2021-04-19 21:46] admin encourage suggestions |
dev:proposals:xatc [2022-06-26 18:08] (current) 56independent ↷ Page moved from dev:lines:xatc to dev:proposals:xatc |
||
---|---|---|---|
Line 21: | Line 21: | ||
==== LuaATC ==== | ==== LuaATC ==== | ||
- | This second automation system is powerful, but not very thought | + | This second automation system is powerful, but not very thought |
* Commands are purely assigned to rails, and can not affect trains that are not standing on the rail (except for approach callbacks which use an ugly workaround) | * Commands are purely assigned to rails, and can not affect trains that are not standing on the rail (except for approach callbacks which use an ugly workaround) | ||
* Insufficient sandboxing (Multiple DoS attacks possible) | * Insufficient sandboxing (Multiple DoS attacks possible) | ||
Line 42: | Line 42: | ||
* Be extensible to new features introduced over time | * Be extensible to new features introduced over time | ||
- | ===== Draft ===== | + | ===== Draft 2 ===== |
+ | |||
+ | Half a year of rethinking xATC has brought some new approaches: | ||
+ | |||
+ | ==== Inspiration ==== | ||
+ | |||
+ | xATC can draw inspiration from other " | ||
+ | * **Scratch** ([[https:// | ||
+ | * **Python asyncio:** the " | ||
+ | |||
+ | ==== Event blocks ==== | ||
+ | |||
+ | xATC code is organized in "Event Blocks" | ||
+ | |||
+ | An Event Block consists of an event identifier and a set of code lines. There are built-in identifiers that depend on the context, and the user can define and call own event identifiers. | ||
+ | |||
+ | ==== Contexts ==== | ||
+ | |||
+ | Each xATC snippet is run in a context. | ||
+ | |||
+ | A new context is instantiated when a context does not exist for a particular combination of involved entities. For example, when a train approaches an xATC rail, a new context for this combination of train and xATC rail is created, unless one already exists. | ||
+ | |||
+ | A context is destroyed when all event blocks in the context are completed and no future events are scheduled for it. | ||
+ | |||
+ | For the first implementation, | ||
+ | |||
+ | A context is not created at all when an event is fired on a not-yet-existing context, but the associated xATC snippet has no handling event block for this event. | ||
+ | |||
+ | ==== Operations ==== | ||
+ | |||
+ | The following high-level operations exist (analogous to Scratch " | ||
+ | * Property/ | ||
+ | * Used for example for train inside/ | ||
+ | * Local variable creation/ | ||
+ | * Local vars are only valid in this event block | ||
+ | * Wait for a Future to complete ('' | ||
+ | * this can be waiting for a certain time, waiting for a signal to turn green etc | ||
+ | * Wait for an event to occur in the current context ('' | ||
+ | * Fire an event in the current context ('' | ||
+ | * Fire an event in a foreign context ('' | ||
+ | * Call another built-in/ | ||
+ | * Control structures: If/Else, for loop? | ||
+ | * Exit this event block ('' | ||
+ | * Destroy the context, killing this and all other event blocks in it ('' | ||
+ | |||
+ | This concept does no longer allow for directly " | ||
+ | |||
+ | '' | ||
+ | |||
+ | ==== Concurrency ==== | ||
+ | |||
+ | Event blocks are executed concurrent, but not multithreaded. Since event blocks will not perform intensive calculations but instead yield very often (via await), every time event blocks (within a context) become ready to continue execution, they are executed consecutively until the next yield. If we ever support loops, they would also yield implicitly every iteration (but instantly become ready again). | ||
+ | |||
+ | ==== Interpreter ==== | ||
+ | |||
+ | The code written in xATC is untrusted, since it is possibly written by untrusted users. We therefore build a somewhat custom Lua interpreter. A plan for this looks as follows: | ||
+ | * Every line is considered an instruction or a block start/end (we won't support ; to separate multiple commands per line for now) | ||
+ | * The global instruction structure is parsed by custom code | ||
+ | * Individual instructions are left as-is and are compiled to Lua directly. | ||
+ | * A special xATC-to-Lua compiler will find out where yield points are, split the xatc instructions into consecutive instructions without yield, and compile these somehow as individual Lua functions. This must be done in the way that the yield point the code currently is at can be saved persistently. We assume that execution does not halt between yield points. | ||
+ | * Instructions are only allowed to be in " | ||
+ | |||
+ | ==== Built-in events and variables ==== | ||
+ | |||
+ | As for the xATC rail, it will emit the following events (in typical order of occurence) | ||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | |||
+ | Special variables bound are " | ||
+ | |||
+ | ==== Examples ==== | ||
+ | |||
+ | This could be a simple stop rail: | ||
+ | < | ||
+ | on approach: | ||
+ | if train.line == " | ||
+ | set_point_speed_limit(2) -- this is a context function since it depends on both train and rail | ||
+ | train.disable_ars = true | ||
+ | end | ||
+ | -- this code does not yield, it directly terminates | ||
+ | -- At this point, no event block is active anymore and the context is destroyed | ||
+ | |||
+ | on enter: | ||
+ | if train.line ~= " | ||
+ | return | ||
+ | end | ||
+ | await train.brake(0) -- instruct the train to brake to speed 0, and wait for it | ||
+ | await train.open_doors_right() -- open the doors and wait for it | ||
+ | await delay(20) -- wait at least 20 seconds before continuing | ||
+ | train.disable_ars = false | ||
+ | await train.next_signal.wait_for_proceed() -- wait until the signal ahead shows a non-danger aspect | ||
+ | await train.close_doors() | ||
+ | train.speed(15) -- depart from the station | ||
+ | </ | ||
+ | |||
+ | More sophisticated: | ||
+ | < | ||
+ | on approach: | ||
+ | set_point_speed_limit(2) -- this is a context function since it depends on both train and rail | ||
+ | train.disable_ars = true | ||
+ | |||
+ | on enter: | ||
+ | await train.brake(0) | ||
+ | await train.open_doors_right() | ||
+ | |||
+ | local other_track = get_xatc_rail(" | ||
+ | |||
+ | rail.data[" | ||
+ | -- if nothing yields (no await and no loops) we have no preemption, so race conditions can not occur. | ||
+ | if other_track.data[" | ||
+ | -- the train is already present on the other track and | ||
+ | -- is waiting to receive our arrival event | ||
+ | other_track.fire_all(" | ||
+ | else | ||
+ | -- the other train has not arrived yet. | ||
+ | -- wait for the " | ||
+ | await event(" | ||
+ | -- note that we don't have a dedicated event block for that event, we just wait for it in here | ||
+ | end | ||
+ | -- when we get here, both trains have arrived. | ||
+ | rail.data[" | ||
+ | |||
+ | await delay(20) -- wait at least 20 seconds before continuing | ||
+ | train.disable_ars = false | ||
+ | await train.next_signal.wait_for_proceed() -- wait until the signal ahead shows a non-danger aspect | ||
+ | await train.close_doors() | ||
+ | train.speed(15) -- depart from the station | ||
+ | </ | ||
+ | |||
+ | An alternative way to write the last example: | ||
+ | < | ||
+ | on approach: | ||
+ | set_point_speed_limit(2) -- this is a context function since it depends on both train and rail | ||
+ | train.disable_ars = true | ||
+ | |||
+ | on enter: | ||
+ | await train.brake(0) | ||
+ | await train.open_doors_right() | ||
+ | |||
+ | rail.data[" | ||
+ | |||
+ | local other_track = get_xatc_rail(" | ||
+ | if other_track.data[" | ||
+ | -- the train is already present on the other track and | ||
+ | -- is waiting to receive our arrival event | ||
+ | other_track.fire_all(" | ||
+ | fire(" | ||
+ | end | ||
+ | |||
+ | -- this event gets always fired by the train arriving second | ||
+ | on other_train_arrived: | ||
+ | rail.data[" | ||
+ | |||
+ | await delay(20) -- wait at least 20 seconds before continuing | ||
+ | train.disable_ars = false | ||
+ | await train.next_signal.wait_for_proceed() -- wait until the signal ahead shows a non-danger aspect | ||
+ | await train.close_doors() | ||
+ | train.speed(15) -- depart from the station | ||
+ | </ | ||
+ | |||
+ | Note that this whole example can probably benefit from a semaphore concept. This is TBD. | ||
+ | |||
+ | ===== Draft 1 (older) | ||
xATC will use a subset of Lua to express actions. The following things are restricted: | xATC will use a subset of Lua to express actions. The following things are restricted: |