[FRAME Core] Adds ability to split a pallet across multiple files #13950

gupnik · 2023-04-19T03:24:08Z

This PR adds the ability to split components of a pallet.

A section can be exported as follows:

#[pallet_section]
mod storages {
	#[pallet::storage]
	pub type MyStorageMap<T: Config> = StorageMap<_, _, u32, u64>;
}

and then, imported in the main pallet section as follows:

#[import_section(storages)]
#[frame_support::pallet(dev_mode)]
pub mod pallet {
     //....
}

This PR also adds pallet-example-split under frame/examples to demonstrate this functionality.

…pallet-split

xlc · 2023-04-19T04:23:53Z

do we really need this?

sam0x17 · 2023-04-19T05:06:44Z

do we really need this?

When I did my substrate seminar last fall this was the main thing people brought up in the Q&A as a desired feature, with all sorts of reasons ranging from breaking up very large pallets into smaller more digestible files to allowing for code sharing of identical sections that could be shared between multiple pallets. The outer macro pattern our pallets rely on is extremely powerful, but the price we pay is everything has to be in one module in one file. This removes that restriction without sacrificing any of the power or capabilities the outer macro pattern brings us in FRAME. There is a reason Rust normally lets you break things up into multiple modules in multiple files. Now we have a way to still do that while nevertheless using the outer macro pattern.

xlc · 2023-04-19T05:21:45Z

You are not talking with the right set of developers for feedbacks. Have you asked senior substrate developers? like the core devs in Parity and parachains, instead of students?

We have a lot of complex pallets in Substrate, staking for example is one, have you asked the core dev for pallet-staking to see if this is helpful?

At least for all the pallets I maintain, I don't need this. The normal ways of abstracting the logics is enough.

Maybe you are right but you need to show an example of how this is beneficial and cannot be done otherwise. Chances are there are easier way to break pallets into smaller files and code reusing without macro magic.

Again, this is another thing I don't like how some approach a problem. You need to show there is an indeed a problem, propose a solution, highlight how it fixes the problem, and then code it.

How is moving events to its own file enable code reuse? How are you going to reuse those events?

Maybe there is a set of storages could be reused by different pallets? But then how is your solution make such use case possible? You should write some pseudocode to see if it works or not. Maybe you already have those? Please show.

gupnik · 2023-04-19T05:39:19Z

You are not talking with the right set of developers for feedbacks. Have you asked senior substrate developers? like the core devs in Parity and parachains, instead of students?

We have a lot of complex pallets in Substrate, staking for example is one, have you asked the core dev for pallet-staking to see if this is helpful?

At least for all the pallets I maintain, I don't need this. The normal ways of abstracting the logics is enough.

As you would imagine, the current mechanism stays and you can continue to use that if you don't find this useful.

Maybe you are right but you need to show an example of how this is beneficial and cannot be done otherwise. Chances are there are easier way to break pallets into smaller files and code reusing without macro magic.

Again, this is another thing I don't like how some approach a problem. You need to show there is an indeed a problem, propose a solution, highlight how it fixes the problem, and then code it.

How is moving events to its own file enable code reuse? How are you going to reuse those events?

You are absolutely right here. That's why I mentioned that this is a POC and the PR is a draft. Once the approach makes sense, I will start to build examples where this would make sense.

The intent of the splitting here was to show that it is possible now to create sections that encompass a few pieces instead of a single monolithic and not that the events should be in its own file (or for any other section for that matter).

sam0x17

This is a good proof of concept. I'd love to see:

an application of this concept to a large pallet that needs to be split up badly, so we can provide a more motivating example
a legitimate scenario where this can enable code sharing, if such a scenario actually exists (think: are there places where several pallets have the same boilerplate, and could that boilerplate become a pallet section that lives in a single location and is used in a number of pallets?)

sam0x17 · 2023-04-19T05:27:40Z

bin/node-template/pallets/template/src/lib.rs

+#[import_section(events)]
+#[import_section(errors)]
+#[import_section(calls)]
+#[import_section(storages)]


now that I'm seeing several imported at once, would be cool to have an #[import_sections(section1, section2, section3)] macro that expands to the above for scenarios like this. Doesn't have to be addressed in the initial PR but making a note of it

Yes and a comment please about what this is doing.

frame/support/procedural/src/lib.rs

