- 25 May, 2021 1 commit
-
-
Daniel Martí authored
The funciton is carefully documented via godoc, so I'm not going to attempt to document it here again. But as a high-level summary, it's like a reflect.DeepEqual applied to the ipld.Node interface rather than reflect.Value. The only other two noteworthy details are that errors are treated as panics, and Links are compared directly via ==. Finally, we add table-driven tests to ensure all edge cases work. Fixes #173.
-
- 25 Dec, 2020 1 commit
-
-
Daniel Martí authored
As discussed on the issue thread, ipld.Kind and schema.TypeKind are more intuitive, closer to the spec wording, and just generally better in the long run. The changes are almost entirely automated via the commands below. Very minor changes were needed in some of the generators, and then gofmt. sed -ri 's/\<Kind\(\)/TypeKind()/g' **/*.go git checkout fluent # since it uses reflect.Value.Kind sed -ri 's/\<Kind_/TypeKind_/g' **/*.go sed -i 's/\<Kind\>/TypeKind/g' **/*.go sed -i 's/ReprKind/Kind/g' **/*.go Plus manually undoing a few renames, as per Eric's review. Fixes #94.
-
- 16 Dec, 2020 1 commit
-
-
Daniel Martí authored
We only supported representing Int nodes as Go's "int" builtin type. This is fine on 64-bit, but on 32-bit, it limited those node values to just 32 bits. This is a problem in practice, because it's reasonable to want more than 32 bits for integers. Moreover, this meant that IPLD would change behavior if built for a 32-bit platform; it would not be able to decode large integers, for example, when in fact that was just a software limitation that 64-bit builds did not have. To fix this problem, consistently use int64 for AsInt and AssignInt. A lot more functions are part of this rewrite as well; mainly, those revolving around collections and iterating. Some might never need more than 32 bits in practice, but consistency and portability is preferred. Moreover, many are interfaces, and we want IPLD interfaces to be flexible, which will be important for ADLs. Below are some GNU sed lines which can be used to quickly update function signatures to use int64: sed -ri 's/(func.* AsInt.*)\<int\>/\1int64/g' **/*.go sed -ri 's/(func.* AssignInt.*)\<int\>/\1int64/g' **/*.go sed -ri 's/(func.* Length.*)\<int\>/\1int64/g' **/*.go sed -ri 's/(func.* LookupByIndex.*)\<int\>/\1int64/g' **/*.go sed -ri 's/(func.* Next.*)\<int\>/\1int64/g' **/*.go sed -ri 's/(func.* ValuePrototype.*)\<int\>/\1int64/g' **/*.go Note that the function bodies, as well as the code that calls said functions, may need to be manually updated with the integer type change. That cannot be automated, because it's possible that an automated fix would silently introduce potential overflows not being handled. Some TODOs and FIXMEs for overflow checks are removed, since we remove some now unnecessary int64->int conversions. On the other hand, the older codecs based on refmt need to gain some overflow check TODOs, since refmt uses ints. That is okay for now, since we'll phase out refmt pretty soon. While at it, update codectools to use int64 for token Length fields, so that it properly supports full IPLD integers without machine-dependent behavior and overflow checks. The budget integer is also updated to be int64, since the lengths it uses are now int64. Note that this refactor needed changes to the Go code generator as well as some of the tests, for the purpose of updating all the code. Finally, note that the code-generated iterator structs do not use int64 fields internally, even though they must return int64 numbers to implement the interface. This is because they use the numeric fields to count up to a small finite amount (such as the number of fields in a Go struct), or up to the length of a map/slice. Neither of them can ever outgrow "int". Fixes #124.
-
- 10 Sep, 2020 1 commit
-
-
Daniel Martí authored
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.
-
- 09 Jul, 2020 1 commit
-
-
Eric Myhre authored
This is full of mundane plonking away at adding stars and ampersands, of which approximately none are interesting. (I'm particularly frustrated by this because these are all placeholder types, and we're getting *very* close to replacing them, as we get closer and closer to self-hosting... at which point all of this bonking about will be made totally irrelevant. And yet to close the last mile, these "small" fixes are surprisingly irritating. Ah well.) The bits that *are* interesting: - the Spawn functions for type info now take strings rather than types (so that they don't provoke a cycle problem for the user when constructing the information to describe cyclic type info); - all of the Type info structure hold a pointer to the TypeSystem, and use that to look up reified Type info for related types, so that their methods don't force the caller to do that themselves. (The TypeSystem pointer was already there, amusingly; just never before initialized, because it hadn't turned out to be load-bearing yet.) It also would've been possible to just change all the methods on the Type types to return TypeName rather than full Type info. That would avoid the need to use a TypeSystem pointer. I didn't because: Overall, this was done in such a way as to minimize the diff that impacts within the templates. This was a goal because updating templates is a fair bit more work than other code due to the weak compiler support. And we'll end up reviewing and changing these methods when we get to our goal of self-hosting generation of the schema types from the schema-schema, so, it's not worth pushing around diffs in that same area when they'd be sure to be churned under soon.
-
- 29 Jun, 2020 1 commit
-
-
Eric Myhre authored
Hopefully this increases clarity and eases comprehension. Notes and discussion can be found at https://github.com/ipld/go-ipld-prime/issues/54 (and also I suppose in some of our weekly video chats, but I'd have to go on quite a dig to find the relevant links and time). Many many refernces to 'ns' are also updated to 'np', making the line count in this diff pretty wild.
-
- 26 Jun, 2020 1 commit
-
-
Eric Myhre authored
See the changelog for discussion; this had already been on the docket for a while now.
-
- 24 Apr, 2020 1 commit
-
-
Eric Myhre authored
Works.
-
- 17 Apr, 2020 1 commit
-
-
Eric Myhre authored
\o/
-
- 13 Apr, 2020 1 commit
-
-
Eric Myhre authored
This diff is pretty fun. It's our first alternative representation, and it all works out nicely (no internal syntactical complications encountered or any other unexpected unpleasantness). It's also our first representation that involves potentially recursive destructuring work over a scalar! So, you can see the new 'construct' method conventions appearing to handle that. Works out neatly. This kind of recursive destructuring happens all within the span of processing one "token" so to speak, so naturally it can work without any stateful machinery. Some utility functions are added to the mixins package. (It's sort of betraying in the name of the package, but, well, it's an extremely expedient choice. See comments about import management. tl;dr: consistency makes things easier.) Tests for a recursive case of this will be coming soon, but requires addressing some other design flaws with the AdjunctConfig maps. (StructField is... not a good key. It's not always hashable... such as when the StructField.Type field is inhabited by TypeStruct.) Easy enough to fix, just not going to cram it into this commit. The way null and the 'fcb' are handled here differs from previous generators: here, we *always* have an 'fcb', and just make a special one for the root builder. This is... well, it works. It was an attempt to simplify things and generate fewer method overrides, and it did. However, I'm not going to dwell on this too long, because... The 'fcb' system is not working out well overall for other reasons: it's causing costly allocations. (Taking a function pointer from a method requires at least two words: one for the function pointer and one for the value to apply it on. That means an allocation.) So a serious rewrite of anything involing the 'fcb' strategy is needed. And that is going to be a little tricky. The 'fcb' idea was itself a trying-slightly-too-hard-to-be-clever attempt to avoid an alternative solution that involves generating additional types per distinct child value slot (and I'm still unwilling to pursue that one -- it suggests far too many types). The next best idea I have now seems to involve a lot of pointers into other assembler's state machines; this will surely be a bit touchy. But no worse than any of the rest of all this, I suppose: it's *all* "a bit touchy". Buckle up for fun diffs ahead.) So, considering these 'fcb' notes, this feels a bit mixed... "Two steps forward, one step back", so to speak. Still: progress! And it's very exciting that we got through several new categories of behavior without hitting any other new roadbumps.
-