- 22 Aug, 2021 1 commit
-
-
tavit ohanian authored
-
- 16 Aug, 2021 1 commit
-
-
tavit ohanian authored
-
- 29 Jul, 2021 1 commit
-
-
tavit ohanian authored
-
- 01 Jul, 2021 1 commit
-
-
Daniel Martí authored
After experimenting with quip and qp for a few months, we seem to agree that qp is a bit nicer to use. Remove quip, since it's largely redundant going forward. Since the qp docs referenced quip, redo that to stand on its own ground.
-
- 05 May, 2021 1 commit
-
-
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.
-
- 21 Jan, 2021 1 commit
-
-
Daniel Martí authored
I started rewriting the "getting started" Go guide to use fluent/qp instead of fluent, but I'm missing some of the helpers since the guide uses links, among others. This is largely copy-pasted, but there are just a handful of types and it's barely a dozen lines per type. A generator is not worth it for 100 lines of code that will rarely ever need to change.
-
- 18 Jan, 2021 1 commit
-
-
Daniel Martí authored
This is what I came up with, building on top of Eric's quip. I don't want to waste too much time naming this, and I like two-letter package names in place of dot-imports, so "qp" seems good enough for now. They are the "strong" consonants when one says "Quick iPld". First, move the benchmarks comparing all fluent packages to the root fluent package, to keep things a bit more tidy. Second, make all the benchmarks report their allocation stats, without having to always remember to use the -benchmem flag. Third, add a qp benchmark. Fourth, notice a couple of potential bugs in the quip benchmarks, and add TODOs for them. Finally, add the qp API. It differs from quip in a few external ways: 1) No error pointers. Instead, it uses panics which are recovered at the top-level API layer. This reduces verbosity, removes the "forgot to handle an error" type of mistake, and does not affect performance thanks to the defers being statically allocated in the stack. 2) Supposed better composition. For example, one can use MapEntry along with Map to have a map inside another map. In contrast, quip requires either an extra layer of func literals, or extra API like AssignMapEntryString. 3) Thanks to the points above, the API is significantly smaller. Note that some helper APIs like Bool are missing, but even when added, qp should expose about half the API funcs taht quip does. This is the first proof of concept. I'll probably finish adding the rest of the API helpers when I find the first use case for qp. Benchmark numbers, with perflock and benchstat on my i5-8350u laptop: name time/op Quip-8 1.39µs ± 1% QuipWithoutScalarFuncs-8 1.42µs ± 2% Qp-8 1.46µs ± 2% name alloc/op Quip-8 912B ± 0% QuipWithoutScalarFuncs-8 912B ± 0% Qp-8 912B ± 0% name allocs/op Quip-8 18.0 ± 0% QuipWithoutScalarFuncs-8 18.0 ± 0% Qp-8 18.0 ± 0%
-