RE: weak reference proposal

2016-12-31 Thread Uther Pendragon 
...additionally, I think the term "weak reference" is inaccurate for ipc
referencing...  I would describe that more as super-strong references than
weak...  resilient referencing.

On Dec 31, 2016 11:20 AM,  wrote:

> If it were me, I would use a socket for ipc and use the socket as the weak
> map reference... Thus, when the socket was destroyed, and you get the
> SIGPIPE, free the socket reference, and it's referenced object should be
> cleared.  This should work, however if you have too many objects, then you
> might have to tree it out or something.
>
> I think the idea is a good one for library, I just don't think it's worth
> polluting the spec with...  thoughts?
>
> On Dec 31, 2016 11:20 AM,  wrote:
>
> Send es-discuss mailing list submissions to
> es-discuss@mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.mozilla.org/listinfo/es-discuss
> or, via email, send a message with subject or body 'help' to
> es-discuss-requ...@mozilla.org
>
> You can reach the person managing the list at
> es-discuss-ow...@mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
>
> Today's Topics:
>
>1. Re: Weak Reference proposal (Isiah Meadows)
>2. Re: Weak Reference proposal (Alexander Jones)
>3. Re: Resource management (Isiah Meadows)
>4. Re: Resource management (Isiah Meadows)
>5. Re: Weak Reference proposal (Isiah Meadows)
>
>
> -- Forwarded message --
> From: Isiah Meadows 
> To: Steve Fink 
> Cc: "es-discuss@mozilla.org" 
> Date: Sat, 31 Dec 2016 08:48:19 -0500
> Subject: Re: Weak Reference proposal
> For my particular case, yes it is. Everything mirrored have globally
> unique IDs assigned to them, managed independently of the child
> process (in most cases), and the state is tied to the ID, not the
> value, so I only need a weak reference to clear the backing ID and its
> associated state. And reference cycles within the process are
> mitigated by the existing mark-and-sweep derivatives engines already
> use.
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
>
> On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink  wrote:
> > On 12/27/2016 04:45 AM, Isiah Meadows wrote:
> >
> > The weak reference proposal hasn't seen a lot of activity, and I haven't
> > found much news elsewhere on it. What's the status on it?
> >
> > Where I'm building a language-integrated process pool in Node.js,
> complete
> > with shared "references" and async iterator support, I really badly need
> > weak references to avoid otherwise inevitable memory leaks across
> multiple
> > processes if the references aren't explicitly released. So far, my only
> > option is to take a native dependency (I have no other dependencies), but
> > that's very suboptimal, and it eliminates the possibility of porting to
> > browsers. So I really badly need language-level weak references.
> >
> >
> > Would weak references be enough to solve cross-process garbage
> collection?
> > How would you recover a cycle of references among your processes?
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
> -- Forwarded message --
> From: Alexander Jones 
> To: Isiah Meadows 
> Cc: "es-discuss@mozilla.org" 
> Date: Sat, 31 Dec 2016 14:23:38 +
> Subject: Re: Weak Reference proposal
> Please correct me Isiah/Steve - but I think the problem Steve is talking
> about is *cross-process* cycles. Without an inter-process protocol to
> express the referencing graph, or otherwise negotiate cycles for GC, you'll
> never have a way to reclaim them. Each side thinks the other side is still
> needing the resource.
>
> Cheers
>
> On 31 December 2016 at 13:48, Isiah Meadows 
> wrote:
>
>> For my particular case, yes it is. Everything mirrored have globally
>> unique IDs assigned to them, managed independently of the child
>> process (in most cases), and the state is tied to the ID, not the
>> value, so I only need a weak reference to clear the backing ID and its
>> associated state. And reference cycles within the process are
>> mitigated by the existing mark-and-sweep derivatives engines already
>> use.
>> -
>>
>> Isiah Meadows
>> m...@isiahmeadows.com
>>
>>
>> On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink  wrote:
>> > On 12/27/2016 04:45 AM, Isiah Meadows wrote:
>> >
>> > The weak reference proposal hasn't seen a lot of activity, and I haven't
>> > found much news elsewhere on it. What's the status on it?
>> >
>> > Where I'm building a language-integrated process pool in Node.js,
>> complete
>> > with shared "references"

