Derive StorageAccess for struct #3062

maciejka · 2023-05-08T08:33:19Z

This is an incomplete draft of storage_access derive for structs.

I am stuck at how to compose StorageAccess operations. For example for a struct:

struct AB {
  a: u256,
  b: u32
}

I would like to write it in a series of fields StorageAccess writes:

    fn write(address_domain: u32, base: starknet::StorageBaseAddress, value: AB) -> starknet::SyscallResult<()> {
        starknet::StorageAccess::<u256>::write(address_domain, base, value.a)?;
        starknet::StorageAccess::<u32>::write(address_domain, next_address, value.b)?;
        starknet::SyscallResult::Ok(())
    }

The problem is that information about space used by previous write is not available in the StorageAccess trait and I see no general way to calculate next_address.

@spapinistarkware any sugestions?

This change is

spapinistarkware

One solution is const generics and exprs, which wedont haev yet and is hard.
Another solution is to ahve associated consts on the StorageAccess trait, which we also don't have yet. This might be a viable path though.
Another solution is to have annotations on the struct fields #[size(4)] as a temporary solution. But it won't be verified in any way, and can lead to bugs.

Reviewable status: 0 of 5 files reviewed, all discussions resolved

maciejka · 2023-05-08T09:17:55Z

Is it a const? Size is a function of value I suppose, e.g.: Option type. Unless this kind of optimization is not important. pon., 8 maj 2023 o 11:10 Shahar Papini ***@***.***> napisał(a):

…

***@***.**** commented on this pull request. One solution is const generics and exprs, which wedont haev yet and is hard. Another solution is to ahve associated consts on the StorageAccess trait, which we also don't have yet. This might be a viable path though. Another solution is to have annotations on the struct fields #[size(4)] as a temporary solution. But it won't be verified in any way, and can lead to bugs. *Reviewable <https://reviewable.io/reviews/starkware-libs/cairo/3062#-:-NUuaPfw7YIYBPJoruJJ:b-nddzie>* status: 0 of 5 files reviewed, all discussions resolved — Reply to this email directly, view it on GitHub <#3062 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABOTB5MIX3Y5AWPB3CPPC3XFC2ANANCNFSM6AAAAAAXZT7TJM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- mk

spapinistarkware

There is no "written in stone" answer here. You can decide how the storage layout works. Yuo have all the ifnormation regarding how StorageAccess works.

Reviewable status: 0 of 5 files reviewed, all discussions resolved

maciejka · 2023-05-10T16:57:18Z

I would either turn base argument into a reference:

trait StorageAccess<T> {
    fn read(address_domain: u32, ref base: StorageBaseAddress) -> SyscallResult<T>;
    fn write(address_domain: u32, ref base: StorageBaseAddress, value: T) -> SyscallResult<()>;
}

or, if we want to save on memory operations in case of single storage operations, add another pair of read/write methods for consecutive operations:

trait StorageAccess<T> {
    fn read(address_domain: u32, base: StorageBaseAddress) -> SyscallResult<T>;
    fn write(address_domain: u32, base: StorageBaseAddress, value: T) -> SyscallResult<()>;
    fn read_con(address_domain: u32, ref base: StorageBaseAddress) -> SyscallResult<T>;
    fn write_con(address_domain: u32, ref base: StorageBaseAddress, value: T) -> SyscallResult<()>;
}

WDYT?

spapinistarkware · 2023-05-10T17:03:02Z

I would either turn base argument into a reference:

trait StorageAccess<T> {
    fn read(address_domain: u32, ref base: StorageBaseAddress) -> SyscallResult<T>;
    fn write(address_domain: u32, ref base: StorageBaseAddress, value: T) -> SyscallResult<()>;
}

or, if we want to save on memory operations in case of single storage operations, add another pair of read/write methods for consecutive operations:

trait StorageAccess<T> {
    fn read(address_domain: u32, base: StorageBaseAddress) -> SyscallResult<T>;
    fn write(address_domain: u32, base: StorageBaseAddress, value: T) -> SyscallResult<()>;
    fn read_con(address_domain: u32, ref base: StorageBaseAddress) -> SyscallResult<T>;
    fn write_con(address_domain: u32, ref base: StorageBaseAddress, value: T) -> SyscallResult<()>;
}

WDYT?

I think making it a ref is a good option.
@orizi ?

orizi

