Feature #6611: Comments requested on implementation of set_parse_func

[Clifford Heath]

Folk,

I've implemented Twister, a new mutation testing tool to replace Heckle.
It relies on a new hook into the Ruby parser, in order to modify what the
parser thinks it has seen.

Although I have written C extensions before, there are some aspects of
the Ruby core which I'm unfamiliar with and as a result don't know the right
way to handle. I'd like your comments, suggestions and improvements
please.

https://github.com/cjheath/ruby/commit/ea99527feaf7dd06b3e8433ec640238441b188db

In particular, I'd like to know the following:

1) Do you prefer that I move the literal strings (which occur once each) to #defined?

https://github.com/cjheath/ruby/commit/ea99527feaf7dd06b3e8433ec640238441b188db#L1R1003

2) Will this line of code mess up the GC, and how should I fix that?

https://github.com/cjheath/ruby/commit/ea99527feaf7dd06b3e8433ec640238441b188db#L1R3853

3) The setparsefunc is extern though it should be static, but I need to move
the rbdefineglobalfunction out of thread.c. Can someone please tell me where I should
move it to, since there is no InitParser?

https://github.com/cjheath/ruby/commit/ea99527feaf7dd06b3e8433ec640238441b188db#L1R9029

https://github.com/cjheath/ruby/commit/ea99527feaf7dd06b3e8433ec640238441b188db#L3R4705

4) I think I should change setparsefunc to accept a flags argument and a block,
instead of assuming all flags, and taking a Proc. What are the downsides of using a
block instead of a Proc (does this reduce the number of Bindings that get created)?
How do I change setparsefunc to use a block?

The initial implementation of Twister is an extension to RSpec which adds the option
"--twist file-or-dir". It's still a bit rough - it needs to change the reporting on the twisted
runs that follow the first (untwisted) run - but it does prove then concept.

Clifford Heath, Data Constellation, http://dataconstellation.com
Agile Information Management and Design.

[Clifford Heath]

Bump.

Please comment on https://bugs.ruby-lang.org/issues/6611.
I need to finish this implementation, and the support in RSpec.

Clifford Heath.

On 19/06/2012, at 10:45 AM, Clifford Heath wrote:

Folk,

I've implemented Twister, a new mutation testing tool to replace Heckle.
It relies on a new hook into the Ruby parser, in order to modify what the
parser thinks it has seen.

Although I have written C extensions before, there are some aspects of
the Ruby core which I'm unfamiliar with and as a result don't know the right
way to handle. I'd like your comments, suggestions and improvements
please.

https://github.com/cjheath/ruby/commit/ea99527feaf7dd06b3e8433ec640238441b188db

In particular, I'd like to know the following:

1) Do you prefer that I move the literal strings (which occur once each) to #defined?

https://github.com/cjheath/ruby/commit/ea99527feaf7dd06b3e8433ec640238441b188db#L1R1003

2) Will this line of code mess up the GC, and how should I fix that?

https://github.com/cjheath/ruby/commit/ea99527feaf7dd06b3e8433ec640238441b188db#L1R3853

3) The setparsefunc is extern though it should be static, but I need to move
the rbdefineglobalfunction out of thread.c. Can someone please tell me where I should
move it to, since there is no InitParser?

https://github.com/cjheath/ruby/commit/ea99527feaf7dd06b3e8433ec640238441b188db#L1R9029

https://github.com/cjheath/ruby/commit/ea99527feaf7dd06b3e8433ec640238441b188db#L3R4705

4) I think I should change setparsefunc to accept a flags argument and a block,
instead of assuming all flags, and taking a Proc. What are the downsides of using a
block instead of a Proc (does this reduce the number of Bindings that get created)?
How do I change setparsefunc to use a block?

The initial implementation of Twister is an extension to RSpec which adds the option
"--twist file-or-dir". It's still a bit rough - it needs to change the reporting on the twisted
runs that follow the first (untwisted) run - but it does prove then concept.

Clifford Heath, Data Constellation, http://dataconstellation.com
Agile Information Management and Design.

[Yui NARUSE]

Generally speaking on ruby, feature request is hard to accept.
Submitter must make people understand why the feature is required.
The challenger must explain
* Background
* use case and current workaround
* how the new feature make their life well

Therefore for your proposal, why ripper is not enough?

[Yusuke Endoh]

• Status changed from Open to Assigned
• Assignee set to Yukihiro Matsumoto
• Target version set to next minor