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) 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 |
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 |
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 |
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 |