Re: Dates with Timezones and ISO8601 Date Constants.

[Jordan Harband]

Are you familiar with the Temporal proposal?
https://github.com/tc39/proposal-temporal

On Mon, Sep 24, 2018 at 8:32 PM, J Decker  wrote:

> I did look back to see other conversations about Dates
>
> Operating with arbitrary timezones
> https://mail.mozilla.org/pipermail/es-discuss/2016-August/046478.html
>
> Add timezone data to Date
> https://mail.mozilla.org/pipermail/es-discuss/2017-June/048259.html
>
> Even until this moment, Edge/IE cannot parse new Date(
> "2018-09-25T00:17:55.385-07:00").  which makes 50% of the world already
> require a date/time library.
> https://github.com/Microsoft/ChakraCore/issues/5502
> (actually Aug 16 that was closed)
>
> Date.toISOString() only emits 'Z', even though the type itself has the
> offset
>
> as a Date.prototype.toISOLocalString()
> cb : function () {
> var tzo = -this.getTimezoneOffset(),
> dif = tzo >= 0 ? '+' : '-',
> pad = function(num) {
> var norm = Math.floor(Math.abs(num));
> return (norm < 10 ? '0' : '') + norm;
> };
> return this.getFullYear() +
> '-' + pad(this.getMonth() + 1) +
> '-' + pad(this.getDate()) +
> 'T' + pad(this.getHours()) +
> ':' + pad(this.getMinutes()) +
> ':' + pad(this.getSeconds()) +
> dif + pad(tzo / 60) +
> ':' + pad(tzo % 60);
> }
> --
> But; that's only semi-accurate, because if I say -07:00 as the offset, I
> don't know if it's MST or PDT (which is knowable I suppose).
>
> There's not a LOT of usage of times in code; but it could be that the
> constant number 2018-09-25T00:26:00.741Z could just BE a Date, similar to
> 123n just being a BigInt.
>
> It would also be handy if there were a builtin ISO w/ Timezone emitter.
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Dates with Timezones and ISO8601 Date Constants.

[J Decker]

I did look back to see other conversations about Dates

Operating with arbitrary timezones
https://mail.mozilla.org/pipermail/es-discuss/2016-August/046478.html

Add timezone data to Date
https://mail.mozilla.org/pipermail/es-discuss/2017-June/048259.html

Even until this moment, Edge/IE cannot parse new Date(
"2018-09-25T00:17:55.385-07:00").  which makes 50% of the world already
require a date/time library.
https://github.com/Microsoft/ChakraCore/issues/5502
(actually Aug 16 that was closed)

Date.toISOString() only emits 'Z', even though the type itself has the
offset

as a Date.prototype.toISOLocalString()
cb : function () {
var tzo = -this.getTimezoneOffset(),
dif = tzo >= 0 ? '+' : '-',
pad = function(num) {
var norm = Math.floor(Math.abs(num));
return (norm < 10 ? '0' : '') + norm;
};
return this.getFullYear() +
'-' + pad(this.getMonth() + 1) +
'-' + pad(this.getDate()) +
'T' + pad(this.getHours()) +
':' + pad(this.getMinutes()) +
':' + pad(this.getSeconds()) +
dif + pad(tzo / 60) +
':' + pad(tzo % 60);
}
--
But; that's only semi-accurate, because if I say -07:00 as the offset, I
don't know if it's MST or PDT (which is knowable I suppose).

There's not a LOT of usage of times in code; but it could be that the
constant number 2018-09-25T00:26:00.741Z could just BE a Date, similar to
123n just being a BigInt.

It would also be handy if there were a builtin ISO w/ Timezone emitter.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removing a module from the cache

[Isiah Meadows]

First, I'm reconsidering this approach as per a discussion on #tc39
IRC, and plan to come up with a CommonJS prototype first before
actually developing a proposal. Most likely, it won't actually involve
mutating the graph, but something closer to Erlang's, where different
versions of modules might coexist for different views of the world.

Second, there are ways around those issues you listed:

1. If you stick with immutability, you can achieve something similar
to what you'd get with Erlang or Elixir. You generally have to code
*for* hot reloading, simply because it ruins the assumption you have
full local control over the runtime's world.
1. I've personally had to resort to restarting everything, but for me,
it's not paranoia, but actual things breaking.
1. Almost nobody outside OTP circles seem to correctly account for
data and module dependencies. When a module changes, you have to also
reload everything that imports it, so things actually work. You still
can have implicit dependencies from arguments, but those are less
common, and they almost never show up in object-oriented code bases
(where things are typically directly imported).

But anyways, I'm letting this mailing list proposal die here while I
figure out how best to come up with something truly compelling.

-

Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com

On Mon, Sep 24, 2018 at 4:46 AM kai zhu  wrote:
>
> hi Isiah, i don’t feel your use-case is a valid one.  i've played with many 
> crazy hot-module loading-techniques in my 7 years as a python-dev, and 
> afterwards, first year as js-dev.  reflecting on all that time spent, what 
> have i learned?  that for anything besides contrived toy-cases, i *never* 
> trusted the modules would hot-load correctly, with properly resolved 
> dependencies (especially inter-module class-inheritances, which was a factor 
> why i'm hostile to inheritance-based design-patterns in dynamics-languages).  
> in practice i always ended up restarting the entire app/test-runner after 
> file-updates due to paranoia, and there was alot of loader-related tech-debt 
> i should have deleted years earlier, but didn’t due to sentimental value.
>
> the *only* valid use-case for hot-loading modified-modules is during 
> bootstrap-phase (with minimal integration-worries about module-dependency 
> issues), so you can insert instrumentation-code for test-coverage like this 
> real-world example [1].
>
> [1] bootstrap to load modified-modules with instrumentation-code for 
> test-coverage
> https://github.com/kaizhu256/node-istanbul-lite/blob/2018.4.25/lib.istanbul.js#L2765
>
> kai zhu
> kaizhu...@gmail.com
>
>
>
> On 21 Sep 2018, at 1:33 AM, Isiah Meadows  wrote:
>
> I could seriously use the ability to remove, relative to a module, a
> loaded module from the cache.
>
> - In my test runner, I don't want to have to append a random query
> just to reload all the test files in watch mode.
> - I was at one point running an experiment to try to use JS tagged
> templates as a template engine of sorts, but I can't really use ES
> modules because I need the ability to drop them from cache and
> re-import them manually.
>
> I do not require any new syntax (it can just be a built-in exposed to
> hosts and maybe by hosts like Node), but I would like such a hook
> exposed.
>
> This won't require much in the spec, but it will require three main
> spec changes:
>
> - A new per-realm specifier blacklist (like maybe realm.[[Reload]]) added.
> - The third requirement in `HostResolveImportedModule` [1] altered to not
> require idempotence when the specifier is in the current realm's
> [[Reload]] list.
> - All callees to `HostResolveImportedModule` changed to also remove
> the specifier from the current realm's [[Reload]] list if the
> operation completed normally.
>
> [1]: https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: await enhancement proposal: Wrap Array return values with Promise.all

[Michał Wadas]

https://esdiscuss.org/topic/proposal-await-p1-p2-equivalent-to-await-promise-all-p1-p2



On Mon, 24 Sep 2018, 16:21 Michael Luder-Rosefield, 
wrote:

> Would it be possible to extend `await` such that you could `await.all()`?
>
> If not, one minor thing that might help cut down the noise (if it works
> with native Promises without this-binding; I've done it with RSVP):
>
> ```
> const { all } = Promise;
>
> await all(/* */);
> ```
>
> On Sun, 23 Sep 2018, 02:53 Logan Smyth,  wrote:
>
>> Making `await` itself do this would be a breaking change, so that'd be
>> very unlikely. There was discussion around an `await*` similar to the
>> existing `yield*` for generators, but I think it was deemed unneeded
>> complexity since `Promise.all` was already pretty easy to use, especially
>> since it isn't 100% obvious from the usage of an array what should be done.
>> For instance `Promise.race` also works on an iterable value. I'm not really
>> involved with the process, so I can't say more though.
>>
>> On Sat, Sep 22, 2018 at 12:25 AM Rudi Cilibrasi 
>> wrote:
>>
>>> Greetings,
>>>
>>> I have enjoyed using the `await` keyword tremendously in async code. One
>>> point I notice in using it is that it is ideal in terms of clarity and
>>> composability but limited in a sense to sequential composition. That is, I
>>> cannot easily use `await` (by itself) to do parallel calculations.
>>>
>>> A few times, I have myself hit a bug where I return (without thinking)
>>> an Array of Promise only to find that none will resolve using `await` on
>>> the Array. I noticed others have similar bugs. [1,2] I frequently wind up
>>> wrapping them in one of two ways: a) occasionally a for loop that awaits
>>> each in sequence, but b) more often a `Promise.all`. I think the current
>>> `await` syntax makes every kind of sequential composition quite simple to
>>> read, write, and maintain, but the fact that we have to introduce
>>> `Promise.all` for each case of parallel (overlapping) execution seems to be
>>> a common cause of bugs and a minor aesthetic issue to me as well as perhaps
>>> maintenance. It occurs to me that for my cases, and indeed perhaps others,
>>> a useful rule would be that all `await` on `Array` behave as if the Array
>>> were wrapped in `Promise.all`.  Then we can have a nice parallel
>>> composition syntax built into the language with the keyword using Array and
>>> lists can become idiomatic and concise parallel composition operators. I
>>> feel like this could improve the readability, power, and real time
>>> responsiveness of the language without necessarily sacrificing quality nor
>>> clarity.
>>>
>>> await on an Array value v acts as await Promise.all(v)
>>>
>>> Weighing against this idea seems to be the usual: operator tricks are
>>> unsearchable via keywords compared to `Promise.all`. So there is a style
>>> question however with the latest addition of the great new
>>> optional-chaining and pipeline ideas I thought it might be a good time to
>>> give this idea a try.
>>>
>>> What does the group think about this await enhancement proposal?
>>>
>>> Best regards,
>>>
>>> Rudi Cilibrasi
>>>
>>> [1]:
>>> https://stackoverflow.com/questions/38694958/javascript-async-await-for-promises-inside-array-map
>>> [2]:
>>> https://stackoverflow.com/questions/37360567/how-do-i-await-a-list-of-promises-in-javascript-typescript
>>>
>>> --
>>> Happy to Code with Integrity : Software Engineering Code of Ethics and
>>> Professional Practice 
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: await enhancement proposal: Wrap Array return values with Promise.all

[Michael Luder-Rosefield]

Would it be possible to extend `await` such that you could `await.all()`?

If not, one minor thing that might help cut down the noise (if it works
with native Promises without this-binding; I've done it with RSVP):

```
const { all } = Promise;

await all(/* */);
```

On Sun, 23 Sep 2018, 02:53 Logan Smyth,  wrote:

> Making `await` itself do this would be a breaking change, so that'd be
> very unlikely. There was discussion around an `await*` similar to the
> existing `yield*` for generators, but I think it was deemed unneeded
> complexity since `Promise.all` was already pretty easy to use, especially
> since it isn't 100% obvious from the usage of an array what should be done.
> For instance `Promise.race` also works on an iterable value. I'm not really
> involved with the process, so I can't say more though.
>
> On Sat, Sep 22, 2018 at 12:25 AM Rudi Cilibrasi 
> wrote:
>
>> Greetings,
>>
>> I have enjoyed using the `await` keyword tremendously in async code. One
>> point I notice in using it is that it is ideal in terms of clarity and
>> composability but limited in a sense to sequential composition. That is, I
>> cannot easily use `await` (by itself) to do parallel calculations.
>>
>> A few times, I have myself hit a bug where I return (without thinking) an
>> Array of Promise only to find that none will resolve using `await` on the
>> Array. I noticed others have similar bugs. [1,2] I frequently wind up
>> wrapping them in one of two ways: a) occasionally a for loop that awaits
>> each in sequence, but b) more often a `Promise.all`. I think the current
>> `await` syntax makes every kind of sequential composition quite simple to
>> read, write, and maintain, but the fact that we have to introduce
>> `Promise.all` for each case of parallel (overlapping) execution seems to be
>> a common cause of bugs and a minor aesthetic issue to me as well as perhaps
>> maintenance. It occurs to me that for my cases, and indeed perhaps others,
>> a useful rule would be that all `await` on `Array` behave as if the Array
>> were wrapped in `Promise.all`.  Then we can have a nice parallel
>> composition syntax built into the language with the keyword using Array and
>> lists can become idiomatic and concise parallel composition operators. I
>> feel like this could improve the readability, power, and real time
>> responsiveness of the language without necessarily sacrificing quality nor
>> clarity.
>>
>> await on an Array value v acts as await Promise.all(v)
>>
>> Weighing against this idea seems to be the usual: operator tricks are
>> unsearchable via keywords compared to `Promise.all`. So there is a style
>> question however with the latest addition of the great new
>> optional-chaining and pipeline ideas I thought it might be a good time to
>> give this idea a try.
>>
>> What does the group think about this await enhancement proposal?
>>
>> Best regards,
>>
>> Rudi Cilibrasi
>>
>> [1]:
>> https://stackoverflow.com/questions/38694958/javascript-async-await-for-promises-inside-array-map
>> [2]:
>> https://stackoverflow.com/questions/37360567/how-do-i-await-a-list-of-promises-in-javascript-typescript
>>
>> --
>> Happy to Code with Integrity : Software Engineering Code of Ethics and
>> Professional Practice 
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removing a module from the cache

[kai zhu]

hi Isiah, i don’t feel your use-case is a valid one.  i've played with many 
crazy hot-module loading-techniques in my 7 years as a python-dev, and 
afterwards, first year as js-dev.  reflecting on all that time spent, what have 
i learned?  that for anything besides contrived toy-cases, i *never* trusted 
the modules would hot-load correctly, with properly resolved dependencies 
(especially inter-module class-inheritances, which was a factor why i'm hostile 
to inheritance-based design-patterns in dynamics-languages).  in practice i 
always ended up restarting the entire app/test-runner after file-updates due to 
paranoia, and there was alot of loader-related tech-debt i should have deleted 
years earlier, but didn’t due to sentimental value.

the *only* valid use-case for hot-loading modified-modules is during 
bootstrap-phase (with minimal integration-worries about module-dependency 
issues), so you can insert instrumentation-code for test-coverage like this 
real-world example [1].

[1] bootstrap to load modified-modules with instrumentation-code for 
test-coverage
https://github.com/kaizhu256/node-istanbul-lite/blob/2018.4.25/lib.istanbul.js#L2765
 


kai zhu
kaizhu...@gmail.com



> On 21 Sep 2018, at 1:33 AM, Isiah Meadows  wrote:
> 
> I could seriously use the ability to remove, relative to a module, a
> loaded module from the cache.
> 
> - In my test runner, I don't want to have to append a random query
> just to reload all the test files in watch mode.
> - I was at one point running an experiment to try to use JS tagged
> templates as a template engine of sorts, but I can't really use ES
> modules because I need the ability to drop them from cache and
> re-import them manually.
> 
> I do not require any new syntax (it can just be a built-in exposed to
> hosts and maybe by hosts like Node), but I would like such a hook
> exposed.
> 
> This won't require much in the spec, but it will require three main
> spec changes:
> 
> - A new per-realm specifier blacklist (like maybe realm.[[Reload]]) added.
> - The third requirement in `HostResolveImportedModule` [1] altered to not
> require idempotence when the specifier is in the current realm's
> [[Reload]] list.
> - All callees to `HostResolveImportedModule` changed to also remove
> the specifier from the current realm's [[Reload]] list if the
> operation completed normally.
> 
> [1]: https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule
> 
> -
> 
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: defer keyword

[kai zhu]

how would you handle cleanup after timeouts in 
https://github.com/tc39/proposal-using-statement? 


when managing io-complexity at the integration-level, i feel the 
reliable/zero-magic/verifiable way to guarantee cleanup in all scenarios is 
still to use traditional-callbacks, with a timeout-closure.

here are 2 examples using the recursive-callback approach, where cleanup is 
guaranteed-to-run in the “default” switch-statement; one is real-world [1], and 
the other is this working, standalone nodejs code:

[1] real-world example of guaranteed cleanup
https://github.com/kaizhu256/node-utility2/blob/2018.9.8/lib.utility2.js#L3320 




```js
// example.js
// fully-working standalone code to fetch data from https://api.github.com 

// and cleanup afterwards
/*jslint node: true*/
/*property
GITHUB_TOKEN, authorization, concat, created_at, date, destroy, end, env,
error, exit, headers, html_url, log, map, on, parse, push, request,
responseHeaders, responseStatusCode, size, slice, stargazers_count, status,
statusCode, stringify, updated_at
*/
(function () {
"use strict";
var cleanup;
var chunkList;
var modeNext;
var onNext;
var request;
var response;
var timerTimeout;
cleanup = function () {
// cleanup timerTimeout
clearTimeout(timerTimeout);
// cleanup request-stream
try {
request.destroy();
} catch (ignore) {
}
// cleanup response-stream
try {
response.destroy();
} catch (ignore) {
}
console.error(
"\u001b[31mcleaned up request and response streams\u001b[39m"
);
};
onNext = function (error, data) {
try {
// guarantee cleanup on callback-error
if (error) {
console.error(error);
modeNext = Infinity;
}
modeNext += 1;
switch (modeNext) {
case 1:
// guarantee cleanup after 15ms timeout
timerTimeout = setTimeout(function () {
onNext(new Error("timeout error"));
}, 15000);
// fetch json repository-data from
// https://api.github.com/tc39/repos
request = require("url").parse(
"https://api.github.com/orgs/tc39/repos;
);
request.headers = {};
request.headers["user-agent"] = "undefined";
// add optional oauth-token to increase rate-limit quota
if (process.env.GITHUB_TOKEN) {
request.headers.authorization = (
"token " + process.env.GITHUB_TOKEN
);
}
request = require("https").request(
request,
// concatenate data-chunks from response-stream
function (_response) {
chunkList = [];
response = _response;
response
.on("data", function (chunk) {
chunkList.push(chunk);
})
.on("end", function () {
onNext(null, Buffer.concat(chunkList));
})
// guarantee cleanup on response-error
.on("error", onNext);
}
);
// guarantee cleanup on request-error
request.on("error", onNext)
.end();
break;
case 2:
// print response data
console.log(JSON.stringify(
{
responseStatusCode: response.statusCode,
responseHeaders: {
date: response.headers.date,
status: response.headers.status,
"content-type": response.headers["content-type"],
"content-length": (
response.headers["content-length"]
)
}
},
null,
4
));
// print first 5 results of abridged,
// JSON.parsed concatenated-data
console.log(JSON.stringify(
JSON.parse(String(data))
.slice(0, 5)
.map(function (githubRepo) {
return {
html_url: githubRepo.html_url,
created_at: githubRepo.created_at,
updated_at: