@barter-simsum would you mind providing an approval if this looks good?

Are there any potential risks with this that you foresee?

Everything else lgtm, mostly nits

Made changes and pushed them up

Also, I just realized that --jamkhan is a misnomer, because it has nothing to do with the Khan vane. What it's doing is creating a newt encoded jammed noun; beyond that, the noun could be used for multiple purposes, even by conn.c.

For example, the [1 %urth %meld] from the description is a command to Vere.

@mopfel-winrux What's the use of the --jam option (i.e. who/where needs jammed nouns encoded as hex-strings)? It seems to be consensus that the thin waist of Urbit should be newt-encoded jammed nouns.

@ashelkovnykov --jamkhan was the name Joe and I came up with while working on this. I can change it to whatever you'd like.

For example, the [1 %urth %meld] from the description is a command to Vere.

Can you elaborate on this? Doesn't the command still goes to khan and then back to Vere?

The idea of just using --jam and outputting as hex-strings was to use the utility to test out hoon scripts and be able to copy and paste something readable. Again part of my discussion with Joe about this. I'm fine removing it if people feel its necessary.

@ashelkovnykov --jamkhan was the name Joe and I came up with while working on this. I can change it to whatever you'd like.

@joemfb want to weigh in here?

I would remove --jam and rename --jamkhan to --jam. I'd also try to replace the logic in _cw_eval that replicates newt encoding with u3_newt_send. Both of these changes can be done in later commits, if merging this is a priority.

#197 (comment) has some good context from @ashelkovnykov.

The noun is the exclusive, universal data type of urbit. Jam is universal noun serialization. And the "newt" wire-framing is how we pass around those serialized nouns in a streaming context. Everything in urbit is a noun, +jam is used anytime we want to convert an arbitrary noun to an atom or a byte buffer (nouns are often imported/exported/distributed as "jamfiles"), "newt" is used for all our IPC. The first two will most likely never change, the third is much more contingent (shared-memory IPC is probably the future for mars/urth).

The --jam option is useful if you need a lightweight way to generate a jammed noun, or if you're implementing +jam, +cue, or a new interpreter, or if you're moving nouns between nock interpreters, or if you just want to poke around with implementation details. I don't have an immediate operational use-case for it -- it's just obvious and low-cost.

We'll want to have a +cue command as well, maybe taking a hoon mold as text to control pretty-printing. And a version that can also cope with "newt" wire-framing, for handling responses from conn.

The naming of %khan/conn remains a sore spot and source of confusion -- the relationship between them is quite minimal. The most technically correct names for these arguments would be --jam/-j and --jam-newt (or --jam --newt/-jn). Which isn't to say that they're good. I'm not sure what would be ...