happy new year, y'all

jandem, good day! if it's not too late, i might add new information to the newsletter

bbouvier: yes please! was going to ping you today about that :)

and happy new year

jandem, so we're looking at all activity until today, right?

bbouvier: yep

jandem, great, done

merci!

jonco: ping

allstarschh: pong

jonco: hi, I have a question regarding my bug 1605633

jonco: so in my patch, I check if the wrapped weakRef is a dead wrapper, if it is, I report the error and bail out

jonco: but I have already created the weakRef object, right?

jonco: searchfox.org/mozilla-central/sourc…js/src/builtin/WeakRefObject.cpp#45

ok

jonco: then the finalizer of the weakRef object is called

jonco: but the target of the weakRef is already relocated

jonco: and the target is not updated because it isn't added to the weakRefMap, because I bail out early in the weakRefObject::construct

oh right, I see

so how can you fix that?

jonco: so can my first version of patch to fix that?

jonco: so in my first version, I didn't bail out, I relaxed the assertion searchfox.org/mozilla-central/sourc…s/src/builtin/WeakRefObject.cpp#213

well bailing out early is good if there's a problem

can you think of a fix to the second version of the patch to prevent this new problem?

jonco: okay, I'll try, thanks

cool, let me know how you get on

bbouvier: I looked at your bot, looks cool and easy to maintain

the bugzilla handler could probably use bugzilla.mozilla.org/rest/bug/35

evilpie, yeah, glob actually opened an issue to tell me that we could use the REST api

evilpie, please make pull requests

(i think a few more things should be added, like an abstraction over the matrix-bot-sdk Client, maybe rewrite it in typescript to have static typing happiness, etc.)

bbouvier: ok I don't have a Matrix account yet

hmm.. I guess the merge hasn't been pushed yet

evilpie, and yet he opened a PR! thanks

So is matrix up already?

not yet

jandem: train has left the station, in case you want to update /topic :)

woo :)

jcristau: thanks :)

I don't see the version bump yet: hg.mozilla.org/integration/autoland/pushloghtml

ah, 73 Beta tag is set

jonco: around 👀?

cybai: sure]

yeah! I'd like to ask a question about compiling module script! wait me a minute! thanks!

jonco: currently, Servo uses the CompileModule exposed from mozjs crate which will receive source buffer with u16 (doc.servo.org/mozjs/jsapi/fn.CompileModule.html)

jonco: but, Servo will compile UTF-16 BOM successfully which makes the UTF-16 BOM tests failed in wpt.fyi/results/html/semantics/scri…ript-element/module/charset-02.html

jonco: I'm wondering if Gecko fails UTF-16 BOM by using the branching checking here (searchfox.org/mozilla-central/rev/9…dom/script/ScriptLoader.cpp#530-542) ? Do I understand it correctly?

Thanks 🙏

cybai: that code is switching between UTF16 and UTF8 inputs… I don't think that's related

cybai: but I don't know too much about unicode

cybai: I can't find where the rust CompileModule comes from but I assume it's just calling the JS version?

oh, it's not a shim, this is just calling the JSAPI function

jonco: yes, it's a binding of the JSAPI function!

This seems like a good question for Waldo when he shows up

cybai: yes that's my suggestion too ^

tcampbell: jonco: thanks! I might go to sleep later 😂 (I'm in GMT+8 timezone now) will try to ping Waldo maybe later or next time! thanks!

cybai: searchfox.org/mozilla-central/rev/9…om/script/ScriptLoadHandler.cpp#176

cybai: np

that looks to be the code that handles it

tcampbell: oh, cool! didn't find this file! let me try to read them! thanks a lot!

yeah, I get lost in those files easily

confession: Grumbling at MOZ_NON_PARAM.

does it work unexpectedly?

It's totally doing the right thing, but it just meant that passing something with a variant inside is not allowed, which makes providing a default argument not possible in this case

(tiny paper cut, but slightly sad :) )

ah, yeah, the workaround is to use reference in parameter type, but then you'll need to create static variable somewhere for using in default

arai: ooooh a static hadn't crossed my mind. That'sd not a bad work around.

arai: What do you think about the ability to have actions in the middle of a grammar production, such as: A ::= B . C D => { /* after B */ do_something(); }

arai: /* after B */ is implied by the dot `.` location.

it's for the case where both B and C are terminal, or some non-terminal that is shared with other grammar ?

arai: where either B, C and D are terminals / non-terminals.

arai: what do you mean by shared with other grammar?

I was thinking about the motivation

err, maybe I'm misunderstanding

arai: the motivation is implementing flags, doing name collections, or implementing any other grammar rules. (such as initializer restriction after a LetOrConst)

by adding the ability of having actions in the middle of a production, we can implement any Left-to-Right computation.

as-if we were in an LL parser.

yeah, the ability itself would be nice

not sure about the syntax

arai: I think if we do so, we would want to repeat the production rules. I had to deal once with something where the actions were in the middle of the rule, and this was aweful.

what do you mean by repeat the rules?

arai: so the idea would be to have the generated grammar in one file, and "extensions" in multiple other files, where rules are repeated.

and matched against the generated grammar.

do you mean replacing the current `es-simplified.esgrammar` syntax ? (I mean the syntax to write the grammar rule)

I mean the generated grammar would have "A ::= B C D", and we would write in another file "A ::= B C D . => { build_A($1, $2, $3); }"

The reason being that I want us to be using the ECMA grammar as much as possible.

any deviation from it is a future maintenance cost.

what is the former file (generated grammar) for ?

doesn't the latter file contain all grammar again?

Similar to what we have in es-simplified.grammar

the later file*s* contain only the rule we care about adding semantic to them.