Re: weak reference proposal

2016-12-31 Thread Uther Pendragon 
If it were me, I would use a socket for ipc and use the socket as the weak
map reference... Thus, when the socket was destroyed, and you get the
SIGPIPE, free the socket reference, and it's referenced object should be
cleared.  This should work, however if you have too many objects, then you
might have to tree it out or something.

I think the idea is a good one for library, I just don't think it's worth
polluting the spec with...  thoughts?

On Dec 31, 2016 11:20 AM,  wrote:

Send es-discuss mailing list submissions to
es-discuss@mozilla.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mail.mozilla.org/listinfo/es-discuss
or, via email, send a message with subject or body 'help' to
es-discuss-requ...@mozilla.org

You can reach the person managing the list at
es-discuss-ow...@mozilla.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of es-discuss digest..."

Today's Topics:

   1. Re: Weak Reference proposal (Isiah Meadows)
   2. Re: Weak Reference proposal (Alexander Jones)
   3. Re: Resource management (Isiah Meadows)
   4. Re: Resource management (Isiah Meadows)
   5. Re: Weak Reference proposal (Isiah Meadows)


-- Forwarded message --
From: Isiah Meadows 
To: Steve Fink 
Cc: "es-discuss@mozilla.org" 
Date: Sat, 31 Dec 2016 08:48:19 -0500
Subject: Re: Weak Reference proposal
For my particular case, yes it is. Everything mirrored have globally
unique IDs assigned to them, managed independently of the child
process (in most cases), and the state is tied to the ID, not the
value, so I only need a weak reference to clear the backing ID and its
associated state. And reference cycles within the process are
mitigated by the existing mark-and-sweep derivatives engines already
use.
-

Isiah Meadows
m...@isiahmeadows.com


On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink  wrote:
> On 12/27/2016 04:45 AM, Isiah Meadows wrote:
>
> The weak reference proposal hasn't seen a lot of activity, and I haven't
> found much news elsewhere on it. What's the status on it?
>
> Where I'm building a language-integrated process pool in Node.js, complete
> with shared "references" and async iterator support, I really badly need
> weak references to avoid otherwise inevitable memory leaks across multiple
> processes if the references aren't explicitly released. So far, my only
> option is to take a native dependency (I have no other dependencies), but
> that's very suboptimal, and it eliminates the possibility of porting to
> browsers. So I really badly need language-level weak references.
>
>
> Would weak references be enough to solve cross-process garbage collection?
> How would you recover a cycle of references among your processes?
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- Forwarded message --
From: Alexander Jones 
To: Isiah Meadows 
Cc: "es-discuss@mozilla.org" 
Date: Sat, 31 Dec 2016 14:23:38 +
Subject: Re: Weak Reference proposal
Please correct me Isiah/Steve - but I think the problem Steve is talking
about is *cross-process* cycles. Without an inter-process protocol to
express the referencing graph, or otherwise negotiate cycles for GC, you'll
never have a way to reclaim them. Each side thinks the other side is still
needing the resource.

Cheers

On 31 December 2016 at 13:48, Isiah Meadows  wrote:

> For my particular case, yes it is. Everything mirrored have globally
> unique IDs assigned to them, managed independently of the child
> process (in most cases), and the state is tied to the ID, not the
> value, so I only need a weak reference to clear the backing ID and its
> associated state. And reference cycles within the process are
> mitigated by the existing mark-and-sweep derivatives engines already
> use.
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
>
> On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink  wrote:
> > On 12/27/2016 04:45 AM, Isiah Meadows wrote:
> >
> > The weak reference proposal hasn't seen a lot of activity, and I haven't
> > found much news elsewhere on it. What's the status on it?
> >
> > Where I'm building a language-integrated process pool in Node.js,
> complete
> > with shared "references" and async iterator support, I really badly need
> > weak references to avoid otherwise inevitable memory leaks across
> multiple
> > processes if the references aren't explicitly released. So far, my only
> > option is to take a native dependency (I have no other dependencies), but
> > that's very suboptimal, and it eliminates the possibility of porting to
> > browsers. So I really badly need language-level weak references.
> >
> >
> > Would weak

Re: weak references

2016-12-28 Thread Uther Pendragon 
...does a weak map not provide that functionality?

...additionally, if writing something that sophisticated, then not managing
your own instances (i.e. Relying on the language to do it for you) is the
same mentality that produces horrible java code.

I also agree with what was said previously...  how are weak references
going to help you with ipc (inter process communication) referencing?


On Dec 28, 2016 6:00 AM,  wrote:

Send es-discuss mailing list submissions to
es-discuss@mozilla.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mail.mozilla.org/listinfo/es-discuss
or, via email, send a message with subject or body 'help' to
es-discuss-requ...@mozilla.org

You can reach the person managing the list at
es-discuss-ow...@mozilla.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of es-discuss digest..."

Today's Topics:

   1. Weak Reference proposal (Isiah Meadows)
   2. Resource management (Isiah Meadows)
   3. Re: Weak Reference proposal (Steve Fink)


-- Forwarded message --
From: Isiah Meadows 
To: "es-discuss@mozilla.org" 
Cc:
Date: Tue, 27 Dec 2016 07:45:32 -0500
Subject: Weak Reference proposal
The weak reference proposal  hasn't
seen a lot of activity, and I haven't found much news elsewhere on it.
What's the status on it?

Where I'm building a language-integrated process pool in Node.js, complete
with shared "references" and async iterator support, I really badly need
weak references to avoid otherwise inevitable memory leaks across multiple
processes if the references aren't explicitly released. So far, my only
option is to take a native dependency (I have no other dependencies), but
that's very suboptimal, and it eliminates the possibility of porting to
browsers. So I really badly need language-level weak references.

-

Isiah Meadows
m...@isiahmeadows.com


-- Forwarded message --
From: Isiah Meadows 
To: "es-discuss@mozilla.org" 
Cc:
Date: Tue, 27 Dec 2016 11:25:11 -0500
Subject: Resource management
In [this GH issue in the async iteration proposal][1], I found that
the async iteration concept itself could theoretically be used for
resource management, such as in this example (copy/pasted from my
initial issue):

```js
const fsp = require("fs-promise")

async function *open(file, opts) {
const fd = await fsp.open(file, opts)
try { yield fd } finally { await fsp.close(fd) }
}

for await (const fd of open("/path/to/file", {mode: "r+"})) {
const bit = await fsp.read(fd)
// do other things...
}

// descriptor automatically closed, so no resource leaks!
```

It's neat and all, but we *really* should have something much better
than that. Maybe something like this?

```js
// Strict mode only
with (const fd = await open("/path/to/file", {mode: "r+"})) {
const bit = await fsp.read(fd)
// do other things...
}
```

(I'm not totally sure about what methods the closeable/etc. API or
protocol should use.)

[1]: https://github.com/tc39/proposal-async-iteration/issues/68

-

Isiah Meadows
m...@isiahmeadows.com



-- Forwarded message --
From: Steve Fink 
To: es-discuss@mozilla.org
Cc:
Date: Tue, 27 Dec 2016 13:34:38 -0800
Subject: Re: Weak Reference proposal
On 12/27/2016 04:45 AM, Isiah Meadows wrote:

The weak reference proposal  hasn't
seen a lot of activity, and I haven't found much news elsewhere on it.
What's the status on it?

Where I'm building a language-integrated process pool in Node.js, complete
with shared "references" and async iterator support, I really badly need
weak references to avoid otherwise inevitable memory leaks across multiple
processes if the references aren't explicitly released. So far, my only
option is to take a native dependency (I have no other dependencies), but
that's very suboptimal, and it eliminates the possibility of porting to
browsers. So I really badly need language-level weak references.


Would weak references be enough to solve cross-process garbage collection?
How would you recover a cycle of references among your processes?


___
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: es-discuss Digest, Vol 118, Issue 14

2016-12-21 Thread Uther Pendragon 
Sorry for quoting all that in my previous reply
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proxy

2016-12-21 Thread Uther Pendragon 
Agreed, but it lacks intent...  I.e., the get handler doesn't know whether
the return value is being called.

Imagine a layer that is so robust and flexible that, to use it, you don't
have to know or care how the things are used...   You just do what makes
sense and it works...  this concept kinda depends on knowing whether
something is being called from, read or assigned when the handler is called.

