There is Progress! 
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).

By the way, KnitML got mentioned on Brenda Dayne's Cast On, Episode 57.

[ 1 comment ] ( 6 views )   |  [ 0 trackbacks ]   |  permalink
<repeat> vs. <repeat-instruction> 
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.
<instruction id="cuff-round">
<row type="round">
<repeat to-end="true">
<knit>1</knit>
<purl>1</purl>
</repeat>
</row>
</instruction>
<repeat-instruction idref="cuff-round">
<until-measures unit="inches">1.5</until-measures>
</repeat-instruction>


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

Round 1: *k1, p1*, repeat * to end
Repeat Round until piece measures 1.5 inches.

To implement a <repeat>, I can record the commands I send to the engine and simply play them back in a loop until 0 stitches remain in the row.

<repeat-instruction>, on the other hand, can have some intelligence inside of it. Therefore I cannot just blindly replay what I sent to the engine when I was recording this instruction.

Suppose that the KnitML instead looked like this:

<instruction id="cuff-round">
<row type="round">
<decrease type="k2tog"/>
<repeat to-before-end="2">
<knit>1</knit>
<purl>1</purl>
</repeat>
<decrease type="ssk"/>
</row>
</instruction>
<repeat-instruction idref="cuff-round">
<until-equals>
<stitch-count/>
<value>36</value>
</until-equals>
</repeat-instruction>


or
Round 1: k2tog, *k1, p1*, repeat * to 2 before end, ssk.
Repeat Round until 36 stitches remain.

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.

[ 1 comment ] ( 6 views )   |  [ 0 trackbacks ]   |  permalink
Recent Successes 
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?

[ 1 comment ] ( 6 views )   |  [ 0 trackbacks ]   |  permalink
Up and Ready to Blog 
So that I don't have to bore folks on my knitting blog about the progress of KnitML, Matt has graciously allowed me to run a blog off his web server. So Kudos to Matt for getting this off the ground!

More will be forthcoming as I start formalizing the KnitML Project.

[ 7 comments ] ( 132 views )   |  [ 0 trackbacks ]   |  permalink

<<First <Back | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |