feat(sozo): in build stats add bytecode and class size of casm class

[itzlambda]

fix: #1952

• add stats of casm class
• sort table by contract name

[codecov]

Codecov Report

Attention: Patch coverage is 93.43066% with 9 lines in your changes are missing coverage. Please review.

Project coverage is 67.54%. Comparing base (6153192) to head (2d2e189).
Report is 1 commits behind head on main.

Files	Patch %	Lines
crates/sozo/ops/src/statistics.rs	88.46%	9 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2004      +/-   ##
==========================================
+ Coverage   67.50%   67.54%   +0.03%     
==========================================
  Files         318      318              
  Lines       37880    37979      +99     
==========================================
+ Hits        25572    25654      +82     
- Misses      12308    12325      +17     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[glihm]

thanks @lambda-0x for those fixes! It will be great to have those numbers and also see how the Sierra / casm sizes are evolving.

Some minor comment, but overall it looks great.

[glihm]

Those one are not usually present in a dojo project, but good to keep this in case. 👍

[itzlambda]

it would cause issue when someone adds sierra = true or casm = true in manifest file manually for any reason, which i did for testing file size of casm class.

[glihm]

There isn't a way to factorize how the byte size of a file is computed? (for Sierra and casm)

[itzlambda]

fixed

[kariy]

hmm the table takes a considerable amount of screen real estate to display it without wrapping.

what do you think about compressing the table somehow? like deferring the units in the help message? or if the table lib that we're using can somehow do the header row like so:

+-------------+
|     Col1    |
+-------------+
| Col1 | Col2 |
+------+------+
|    1 |    2 |
|    3 |    4 |
+------+------+

[glihm]

hmm the table takes a considerable amount of screen real estate to display it without wrapping.

what do you think about compressing the table somehow? like deferring the units in the help message? or if the table lib that we're using can somehow do the header row like so:

+-------------+
|     Col1    |
+-------------+
| Col1 | Col2 |
+------+------+
|    1 |    2 |
|    3 |    4 |
+------+------+

Good idea, could help to have more concise report. We could have an introductory message before the table to add enough context for users to understand the table and get used to it.

[itzlambda]

hmm the table takes a considerable amount of screen real estate to display it without wrapping.

what do you think about compressing the table somehow? like deferring the units in the help message? or if the table lib that we're using can somehow do the header row like so:

+-------------+
|     Col1    |
+-------------+
| Col1 | Col2 |
+------+------+
|    1 |    2 |
|    3 |    4 |
+------+------+

the library we are using doesn't support it atm, see: phsym/prettytable-rs#91

wdyt about something like:

[kariy]

hmm the table takes a considerable amount of screen real estate to display it without wrapping.
what do you think about compressing the table somehow? like deferring the units in the help message? or if the table lib that we're using can somehow do the header row like so:

+-------------+
|     Col1    |
+-------------+
| Col1 | Col2 |
+------+------+
|    1 |    2 |
|    3 |    4 |
+------+------+

the library we are using doesn't support it atm, see: phsym/prettytable-rs#91

wdyt about something like:

Not bad, but i think should remove the parentheses in the non-header cells.

We could have an introductory message before the table to add enough context for users to understand the table and get used to it.

yeah i think looking at it from the perspective of user that haven't seen the starknet docs, Bytecode size [felts] doesn't exactly explain what unit is felts and what the value it's based on. maybe worth putting some extra messages either embedded in the CLI help message, or displayed along with the table itself.

[glihm]

Works for me for this iteration after addressing the changes. A little detail is that we don't have good alignment with bigger numbers.

But it still more compact than before, that's for sure. :)

[glihm]

Let's go for the first iteration, nice @lambda-0x!