Merge pull request #200 from axmmisaka/fix-intro-links

Link to Introduction markdown, not URL

docs/reference/target-language-details.mdx

@@ -199,7 +199,7 @@ To have Lingua Franca generate C code, start your `.lf` file with one of the fol
 
 Note that for all LF statements, a final semicolon is optional. If you are writing your code in C, you may want to include the final semicolon for uniformity.
 
-For options to the target specification, see [detailed documentation of the target options](../introduction).
+For options to the target specification, see [detailed documentation of the target options](../introduction.md).
 
 The second form, `CCpp`, is used when you wish to use a C++ compiler to compile
 the generated code, thereby allowing your C reactors to call C++ code.
@@ -238,7 +238,7 @@ To have Lingua Franca generate C++ code, start your `.lf` file with the followin
 
 Note that for all LF statements, a final semicolon is optional. If you are writing your code in C++, you may want to include the final semicolon for uniformity.
 
-For options to the target specification, see [detailed documentation of the target options](../introduction).
+For options to the target specification, see [detailed documentation of the target options](../introduction.md).
 
 </ShowIf>
 <ShowIf py>
@@ -251,7 +251,7 @@ To have Lingua Franca generate Python code, start your `.lf` file with the follo
 
 Note that for all LF statements, a final semicolon is optional.
 
-For options to the target specification, see [detailed documentation of the target options](../introduction).
+For options to the target specification, see [detailed documentation of the target options](../introduction.md).
 
 </ShowIf>
 <ShowIf ts>
@@ -264,7 +264,7 @@ To have Lingua Franca generate TypeScript code, start your `.lf` file with the f
 
 Note that for all LF statements, a final semicolon is optional.
 
-The supported target parameters and command-line options are documented in the [Target Declaration](../introduction) documentation.
+The supported target parameters and command-line options are documented in the [Target Declaration](../introduction.md) documentation.
 
 </ShowIf>
 <ShowIf rs>