sam0x17 · 2023-04-19T05:49:59Z

Have you asked senior substrate developers?

This was discussed a good bit in the parity forum a while ago where @bkchr, Shawn, and @aaronbassett were in favor of it. People coming out of the academy consistently ask for this as well, which I think is an even better indicator.

Rather than look at this from a perspective of "why should we add this?" though, consider this: in Rust, it is normal to be able to split up a module into multiple smaller modules. This is just how Rust works, and it enables better readability and a number of positive things commonly associated with modularity that I'm sure we could all agree on such as not having to scroll through a 1000-line file.

Pallets are modules, however since FRAME parses pallets using the outer macro pattern, we are stuck with this artificial, non-rusty limitation that the pallet module cannot be split into multiple external files like normal Rust modules can, and explaining this fact to newcomers is a laborious task.

The burden of proof should then be on "why shouldn't we remove this non-Rusty artificial limitation if we have the means to do so?"

xlc · 2023-04-19T05:56:19Z

Well, you are not wrong, but again, there are ways to break pallets into multiple files and that worked well so far (at least for myself). But yeah maybe those are bad workaround that deserve a better solution. A real life example will help me to change my mind.

My main point is, why wasting so much time getting code actually compile when you can just write something and say image if this code compiles? This is just not the correct way to develop such solution.

I wrote a lot of resuable code for pallets, most of them live in ORML. You might be surprised how much can be done without macro magic.

xlc · 2023-04-19T06:03:01Z

Also yes I can simply not use this features if I don't want to use. I guess I am just getting a bit grumpy when I see people wasting time building something isn't important than fixing critical issues I raised years ago. I still have 46 open issues and I don't think any of them have been take care of https://github.com/paritytech/substrate/issues/created_by/xlc

kianenigma · 2023-04-20T08:50:21Z

You are not talking with the right set of developers for feedbacks. Have you asked senior substrate developers? like the core devs in Parity and parachains, instead of students?

The desire to break pallets into smaller parts stems not from PBA or students, but rather from Parity engineers, and dates at least to 2021, with the introduction of the new pallet macro that forced everything into one file.

I agree with the rest of your comments @xlc and I see that @sam0x17 and @gupnik are also onboard, we need to now find use-cases for this.

I broadly think this can help us with 3 classes of issues:

Breaking big files into smaller ones. Developers generally like to do this for various reasons and I think that's a totally fair ask. My only worry is that if this breaks RA support even further, I would personally be hesitant to use it.

If you want to try one, pallet-staking is already trying to break itself into smaller parts and could use a new approach.

Also, you can just have a new pallet-example-splitted that has each pallet part in a new file, and an aggregating lib.rs that is only bringing them under one umbrella.

As noted, I think the real killer feature is not splitting, but reusing. Right now, we have a paradigm where if a pallet wants to use a set of features from another code component that needs its own storage/events/calls, it has to be two pallets.

I think this is perfectly fine for most use cases. Moreover, it forces us to link the two pallets together via a trait, which makes you think about the interface between the two components.

The downside is having too much boilerplate, and some limitations like the fact that someday, we simply will run out of pallets to add to the outer RuntimeCall enum.

One example that you can look into is pallet-bags-list and how it is being used in pallet-staking. It is basically a pallet that only provides the functionality of a linked-list to some other pallet. I can't say I was particularly annoyed by implementing and using it as a whole new pallet, but I am certainly curious to see how it could have been done otherwise.

Perhaps a subset of the latter, I another feature that I would personally like to see is an easier means of "privatizing" a group of storage items, and putting them behind a firewall that makes sure they are only mutated in a sensible way. A few examples of this that come to mind:

bags-list has some storage items that must never be mutated directly
A similar one in the offences pallet.
This example in election-provider-multi-phase. This is a good example for use case 1 as well. All of the logic for the "signed phase" in this pallet is in signed.rs, but the storage and calls are not stuck in the main.rs.

All in all, I think this is a very promising avenue. I hear the call for more validation, and it is fair, but I think enforcing it at an early stage of an experimental work like this will hinder innovation. Sometimes you don't know what you are missing unless if some tool is there to fix it for you.

xlc · 2023-04-20T10:06:51Z

It sounds like we don't really want to break pallet into files. This is not the goal.

