Simple calculator #1483

minacode · 2022-12-08T19:39:30Z

This PR implements a simple fixed-point calculator. In contrast to #375 it aims to be simpler by not parsing whole equations but just evaluating one operation at a time over an accumulated result.

It takes an operation and a value (digit-wise) and applies the value to the result with the chosen operation whenever a new operation is chosen or = is pressed.

=: evaluate current input
<: removes the input charwise or reset the result if the input is zero.
(-): toggle the sign of the current input (thanks @FintasticMan)
+ - / * /: press the button to cycle through the operators and "no-operator".

It uses fixed-point numbers and checks for errors like too big results and zero division.

Known issues:

from @yusufmte's comment below:

joseph58tech · 2022-12-08T20:04:57Z

I feel like the original design from #375 was simpler and cleaner, the multifunctional +/- and */ buttons might be too much of a hassle for regular use.

FintasticMan · 2022-12-08T20:19:09Z

About the printing of the value, I think that doing something like what's done here should be fine:

InfiniTime/src/displayapp/screens/BatteryInfo.cpp

Line 38 in 361e381

    
           lv_label_set_text_fmt(voltage, "%1i.%02i volts", batteryVoltage / 1000, batteryVoltage % 1000 / 10);

Edit: looking at the code, seems like you're already using something like this.

I would say that it would be better to use fixed width integers instead of long ints, so that it's obvious what the min and max values are.

minacode · 2022-12-09T11:04:34Z

@joseph58tech, you mean the design with two keyboard layers?

@FintasticMan, I can change long int to int64_t, but the format string will still contain %ld which means "long decimal".

FintasticMan · 2022-12-09T12:51:09Z

You can either leave the format string as "%ld", or you can use fixed width format literals. This would mean that the format string would become "%" PRId64. To use those you need to include the <cinttypes> header. It's worth mentioning that it seems like in this codebase printing fixed width integers is usually just done with normal format specifiers.

yusufmte · 2022-12-11T20:36:59Z

This looks amazing, thanks for making it! The UI looks really nicely designed with a good balance of button size and ability to do most of the major operations you would need. Personally I prefer the simplicity of this app though I see advantages in both. I also love the inclusion of ^ and using the same button for +- and */ to save space.

I would love to one of the calculator apps merged in an upcoming release and I'll probably be using it on my PT until then. It feels like the biggest thing currently "missing" from the PineTime to me. Along with the usefulness of having a calculator close by, a small part of that is probably from reminiscing about these calculator watches from childhood, haha.

minacode · 2022-12-11T23:35:28Z

Thank you! 😊 Nice to hear that you want to try it already. This may help with finding any eventual bugs. I haven't tried the last two commits on my watch because I have another test build running right now.

FintasticMan · 2022-12-12T22:43:55Z

Looks good, I've tried this on my watch and it works quite nicely. I do think that it is better to use floats rather than doubles for the pow calculation. Why did you switch to doubles?

Ceimour · 2022-12-12T22:57:48Z

Thanks! I thought I had worked through all the replacements of float for double. Where did you find a double? From: ***@***.***> Sent: Monday, December 12, 2022 4:44 PM To: ***@***.***> Cc: ***@***.***> Subject: Re: [InfiniTimeOrg/InfiniTime] Simple calculator (PR #1483) Looks good, I've tried this on my watch and it works quite nicely. I do think that it is better to use floats rather than doubles for the pow calculation. Why did you switch to doubles? — Reply to this email directly, view it on GitHub<#1483 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A3C6AGUV6STVDJILC6TNB23WM6TD3ANCNFSM6AAAAAASYQQYU4>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

minacode · 2022-12-12T23:21:56Z

I thought that double matches the 64-bit integers better than float. Is that correct? 🤔
The workaround is necessary because I wanted to have a power function and could not find one the works with the fixed point numbers. Speed should be no concern for one calculation.

Ceimour · 2022-12-12T23:36:35Z

I switched to floats instead of doubles to see if the compiler would make use of the FPU. And I was very pleased to see big performance increase (something like 10x). So I assume the FPU is in use. From: Max ***@***.***> Sent: Monday, December 12, 2022 5:22 PM To: ***@***.***> Cc: ***@***.***>; ***@***.***> Subject: Re: [InfiniTimeOrg/InfiniTime] Simple calculator (PR #1483) I thought that double matches the 64-bit integers better than float. Is that correct? 🤔 The workaround is necessary because I wanted to have a power function and could not find one the works with the fixed point numbers. Speed should be no concern for one calculation. — Reply to this email directly, view it on GitHub<#1483 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A3C6AGUHY7CZYVJSGQM3CE3WM6XR7ANCNFSM6AAAAAASYQQYU4>. You are receiving this because you commented.Message ID: ***@***.***>

Ceimour · 2022-12-12T23:38:08Z

Oh, and the datasheet specifies that the FPU is restricted to float. From: Max ***@***.***> Sent: Monday, December 12, 2022 5:22 PM To: ***@***.***> Cc: ***@***.***>; ***@***.***> Subject: Re: [InfiniTimeOrg/InfiniTime] Simple calculator (PR #1483) I thought that double matches the 64-bit integers better than float. Is that correct? 🤔 The workaround is necessary because I wanted to have a power function and could not find one the works with the fixed point numbers. Speed should be no concern for one calculation. — Reply to this email directly, view it on GitHub<#1483 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A3C6AGUHY7CZYVJSGQM3CE3WM6XR7ANCNFSM6AAAAAASYQQYU4>. You are receiving this because you commented.Message ID: ***@***.***>

minacode · 2022-12-13T00:26:48Z

Ok, I will test both types on the watch. Thank you for the input!

Ceimour · 2022-12-13T00:33:16Z

So sorry, I thought this was related to my recent pull request and responded in that context. Anyway, you might try powf() with floats. From: Max ***@***.***> Sent: Monday, December 12, 2022 6:27 PM To: ***@***.***> Cc: ***@***.***>; ***@***.***> Subject: Re: [InfiniTimeOrg/InfiniTime] Simple calculator (PR #1483) Ok, I will test both types on the watch. Thank you for the input! — Reply to this email directly, view it on GitHub<#1483 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A3C6AGQO2EACQDE7LOS6PI3WM67FHANCNFSM6AAAAAASYQQYU4>. You are receiving this because you commented.Message ID: ***@***.***>

Ceimour · 2022-12-13T00:37:17Z

I apologize for any confusion, I thought this was related to a pull request I made. From: ***@***.***> Sent: Monday, December 12, 2022 4:44 PM To: ***@***.***> Cc: ***@***.***> Subject: Re: [InfiniTimeOrg/InfiniTime] Simple calculator (PR #1483) Looks good, I've tried this on my watch and it works quite nicely. I do think that it is better to use floats rather than doubles for the pow calculation. Why did you switch to doubles? — Reply to this email directly, view it on GitHub<#1483 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A3C6AGUV6STVDJILC6TNB23WM6TD3ANCNFSM6AAAAAASYQQYU4>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

FintasticMan · 2022-12-13T08:12:23Z

I thought that double matches the 64-bit integers better than float. Is that correct? 🤔

While doubles are 64 bits wide, that doesn't make a difference for int > float and float > int conversion. 32-bit floats will definitely have enough precision for this calculation, and as Ceimour already said, the FPU in the nRF 52832 is for 32-bit floats only, so double calculations will be done much less efficiently.

minacode · 2022-12-13T08:15:05Z

This says that there are 9 digits for float and 17 for double. 9 is not enough. That is only 6 integer digits.

CCF100 · 2022-12-19T06:27:10Z

Hey @minacode, if the variable used to store the calculated value overflows, the watch reboots...

minacode · 2022-12-19T09:13:51Z

Thank you for testing this! It doesn't happen in the simulator so I wonder what makes the watch crash.
Does it happen with every operation or only with the power function?

Edit: I tested the last changes on the watch and it seems like a lot broke. Maybe we have to revert some of the changes.

yusufmte · 2022-12-19T18:50:59Z

@minacode : I've been using the calculator for a little while now. Overall for most calculations it's working great, doing just what it's supposed to, and has been very useful-- gonna keep using it on my build and I would love to see it included in an upcoming milestone!

Basically it has worked flawlessly for me with any small integer operations (small meaning anything not huge, like less than 10^12). Deviating from small integers, there are a few bugs to iron out:

Bug with crashing on large operations. As @CCF100 mentioned-- try feeding the calculator a very large operation (eg large number ^ large number), and InfiniTime will crash and reboot. I do agree this is probably because of overflow, as this consistently this happens with 2^54 but not with 2^53. It is not just the power function -- the same crash happens when reaching similar magnitudes by repeatedly doing 10*10. Suggested behavior: when an operation is about to cause overflow, the result label should just say "TOO LARGE." This would be fine, as in daily use most people wouldn't need to conduct operations that large.
Bug when typing a number larger than the interface allows. Try repeatedly tapping "9" (or any digit)-- eventually the input label will start cycling between a jumble of random numbers, and as you keep tapping it, eventually it will show "-1". Not sure exactly what causes this. Suggested behavior: When the current number in the input field fills the field (looks like that happens as 12 digits), further digits input should be ignored, and some feedback should be sent to the user to indicate that this happened (eg short vibration as if to say "Nope, no more digits allowed.").
Bug with any use of the decimal point. Try using the . (for example, type 5.1) and the number shown in the input field would be different (for 5.1, you would see 5.15663343). Not sure exactly what is causing this, but it has been consistent for me. However, the number actually stored in the input field is what you typed (5.1). For example, try 49^0.5 -- the result will, appropriately, be 7, even though the operation will look like you are doing 49^0.15663343.
Bug where if the result exceeds 12 digits, you will only see the last 12. For example, if the result is 1234567890123, you will only see 234567890123. Suggested behavior: Either (a) the result label just says "TOO LARGE" if the result exceeds 12 digits, or (b) use scientific notation with E to denote numbers larger than 12 digits (for example, the result above would display as 1.2345678E12). I think solution (a) would be just fine, but solution (b) would ultimately be ideal.
Bug when pressing ^, sometimes it will repeat whichever number you last placed. This one is tricky as it is not consistent, but when it starts happening (and I'm not quite sure what triggers it to start happening), it continues to happen consistently until the PineTime reboots. When pressing ^, instead of changing the operation to ^, it will repeat the digit you just typed. For example, if you tap 2 then ^, you will see 22 in the input field and no operation. If you keep tapping ^, it will keep repeating the same digit, then eventually clear the input field after a few taps.
UI gripe / Suggestion (not a bug). This is somewhat subjective of a design decision and it might just be me, but when I see the < I sort of expect it to work as a BACKSPACE rather than a CLEAR. Along similar lines, I feel like a BACKSPACE would be quite handy for the sausage-fingered among us, as the buttons are quite small and it's easy to mistype :) Suggestion: I would keep the < button in it's place and change it to a BACKSPACE function, removing the last digit placed in the input field rather than clearing the whole thing. Then, I would use the space in the top-right corner (above the operation label) for a CLEAR button, and I would use the symbol C or even something like an eraser symbol from the FontAwesome library.

I hope this is helpful-- FYI these are all on PineTime hardware, I haven't tested any of these in the sim! If I have time in the upcoming days, I might poke around the code and see if I can help troubleshoot the causes for some of these.

minacode · 2022-12-19T19:31:47Z

Thank you so much for this detailed feedback! You even gave examples to reproduce. This is very helpful.
I added your points to the description as "known issues" and will investigate them.

There seems to be a difference in behaviour between the simulator (x86) and the watch. I am currently diving in the details to get everything a little more safer. The format strings are way less forgiving on the watch it seems.

At first I ignored the issues around overflows but I get that the UX would be heavily improved by a controlled maximum value.

This is somewhat subjective of a design decision and it might just be me, but when I see the < I sort of expect it to work as a BACKSPACE rather than a CLEAR

This is a good idea. It would also be a lot more forgiving since it would not delete the result instantly. I don't know about a clear button and will think about it. Nulling the result could technically also be done via the = button.

Avamander · 2022-12-20T07:24:52Z

Nulling the result could technically also be done via the = button.

That's usually "repeat the last operation"

minacode · 2022-12-20T09:26:53Z

Then this shall be it.

yusufmte · 2022-12-20T14:42:42Z

Glad it is helpful-- thanks for your diligence!

At first I ignored the issues around overflows but I get that the UX would be heavily improved by a controlled maximum value.

I was thinking the same thing at first: probably very few users would need to perform calculations at the level needed to cause overflow. It's more the kind of bug that comes out of the user looking for ways to break the app. But out of principle it is best to foolproof it such that the user is incapable of causing a crash with any combination of inputs, and to make it clear when the user passes into too-large territory where the calculations or interface start to break down. 🙂

That's usually "repeat the last operation"

Agree! That would be a more expected behavior for =.

PS: This might be a good BACKSPACE symbol if you are interested! (But < works fine as well!)

yusufmte · 2022-12-20T18:59:45Z

Bug with any use of the decimal point. Try using the . (for example, type 5.1) and the number shown in the input field would be different (for 5.1, you would see 5.15663343). Not sure exactly what is causing this, but it has been consistent for me. However, the number actually stored in the input field is what you typed (5.1). For example, try 49^0.5 -- the result will, appropriately, be 7, even though the operation will look like you are doing 49^0.15663343.

Just wanted to add briefly -- In case it is helpful with troubleshooting this one: this bug also happens with division of non-divisible integers. For example, 52/53 and 1/2 both evaluate to 0.48957.

minacode · 2022-12-20T19:42:32Z

Ok, so I changed some things in the last commits. It's not done yet, but we are getting there.

backspace is now beautiful 😊 and deletes in this order
1. the operation (if it exists)
2. a digit from the input value (if it exists)
3. the result
the values are bounded and overflow is checked (but not reported yet). I also updated the number of decimal digits to 4 for the time being as 3 let some bugs slip through. I may go back to 3 because there are only 6 integer digits left now

All changes are only tested in the simulator for now.

And I have a question: How exactly do you expect the = button to behave?

Currently it calculates a new result and keeps the value and operation untouched. Therefore you can press it multiple times for repeated calculation. But this causes two issues:

pressing any operation button afterwards will evaluate the calculation again (as it normally does as well). I think this would be unexpected.
number input will extend the number that is already there.

One could use the backspace but it seems very inconvenient to me.
Another solution could be an internal "= was pressed"-flag that causes an immediate reset of the operation and number once anything other than = gets pressed.

minacode · 2022-12-21T15:04:06Z

The last commit is an experiment for the UX. Instead of standard button presses you can now hold the touch and drag it accross the button matrix. The current button is colored with a different background. Releasing triggers the button handle. I hope that this help with pressing the correct buttons on the small screen.

If anyone has a good suggestion for the focus color I will add it. I am not good with colors 😀

yusufmte · 2022-12-21T15:45:39Z

Awesome, thanks for your work on this-- love the changes!! Tested new build on PineTime hardware and can confirm that:

Overflow no longer causes a crash-- any overflow seemingly evaluates to 0.0001. Remaining suggestion: Probably best if it's eventually reported as OVERFLOW or TOO LARGE, for accuracy, but I think this is great.
Values bounding is working well and it is not possible to type a number larger than the interface allows. Remaining suggestion: It feels a bit odd that you can only type 6 digits before the decimal point, and 4 digits after. With room for 11 characters (including the decimal point), it feels like you should be able to type either n.nnnnnnnnn or nnnnnnnnn.n , for example. My suggestion would be to check for the total number of characters (digits before decimal point, decimal point itself, and digits after), and stop accepting inputs once the total is 11.
Calculations with non-integer numbers have been working perfectly, and there is no more discrepancy between the number typed and the number in the register! Remaining suggestion: Similar to the suggestion in (2) above, it would be nice if the number of digits after the decimal point in the result extended to the end of the result area. For example, 1/9 currently evaluates to 0.1111. With room for 11 characters, I feel it should show 0.111111111. In other words, the behavior would be: (a) show all digits to the left of the . -- if there are more than 11, instead report the number as too large or use a scientific notation; (b) show as many digits as possible to the right of the ., based on how much room is left in the label. The reason for this is that it's clear to the user that the calculator will round when the label is full, but not necessarily if it gets cut off before that (so user might ask "are there only 4 digits here, or is it rounding?'). However feel free to disregard this one if it's overcomplicating things.
The backspace is looking/working great! 🙂

And I have a question: How exactly do you expect the = button to behave?
Currently it calculates a new result and keeps the value and operation untouched. Therefore you can press it multiple times for repeated calculation. But this causes two issues:

pressing any operation button afterwards will evaluate the calculation again (as it normally does as well). I think this would be unexpected.

number input will extend the number that is already there.
One could use the backspace but it seems very inconvenient to me.
Another solution could be an internal "= was pressed"-flag that causes an immediate reset of the operation and number once anything other than = gets pressed.

The way = now is working is exactly as I would expect, with allowing multiple presses for repeated calculation!

Here's the way I would recommend addressing those two issues:

i. I agree this is confusing. I would make it so that pressing the operation buttons never causes a calculation-- only changes the current operation. The ONLY way to cause a calculation therefore would be pressing =, and so the user would never do it accidentally. If you did this, I would also modify the backspace so that it doesn't remove the operation (since you can change it freely), only: (a) a digit from the input value, then (b) the result. (I think that change to the backspace is an added bonus, because it's potentially confusing that the backspace would remove the operation first even though it may not be the last thing typed.)

ii. I like your solution-- when = is pressed and a calculation happens, if you type any digit after that, it should reset the current input label and place the digit freshly. (This also makes clearing more convenient.) However, I don't think the operation needs to be reset (only the number), especially if the tweak in (i) is made where the operation can be changed anytime.

Unrelated: division by zero does nothing (tapping the = doesn't register). I think this is fine to stay that way, but if you eventually had reported flags like TOO LARGE or OVERFLOW, it would probably make sense to report this as well as something like UNDEFINED, for accuracy.

The last commit is an experiment for the UX. Instead of standard button presses you can now hold the touch and drag it accross the button matrix. The current button is colored with a different background. Releasing triggers the button handle. I hope that this help with pressing the correct buttons on the small screen.

This sounds like a great idea, excited to try it out!

(Of course, feel free to take or leave any of the suggestions above at your discretion! Just my thoughts but others might think differently and it is your app 🙂)

minacode · 2022-12-21T16:47:41Z

Again thank you for the feedback! It means a lot 😊

There needs to be an overflow check for the power function. I haven't done this yet.
(and 3.) The current implementation builds on fixed point numbers. You basically suggest changing to floats. Maybe that is a thing, I don't know. I didn't use floats based on advice from the chat in the early development and will keep it like that for now. But I will change back to 3 decimals digits and 7 integer digits, because I guess that is the most practical format. 4 is just better for debugging.
Nice! I like it as well 😌

minacode · 2022-12-31T13:19:56Z

I did some updates:

Power overflow is done.
Error messages are done for "too large" and "zero division".
The operation label is gone and instead the buttons are now colored. The numbers can be a lot larger now. I hope that this doesn't open any new bugs 😀

A gif probably says the most:

There are some minor issues left that I will continue working on.

yusufmte · 2023-01-01T02:43:20Z

Awesome updates! Thanks for your work 👍 Testing latest build on PineTime hardware and all the bugs number 1-7 reported above are resolved from my end ✔️ I love the design changes like the touch/drag coloring, and coloring the currently active operation! Very clever & sleek.

(Also, regarding the fixed vs floating point, that makes sense 🙂 I agree, I've become familiar with it and think fixed point is probably favorable for simplicity of design.)

minacode · 2024-09-01T20:09:52Z

The last commit did not change something, so I guess that was all we will get.

mark9064 · 2024-09-01T20:15:20Z

Oh they're equivalent, it's that constexpr is nicer to use in general as it is a guarantee of compile time evaluation (if it cannot be evaluated at compile time compilation fails). The way you had previously is the way to do it in C, with constexpr added to C++ constexpr const char* is the more modern way from what I understand

minacode · 2024-09-01T20:17:33Z

So we just leave it like this, because more const -> more good? 😀

mark9064 · 2024-09-01T20:21:46Z

The const immediately after constexpr is redundant (constexpr implies const) so I'd remove that personally but it doesn't make a difference in terms of semantics

Because it is redundant

by making the button labels even more const

mark9064

Haven't reviewed the mathematical part as I'm not really a fixed point expert. I've been using this for a while though and it's worked well

src/displayapp/fonts/fonts.json

src/displayapp/screens/Calculator.h

src/displayapp/screens/Calculator.cpp

Co-authored-by: mark9064 <[email protected]>

src/displayapp/fonts/fonts.json

src/displayapp/screens/Calculator.cpp

mark9064

All looks good to me!
(minus checking the fixed point correctness, it's beyond me :P)

src/displayapp/screens/Calculator.h

yusufmte · 2024-12-08T23:24:19Z

Just piping in to say - thanks everyone for keeping up work on this so diligently! Would be very excited as a user to see this merged sometime! Many thanks :)

jackdur · 2024-12-09T18:33:02Z

All looks good to me! (minus checking the fixed point correctness, it's beyond me :P)

So, can we merge this now? Very cool app!

Co-authored-by: mark9064 <[email protected]>

minacode · 2024-12-09T19:10:10Z

Wohoo, approval 🥳! Thanks everyone for testing and reviewing this app over the last two years!

minacode added 2 commits September 3, 2024 03:03

Remove const

eb160ee

Because it is redundant

Merge branch 'main' into simple-calculator

fb03cf6

mark9064 mentioned this pull request Oct 12, 2024

Calculator App #375

Open

5 tasks

minacode and others added 3 commits November 1, 2024 12:01

Merge branch 'main' into simple-calculator

d8c2b99

Merge branch 'main' into simple-calculator

8c47941

fix compile error

8c30a35

by making the button labels even more const

mark9064 reviewed Nov 24, 2024

View reviewed changes

src/displayapp/fonts/fonts.json Outdated Show resolved Hide resolved

src/displayapp/screens/Calculator.h Outdated Show resolved Hide resolved

src/displayapp/screens/Calculator.h Show resolved Hide resolved

src/displayapp/screens/Calculator.cpp Outdated Show resolved Hide resolved

minacode and others added 4 commits November 24, 2024 16:39

fix typo

76c4bda

Co-authored-by: mark9064 <[email protected]>

rearrange font symbols

9a97e6c

explain number of digits

7be0251

remove logging

0e1893f

mark9064 reviewed Nov 24, 2024

View reviewed changes

src/displayapp/fonts/fonts.json Outdated Show resolved Hide resolved

do not remove dice icon

9e3c665

mark9064 reviewed Nov 26, 2024

View reviewed changes

src/displayapp/screens/Calculator.cpp Outdated Show resolved Hide resolved

src/displayapp/screens/Calculator.cpp Outdated Show resolved Hide resolved

src/displayapp/screens/Calculator.cpp Outdated Show resolved Hide resolved

minacode added 5 commits December 7, 2024 17:48

Merge branch 'main' into simple-calculator

f871487

Specify auto types

acf38e9

Change variables to camel case

9cb3b65

Rename equalSignPressed to equalSignPressedBefore

3705dc9

Update header

1cb1a8b

mark9064 approved these changes Dec 8, 2024

View reviewed changes

src/displayapp/screens/Calculator.h Outdated Show resolved Hide resolved

minacode and others added 2 commits December 9, 2024 20:07

fix constexpr position

a3320b1

Co-authored-by: mark9064 <[email protected]>

Merge branch 'main' into simple-calculator

aca8a1d

Merge branch 'main' into simple-calculator

98b84c8

Simple calculator #1483

Are you sure you want to change the base?

Simple calculator #1483

Conversation

minacode commented Dec 8, 2022 • edited Loading

Known issues:

joseph58tech commented Dec 8, 2022

FintasticMan commented Dec 8, 2022 • edited Loading

minacode commented Dec 9, 2022

FintasticMan commented Dec 9, 2022 • edited Loading

yusufmte commented Dec 11, 2022 • edited Loading

minacode commented Dec 11, 2022

FintasticMan commented Dec 12, 2022

Ceimour commented Dec 12, 2022 via email

minacode commented Dec 12, 2022

Ceimour commented Dec 12, 2022 via email

Ceimour commented Dec 12, 2022 via email

minacode commented Dec 13, 2022

Ceimour commented Dec 13, 2022 via email

Ceimour commented Dec 13, 2022 via email

FintasticMan commented Dec 13, 2022

minacode commented Dec 13, 2022

CCF100 commented Dec 19, 2022

minacode commented Dec 19, 2022 • edited Loading

yusufmte commented Dec 19, 2022 • edited Loading

minacode commented Dec 19, 2022

Avamander commented Dec 20, 2022

minacode commented Dec 20, 2022

yusufmte commented Dec 20, 2022 • edited Loading

yusufmte commented Dec 20, 2022

minacode commented Dec 20, 2022 • edited Loading

minacode commented Dec 21, 2022

yusufmte commented Dec 21, 2022 • edited Loading

minacode commented Dec 21, 2022

minacode commented Dec 31, 2022

yusufmte commented Jan 1, 2023 • edited Loading

minacode commented Sep 1, 2024

mark9064 commented Sep 1, 2024

minacode commented Sep 1, 2024

mark9064 commented Sep 1, 2024

mark9064 left a comment

Choose a reason for hiding this comment

mark9064 left a comment

Choose a reason for hiding this comment

yusufmte commented Dec 8, 2024 • edited Loading

jackdur commented Dec 9, 2024

minacode commented Dec 9, 2024

minacode commented Dec 8, 2022 •

edited

Loading

FintasticMan commented Dec 8, 2022 •

edited

Loading

FintasticMan commented Dec 9, 2022 •

edited

Loading

yusufmte commented Dec 11, 2022 •

edited

Loading

minacode commented Dec 19, 2022 •

edited

Loading

yusufmte commented Dec 19, 2022 •

edited

Loading

yusufmte commented Dec 20, 2022 •

edited

Loading

minacode commented Dec 20, 2022 •

edited

Loading

yusufmte commented Dec 21, 2022 •

edited

Loading

yusufmte commented Jan 1, 2023 •

edited

Loading

yusufmte commented Dec 8, 2024 •

edited

Loading