anaeem1_ has quit [Remote host closed the connection]
anaeem1 has joined #jruby
anaeem1 has quit [Remote host closed the connection]
mitchellhenke has joined #jruby
mitchellhenke has quit [Client Quit]
yfeldblum has joined #jruby
nateberkopec has quit [Quit: Leaving...]
<nirvdrum>
bbrowning: FYI, that popen snippet you gave me doesn't seem to set $? correctly. I need to look into it more. But if you rely on that, it's something to watch out for.
<nirvdrum>
Ahh. I didn't realize popen3 in 1.9 added the wait thread, from which the PID can be retrieved. It'd be great to drop my dependency on open4.
<nirvdrum>
Although I guess if I still need to support JRuby 1.7.x I'm going to have to switch to IO.popen4 anyway.
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] enebo closed pull request #2341: allow for negative arity when calling curried proc (master...bugfix/2340-curry-proc-with-varargs) http://git.io/UTwq6w
JRubyGithub has left #jruby [#jruby]
<enebo>
bbrowning: Is this on jruby-1_7? The popen3 problem?
<bbrowning>
enebo: master
<enebo>
bbrowning: ok
<enebo>
bbrowning: hoping to do 1.7.18 today
<enebo>
ah nuts mkristian just opened an issue
<bbrowning>
enebo: yay, I think? I can't get TB3 integs to run w/ 1.7.18-SNAPSHOT yet but it's due to various issues from the rubygems update I think.
<bbrowning>
So probably not an actual JRuby problem as much as a RubyGems problem and/or change of behavior
<enebo>
bbrowning: oh yeah I wonder if we should go back one version of rg or not
<bbrowning>
enebo: well headius worked around the issue that cropped up in 2.4.5 - I haven't tracked down my latest issue to RG definitively or not yet
<enebo>
nirvdrum: chrisseaton: you guys miss something in a recent commit?
<chrisseaton>
Travis?
<enebo>
chrisseaton: yeah project is not compiling
<bbrowning>
enebo: I'm not advocating one way or the other about RubyGems. I just won't be able to run the TorqueBox 3 integ suite against 1.7.18 until I can figure out my stack overflow issue.
<chrisseaton>
Give me a minute...
<enebo>
chrisseaton: np
<enebo>
bbrowning: well I guess I am advocating reverting on rg and solving this for 19
<bbrowning>
enebo: that makes me wonder - how easy is it to revert? just revert the commit that upgraded RG?
<enebo>
which mean possibly reverting headius patch on top of that upgrade hoping this will be a single commit
<enebo>
bbrowning: yeah that one for sure
<enebo>
bbrowning: but one other one first
<bbrowning>
perhaps I should see if I can revert locally and then run TB3 integs against that. if I still get my latest error, then at least I know it's not related to RG upgrade
<enebo>
bbrowning: true but mkristian also has an issue now
<bbrowning>
but if my stack overflow error goes away that's another strike against upgrading RG for 1.7.18
<enebo>
bbrowning: at this point multiple stacking issues makes it risky even if a total bummer
<bbrowning>
yeah
<enebo>
plus I really only have today and tomorrow for a release this week
<bbrowning>
do you know which version of RG shipped with which version of MRI?
<enebo>
bbrowning: not off hand no
<chrisseaton>
I wish travis would say 'I know it was broken before, but you've really broken it now'
<bbrowning>
I wonder if perhaps they made some breaking behavioral changes along the way
<enebo>
chrisseaton: heh
<enebo>
bbrowning: anything is possible but let’s face it there are many moving parts
mitchellhenke has quit [Quit: Computer has gone to sleep.]
<bbrowning>
yeah
tcrawley-away is now known as tcrawley
<enebo>
bbrowning: I don’t actually see headius commit for rg?
<nirvdrum>
chrisseaton: Going along with that, I'd like it to remember who broke the build. As of now it just uses the latest commit author.
etehtsea has joined #jruby
<enebo>
bbrowning: can you look at commit history quick to see if you can see it or perhaps it never landed
<enebo>
headius: also bbrowning is still having an issue with it possibly?
<bbrowning>
enebo: integs are running against reverted RG 2.4.5 now to see if that fixes my issues
elia has quit [Quit: Computer has gone to sleep.]
<enebo>
bbrowning: thanks. Hopefully it is golden
<enebo>
hmm or greenish
<headius>
enebo: did you revert on 1.7 already?
<enebo>
locally
<enebo>
I have not pushed
<enebo>
headius: bbrowning reverted lcoally as well just to make sure he is green
<headius>
ok
<enebo>
headius: mkristian already confirmed reverting fixed his issue
<headius>
yeah I saw that
<enebo>
I do think it is important to fix this issue but I would rather release. There appears to be a lot more fallout than I thought possible here :)
<enebo>
Our other alternative could be to try 2.1.4 but I don’t think that will reduce our support footprint
<enebo>
unless there is a significant thing in 2.1.4 like security fix
<enebo>
but again the issue is no bake time so I don’t think we should if we release today/tomorrow
<enebo>
headius: the other thing on crypt probably is a misconfigured system
<enebo>
headius: libcrypt did exist but it was not in a common path
<enebo>
OTOH perhaps now with this report it is more serious. I tested on ubuntu so I am confused :)
Aethenelle has quit [Quit: Aethenelle]
Aethenelle has joined #jruby
<headius>
seems like it's forcing us to make optional binding in jnr-ffi
yfeldblum has joined #jruby
<enebo>
headius: ah this looks like it is a NPE when converting arbitrary ggoofy chars to native something is probably picking up \0 or something an doing the wrong thing
subbu has joined #jruby
<headius>
hmm
<enebo>
headius: although I do not see this issue on travis nor locally
<enebo>
That particular test does massive permutations of odd strings and calls crypt
anaeem1 has joined #jruby
<headius>
can crypt return null there?
<enebo>
hmmm yeah probably
<enebo>
I am more confused why I can get it to run
<headius>
well, that's my guess then :-)
anaeem1 has quit [Remote host closed the connection]
yfeldblum has quit [Ping timeout: 245 seconds]
elia has joined #jruby
<headius>
hmm
erikhatcher has quit [Quit: erikhatcher]
<enebo>
headius: yeah who knows. Nothing explicitly passes null back but it can do it no doubt
yfeldblum has joined #jruby
<headius>
I'm trying to determine how that would happen
<enebo>
hmmm I actually think I might have excluded this test
<enebo>
but that exclusion is not there
<headius>
POSIX.crypt goes straight to LibC.crypt
<enebo>
this test is weird because it takes a bunch of arbtrarily encoded crap and sends it to crypt
<headius>
The function crypt() returns a pointer to the encrypted value on success, and NULL on failure.
<headius>
you need a null check + errno
<headius>
that wouldn't make it run but we'd know what the error is
<enebo>
as can be seen in rubyspec the behavior does not seem to be consistent between OSes
mkristian has quit [Ping timeout: 252 seconds]
<enebo>
headius: ah yeah…whoops
<enebo>
but we can fix this without re-releasign jnr-posix for now
<enebo>
if null then call errno
<enebo>
from jruby
<enebo>
and then remove that once we fix jnr-posix
<headius>
yeah
<headius>
looking at MRI
<enebo>
Passes on MacOS
<bbrowning>
enebo: all TB3 integs pass w/ jruby 1.7.18-SNAPSHOT and the one RG upgrade commit reverted
<bbrowning>
how does an RG upgrade result in DRB throwing a stack level too deep error? no idea.
<enebo>
bbrowning: great. Thanks for checking
yfeldblum has quit [Ping timeout: 252 seconds]
<bbrowning>
but it does
<enebo>
bbrowning: require semantics changing
<enebo>
bbrowning: infinite require?
<headius>
enebo: there's BROKEN_CRYPT idefs in the MRI version
<bbrowning>
perhaps so - the error makes me think it's actually a StackOverFlow coming from jruby somewhere being wrapped and handed off to ruby as stack level too deep
<headius>
it does something with the salt
<bbrowning>
but I've yet to find where in the jruby code that is occuring
<enebo>
headius: well crypt is a weird C function in that it does special stuff if the string of salt is in a special format
<headius>
enebo: the error check is literally just check for null and raise sys err
<subbu>
enebo, headius i changed impl of record-end-block instr ... now, that should be simple to add jit support for.
<headius>
subbu: oh nice
<enebo>
headius: I find it weird they did not just make another C function
<enebo>
subbu: I wonder if other finalizers can be woven into that?
elia has quit [Ping timeout: 245 seconds]
<enebo>
subbu: all the ones run by runtime.terminate() run after rootscript body scope is done
<enebo>
subbu: and I thikn it should be same time as end
<subbu>
enebo, i don't know .. i just tweaked it to match 1.7 ... i haven't taken a look at that other stuff.
<headius>
enebo: weird...if the salt is non-ascii they just use the first two bytes
<subbu>
but, perhaps could be done there.
<headius>
anyway, hopefully handling error will tell us what's failing
<headius>
subbu: I'll try to impl begin/end this week
<enebo>
headius: yeah I looked at that too but even if so I am confused why macos runs them without doing that
mkristian has joined #jruby
<enebo>
headius: It only does that is BROKEN_CRYPT though right?
<headius>
enebo: yeah
<headius>
there's a simple configure test for it
<enebo>
headius: looking at that now
<enebo>
awful
<enebo>
I don’t see why they would bother
<enebo>
Can this actually solve the underlying issue
<enebo>
I mean they are just deciding to truncate and pick the salf for the people who are sending non-7bit chars
<enebo>
Unless this is some known convention for handling cryprt
<enebo>
irony is this was changed for MacOS and not Linux
<enebo>
I wonder if this is in fact the problem
<enebo>
I don’t have any clue why you would change someone’s salt for them. Seems like the wrong fix to me.
<enebo>
can confirm mkristian’s crypt bug on my ubuntu image so there’s that.
<enebo>
I will figure out what is causing it
anaeem1 has joined #jruby
<headius>
enebo: ahh great
<headius>
enebo: does seem like the wrong fix
tenderlove has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 1 new commit to master: http://git.io/stsJqw
<JRubyGithub>
jruby/master 58ca80d Chris Seaton: [Truffle] Starting to fix attribute assignment returning the RHS rather than the result of the method.
<headius>
we're trying to figure out why the change was made and why it's the right change
<asarih>
hmmm.
<headius>
"This is actually the expected behavior of crypt(3) on OS X. It doesn't support the $id$ modular format, and if the salt does not begin with an underscore only the first 2 bytes are used (presumably in your "bug #2" you're changing parts of the salt beyond the first 2 bytes.)"
<headius>
subbu: how do the end blocks eventually get invoked?
<subbu>
headius, however it was in 1.7 .. via tearDown in Ruby.java
<headius>
oh hrm
<headius>
ok
<headius>
I'm not sure how to test that
<headius>
without shelling out
<subbu>
how was this tested in 1.7?
<headius>
the end block doesn't seem right
<headius>
in the case of END { } it has no instructions at all
<Aethenelle>
headius: the options are what ever i can eventually find... just want to know if anyone has a preference or good example box for the various platforms supported by ffi/jruby
<headius>
ends up emitting preamble code in JIT that does not do a return, blows up
yfeldblum has quit [Ping timeout: 245 seconds]
<headius>
Aethenelle: are you looking for arm and arm64 or just the latter?
<headius>
we don't have any testing on arm either, of course
<Aethenelle>
arm, arm64, ia64, mips(el), mips64(el), ppc(64), s390(x) (if i can get it working at all), sparc-linux
<headius>
subbu, enebo: yeah something's weird about the END { } block
<Aethenelle>
s390(x) may not happen at all and sparc-solaris is out entirely
<subbu>
headius, but, it works fine with non-empty end blocks? if just empty blocks . it is probably a bug in the add call protocol instr code that may not be handling empty cfgs properly.
<Aethenelle>
not sure ppc-aix will happen either
<Aethenelle>
similarly ppc-darwin
<headius>
subbu: no it looks like all END and BEGIN are missing logic
<headius>
END with {} or { 1 } or { a = 1 } all boil away to zero instructions
<headius>
END with { puts 1 } has the puts logic and then falls off the end anyway
<subbu>
hmm .. ok.
<subbu>
will take a look later today.
donV has joined #jruby
<headius>
I'm poking around anyway, might figure it out
<headius>
I think if we fix this the JIT work is done
<headius>
(small local diff)
<donV>
Hi all!
<headius>
donV: hello there!
<headius>
happy holidays!
<donV>
And you too!
<subbu>
headius, great, yes. poke away!
<chrisseaton>
headius: do you still have more optimisations planned?
<headius>
subbu: looks like it may simply be because it's not wrapped in full iter logic in the AST
<headius>
chrisseaton: you mean ever?
<subbu>
headius, but, why is it JIT specific?
<subbu>
it runs fine in interp mode.
<headius>
subbu: interpreter can fall off the end of a body
<headius>
JVM doesn't allow that
<chrisseaton>
I mean before the 9k release? I wasn't sure what you had planned and what you've completed in terms of opt.
<headius>
chrisseaton: oh, probably not before a preview, but I'm hoping we'll get some reports after that
<headius>
it has been a mixed bag so far, some faster than 1.7, some slower
<enebo>
headius: END for a = 1 and 1 do DCE all instrs away. and I didn’t think END returns a value
<headius>
enebo: it needs to in JIT
<headius>
I can't have a method that just fades away
<chrisseaton>
headius: yeah I can point you at some benchmarks that still aren't quite as fast as before if you are interested - but there are also some huge improvements - deltablue I think is an example
<headius>
I am going to try to add an artificial return in the builder
<enebo>
headius: so perhaps we unconditionally add a return nil or something so JIT won’t die?
<subbu>
headius, yes, the return should fix it.
<subbu>
i add returns to all other scopes in builder but didn't think of it for the end block :)
<chrisseaton>
headius: yeah deltablue is something like 4.4x in my configuration
<enebo>
oh you just said that :)
havenwood has joined #jruby
<subbu>
headius, that also explains this fixme i added to interp code :)
<subbu>
// Control should never get here!
<subbu>
// SSS FIXME: But looks like BEGIN/END blocks get here -- needs fixing
<subbu>
return null;
<enebo>
heh
<subbu>
you can get rid of it as well and probably throw an exception if it ever gets there.
<headius>
subbu, enebo trying it now
<headius>
yay
<headius>
worked
<enebo>
headius: that fixme bugged the hell out of me too :)
<headius>
where is that?
<enebo>
in interpreter
<enebo>
I had to kill my IDE to run my ubuntu image or I would tell you more
<subbu>
Interpreter.java line 574
<headius>
rock and roll, BEGIN and END work
<headius>
I changed the fixme to raise Ruby RuntimeError
<enebo>
someone gets bonus points for running finalizers on end of that :)
<enebo>
I admit the concept of that is fuzzy to me still
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius>
I'm going to go with this patch
josh-k has quit [Remote host closed the connection]
triple_b has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to master: http://git.io/C6t0vg
<JRubyGithub>
jruby/master a15af3e Charles Oliver Nutter: JIT support for BEGIN and END.
JRubyGithub has left #jruby [#jruby]
<headius>
enebo, subbu: all that leaves in the compiler spec is long code bodies
<headius>
so I guess that means all language constructs are JITing
<headius>
or at least all the ones we have tests for in there
<enebo>
headius: cool
<chrisseaton>
congrats!
<enebo>
headius: we have a plan for long bodies but I don’t think we care for final
<headius>
it's a low priority to be sure
<enebo>
headius: If we accept AOT will save persisted IR then long bodies will at least execute AOT
<enebo>
headius: I think that was our only main big issue with long bodies
<headius>
language rubyspecs with -X+C: 64 files, 1813 examples, 3242 expectations, 0 failures, 0 errors
<headius>
woot
<subbu>
wonderful.
<headius>
I should probably confirm they don't all bail out to interpreter
<headius>
mkristian: hey, do you know what's wrong with -Pmain on master?
<headius>
it ran ok locally but has been failing since you merged in jruby-openssl 0.9.6
<headius>
we need to get that green
<mkristian>
headius, let me see - sorry I never look on travis after the merge
<headius>
it's in one of those web container tests
<subbu>
headius, i suppose there really should not be any inherent blockers to jitting most code bodies now .. just whether it is worth it, and whether the code body will generate too big of a body
<headius>
subbu: yeah, that's about it
<headius>
if there's time before 9k we can explore what it would mean to JIT blocks without jitting the containing method
<headius>
I think that would be tricky right now because of the way shared state gets optimize
<headius>
enebo: what's the status of your refinements work?
<headius>
I'm starting to contemplate what all we need to finish for a preview
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian pushed 1 new commit to master: http://git.io/DVbsYQ
<JRubyGithub>
jruby/master 01c0ba4 Christian Meier: switch BC version in test
JRubyGithub has left #jruby [#jruby]
Felystirra has quit []
<headius>
mkristian: figured it would be something like that
<mkristian>
strange that I did not see it on the test-branch I had
<enebo>
headius: It passes many of the basic refinements but fails plenty of stuff
<enebo>
headius: I need to change it before committing because I added an instr for it and this would be much better suited to choosing a callsiteadapter when all the ordinary call-related instrs are being made
<headius>
enebo: ok
erick has joined #jruby
cprice__ has joined #jruby
e_dub has quit [Quit: e_dub]
<headius>
hmm
<headius>
for some reason speedtest.net wants to route me through Georgia
<headius>
my traceroute doesn't appear to go anywhere near Georgia
<enebo>
headius: fun. Perhaps our local routes are pinging poorly
<enebo>
headius: It decides based on ping latency I think
<headius>
maybe
<headius>
well I noticed something else today
<headius>
I went to pbs site and it picked a Georgia station as my local
<headius>
something about my connection was associated with a Georgia head end at some point, I think
<headius>
yeah, whatsmyip.com says this IP is in Georgia
<headius>
lovely
<enebo>
hahah
<enebo>
Minneapolis for me
<headius>
lame
<headius>
I think I will have to request an IP block registered to be in MN
<headius>
sigh
cprice has joined #jruby
cprice__ has quit [Ping timeout: 240 seconds]
<enebo>
headius: that is pretty weird
codefinger has joined #jruby
yfeldblum has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] lucasallan pushed 2 new commits to master: http://git.io/FGywDg
<JRubyGithub>
jruby/master fa9fb6c Lucas Allan Amorim: [Truffle] - Implements String#upcase
<JRubyGithub>
jruby/master b68cdcf Lucas Allan Amorim: Merge branch 'master' of github.com:jruby/jruby
<enebo>
headius: You should figure out what you can get from a Georgia ip addr
yfeldblum has quit [Ping timeout: 240 seconds]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] enebo pushed 1 new commit to jruby-1_7: http://git.io/9HBudg
<JRubyGithub>
jruby/jruby-1_7 53afbbb Thomas E. Enebo: too many issues discovered too close to release. reverting upgrade
JRubyGithub has left #jruby [#jruby]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] lucasallan pushed 1 new commit to master: http://git.io/jRE-QA
<JRubyGithub>
jruby/master 98f907d Lucas Allan Amorim: [Truffle] - Implements String#upcase!
JRubyGithub has left #jruby [#jruby]
marr has quit [Ping timeout: 244 seconds]
nateberkopec has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] enebo pushed 1 new commit to jruby-1_7: http://git.io/KMv8nw
<JRubyGithub>
jruby/jruby-1_7 fce7ea8 Thomas E. Enebo: Fix #2342. Java::JavaLang::NullPointerException: org.jruby.RubyString.crypt(RubyString.java:2660)
JRubyGithub has left #jruby [#jruby]
<headius>
enebo: probably some local stations that will stream or something
<enebo>
headius: It is not like you got the uk and can stream bbc archives but perhaps something is there
<headius>
yeah
<headius>
that would be nice for some things, but then netflix would only stream crappy Britcoms :-)
<enebo>
ok well EINVAL now happens on ubuntu with weird salts
<headius>
yay
<enebo>
not so easy to test
<enebo>
at least I don’t want to try and add something for glibc 2.12+ systems
<enebo>
but I did verify it works
mister_solo has quit [Ping timeout: 252 seconds]
<headius>
I look forward to a day when it is as easy to rip and upload movies to the cloud as it is to rip and upload music
<enebo>
nirvdrum: ^ that impl seems like it will explode on bad input
anaeem1 has joined #jruby
<enebo>
nirvdrum: Not that you wrote it :)
<nirvdrum>
enebo: A lot of our stuff currently explodes on bad input :-/
<enebo>
nirvdrum: I was talking about 0-1 char but I also just realized it does a toString() which won’t help for all m17n stuff
<nirvdrum>
And rubyspec doesn't really cover a lot of bad cases.
<enebo>
nirvdrum: fwiw getting off the ground is much more about common cases working then uncommon cases throwing proper error
<enebo>
nirvdrum: but all of these checks will add codesize to the impl and slow it little by little
anaeem1 has quit [Remote host closed the connection]
<nirvdrum>
We're trying to push some stuff out to ruby.
<enebo>
nirvdrum: cool
<enebo>
nirvdrum: It is our looooong term goal and has been for a long time
<nirvdrum>
I suppose a lot of this is the same cycle non-Truffle JRuby went through.
<nirvdrum>
Push what you can out to Ruby and then optimize in Java as needed.
<enebo>
nirvdrum: well we did not start that way because winning on performance in a short period of time had us default to Java and move to Ruby when performance was about the same or didn’t matter
<enebo>
nirvdrum: with 9k and ability to inline having it in Ruby will end up allowing us to opt things we never could
cprice has quit [Ping timeout: 255 seconds]
<enebo>
nirvdrum: but even then it will be things like Enumerable moving to Ruby
anaeem1 has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian pushed 1 new commit to master: http://git.io/BcWKTA
<JRubyGithub>
jruby/master 427c786 Christian Meier: more build fix after jruby-openssl update
JRubyGithub has left #jruby [#jruby]
nateberkopec has quit [Quit: Leaving...]
<nirvdrum>
enebo: I commented on the commit. Thanks.
<nirvdrum>
enebo: chrisseaton has been working to pull in rubinius for at least stdlib and probably more of corelib. I suspect the things you can think more of as language atoms would still get Java treatment.
<nirvdrum>
Doing full error checking for some of these methods is insane.
yfeldblum has joined #jruby
<enebo>
yeah
erick has quit [Remote host closed the connection]
yfeldblum has quit [Ping timeout: 265 seconds]
capitalist has quit [Quit: Sleep quit]
<headius>
enebo: I'm kinda feeling vacationy so I'm going to do some benchmarking and see if I can figure out the last mile to match 1.7 JIT perf
<headius>
starting with simple things like method dispatch and numerics
<enebo>
headius: I am not in a good mood today…I am releasing angry
<enebo>
headius: not sure why either…I think I may need the holidays this week
<enebo>
headius: which is one thing I have probably never said before :)
<headius>
it's because untapped is being ddos'ed today, isn't it
<enebo>
headius: is it?
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] lucasallan pushed 2 new commits to master: http://git.io/p9yGFg
<JRubyGithub>
jruby/master cceec43 Lucas Allan Amorim: [Truffle] - Handles empty string on String#capitalize and String#capitalize!
<JRubyGithub>
jruby/master 2090571 Lucas Allan Amorim: Merge branch 'master' of github.com:jruby/jruby
JRubyGithub has left #jruby [#jruby]
<nirvdrum>
headius: Not to sound like a broken record, but any luck with that C1 crasher? That seems like a blocker.
<headius>
no :-(
<nirvdrum>
Especially now that people are using the --dev flag to get tiered compilation.
<nirvdrum>
I can check memory usage again now that enebo had some work in. I needed to bump permgen to 1GB just to run my specs as of a week ago.
tcrawley is now known as tcrawley-away
<enebo>
oh heh…and dirgra 0.2 is not in
<enebo>
I forgot to close and release it but it should be good now
<nirvdrum>
enebo: Let me know when you do. I'll test again.
<headius>
nirvdrum: I'm guessing I won't get any responses on it until after holidays
<enebo>
nirvdrum: You can update core/pom.xml and core/pom.rb to move dirgra from 0.1 to 0.2
<enebo>
nirvdrum: I did run the most common tests against it and it uses quite a bit less memory
<headius>
hmm
<headius>
33% slower for fib(37) and allocation profile looks pretty much the same
<headius>
something's not inlining or folding
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] lucasallan pushed 1 new commit to master: http://git.io/M5QoKQ
<JRubyGithub>
jruby/master e9444ff Lucas Allan Amorim: [Truffle] - Implements String#clear
JRubyGithub has left #jruby [#jruby]
<nirvdrum>
enebo: Those two files scare the hell out of me :-/
mkristian has quit [Read error: Connection reset by peer]
<nirvdrum>
And apparently the mere suggestion made mkristian die.
<enebo>
nirvdrum: It should regenerate all the poms using rmvn but I have never had it work and in this case I know the only pom.xml which should change so ...
<headius>
killing a couple builds to see that mkristian's commit goes green
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
nateberkopec has joined #jruby
mister_solo has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] lucasallan pushed 1 new commit to master: http://git.io/HyTaSw
<JRubyGithub>
jruby/master dbff750 Lucas Allan Amorim: [Truffle] - String#clear should preserve the string encoding.
JRubyGithub has left #jruby [#jruby]
Hobogrammer has joined #jruby
lucasallan has joined #jruby
elux has quit [Quit: Leaving...]
mister_solo has quit [Ping timeout: 240 seconds]
<headius>
enebo: looking at assembly comparson for 1.7 vs 9k
<headius>
obvious differences right away are that ThreadContext.getCurrentScope is getting run even for bodies without scopes, so that's at least two memory traversals plus boundscheck
<headius>
and calls with literal fixnums are using RubyFixnum, where indy in 1.7 would use long
JohnBat26 has quit [Ping timeout: 244 seconds]
<headius>
that was one-off opto logic in the other JIT of course
donV has quit [Quit: donV]
<headius>
you wouldn't think it would lead to much but there's instanceof RubyFixnum plus field access that aren't there in 1.7
<headius>
subbu: doesn't feel right for me to start putting one-off unboxing hacks in the JIT, eh?
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<enebo>
seems like we should be able to kill scope if it is not really being used
<headius>
that for sure
<headius>
I assume it lingers because it claims to have side effects
<headius>
and because instrs that consume it don't do so explicitly
<headius>
enebo: good news is that so far I'm not seeing anything allocation-wise that would explain JIT being a bit slower
<headius>
on indy anyway
triple_b has joined #jruby
iamjarvo has joined #jruby
<enebo>
headius: unboxing I envisioned entirely in compiler passes but I guess it is because IR should have the info to do it.
<enebo>
headius: but I also thought we would be able to do a series of JIT compilations based on profiled stats
<enebo>
headius: that seems like a much longer road to me now
<subbu>
headius, enebo do what makes sense for 9k release .. we can always rip out and fix things going forward. we just cannot get everything done perf wise for 9k .. unless you want to keep pushing it ahead.
<headius>
enebo: turning off pre-unboxed fixnum operations brings 1.7 nearly up to 9k times
<headius>
the scope access is probably the rest
<subbu>
but, i can help look at some things over the next week as well .. i am sure i'll need htings to do during the holidays that is not just socializing :)
yfeldblum has joined #jruby
<headius>
subbu: yeah I'm just sanity-checking
<headius>
I am ok shipping with slightly reduced perf if we know what it is and can iterate it back to full speed in dot releases
<enebo>
I guess I am wondering is there some level of opts which happen only at bytecode level vs handling them higher level?
<headius>
I just need to know
<headius>
hmm
yfeldblum has quit [Remote host closed the connection]
<headius>
enebo: well I see the role of the JIT compiler as just bridging the gap from IR to JVM bytecode + classes + methods
<headius>
ideally
<enebo>
headius: yeah me too
<subbu>
headius, enebo what i meant was: i am okay with 1-off hacks for now if it helps make forward progress. i don't want to be the bottleneck.
<headius>
so if we want to do method splitting, unboxing, specialization, that all happens well before JIT
<enebo>
headius: but the gap of boxed Objects vs primitives?
<headius>
subbu: if we can get rid of that scope access that would be a big help
<subbu>
what scope access again?
<enebo>
headius: I just killed method splitting code but it was pretty rotten
<headius>
I *may* be doing it unconditionally in JIT because it's not consistently alive in IR
<headius>
subbu: ThreadContext.getCurrentScope loaded into a temp
<headius>
early in method preamble
<enebo>
%current_scope = recv_scpoe?
<headius>
yeah
<subbu>
oh, why isn't it getting killed though?
<subbu>
ok, i can take a look, ruby code snippet?
e_dub has joined #jruby
subbu is now known as subbu|lunch
<headius>
subbu|lunch: any empty method...and I'm nearly certain I'm doing it unconditionally in JIT because some cases needed it and weren't leaving it in IR
<headius>
I will try to confirm
<enebo>
ok things are looking good
<enebo>
and Rails 4.2 fixed windows tzinfo data gem thing which is fantastic…
djellemah has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] lucasallan pushed 1 new commit to master: http://git.io/6af9vw
<JRubyGithub>
jruby/master c1f0e4c Lucas Allan Amorim: [Truffle] - Implements String#chr
JRubyGithub has left #jruby [#jruby]
djellemah has quit [Client Quit]
<headius>
subbu|lunch, enebo: JVMVisitor around L152
<enebo>
headius: why can’t you just depend on not pushing it if it is not suppplied (don’t have IDE open)
calavera has joined #jruby
<headius>
enebo: there were loads that did not preserve it in DCE
<enebo>
headius: oh meaning DCE was removing it wrongly?
<headius>
my fixme indicates that scopes which did not get call protocol had this issue (module/class bodies for example)
<headius>
I think so
<enebo>
headius: ah so this could be pretty significant
<enebo>
headius: perhaps not compared to unboxing on fib but more generally
<headius>
enebo: it's a portion for sure
<headius>
will mostly affect small method bodies called a lot
<headius>
yeah, so with this extra scope load removed in 9k and fast fixnum ops removed in 1.7, they are almost identical perf for fib
<enebo>
headius: red black is a lot of small methods as well
<headius>
yeah I'm trying it with the same tweaks now
kares has quit [Quit: Ex-Chat]
<enebo>
headius: I guess as a correctness bug and one which could uncover problems figuring out which methods fail would be nice
<enebo>
headius: the fact that it will help perf is a massive bonus
<headius>
yeah
<enebo>
I consider ACP being bug free an important deliverable for preview
<enebo>
well thought to be bug free anyways :)
<headius>
that's for sure
<headius>
but we don't use it on all scopes so I still have some one-off logic that really should go away
<headius>
ok, I can't remove the push logic altogether, but compiler specs pass if I do it only when explicitCallProtocol=false
<enebo>
I started switching BasicBlock to use primitive array since rails console about 30% of all ArrayLists are from there
<enebo>
It is an interesting transition since it exposes how thinking with primitive arrrays means doing more bulk operations
<enebo>
with array list it is like oh delete these n elements one at a time
etehtsea has quit [Quit: Computer has gone to sleep.]
<headius>
yeah
<headius>
enebo: with this change, making get scope conditional on !explicitCallProtocol, "gem install dicks" with threshold=0 compiles all methods except four and works proparly
<headius>
those four appear to be NPEs inside LVA in IR
<headius>
subbu|lunch: ^
<enebo>
headius: sweet
<headius>
I can't -X+C because we don't have a graceful failover for big method bodies yet
<enebo>
headius: but good enough to run benches right?
<headius>
yeah
<headius>
and compiler specs are 100%
<headius>
so I will push this...it's one less thing
<headius>
it's only like 5% on fib but it could affect e.g. simple accessors more
<enebo>
headius: I guess if you open an issue on this marked against pre one of us will try and see what those particular methods are doing
<headius>
it's nice to be at the point where we get to work on emitting *better* code rather than *working* code
<headius>
ok
<enebo>
run rbtree!!!! :)
<chrisseaton>
enebo: what's ACP?
<enebo>
chrisseaton: Add Call Protocol
<enebo>
chrisseaton: It is where we decide whether we are going to push a variable scope or just rely on temps
<headius>
chrisseaton: heap frame logic, mostly
<enebo>
only done for methods but some day for blocks as well (knock on metal desk)
<enebo>
headius: but I imagine red black will get a bit faster and from what I remember I think we run that interp’d faster in IR
<enebo>
than 1.7
<enebo>
probably because of scope removal (although I don’t know if we do now since I don’t remember which passes we are doing anymore :) )
donV has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] lucasallan pushed 1 new commit to master: http://git.io/wZOf0g
<JRubyGithub>
jruby/master 86cab8d Lucas Allan Amorim: [Truffle] - String#capitalize(!) should preserve the string encoding
JRubyGithub has left #jruby [#jruby]
<chrisseaton>
lucasallan: love these commits - are you aiming towards running something and need these methods, or just filling in the blanks?
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius opened issue #2345: NPE in IR's LiveVariableAnalysis when running JIT passes http://git.io/cjn8xQ
JRubyGithub has left #jruby [#jruby]
<headius>
subbu|lunch, enebo ^
<nirvdrum>
donV: Howdy!
<enebo>
headius: cool. Amazing it is only 4 methods too
<donV>
nirvdrum: Hi!
<nirvdrum>
donV: The rumor is you're the guy that knows why the load service checks for files ending in .jar.rb.
<lucasallan>
chrisseaton I wrote a bunch of ruby scripts and I'm trying to execute on jruby (truffle)
<donV>
nirvdrum: May be :)
<nirvdrum>
donV: Care to share with the rest of :-)
<nirvdrum>
I keep bugging headius, but he doesn't recall.
<donV>
nirvdrum: I’d love to. Just searching my memory.
<headius>
donV: I'm pretty sure it was you, but my memory is getting old too
<donV>
headius: I is definitely me :)
<donV>
So, searching for jar.rb should not be a special case.
<donV>
If you require <file>, we always check <file>.rb
<subbu|lunch>
headius, enebo so, summary is: that fixme is fixed, but, we have lva failures but that doesn't get in the way of JIT?
<nirvdrum>
That's what I was thinking. Unless the .jar loader appears before the general file loader. But I don't think that's the case.
<donV>
The Ruboto project uses this to replace JARs with corresponding dummy jar.rb files.
<headius>
subbu|lunch: correct
<subbu|lunch>
k
<headius>
subbu|lunch: or at least I can't find any cases that fail with the conditional reinstated
<headius>
the LVA thing is not related, I just noticed it verifying this change
<subbu|lunch>
ya, i would have been surprised if there had any .. i think that check/fixme was a carryover from when we were trying interp and jit to co-operate with each other.
<nirvdrum>
donV: Well, then it's possible the reason you added it is because if you require 'foo', the loader will search for foo.jar.
<donV>
nirvdrum: We package the contents of the jars into the Android package, and insert the jar.rb files to satisfy any “require <jar>” statements.
<donV>
We need to satisfy “require ‘some.jar’” statements after we repackage the jar class files.
subbu|lunch is now known as subbu
<donV>
We do that by adding a some.jar.rb file. It should actually not be special case. I am repeating myself due to lag :)
<subbu>
headius, so, does that fix get perf back up somewhat?
<donV>
nirvdrum: Do you get the use case?
<subbu>
time to head out to a coffee shop ...
<nirvdrum>
donV: Okay. It looks like "require 'foo'" will match 'foo.jar' before 'foo.jar.rb' in the current load service. So I'm not sure if it ever did what you might have wanted :-)
<nirvdrum>
But if it can be removed, that's fantastic news.
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] lucasallan pushed 1 new commit to master: http://git.io/TIstRw
<JRubyGithub>
jruby/master ef0e585 Lucas Allan Amorim: [Truffle] - String#upcase(!) should preserve the string encoding.
JRubyGithub has left #jruby [#jruby]
<headius>
subbu: 5% on fib
<donV>
nirvdrum: the use case is not “require ‘foo’” but “require ‘foo.jar’”
<headius>
it's a few memory traversals and branches at asm level, so there you go
<headius>
it speeds it up by the cost of a few memory traversals and branches :-)
<subbu>
headius, ok. so the rest is unboxing?
<nirvdrum>
donV: Okay. I'm just saying if you execute arbitrary user code, they could be trying to load a jar that way.
<headius>
yeah appears to be...old JIT compiled a + 1 as a specialized call site that used (long)1 rather than an object
<nirvdrum>
But if you're sure it won't break anything, removing it will cut down on filesystem access significantly during boot-up.
<headius>
for a number of operations
<enebo>
headius: RED BLACK TREEEEEEE :)
<headius>
those operations now have to instanceof, cast, and access field
<headius>
enebo: I'll check...it didn't get back down to 1.7 - fastops
<nirvdrum>
enebo: You guys seem to like that benchmark a lot. Not being terribly familiar with it, what makes it so good?
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius>
I'll see if it sped up at all
<subbu>
but, i thought we had an specialized call for that scenario?
<subbu>
enebo, ^
<subbu>
a+1
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to master: http://git.io/3fs6iA
<JRubyGithub>
jruby/master d6810e9 Charles Oliver Nutter: This check appears to be enough to know when to load scope now.
JRubyGithub has left #jruby [#jruby]
<subbu>
nirvdrum, i think it is just that is better than fib :)
<enebo>
nirvdrum: more object + method call heavy and not particularly heavy on math. It is not great though
<headius>
subbu: I don't believe so
<donV>
nirvdrum: Not sure we are on the same page, yet, but I think there are tests that cover it.
<nirvdrum>
headius, enebo: According to donV, we can remove the .jar.rb case in LoadService :-D
<donV>
I think I added them.
<enebo>
subbu: we do on specializeForInterpretation
<headius>
nirvdrum: I like fib because it measures simple method dispatch and fixnum operations... and red/black because it's a pure-Ruby data structure bench
<donV>
nirvdrum,headius: not sure that is what I said.
<enebo>
subbu: if we gave JIT those instrs it could trivially unbox simple math literal ops
<headius>
donV, nirvdrum: Imma let you guys finish
<headius>
you let me know after if we can remove it
<donV>
nirvdrum: Is there a case where “require ‘foo’” loads ‘foo.jar.rb’ ?
<nirvdrum>
donV: All I'm saying is a user can require 'foo' and if there is a foo.jar, it will get loaded. If you're looking to override that with a foo.jar.rb, the user would need to require 'foo.jar', not just require'foo'.
<subbu>
enebo, so why not give it those?
<nirvdrum>
donV: Yes.
<enebo>
subbu: we can
<headius>
perhaps the problem was that someone required foo.jar and expected foo.jar.rb to load rather than foo.jar
<donV>
nirvdrum: OK, so then I _think_ that case can be removed.
pchalupa has quit [Quit: Leaving]
<nirvdrum>
donV: When you "require 'foo'", the search currently is foo.jar -> foo.class -> foo.jar -> foo.jar.rb.
<enebo>
subbu: I guess my only question (and of course we can change this) is that interp maybe may stop targetting instrs directly
<enebo>
subbu: OTOH we are still using them
<nirvdrum>
And that chain gets traversed a lot during bootup.
<enebo>
subbu: fwiw. I think we could just generate those during IRBuild time
<donV>
nirvdrum: Yes, I think we can remove the foo => foo.jar.rb case.
<enebo>
subbu: we really save nothing and they appear to be ordinary call instrs from analysis standpoint
<nirvdrum>
donV: Does that mean I can get my ":-D" back?
<donV>
:smile: ?
<subbu>
headius, enebo, ok .. i think till we have a better soln. i think it makes sense to use them in both interp + jit then.
<enebo>
subbu: perhaps the factory for creating callinstrs (we do have one) should just include these
<enebo>
headius: not sure if you just tracked that conversation or not
<mpapis>
enebo, when new version?
<headius>
yeah I just caught up
<mpapis>
or headius ;)
<nirvdrum>
headius: It sounds like we can remove it.
<headius>
I'd be happy to add JIT for the unboxed operations
<enebo>
mpapis: oh very very soon
<enebo>
:|
<headius>
nirvdrum: ok
<nirvdrum>
And since you pulled out the .class case unless using AOT, this will cut FS access down 50% at bootup over 1.7.x.
<nirvdrum>
I think it actually gets us on par with MRI.
<enebo>
headius: so all we need to do is just add in factory logic for classes like: OneFixnumArgNoBlockCallInstr
<nirvdrum>
MRI searches foo.rb and foo.so, IIRC.
mister_solo has joined #jruby
* subbu
--> coffee shop .. back in 15
<enebo>
then JIT can look at specialization and key off that for specialized generation
<headius>
enebo: those are being used by interp right now?
<enebo>
headius: they are yes
<headius>
can I just run the same pass prepareForInterp uses?
<enebo>
well it does quite use a pass now
<enebo>
just a sec…
<headius>
oh I see it
<headius>
if (newInstr instanceof Specializeable) {
<headius>
I could do the same thing in JIT and see what magic falls out
<enebo>
headius: ok quick hack for you which may not even be the wrong solution (although it is )
<headius>
it does this when cloning for IC
<headius>
I understand completely ;-)
<enebo>
headius: just change CallInstr.create so that after the constructors in those methods you just tack on .specliazeForInterpretation()
<enebo>
new CallInstr(…).speciializeForInterpetation()
<nirvdrum>
headius: I suppose if this isn't needed, we could backport to 1.7.x for a little startup boost. But dunno if that's too risky at this juncture.
<enebo>
ok hopefully all is up and well
<enebo>
no doubt nirvdrum will help find anything wrong
<enebo>
subbu: ah yeah so it was just be mucking with order...sorry
<subbu>
ya, np .. simple fix.
<enebo>
subbu: you can see the other unfniished glaring issue here too. We have the tiniest race
<headius>
nirvdrum: yeah, but I'm not sure int gains us much other than avoiding overflow check
<enebo>
subbu: scope.cfg() can mutate since we are not examinging the one on IC
<subbu>
oh, i didn't look beyond that.
<enebo>
subbu: but it is unlikely to hit us debugging
<enebo>
subbu: in fact insanely unlikely
<headius>
I'm adding the same fixnum optimization for floats
<subbu>
but, aren't IC and scope both pointing to the same cfg?
<headius>
with that the only remaining float/fixnum unboxing optimization missing from 1.7 is for boolean conditions
<enebo>
subbu: well they do but they shouldn’t
<headius>
I specialized stuff like "if a < 2" to use long for 2 and boolean for return value
<headius>
rather than RubyFixnum and RubyBoolean
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] lucasallan pushed 1 new commit to master: http://git.io/iKbGCQ
<JRubyGithub>
jruby/master 827f20a Lucas Allan Amorim: [Truffle] - String#downcase! returning nil if no changes were made.
JRubyGithub has left #jruby [#jruby]
<enebo>
subbu: the instrs all are specialized in interp list but not in cfg
bbrowning is now known as bbrowning_away
<enebo>
subbu: since headius can make use of specialization I can perhaps change instrs to generate specialized instrs right away during build
<enebo>
subbu: then the cfg should be the same
<enebo>
subbu: other than cloned versions
<subbu>
enebo, ah .. instr output could differ you mean, not the cfg itself.
<enebo>
subbu: and I would like to make ipc/rpc not live on instrs so we can almost entirely remove the cloning
finch has joined #jruby
<subbu>
sounds reasonable.
<enebo>
subbu: yeah sorry cfg itself is the same until compler passes mangle it
<finch>
rtyler: \o
<enebo>
subbu: but for debugging output you look at instrs in context of cfg and those will look different
<nirvdrum>
headius: I'd imagine it matters on 32-bit platforms. I'm not sure what the opcode cost is in x64 though.
<rtyler>
finch: I don't know what most people do with their JRuby hacking to work with Java libraries without killing themselves
<rtyler>
finch: I know a lot of people that use RubyMine but I'm not sure if that helps at all
<finch>
alcoholism?
<headius>
nirvdrum: yeah, it starts to get down to whether CPU prefers 32 or 64 bit
<finch>
I'm a little concerned about IDEs in general because I'm fighting with RSI right now
<headius>
I think that kind of opto is currently lost in other noise
<headius>
but we'll get there once we start aggressively specializing
<rtyler>
finch: have you stumbled across eclim yet?
<finch>
I was trying out Intellij for some basic stuff but it felt incredibly mouse driven, which is my bane
<finch>
rtyler: I used it a while ago and I was pretty impressed by it, actually. A lot of people have a negative opinion of eclipse though and people were pushing me to try out intellij
<finch>
I may give it another pass
<rtyler>
is your normal editor vim?
<finch>
The biggest thing for me by far is how to effectively navigate project documentation
<finch>
does the pope wear a funny hat? ;)
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 6 new commits to master: http://git.io/ljvNrQ
<JRubyGithub>
jruby/master c30c750 Chris Seaton: [Truffle] Remove some duplicated code in the body translator.
<JRubyGithub>
jruby/master 173a414 Chris Seaton: [Truffle] Preserve an args push through attribute assignment transformations.
<rtyler>
headius: writing up a post about lookout's jruby work as of late, I can't think of atitle that doesn't come across as pmpous
<JRubyGithub>
jruby/master c15bdfa Chris Seaton: [Truffle] Lots of method specs passing.
<finch>
rtyler: so for that matter, is there a particularly good way of navigating javadoc at all?
<subbu>
ok .. case/when opt. couldn't be that important though?
<rtyler>
finch: vimperator? :P
<rtyler>
(no)
<nirvdrum>
headius: Let me know what you end up doing with case/when. I've been thinking about ideas around there in general.
<subbu>
i mean .. i am sure there is someone out there who will benefit from it, but probably not a common use case.
<enebo>
headius: ah I was saying to you on IM you did not need to add to Interpreter
<headius>
nirvdrum: 1.7 examined all whens, and if they were fixnum, symbol, or string it turned them into O(1) branch
<headius>
enebo: I did anyway, it was trivial
yfeldblum has joined #jruby
<headius>
and it blew up because instr had a new operand type but was still using call_1f
<enebo>
headius: well it becomes a potential code-size issue but it is probably fin
<finch>
rtyler: the extra mega frustrating part of this is that I can't find a copy of the jgit javadoc online. I suppose that I should take your point and just generate the docs and host them locally
<nirvdrum>
subbu: psych is a mess of case/when around regexp. I'd like to see if I could do an FSM for it with ragel or something. But as it stands, each clause is evaluated linearly. And depending on the token distribution in your YAML, you get wildly different performance profiles as a result.
<nirvdrum>
subbu: I suspect a lot of naive web routing engines could benefit as well.
<headius>
enebo: mandelbrot may be faster in interp as a result too
<enebo>
headius: it can just be a operation of CALL,
<headius>
but yeah, I don't expect we are going to do this for more instrs
<enebo>
headius: yeah that is probably true
<finch>
rtyler: jruby itself has been pretty good, aside from some fun with open3. The real issue is that I'm not familiar with the Java ecosystem and it makes me angsty
<headius>
float and fixnum had special call paths so they're ok
<nirvdrum>
headius: Interesting. Can you point me to where that occurs?
<subbu>
nirvdrum, i see. interesting.
<enebo>
I am curious about interp mandlebrot speedup
<cprice>
headius: congrats & thx for 1.7.18! :) the crypt stuff especially
<headius>
nirvdrum: ASTCompiler.compileCase and on down
<rtyler>
finch: I know the feeling, you can relatively easily generate the javadocs from a sources jar fwiw
<rtyler>
I've been working on agradle plugin to make that easier
<headius>
specifically there's methods called "getHomogeneousSwitchType" etc
<nirvdrum>
Thanks.
<finch>
gimmie a yell when you've done that? That would be awesome to have right now
<rtyler>
finch: do you have an open repo I could look at and see if I can help?
<cprice>
we've had some requests for trying to get pry-debugger and pry-stack_explorer working, so have been hacking around with that on and off while on PTO
<headius>
this would easily fit into IR building....like after we generate a case/when we tell it to specialize and it either stays the same or turns into one value eval plus O(1) switch logic
<rtyler>
cprice: sounds promising!
<headius>
I forget whether I have this opto on by default in 1.7 though
<nirvdrum>
headius: Yeah. My thinking is a lot of case/when constructs are structured like pattern matching and optimizations from that realm could be borrowed.
<finch>
rtyler: I really just have a disorganized pile of code that randomly hooks into jgit, I've been looking into how I would do things like perform a fetch on an existing git repo and jgit has quite a few steps to do that
<headius>
enebo: I still have a fix outstanding for read(0) blockage...ok to land on 1.7 now?
<headius>
I believe that's a .19 issue
<enebo>
headius: yeah that is already marked against 19
<nirvdrum>
regexp is trickier because of captures and the $n variables. But I think it could be managed.
<enebo>
headius: you can re-revert rg update if you want too :)
<finch>
WRT gradle I'm a little concerned about bringing that in as a dependency because of the impact it'll have on the people that have to package my code; I don't want to add a ton of additional things they need to do to get things working
subbu has quit [Remote host closed the connection]
<headius>
chrisseaton: I know a few folks around the world using jruby for bioinfo
<headius>
mostly because it's a lot faster than MRI for processing large datasets
<rtyler>
finch: because of gradle all you technically need to start working with the project is the JDK
<rtyler>
finch: otherwise you need to incorporate bundler, jbundler and all sorts of other mess
<rtyler>
rmvn and jruby-gradle are probably the best ways to solve this right now
<cprice>
finch: you could probably use gradle stuff in your dev env w/o affecting RE
<finch>
cprice: probably, yeah
<rtyler>
oh yeah, entirely
<rtyler>
jruby-gradle-jar-plugin will produce a fully self-contained executable jar
tenderlove has joined #jruby
<finch>
I'm just a little overwhelmed by the overhead of getting started with a new project and all the tools I need to drag in
subbu has joined #jruby
<rtyler>
understandably
codefinger has quit [Quit: Leaving...]
ravster has joined #jruby
<rtyler>
finch: https://github.com/rtyler/blick is a demo project (unfortunately) which uses jruby-gradle to create a slef-contained jar file
<cprice>
hey finch, curious, which do you use more out of pry-debugger and pry-stack_explorer
<finch>
rtyler: perfect, thanks?
<finch>
cprice: it depends on how badly I've fucked up :)
<rtyler>
first one then the other :P
<cprice>
:)
<finch>
cprice: for basic poking around I just use pry-debugger; when I have royally made a mess somewhere and nothing is real anymore then that's when I need to start wandering about the stack. why do you ask?
<cprice>
trying to see if it's possible to get either of them working with Puppet Server (so, i.e., JRuby)
<cprice>
trying to pick one to focus on
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to jruby-1_7: http://git.io/VMLYwA
<JRubyGithub>
jruby/jruby-1_7 287cb36 Charles Oliver Nutter: Never block for read(0), return blank string. Fixes #1637.
JRubyGithub has left #jruby [#jruby]
<cprice>
stack explorer seems easier :)
<finch>
cprice: have you looked at byebug?
<finch>
and pry-byebug as well
tenderlove has quit [Ping timeout: 245 seconds]
<finch>
oh. shoot. I think it works pretty heavily at the C layer
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to jruby-1_7: http://git.io/BbnvqA
<JRubyGithub>
jruby/jruby-1_7 4f21b1e Charles Oliver Nutter: Merge branch 'test-fix-2333' into jruby-1_7
JRubyGithub has left #jruby [#jruby]
<finch>
cprice: at one point I had to debug something on ruby 1.8 which pry-debugger doesn't work with, so I edited each function I needed to step into with `edit`, added a new binding.pry`, and continued.
<finch>
bam. breakpoint setting on ruby 1.8 with pry.
<rtyler>
ruby 1.8?
* rtyler
vomits
<finch>
I have many reasons to drink. That is one of them.
subbu has quit [Ping timeout: 272 seconds]
<finch>
cprice: TBH, pry-stack_explorer loses a great deal of value without pry-debugger
subbu_ has joined #jruby
<cprice>
agree
subbu_ is now known as subbu
<finch>
Also, I want to make your life hard so if stack_explorer is easier then I need to throw road blocks in your way.
<cprice>
so what's the difference between pry-byebug and pry-debugger?
<cprice>
and why does ruby have So Many Things
<finch>
cprice: byebug is a debugger written for ruby 2+, I don't know if ruby-debugger works on 2.0+
<cprice>
:(
<cprice>
maybe I should just be looking into writing a new jruby-compatible stack navigator instead of trying to get one of those to work if they are version-specific
<rtyler>
you know, the plane isn't a great place to need to resolve new maven dependencies
<finch>
cprice: so I think we're in a split brain mode, since we would need different debuggers depending on the ruby version. since 2.x support is coming in jruby 9000 we can't invest a lot in that version till release
<finch>
cprice: pry-stack_explorer might be generic; I just know that byebug implements that
<cprice>
rtyler: I do know! :) been there
<rtyler>
there's kind of ruby 2.x support in 1.7
<rtyler>
the extend of which you'd have to ask these chap sabout
<finch>
nope, pry-stack_explorer is 1.9.x. Who knows if it'll work on 2.x?
<cprice>
i think pry-stack_explorer is more generic than any of the debugger libs. and i'd guess that any debugging lib that works with jruby 1.7 is fairly likely to work with jruby9000 regardless of the mri versions it is targeted at
<cprice>
and ruby-debug already works with jruby
<cprice>
so maybe there's a way to wire that into pry
<finch>
well, byebug looks like it hooks deeply into the C layer with gets us nothing in jruby
<cprice>
yeah, that
<cprice>
i'm guessing same for pry-debugger
<rtyler>
this lady dropped her broach while going to the bathroom
<cprice>
but taking the ruby-debug jruby compat stuff and building a plugin for pry, maybe :)
<rtyler>
it's this dope red cardinal, I'm going to take a picture for posterity
<rtyler>
seems fitting given what I'm hacking
<cprice>
rtyler: you can prolly get on ebay on the plane more readily than resolving your maven deps
<rtyler>
nah bro, maven resolved
<rtyler>
hooray internet
<rtyler>
cprice: will you be joining us at fosdem too?
<finch>
cprice: yeah, I think ruby-debug might be a better investment since it has jruby support. from there it should be possible to write pry bindings
Felystirra has joined #jruby
<cprice>
rtyler: not this year, unfortunately. will be in europe shortly thereafter and it seemed crazy to go back and forth twice in such a short span. there is a guy from my team going to fosdem though.
tenderlove has joined #jruby
<rtyler>
cprice: you weenies should have submitted a talk to the ruby devroom
<cprice>
rtyler: i know, we suck
<cprice>
it was just bad timing
<rtyler>
pretty much the worst
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius created test-fix-2221 (+1 new commit): http://git.io/txq5Rw
<JRubyGithub>
jruby/test-fix-2221 a9fa229 Charles Oliver Nutter: Preserve order in ThreadGroup#list....
JRubyGithub has left #jruby [#jruby]
<cprice>
we were in the middle of a huge terrifying release when I saw the request for talks
<cprice>
i'd totally submit one today :)
havenwood has quit [Remote host closed the connection]
havenwood has joined #jruby
<rtyler>
VERBOTEN!
erick has joined #jruby
* cprice
is using vim to hack on pry-stack_explorer right now, despite his trolling
<finch>
cprice: before you used intellij, what editor did you use most?
<rtyler>
BlueJ I bet
mitchellhenke has quit [Quit: Computer has gone to sleep.]
<cprice>
ha
<finch>
ZING
<cprice>
i went vim -> emacs -> eclipse -> IntelliJ
<finch>
emacs for lithp?
<cprice>
nah perl and C
<rtyler>
enebo: do you guys have protips written down anywhere for hacking on java nad ruby at the same time
<finch>
cprice: do you feel that eclipse/intellij are as good as manipulating text as vim/emacs?
erick has quit [Ping timeout: 255 seconds]
<enebo>
rtyler: not per se no. I did start to prototype something which would generate docs called noridoc but it is pretty dead currently
havenwood has quit [Remote host closed the connection]
zorak8 has quit [Ping timeout: 264 seconds]
cprice has quit [Ping timeout: 258 seconds]
byteit101 has joined #jruby
byteit101 is now known as byteit101__
Kavinder has joined #jruby
Felystirra has quit []
<Kavinder>
Hi,is the containsAll method available to a standard Array instance in jruby? I'm working in a codebase that calls it and I keep getting an undefinedmethod error