@eagleoutice/flowr 2.2.2 → 2.2.4

package/documentation/print-interface-wiki.js

@@ -24,6 +24,7 @@ const pipeline_executor_1 = require("../core/pipeline-executor");
 const doc_structure_1 = require("./doc-util/doc-structure");
 const doc_types_1 = require("./doc-util/doc-types");
 const path_1 = __importDefault(require("path"));
+const tree_sitter_executor_1 = require("../r-bridge/lang-4.x/tree-sitter/tree-sitter-executor");
 async function explainServer(shell) {
     (0, doc_data_server_messages_1.documentAllServerMessages)();
     return `
@@ -133,7 +134,7 @@ use ${(0, doc_cli_option_1.getReplCommand)('dataflow*')} (or ${(0, doc_cli_optio
 
 ${await (0, doc_repl_1.documentReplSession)(shell, [{
             command: ':dataflow* y <- 1 + x',
-            description: `Retrieve the dataflow graph of the expression \`y <- 1 + x\`. It looks like this:\n${await (0, doc_dfg_1.printDfGraphForCode)(shell, 'y <- 1 + x')}.`
+            description: `Retrieve the dataflow graph of the expression \`y <- 1 + x\`. It looks like this:\n${await (0, doc_dfg_1.printDfGraphForCode)(shell, 'y <- 1 + x')}`
         }])}
 
 For the slicing with ${(0, doc_cli_option_1.getReplCommand)('slicer')}, you have access to the same [magic comments](#slice-magic-comments) as with the [slice request](#message-request-slice).
@@ -239,7 +240,7 @@ ${(0, schema_1.describeSchema)(config_1.flowrConfigFileSchema, ansi_1.markdownFo
 }
 function explainWritingCode(shell) {
     const types = (0, doc_types_1.getTypesFromFolderAsMermaid)({
-        rootFolder: path_1.default.resolve('./src/r-bridge/'),
+        rootFolder: path_1.default.resolve('./src/'),
         files: [path_1.default.resolve('./src/core/pipeline-executor.ts'), path_1.default.resolve('./src/core/steps/pipeline/default-pipelines.ts')],
         typeName: 'RShell',
         inlineTypes: doc_types_1.mermaidHide
@@ -251,20 +252,26 @@ _flowR_ can be used as a [module](${doc_files_1.FlowrNpmRef}) and offers several
 ### Using the ${(0, doc_types_1.shortLink)(shell_1.RShell.name, types.info)} to Interact with R
 
 The ${(0, doc_types_1.shortLink)(shell_1.RShell.name, types.info)} class allows interfacing with the \`R\`&nbsp;ecosystem installed on the host system.
-Please have a look at [flowR's engines](${doc_files_1.FlowrWikiBaseRef}/Engines) for more information on alterantives.
+Please have a look at [flowR's engines](${doc_files_1.FlowrWikiBaseRef}/Engines) for more information on alterantives (for example, the ${(0, doc_types_1.shortLink)(tree_sitter_executor_1.TreeSitterExecutor.name, types.info)}).
 
-> [!IMPORTANT]
-> Each ${(0, doc_types_1.shortLink)(shell_1.RShell.name, types.info)} controls a new instance of the R&nbsp;interpreter, make sure to call <code>${(0, doc_types_1.shortLink)(shell_1.RShell.name, types.info, false)}::${shell.close.name}()</code> when you’re done.
+${(0, doc_structure_1.block)({
+        type: 'IMPORTANT',
+        content: `
+Each ${(0, doc_types_1.shortLink)(shell_1.RShell.name, types.info)} controls a new instance of the R&nbsp;interpreter, 
+make sure to call ${(0, doc_code_1.codeInline)((0, doc_types_1.shortLink)(shell_1.RShell.name + '::' + shell.close.name, types.info, false, 'i') + '()')} when you are done.`
+    })}
 
-You can start a new "session" simply by constructing a new object with <code>new ${(0, doc_types_1.shortLink)(shell_1.RShell.name, types.info, false)}()</code>.
+You can start a new "session" simply by constructing a new object with ${(0, doc_code_1.codeInline)('new ' + (0, doc_types_1.shortLink)(shell_1.RShell.name, types.info, false) + '()')}.
 
-However, there are several options that may be of interest (e.g., to automatically revive the shell in case of errors or to control the name location of the R process on the system).
+However, there are several options that may be of interest 
+(e.g., to automatically revive the shell in case of errors or to control the name location of the R process on the system).
 
-With a shell object (let's call it \`shell\`), you can execute R code by using <code>${(0, doc_types_1.shortLink)(shell_1.RShell.name, types.info, false)}::${shell.sendCommand.name}</code>, 
-for example \`shell.${shell.sendCommand.name}("1 + 1")\`. 
-However, this does not return anything, so if you want to collect the output of your command, use <code>${(0, doc_types_1.shortLink)(shell_1.RShell.name, types.info, false)}::${shell.sendCommandWithOutput.name}</code> instead.
+With a shell object (let's call it \`shell\`), you can execute R code by using ${(0, doc_types_1.shortLink)(shell_1.RShell.name + '::' + shell.sendCommand.name, types.info, true, 'i')}, 
+for example ${(0, doc_code_1.codeInline)('shell.' + (0, doc_types_1.shortLink)(shell_1.RShell.name + ':::' + shell.sendCommand.name, types.info, false) + '("1 + 1")')}. 
+However, this does not return anything, so if you want to collect the output of your command, use
+${(0, doc_types_1.shortLink)(shell_1.RShell.name + '::' + shell.sendCommandWithOutput.name, types.info, true, 'i')} instead.
 
-Besides that, the command <code>${(0, doc_types_1.shortLink)(shell_1.RShell.name, types.info, false)}::${shell.tryToInjectHomeLibPath.name}</code> may be of interest, as it enables all libraries available on the host system.
+Besides that, the command ${(0, doc_types_1.shortLink)(shell_1.RShell.name + '::' + shell.tryToInjectHomeLibPath.name, types.info)} may be of interest, as it enables all libraries available on the host system.
 
 ### The Pipeline Executor
 
@@ -284,22 +291,21 @@ const slice = await slicer.allRemainingSteps()
 // console.log(slice.reconstruct.code)
 `)}
 
-<details>
-
-<summary style='color:gray'>More Information</summary>
+${(0, doc_structure_1.details)('More Information', `
 
 If you compare this, with what you would have done with the old (and removed) \`SteppingSlicer\`, 
 this essentially just requires you to replace the \`SteppingSlicer\` with the ${(0, doc_types_1.shortLink)(pipeline_executor_1.PipelineExecutor.name, types.info)}
 and to pass the ${(0, doc_types_1.shortLink)('DEFAULT_SLICING_PIPELINE', types.info)} as the first argument.
 The ${(0, doc_types_1.shortLink)(pipeline_executor_1.PipelineExecutor.name, types.info)}...
 
-1. allows investigating the results of all intermediate steps
+1. Provides structures to investigate the results of all intermediate steps
 2. Can be executed step-by-step
 3. Can repeat steps (e.g., to calculate multiple slices on the same input)
 
 See the in-code documentation for more information.
 
-</details>
+	`)}
+
 
 ### Generate Statistics
 

package/documentation/print-linting-and-testing-wiki.js

@@ -1,11 +1,24 @@
 "use strict";
+var __importDefault = (this && this.__importDefault) || function (mod) {
+    return (mod && mod.__esModule) ? mod : { "default": mod };
+};
 Object.defineProperty(exports, "__esModule", { value: true });
 const log_1 = require("../../test/functionality/_helper/log");
 const doc_code_1 = require("./doc-util/doc-code");
 const doc_files_1 = require("./doc-util/doc-files");
 const doc_structure_1 = require("./doc-util/doc-structure");
+const doc_types_1 = require("./doc-util/doc-types");
+const path_1 = __importDefault(require("path"));
+const doc_auto_gen_1 = require("./doc-util/doc-auto-gen");
 function getText() {
-    return `
+    const { info } = (0, doc_types_1.getTypesFromFolderAsMermaid)({
+        rootFolder: path_1.default.resolve('./test'),
+        files: [path_1.default.resolve('./src/dataflow/graph/dataflowgraph-builder.ts')],
+        typeName: 'parameter',
+        inlineTypes: doc_types_1.mermaidHide
+    });
+    return `${(0, doc_auto_gen_1.autoGenHeader)({ filename: module.filename, purpose: 'linting and testing definitions' })}
+
 For the latest code coverage information, see [codecov.io](${doc_files_1.FlowrCodecovRef}), 
 for the latest benchmark results, see the [benchmark results](${doc_files_1.FlowrSiteBaseRef}/wiki/stats/benchmark) wiki page.
 
@@ -53,7 +66,7 @@ If you want to run the tests without the watch mode, you can use:
 
 ${(0, doc_code_1.codeBlock)('shell', 'npm run test -- --no-watch')}
 
-To run all tests, including a coverage report and label summary, run: 
+To run all tests, including a coverage report and label summary, run:
 
 ${(0, doc_code_1.codeBlock)('shell', 'npm run test-full')}
 
@@ -64,7 +77,7 @@ It is up to the [ci](#ci-pipeline) to run the tests on different systems to ensu
 
 #### Test Structure
 
-All functionality tests are to be located under [test/functionality](${doc_files_1.RemoteFlowrFilePathBaseRef}test/functionality).
+All functionality tests are to be located under [test/functionality](${doc_files_1.RemoteFlowrFilePathBaseRef}/test/functionality).
 
 This folder contains three special and important elements:
 
@@ -76,19 +89,23 @@ ${(0, doc_structure_1.block)({
         type: 'WARNING',
         content: `
 We name all test files using the \`.test.ts\` suffix and try to run them in parallel.
-Whenever this is not possible (e.g., when using \`withShell\`), please use \`describe.sequential\`
+Whenever this is impossible (e.g., when using ${(0, doc_types_1.shortLink)('withShell', info)}), please use _\`describe.sequential\`_
 to disable parallel execution for the respective test (otherwise, such tests are flaky).
 `
     })}
 
 #### Writing a Test
 
-Currently, this is heavily dependent on what you want to test (normalization, dataflow, quad-export, ...) 
+Currently, this is heavily dependent on what you want to test (normalization, dataflow, quad-export, …) 
 and it is probably best to have a look at existing tests in that area to get an idea of what comfort functionality is available.
 
-Generally, tests should be [labeled](${doc_files_1.RemoteFlowrFilePathBaseRef}test/functionality/_helper/label.ts) according to the *flowR* capabilities they test. The set of currently supported capabilities and their IDs can be found in ${(0, doc_files_1.getFilePathMd)('../r-bridge/data/data.ts')}. The resulting labels are used in the test report that is generated as part of the test output. They group tests by the capabilities they test and allow the report to display how many tests ensure that any given capability is properly supported. 
+Generally, tests should be [labeled](${doc_files_1.RemoteFlowrFilePathBaseRef}test/functionality/_helper/label.ts) according to the *flowR* capabilities they test. 
+The set of currently supported capabilities and their IDs can be found in ${(0, doc_files_1.getFilePathMd)('../r-bridge/data/data.ts')}. 
+The resulting labels are used in the test report that is generated as part of the test output. 
+They group tests by the capabilities they test and allow the report to display how many tests ensure that any given capability is properly supported.
 
-Various helper functions are available to ease in writing tests with common behaviors, like testing for dataflow, slicing or query results. These can be found in [the \`_helper\` subdirectory](${doc_files_1.RemoteFlowrFilePathBaseRef}test/functionality/_helper).
+Various helper functions are available to ease in writing tests with common behaviors, like testing for dataflow, slicing or query results. 
+These can be found in [the \`_helper\` subdirectory](${doc_files_1.RemoteFlowrFilePathBaseRef}test/functionality/_helper).
 
 For example, an [existing test](${doc_files_1.RemoteFlowrFilePathBaseRef}test/functionality/dataflow/processing-of-elements/atomic/dataflow-atomic.test.ts) that tests the dataflow graph of a simple variable looks like this:
 ${(0, doc_code_1.codeBlock)('typescript', `
@@ -96,11 +113,14 @@ assertDataflow(label('simple variable', ['name-normal']), shell,
 	'x', emptyGraph().use('0', 'x')
 );
 `)}
+Have a look at ${(0, doc_types_1.shortLink)('assertDataflow', info)}, ${(0, doc_types_1.shortLink)('label', info)}, and ${(0, doc_types_1.shortLink)('emptyGraph', info)} for more information.
 
 When writing dataflow tests, additional settings can be used to reduce the amount of graph data that needs to be pre-written. Notably:
 
-- \`expectIsSubgraph\` indicates that the expected graph is a subgraph, rather than the full graph that the test should generate. The test will then only check if the supplied graph is contained in the result graph, rather than an exact match.
-- \`resolveIdsAsCriterion\` indicates that the ids given in the expected (sub)graph should be resolved as [slicing criteria](${doc_files_1.FlowrWikiBaseRef}/Terminology#slicing-criterion) rather than actual ids. For example, passing \`12@a\` as an id in the expected (sub)graph will cause it to be resolved as the corresponding id.
+- ${(0, doc_types_1.shortLink)('expectIsSubgraph', info)} indicates that the expected graph is a subgraph, rather than the full graph that the test should generate. 
+  The test will then only check if the supplied graph is contained in the result graph, rather than an exact match.
+- ${(0, doc_types_1.shortLink)('resolveIdsAsCriterion', info)} indicates that the ids given in the expected (sub)graph should be resolved as [slicing criteria](${doc_files_1.FlowrWikiBaseRef}/Terminology#slicing-criterion) rather than actual ids. 
+  For example, passing \`12@a\` as an id in the expected (sub)graph will cause it to be resolved as the corresponding id.
 
 The following example shows both in use:
 ${(0, doc_code_1.codeBlock)('typescript', `

package/documentation/print-normalized-ast-wiki.js

@@ -19,21 +19,21 @@ const retriever_1 = require("../r-bridge/retriever");
 const visitor_1 = require("../r-bridge/lang-4.x/ast/model/processing/visitor");
 const collect_1 = require("../r-bridge/lang-4.x/ast/model/collect");
 const normalized_ast_fold_1 = require("../abstract-interpretation/normalized-ast-fold");
+const default_pipelines_1 = require("../core/steps/pipeline/default-pipelines");
 async function getText(shell) {
     const rversion = (await shell.usedRVersion())?.format() ?? 'unknown';
     const now = performance.now();
     const types = (0, doc_types_1.getTypesFromFolderAsMermaid)({
-        rootFolder: path_1.default.resolve('./src/r-bridge/lang-4.x/ast/model/'),
-        files: [path_1.default.resolve('./src/abstract-interpretation/normalized-ast-fold.ts'), path_1.default.resolve('./src/core/steps/pipeline/default-pipelines.ts')],
+        rootFolder: path_1.default.resolve('./src'),
         typeName: 'RNode',
         inlineTypes: doc_types_1.mermaidHide
     });
     const elapsed = performance.now() - now;
     return `${(0, doc_auto_gen_1.autoGenHeader)({ filename: module.filename, purpose: 'normalized ast', rVersion: rversion })}
 
-_flowR_ produces a normalized version of R's abstract syntax tree (AST), 
+_flowR_ produces a normalized version of R's abstract syntax tree (AST),
 offering the following benefits:
- 
+
 1. abstract away from intricacies of the R parser
 2. provide a version-independent representation of the program
 3. decorate the AST with additional information, e.g., parent relations and nesting information
@@ -49,12 +49,10 @@ Each edge is labeled with the type of the parent-child relationship (the "role")
 
 ${await (0, doc_normalized_ast_1.printNormalizedAstForCode)(shell, 'x <- 2 * 3 + 1', { showCode: false, prefix: 'flowchart LR\n' })}
 
-&nbsp;
-
 > [!TIP]
 > If you want to investigate the normalized AST, 
 > you can either use the [Visual Studio Code extension](${doc_files_1.FlowrGithubBaseRef}/vscode-flowr) or the ${(0, doc_cli_option_1.getReplCommand)('normalize*')} 
-> command in the REPL (see the [Interface wiki page](${doc_files_1.FlowrWikiBaseRef}/Interface) for more information). 
+> command in the REPL (see the [Interface wiki page](${doc_files_1.FlowrWikiBaseRef}/Interface) for more information).
 
 Indicative of the normalization is the root expression list node, which is present in every normalized AST.
 In general, we provide node types for:
@@ -84,7 +82,7 @@ Most notably, the \`info\` field holds the \`id\` of the node, which is used to
 
 In summary, we have the following types:
 
-${(0, doc_structure_1.details)('Normalized AST Node Types', (0, doc_types_1.printHierarchy)({ program: types.program, hierarchy: types.info, root: 'RNode', collapseFromNesting: Number.MAX_VALUE }))}
+${(0, doc_structure_1.details)('Normalized AST Node Types', (0, doc_types_1.printHierarchy)({ program: types.program, info: types.info, root: 'RNode', collapseFromNesting: Number.MAX_VALUE }))}
 
 The following segments intend to give you an overview of how to work with the normalized AST:
 
@@ -94,7 +92,7 @@ The following segments intend to give you an overview of how to work with the no
 ## How Get a Normalized AST
 
 As explained alongside the [Interface](${doc_files_1.FlowrWikiBaseRef}/Interface#the-pipeline-executor) wiki page, you can use the 
-\`${pipeline_executor_1.PipelineExecutor.name}\` to get the ${(0, doc_types_1.shortLink)('NormalizedAst', types.info)}. If you are only interested in the normalization,
+${(0, doc_types_1.shortLink)(pipeline_executor_1.PipelineExecutor.name, types.info)} to get the ${(0, doc_types_1.shortLink)('NormalizedAst', types.info)}. If you are only interested in the normalization,
 a pipeline like the ${(0, doc_types_1.shortLink)('DEFAULT_NORMALIZE_PIPELINE', types.info)} suffices:
 
 ${(0, doc_code_1.codeBlock)('ts', `
@@ -106,7 +104,7 @@ async function getAst(code: string): Promise<RNode> {
     return result.normalize.ast;
 }`)}
 
-From the REPL, you can use the ${(0, doc_cli_option_1.getReplCommand)('normalize')} command. 
+From the REPL, you can use the ${(0, doc_cli_option_1.getReplCommand)('normalize')} command.
 
 ## Traversing the Normalized AST
 
@@ -114,12 +112,11 @@ We provide two ways to traverse the normalized AST: [Visitors](#visitors) and [F
 
 ### Visitors
 
-If you want a simple visitor which traverses the AST, the \`${visitor_1.visitAst.name}\` function from 
-${(0, doc_files_1.getFilePathMd)('../r-bridge/lang-4.x/ast/model/processing/visitor.ts')} is a good starting point.
+If you want a simple visitor which traverses the AST, the ${(0, doc_types_1.shortLink)(visitor_1.visitAst.name, types.info)} function is a good starting point.
 You may specify functions to be called whenever you enter and exit a node during the traversal, and any
 computation is to be done by side effects.
 For example, if you want to collect all the \`id\`s present within a normalized (sub-)ast,
-as it is done by the ${collect_1.collectAllIds.name} function, you can use the following visitor:
+as it is done by the ${(0, doc_types_1.shortLink)(collect_1.collectAllIds.name, types.info)} function, you can use the following visitor:
 
 ${(0, doc_code_1.codeBlock)('ts', `
 const ids = new Set<NodeId>();
@@ -131,12 +128,12 @@ return ids;
 
 ### Folds
 
-We formulate a fold with the base class \`${normalized_ast_fold_1.DefaultNormalizedAstFold.name}\` in ${(0, doc_files_1.getFilePathMd)('../abstract-interpretation/normalized-ast-fold.ts')}.
+We formulate a fold with the base class ${(0, doc_types_1.shortLink)(normalized_ast_fold_1.DefaultNormalizedAstFold.name, types.info)} in ${(0, doc_files_1.getFilePathMd)('../abstract-interpretation/normalized-ast-fold.ts')}.
 Using this class, you can create your own fold behavior by overwriting the default methods.
 By default, the class provides a monoid abstraction using the _empty_ from the constructor and the _concat_ method.
 
  
-${(0, doc_types_1.printHierarchy)({ program: types.program, hierarchy: types.info, root: 'DefaultNormalizedAstFold' })}
+${(0, doc_types_1.printHierarchy)({ program: types.program, info: types.info, root: 'DefaultNormalizedAstFold' })}
 
 Now, of course, we could provide hundreds of examples here, but we use tests to verify that the fold behaves as expected
 and happily point to them at ${(0, doc_files_1.getFilePathMd)('../../test/functionality/r-bridge/normalize-ast-fold.test.ts')}.
@@ -173,8 +170,8 @@ class MyMathFold<Info> extends ${normalized_ast_fold_1.DefaultNormalizedAstFold.
 }
 `)}
 
-Now, we can use the \`${pipeline_executor_1.PipelineExecutor.name}\` to get the normalized AST and apply the fold:
-  
+Now, we can use the ${(0, doc_types_1.shortLink)(pipeline_executor_1.PipelineExecutor.name, types.info)} to get the normalized AST and apply the fold:
+ 
 ${(0, doc_code_1.codeBlock)('ts', `
 const shell = new ${shell_1.RShell.name}();
 const ast = (await new ${pipeline_executor_1.PipelineExecutor.name}(DEFAULT_NORMALIZE_PIPELINE, {
@@ -185,6 +182,14 @@ const result = new MyMathFold().fold(ast);
 console.log(result); // -> 7
 `)}
 
+${(0, doc_structure_1.block)({
+        type: 'NOTE',
+        content: `
+If you want to retrieve the normalized AST with the [Tree-Sitter Engine](${doc_files_1.FlowrWikiBaseRef}/Engines),
+you may use the ${(0, doc_types_1.shortLink)('TREE_SITTER_NORMALIZE_PIPELINE', types.info)} or directly rely on one of the
+helper functions like ${(0, doc_types_1.shortLink)(default_pipelines_1.createNormalizePipeline.name, types.info)}.
+		`
+    })}
 `;
 }
 /** if we run this script, we want a Markdown representation of the capabilities */

package/documentation/print-query-wiki.js

@@ -59,9 +59,9 @@ Besides this, we provide the following ways to automatically categorize and link
 It's also possible to filter the results based on the following properties:
 
 1. **File** (\`fileFilter\`): This allows you to filter the results based on the file in which the call is located. This can be useful if you are only interested in calls in, e.g., specific folders.
-  The \`fileFilter\` property is an object made up of two properties:
-  - **Filter** (\`filter\`): A regular expression that a node's file attribute must match to be considered.
-  - **Include Undefined Files** (\`includeUndefinedFiles\`): If \`fileFilter\` is set, but a node's file attribute is not present, should we include it in the results? Defaults to \`true\`.
+   The \`fileFilter\` property is an object made up of two properties:
+     - **Filter** (\`filter\`): A regular expression that a node's file attribute must match to be considered.
+     - **Include Undefined Files** (\`includeUndefinedFiles\`): If \`fileFilter\` is set, but a node's file attribute is not present, should we include it in the results? Defaults to \`true\`.
 
 Re-using the example code from above, the following query attaches all calls to \`mean\` to the kind \`visualize\` and the subkind \`text\`,
 all calls that start with \`read_\` to the kind \`input\` but only if they are not locally overwritten, and the subkind \`csv-file\`, and links all calls to \`points\` to the last call to \`plot\`:
@@ -164,7 +164,7 @@ ${await (0, doc_query_1.showQuery)(shell, exampleCode, [{
             }], { showCode: false })}
 
 In this simple scenario, the _lineage_ is equivalent to the slice (and in-fact the complete code). 
-In general the lineage is smaller and makes no executability guarantees. 
+In general the lineage is smaller and makes no guarantees on executability. 
 It is just a quick and neither complete nor sound way to get information on where the variable originates from.
 
 This query replaces the old [\`request-lineage\`](${doc_files_1.FlowrWikiBaseRef}/Interface#message-request-lineage) message.
@@ -368,7 +368,7 @@ ${await (0, doc_query_1.showQuery)(shell, exampleCode, [{
                 criteria: ['3@x']
             }], { showCode: false })}
 
-In general you may be uninterested in seeing the reconstructed version and want to save some computation time, for this,
+In general, you may be uninterested in seeing the reconstructed version and want to save some computation time, for this,
 you can use the \`noReconstruction\` flag.
 
 ${(0, doc_structure_1.details)('No Reconstruction Example', await (0, doc_query_1.showQuery)(shell, exampleCode, [{
@@ -449,7 +449,7 @@ ${await (0, doc_query_1.showQuery)(shell, longerCode, [{
         });
         const exampleCode = 'x + 1\nx * 2';
         return `
-A query like the ${(0, doc_query_1.linkToQueryOfName)('id-map')} query can return a really big result, especially for larger scripts.
+A query like the ${(0, doc_query_1.linkToQueryOfName)('id-map')} query can return a huge result, especially for larger scripts.
 If you are not interested in all of the information contained within the full map, you can use the location map query to get a simple mapping of ids to their location in the source file.   
 
 Consider you have the following code:
@@ -489,7 +489,7 @@ Queries are JSON arrays of query objects, each of which uses a \`type\` property
 In general, we separate two types of queries:
 
 1. **Active Queries**: Are exactly what you would expect from a query (e.g., the ${(0, doc_query_1.linkToQueryOfName)('call-context')}). They fetch information from the dataflow graph.
-2. **Virtual Queries**: Are used to structure your queries (e.g., the ${(0, doc_query_1.linkToQueryOfName)('compound')}). 
+2. **Virtual Queries**: Are used to structure your queries (e.g., the ${(0, doc_query_1.linkToQueryOfName)('compound')}).
 
 We separate these from a concept perspective. 
 For now, we support the following **active** queries (which we will refer to simply as a \`query\`):

package/documentation/print-readme.d.ts

@@ -0,0 +1 @@
+export {};

package/documentation/print-readme.js

@@ -0,0 +1,160 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+const shell_1 = require("../r-bridge/shell");
+const log_1 = require("../../test/functionality/_helper/log");
+const tree_sitter_executor_1 = require("../r-bridge/lang-4.x/tree-sitter/tree-sitter-executor");
+const doc_files_1 = require("./doc-util/doc-files");
+const doc_code_1 = require("./doc-util/doc-code");
+const doc_cli_option_1 = require("./doc-util/doc-cli-option");
+const doc_benchmarks_1 = require("./doc-util/doc-benchmarks");
+const numbers_1 = require("../util/numbers");
+const html_hover_over_1 = require("../util/html-hover-over");
+const doc_structure_1 = require("./doc-util/doc-structure");
+const doc_repl_1 = require("./doc-util/doc-repl");
+const doc_auto_gen_1 = require("./doc-util/doc-auto-gen");
+const doc_general_1 = require("./doc-util/doc-general");
+const doc_dfg_1 = require("./doc-util/doc-dfg");
+async function getText(shell) {
+    const dateOptions = { year: 'numeric', month: 'short', day: 'numeric' };
+    return `
+[![flowR logo](https://raw.githubusercontent.com/wiki/flowr-analysis/flowr/img/flowR.png)](${doc_files_1.FlowrGithubBaseRef}/flowr/wiki)\\
+[![QA (and potentially deploy)](${doc_files_1.FlowrGithubBaseRef}/flowr/actions/workflows/qa.yaml/badge.svg)](${doc_files_1.FlowrGithubBaseRef}/flowr/actions/workflows/qa.yaml)
+[![codecov](https://codecov.io/gh/flowr-analysis/flowr/graph/badge.svg)](https://codecov.io/gh/flowr-analysis/flowr)
+[![Docker Image Version (latest semver)](https://img.shields.io/docker/v/eagleoutice/flowr?logo=docker&logoColor=white&label=dockerhub)](${doc_files_1.FlowrDockerRef})
+[![latest tag](https://badgen.net/github/tag/flowr-analysis/flowr?label=latest&color=purple)](${doc_files_1.FlowrGithubBaseRef}/flowr/releases/latest)
+[![Marketplace](https://badgen.net/vs-marketplace/v/code-inspect.vscode-flowr)](${doc_files_1.FlowrVsCode})
+[![DOI](https://zenodo.org/badge/624819038.svg)](https://zenodo.org/doi/10.5281/zenodo.13319290)
+
+_flowR_ is a sophisticated, static [dataflow analyzer](https://en.wikipedia.org/wiki/Data-flow_analysis) for the [R programming language](https://www.r-project.org/).
+It offers a wide variety of features, for example:
+
+* 🍕 **program slicing**\\
+   Given a point of interest like the visualization of a plot, _flowR_ reduces the program to just the parts which are relevant
+   for the computation of the point of interest.
+
+${(0, doc_general_1.prefixLines)((0, doc_structure_1.details)('Example: Slicing with flowR', `
+The simplest way to retrieve slices is with flowR's [Visual Studio Code extension](${doc_files_1.FlowrVsCode}). 
+However, you can slice using the [REPL](${doc_files_1.FlowrWikiBaseRef}/Interface#using-the-repl) as well.
+This can help you if you want to reuse specific parts of an existing analysis within another context or if you want to understand
+what is happening in the code.
+
+For this, let's have a look at the example file, located at ${(0, doc_files_1.linkFlowRSourceFile)('test/testfiles/example.R')}:
+
+${(0, doc_code_1.codeBlock)('r', (0, doc_files_1.getFileContentFromRoot)('test/testfiles/example.R'))}
+
+Let's suppose we are interested only in the sum which is printed in line 11.
+To get a slice for this, you can use the following command:
+
+${await (0, doc_repl_1.documentReplSession)(shell, [{
+            command: ':slicer test/testfiles/example.R --criterion "11@sum"',
+            description: ''
+        }])}
+   
+   `), '    ')}
+
+* 📚 **dependency analysis**\\
+  Given your analysis project, flowR offers a plethora of so-called [queries](${doc_files_1.FlowrWikiBaseRef}/Query-API) to get more information about your code.
+  An important query is the [dependencies query](${doc_files_1.FlowrWikiBaseRef}/Query-API#dependencies-query), which shows you the library your project needs,
+  the data files it reads, the scripts it sources, and the data it outputs.
+  
+  ${(0, doc_general_1.prefixLines)((0, doc_structure_1.details)('Example: Dependency Analysis with flowR', `
+The following showcases the dependency view of the [Visual Studio Code extension](${doc_files_1.FlowrVsCode}):
+
+![Dependency Analysis](https://raw.githubusercontent.com/flowr-analysis/vscode-flowr/refs/heads/main/media/dependencies.png)
+  
+  `), '    ')}
+
+* 🚀 **fast data and control-flow graphs**\\
+  Within just ${'<i>' + (0, html_hover_over_1.textWithTooltip)((0, numbers_1.roundToDecimals)(await (0, doc_benchmarks_1.getLatestDfAnalysisTime)('"social-science" Benchmark Suite (tree-sitter)'), 1) + ' ms</i>', 'This measurement is automatically fetched from the latest benchmarks!')} (as of ${new Date(await (0, doc_benchmarks_1.getLastBenchmarkUpdate)()).toLocaleDateString('en-US', dateOptions)}), 
+  _flowR_ can analyze the data- and control-flow of the average real-world R script. See the [benchmarks](https://flowr-analysis.github.io/flowr/wiki/stats/benchmark) for more information,
+  and consult the [wiki pages](${doc_files_1.FlowrWikiBaseRef}/Dataflow-Graph) for more details on the dataflow graph.
+
+${(0, doc_general_1.prefixLines)((0, doc_structure_1.details)('Example: Generating a dataflow graph with flowR', `
+You can investigate flowR's analyses using the [REPL](${doc_files_1.FlowrWikiBaseRef}/Interface#using-the-repl).
+Commands like ${(0, doc_cli_option_1.getReplCommand)('dataflow*')} allow you to view a dataflow graph for a given R script.
+
+Let's have a look at the following example:
+
+${(0, doc_code_1.codeBlock)('r', (0, doc_files_1.getFileContentFromRoot)('test/testfiles/example.R'))}
+
+To get the dataflow graph for this script, you can use the following command:
+
+${await (0, doc_repl_1.documentReplSession)(shell, [{
+            command: ':dataflow* test/testfiles/example.R',
+            description: `
+Following the link output should show the following:
+${await (0, doc_dfg_1.printDfGraphForCode)(shell, (0, doc_files_1.getFileContentFromRoot)('test/testfiles/example.R'), { showCode: false })}`
+        }])}
+   
+   `), '    ')}
+
+If you want to use flowR and the features it provides, feel free to check out the:
+
+- [Visual Studio Code extension](${doc_files_1.FlowrVsCode}): provides access to flowR's capabilities directly in VS Code (also works in [vscode.dev](https://vscode.dev/))
+- [RStudio Addin](${doc_files_1.FlowrGithubBaseRef}/rstudio-addin-flowr): integrates flowR into [RStudio](https://posit.co/downloads/)
+- [R package](${doc_files_1.FlowrGithubBaseRef}/flowr-r-adapter): allows you to use flowR in your R scripts
+- [Docker image](${doc_files_1.FlowrDockerRef}): run flowR in a container, this also includes [flowR's server](${doc_files_1.FlowrWikiBaseRef}/Interface#communicating-with-the-server)
+- [NPM package](${doc_files_1.FlowrNpmRef}): include flowR in your TypeScript and JavaScript projects (e.g., used for the VS Code extension)
+ 
+## ⭐ Getting Started
+
+To get started with _flowR_ and its features, please check out the [Overview](${doc_files_1.FlowrGithubBaseRef}/flowr/wiki/Overview) wiki page. 
+The [Setup](${doc_files_1.FlowrGithubBaseRef}/flowr/wiki/Setup) wiki page explains how you can download and setup _flowR_ on your system. 
+With docker&nbsp;🐳️, the following line should be enough (and drop you directly into the read-eval-print loop):
+
+${(0, doc_code_1.codeBlock)('shell', 'docker run -it --rm eagleoutice/flowr')}
+
+You can enter ${(0, doc_cli_option_1.getReplCommand)('help')} to gain more information on its capabilities.
+
+<details>
+
+<summary>Example REPL session</summary>
+
+![Example of a simple REPL session](wiki/gif/repl-demo.gif)
+
+</details>
+
+## 📜 More Information
+
+For more details on how to use _flowR_ please refer to the [wiki pages](${doc_files_1.FlowrGithubBaseRef}/flowr/wiki),
+as well as the deployed [code documentation](https://flowr-analysis.github.io/flowr/doc/).
+
+## 🚀 Contributing
+
+We welcome every contribution! Please check out the [contributing guidelines](${doc_files_1.FlowrGithubBaseRef}/flowr/tree/main/.github/CONTRIBUTING.md) for more information.
+
+### Contributors
+
+<a href="https://github.com/flowr-analysis/flowr/graphs/contributors">
+  <img src="https://contrib.rocks/image?repo=flowr-analysis/flowr"  alt="flowR Contributors"/>
+</a>
+
+----
+
+*flowr* is actively developed by [Florian Sihler](https://eagleoutice.github.io/portfolio/) under the
+[GPLv3 License](LICENSE).\\
+It is partially supported by the German Research Foundation (DFG) under the grant [504226141](https://gepris.dfg.de/gepris/projekt/504226141) ("CodeInspector").
+
+----
+
+### Generation Notice
+
+Please notice that this file was generated automatically using the file ${(0, doc_auto_gen_1.fileNameForGenHeader)(module.filename)} as a source.\\
+If you want to make changes please edit the source file (the CI will take care of the rest).
+In fact, many files in the [wiki](${doc_files_1.FlowrWikiBaseRef}) are generated, so make sure to check for the source file if you want to make changes.
+
+`.trim();
+}
+/** if we run this script, we want a Markdown representation of the capabilities */
+if (require.main === module) {
+    void tree_sitter_executor_1.TreeSitterExecutor.initTreeSitter().then(() => {
+        (0, log_1.setMinLevelOfAllLogs)(6 /* LogLevel.Fatal */);
+        const shell = new shell_1.RShell();
+        void getText(shell).then(str => {
+            console.log(str);
+        }).finally(() => {
+            shell.close();
+        });
+    });
+}
+//# sourceMappingURL=print-readme.js.map

package/documentation/print-search-wiki.js

@@ -12,6 +12,7 @@ const flowr_search_builder_1 = require("../search/flowr-search-builder");
 const vertex_1 = require("../dataflow/graph/vertex");
 const doc_types_1 = require("./doc-util/doc-types");
 const path_1 = __importDefault(require("path"));
+const flowr_search_executor_1 = require("../search/flowr-search-executor");
 async function getText(shell) {
     const rversion = (await shell.usedRVersion())?.format() ?? 'unknown';
     const types = (0, doc_types_1.getTypesFromFolderAsMermaid)({
@@ -24,7 +25,7 @@ async function getText(shell) {
 This page briefly summarizes flowR's search API which provides a set of functions to search for nodes in the [Dataflow Graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow%20Graph) and the 
 [Normalized AST](${doc_files_1.FlowrWikiBaseRef}/Normalized%20AST) of a given R code (the search will always consider both, with respect to your search query).
 Please see the [Interface](${doc_files_1.FlowrWikiBaseRef}/Interface) wiki page for more information on how to access this API.
-Within code, you can execute a search using the ${(0, doc_types_1.shortLink)('runSearch', types.info)} function.
+Within code, you can execute a search using the ${(0, doc_types_1.shortLink)(flowr_search_executor_1.runSearch.name, types.info)} function.
 
 For an initial motivation, let's have a look at the following example: