| 08:32 | <annevk> | bakkot_: shouldn't the argument to fontcolor then be called colour? |
| 08:42 | <bakkot_> | annevk debatable; there it makes sense to match the name of the methood |
| 08:43 | <bakkot_> | I can totally believe there are inconsistencies though |
| 09:24 | <littledan> | which locale is Referer spelled in? |
| 09:25 | <littledan> | devsnek: I've pinged internally about this |
| 09:26 | <annevk> | littledan: the [sic] locale |
| 09:27 | <littledan> | maybe we should put this in the lang tag for all web specs |
| 09:27 | <annevk> | littledan: also responsible for URI, white-space, and Keep-Alive |
| 09:27 | <littledan> | en-us-SIC |
| 09:27 | <littledan> | it's a variant |
| 09:28 | <annevk> | en-GB-oxendict-SIC for ECMAScript |
| 09:28 | <littledan> | right |
| 09:28 | <littledan> | there needs to be a variant tag or extension key for oxford comma. oxendict doesn't quite describe it. This is a well-established need for Intl.ListFormat |
| 09:29 | <annevk> | Indeed, you might well want the Oxford comma and also spell color as color |
| 09:29 | <littledan> | exactly |
| 09:30 | <littledan> | en-GB-oxendict-SIC-u-com-oxford |
| 14:17 | <bendtherules> | I need some help in understanding how function hoisting works, following the spec. |
| 14:17 | <bendtherules> | From a light read, i thought - function gets declared during static semantics of its outer function body. |
| 14:17 | <bendtherules> | But this example i saw recently doesn't match up then. If you have function declaration within `if (false) {function abc() {} } `, then it doesn't get declared ;but if it's within if true, then it gets declared and hoisted to closest function scope. |
| 14:18 | <bendtherules> | How does it actually work? |
| 14:24 | <bendtherules> | Is it like - if the statementlist directly contains function declaration, then declare it during static semantics (and hence hoisted). But if it's within a construct like if-else, then let it get declared during runtime semantics (hence not hoisted).? |
| 14:31 | <bradleymeck> | bendtherules: you have entered the dark space of annex B https://tc39.es/ecma262/#sec-functiondeclarations-in-ifstatement-statement-clauses |
| 14:31 | <bradleymeck> | web compatibility yay |
| 14:32 | <bendtherules> | so this is something special about if-else only? |
| 14:33 | <bendtherules> | If i declared function within say, a while loop (or some other construct), wouldn't that get moved to parent function? |
| 14:36 | <bradleymeck> | bendtherules: no, the end of that section points to more web compat stuff that affects hoisting |
| 14:37 | <bradleymeck> | https://tc39.es/ecma262/#sec-block-level-function-declarations-web-legacy-compatibility-semantics is probably the worst part of the spec to understand IMO |
| 14:38 | <bendtherules> | Ahh, nice. I will try to understand that. |
| 14:38 | <bendtherules> | If someone can provide a TLDR or point to some blog post, that would also be very helpful |
| 14:39 | <bendtherules> | (just being lazy, haha 😀 ) |
| 14:41 | <bendtherules> | Also, can you tell if engine262 would implement things like this? |
| 14:43 | <bradleymeck> | devsnek: ^ |
| 14:47 | <devsnek> | bendtherules: at the moment engine262 ignores annex b |
| 14:47 | <devsnek> | anything else is fair game |
| 14:48 | <bendtherules> | ok. Thanks 👍 |
| 15:00 | <avandolder> | bakkot_ ljharb devsnek: I've been thinking about how to spec builtin generators for the iterator helpers proposal, I had a thought of couple designs and wanted to make sure I was on the right path: https://gist.github.com/avandolder/b852641a4c218cf8a98f1ad4aa133a96 |
| 15:01 | <avandolder> | I'm pretty sure design 1 was basically what had been agreed upon IIRC |
| 15:01 | <devsnek> | avandolder: what we can technically do is |
| 15:02 | <bakkot_> | bendtherules: rkirsling wrote a good summary at https://dev.to/rkirsling/tales-from-ecma-s-crypt-annex-b-3-3-56go |
| 15:02 | <devsnek> | avandolder: we can use the existing section to create two duplicates |
| 15:02 | <devsnek> | and from there, the operations on them should work normally since the internal slots have the same names |
| 15:06 | <avandolder> | so define the builtin generators as having GeneratorState/Context slots then using the already defined operations on them? |
| 15:07 | <devsnek> | yeah that seems simplest to me |
| 15:13 | <avandolder> | i think the only potential issue with that would be if the builtin generator object is directly available, then you could call `%GeneratorPrototype%.next(builtinGen)` |
| 15:13 | <devsnek> | maybe no one will notice :P |
| 15:14 | <devsnek> | we could add checks in the exposed functions i guess |
| 15:14 | <avandolder> | if the builtin generators are always kept in an internal slot then that would |
| 15:14 | <avandolder> | n't be possible to call |
| 16:47 | <ljharb> | avandolder: see https://github.com/tc39/ecma262/pull/2045 as well |
| 17:12 | <avandolder> | alright. assuming that PR is adjusted like jackworks said, and merged, would that be the approach to go with? having the iterator methods return an object that spec-wise is a brand-checked object with generator internal slots? |
| 17:12 | <avandolder> | brand-checked *iterator |
| 17:23 | <ljharb> | avandolder: assuming that PR will convince the editors that it's a viable approach for both all current iterator-producers, as well as the iterator helpers proposal, then that seems like the approach we'll go with yeah |
| 19:02 | <bendtherules> | bakkot_, rkirsling - Thanks for the article. This was much more easy to understand, specially with the historical context. |
| 19:12 | <rkirsling> | :D |
| 20:43 | <rkirsling> | ljharb: wait so JS itself is predicted to have a "heat death"? :p |
| 20:44 | <devsnek> | rkirsling: you might say that when people stop working on js it will become cold |
| 20:45 | <rkirsling> | seems like a reasonable metaphor |
| 20:46 | <ljharb> | rkirsling: you are welcome to define that as you wish |
| 20:48 | <rkirsling> | now I just have Uptown Funk stuck in my head tbqh |
| 21:12 | <ryzokuken> | devsnek: rkirsling: leobalter: https://webkitgtk.org/jsc-built-products/x86_64/release/ is now back up! |
| 21:12 | <devsnek> | yehaw |
| 21:12 | <ryzokuken> | sorry for the inconvenience, it was an infra snag. |
| 21:13 | <devsnek> | esvu installed it |
| 21:13 | <devsnek> | all seems well |
| 21:13 | <ryzokuken> | yaaaay! |
| 21:13 | <devsnek> | i wish js engine debug clis would support moving the cursor left and right |
| 21:13 | <devsnek> | history would be cool as well |
| 21:14 | <ryzokuken> | devsnek: I mean, you're optimizing for a very very narrow niche here I guess |
| 21:14 | <devsnek> | hey man i'll take left/right |
| 21:14 | <ryzokuken> | but maybe you should make a simple C++ prompt library |
| 21:14 | <devsnek> | i had a CL way back in the day to add readline to d8 |
| 21:15 | <devsnek> | it was totally ignored |
| 21:15 | <ryzokuken> | lol |
| 21:15 | <ryzokuken> | F |
| 21:16 | <rkirsling> | nice, I didn't realize that that was in fact the right place |
| 21:18 | <devsnek> | hm i guess it was linenoise instead of readline https://chromium-review.googlesource.com/c/v8/v8/+/1012404 |
| 21:18 | <ryzokuken> | devsnek: well, you can see the OWNERS of `d8` |
| 21:18 | <ryzokuken> | and talk to them? |
| 21:19 | <devsnek> | i CC'd an owner |
| 21:19 | <devsnek> | :( |
| 21:19 | <devsnek> | but oh well it doesn't matter that much |
| 21:19 | <ryzokuken> | 🤷 |
| 21:19 | <ryzokuken> | I tend to be a tad more shameless sometimes. |
| 21:20 | <devsnek> | if i was gonna do it today i would vendor node to replace d8 |
| 21:21 | <ryzokuken> | really? |
| 21:21 | <ryzokuken> | isn't that too heavy a debug shell? |
| 21:21 | <ryzokuken> | why does d8 need a stdlib lol |
| 21:22 | <rkirsling> | it is surprising that "nice" CLI behavior is DIY |
| 21:23 | <devsnek> | POSIX has readline |
| 21:23 | <devsnek> | which is pretty good |
| 21:23 | <devsnek> | it even supports persistent history |
| 21:23 | <rkirsling> | I mean JSC does have the things you described |
| 21:23 | <devsnek> | jsc has none of it |
| 21:23 | <rkirsling> | left/right arrow support and (session-specific) history |
| 21:24 | <devsnek> | https://gc.gy/60825255.png |
| 21:24 | <devsnek> | me hitting arrow keys |
| 21:24 | <rkirsling> | maybe Mac specific? |
| 21:25 | <devsnek> | sec lemme try on mac |
| 21:25 | <devsnek> | using the brilliant power of esvu |
| 21:25 | <rkirsling> | doesn't allow Ctrl+left/right though |
| 21:25 | <rkirsling> | which is frequently annoying |
| 21:25 | <devsnek> | wow it is supported |
| 21:25 | <devsnek> | why doesn't it work on linux |
| 21:26 | <rkirsling> | there's a #if HAVE(READLINE) |
| 21:27 | <devsnek> | where is READLINE defined |
| 21:27 | <devsnek> | tbh what is HAVE |
| 21:28 | <devsnek> | https://github.com/WebKit/webkit/blob/master/Source/WTF/wtf/Platform.h |
| 21:28 | <devsnek> | HAVE_READLINE isn't defined for linux |
| 21:29 | <rkirsling> | https://github.com/WebKit/webkit/blob/master/Source/WTF/wtf/PlatformHave.h |
| 21:29 | <rkirsling> | is the new location but yeah just flagged for Mac and iOS |
| 21:30 | <devsnek> | down lower there's an if DARWIN or LINUX that would be a good place to put it |
| 21:32 | <rkirsling> | I think they're separated out so that you can change the platform setting for each HAVE instead of vice-versa |
| 21:32 | <rkirsling> | https://github.com/WebKit/webkit/blob/master/Source/WTF/wtf/PlatformHave.h#L75-L77 is redundant though because it's also Darwin |
| 21:45 | <bakkot_> | I just aliased d8 to `rlwarp d8` |
| 21:46 | <devsnek> | holy shit that's brilliant |
| 21:46 | <devsnek> | this changes EVERYTHING |
| 21:47 | <rkirsling> | lol nice |
| 21:49 | <ljharb> | what's rlwarp? |
| 21:50 | <devsnek> | rlwrap wraps a program's stdin through readline |
| 21:50 | <devsnek> | https://linux.die.net/man/1/rlwrap |
| 21:54 | <ljharb> | ah |
| 21:55 | <devsnek> | maybe i'll add a feature to esvu to support wrapping engines with it |
| 21:56 | <rkirsling> | next step is to make rtlwrap |
| 21:56 | <rkirsling> | oops this isn't tdz |
| 21:58 | <rkirsling> | ljharb: gonna say this here 'cause I don't really want to derail the issue thread but if we made an error for optional call of %eval% in particular that'd be a runtime error since even `eval()` might turn out not to be %eval% |
| 21:59 | <devsnek> | only in sloppy mode |
| 22:01 | <rkirsling> | anyway recognizing that an error could be a third path is not unworthwhile but I think both ways of realizing it would be icky |
| 22:04 | <ljharb> | rkirsling: ah right, true enough |
