Re: [webkit-dev] Preferred style for checking for undefined in our built-in JavaScript code?

2015-11-30 Thread Darin Adler
> On Nov 30, 2015, at 11:57 AM, Geoffrey Garen wrote: > > For the time being, I like “x === undefined”. > > Long term, I’d like us to switch to “x === @undefined”. > > We use @ to indicate reserved words in built-ins. Currently, “@undefined" > does not exist, but the

Re: [webkit-dev] Preferred style for checking for undefined in our built-in JavaScript code?

2015-11-30 Thread Geoffrey Garen
> Seems like we should not have to wait long for the “long term”. It seems that > the built-in compiler could start magically transforming “@undefined” instead > of magically transforming “undefined” any time we like; likely a simple find > and replace job. Or it could do both during a

Re: [webkit-dev] OSX: Linking to custom build resorts to system version...

2015-11-30 Thread S. Litherum
This sounds to me like SIP is not disabled. --Myles > On Nov 29, 2015, at 3:58 AM, Nikolay Tsenkov wrote: > > I tried this in a testing project, producing an app with a single window with > a webView in it, and it doesn’t work. (setting the env variable in the scheme) > >

[webkit-dev] Preferred style for checking for undefined in our built-in JavaScript code?

2015-11-30 Thread Darin Adler
I see the following in some code: if (xxx === undefined) And I see the following in some other code: if (typeof xxx == “undefined”) or if (typeof xxx === “undefined”) Is one preferred over the other, style-wise? Is one more efficient than the other? — Darin

Re: [webkit-dev] Preferred style for checking for undefined in our built-in JavaScript code?

2015-11-30 Thread Filip Pizlo
I’ve also been guilty of: if (xxx === void 0) This is slightly better than saying “undefined”, since that’s not actually a reserved word. I believe that all of these should perform the same. We should pick one based on what looks nicest and what has the most clear semantics. -Filip

Re: [webkit-dev] Preferred style for checking for undefined in our built-in JavaScript code?

2015-11-30 Thread Chris Aljoudi
FWIW, performance seems to be equivalent: http://jsperf.com/typeof-vs-undefined-check/39 Chris https://chrismatic.io/ > On Nov 30, 2015, at 1:01 PM, Geoffrey Garen wrote: > > For the time being, I like “x === undefined”. > > Long term, I’d like us to switch to “x ===

Re: [webkit-dev] How to deal with 1-pixel differences in reftests ?

2015-11-30 Thread Myles C. Maxfield
I believe that any way to specify fuzziness should not treat the following cases the same: - 1 pixel being 100% wrong - All pixels being 1% wrong There are certain cases where one of those should cause a failure, but the other shouldn't. --Myles > On Nov 18, 2015, at 10:44 PM, Alexey

Re: [webkit-dev] Preferred style for checking for undefined in our built-in JavaScript code?

2015-11-30 Thread Geoffrey Garen
For the time being, I like “x === undefined”. Long term, I’d like us to switch to “x === @undefined”. We use @ to indicate reserved words in built-ins. Currently, “@undefined" does not exist, but the built-in compiler magically transforms “undefined” a safe reserved word. The typeof and void

Re: [webkit-dev] Preferred style for checking for undefined in our built-in JavaScript code?

2015-11-30 Thread Brian Burg
Web Inspector’s frontend code tends to use “x === undefined”, as we’ve found it the easiest to read. > On Nov 30, 2015, at 11:57 AM, Geoffrey Garen wrote: > > For the time being, I like “x === undefined”. > > Long term, I’d like us to switch to “x === @undefined”. > > We

Re: [webkit-dev] Preferred style for checking for undefined in our built-in JavaScript code?

2015-11-30 Thread Ryosuke Niwa
On Mon, Nov 30, 2015 at 11:37 AM, Darin Adler wrote: > I see the following in some code: > > if (xxx === undefined) FWIW, I always use this style. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org

Re: [webkit-dev] Memory leak tracking in WebKit

2015-11-30 Thread Vienneau, Christopher
Hi, I've still been tracking memory leaks in our application, and I think I have a good test scenario to share. In our application we found that a lot of memory would be held onto when visiting this particular site: http://answers.ea.com In a loop we visit this site, and a simple html page

Re: [webkit-dev] Memory leak tracking in WebKit

2015-11-30 Thread Myles C. Maxfield
I've got a few questions/statements about this: 1. What makes you think that CSSParser::parseFontFaceSource() is the culprit? Which memory instrumentation tools are you using? 2. Font::platformInit() is the function where we start populating all our internal font caches. For example, we start