@eagleoutice/flowr 2.2.1 → 2.2.3

package/documentation/print-dataflow-graph-wiki.js

@@ -92,7 +92,7 @@ async function getVertexExplanations(shell, vertexType) {
 Describes a constant value (numbers, booleans/logicals, strings, ...).
 In general, the respective vertex is more or less a dummy vertex as you can see from its implementation.
 
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, hierarchy: vertexType.info, root: 'DataflowGraphVertexValue' })}
+${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'DataflowGraphVertexValue' })}
 
 ${(0, doc_structure_1.block)({
                 type: 'NOTE',
@@ -122,7 +122,7 @@ Describes symbol/variable references which are read (or potentially read at a gi
 Similar to the [value vertex](#value-vertex) described above, this is more a marker vertex as 
 you can see from the implementation.
 
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, hierarchy: vertexType.info, root: 'DataflowGraphVertexUse' })}
+${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'DataflowGraphVertexUse' })}
 
 ${(0, doc_structure_1.block)({
                 type: 'NOTE',
@@ -168,12 +168,12 @@ Describes any kind of function call, including unnamed calls and those that happ
 In general the vertex provides you with information about 
 the _name_ of the called function, the passed _arguments_, and the _environment_ in which the call happens (if it is of importance).
 
-However, the implementation reveals that it may hold an additional \`onlyBuiltin\` flag to indicate that the call is only calling builtin functions — however, this is only a flag to improve performance
+However, the implementation reveals that it may hold an additional \`onlyBuiltin\` flag to indicate that the call is only calling builtin functions — however, this is only a flag to improve performance,
 and it should not be relied on as it may under-approximate the actual calling targets (e.g., being \`false\` even though all calls resolve to builtins).
 	 
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, hierarchy: vertexType.info, root: 'DataflowGraphVertexFunctionCall' })}
+${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'DataflowGraphVertexFunctionCall' })}
 The related function argument references are defined like this:
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, hierarchy: vertexType.info, root: 'FunctionArgument' })}
+${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'FunctionArgument' })}
 
 
 ${(0, doc_structure_1.details)('Example: Simple Function Call (unresolved)', await (async () => {
@@ -214,7 +214,7 @@ In other words, we classify the references as ${(0, doc_general_1.lastJoin)(call
                 }), ', ', ', and ')}.
 For more information on the types of references, please consult the implementation.
 
-${(0, doc_types_1.printHierarchy)({ program: identifierType.program, hierarchy: identifierType.info, root: 'ReferenceType' })}
+${(0, doc_types_1.printHierarchy)({ program: identifierType.program, info: identifierType.info, root: 'ReferenceType' })}
 	`;
             })())}
 
@@ -289,7 +289,7 @@ However, they are actually linked with the call of the built-in function \`{\` (
 
 ${(0, doc_structure_1.details)('3) the function resolves to a mix of both', `
 
