Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move ops into their own files, introduce new state structures #43

Merged
merged 45 commits into from Jun 11, 2016

Conversation

@samdoshi
Copy link
Collaborator

@samdoshi samdoshi commented Jun 7, 2016

samdoshi added 30 commits Apr 29, 2016
also introduce copy_command and copy_sub_command
@@ -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];

This comment has been minimized.

@scanner-darkly

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.

This comment has been minimized.

@samdoshi

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.

This comment has been minimized.

@scanner-darkly

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.


for (i = 2; i < 8; i++) {
for (size_t i = 2; i < 8; i++) {

This comment has been minimized.

@scanner-darkly

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! 👍

if (v < 32766) {
tele_set_pattern_val(edit_pattern,
edit_index + offset_index,
v++);

This comment has been minimized.

@scanner-darkly

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.

This comment has been minimized.

@samdoshi

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.

if (v > -32767) {
tele_set_pattern_val(edit_pattern,
edit_index + offset_index,
v--);

This comment has been minimized.

@scanner-darkly

scanner-darkly Jun 10, 2016
Member

similar to above, would be good to have tele_dec_pattern_val

tele_set_script_l(
edit,
tele_get_script_l(edit) +
1);

This comment has been minimized.

@scanner-darkly

scanner-darkly Jun 10, 2016
Member

same as above, could possibly be tele_inc_script_l

... have to stop here, will continue tomorrow.

This comment has been minimized.

@samdoshi

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...

This comment has been minimized.

@scanner-darkly

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)

@tehn tehn merged commit d7d21ef into monome:master Jun 11, 2016
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@tehn
Copy link
Member

@tehn tehn commented Jun 11, 2016

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) {

This comment has been minimized.

@scanner-darkly

scanner-darkly Jun 11, 2016
Member

should this be l < 63?

This comment has been minimized.

@scanner-darkly

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)

@scanner-darkly
Copy link
Member

@scanner-darkly scanner-darkly commented Jun 15, 2016

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 main.c at least, everything looks good], best to just dive in and work on some of the issues, which should be easier now because of this. thanks again for tackling this!

@samdoshi samdoshi deleted the samdoshi:dev branch Nov 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants