<JRubyGithub>
[jruby] headius pushed 2 new commits to master: http://git.io/hWgJ
<JRubyGithub>
jruby/master 05b48fb Charles Oliver Nutter: Fix String#b to not mutate original ByteList.
<JRubyGithub>
jruby/master 459fff9 Charles Oliver Nutter: Only emit bytecode once for each unique literal. Fixes #2718.
JRubyGithub has left #jruby [#jruby]
<headius>
hmmm you know the real problem with our use of travis is that when something fails, all commits until it's fixed will fail
<headius>
so every push burns up another couple hours of CPU time eventually failing
<headius>
then we have to wait hours for the fix build to queue up
<headius>
sigh
<nirvdrum>
I would be willing to sacrifice the granularity of isolating a build failure to a single commit if it meant we could speed up builds by batching commits in a given window.
baroquebobcat has quit [Quit: baroquebobcat]
<nirvdrum>
In a small set of commits, it's usually easy to figure out which one was the problematic one anyway.
<headius>
I wonder if we should be keeping jitted code in soft references, so memory pressure will clear old ones out
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<eregon>
ah ... PermGen ... we can't use jdk8 ?
_dabradley has quit [Ping timeout: 265 seconds]
<headius>
we can, but I want to know if this is unreasonable memory use
<headius>
I could flip the build to 8 now I suppose
<headius>
oh what the heck, it's not honoring the flag?
<headius>
bleh, the permgen flag isn't getting passed it seems
calavera has joined #jruby
robbyoconnor has joined #jruby
<headius>
d'oh
lucasallan has quit [Remote host closed the connection]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to master: http://git.io/hW5W
<JRubyGithub>
jruby/master b478c88 Charles Oliver Nutter: Need to up permgen for these test runs.
JRubyGithub has left #jruby [#jruby]
<headius>
ok, next build should be awesome
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] bjfish opened pull request #2720: [Truffle] Adding annotation to return an enumerator if no block is given to a method. (master...truffle_return_enumerator_annotation) http://git.io/hWdu
camlow325 has quit [Remote host closed the connection]
rsim has joined #jruby
camlow325 has joined #jruby
lanceball is now known as lance|afk
shellac has joined #jruby
rsim1 has joined #jruby
rsim1 has quit [Read error: Connection reset by peer]
rsim2 has joined #jruby
rsim has quit [Ping timeout: 265 seconds]
bbrowning has joined #jruby
cremes has quit [Remote host closed the connection]
cremes has joined #jruby
pitr-ch has joined #jruby
skade has joined #jruby
erikhatcher has quit [Quit: erikhatcher]
rsim has joined #jruby
rsim2 has quit [Read error: Connection reset by peer]
kares has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton closed pull request #2720: [Truffle] Adding annotation to return an enumerator if no block is given to a method. (master...truffle_return_enumerator_annotation) http://git.io/hWdu
JRubyGithub has left #jruby [#jruby]
shellac has quit [Quit: Computer has gone to sleep.]
dinfuehr has quit [Remote host closed the connection]
<headius>
looks like I booched something
<nirvdrum>
chrisseaton, bjfish2: I added some comments to that just merged PR. I don't know if you guys discussed either of those issues previously because the comments were removed by GitHub.
phrinx has quit [Read error: Connection reset by peer]
rsim has quit [Read error: Connection reset by peer]
rsim has joined #jruby
<nirvdrum>
bjfish2: I didn't totally follow that comment. What's the problem?
rsim has quit [Ping timeout: 265 seconds]
rsim has joined #jruby
<bjfish2>
nirvdrum i wan’t the map! method to raise a frozen error if someone is using it after calling to_enum(:map!) but I had problems doing this with raiseIfFrozen and IsFrozenNode inside the method
<nirvdrum>
bjfish2: Tricky. I didn't realize the to_enum variant wouldn't raise.
<nirvdrum>
bjfish2: But this is actually kinda simple. And adds value to your new wrapper :-)
<nirvdrum>
bjfish2: While a bit messy, what I think you want to do is wrap the "sequence" value with TaintResultNode before passing it to the ReturnEnumeratorIfNoBlockNode constructor.
<nirvdrum>
And then just skip the general path for using TaintResultNode.
<nirvdrum>
They're currently treated as independent options in CoreMethodNodeManager, but you can take divergent behavior based on whether both options are set.
<nirvdrum>
bjfish2: Actually, even simpler, I think you can just reorder those two if statements.
<nirvdrum>
Oh, no. It looks like I copy and pasted badly.
<bjfish2>
k
<nirvdrum>
I guess we haven't actually used that option yet.
<nirvdrum>
I think they've all been the "self" variant.
<nirvdrum>
Good catch.
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] bjfish opened pull request #2721: [Truffle] Adding ConditionProfile to ReturnEnumeratorIfNoBlock annotation and updating to execute. (master...truffle_returns_enum_fix) http://git.io/h8mD
JRubyGithub has left #jruby [#jruby]
<nirvdrum>
So, the problem is "self" and the argument nodes are effectively executed before the method is even run. That's how the specializations deal with Object parameters rather than Nodes.
<nirvdrum>
I think what you want to do is skip the RaiseIfFrozenNode wrapping if returnsEnumeratorIfNoBlock is true.
<nirvdrum>
And then pass raiseIfFrozenSelf and raiseIfFrozenParameters through to ReturnEnumeratorIfNoBlockNode, much like TaintResultNode does.
<bjfish2>
nirvdrum i can give that a tru
<bjfish2>
tyr
<bjfish2>
try
<nirvdrum>
And then you'd manually call the RaiseIfFrozenNode inside your node.
marr has quit [Read error: Connection reset by peer]
<nirvdrum>
Note that RaiseIfFrozenNode is currently written with the intention that it's being added at a known location in the graph. In your case, you're going to have an instance handle of TaintResultNode, but the object being tested is going to change from call to call.
<nirvdrum>
To make that simpler, you'll want to add: public abstract Object execute(VirtualFrame frame, Object o) to RaiseIfFrozenNode.
<nirvdrum>
And then you can call that method in your enumerator wrapper node.
<nirvdrum>
Let me know if that was confusing.
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 2 new commits to master: http://git.io/h8Gd
<JRubyGithub>
jruby/master 178a55e Brandon Fish: [Truffle] Adding ConditionProfile to ReturnEnumeratorIfNoBlock annotation and updating to execute.
<JRubyGithub>
jruby/master 71aaac9 Kevin Menard: Merge pull request #2721 from bjfish/truffle_returns_enum_fix...
JRubyGithub has left #jruby [#jruby]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 1 new commit to master: http://git.io/h8cf
<JRubyGithub>
jruby/master c62422d Kevin Menard: [Truffle] Fixed a bad node wrapper.
JRubyGithub has left #jruby [#jruby]
<nirvdrum>
bjfish2: ^ That's the fix for the issue you just raised.
<nirvdrum>
Thanks again.
phrinx_ has joined #jruby
phrinx has quit [Read error: Connection reset by peer]
phrinx has joined #jruby
phrinx_ has quit [Read error: Connection reset by peer]
<bjfish2>
no problem
yfeldblum has joined #jruby
lucasallan has quit [Remote host closed the connection]
<bjfish2>
nirvdrum I don’t think I actually need to call RaiseIfFrozenNode from inside the ReturnEnumeratorIfNoBlockNode because the frozen check needs to happen after the enumerator is returned
dinfuehr has joined #jruby
<nirvdrum>
bjfish2: I think you'd do it inside the else clause.
<nirvdrum>
I think we might be talking past each other. The raiseIfFrozen stuff in @CoreMethod was written to simplify our specializations, which are essentially just executions of a node. I'm suggessting since the helper doesn't work in this case, you'd fallback to the old behavior and handle it inside the excution. But the execution this time happens to be your node wrapper.
dinfuehr has quit [Ping timeout: 256 seconds]
<nirvdrum>
bjfish2: Right. And the enumerator each should call the method again, this time with a block, which should correspond to your else clause.
<nirvdrum>
bjfish2: In broad strokes, I'm suggesting it should look like: else { raiseIfFrozenNode.execute(frame, self); return method.execute(); }
<nirvdrum>
Guarding that raise call, based on whether the raiseIfFrozenSelf value is set or not.
<bjfish2>
nirvdrum yes I can do that, I think that would work, I just thought it might be better if they could be separate but still work correctly
<bjfish2>
nirvdrum I’ll just give that a try for now
<nirvdrum>
If you can find a way, great. But I don't think there is. The argument nodes will have been executed by the time your wrapper is executed.
<nirvdrum>
bjfish2: StringNodes#initialize is a similar case where there was one situation we couldn't raise in, so I had to drop using the annotation helper :-/
<nirvdrum>
And I'm now seeing that I should have added this abstract method I suggested to cut down on some of the code duplication.
saga65 has joined #jruby
<nirvdrum>
bjfish2: I guess the other way you could go is to push additional context into RaiseIfFrozenNode telling it to essentially no-op if the block is null and the method name is "to_enum".
<nirvdrum>
But that might be messier and could impose a penalty on all other uses of RaiseIfFrozenNode.
anaeem1 has joined #jruby
<bjfish2>
nirvdrum okay, i think I had an error between the chair and the computer, this seems to be working now as is
<nirvdrum>
Oh? Great.
<bjfish2>
yes, thanks for the help on this though
lucasallan has joined #jruby
<headius>
nirvdrum: hey, what kind of errors did you get when you fixed String#b before? Anything like the failures on travis?
<headius>
bisects to acd4108e579be1d05bba7960b80a6f219475a93c, a commit in the JIT
<headius>
but I'm getting this failure in -X-C
<headius>
nirvdrum: can you try running jruby -X-C -e '"a".force_encoding("ASCII-8BIT").tr_s(".".force_encoding("Windows-31J"),"\xA1\xA1".force_encoding("EUC-JP"))'
<enebo>
any snapshots in 1.7? I did not change any
<headius>
enebo: certainly not in the release, right?
<enebo>
headius: no
<enebo>
headius: You are using 1.7.20?
<enebo>
err 19 whatever latest is?
<headius>
I just tried my rvm copy of 1.7.19 and it fails
<nirvdrum>
It looks like I did some refactoring around that time. But I don't recall any builds failing as a result. We've certainly had green builds since then.
<enebo>
nirvdrum: but it does not explain why that simple mri test is passing a couple of hours ago on CI
<bjfish2>
I dont’ know if this is a clue, I always get StringSupport compile errors locally when running ‘jt build truffle’ and then I have to run ‘jt rebuild’
<headius>
hmm ok
<enebo>
I could see a caching effect in play
<headius>
enebo: caching what? I tried a release build of 1.7.19
<enebo>
headius: my point is the env of running your CLI
<JRubyGithub>
[jruby] headius pushed 1 new commit to master: http://git.io/h4zL
<JRubyGithub>
jruby/master c1dc6e5 Charles Oliver Nutter: Simplify bytelist keying for cache in JIT.
JRubyGithub has left #jruby [#jruby]
subbu has joined #jruby
<enebo>
ok
<enebo>
confirmed. 05b48fb76f9babb87a39228c792b20c196673dc4 broke something in m17n_comb
<headius>
so it was b, and I led us astray by looking at the wrong test
<enebo>
headius: ^ but this uncovered something odd which we happily could not see
<headius>
really odd
<enebo>
headius: So I think somehow ‘b’ is hiding this error or being used and it is modifying a string in a way we can work with it
<enebo>
headius: so the CLI you are using is somehow a real bug and the way MRI unit tests are running wallpapered it
<headius>
yeah, I almost couldn't believe nirvdrum when he said fixing b caused failures before
<nirvdrum>
You cut deep.
<enebo>
headius: so no resolution but at least your sanity is back
<headius>
at least
<enebo>
“at least"
<headius>
it is replaced with the insanity of this fix causing failures
<nirvdrum>
I'm trying to dig up the build, but Travis's pagination is on of those silly ajax things, so it'll take like a week.
<headius>
these tests do use b
<enebo>
headius: well I suppose that CLI is a place to start since it fails iwthout b in the picture
<headius>
that STRINGS array
<nirvdrum>
Bah. I can't even jump by job number because Travis uses global IDs.
<headius>
I bet it's a CR thing
<headius>
it's always CR
<headius>
it should be getting cleared by modify19 though
<enebo>
heh…I have had no encoding assignments or bad swapped encoding
<enebo>
OTOH those bugs keep getting much less common
<enebo>
One can only eyeball and debug cat19 so many times
<headius>
that's for sure
<nirvdrum>
headius: But then I don't get why the same change worked on 1.7 without failure. Unless it's broken and those tests are just excluded.
<headius>
nirvdrum: it's possible they're excluded
<headius>
it's also possible that b being broken caused these failing tests to pass in a weird way
<headius>
by modifying strings it shouldn't have...like everything comes out b
<headius>
I think that's probably it
<headius>
these were broken all along and got swept up in an untagging
<headius>
then b got fixed and they show their true form
<headius>
several of the tests that failed were untagged by me after I finished the new transcoder last summer
anaeem1 has quit [Remote host closed the connection]
<nirvdrum>
I'm trying to find the job history. I think my browser is going to run out of RAM before I get there, however :-(
<headius>
hahah
<headius>
yeah
anaeem1_ has joined #jruby
<nirvdrum>
It just keeps appending to the DOM.
<nirvdrum>
Maybe I should do more by way of pull request.
<headius>
I will try to fix one of these and maybe it will fix them all
anaeem1_ has quit [Ping timeout: 272 seconds]
baroquebobcat has quit [Quit: baroquebobcat]
baroquebobcat has joined #jruby
<nirvdrum>
m17n failing actually sounds like it could be right. I remember it being a test suite I don't typically run and I was thoroughly confused. It was also Christmas Eve, so I just reverted.
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<nirvdrum>
I'm cursed.
dinfuehr has joined #jruby
<nirvdrum>
bbiaf. Need to connect to the silly corporate VPN.
aadam21 has quit [Ping timeout: 255 seconds]
pietr0 has quit [Quit: pietr0]
pietr0 has joined #jruby
nirvdrum has quit [Ping timeout: 255 seconds]
viking has quit [Remote host closed the connection]
slyphon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
nirvdrum has joined #jruby
donV has joined #jruby
slyphon has joined #jruby
djbkd has quit [Remote host closed the connection]
enebo has quit [Quit: enebo]
djbkd has joined #jruby
camlow325 has joined #jruby
slyphon_ has joined #jruby
slyphon has quit [Ping timeout: 264 seconds]
<lopex>
so what was wrong with that tr failure ?
<headius>
omg
<headius>
I just noticed test results are getting clobbered by some *code* from an earlier run
<headius>
I think it's an additional COW bug that the b bug masked
<headius>
GRRRREAT.
<headius>
or I broke sharing somehow?
<lopex>
string sharing ?
<headius>
yeah
<lopex>
what did you do to my sharing!
nirvdrum has quit [Ping timeout: 252 seconds]
x1337807x has joined #jruby
dinfuehr has quit [Remote host closed the connection]
dinfuehr has joined #jruby
<headius>
I don't know!!!
djbkd has quit [Remote host closed the connection]
tcrawley is now known as tcrawley-away
dinfuehr has quit [Ping timeout: 272 seconds]
e_dub has quit [Quit: e_dub]
djbkd has joined #jruby
yfeldblu_ has quit [Remote host closed the connection]