this sounds like a good idea - but i think we'd maybe want to update this later somehow -
so if we can have a worse name for *_con variants - that would be even better.
maybe even add read_con_internal or something of that manner.

Reviewed 2 of 5 files at r1, all commit messages.
Reviewable status: 2 of 5 files reviewed, all discussions resolved

maciejka · 2023-05-11T10:09:35Z

this sounds like a good idea - but i think we'd maybe want to update this later somehow - so if we can have a worse name for *_con variants - that would be even better. maybe even add read_con_internal or something of that manner.

Maybe just read_internal, write_internal?

orizi

this lacks some of the meaning read_continuous_internal sounds very explicit - but it shouldn't be called directly anyway - so a bad name is good IMO.

Reviewable status: 2 of 5 files reviewed, all discussions resolved

maciejka · 2023-05-11T11:08:06Z

Agree. I will proceed with implementation then.

…

***@***.**** commented on this pull request. this lacks some of the meaning read_continuous_internal sounds very explicit - but it shouldn't be called directly anyway - so a bad name is good IMO. *Reviewable <https://reviewable.io/reviews/starkware-libs/cairo/3062#-:-NV9K4N45lXmV2A4rgY_:b-mpqcde>* status: 2 of 5 files reviewed, all discussions resolved — Reply to this email directly, view it on GitHub <#3062 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABOTBZMDLSW33W6ZPHQAV3XFS4XTANCNFSM6AAAAAAXZT7TJM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

…_access

orizi

Reviewable status: 0 of 10 files reviewed, 1 unresolved discussion (waiting on @maciejka and @spapinistarkware)

a discussion (no related file):
you should just increase the u8 offset - not the base.
the idea of storage_address_from_base_and_offset(base, offset) is exactly the fact that we know this never fails, and base is limited to 2^251 - 256.

maciejka · 2023-05-16T18:18:41Z

Reviewable status: 0 of 10 files reviewed, 1 unresolved discussion (waiting on @maciejka and @spapinistarkware)

a discussion (no related file): you should just increase the u8 offset - not the base. the idea of storage_address_from_base_and_offset(base, offset) is exactly the fact that we know this never fails, and base is limited to 2^251 - 256.

Fair enough. In this case I would go with straightforward offset argument on consecuitive methods and additional :

trait StorageAccess<T> {
    fn read(address_domain: u32, base: StorageBaseAddress) -> SyscallResult<T>;
    fn write(address_domain: u32, base: StorageBaseAddress, value: T) -> SyscallResult<()>;
    fn read_consecutive_internal(
        address_domain: u32, base: StorageBaseAddress, offset: u8
    ) -> SyscallResult<T>;
    fn write_consecutive_internal(
        address_domain: u32, base: StorageBaseAddress, offset: u8, value: T
    ) -> SyscallResult<()>;
    fn size_internal(value: T) -> u8;
}

with intention to use it like this:

impl StorageAccessU256 of StorageAccess<u256> {
    fn read(address_domain: u32, base: StorageBaseAddress) -> SyscallResult<u256> {
        StorageAccess::<u256>::read_consecutive_internal(address_domain, base, 0_u8)
    }
    fn write(address_domain: u32, base: StorageBaseAddress, value: u256) -> SyscallResult<()> {
        StorageAccess::<u256>::write_consecutive_internal(address_domain, base, 0_u8, value)
    }
    fn read_consecutive_internal(
        address_domain: u32, base: StorageBaseAddress, offset: u8
    ) -> SyscallResult<u256> {
        let low = StorageAccess::<u128>::read(address_domain, base)?;
        let high = StorageAccess::<u128>::read_consecutive_internal(
            address_domain, base, offset + StorageAccess::<u128>::size_internal(low)
        )?;
        Result::Ok(
            u256 {
                low,
                high
            }
        )
    }
    fn write_consecutive_internal(
        address_domain: u32, base: StorageBaseAddress, offset: u8, value: u256
    ) -> SyscallResult<()> {
        StorageAccess::<u128>::write(address_domain, base, offset, value.low)?;
        StorageAccess::<u128>::write(
            address_domain, base, offset + StorageAccess::<u128>::size_internal(value.low), value.high
        )?;
    }
}

WDYT?

orizi

Reviewable status: 0 of 10 files reviewed, 1 unresolved discussion (waiting on @maciejka and @spapinistarkware)

a discussion (no related file):

