pygy Github contribution chart
pygy Github Stats
pygy Most Used Languages

Activity

05 Sep 2022

Issue Comment

Pygy

Custom elements: built-in element extensions lose their `is` attribute

As demonstrated here, a custom element that extends a built-in via the is attribute behaves strangely. The extension is recognised and the custom element is constructed as expected; but the is attribute that determined this behaviour is not present on the rendered element. Having been specified in hyperscript, I would expect it to remain.

Forked On 05 Sep 2022 at 11:32:54

Pygy

As long as we deal with [is], we have a render bug in the update phase. is should be considered part of the element identity along with the tag name when diffing.

Commented On 05 Sep 2022 at 11:32:54
Issue Comment

Pygy

Equality semantics for `-0` and `NaN`

What should each of the following evaluate to?

#[+0] == #[-0];

#[+0] === #[-0];

Object.is(#[+0], #[-0]);

#[NaN] == #[NaN];

#[NaN] === #[NaN];

Object.is(#[NaN], #[NaN]); 

(For context, this is non-obvious because +0 === -0 is true, Object.is(+0, -0) is false, NaN === NaN is false, and Object.is(NaN, NaN) is true.)

Personally I lean towards the -0 cases all being false and the NaN cases all being true, so that the unusual equality semantics of -0 and NaN do not propagate to the new kinds of objects being introduced by this proposal.

Forked On 27 Aug 2022 at 12:17:06

Pygy

@papb re. typing IEEE Floats are effectively a Maybe number (number | NaN in a parallel world where TS would have typed them as such) type, with NaN as the Nothing type.

TS could keep track of the operations that can return NaN, make math ops generic, and have them return number | NaN unless they can statically prove that the result isn't NaN.

Commented On 27 Aug 2022 at 12:17:06
Issue Comment

Pygy

Equality semantics for `-0` and `NaN`

What should each of the following evaluate to?

#[+0] == #[-0];

#[+0] === #[-0];

Object.is(#[+0], #[-0]);

#[NaN] == #[NaN];

#[NaN] === #[NaN];

Object.is(#[NaN], #[NaN]); 

(For context, this is non-obvious because +0 === -0 is true, Object.is(+0, -0) is false, NaN === NaN is false, and Object.is(NaN, NaN) is true.)

Personally I lean towards the -0 cases all being false and the NaN cases all being true, so that the unusual equality semantics of -0 and NaN do not propagate to the new kinds of objects being introduced by this proposal.

Forked On 11 Aug 2022 at 07:49:02

Pygy

The surprises for NaN and -0 fundamentally lie in the IEEE-754 spec, and the additional complexity added by how JS handles them (e.g. String(-0) === '0').

How surprising these are depends on how acquainted coders are with those intricacies.

My guess would be that the median dev is not at all familiar with any of this (e.g. I just discovered that the default JSON stringifier culls the minus sign of -0, whereas JSON.parse respects the minus sign), and diking the values out of new parts of the language would be a net improvement for code reliability.

Commented On 11 Aug 2022 at 07:49:02
Issue Comment

Pygy

No data on July 21, and for the last 48 hours

Hey Paul,

It looks like npm-stat.com hasn't been getting fresh data for the last two days. Also, data for July 21 is susiciously low (0) all across the board

This is what I see for React: .

Forked On 10 Aug 2022 at 02:58:59

Pygy

Ah, ok, sorry for the noise.

Commented On 10 Aug 2022 at 02:58:59
Issue Comment

Pygy

Equality semantics for `-0` and `NaN`

What should each of the following evaluate to?

#[+0] == #[-0];

#[+0] === #[-0];

Object.is(#[+0], #[-0]);

#[NaN] == #[NaN];

#[NaN] === #[NaN];

Object.is(#[NaN], #[NaN]); 

(For context, this is non-obvious because +0 === -0 is true, Object.is(+0, -0) is false, NaN === NaN is false, and Object.is(NaN, NaN) is true.)

Personally I lean towards the -0 cases all being false and the NaN cases all being true, so that the unusual equality semantics of -0 and NaN do not propagate to the new kinds of objects being introduced by this proposal.

Forked On 10 Aug 2022 at 11:45:35

Pygy

Both are weird, but rejecting them at construction time has the advantage of making the surprising behavior obvious, while having unusual equality semantics can lead to subtle bugs.

Commented On 10 Aug 2022 at 11:45:35
Issue Comment

Pygy

Event binding & DOM property hints for `attrs` input

Some forks of the hyperscript function recognise lifecycle methods as potential matches on the attrs input, but other than that, AFAICT, the interface is an Any — so unless the author is reaching for a lifecycle method, the contents of attrs are completely freeform, with no hints.

But there is a lot of further domain complexity to what can be described in attrs, and we could make the IDE experience much more powerful out of the box by providing hints for authors that describe some of these domains.

The matching sequence for Attrs ought IMO to behave as follows for the DOM element fork of the hyperscript function (non-element hyperscript forks are not affected by this proposal):

LifecycleMethod | Style | EventHandler | ElementProperty | Any 
  • The remaining magic attribute, key, is of type Any anyway so merits no special consideration.
  • ElementProperty is AFAICT directly referencible via TypeScripts built-ins (Element is used to qualify vnode.dom in current types).
  • Style is its own discrete type, @panoply has this covered in #46
  • EventHandler is the type I think would bring the most value 👇

@BoazBlake spent a while looking for some logic design mistake in some code; but eventually it turned out to be an easily-missed typo — onclick: {/*contents*/} instead of onclick: () => {/*contents*/}. Exposing the type semantics for on-prefixed keys as being proxied to the DOM EventHandler interface would have caught this early. It turns out this is possible in TypeScript using the recent syntax addition:

interface ElementAttributes extends Element {
  [k: `on${string}`]: EventHandler,
  ...
} 

I’ve never written TypeScript day to day but figure we could merge something like that 👆 into a rewritten Attributes.

If we can merge these things together without building an inheritance hierarchy, so much the better.

@spacejack what do you think?


External sources:

  1. The Mithril chat conversation that gave rise to this issue https://mithril.zulipchat.com/#narrow/stream/326810-help/topic/.E2.9C.94.20Spot.20the.20error/near/291786300
  2. My TypeScript chatroom help request thread on this subject https://discord.com/channels/508357248330760243/942074070860705852/1004379612387737670
  3. TypeScripts property key string matching feature announcement https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-4.html#symbol-and-template-string-pattern-index-signatures
  4. TypeScripts built-in DOM types https://github.com/microsoft/TypeScript/blob/main/lib/lib.dom.d.ts

Forked On 05 Aug 2022 at 04:28:56

Pygy

IIRC, the | operator is not ordered in TS, and any swallows narrower types.

Commented On 05 Aug 2022 at 04:28:56
Issue Comment

Pygy

Event binding & DOM property hints for `attrs` input

Some forks of the hyperscript function recognise lifecycle methods as potential matches on the attrs input, but other than that, AFAICT, the interface is an Any — so unless the author is reaching for a lifecycle method, the contents of attrs are completely freeform, with no hints.

But there is a lot of further domain complexity to what can be described in attrs, and we could make the IDE experience much more powerful out of the box by providing hints for authors that describe some of these domains.

The matching sequence for Attrs ought IMO to behave as follows for the DOM element fork of the hyperscript function (non-element hyperscript forks are not affected by this proposal):

LifecycleMethod | Style | EventHandler | ElementProperty | Any 
  • The remaining magic attribute, key, is of type Any anyway so merits no special consideration.
  • ElementProperty is AFAICT directly referencible via TypeScripts built-ins (Element is used to qualify vnode.dom in current types).
  • Style is its own discrete type, @panoply has this covered in #46
  • EventHandler is the type I think would bring the most value 👇

@BoazBlake spent a while looking for some logic design mistake in some code; but eventually it turned out to be an easily-missed typo — onclick: {/*contents*/} instead of onclick: () => {/*contents*/}. Exposing the type semantics for on-prefixed keys as being proxied to the DOM EventHandler interface would have caught this early. It turns out this is possible in TypeScript using the recent syntax addition:

interface ElementAttributes extends Element {
  [k: `on${string}`]: EventHandler,
  ...
} 

I’ve never written TypeScript day to day but figure we could merge something like that 👆 into a rewritten Attributes.

If we can merge these things together without building an inheritance hierarchy, so much the better.

@spacejack what do you think?


External sources:

  1. The Mithril chat conversation that gave rise to this issue https://mithril.zulipchat.com/#narrow/stream/326810-help/topic/.E2.9C.94.20Spot.20the.20error/near/291786300
  2. My TypeScript chatroom help request thread on this subject https://discord.com/channels/508357248330760243/942074070860705852/1004379612387737670
  3. TypeScripts property key string matching feature announcement https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-4.html#symbol-and-template-string-pattern-index-signatures
  4. TypeScripts built-in DOM types https://github.com/microsoft/TypeScript/blob/main/lib/lib.dom.d.ts

Forked On 05 Aug 2022 at 08:12:24

Pygy

+1 for [k: on${string}]: EventHandler if we can pull it out.

IIRC X | any coalesces to any so we'd have to be a bit smarter with this (maybe using negative logic to exclude the keys that are on the the other types).

But going loose with ElementProperties and a generic fallback seems like a reasonable route.

Otherwise, we'd need specialized types for every HTML and SVG element. This could probably be automated from IDLs. Also, we'd need to special case for and class (or more broadly take into account the HTML spec). If we were to go the strict route, [k: data-${x}]: any] could be used for custom attrs. Not sure going strict would be a good idea though.

Commented On 05 Aug 2022 at 08:12:24

Pygy

'2021 roadmap' => 'current roadmap', en-US + fr

Created On 28 Jul 2022 at 08:45:36
Create Branch
Pygy In pygy/www.rust-lang.org Create Branchfix-1699

Pygy

The home of the Rust website

On 28 Jul 2022 at 08:45:00
Issue Comment

Pygy

The governance page still links to the 2021 roadmap

What needs to be fixed?

The roadmap link is stale. I'm not following the Rust dev process closely, and I couldn't find a 2022 roadmap in the RFC repo... I suppose this is the new home for the roadmap.

Page(s) Affected

https://www.rust-lang.org/governance

Suggested Improvement

Since this is a recurring issue (#846 #1007 #1328), it may be worthwhile to bake an expiration date into the build script, after which the roadmap section is automatically removed from the site and a warning is issued.

Forked On 28 Jul 2022 at 06:42:30

Pygy

Ok, I'll send a PR later this evening for French and English, and I'll have a look at pontoon (not familiar with the platform).

Commented On 28 Jul 2022 at 06:42:30
Issue Comment

Pygy

The governance page still links to the 2021 roadmap

What needs to be fixed?

The roadmap link is stale. I'm not following the Rust dev process closely, and I couldn't find a 2022 roadmap in the RFC repo... I suppose this is the new home for the roadmap.

Page(s) Affected

https://www.rust-lang.org/governance

Suggested Improvement

Since this is a recurring issue (#846 #1007 #1328), it may be worthwhile to bake an expiration date into the build script, after which the roadmap section is automatically removed from the site and a warning is issued.

Forked On 28 Jul 2022 at 05:59:11

Pygy

This is understandable. https://github.com/rust-lang/www.rust-lang.org/graphs/contributors tells the story, I should have looked first, I assumed that the Web site was actively maintained.

I can change the en-US and fr text to say "latest".

How do I proceed for the other translations? Is it ok to ping the folks who did them? If so, I could open a PR with my translations, and ask the translators to open PRs on my fork/branch with theirs, and I'll ping you once all of them are done.

Commented On 28 Jul 2022 at 05:59:11
Issue Comment

Pygy

The governance page still links to the 2021 roadmap

What needs to be fixed?

The roadmap link is stale. I'm not following the Rust dev process closely, and I couldn't find a 2022 roadmap in the RFC repo... I suppose this is the new home for the roadmap.

Page(s) Affected

https://www.rust-lang.org/governance

Suggested Improvement

Since this is a recurring issue (#846 #1007 #1328), it may be worthwhile to bake an expiration date into the build script, after which the roadmap section is automatically removed from the site and a warning is issued.

Forked On 28 Jul 2022 at 02:56:31

Pygy

Indeed... The problem, if there's one may lie in the "2021" part of the name then...

As it is, it looks like an oversight.

Commented On 28 Jul 2022 at 02:56:31
Issue Comment

Pygy

The governance page still links to the 2021 roadmap

What needs to be fixed?

The roadmap link is stale. I'm not following the Rust dev process closely, and I couldn't find a 2022 roadmap in the RFC repo... I suppose this is the new home for the roadmap.

Page(s) Affected

https://www.rust-lang.org/governance

Suggested Improvement

Since this is a recurring issue (#846 #1007 #1328), it may be worthwhile to bake an expiration date into the build script, after which the roadmap section is automatically removed from the site and a warning is issued.

Forked On 28 Jul 2022 at 02:15:40

Pygy

The @Manishearth shouldn't the link to the past roadmap be removed altogether then ?

Commented On 28 Jul 2022 at 02:15:40

Pygy

Grammar fix for the French translation. See #1647

Created On 28 Jul 2022 at 01:01:56
Create Branch
Pygy In pygy/www.rust-lang.org Create Branchfix-1647

Pygy

The home of the Rust website

On 28 Jul 2022 at 01:00:41

Pygy

Fix the roadmap link for 2024

Created On 28 Jul 2022 at 12:50:15
Create Branch
Pygy In pygy/www.rust-lang.org Create Branchroadmap2024

Pygy

The home of the Rust website

On 28 Jul 2022 at 12:35:37

Pygy

The home of the Rust website

Forked On 28 Jul 2022 at 12:34:41