It’s a fair cop:

Miyako Messe in Kyoto hosts the Museum of Traditional Crafts. It’s small, fascinating, free, and quite expensive, because many modern examples of the various crafts are for sale. I ended up buying two Shingen-bukuro (Samurai Man-Purse), a handmade orin (the Japanese version of the popular “singing bowl”), a bottle of saké (that I should have bought more of; who knew matcha worked so well as a saké flavoring?), and an assortment of gifts. We’ll be visiting again in March.

One of the crafts on display was kumihimo, with some finished braids shown in their usual context as kimono ties, and some small sample braids next to illustrations of the equipment used to create them. There were two I’d never heard of, so I grabbed a quick pic with my phone and promptly forgot to look them up.

One was a special stand for making the Naiki-gumi (内記組) braid, with the appropriate name Naiki-dai. I know how to make that one on a marudai, so it was mostly of academic interest.

The other sample was called Chiyoda-gumi (千代田組), a loose chain-like structure that was more weave than braid, and the stand was an elaborate construct that looked vaguely like a warp-weighted rigid heddle loom that used kumihimo weighted bobbins for tension, called a Kago-uchi-dai (籠打台).

Last night I googled it, and the one non-BL result in English was a scanned PDF of a 1985 weaving journal article by Noémi Speiser, detailing her discovery of this device while working on her long-out-of-print book The Manual of Braiding, which, it turns out, just came back into print last November, and which includes instructions for the Naiki-dai (and, apparently, the Ayatakedai).

The text, pictures, and clear instructions in her article revealed that the Kago-uchi-dai is… a warp-weighted rigid heddle loom that uses kumihimo weighted bobbins for tension.

Well, alrighty then.

Coincidentally, a few months back, I got the idea of setting my card loom up vertically so I could use kumihimo bobbins to provide tension and allow the strands to freely untwist; I’ve been too busy to try it, but it seemed like it would work well, and now I know it will. 😁

Oh, and the kagouchi braid? Speiser identified the structure as identical to #2918 in The Ashley Book of Knots, and speculated that the rounded version the artisans told her about but didn’t show was likely #2919.

Is there a bag limit on Antifa? Asking for a friend.

If she’s good for a gander, she’s good for a goose.

more...

In which Bell discovers Orario’s red-light district and a princess in need of rescuing, and Hermes gets more than he bargained for. And I don’t mean rubber ducks.

(this week’s new character in the game turns out to be Ishtar; perhaps they won’t add Haruhime until her power is revealed in an upcoming episode)

This is actually a bit disturbing…

The Happy Fan:

The Miller data-manipulation tool has a lot of potential, but the organic development process has left it with a lot of rough edges.

My first hint that all was not well internally was when I was hacking on PDQ output and realized that I had to type nest --implode --values --across-records --nested-fs space to get what I wanted. The manpage includes a shortcut for the nest verb’s other mode, so that --explode --values --across-records --nested-fs can be replaced with --evar, but there’s no matching --ivar. So I forked the project, added it, and sent a pull request.

The functionality was trivial, but the single-line usage description had to be added five times. That sent up a little red flag.

Still, it was easy to do, so I thought I’d see if it was feasible to fix one of the other things that bugs me, which is the lack of quoting and/or escape characters in its native DKVP file format (delimited key-value pairs, aka foo=1,bar=2,baz=3).

The answer turns out to be “not easily”, and I quickly learned some unpleasant things about how it handles other data-format conversions.

Given the perfectly-ordinary CSV input file foo.csv containing:

a,b,c,d,e
"1,1","2
2","3","4\r4","5\n5"

I get the following results:

# DKVP: useless as expected
% mlr --icsv cat foo.csv
a=1,1,b=2
2,c=3,d=4\r4,e=5\n5

# (note: internally, fields have correct values)
% mlr --icsv --ojson cut -f a,b foo.csv
{ "a": "1,1", "b": "2\n2" }

# CSV: reasonable, but strings converted to ints
% mlr --csv cat foo.csv
a,b,c,d,e
"1,1","2
2",3,4\r4,5\n5

# Quoted CSV: better, but should be default
% mlr --csv --quote-original cat foo.csv
a,b,c,d,e
"1,1","2
2","3","4\r4","5\n5"

# JSON: reasonable, but strings converted to ints
% mlr --icsv --ojson  cat foo.csv 
{ "a": "1,1", "b": "2\n2", "c": 3, "d": "4\\r4", "e": "5\\n5" }

# Quoted JSON: oh, hell no
% mlr --icsv --ojson --jvquoteall cat foo.csv 
{ "a": "1,1", "b": "2
2", "c": "3", "d": "4\r4", "e": "5\n5" }

Note that the automated num-ification has real consequences for data processing, since you can’t do things like regex matches or string-substitutions on a number type, and have to explicitly coerce fields back to strings; the error message for this is less than clear. Also, leading zeroes trigger octal conversion…

So that’s an enhancement request for escaping comma, cr, and lf in DKVP, plus a bug on the busted output when you add the --jvquoteall option to avoid the num-ification of string literals. (and it bothers me that I had to explain the bug in a completely different way because one of the devs didn’t understand my sample CSV file…)

I see a massive refactoring in its future (“cover a wall with color-coded sticky notes, then break out the chainsaws and forklifts”). Oh, well, useful tool when used with care.