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)
>
> What’s even worse, I
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
_
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
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 Proskurya
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 0
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 === @undefined”.
>
> We use @ to
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 use @ to indicate res
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
https://lists.webkit.org/mailman/li
> 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 built-in compiler magicall
> 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 transitio
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 that
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 cr
12 matches
Mail list logo
