08:06
<Mathieu Hofman>
I think the difference is that one (OOMs, panic) is dependent on actions taken by the program, where the other one (solar flares) isn't. For the latter it's the mere existence of the program that maters most, not what it did. The line blurs a little bit for OS OOM killers, but my understanding is that this is fatal to the agent cluster anyway.
13:57
<ryzokuken>
@room starting in >3 mins
14:00
<snek>
matrix pls mark this channel read
14:01
<sffc>
Working on connecting...
14:10
<Richard Gibson>
matrix: Yes, I have marked this channel red.
14:11
<ryzokuken>
sorry this functionality doesn't exist for your client
14:11
<snek>
i wish "mark as read" actually did something 😔
14:11
<shu>
jesus i've seen what you've done marking other channels as read and i want it for this channel
14:14
<nicolo-ribaudo>
I just managed to get the number of unread messages in this channel down from 4 to 1 by opening all the old threads in the right sidebar
14:15
<Chengzhong Wu>
tip: there is a button "Mark as read" hidden in the channel list "..." menu. It also marks unread subthreads as read
14:17
<ryzokuken>
the threads interaction is usually what makes the "mark as read" action not work as expected. Another way to fix that is to enable the threads activity center which gives you a popup on the bottom left with all unread threads
14:17
<Jesse>
still working on getting down to 4 digits
14:18
<snek>
in particular its not dismissing mentions in this channel (the two i had above for example). threads unrelated. only way is to send a message :(
14:27
<Aki>
Y'all if you have a topic on the agenda this meeting, please consider taking a session or two editing the notes.
14:40
<shu>
code unit order is well defined too, isn't it?
14:43
<Michael Ficarra>
@shu for systems that have encoded the same string in UTF-16, yes
14:43
<shu>
then i guess that's the same question as my one on the queue
14:43
<shu>
i don't really get the portability
14:44
<Michael Ficarra>
portability to systems that use another encoding and don't want to transcode to UTF-16 to figure out sort order?
14:45
<shu>
but your problem is that we don't have utf16, not the sort order?
14:45
<Andreu Botella>
most other systems use UTF-8 (or in the case of python, UTF-32)
14:45
<shu>
like the portability problem i'd have figured is that our strings can be malformed
14:46
<Michael Ficarra>
no I think that's a whole other issue that was not addressed here
14:46
<shu>
what is the portability problem around sort order
14:46
<Michael Ficarra>
I think the whole proposal was assuming well-formedness
14:47
<shu>
a concrete example would be good
14:47
<Andreu Botella>
most systems use UTF-8, and sort based on that (or in the case of python, it doesn't use UTF-8 but has an equivalent comparison)
14:47
<Andreu Botella>
most developers don't realize there's a mismatch
14:47
<shu>
give me an example
14:47
<shu>
where you sort some strings in JS, and then...
14:47
<Michael Ficarra>
oh I think I understand what you mean @shu: you're asking why they must sort identically on two systems that use different encodings?
14:48
<shu>
yeah, that's not a portability problem to me
14:48
<shu>
i understand different systems have different behaviors
14:48
<shu>
they're different systems!
14:48
<shu>
oh i see, the "portability" here means "portability of lack of surprise when workign with strings across different systems"?
14:48
<bakkot>
yes
14:48
<shu>
not like, code is in non-interoperable
14:48
<Michael Ficarra>
@shu imagine a page that is server-side rendered with a sorted list of things, then dynamically updated at runtime (say, to add an item) and completely re-orders instead of just appearing to add the one item
14:49
<bakkot>
it is good to be able to implement the same algorithm in JS as in other languages without huge pain
14:50
<Michael Ficarra>
I guess there could be interoperability concerns? If you're like hashing a sorted list, your hash will be different on systems that sort it differently
14:50
<bakkot>
also for me the motivation is not really performance; you could do this in userland the same way you can always do (a, b) => a - b but it's super painful
14:50
<bakkot>
this is a very natural way of sorting strings so it should be provided by the language
14:51
<littledan>
yeah I'm really not convinced that this function makes sense to add to JS
14:53
<bakkot>
littledan: because you don't think it comes up or because you think it's easy to do in userland or?
14:54
<littledan>
More the first one, and that it'll be used when it shouldn't be. But sorry I joined in the middle, should not have made such a confident comment, sounds like it maybe does come up
14:55
<nicolo-ribaudo>
When should this not be used? I guess maybe where performance matters, and the engine is encoding the string as UTF-16 and not as UTF-8?
14:55
<bakkot>
if you're not interoperating with other systems then you should not use this
14:55
<bakkot>
for performance reasons if nothing else
14:56
<bakkot>
(do any major engines encode as utf-8? I don't think so? some do one-byte representations for strings with only small codepoints but that's different)
14:57
<msaboff>
This seems like a reasonable and straightforward proposal. I think this would be usable for some devs.
14:57
<littledan>
it should definitely not be used when interacting with humans. The problem is that, when applied to English, it is almost usable.
15:00
<bakkot>
I want the thing Michael Ficarra is describing (a lexicographic comparator builder and a codepoint iterator) but I still want the thing described here even if we get those things
15:00
<Michael Ficarra>
that's totally fair @bakkot
15:01
<sffc>

I saw two use cases for sorting:

  1. A total ordering for use in a BTree-like data structure
  2. A human-readable ordering

(1) is better served by UTF-16 ordering. (2) is better-served by Intl.Collator.

But I'm reasonably convinced that given how common UTF-8 is on the Web and elsewhere in software, there is value for having a code point ordering function available in the JS standard library, in order to interoperate with those syetems.

15:02
<nicolo-ribaudo>

ryzokuken / Chris de Almeida If this takes less than one hour, the continuation of my topic from Monday has a 🔒️ but can be moved to the end of this slot

(assuming Mathieu Hofman will be online and read my answer on GitHub)

15:03
<ryzokuken>
thanks for the heads up
15:03
<Michael Ficarra>
a process discussion taking less than an hour? impossible!
15:03
<sffc>
Main risk from my POV is that I don't want developers to see this new shiny function and think they should generally be using it for sorting. It is useful for the fairly narrow use case of interoperating with these external systems.
15:03
<nicolo-ribaudo>
Well Michael said so 😛
15:04
<Mathieu Hofman>
Actually it isn't but I left the question of lone surrogate for stage 2. Spoiler: use their code unit value to sort them
15:05
<littledan>
if this is for interop with other systems, we'll get our answer pretty objectively
15:06
<bakkot>
I am inclined to treat them as replacement character for sorting purposes, and only use code unit value for breaking ties
15:06
<Michael Ficarra>
yeah, there's an obvious answer
15:06
<bakkot>
because when you convert to a string in the other system it's going to use the replacement character
15:06
<bakkot>
so if you want to match sort order that's how you have to sort
15:06
<Michael Ficarra>
🤔 replacement characters should only really be used when transcoding
15:08
<Mathieu Hofman>
catching up now, sorry things came up in the real world
15:10
<Mathieu Hofman>
I think this is not a real issue. We do have Intl.Collator.prototype.compare, and I expect this would be introduced in that context with use cases
15:11
<Andreu Botella>
the dev outreach, and MDN and so on, should give the three types of comparison and their use cases
15:23
<nicolo-ribaudo>
I got distracted (apparently I left the gas stove on for hours by accident), and I missed the discussion for the second point by Dan Minor. I agree that blocks based on process not being respected should have a lower bar
15:27
<Jesse>
can someone take over for me in the notes in ~5 min?
15:29
<shu>
i... think ecma exists to attract due-paying members?
15:29
<shu>
i don't think they exist to serve us
15:29
<Chris de Almeida>
how about this ecma rule:
15:29
<Chris de Almeida>
The agenda shall be made available to all members three weeks before each meeting
15:30
<shu>
oh man that'd be awesome
15:30
<ljharb>
serving us is what attracts due-paying members (TCs in general, but TC39 more than most)
15:30
<littledan>
we've repeatedly confirmed with the Ecma ExeCom that that can be overridden by TC's. I've proposed changing it and the response is, this isn't necessary.
15:31
<waldemar>
The vast majority of members are non-due-paying
15:31
<shu>
ljharb: what i mean is, let's stipulate IEs have exact same status. why would BigCo join instead of send all its employees as IEs?
15:31
<littledan>
the majority of TC39 participation is dues-paying, though
15:31
<ljharb>
oh sure. but per "any system can be gamed", if ecma sees that happen, they'll revoke the IE status
15:32
<shu>
i don't think "looking at this line in the opex chart to see if we should continue paying it" is even gaming it
15:32
<shu>
it happens as standard procedure every year
15:32
<littledan>
IEs are included in a way that's entirely contingent on Samina's discretion -- this is what the bylaws have always said. The current practice is to give people a year, and then see if they can be convinced to join Ecma.
15:32
<ljharb>
the openjs foundation (and its predecessors) route always made previous secretariats nervous for the same possibility, but it never actually happened
15:33
<Andreu Botella>
will do
15:33
<littledan>
I think OpenJS has made changes over time towards sending people who represent their projects, rather than just anyone (since we have the IE system for other projects)
15:34
<littledan>
long-term IEs make sense when you're representing a particular constituency, e.g., a strategic open source project (or in an Ecma Fellows-like situation). Lots of IEs are more transitional/introductory
15:34
<nicolo-ribaudo>
What if you gain block points by taking notes
15:34
<ljharb>
that's indeed actual policy now, but i don't think historically it's ever violated that policy ¯_(ツ)_/¯
15:35
<Chris de Almeida>
+1
15:36
<shu>
damn okay, was about to tell mark to catch me outside...
15:36
<shu>
guess it's not me
15:37
<ryzokuken>
you jest but I have suggested this in the past
15:37
<Michael Ficarra>
can I pay people to take notes and then transfer their block points to me?
15:38
<Chris de Almeida>
you will need them to block on your behalf... clandestinely
15:38
<nicolo-ribaudo>
That's only valid for green credits
15:39
<littledan>
Ecma needs to be able to explain to prospective members what benefits they will get by joining, so that we can do things like pay Aki for her good support work, and the transcriptionists, and maybe one day sponsor test262. It's a balancing act because we need to make sure that those who can't pay but will make good technical contributions can be involved. (This is a common situation which W3C and Unicode also face and solve similarly.)
15:40
<littledan>
often symbolic things ("do you really get to vote?") are important for people to make their internal arguments in companies
15:44
<Michael Ficarra>
Isn't the continued participation of IEs always dependent on the member that invited them? I don't think a company would want to subjugate themselves like that if they're truly interested in participating.
15:45
<shu>
do we actually check back in?
15:45
<shu>
with the sponsoring company, that is
15:45
<Michael Ficarra>
all IEs are temporary, so they need to be re-sponsored at the very least
15:46
<Chris de Almeida>
yes, and it also becomes an issue if the sponsoring member has left ecma
15:46
<Michael Ficarra>
yeah that's taking on a lot of risks just to save on dues
15:53
<jschoi>
all IEs are temporary, so they need to be re-sponsored at the very least
How often does Invited Expert status need to be renewed?
15:53
<Chris de Almeida>
they are reviewed yearly
15:53
<jkup>
I believe the status is meant to be re-evaluated annually
15:56
<jschoi>
Oh boy—then thank you to whoever kept my status even when I didn’t show up for a year or two.
15:56
<Aki>
i feel like there's a Supreme Court/Andrew Jackson analogy to be made here
15:56
<ryzokuken>
we missed you 😄
15:57
<littledan>
tbh we're falling behind on those reviews/renominations and just leaving people in until we get around to it
15:57
<ryzokuken>
oh wait, did we even have someone sponsor you?
15:57
<ryzokuken>
guess you went from delegate to IE directly and without an explicit sponsor because of the WIP proposals
15:58
<ljharb>
we also didn't used to review/revisit/recertify them at all, it's a relatively recent (and good) thing to do so
15:59
<Michael Ficarra>
@erights Mark Miller (Agoric) MM, @shu, and chairs: https://syg.github.io/proposal-nonextensible-applies-to-private/ LGTM, that proposal can advance to 2.7
15:59
<jschoi>
(I promise to try harder to get the University of Utah to join Ecma. I’m still not sure if it should specifically be by the Department of Computer Science...)
16:00
<littledan>
whatever's easiest for your internal paperwork
16:01
<shu>
i'm being dense, did someone else understand mark's argument?
16:02
<Bradford Smith>
In my experience (since 2020), I don't think I've ever seen an invite expert's lone objection be overruled. I feel like we've been de facto treating them as equivalent to other delegates, even if the Ecma rules say otherwise. Does that observation match with others'?
16:06
<msaboff>
I did not.
16:06
<nicolo-ribaudo>
I think I've seen it being overruled, but through behind the doors discussions
16:07
<nicolo-ribaudo>
Actually at this point I don't even remember who was IE and who was not
16:08
<Chris de Almeida>
the notion of who is blocking is far less important than the substance of the blocking concern(s)
16:10
<jschoi>
“Let it be known that ${organization}, embodied by me, blocks this proposal.” — delegate of organization
16:12
<Chris de Almeida>
it's not healthy for this committee to say that we don't care about an IE's concerns or that their concerns are any less valid than a delegate's. or, as some have pointed out, that their reviews are insufficient, or they cannot champion proposals, and so on
16:12
<shu>
IME that statement is false
16:12
<Chris de Almeida>
say more
16:13
<hax (HE Shi-Jun)>
"Because one person could have a non-technical, political reason that they want to block something. It’s happened in the past, we have seen it; and there’s no technical resolution that will allow something to move forward." --- I read the notes and I really want to know the real example and check if I agree that or not...
16:13
<shu>
i'll dm
16:14
<jkup>
I'm a bit nervous about the "technical vs. non-technical reason" concept. On one hand it feels like someone could say a technical reason while really wanting to block for "political" reasons. On the other hand I worry a bit about spawning meta discussions around "Was that a technical or political objection?"
16:15
<ryzokuken>
especially given how commonplace it can be in our industry to dismiss things as "non-technical"
16:15
<ryzokuken>
"any concern I disagree with is non-technical" drops mic /s
16:17
<shu>
i get the strong sense that the bar against which people are comparing msaboff's proposal is an ideal working mode, not our current working mode
16:18
<shu>
which is unfair to the proposal
16:22
<Michael Ficarra>
@waldemar @Mathieu Hofman see https://github.com/endojs/proposal-compare-strings-by-codepoint/issues/6 for my more general approach
16:34
<dminor>
Is objecting to a new feature based upon language complexity or lack of harmony with existing features a technical or non-technical objection? If we can only object based upon narrow technical grounds, I worry that JavaScript will keep growing until it subsumes every feature in every other programming language.
16:37
<littledan>
whenever we get on the topic of "good faith", we're getting into some kind of trouble territory, where we'll soon be talking about politics/bad faith. I think everyone here is consistently doing what they think is best for JavaScript.
16:37
<littledan>
the main thing is, when we disagree, then what do we do?
16:38
<littledan>
Even if we don't raise the bar for blocking from 1 person to 2, we can still have a subsequent discussion in a meeting about whether we want to uphold the block (even if it just takes one person to actually do it).
16:51
<Chris de Almeida>
when we disagree, then what do we do?

according to our CoC, we try to understand why. 😊
16:54
<littledan>
yes, and then? that's the question we were trying to answer
16:59
<ryzokuken>
@room we're back in under a minute!
17:04
<nicolo-ribaudo>
I know Eemeli will probably want to speak, I'll try to fill in when he cannot take notes
17:16
<ljharb>
(the queue topic isn't advanced yet fwiw)
17:46
<jschoi>
There seem to be are a lot of missing attendees in the notes’ attendee lists.
17:46
<Chris de Almeida>
people add themselves voluntarily
17:47
<Chris de Almeida>
the secretary maintains an accurate list
18:03
<shu>
what's the point of the list in the notes?
18:03
<littledan>
yeah I would like to remove that
18:03
<littledan>
we always have a lot of people missing; it's not a good record of anything in particular
18:03
<littledan>
we already have the sign-in form
18:03
<snek>
it used to be helpful for notetakers to get the right abbreviation
18:04
<snek>
perhaps not needed anymore
18:04
<ljharb>
that's always been the only purpose i understood for it
18:06
<ryzokuken>
unfortunately the note-takers at this point is a very small set of regulars but it would be super helpful to keep and maintain if someone new was taking notes for instance
18:08
<bakkot>
we should point note-takers to delegates.txt
18:08
<bakkot>
when I take notes that's always what I look at anyway
18:08
<bakkot>
since it's complete
18:08
<bakkot>
maybe other note takers do something else though
18:08
<Ashley Claymore>
IE's wouldn't appear in delgates.txt right.
18:08
<ljharb>
they would
18:08
<Ashley Claymore>
but yeah otherwise I just use delgates.txt
18:08
<ryzokuken>
every person who has a TLA should appear there
18:08
<ryzokuken>
the name of the file... isn't great
18:08
<ryzokuken>
maybe it should be renamed
18:09
<ryzokuken>
participants.txt
18:10
<bakkot>
no renaming things!!! 💢
18:10
<Ashley Claymore>
symlink
18:12
<waldemar>
Option 4: use AI
18:13
<Ashley Claymore>
Can't see an AI in delegates.txt
18:14
<shu>
wait, is comparative testing == testing for injectivity?
18:14
<shu>
are intl functions all injective?
18:15
<snek>
no
18:20
<littledan>
but with MessageFormat, they will be surjective
18:20
<littledan>
(via the template which just passes through its string arg)
18:27
<jschoi>
unfortunately the note-takers at this point is a very small set of regulars but it would be super helpful to keep and maintain if someone new was taking notes for instance
When I took notes in Seattle at my first meeting in a long time, I first checked the notes’ attendees table for abbreviations and failed to find the ones I needed. Then I asked for a link to delegates.txt again.
18:28
<shu>
LLMs would probably make test262 bots so expensive we'd stop running them lol
18:28
<ptomato>
shu: here's an example of a mini-implementation in test262 https://github.com/tc39/test262/blob/61fcd7bd565e01f795e55080ed9af70b71adb27e/harness/testIntl.js#L2517
18:29
<dminor>
ptomato: nice presentation and discussion
18:30
<ptomato>
thanks!
18:30
<Richard Gibson>
thanks I hate it
18:30
<shu>
i still don't really get it
18:31
<shu>
is it just programmatic goldens?
18:31
<ptomato>
gotta go now but I can elaborate later
18:58
<littledan>
shu: Whether to apply defer inwardly can be decided independently of which syntax choice we make
18:59
<shu>
that sounds right
18:59
<littledan>
(we've gone back and forth on it)
19:00
<littledan>
I feel like, it makes things faster and should work fine in practice for the same reason (that you're not depending on side effects), so let's throw it in
19:08
<sffc>
I mentioned this in TDZ but I think it's important enough to bring over here: the quality of the transcriptions today was quite terrible. Not only was there a very large number of errors (multiple per line), but in some cases whole sentences and key concepts were missing. For example, when Nicolo read off the names of people in the queue who supported Stage 2, that whole section got dropped from the transcription (I tried to re-create it manually). This is not a great note-taker experience. CC littledan
19:13
<littledan>
ryzokuken: Can you escalate this to Duane?
19:13
<littledan>
it's crazy how variable this is
19:13
<littledan>
because yesterday it was great
19:20
<Ashley Claymore>
the first hour of the 2nd half was OK, but they switched on the hour and the quality stopped significantly 
19:20
<Ashley Claymore>
*dropped 
19:23
<littledan>
thanks, I've escalated this to the transcription company
19:24
<nicolo-ribaudo>
Do people also struggle to understand what I say, or is it just the transcription when I speak?
19:25
<nicolo-ribaudo>
Changing how I speak is difficult, but things like "speak slower" is something I can try to do
19:26
<bakkot>
nicolo-ribaudo I have always understood you fine personally
19:35
<sffc>
I didn't notice a significant difference between number of errors when you were speaking versus others
21:42
<jschoi>
Regarding +0 vs. -0 again, an interesting bug whose fix just got pushed to Safari Technical Preview: https://github.com/WebKit/WebKit/commit/2f856d3a253c3ad7d4d0d1ba21e8ec78772c9e26
22:25
<ptomato>
shu: here's an example of a mini-implementation in test262 https://github.com/tc39/test262/blob/61fcd7bd565e01f795e55080ed9af70b71adb27e/harness/testIntl.js#L2517
Following up on this, here's what I call a "mini-implementation": you write a function in your test file, that imitates the spec algorithm of the method under test, line by line. Then you feed the same test data to that function and to the implementation's method under test. If the output is the same, the test passes
22:27
<ptomato>
It isn't specific to tests for ILD behavior. You could write a test for, e.g. Array.prototype.at in that style
22:34
<Steve Hicks>
As a point of order - would anyone object to bumping the AsyncContext Disposable topic to first thing tomorrow? IIUC that should not go against any constraints, but will allow me to make the full discussion. Thanks!
23:15
<ljharb>
that's confusing, the tests pass already in my safari 18.1
23:18
<nicolo-ribaudo>
I recommend trying to reach out to Dominic Farolino (colleague of yours!) and asking him too. It has been historically difficult to coordinate with him to present observables in TC39, so he might have planned around the current time slot