can I take this?

This exercise is a bit different than the others - the idea is to give students a working, but complex solution, and have them refactor it to make it as simple as possible.

This last sentence from the exercise instructions:

Please keep a log of what changes you've made and make a comment on the exercise containing that log, this will help reviewers.

applies to this issue's PR as well, i.e. the PR you create should contain a description/comment explaining what changes you made to the complex solution (lib.cairo) to make it simpler (example.cairo). We will use this as a good example of a refactor to show students who might ask their mentors to review their work.

Let me know if anything is unclear or if you need help!

Alright, I will look into it properly and get back if I have any question. Thanks

Hi @0xNeshi, the € symbol is not an ascii character so I am replacing it with eur. I do not know if that is accepted or if you can help with an implementation that can help print the symbol nicely.

And also I have the passing code in a messy and complex manner, do not know if it will be acceptable and the ledger is printed in the order in which it is being passed in the arguement and not ordered by the date of the transaction.

Since Cairo only supports ASCII chars, so must we in this exercise. Let's use the lowercase letter e instead of €, to keep currency lengths consistent, and to avoid formatting complications in the implementation. Just make sure to add a short instructions.append.md file that explains why we made this change in our exercise.

And also I have the passing code in a messy and complex manner, do not know if it will be acceptable and the ledger is printed in the order in which it is being passed in the argument and not ordered by the date of the transaction.

The most important thing is for the test cases from canonical data to pass with the exact inputs and outputs (or as close to exact as possible, in our case using e instead of €). Only after that do we worry about the "cleanliness" and readability of the implementation. So feel free to do it the "messy" way 👍

In the canonical.json test 4 have the same slug as the last test, but looking at their cases they are not the same, the test 4 tested for transactions on different dates while the other tested for transactions on the same date.

Even thou the last test has an additional comment in the test.toml file stating it is reimplementing test 4. I still feel it is not and the name for the test 4 should be changed to multiple_entries_on_different_date_ordered_by_description instead of multiple_entries_on_same_date_ordered_by_description.

cairo won't let me declare more than one test with the same name, so I had to change the test 4 to the name I suggested above.

what do you think?

A test marked as reimplementing another one is intended to replace it completely in the test suite. I wouldn’t expect both to be present so having the same name shouldn’t occur.

Okay well noted, I can see now that the number 4 has the include = false comment. so it safe to remove it from my test cases.
Thank you very much.