tcrypt has quit [Remote host closed the connection]
benlovell has quit [Ping timeout: 246 seconds]
GregMefford_ is now known as GregMefford
xcv has joined #jruby
nanoyak has quit [Read error: Connection reset by peer]
nanoyak has joined #jruby
r0bby_ has joined #jruby
robbyoconnor has quit [Ping timeout: 246 seconds]
jrhe_ has quit [Quit: Connection closed for inactivity]
<headius>
subbu: yeah I'm not sure whats up yet...some construct in a medium-complex method is causing a local variable to get overwritten when it should not be...something in JIT
brettporter has quit []
nanoyak has quit [Quit: Computer has gone to sleep.]
johnsonch_afk is now known as johnsonch
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jaju has joined #jruby
kgerman has joined #jruby
rcvalle has joined #jruby
tcrypt has joined #jruby
kgerman_ has joined #jruby
jaju has quit [Remote host closed the connection]
diegoviola has quit [Quit: WeeChat 1.0]
kgerman has quit [Ping timeout: 272 seconds]
phrinx_ has quit [Remote host closed the connection]
kgerman_ is now known as kgerman
phrinx has joined #jruby
diegoviola has joined #jruby
xcv has quit [Remote host closed the connection]
phrinx has quit [Ping timeout: 246 seconds]
nirvdrum has joined #jruby
havenwood has quit [Remote host closed the connection]
havenwood has joined #jruby
benlovell has joined #jruby
havenwood has quit [Remote host closed the connection]
benlovell has quit [Ping timeout: 250 seconds]
calavera has joined #jruby
rcvalle has quit [Quit: rcvalle]
havenwood has joined #jruby
calavera has quit [Ping timeout: 272 seconds]
calavera has joined #jruby
calavera has quit [Ping timeout: 258 seconds]
calavera has joined #jruby
brettporter has joined #jruby
calavera has quit [Ping timeout: 246 seconds]
calavera has joined #jruby
calavera has quit [Ping timeout: 258 seconds]
calavera has joined #jruby
tlarevo has joined #jruby
calavera has quit [Ping timeout: 255 seconds]
calavera has joined #jruby
calavera has quit [Ping timeout: 260 seconds]
calavera has joined #jruby
calavera has quit [Ping timeout: 258 seconds]
calavera has joined #jruby
benlovell has joined #jruby
nirvdrum has quit [Ping timeout: 258 seconds]
havenwood has quit [Remote host closed the connection]
havenwood has joined #jruby
benlovell has quit [Ping timeout: 246 seconds]
diegoviola has quit [Read error: Connection reset by peer]
diegoviola has joined #jruby
johnsonch is now known as johnsonch_afk
havenwood has quit [Ping timeout: 264 seconds]
subbu has joined #jruby
colinsurprenant has joined #jruby
colinsurprenant has quit [Client Quit]
havenwood has joined #jruby
nanoyak has joined #jruby
johnsonch_afk is now known as johnsonch
johnsonch is now known as johnsonch_afk
yfeldblum has quit [Ping timeout: 255 seconds]
tlarevo has quit [Remote host closed the connection]
tlarevo has joined #jruby
tlarevo has quit [Remote host closed the connection]
tlarevo has joined #jruby
e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
statonjr has quit [Ping timeout: 250 seconds]
statonjr has joined #jruby
benlovell has joined #jruby
anaeem1_ has joined #jruby
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
anaeem1_ has quit [Remote host closed the connection]
anaeem1_ has joined #jruby
benlovell has quit [Ping timeout: 245 seconds]
johnsonch_afk is now known as johnsonch
johnsonch is now known as johnsonch_afk
donV has joined #jruby
donV has quit [Quit: donV]
tcrypt has quit [Remote host closed the connection]
diegoviola has quit [Quit: WeeChat 1.0]
JRubyGithub has joined #jruby
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
jruby/master 4303b57 Subramanya Sastry: Fix #1969: Make StaticScope and IRScope agree on var slot assignment...
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/9vMXWw
Aethenelle has quit [Read error: Connection reset by peer]
Aethenelle__ is now known as Aethenelle
donV has quit [Quit: donV]
calavera has joined #jruby
calavera has quit [Client Quit]
Aethenelle_ has quit [Ping timeout: 272 seconds]
calavera has joined #jruby
<subbu>
headius, good morning. rubyspecs are not green on master for me.
<headius>
subbu: how unfortunate! what fails?
<subbu>
1782 files, 16735 examples, 51048 expectations, 9 failures, 4 errors ... but then I dont use mvn to run it .. i use a old cmdline that i've always
<nirvdrum>
Dunno if my comment is on point or not, but that code just got touched again so I figured I'd mention it.
Aethenelle_ has joined #jruby
<headius>
nirvdrum: subbu fixed it
<headius>
then I fixed it again the same way
<subbu>
oh, we both did? :)
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to jruby-1_7: http://git.io/FeNXGg
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
jruby/jruby-1_7 7b194e6 Christian Meier: reduce OSGi DynamicImport-Package to javax.* needed for openssl - fixes #1977
<nirvdrum>
Right. I'm suggesting the spec itself might be better served by verifying _ is bound correctly as well.
<Aethenelle_>
it would seem the logs are borked again...
<Aethenelle_>
headius: in explaining the current prepend issue to the MRI channels, I came up with a use case that might explain the behavior. Minimizing the unintended consequences of monkeypatching
<headius>
nirvdrum: I think we did that
<headius>
thought I admit I was surprised at the result
<nirvdrum>
headius: Not sure how. The expectation only checks [x,a,b,c]. I'm saying maybe it should check [x,a,b,c,_]
<subbu>
nirvdrum, git up :)
<nirvdrum>
Oh.
<headius>
you are absolutely right!
<nirvdrum>
subbu: Bah. I was looking at headius's latest commit.
<headius>
we agreed so hard we fixed it twice
* nirvdrum
goes back to his corner
<headius>
heheh
Aethenelle has quit [Ping timeout: 272 seconds]
Aethenelle_ is now known as Aethenelle
<nirvdrum>
Thanks.
<subbu>
gh-1960 regression spec can also use the fix that headius just made .. but i'm going to look at the ordering issue instead. but i have to get away from jruby for a bit and get other things taken care of. back in a bit.
<subbu>
cleanup i meant
colinsurprenant has quit [Quit: colinsurprenant]
johnsonch is now known as johnsonch_afk
multibot_ has quit [Remote host closed the connection]
<headius>
nirvdrum: my fix for failures subbu saw may fix #1976
<headius>
my partial port of checked funcall stuff for coercion was a little too partial
<nirvdrum>
Pushed already?
<headius>
almost
<headius>
running specs locally
subbu is now known as subbu|breakfast
<subbu|breakfast>
headius, i finished a rubyspecs run with runspecs "OptimizeTempVarsPass,LocalOptimizationPass,AddLocalVarLoadStoreInstructions,AddCallProtocolInstructions,LinearizeCFG" .. and i see 11f/6e vs 9f/4e for the default run.
kgerman_ has joined #jruby
<headius>
hmmm, language specs are clean but core has failures
<subbu|breakfast>
will look at your ordering issue later this morning ... and maybe fix the additional failures tonight.
<headius>
subbu|breakfast: I will get specs green and we'll see how it looks then
<headius>
damn process specs take too long
<headius>
we need to put together a fast set for local runs
<subbu|breakfast>
8 mins yes.
colinsurprenant has joined #jruby
Aethenelle has joined #jruby
nanoyak has joined #jruby
anaeem1 has joined #jruby
<Aethenelle>
on the plus side... redoing the prepend stuff will make some of the logic simpler...
<Aethenelle>
entirely not getting anywhere in the MRI channel though...
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dabradley has quit [Quit: WeeChat 0.3.8]
dabradley has joined #jruby
JRubyGithub has joined #jruby
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
jruby/master 769b2c3 Charles Oliver Nutter: Fill out port of check_funcall logic more completely....
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/u-g5ow
<headius>
nirvdrum: ^
<nirvdrum>
I'll pull.
<headius>
subbu|breakfast: fixed the language failure...the four others appear to be enebo breakage
calavera has joined #jruby
donV has quit [Quit: donV]
mjc__ is now known as mjc
mjc is now known as mjc_
<nirvdrum>
headius: I think that fixed it. The same exact set of specs are failing for me, but the trace looks different now.
<headius>
ok
vtunka has quit [Quit: Leaving]
subbu|breakfast is now known as subbu
noopq has quit [Ping timeout: 255 seconds]
<subbu>
headius, ok, thx.
e_dub has joined #jruby
<nirvdrum>
headius: When I run with raw backtraces, I'm seeing "Failure/Error: Unable to find matching line from backtrace" Is this a known issue?
toady00 has quit [Remote host closed the connection]
<headius>
yes, that's because we show lines in the backtrace rspec doesn't recognize
<headius>
since it only ever expects to see .rb lines
toady00 has joined #jruby
<nirvdrum>
And another Jenga piece is removed from the tower.
<subbu>
nirvdrum, so you said you see the same failures with 9k as with 1.7?
<nirvdrum>
subbu: I have no failures in 1.7.
<dfr|work>
morning
<headius>
subbu: I'm filing an issue for the remaining failures...99% sure they're from enebo's path-related commits last week
<subbu>
"The same exact set of specs are failing for me" .. i assumed you were talking of specs for your app that you were testing. but maybe i was too optimistic ;)
<nirvdrum>
subbu: I am talking about specs in my app. I meant on 9k, pre and post headius's patch.
<subbu>
ah, ok.
<nirvdrum>
So, same specs failing, but no NPE this time.
<nirvdrum>
I need to look into why they're failing now.
toady00 has quit [Ping timeout: 260 seconds]
<subbu>
k
<Aethenelle>
nirvdrum: I've found NPE to be a very helpful state for fixing tests...
<subbu>
headius, wonderful! will save a lot of time.
<subbu>
how do i run it?
<headius>
I'll commit momentarily, but "rake spec:ruby:fast" will do it
<headius>
tweaking the rake task now
JRubyGithub has joined #jruby
<JRubyGithub>
jruby/master 43b4a25 Charles Oliver Nutter: Add a spec:ruby:fast target that avoids subprocess-spawning specs.
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/uWITug
mister_solo has quit [Ping timeout: 272 seconds]
<headius>
chrisseaton: we were excluding the Encoding::Converter specs, which result in about 101k expectations given current tags
<headius>
there's your expectation count discrepancy
<headius>
like I said, we should pass 99% of what MRI and rbx do
<chrisseaton>
headius: ah thanks - but I don't understand is Encoding::Converted non-standard, or do we not support it? Is it just tons of tests for a tiny feature?
<headius>
I just never turned it on in the main spec run after I finished porting transcoder logic
<headius>
I'm doing that now and checking spec run
<headius>
I had been running it directly, which ignores excluded specs from jruby.2.1.mspec config
<chrisseaton>
great thanks
<headius>
yep yep
<Aethenelle>
i'll get on redoing prepend but keep my current branch around while I take the question to ruby-core's mailing list...
<headius>
Aethenelle: yeah good idea
<headius>
if it turns out any of our tests are appropriate to add to MRI, I can do that
<headius>
let me know when you post and I'll try to keep up with the thread
<Aethenelle>
k
<headius>
chrisseaton: specs look fine...I'll push this once I complete a :fast run
<chrisseaton>
yes that looks right - between MRI and a couple thousand less than RBX
<chrisseaton>
Does this meaning specifying encoding converter takes over 2/3 of the specs - wow that's complicated
<chrisseaton>
Hopefully I can pass all this stuff just by plugging into your work though
<headius>
they're just N * M permutations of encodings
<headius>
I believe
<headius>
you should be able to leverage the transcoder port without much trouble
lance|afk is now known as lanceball
<headius>
it is perhaps not the best way to write these specs, but it is what it is
<headius>
that's why we run MRI's tests too
<chrisseaton>
I need to look into that at some point
<headius>
we use minitest/excludes, which just goes off test's class + method...see test/mri/excludes files and it should be pretty self-explanatory
benlovell has quit [Ping timeout: 260 seconds]
<headius>
and rakelib/test.rake, which has the logic to run with excludes on
Hobogrammer has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
jruby/master ddc62c4 Charles Oliver Nutter: Fix verbose-mode warnings from jruby.rb.
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/2yxyjA
JRubyGithub has left #jruby [#jruby]
colinsurprenant has quit [Ping timeout: 260 seconds]
nanoyak has quit [Quit: Computer has gone to sleep.]
purplefox has quit [Ping timeout: 272 seconds]
colinsurprenant has joined #jruby
calavera_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
purplefox has joined #jruby
calavera has joined #jruby
toady00 has joined #jruby
enriclluelles has quit [Remote host closed the connection]
tcrypt has joined #jruby
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
elia has quit [Quit: Computer has gone to sleep.]
elia has joined #jruby
elia has quit [Client Quit]
<nirvdrum>
At some point it'd be good to see with one of the RubyMine guys why 9k won't load in the IDE. I assume they're looking for some file that longer exists.
<nirvdrum>
It looks like it might be looking for test/unit/autorunner.rb.
<headius>
doesn't load in the IDE?
<headius>
what do you mean
<headius>
if it's looking for test/unit stuff that has been removed, it will be a problem in MRI too
<nirvdrum>
You can choose which Ruby version to use in RubyMine. It just doesn't work with 9k.
<headius>
nice
<nirvdrum>
MRI 2.1.2 loads fine. Maybe it's a special-cased path for JRuby. Dunno.
<headius>
install test/unit gem, maybe it will have the necessary file
<headius>
test-unit
yfeldblum has joined #jruby
<nirvdrum>
Nope.
<nirvdrum>
Oh well, I'll file an issue.
<nirvdrum>
Heh. Apparently I've filed 109 over the years.
<Aethenelle>
thanks! my brain kinda stopped while i was writing that bug report... hope it makes sense.
xcv has joined #jruby
kgerman_ has quit [Ping timeout: 245 seconds]
skade has joined #jruby
nipra has joined #jruby
<headius>
yeah check my comment and see if it works
<headius>
it's hard to come up with the right language to describe this
skade has quit [Ping timeout: 260 seconds]
skade has joined #jruby
skade has quit [Client Quit]
<headius>
mpapis: any progress on that oauth gem?
<mpapis>
headius, I will be doing my own thing, already have some code using faraday, the only quyestion if it will be branch on oauth (for 0.5.0) or a new thing
<headius>
so you're not getting any responses eh?
<mpapis>
you know opensource = diy
tlarevo_ has quit [Remote host closed the connection]
tlarevo has joined #jruby
elia has joined #jruby
<headius>
yeah
<headius>
unfortunate though
Aethenelle has quit [Quit: Aethenelle]
yfeldblu_ has joined #jruby
elia has quit [Quit: Computer has gone to sleep.]
e_dub has quit [Quit: It's a hard knock life]
yfeldblum has quit [Ping timeout: 255 seconds]
yfeldblu_ has quit [Ping timeout: 272 seconds]
tlarevo has quit [Ping timeout: 245 seconds]
<nirvdrum>
headius: Well, good news. 5 of these specs are due to iconv being removed. Apparently it still loads in 2.0 mode in 1.7.x. Bad news is there's no longer an iconv gem that will load with JRuby as of 9k.
xcv has quit [Remote host closed the connection]
<headius>
iconv features have been replaced by Encoding::Converter...what's using iconv?
<nirvdrum>
My code.
<headius>
how dare you
<headius>
seriously though I think the translation is almost 1:1
nanoyak has quit [Quit: Computer has gone to sleep.]
<nirvdrum>
I'll take a look. It had been deprecated due to 1.9 Strings doing encoding conversions, only 1.9 Strings couldn't handle a bunch of conversions that Iconv could . . .
<nirvdrum>
It was like someone just said "close enough, shut it down"
kwando has quit [Ping timeout: 246 seconds]
<headius>
hmmm
<headius>
ok
Aethenelle has joined #jruby
<headius>
well if we wanted to support iconv still, perhaps it's possible to make a ruby wrapper
<headius>
or perhaps what you're doing with it is ok on the builtin converter
<nirvdrum>
I'm not sure if the conversion stuff got better in 2.0.
<nirvdrum>
There's one gem here that uses iconv too and upgrading isn't straightforward.
<headius>
mmm I see
<headius>
iconv was pulled into an external gem when they dropped it?
<Aethenelle>
headius: comments look good
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
mister_solo has joined #jruby
<headius>
nirvdrum: what's the gem?
<nirvdrum>
css_parser.
<nirvdrum>
I think they've fixed it upstream, but I'm 3 years behind master.
<headius>
options: bring back 1.7's iconv as a gem for you, write an API-compatible wrapper around Converter, change your code and the gem
kwando has joined #jruby
<nirvdrum>
I can fix my stuff I think. I'm a bit concerned that MRI people have the ability to "gem install iconv" and JRuby people do not.
<nirvdrum>
But maybe that's not anything to really worry about.
<headius>
if that's true, we can work with iconv gem maintainer to get a jruby version
<headius>
it has not come up recemtly
<headius>
looks like it is indeed the old MRI iconv
mister_solo has quit [Ping timeout: 255 seconds]
benlovell has joined #jruby
kgerman has quit [Quit: kgerman]
benlovell has quit [Ping timeout: 260 seconds]
<nirvdrum>
So, at least I know what's going on there. I'll move to the other 3 failures.
<ahadding1>
The comments advise against calling ThreadService.getCurrentContext() directly. Why is that?
<ahadding1>
And what is the recommended usage, then?
mkristian has joined #jruby
<headius>
ahadding1: if you want a thread context, ruby.getCurrentContext is preferred because ThreadService is an internal API
<headius>
other than that, there's no reason...the former calls the latter
<ahadding1>
ah, okay.
tcrypt_ has joined #jruby
<ahadding1>
headius: thanks!
tcrypt has quit [Read error: Connection reset by peer]
<ahadding1>
and since going through ruby.getCurrentContext does a bunch of setup stuff to map the threadcontext to a java thread... it would be inadvisable to create a new one via ThreadContext.newContext(ruby) to call say, someIRubyObject.callMethod(context, "some_method"))?
nanoyak has joined #jruby
<dfr|work>
headius, how about ThreadContext.newContext?
<dfr|work>
headius, or generally people shouldn't really be trying to create new thread contexts?
<headius>
ahadding1, dfr|work: it's best to allow getCurrentContext to manage all of that
diegoviola has joined #jruby
<dfr|work>
[full disclosure: ahadding1 and I work together]
<headius>
there's a lot of plumbing in there to make sure contexts are GCable without the thread going away, etc
<ahadding1>
headius: is the comment that advises against getCurrentContext somewhat misleading, then? since ruby.getCurrentContext() just uses that...
<headius>
what are you trying to do?
<headius>
well...maybe
<dfr|work>
basically we have a java object that responds to RPC calls and does that by invoking ruby methods... so I was thinkign that creating a 'clean' thread context made sense for duration of the call
<headius>
that's a pretty old and arcane part of JRuby
<headius>
dfr|work: TC is pretty expensive to set up
<headius>
very large
<headius>
internally we attach them to their native thread with a soft link so they don't GC too quickly but don't stick around forever either
<headius>
ThreadContext.newContext also does not associate the TC with the thread...it just gives you a blank one
rue has joined #jruby
<headius>
so any code that's going back to getCurrentContext will not see the one you pass through
etehtsea has quit [Quit: Computer has gone to sleep.]
<headius>
that will eventually bite you
<headius>
(if the cost of creating a new TC per call hasn't already)
kfpratt has quit [Remote host closed the connection]
<headius>
bbiab
rue has quit [Client Quit]
<dfr|work>
headius, hokay, fair enough.
<dfr|work>
headius, I just am a bit fuzzy on what 'current' really means. I guess current for the current thread, but yea =/
mister_solo has joined #jruby
_kfpratt has joined #jruby
_kfpratt has quit [Remote host closed the connection]
<headius>
current context is whatever context has been set for the thread in our internal structures...we often avoid going through those structures by passing TC through as a param, but it still needs to be associate with the thread
<dfr|work>
headius, my general understanding of ThreadContext was that it was representation of a ruby thread... Is that not quite correct?
<dfr|work>
because if so, if I'm doing a java RPC I'd rather setup a clean slate rather than inherit some other thread =/
<headius>
well, it's the behind-the-scenes data our runtime needs in each thread to support Ruby features
toady00 has quit [Remote host closed the connection]
<headius>
you *can* wipe out the TC and replace it if you want...but you're getting into JRuby internals to do that
mister_solo has quit [Read error: Connection reset by peer]
toady00 has joined #jruby
<dfr|work>
headius, alrighty. Long story short, until I'm willign to dig into internals, we'll use current thread context. That makes sense :)
<headius>
ThreadService#disposeCurrentThread and #adoptCurrentThread I think
mister_solo has joined #jruby
<headius>
oh, adopt is private... so just dispose and then getCurrentContext again
<headius>
should give you a clean slate...but DO NOT do that form a thread that's already deep in a Ruby stack, because it will blow up severely on the way out trying to pop frames
rimenes has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<ahadding1>
since every ruby object has getRuntime, if we wrap RaiseException in a new exception and rethrow it...
<ahadding1>
a client could get the RaiseException e from our rethrown exception, then call e.getException().getRuntime().getCurrentContext()?
nanoyak_ has quit [Read error: Connection reset by peer]
nanoyak has joined #jruby
kgerman has joined #jruby
bbrowning_away is now known as bbrowning
Aethenelle has quit [Quit: Aethenelle]
tcrawley is now known as tcrawley-away
fridim_ has quit [Ping timeout: 258 seconds]
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
e_dub has joined #jruby
BrindleFly has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/dkYWYg
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
jruby/master b55585c Chris Seaton: [Truffle] Remove unneeded transfer in Array#push.
BrindleFly has quit [Client Quit]
<headius>
chrisseaton: about how many passes through the interpreter does it take for something to JIT?
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to truffle-head: http://git.io/_GakAQ
<JRubyGithub>
jruby/truffle-head eecbbdc Chris Seaton: Merge branch 'master' into truffle-head
JRubyGithub has left #jruby [#jruby]
<headius>
ahadding1: to what end?
bbrowning is now known as bbrowning_away
<headius>
yes, you could, but you'd then be running that thread's Ruby stack against another thread's ThreadContext
donV has quit [Quit: donV]
phrinx has quit [Quit: Leaving...]
<headius>
I know this is kinda complicated...it might be simplified if we just had a single JRuby runtime in a given classloader, but you still mostly need to honor the association of ThreadContext and thread
mister_solo has joined #jruby
<ahadding1>
headius: not to any useful end. i was just realizing that i might be exposing the runtime when id rather not do so.
nanoyak has quit [Quit: Computer has gone to sleep.]
skade has quit [Quit: Computer has gone to sleep.]
nanoyak has joined #jruby
nanoyak has quit [Quit: Computer has gone to sleep.]
e_dub has quit [Quit: ZZZzzz…]
skade has joined #jruby
viking has quit [Remote host closed the connection]
nanoyak has joined #jruby
momomomomo has joined #jruby
kgerman has quit [Ping timeout: 272 seconds]
benlovell has joined #jruby
mje113__ has quit [Quit: Connection closed for inactivity]
benlovell has quit [Ping timeout: 240 seconds]
mister_solo has joined #jruby
<headius>
ahadding1: definitely would rather not to :-)
suvash has joined #jruby
suvash has left #jruby ["WeeChat 1.0"]
yfeldblum has quit [Read error: Connection reset by peer]
yfeldblum has joined #jruby
mister_solo has quit [Ping timeout: 240 seconds]
AlHafoudh has quit [Ping timeout: 260 seconds]
asuka has quit [Ping timeout: 245 seconds]
mfournier has quit [Ping timeout: 272 seconds]
asuka has joined #jruby
mfournier has joined #jruby
phrinx has joined #jruby
AlHafoudh has joined #jruby
<nirvdrum>
headius: Is the debugger known to be broken in 9k?
<headius>
"the debugger"
<nirvdrum>
require 'debug'
nanoyak has quit [Quit: Computer has gone to sleep.]
<nirvdrum>
That's built-in, isn't it?
<headius>
ahh well that works on trace events...if it's broken we can fix that
<headius>
trace events are tied into code execution (method calls etc) and I am not entirely sure that's 100% on 9k just yet
<headius>
it won't be hard to fix, but it's fill in the blnaks
<headius>
bbl
nanoyak has joined #jruby
<subbu>
nirvdrum, afaik, enebo add support for tracing.
<nirvdrum>
I'll file an issue for that then.
<nirvdrum>
I'm back to trying to track down this crazy issue.
<nirvdrum>
subbu: Maybe you'll have some thoughts on this. For the life of me, I can't find a simple reproduction. But basically, a method with a method-level ensure block doesn't seem to return back to its caller. I can't tell where it goes though.
<nirvdrum>
If I comment out the ensure, but leave the body, everything works.
xcv has quit [Remote host closed the connection]
<nirvdrum>
But, it only happens when calling a method that happens to take a block as well.
<subbu>
hmm ...
xcv has joined #jruby
<nirvdrum>
So, it's not all ensure blocks.
<subbu>
try with -Xir.passes=LinearizeCFG to rule out bad analyses?
marr has quit [Ping timeout: 272 seconds]
<nirvdrum>
And it's not all methods that take a block that triggers it either. I can put "[].each {}" and that works.
<nirvdrum>
Still fails.
<subbu>
and if it is not a really long-running piece of code, you can turn on full IR instruction tracing to see what is going on ...
<subbu>
but, if you know the name of the method, you can pipe it through less and search for it to go right to it.
<subbu>
over there, you will probably see code that raises the exception and you should be able to see where it is going ... the interp emits info about who is catching it.
rimenes has joined #jruby
<nirvdrum>
Whoa.
diegoviola has quit [Quit: WeeChat 1.0]
<nirvdrum>
432 MB and going.
<subbu>
ya, it is too verbose for stuff that is longer than few seconds.
<subbu>
enebo had a trick for turning this tracing on/off from ruby code.
<nirvdrum>
Still going.
<subbu>
i dont remember that offhand ... but he was using java integration from jruby to do it.
<subbu>
but, that doesn't help you now. but if i see him online later tonight, will ping him about it.
DomKM has joined #jruby
<nirvdrum>
So, one spec here. I'm approaching a 1GB logfile.
<nirvdrum>
Granted there's all the rails booting stuff.
diegoviola has joined #jruby
<nirvdrum>
Finished at 1.3 GB.
<subbu>
but, gives you a sense of how much code runs for booting up rails .. in case you didn't know that already. :)
<nirvdrum>
Heh.
anaeem1 has quit [Remote host closed the connection]
e_dub has joined #jruby
<nirvdrum>
subbu: Is this normal?
<nirvdrum>
in scope: INSTANCE_METHOD fetch_remote_form[/home/nirvdrum/dev/workspaces/mogotest/app/models/cookie_login_option.rb:150],