-Users may write... interesting pieces of code - for reasons we should not be interested in!
+Users may write… interesting pieces of code - for reasons we should not be interested in!
 Consider a case in which you have a built-in function (like the assignment operator \`<-\`) and a user that wants to redefine the meaning of the function call _sometimes_:
 
 ${await (async () => {
@@ -333,7 +333,7 @@ Function calls are the most complicated mechanism in R as essentially everything
 Even **control structures** like \`if(p) a else b\` are desugared into function calls (e.g., as \`if\`(p, a, b)).
 ${(0, doc_structure_1.details)('Example: <code>if</code> as a Function Call', await (0, doc_dfg_1.printDfGraphForCode)(shell, 'if(p) a else b'))}
 
-Similarly you should be aware of calls to **anonymous functions**, which may appear given directly (e.g. as \`(function() 1)()\`) or indirectly, with code
+Similarly, you should be aware of calls to **anonymous functions**, which may appear given directly (e.g. as \`(function() 1)()\`) or indirectly, with code
 directly calling the return of another function call: \`foo()()\`.
 ${(0, doc_structure_1.details)('Example: Anonymous Function Call (given directly)', await (0, doc_dfg_1.printDfGraphForCode)(shell, '(function() 1)()', { mark: new Set([6, '6->4']) }))}
 
@@ -358,7 +358,7 @@ ${(0, doc_structure_1.details)('Example: Super Definition (<code><<-</code>)', a
 
 The implementation is relatively sparse and similar to the other marker vertices:
 
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, hierarchy: vertexType.info, root: 'DataflowGraphVertexVariableDefinition' })}
+${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'DataflowGraphVertexVariableDefinition' })}
 
 Of course, there are not just operators that define variables, but also functions, like \`assign\`.
 
@@ -399,11 +399,11 @@ As you can see, _flowR_ is able to recognize that the initial definition of \`x\
 Defining a function does do a lot of things: 1) it creates a new scope, 2) it may introduce parameters which act as promises and which are only evaluated if they are actually required in the body, 3) it may access the enclosing environments and the callstack.
 The vertex object in the dataflow graph stores multiple things, including all exit points, the enclosing environment if necessary, and the information of the subflow (the "body" of the function).
 
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, hierarchy: vertexType.info, root: 'DataflowGraphVertexFunctionDefinition' })}
+${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'DataflowGraphVertexFunctionDefinition' })}
 The subflow is defined like this:
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, hierarchy: vertexType.info, root: 'DataflowFunctionFlowInformation' })}
+${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'DataflowFunctionFlowInformation' })}
 And if you are interested in the exit points, they are defined like this:
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, hierarchy: vertexType.info, root: 'ExitPoint' })}
+${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'ExitPoint' })}
 
 
 Whenever we visualize a function definition, we use a dedicated node to represent the anonymous function object,
@@ -481,7 +481,7 @@ Besides this being a theoretically "shorter" way of defining a function, this be
     }
     return results.join('\n');
 }
-async function getEdgesExplanations(shell) {
+async function getEdgesExplanations(shell, vertexType) {
     const edgeExplanations = new Map();
     edgeExplanations.set(edge_1.EdgeType.Reads, [{
             shell,
@@ -495,8 +495,8 @@ ${(0, doc_structure_1.block)({
                 content: `
 A ${linkEdgeName(edge_1.EdgeType.Reads)} edge is not a transitive closure and only links the "directly read" definition(s).
 Our abstract domains resolving transitive ${linkEdgeName(edge_1.EdgeType.Reads)} edges (and for that matter, following ${linkEdgeName(edge_1.EdgeType.Returns)} as well)
-are currently tailored to what we need in _flowR_. Hence we offer a function like \`${linker_1.getAllFunctionCallTargets.name}\` (defined in ${(0, doc_files_1.getFilePathMd)('../dataflow/internal/linker.ts')}),
-as well as \`${resolve_by_name_1.resolvesToBuiltInConstant.name}\` (defined in ${(0, doc_files_1.getFilePathMd)('../dataflow/environments/resolve-by-name.ts')}) which do this for specific cases.
+are currently tailored to what we need in _flowR_. Hence, we offer a function like ${(0, doc_types_1.shortLink)(linker_1.getAllFunctionCallTargets.name, vertexType.info)} (defined in ${(0, doc_files_1.getFilePathMd)('../dataflow/internal/linker.ts')}),
+as well as ${(0, doc_types_1.shortLink)(resolve_by_name_1.resolvesToBuiltInConstant.name, vertexType.info)} (defined in ${(0, doc_files_1.getFilePathMd)('../dataflow/environments/resolve-by-name.ts')}) which do this for specific cases.
 
 ${(0, doc_structure_1.details)('Example: Multi-Level Reads', await (0, doc_dfg_1.printDfGraphForCode)(shell, 'x <- 3\ny <- x\nprint(y)', { mark: new Set(['9->7', '7->3', '4->0']) }))}
 
@@ -557,7 +557,7 @@ However, nested definitions can carry it (in the nested case, \`x\` is defined b
             shell,
             name: 'Returns Edge',
             type: edge_1.EdgeType.Returns,
-            description: 'Link the [function call](#function-call-vertex)  to the exit points of the target definition (this may incorporate the call-context).',
+            description: 'Link the [function call](#function-call-vertex) to the exit points of the target definition (this may incorporate the call-context).',
             code: 'foo <- function() x\nfoo()',
             expectedSubgraph: (0, dataflowgraph_builder_1.emptyGraph)().returns('2@foo', '1@x')
         }, []]);
@@ -582,7 +582,7 @@ f()
    
 ${dfInfo}
 
- The final call evaluates to \`3\` (similar to if we would have defined \`x\` before the function definition).
+ The final call evaluates to \`3\` (similar to if we defined \`x\` before the function definition).
  Within a dataflow graph you can see this with two edges. The \`x\` within the function body will have a ${linkEdgeName(edge_1.EdgeType.DefinedByOnCall)} 
  to every definition it _may_ refer to. In turn, each call vertex calling the function which encloses the use of \`x\` will have a
  ${linkEdgeName(edge_1.EdgeType.DefinesOnCall)} edge to the definition(s) it causes to be active within the function body. 
@@ -607,7 +607,7 @@ ${dfInfo}
             type: edge_1.EdgeType.Argument,
             description: `Links a [function call](#function-call-vertex) to the entry point of its arguments. If we do not know the target of such a call, we automatically assume that all arguments are read by the call as well!
 		
-The exception to this is the [function definition](#function-definition-vertex) which does no longer hold these argument relationships (as they are no implicit in the structure).
+The exception to this is the [function definition](#function-definition-vertex) which does no longer hold these argument relationships (as they are not implicit in the structure).
 		`,
             code: 'f(x,y)',
             expectedSubgraph: (0, dataflowgraph_builder_1.emptyGraph)().argument('1@f', '1@x').reads('1@f', '1@x').argument('1@f', '1@y').reads('1@f', '1@y')
@@ -678,7 +678,7 @@ async function getText(shell) {
     const rversion = (await shell.usedRVersion())?.format() ?? 'unknown';
     /* we collect type information on the graph */
     const vertexType = (0, doc_types_1.getTypesFromFolderAsMermaid)({
-        files: [path_1.default.resolve('./src/dataflow/graph/vertex.ts'), path_1.default.resolve('./src/dataflow/graph/graph.ts'), path_1.default.resolve('./src/dataflow/environments/identifier.ts'), path_1.default.resolve('./src/dataflow/info.ts')],
+        rootFolder: path_1.default.resolve('./src/'),
         typeName: 'DataflowGraphVertexInfo',
         inlineTypes: ['MergeableRecord']
     });
@@ -689,8 +689,8 @@ async function getText(shell) {
     });
     return `${(0, doc_auto_gen_1.autoGenHeader)({ filename: module.filename, purpose: 'dataflow graph', rVersion: rversion })}
 
-This page briefly summarizes flowR's dataflow graph, represented by ${(0, doc_types_1.shortLink)('DataflowGraph', vertexType.info)} in ${(0, doc_files_1.getFilePathMd)('../dataflow/graph/graph.ts')}.
-In case you want to manually build such a graph (e.g., for testing), you can use the builder in ${(0, doc_files_1.getFilePathMd)('../dataflow/graph/dataflowgraph-builder.ts')}.
+This page briefly summarizes flowR's dataflow graph, represented by the ${(0, doc_types_1.shortLink)(graph_1.DataflowGraph.name, vertexType.info)}.
+In case you want to manually build such a graph (e.g., for testing), you can use the ${(0, doc_types_1.shortLink)(dataflowgraph_builder_1.DataflowGraphBuilder.name, vertexType.info)}.
 This wiki page focuses on explaining what such a dataflow graph looks like!
 
 Please be aware that the accompanied [dataflow information](#dataflow-information) returned by _flowR_ contains things besides the graph,
@@ -702,7 +702,7 @@ Additionally, you may be interested in the set of [Unknown Side Effects](#unknow
 > you can either use the [Visual Studio Code extension](${doc_files_1.FlowrGithubBaseRef}/vscode-flowr) or the ${(0, doc_cli_option_1.getReplCommand)('dataflow*')}
 > command in the REPL (see the [Interface wiki page](${doc_files_1.FlowrWikiBaseRef}/Interface) for more information). When using _flowR_ as a library, you may use the functions in ${(0, doc_files_1.getFilePathMd)('../util/mermaid/dfg.ts')}.
 > 
-> If you receive a dataflow graph in its serialized form (e.g., by talking to a [_flowR_ server](${doc_files_1.FlowrWikiBaseRef}/Interface)), you can use \`${graph_1.DataflowGraph.name}::${graph_1.DataflowGraph.fromJson.name}\` to retrieve the graph from the JSON representation.
+> If you receive a dataflow graph in its serialized form (e.g., by talking to a [_flowR_ server](${doc_files_1.FlowrWikiBaseRef}/Interface)), you can use ${(0, doc_types_1.shortLink)(`${graph_1.DataflowGraph.name}::${graph_1.DataflowGraph.fromJson.name}`, vertexType.info, true, 'i')} to retrieve the graph from the JSON representation.
 
 ${await (0, doc_dfg_1.printDfGraphForCode)(shell, 'x <- 3\ny <- x + 1\ny')}
 
@@ -743,9 +743,9 @@ The following sections present details on the different types of vertices and ed
 > [!NOTE]
 > Every dataflow vertex holds an \`id\` which links it to the respective node in the [normalized AST](${doc_files_1.FlowrWikiBaseRef}/Normalized%20AST).
 > So if you want more information about the respective vertex, you can usually access more information
-> using the \`${graph_1.DataflowGraph.name}::idMap\` linked to the dataflow graph:
+> using the <code>${(0, doc_types_1.shortLink)(`${graph_1.DataflowGraph.name}`, vertexType.info, false, 'i')}::idMap</code> linked to the dataflow graph:
 ${(0, doc_general_1.prefixLines)((0, doc_code_1.codeBlock)('ts', 'const node = graph.idMap.get(id);'), '> ')}
-> In case you just need the name (\`lexeme\`) of the respective vertex, ${node_id_1.recoverName.name} (defined in ${(0, doc_files_1.getFilePathMd)('../r-bridge/lang-4.x/ast/model/processing/node-id.ts')}) can help you out:
+> In case you just need the name (\`lexeme\`) of the respective vertex, ${(0, doc_types_1.shortLink)(node_id_1.recoverName.name, vertexType.info)} can help you out:
 ${(0, doc_general_1.prefixLines)((0, doc_code_1.codeBlock)('ts', `const name = ${node_id_1.recoverName.name}(id, graph.idMap);`), '> ')}
 
 ## Vertices
@@ -754,7 +754,7 @@ ${await getVertexExplanations(shell, vertexType)}
 
 ## Edges
 
-${await getEdgesExplanations(shell)}
+${await getEdgesExplanations(shell, vertexType)}
 
 ## Control Dependencies
 
@@ -778,7 +778,7 @@ ${(0, doc_structure_1.details)('Example: Nested Conditionals', await (0, doc_dfg
 ## Dataflow Information
 
 Using _flowR's_ code interface (see the [Interface](${doc_files_1.FlowrWikiBaseRef}/Interface) wiki page for more), you can generate the dataflow information
-for a given piece of R code (in this case \`x <- 1; x + 1\`) as follows:
+for a given piece of R code (in this case \`x <- 1; x + 1\`) as follows (using the ${(0, doc_types_1.shortLink)(shell_1.RShell.name, vertexType.info)} and the ${(0, doc_types_1.shortLink)(pipeline_executor_1.PipelineExecutor.name, vertexType.info)} classes):
 
 ${(0, doc_code_1.codeBlock)('ts', `
 const shell = new ${shell_1.RShell.name}()
@@ -821,7 +821,7 @@ ${(0, doc_code_1.codeBlock)('text', JSON.stringify(result.dataflow, json_1.jsonR
 
 You may be interested in its implementation:
 
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, hierarchy: vertexType.info, root: 'DataflowInformation' })}
+${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'DataflowInformation' })}
 
 Let's start by looking at the properties of the dataflow information object: ${Object.keys(result.dataflow).map(k => `\`${k}\``).join(', ')}.
 

package/documentation/print-interface-wiki.js

@@ -133,7 +133,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).
@@ -175,7 +175,6 @@ ${(0, doc_code_1.codeBlock)('shell', ':query @config')}
 The following summarizes the configuration options:
 
 - \`ignoreSourceCalls\`: If set to \`true\`, _flowR_ will ignore source calls when analyzing the code, i.e., ignoring the inclusion of other files.
-- \`rPath\`: The path to the R executable. If not set, _flowR_ will try to find the R executable in the system's PATH.
 - \`semantics\`: allows to configure the way _flowR_ handles R, although we currently only support \`semantics/environment/overwriteBuiltIns\`. 
   You may use this to overwrite _flowR_'s handling of built-in function and even completely clear the preset definitions shipped with flowR. 
   See [Configure BuiltIn Semantics](#configure-builtin-semantics) for more information.
@@ -191,7 +190,6 @@ So you can configure _flowR_ by adding a file like the following:
 
 ${(0, doc_code_1.codeBlock)('json', JSON.stringify({
         ignoreSourceCalls: true,
-        rPath: '/usr/bin/R',
         semantics: {
             environment: {
                 overwriteBuiltIns: {

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

@@ -1,10 +1,21 @@
 "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"));
 function getText() {
+    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 `
 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 +64,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 +75,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 +87,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 +111,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

@@ -1,4 +1,7 @@
 "use strict";
+var __importDefault = (this && this.__importDefault) || function (mod) {
+    return (mod && mod.__esModule) ? mod : { "default": mod };
+};
 Object.defineProperty(exports, "__esModule", { value: true });
 const shell_1 = require("../r-bridge/shell");
 const doc_dfg_1 = require("./doc-util/doc-dfg");
@@ -29,6 +32,8 @@ const config_query_executor_1 = require("../queries/catalog/config-query/config-
 const search_query_executor_1 = require("../queries/catalog/search-query/search-query-executor");
 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"));
 (0, doc_query_1.registerQueryDocumentation)('call-context', {
     name: 'Call-Context Query',
     type: 'active',
@@ -54,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\`:
@@ -159,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.
@@ -194,6 +199,25 @@ ${await (0, doc_query_1.showQuery)(shell, example_query_code_1.exampleQueryCode,
 		`;
     }
 });
+(0, doc_query_1.registerQueryDocumentation)('resolve-value', {
+    name: 'Resolve Value Query',
+    type: 'active',
+    shortDescription: 'Provides access to flowR\'s value tracking (which is configurable)',
+    functionName: search_query_executor_1.executeSearch.name,
+    functionFile: '../queries/catalog/resolve-value-query/resolve-value-query-executor.ts',
+    buildExplanation: async (shell) => {
+        const exampleCode = 'x <- 1\nprint(x)';
+        return `
+With this query you can use flowR's value-tracking capabilities to resolve identifiers to all potential values they may have at runtime (if possible). The extend to which flowR traces values (e.g. built-ins vs. constants) can be configured in flowR's Configuration file (see the [Interface](${doc_files_1.FlowrWikiBaseRef}/Interface) wiki page for more information). 
+
+Using the example code \`${exampleCode}\`, the following query returns all values of 'x' in the code:
+${await (0, doc_query_1.showQuery)(shell, exampleCode, [{
+                type: 'resolve-value',
+                criteria: ['2@x']
+            }], { showCode: true })}
+		`;
+    }
+});
 (0, doc_query_1.registerQueryDocumentation)('search', {
     name: 'Search Query',
     type: 'active',
@@ -344,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, [{
@@ -419,9 +443,13 @@ ${await (0, doc_query_1.showQuery)(shell, longerCode, [{
     functionName: location_map_query_executor_1.executeLocationMapQuery.name,
     functionFile: '../queries/catalog/location-map-query/location-map-query-executor.ts',
     buildExplanation: async (shell) => {
+        const types = (0, doc_types_1.getTypesFromFolderAsMermaid)({
+            files: [path_1.default.resolve('./src/util/range.ts')],
+            typeName: 'SourceRange'
+        });
         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:
@@ -434,6 +462,8 @@ ${await (0, doc_query_1.showQuery)(shell, exampleCode, [{
                 type: 'location-map'
             }], { showCode: false, collapseQuery: true })}
 
+All locations are given as a ${(0, doc_types_1.shortLink)('SourceRange', types.info)} in the format \`[start-line, start-column, end-line, end-column]\`.	
+
 		`;
     }
 });
@@ -459,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-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:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@eagleoutice/flowr",
-  "version": "2.2.1",
+  "version": "2.2.3",
   "description": "Static Dataflow Analyzer and Program Slicer for the R Programming Language",
   "types": "dist/src/index.d.ts",
   "repository": {
@@ -21,21 +21,23 @@
     "stats-helper": "ts-node src/cli/statistics-helper-app.ts",
     "slicer": "ts-node src/cli/slicer-app.ts",
     "benchmark-helper": "ts-node src/cli/benchmark-helper-app.ts",
-    "benchmark": "npm run build && npm run build:copy-wasm && node dist/src/cli/benchmark-app.js",
+    "benchmark": "npm run build-dev && node dist/src/cli/benchmark-app.js",
     "summarizer": "ts-node src/cli/summarizer-app.ts",
     "export-quads": "ts-node src/cli/export-quads-app.ts",
     "capabilities-markdown": "ts-node src/documentation/print-capabilities-markdown.ts",
     "wiki:df-graph": "ts-node src/documentation/print-dataflow-graph-wiki.ts",
     "wiki:normalized-ast": "ts-node src/documentation/print-normalized-ast-wiki.ts",
     "wiki:query-api": "ts-node src/documentation/print-query-wiki.ts",
+    "wiki:core": "ts-node src/documentation/print-core-wiki.ts",
     "wiki:engines": "ts-node src/documentation/print-engines-wiki.ts",
     "wiki:search-api": "ts-node src/documentation/print-search-wiki.ts",
     "wiki:linting-and-testing": "ts-node src/documentation/print-linting-and-testing-wiki.ts",
     "wiki:interface": "ts-node src/documentation/print-interface-wiki.ts",
     "build": "tsc --project .",
-    "build:bundle-flowr": "npm run build && esbuild --bundle dist/src/cli/flowr.js --platform=node --bundle --minify --target=node22 --outfile=dist/src/cli/flowr.min.js && npm run build:copy-wasm-min",
-    "build:copy-wasm": "cp src/r-bridge/lang-4.x/tree-sitter/tree-sitter-r.wasm dist/src/r-bridge/lang-4.x/tree-sitter/ && cp src/r-bridge/lang-4.x/tree-sitter/tree-sitter.wasm dist/src/r-bridge/lang-4.x/tree-sitter/",
-    "build:copy-wasm-min": "cp src/r-bridge/lang-4.x/tree-sitter/tree-sitter-r.wasm dist/src/cli && cp src/r-bridge/lang-4.x/tree-sitter/tree-sitter.wasm dist/src/cli",
+    "build-dev": "npm run build && npm run build:copy-wasm",
+    "build:bundle-flowr": "npm run build && esbuild --bundle dist/src/cli/flowr.js --platform=node --bundle --minify --external:clipboardy --target=node22 --outfile=dist/src/cli/flowr.min.js && npm run build:copy-wasm-min",
+    "build:copy-wasm": "mkdir -p dist/src/r-bridge/lang-4.x/tree-sitter/ && cp src/r-bridge/lang-4.x/tree-sitter/tree-sitter-r.wasm src/r-bridge/lang-4.x/tree-sitter/tree-sitter.wasm dist/src/r-bridge/lang-4.x/tree-sitter/",
+    "build:copy-wasm-min": "mkdir -p dist/src/cli && cp src/r-bridge/lang-4.x/tree-sitter/tree-sitter-r.wasm src/r-bridge/lang-4.x/tree-sitter/tree-sitter.wasm dist/src/cli",
     "lint-local": "npx eslint --version && npx eslint src/ test/ --rule \"no-warning-comments: off\"",
     "lint": "npm run license-compat -- --summary && npx eslint --version && npx eslint src/ test/",
     "license-compat": "license-checker --onlyAllow 'MIT;MIT OR X11;GPLv2;LGPL;GNUGPL;ISC;Apache-2.0;FreeBSD;BSD-2-Clause;clearbsd;ModifiedBSD;BSD-3-Clause;Python-2.0;Unlicense;WTFPL;BlueOak-1.0.0;CC-BY-4.0;CC-BY-3.0;CC0-1.0;0BSD'",
@@ -166,7 +168,7 @@
         "npm run lint",
         "npm run test-full"
       ],
-      "after:bump": "npm run build && npm run build:copy-wasm",
+      "after:bump": "npm run build-dev",
       "after:git:release": "echo After git push, before github release",
       "after:release": "echo Successfully released ${name} v${version} to ${repo.repository}."
     },
@@ -195,7 +197,7 @@
     "@types/ws": "^8.5.10",
     "@typescript-eslint/eslint-plugin": "^7.8.0",
     "@vitest/coverage-v8": "^2.1.4",
-    "esbuild": "^0.23.1",
+    "esbuild": "^0.25.0",
     "eslint": "^8.57.1",
     "license-checker": "^25.0.1",
     "npm-run-all": "^4.1.5",
@@ -210,6 +212,7 @@
   },
   "dependencies": {
     "@xmldom/xmldom": "^0.9.2",
+    "clipboardy": "^4.0.0",
     "command-line-args": "^6.0.0",
     "command-line-usage": "^7.0.3",
     "joi": "^17.13.3",