Previously, maciejka (Maciej Kamiński) wrote…

Fair enough. In this case I would go with straightforward offset argument on consecuitive methods and additional :

trait StorageAccess<T> {
    fn read(address_domain: u32, base: StorageBaseAddress) -> SyscallResult<T>;
    fn write(address_domain: u32, base: StorageBaseAddress, value: T) -> SyscallResult<()>;
    fn read_consecutive_internal(
        address_domain: u32, base: StorageBaseAddress, offset: u8
    ) -> SyscallResult<T>;
    fn write_consecutive_internal(
        address_domain: u32, base: StorageBaseAddress, offset: u8, value: T
    ) -> SyscallResult<()>;
    fn size_internal(value: T) -> u8;
}

with intention to use it like this:

impl StorageAccessU256 of StorageAccess<u256> {
    fn read(address_domain: u32, base: StorageBaseAddress) -> SyscallResult<u256> {
        StorageAccess::<u256>::read_consecutive_internal(address_domain, base, 0_u8)
    }
    fn write(address_domain: u32, base: StorageBaseAddress, value: u256) -> SyscallResult<()> {
        StorageAccess::<u256>::write_consecutive_internal(address_domain, base, 0_u8, value)
    }
    fn read_consecutive_internal(
        address_domain: u32, base: StorageBaseAddress, offset: u8
    ) -> SyscallResult<u256> {
        let low = StorageAccess::<u128>::read(address_domain, base)?;
        let high = StorageAccess::<u128>::read_consecutive_internal(
            address_domain, base, offset + StorageAccess::<u128>::size_internal(low)
        )?;
        Result::Ok(
            u256 {
                low,
                high
            }
        )
    }
    fn write_consecutive_internal(
        address_domain: u32, base: StorageBaseAddress, offset: u8, value: u256
    ) -> SyscallResult<()> {
        StorageAccess::<u128>::write(address_domain, base, offset, value.low)?;
        StorageAccess::<u128>::write(
            address_domain, base, offset + StorageAccess::<u128>::size_internal(value.low), value.high
        )?;
    }
}

WDYT?

generally sound good.
write_consecutive_internal should probably now be write_at_offset_internal - but i'm still now sure if this would be preferable to just adding ref the offset value.

maciejka · 2023-05-17T07:21:42Z

Reviewable status: 0 of 10 files reviewed, 1 unresolved discussion (waiting on @maciejka and @spapinistarkware)

a discussion (no related file):

Previously, maciejka (Maciej Kamiński) wrote…
generally sound good. write_consecutive_internal should probably now be write_at_offset_internal - but i'm still now sure if this would be preferable to just adding ref the offset value.

Agree on write_at_offset_internal.

Adding ref to offset is problematic since offset has to be increased before it is clear that there will be next operation. Which might result in overflow in case of writing data of lenght == 256. I mean, if we have:

fn write_at_offset_internal(
    address_domain: u32, base: StorageBaseAddress, ref offset: u8, value: u256
) -> SyscallResult<()>

then what should it do when offset is 255?

orizi

Reviewed all commit messages.
Reviewable status: 0 of 10 files reviewed, 1 unresolved discussion (waiting on @maciejka and @spapinistarkware)

a discussion (no related file):

Previously, maciejka (Maciej Kamiński) wrote…

Agree on write_at_offset_internal.

Adding ref to offset is problematic since offset has to be increased before it is clear that there will be next operation. Which might result in overflow in case of writing data of lenght == 256. I mean, if we have:
fn write_at_offset_internal(
    address_domain: u32, base: StorageBaseAddress, ref offset: u8, value: u256
) -> SyscallResult<()>
then what should it do when offset is 255?

got it.

…_access

orizi

Reviewed all commit messages.
Reviewable status: 0 of 10 files reviewed, 2 unresolved discussions (waiting on @maciejka and @spapinistarkware)

corelib/src/starknet/storage_access.cairo line 365 at r3 (raw file):

