@eagleoutice/flowr 2.0.25 → 2.1.0

package/documentation/print-interface-wiki.d.ts

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

package/documentation/print-interface-wiki.js

@@ -0,0 +1,401 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+const shell_1 = require("../r-bridge/shell");
+const log_1 = require("../../test/functionality/_helper/log");
+const doc_files_1 = require("./doc-util/doc-files");
+const doc_auto_gen_1 = require("./doc-util/doc-auto-gen");
+const doc_cli_option_1 = require("./doc-util/doc-cli-option");
+const doc_server_message_1 = require("./doc-util/doc-server-message");
+const doc_data_server_messages_1 = require("./data/server/doc-data-server-messages");
+const doc_code_1 = require("./doc-util/doc-code");
+const retriever_1 = require("../r-bridge/retriever");
+const doc_docker_1 = require("./doc-util/doc-docker");
+const doc_repl_1 = require("./doc-util/doc-repl");
+const doc_dfg_1 = require("./doc-util/doc-dfg");
+const config_1 = require("../config");
+const schema_1 = require("../util/schema");
+const ansi_1 = require("../util/ansi");
+const flowr_main_options_1 = require("../cli/flowr-main-options");
+const doc_issue_1 = require("./doc-util/doc-issue");
+const pipeline_executor_1 = require("../core/pipeline-executor");
+async function explainServer(shell) {
+    (0, doc_data_server_messages_1.documentAllMessages)();
+    return `
+As explained in the [Overview](${doc_files_1.FlowrWikiBaseRef}/Overview), you can simply run the [TCP](https://de.wikipedia.org/wiki/Transmission_Control_Protocol)&nbsp;server by adding the ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'server', true)} flag (and, due to the interactive mode, exit with the conventional <kbd>CTRL</kbd>+<kbd>C</kbd>).
+Currently, every connection is handled by the same underlying \`${shell_1.RShell.name}\` - so the server is not designed to handle many clients at a time.
+Additionally, the server is not well guarded against attacks (e.g., you can theoretically spawn an arbitrary number of&nbsp;${shell_1.RShell.name} sessions on the target machine).
+
+Every message has to be given in a single line (i.e., without a newline in-between) and end with a newline character. Nevertheless, we will pretty-print example given in the following segments for the ease of reading.
+
+> [!NOTE]
+> The default ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'server', false)} uses a simple [TCP](https://de.wikipedia.org/wiki/Transmission_Control_Protocol)
+> connection. If you want _flowR_ to expose a [WebSocket](https://de.wikipedia.org/wiki/WebSocket) server instead, add the ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'server', false)} flag (i.e., ${(0, doc_cli_option_1.multipleCliOptions)('flowr', 'server', 'ws')}) when starting _flowR_ from the command line.
+
+${await (0, doc_server_message_1.printServerMessages)(shell)}
+
+### 📡 Ways of Connecting
+
+If you are interested in clients that communicate with _flowR_, please check out the [R adapter](${doc_files_1.FlowrGithubBaseRef}/flowr-r-adapter)
+as well as the [Visual Studio Code extension](${doc_files_1.FlowrGithubBaseRef}/vscode-flowr). 
+
+<ol>
+
+<li>
+<a id="using-netcat-without-websocket"></a>Using Netcat
+
+<details>
+
+<summary>Without Websocket</summary>
+
+Suppose, you want to launch the server using a docker container. Then, start the server by (forwarding the internal default port):
+
+${(0, doc_code_1.codeBlock)('shell', `docker run -p1042:1042 -it --rm ${doc_docker_1.DockerName} --server`)}
+
+Now, using a tool like [_netcat_](https://linux.die.net/man/1/nc) to connect:
+
+${(0, doc_code_1.codeBlock)('shell', 'nc 127.0.0.1 1042')}
+
+Within the started session, type the following message (as a single line) and press enter to see the response:
+
+${(0, doc_code_1.codeBlock)('json', (0, retriever_1.removeRQuotes)(JSON.stringify({ type: 'request-file-analysis', content: 'x <- 1', id: '1' })))}
+
+</details>
+</li>
+
+<li> Using Python
+<details>
+<summary>Without Websocket</summary>
+
+In Python, a similar process would look like this. After starting the server as with using [netcat](#using-netcat-without-websocket), you can use the following script to connect:
+
+${(0, doc_code_1.codeBlock)('python', `
+import socket
+
+with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
+    s.connect(('127.0.0.1', 1042))
+    print(s.recv(4096))  # for the hello message
+
+    s.send(b'${(0, retriever_1.removeRQuotes)(JSON.stringify({ type: 'request-file-analysis', content: 'x <- 1', id: '1' }))}\\n')
+
+    print(s.recv(65536))  # for the response (please use a more sophisticated mechanism)
+`)}
+
+</details>
+</li>
+
+</ol>
+
+`;
+}
+async function explainRepl(shell) {
+    return `
+> [!NOTE]
+> To execute arbitrary R commands with a repl request, _flowR_ has to be started explicitly with ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'r-session-access')}.
+> Please be aware that this introduces a security risk.
+
+
+Although primarily meant for users to explore, 
+there is nothing which forbids simply calling _flowR_ as a subprocess to use standard-in, -output, and -error 
+for communication (although you can access the REPL using the server as well, 
+with the [REPL Request](#message-request-repl-execution) message).
+
+The read-eval-print loop&nbsp;(REPL) works relatively simple.
+You can submit an expression (using enter),
+which is interpreted as an R&nbsp;expression by default but interpreted as a *command* if it starts with a colon (\`:\`).
+The best command to get started with the REPL is ${(0, doc_cli_option_1.getReplCommand)('help')}.
+Besides, you can leave the REPL either with the command ${(0, doc_cli_option_1.getReplCommand)('quit')} or by pressing <kbd>CTRL</kbd>+<kbd>C</kbd> twice.
+
+
+<details>
+<summary>Available Commands</summary>
+
+We currently offer the following commands (this with a \`[*]\` suffix are available with and without the star):
+
+${(0, doc_repl_1.printReplHelpAsMarkdownTable)()}
+
+</details>
+
+
+### Example: Retrieving the Dataflow Graph
+
+To retrieve a URL to the [mermaid](https://mermaid.js.org/) diagram of the dataflow of a given expression, 
+use ${(0, doc_cli_option_1.getReplCommand)('dataflow*')} (or ${(0, doc_cli_option_1.getReplCommand)('dataflow')} to get the mermaid code in the cli):
+
+${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')}.`
+        }])}
+
+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).
+
+### Example: Interfacing with the File System
+
+Many commands that allow for an R-expression (like ${(0, doc_cli_option_1.getReplCommand)('dataflow*')}) allow for a file as well 
+if the argument starts with \`${retriever_1.fileProtocol}\`. 
+If you are working from the root directory of the _flowR_ repository, the following gives you the parsed AST of the example file using the ${(0, doc_cli_option_1.getReplCommand)('parse')} command:
+
+${await (0, doc_repl_1.documentReplSession)(shell, [{
+            command: `:parse ${retriever_1.fileProtocol}test/testfiles/example.R`,
+            description: `Retrieve the parsed AST of the example file.
+
+<details>
+
+<summary>File Content</summary>	
+
+${(0, doc_code_1.codeBlock)('r', (0, doc_files_1.getFileContentFromRoot)('test/testfiles/example.R'))}
+
+</details>
+
+As _flowR_ directly transforms this AST the output focuses on being human-readable instead of being machine-readable. 
+		`
+        }])}
+`;
+}
+function explainConfigFile() {
+    return `
+
+When running _flowR_, you may want to specify some behaviors with a dedicated configuration file. 
+By default, flowR looks for a file named \`${flowr_main_options_1.defaultConfigFile}\` in the current working directory (or any higher directory). 
+You can also specify a different file with ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'config-file')} or pass the configuration inline using ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'config-json')}.
+
+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.
+
+So you can configure _flowR_ by adding a file like the following:
+
+<details>
+
+<summary>Example Configuration File</summary>
+
+${(0, doc_code_1.codeBlock)('json', JSON.stringify({
+        ignoreSourceCalls: true,
+        rPath: '/usr/bin/R',
+        semantics: {
+            environment: {
+                overwriteBuiltIns: {
+                    definitions: [
+                        { type: 'function', names: ['foo'], processor: 'builtin:assignment', config: {} }
+                    ]
+                }
+            }
+        }
+    }, null, 2))}
+
+</details>
+
+<details> 
+<a id='configure-builtin-semantics'></a>
+<summary>Configure Built-In Semantics</summary> 
+
+
+\`semantics/environment/overwriteBuiltins\` accepts two keys:
+
+- \`loadDefaults\` (boolean, initially \`true\`): If set to \`true\`, the default built-in definitions are loaded before applying the custom definitions. Setting this flag to \`false\` explicitly disables the loading of the default definitions.
+- \`definitions\` (array, initially empty): Allows to overwrite or define new built-in elements. Each object within must have a \`type\` which is one of the below. Furthermore, they may define a string array of \`names\` which specifies the identifiers to bind the definitions to. You may use \`assumePrimitive\` to specify whether _flowR_ should assume that this is a primitive non-library definition (so you probably just do not want to specify the key).
+
+  | Type          | Description                                                                                                                                                                                                                                                                                              | Example                                                                                                    |
+  | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
+  | \`constant\`    | Additionally allows for a \`value\` this should resolve to.                                                                                                                                                                                                                                                | \`{ type: 'constant', names: ['NULL', 'NA'],  value: null }\`                                                |
+  | \`function\`    | Is a rather flexible way to define and bind built-in functions. For the time, we do not have extensive documentation to cover all the cases, so please either consult the sources with the \`default-builtin-config.ts\` or open a [new issue](${doc_issue_1.NewIssueUrl}). | \`{ type: 'function', names: ['next'], processor: 'builtin:default', config: { cfg: ExitPointType.Next } }\` |
+  | \`replacement\` | A comfortable way to specify replacement functions like \`$<-\` or \`names<-\`. \`suffixes\` describes the... suffixes to attach automatically. | \`{ type: 'replacement', suffixes: ['<-', '<<-'], names: ['[', '[['] }\` |
+
+
+</details>
+
+<details>
+
+<summary style='color:gray'>Full Configuration-File Schema</summary>
+
+${(0, schema_1.describeSchema)(config_1.flowrConfigFileSchema, ansi_1.markdownFormatter)}
+
+</details>
+
+	`;
+}
+function explainWritingCode(shell) {
+    return `
+
+
+_flowR_ can be used as a [module](${doc_files_1.FlowrNpmRef}) and offers several main classes and interfaces that are interesting for extension writers 
+(see the [Visual Studio Code extension](${doc_files_1.FlowrGithubBaseRef}/vscode-flowr) or the [core](${doc_files_1.FlowrWikiBaseRef}/Core) wiki page for more information).
+
+### Using the \`${shell_1.RShell.name}\` to Interact with R
+
+The \`${shell_1.RShell.name}\` class allows to interface with the \`R\`&nbsp;ecosystem installed on the host system.
+For now there are no (real) alternatives, although we plan on providing more flexible drop-in replacements.
+
+> [!IMPORTANT]
+> Each \`${shell_1.RShell.name}\` controls a new instance of the R&nbsp;interpreter, make sure to call \`${shell_1.RShell.name}::${shell.close.name}()\` when you’re done.
+
+You can start a new "session" simply by constructing a new object with \`new ${shell_1.RShell.name}()\`.
+
+However, there are several options which 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 \`${shell_1.RShell.name}::${shell.sendCommand.name}\`, 
+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 \`${shell_1.RShell.name}::${shell.sendCommandWithOutput.name}\` instead.
+
+Besides that, the command \`${shell_1.RShell.name}::${shell.tryToInjectHomeLibPath.name}\` may be of interest, as it enables all libraries available on the host system.
+
+### The Pipeline Executor
+
+Once, in the beginning, _flowR_ was meant to produce a dataflow graph merely to provide *program slices*. 
+However, with continuous updates, the [dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow&20Graph) repeatedly proves to be the more interesting part.
+With this, we restructured _flowR_'s originally *hardcoded* pipeline to be far more flexible. 
+Now, it can be theoretically extended or replaced with arbitrary steps, optional steps, and what we call 'decorations' of these steps. 
+In short, if you still "just want to slice" you can do it like this:
+
+${(0, doc_code_1.codeBlock)('ts', `
+const slicer = new ${pipeline_executor_1.PipelineExecutor.name}(DEFAULT_SLICING_PIPELINE, {
+  shell:     new ${shell_1.RShell.name}(),
+  request:   ${retriever_1.requestFromInput.name}('x <- 1\\nx + 1'),
+  criterion: ['2@x']
+})
+const slice = await slicer.allRemainingSteps()
+// console.log(slice.reconstruct.code)
+`)}
+
+<details>
+
+<summary style='color:gray'>More Information</summary>
+
+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 \`${pipeline_executor_1.PipelineExecutor.name}\` 
+and to pass the \`DEFAULT_SLICING_PIPELINE\` as the first argument.
+The \`${pipeline_executor_1.PipelineExecutor.name}\`...
+
+1. allows investigating 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
+
+
+<details>
+
+<summary>Adding a New Feature to Extract</summary>
+
+In this example, we construct a new feature to extract, with the name "*example*".
+Whenever this name appears, you may substitute this with whatever name fits your feature best (as long as the name is unique).
+
+1. **Create a new file in \`src/statistics/features/supported\`**\\
+   Create the file \`example.ts\`, and add its export to the \`index.ts\` file in the same directory (if not done automatically).
+
+2. **Create the basic structure**\\
+   To get a better feel of what a feature must have, let's look
+   at the basic structure (of course, due to TypeScript syntax,
+   there are other ways to achieve the same goal):
+
+   \`\`\`ts
+   const initialExampleInfo = {
+       /* whatever start value is good for you */
+       someCounter: 0
+   }
+
+   export type ExampleInfo = Writable<typeof initialExampleInfo>
+
+   export const example: Feature<ExampleInfo> = {
+    name:        'Example Feature',
+    description: 'A longer example description',
+
+    process(existing: ExampleInfo, input: FeatureProcessorInput): ExampleInfo {
+      /* perform analysis on the input */
+      return existing
+    },
+
+    initialValue: initialExampleInfo
+   }
+   \`\`\`
+
+   The \`initialExampleInfo\` type holds the initial values for each counter that you want to maintain during the feature extraction (they will usually be initialized with 0). The resulting \`ExampleInfo\` type holds the structure of the data that is to be counted. Due to the vast amount of data processed, information like the name and location of a function call is not stored here, but instead written to disk (see below).
+
+   Every new feature must be of the \`Feature<Info>\` type, with \`Info\` referring to a \`FeatureInfo\` (like \`ExampleInfo\` in this example). Next to a \`name\` and a \`description\`, each Feature must provide:
+
+   - a processor that extracts the information from the input, adding it to the existing information.
+   - a function returning the initial value of the information (in this case, \`initialExampleInfo\`).
+
+3. **Add it to the feature-mapping**\\
+   Now, in the \`feature.ts\` file in \`src/statistics/features\`, add your feature to the \`ALL_FEATURES\` object.
+
+Now, we want to extract something. For the *example* feature created in the previous steps, we choose to count the amount of \`COMMENT\` tokens.
+So we define a corresponding [XPath](https://developer.mozilla.org/en-US/docs/Web/XPath) query:
+
+\`\`\`ts
+const commentQuery: Query = xpath.parse('//COMMENT')
+\`\`\`
+
+Within our feature's \`process\` function, running the query is as simple as:
+
+\`\`\`ts
+const comments = commentQuery.select({ node: input.parsedRAst })
+\`\`\`
+
+Now we could do a lot of further processing, but for simplicity, we only record every comment found this way:
+
+\`\`\`ts
+appendStatisticsFile(example.name, 'comments', comments, input.filepath)
+\`\`\`
+
+We use \`example.name\` to avoid duplication with the name that we’ve assigned to the feature. It corresponds to the name of the folder in the statistics output.
+\`'comments'\` refers to a freely chosen (but unique) name, that will be used as the name for the output file within the folder. The \`comments\` variable holds the result of the query, which is an array of nodes. Finally, we pass the \`filepath\` of the file that was analyzed (if known), so that it can be added to the statistics file (as additional information).
+
+</details>
+	`;
+}
+async function getText(shell) {
+    const rversion = (await shell.usedRVersion())?.format() ?? 'unknown';
+    return `${(0, doc_auto_gen_1.autoGenHeader)({ filename: module.filename, purpose: 'interfaces', rVersion: rversion })}
+
+Although far from being as detailed as the in-depth explanation of
+[_flowR_](${doc_files_1.FlowrWikiBaseRef}/Core),
+this wiki page explains how to interface with _flowR_ in more detail.
+In general, command line arguments and other options provide short descriptions on hover over.
+
+* [💬 Communicating with the Server](#communicating-with-the-server)
+* [💻 Using the REPL](#using-the-repl)
+* [⚙️ Configuring FlowR](#configuring-flowr)
+* [⚒️ Writing Code](#writing-code)
+
+<a id='communicating-with-the-server'></a>
+## 💬 Communicating with the Server
+
+${await explainServer(shell)}
+
+<a id='using-the-repl'></a>
+## 💻 Using the REPL
+
+${await explainRepl(shell)}
+
+<a id='configuring-flowr'></a>
+## ⚙️ Configuring FlowR
+
+${explainConfigFile()}
+
+<a id='writing-code'></a>
+## ⚒️ Writing Code
+
+${explainWritingCode(shell)}
+
+`;
+}
+/** if we run this script, we want a Markdown representation of the capabilities */
+if (require.main === module) {
+    (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-interface-wiki.js.map

package/documentation/print-normalized-ast-wiki.d.ts

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

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

@@ -0,0 +1,98 @@
+"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 log_1 = require("../../test/functionality/_helper/log");
+const doc_auto_gen_1 = require("./doc-util/doc-auto-gen");
+const doc_code_1 = require("./doc-util/doc-code");
+const doc_normalized_ast_1 = require("./doc-util/doc-normalized-ast");
+const doc_types_1 = require("./doc-util/doc-types");
+const path_1 = __importDefault(require("path"));
+const doc_files_1 = require("./doc-util/doc-files");
+const doc_ms_1 = require("./doc-util/doc-ms");
+const doc_cli_option_1 = require("./doc-util/doc-cli-option");
+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/'),
+        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), 
+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
+
+In general, the mapping should be rather intuitive and focused primarily on the
+syntactic structure of the program.
+Consider the following example which shows the normalized AST of the code
+
+${(0, doc_code_1.codeBlock)('r', 'x <- 2 * 3 + 1')}
+
+Each node in the AST contains the type, the id, and the lexeme (if applicable).
+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')}
+
+&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). 
+
+Indicative is the root expression list node, which is present in every normalized AST.
+In general, we provide node types for:
+
+1. literals (e.g., numbers and strings)
+2. references (e.g., symbols, parameters and function calls)
+3. constructs (e.g., loops and function definitions)
+4. branches (e.g., \`next\` and \`break\`)
+5. operators (e.g. \`+\`, \`-\`, and \`*\`)
+
+<details>
+
+<summary style="color:gray">Complete Class Diagram</summary>
+
+Every node is a link, which directly refers to the implementation in the source code.
+Grayed-out parts are used for structuring the AST, grouping together related nodes.
+
+${(0, doc_code_1.codeBlock)('mermaid', types.text)}
+
+_The generation of the class diagram required ${(0, doc_ms_1.printAsMs)(elapsed)}._
+</details>
+
+Node types are controlled by the \`${'RType'}\` enum (see ${(0, doc_files_1.getFilePathMd)('../r-bridge/lang-4.x/ast/model/type.ts')}), 
+which is used to distinguish between different types of nodes.
+Additionally, every AST node is generic with respect to the \`Info\` type which allows for arbitrary decorations (e.g., parent inforamtion or dataflow constraints).
+Most notably, the \`info\` field holds the \`id\` of the node, which is used to reference the node in the [dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow%20Graph).
+
+In summary, we have the following types:
+
+${(0, doc_types_1.printHierarchy)({ program: types.program, hierarchy: types.info, root: 'RNode', collapseFromNesting: Number.MAX_VALUE })}
+
+With this, the example file produced the following AST (shown from left to right for space reasons):
+
+${await (0, doc_normalized_ast_1.printNormalizedAstForCode)(shell, (0, doc_files_1.getFileContentFromRoot)('test/testfiles/example.R'), { prefix: 'flowchart LR\n' })}
+
+`;
+}
+/** if we run this script, we want a Markdown representation of the capabilities */
+if (require.main === module) {
+    (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-normalized-ast-wiki.js.map

package/documentation/print-query-wiki.d.ts

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