You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would it be conceivable to make ssz-size / ssz-max accept variable names that would get inserted in the generated code, instead of hardcoded values?
The idea behind this is that the Ethereum spec comes with configurable variables, and it's currently impossible (or at least quite complicated and repetitive) to write code that can be compatible with multiple presets at the same time.
For example, I'd like to be able to write something like this:
And it would then generate the file with MAX_WITHDRAWALS_PER_PAYLOAD in place of the hardcoded 16, as well as import the config package (although that might already be doable automatically?).
I'm guessing this could introduce some overhead in cases where calculations are required for buffer indexes etc, but for extremely high performance apps it would still be possible to use the current way.
The text was updated successfully, but these errors were encountered:
Hello! Thank you for the proposal.
This is not something I am planning to do in the short term. Unfortunately, the changes in the code generator to support this feature are not trivial to do.
Hi,
Would it be conceivable to make
ssz-size
/ssz-max
accept variable names that would get inserted in the generated code, instead of hardcoded values?The idea behind this is that the Ethereum spec comes with configurable variables, and it's currently impossible (or at least quite complicated and repetitive) to write code that can be compatible with multiple presets at the same time.
For example, I'd like to be able to write something like this:
And it would then generate the file with
MAX_WITHDRAWALS_PER_PAYLOAD
in place of the hardcoded16
, as well as import theconfig
package (although that might already be doable automatically?).I'm guessing this could introduce some overhead in cases where calculations are required for buffer indexes etc, but for extremely high performance apps it would still be possible to use the current way.
The text was updated successfully, but these errors were encountered: