josh-k has quit [Remote host closed the connection]
mister_solo has joined #jruby
phrinx has quit [Remote host closed the connection]
mister_solo has quit [Ping timeout: 246 seconds]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to truffle-head: http://git.io/eLO5iw
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
jruby/truffle-head f346382 Chris Seaton: [Truffle] SlowPath has become TruffleBoundary.
<chrisseaton>
rhinon: sorry I don't know anything about puma. Leave your question there on ask again tomorrow and I'm sure someone will get back to you.
ludyte has joined #jruby
statonjr has quit [Quit: statonjr]
ludyte has quit [Ping timeout: 245 seconds]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/jYhtLw
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
jruby/master 3f72e2c Chris Seaton: [Truffle] PE tests broken.
josh-k has quit [Remote host closed the connection]
havenwood has quit [Remote host closed the connection]
subbu has quit [Quit: Ex-Chat]
josh-k has joined #jruby
ludyte has quit [Quit: ludyte]
phrinx has joined #jruby
phrinx has quit [Ping timeout: 246 seconds]
<nirvdrum>
rhinon: I'm a big fan of TorqueBox. It's a bit heavier (although TB 4 aims to fix that), but it works fantastically.
yfeldblum has quit [Remote host closed the connection]
havenwood has joined #jruby
josh-k has quit [Read error: Connection reset by peer]
yfeldblum has joined #jruby
brettpor_ has joined #jruby
brettporter has quit [Ping timeout: 256 seconds]
tenderlove has quit [Quit: Leaving...]
qmx has quit [Read error: Connection reset by peer]
qmx has joined #jruby
brettpor_ has quit [Remote host closed the connection]
brettporter has joined #jruby
pgokeeffe has quit [Quit: pgokeeffe]
brettporter has quit [Ping timeout: 255 seconds]
brettporter has joined #jruby
brettporter has quit [Ping timeout: 258 seconds]
diegoviola has quit [Quit: WeeChat 1.0.1]
brettporter has joined #jruby
josh-k has joined #jruby
e_dub has joined #jruby
josh-k has quit [Remote host closed the connection]
havenwood has quit [Remote host closed the connection]
colinsurprenant has joined #jruby
johnsonch is now known as johnsonch_afk
johnsonch_afk is now known as johnsonch
e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
johnsonch is now known as johnsonch_afk
pgokeeffe has joined #jruby
SynrG has quit [Ping timeout: 245 seconds]
josh-k has joined #jruby
josh-k has quit [Read error: Connection reset by peer]
josh-k has joined #jruby
johnsonch_afk is now known as johnsonch
johnsonch is now known as johnsonch_afk
<Antiarc>
I'm trying to upgrade from 1.7.12 -> 1.7.16, and I'm having problems with jbundler - after installing it, bundler complains about jar-dependencies-0.1.3 being activated when it wants 0.1.2
<Antiarc>
That's when attempting to bundle install
<Antiarc>
Is that a known issue?
robbyoconnor has joined #jruby
<Antiarc>
fresh gemset, gem install jbundler, bundle install then fails
<usebrn>
are there some requirements that scriptingcontainer has to be terminated from the same java thread which parsed and run script ?
kares has joined #jruby
yfeldblum has quit [Ping timeout: 265 seconds]
josh-k has quit [Remote host closed the connection]
johnsonch_afk is now known as johnsonch
johnsonch is now known as johnsonch_afk
dvorak has quit [Ping timeout: 250 seconds]
dvorak has joined #jruby
colinsurprenant has quit [Quit: colinsurprenant]
nirvdrum has quit [Ping timeout: 255 seconds]
pgokeeffe has quit [Quit: pgokeeffe]
rsim has joined #jruby
johnsonch_afk is now known as johnsonch
johnsonch is now known as johnsonch_afk
pchalupa has joined #jruby
brettporter has quit [Remote host closed the connection]
<usebrn>
so it seems that I already found a cause of my problems with jruby
brettporter has joined #jruby
<usebrn>
namely, in my Server different thread initializate SC, and different terminates it
yfeldblum has joined #jruby
<usebrn>
it causes that server after handling some number of request starts be unresponsive because of the fact that objects on the heap are not released, they are kept by something, I haven't immersed into Threading system in Jruby, but what I could see in heap dump was the org.jruby.Ruby instances kept by Thread who initializated SC
<usebrn>
even when request was already gone
<usebrn>
I created some snippet of code which exposes this behaviour
josh-k has joined #jruby
brettporter has quit [Ping timeout: 244 seconds]
tylersmith has quit [Remote host closed the connection]
tylersmith has joined #jruby
yfeldblum has quit [Remote host closed the connection]
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<chrisseaton>
usebrn: that's great - can you submit a bug report about this. If JRuby doesn't work in that configuration we should issue a warning, or at least document it
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/CPi5Ng
<JRubyGithub>
jruby/master cd315fa Benoit Daloze: [Truffle] Fix method search of Module#alias_method and public/protected/private....
JRubyGithub has left #jruby [#jruby]
robbyoconnor has joined #jruby
robbyoconnor has quit [Client Quit]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/7skXOw
<enebo>
headius: oh hmm this is using raw IRClosure
<headius>
so RecordBeginEnd... basically aggregates a list during interp and then they run after the main script body
<headius>
I'm trying to figure out the best way to compile them
<enebo>
This also seems wrong to me as well
<enebo>
I think all END is processed regardless of whether body actually runs properly right?
<enebo>
like if I exit half way through a script the END still invokes
<headius>
I guess I've never tried all those scenarios
<headius>
there appear to be a few specs using END but they're only testing DATA
<enebo>
oh hmm
<enebo>
I am wrong I guess
<headius>
oh, and that's __END__
<headius>
so there's nothing
<enebo>
END { }
<enebo>
but it does not invoke END if you exit early
<enebo>
which I thought it would
<headius>
enebo: I am actually most confused why the script body doesn't include the invocation of BEGIN and END blocks
<headius>
i.e. why it is outside the interpret of the script body
<headius>
so failure to complete the script means END blocks don't run at all
<headius>
are you sure?
<enebo>
postexe is record_end_block
colinsurprenant has quit [Quit: colinsurprenant]
<enebo>
but I am not seeing the puts
<headius>
"END { puts 1 }; raise" does puts 1
<headius>
oh right
<headius>
it would have to go after
<headius>
yeah if I put it after MRI doesn't puts either
<enebo>
on master at where I last pulled the end block is not invoking
<enebo>
which would be before any JIT merge
<headius>
so it does run END blocks it has encountered but not any it hasn't reached before script exits
<enebo>
no it doesn’t seem to ever run them for me
<headius>
ok...so JIT is not to blame
<headius>
oh!
<enebo>
yeah I think it is something not hooked up
<headius>
yeah you're right...something changed so that interp is not running them
<enebo>
The other problem is since there are not referenced through wrappedirclosure we are not prepping for interp
<enebo>
which I guess is possible that is the issue since I think for closures we assume they must have prepped but then we shold see an exception
<enebo>
So I expect they are not hooked up and once we hook them up then they will crash
<enebo>
headius: you remember our 3:30 f2f
<headius>
yes
<enebo>
ok added prepping and it did not invoke which I guess I expected.
<headius>
huh
<enebo>
looks like runBeginEndBlociks should be happening
<enebo>
It even has a prepare in it but I think that is the wrong place
<headius>
enebo: I think this is your InterpreterContext changes or something
<enebo>
headius: yeah it could very well be
<headius>
the logic for RecordBeginEndBlock adds it to toplevel IRScope directly
<enebo>
headius: I think I might even know why
mister_solo has joined #jruby
<enebo>
yeah exactly
<headius>
then the runBeginEndBlocks tries to get it from IC
<enebo>
so we mutate as we run and we prep ic before they are added
<headius>
former probably just needs to aedd to IC
<headius>
right
<enebo>
yep so we both have same explanation
<headius>
if I'm reading this right, multiple runs through the same script would add them multiple times, but maybe that doesn't happen?
<headius>
actually no...here's an even better one
<headius>
2.times { END { puts 1 } }
<headius>
END blocks aren't running correctly right now, but I think that would add two END blocks to the list
<enebo>
yeah we can solve that with some identity if it is actually broken
<headius>
ordered set or something
<enebo>
It should be a set
<enebo>
yeah ordered
<headius>
and on IC?
subbu|lunch is now known as subbu
<enebo>
headius: well I think it should be the same but I am worried about this relationship
<enebo>
headius: a main point of IC is it is self-contained
<enebo>
but I guess END is halting problem thing
<enebo>
So I think the answer here is to a) make sure prepareIC happens once during clone (I think I fixed that locally) and b) running into these ENDs saves the IC for these END blocks to the script IC
<enebo>
we cannot do it statically but I forgot that END was like this
<headius>
ahh right
<enebo>
headius: in any case I will fix this. I understand why it is broken now
<headius>
should I go ahead implementing RecordBeginEndBlock or do you have larger changes in mind?
<headius>
implementing in JIT I mean
<enebo>
headius: it should be the same from an IRScope perspective
mister_solo has quit [Quit: So long, and thanks for all the fish!]
<headius>
ok
<enebo>
headius: When we walk an IRScope/CFG for making linearized list of instrs for interp we call simpleclone
<enebo>
headius: That should now see all these END block closures and prepare them as a side-effect of cloning
yfeldblum has joined #jruby
havenwood has joined #jruby
<enebo>
headius: When we actually hit record_end_block it will get the IC and register the END IC with the script IC
<enebo>
So the IC’s should basically all match since they will all be prepared during the clone. Execution is dependent on execution flow
<headius>
seems like the running of END blocks needs to be in a finally too
<headius>
as it is right now, the END { puts 1 }; raise example won't work like MRI
<headius>
enebo: I'm going to let you mess with this and try a couple things for JIT side
<enebo>
headius: yeah this will be a bit too but I feel I know what should change
<headius>
I'd hoped to just leave these unimplemented for now because they're above and beyond the script body...it means I need extra wrapper logic around the jitted code
<headius>
I should be able to do the records the same way interpreter did it (before IC) but I still need somewhere to run them
<headius>
and unsure what the "finally" situation needs to be
JohnBat26 has joined #jruby
<enebo>
headius: really the impl should be the same before and after
<headius>
I know...I'm just not sure how best to do it :-)
<enebo>
yeah
<headius>
I want the runnning of those blocks to just be part of the script body, and if they're not I'm not sure where I should put them
<enebo>
gah
<enebo>
record_end_block should just use wrappedirclosure
<headius>
oh hmm
<enebo>
IT constructs one live
<headius>
yeah that would help
<headius>
could it also aggregate into an array and run them as part of script's GEB? :-D
<enebo>
yeah I am wondering that too
<enebo>
but is self always top-level self?
<headius>
I realized a simple way I can make this work...in my synthetic __script__ method that wraps invocation of the actual script body
<headius>
I just need the records
<enebo>
we pass in a value ‘self’ into this execution but that is top-level script self at that point
<enebo>
oh wait it asks IRClosure for self so perhaps this is ok to make it right away (at least for end blocks)
<enebo>
begin sort is headless from instr stream
<enebo>
but I suppose it is still the same self
<headius>
ugh, I can't do this yet either
<enebo>
but I cannot make an operand anywhere for it which is probably why these are made in the method
<enebo>
runbeginend method
<headius>
RecordBeginEndBlock holds a reference to "declaringScope" that I can't propagate
<headius>
I don't know what scope that is or where it comes from
<enebo>
Seems like we could make instrs run_begin closure at entry BB
<enebo>
then you would not need any special JIT logic
<enebo>
how the hell to BEGIN blocks work
<enebo>
Are they the non-halting ones
subbu has quit [Ping timeout: 244 seconds]
<headius>
yeah BEGIN blocks need to always run
thsig has quit [Remote host closed the connection]
<enebo>
heh…yeah they also run reverse order right?
<enebo>
on no in order ok
<headius>
yeah there's no IR at all for encountering begin blocks, so they must already be in the right place
<headius>
they do run right now
<enebo>
headius: yeah root level interpret just accesses the list which is right because it is not execution dependent
<enebo>
headius: very first thing to run too in the script
<enebo>
ok a little hack I will handle begins as-is atm and make ends register ics
<enebo>
ends will also use wrappedirclosure since they are part of instr stream
<enebo>
headius: Actually I will bandaid this and pass scope into interpret_root
<enebo>
headius: I just noticed evalCommon is still using scope
<enebo>
headius: so it will make it work but we will be sharing scopes so there is likely issues
<enebo>
but it will be better than current master
colinsurprenant has joined #jruby
noop has quit [Quit: Leaving]
kgerman has quit [Remote host closed the connection]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/6SQrkA
<JRubyGithub>
jruby/master b533e58 Thomas E. Enebo: Workaround some issues in BEGIN/END moving to IC
JRubyGithub has left #jruby [#jruby]
<enebo>
headius: ^ should be fixed again
<enebo>
headius: tiny revert until it gets fixed for reals
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/P03INA
<JRubyGithub>
jruby/master 0b95ac1 Thomas E. Enebo: END should fire even if Ruby has exception
JRubyGithub has left #jruby [#jruby]
subbu has joined #jruby
<headius>
ok
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/VeY4lg
<JRubyGithub>
jruby/master 736fb94 Thomas E. Enebo: END should fire even if Ruby has exception in eval
JRubyGithub has left #jruby [#jruby]
colinsurprenant has quit [Quit: colinsurprenant]
mrmargolis has joined #jruby
colinsurprenant has joined #jruby
tenderlove has quit [Remote host closed the connection]
rolfb has joined #jruby
rsim has quit [Quit: Leaving.]
brettporter has joined #jruby
thsig has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
jruby/master b58b9f3 Charles Oliver Nutter: Use NotCompilableException more consistently.
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/lzBE4g