Skip to content

Conversation

@bnoordhuis
Copy link
Member

deps/v8/benchmarks/regexp.js clobbers the RegExp global, breaking
util.format() and console.log(). Unclobber it to keep the other
benchmarks working.

Fixes the following error when running benchmark/misc/v8-bench.js:

$ out/Release/iojs benchmark/misc/v8-bench.js
util.js:84
    if (new RegExp('\\b' + set + '\\b', 'i').test(debugEnviron)) {
        ^
TypeError: object is not a function
    at Object.exports.debuglog (util.js:84:9)
    at timers.js:12:29
    at NativeModule.compile (node.js:800:5)
    at NativeModule.require (node.js:769:18)
    at net.js:5:14
    at NativeModule.compile (node.js:800:5)
    at NativeModule.require (node.js:769:18)
    at tty.js:4:11
    at NativeModule.compile (node.js:800:5)
    at Function.NativeModule.require (node.js:769:18)

This could alternatively be addressed by caching the RegExp global
in lib/util.js. That's not a bad approach and I considered it but
doing it for just RegExp and not other globals would be half-baked.

Maybe the more thorough approach where we cache all globals at
start-up is something for a follow-up pull request.

Fixes: #475

R=@chrisdickinson @yosuke-furukawa

@bnoordhuis
Copy link
Member Author

Another option is to send a patch upstream that fixes the benchmark but that takes a lot more time.

deps/v8/benchmarks/regexp.js clobbers the RegExp global, breaking
util.format() and console.log().  Unclobber it to keep the other
benchmarks working.

Fixes the following error when running benchmark/misc/v8-bench.js:

    $ out/Release/iojs benchmark/misc/v8-bench.js
    util.js:84
        if (new RegExp('\\b' + set + '\\b', 'i').test(debugEnviron)) {
            ^
    TypeError: object is not a function
        at Object.exports.debuglog (util.js:84:9)
        at timers.js:12:29
        at NativeModule.compile (node.js:800:5)
        at NativeModule.require (node.js:769:18)
        at net.js:5:14
        at NativeModule.compile (node.js:800:5)
        at NativeModule.require (node.js:769:18)
        at tty.js:4:11
        at NativeModule.compile (node.js:800:5)
        at Function.NativeModule.require (node.js:769:18)

This could alternatively be addressed by caching the RegExp global
in lib/util.js.  That's not a bad approach and I considered it but
doing it for just RegExp and not other globals would be half-baked.

Maybe the more thorough approach where we cache all globals at
start-up is something for a follow-up pull request.

Fixes: nodejs#475
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1!

@yosuke-furukawa
Copy link
Member

LGTM

1 similar comment
@cjihrig
Copy link
Contributor

cjihrig commented Jan 18, 2015

LGTM

bnoordhuis added a commit that referenced this pull request Jan 18, 2015
deps/v8/benchmarks/regexp.js clobbers the RegExp global, breaking
util.format() and console.log().  Unclobber it to keep the other
benchmarks working.

Fixes the following error when running benchmark/misc/v8-bench.js:

    $ out/Release/iojs benchmark/misc/v8-bench.js
    util.js:84
        if (new RegExp('\\b' + set + '\\b', 'i').test(debugEnviron)) {
            ^
    TypeError: object is not a function
        at Object.exports.debuglog (util.js:84:9)
        at timers.js:12:29
        at NativeModule.compile (node.js:800:5)
        at NativeModule.require (node.js:769:18)
        at net.js:5:14
        at NativeModule.compile (node.js:800:5)
        at NativeModule.require (node.js:769:18)
        at tty.js:4:11
        at NativeModule.compile (node.js:800:5)
        at Function.NativeModule.require (node.js:769:18)

This could alternatively be addressed by caching the RegExp global
in lib/util.js.  That's not a bad approach and I considered it but
doing it for just RegExp and not other globals would be half-baked.

Maybe the more thorough approach where we cache all globals at
start-up is something for a follow-up pull request.

Fixes: #475
PR-URL: #489
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Yosuke Furukawa <[email protected]>
@bnoordhuis
Copy link
Member Author

Thanks, Yosuke, Colin, landed in 50177fb.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants