@suffolklitlab/alkiln 5.13.0-logs3 → 5.13.1

package/lib/utils/session_vars.js

@@ -3,22 +3,19 @@ const fg = require('fast-glob');
 const path = require('path'); 
 require('dotenv').config();
 
-/** WARNING: Avoid importing other project files into here. Every other
- *  file should be able to reference this one without worrying
- *  about circular references.
- * */
-
-/** This file provides user info variable getters and setters.
- *  E.g. server address. It often uses `process.env` vars or
- *  vars that have been built from `process.env` vars. It is
- *  meant to avoid duplication, make testing easier, and leave
- *  room for future manipulation.
- *
- * No other file should need to use `process.env`.
- *
- * We use `.get_foo()` functions partly because it makes the code
- * easier to test.
- * */
+/**
+ * This code assumes that this module is run as part of a GitHub Action.  If the
+ * customer is running it as a CLI tool, then they won't get useful messages yet.
+ */
+
+/* This file provides user info variables. E.g. server address. They're either
+*    `process.env` vars or vars that have been built from `process.env` vars.
+*    It is meant to avoid duplication, make testing easier, and leave room for
+*    future manipulation. No other file should need to use `process.env`.
+*
+* We have a bunch of `.get_foo()` functions partly because it makes the code
+*    much easier to test.
+*/
 
 const session_vars = {};
 
@@ -139,7 +136,7 @@ session_vars.save_project_name = function ( project_name ) {
   let file = fs.writeFileSync( runtime_config_path, JSON.stringify( json, null, 2 ) );
 
   if ( session_vars.get_debug() ) {
-    console.debug( `🐛 ALK0036 DEBUG: Stored name of Project "${ project_name }" locally.` );
+    console.log( `🐞 ALK0036 DEBUG: Stored name of Project "${ project_name }" locally.` );
   }
   return file;
 };  // Ends save_project_name()
@@ -151,7 +148,7 @@ session_vars.get_project_name = function () {
   }
   let json = JSON.parse( fs.readFileSync( runtime_config_path ));
   let project_name = json[ project_name_key ] || null;
-  if ( session_vars.get_debug() ) { console.debug( `🐛 ALK0037 DEBUG: Project name from file is "${ project_name }".` ); }
+  if ( session_vars.get_debug() ) { console.log( `🐞 ALK0037 DEBUG: Project name from file is "${ project_name }".` ); }
   return project_name;
 };  // Ends get_project_name()
 
@@ -175,11 +172,7 @@ session_vars.delete_project_name = function () {
 // const file_storing_artifact_path = `_alkiln_test_artifacts_dir_name.json`;
 const artifacts_path_key = `artifacts_path`;
 session_vars.save_artifacts_path_name = function ( path_name ) {
-  /** Save a key with the name of the current artifacts folder
-   *  in case it doesn't exist. Should we create the path in here
-   *  if it doesn't exist? Should we reserve this file for getting
-   *  and setting?
-   * */
+  /* Save a key with the name of the current artifacts folder in case it doesn't exist. */
   return session_vars.save_runtime_config_var({ key: artifacts_path_key, value: path_name });
 };  // Ends save_artifacts_path_name()
 session_vars.get_artifacts_path_name = function () {
@@ -233,7 +226,7 @@ session_vars.save_runtime_config_var = function ({ key, value }) {
   let file = fs.writeFileSync( runtime_config_path, JSON.stringify( json, null, 2 ) );
 
   if ( session_vars.get_debug() ) {
-    console.debug( `🐛 ALK0040 DEBUG: Stored runtime config var "${key}" locally as "${value}".` );
+    console.log( `🐞 ALK0040 DEBUG: Stored runtime config var "${key}" locally as "${value}".` );
   }
   return file;
 };  // Ends session_vars.save_runtime_config_var()
@@ -249,7 +242,7 @@ session_vars.get_runtime_config_var = function ( key ) {
     let json = JSON.parse( fs.readFileSync( runtime_config_path ));
     let value = json[ key ];
     if ( session_vars.get_debug() ) {
-      console.debug( `🐛 ALK0041 DEBUG: Runtime config var "${key}" is "${value}".` );
+      console.log( `🐞 ALK0041 DEBUG: Runtime config var "${key}" is "${value}".` );
     }
 
     return value;

package/lib/utils/time.js

@@ -24,47 +24,3 @@ time.waitForTimeout = function( milliseconds ) {
     setTimeout(resolve, milliseconds);
   });
 };
-time.sleep = time.waitForTimeout;
-time.wait = time.waitForTimeout;
-
-time.filename_date = function() {
-  /** Return the current timestamp in a human-readable
-  *   filename-safe format to match the workflow artifact
-  *   date format.
-  *   See https://stackoverflow.com/a/48729396/14144258 and https://stackoverflow.com/a/6040556/14144258
-  */
-  // let date = new Date();  // now
-  // let day = ("0" + date.getUTCDate()).slice(-2);
-  // let month = ("0" + (date.getUTCMonth() + 1)).slice(-2);
-  // let year = date.getUTCFullYear();
-  // let hours = ("0" + date.getUTCHours()).slice(-2);
-  // let mins = ("0" + date.getUTCMinutes()).slice(-2);
-  // let secs = ("0" + date.getUTCSeconds()).slice(-2);
-
-  let dt = time.get_time_parts();
-  let safe_date = `${ dt.y }-${ dt.mon }-${ dt.d } at ${ dt.h }h${ dt.min }m${ dt.s }sUTC`;
-  return safe_date;
-};  // Ends time.filename_date()
-
-time.log_date = function () {
-  /** Return the current timestamp in a human-readable
-  *   more compact log format.
-  * See https://stackoverflow.com/a/48729396/14144258 and https://stackoverflow.com/a/6040556/14144258
-  */
-  let dt = time.get_time_parts();
-  let short_date = `${ dt.y }-${ dt.mon }-${ dt.d } ${ dt.h }:${ dt.min }:${ dt.s }UTC`;
-  return short_date;
-};  // Ends time.log_date()
-
-time.get_time_parts = function () {
-  /** Get all the parts of the date as numbers. */
-  let date = new Date();  // now
-  return ({
-    y: date.getUTCFullYear(),
-    mon: ("0" + (date.getUTCMonth() + 1)).slice(-2),
-    d: ("0" + date.getUTCDate()).slice(-2),
-    h: ("0" + date.getUTCHours()).slice(-2),
-    min: ("0" + date.getUTCMinutes()).slice(-2),
-    s: ("0" + date.getUTCSeconds()).slice(-2),
-  });
-}

package/npm-shrinkwrap.json

@@ -22,7 +22,7 @@
         "minimatch": "3.0.5",
         "minimist": "1.2.8",
         "mocha": "9.2.2",
-        "pdfjs-dist": "3.2.146",
+        "pdfjs-dist": "3.11.174",
         "puppeteer": "22.15.0",
         "qs": "6.10.3",
         "sanitize-filename": "1.6.3",
@@ -2908,6 +2908,16 @@
         "node": ">=0.10.0"
       }
     },
+    "node_modules/path2d-polyfill": {
+      "version": "2.0.1",
+      "resolved": "https://registry.npmjs.org/path2d-polyfill/-/path2d-polyfill-2.0.1.tgz",
+      "integrity": "sha512-ad/3bsalbbWhmBo0D6FZ4RNMwsLsPpL6gnvhuSaU5Vm7b06Kr5ubSltQQ0T7YKsiJQO+g22zJ4dJKNTXIyOXtA==",
+      "license": "MIT",
+      "optional": true,
+      "engines": {
+        "node": ">=8"
+      }
+    },
     "node_modules/pathval": {
       "version": "1.1.1",
       "resolved": "https://registry.npmjs.org/pathval/-/pathval-1.1.1.tgz",
@@ -2917,14 +2927,16 @@
       }
     },
     "node_modules/pdfjs-dist": {
-      "version": "3.2.146",
-      "resolved": "https://registry.npmjs.org/pdfjs-dist/-/pdfjs-dist-3.2.146.tgz",
-      "integrity": "sha512-wy1OB/v75usRD1LqgxBUWC+ZOiKTmG5J8c2z9XVFrVSSWiVbSuseNojmvFa/TT0pYtcFmkL4zn6KaxvqfPYMRg==",
-      "dependencies": {
-        "web-streams-polyfill": "^3.2.1"
+      "version": "3.11.174",
+      "resolved": "https://registry.npmjs.org/pdfjs-dist/-/pdfjs-dist-3.11.174.tgz",
+      "integrity": "sha512-TdTZPf1trZ8/UFu5Cx/GXB7GZM30LT+wWUNfsi6Bq8ePLnb+woNKtDymI2mxZYBpMbonNFqKmiz684DIfnd8dA==",
+      "license": "Apache-2.0",
+      "engines": {
+        "node": ">=18"
       },
       "optionalDependencies": {
-        "canvas": "^2.11.0"
+        "canvas": "^2.11.2",
+        "path2d-polyfill": "^2.0.1"
       }
     },
     "node_modules/pend": {
@@ -3782,14 +3794,6 @@
         "extsprintf": "^1.2.0"
       }
     },