On Dec 21, 2016 7:05 AM, "Isiah Meadows" <isiahmead...@gmail.com> wrote:

> You can always just return a callable from `handler.get`. Function
> closures are much more ergonomic than proxies for that in my experience,
> although I generally make no distinction regarding `this` (which only
> complicates in this area).
>
> On Wed, Dec 14, 2016, 20:47 Uther Pendragon <uther...@gmail.com> wrote:
>
>> Perhaps it's a bit late... but I'd like to discuss the proxy object.
>> Notably:  why no way to define a hook for when a property is called as a
>> function.
>>
>> I think I understand *why* there isn't one..  I presume because how a
>> property is used (I.e. as a property or called as a function) is a level
>> deeper than the recalling of said property.  If at all possible, I think it
>> would be incredibly useful.  This may be outside the intended purpose of
>> the proxy object, but a proxy for the purposes of a middleware (I hate that
>> word too) that is more dynamic  would be perfect for adaptors etc...
>> Perhaps it's not feasible, because the proxy hook is best applied at the
>> point when the property's definition, which brings me to my next
>> suggestion
>>
>> What about the ability to alter / define the configuration of a scope
>> variable, like those on objects with defineProperty... but with simple
>> scope variables...  I presume most implementations define scope variables
>> much like object properties internally.
>>
>> On Dec 14, 2016 2:56 PM, <es-discuss-requ...@mozilla.org> wrote:
>>
>> Send es-discuss mailing list submissions to
>> es-discuss@mozilla.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://mail.mozilla.org/listinfo/es-discuss
>> or, via email, send a message with subject or body 'help' to
>> es-discuss-requ...@mozilla.org
>>
>> You can reach the person managing the list at
>> es-discuss-ow...@mozilla.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of es-discuss digest..."
>>
>> Today's Topics:
>>
>>1. Re: Ranges (Jeremy Martin)
>>2. Re: Ranges (Alexander Jones)
>>3. Re: Destructuring object outside of var declaration (Jeff Walden)
>>
>>
>> -- Forwarded message --
>> From: Jeremy Martin <jmar...@gmail.com>
>> To: Hikaru Nakashima <oao.hikaru@gmail.com>
>> Cc: es-discuss <es-discuss@mozilla.org>
>> Date: Wed, 14 Dec 2016 11:55:02 -0500
>> Subject: Re: Ranges
>> While slightly more verbose, the previously suggested `...` syntax does
>> have a superficial consistency with the spread operator. Both perform an
>> expansion of sorts, which has a subtle elegance to it, IMO.
>>
>> On Wed, Dec 14, 2016 at 4:02 AM, Hikaru Nakashima <
>> oao.hikaru@gmail.com> wrote:
>>
>> I understand.
>> I hope to find a good form of literals.
>>
>> Is there a fact that literals are easier to optimize in the following
>> cases?
>>
>> ```
>> for (let i of [1 to 5]) { .. }
>> vs
>> for (let i of Array.range(1, 5)) { .. }
>> ```
>>
>> If so, it seems that we can attract vendors' interests.
>>
>> 2016-12-14 17:29 GMT+09:00 Andy Earnshaw <andyearns...@gmail.com>:
>>
>> I think you'd be lucky to even get to that stage.  Vendors aren't keen on
>> any kind of backwards incompatibility in new specs and trying to get this
>> to stage 4 with such a glaring one would be practically  impossible.
>>
>> It's not just the incompatibility either.  You also introduce an
>> inconsistencies where things like `[1..toFixed(2)]` doesn't mean the same
>> as `[ 1..toFixed(2) ]`. That kind of thing is just confusing to developers.
>>
>> When you consider these things, it becomes clear that it's not practical
>> to change the language this way for such a small benefit.
>>
>> On Wed, 14 Dec 2016, 03:00 Hikaru Nakashima, <oao.hikaru@gmail.com>
>> wrote:
>>
>> Oh, I understood it.
>> It looks like serious problem, but it is may not actually.
>> If this spec change doesn't

Proxy

2016-12-14 Thread Uther Pendragon 
Perhaps it's a bit late... but I'd like to discuss the proxy object.
Notably:  why no way to define a hook for when a property is called as a
function.

