Issues with half rack (doesn't convert from 0.25 to 0.5, and knits needles individually in multiple passes)

[gabrielle-ohlson]

For knitout that conforms to the shima standard of 0.25 half rack, the kniterate backend doesn't convert it to 0.5 (which is what kniterate uses for half rack). I'm guessing this is probably a pretty easy issue to fix, so I can attempt to do so and commit it.

The issue that seems a bit more difficult is the passes that result from this quirk—in a knitout file that has a full needle rib pass (all working needles knitting on both beds at half-rack), the output k-code file splits it up to knit each needle individually in separate passes. Here are some snippets that demonstrate what's going on: (1) The input knitout pass: https://gist.github.com/gabrielle-ohlson/0c6ebf1337e884d13ebcf54d52232167#file-full-needle-rib-pass-k (2) What the backend outputs for k-code: https://gist.github.com/gabrielle-ohlson/0c6ebf1337e884d13ebcf54d52232167#file-backend-kcode-version-kc (3) What it should look like for k-code: https://gist.github.com/gabrielle-ohlson/0c6ebf1337e884d13ebcf54d52232167#file-correct-kcode-version-kc

So I guess this means it's the dreaded time to decide whether we keep the shima 0.25 half-rack or change it to 0.5 ...... I think it could be a good move to at least have the visualizer interpret 0.5 as a true half rack if the machine is specified as kniterate in the header [less urgent TODO], and then, since kniterate doesn't have a quarter (0.25) racking option, the backend could treat knitout rack 0.5 and rack 0.25 both as half rack (converting the later to RACK:0.5) [more urgent TODO].

[gabrielle-ohlson]

I changed if (frac != 0.0 && frac != 0.25) throw "ERROR: rackings must be an integer or an integer + 0.25"; (currently commented out) to if (frac != 0.0 && frac != 0.5) throw "ERROR: rackings must be an integer or an integer + 0.5"; & added some code that converts any quarter step racks to half step (+= 0.25). (see changes @ line 891 in most recent commit).

Not sure if this is the direction we want to take for dealing with 0.25 and 0.5 racks, but at least this allows proper representation in the visualizer for now. (Also, things seem fine, but not 100% sure if these changes might have thrown some of the earlier code @ixchow wrote off)

Solves issue of how the backend outputs the rack value in the k-code file, but issue of how the full needle rib pass is handled still remains.

[ixchow]

Looks like pass merging might be checking racking incorrectly -- looking into it.

Smaller test case:

in 5
rack 0.5

knit + f1 5
knit + b1 5
knit + f2 5
knit + b2 5
knit + f3 5
knit + b3 5
knit + f4 5
knit + b4 5
knit + f5 5
knit + b5 5
knit + f6 5
knit + b6 5
knit + f7 5
knit + b7 5
knit + f8 5
knit + b8 5
knit + f9 5
knit + b9 5
knit + f10 5

out 5

[ixchow]

The problem was that merge_ops wasn't properly handling cases with non-composite operations (e.g. it didn't handle OP_KNIT_FRONT, but it did handle OP_KNIT_FRONT_MISS_BACK). I've added the missing cases in c6f758a .