-    "node_modules/web-streams-polyfill": {
-      "version": "3.3.3",
-      "resolved": "https://registry.npmjs.org/web-streams-polyfill/-/web-streams-polyfill-3.3.3.tgz",
-      "integrity": "sha512-d2JWLCivmZYTSIoge9MsgFCZrt571BikcWGYkjC1khllbTeDlGqZ2D8vD8E/lJa8WGWbb7Plm8/XJYV7IJHZZw==",
-      "engines": {
-        "node": ">= 8"
-      }
-    },
     "node_modules/webidl-conversions": {
       "version": "3.0.1",
       "resolved": "https://registry.npmjs.org/webidl-conversions/-/webidl-conversions-3.0.1.tgz",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@suffolklitlab/alkiln",
-  "version": "5.13.0-logs3",
+  "version": "5.13.1",
   "description": "Integrated automated end-to-end testing with docassemble, puppeteer, and cucumber.",
   "main": "lib/index.js",
   "scripts": {
@@ -47,7 +47,7 @@
     "minimatch": "3.0.5",
     "minimist": "1.2.8",
     "mocha": "9.2.2",
-    "pdfjs-dist": "3.2.146",
+    "pdfjs-dist": "3.11.174",
     "puppeteer": "22.15.0",
     "qs": "6.10.3",
     "sanitize-filename": "1.6.3",

package/tests/log_codes/check_codes.sh

@@ -55,8 +55,7 @@ fi
 
 # removed and are no longer used. Syntax used works with GitHub cli - [[:digit:]]
 # https://stackoverflow.com/a/6901221
-# Exclude files and paths
-instances=$(find "$where_to_look" -type f ! -name "check_codes.sh" ! -name "CONTRIBUTING.md" ! -name "$expected_instances_file" ! -name "debug_log.txt" ! -name "cucumber-report.txt" ! -path "*/node_modules/*" ! -path "*/ALKilnTests/*" ! -path "*/alkiln-*/*" ! -path "*/_alkiln*/*" ! -path "*/docs/decisions/*" ! -path "*/\.*" -print0 | xargs -0 -P 4 grep -0 -ro 'ALK[[:digit:]][[:digit:]][[:digit:]][[:digit:]]' | grep -v -- '--' )
+instances=$(find "$where_to_look" -type f ! -name "check_codes.sh" ! -name "CONTRIBUTING.md" ! -name "$expected_instances_file" ! -name "debug_log.txt" ! -name "cucumber-report.txt" ! -path "*/node_modules/*" ! -path "*/ALKilnTests/*" ! -path "*/alkiln-*/*" ! -path "*/_alkiln*/*" -print0 | xargs -0 -P 4 grep -0 -ro 'ALK[[:digit:]][[:digit:]][[:digit:]][[:digit:]]' | grep -v -- '--' )
 
 if [[ "$loudness" != "0" ]]; then
   total_instances=$(echo "$instances" | wc -l)

package/tests/log_codes/log_code_expected_instances.txt

@@ -4,11 +4,7 @@ Why we need duplicate codes sometimes: GitHub actions sometimes don't have ways
 
 The script that tests the log codes will ignore this file (or any file with this name), and any file with these names: check_codes.sh, debug_log.txt, cucumber-report.txt. It will also ignore files in folders with these names:, node_modules, ALKilnTests, alkiln-*, _alkiln*. That list might get updated, so for an up-to-date list, always check the file check_codes.sh where we use `--exclude=` and such.
 
-Reasons for deletion:
-0053 - duplicate log
-0173 - redundant
-
-ALK0000:0
+ALK0000:8
 ALK0001:1
 ALK0002:2
 ALK0003:2
@@ -26,7 +22,7 @@ ALK0014:1
 ALK0015:1
 ALK0016:1
 ALK0017:1
-ALK0018:1
+ALK0018:2
 ALK0019:2
 ALK0020:1
 ALK0021:1
@@ -37,10 +33,10 @@ ALK0025:1
 ALK0026:2
 ALK0027:2
 ALK0028:3
-ALK0029:2
+ALK0029:1
 ALK0030:2
-ALK0031:2
-ALK0032:2
+ALK0031:1
+ALK0032:1
 ALK0033:1
 ALK0034:1
 ALK0035:1
@@ -61,7 +57,7 @@ ALK0049:1
 ALK0050:1
 ALK0051:1
 ALK0052:1
-ALK0053:0
+ALK0053:1
 ALK0054:1
 ALK0055:1
 ALK0056:1
@@ -181,7 +177,7 @@ ALK0169:1
 ALK0170:1
 ALK0171:1
 ALK0172:1
-ALK0173:0
+ALK0173:1
 ALK0174:1
 ALK0175:1
 ALK0176:1

package/tests/unit_tests/getAllFields.test.js

@@ -7,11 +7,6 @@ chai.use(deepEqualInAnyOrder);
 const html = require('./html.fixtures.js');
 const fields = require('./fields.fixtures.js');
 const scope = require('../../lib/scope.js');
-
-const Log = require(`../../lib/utils/log.js`);
-const log = new Log({ path: `_alkiln-misc_artifacts`, context: `unit_tests getAllFields` });
-scope.set_log({ log_obj: log });
-
 const getAllFields = scope.getAllFields;
 
 chai.config.truncateThreshold = 0

package/tests/unit_tests/getMatchingRows.test.js

@@ -6,11 +6,6 @@ const tables = require('./tables.fixtures.js');
 const fields = require('./fields.fixtures.js');
 const matches = require('./matches.fixtures.js');
 const scope = require('../../lib/scope.js');
-
-const Log = require(`../../lib/utils/log.js`);
-const log = new Log({ path: `_alkiln-misc_artifacts`, context: `unit_tests getMatchingRows` });
-scope.set_log({ log_obj: log });
-
 const getMatchingRows = scope.getMatchingRows;
 // Match state var instantiated in steps.js. TODO: Add tests for such rows.
 scope.row_needs_trigger_flag = `ALKiln: no trigger variable needed`;

package/tests/unit_tests/normalizeTable.test.js

@@ -5,11 +5,6 @@ const expect = chai.expect;
 
 const tables = require('./tables.fixtures.js');
 const scope = require('../../lib/scope.js');
-
-const Log = require(`../../lib/utils/log.js`);
-const log = new Log({ path: `_alkiln-misc_artifacts`, context: `unit_tests normalizeTable` });
-scope.set_log({ log_obj: log });
-
 const normalizeTable = scope.normalizeTable;
 
 

package/docs/decisions/006_which_log_level_to_pick_2024_09_5.md

@@ -1,46 +0,0 @@
-# Which log levels to pick
-
-## Context and Problem Statement
-
-The log levels we're giving access to in Log are `success` (`info` with a special icon), `info`, `warn`, and `throw` (`error` and throw the error). Sometimes, like in the log file itself, we hard-code the icons and such. Those places have access to other levels, like `error`.
-
-We want to avoid distracting our users by logging errors everywhere, even when an error is what triggered the log. Does that hold true in the debug log? Successes can also be misleading about whether tests have passed or not.
-
-When picking the log level for a log, how do we know which level to choose?
-
-## Considered Options
-
-- Stay as true to technical behavior as possible.
-- Stay as clear to users as possible - use levels that will help users pay attention to what affects them.
-
-For example:
-
-`success`:
-  - Use whenever anything completes successfully.
-  - Only use for success of major operations.
-  - Use for every test success.
-  - Use for success of all the tests.
-`error`:
-- Always use `error` when an error happens.
-- Use `error` when an unexpected error happens.
-- Only use `error` for user-relevant errors.
-
-
-## Decision Outcome
-
-Distract the user as little as possible everywhere.
-
-`success`:
-  - Only log success once for success of all tests.
-  - Include the `success` icon in the Scenario "Passed" section of the report.
-`throw`:
-  - Use this level to throw errors for the user's tests (or our own internal tests).
-  - Use this if ALKiln itself needs to abort a test or the test suite.
-`error`:
-  - Avoid using `error` explicitly. Only the debug logs should use the `error` level, and only to record critical errors that come in with `throw`.
-`info`:
-  - Log expected errors as `info`. For example, the aborted promises when awaiting navigation.
-`warn`:
-  - Avoid using the word "error" in warnings if possible.
-  - Use `warn` in the console for messages the user should investigate.
-  - Use `warn` in the debug log for messages ALKiln devs might investigate if necessary. If the warning comes from non-critical unexpected behavior, do try to be clear about what happened, but also try to avoid using the word "error" if possible. E.g. "Skipped creating metadata for the logs" instead of "Error while creating metadata for the logs".

package/docs/decisions/reports_and_logs_2024_08_11.md

@@ -1,141 +0,0 @@
-# Shape and behavior of the report and log objects
-
-## Context and scope
-
-We have reports and logs we show to the user in the console and as artifacts. We have logs we use for development. cucumber also has logs we want to include in the above until we are confident we are handling all cases ourselves.
-
-Right now, the system for logging is fractured and scattered - reports log to the console and save completely separately from other logs. Logs that are not from the report don't get saved anywhere. Some logs only get shown in debug mode, which can be frustrating and unhelpful.
-
-## Goals
-
-Overview:
-
-- Unify the logging and report systems
-- Clarify their flow
-- Make log information more visible
-
-Details:
-
-- Log objects have statuses, icons, log codes (e.g. ALK0105), contextual info (e.g. `setup`, `takedown`, `invalid answer`), timestamps, descriptive text, and data (like full error traces).
-- These are the broad purposes of various logs:
-1. Setup and takedown messages.
-2. Test progress (a compact way to see what's happening/happened in each test):
-
-   Test1: .............F--
-   
-   Test 2: ..
-3. A pretty report at the end with details about each test. It has sections, like "failed" and "passed", headings, etc.
-4. cucumber's various console logs
-5. Lots of other informational logs for internal development and debugging purposes.
-I want to do different things with different logs:
-- During the tests, always log items 1, 2, 3, and 4 to the console.
-- During the tests, save items 2, 3, and 4 to a log as they come with all the info in the log objects - `report_log.txt`/`running_report.txt`/`report_run.txt` maybe. If we have to stop the tests early because of an infinite loop or something, this will at least show some information.
-- At the end of the tests, format items 2, 3, and 4, often with only part of the log object info, in a file called `report.txt`.
-- During the tests, save all of the items to a `verbose_log.txt` as they happen.
-- In debug mode, log all that stuff to the console while the tests are running.
-Right now, a few of the logs, like for the test progress (item 2), are printed with `stdout` inline while all others are logged with `console.log`.
-- Logs should accept multiple arguments to match console.log/etc. behavior.
-
-Note: The progress logs printed to the console have color codes. We also may want a plain text version without any colors to save in the report log and show in the Playground[^1] "console" and/or a version converted to HTML that does have styles. The latter may be for something easier to digest in a browser and/or to show visually in the Playground version of the tests.
-
-Questions:
-- Should `log` throw errors? Otherwise everywhere we need to error, we need to use `log` and `throw`, but I am unable to find a way to remove the current function from an error stack/trace.
-- How do we capture "errors" that are more subtle? Keep the word "error" in the "context"/"types" list? For example, expected errors:
-  - Invalid answers on the form that are then assessed as valid behavior?
-  - `AbortError`s of promises that should indeed have been aborted.
-- Should we allow "in-between"s for all parts of the log? All together: pre-everything (new lines, dividers, etc), icon/context/etc., pre-logs, logs (the actual messages to print), pre-data, data, post-data? We can default to nothing for all of those.
-- How do we differentiate between methods that log to the console vs. methods that just store data?
-
-[^1]: Don't go down this rabbit hole. Broadly - with the "Playground" version, users see the results as a web page instead of in the GitHub job console or in the artifacts. The users run the tests on their own server. This has to do with the platform we built ALKiln for - [docassemble](https://docassemble.org/). It gives users a faster iteration cycle.
-
-## Non/anti-goals
-
-- Spend a month on this
-- Create a complex and heavy system to try to abstract absolutely everything
-
-## The actual design
-
-This design still seems a little complex and potentially too coupled with reports.
-
-### System-context diagram
-
-```
-logic code -> logger -> report -----------> console
-              ^     |-> console         |-> stdout/progress
-  cucumber ---|     |-> running report  |-> final report.txt
-                    |-> verbose log
-```
-
-```
-logic code -> logger ------> report ------> final report.txt
-              ^     |-> console
-  cucumber ---|     |-> stdout/inline/progress
-                    |-> running report
-                    |-> verbose log
-```
-
-```
-              |------------------------------------<|
-              v                                     |
-logic code -> logger -> report -----------> format prettily
-              ^     |-> console
-  cucumber ---|     |-> running report
-                    |-> verbose log
-                    |-> stdout/progress
-                    |-> final report.txt
-```
-
-### APIs
-
-Everything saves to the "verbose"/"debug" log. Aside from that:
-
-`log.info/warning/success/error` methods log to console. This includes, e.g, setup, takedown which show up in GitHub workflow job logs.
-
-`log.report` saves to the running report then uses a report obj focused on cosmetics that has `.heading/table/header/error/etc` methods. Maybe a `.stdout/inlne` method, which then prints to the console immediately.
-
-`log.verbose/debug` (name?) - Only save to verbose/debug log with log codes, etc.
-
-### Data storage
-
-- `report.txt` - final pretty output for the user with headings, etc.
-- Each Scenario's `report.txt` - pretty output in each test's folder.
-- `running_report_log.txt` (name?) - ugly, but still sparse, giving the user some info about what happened during the tests without overwhelming them.
-- `verbose.txt` (name? `debug`?) - very ugly and full of all the information from everywhere else and more. Useful for internal development and troubleshooting. Includes setup and takedown.
-
-It may be complex to store setup and takedown output in the verbose/debug file. `console.Console` cannot append to a file[^2], so we would have to figure out a work-around. One approach could be to always first copy from the existing verbose file and paste those contents back into the file as the first log. That may take setting up some fallbacks to avoid errors.
-
-[^2]: `fs.appendFile()` only takes strings and doesn't log exactly like the console. I want to log exactly like the console to make it easy to search for words I and others see in the console output.
-
-### Code and pseudo-code
-
-For capturing console output, look into how to get the `stdin` for capturing various console output. https://stackoverflow.com/a/54202970:
-
-```js
-const stdin = process.openStdin()
-
-process.stdout.write('Enter name: ')
-
-stdin.addListener('data', text => {
-  const name = text.toString().trim()
-  console.log('Your name is: ' + name)
-
-  stdin.pause() // stop reading
-})
-```
-
-### Degree of constraint
-
-I think this can basically be greenfield (designed from scratch). We do have a current system, but I think we can easily convert our existing code to a new system.
-
-## Alternatives considered
-
-- The `report` object saves to the running report and then sends that same information to the `log` object. Also prints the final report. This includes `stdout` logs. `log` remains otherwise the same as described above.
-- `log` handles `stdout` logs and leaves them out of the report.
-- For report content, `log` would call to `report`, which would do pretty formatting and then hand the format text back to `log` to be saved and/or printed to the console. I'm not sure how `log` could then know what to do with the output - leave out the codes/etc. when it logs to the console and/or saves to the final report.txt.
-- Avoid the complexity of storing setup and takedown output in the verbose/debug file. In GitHub, they're in the GitHub console. Locally, we see the results immediately. On the other hand, storing them ourselves lets us look for information in just one place.
-
-## Cross-cutting concerns
-
-_Security, privacy, observability, etc._
-
-The same ones we've already dealt with for our current logs.

package/tests/unit_tests/log.test.js

@@ -1,20 +0,0 @@
-const chai = require('chai');
-const expect = chai.expect;
-
-const Log = require('../../lib/utils/log.js');
-
-const path = `_alkiln-misc_artifacts`;
-const log = new Log({ path, context: `unit_tests log_tests` });
-
-describe(`log`, async function () {
-
-  // Test it creates a new folder?
-  // Test the contents that it saves to various files?
-
-  it(`returns a debug message from an empty log.debug`, async function() {
-    let result = log.debug();
-    expect( result ).to.include( `🐛 ALK000v DEBUG` );
-  });
-
-});
-