@@ -2730,15 +2730,15 @@ FIXME: Details needed here.
 
 A suite of useful functions is provided in [util.h](https://www.lf-lang.org/reactor-c/d8/d3c/util_8h.html) for producing messages to be made visible when the generated program is run. Of course, you can always use `printf`, but this is not a good choice for logging or debug information, and it is not a good choice when output needs to be redirected to a window or some other user interface (see for example the [sensor simulator](https://github.com/lf-lang/reactor-c/blob/main/util/sensor_simulator.h)). Also, in federated execution, these functions identify which federate is producing the message. The functions are listed below. The arguments for all of these are identical to `printf` with the exception that a trailing newline is automatically added and therefore need not be included in the format string.
 
-- `LF_PRINT_DEBUG(format, ...)`: Use this for verbose messages that are only needed during debugging. Nothing is printed unless the [target](<../introduction#logging>) parameter `logging` is set to `debug`. THe overhead is minimized when nothing is to be printed.
+- `LF_PRINT_DEBUG(format, ...)`: Use this for verbose messages that are only needed during debugging. Nothing is printed unless the [target](<../introduction.md#logging>) parameter `logging` is set to `debug`. THe overhead is minimized when nothing is to be printed.
 
-- `LF_PRINT_LOG(format, ...)`: Use this for messages that are useful logs of the execution. Nothing is printed unless the [target parameter `logging`](<../introduction#logging>) is set to `log` or `debug`. This is a macro so that overhead is minimized when nothing is to be printed.
+- `LF_PRINT_LOG(format, ...)`: Use this for messages that are useful logs of the execution. Nothing is printed unless the [target parameter `logging`](<../introduction.md#logging>) is set to `log` or `debug`. This is a macro so that overhead is minimized when nothing is to be printed.
 
-- `lf_print(format, ...)`: Use this for messages that should normally be printed but may need to be redirected to a user interface such as a window or terminal (see `register_print_function` below). These messages can be suppressed by setting the [logging target property](<../introduction#logging>) to `warn` or `error`.
+- `lf_print(format, ...)`: Use this for messages that should normally be printed but may need to be redirected to a user interface such as a window or terminal (see `register_print_function` below). These messages can be suppressed by setting the [logging target property](<../introduction.md#logging>) to `warn` or `error`.
 
-- `lf_print_warning(format, ...)`: Use this for warning messages. These messages can be suppressed by setting the [logging target property](<../introduction#logging>) to `error`.
+- `lf_print_warning(format, ...)`: Use this for warning messages. These messages can be suppressed by setting the [logging target property](<../introduction.md#logging>) to `error`.
 
-- `lf_print_error(format, ...)`: Use this for error messages. These messages are not suppressed by any [logging target property](<../introduction#logging>).
+- `lf_print_error(format, ...)`: Use this for error messages. These messages are not suppressed by any [logging target property](<../introduction.md#logging>).
 
 - `lf_print_error_and_exit(format, ...)`: Use this for catastrophic errors.
 
@@ -2771,7 +2771,7 @@ Which type of messages are actually produced by the compiled program can be cont
 </ShowIf>
 <ShowIf py>
 
-The Python supports the [logging](<../introduction#logging>) target specification. This will cause the runtime to produce more or less information about the execution. However, user-facing functions for different logging levels are not yet implemented (see issue [#619](https://github.com/lf-lang/lingua-franca/issues/619)).
+The Python supports the [logging](<../introduction.md#logging>) target specification. This will cause the runtime to produce more or less information about the execution. However, user-facing functions for different logging levels are not yet implemented (see issue [#619](https://github.com/lf-lang/lingua-franca/issues/619)).
 
 </ShowIf>
 <ShowIf ts>
@@ -2788,7 +2788,7 @@ The executable reacts to the environment variable `RUST_LOG`, which sets the log
 
 Error and warning logs are on by default. Enabling a level enables all greater levels (i.e., `RUST_LOG=info` also enables `warn` and `error`, but not `trace` or `debug`).
 
-Logging can also be turned on with the `--log-level` CLI option, if the application features a [CLI](<../introduction#command-line-arguments>).
+Logging can also be turned on with the `--log-level` CLI option, if the application features a [CLI](<../introduction.md#command-line-arguments>).
 
 Note that the `logging` target property is ignored, as its levels do not match the Rust standard levels we use (those of the [`log` crate](https://docs.rs/log/)).
 
@@ -2962,7 +2962,7 @@ primitives and sleep functions.
 
 ### Multithreaded Implementation
 
-By default, the C runtime system uses multiple worker threads in order to take advantage of multicore execution. The number of worker threads will match the number of cores on the machine unless the `workers` argument is given in the [target](<../introduction#threading>) statement or the `--workers` [command-line argument](<../introduction#command-line-arguments>) is given.
+By default, the C runtime system uses multiple worker threads in order to take advantage of multicore execution. The number of worker threads will match the number of cores on the machine unless the `workers` argument is given in the [target](<../introduction.md#threading>) statement or the `--workers` [command-line argument](<../introduction.md#command-line-arguments>) is given.
 
 Upon initialization, the main thread will create the specified number of worker threads.
 Execution proceeds in a manner similar to the [single threaded implementation](#single-threaded-implementation)
@@ -2971,17 +2971,17 @@ The execution algorithm ensures that no reaction executes until all reactions th
 
 ### Single Threaded Implementation
 
-By giving the `single-threaded` [target option](<../introduction#single-threaded>) or the `--single-threaded` [command-line argument](<../introduction#command-line-arguments>), the generated program will execute the program using only a single thread. This option is most useful for creating programs to run on bare-metal microprocessors that have no threading support. On such platforms, mutual exclusion is typically realized by disabling interrupts.
+By giving the `single-threaded` [target option](<../introduction.md#single-threaded>) or the `--single-threaded` [command-line argument](<../introduction.md#command-line-arguments>), the generated program will execute the program using only a single thread. This option is most useful for creating programs to run on bare-metal microprocessors that have no threading support. On such platforms, mutual exclusion is typically realized by disabling interrupts.
 
 The execution strategy is to have two queues of pending accessor invocations, one that is sorted by
 tag (the **event queue**) and one that is sorted by priority (the **reaction queue**).
 Execution proceeds as follows:
 
 1. At initialization, an event for each timer is put on the event queue and logical time is initialized to the current time, represented as the number of nanoseconds elapsed since January 1, 1970.
 
-2. At each logical time, pull all events from event queue that have the same earliest tag, find the reactions that these events trigger, and put them on the reaction queue. If there are no events on the event queue, then exit the program (unless the `--keepalive true` [command-line argument](<../introduction#command-line-arguments>) is given).
+2. At each logical time, pull all events from event queue that have the same earliest tag, find the reactions that these events trigger, and put them on the reaction queue. If there are no events on the event queue, then exit the program (unless the `--keepalive true` [command-line argument](<../introduction.md#command-line-arguments>) is given).
 
-3. Wait until physical time matches or exceeds that earliest timestamp (unless the `--fast true` [command-line argument](<../introduction#command-line-arguments>) is given). Then advance logical time to match that earliest timestamp.
+3. Wait until physical time matches or exceeds that earliest timestamp (unless the `--fast true` [command-line argument](<../introduction.md#command-line-arguments>) is given). Then advance logical time to match that earliest timestamp.
 
 4. Execute reactions in order of priority from the reaction queue. These reactions may produce outputs, which results in more events getting put on the reaction queue. Those reactions are assured of having lower priority than the reaction that is executing. If a reaction calls `lf_schedule()`, an event will be put on the event queue, not the reaction queue.
 
@@ -2995,7 +2995,7 @@ Unlike the C target, the Cpp target implements more of the analysis and setup of
 </ShowIf>
 <ShowIf py>
 
-The Python target is built on top of the C runtime to enable maximum efficiency where possible. It uses the single-threaded C runtime by default but will switch to the multi-threaded C runtime if a physical action is detected. The [threading](<../introduction#threading>) target property can be used to override this behavior.
+The Python target is built on top of the C runtime to enable maximum efficiency where possible. It uses the single-threaded C runtime by default but will switch to the multi-threaded C runtime if a physical action is detected. The [threading](<../introduction.md#threading>) target property can be used to override this behavior.
 
 Running [lfc](../tools/command-line-tools.mdx) on a `XXX.lf` program that uses the Python target specification on a
 Linux machine will create the following files (other operating systems will have
@@ -3347,11 +3347,11 @@ target Rust {
 }
 ```
 
-See [Target Declaration](../introduction) for the full list of supported target properties.
+See [Target Declaration](../introduction.md) for the full list of supported target properties.
 
 ### The Executable
 
-The executable name is the name of the main reactor _transformed to snake_case_: `main reactor RustProgram` will generate `rust_program`. See [Command-Line Arguments](<../introduction#command-line-arguments>) for details.
+The executable name is the name of the main reactor _transformed to snake_case_: `main reactor RustProgram` will generate `rust_program`. See [Command-Line Arguments](<../introduction.md#command-line-arguments>) for details.
 
 ### File layout
 

docs/reference/tracing.mdx

@@ -13,7 +13,7 @@ import {
 
 Tracing is a powerful tool when it comes to analysis and debugging of applications. Unfortunately, most tracing tools that are readily available are designed specifically for analyzing processes, threads and system calls. Specialized tools are required to enable analysis that is tailored to an alternative model of computation such as Reactors. The tools should be capable of understanding the fundamental concepts of the model, such as the distinction between logical and physical time, as well as structural units such as reactors and reactions. This page gives an overview of the currently supported trace mechanism, as well as an outline of alternative tools that could be useful in the future.
 
-Tracing is different from [logging](<../introduction#logging>). Logging produces human-readable output in textual form and incurs significant overhead. Tracing produces binary data that must be further processed to be useful and is designed to have minimal impact on the execution time of a program.
+Tracing is different from [logging](<../introduction.md#logging>). Logging produces human-readable output in textual form and incurs significant overhead. Tracing produces binary data that must be further processed to be useful and is designed to have minimal impact on the execution time of a program.
 
 Tracing is currently supported in the C, Python, and C++ targets. The mechanism used in C and Python is different from that used in C++. Tracing in C++ requires third-party tools that may only be available in Linux. Tracing in C and Python does not require any third-party tools.
 

docs/writing-reactors/a-first-reactor.mdx

@@ -23,7 +23,7 @@ import TS_HelloWorld from '../assets/code/ts/src/HelloWorld.lf';
 
 <NoSelectorTargetCodeBlock c={C_HelloWorld} cpp={Cpp_HelloWorld} py={Py_HelloWorld} rs={Rs_HelloWorld} ts={TS_HelloWorld} lf />
 
-Every Lingua Franca program begins with a [target declaration](../introduction) that specifies the language in which reactions are written. This is also the language of the program(s) generated by the Lingua Franca code generator.
+Every Lingua Franca program begins with a [target declaration](../introduction.md) that specifies the language in which reactions are written. This is also the language of the program(s) generated by the Lingua Franca code generator.
 
 Every LF program also has a `main` or `federated` (depending on the target support) reactor, which is the top level of a hierarchy of contained and interconnected reactors. The above simple example has no contained reactors.
 

docs/writing-reactors/actions.mdx

@@ -133,7 +133,7 @@ Action triggered at logical time 603669000 nsec after start.
 ...
 ```
 
-Here, logical time is lagging physical time by a few milliseconds. Note that, unless the [fast option](<../introduction#fast>) is given, logical time _t_ chases physical time _T_, so _t_ < _T_. Hence, the event being scheduled in the reaction to input `x` is assured of being in the future in logical time.
+Here, logical time is lagging physical time by a few milliseconds. Note that, unless the [fast option](<../introduction.md#fast>) is given, logical time _t_ chases physical time _T_, so _t_ < _T_. Hence, the event being scheduled in the reaction to input `x` is assured of being in the future in logical time.
 
 Whereas logical actions are required to be scheduled within a reaction of the reactor that declares the action, physical actions can be scheduled by code that is outside the Lingua Franca system. For example, some other thread or a callback function may call `schedule()`, passing it a physical action. For example:
 

docs/writing-reactors/termination.mdx

@@ -29,7 +29,7 @@ We address each of these in turn.
 
 ## Timeout
 
-The [target property `timeout`](<../introduction#timeout>) specifies the last logical time at which reactions should be triggered. The last invocation of reactions will be at tag (`timeout`, 0).
+The [target property `timeout`](<../introduction.md#timeout>) specifies the last logical time at which reactions should be triggered. The last invocation of reactions will be at tag (`timeout`, 0).
 
 There is a significant subtlety when using [physical connections](<../writing-reactors/composing-reactors.mdx#physical-connections>), which are connections using the syntax `~>`. Such connections specify that the tag at the receiving end will be based on the physical time at which the message is received. If the tag assigned at the receiving end is greater than the final tag, then the message is lost. Hence, **messages sent near the `timeout` time are likely to be lost!**
 

docs/writing-reactors/time-and-timers.mdx

@@ -15,7 +15,7 @@ import {
 
 A key property of Lingua Franca is **logical time**. All events occur at an instant in logical time. By default, the runtime system does its best to align logical time with **physical time**, which is some measurement of time on the execution platform. The **lag** is defined to be physical time minus logical time, and the goal of the runtime system is maintain a small non-negative lag.
 
-The **lag** is allowed to go negative only if the [`fast` target property](<../introduction#fast>) or the [`--fast`](<../introduction#command-line-arguments>) command-line argument is set to `true`. In that case, the program will execute as fast as possible with no regard to physical time.
+The **lag** is allowed to go negative only if the [`fast` target property](<../introduction.md#fast>) or the [`--fast`](<../introduction.md#command-line-arguments>) command-line argument is set to `true`. In that case, the program will execute as fast as possible with no regard to physical time.
 
 <ShowOnly c cpp rs>
 
@@ -165,7 +165,7 @@ A reaction is always invoked at a well-defined logical time, and logical time do
 
 ## Timeout
 
-By default, a Lingua Franca program will terminate when there are no more events to process. If there is a timer with a non-zero period, then there will always be more events to process, so the default execution will be unbounded. To specify a finite execution horizon, you can either specify a [`timeout` target property](<../introduction#timeout>) or a [`--timeout` command-line option](<../introduction#command-line-arguments>). For example, the following `timeout` property will cause the above timer with a period of one second to terminate after 11 events:
+By default, a Lingua Franca program will terminate when there are no more events to process. If there is a timer with a non-zero period, then there will always be more events to process, so the default execution will be unbounded. To specify a finite execution horizon, you can either specify a [`timeout` target property](<../introduction.md#timeout>) or a [`--timeout` command-line option](<../introduction.md#command-line-arguments>). For example, the following `timeout` property will cause the above timer with a period of one second to terminate after 11 events:
 
 <NoSelectorTargetCodeBlock lf
   c={`target C {