I think I understand *why* there isn't one..  I presume because how a
property is used (I.e. as a property or called as a function) is a level
deeper than the recalling of said property.  If at all possible, I think it
would be incredibly useful.  This may be outside the intended purpose of
the proxy object, but a proxy for the purposes of a middleware (I hate that
word too) that is more dynamic  would be perfect for adaptors etc...
Perhaps it's not feasible, because the proxy hook is best applied at the
point when the property's definition, which brings me to my next
suggestion

What about the ability to alter / define the configuration of a scope
variable, like those on objects with defineProperty... but with simple
scope variables...  I presume most implementations define scope variables
much like object properties internally.

On Dec 14, 2016 2:56 PM,  wrote:

Send es-discuss mailing list submissions to
es-discuss@mozilla.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mail.mozilla.org/listinfo/es-discuss
or, via email, send a message with subject or body 'help' to
es-discuss-requ...@mozilla.org

You can reach the person managing the list at
es-discuss-ow...@mozilla.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of es-discuss digest..."

Today's Topics:

   1. Re: Ranges (Jeremy Martin)
   2. Re: Ranges (Alexander Jones)
   3. Re: Destructuring object outside of var declaration (Jeff Walden)


-- Forwarded message --
From: Jeremy Martin 
To: Hikaru Nakashima 
Cc: es-discuss 
Date: Wed, 14 Dec 2016 11:55:02 -0500
Subject: Re: Ranges
While slightly more verbose, the previously suggested `...` syntax does
have a superficial consistency with the spread operator. Both perform an
expansion of sorts, which has a subtle elegance to it, IMO.

On Wed, Dec 14, 2016 at 4:02 AM, Hikaru Nakashima 
wrote:

> I understand.
> I hope to find a good form of literals.
>
> Is there a fact that literals are easier to optimize in the following
> cases?
>
> ```
> for (let i of [1 to 5]) { .. }
> vs
> for (let i of Array.range(1, 5)) { .. }
> ```
>
> If so, it seems that we can attract vendors' interests.
>
> 2016-12-14 17:29 GMT+09:00 Andy Earnshaw :
>
>> I think you'd be lucky to even get to that stage.  Vendors aren't keen on
>> any kind of backwards incompatibility in new specs and trying to get this
>> to stage 4 with such a glaring one would be practically  impossible.
>>
>> It's not just the incompatibility either.  You also introduce an
>> inconsistencies where things like `[1..toFixed(2)]` doesn't mean the same
>> as `[ 1..toFixed(2) ]`. That kind of thing is just confusing to developers.
>>
>> When you consider these things, it becomes clear that it's not practical
>> to change the language this way for such a small benefit.
>>
>> On Wed, 14 Dec 2016, 03:00 Hikaru Nakashima, 
>> wrote:
>>
>>> Oh, I understood it.
>>> It looks like serious problem, but it is may not actually.
>>> If this spec change doesn't break web, we can introduce this idea?
>>> ___
>>> 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
>
>


-- 
Jeremy Martin
661.312.3853 <(661)%20312-3853>
http://devsmash.com
@jmar777


-- Forwarded message --
From: Alexander Jones 
To: Hikaru Nakashima , Jeremy Martin <
jmar...@gmail.com>
Cc: es-discuss 
Date: Wed, 14 Dec 2016 20:28:37 +
Subject: Re: Ranges
IMO this is quite unnecessary syntax sugar. Python has everything you could
need here without special syntax.

On Wed, 14 Dec 2016 at 16:55, Jeremy Martin  wrote:

> While slightly more verbose, the previously suggested `...` syntax does
> have a superficial consistency with the spread operator. Both perform an
> expansion of sorts, which has a subtle elegance to it, IMO.
>
> On Wed, Dec 14, 2016 at 4:02 AM, Hikaru Nakashima <
> oao.hikaru@gmail.com> wrote:
>
> I understand.
> I hope to find a good form of literals.
>
> Is there a fact that literals are easier to optimize in the following
> cases?
>
> ```
> for (let i of [1 to 5]) { .. }
> vs
> for (let i of Array.range(1, 5)) { .. }
> ```
>
> If so, it seems that we can attract vendors' interests.
>
> 2016-12-14 17:29 GMT+09:00 Andy Earnshaw :
>
> I think you'd be lucky to