Ironing out the corner cases on the engine has been a very involved process. It takes a lot of work to make the engine a real-world simulator. If you can't do it in real life, you should not be able to do it with the engine!

I think I'm definitely close now, though I haven't even had a chance to start on the renderer. Fortunately, the structure is all in place, and it should be a fairly straightforward matter of firing off messages to a file or screen.

Subversion is supposed to be installed on this server fairly soon. As soon as that happens, I will upload my project so that you can see where I am (and make recommendations, if you like).

I was asking myself the other day why I included two different ways to indicate a repeat. One is <repeat> and the other is <repeat-instruction>. I realized that it was something instinctive, and today I think I figured out why I did this.

Let me illustrate with a bit of KnitML which describes working 1-by-1 ribbing for 1.5 inches of a sock cuff.

<repeat> here indicates a literal repeat of atomic knitting steps (i.e. knit and purl) with no intelligence inside of the <repeat> block. This type of repetition is often represented by *s in a pattern, such as:

Granted, this isn't what I'd call a cuff, unless you have really conical legs! This is, however, reminiscent of knitting a sweater sleeve, which is a situation I will find myself in eventually.

Capturing this with a simple "record and playback" mechanism won't work, simply because the decreases are constantly changing what needs to be done for a particular row. On Round 1, I would repeat k1,p1 34 times. On the next round, however, I would only repeat it 33 times. A "record and playback" mechanism would attempt to repeat it 34 times, and the engine would subsequently complain that there weren't enough stitches left in the row.

In summary, what lies beneath <repeat> is Igor-like ("Knit, purl... repeat that until I tell you to stop." "Yes, master!") <repeat-instruction> takes some evaluation.

Well, I am making progress. Just ask my wife who knows that I stayed up way too late last night working on a programming problem I was having.

The knitting engine itself is pretty much fully functional and has a robust set of tests which validate its behavior. I'm now starting to build the PatternDraw functionality as well as some of the other things that need to be written while driving through a pattern. One such thing is a recording mechanism for the knitting engine. It essentially monitors external calls into the engine and records the sequence of those calls. In KnitML, an instruction can be tagged with an identifier so that you can refer to it later in the pattern if you want to issue a repeat, so this feature is very important to the health of a KnitML interpreter.

In order to implement this in the engine, I had to develop a way to record the actions I perform on the engine. The best way to do this is with some sort of AOP advice to the engine itself. I'm familiar with Spring AOP (i.e. the proxy-target style of AOP), but I wanted to dabble with AspectJ. Unfortunately, this has caused me more headaches than it's been worth. AspectJ is actually too good at what it does and I can't figure out how to tell it how to only record a top-level method call into the engine using only a pointcut. I've settled on incrementing / decrementing a depth counter with branching logic in the advice, which actually works pretty well. Ideally, though, sub-calls to methods shouldn't even be selected by the pointcut. Are there any AspectJ experts out there?