test(ivc): test of folding W

[cyphersnake]

Part of #32
Test with NIFS & IVC folding of W

[cyphersnake]

@chaosma I decomposed TableData::assembly into three functions and the question arose as to why the prepare part is not part of new at all. I.e. what does the expected flow of usage TableData look like?

[chaosma]

what's the purpose to split fn assembly into 3 small functions? Especially, do we need a postpone method?

[cyphersnake]

I just haven't chosen the final design for using TableData in IVC yet, but it definitely won't be an assembly function, so I've summarised all the code that isn't about halo2::Circuit

[chaosma]

@chaosma I decomposed TableData::assembly into three functions and the question arose as to why the prepare part is not part of new at all. I.e. what does the expected flow of usage TableData look like?

good point. We can definitely move prepare part into the fn new. The reason why it is not in new: in the very beginning, my code doesn't have prepare part which causes error; then later the fix is into the assembly instead of new.

[cyphersnake]

@chaosma In that case, I'll mv prepare part to the new
What about postpone? What the idea of that part of code?

[cyphersnake]

@chaosma We still need the prepare_assembly function, because in fact the function should be called every time configure over cs is called

@cyphersnake Do you mean each time configure over cs, call prepare_assembly to reset the data inside TableData?
As for the postpone, I think it depending on whether it is necessary to separate from configuration in the design of IVC

[cyphersnake]

Added docs & decided not to touch TableData right now, but to work with it together with IVC & this place

What do you think?

[chaosma]

NBD: I usually will remove debug code after testing.

[cyphersnake]

This is not dbg! this is log::debug! expression. The lowest level of logs, even lower log::trace!

It's off on a real running system because of verbosity, but for debugging some cases it can stay on.

I left it here meaningfully

[cyphersnake]

This is just handy for projects under active development, to include the most detailed action log possible at any time, rather than adding debug messages every time.

Such more generalised code for debugging, which at the TRACE level and above does not give any overhead

[chaosma]

NBD: remove debug code after debugging

[cyphersnake]

@cyphersnake Do you mean each time configure over cs, call prepare_assembly to reset the data inside TableData?
As for the postpone, I think it depending on whether it is necessary to separate from configuration in the design of IVC

Now the real use case scenario is to call TableData::assembly around halo2::Circuit. However, the next step after testing the fold chip I will be testing the IVC itself. It will include the use of TableData and there it will be clear in what form we need it.

I can do well now and generalise the TableData API as much as possible, as another option is the possibility of multiple configurations and/or tracking the life stage of TableData (create -> configure -> assembly & only in this order), I'm just afraid it's redundant for our use-case

[chaosma]

@cyphersnake From our conversation, you decide not to touch the TableData code? In this case, are you planning to remove the prepare and postpone code?

[cyphersnake]

you decide not to touch the TableData code

@chaosma No, what is meant is not to finalize the design changes, but to leave the refactoring as it is already in use (I need the prepare function as the tests will break without it).

Alternatively, I can update the draft of the IVC API that uses TableData and get on with the final design right now. It's just that this will be ahead of debugging all the fold-chip tests