1488 Passable (REVERTED in #1961) #1933

turadg · 2024-01-08T22:50:31Z

closes: #1488

Description

Makes Passable a generic type instead of any.
Defines overloads for passStyleOf to return the actual style.
Defines the Key in terms of Passable
Makes a ton of fixes and suppressions in places that relied on the previous any's

Security Considerations

n/a

Scaling Considerations

n/a

Documentation Considerations

Better types are better documentation.

Testing Considerations

I improved the test coverage. Additional suggestions welcomed.

Upgrade Considerations

These changes may cause type errors downstream. I don't think we should call those breaking change à la semver because they don't affect the runtime.

dckc

is a recursive definition of Passable feasible?

packages/pass-style/src/types.js

dckc · 2024-01-09T23:19:28Z

packages/pass-style/src/types.js

+ * (p: Iterable): 'remotable';
+ * (p: Iterator): 'remotable';


I don't understand why Iterable and Iterator are here. I wonder what I'm missing.

hacks along the way. I'll see about removing them

I didn't know how else to handle these cases

endo/packages/patterns/test/test-copyMap.js

Lines 131 to 133 in 3d927c3

t.is(passStyleOf(entriesIterable), 'remotable');

const entriesIterator = entriesIterable[Symbol.iterator]();

t.is(passStyleOf(entriesIterator), 'remotable');

oh. wild. I didn't realize getCopyMapEntries() returned a passable value.

I did know that tsc thinks getCopyMapEntries() returns any before this PR.
https://github.com/Agoric/dapp-offer-up/blob/8da2191af4a3333e0ec0f0cd884f739fa021950a/contract/src/gameAssetContract.js#L21

dckc · 2024-01-09T23:21:26Z

packages/pass-style/src/types.js

- * @typedef {Passable} RemotableObject
+ * @template {string} S pass style
+ * @template {InterfaceSpec} I interface tag
+ * @typedef {PassStyled<S> & {[Symbol.toStringTag]: I}} TaggedRecord


This use of "Tagged" is different from the tagged passStyle, right? That seems like a source of confusion.

Different, yes. This is as in "toStringTag". Naming suggestions welcomed

I see.... 🤔

"PassStyled" seems like a good name... do we need both types, or can they be collapsed together?

I wasn't sure. I thought I saw an object with the [PASS_STYLE] property and not the toStringTag or vice-versa. Are they supposed to be always present together?

Are they supposed to be always present together?

Yes, AFAIK. A Tagged has own [PASS_STYLE]: "tagged", [Symbol.toStringTag]: $tag, and a Remotable has a prototype chain in which the penultimate object has own [PASS_STYLE]: "remotable", [Symbol.toStringTag]: $iface (where both $tag and $iface must be strings, and the latter must either be "Remotable" or start with "Alleged: " or "DebugName: ").

Thanks! 1b30d60

gibson042

This is very nice!!!

packages/marshal/src/marshal.js

gibson042 · 2024-01-10T01:10:55Z

packages/pass-style/src/passStyleOf.js

@@ -81,28 +81,28 @@ const makePassStyleOf = passStyleHelpers => {
   * structures, so without this cache, these algorithms could be
   * O(N**2) or worse.
   *
-   * @type {WeakMap<Passable, PassStyle>}
+   * @type {WeakMap<WeakKey, PassStyle>}


Do we have a TypeScript type corresponding with our Key concept (Passable structure in which each leaf is a Passable primitive value or a Remotable)?

That reminds me: Key is another motivation for parameterizing Passable: Passable<Remotable, never>

PureData is Passable<never, never> as discussed earlier

gibson042 · 2024-01-10T01:13:24Z

packages/pass-style/src/passStyleOf.js

+          // sanity check on falsy values. Do 'get' first to get the type narrowing of the `if`
+          assert(passStyleMemo.has(inner));


What value is this sanity check providing, given that get is guaranteed to return undefined for absent keys?

Suggested change

// sanity check on falsy values. Do 'get' first to get the type narrowing of the `if`

assert(passStyleMemo.has(inner));

Indeed. I flubbed the implementation but the case I was concerned about is if passStyleMemo has inner but that value is falsy. Does this need to handle that?

I don't think so, because passStyleMemo values are always PassStyle strings. And if we do care, I guess the place for such an assertion would be adjacent to set rather than get.

Unfortunately, simpy knowledge that it is a string does not by itself imply that it is truthy, since the empty string is falsy. In this case, we know that it is always a pass-style string, which is always a non-empty string and thus always truthy. But still, to avoid even needing to worry about this edge case, I suggest rewriting

if (inner) {

to

if (inner !== undefined) {

or

if (typeof inner === 'string') {

FWIW, I prefer the !== undefined .

In any case, given that we statically know we're only putting strings in there, I'd say no further sanity check is needed.

gibson042 · 2024-01-10T01:16:56Z

packages/pass-style/src/remotable.js

+/**
+ * Simple semantics, just tell what interface (or undefined) a remotable has.
+ * @type {{
+ * <T extends string>(val: import('./types.js').TaggedRecord<any, T>): T;
+ * (val: any): any;
+ * }}


Cool! Can we narrow further?

Suggested change

/**

* Simple semantics, just tell what interface (or undefined) a remotable has.

* @type {{

* <T extends string>(val: import('./types.js').TaggedRecord<any, T>): T;

* (val: any): any;

* }}

/**

* Simple semantics, just tell what interface (or undefined) a remotable has.

* @type {{

* <T extends string>(val: import('./types.js').TaggedRecord<any, T>): T;

* (val: any): string | undefined;

* }}

Since remotable tags are only for debugging, I don't think we should use them for static typing.

Can we narrow further?

~~I had tried that and it caused some problems. I'll document.~~

Works! thx

Since remotable tags are only for debugging, I don't think we should use them for static typing.

That's what this doc says,

endo/packages/patterns/src/types.js

Lines 310 to 313 in 40f6cf8

* @property {(label?: string) => Matcher} remotable

* Matches a far object or its remote presence.

* The optional `label` is purely for diagnostic purposes and does not

* add any constraints.

but when we changed the label it failed rehydration,
https://github.com/Agoric/agoric-sdk/blob/62a7c9c42007020994f6036cf4090590e4811b8e/packages/zoe/src/zoeService/startInstance.js#L65

Is that a bug?

It's an unpleasant surprise, at least.

I suppose the tag is pass-invariant, so using it for static typing is maybe not all that bad.

when we changed the label it failed rehydration, https://github.com/Agoric/agoric-sdk/blob/62a7c9c42007020994f6036cf4090590e4811b8e/packages/zoe/src/zoeService/startInstance.js#L65

Is that a bug?

Plausibly, although not related to this PR. The fundamental issue is that agoric-sdk doesn't allow a new vat incarnation to change stateShape, and adding/removing/altering the label of a Matcher<'remotable'> is a change (albeit a benign one from internal structure like { [Symbol.for("passStyle")]: "tagged", [Symbol.toStringTag]: "match:kind", payload: "remotable" } to { [Symbol.for("passStyle")]: "tagged", [Symbol.toStringTag]: "match:remotable", payload: { label: "$label" } }). This will need to be allowed in the fix for Agoric/agoric-sdk#7337 / Agoric/agoric-sdk#7407 .

gibson042 · 2024-01-10T01:26:29Z

packages/pass-style/src/types.js

- * @typedef {Passable} RemotableObject
+ * @template {string} S pass style
+ * @template {InterfaceSpec} I interface tag
+ * @typedef {PassStyled<S> & {[Symbol.toStringTag]: I}} TaggedRecord


"PassStyled" seems like a good name... do we need both types, or can they be collapsed together?

packages/patterns/src/keys/copySet.js

packages/patterns/src/keys/merge-set-operators.js

gibson042 · 2024-01-10T01:32:06Z

packages/patterns/src/types.js

@@ -22,7 +22,7 @@ export {};
 /** @typedef {import('@endo/marshal').RankCover} RankCover */

 /**
- * @typedef {Passable} Key
+ * @typedef {Exclude<Passable, Error | Promise>} Key


This is still overly broad; we should probably have a TODO.

Exclude at the top level doesn't address promises and errors nested further down. Again, I hope we can parameterize Passable.

gibson042 · 2024-01-10T01:32:18Z

packages/patterns/src/types.js

@@ -61,7 +61,7 @@ export {};
 */

 /**
- * @typedef {Passable} Pattern
+ * @typedef {Exclude<Passable, Error | Promise>} Pattern


Likewise here.

mhofman · 2024-01-10T19:09:58Z

I am only following from a distance, but I believe you can have circular type definitions in .d.ts files, but not in JSDoc

turadg · 2024-01-10T19:37:20Z

I am only following from a distance, but I believe you can have circular type definitions in .d.ts files, but not in JSDoc

I'm not sure about that but I do know the solution is more complicated than changing to .ts. Even with .ts,

export type CopyArray<T extends Passable = Passable> = T[];

causes

Type alias 'PassByCopy' circularly references itself.

erights · 2024-01-10T22:53:59Z

Attn @michaelfig re #1933 (comment) circular types mysteries

dckc · 2024-01-10T22:59:57Z

#1952 shows how to address the circular type issues, I think. I discussed it with @turadg today. It's not clear how much work it would be to finish that direction.

It's based on earlier ocapn work, but at the time I learned tsc's limitations around self-referential types, I neglected to take good notes.

@mhofman gave a particularly useful pointer earlier today:

Recursive type references microsoft/TypeScript#33050

turadg · 2024-01-10T23:16:53Z

#1952 shows how to address the circular type issues, I think. I discussed it with @turadg today. It's not clear how much work it would be to finish that direction.

I think that solved it, @dckc . PTAL 5b8b349 9aac68e.

erights

Very enthusiastic to see this PR be merged!

Looks Good To Me so far, but review not yet completed.

erights · 2024-01-10T23:02:11Z

packages/marshal/src/encodeToCapData.js

@@ -117,7 +117,7 @@ export const makeEncodeToCapData = (encodeOptions = {}) => {
   * Readers must not care about this order anyway. We impose this requirement
   * mainly to reduce non-determinism exposed outside a vat.
   *
-   * @param {Passable} passable
+   * @param {any} passable


Curious: Why did this "regress" from Passable to any?

(scare quotes because the old Passable meant any. So the real question is: Why couldn't this become the new Passable?)

Likewise for similar changes elsewhere.

All the string replacements of old-Passable to any is because the new (non-any) Passable caused too many errors and I judged solving them to not be worth it. Usually because the following code relied heavily on dynamic type inspection and would not benefit from the static type information. This was mostly in switch statements where TS cannot statically infer the type narrowing being used.

erights · 2024-01-10T23:03:17Z

packages/marshal/src/encodeToCapData.js

@@ -269,11 +269,11 @@ harden(makeEncodeToCapData);
 * @property {(
 *   encodedRemotable: Encoding,
 *   decodeRecur: (e: Encoding) => Passable
- * ) => (Promise|Remotable)} [decodeRemotableFromCapData]
+ * ) => (Promise|RemotableObject)} [decodeRemotableFromCapData]


Thanks for doing this type renaming. Having a type name collide with a value (function) name was really terrible. Good to see this straightened out. No change suggested.

erights · 2024-01-10T23:12:52Z

packages/pass-style/src/passStyleOf.js

+          // sanity check on falsy values. Do 'get' first to get the type narrowing of the `if`
+          assert(passStyleMemo.has(inner));


Unfortunately, simpy knowledge that it is a string does not by itself imply that it is truthy, since the empty string is falsy. In this case, we know that it is always a pass-style string, which is always a non-empty string and thus always truthy. But still, to avoid even needing to worry about this edge case, I suggest rewriting

if (inner) {

to

if (inner !== undefined) {

or

if (typeof inner === 'string') {

FWIW, I prefer the !== undefined .

erights · 2024-01-10T23:14:30Z

packages/pass-style/src/passStyleOf.js

+          // sanity check on falsy values. Do 'get' first to get the type narrowing of the `if`
+          assert(passStyleMemo.has(inner));


In any case, given that we statically know we're only putting strings in there, I'd say no further sanity check is needed.

erights · 2024-01-10T23:17:47Z

packages/patterns/src/keys/checkKey.js

 const keyMemo = new WeakSet();

 /**
- * @param {Passable} val
+ * @param {Key} val


Excellent!

No change suggested.

erights · 2024-01-10T23:19:11Z

packages/patterns/src/patterns/patternMatchers.js

+// @ts-nocheck So many errors that the suppressions hamper readability.
+// TODO parameterize MatchHelper which will solve most of them


Interesting.

No change suggested.

erights

LGTM!!

erights · 2024-01-10T23:29:20Z

packages/pass-style/src/types.d.ts

+};
+export type ExtractStyle<P extends PassStyled<any>> = P[typeof PASS_STYLE];
+export type PassByCopy =
+  | import('type-fest').Primitive


TIL 'type-fest'. Does everyone else already know about this? Is it worth a comment or URL?

I figure it's intuitive that it's an NPM package and those are easy to find. But I have to clean up the commits anyway so I'll include this link https://github.com/sindresorhus/type-fest/blob/main/source/primitive.d.ts

This is a weird dependency to take on for non test types. It's simple enough, can we just inline it?

Ok, I'll inline it.

erights · 2024-01-10T23:31:10Z

packages/pass-style/src/types.d.ts

+  | any[]
+  | CopyRecord


Curious why we do use CopyRecord rather than Record but we use any[] rather than CopyArray?

Also, shouldn't this at least be Passable[], or does this encounter recursive type problems again?

changed to CopyArray

erights · 2024-01-10T23:35:41Z

packages/pass-style/src/types.d.ts

+export type PassByRef =
+  | RemotableObject
+  | Promise<RemotableObject>
+  | Promise<PassByCopy>;


I was going to suggest

Suggested change

export type PassByRef =

| RemotableObject

| Promise<RemotableObject>

| Promise<PassByCopy>;

export type PassByRef =

| RemotableObject

| Promise<Passable>;

but then I realized that your's correctly excludes Promise<Promise>, which is great! No change suggested.

You could likely do Promise<Awaited<Passable>>

erights · 2024-01-10T23:37:47Z

packages/pass-style/src/types.d.ts

+export type Passable<
+  PC extends PassableCap = PassableCap,
+  E extends Error = Error,


Took me awhile to understand what's going on here. This is awesome! No change suggested.

erights · 2024-01-10T23:41:33Z

packages/pass-style/src/types.d.ts

+export type PassStyleOf = {
+  (p: undefined): 'undefined';


I don't understand the type notation here. What does it mean?

What especially confuses me is { ... : ...
suggests a record type where the thing to the left of the colon is a property key. But that does not look consistent with the rest. From the rest, I'd guess that it is a type overload, but overloaded on what? Is p a parameter?

Yep, it defines overloads for the function signature. If the call matches a function that has one parameter, of type undefined, then the return type is the string literal 'undefined'. Each case defines another signature. They're matched in order so the most general is last.

erights · 2024-01-10T23:42:50Z

packages/pass-style/src/types.d.ts

+  (p: any[]): 'copyArray';
+  (p: Iterable<any>): 'remotable';
+  (p: Iterator<any, any, undefined>): 'remotable';
+  <T extends PassStyled<any>>(p: T): ExtractStyle<T>;


Is this too open ended? Does it loose the static knowledge that the extracted style can only be one of a small number of enumerated strings?

tightened up with,

export type TaggedOrRemotable = 'tagged' | 'remotable';

erights · 2024-01-10T23:43:13Z

packages/pass-style/src/types.d.ts

+ * trip (as exists between vats) to produce data structures disconnected from
+ * any potential proxies.
+ */
+export type PureData = Passable<never, never>;


Awesome! No change suggested.

erights · 2024-01-10T23:46:27Z

packages/pass-style/src/types.d.ts

+ * This is an interface specification.
+ * For now, it is just a string, but will eventually be `PureData`. Either


No change suggested.

But noting that I doubt we ever would change this from a string. But the time we'd want to, it will be too great a compat hazard to bother with. Unless we encounter a compelling need, which I do not expect.

I'll revise the text to something less certain than "will eventually be"

erights · 2024-01-10T23:48:12Z

packages/pass-style/src/types.d.ts

+ *
+ * See the various uses for good examples.
+ */
+export type Checker = (


No change suggested.

Just FYI as of #1935 I expect I'll migrate Checker to a lower level utils package. But there's no reason for that to affect this PR, which will merge first.

mhofman

Did a quick pass. Lots of great changes. I'm a little surprised some type definitions drop down to not plumbing through the PassableCap restriction, and I would need to look closer where that loosening would have an impact, but we can always iterate on that later

mhofman · 2024-01-11T00:17:59Z

packages/pass-style/src/types.d.ts

+  | 'remotable'
+  | 'error'
+  | 'promise';
+export type PassStyled<S extends string> = {


Why not extends PassStyle?

mhofman · 2024-01-11T00:20:42Z

packages/pass-style/src/types.d.ts

+export type PassByRef =
+  | RemotableObject
+  | Promise<RemotableObject>
+  | Promise<PassByCopy>;


You could likely do Promise<Awaited<Passable>>

packages/pass-style/src/types.d.ts

chore(patterns): define Key using parameterized Passable

tighten Pattern better RemotableObject WIP punt getInterfaceOf WIP fix sorting restore PassableCap fix valMap type runtime fix decodeErrorCommon acknowledge deferred work fixes to get types building

erights · 2024-01-20T04:17:41Z

@turadg @kriskowal all,

Now that the endo-agoric-sdk sync is behind us, I would love to see this PR move forward again! What is needed?

At Agoric/agoric-sdk#8771 I have a PR of postponed changes on the agoric-sdk side that were waiting on that sync. Would that one help or hurt the effort to move forward on this PR?

turadg · 2024-01-20T16:04:49Z

What is needed?

In Endo, a PR re-applying these changes.

And in agoric-sdk a PR that integrates with that PR, demonstrating agoric-sdk CI passing. That way when land the Endo PR we can follow up quickly with a release and make the SDK PR the basis of an Endo upgrade.

I've started in

1488 Endo Passable Agoric/agoric-sdk#8774

At Agoric/agoric-sdk#8771 I have a PR of postponed changes on the agoric-sdk side that were waiting on that sync. Would that one help or hurt the effort to move forward on this PR?

I'm not sure. I think 8771 should be prioritized, though, because it doesn't require an Endo release. I'll try to get 8774 passing and I expect by the time it's R4R that master will have 8771 so I'll solve whatever else comes up.

closes: #1488 ## Description Reattempting: - #1933 Again: - Makes `Passable` a generic type instead of `any`. - Defines overloads for `passStyleOf` to return the actual style. - Defines the `Key` in terms of `Passable` - Makes a ton of fixes and suppressions in places that relied on the previous `any`'s ### Security Considerations n/a ### Scaling Considerations n/a ### Documentation Considerations Better types are better documentation. ### Testing Considerations - [ ] Agoric/agoric-sdk#8774 ### Upgrade Considerations These changes may cause type errors downstream. I don't think we should call those breaking change à la semver because they don't affect the runtime.

@type

closes: #XXXX refs: #1933 ## Description The declaration site had both a correct @type declaration and a redundant vestigial partial @returns declaration. Because the latter also was not properly formed, it caused the warning ``` .../endojs/endo/packages/pass-style/src/remotable.js 175:1 warning Missing JSDoc @returns type jsdoc/require-returns-type ✖ 1 problem (0 errors, 1 warning) ``` This PR removes it, and does a bit of trivial polishing of the remainder. ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations more accurate type declarations should eventually help documentation ### Testing Considerations none ### Upgrade Considerations none

dckc reviewed Jan 8, 2024

View reviewed changes

packages/pass-style/src/types.js Outdated Show resolved Hide resolved

turadg force-pushed the 1488-Passable branch 2 times, most recently from a6c2693 to 75605a1 Compare January 9, 2024 22:43

turadg mentioned this pull request Jan 9, 2024

more typedoc #1928

Merged

dckc reviewed Jan 9, 2024

View reviewed changes

gibson042 reviewed Jan 10, 2024

View reviewed changes

dckc mentioned this pull request Jan 10, 2024

define Key, PureData using parameterized Passable (WIP) #1952

Draft

gibson042 mentioned this pull request Jan 10, 2024

Upgraded stateShape may be incompatible with existing state Agoric/agoric-sdk#7337

Closed

turadg force-pushed the 1488-Passable branch from 5baf106 to 65d32b5 Compare January 10, 2024 19:56

turadg mentioned this pull request Jan 10, 2024

fix type imports in 'marshal' package #1940

Merged

turadg force-pushed the 1488-Passable branch from 65d32b5 to 05f133e Compare January 10, 2024 21:21

turadg requested a review from gibson042 January 10, 2024 21:24

turadg marked this pull request as ready for review January 10, 2024 21:24

turadg force-pushed the 1488-Passable branch from 05f133e to 4cd95d9 Compare January 10, 2024 23:15

erights reviewed Jan 10, 2024

View reviewed changes

erights approved these changes Jan 10, 2024

View reviewed changes

mhofman self-requested a review January 11, 2024 00:17

mhofman reviewed Jan 11, 2024

View reviewed changes

turadg force-pushed the 1488-Passable branch from 4cd95d9 to 1b30d60 Compare January 11, 2024 00:54

turadg enabled auto-merge January 11, 2024 00:55

turadg and others added 4 commits January 10, 2024 20:01

test: isFake type

e6d6984

chore(types): type makeTagged

935718b

feat(types): generic Passable

ae6ad15

chore(patterns): define Key using parameterized Passable

81aced1

chore(patterns): define Key using parameterized Passable

turadg added 2 commits January 10, 2024 20:01

chore(types): misc accommodations

418b2da

tighten Pattern better RemotableObject WIP punt getInterfaceOf WIP fix sorting restore PassableCap fix valMap type runtime fix decodeErrorCommon acknowledge deferred work fixes to get types building

chore(types): consolidate PassStyled type

ddcdad1

turadg force-pushed the 1488-Passable branch from 1b30d60 to ddcdad1 Compare January 11, 2024 01:01

turadg merged commit e423804 into master Jan 11, 2024
14 checks passed

turadg deleted the 1488-Passable branch January 11, 2024 01:09

erights mentioned this pull request Jan 11, 2024

fix(pass-style): remove redundant vestigial @returns declaration #1958

Merged

turadg mentioned this pull request Jan 11, 2024

Revert "1488 Passable" #1961

Merged

dckc changed the title ~~1488 Passable~~ 1488 Passable (REVERTED in #1961) Jan 11, 2024

This was referenced Jan 20, 2024

refactor: postponed removals and simplifications Agoric/agoric-sdk#8771

Merged

deeplyFulfilled erases type information #1257

Closed

turadg mentioned this pull request Apr 23, 2024

1488 Passable redux #2238

Merged

1 task

	t.is(passStyleOf(entriesIterable), 'remotable');
	const entriesIterator = entriesIterable[Symbol.iterator]();
	t.is(passStyleOf(entriesIterator), 'remotable');

		// sanity check on falsy values. Do 'get' first to get the type narrowing of the `if`
		assert(passStyleMemo.has(inner));

	* @property {(label?: string) => Matcher} remotable
	* Matches a far object or its remote presence.
	* The optional `label` is purely for diagnostic purposes and does not
	* add any constraints.

		// @ts-nocheck So many errors that the suppressions hamper readability.
		// TODO parameterize MatchHelper which will solve most of them

		* This is an interface specification.
		* For now, it is just a string, but will eventually be `PureData`. Either

1488 Passable (REVERTED in #1961) #1933

1488 Passable (REVERTED in #1961) #1933

Conversation

turadg commented Jan 8, 2024 • edited Loading

Description

Security Considerations

Scaling Considerations

Documentation Considerations

Testing Considerations

Upgrade Considerations

dckc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gibson042 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

turadg Jan 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

turadg Jan 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mhofman commented Jan 10, 2024

turadg commented Jan 10, 2024

erights commented Jan 10, 2024

dckc commented Jan 10, 2024 • edited Loading

turadg commented Jan 10, 2024

erights left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

erights left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

turadg Jan 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mhofman left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

turadg commented Jan 8, 2024 •

edited

Loading

turadg Jan 10, 2024 •

edited

Loading

turadg Jan 10, 2024 •

edited

Loading

dckc commented Jan 10, 2024 •

edited

Loading

erights left a comment •

edited

Loading

turadg Jan 11, 2024 •

edited

Loading