<JinhoYoon[m]> Could you please check it again?
<byteit101[m]> Nice. some quick comments: 1) You accidentally committed a lot of build artifacts by accident 2) Say "Fixed #7710" in the commit message so that github will link it correctly (the "#" is important). 3) Same for the pull request, and provide at least some minimal description of what you did in the pull request
<JinhoYoon[m]> will my fix enough to merge in to master?
<JinhoYoon[m]> Once I remove build artifacts and re commit it?
<JinhoYoon[m]> I'll create new PR I think it is faster then just deleting all build artifacts
<JinhoYoon[m]> Reuploaded a new PR yykuk2003/jruby and named as FIXED jruby #7710
_whitelogger has joined #jruby
subbu has joined #jruby
subbu has quit [Ping timeout: 265 seconds]
AlenSebastian[m] has quit [Quit: You have been kicked for being idle]
subbu has joined #jruby
subbu has quit [Ping timeout: 260 seconds]
<JinhoYoon[m]> is there way to compile only enumerator and test if it is running correctly?
<enebo[m]> Jinho Yoon if you just type mvn it will only compile the file changed but then our build always does a bunch of extra stuff. You should definitely full build at least once since many other things depend on Enumerator Java code.
<enebo[m]> mvn clean; mvn
<enebo[m]> we have a bunch of test suites but one reasonable one is jruby -S rake spec:ruby:fase. If you want to burrow down you can run individual specs like jruby spec/mspec/bin/mspec-ci spec/ruby/core/enumerator (or even specific spec files within enumerator if you need to debug something more specific)
<JinhoYoon[m]> Still solving issue 7710 and confused what to remove based on the changes issue #7709
<JinhoYoon[m]> could you please provide a bit more information?
<byteit101[m]> If it's not used, it can be removed
<byteit101[m]> also for future reference and historiography It would be nice to mention the new PR number in the old PR so that people can see why it was closed. It's nice to only have one PR and instead force-push to it so that there aren't bits and pieces of stuff all over the place so it is organized in one spot.
<JinhoYoon[m]> How am I supposed to check if it is not used or not?
<byteit101[m]> Your IDE should have a "find usages" feature, i would recommend using that
<headius> Jinho Yoon: hello
<headius> I'm going to have a look and see what is left that is unused
<headius> I started to try to remove it at one point and got pulled away
<headius> ok yes... so in the original issue 7710 you can see what was changed in CRuby... the equivalent code may be hard to figure out in JRuby but that's the place to start
<JinhoYoon[m]> Got it
<headius> you may be able to trace from the code I deleted in 7709 and figure out what is no longer used
<headius> those initializers set up state that is now never set up and never used
<JinhoYoon[m]> Where is the original issue 7710?
<byteit101[m]> the one you are solving? on github? that you commented on? that you pasted a link to yesterday?
<JinhoYoon[m]> yes the one that I'm solving on the github
<JinhoYoon[m]> I'm working based on looking at this issue and tracking over following merged issue
<byteit101[m]> That's good
<JinhoYoon[m]> I just committed fixed issue #7710 could you please check and give me a comment about it?
<headius> I will have a look
<headius> Jinho Yoon: I think it is a good start. What you should notice is that the remaining constructors and initializers set some state to the same thing all the time, so anything that uses that state is probably only ever doing one thing. That's where a lot of dead code loves
<headius> s/loves/lives/
<JinhoYoon[m]> <headius> "Jinho Yoon: I think it is a good..." <- The only code that should be removed is from file RubyEnumerable.java right? and It will be initialize function right?
<JinhoYoon[m]> Could you please give me some advice or hints how to find rest of the dead code out of it?