CalChart's new Viewer File exporter

[kmdurand]

The CalChart Online Viewer has been held back a little by the way that CalChart has been exporting viewer files. I'm updating CalChart in a couple ways right now that should improve things on the viewer side:

1. CalChart will now support "stand" commands, instead of just making everyone mark time
2. "Even" commands will only be used when Stunt intentionally specifies even-step movements; that means that all regular movements will be broken down into "move" commands for the viewer, instead of "even" commands

The main change that this will cause for the viewer, as far as I can tell, is the way that PDFs are generated. Correct me if I'm wrong, but I believe that the viewer currently looks at each even step command and convert it to a move command if the step size is right; that won't be necessary anymore, since all non-even step movements will be provided explicitly.

[kmdurand]

I think the easiest way to fix this up is to just prevent the viewer from predicting which "even" commands should be "move" commands, and then to re-export all of the old 2014 shows for the server so that they no longer rely on that feature of the viewer.

[brandonchinn178]

I think it's fine to keep as it is, just for future error-proofing reasons. What if STUNT mislabels a step type? It's fine, because we have catching for those situations. After all, it's not like the unnecessary code will make anything wrong, it's just a bit more code we can keep in there.

[noahsark769]

"Unnecessary code is ALWAYS a problem" - Mark Twain

Brandon I disagree about this, I think we should definitely render the PDF
based on what the format says rather than based on what the viewer thinks:
that would break the entire abstraction. I don't think we need to over
correct for STUNT charting a type wrong, and on the contrary I think we
should always do whatever STUNT wants, whether it doesn't make sense or
not, because at least then STUNT will be able to triage any issues
themselves.

The reason why projects get bloated and not maintainable is because we
leave in code that doesn't make sense just for fun :)

What do you think?
On Thu, Feb 5, 2015 at 3:29 PM Brandon Chinn [email protected]
wrote:

I think it's fine to keep as it is, just for future error-proofing
reasons. What if STUNT mislabels a step type? It's fine, because we have
catching for those situations. After all, it's not like the unnecessary
code will make anything wrong, it's just a bit more code we can keep in
there.

—
Reply to this email directly or view it on GitHub
#161 (comment)
.

[brandonchinn178]

Yea, sure, sounds fine. I just assumed you would prefer the catching just-in-case

[noahsark769]

Nope nope, with cal band code you gotta choose maintainability every time
On Thu, Feb 5, 2015 at 5:11 PM Brandon Chinn [email protected]
wrote:

Yea, sure, sounds fine. I just assumed you would prefer the catching
just-in-case

—
Reply to this email directly or view it on GitHub
#161 (comment)
.

[brandonchinn178]

@kmdurand let me know when you fix calchart so i can fix the code

[kmdurand]

Yup, I'll let you know

[brandonchinn178]

@kmdurand status on this?

[kmdurand]

Lol haven't worked on this a ton. I'll try to check it out in the next few days and see what kind of time I'd need for this

[brandonchinn178]

maybe migrate to letting @dpgrubb13 and @belinda-liu work on this?

[kmdurand]

If they'd like to! @dpgrubb13 @belinda-liu What do you think?

[rmpowell77]

I've just added Close to CalChart with 3.7.1. Using this to add the close to CalChart Viewer.