Buffer() without new keyword?

[ghost]

Hi. Great work with this project! I really like it :+1:

However I was looking at substack repo and discovered this: https://github.com/substack/node-deep-equal/issues/42

[dead-claudia]

Where do you find it in the source? I don't recall a single usage of it, so it shouldn't affect me (other than maybe tests, but that's trivial to fix, and won't result in a new release).

On Wed, Sep 7, 2016, 19:17 crazyhuggins notifications@github.com wrote:

Hi. Great work with this project! I really like it 👍

However I was looking at substack repo and discovered this: substack/node-deep-equal#42 https://github.com/substack/node-deep-equal/issues/42

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/8, or mute the thread https://github.com/notifications/unsubscribe-auth/AERrBGDtTqbNsoQK3rc0_A4Gi-CVweahks5qn0YKgaJpZM4J3dEz .

[ghost]

It's not in your source code, but you wrote this "This code was initially derived from node-deep-equal by James Halliday", so I just noticed you wasn't supporting it? And this features now have a deprecation warning.

[dead-claudia]

It's derived from it initially (I wasn't about to take credit), but I've edited it so much it bears little resemblance to the original except at a high level. For one, it works with ES6 Maps, Sets, and Symbols, complete with loose equality, which the original does not. Second, I support a third type of test that does strict, but purely structural, checking (no prototype matching, and Symbols aren't checked for identity). I really need to document this eventually, it's just I haven't gotten around to it (along with the 90 or so related assertions).

On Wed, Sep 7, 2016, 19:52 crazyhuggins notifications@github.com wrote:

It's not in your source code, but you wrote this "This code was initially derived from node-deep-equal by James Halliday", so I just noticed you wasn't supporting it? And this features now have a deprecation warning.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/8#issuecomment-245454661, or mute the thread https://github.com/notifications/unsubscribe-auth/AERrBCZIgiiE1j-H93N02hZUdNfvSPbgks5qn05FgaJpZM4J3dEz .

[ghost]

https://github.com/teppeis/deeq did you see this? With strict key order are checked for Set and Map. And the new prototypes for map() will work?

[dead-claudia]

@crazyhuggins I've explicitly coded the algorithm to be independent of key order for all types, simply because relying on key order for traditionally unordered collections is, in my experience, rather bug-prone, and is rarely necessary for the work at hand. (I've only used key order a few times, and all but one of those were later refactored away to something much cleaner.)

You may be surprised to find that it actually took extra work to ensure new Set([1, 2, 3]) and new Set([3, 2, 1]) actually matched (and equivalent for Maps`).

And I do invite you to take a look at the implementation itself.

To maybe answer a few more potential questions, here is what it supports:

• Strict + nominal (t.deepEqual), strict + structural (t.match), loose + structural (t.deepEqualLoose)
  • Nominal: t.deepEqual({}, Object.create({})) fails
  • Structural: t.match({}, Object.create({})) succeeds
• Symbols checked for description equality, not identity, for t.match and t.deepEqualLoose
• Circular references checked for equality (#6)
• NaNs are equal, through the Object.is algorithm
• RegExp matching (#7)
• Date matching
• arguments matching
  • t.match((function () { return arguments })(), []) fails
• TypedArray and Buffer matching
• Ignores keys like stack added to thrown objects by IE, Edge, Safari, and PhantomJS
• Map and Set matching, key order independent, and properly loosely checked for t.deepEqualLoose
• Supports ES5 without polyfills, but works with global polyfills for Map and Set (if loaded before your first require("thallium"))
  • Maps and Sets aren't checked when only one is polyfilled, but no engine ships one without the other, and most polyfill users use both, anyways
  • This won't work with third-party ponyfills, since duck testing isn't practical, and I want to minimize execution of the arguments' methods.
• Expando properties are fully checked (e.g. an extra arr.foo = 1 or even arguments.foo = 1 is also checked)

I made sure to cover a lot of bases. If I'm going to write a deep equality library for testing, I'm going to prefer completeness over ease of implementation.

[dead-claudia]

Between that and the various optimizations [1] (to keep the running times sane), it's well over 500 lines of code (vs the 120 or so for deeq and deep-equal, about 270 for Chai's deep-eql, about 200 for Jasmine's algorithm, etc.).

[1]: Things like checking indices first, avoiding runtime-generated closures (since the code is highly polymorphic), limiting polymorphism where possible, etc.

[ghost]

I understand it now :) Actually I talked to a friend of mine too yesterday that is an expert on such things, and he told me - after he looked at your code - that you did a amazing GOOD job and he was surprised about your skills :)

But he noticed there was some obvious bottle necks in your algo? I'm not sure what I mean with that, but he wrote a simple algo himself to point out the differences and where the bottlenecks are.

He doesn't have a Github, or maybe he created one yesterday. Not sure :)

Yours:

NaN                            x 37,520,025 ops/sec ±0.57% (92 runs sampled)
string literal              x 39,753,005 ops/sec ±0.57% (93 runs sampled)
array literal               x 309,051 ops/sec ±0.53% (92 runs sampled)
boolean literal             x 39,622,088 ops/sec ±0.49% (91 runs sampled)
object literal              x 1,172,920 ops/sec ±0.59% (88 runs sampled)
object from null            x 1,589,217 ops/sec ±0.75% (89 runs sampled)
regex literal               x 1,329,053 ops/sec ±0.82% (91 runs sampled)
number literal              x 42,213,429 ops/sec ±0.55% (88 runs sampled)
null                        x 39,036,191 ops/sec ±0.85% (93 runs sampled)
undefined                   x 39,348,740 ops/sec ±0.67% (91 runs sampled)
date                        x 1,411,588 ops/sec ±1.14% (88 runs sampled)
regex constructor           x 1,004,130 ops/sec ±0.68% (90 runs sampled)
string constructor          x 773,232 ops/sec ±0.86% (91 runs sampled)
string literal (differing)  x 29,061,520 ops/sec ±0.43% (91 runs sampled)
array literal (differing)   x 2,057,313 ops/sec ±0.82% (89 runs sampled)
boolean literal (differing) x 32,319,124 ops/sec ±0.57% (94 runs sampled)
object literal (differing)  x 989,009 ops/sec ±1.02% (87 runs sampled)
regex literal (differing)   x 10,122,073 ops/sec ±1.12% (90 runs sampled)
number literal (differing) :
null & undefined            x 31,707,553 ops/sec ±0.60% (90 runs sampled)
date (differing)            x 8,445,773 ops/sec ±0.59% (92 runs sampled)
error                      :
regex ctor (differing)      x 9,930,519 ops/sec ±0.47% (91 runs sampled)
string ctor (differing)    :
weakmap                    :
weakset                    :
promise                    :

His (quick dirty work he said):

NaN                            x 39,799,909 ops/sec ±0.16% (91 runs sampled)
string literal              x 43,785,121 ops/sec ±0.51% (88 runs sampled)
array literal               x 3,854,342 ops/sec ±0.58% (90 runs sampled)
boolean literal             x 40,839,804 ops/sec ±0.49% (93 runs sampled)
object literal              x 2,317,986 ops/sec ±0.57% (90 runs sampled)
object from null            x 3,390,177 ops/sec ±0.64% (92 runs sampled)
regex literal               x 15,403,105 ops/sec ±0.78% (90 runs sampled)
number literal              x 45,846,439 ops/sec ±0.85% (88 runs sampled)
null                        x 42,618,306 ops/sec ±0.60% (88 runs sampled)
undefined                   x 42,727,581 ops/sec ±0.53% (92 runs sampled)
date                        x 23,136,702 ops/sec ±0.60% (89 runs sampled)
regex constructor           x 14,990,824 ops/sec ±0.59% (90 runs sampled)
string constructor         :
string literal (differing)  x 34,924,710 ops/sec ±0.54% (90 runs sampled)
array literal (differing)   x 4,775,895 ops/sec ±0.61% (88 runs sampled)
boolean literal (differing) x 37,511,439 ops/sec ±0.53% (91 runs sampled)
object literal (differing)  x 2,199,399 ops/sec ±0.68% (90 runs sampled)
regex literal (differing)   x 23,134,269 ops/sec ±1.03% (89 runs sampled)
number literal (differing) :
null & undefined            x 35,193,209 ops/sec ±0.52% (95 runs sampled)
date (differing)            x 22,800,127 ops/sec ±0.87% (91 runs sampled)
error                       x 10,237,955 ops/sec ±0.54% (91 runs sampled)
regex ctor (differing)      x 22,276,672 ops/sec ±0.69% (88 runs sampled)
string ctor (differing)     x 9,576,583 ops/sec ±0.57% (91 runs sampled)
weakmap                     x 12,350,834 ops/sec ±1.08% (87 runs sampled)
weakset                     x 11,459,314 ops/sec ±0.69% (90 runs sampled)
promise                     x 13,137,372 ops/sec ±0.65% (90 runs sampled)

[dead-claudia]

I'd gladly accept PRs to improve it. (I tried to optimize the obvious parts, but I haven't actually profiled it yet.)

On Sun, Sep 11, 2016, 23:33 crazyhuggins notifications@github.com wrote:

I understand it now :) Actually I talked to a friend of mine too yesterday that is an expert on such things, and he told me there was some obvious bottle necks in your algo? I'm not sure what I mean with that, but he wrote a simple algo to illustrate it. He doesn't have a Github, or maybe he created one yesterday. Not sure :)

Yours:

NaN x 37,789,369 ops/sec ±0.64% (91 runs sampled) string literal x 40,213,125 ops/sec ±0.53% (92 runs sampled) boolean literal x 39,392,311 ops/sec ±0.58% (89 runs sampled) object literal x 1,232,373 ops/sec ±0.87% (91 runs sampled) object from null x 1,419,896 ops/sec ±0.65% (89 runs sampled) regex literal x 1,299,209 ops/sec ±0.74% (92 runs sampled) number literal x 41,063,716 ops/sec ±0.71% (94 runs sampled)null x 38,519,227 ops/sec ±0.54% (93 runs sampled)undefined x 39,956,628 ops/sec ±1.66% (90 runs sampled) date x 1,392,679 ops/sec ±0.75% (91 runs sampled)

His (quick dirty work he said):

NaN x 39,733,070 ops/sec ±0.92% (92 runs sampled) string literal x 38,415,608 ops/sec ±0.52% (90 runs sampled) boolean literal x 43,479,955 ops/sec ±0.54% (91 runs sampled) object literal x 2,999,654 ops/sec ±0.92% (86 runs sampled) object from null x 4,008,198 ops/sec ±1.26% (91 runs sampled) regex literal x 16,038,269 ops/sec ±0.46% (90 runs sampled) number literal x 47,138,598 ops/sec ±0.37% (89 runs sampled)null x 37,025,127 ops/sec ±0.39% (90 runs sampled)undefined x 41,080,480 ops/sec ±0.50% (91 runs sampled) date x 23,071,170 ops/sec ±0.55% (92 runs sampled)

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/8#issuecomment-246236096, or mute the thread https://github.com/notifications/unsubscribe-auth/AERrBGNLxU7If3PxeJ6wtP0ChH1x2XObks5qpMgegaJpZM4J3dEz .

[ghost]

Hi. I asked my firend about it earlier if he would help out, and he told me on Skype that he was looking at your requirments. So he would need to fire up Karma too. I guess he either send a PR or invite you to a repo once he is done so you could cherry pick.

[ghost]

@isiahmeadows Hi! I'm looking into your algorithm now, and I will come up with a improved solution within a few days I guess. I'm new to open source and little scared to dive into others code without any knowledge, so I will just put up a repo and let you take it from there if you like my solution.

Just now I have everything covered, but I guess massive use of instanceOf will have bad impact on V8's hidden classes in a browser environment. I'm not sure, but for NodeJS it's ok.

Another issue is - if this is going to run in browser - WeakMap and WeakSet. Both of this two has issues with IE11, and need some work to patch it. Also same with Promises. There are loads of different promise libraries, and feature detect native ES6 Promises is easy, but not allways you can rely on .then for 3rd party libs. And also Generators will cause extra work for the Edge browser.

It's also hilarious how Lodash claim to have best performance, but it's turn out it's one of the worst on performance if you benchmark isEqual.

Left now is Map() and Set(). I guess I can inherit some of your great work?

Outstanding good job with this library!! :+1:

[dead-claudia]

@zubuzon I understand the feeling of uncertainty when you're just getting started with open source. We've all been there at some point. And in case you're wondering, the best way to learn about how code works is just to play with it. 😄

Just now I have everything covered, but I guess massive use of instanceOf will have bad impact on V8's hidden classes in a browser environment. I'm not sure, but for NodeJS it's ok.

It shouldn't have much of a performance impact beyond what you would normally expect of type checking operators (beyond typeof). It does do a full prototype walk in the worst case, so keep that in mind.

Another issue is - if this is going to run in browser - WeakMap and WeakSet. Both of this two has issues with IE11, and need some work to patch it.

It does support browsers (tested in Firefox and Chrome), and it's also tested in legacy engines (all the way to Node 0.10, which has zero ES6 support, and PhantomJS 1.x, running an ancient WebKit version used in Safari 5). So WeakMaps and WeakSets (as well as Maps and Sets) aren't guaranteed to exist. The Promises used everywhere are actually Bluebird promises, not native ones.

It's also hilarious how Lodash claim to have best performance, but it's turn out it's one of the worst on performance if you benchmark isEqual.

The performance focus IIRC was on the iteration functions like _.map, _.filter, etc., and on the function-manipulating functions like _.partial, _.bind, etc. But if you're actually dealing with performance issues, chances are you may have to give those up.

Outstanding good job with this library!! 👍

Thank you! 😄

[dead-claudia]

Oh, all you need is to do this:

1. Install Node.js if you haven't already.
2. Fork this repo to your local account. GitHub has help topics for this.
3. Clone the fork to wherever. GitHub also has help topics for this.
4. Run npm install (this will install Karma locally)
5. Hack around. Check out the readme for helpful commands.
6. Commit your changes locally.
7. Push them to your fork. You can find plenty of resources online if you need them.
8. Open a pull request. GitHub has help articles for this.
9. I may suggest a few changes (something doesn't look right) or additions (something is missing). In this case, go back to step 4.
10. I'll likely merge your contribution.
11. You've successfully contributed to the project.

On Mon, Sep 12, 2016, 08:58 zubuzon notifications@github.com wrote:

@isiahmeadows https://github.com/isiahmeadows Hi! I'm looking into your algorithm now, and I will come up with a improved solution within a few days I guess. I'm new to open source and little scared to dive into others code without any knowledge, so I will just put up a repo and let you take it from there if you like my solution.

Great work with this library!! 👍

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/8#issuecomment-246338877, or mute the thread https://github.com/notifications/unsubscribe-auth/AERrBOlm0CpDF3yYnT6mJ9p6O0PwTVq9ks5qpUxegaJpZM4J3dEz .

[dead-claudia]

That's generally the workflow with most GitHub projects. (Larger projects like Angular or jQuery often have a more complicated step 4, but that's most of the variation.)

On Mon, Sep 12, 2016, 16:44 Isiah Meadows impinball@gmail.com wrote:

Oh, all you need is to do this:

1. Install Node.js if you haven't already.
2. Fork this repo to your local account. GitHub has help topics for this.
3. Clone the fork to wherever. GitHub also has help topics for this.
4. Run npm install (this will install Karma locally)
5. Hack around. Check out the readme for helpful commands.
6. Commit your changes locally.
7. Push them to your fork. You can find plenty of resources online if you need them.
8. Open a pull request. GitHub has help articles for this.
9. I may suggest a few changes (something doesn't look right) or additions (something is missing). In this case, go back to step 4.
10. I'll likely merge your contribution.
11. You've successfully contributed to the project.

On Mon, Sep 12, 2016, 08:58 zubuzon notifications@github.com wrote:

@isiahmeadows https://github.com/isiahmeadows Hi! I'm looking into your algorithm now, and I will come up with a improved solution within a few days I guess. I'm new to open source and little scared to dive into others code without any knowledge, so I will just put up a repo and let you take it from there if you like my solution.

Great work with this library!! 👍

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/8#issuecomment-246338877, or mute the thread https://github.com/notifications/unsubscribe-auth/AERrBOlm0CpDF3yYnT6mJ9p6O0PwTVq9ks5qpUxegaJpZM4J3dEz .

[ghost]

Hi. I will just experiment a little regarding this. However you can speed up the regEx and date comparison checks very easy refactor deepEqual to be factory function you are calling when needed. And quickly bail out if any match

function deepEqual() {
// do primitive check directly here
return objMatch(matcher, deepEqual, a, b); // then this...
}

function objMatch(matcher, deepEqual, a, b) {}

.../ No need for strictIs etc now. Only use deepEqual

That gave me improved performance. And for the keys you are checking, just call the same deepEqual function again.

I'm still experimenting on this, and I found issues with your Set() implementation. Set() can actually have circular references, but in your code this will break.

 var set1 = new Set;
 var  set2 = new Set;

        set1.add(set1);
        set2.add(set2);

       //  set1 and set2 -> true

        set1.add(1);
        set2.add(2);

       //  set1 and set2 -> false

And I'm not sure about transitive equivalence for circular references.

In fact there are various stuff I have noticed so far, but I will look into it. Just now I got a unforeseen meeting with a client so I have to deal with that first.

[ghost]

Another issue is your NaN checks, and the fact your code see +0, -0 as equal. In the original Object.is implementation this will return falsey in strict mode.

a !== 0 || 1 / a === 1 / b; // original code

This will anyway be fixed if you deepEqual as a factory function. All primitives etc will have performance boost with around 30 - 40%.

In first place I'm going to put together some code that demonstrate all this, and we can discuss it from there before I port the code to Thallium (if you like my solutions)

Now I'm heading out for my meeting.

[dead-claudia]

The double check for circular references is actually to check that each object contains the equivalent reference for each. I didn't catch the set issue (maps have similar problems), though, so thanks for that.

As for Object.is(0, -0) === false, I intentionally deviated simply because I've yet to find a use case beyond formatting objects to strings (util.inspect does this). I'll admit my comparison was slightly off (it's actually strict equality, except NaNs are equal).

I do suspect the primitive issue is because I abstracted too much (no engine AFAIK inlines highly polymorphic calls). To be honest, the CLI is where most of the optimization is needed, though, because it's doing way too much I/O for my liking (although this will help).

On Mon, Sep 12, 2016, 20:37 zubuzon notifications@github.com wrote:

Hi. I will just experiment a little regarding this. However you can speed up the regEx and date comparison checks very easy refactor deepEqual to be factory function you are calling when needed. And quickly bail out if any match

function deepEqual() {// do primitive check directly herereturn objMatch(matcher, deepEqual, a, b); // then this... } function objMatch(matcher, deepEqual, a, b) {} .../ No need for strictIs etc now. Only use deepEqual

That gave me improved performance. And for the keys you are checking, just call the same deepEqual function again.

I'm still experimenting on this, and I found issues with your Set() implementation. Set() can actually have circular references, but in your code this will break.

var set1 = new Set; var set2 = new Set;

    set1.add(set1);
    set2.add(set2);

   //  set1 and set2 -> true

    set1.add(1);
    set2.add(2);

   //  set1 and set2 -> false

And I'm not sure about transitive equivalence for circular references.

In fact there are various stuff I have noticed so far, but I will look into it. Just now I got a unforeseen meeting with a client so I have to deal with that first.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/8#issuecomment-246538816, or mute the thread https://github.com/notifications/unsubscribe-auth/AERrBAzR85iMst_Zvi0hEqm8IOxuK8xcks5qpfBPgaJpZM4J3dEz .

[ghost]

I'm in the car now, but i can look into your CLI soon as this is settled. And if you don't do a -0,+0 check all primitives will get a 60% performance boost.

However. Im not sure if we are following the ECMA standards here? If so in ecma-262 v. 7 regex, primitives and so on they should all be seen as equal if you coerce them to strings. http://www.ecma-international.org/ecma-262/7.0/#sec-regexp.prototype.tostring

On Sep 13, 2016 8:56 AM, "Isiah Meadows" notifications@github.com wrote:

The double check for circular references is actually to check that each object contains the equivalent reference for each. I didn't catch the set issue (maps have similar problems), though, so thanks for that.

As for Object.is(0, -0) === false, I intentionally deviated simply because I've yet to find a use case beyond formatting objects to strings (util.inspect does this). I'll admit my comparison was slightly off (it's actually strict equality, except NaNs are equal).

I do suspect the primitive issue is because I abstracted too much (no engine AFAIK inlines highly polymorphic calls). To be honest, the CLI is where most of the optimization is needed, though, because it's doing way too much I/O for my liking (although this will help).

On Mon, Sep 12, 2016, 20:37 zubuzon notifications@github.com wrote:

Hi. I will just experiment a little regarding this. However you can speed up the regEx and date comparison checks very easy refactor deepEqual to be factory function you are calling when needed. And quickly bail out if any match

function deepEqual() {// do primitive check directly herereturn objMatch(matcher, deepEqual, a, b); // then this... } function objMatch(matcher, deepEqual, a, b) {} .../ No need for strictIs etc now. Only use deepEqual

That gave me improved performance. And for the keys you are checking, just call the same deepEqual function again.

I'm still experimenting on this, and I found issues with your Set() implementation. Set() can actually have circular references, but in your code this will break.

var set1 = new Set; var set2 = new Set;

set1.add(set1); set2.add(set2);

// set1 and set2 -> true

set1.add(1); set2.add(2);

// set1 and set2 -> false

And I'm not sure about transitive equivalence for circular references.

In fact there are various stuff I have noticed so far, but I will look into it. Just now I got a unforeseen meeting with a client so I have to deal with that first.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/ 8#issuecomment-246538816, or mute the thread https://github.com/notifications/unsubscribe-auth/AERrBAzR85iMst_ Zvi0hEqm8IOxuK8xcks5qpfBPgaJpZM4J3dEz .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/8#issuecomment-246541599, or mute the thread https://github.com/notifications/unsubscribe-auth/AVG55-DCEv8p8Ltj_axPXZVZoQvZ0phAks5qpfSjgaJpZM4J3dEz .

[dead-claudia]

Yes, that's the case for primitives of the same type. I'll try to find time tomorrow to get this all done.

(By the way, I don't differentiate positive and negative 0.)

On Mon, Sep 12, 2016, 21:09 zubuzon notifications@github.com wrote:

Im in the car now, but i can look into your CLI soon as this is settled. And if you dont do a -0,+0 check all primitives will get a 60% performance boost.

However. Im not sure if we are following the ECMA standards here? If so in ecma-262 v. 7 regex, primitives and so on they should all be seen as equal if you coerce them to strings.

On Sep 13, 2016 8:56 AM, "Isiah Meadows" notifications@github.com wrote:

The double check for circular references is actually to check that each object contains the equivalent reference for each. I didn't catch the set issue (maps have similar problems), though, so thanks for that.

As for Object.is(0, -0) === false, I intentionally deviated simply because I've yet to find a use case beyond formatting objects to strings (util.inspect does this). I'll admit my comparison was slightly off (it's actually strict equality, except NaNs are equal).

I do suspect the primitive issue is because I abstracted too much (no engine AFAIK inlines highly polymorphic calls). To be honest, the CLI is where most of the optimization is needed, though, because it's doing way too much I/O for my liking (although this will help).

On Mon, Sep 12, 2016, 20:37 zubuzon notifications@github.com wrote:

Hi. I will just experiment a little regarding this. However you can speed up the regEx and date comparison checks very easy refactor deepEqual to be factory function you are calling when needed. And quickly bail out if any match

function deepEqual() {// do primitive check directly herereturn objMatch(matcher, deepEqual, a, b); // then this... } function objMatch(matcher, deepEqual, a, b) {} .../ No need for strictIs etc now. Only use deepEqual

That gave me improved performance. And for the keys you are checking, just call the same deepEqual function again.

I'm still experimenting on this, and I found issues with your Set() implementation. Set() can actually have circular references, but in your code this will break.

var set1 = new Set; var set2 = new Set;

set1.add(set1); set2.add(set2);

// set1 and set2 -> true

set1.add(1); set2.add(2);

// set1 and set2 -> false

And I'm not sure about transitive equivalence for circular references.

In fact there are various stuff I have noticed so far, but I will look into it. Just now I got a unforeseen meeting with a client so I have to deal with that first.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/ 8#issuecomment-246538816, or mute the thread https://github.com/notifications/unsubscribe-auth/AERrBAzR85iMst_ Zvi0hEqm8IOxuK8xcks5qpfBPgaJpZM4J3dEz .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/isiahmeadows/thallium/issues/8#issuecomment-246541599>, or mute the thread < https://github.com/notifications/unsubscribe-auth/AVG55-DCEv8p8Ltj_axPXZVZoQvZ0phAks5qpfSjgaJpZM4J3dEz

.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/8#issuecomment-246543423, or mute the thread https://github.com/notifications/unsubscribe-auth/AERrBMne8d8D5Tod2OyMF89CkbmCcYdMks5qpfeqgaJpZM4J3dEz .

[ghost]

I will put up a demo repo for this soon as I get home. I got it all working except for Set() and Map(). And also covers everything. But i need to find better ways a few places so see it as a stupid playground.

I probably would need to run all tests through karma as well.

On Sep 13, 2016 9:13 AM, "Isiah Meadows" notifications@github.com wrote:

Yes, that's the case for primitives of the same type. I'll try to find time tomorrow to get this all done.

(By the way, I don't differentiate positive and negative 0.)

On Mon, Sep 12, 2016, 21:09 zubuzon notifications@github.com wrote:

Im in the car now, but i can look into your CLI soon as this is settled. And if you dont do a -0,+0 check all primitives will get a 60% performance boost.

However. Im not sure if we are following the ECMA standards here? If so in ecma-262 v. 7 regex, primitives and so on they should all be seen as equal if you coerce them to strings.

On Sep 13, 2016 8:56 AM, "Isiah Meadows" notifications@github.com wrote:

The double check for circular references is actually to check that each object contains the equivalent reference for each. I didn't catch the set issue (maps have similar problems), though, so thanks for that.

As for Object.is(0, -0) === false, I intentionally deviated simply because I've yet to find a use case beyond formatting objects to strings (util.inspect does this). I'll admit my comparison was slightly off (it's actually strict equality, except NaNs are equal).

I do suspect the primitive issue is because I abstracted too much (no engine AFAIK inlines highly polymorphic calls). To be honest, the CLI is where most of the optimization is needed, though, because it's doing way too much I/O for my liking (although this will help).

On Mon, Sep 12, 2016, 20:37 zubuzon notifications@github.com wrote:

Hi. I will just experiment a little regarding this. However you can speed up the regEx and date comparison checks very easy refactor deepEqual to be factory function you are calling when needed. And quickly bail out if any match

function deepEqual() {// do primitive check directly herereturn objMatch(matcher, deepEqual, a, b); // then this... } function objMatch(matcher, deepEqual, a, b) {} .../ No need for strictIs etc now. Only use deepEqual

That gave me improved performance. And for the keys you are checking, just call the same deepEqual function again.

I'm still experimenting on this, and I found issues with your Set() implementation. Set() can actually have circular references, but in your code this will break.

var set1 = new Set; var set2 = new Set;

set1.add(set1); set2.add(set2);

// set1 and set2 -> true

set1.add(1); set2.add(2);

// set1 and set2 -> false

And I'm not sure about transitive equivalence for circular references.

In fact there are various stuff I have noticed so far, but I will look into it. Just now I got a unforeseen meeting with a client so I have to deal with that first.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/ 8#issuecomment-246538816, or mute the thread https://github.com/notifications/unsubscribe-auth/AERrBAzR85iMst_ Zvi0hEqm8IOxuK8xcks5qpfBPgaJpZM4J3dEz .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/isiahmeadows/thallium/issues/8#issuecomment-246541599 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AVG55-DCEv8p8Ltj_ axPXZVZoQvZ0phAks5qpfSjgaJpZM4J3dEz

.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/ 8#issuecomment-246543423, or mute the thread https://github.com/notifications/unsubscribe-auth/ AERrBMne8d8D5Tod2OyMF89CkbmCcYdMks5qpfeqgaJpZM4J3dEz .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/8#issuecomment-246544181, or mute the thread https://github.com/notifications/unsubscribe-auth/AVG55-shuVBLQyDtADOeqdHsD-nRFsH8ks5qpfjSgaJpZM4J3dEz .

[ghost]

One quick thing to mention before I'm gone for awhile. I did a totaly rewrite of your code in my experiment, but copied your tests. All your tests passes 100%. In fact I have around 100 tests running. Still. Things have to be improved A LOT. I'm not happy at all with my solution, and absolutely not to be used in production.

You will see it later.

[ghost]

@isiahmeadows I added a repo without the source for now, here: https://github.com/zubuzon/booxi I need to talk to @crazyhuggins about how to set up Travis, and how to give you access rights.

[ghost]

@isiahmeadows My experiment code is now uploaded, so I will just play around with it to find the perfect combination with bits and bytes and then try to implement it on Thallium as a PR. I linked to the repo above, and sent you a invite for access rights as well.

update You are missing a lot of features, that now gives me headache. See this as one example: https://github.com/zubuzon/booxi/issues/1

Also your Symbol() implementation failed on this Symbol.iterator. I fixed the Symbol() issue with a little rewrite. Shouldn't bee to hard to skip this checks for Strict mode if that's needed.

update again Sorry to say. I couldn't figure out your Map() implementation, so I made a simpler solution and made sure all your Map() tests works. And circular references for Map() also fixed :+1: You see it here: https://github.com/zubuzon/booxi/blob/master/test/specs/booxi.ts#L872

Your Map() performance

map                         x 381,333 ops/sec ±0.46% (91 runs sampled)

My experiment

map                         x 594,083 ops/sec ±1.46% (91 runs sampled)

Anyway. My main goal now will be to add support for EVERYTHING, then performance and back port this to Thallium.

Status

• supports allmost all ECMA features
• 221 tests running now
• circular references fixed
• cyclic structured works
• nested object works
• small code size

Both Loose and Strict mode works as well, but didn't figure out the difference between them and Match mode yet. But should work too.

Not sure if I should continue on this? It will probably be rejected, and my head isn't with me now :)

[ghost]

@isiahmeadows I worked a little more on this now, and have almost implemented all features you was missing, and the performance seems to be okay. For generators I get this perf:

generator func (differing)  x 13,905,669 ops/sec ±0.76% (89 runs sampled)

Still things has to be moved around a little to gain even better performance, and fix the Key issue, but after that I think this is good to go?

[ghost]

I'm done! @crazyhuggins you see my prototype / experimental solution here: https://github.com/zubuzon/booxi

There are little perf loss now, but still faster then current implementation. And there is a few issues yet to solve, but this is a prototype, and I'm not even sure if @isiahmeadows want me to back port this solution to Thallium.

[dead-claudia]

Feel free to go ahead and do it yourself if you like! Recent family issues are taking a lot of my time, so I won't have much time to do it. :-(

(Keep in mind this is more of a pet project of mine, something I've been working on for a while in my free time.)

On Tue, Sep 13, 2016, 10:02 zubuzon notifications@github.com wrote:

I'm done! @crazyhuggins https://github.com/crazyhuggins you see my prototype / experimental solution here: https://github.com/zubuzon/booxi

There are little perf loss now, but still faster then current implementation. And there is a few issues yet to solve, but this is a prototype, and I'm not even sure if @isiahmeadows https://github.com/isiahmeadows want me to back port this solution to Thallium.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/8#issuecomment-246691213, or mute the thread https://github.com/notifications/unsubscribe-auth/AERrBGSdmOfJzuiILRAc29y5hvPHgcJ-ks5qpqz4gaJpZM4J3dEz .

[ghost]

Sorry to hear about your personal issues :(

I have client meetings the next days but i will try to squeeze in some time to finish and send a PR.

No worries I will try my best to stay true to your original code, but havent figured out your match mode yet. I guess i need to study your assertion library. With so many new features i would need to know what should be "loose" or not.

Take care of your family1

On Sep 13, 2016 10:40 PM, "Isiah Meadows" notifications@github.com wrote:

Feel free to go ahead and do it yourself if you like! Recent family issues are taking a lot of my time, so I won't have much time to do it. :-(

(Keep in mind this is more of a pet project of mine, something I've been working on for a while in my free time.)

On Tue, Sep 13, 2016, 10:02 zubuzon notifications@github.com wrote:

I'm done! @crazyhuggins https://github.com/crazyhuggins you see my prototype / experimental solution here: https://github.com/zubuzon/booxi

There are little perf loss now, but still faster then current implementation. And there is a few issues yet to solve, but this is a prototype, and I'm not even sure if @isiahmeadows https://github.com/isiahmeadows want me to back port this solution to Thallium.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/ 8#issuecomment-246691213, or mute the thread https://github.com/notifications/unsubscribe-auth/ AERrBGSdmOfJzuiILRAc29y5hvPHgcJ-ks5qpqz4gaJpZM4J3dEz .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/8#issuecomment-246703808, or mute the thread https://github.com/notifications/unsubscribe-auth/AVG551HowAYaxmlR11Z_1TP2T0e2ateWks5qprX7gaJpZM4J3dEz .

[ghost]

Seems like I don't get any time to continue on this the next days. And I guess I would need your opinion regarding my experiment if I'm thinking correctly before event try to port it and send a PR.

[dead-claudia]

First, I may not be able to actually do anything other than look at it and comment for a while, because of family (grandfather in hospital).

Second, the match mode is simply the strict mode, except symbols are matched by their description, not identity, and prototypes are largely ignored (dates, maps, sets, etc. are checked, but rest aren't for types).

Third, I am very strict on the style and tests, but it helps me manage the 8.5k (~22k with tests, etc.) project by myself. (It would be nearly impossible otherwise.)

On Tue, Sep 13, 2016, 19:31 zubuzon notifications@github.com wrote:

Seems like I don't get any time to continue on this the next days. And I guess I would need your opinion regarding my experiment if I'm thinking correctly before event try to port it and send a PR.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/8#issuecomment-246859133, or mute the thread https://github.com/notifications/unsubscribe-auth/AERrBFah4x4xeKTf32PNWXXL0bvNxjCoks5qpzJSgaJpZM4J3dEz .

[dead-claudia]

@zubuzon If you'd like, you can send a PR. Note that Thallium is in pure ES5, not TypeScript.

[ghost]

@isiahmeadows I had plans to port my work over to Thallium and open a PR soon as I got time. I know it's pure ES5. Just me that allways using TS so I easier can see if there are misstakes in the code.

I did some interesting findings. If you create a new Matcher instance each time you use your code, and pass it through from function from function you will loose simple object comparison performance with around 25%.

However. If you do use same solution as NodeJS, your perf will be much better, but you are stuck on large arrays and objects. Not ideal either.

The ideal solution to get it working for large data sets, and have a OK performance is to have a set of various classes that inherit from each other, and created if needed.

 matcher || ( matcher = new  matcher);

is the best solution I found.

Next is use of instanceof. Be aware this can be faked with Object.create so try to avoid. For basic equality checks you can use typeOf for better performance for regEx and date

Just mention it what I found out.

[ghost]

Here is an not public demo I did with class inheritance to gain better performance so you may understand the huge difference in perf. I'm all gone now. Need to take care of clients :(

locale x 75,765,397 ops/sec ±0.74% (94 runs sampled)
booxi x 44,651,586 ops/sec ±0.55% (94 runs sampled)

[dead-claudia]

I had plans to port my work over to Thallium and open a PR soon as I got time. I know it's pure ES5. Just me that allways using TS so I easier can see if there are misstakes in the code.

Yeah...this is kind of large for a JS-only project, anyways (if core was any more complex, I'd consider TypeScript, anyways).

I did some interesting findings. If you create a new Matcher instance each time you use your code, and pass it through from function from function you will loose simple object comparison performance with around 25%.

Using shared data should make a significant difference. I used an object at first for easier debugging in the initial work, but converting that to using a global closure would be almost trivial.

The ideal solution to get it working for large data sets, and have a OK performance is to have a set of various classes that inherit from each other, and created if needed.

I may do that for objects (not allocate the array for primitives, and unallocate after completion).

Next is use of instanceof. Be aware this can be faked with Object.create so try to avoid. For basic equality checks you can use typeOf for better performance for regEx and date

I'm not that worried about instanceof, and there is the issue of ES6 subclasses of those. I actually still have edge cases not covered (expando property checking) as well, which should most definitely be checked. Yes, you can fake it with Object.create (or even adding a Symbol.hasInstance method on RegExp itself), but nowadays, even Object.prototype.toString isn't foolproof because of Symbol.toStringTag.

Also, here's why just checking for source/etc. equality isn't sufficient:

const foo1 = /foo/
const foo2 = /foo/

foo1.bar = 1
t.match(foo1, foo2) // should be false

Although I can sidestep that by doing a quick, cheap isEmpty check to shortcut a lot of expensive property checking:

function isEmpty(obj) {
  for (var key in obj) if ({}.hasOwnProperty.call(obj, key)) return true
  return false
}

---

I eventually plan on pulling this out of core, anyways. It most definitely doesn't belong here in the long run.

[ghost]

For your regExp example you could simply do

Object.is(a, b);

I will try to squeeze in some time sunday and look into this again.

[ghost]

@isiahmeadows I removed the Booxi repo. And working on something new regarding this now that will replace the Booxi code.

[dead-claudia]

@zubuzon Note that parts of it may become moot, since I'm now using actual CPU profiling tools here. I've finally got time to dedicate to this. Expect a new commit or three soon.

[ghost]

@isiahmeadows Sounds good. I'm trying to learn your code style now and figure out how your module is working so I probably can help out in my spare time. If you want. In case you wonder. I'm a freelancer now but worked 8 years in a company you are using everyday. I'm not doing any marketing here so I keep the name on the company for myself :)

Wich part are you optimizing, and how? I noticed that object equality checks are terrible slow in most of all similiar implementations. And be aware that IE11 doesn't support Set#entries or Set#@@iterator.

And I also found that +0 and -0 is actualy true after the specs in ECMA 2016 and upcoming ECMA 2017. However there is distinct difference between weakMaps and WeakSet vsMapandSet. MapandSetwill equate -0 and +0 butweakMapsandWeakSet will not.

I just mention this in case you want to normalize this behaviour to follow the specs.

You may also allow equality checks of DOM nodes if you plan this to work in a browser? The Jasmine implementation of deepEqual does this. And so does Lodash, but Lodash does it very very slow it seems.

[ghost]

And if you want to go all the way and actually create a ultimate solution, you may also consider comparing style objects in browsers.

[dead-claudia]

@zubuzon

Wich part are you optimizing, and how? I noticed that object equality checks are terrible slow in most of all similiar implementations. And be aware that IE11 doesn't support Set#entries or Set#@@iterator.

I'm mainly trying to optimize the cases of plain objects (Thallium's own tests use them extensively), primitives, things like new Date(), and combinations of those.

And yes, I'm aware IE11 has no support for those (spoiler alert: Node 0.10, which this does support, doesn't, either).

However there is distinct difference between weakMaps and WeakSet vsMapandSet. MapandSetwill equate -0 and +0 but weakMaps and WeakSet will not.

You can't iterate WeakSets, either, so I don't even bother. Yes, new WeakSet().add({foo: 1}) matches new WeakSet().add({bar: 2}), but I have no way of knowing they shouldn't be equal.

Also, WeakMaps and WeakSets only accept objects and functions, not even Symbols (numbers are often unboxed, anyways, so they can't be used reliably). It mainly exists for private data and tagging.

I just mention this in case you want to normalize this behaviour to be equal to the specs.

I understand, but I still plan on keeping 0 === -0 (strict equality except t.match(NaN, NaN)).

And if you want to go all the way and actually create a ultimate solution, you may also consider comparing style objects in browsers.

That's not going into core. I've already ditched loose equality-based matching because it slowed things down by complicating everything.

[ghost]

If you use Object.is and compare your WeakMap example they will return false after the specs because they are two different object instances. They shouldn't be equal in the first place, and if they should, can't you use get() to extract the valùes and compare them ?

This is just the same as

(Symbol(), Symbol());

and

var symbol = Symbol()
(symbol, symbol);

Only the last example should return true.

[dead-claudia]

@zubuzon Yes, but Object.is is only applied to primitives (except for non-strict matching with symbols), and that is not going to change, because that's the whole point of deep matching/equality. I'd rather not special case specific object types for referential equality, and I'd also rather avoid special-casing any type at all unless:

1. It's a language-level type (React elements are not)
2. It can meaningfully be checked (weak collections cannot)
3. It has data that can't be trivially extracted and/or in a still-meaningful way (String wrapper objects do with valueOf, but Date's getTime method is unhelpful in inspect results, and maps and sets can't be compared in an unordered way with Array.from).

The reason why I'm not going to check for WeakMaps or WeakSets in the deep equality algorithm is because the data within it is inaccessible by design (by TC39) and the nature of deep equality is to check structure, not referential equality. And if you need to check actual referential equality, t.equal is how you do it.

Sorry if I'm coming across as a little blunt, but I have to draw the line on that one.

[ghost]

I understand. Will be interesting to see your new changes.

On Sep 17, 2016 11:43 AM, "Isiah Meadows" notifications@github.com wrote:

@zubuzon https://github.com/zubuzon Yes, but Object.is is only applied to primitives (except for non-strict matching with symbols), and that is not going to change, because that's the whole point of deep matching/equality. I'd rather not special case specific object types for referential equality, and I'd also rather avoid special-casing any type at all unless:

1. It's a language-level type (React elements are not)
2. It can meaningfully be checked (weak collections cannot)
3. It has data that can't be trivially extracted and/or in a still-meaningful way (String wrapper objects do with valueOf, but Date's getTime method is unhelpful in inspect results, and maps and sets can't be compared in an unordered way with Array.from).

The reason why I'm not going to check for WeakMaps or WeakSets in the deep equality algorithm is because the data within it is inaccessible by design (by TC39) and the nature of deep equality is to check structure, not referential equality. And if you need to check actual referential equality, t.equal is how you do it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/8#issuecomment-247746960, or mute the thread https://github.com/notifications/unsubscribe-auth/AVG559nNsujrNC2oVStCO8FYG8lpK8F1ks5qq2HEgaJpZM4J3dEz .

[ghost]

Did you finish a refactoring or how it goes?

On Sep 17, 2016 12:05, "Kenny Flashlight" kflash123@gmail.com wrote:

I understand. Will be interesting to see your new changes.

On Sep 17, 2016 11:43 AM, "Isiah Meadows" notifications@github.com wrote:

@zubuzon https://github.com/zubuzon Yes, but Object.is is only applied to primitives (except for non-strict matching with symbols), and that is not going to change, because that's the whole point of deep matching/equality. I'd rather not special case specific object types for referential equality, and I'd also rather avoid special-casing any type at all unless:

1. It's a language-level type (React elements are not)
2. It can meaningfully be checked (weak collections cannot)
3. It has data that can't be trivially extracted and/or in a still-meaningful way (String wrapper objects do with valueOf, but Date's getTime method is unhelpful in inspect results, and maps and sets can't be compared in an unordered way with Array.from).

The reason why I'm not going to check for WeakMaps or WeakSets in the deep equality algorithm is because the data within it is inaccessible by design (by TC39) and the nature of deep equality is to check structure, not referential equality. And if you need to check actual referential equality, t.equal is how you do it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/8#issuecomment-247746960, or mute the thread https://github.com/notifications/unsubscribe-auth/AVG559nNsujrNC2oVStCO8FYG8lpK8F1ks5qq2HEgaJpZM4J3dEz .

[ghost]

@isiahmeadows You seem to like Mithril. Let me know if you want to help out - in progress - fastest ui interface framework that is 90% faster then Mithril or any other frameworks

[dead-claudia]

@zubuzon Thanks, but not too interested ATM. (Due to a flurry of things going on recently, I've barely had time to even work on this.)

I'm personally working off-and-on on another vdom-style framework that is supposed to even support animations (fast with real-time requirements), but I'm keeping it closed until I have something usable to start with. Most of the complexity is from the real-time requirements (I need guaranteed constant-time insertions and deletions, as well as linear iterations) and because the framework lets components control their own rendering and updates (div/etc. are userland components themselves).

I've got a secret gist explaining this, but I plan to open it up as soon as I have the concepts solidified. What's mainly holding me back, though, is that the API is so coupled to the implementation details in the case of components that render themselves, much like how React's custom renderers also have to have at least some knowledge of the internal data structures.

Did you finish a refactoring or how it goes?

It's going well. It's fun using IRHydra (and less so perf and its JIT-unfriendliness) to investigate the bytecode and other related data. CPU profiling alone wasn't giving me nearly enough information, because the algorithm is so incredibly recursive, and the bottleneck was centralized from the beginning.

[ghost]

Actually what i mentioned you cant call it a virtual dom. It's a virtual fragment lib. It can never be beaten in performance. With a vdom such as React you have too many bottle necks. This one split static and dynamic logic with almost zero memory use and overhead.

Instant 60 FPS at 50% and 51 FPS at 100%. And in perf 79% faster then React.

Sounds interesting your RL logic and animation plans. Is it js animation or css? I already support css animation at 60 Fps but no components ala React. The whole thing is build around stateless commponent principe.

@isiahmeadows Main issue is - if you follow React - that you would need to work with objects and iterate through an object before e.g. setting CSS values

{ styles: { width:'200px' } }

Get the styles inside the plain object, and iterate through the 'styles' object is expensive. I'm not doing that. I skip it, and set the new value directly.

When do you plan to open up your gist? I must say i like your skills!

Mostly CPU profiling isnt helpfull. Irhydra is the best tool i guess.

I will continue to keep and eye on your work.

Cheers

On Sep 19, 2016 09:15, "Isiah Meadows" notifications@github.com wrote:

@zubuzon https://github.com/zubuzon Thanks, but not too interested ATM. (Due to a flurry of things going on recently, I've barely had time to even work on this.)

I'm personally working off-and-on on another vdom-style framework that is supposed to even support animations (fast with real-time requirements), but I'm keeping it closed until I have something usable to start with. Most of the complexity is from the real-time requirements (I need guaranteed constant-time insertions and deletions, as well as linear iterations) and because the framework lets components control their own rendering and updates (div/etc. are userland components themselves).

I've got a secret gist explaining this, but I plan to open it up as soon as I have the concepts solidified. What's mainly holding me back, though, is that the API is so coupled to the implementation details in the case of components that render themselves, much like how React's custom renderers also have to have at least some knowledge of the internal data structures.

Did you finish a refactoring or how it goes?

It's going well. It's fun using IRHydra http://mrale.ph/irhydra/2/# (and less so perf and its JIT-unfriendliness) to investigate the bytecode and other related data. CPU profiling alone wasn't giving me nearly enough information, because the algorithm is so incredibly recursive, and it was already written fairly well to begin with.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/8#issuecomment-247896549, or mute the thread https://github.com/notifications/unsubscribe-auth/AVG55-a4jbyqSHF0cUtoFYBJms9oq2OEks5qreJGgaJpZM4J3dEz .

[dead-claudia]

@zubuzon

Actually what i mentioned you cant call it a virtual dom. It's a virtual fragment lib. It can never be beaten in performance. With a vdom such as React you have too many bottle necks. This one split static and dynamic logic with almost zero memory use and overhead.

True that static generation is always faster.

Sounds interesting your RL logic and animation plans. Is it js animation or css? I already support css animation at 60 Fps but no components ala React. The whole thing is build around stateless commponent principe.

Mine will be JS animations (including <canvas>, if someone writes something for it), and it will require 60FPS support, even across multiple components and continuous updating. Basically, even heavy <canvas> animations in a game loop should run smoothly.

When do you plan to open up your gist? I must say i like your skills!

Thanks. And I don't really have a set time frame for it other than when I feel it's ready. It's just a spare time project with little actual importance.

Mostly CPU profiling isnt helpfull. Irhydra is the best tool i guess.

It largely depends. If you're working at a higher level, like at the application level or framework level (e.g. a rendering algorithm), profiling is very useful, especially when using Chrome's CPU profiler and flame graphs. If the issue is I/O (e.g. frequent file system access), there's specialized tools for that. At a lower level (e.g. deep equality testing), you'll need to inspect the branches themselves, which bytecode inspectors like IRHydra are for.

(My biggest issue ATM is that I can't get the perf output I need to get the perf annotate output for IRHydra, but I can at least live without it for now, since the heuristics have generally helped, anyways.)

[ghost]

I simply do this:

Var template= createTemplate(function(x , y) { return { tag: 'div', Style: { Height: x Width: y } } });

Render(template(23, 45), document.body);

If a ball is jumping. Only x and y is updated. And each template can be nested. Rest is static.

Hobby project. Too many clients so have not so much time

On Sep 19, 2016 10:09, "Isiah Meadows" notifications@github.com wrote:

@zubuzon https://github.com/zubuzon

Actually what i mentioned you cant call it a virtual dom. It's a virtual fragment lib. It can never be beaten in performance. With a vdom such as React you have too many bottle necks. This one split static and dynamic logic with almost zero memory use and overhead.

True that static generation is always faster.

Sounds interesting your RL logic and animation plans. Is it js animation or css? I already support css animation at 60 Fps but no components ala React. The whole thing is build around stateless commponent principe.

Mine will be JS animations (including , if someone writes something for it), and it will require 60FPS support, even across multiple components and continuous updating. Basically, even heavy animations in a game loop should run smoothly.

When do you plan to open up your gist? I must say i like your skills!

Thanks. And I don't really have a set time frame for it other than when I feel it's ready. It's just a spare time project with little actual importance.

Mostly CPU profiling isnt helpfull. Irhydra is the best tool i guess.

It largely depends. If you're working at a higher level, like at the application level or framework level (e.g. a rendering algorithm), profiling is very useful, especially when using Chrome's CPU profiler and flame graphs. If the issue is I/O (e.g. frequent file system access), there's specialized tools for that. At a lower level (e.g. deep equality testing), you'll need to inspect the branches themselves, which bytecode inspectors like IRHydra are for.

(My biggest issue ATM is that I can't get the perf output I need to get the perf annotate output for IRHydra, but I can at least live without it for now.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/8#issuecomment-247900279, or mute the thread https://github.com/notifications/unsubscribe-auth/AVG558iABEHYPqMzsabYTWRT4-TMC9-sks5qre7pgaJpZM4J3dEz .

[dead-claudia]

@zubuzon I've pushed a new commit about this, and filed #11 in response.

[ghost]

I can try to look at it within a few hours

On Sep 21, 2016 18:36, "Isiah Meadows" notifications@github.com wrote:

@zubuzon https://github.com/zubuzon I've pushed a new commit about this, and filed #11 https://github.com/isiahmeadows/thallium/issues/11 in response.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/8#issuecomment-248573963, or mute the thread https://github.com/notifications/unsubscribe-auth/AVG55wCwltV6IqZZJ7xgmwQyd_8FcWCMks5qsQi8gaJpZM4J3dEz .

[ghost]

I looked at your improved matcher and it looks good. However you are missing a lot of ES stuff. Map and symbol iterator, promises, generators etc.

And i noticed almost identical code for primitives. Simplify?

On Sep 21, 2016 18:53, "Kenny Flashlight" kflash123@gmail.com wrote:

I can try to look at it within a few hours

On Sep 21, 2016 18:36, "Isiah Meadows" notifications@github.com wrote:

@zubuzon https://github.com/zubuzon I've pushed a new commit about this, and filed #11 https://github.com/isiahmeadows/thallium/issues/11 in response.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/isiahmeadows/thallium/issues/8#issuecomment-248573963, or mute the thread https://github.com/notifications/unsubscribe-auth/AVG55wCwltV6IqZZJ7xgmwQyd_8FcWCMks5qsQi8gaJpZM4J3dEz .