Move ops into their own files, introduce new state structures #43
Conversation
also introduce copy_command and copy_sub_command
split the algorithm code from the module code update libavr32 use a single .clang-format and .editorconfig move the format target to the root Makefile
| @@ -131,13 +127,13 @@ int16_t output, output_new; | |||
| #define FIRSTRUN_KEY 0x22 | |||
|
|
|||
| typedef const struct { | |||
| tele_script_t script[10]; | |||
| tele_pattern_t patterns[4]; | |||
| scene_script_t script[10]; | |||
scanner-darkly
Jun 10, 2016
Member
curious about the name change - scene_script_t is still a single script, right? 'scene' here seems to be more appropriate for the variable name (an array of scripts for a scene) than the type itself.
also thinking might be good to rename script to scripts to keep it consistent with patterns. this is a minor thing though, as is the above.
curious about the name change - scene_script_t is still a single script, right? 'scene' here seems to be more appropriate for the variable name (an array of scripts for a scene) than the type itself.
also thinking might be good to rename script to scripts to keep it consistent with patterns. this is a minor thing though, as is the above.
samdoshi
Jun 10, 2016
Author
Collaborator
See state.h, that's where the actual scene types are defined. This is just for saving data to and from nvram. I haven't paid much attention to it, but it probably should be renamed to scripts.
Putting scene at the front is an attempt at namespacing. I've renamed tele_pattern_t to scene_pattern_t too.
See state.h, that's where the actual scene types are defined. This is just for saving data to and from nvram. I haven't paid much attention to it, but it probably should be renamed to scripts.
Putting scene at the front is an attempt at namespacing. I've renamed tele_pattern_t to scene_pattern_t too.
scanner-darkly
Jun 10, 2016
Member
yeah as namespacing i think it's a good thing. the only concern would be if for whatever reason scripts and patters as entities could live outside of scenes, but perhaps that would be a different type altogether.
yeah as namespacing i think it's a good thing. the only concern would be if for whatever reason scripts and patters as entities could live outside of scenes, but perhaps that would be a different type altogether.
|
|
||
| for (i = 2; i < 8; i++) { | ||
| for (size_t i = 2; i < 8; i++) { |
scanner-darkly
Jun 10, 2016
Member
was going to ask why size_t is a better choice here (and in other loops) but then realized that it makes perfect sense! 👍
was going to ask why size_t is a better choice here (and in other loops) but then realized that it makes perfect sense!
| if (v < 32766) { | ||
| tele_set_pattern_val(edit_pattern, | ||
| edit_index + offset_index, | ||
| v++); |
scanner-darkly
Jun 10, 2016
•
Member
something like tele_inc_pattern_val could be a good function to have as it'll make it more readable and will keep the magic number in the place where all pattern related things are. i can add it once this is merged.
something like tele_inc_pattern_val could be a good function to have as it'll make it more readable and will keep the magic number in the place where all pattern related things are. i can add it once this is merged.
samdoshi
Jun 10, 2016
Author
Collaborator
Good idea. One of the things I've been (slowly) trying to do is keep like minded code together. It definitely helps spot patterns and code reductions.
Good idea. One of the things I've been (slowly) trying to do is keep like minded code together. It definitely helps spot patterns and code reductions.
| if (v > -32767) { | ||
| tele_set_pattern_val(edit_pattern, | ||
| edit_index + offset_index, | ||
| v--); |
scanner-darkly
Jun 10, 2016
Member
similar to above, would be good to have tele_dec_pattern_val
similar to above, would be good to have tele_dec_pattern_val
| tele_set_script_l( | ||
| edit, | ||
| tele_get_script_l(edit) + | ||
| 1); |
scanner-darkly
Jun 10, 2016
•
Member
same as above, could possibly be tele_inc_script_l
... have to stop here, will continue tomorrow.
same as above, could possibly be tele_inc_script_l
... have to stop here, will continue tomorrow.
samdoshi
Jun 10, 2016
Author
Collaborator
Yes, I almost did this myself.
But... it might be worth doing things like tele_script_insert first. We might find that once they're in place there is no need for a tele_inc_script_l. On the other hand doing tele_inc_script_l first might make it easier to understand whats going on...
Yes, I almost did this myself.
But... it might be worth doing things like tele_script_insert first. We might find that once they're in place there is no need for a tele_inc_script_l. On the other hand doing tele_inc_script_l first might make it easier to understand whats going on...
scanner-darkly
Jun 10, 2016
Member
i could make this and similar changes once this is merged, assuming @tehn is okay with the change - i think it would be nice to encapsulate all script related functionality in one file eventually (same for patterns)
i could make this and similar changes once this is merged, assuming @tehn is okay with the change - i think it would be nice to encapsulate all script related functionality in one file eventually (same for patterns)
|
thank you for your patience-- that was a lot to review! i am incredibly grateful for this confounding level of improvement to the codebase. i learned a few tricks, and got the chance to repeatedly meditate on my development process-- how i was adding features and hacking them in without standing back to assess the overall system. this is a fantastic refactoring. thank you again. i look forward to extending new functionality with this as a model. |
| tele_patterns[edit_pattern].l < 64) { | ||
| tele_patterns[edit_pattern].l++; | ||
| uint16_t l = tele_get_pattern_l(edit_pattern); | ||
| if (edit_index + offset_index == l && l < 64) { |
scanner-darkly
Jun 11, 2016
Member
should this be l < 63?
should this be l < 63?
scanner-darkly
Jun 11, 2016
Member
(actually, this PR is probably not a good place, will move this to main repo instead and only post PR specific questions here)
(actually, this PR is probably not a good place, will move this to main repo instead and only post PR specific questions here)
|
i have even more appreciation for your monumental refactoring now - tried to diligently review all the changes but it's just not possible [i did review all of the changes in |
See http://llllllll.co/t/teletype-refactoring-ideas/2836/90?u=sam