This is What Happens When You Stuff Things Into Boxes Blindfolded

Imagine working for the packing department of a Rubik’s Cube factory. The kind of rubik’s cube you make has the colors painted on, so there are no stickers to peel, and is constructed in such a way that it’s really, really hard to get your fingernails in between the pieces (to prevent the irksome child from taking it apart and reassembling it solved). They also come in a very tight plastic, opaque cube cover, made from the leftover bits of plastic during the cube-making process (it’s a green company).

Your job is to put these cubes into the boxes. When sold from the factory’s own store, they come with the cover on. However, when shipped to other places, you (for some reason) need to remove these black cube covers. If you leave the covers on, the guy on the receiving end has to spend 1 extra unit of time taking the rubik’s cube out of the cover, which may not have been given to him. In that case, the unpacking guy at the other end of the delivery has to give up just before being done (having unexpectedly wasted one precious unit of time on a cover that wasn’t supposed to be there), and the company Unpacking Guy works for falls apart, and gets angry at the Rubik’s cube factory.

Now imagine you have to put these cubes in the packing boxes (the boxes that get all those stickers and barcodes on them) blindfolded. You can’t feel the difference between a covered and uncovered cube (no space inbetween the spaces to feel, no stickers to get your fingernails caught on). You were never told that these cubes came to you in covers, you only ever saw the uncovered cube. Until you take off your blindfold, (which is difficult because of a, lock, or something) you won’t see the problem.

Today I took off my blindfold, using some round tuits to break the lock-thing.

Here is what I’ve been having trouble with: the fact that only one Pod6 block parses before quitting.

I found out that it’s not an issue with parsing >1 block, but rather an issue with paragraph and abbreviated blocks. I need three newlines at the end of a block (\n\n\n, which would translate to two blank lines, the first \n being at the end of the last nonblank line). A quick check doing s/<delimend>/<blankline>/ in the delimited block confirmed the problem was with <blankline>. When I found out nothing was wrong with that, I turned to its other half, <content>.

regex blankline {^^ \h* $$ \n}
regex content {^^ [<-directive>&&<-blankline>]+ $$ \n}

At one point it hit me. <directive> and <blankline> both match entire lines (/^^ stuff $$/). No wonder I needed two blank lines! So I got rid of the ^^ and $$\n in <content>, and now this happens:


> SEKRIT.parse("=begin head1\nHAI\n=end head1\n=for head1\nDERE\n\n=head1\nHELLO\n", :rule<document>)
=begin head1
HAI
=end head1
=for head1
DERE


The abbreviated block only needs a blank line after it (which means \n\n), which is a problem that I’ll have to resolve by matching to EOF (if there was only a way to do that!) as an alternative to a newline. Maybe there’s a way to fake it, like I did in <delimend> (the \n? part).

Ah well, I guess the lesson here is to make sure you aren’t matching entire lines multiple times like I did (using the story at the beginning, I guess it’s make sure you don’t cover your cubes more than necessary(?) Ah well. With practice, I’m sure I’ll get better at writing these kinds of stories.)

Advertisements
This entry was posted in Progress Happened and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s