impl StorageAccessClassHash of StorageAccess<ClassHash> {
    fn read(address_domain: u32, base: StorageBaseAddress) -> SyscallResult<ClassHash> {
        StorageAccess::<ClassHash>::read_at_offset_internal(address_domain, base, 0_u8)

don't make existing implementations less efficient just for creating less code.

Suggestion:

        Result::Ok(
            StorageAccess::<felt252>::read(address_domain, base)?.try_into().expect('Non ClassHash')
        )

maciejka · 2023-05-18T07:48:35Z

Reviewed all commit messages.
Reviewable status: 0 of 10 files reviewed, 2 unresolved discussions (waiting on @maciejka and @spapinistarkware)

corelib/src/starknet/storage_access.cairo line 365 at r3 (raw file):
impl StorageAccessClassHash of StorageAccess<ClassHash> {
    fn read(address_domain: u32, base: StorageBaseAddress) -> SyscallResult<ClassHash> {
        StorageAccess::<ClassHash>::read_at_offset_internal(address_domain, base, 0_u8)
don't make existing implementations less efficient just for creating less code.

Suggestion:
        Result::Ok(
            StorageAccess::<felt252>::read(address_domain, base)?.try_into().expect('Non ClassHash')
        )

I've been thinking about exactly this. I just wanted to make it work first before optimising.

Another question: What should be the critiria for adding #[inline(always)] to StorageAccess read/write methods. It is not clear to mewhy the write methods are usually inlined when read are not?

orizi

Reviewed 1 of 5 files at r1, 1 of 17 files at r4, 1 of 7 files at r6, 4 of 4 files at r7, all commit messages.
Reviewable status: 10 of 25 files reviewed, 3 unresolved discussions (waiting on @maciejka and @spapinistarkware)

corelib/src/starknet/storage_access.cairo line 97 at r7 (raw file):

impl StorageAccessBool of StorageAccess<bool> {
    #[inline(always)]

make this in another pr - to reduce the changes in generation sierra code.

Code quote:

#[inline(always)]

crates/cairo-lang-starknet/src/plugin/events.rs line 206 at r6 (raw file):

Previously, maciejka (Maciej Kamiński) wrote…

Removed unnecesary comments.
What's wrong with derive_event_needed? It returns true if event emission functions should be derived for a type. Name makes sense to me.

didn't ee you added a parallel function for the storage access - all good.

crates/cairo-lang-starknet/src/plugin/storage_access.rs line 107 at r7 (raw file):

}

pub fn derive_storage_access_needed<T: QueryAttrs>(with_attrs: &T, db: &dyn SyntaxGroup) -> bool {

doc

Code quote:

derive_storage_access_needed

This reverts commit 9e5a6a1.

maciejka · 2023-05-22T09:32:58Z

Reviewed 1 of 5 files at r1, 1 of 17 files at r4, 1 of 7 files at r6, 4 of 4 files at r7, all commit messages.
Reviewable status: 10 of 25 files reviewed, 3 unresolved discussions (waiting on @maciejka and @spapinistarkware)

corelib/src/starknet/storage_access.cairo line 97 at r7 (raw file):
impl StorageAccessBool of StorageAccess<bool> {
    #[inline(always)]
make this in another pr - to reduce the changes in generation sierra code.

Code quote:
#[inline(always)]
crates/cairo-lang-starknet/src/plugin/events.rs line 206 at r6 (raw file):

Previously, maciejka (Maciej Kamiński) wrote…
didn't ee you added a parallel function for the storage access - all good.

crates/cairo-lang-starknet/src/plugin/storage_access.rs line 107 at r7 (raw file):
}

pub fn derive_storage_access_needed<T: QueryAttrs>(with_attrs: &T, db: &dyn SyntaxGroup) -> bool {
doc

Code quote:
derive_storage_access_needed

Done. There are still changes in erc20 sierra code. Maybe it is due to this change: https://github.com/starkware-libs/cairo/pull/3062/files#diff-4feb70577299f5836d5feacb9c62326358848bdfe48afcf5de19f51a8663e1f9R313 ? Should I delegate it to a separate pr as well?

orizi

Reviewed 1 of 8 files at r2, 9 of 18 files at r5, 8 of 8 files at r8, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @maciejka and @spapinistarkware)

crates/cairo-lang-starknet/src/plugin/storage_access.rs line 107 at r7 (raw file):

Previously, maciejka (Maciej Kamiński) wrote…

Done. There are still changes in erc20 sierra code. Maybe it is due to this change: https://github.com/starkware-libs/cairo/pull/3062/files#diff-4feb70577299f5836d5feacb9c62326358848bdfe48afcf5de19f51a8663e1f9R313 ? Should I delegate it to a separate pr as well?

you still need the inline of write_at_offset_internal to remove the changes - aside from that it should be fine.

…_access

maciejka · 2023-05-22T11:10:20Z

Reviewed 1 of 8 files at r2, 9 of 18 files at r5, 8 of 8 files at r8, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @maciejka and @spapinistarkware)

crates/cairo-lang-starknet/src/plugin/storage_access.rs line 107 at r7 (raw file):

Previously, maciejka (Maciej Kamiński) wrote…
you still need the inline of write_at_offset_internal to remove the changes - aside from that it should be fine.

Is it ok now?

orizi

Reviewed 5 of 5 files at r9, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @maciejka and @spapinistarkware)

crates/cairo-lang-starknet/src/plugin/storage_access.rs line 107 at r7 (raw file):

Previously, maciejka (Maciej Kamiński) wrote…

Is it ok now?

looks good!

orizi

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @maciejka and @spapinistarkware)

maciejka · 2023-05-23T08:18:22Z

Any chance of merging this any time soon? @spapinistarkware

spapinistarkware

Reviewed 1 of 5 files at r1, 2 of 8 files at r2, 1 of 17 files at r4, 10 of 18 files at r5, 3 of 4 files at r7, 3 of 8 files at r8, 5 of 5 files at r9, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @maciejka)

spapinistarkware

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @maciejka)

