GitLab

Absence of this is an oversight, and I just happened to catch it while
passing through the vicinity.

Also: dropped a comment for later review on the bytesprefix strategy.
While adding the stringprefix strategy, it's hard not to notice that
variable length strings are allowed; so, it occurs to me we should
probably do the same for byteprefix.  (Also, possibly renaming it to
byte*s*prefix.)  Doing this would also fix the ancient weirdness of
the map being flipped in an awkward way to evade int keys, which is
a very happy coincidence (and in retrospect, I'm not sure why we didn't
think of this solution earlier).

The capitalization on this has varied a bit over time.
It's been tempting to capitalize these things because they're clearly
two english words.  However, I'm taking the line that they're a single
word that just happens to have been derived from two english words,
and such a neologism does not retain mid-word capitalization.

(I'm looking at this right now because I'm attempting to write some new
code around the schema-schema outputs, and so I want any dissonance and
inconsistency gone from the start in this new code.)

No suprise this is needed; just filling in the gaps.

No surprise this is needed; just filling in the gaps.

This requires introducing an error-carrying NodeAssembler,
because the AssembleValue methods don't have the ability to return errors themselves.

AssembleValue methods have not needed to return errors before!
Most lists don't have any reason to error: out of our whole system,
it's only struct-with-tuple-representation that can have errors here,
due to tuples having length limits.
AssembleValue for maps doesn't have a similar challenge either,
because key invalidity can always be indicated by errors returned from
the key assembly process.

I'm not a big fan of this diff -- error carrying thunks like this are
ugly to write and they're also pretty ugly to use -- but I'm not sure
what would be better.  ListAssembler.AssembleValue returning an error?
Turning ListAssembler into a two phase thing, e.g. with an Advance
method that fills some of the same role as AssembleKey does for maps,
and gives us a place to return errors?

Codegen for links should emit the methods to conform to the schema.TypedLinkNode interface where applicable.

Should fix https://github.com/ipld/go-ipld-prime/issues/90 .

They do quite a lot of work, including setting up a type system,
generating Go code, and building it.

This package is by far the slowest to test. On a warm cache, 'go test
-count=1 ./...' shows all packages under 0.2s, while this one sits at
~1.5s.

1.5s is not unreasonable with a warm cache, but we can bring that down
to 0.6s on my quad-core laptop by just making all tests parallel. Note
that sub-tests aren't parallel for now, since there are multiple layers
of them and I'm not sure I even follow what's going on.

Mac is also disabled for the time being, since it seems to time out too
often.

Buffers are not a good option for tests if the other side expects a
reader. Otherwise, the code being tested could build assumptions around
the reader stream being a single contiguous chunk of bytes, such as:

	_ = r.(*bytes.Buffer).Bytes()

This kind of hack might seem unlikely, but it's an easy mistake to make,
especially with APIs like fmt which automatically call String methods.

With bytes.Reader and strings.Reader, the types are much more
restricted, so the tests need to be more faithful.

Align several more bits of schema-schema json with the drifts made by the programatic type construction.

The gap between these isn't within the reach of this test to probe.
(Yet.  We'll get there.  It's not terribly much further.)

This is a somewhat altered schema-schema document, as commented.
Some of those alterations might get upstreamed; I'll be making other
PRs to the upstream specs repo to discuss that.

- it now uses kinded unions (since those are supported now; they
  weren't yet the last time we touched this demo!).

- a few typos are fixed (field names; in one case, a place that must
  support type names as well as inline defns).

- added the 'Schema' type at the very top!  this is what parsing the
  schema-schema starts with!

This is probably now one of the nicer (directly-exercised) examples we
have for how the type-level and representation-level views of data can
differ with the use of schemas.

Interesting to note that this causes the go-wish library to drop out of
the imports list entirely.

The increased coverage found an infinite loop in iterators, so the
fix for this is included in this commit.

Though in general, letting golang's test system replace spaces and
other unusual characters with underscores has very little downside,
here, the resulting "_--_" is quite unpleasant on the eyes.

Change things to use TitleCase.

This new system focuses on table-driven tests, and leans heavily upon
json as a shorthand for expressing fixtures.

It also makes a great deal more effort to exercise the different
features of nodes (and their paired representation nodes) from all
directions at once for each test datum, rather than requring that all
be written out manually.

The result is that the struct tests we've renovated have a lovely
diffstat shrinkage: 111 insertions, 299 deletions...

And yet the smaller line count results in *more* coverage.

(Okay, the linecount increase for the testcase structure and helper
methods is much bigger than the savings in fixture size... but,
only *so far*.  I assume this will continue to pay off in the future.)

Relatedly: a bug in struct map representations has been fixed.
(It was the sibling of 5f589653, embarassingly.)  Thank goodness we now
get proper coverage of this area.

There's a few TODOs left to further expand the exercises, but those
can slot in easily in subsequent commits.  Same goes for further
expansion of usage of this new system.

(This type isn't really "embedded" in the others directly, so those
docs were somewhat confusing.)

(This should've been committed earlier.  I have too much WIP standing
uncommitted in my working tree.  Ow.  Mea cupla.)

The AssignNode method is now supplied; and the previous hacky shrug
regarding switch statements with no applicable cases also had to go.
(Turns out that the no-applicable-cases thing coincidentally worked
for the "embedall" internal implementation mode; but didn't fly for
the "interface" internal style, because that would end up with
variable declarations made but not referenced.  Harrumph.)

This template munging business got nastier as time proceded.
I think we could drastically reduce the amount of redundancy in the
arugments to `kindedUnionNodeMethodTemplateMunge` if we re-did that
function with a more structural understanding of what's going on,
and made some basic understanding of what zero values are per golang
type, etc.

That can be future work, though.  Today, I want working kinded unions,
and I just want them done enough to use; kludge tolerance high.

So far, the generation itself runs, but the result will not yet compile.
I just want a checkpoint here.  (Most of this was written a few days ago already.)

This will become relevant when we have structs with tuple representation!