2024-01-03 [10:50:51.0541] we cancelled today's meeting, right? [10:50:52.0929] i don't remember [10:51:57.0407] yup [10:52:33.0328] and it's not in the TC39 Events Calendar [10:52:42.0503] thanks 2024-01-07 [14:57:40.0796] shu: do you want to stamp https://github.com/tc39/ecma262/pull/3163#issuecomment-1730375160 or should we just land it [14:57:45.0656] it is a very minor tweak 2024-01-10 [14:26:48.0483] will be a few mins late 2024-01-11 [08:50:00.0534] some of the aliases in `%TypedArray%.prototype.slice`: `count`, `len`, `final`, `limit`, and a long-lived single-letter alias `k` [08:50:12.0042] this would be so much easier to follow with more descriptive aliases [08:51:04.0332] agree, but not as part of the bugfix PR [09:38:40.0854] of course [09:38:52.0080] https://github.com/tc39/ecma262/pull/3245 is ready to stamp now I think 2024-01-17 [13:35:43.0244] i'll be 10 minutes late again, hopefully no more [13:36:00.0273] have a weird meeting slot that's 2:20-2:40pm [14:25:46.0312] Michael Ficarra and I will wait until 2:40 to show up then 2024-01-23 [13:18:54.0835] Michael Ficarra: IBM plex just did a release which closed the issue with the weird `#`: https://github.com/IBM/plex/pull/555 [13:19:07.0418] presumably as a variant glyph [13:19:10.0374] you want to update the fonts? [13:36:28.0882] I'm not especially motivated to spend my time that way 2024-01-24 [11:15:49.0888] how would this have even happened? https://github.com/tc39/ecma262/issues/3267 [11:16:04.0859] it's not like a column got cut off because of page width [11:16:39.0119] oh i suppose the table bled across the page break, so Allen manually broke it up and missed a row [11:17:48.0277] that or a bug in the preview of paged.js vs the print-to-pdf function in the browser [11:18:30.0831] I know this because literally yesterday I had a printed book show up at my door which I made with paged.js which was missing lines of text at the bottom of a couple pages and it turned out to be because those lines were present in paged.js's preview but not in the PDF generated by doing print-to-pdf from that page [11:18:43.0660] ha [11:18:49.0544] i mean, sorry about your misprinted book [11:19:08.0531] it was only $10 and only for me, not actually a problem [11:20:02.0813] that seems pretty affordable [12:49:53.0883] yeah this is likely from allen manually splitting tables across pages and repeating the headers [13:41:08.0406] every use of `IteratorStep` in the spec except for elisions in array bindings (`[a, /*hole*/, b] = iterable`) is immediately followed by `"if _result_ is false; do something; else do IteratorValue(_result_)`. places that have special abrupt completion handling (e.g. `PerformPromiceRace`) duplicate the logic for the `IteratorStep` and `IteratorValue` cases. this is silly. we should make a version of `IteratorStep` which does the `IteratorValue` itself and returns a completion with either `~done~` or `result.value`. [13:41:38.0843] i.e. `IteratorStep` should unwrap the value itself in the not-finished case, instead of making the caller do it [13:48:13.0534] before and after [15:17:22.0522] omg it actually is... [15:28:02.0279] F [15:49:47.0561] i'm confused, why was your flight from denver to SF going to be routed through san diego [15:50:53.0372] we were talking about check the SD flights for using the Boeing MAXes since they're grounding them close to the actual day of the flight, not beforehand [15:51:07.0781] so if you're flying on a route that uses those you'll likely get cancelled on and have to rebook last minute [15:52:10.0844] oh shit, gotcha 2024-01-25 [18:27:56.0136] https://github.com/tc39/ecma262/pull/3268 2024-01-26 [12:59:49.0404] we have 3 places where we do "1. If foo is an abrupt completion, do some stuff and return. 2. Set foo to foo.[[Value]]". thoughts on replacing the second line those case to "Set foo to ! foo"? [13:00:15.0703] i'd like that very much [13:10:38.0946] https://github.com/tc39/ecma262/pull/3273 2024-01-28 [12:46:26.0776] shu: am i right that step 1 of https://tc39.es/ecma262/#sec-arraybufferbytelength could also be achieved by using IsFixedLengthArrayBuffer()? (and perhaps checking both slots in there, since the ArrayBufferByteLengthData slot is what's used in the AO) 2024-01-29 [19:57:29.0124] ljharb: the second half of the check, you mean? you can check for IsSharedArrayBuffer and !IsFixedLengthArrayBuffer, that currently implies the object must have a [[ArrayBufferByteLengthData]] internal slot [19:57:51.0014] but i don't see why you wouldn't check for the slot directly instead of obfuscating it via an implication from another slot [19:58:40.0026] to me it conveys the meaning better; i had to search for the slot to figure out why it was checking that [19:58:53.0086] but gotcha [12:02:56.0865] yeah i can see going both ways on that preference [12:03:34.0606] we got rid of actual brands (i.e. internal slots that serve no other purpose than as indicators of what type something is), but we don't always check for a slot that we're going to be using [12:03:52.0486] sometimes we use brand-like AOs that pick a slot as the brand-like slot [12:26:07.0167] the global object could be a proxy, couldn't it? [15:21:27.0533] also, transfer will add IsResizableBuffer which perhaps could be used in more places [15:23:37.0648] why is it adding IsResizableBuffer? [15:23:59.0902] IsResizableBuffer was changed to the negation (IsFixedLengthArrayBuffer) for better readability in a lot of algorithms [15:25:36.0006] also https://github.com/tc39/ecma262/pull/3175 doesn't add that AO currently 2024-01-30 [16:30:28.0239] oh hm, maybe i have it in my polyfill from before it was changed, i'll update [16:32:03.0085] shu: separately, i'm implementing the changes to SetTypedArrayFromArrayLike in ES2024, and only one of my tests is starting to fail - it's basically this: ``` var ta = new Uint8Array([1, 2, 3]); var obj = { length: 1 }; Object.defineProperty(obj, '0', { get: function () { ES.DetachArrayBuffer(ta.buffer); return 10; } }); t.throws( function () { ES.SetTypedArrayFromArrayLike(ta, 1, obj); }, TypeError, 'when a Get detaches the buffer, it throws' ); ``` is it possible that there's an issue in the algorithm where it's missing a detachedness check? [16:32:34.0804] * shu: separately, i'm implementing the changes to SetTypedArrayFromArrayLike in ES2024, and only one of my tests is starting to fail - it's basically this: ``` var ta = new Uint8Array([1, 2, 3]); var obj = { length: 1 }; Object.defineProperty(obj, '0', { get: function () { ES.DetachArrayBuffer(ta.buffer); return 10; } }); t.throws( function () { ES.SetTypedArrayFromArrayLike(ta, 1, obj); }, TypeError, 'when a Get detaches the buffer, it throws' ); ``` is it possible that there's an issue in the algorithm where it's missing a detachedness check? [16:37:10.0094] * shu: separately, i'm implementing the changes to SetTypedArrayFromArrayLike in ES2024, and only one of my tests is starting to fail - it's basically this: ``` var ta = new Uint8Array([1, 2, 3]); var obj = { length: 1 }; Object.defineProperty(obj, '0', { get: function () { ES.DetachArrayBuffer(ta.buffer); return 10; } }); t.throws( function () { ES.SetTypedArrayFromArrayLike(ta, 1, obj); }, TypeError, 'when a Get detaches the buffer, it throws' ); ``` is it possible that there's an issue in the algorithm where it's missing a detachedness check? (obv, there's always a chance the bug is in my impl, but it's pretty 1:1 with the spec text) [16:38:19.0557] why do you think it should throw? [16:38:29.0167] like, which step do you think should be throwing [16:38:36.0491] because it threw with the previous spec text [16:38:46.0206] ah [16:38:52.0526] so maybe it's just a spec bug that's now fixed, i haven't compared it to real TA code yet [16:39:47.0351] i mean i do see that SetTAFAL calls Get (which in this case detaches), and then it calls TypedArraySetElement, which then calls SetValueInBuffer, which then checks IsDetachedBuffer, which would throw [16:40:02.0686] i don't really know why it would throw previously [16:40:27.0713] because the Get detaches it, right before it tries to Set to a detached buffer. shouldn't (doesn't) it throw now too? [16:40:29.0041] ah, but see step 3 here: https://tc39.es/ecma262/#sec-typedarraysetelement [16:40:44.0198] if it's not a valid index (which no index would be, if the buffer is detached), that AO just no-ops [16:40:49.0417] ohhhhhhhh [16:40:57.0216] this was part of the reality alignment changes that rkirsling did a while back [16:41:02.0274] but that should predate es2024 for sure [16:41:33.0705] hm, ok, maybe it's a bug in my earlier implementations too then. but that suggests that at some point, the spec said to throw for this test but impls did not? [16:42:04.0939] yes, the TA stuff is famously out of sync with impl reality since it was imported from Khronos [16:42:13.0827] which is why ross proposed those changes [16:42:46.0418] thanks for confirming, i can dive in from here. it's probably that SetTAFromArrayLike changed at some point before 24, and i failed to update my impl to match [16:42:48.0924] famously out of sync with impl reality, specifically on what throws on detached and what no-ops, and what returns 0 etc [17:06:16.0243] https://github.com/tc39/ecma262/pull/2164 specifically: > IsDetachedBuffer checks should not cause the following to throw: [...] > IntegerIndexedElementSet (i.e. [[DefineOwnProperty]] and [[Set]] for typed arrays) [19:32:51.0079] should we back out https://github.com/tc39/ecma262/pull/3249 so we can land other stuff? [19:33:07.0543] that person does not appear to be active on github much [19:34:11.0334] yeah true. i can push up an exception for them rather than backing it out tho, if you want [19:34:53.0473] also i'll look into adding a status check that fails if the commit email address doesn't link to the PR's github user, since that's caused us problems a few times [19:38:25.0685] i'll just push up the exception [19:38:58.0742] wfm, but then I have never felt that it made sense to apply the contributing policy to changes like this [19:41:36.0329] also fair [19:42:12.0698] it would be interesting to figure out if the policy is only needed for normative changes - that would skip the nonsense pretty consistently [13:41:06.0460] In the November editors' report, on the [upcoming work](https://docs.google.com/presentation/d/14oO9ACSx66ChJK-5-dxhuKYmmh5XFaE1uC_4MS6tcEw/edit?pli=1#slide=id.g719821a82a_3_0) page, the item "#2085 & others: replace complex spec values with spec records" is struck-through "because we have now finally finished the work of making all internal values consistent. We now use records everywhere." [13:41:20.0227] But there's still [Execution Contexts](https://github.com/tc39/ecma262/pull/2246) and [Declarative Env Records](https://github.com/tc39/ecma262/pull/2288). [13:41:50.0565] (And maybe some others.) [15:43:18.0441] ah, yeah [15:43:30.0511] I was mostly thinking of the regex cases but you're right there's still a couple others 2024-01-31 [13:48:18.0334] https://github.com/tc39/ecmarkup/pull/571 [15:42:44.0636] Michael Ficarra: another thing you could do for your centering visual preference is to give the margins a slightly different color, or to give the main content column a different color [15:42:48.0535] some version of light grey somewhere [15:46:12.0750] I'll try it [15:46:34.0297] TEN YEARS behind a flag smh