feat(reflect): add `function_declaration` API to set initializer and inspect parameters #831

JohelEGP · 2023-11-15T04:14:59Z

I've been playing around with program-defined metafunctions in #797.
It's been a terrific experience.

This PR enhances the reflection API on functions.

get_parameters returns the objects in the parameter list.
add_initializer sets the function's initializer.

main's reflection API on a function has very limited queries.
Returning the parameters permits generating code based on inspection.
To make full use of that, I allow setting the function's initializer.
It also convenience members:

declaration::get_arguments.
type_declaration::get_member_functions_needing_initializer.

Here's some of the things that can be done with this PR:

Write a metafunction that set a function's initializer by inspecting its signature.
For an example, see @sfml at Playing with the meta functions / writing own meta functions #789 (reply in thread).
It's on my TODO list to also play with the visitor of @unions discussed at How to use union metafunction to replace variant member and member functions that call std::visit. #766.
Parameter introspection will also be needed for
the highly wanted feature mentioned at Informal meetup at CppCon 2023 @ 12.30 Monday 2 Oct #650 (comment):

[…] writing a metafunction that generates compile-time file output (e.g., to generate code in another language, such as a Java/Swift wrapper for a C++ object by writing my_interface: @java_interface type = { ... }.

Incidentally, fix a bug in declaration::get_parent.

I've also noticed an inconsistency declaration's API.
type returns a std::string, whereas name returns a std::string_view.

Testing summary:

100% tests passed, 0 tests failed out of 858

Total Test time (real) =  47.70 sec

Acknowledgements:

Tested thanks to https://github.com/modern-cmake/cppfront.
Commit messages follow Conventional Commits 1.0.0.
Comments and commit messages follow Semantic Line Breaks.

JohelEGP · 2023-11-23T22:44:37Z

Here's another bug.

A member sum; is a valid declaration in the grammar which a metafunction can process.
But t.add_member("sum;"); fails.
The use case is letting a latter (part of the) metafunction process it.

Although sum := 0; is rejected with a type scope variable must have a declared type,
add_member accepts that, so I would expect sum; to also be accepted.

JohelEGP · 2023-11-26T16:54:39Z

Another thing is that you don't have access to the type's template parameters.
That makes it impossible to generate this members that use CRTP.
Although P3009 could cover this use case if it were accepted.

JohelEGP · 2023-12-01T00:43:40Z

A minor inconsistency is that most built-in metafunctions are found by ADL.
Except for @print, because declaration_base::print exists.
So you can do t.basic_value(),
but not t.print(); (which errors due to an unused std::string return value).

Johel, can you give this a try in your test code and make sure your test code still works as expected? I had to create a little test to exercise it, since the new functions aren't used in this PR.

hsutter

Thanks! Here's a set of review comments that go with the commit I just pushed. Please check that it still works for your use cases, and any other feedback?

I think this is ready to merge if you have nothing more to add/tweak?

hsutter · 2023-12-15T22:31:42Z

source/reflect.h2

+        while !ret.emplace_back(get_argument(count)).empty() { count++; } // No `next` (#832).
+        ret.pop_back();
+        return ret;
+    }


Would the following be equivalent?

get_arguments: (inout this) -> std::vector<std::string> = { metafunction_used = true; return metafunction_args; }

I tried a quick example and it seems to be the same.

Definitely.
To think it was so easy.

hsutter · 2023-12-15T22:32:22Z

source/reflect.h2

@@ -272,7 +279,7 @@ declaration: @polymorphic_base @copyable type =
    as_type     : (this) -> type_declaration     = type_declaration(n, this);
    as_alias    : (this) -> alias_declaration    = alias_declaration(n, this);

-    get_parent  : (this) -> declaration          = declaration(n, this);
+    get_parent  : (this) -> declaration          = declaration(n*.parent_declaration, this);


Wups! Thanks. 😌

hsutter · 2023-12-15T22:36:50Z

source/parse.h

@@ -3383,6 +3383,16 @@ struct declaration_node
        return false;
    }

+    auto get_function_parameters()
+        -> std::span<std::unique_ptr<parameter_declaration_node>>


