1. 09 Jun, 2021 1 commit
    • Daniel Martí's avatar
      node/bindnode: rethink and better document APIs · 2fc002c2
      Daniel Martí authored
      Before, we envisioned exposing the following APIs:
      
      	Prototype
      	PrototypeNoSchema
      	PrototypeOnlySchema
      	Wrap
      	WrapNoSchema
      
      The names were long, though, and perhaps a bit confusing too. Instead,
      just expose Prototype and Wrap, and allow either of the parameters to be
      nil to infer its value. This makes the API easier to navigate, and we
      can concentrate documentation in fewer places.
      
      Now there's two main entrypoints: Prototype if one wants a high-level
      prototype to create nodes of a certain shape, and Wrap if one wants to
      expose an existing Go value as an IPLD node. Whether one supplies only
      an IPLD Schema, only a Go type/value, or both, is their choice. The only
      exception is Wrap, which always requires a Go value by definition.
      
      Wrap works now, too, and gains an example. It's the same idea as the
      previous Prototype example, but it builds the value via a Go composite
      literal rather than fluent/qp on the IPLD side.
      
      Another noteworthy change is that we now return TypedPrototype and
      TypedNode rather than the regular NodePrototype and Node interfaces,
      since bindnode always works with a schema - even when it's inferred.
      The big advantage here is that one can call the Representation method
      directly on the result without having to type assert, like the example
      does.
      2fc002c2
  2. 08 Jun, 2021 1 commit
    • Daniel Martí's avatar
      node/tests: cover yet more interface methods · b832b762
      Daniel Martí authored
      Including LookupBySegment and LookupByNode for both maps and lists, but
      also As<T> for the representation form of all scalar kinds.
      
      While at it, expand the interface implementation assertions, too.
      
      Note that we had to make the node/basic tests external,
      for the sake of testing LookupByNode without inserting an import cycle.
      b832b762
  3. 07 Jun, 2021 1 commit
    • Daniel Martí's avatar
      node/tests: cover more error cases for scalar kinds · dab6ec7c
      Daniel Martí authored
      In particular, calling non-scalar Node and Assembler methods should
      always fail.
      
      While at it, remove some unused code, since unions always have
      representation strategies.
      
      Brings up code coverage in bindnode from 72.7% to 75%.
      dab6ec7c
  4. 03 Jun, 2021 2 commits
    • Daniel Martí's avatar
      node/tests: add more extensive scalar kind tests · b6e2b10f
      Daniel Martí authored
      It covers AssignKind, AssignNode, and AsKind for every combination of
      assembler kind and method.
      
      We also verify that a constructed scalar node behaves the same with
      AsKind when using its representation, like the old test.
      
      There's effectively a triple loop as a test table, so the subtest name
      has up to three components separated by dashes, such as:
      
      	TestSchema/Scalars/Bytes-AssignNode-String
      
      We also use this test as a demo of quicktest instead of go-wish.
      
      Finally, adapt bindnode to pass these tests just like codegen. This was
      mainly a bunch of TODOs in the relevant methods.
      b6e2b10f
    • Daniel Martí's avatar
      node/bindnode: start running all schema tests · 6042d4d8
      Daniel Martí authored
      We add node/tests.SchemaTestAll to simplify this task, meaning we don't
      need to duplicate all test func declarations in node/bindnode.
      SchemaTestAll is also flexible enough to allow running multiple
      sub-tests per schema test in the future.
      
      There were two remaining places in node/tests that still weren't using
      ipld.DeepEqual, so fix those.
      
      Finally, bindnode needed a couple of changes to fully support
      ipld.DeepEqual. Most notable is iteration over maps, which required a
      bit of a refactor to keep ordered keys.
      6042d4d8
  5. 02 Jun, 2021 4 commits
  6. 25 May, 2021 5 commits
  7. 24 May, 2021 2 commits
    • Will Scott's avatar
      Add enumerate methods to the multicodec registries. · 401e218a
      Will Scott authored
      (This is a logical port of
      https://github.com/ipld/go-ipld-prime/pull/169 to follow
      https://github.com/ipld/go-ipld-prime/pull/172 .)
      
      I've added more documentation -- particularly, cautionary notes on the
      package-scope functions which read the global shared state.
      401e218a
    • Eric Myhre's avatar
      Make a multicodec.Registry type available. · 575054d9
      Eric Myhre authored
      The hope is that this might be helpful if you want to build a
      multicodec registry other than the global one, but are still buying
      into the idea of the registry being keyed by indicator numbers.
      
      (I'm... not actually sure how useful this is, because I'd think if
      you're building something other than the default, there's also a good
      chance you'd want *more* features than a primitive numerical mapping,
      which are probably going to be related to whatever your application
      logic in the area is, and therefore not possible for this library
      to usefully anticipate.  But, I dunno.  I'm doing this because
      people are proposing attaching more features to the global, and
      I'm not comfortable with it, and I'm hoping this will provide a
      pressure release valve.)
      
      The current interfaces are functionally unchanged.
      
      The multicodec.Registry type can now be used when constructing
      a cidlink.LinkSystem.  (This saves you from having to write the
      glue functions to unbox cidlink and then do the LookupEncoder
      and LookupDecode calls.)
      
      For where this relates to LinkSystem, I considered a mechanism like:
      `func (r *Registry) InstallOn(lsys *ipld.LinkSystem)` ...
      and probably would've found that a bit cleaner.
      However, it doesn't jive with the way we've isolated the CID types
      into a package with a LinkSystem just for them (sigh; that really is
      the gift of complexity that just keeps giving); you can see how the
      EncoderChooser and DecoderChooser funcs need a tiny bit of type
      assertions in order to figure out how to extract the multicodec
      indicator from the Link/LinkPrototype types?  That bit is a bit
      that we still want to keep cordoned off the rest of the import tree.
      
      DefaultRegistry is also now an exported variable, in addition to the
      functions which already worked with the global data.
      I probably would've preferred to keep the DefaultRegistry variable
      unexported, because I can't imagine any good coming of touching it,
      but the relationship to LinkSystem detailed in the above paragraph
      requires some access to it.
      575054d9
  8. 05 May, 2021 1 commit
    • Daniel Martí's avatar
      fluent/qp: don't panic on string panics · aff91f7b
      Daniel Martí authored
      Since qp uses panics as an error mechanism, the top-level functions
      recover those errors to return them normally.
      
      However, this blows up if, internally, an ipld.Node implementation
      panics with a value whose type is not error. For example, with:
      
      	panic("some panic message")
      
      One gets:
      
      	panic: some panic message [recovered]
      		panic: interface conversion: string is not error: missing method Error
      
      Fix this by having a fallback for non-error panic values.
      aff91f7b
  9. 28 Apr, 2021 2 commits
  10. 26 Apr, 2021 1 commit
  11. 25 Apr, 2021 2 commits
    • Eric Myhre's avatar
      Package docs for dag-cbor. · 92c695e9
      Eric Myhre authored
      These are somewhat overdue, and clarify what features are supported,
      and also note some discrepancies in implementation versus the spec.
      
      (As I'm taking this inventory of discrepancies, there's admittedly
      rather more than I'd like... but step 1: document the current truth.
      Prioritizing which things to hack on, in the field of infinite possible
      prioritizations of things that need hacking on, can be a step 2.)
      92c695e9
    • Eric Myhre's avatar
      Update package docs. · e53a83e8
      Eric Myhre authored
      These had drifted a bit, and I just noticed it's due for some freshening up.
      e53a83e8
  12. 19 Apr, 2021 1 commit
  13. 09 Apr, 2021 4 commits
    • Daniel Martí's avatar
      schema/gen/go: apply gofmt automatically · 4bb2f097
      Daniel Martí authored
      Now that we buffer the output, using go/format is trivial.
      
      This makes the default behavior better, and means not having to use an
      extra gofmt go:generate step everywhere.
      4bb2f097
    • Daniel Martí's avatar
      schema/gen/go: fix remaining vet warnings on generated code · 2359e698
      Daniel Martí authored
      And re-generate all code in this module.
      
      This gets us to a point where go-codec-dagpb has zero vet warnings, for
      example. schema/dmt still has a few warnings, but those are trickier to
      fix, so will require another PR.
      2359e698
    • Eric Myhre's avatar
      Merge pull request #161 from mvdan/generate-buffer · 7bca6b48
      Eric Myhre authored
      schema/gen/go: batch file writes via a bytes.Buffer
      7bca6b48
    • Daniel Martí's avatar
      schema/gen/go: batch file writes via a bytes.Buffer · 88f72f58
      Daniel Martí authored
      With this change, running 'go generate ./...' on the entire module while
      running gopls on one of its files drops gopls's CPU spinning from ~25s
      to well under a second. They should improve that anyway, but there's no
      reason for the tens of thousands of tiny FS writes on our end either.
      
      The time to run 'go generate ./...' itself is largely unaffected; it
      goes from ~1.2s to ~1.1s, judging by a handful of runs.
      88f72f58
  14. 07 Apr, 2021 1 commit
    • Daniel Martí's avatar
      schema/gen/go: avoid Maybe pointers for small types · f3d42e04
      Daniel Martí authored
      If we know that a schema type can be represented in Go with a small
      amount of bytes, using a pointer to store its "maybe" is rarely a good
      idea. For example, an optional string only weighs twice as much as a
      pointer, so a pointer adds overhead and will barely ever save any
      memory.
      
      Add a function to work out the byte size of a schema.TypeKind, relying
      on reflection and the basicnode package. Debug prints are also present
      if one wants to double-check the numbers. As of today, they are:
      
      	sizeOf(small): 32 (4x pointer size)
      	sizeOf(Bool): 1
      	sizeOf(Int): 8
      	sizeOf(Float): 8
      	sizeOf(String): 16
      	sizeOf(Bytes): 24
      	sizeOf(List): 24
      	sizeOf(Map): 32
      	sizeOf(Link): 16
      
      Below is the result on go-merkledag's BenchmarkRoundtrip after
      re-generating go-codec-dagpb with this change. Note that the dag-pb
      schema contains multiple optional fields, such as strings.
      
      	name         old time/op    new time/op    delta
      	Roundtrip-8    4.24µs ± 3%    3.78µs ± 0%  -10.87%  (p=0.004 n=6+5)
      
      	name         old alloc/op   new alloc/op   delta
      	Roundtrip-8    6.38kB ± 0%    6.24kB ± 0%   -2.26%  (p=0.002 n=6+6)
      
      	name         old allocs/op  new allocs/op  delta
      	Roundtrip-8       103 ± 0%        61 ± 0%  -40.78%  (p=0.002 n=6+6)
      
      Schema typekinds which don't directly map to basicnode prototypes, such
      as structs and unions, are left as a TODO for now.
      
      I did not do any measurements to arrive at the magic number of 4x, which
      is documented in the code. We might well increase it in the future, with
      more careful benchmarking. For now, it seems like a conservative starting
      point that should cover all basic types.
      
      Finally, re-generate within this repo.
      f3d42e04
  15. 03 Apr, 2021 1 commit
  16. 02 Apr, 2021 1 commit
  17. 01 Apr, 2021 1 commit
    • hannahhoward's avatar
      feat(linksystem): add reification to LinkSystem · 9340af55
      hannahhoward authored
      add an optional reifier into the link system process. The reason to do this is to capture the link
      system itself when reification happens, in case it needs to be put into the node, which is often not
      accessible by the time you have a node. another alternative would be to make this specific to
      selector traversal, similar to LinkNodePrototypeChooser
      9340af55
  18. 24 Mar, 2021 2 commits
  19. 23 Mar, 2021 5 commits
  20. 22 Mar, 2021 1 commit
  21. 15 Mar, 2021 1 commit