An additional change here is we're allowing more keys to be omitted in
the JSON format. This is both intuitive for data entry, and safer in
terms of Flow types (as JSON.parse returns any).
The test examples now cover a v0.1.0 (initiative-A), v0.2.0 with just
URLs (initiative-B) and one with just entries (initiative-C).
To make this commit smaller and easier to review, we're not yet adding
`EdgeSpec` to the `Initiative` type and will ignore the entries when
converting from `InitiativeFile` to `Initiative`.
Defines the NodeAddress format we want to use for a NodeEntry.
Because we want to use the parent InitiativeId as parts of the address,
we'll need to read the underlying string[], changing the opaque type.
This commit modifies the resolveAlias function in the identity plugin's
alias module so that it now allows you to convert sourcecred identity
aliases (e.g. "sourcecred/user") back into NodeAddresses. This will be
necessary so that we can convert our ad-hoc distributions and transfers
(which use aliases, including SourceCred identity aliases) into the more
robust formats for the productionized grain ledger, which use full node
addresses.
I did a slight refactor on the identity module to expose a method for
constructing the address without the rest of the node.
Test plan: `yarn test`
Summary:
Version 5.0.0 of `better-sqlite3` redesigned the `Database.transaction`
method to do exactly what we want, obviating the need for our custom
helper function and tests. It’s actually more flexible: it allows the
transaction function to take arguments, and allows nested transactions.
Test Plan:
All tests pass as written. If this patch is instead made by changing the
implementation of `_inTransaction` to `return db.transaction(fn)()`,
most tests still pass, excepting only some tests about the behavior of
`_inTransaction` itself around transaction nesting and manual rollbacks;
those behavior changes are acceptable, especially given that they’re not
exercised in the code under test.
wchargin-branch: mirror-builtin-transaction
Summary:
I first wrote these type definitions for v4.x.x. The library API has
changed since then. This patch updates the type definitions to match the
current API as of the v7.0.0 release:
<https://github.com/JoshuaWise/better-sqlite3/blob/v7.0.0/docs/api.md>
There are breaking changes, but none among functions that we use. On the
other hand, there are new features that will be useful to us.
Test Plan:
Running `yarn flow` still passes. There may be some errors among typing
of functions that we don’t actually use (particularly `aggregate`, which
is more complicated than the others). If so, we can cross those bridges
when we come to them.
wchargin-branch: flow-better-sqlite3-v7-api
Summary:
In `_findOutdated`, we bound a query parameter that was not used by the
query. This is entirely harmless, but should still be fixed.
Test Plan:
That unit tests continue to pass suffices.
wchargin-branch: mirror-findoutdated-superfluous-param
Summary:
This fixes a bug introduced in #1665, where we added a `typenames`
clause to the query plan but didn’t update the termination checking
accordingly. As a result, query plans with only `typenames` left to
update would not execute, so `extract` would fail with a `NOT NULL`
constraint violation because not all transitively needed objects had
been fetched.
Databases created before this change are still valid. Re-running the
problematic `sourcecred load` command should successfully update the
cache and proceed.
Fixes#1762.
Test Plan:
Regression test added; `aracred/ideas` and `aracred/aracred-template`
both load successfully now.
wchargin-branch: mirror-typenames-only-plan
Adds a new NodeType for each NodeEntryField. Allowing multipliers to be
set per field.
Since the "contributes to" edge is very generic and created a naming
conflict, this includes a slightly awkward "contributes to entry" addition.
Including "entry" to differentiate from the existing edge type.
The edge weights for this loosely follow the current edge weight rationale.
When we've merged enough functionality to do in-browser testing of different
weights with an example scenario, I think we should revisit them.
This type will replace the current `$ReadOnlyArray<URL>` on the Initiative
fields to support NodeEntry arrays as well. Like with the NodeEntryJson
they will have a manual-entry convenience flavor and an internally
normalized one.
The normalization function aims to throw errors that help users notice any
input mistakes.
This is where most flexibility when hand-writing JSON files is expected
to come from. As it makes few assumptions about the formatting but the
internal normalized type is still consistent.
This is the generalized type that allows us to define contributions to an
Initiative from the same JSON file as the Initiative. See #1739.
The types distinguish between what a user is expected to enter and what
this is internally normalized to. The normalization logic is implemented
in a follow-up PR.
Often we can use representations like Set to avoid duplicates in the first
place. However when duplicates are not allowed in some kind of user input
we may want to present them with a useful error message.
This util will find the duplicate elements, so they can be highlighted
in an error.
Add a numerically-naive method for calculating the floating point ratio
between grain values, as it is needed in #1743.
Following discussion in [this review], we hope that @wchargin will
re-write this method later to have better precision.
Test plan: Attached unit tests should pass.
[this review]: https://github.com/sourcecred/sourcecred/pull/1715#discussion_r396909459
Paired with @hammadj
Adds a class to persist a local mirror of data from a Discord Guild.
Implements create and read functionality.
Adds a function to `models` which converts an Emoji string-reference
into an Emoji object.
Test plan:
Unit tests added.
Paired with: @beanow
By adding information about configuration and what identity contractions
do, it provides more reference for instance maintainers and community
members to understand the plugin.
Includes rephrasing and feedback from @s-ben and @vsoch.
Closes#1725
In PR #1746 we've added `src/util/timestamp.js`. This commit replaces the
plugin's internal opaque string and number types with well tested types
and conversion functions.
As we're looking to add more features to InitiativeFile, the single source
file would grow large. Anticipating this we're splitting one type and it's
related functions off into a new file.
* Add a README.md for the GitHub plugin
This mostly documents at a conceputal level that would be useful for
users; it's not trying to document it for contributors to the GitHub
plugin, although that could be useful as a followup.
Sending this out for initial review, although arguably we should merge
it to sourcecred/docs rather than directly alongside the code. I welcome
feedback on content, structure, and location.
Test plan: No tests, just review.
* Address review feedback
* Address @s-ben's review feedback
The URL type used by Initiatives was added before reference detection was
fully fleshed out. Since we'll use this reference detection, we'll use
it's URL type as well.
Previously we intended to use Discourse as a source of Initiatives.
Since we're not taking this approach anymore, we're removing the
related features here.
We have a convention of using TimestampMs as our default representation.
However TimestampISO has the benefit of being human readable / writable,
so it's used for serialization and display as well.
We'll validate types at runtime, as there's a fair chance we'll use these
functions to parse data that came from a Flow `any` type (like JSON).
Fixes#1653
This is a fairly simple helper function that allows transforming a Map into an Array using a provided transformer function. It's really an alias for `Array.from(map.entries()).map(f)`, which is nice because that invocation is somewhat tedious to write.
Test plan: The method is very simple; we've added some correspondingly simple test. Also, grepping for `Array\.from(.*\.entries())\.map` should return no hits (i.e. we've converted existing usage).
Paired with @decentralion
Test Plan: grep for global BigInt and make sure there's no longer
instances in code files now that we added it to central ESLint Config
Paired with @decentralion
This commit adds two math helpers to the `grain` module:
`multiplyFloat` has a canonical way to multiply a grain amount by a
floating point number, which is useful e.g. if we need to multiply grain
amounts by cred ratios. For now, we have a naive approach which coerces
the grain into a float, does float multiplication, and then converts
back to grain.
This is imprecise, but in testing (see [notebook]) the absolute error
amounts are very small, i.e. in the atto-grain to femto-grain range.
Because we will be using this in conjunction with payout strategies that
implement explicit payment-error-correction over time (i.e. we calculate
who has been historically under-paid and give them more reward), these
insignificant errors will tend to disappear rather than accumulate over
time.
`fromFloat` is a helper method for creating a grain balance directly
from a float. It's basically an alias for `multiply(ONE, float)` and
is useful for test code.
Test plan: Unit tests included (and re-factored to use the new helpers).
See attached notebook for some exploration of error values.
[notebook]: https://observablehq.com/@decentralion/grain-arithmetic
"This rule is aimed at flagging variables that are declared using let
keyword, but never reassigned after the initial assignment."
https://eslint.org/docs/rules/prefer-const
This is a rule that helps you spot mistakes while writing code with a
let statement. When thinking that you will need to reassign it, eslint
will point out you're not actually doing so.
This could be because you've forgotten something, assigned the wrong
variable, or no longer need to reassign.
Removes `roles` as a property of `GuildMember` because the use
case is not clear at this point in time.
Test Plan: Yarn Test passes. `git grep -i "roles"` also returns an
empty result.
Summary:
This commit introduces an `ignoreRevsFile` for use with Git blame. See
the header of the new file for details.
Test Plan:
Run `git blame -L183,183 config/test.js`. Before this change, note that
it blames to the reformatting commit. After this change, and after
configuring `git config blame.ignoreRevsFile .git-blame-ignore-revs`,
note that it blames to the last real change.
wchargin-branch: prettier-2.0.1-unblame
This is based on notes taken during exploring of the API and building
the hackathon prototype. As the production-ready version is being built
right now, they seem like useful notes to keep on hand.
Though we don't return any value, we should wait till we've completed
the file I/O. This likely caused the flake from #1655. As we didn't
await the write, it caused a race condition where we tried to read first.
Fixes#1655
Adds a Fetcher class that takes fetch options and fetches against
the correct endpoints, returning re-formatted request data
and pagination info.
Adds a models.js file that defines Discord types.
Test Plan:
Unit tests added for fetcher class and helper functions in
models.js file.
Paired with @Beanow
Summary:
Generated by running `yarn prettify`.
Test Plan:
Running `yarn check-pretty` no longer prints any errors.
wchargin-branch: prettier-2.0.1-reformat
Summary:
Prettier 2.0.0 introduced some far-reaching formatting changes, so this
commit temporarily neutralizes `check-pretty`. Follow-up commits will
update all formatting and re-enable the package script.
Generated with `yarn add prettier@^2.0.1`.
Test Plan:
Running `yarn check-pretty` prints a bunch of files and then the
expected “Failures OK” message, exiting 0.
wchargin-branch: prettier-2.0.1-upgrade
Improves readability of the code and makes it easy to understand that these are constants instead of parameters/variables.
Test plan: This is a rename; verify that CI passes.
This commit adds a `grain/grain.js` module, which contains a type and
logic for representing Grain balances with 18 digits of precision. We
use the native BigInt type (and add the necessary babel plugin to
support it).
Unfortunately, Flow does not yet support BigInts (see
[facebook/flow#6639]). To hack around this, we lie to Flow, claiming
that BigInts are numbers, and we expect/suppress the flow errors
whenever we actually instantiate one. For example:
```js
// $ExpectFlowError
const myBigInt = 5n;
```
We can use the BigInt operators like `+`, `-`, `>` without flow errors,
since these actually exist on numbers too. However, flow will fail to
detect improper combinations of regular numbers and BigInts:
```js
// $ExpectFlowError
const x = 5n;
const y = x + 5;
// Uncaught TypeError: Cannot mix BigInt and other types
```
Since any improper mixing will result in a runtime error, these issues
will be easy to detect via unit tests.
In addition to adding the basic Grain type, I exported a `format`
function which will display Grain balances in a human readable way.
It supports arbitrary decimal precision, groups large amounts with comma
separators, handles negative numbers, and adds a suffix string.
The format method is thoroughly documented and tested. Thanks to @Beanow
for valuable feedback on its implementation.
Test plan: See included unit tests. `yarn test` passes.
[facebook/flow#6639]: https://github.com/facebook/flow/issues/6639
Found this incorrectly encoded %93 in an actual forum post.
This change will make it so we will print the error and ignore the URL
for reference detection, rather than crash.
Preparing for release #1679
Note: due to a regression, not upgrading eslint-plugin-react
See https://github.com/yannickcr/eslint-plugin-react/issues/2570
Also updated package.json to latest semver in-range versions.
Note, this changes all packages (other than eslint-plugin-react)
to ^x.x.x format.
This commit modifies the default weights in the Discourse plugin. The
overall theme is to make the plugin flow less cred to "raw activity", in
favor of only flowing cred to posts where there is some explicit signal
that they were valuable.
Most significantly, we move over to fully [like-minted cred][1], instead
of minting cred directly to posts and topics. Also, we remove the edges
that tend to flow cred to posts indiscriminately. For example, topics no
longer flow cred to every post within the topic.
Based on local testing on a few forums I'm familiar with, I feel
confident that these cred scores are an improvement over the current
defaults, as we now have a few "real life test cases" of high-noise,
high-activity users, and these weights reduce the amount of cred that
accrues to such "stress testers". With these changes, I feel that we can
start cautiously using the Discourse plugin in [Trust Level 2][2]
communities.
Test plan: `yarn flow` and code inspection are sufficient to verify that
the new weights are technically valid. Because my calibration process
for validating these changes involves subjective judgements about
contributions from real people, I'm declining to publicly post any
specifics; reviewers are welcome to reach out to my offline for further
discussion.
[1]: https://discourse.sourcecred.io/t/minting-discourse-cred-on-likes-not-posts/603
[2]: https://github.com/sourcecred/docs/pull/24
Summary:
This is mostly a QoL improvement for maintainers. GraphQL mirrors are
stored in the SourceCred cache directory, but until now have been hard
to tell apart. All IDs looked like long, similar hex strings; e.g.:
```
github_736f75726365637265642d746573742f6578616d706c652d676974687562.db
github_736f75726365637265642f646f6373.db
github_736f75726365637265642f736f7572636563726564.db
```
It’s too hard to tell that these are `sourcecred-test/example-github`,
`sourcecred/docs`, and `sourcecred/sourcecred` in that order. (Yes, you
can work it out if you try; that’s not good enough.) With dozens of
caches loaded, finding the right one to poke at for debugging or
progress-checking takes way too much scripting.
The purpose of this abstruse encoding was portable filename safety, but
we can actually achieve this with human-readable names like these:
```
github_sourcecred-test_example_github.db
github_sourcecred_docs.db
github_sourcecred_sourcecred.db
```
This suffices because (a) login names cannot contain underscores, so we
can safely use that as a separator, and (b) GitHub disallows collisions
on names that are equal ignoring case, so we can convert all names to
lowercase without introducing collisions.
This change orphans existing caches. Running `sourcecred clear --cache`
will clean those up.
Test Plan:
Try to create a GitHub repository with the same name as a repository
that you already have, but with inverted case; note that this is
disallowed. Then, note that loading `sourcecred-test/example-github`
still works and produces a database with nicely readable name.
wchargin-branch: github-readable-db-names
Summary:
The `_addCommit` helper recurs against the list of parents of a commit.
We add pull requests to the repository in ascending numeric order, so in
many cases the depth of this recursion is bounded, because each PR’s
merge commit is only a few levels down from the previous one’s. But this
is not the case for repositories that have long sequences of commits
none of which was merged by a pull request. In such cases, we’ll simply
blow the stack.
To complicate matters, the conditions in which we observe this are hard
to predict, because V8 optimizes `_addCommit` when it determines that
it’s a hotspot. This means that the tests are a bit brittle, with
carefully chosen constants that balance test execution time against
regression-catching power. See [comment on #1354 with my analysis][c].
[c]: https://github.com/sourcecred/sourcecred/issues/1354#issuecomment-593062805Fixes#1354.
Test Plan:
Tests pass as written, and fail if `commitStack.push(parent)` is
replaced with `this._addCommit(parent)`, even if the two `it`-blocks
under the new `describe` spec are commuted. An end-to-end test shows
that we can now compute cred for `passbolt/passbolt_api` (which takes
about an hour to load and compute).
wchargin-branch: rv-fix-addcommit-overflow
* Add serialization to TimelineCredScores
Right now the serialization is super trivial, we just attach a compat
header. In the future, we can try encoding the float64 arrays as
bytestrings to save space.
Test plan: Unit tests included; `yarn test` passes.
* Fix up serialization per @Beanow's review