For (1), I don't yet see a big pallet that is build in such way will be benefit from this. We can already move most of the logics to other files. I definitely prefer to have all the definitions in a single file.

For (2) and (3), they sound like the same thing to me and split pallet across multiple files is not the right solution. Let's use common programming design patterns when approaching such a common issue.

Let's use OO here. A class (pallet) is made of fields (storages) and methods (calls). The calls can return errors and emit events. What happen if we have a god class that's too big to maintain? We break it down into multiple smaller class. We don't break it down into multiple files and write fields in one file and method in another file and somehow allow the fields to be reuseable??? This simply makes zero sense.

So the right solution is being able to define a component that's made of storages, calls and supporting types (events, errors and related types) and then build a pallet from those components.

How about inheritance. Allow a pallet to inherent everything from another pallet. Then we can build a storage only pallet and that's exactly what you want here. It could even support multiple inheritance (and make your life harder).

We can use composition. Allow a pallet to embed child pallet. The child pallet's storage will be placed under parent pallet's storege prefix. The calls events errors can be aggregated and flattened.

aaronbassett · 2023-04-20T12:59:48Z

You are not talking with the right set of developers for feedbacks. Have you asked senior substrate developers? like the core devs in Parity and parachains, instead of students?

If you do not take students' opinions into account then where do you think the next generation of senior substrate developers will come from?

ggwpez

Awesome!

ggwpez · 2023-04-20T14:41:39Z

bin/node-template/pallets/template/src/calls.rs