So we will definitely repeat the grammar, and we can raise error as not being able to merge the action to any of the productions.

I see

The advantages of having multiple files, is that we can have a file which is only dealing with Return flags, or one which is only dealing with LetOrConst and Initialization lists.

how do you write when you want to do something also after B and C ?

You repeat the production multiple times, one for each action.

"A ::= B . C D => {} A ::= B C . D => {} A ::= B C D . => {}"

not having a `.` in an extension file would be an error.

I see

(I feel it's a bit redundant to repeat whole syntax, but simplicity would be better here

I think copy and pasting is something humans are good at, and this as well has the benefit of being self-documenting :)

and something we can check against.

while implementing the dup-early-error branch, what I was thinking was to write syntax once, and say "do this after $1, do this after $2, ...", and then convert that to non-terminal with the rule for it

as someone who hasn't been following the new parser stuff, I'm a little curious how this works. Are you generating an LR-style parser, or are you backtracking, or what? If you have A ::= B . C with some action, how do you know for sure that you have the right rule before reducing C? Do you need to have undo actions to allow for backtracking?

mccr8: I was wondering if we had something like AutoRestore!

this would be pretty useful in SM too

Yeah, I only know about it because of a review comment on a patch I wrote many years ago.

iiuc, no backtracking. and to my understanding, the rule should be added to the place where only one possibility is left

sfink: mozilla-spidermonkey/jsparagus #54 , by no longer doing an LR parser.

What happened to JSOP_THIS ?

sfink: at least not on paper, but on the principle.

sfink: The idea so far was to delay the action until you are sure that you are in the right rules.

sfink: the action does not matter as long as they are executed in the same order and non-ambiguous.

Ah, it's JSOP_GLOBALTHIS now?

sfink: "A ::= B . C D => { do_1() } A ::= B . C E => { do_2(); }" would imply that all actions executions are delayed until you figured the first character which distinguish between D / E.

sfink: which is not something you can easily do with reduce-actions in an LR grammar.

sfink: and this is better achieved if you have non-aliasing data, which can somewhat be done using Traits (manipulating disjoint data)

sfink: And yes, we are generating the parser from a grammar file.

ah, thanks for the link. It makes sense.

jonco: there's a typo in your new comment. :P

"This as often"

I think as should be has.

ah dammit

I'm not sure that is worth a followup though.

I'm mostly familiar with LR parsers, and can see how you could implement this in a GLR type of gnerator, but it does seem like you'd need to know things about what the actions are doing and relying on

sfink: you do not need GLR parser, if you are willing to multiply the number of states.

sfink: when you are going GLR, you basically do the multiplication of states at runtime.

in my mind, multiplying the number of states is one way to implement a GLR parser :-)

oh, I see what you mean

jorendorff: promises terminology goo

Waldo: ?

jorendorff: there's currently a function called RunResolutionFunction, used to call the resolve/reject function when handling a promise

jorendorff: I want to split it into two functions with different names and slightly different arguments

jorendorff: would RunResolveFunction and RunRejectFunction the proper names, or RunFulfillFunction and RunRejectFunction? or should I sneak a *ion suffix in there, e.g. RunRejectionFunction?

jorendorff: my rough problem is "resolve" -> "resolution", but then that means the current name is a really bad one, which seems unlikely

Waldo: I don't know as much about this code as you think

this is probably a question I could answer myself if I were slightly more fluent in promises terminology

I think the spec says "resolve function" consistently

never "resolution function"

jorendorff: I don't *believe* you need to know about the code, only about what people name stuff in promises APIs and their workings

ok, so I think no *ion suffix

that was the direction I was tending, yeah

my tree has RunResolveFunction and RunRejectFunction in it, in patches that are in all-but-reviewable state

I think it should be fulfill, not resolve, but i don't know why

:-|

anyone else here know anything about promises terminology? the two of us seem to be science-dogging pretty good right now

Waldo: we are talking about script-supplied handler functions, right?

jorendorff: they can be script-supplied, or they can have default behavior that gets done as C++ calls

right

jorendorff: searchfox.org/mozilla-central/source/js/src/builtin/Promise.cpp#2703 is the function

jorendorff: (my basic problem I'm trying to solve is that line 2725's block I need to not happen sometimes, in order to implement ReadableStream spec changes)

Waldo: "resolve" is what happens when you do `new Promise((resolve, reject) => { resolve otherPromise; })`

er, `resolve(otherPromise);`

if `otherPromise` is still pending, then your new promises is resolved, but not yet fulfilled

it'll become fulfilled when otherPromise becomes fulfilled

and s/fulfilled/rejected/g

okay

Waldo: in other news what the heck happened Saturday

jorendorff: no idea at all

Did you see the game?

jorendorff: the offense looked like it has of late...but just not getting stops on D came from nowhere

jorendorff: yeah, AUS->SJC was delayed so I just barely got home in time for it, but I caught the whole thing

watched about the second half and OT of the earlier game, too, so what I saw in that game was massively one-sided despite the score when I turned it on

did a bunch of reading on most of the flight, then I remembered there was a first game of the day I could have put on, via Southwest wifi

yay the future

the early Targaryen family history is curiously engrossing, if you're already five books and several novellas in and are willing to read quasi-dry historical accounts

(Fire and Blood)

way too many people with vaguely similar names, tho, I'm having serious trouble keeping everyone's roles distinct in my mind

and then I read the two previous novellas in similar tone already, so I'm behind The Princess and the Queen but I know some of its principals are being talked about now but boy can I not remember which of them are which

I do like me some reading about dragons being a part of life, tho

NEED MOAR DRAGONS

confession: Landed Bug 1592102 -- Thanks to the super kind shepherding of tcampbell, it's a much nicer result than the original patch :)