spapinistarkware

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @maciejka)

orizi

Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @maciejka)

milancermak · 2023-05-23T11:37:47Z

Why does size_internal take a value argument? Isn't the type size independent of its value?

orizi

since there are options where it would be dependent - for example - if we implement this for Option<VeryLargeStruct> - we would probably decide to not write as much in the None case.

Reviewable status: complete! all files reviewed, all discussions resolved

spapinistarkware

Not sure I agree here. This is not Serde where we always write sequentially. We need to be able to write out of order, and we need a constant size slot in storage

Reviewable status: complete! all files reviewed, all discussions resolved

maciejka · 2023-05-23T12:30:21Z

Not sure I agree here. This is not Serde where we always write sequentially. We need to be able to write out of order, and we need a constant size slot in storage

Reviewable status: complete! all files reviewed, all discussions resolved

Defining a model of underlying storage would definitely help. What do you mean by "we need to be able to write out of order"?

milancermak · 2023-05-23T12:51:11Z

Not being dependent on the value would also allow for some kind of lazy loading or writing only the dirty values (not sure how that would look like in practice tho).

orizi

but i think this should be up to the user (be it through the usage of another wrapping trait or something of that manner) - but i don't think it should block the other option.

Reviewable status: complete! all files reviewed, all discussions resolved

maciejka · 2023-05-25T21:02:15Z

It is not clear to me what is the outcome of recent considerations about sizeInternal being value dependent. Should it be changed somehow? What are the usecases it is not compatible with? It would be better to do it before current version is released...

It seems like there are a few simple tasks left to complete introduction of #derive(storage_access::StorageAccess) into the code base:

use it for starknet builtin types like: u256, EthAddress
use it for Dispatcher's generated for #[abi]
add #[inline] to StorageAccess impls for builtin types
Anything else?
WDYT?

maciejka · 2023-05-26T09:39:31Z

It seems like there are a few simple tasks left to complete introduction of #derive(storage_access::StorageAccess) into the code base:

use it for starknet builtin types like: u256, EthAddress

use it for Dispatcher's generated for #[abi]

Here is a pr deriving StorageAccess for u256, EthAddress, Dispatcher: #3247

moodysalem · 2023-05-27T00:24:36Z

This is a breaking change so I would personally think it better to just remove the old methods. If you're optimizing for gas I imagine you're going to write custom implementations of StorageAccess, since tx cost should be dominated by posting storage diffs to L1 so you'll want to do maximum packing, and the multiple methods to do the same thing is a bit annoying

Also if the size is constant it could be a generic const parameter. Not sure if this is possible but I would prefer constant size where this is used

maciejka added 2 commits May 8, 2023 10:17

wip: derive struct storage_access

4f62460

format fix

73566bf

maciejka changed the title ~~Derive storage_access for struct~~ Derive StorageAccess for struct May 8, 2023

maciejka mentioned this pull request May 8, 2023

feat: derive StorageAccess for arbitrary struct #3063

Closed

Fix linter errors

56d27c0

spapinistarkware reviewed May 8, 2023

View reviewed changes

orizi reviewed May 11, 2023

View reviewed changes