+#[export_section]
+mod calls {


Could you please add a comment that it is not possible to add that attribute on a file level like #![export_section].
I think that applies to all attribute macros.

yes this comment would be a good idea.

And yes, custom inner attributes are a nightly-only feature atm

ggwpez · 2023-04-20T14:42:43Z

bin/node-template/pallets/template/src/calls.rs

+				// Return an error if the value has not been set.
+				None => return Err(Error::<T>::NoneValue.into()),
+				Some(old) => {
+					// Increment the value read from storage; will error in the event of overflow.


I think we can dumb these example down by a lot. Just accepting an should_error bool is probably enough.
Keeping it condensed is IMHO important to not loose devs that want to understand it.

ggwpez · 2023-04-20T14:43:00Z

bin/node-template/pallets/template/src/errors.rs

+
+#[export_section]
+mod errors {
+	// Errors inform users that something went wrong.


Suggested change

// Errors inform users that something went wrong.

/// Errors inform users that something went wrong.

ggwpez · 2023-04-20T14:43:56Z

bin/node-template/pallets/template/src/lib.rs

+#[import_section(events)]
+#[import_section(errors)]
+#[import_section(calls)]
+#[import_section(storages)]


Yes and a comment please about what this is doing.

ggwpez · 2023-04-20T14:49:52Z

bin/node-template/pallets/template/src/lib.rs

+mod storages;
+mod events;
+mod errors;
+mod calls;


These are modules, but i am not sure if anyone actually wants to use them as normal Rust modules?
Maybe we can find a more FRAME syntax which just wraps these and the import_sections below. Although i would definitely keep this syntax working with the manual mods and manual import_sections.

For example:

#[pallet_sections( mod storages; mod events; mod errors; mod calls; )]

(not quite happy with the syntax, but you see what i mean)

sam0x17 · 2023-04-20T16:00:15Z

Let's use OO here. A class (pallet) is made of fields (storages) and methods (calls). The calls can return errors and emit events. What happen if we have a god class that's too big to maintain? We break it down into multiple smaller class. We don't break it down into multiple files and write fields in one file and method in another file and somehow allow the fields to be reuseable??? This simply makes zero sense.

I agree with this sentiment, but we are already stuck with how FRAME was designed around the outer macro pattern encompasing one giant pallet module. We could completely re-design FRAME to be more "proper" from an OO perspective for example, but with FRAME the way it is, where a pallet is a giant module, we can't stop people from expecting to be able to use normal Rust mechanics like use some::path to bring in other modules containing #[pallet::whatever] stuff. Not being able to do this violates principle of least surprise for people used to how Rust modules are supposed to work, and this PR provides a completely optional path for people who want to organize their code in a way the existing FRAME syntax already strongly suggests you can.

xlc · 2023-04-20T21:23:19Z

we can't stop people from expecting to be able to use normal Rust mechanics like use some::path to bring in other modules containing #[pallet::whatever] stuff. Not being able to do this violates principle of least surprise for people used to how Rust modules are supposed to work

Maybe it is just me but I definitely will be surprised if import form other modules actually work. I just don't agree with you on this. But anyway, lets skip this point.

Let's get back to code reuse. You have to give me an example on how this can achieve code reuse. Also the goal is to achieve code reuse, not split files so you NEED to explore alternative solutions and syntax.

xlc · 2023-04-20T21:26:31Z

You are not talking with the right set of developers for feedbacks. Have you asked senior substrate developers? like the core devs in Parity and parachains, instead of students?

If you do not take students' opinions into account then where do you think the next generation of senior substrate developers will come from?

NO. You may find Rust is hard to learn/use and have some idea on how to improve Rust syntax but I would not trust your suggestions on how to improve Rust. Your suggestion maybe great but it MUST be reviewed by multiple Rust experts first and go through a lot of discussions before any implementation. Same thing apply here.

I did not see ANY open discussion about this and that makes me sad. Yeah you may have a lot of internal discussion but they are non existent to me if I can't access them. Can't you just write an issue first before coding?

sam0x17

looking good just want to see the proper path resolution + kian's stuff and we should be good

frame/examples/split/Cargo.toml

frame/support/test/tests/split_ui/import_without_pallet.stderr

frame/support/test/tests/split_ui/section_not_imported.stderr

frame/support/procedural/src/lib.rs

…pallet-split

gupnik · 2023-06-21T13:19:55Z

bot fmt

command-bot · 2023-06-21T13:20:01Z

@gupnik https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/3042451 was started for your command "$PIPELINE_SCRIPTS_DIR/commands/fmt/fmt.sh". Check out https://gitlab.parity.io/parity/mirrors/substrate/-/pipelines?page=1&scope=all&username=group_605_bot to know what else is being executed currently.

Comment bot cancel 2-78b7fd27-cdae-4abb-99db-4db4841fd13f to cancel this command or bot cancel to cancel all commands in this pull request.

command-bot · 2023-06-21T13:22:06Z

@gupnik Command "$PIPELINE_SCRIPTS_DIR/commands/fmt/fmt.sh" has finished. Result: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/3042451 has finished. If any artifacts were generated, you can download them from https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/3042451/artifacts/download.

gupnik · 2023-06-21T13:43:45Z

bot fmt

command-bot · 2023-06-21T13:43:49Z

@gupnik https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/3043015 was started for your command "$PIPELINE_SCRIPTS_DIR/commands/fmt/fmt.sh". Check out https://gitlab.parity.io/parity/mirrors/substrate/-/pipelines?page=1&scope=all&username=group_605_bot to know what else is being executed currently.

Comment bot cancel 3-2d6aaf97-a5e0-4c6f-8d51-510c2c2aceb4 to cancel this command or bot cancel to cancel all commands in this pull request.

command-bot · 2023-06-21T13:45:37Z

@gupnik Command "$PIPELINE_SCRIPTS_DIR/commands/fmt/fmt.sh" has finished. Result: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/3043015 has finished. If any artifacts were generated, you can download them from https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/3043015/artifacts/download.

gupnik · 2023-06-21T13:51:29Z

@kianenigma @sam0x17 Could you take a look now?

sam0x17

looks good to me!

had one missing newline other than that should be good to merge

frame/support/test/tests/split_ui/no_section_found.rs

Co-authored-by: Sam Johnson <sam@durosoft.com>

frame/examples/split/src/lib.rs

kianenigma

A few small suggestions to make the scope of the example even narrower, everything else looks good.

… into gupnik/pallet-split

…pallet-split

gupnik · 2023-06-27T12:11:55Z

bot merge

…ritytech#13950) * Initial setup * Updates macro_magic version and refactors accordingly * Removes unwrap from macro * Splits into multiple sections * Uses call_site to fix macro hygiene issue * Initial setup * Removes unnecessary changes * Moves template palet back * Updates cargo.lock * Moves BagsList inside mod * Comments access to internal functions for now * Updates tests * Uncomments code * Fixes test * Moves bags-list to separate crate * Initial setup * Removes bags-list changes * Fix structure * Minor update * Addresses review comment * Adds a couple of UI tests. More to be added * Adds err files * Adds test for no pallet * Adds doc * Updates versions * Adds benchmarking * Updates doc link * ".git/.scripts/commands/fmt/fmt.sh" * Minor update * Adds missing changes * ".git/.scripts/commands/fmt/fmt.sh" * Update frame/support/procedural/src/lib.rs Co-authored-by: Sam Johnson <sam@durosoft.com> * Addresses review comments * Addresses review comments * ".git/.scripts/commands/fmt/fmt.sh" * Update frame/support/procedural/src/lib.rs Co-authored-by: Sam Johnson <sam@durosoft.com> * Update frame/support/procedural/src/lib.rs Co-authored-by: Sam Johnson <sam@durosoft.com> * Update frame/support/procedural/src/lib.rs Co-authored-by: Sam Johnson <sam@durosoft.com> * Adds UI test for disambiguation * ".git/.scripts/commands/fmt/fmt.sh" * Makes clippy happy * ".git/.scripts/commands/fmt/fmt.sh" * Fixes frame support test * Fixes frame support test * Split items other than storage * Updates versions * Fixes some review comments * Addresses review comments * ".git/.scripts/commands/fmt/fmt.sh" * Updates docs * Adds experimental disclaimer * ".git/.scripts/commands/fmt/fmt.sh" * Update frame/support/test/tests/split_ui/no_section_found.rs Co-authored-by: Sam Johnson <sam@durosoft.com> * Addresses review comments * Fixes test --------- Co-authored-by: command-bot <> Co-authored-by: command-bot <ci@gitlab.parity.io> Co-authored-by: Sam Johnson <sam@durosoft.com>

gupnik added 5 commits April 17, 2023 10:42

Initial setup

01513b9

Updates macro_magic version and refactors accordingly

063ed10

Removes unwrap from macro

c1a1342

Splits into multiple sections

6fe645b

Merge branch 'master' of github.com:paritytech/substrate into gupnik/…

b582bd0

…pallet-split

gupnik requested review from sam0x17, kianenigma and ggwpez April 19, 2023 03:24

Uses call_site to fix macro hygiene issue

e403600

sam0x17 reviewed Apr 19, 2023

View reviewed changes

ggwpez mentioned this pull request Aug 24, 2023

Vision: Pallet syntax improvement paritytech/polkadot-sdk#187

Open

7 tasks

ggwpez reviewed Apr 20, 2023

View reviewed changes

sam0x17 reviewed Jun 19, 2023

View reviewed changes

gupnik added 3 commits June 21, 2023 11:45

Merge branch 'master' of github.com:paritytech/substrate into gupnik/…

e52690a

…pallet-split

Fixes some review comments

0c444ce

Addresses review comments

5219370

".git/.scripts/commands/fmt/fmt.sh"

72d4204

gupnik added 2 commits June 21, 2023 19:09

Updates docs

17b9cdb

Adds experimental disclaimer

125b5dc

".git/.scripts/commands/fmt/fmt.sh"

3fa8d5c

sam0x17 approved these changes Jun 21, 2023

View reviewed changes

frame/support/test/tests/split_ui/no_section_found.rs Outdated Show resolved Hide resolved

Update frame/support/test/tests/split_ui/no_section_found.rs

ebf806d

Co-authored-by: Sam Johnson <sam@durosoft.com>

kianenigma reviewed Jun 27, 2023

View reviewed changes

frame/examples/split/src/lib.rs Outdated Show resolved Hide resolved

kianenigma reviewed Jun 27, 2023

View reviewed changes

frame/examples/split/src/lib.rs Outdated Show resolved Hide resolved

kianenigma approved these changes Jun 27, 2023

View reviewed changes

gupnik added 4 commits June 27, 2023 16:27

Addresses review comments

04aefd2

Merge branch 'gupnik/pallet-split' of github.com:paritytech/substrate…

0ee6184

… into gupnik/pallet-split

Merge branch 'master' of github.com:paritytech/substrate into gupnik/…

90ff1bc

…pallet-split

Fixes test

dd96d1a

paritytech-processbot bot merged commit a779e4d into master Jun 27, 2023

paritytech-processbot bot deleted the gupnik/pallet-split branch June 27, 2023 12:12

crystalin mentioned this pull request Oct 20, 2023

Update substrate/polkadot/cumulus from v0.9.43 to v1.1.0 moonbeam-foundation/moonbeam#2535

Closed

JesseAbram mentioned this pull request Oct 26, 2023

Update substrate and subxt entropyxyz/entropy-core#435

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[FRAME Core] Adds ability to split a pallet across multiple files #13950

[FRAME Core] Adds ability to split a pallet across multiple files #13950

gupnik commented Apr 19, 2023 •

edited by sam0x17

Loading

xlc commented Apr 19, 2023

sam0x17 commented Apr 19, 2023 via email •

edited

Loading

xlc commented Apr 19, 2023 •

edited

Loading

gupnik commented Apr 19, 2023 •

edited

Loading

sam0x17 left a comment •

edited

Loading

sam0x17 Apr 19, 2023

ggwpez Apr 20, 2023

sam0x17 commented Apr 19, 2023 •

edited

Loading

xlc commented Apr 19, 2023 •

edited

Loading

xlc commented Apr 19, 2023 •

edited

Loading

kianenigma commented Apr 20, 2023

xlc commented Apr 20, 2023

aaronbassett commented Apr 20, 2023

ggwpez left a comment

ggwpez Apr 20, 2023

sam0x17 Apr 20, 2023

ggwpez Apr 20, 2023

ggwpez Apr 20, 2023

ggwpez Apr 20, 2023

ggwpez Apr 20, 2023

sam0x17 commented Apr 20, 2023

xlc commented Apr 20, 2023

xlc commented Apr 20, 2023 •

edited

Loading

sam0x17 left a comment

gupnik commented Jun 21, 2023

command-bot bot commented Jun 21, 2023 •

edited

Loading

command-bot bot commented Jun 21, 2023

gupnik commented Jun 21, 2023

command-bot bot commented Jun 21, 2023 •

edited

Loading

command-bot bot commented Jun 21, 2023

gupnik commented Jun 21, 2023

sam0x17 left a comment

kianenigma left a comment

gupnik commented Jun 27, 2023

	// Errors inform users that something went wrong.
	/// Errors inform users that something went wrong.

[FRAME Core] Adds ability to split a pallet across multiple files #13950

[FRAME Core] Adds ability to split a pallet across multiple files #13950

Conversation

gupnik commented Apr 19, 2023 • edited by sam0x17 Loading

xlc commented Apr 19, 2023

sam0x17 commented Apr 19, 2023 via email • edited Loading

xlc commented Apr 19, 2023 • edited Loading

gupnik commented Apr 19, 2023 • edited Loading

sam0x17 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

sam0x17 commented Apr 19, 2023 • edited Loading

xlc commented Apr 19, 2023 • edited Loading

xlc commented Apr 19, 2023 • edited Loading

kianenigma commented Apr 20, 2023

xlc commented Apr 20, 2023

aaronbassett commented Apr 20, 2023

ggwpez 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

sam0x17 commented Apr 20, 2023

xlc commented Apr 20, 2023

xlc commented Apr 20, 2023 • edited Loading

sam0x17 left a comment

Choose a reason for hiding this comment

gupnik commented Jun 21, 2023

command-bot bot commented Jun 21, 2023 • edited Loading

command-bot bot commented Jun 21, 2023

gupnik commented Jun 21, 2023

command-bot bot commented Jun 21, 2023 • edited Loading

command-bot bot commented Jun 21, 2023

gupnik commented Jun 21, 2023

sam0x17 left a comment

Choose a reason for hiding this comment

kianenigma left a comment

Choose a reason for hiding this comment

gupnik commented Jun 27, 2023

gupnik commented Apr 19, 2023 •

edited by sam0x17

Loading

sam0x17 commented Apr 19, 2023 via email •

edited

Loading

xlc commented Apr 19, 2023 •

edited

Loading

gupnik commented Apr 19, 2023 •

edited

Loading

sam0x17 left a comment •

edited

Loading

sam0x17 commented Apr 19, 2023 •

edited

Loading

xlc commented Apr 19, 2023 •

edited

Loading

xlc commented Apr 19, 2023 •

edited

Loading

xlc commented Apr 20, 2023 •

edited

Loading

command-bot bot commented Jun 21, 2023 •

edited

Loading

command-bot bot commented Jun 21, 2023 •

edited

Loading