profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/ninevra/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

ninevra/Simple-Temporary-Containers 3

Makes it simple to create and destroy temporary containers in Mozilla Firefox.

ninevra/crystal-query 1

A simple query language with customizable semantics

ninevra/ava 0

Node.js test runner that lets you develop with confidence 🚀

ninevra/ava-next-eslint-hangs-mre 0

MRE for avajs/eslint-plugin-ava

ninevra/ava-snapshot-skip-id 0

MRE for avajs/ava#2662

ninevra/coda 0

The d20 system updated for the 2020s.

ninevra/concordance 0

Compare, format, diff and serialize any JavaScript value

ninevra/cooperate 0

Plugin to enable cooperation between AVA test files

ninevra/eslint-plugin-ava 0

ESLint rules for AVA

pull request commentconcordancejs/concordance

Handle empty items in arrays and arraylike objects

There's a bug in the alignment code that I need to figure out.

ninevra

comment created time in 2 months

PR opened concordancejs/concordance

Handle empty items in arrays and arraylike objects

Adds an EmptyItem descriptor to represent the gaps in sparse arrays. Formats gaps as <empty item>, and treats them as unequal to anything other than empty items for comparison and diffing.

Adds theme keys

item: {
    empty: {
        open: '<',
        close: '>',
    }
}

for controlling the formatting; I'm not sure if this is the best way to do this. Maybe the item text should be configurable, or maybe the brackets should be part of the item text and not part of the open/close wrappers?

I initially implemented this with an Empty primitive descriptor, but I think EmptyItem better matches the data model. I can't think of a non-list context where Empty would be valid.

This PR does not collapse empty items into e.g. <5 empty items> like util.inspect does; that functionality seemed like a subset of #12.

Closes #74.

This is a breaking change & bumps the serialization format version to 4.

+205 -4

0 comment

15 changed files

pr created time in 2 months

create barnchninevra/concordance

branch : empty-array-items

created branch time in 2 months

issue closedconcordancejs/concordance

Infinite iterables cause infinite loops

concordance attempts to traverse iterables to completion, so that it can compare and/or describe their elements. This means that compare, diff, format, and serialize loop infinitely when called with infinite iterables.

This can cause AVA tests to time out, even on comparisons that can be completed in finite time, such as

const test = require('ava');

test('Comparing infinite iterables', t => {
  t.deepEqual(
    (function * () { while (true) yield; })(),
    undefined
  );
});

I'm not sure whether this is the intended behavior or not.

closed time in 2 months

ninevra

issue commentconcordancejs/concordance

Infinite iterables cause infinite loops

I'm not sure? It wouldn't make sense to consider only a finite number of elements, but I suppose one could throw after a configurable number of steps.

Traversing iterables at all seems odd to me, since stateful iterables could produce strange results and async iterables aren't (and can't be) treated similarly, but that's a done design decision. (Looking at other libraries, chai and jest likewise traverse iterables, lodash just declares them equal for some reason, and node assert compares them by reference / identity.)

describe() and compare() seem to work fine with infinite iterables (unless compare receives two equal infinite iterables, of course). It might be possible to improve on this slightly by setting a configurable maximum iterations cap for at least diff() and format(), so that AVA could produce sensible output in slightly more cases. Doesn't seem worth the work, though, since assertions on infinite iterables will never pass.

I'll close this issue.

ninevra

comment created time in 2 months

issue commentconcordancejs/concordance

Sparse arrays are treated like arrays of undefined

That would make sense to me. Detecting the gap is simple enough, just add if (current in this.value) {} around line 122 in https://github.com/concordancejs/concordance/blob/b30e7c8bdb19463b3a7e11d1dc8725affce7b059/lib/complexValues/object.js#L110-L123

I think any change here would probably(?) be breaking, though, since it would mean introducing a new descriptor tag (so old versions couldn't decode new serializations) and existing snapshots of sparse arrays would compare inequal to new snapshots of the same values.

There's also a test case asserting the current behavior at https://github.com/concordancejs/concordance/blob/b30e7c8bdb19463b3a7e11d1dc8725affce7b059/test/lodash-isequal-comparison.js#L135

I reviewed a few other libraries; it looks like chai, jest, and lodash all consider empty array items to equal undefined, while node's assert builtin module does not.

ninevra

comment created time in 2 months

issue openedconcordancejs/concordance

Sparse arrays are treated like arrays of undefined

concordance treats empty slots in arrays like undefined, for both formatting and comparison.

format(new Array(5)) gives

[
  undefined,
  undefined,
  undefined,
  undefined,
  undefined,
]

whereas util.inspect(new Array(5)) gives [ <5 empty items> ]

compare(new Array(5), Array.from({length: 5}) returns true, although these values behave rather differently.

created time in 2 months

issue openedconcordancejs/concordance

Infinite iterables cause infinite loops

concordance attempts to traverse iterables to completion, so that it can compare and/or describe their elements. This means that compare, diff, format, and serialize loop infinitely when called with infinite iterables.

This can cause AVA tests to time out, even on comparisons that can be completed in finite time, such as

const test = require('ava');

test('Comparing infinite iterables', t => {
  t.deepEqual(
    (function * () { while (true) yield; })(),
    undefined
  );
});

I'm not sure whether this is the intended behavior or not.

created time in 2 months

push eventninevra/jsdom

ninevra

commit sha c254c7bc04975cacf8d7f3521d980afcdc79625f

Remove unneed support for resetQueue asserts

view details

push time in 2 months

PR opened concordancejs/concordance

Handle undescribed own properties

This PR treats own properties that lack descriptors as non-enumerable (skipping them). This prevents throwing when the input contains certain strange Proxy objects.

Closes #71.

+13 -2

0 comment

2 changed files

pr created time in 2 months

create barnchninevra/concordance

branch : odd-properties

created branch time in 2 months

push eventninevra/concordance

ninevra

commit sha 50289f5deed0027484d627aa17d04c5bb8eace63

Escape backticks in multi-line strings with the default theme

view details

Mark Wubben

commit sha 9b21a19c14bc206406e23376ff96f439bfc30171

5.0.4

view details

Mark Wubben

commit sha b30e7c8bdb19463b3a7e11d1dc8725affce7b059

Update snapshot reports given backtick fix

view details

push time in 2 months

create barnchninevra/webidl2js

branch : init-global

created branch time in 2 months

delete branch ninevra/participant-data

delete branch : patch-1

delete time in 2 months

pull request commentjsdom/webidl2js

Create async iterators and iterator result objects in the correct realm

This PR is ready for review/merge as far as I'm aware. I've updated the title & header to reflect the current implementation.

ninevra

comment created time in 2 months

push eventninevra/webidl2js

ninevra

commit sha 30915432669e094ed837e7b9941de8b69b3e8428

Comment unused exports

view details

push time in 2 months

Pull request review commentjsdom/webidl2js

Allow injecting correct realm's AsyncIteratorPrototype

 const ctorRegistrySymbol = Symbol.for("[webidl2js]  constructor registry"); // This only contains the intrinsic names that are referenced from the `ctorRegistry`: const intrinsicConstructors = ["Array"]; +const IteratorPrototype = Object.getPrototypeOf(Object.getPrototypeOf([][Symbol.iterator]()));+const AsyncIteratorPrototype = Object.getPrototypeOf(Object.getPrototypeOf(async function* () {}).prototype);

Makes sense. It's worth noting though that there's already a bit of incompatibility between the main branch and the last release; interfaces generated after #234 expect initCtorRegistry to be the only way of initializing the ctorRegistry, while code generated before #234 naturally doesn't call initCtorRegistry, as it didn't exist. Installing pre-#234 interfaces before post-#234 interfaces causes the latter to throw, because the ctorRegistry was created but %IteratorPrototype% was not captured. There's a workaround (calling initCtorRegistry manually before installing interfaces), which I've been using in local testing, but it's not documented.

I sort of assumed that the next release would be major for this reason, though admittedly that would probably be more of a pain for jsdom than just using the workaround. I'm not terribly clear on what the semver guarantees mean for codegen projects, much less for domexception and other projects whose public interface is only part codegen.

ninevra

comment created time in 2 months

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentjsdom/webidl2js

Allow injecting correct realm's AsyncIteratorPrototype

 const ctorRegistrySymbol = Symbol.for("[webidl2js]  constructor registry"); // This only contains the intrinsic names that are referenced from the `ctorRegistry`: const intrinsicConstructors = ["Array"]; +const IteratorPrototype = Object.getPrototypeOf(Object.getPrototypeOf([][Symbol.iterator]()));+const AsyncIteratorPrototype = Object.getPrototypeOf(Object.getPrototypeOf(async function* () {}).prototype);

These exports could be removed now; should they be?

ninevra

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentjsdom/webidl2js

Allow injecting correct realm's AsyncIteratorPrototype

 function initCtorRegistry(globalObject) {     ctorRegistry[`%${intrinsic}%`] = globalObject[intrinsic];   } -  // TODO: Also capture `%AsyncIteratorPrototype%`+  ctorRegistry["%Object.prototype%"] = globalObject.Object.prototype;   ctorRegistry["%IteratorPrototype%"] = Object.getPrototypeOf(     Object.getPrototypeOf(new ctorRegistry["%Array%"]()[Symbol.iterator]())   );

Should I add fallbacks for "%IteratorPrototype%", "%Object.prototype%", and/or "%Array%" too?

ninevra

comment created time in 2 months

push eventninevra/webidl2js

ninevra

commit sha 50c73795e8ef875443b2d83bd94e6beb1526183a

Remove eval from tests

view details

ninevra

commit sha 02dcb6762bc9a248fb1bb44eb34c87bd4ff505af

Remove blank line

view details

push time in 2 months

push eventninevra/webidl2js

ninevra

commit sha c56aeae67ff8c89809eefd39f1a2c5ee77beb77d

Remove unused error variable

view details

push time in 2 months

push eventninevra/webidl2js

ninevra

commit sha 268fc9d6e4d66e40ef706136cca35c2020f26401

Capture Object.prototype directly

view details

ninevra

commit sha 682cc7dc3ca02a4082e3612c07099b44dd13b206

Use fallback AsyncIteratorPrototype if eval fails

view details

push time in 2 months

pull request commentjsdom/jsdom

Implement streams by adopting the reference implementation

Okay, I'll continue with using this._globalObject.Promise for now then, and see what tests fail.

@TimothyGu pointed out in https://github.com/jsdom/webidl2js/pull/247#discussion_r664901035 that we actually often need to capture properties of intrinsics, like Object.prototype. I think that's true here as well, that we have to capture Promise.prototype.then, because either Promise or Promise.prototype could get modified by the user. That seems like a strong argument in favor of an Impl.install() hook and/or a general rewriting approach like you suggest, rather than my original suggestion of capturing a partial list of intrinsics in webidl2js.

ninevra

comment created time in 2 months

Pull request review commentjsdom/webidl2js

Allow injecting correct realm's AsyncIteratorPrototype

 function define(target, source) {   } } +function newObjectInRealm(globalObject, object) {+  const ctorRegistry = initCtorRegistry(globalObject);+  return Object.defineProperties(+    Object.create(ctorRegistry["%Object%"].prototype),

Good catch!

ninevra

comment created time in 2 months

PullRequestReviewEvent

pull request commentjsdom/jsdom

Implement streams by adopting the reference implementation

In order to fix the Promise prototype, impls need to be able to access their relevant realm's Promise intrinsic (not just this._globalObject.Promise).

Can you explain how these are different?

The spec wants you to use current realm, not relevant realm. But getting the current realm is hard with current architecture, as discussed in #2727.

However the relevant global object should be the same as this._globalObject, so I think this._globalObject.Promise should work, as long as we compromise by saying relevant is good enough.

The issue is that user code can mess with this._globalObject, so this._globalObject.Promise can be an arbitrary user-defined value, whereas streams are only supposed to create actual Promises. Basically it's the difference between the initial value of this._globalObject.Promise and the current value.

There's some web-platform-tests that mess with globalThis.Promise and globalThis.Promise.prototype.then to make sure they don't affect the promises returned by streams (e.g. readable-streams/patched-global.any.js); using this._globalObject.Promise causes those to fail.

The current implementation passes these tests because it uses wrong-realm Promises; adopting in-realm promises should require capturing both Promise and Promise.prototype.then before the user can modify them (which is what the reference implementation does, though its method for doing that won't work here).

ninevra

comment created time in 2 months

pull request commentwhatwg/streams

Fix reference implementation's ReadableStream{Default,BYOB}ReadResult.webidl

PR submitted: https://github.com/whatwg/participant-data/pull/38.

ninevra

comment created time in 2 months