maciejka added 3 commits May 15, 2023 11:40

extend StorageAccess with methods for consecutive operations

ff06f5d

Merge remote-tracking branch 'origin/main' into derive_struct_storage…

27e6bb3

…_access

fix tests

d12a394

maciejka marked this pull request as ready for review May 15, 2023 15:35

Merge remote-tracking branch 'origin/main' into derive_struct_storage…

6ea91a8

…_access

maciejka requested a review from spapinistarkware May 15, 2023 15:37

orizi requested changes May 15, 2023

View reviewed changes

orizi requested changes May 17, 2023

View reviewed changes

maciejka added 2 commits May 18, 2023 00:23

cairo level tests ok, wip

ee7969d

Merge remote-tracking branch 'origin/main' into derive_struct_storage…

439be83

…_access

orizi requested changes May 18, 2023

View reviewed changes

fix tests

485c112

orizi requested changes May 22, 2023

View reviewed changes

maciejka added 3 commits May 22, 2023 11:06

Add doc

8a4f4cd

Revert "inline reads/writes of StorageAccess impls"

dd7d0e5

This reverts commit 9e5a6a1.

fix tests

3bda477

orizi requested changes May 22, 2023

View reviewed changes

maciejka added 2 commits May 22, 2023 12:41

inline StorageAccess internal methods

fc282bd

Merge remote-tracking branch 'origin/main' into derive_struct_storage…

0adaca9

…_access

orizi reviewed May 22, 2023

View reviewed changes

orizi approved these changes May 22, 2023

View reviewed changes

spapinistarkware approved these changes May 23, 2023

View reviewed changes

spapinistarkware added this pull request to the merge queue May 23, 2023

orizi approved these changes May 23, 2023

View reviewed changes

Merged via the queue into starkware-libs:main with commit 9203b80 May 23, 2023

orizi reviewed May 23, 2023

View reviewed changes

spapinistarkware reviewed May 23, 2023

View reviewed changes

orizi reviewed May 23, 2023

View reviewed changes

milancermak pushed a commit to milancermak/cairo that referenced this pull request May 23, 2023

Derive StorageAccess for struct (starkware-libs#3062)

f23ae20

ametel01 mentioned this pull request Jun 24, 2023

Added StorageAccess to appendix 3 cairo-book/cairo-book#258

Merged

Derive StorageAccess for struct #3062

Derive StorageAccess for struct #3062

Conversation

maciejka commented May 8, 2023 • edited by spapinistarkware Loading

spapinistarkware left a comment

Choose a reason for hiding this comment

maciejka commented May 8, 2023 via email

spapinistarkware left a comment

Choose a reason for hiding this comment

maciejka commented May 10, 2023

spapinistarkware commented May 10, 2023

orizi left a comment

Choose a reason for hiding this comment

maciejka commented May 11, 2023

orizi left a comment

Choose a reason for hiding this comment

maciejka commented May 11, 2023 via email

orizi left a comment

Choose a reason for hiding this comment

maciejka commented May 16, 2023

orizi left a comment

Choose a reason for hiding this comment

maciejka commented May 17, 2023

orizi left a comment

Choose a reason for hiding this comment

orizi left a comment

Choose a reason for hiding this comment

maciejka commented May 18, 2023

orizi left a comment

Choose a reason for hiding this comment

maciejka commented May 22, 2023

orizi left a comment

Choose a reason for hiding this comment

maciejka commented May 22, 2023

orizi left a comment

Choose a reason for hiding this comment

orizi left a comment

Choose a reason for hiding this comment

maciejka commented May 23, 2023

spapinistarkware left a comment

Choose a reason for hiding this comment

spapinistarkware left a comment

Choose a reason for hiding this comment

spapinistarkware left a comment

Choose a reason for hiding this comment

orizi left a comment

Choose a reason for hiding this comment

milancermak commented May 23, 2023

orizi left a comment

Choose a reason for hiding this comment

spapinistarkware left a comment

Choose a reason for hiding this comment

maciejka commented May 23, 2023

milancermak commented May 23, 2023

orizi left a comment

Choose a reason for hiding this comment

maciejka commented May 25, 2023

maciejka commented May 26, 2023

moodysalem commented May 27, 2023 • edited Loading

maciejka commented May 8, 2023 •

edited by spapinistarkware

Loading

moodysalem commented May 27, 2023 •

edited

Loading