agoric-sdk says
|
const LABEL_INSTANCES = (env.DEBUG || '') |
|
.split(':') |
|
.includes('label-instances'); |
whereas endo says
https://github.com/endojs/endo/blob/ac9bb3b03bfa67fdbbaf9a6febde1fba7ba154da/packages/exo/src/exo-makers.js#L14
const LABEL_INSTANCES = DEBUG.split(',').includes('label-instances');Thus, one splits on commas and the other splits on colons. IIRC, originally both agreed on the wrong answer. But it seems the correction to the right answer happened only in one place, leaving them inconsistent.
As to what the right answer is, grepping for DEBUG yielded some more surprises:
|
} else if (DEBUG.includes('agoric')) { |
tests only for string inclusion, so setting DEBUG=noagoric will mean the same as DEBUG=agoric.
|
pspawnEnv.DEBUG = 'agoric,SwingSet:vat,SwingSet:ls'; |
suggests that our convention is that the outer separator is comma, and that colon is used within each comma-separated segment for something like componentName:optionName. If that is correct, then the endo comma for label-instances is correct and the agoric-sdk code is buggy. Hence, I'm filing this as an agoric-sdk bug. But in that case, the endo code
https://github.com/endojs/endo/blob/ac9bb3b03bfa67fdbbaf9a6febde1fba7ba154da/packages/eventual-send/src/track-turns.js#L23
const VERBOSE = DEBUG.split(':').includes('track-turns');is buggy.
Related:
We can now switch agoric-sdk over to use @endo/env-options rather that rolling our own.
Controversial: One of us thinks that...
We should whenever possible avoid inventing yet another textual language that needs to be parsed accurately. This leads exactly to the hazards we fell into above. By contrast, the environment variables for the lockdown options are separate variables per option, each prefixed with LOCKDOWN_. We should deprecate DEBUG entirely and shift to this env-var-per-option with common prefix convention instead,
agoric-sdk says
agoric-sdk/packages/swingset-liveslots/src/virtualObjectManager.js
Lines 45 to 47 in 8baf0aa
whereas endo says
https://github.com/endojs/endo/blob/ac9bb3b03bfa67fdbbaf9a6febde1fba7ba154da/packages/exo/src/exo-makers.js#L14
Thus, one splits on commas and the other splits on colons. IIRC, originally both agreed on the wrong answer. But it seems the correction to the right answer happened only in one place, leaving them inconsistent.
As to what the right answer is, grepping for
DEBUGyielded some more surprises:agoric-sdk/packages/agoric-cli/src/anylogger-agoric.js
Line 10 in 8baf0aa
tests only for string inclusion, so setting
DEBUG=noagoricwill mean the same asDEBUG=agoric.agoric-sdk/packages/agoric-cli/src/start.js
Line 73 in 8baf0aa
suggests that our convention is that the outer separator is comma, and that colon is used within each comma-separated segment for something like
componentName:optionName. If that is correct, then the endo comma forlabel-instancesis correct and the agoric-sdk code is buggy. Hence, I'm filing this as an agoric-sdk bug. But in that case, the endo codehttps://github.com/endojs/endo/blob/ac9bb3b03bfa67fdbbaf9a6febde1fba7ba154da/packages/eventual-send/src/track-turns.js#L23
is buggy.
Related:
We can now switch agoric-sdk over to use
@endo/env-optionsrather that rolling our own.Controversial: One of us thinks that...
We should whenever possible avoid inventing yet another textual language that needs to be parsed accurately. This leads exactly to the hazards we fell into above. By contrast, the environment variables for the
lockdownoptions are separate variables per option, each prefixed withLOCKDOWN_. We should deprecateDEBUGentirely and shift to this env-var-per-option with common prefix convention instead,