I usually don't expose the unique_ptr. Also I usually as const.

Perhaps -> std::vector<parameter_declaration_node const*>?

hsutter · 2023-12-15T22:49:05Z

source/reflect.h2


    is_binary_comparison_function: (this) -> bool = n*.is_binary_comparison_function();

    default_to_virtual           : (inout this) = _ = n*.make_function_virtual();

    make_virtual                 : (inout this) -> bool = n*.make_function_virtual();
+
+    add_initializer: (move this, source: std::string_view)


Is move this intentional?

Yes, it was.
It's can be considered a manifestation of Value category is not lifetime.
Since my implementation did remove the member,
this was necessary as an indication of safety.

Oh right, and I even briefly thought about that move-from-this-member original characteristic, then forgot it when writing the comment. OK, anyway it's good now, thanks. 👍

hsutter · 2023-12-15T23:13:52Z

source/reflect.h2

+        p.add_member(prefix + source);
+        _ = p;
+        mark_for_removal_from_enclosing_type();
+    }


Two things:

I wouldn't use duplicate-and-remove here, because here it's easy to graft a new node into the existing parse tree.

That also avoids the need to visualize-and-reparse existing code that's already been parsed, which so far I've avoided doing. (I hope visualizing round-trips, but I don't thoroughly test for that yet... I have a test case to exercise it, but it's not exhaustive and I only occasionally manually try to compile the visualization test case's output to make sure it compiles and I don't compare the before/after trees.)

I would just make add_initializer follow the model of add_member, which is this:

add_member: (inout this, source: std::string_view) = { decl := parse_statement(source); if !decl || !n*.add_type_member(decl) { error( std::string("error attempting to add member:\n") + source ); } }

So add_initializer would similarly be:

