It's my understanding that the vast majority of the CLR's dynamic
language support is at the runtime level, not the bytecode level. The
bytecode is strongly typed (with lots of instructions/mechanisms for
boxing, unboxing and type casts), and dynamic support is done through
something called the
Minor correction to Domenic's comments in this (interesting)
discussion; IEnumerable and IDisposable are separate concepts in C#.
Neither IEnumerable or IEnumerator are disposable objects in C#;
*however*, if you use 'for each' on an object that yields an
enumerator that is *also* disposable, the
Is my understanding correct that __proto__/setPrototypeOf are still
required if you want to do things like that with instances of
Function? Or did Function's constructor finally get patched to let you
set a prototype?
On Mon, Apr 7, 2014 at 2:26 AM, David Bruant bruan...@gmail.com wrote:
Le
I guess the analog for this in traditional JS 'Object' instances is
that when you use the [] operator, i.e. obj[valueObject], it actually
does obj[valueObject.toString()], so you can control the 'hashing
function' in a sense by overriding toString. It seems natural to want
something equivalent
The accuracy of this aside, history shows that most of my users are
not satisfied by 'just debug the JS, it's fairly readable'. Maybe
emscripten, gwt, etc. users are more fluent in JS and don't mind
debugging it, but based on what I've seen, maybe not...
I do think it's important that source maps
I agree that the current source maps format does a poor job of
handling many translation/transpiling/js-as-compilation-target
scenarios. I do think it is worthwhile to try and build on the
existing format instead of reinvent it or significantly overhaul it,
though. The things it does, it does a
are looking for feedback on the proposal! Please keep it
coming.
Here are some answers reflecting our current thinking.
On Sun, Nov 17, 2013 at 4:07 PM, K. Gadd k...@luminance.org wrote:
Since the strawman is close to the final spec, questions/nitpicks:
I noticed the current spec explicitly provides
Are there any known-good polyfills for the current draft Typed Objects /
Binary Data spec?
Presently, JSIL has a set of primitives that roughly correspond with a big
chunk of the draft specification. I'm interested in seeing whether they can
work atop ES6 typed objects, which means either
...@tillschneidereit.net wrote:
On Sun, Nov 17, 2013 at 10:23 AM, K. Gadd k...@luminance.org wrote:
Are there any known-good polyfills for the current draft Typed Objects /
Binary Data spec?
I want this, too, and will start working on it soon-ish if nobody else
does or already did.
Presently, JSIL has a set
Finding out at runtime (by doing a sanity check in the finalizer) is a way
to catch bugs in the application that were not caught at
compile/development time, so you can log/report them and go back and fix
them. This is an incredibly useful facility since (generally speaking)
promise libraries have
. Miller erig...@google.com wrote:
On Sun, Nov 10, 2013 at 1:30 PM, K. Gadd k...@luminance.org wrote:
JSIL and embind both need arguments.length for efficient method call
dispatch when dealing with overloaded functions. Is it your intent that all
such scenarios must now pay the cost of creating
More tooling is great for developing new software in ES, but it does
nothing to address use cases where existing software and algorithms can't
be ported without Weak References. Perhaps enough research will allow us to
arrive at some sort of general 'best practice' for replacing the use of
weak
stays unreachable.
On Fri, Nov 8, 2013 at 2:42 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Nov 7, 2013, at 3:16 PM, Mark Miller wrote:
I agree. This is a good use for weakrefs without the need for
finalization. Thanks!
On Thu, Nov 7, 2013 at 3:12 PM, K. Gadd k...@luminance.org wrote
:
On 11/06/2013 07:37 PM, K. Gadd wrote:
Generally speaking, all the discussions on this list about WRs so far
have
not suggested that there is any way to introduce WeakRefs without making
GC
behavior observable in some fashion. WeakRefs functionally make GC
observable because when you try
, Nov 7, 2013 at 1:46 PM, K. Gadd k...@luminance.org wrote:
When I talk about the importance of weak references I am *not* talking
about the importance of finalization for managing native/remote resources;
that's an important consideration but it's a separate one. When I talk
about why weak
it could be implemented with WeakMap instead
of WeakRef. Am I missing something?
On Thu Nov 07 2013 at 2:43:45 PM, K. Gadd k...@luminance.org wrote:
I'll try and restate an example I used before.
Let's say you're building a somewhat simple tab-based application, where
each tab represents
The problem is that the cycles remain uncollectable for a very long period
of time, even though functionally the references don't need to be strong.
On Thu, Nov 7, 2013 at 3:10 PM, David Bruant bruan...@gmail.com wrote:
Le 07/11/2013 22:46, K. Gadd a écrit :
That's the sort of obstacle
your heap using your own lifetime
rules.
On Thu, Nov 7, 2013 at 4:27 PM, Marius Gundersen gunder...@gmail.comwrote:
On Thu, Nov 7, 2013 at 11:42 PM, K. Gadd k...@luminance.org wrote:
I'll try and restate an example I used before.
Let's say you're building a somewhat simple tab-based
Generally speaking, all the discussions on this list about WRs so far have
not suggested that there is any way to introduce WeakRefs without making GC
behavior observable in some fashion. WeakRefs functionally make GC
observable because when you try to get at the target of the weakref, you
either
Requiring early registration prevents the use of futures as value
containers; i.e. kicking off an operation and storing the Future somewhere
so anyone can use it at a later date.
I agree that an improved error handling policy would be very, very good to
have, though.
On Mon, Oct 21, 2013 at
Did anyone address what should be done in the use case where it's necessary
for information to 'tag along' with an array or typed array, for interop
purposes? The existence of interior binary data objects seems to complicate
this further; for example I had said that it seems like WeakMap allows
To me the compelling argument against using encapsulation instead of
extensibility is that it breaks compatibility with existing JS code. Once
you encapsulate an array, the encapsulated object no longer acts like an
array and you can't use it in contexts where a normal array is expected.
The
and ruled out (it would definitely be strange to mix that with
passing in actual StructType instances).
-kg
On Wed, Aug 21, 2013 at 10:36 AM, Dmitry Lomov dslo...@chromium.org wrote:
On Wed, Aug 21, 2013 at 6:50 PM, K. Gadd k...@luminance.org wrote:
Does this mean the addition of binary data
Why is the slow script dialog box even relevant for setImmediate? As I
understand it, setImmediate is equivalent to DoEvents in Visual
Basic/Windows Forms and pumping the message loop in a normal C application.
That is, you can use setImmediate to make your application run as fast as
possible
If memory serves,
http://point.davidglasser.net/2013/06/27/surprising-javascript-memory-leak.htmlwas
also complaining about a similar closure/scope leak in v8 where locals
that you wouldn't expect to be retained are retained by closures in some
cases.
Arguably those cases just need to be fixed.
The builtin could have weak values (i.e. Symbol instances expire when no
longer referenced by JS) instead of weak keys, which is not something we
can currently express in JS. This would also make it possible to use
strings/integers/floats as Symbol keys without leaking those Symbol
instances
Sorry Jeff, but this is actually not the case. The performance consequences
from using .bind() can be quite severe because it pollutes type information
and disables fast paths. Not 'your entire application runs in the
interpreter' slow, but surprisingly slow. It can even slow down code paths
where
I've had some back and forth with v8 devs about this since it affects my
compiler. I believe they already have open issues about it but I don't know
the bug #s.
In general, the problem seems to be that Function.bind creates functions
that have different type information from normal functions you
I would welcome (with fanfare and parades) a new Symbol(obj) that worked
for strings and integers. Such is not possible using the WeakMap shim
(you'd have to detect the type of the value and have multiple dictionaries,
or something, and you'd leak the symbols forever...)
Of course, what that
In addition to the perf savings from not having to allocate (to call bind)
not needing to use bind() for cases like .find() can have beneficial
effects for JITs as well. It's my understanding that at a recent point in
time (maybe even still today?) functions created by bind() had the ability
to
I think at this point we have a long history of language designs where
random stuff has been tacked onto the core base class (i.e. Object) that
really shouldn't have gone there - hashCode/toString in Java/C#, etc - such
that any proposal to put something on Object instances deserves extreme
31 matches
Mail list logo
