2025-05-01 [05:58:23.0650] I'll use the time to review your node PR [08:05:05.0319] Thanks that would be great! [08:20:54.0165] https://github.com/tc39/ecma262/issues/3582 I think I found a bug with module evaluation, but I think it's a regression [08:22:04.0529] * https://github.com/tc39/ecma262/issues/3582 I think I found a bug with module evaluation [09:48:28.0215] good catch, it seems like we either need to clarify that it can be unset for errored modules, or to set it to some arbitrary value in this case [09:55:35.0698] another approach might be to move the CycleRoot set into the linking algorithm, but this would imply creating a proper equivalence between DFS for link and DFS for evaluate which doesn't currently exist [09:56:50.0390] The algorithm as written though, never did proper state transitions on error in evaluate (DFS transitions), and that was a property from the start. Sticking with that model would effectively mean just saying [[CycleRoot]] can be unset... [09:57:09.0378] I'm pretty sure this doesn't affects any real execution paths fwiw [10:23:03.0169] I opened https://github.com/tc39/ecma262/pull/3583, which defaults it to the module itself, and I _think_ it's fine to do it in the error case [11:09:07.0954] Yeah I'm pretty sure that works, as an import to any module in an errored cycle should still find that error and throw it before trying further evaluations. [11:36:43.0617] nicolo-ribaudo guybedford as the only two people in the world who have this machinery in their heads, any ideas for editorially improving understanding? [11:37:07.0603] i was thinking maybe an interactive example? [11:37:12.0811] how do people teach graph algorithms? [11:38:02.0158] i learned graphs from dr greibach, who taught on transparencies... 2025-05-02 [23:35:33.0449] The problem is that this is not just a graph, but each node has also a ton of different states, and for evaluation they are _all_ relevant [23:36:16.0330] I do have an interactive example (linked to in that PR), maybe I could join the next editors call and we could consider how to embed smaller versions of it in the spec, together with the existing examples? [01:52:14.0268] shu Maybe another approach would be to make [[Status]] an enum with a payload, like Rust enums, so that the various slots are only available when they are relevant, and they transition more atomically. e.g. given that [[AsyncEvaluationOrder]] is only relevant while a module is evaluating-async, it would be used as `If _module_.[[Status]] is an AsyncEvaluationState Record, use _module_.[[Status]].[[AsyncEvaluationOrder]]` [01:52:51.0357] Or like, [[EvaluationError]] would be defined on the EvaluatedState Record [01:56:58.0700] Or maybe we could draw some sort of state machine representing the various valid intermediate states that modules go through during the process, and how they transition between them [02:21:26.0438] * shu Maybe another approach would be to make \[\[Status\]\] an enum with a payload, like Rust enums, so that the various slots are only available when they are relevant, and they transition more atomically. e.g. given that \[\[AsyncEvaluationOrder\]\] is only relevant while a module is evaluating-async, it would be used as `Assert: _module_.[[Status]] is an AsyncEvaluationState Record. Use _module_.[[Status]].[[AsyncEvaluationOrder]]` [02:53:04.0063] I opened a PR with a test262 test for a top-level await case that was not previously covered, if anybody has time please review :) https://github.com/tc39/test262/pull/4465 [08:14:57.0875] it'd be very late for you in CET, but would be appreciated 2025-05-05 [15:56:06.0043] As per usual, if anyone has anything for the agenda this week, please add it to the minutes document for us to schedule the meeting. 2025-05-06 [14:28:06.0313] I’m hoping to participate in Module Harmony more as the year progresses. But, the current recurring meeting time continues to overlap a block of reserved parenting time. +1hr is much more feasible. +2hr is absolutely feasible. I am hoping to make progress on import hooks, which has some remaining decision axes. [14:29:43.0663] When I start at Cloudflare in a couple of weeks - then as soon I've got a handle on my schedule I was hoping to finally look into the meeting timing again, so I'm hopeful we can figure out a crossover soon 2025-05-08 [19:26:20.0988] It looks like we do have an agenda item for tomorrow for modules in engine-262, happy to discuss that if we have critical mass for the meeting, although I'm also not sure who added that one [23:09:31.0185] It was me :) [23:09:39.0859] But it's not urgent [23:10:40.0112] ah, shall we perhaps bump to next week? [23:11:26.0628] Sure [23:12:33.0044] unless it's urgent or you want to run it, might make sense while the agenda is shorter [23:16:11.0863] It would probably fit in 15 minutes [23:19:00.0926] we can discuss it if it would be useful sooner, we just need to make a decision for the meeting tomorrow [23:23:02.0674] Ok let's wait until there is more content so we can fill the hours. I also will have a topic for some editorial aspects of modules in 262, but I'm not ready to present it tomorrow [23:23:15.0428] * Ok let's wait until there is more content so we can fill the hour. I also will have a topic for some editorial aspects of modules in 262, but I'm not ready to present it tomorrow [23:25:23.0505] okay, unless something else comes up let's skip the meeting tomorrow then, and then pick back up again from next week. Will update the agenda item for next week. 2025-05-10 [22:17:10.0921] Just found a JSON import reexport crash in Firefox :( https://bugzilla.mozilla.org/show_bug.cgi?id=1965620 2025-05-13 [10:20:49.0424] Even Stensberg: welcome aboard. I expect this to be the group of people who will be most interested in selling you and being sold ideas relevant to bundling/webpack. Have you seen our brochure? [10:46:21.0594] I have not! [10:46:53.0217] The brochure is a metaphor. I invite folks to share their proposals 😉 [10:47:07.0663] I’m champion on various module loader hook proposals. [10:47:23.0362] I'm very new to the org, so any resource link to read up on the glossary etc would be great [10:47:27.0513] And I have a great need to dust them off https://signal.me/#eu/tcbGqRxd4pIDtLZ0D3ZyOPO0OJeL6dRiZDIvXEJSW0GpcoYT3eBPuJXwmnY252MN [10:47:52.0215] nicolo-ribaudo has the most recent renderings of our tech tree [10:48:07.0229] this was my “birds eye view” some years ago https://github.com/tc39/proposal-compartments/blob/master/GRAPH.md [10:49:57.0738] guybedford (Guy Bedford) has done a lot to push for `import source` and `ModuleSource` constructor. This lays the ground for an `import` hook, which would either take the form of an option on `ModuleSource` or a new `Module` constructor that combines a `source` with hooks. [10:51:40.0285] Guy and Luca Casonato are frequent collaborators. I work most closely with Mathieu Hofman and Richard Gibson and we are largely motivated by the https://hardenedjs.org/ project and having shared foundations for safe module loading in sub-realm sandboxes. [14:07:15.0753] Even Stensberg: Welcome, and great to see you here! I would encourage joining the meeting on Thursday morning. Happy to have discussion then. In terms of proposal progress, we don't have a recent module harmony status summary, short of the current proposal progressions. It could definitely be worth discussing the current status further though as well. 2025-05-14 [01:10:16.0252] hi Even Stensberg I'd be happy to give you a longer intro to the sub-realm sandboxes usecases (with specific links to Webpack) 2025-05-15 [07:55:25.0951] I'm not gonna make it today; sorry for the late notice 2025-05-22 [11:03:19.0743] engine262 PR for import defer: https://github.com/engine262/engine262/pull/295 [11:05:58.0719] I plan to also work on a proof-of-concept showing how some implementations could implement lazy loading of sources if they pre-analyzed the graph 2025-05-28 [06:31:57.0463] should i cancel this week's meeting, since it's plenary week?