Hats. People Aren’t Wearing Enough Of Them.

Corri and her beau are leaving for very, very cold places this week. I delivered a hot pink caper hat to her earlier this week, and I’m finishing up a bowler-style stockinette for her finacé today. Pics later. Oops. I delivered the hats without photographing them. My bad.

I’ve also been revisiting the cable grapher lately. See, I lost one of of the cable pattern cards that I’d made before. Creating those cards by hand is what drove me to write the cable grapher in the first place. So now that I’ve got it, I figure I might as well use it. And if I’m going to use it, I might as well improve it.

(If you’re not a geek, you may want to skip this next part.)

One of the big problems with the cable grapher is that I wrote it in two main modules: a knitting pattern parser and a graph generator. This separation makes sense; after all, parsing “p2,c4b,p2” means figuring out that it says “purl two stitches, slip two stitches to a cable needle, hold the needle behind your work, knit two stitches, knit two stitches from the cable needle, purl two stitches”. It has absolutely nothing to do with drawing a graphical representation of the stitches. So parsing and graphing are two separate functional domains.

The problem is that there’s pretty much a one-to-one correspondance between cable stitches (like c4b, t4b, yo, k2tog) and their graphical representation. Each one of those cable stitches has a particular picture, and each picture only stands for one cable stitch. (When I say “cable stitch” here, I mean a group of stitches that can be represented by a single instruction, like c4b. Got it? Good.)

This means that in my program, I’ve defined a list of cable stitches in the parsing module and then a list of images in the graphing module. Each time I want to add a new stitch, I have to remember to add the correct instructions to both modules and I need to make sure I’m matching them up correctly. And this doesn’t even take into account the added complication of figuring out the wrong-side instructions for each cable stitch. This makes for an ugly pain in the butt.

So this weekend I thought about it and came up with a much better idea. I’m going to create an XML file of stitch definitions and write a Python parser that will read that file in and make it available to both the parser and the grapher. It’s going to look something like this:

Copyright © 2004, David Roth.
<cable_stitches>
    <stitch name="purl">
        <abbreviation>p</abbreviation>
        <length>1</length>
        <ws_row>k</ws_row>
        <graph>ellipse( ( x+left , y+top, x+span, y+span), BLACK )</graph>
    </stitch>
    <stitch name="knit">
        <abbreviation>k</abbreviation>
        <length>1</length>
        <ws_row>p</ws_row>
        <graph>None</graph>
    </stitch>
</cable_stitches>

Pretty, huh? What I’ve done here is define a knit and a purl stitch. Purl is abbreviated “p”, it’s one stitch wide, and the ‘graph’ part is the set of directions I feed into the image generator. They basically tell it to draw a black dot in the middle of the graph cell.

I think this is going to end up simplifying things

6 Responses to “Hats. People Aren’t Wearing Enough Of Them.”

  1. jm Says:

    How did your “XML file of stitch definitions” work out?

  2. Emma Says:

    I have no idea what you’re talking about,but I’m sure it’s great.
    Whatever it is !

  3. Lisa Says:

    Nice moving on, lil’ brother! Keep your needles and code-cracking fingers moving. Hugs and woofs!

  4. Mimi Says:

    Very, very interesting!! XML is so cool.

  5. Kaetchen Says:

    My head hurts. “Fire good. Tree pretty.”–Buffy

  6. Brent Says:

    That looks like an elegant solution to a thorny problem. Don’t you just love it when you come up with an idea that makes coding so much easier? Good luck in implementing it.