add_initializer: (inout this, source: std::string_view) = { stmt := parse_statement(source); // only parsing `source`, not the whole thing if !stmt || !n*.add_function_initializer(stmt) { // need to add this function error( std::string("error attempting to add initializer:\n") + source ); } }

I'll push a commit to this PR that makes these changes, and provides the new add_function_initializer function besides the existing add_type_member function in parse.h.

Alternatively, using preconditions it could be:

add_initializer: (inout this, source: std::string_view) pre(!has_initializer(), "cannot add an initializer to a function that already has one") pre(parent_is_type() , "cannot add an initializer to a function that isn't in a type scope") = { stmt := parse_statement(source); // only parsing `source`, not the whole thing if !stmt || !n*.add_function_initializer(stmt) { // need to add this function error( std::string("error attempting to add initializer:\n") + source ); } }

I'm a fan of preconditions, but in this case the parse.h add_type_member function (and so similarly the new add_function_initializer function) also acts as a precondition test because it tests those conditions and returns bool. Note add_type_member pretty much has to check the preconditions internally to navigate the tree correctly, and since it returns false if it failed we just check that and emit a single diagnostic, which would be hidden by preconditions.

I did try this precondition version, and found that another drawback was that by default it aborted the compiler which was inelegant. So maybe it's worth using preconditions, but with a <compiler> contract_group and installing a log-and-continue error handler, or using t.require instead which exists for this. I'll think about it more but maybe not do it right now.

I think this has convinced me that both add_member and the newadd_intializer should be using require more:

add_member: (inout this, source: std::string_view) = { decl := parse_statement(source); require( decl as bool, "the provided source string is not a valid statement"); require( decl*.is_declaration(), "cannot add a member that is not a declaration"); require( n*.add_type_member(decl), std::string("error attempting to add member:\n") + source ); } add_initializer: (inout this, source: std::string_view) = { require( !has_initializer(), "cannot add an initializer to a function that already has one"); require( parent_is_type(), "cannot add an initializer to a function that isn't in a type scope"); stmt := parse_statement(source); require( stmt as bool, std::string("cannot add an initializer that is not a valid statement: ") + source); require (n*.add_function_initializer(stmt), std::string("error attempting to add initializer:\n") + source); }

This improves the error message. For now I'll update the PR to go that direction. In the future we can see about integrating require with preconditions. Interesting exercise, thanks!

Hmm, weird how some of the review comments got interleaved with the parallel commit. These comments were intended to go on the previous commit. Ah well!

Thank you for the insightful comments.

One thing these versions don't have is the ability to add a constexpr initializer
(some relevant discussions include #387 (comment) and #761).

For using contracts, #751 will be necessary.

hsutter · 2023-12-15T23:54:49Z

source/reflect.h2

+        if !d*.has_initializer()
+           && !d*.is_virtual_function()
+           && !d*.is_defaultable_function()
+        {


I still keep noticing how nice (IMO) for-do-if looks to read vertically.

JohelEGP · 2023-12-16T01:14:01Z

I'm hitting a segfault due to #830.

Now that members who have an initializer added aren't added at the end of the type scope,
the this members I generate come after the members with generated initializers.

I already had this problem for types whose member functions weren't all generated.
So I just manually added the this members that would have been generated.

After that (and adjusting the call to add_initializer), everything works as expected for me.

(Previously #789 (reply in thread).)

JohelEGP · 2023-12-16T02:30:17Z

source/reflect.h2

        decl := parse_statement(source);
-        if !decl || !n*.add_type_member(decl) {
-            error( std::string("error attempting to add member:\n") + source );
-        }
+        require( decl as bool, 
+                 "the provided source string is not a valid statement");
+        require( decl*.is_declaration(), 
+                 "cannot add a member that is not a declaration");


Another issue.
I just merged #887, which includes commit 5541a75, into my working branch.
Apparently, that made parse_statement return a nullptr value.
After the first require above, this one dereferences a null decl.

JohelEGP · 2023-12-16T02:41:32Z

source/reflect.h2

+        require( !has_initializer(), 
+                 "cannot add an initializer to a function that already has one");
+        require( parent_is_type(),
+                 "cannot add an initializer to a function that isn't in a type scope");
+
+        stmt := parse_statement(source);


Not using contracts also means that the parse_statement will be executed regardless of the preconditions.
Contracts seems like the better tool here.

It would still be nice to integrate the custom error handling of the reflection API with contracts.

I have similar issues in my code.
I'm using it as I would a contract without continuation.

I may have mentioned this somewhere else,
but I also expect the string argument to be a lazy parameter.
I can't remember what I wrote,
but I expected the condition to guard an invalid use in the interpolated string.

I remember now.
It was something like

require(v.empty() || …, "(v.front())$");

which the expectation that the string remains unevaluated when v is empty.

Oh right, I should be at least using if...error instead of bunding them in require. Will fix...

It would still be nice to integrate the custom error handling of the reflection API with contracts.

Hold that thought... I'm trying it now and discovering some cool things seem to already work.

Spoiler: TIL that pre<this>(expr, msg) already invokes (*this).expects(expr, msg);. I discovered that when I tried to add support for <this> as a special-cased name only to discover it already worked. And there doesn't even have to be a contract_group object around as this behaves as its own custom contract group... +1 for duck typing and generic code.

However, this is making me realize there's a reason not to turn all those requires checks into preconditions or assertions: Contracts shouldn't be used for control flow. Today, the way to turn off contract checks is to install a do-nothing handler, but if in the future there's a way to turn off contract checks, it would disable not only the checks but also the compiler diagnostics that would be emitted.

And: - Add proper early returns for failed null checks - Disable the `contract_group` default constructor, since we aren't checking the handler before trying to invoke it.

hsutter · 2023-12-16T04:49:48Z

OK, I'm just pushing a commit that restores those two preconditions to try that out with diagnose-and-continue semantics, but keeps the .require versions as comments.

I'm not sure I addressed all your comments above. Please take a look -- how is this now?

For the preconditions: Did you prefer diagnose-and-quit semantics?

JohelEGP

For the preconditions: Did you prefer diagnose-and-quit semantics?

That's my preference, yes.

JohelEGP · 2023-12-16T05:10:34Z

source/reflect.h2

-        if !decl || !n*.add_type_member(decl) {
-            error( std::string("error attempting to add member:\n") + source );
+        if !(decl as bool) {
+            error("the provided source string is not a valid statement");


Suggested change

error("the provided source string is not a valid statement");

error("the provided source string is not a valid statement:\n(source)$" );

This one used to include the source fragment.
This is where I'm getting the error, but I can't as easily see what's wrong:

algorithms.test.cpp2: error: unexpected text ' lgorithms.test.cpp2: error: unexpected text ' lgorithms.test.cpp2: error: invalid else branch body (at '{') algorithms.test.cpp2: error: ill-formed initializer (at '{') algorithms.test.cpp2(37,1): error: while applying @array - the provided source string is not a valid statement

With the suggestion above (add_initializer already does it right):

algorithms.test.cpp2: error: unexpected text ' lgorithms.test.cpp2: error: unexpected text ' lgorithms.test.cpp2: error: invalid else branch body (at '{') algorithms.test.cpp2: error: ill-formed initializer (at '{') algorithms.test.cpp2(37,1): error: while applying @array - the provided source string is not a valid statement: operator(): <I, S> (this, copy first: I, copy last: S) -> std::iter_difference_t<I> pre<Bounds>(0 <= n) requires std::sentinel_for<S, I> && std::totally_ordered_with<decltype((n)), std::iter_difference_t<I>> = { if constexpr std::sized_sentinel_for<S, I> { if constexpr std::same_as<S, I> { last = std::ranges::next(first, n, last); } else { return operator()(first, std::ranges::next(first, n, last)); } } take := n; if constexpr std::sized_sentinel_for<S, I> { return last - first; } else { return take - std::ranges::advance(first, take, last);error: expected a single string_ = first; } }

I can immediately see what's wrong in color:

By the way, to print in colors, I use https://stackoverflow.com/questions/5947742/how-to-change-the-output-color-of-echo-in-linux
It's very useful, since I'm programmatically generating the source code.

warn: (forward s) = _ = std::cerr << "\033[1;35mwarning:\033[0m (s)$\n"; error: (forward s) -> std::string = "\033[1;31m(s)$\033[0m";

single_string: type == split_strings<"\033[1;31merror: expected a single string\033[0m">;

By the way, to print in colors, I use https://stackoverflow.com/questions/5947742/how-to-change-the-output-color-of-echo-in-linux
It's very useful, since I'm programmatically generating the source code.

Thanks. Are you suggesting that cppfront have something like this, possibly under a new -fcolor-diagnostics or -fdiagnostics-color switch?

Sorry, I missed your reply.
No, that wasn't my intention.
But I might come back later for that.

JohelEGP · 2023-12-16T05:10:51Z

source/reflect.h2

        }
+        require( n*.add_type_member(decl),
+                 std::string("unexpected error while attempting to add member:\n") + source );


Suggested change

std::string("unexpected error while attempting to add member:\n") + source );

"unexpected error while attempting to add member:\n(source)$") );

JohelEGP · 2023-12-16T05:13:37Z

source/reflect.h2

+
+        stmt := parse_statement(source);
+        if !(stmt as bool) {
+            error( std::string("cannot add an initializer that is not a valid statement: ") + source );


Suggested change

error( std::string("cannot add an initializer that is not a valid statement: ") + source );

error( "cannot add an initializer that is not a valid statement:\n(source)$" );

JohelEGP · 2023-12-16T05:13:54Z

source/reflect.h2

+            return;
+        }
+        require (n*.add_function_initializer(stmt),
+                 std::string("unexpected error while attempting to add initializer:\n") + source);


Suggested change

std::string("unexpected error while attempting to add initializer:\n") + source);

"unexpected error while attempting to add initializer:\n(source)$" );

JohelEGP · 2023-12-16T05:18:23Z

Everything compiles and runs fine after I fixed my bug.

…on violation And restore `source` string to error output, and make it just come out routinely as soon as a parse error is detected

hsutter · 2023-12-16T20:52:18Z

For the preconditions: Did you prefer diagnose-and-quit semantics?

That's my preference, yes.

OK, I've now done that.

I think I learned something from this, so I'll take a minute to write it down...

I found it jarring that the default "quit" semantics for metafunction precondition violations was that cppfront itself aborted. That seemed... ungraceful when we don't do that for other ill-formed programs (e.g., grammar violations). A user-provided metafunction is part of their program that we're compiling.

This raised a very interesting principled question for me, because it didn't quite fit the principles I've followed, which are:

Run-time errors (e.g., ill-formed user input) should be reported using exceptions or error codes or equivalents, handled by the calling code, and reported to the user (e.g., who provided the bad input, not to the programmer since it's not a logic bug).
Programming bugs (e.g., precondition failures) should be reported using contract/assertion handlers, cannot be handled by the calling code (so the default should be to abort), and reported to the programmer (who wrote the bad code and needs to go fix their code, not to the user who can't do anything about it).

Before this, I hadn't personally encountered (or grokked) examples of overlap between the two. That's because I only considered the case of programming bugs of the form "the whole program calls a library and violates a library precondition." In that case, the programming bug is by the owner of the whole program, so it's natural to want to abort and debug the program.

But a buggy metafunction inverts that -- it is of the form "a plugin/extension extends the whole program and violates a whole program precondition." Now the core program can dynamically be given run-time input (therefore any error is a run-time error) that is actually more user-provided code that could invoke our plugin/extension API (therefore any precondition violation is also a programming bug). Putting it qualitatively, I think the issue in that situation, and for that programmatic run-time input only, can be described as that the user is also the programmer, and the program is also the runtime input. So in a compiler we want to report a metafunction precondition violation as gracefully as any ordinary grammatical or other bug we find in any other part of the user's program.

And, generalizing, that arises in any plugin architecture, such as a browser that can load extensions (if the extension makes a call to the API provided for plugins and violates a precondition).

I have to admit that I think I now have a situation where I want a precondition violation to throw an exception -- but only for run-time code (plugins, metafunction preconditions) that call the program's extension API.

I suspect that the people in WG 21 who've been writing papers about examples of where contract violation handlers should be able to throw might now point me to just such examples in their papers that I haven't grokked until I walked into the door myself just now. I still seems to me that the set of use cases of the form "plugins/extensions, where the provider of the run-time code is also a programmer" is small... but it's nonzero.

So in the commit I just pushed, I find myself... 🥁drum roll🥁... throwing from a contraction violation handler. I expect to get a little gentle 🔥 for that, which I'll defend by pointing out that it's a very specific and narrow use case... but here we go, let the games begin! and as the ineffable Effie put it:

hsutter · 2023-12-16T20:56:51Z

Does this now look ready to merge to you, @JohelEGP ?

JohelEGP · 2023-12-16T21:03:20Z

source/reflect.h2

+                generated_tokens*
+              );
+        if !ret {
+            error( "parse failed - the source string is not a valid statement:\n(source)$");


The source string view is modified.
You need to add an original_source := source; at the beginning.
This is the diagnostic for my previous bug:

algorithms.test.cpp2: error: unexpected text ' lgorithms.test.cpp2: error: unexpected text ' lgorithms.test.cpp2: error: invalid else branch body (at '{') algorithms.test.cpp2: error: ill-formed initializer (at '{') algorithms.test.cpp2(37,1): error: while applying @array - parse failed - the source string is not a valid statement: } algorithms.test.cpp2(37,1): error: while applying @array - the provided source string is not a valid statement

Note how the source string is just }.

JohelEGP · 2023-12-16T22:44:40Z

Does this now look ready to merge to you, @JohelEGP ?

Yes.
Thank you for your inputs and for sharing the various very interesting revelations along the way.

Signed-off-by: Herb Sutter <herb.sutter@gmail.com>

hsutter · 2023-12-16T23:49:39Z

There were reflect.h merge conflicts that I manually resolved (and I can regenerate it post-merge to be sure). But the process made me notice that this branch doesn't have commits after Dec 11, starting around the postfix inc/dec generation. Just triple-checking: Those should be preserved and merge fine if I merge this PR in its current state, correct? i.e., this PR doesn't need to be rebased?

JohelEGP · 2023-12-17T00:16:33Z

Yeah, looks like regenerating just changes line numbers.
It should be safe to merge.

This comment was marked as resolved.

Sign in to view

JohelEGP force-pushed the reflect_function_parameters_and_initializer branch from 57217d0 to 4de962b Compare November 21, 2023 01:30

This comment was marked as off-topic.

Sign in to view

JohelEGP added 5 commits December 11, 2023 12:49

feat(reflect): add function_declaration::get_parameters

cf88bd1

feat(reflect): add function_declaration::add_initializer

c499d3b

fix(reflect): actually return the parent

a51e2d1

feat(reflect): add declaration::get_arguments

cb148bc

feat(reflect): add get_member_functions_needing_initializer

66e83d2

JohelEGP force-pushed the reflect_function_parameters_and_initializer branch from 4de962b to 66e83d2 Compare December 11, 2023 16:50

Pre-merge review pass

8676473

Johel, can you give this a try in your test code and make sure your test code still works as expected? I had to create a little test to exercise it, since the new functions aren't used in this PR.

hsutter reviewed Dec 15, 2023

View reviewed changes

JohelEGP commented Dec 16, 2023

View reviewed changes

Restore preconditions for add_initializer

d72a055

And: - Add proper early returns for failed null checks - Disable the `contract_group` default constructor, since we aren't checking the handler before trying to invoke it.

JohelEGP commented Dec 16, 2023

View reviewed changes

Second review: Add graceful termination for a metafunction preconditi…

6c2b434

…on violation And restore `source` string to error output, and make it just come out routinely as soon as a parse error is detected

JohelEGP commented Dec 16, 2023

View reviewed changes

Report original source string on parse errors

3813b46

Merge branch 'main' into reflect_function_parameters_and_initializer

08481ff

Signed-off-by: Herb Sutter <herb.sutter@gmail.com>

regenerate reflect.h

cb865b4

hsutter merged commit 580b83a into hsutter:main Dec 17, 2023

JohelEGP deleted the reflect_function_parameters_and_initializer branch December 17, 2023 01:12

JohelEGP restored the reflect_function_parameters_and_initializer branch December 17, 2023 04:02

JohelEGP mentioned this pull request Dec 19, 2023

[BUG] Generalize _string-literal_ of contract like C++26's static_assert #751

Closed

JohelEGP deleted the reflect_function_parameters_and_initializer branch December 29, 2023 23:06

JohelEGP mentioned this pull request Dec 29, 2023

feat: evaluate program-defined metafunctions (based on #797) #907

Closed

JohelEGP mentioned this pull request Jan 9, 2024

[BUG] Interpolation lowers unparenthesized #828

Closed

	error("the provided source string is not a valid statement");
	error("the provided source string is not a valid statement:\n(source)$" );

	std::string("unexpected error while attempting to add member:\n") + source );
	"unexpected error while attempting to add member:\n(source)$") );

	error( std::string("cannot add an initializer that is not a valid statement: ") + source );
	error( "cannot add an initializer that is not a valid statement:\n(source)$" );

feat(reflect): add function_declaration API to set initializer and inspect parameters #831

feat(reflect): add function_declaration API to set initializer and inspect parameters #831

Conversation

JohelEGP commented Nov 15, 2023 • edited Loading

This comment was marked as resolved.

JohelEGP commented Nov 23, 2023

JohelEGP commented Nov 26, 2023

This comment was marked as off-topic.

JohelEGP commented Dec 1, 2023

hsutter 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

Choose a reason for hiding this comment

JohelEGP commented Dec 16, 2023 • 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

JohelEGP Dec 16, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hsutter Dec 16, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hsutter commented Dec 16, 2023

JohelEGP 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

JohelEGP commented Dec 16, 2023

hsutter commented Dec 16, 2023 • edited Loading

hsutter commented Dec 16, 2023

Choose a reason for hiding this comment

JohelEGP commented Dec 16, 2023

hsutter commented Dec 16, 2023

JohelEGP commented Dec 17, 2023

feat(reflect): add `function_declaration` API to set initializer and inspect parameters #831

feat(reflect): add `function_declaration` API to set initializer and inspect parameters #831

JohelEGP commented Nov 15, 2023 •

edited

Loading

JohelEGP commented Dec 16, 2023 •

edited

Loading

JohelEGP Dec 16, 2023 •

edited

Loading

hsutter Dec 16, 2023 •

edited

Loading

hsutter commented Dec 16, 2023 •

edited

Loading