pjammer has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
mister_solo has quit [Ping timeout: 264 seconds]
bbrowning_away has quit [Quit: Leaving]
Xzyx987X has quit [Ping timeout: 248 seconds]
KevinCorcoran has quit [Remote host closed the connection]
x1337807x has joined #jruby
yfeldblu_ has quit [Remote host closed the connection]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 3 new commits to master: http://git.io/vJIj3
<JRubyGithub>
jruby/master 39fbeaf Chris Seaton: [Truffle] ToIntNode was never guaranteed to return an int - but provide that utility for people using it like that.
<JRubyGithub>
jruby/master 85cbf9c Chris Seaton: [Truffle] Fix how ToIntNode handles ints and longs.
<JRubyGithub>
jruby/master e478127 Chris Seaton: [Truffle] Give MRI tests more heap and tag two failing tests.
<adironduck>
I think I may have encountered a bug in JRuby 1.7.19 on Windows, but I’m not sure. It’s connected to Windows UNC network paths - they make File.expand_path behave a bit unexpectedly. I wrote some tests: https://gist.github.com/jesjos/42abb409295c4614d200
<adironduck>
I do not usually work in Windows environments, so this may be due to a lack of domain knowledge. So I would appreciate input into whether this is an actual bug
lance|afk is now known as lanceball
benlovell has quit [Ping timeout: 265 seconds]
adironduck has quit [Ping timeout: 255 seconds]
nirvdrum has joined #jruby
adironduck has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
bjfish2 has joined #jruby
<cpuguy83>
headius: omg you got proprietary code submitted?
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 1 new commit to master: http://git.io/vJqnD
<JRubyGithub>
jruby/master a320453 Chris Seaton: [Truffle] Committed with debug option on by mistake.
JRubyGithub has left #jruby [#jruby]
adironduck has quit [Ping timeout: 264 seconds]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 1 new commit to master: http://git.io/vJqCw
<JRubyGithub>
jruby/master 8adab0c Chris Seaton: [Truffle] Fix Graal version in bundle builder.
JRubyGithub has left #jruby [#jruby]
gazay has quit [Quit: gazay]
<ponga>
chrisseaton thank you
<ponga>
i will retry
pjammer has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<chrisseaton>
ponga: hang on - the new nightly hasn't been built or uploaded yet
<ponga>
oh
<ponga>
ok
tcrawley-away is now known as tcrawley
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 2 new commits to master: http://git.io/vJqEY
<JRubyGithub>
jruby/master 99feebe Chris Seaton: [Truffle] Give RubyBasicObject a helpful toString for debugging.
<JRubyGithub>
jruby/master 9c67c8c Chris Seaton: [Truffle] If there is a fatal error, just transfer - don't profile and notDesigned.
JRubyGithub has left #jruby [#jruby]
benlovell has joined #jruby
<headius>
cpuguy83: yes...a committer took code from OpenJDK and changed docs and types (char[] to byte[]) and committed it
<headius>
we didn't realize until some years later when IBM lawyers refused to allow our project to be used in a product
deobalds has quit [Quit: Computer has gone to sleep.]
<cpuguy83>
ugh
<chrisseaton>
headius: how did the lawyers find it? Did they have a tool?
<headius>
this is a big reason why I think open commit bit is very risky
<headius>
chrisseaton: they never divulge their secrets
<chrisseaton>
are you happy with the way we're attributing Rubinius? We've instead their licence verbatim into every file we're using from them, even though they didn't have it there themselves, and if we copy some C++ and translate into Java we again use the full license in that file
<chrisseaton>
inserted their licence, not "instead"
benlovell has quit [Ping timeout: 264 seconds]
<chrisseaton>
ponga: can you try again please?
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 1 new commit to truffle-head: http://git.io/vJq21
<JRubyGithub>
jruby/truffle-head 979debc Chris Seaton: [Truffle] Update to Truffle 0.8-SNAPSHOT
JRubyGithub has left #jruby [#jruby]
<headius>
chrisseaton: yeah that's fine...it's three-clause BSD so it's still compatible with our EPL
<headius>
if it's not already there, COPYING should note where the BSD sources are
<chrisseaton>
ponga: quite a few of our benchmarks are broken after the version upgrade, but if you're just tinkering that build should be fine for most things
<ponga>
chrisseaton: ok im fine
<ponga>
and thanks for hardwork keeping Jruby on run
pjammer has joined #jruby
pierreatkillbill has joined #jruby
<headius>
chrisseaton: I thought of a practical use for SVM
<chrisseaton>
headius: yeah?
<headius>
not that standalone runtimes isn't practical, but it's less practical when you can't use Java stuff
<headius>
Android!
<headius>
SVM + appropriate hooks back into Android APIs
<chrisseaton>
it should run Java at some point in the future - just via a Truffle interpreter for Java
<headius>
small apps, fast, precompiled, all you need is the integration point
<chrisseaton>
or an Truffle interpreter for Java bytecode
<headius>
right, but this wouldn't necessarily need much or any Java
<headius>
it would be similar to the RubyMotion approach
<headius>
and those integration points with Android could be shared across many Truffle runtimes, so you get the same SVM integration in Ruby, Smalltalk, Python
<headius>
chrisseaton: that would be quite acceptable...but I am surprised, I thought that SVM did static analysis on dynlangs to avoid the interpret+JIT delay
mje113__ has joined #jruby
<headius>
I suppose with the interpreter AOT compiled there's not as much impact running interpreted for a bit
<headius>
lopex: I wouldn't expect anything there to be broken, no
<chrisseaton>
It achieves the same thing (less delay) but having a lexer, parser, intepreter and JIT, and the entire of your runtime support code, already complied to native and ready to go
<headius>
chrisseaton: right...I wonder what an SVM build of JRuby would look like
<lopex>
headius: and threadldocals ?
<headius>
chrisseaton: we've dreamed of being able to AOT compile JRuby itself...it's 99% of our startup problem
<chrisseaton>
headius: plus all your classes and all the native code just mmaped into memory in one go - very unlike Java clases
pjammer has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<lopex>
headius: this one will be quite hard to narrow
<lopex>
works ok on 1.7.19
<headius>
lopex: threadlocals could indicate a problem with fibers (nobody knows how threadlocals work with fibers) but that shouldn't really differ with 1.7
<headius>
what happens?
pjammer has joined #jruby
<lopex>
well, standard []' for nil called
<lopex>
need to backtrack through the guts of sequel
<JRubyGithub>
[jruby] chrisseaton pushed 4 new commits to master: http://git.io/vJqhH
<JRubyGithub>
jruby/master cbf7dde Chris Seaton: [Truffle] jt poms command.
<JRubyGithub>
jruby/master f34b913 Chris Seaton: [Truffle] CoreMethodNode -> CoreMethodArrayArgumentsNode
<JRubyGithub>
jruby/master c1920c1 Chris Seaton: [Truffle] Add a CoreMethodNode class and get all @CoreMethods to extend it.
JRubyGithub has left #jruby [#jruby]
<headius>
chrisseaton: have you given any thought to volatility in jruby+truffle?
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton closed issue #2475: Truffle: Understand and reduce impact of Truffle on the distribution size http://git.io/bahFGQ
JRubyGithub has left #jruby [#jruby]
<chrisseaton>
headius: concurrency is an 'open research question'
<headius>
for truffle in general or just for jruby+truffle?
<chrisseaton>
JRuby mostly - but it's easier for JS as the model is so much simpler
<headius>
sure, it's easier when there's no concurrency model for a language :-)
<chrisseaton>
The problem of AST rewriting in general is solved - it's all the rest of our runtime stuff
<headius>
that's good...figured that one wouldn't be too hard
colinsurprenant has joined #jruby
<headius>
at least truffle doesn't do like pypy and try to rewrite *running* assembly when it reoptimizes
<headius>
they don't have a prayer of getting concurrency with that model
<chrisseaton>
Benoit will start to look at parallelism in more depth over the next few months - he and I have a first paper under submission somewhat related to the concurrency question
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] k77ch7 opened issue #2896: Symbol#inspect differs from MRI Ruby http://git.io/vJmeF
JRubyGithub has left #jruby [#jruby]
<chrisseaton>
headius: the more you read of their STM papers the most crazy the model seems to me - things like a fixed number of threads at compile time
<ponga>
chrisseaton: adding '--verify-downloads 2' at the end lets me bypass, but solving it entirely will be happy
KevinCorcoran has joined #jruby
<headius>
chrisseaton: I know...I wonder if there's genius in it I'm not seeing, because I can't see it ever working
<headius>
seems like implementing safepoints to branch back to interpreter would be *less* work
<headius>
and they certainly could do it...they have all the frame data in hand
<chrisseaton>
headius: well I'm glad they're working on it - STM is now quite unfashionable in academia so there aren't many people any more
<headius>
it will see a resurgence with hardware read barriers becoming commonplace now
<headius>
haswell I think?
<headius>
yeah haswell
KevinCorcoran has quit [Ping timeout: 250 seconds]
<nirvdrum>
Haswell's TSX implementation is broken, alas :-(
mrmargol_ has joined #jruby
iamjarvo has joined #jruby
iamjarvo has quit [Max SendQ exceeded]
iamjarvo has joined #jruby
havenwood has joined #jruby
mrmargolis has quit [Ping timeout: 244 seconds]
skade has joined #jruby
<chrisseaton>
and the fact that nobody seems to be bothered that it's broken makes me think nobody was using it or wanted to use it
<headius>
is it fixed in subsequent generations?
arturaz has quit [Ping timeout: 250 seconds]
<headius>
maybe they're not available yet... broadwell, skylake
<chrisseaton>
no, it's just disabled
<headius>
yeah reading that now
<chrisseaton>
It was never going to be as great as people thought - it's multiword CAS and I think it should be used like that
<nirvdrum>
Broadwell was just miniaturization, so it had the same problem.
<ponga>
fact it, its Haskell
<chrisseaton>
So don't use it as an HTM - use it to implement a better STM
<ponga>
*face it
<nirvdrum>
ponga: *Haswell. The name for one generation of Intel chips.
<chrisseaton>
But confusingly, Haskell popularised STM
<nirvdrum>
chrisseaton: I think there was some experimental Linux kernel work taking advantage of TSX that got derailed.
<headius>
chrisseaton: I think haskell would have to be popular for that to be true :-) I'd say Clojure did more to make STM a household word than any language
<headius>
ironically clojure code almost never uses it
<chrisseaton>
headius: yeah... I meant amongst the academic community really - never seen any research on Clojure
<headius>
ahh sure
enebo has joined #jruby
<headius>
uint8_t* p = reinterpret_cast<uint8_t*>(const_cast<char*>(str.c_str()));
<headius>
jesus, C++ should be considered a hate crime
<headius>
enebo: howdy do
<headius>
pre2 seems to be received well so far
<nirvdrum>
Just keep casting until you get what you want.
fkchang has joined #jruby
<fkchang>
anyone using jruby 9000 pre2 on heroku? Can't get heroku to recognize ruby 2.2.2 in the gemfile. Apparently 2.2.0 IS supported
<enebo>
headius: yeah so far so good but we will not get full feedback until we see travis update
<ponga>
wow jruby+graal is damn fast
<headius>
fkchang: hmm that's odd, I'm not sure how they validate that
benlovell has joined #jruby
<headius>
RUBY_VERSION for pre2 should definitely be 2.2.2
<headius>
ponga: what are you testing?
<ponga>
headius: just my stupid code of array.push(array.shift)
<ponga>
in two ways
<headius>
enebo: I saw your comments about gems going green
<headius>
ponga: ahh, I wonder if that would be much different under normal JRuby if it's all array accesses
<headius>
do you have a bench I could try?
<fkchang>
looks like Heroku supports MRI 2.2.2, from the error msg, I'm guessing they have a dedicated archive they unpack. i.e. I specify this in the Gemfile -ruby '2.2.2', engine: 'jruby', engine_version: '9.0.0.0.pre2' and I get this error
<ponga>
headius: i think i tried with normal Jruby and Graal was slightly faster
<ponga>
headius: yes i can
<ponga>
wait
<headius>
ponga: that's about what I'd expect for something data-structure intensive
<headius>
chrisseaton: you and your optimize-everything-away benchmarks :-P
<ponga>
my code is not optimized
<chrisseaton>
ponga: that exercises features which make Ruby Ruby - like method missing, send etc
<fkchang>
headius: related, I had a SSL cert issue w/Pivotal's new API cert w/JRuby 1.7.* upgrading to JRuby 9K solved that, but now I can't deploy to heroku
<ponga>
headius: the A method actually is my first attempt to do push(shift) when i didn't know of push(shift) way of doing it
<ponga>
and someone told me "you can push(shift)"
<ponga>
and i made two benches
<ponga>
;p
<headius>
fkchang: hmm ok...well for heroku stuff talk to @codefinger, or file JRuby bugs if it looks like it's our problem
<headius>
codefinger wrote the deploying JRuby book, worked on Java support for Heroku, and is now in charge of JRuby support
reaver has joined #jruby
<headius>
ponga: you might want to look at benchmark/ips to get more accurate results; bm and bmbm don't really do enough warmup and real time is a poor measure for many benchmarks
<headius>
and both JRuby and JRuby+Truffle will improve over time of course
<fkchang>
headius: ok, I'll try @codefinger, what's the forward plan for 1.7.*? Anyone else who is hitting the Pivotal API from Jruby 1.7.* will hit the same issue as me
<ponga>
headius: so time.now time.now-start is always better?
<chrisseaton>
ponga: I recommend a simple loop like in the gist above, and then sit there and watch the numbers come through - you can't automate away stats entirely - you need to observe
<enebo>
codefinger I think also supports all Java envs at Heroku
<headius>
fkchang: 1.7 will be supported until end of year at least, so we'd like to know
<headius>
know the problem
<fkchang>
I'll submit an issue, I have a jruby script that can show the issue
<reaver>
Hay guys, im pretty intereset in jruby (well I'm new to ruby and stuff) but I can't really find something about the performance of jruby compared to normal ruby and other languages. Can you help me a bit?
<headius>
ponga: the method of timing doesn't really matter...real time to run a bench is not accurate if it's a really small piece of work
<headius>
ponga: as long as jruby is the fastest production Ruby impl and jruby+truffle the fastest overall, I'm reasonably happy :-)
<ponga>
i am, too
<headius>
reaver: JRuby should be the fastest Ruby...when it isn't, we want to know about it so we can fix it
<headius>
compared to other languages, it depends on the work load...data-structure heavy code can approach Java perf, numeric code or code with lots of closures can be 10-20x slower
baroquebobcat has joined #jruby
<ponga>
headius: can i ask what sql querry abstraction i could use for Jruby , like Ruby's Sequel
<ponga>
chrisseaton: thanks, "numbers come thu" its real neat
<ponga>
i like it
<headius>
sequel works on JRuby
<ponga>
really? cos i gave out errors last time i used it
<ponga>
perhaps i set it wrong
codefinger has joined #jruby
<fkchang>
codefinger: thx for the quick response on heroku, I have exactly that line
<codefinger>
fkchang: are you getting an error?
<reaver>
Ok thanks so far. good to know. I think I will visit this channle often in the future since I'm gona work with ruby and rails in the future pretty much. I plan to use jruby for rails applications in production. shouldn't be a problem or am i wrong?
<fkchang>
but w/the json like hash syntax - ruby '2.2.2', engine: 'jruby', engine_version: '9.0.0.0.pre2'
<codefinger>
fkchang: cool, please let me know if you have any problems. i'll be here :)
<headius>
cedar-14, I'll try to remember that too
cremes has quit [Remote host closed the connection]
<codefinger>
headius: it's the default stack now, so new apps shouldn't run into that. but upgrades might. we EOL cedar-10 in Nov, so shouldn't be an issue much longer.
<headius>
ok cool...now I know if we get the same question again
cremes has joined #jruby
cremes has quit [Client Quit]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] fkchang opened issue #2897: SSL Cert issue on 1.7.* http://git.io/vJmgV
<headius>
it's exciting stuff but compat-wise there's a lot of work to do
<chrisseaton>
You can sometimes get gems working if you bundle vendor them and manually put them on the load path
colinsurprenant has quit [Ping timeout: 248 seconds]
colinsurprenant has joined #jruby
<headius>
right, if you basically remove RG from loading it
<headius>
so you could use jruby proper to install them and then cobble together a load path manually
<chrisseaton>
Our current goal is to produce a complete version of standalone Ruby - so running all of core and stdlib, but not being able to load gems
rcvalle has joined #jruby
<chrisseaton>
That will hopefully be useful to some people
<headius>
that's a fine start
<headius>
though if you can run all of core and stdlib I'd expect gems to work fine
<ponga>
yes me too
* ponga
glares at chrisseaton in hope
<chrisseaton>
headius: yeah, but the idea is to not even bother ourselves trying to run gems until that point
<fkchang>
codefinger: upgrade was seemless. Deploy was longer than I remember and the processes got reaped a few times for not spinning up fast enough, but the app is running, so thanks!
<chrisseaton>
ponga: :) I'm not sure 'glares' is the word you are looking for
<headius>
fkchang: you were on pre1 before or 1.7?
<ponga>
oh chrisseaton sorry lol
<ponga>
my dictionary is bad
<headius>
chrisseaton: sure...that approach worked for us when tests for Ruby behavior were very limited, but with all the tests available now just making them pass gets you really far
<fkchang>
headius: app was on 1.7.13, upgraded to 9K pre2 to get the SSL fix
<codefinger>
fkchang: cool, the deploy probably had to reinstall all of your gems because of the new stack. so subsequent deploys should be quicker again. if you hit the boot-timeout limit again, please file a ticket and we can increase it slightly.
<headius>
fkchang: oh nice, so your stuff works fine on pre2
<fkchang>
headius: yeah, as far as I can tell, it all works
<headius>
codefinger: 1.7 on heroku is probably still using stock jruby-openssl yeah?
<headius>
it might be worth an update to get it on latest if that fixes fkchang's ssl issue
<headius>
1.7.19 jossl is 0.9.6 I believe, and 0.9.7 has a bunch of fixes
<codefinger>
headius: can that be fixed with an entry in each app's Gemfile, or no?
<headius>
codefinger: yeah, it can be fixed by the user
<headius>
on the other hand 1.7.20 will be out within a week, so perhaps it's a moot point
<fkchang>
headius: saw your comment on the issue, should I try 1.7.19 (thought latest was 1.7.18) or should it wait for 1.7.20
<ponga>
headius: do you know what specific sqlite3 gem i need to install , to get 'sequel' running for Jruby?
<ponga>
there are a lot..
<headius>
fkchang: 19 is latest, but jruby-openssl 0.9.7 may work ok on 18...either way if you could confirm adding jruby-openssl to Gemfile fixes it, I'd appreciate that
<headius>
i.e. this may be fixed and we can close it for .20
<jeremyevans>
ponga: jdbc-sqlite3
<ponga>
jeremyevans: thank you i will do it now
<headius>
hive of activity today
<fkchang>
headius: I'll try it when I have a bit of downtime
camlow325 has joined #jruby
<headius>
fkchang: glad to hear things are working...we may be close to 9k final then
zorak8 has joined #jruby
<headius>
bleh, lots of 1.7.20 bugs
<headius>
I wish we could walk away from 1.7 sooner
KevinCorcoran has quit [Ping timeout: 256 seconds]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] k77ch7 opened pull request #2899: Fix for issue 2896 on master : Symbol#inspect with utf8 encode string (master...fix_GH-2896_on_master) http://git.io/vJmQ7
JRubyGithub has left #jruby [#jruby]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] bjfish opened issue #2900: [Truffle] Method constant_table needed for Gem commands http://git.io/vJm7t
JRubyGithub has left #jruby [#jruby]
<codefinger>
headius: what are the fixes in jruby-openssl 0.9.7 that are important? are they a security concern or just functionality?
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius closed issue #2301: unable to get value of object's fields in RubyMine debugger http://git.io/ChLQvA
JRubyGithub has left #jruby [#jruby]
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lanceball is now known as lance|afk
<headius>
codefinger: I think there's some minor security-related items but mostly compatibility
<headius>
kares and mkristian have a better understanding
<kares>
codefinger: did we forgot the change-log again ... ah sorry!
<codefinger>
ok, i'm hesitant to "mutate" and existing runtime (i.e. repackage 1.7.19). but we're big on keeping up with security fixes so users don't have to
<kares>
greetings btw :)
<codefinger>
kares: hello!
<kares>
there's an attempt to fix some SSL security in 0.9.7
<codefinger>
kares: thanks for scrubbing the warbler backlog!
kfpratt has joined #jruby
<headius>
codefinger: I'd say just get ready for 1.7.20 then
<kares>
was hoping to handle SSL better and disable some of the algorithms used
<kares>
but it did not get finished, but there's certainly improvement
<kares>
TLS 1.1/1.2 should work better (and in a MRI compatible way)
<codefinger>
ok. i assume if there was a significant security problem, there would have been a jruby 1.7.19.1 release or something? is that safe to assume?
<ponga>
oh yeah! thank you jeremyevans
<ponga>
Jruby+Sequel is working divinely now
<kares>
codefinger: semi-safe I guess ... still jruby-openssl is somehow lacking a full-time security expert
<kares>
so while the JDK upgrades handle some security issues - there's room for improvement jruby-openssl is (still) not aligned completely with MRI's OpenSSL defaults
pjammer has joined #jruby
mister_solo has quit [Ping timeout: 265 seconds]
gazay has joined #jruby
zorak8 has quit [Ping timeout: 272 seconds]
zorak8 has joined #jruby
<headius>
codefinger: that's safe to assume
<headius>
or at least, it means we don't know of any security issues
<kares>
codefinger: recall there was a certificate decoding regression in 0.9.6 so I would put 0.9.7 in
<codefinger>
jruby-1.7.19 shipped with 0.9.5 though. so it should be "safe" right?
<headius>
oh, 0.9.5? further back than I thought
shellac has quit [Quit: Computer has gone to sleep.]
<kares>
yy we had a 0.9.6 release - this is actually what we originally intended - put a gem release out ... people try that out and if no issues come in than get it to ship with jruby
<chrisseaton>
headius: how complete was JRuby when you guys started contributing?
<chrisseaton>
headius: was it running Rails?
<kares>
chrisseaton: not at all :)
<kares>
... as far as I remember - can't wait to hear from the Sun-y days
<headius>
chrisseaton: it couldn't run anything
<headius>
we got hired by Sun *because* we got it to run Rails, and that took about 6 months of people implementing libs and improving compat
<headius>
probably 4-5 FTE worth of contribs that year
<headius>
we were laser-focused on getting Rails to run rather than meeting a synthetic compatibility measurement though
<headius>
that was also five or six interpreters ago, pre-JIT, ruby 1.8.4 timeframe (so Ruby itself was much smaller)
lopex has quit [Quit: Connection closed for inactivity]
<codefinger>
headius: when were you guys hired by sun? 2007-ish?
<headius>
Sept 2006
<codefinger>
dang :)
<headius>
presented Rails running in JRuby at JavaOne earlier that year
<Antiarc>
wow, I didn't realize it'd been that long
<Antiarc>
Just in general, thank you :)
<headius>
yes, we've almost been working fulltime on JRuby for nine years
<headius>
or rather, we've been working fulltime on JRuby for almost nine years
<headius>
I sure hope it has been worth it
<headius>
I guess any job you can do for nine years and still have fun is worth it
<kares>
Sun had quite a team here in Prague - best company around ( still regret not going to an interview :) !
colinsurprenant has quit [Ping timeout: 248 seconds]
<headius>
they're still there but I think it has gotten a lot smaller under Oracle
<headius>
and yeah, great bunch of guys...external startup Sun acquired, close-knit group
<headius>
jesus can they drink
kith has quit [Quit: kith]
<codefinger>
i was working at NASA in 2006/7 and we were using JRuby to run migrations for a Hibernate database schema. so i've been exploiting these guys' hard work for almost 9 years!
<headius>
I think there's still a few groups at NASA using JRuby
<codefinger>
oh yea, even my old group still is i think
<headius>
and I assume the SETI use is still around too
<codefinger>
NASA is so great like that. we were like "can we use this thing that barely works" and they were like "sure, just contribute back to it"
<kares>
codefinger: najs!
iamjarvo has joined #jruby
<headius>
yeah cool...I think the guy using JRuby at SETI has posted some fixes back too
skade has quit [Quit: Computer has gone to sleep.]
<headius>
have not heard from that project in a while
zorak8 has quit [Quit: Leaving]
subbu|brkfast is now known as subbu
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 4 new commits to master: http://git.io/vJYlZ
<JRubyGithub>
jruby/master 451e0d5 Chris Seaton: [Truffle] No need for DSL options.
<JRubyGithub>
jruby/master 8161e4f Chris Seaton: [Truffle] No need for DSL type system in pack anymore.
<JRubyGithub>
jruby/master b260e81 Chris Seaton: [Truffle] Tidy up the execute methods on RubyNode.
JRubyGithub has left #jruby [#jruby]
elia_ has quit [Quit: Computer has gone to sleep.]
KevinCorcoran has joined #jruby
rsim has quit [Quit: Leaving.]
kares has quit [Remote host closed the connection]
djbkd has joined #jruby
zorak8 has joined #jruby
brightball has joined #jruby
KevinCorcoran has quit [Ping timeout: 256 seconds]
lance|afk is now known as lanceball
deobalds has quit [Quit: Computer has gone to sleep.]
<mjc_>
was anything decided about 9k supporting (or not) java 7?
<mjc_>
we are still mostly java 6, 7 makes us go "whoa"
<mberg>
Wait, you're supposed to ask before you use things which barely work??
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 1 new commit to master: http://git.io/vJYa9
<JRubyGithub>
jruby/master 6a374e6 Chris Seaton: [Truffle] Move basic guards into a separate class.
JRubyGithub has left #jruby [#jruby]
<headius>
mjc_: we heard from a few others that a move to 8 was not in their 2015 plan
<mjc_>
ah
<mjc_>
I'm surprised we were even allowed to use 7 at all, heh
<mjc_>
8 is super scary apparently
gregorsc5 has joined #jruby
gregorsc5 has quit [Read error: Connection reset by peer]
gregorsc5 has joined #jruby
gregorsc5 has quit [Client Quit]
Aethenelle has joined #jruby
<Antiarc>
lambdas? Sounds like devil worship to me.
<headius>
hah
<ponga>
Proc?
kares has joined #jruby
shellac has joined #jruby
<headius>
hey not sure I mentioned it but JRuby committers that want to use IntelliJ can use our OSS license
rsim has joined #jruby
<Antiarc>
Can you clarify?
<Antiarc>
JRuby stuff I contribute is done in IntelliJ. Is there a complication?
<headius>
we have an OSS license for IntelliJ enterprise
<Antiarc>
Ohhhhhhhhh.
<Antiarc>
I thought there was a licensing issue. Nevermind then :)
<headius>
yeah just for usage
<headius>
most of us had to give up on Netbeans unfortunately :-(
<mjc_>
Antiarc: anything that isn't 5 years old is new and therefore scary, apparently, lambdas are fine, but not in java ;P
kith has joined #jruby
gazay has quit [Quit: gazay]
<kares>
headius: does it have a Ruby plugin - I bought RubyMine a while back just to find out I get text for any .java source :) ?
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 2 new commits to master: http://git.io/vJYX2
<JRubyGithub>
jruby/master 89e1459 Chris Seaton: [Truffle] Final bit of tidying up of RubyNode for now.
<JRubyGithub>
jruby/master a94d7b2 Chris Seaton: [Truffle] Make notDesignedForCompilation transferToInterpreter - will inline later.
JRubyGithub has left #jruby [#jruby]
<kares>
... thus I'm still NB for JRuby - pretty much since the Sun-y days!
<chrisseaton>
kares: IntelliJ licensed does yeah - and it works quite well
<Antiarc>
kares: IIRC the enterprise edition can load the Ruby plugin
<chrisseaton>
kares: no debugger as far as I know
<Antiarc>
Community can't
<kares>
chrisseaton: Antiarc: thanks ... you guys have that OSS license than, right?
<headius>
enebo: omg
<headius>
I talked to evan about how MRI determines class/module name
<Antiarc>
I don't, I use community edition
<headius>
you're going to love this
<Antiarc>
I just work in Ruby in Sublime
<kares>
Antiarc: good for you
<headius>
kares: I'll forward to you
<Antiarc>
But I have a super weird setup anyhow, I work on a Windows box, but all my actual code runs on a headless Linux box on my LAN
KevinCorcoran has joined #jruby
<Antiarc>
So most debugging tools in IDEs don't work anyhow :)
<mjc_>
headius: that sounds like an epic tale, hah
<kares>
Antiarc: who cares for debugging these days, right :) ?!
<Antiarc>
I just debug from the CLI if I have to!
<Antiarc>
IDEs, psh.
<mjc_>
rubymine has remote debug, heh
<Antiarc>
(CLI debugging is a handy skill when you're working on remote prod boxes, though)
<Antiarc>
They have it but it doesn't work terribly well for me for some reason
<fuzzyhorns>
im looking in jconsole at my rails app running in jruby, and though i stopped hitting it with requests, i see a ton of threads that havent died
<kares>
headius: thanks - will love to try IJ as NB has its limits
<fuzzyhorns>
how can i tell if the thread should be alive or not? D:
<fuzzyhorns>
(i am a ruby dev, not a java one, so forgive me for dumb questions)
<headius>
boo, enebo must be having lunch
<Antiarc>
fuzzyhorns: Threads can be alive and not processing work
<Antiarc>
That's perfectly normal
<fuzzyhorns>
ok, so "a lot of threads" != bad
<Antiarc>
Nope
<headius>
kares: I had to give up on NB because it regularly shit itself if you had lots of changes happening outside the IDE (e.g. branch switching, large merges)
<Antiarc>
Well, yes
<Antiarc>
Threads aren't bad
<headius>
it would get slower and slower to bring up code completion
<Antiarc>
Spinning up threads is expensive so it's ideal to keep them alive and reuse them if possible
<enebo>
back from LUNCH
<headius>
kares: sent...there's a RubyMine license too but I don't think you'll need it with the enterprise license
<kares>
headius: yy ... it's the worse with `mvn clean package` under jruby/core project
<fuzzyhorns>
i was doing a load test and my app stopped responding, so i wanted to diagnose what i sholding it up
<headius>
kares: ugh, yes
<fuzzyhorns>
any tool recommendations?
<fuzzyhorns>
im looking in jconsole atm
<headius>
enebo: hi there :-)
<mjc_>
perf on pre2 is much better than it used to be but still slower than 1.7.x on our app
<headius>
So yeah...MRI does *not* assign the module's constant at decl time
<Antiarc>
fuzzyhorns: jstack should tell you where each thread is stuck
<headius>
for cases like Foo = Module.new I mean
<headius>
what does it do, you may ask?
<fuzzyhorns>
Antiarc: is it possible a "stuck thread" would exhibit this behavior, where my app simply stops taking requests?
<headius>
it defers name calculation until you actually call #name
<fuzzyhorns>
it hasnt _crashed_
<fuzzyhorns>
it just doesnt reply x)
<headius>
and how, pray tell, can it figure out nesting when you call #name?
<enebo>
hahah
<Antiarc>
fuzzyhorns: Sure, if you're blocked somewhere
<mjc_>
about 20% slower
<headius>
BECAUSE IT SEARCHES THE ENTIRE CONSTANT NAMESPACE
<enebo>
nice
<Antiarc>
Try jstack -l $your_pid
<headius>
it starts at Object
<Antiarc>
I think it's -l
<headius>
I'm kinda in awe
<mjc_>
headius: hahah :(
<headius>
enebo: so, if we want to do THAT, we could match MRI exactly
<headius>
jeremyevans' case works because regardless of recursive nesting, eventually the search terminates
<enebo>
headius: yeah that sounds weird one two levels. The extra searching it bad but the potential races is even higher than doing it at decl time
<headius>
it also explains why these names come out as nil too... these are not rooted in any namespace, so they can't be found
<headius>
so name is nil
<headius>
this is not a behavior we can easily emulate with eager naming
<Antiarc>
WAITING usually means the thread is blocked and waiting for some condition before resuming
<Antiarc>
But that may be normal depending on the thread
<Antiarc>
If you can gist your trace I'm happy to take a look
<enebo>
headius: I have always thought this side-effect was hinky but it is even worse than I imagined. It is really unfortunate anything depends on this
Hobogrammer_ has joined #jruby
<headius>
parking means that thread has been removed from scheduling until someone else wakes it, used inside some of the lock-free JDK collections for example
camlow32_ has joined #jruby
<headius>
enebo: in this case I think I can patch around it by just putting a recursive detect into the naming loop
<fuzzyhorns>
i will see about gisting it, super appreciate
<headius>
but we will actually give it a name when it doesn't have a name in MRI
<enebo>
headius: we perform faster!
<headius>
I guess one justification for this is that mod.name should be lookupable
<headius>
ours will be A::A but you can't just access A::A
<fuzzyhorns>
lemme know if i can truncate to be more useful or anything else
<headius>
MRI has a wacky design but I can't think of how else you'd do it
<Antiarc>
hehe, I know they can be big
dyce_ has joined #jruby
wasnotrice_ has joined #jruby
<Antiarc>
fuzzyhorns: I see you using MonitorMixin, just FYI, Monitor is slooooow :)
<Antiarc>
If you can, use Mutexes. They aren't reentrant, but if you need reentrancy you have done something wrong 99% of the time anyhow
<fuzzyhorns>
fuzzyhorns: not using it on purpose :<
<fuzzyhorns>
haha responding to myself god
<Antiarc>
Looks like it probably comes from AR's connection pool. Ugh.
<fuzzyhorns>
Antiarc: so i am running torquebox -> jruby -> rails
<fuzzyhorns>
Antiarc: so if i increase AR connection pool i'd releive it? or could i close them manually somehow?
<Antiarc>
So you have a bunch of stuff like "parking to wait for <000000000fd5f520"
<fuzzyhorns>
bad i assume?
<Antiarc>
If you search that address in the file you can find what thread holds that lock
<Antiarc>
It looks like nearly all your threads are waiting on that lock, which is probably bad
<Antiarc>
I don't actually see which thread holds that lock in that trace
<Antiarc>
That's odd.
<fuzzyhorns>
me either
<fuzzyhorns>
i was just looking
<fuzzyhorns>
where else could i poke around?
<Antiarc>
Well, that's almost certainly your problem. Your pool is empty, everything is checked out and isn't being checked back in.
<Antiarc>
Are you using timeout.rb anywhere?
x1337807x has joined #jruby
<Antiarc>
Increasing the pool size may delay the problem but won't fix it
<fuzzyhorns>
ill check
AlHafoudh_ has joined #jruby
<Antiarc>
The reason I ask is that Timeout can cause unexpected behavior, including causing ensure blocks to not run, which can cause connections to not be returned to a pool
<Antiarc>
It's a wonderful way to starve a resource pool :)
<fuzzyhorns>
where would it be Antiarc?
<fuzzyhorns>
you just mean in general?
shellac has quit [*.net *.split]
dumdedum has quit [*.net *.split]
Silent__ has quit [*.net *.split]
ivan\ has quit [*.net *.split]
brixen has quit [*.net *.split]
AlHafoudh has quit [*.net *.split]
camlow325 has quit [*.net *.split]
cultureulterior1 has quit [*.net *.split]
dyce has quit [*.net *.split]
wasnotrice has quit [*.net *.split]
dabradley has quit [*.net *.split]
MacRohard has quit [*.net *.split]
KevinCorcoran has quit [*.net *.split]
fkchang has quit [*.net *.split]
havenwood has quit [*.net *.split]
cprice404 has quit [*.net *.split]
Osho has quit [*.net *.split]
AlHafoudh_ is now known as AlHafoudh
<Antiarc>
fuzzyhorns: yeah, if you're calling Timeout.timeout around anything that uses a DB connection, that could be a problem
wasnotrice_ is now known as wasnotrice
<Antiarc>
Not guaranteed, but it'd be the first place I'd look
<Antiarc>
Can you consistently starve the app out, or is this a hard-to-repro issue?
ivan\ has joined #jruby
ivan\ has joined #jruby
ivan\ has quit [Changing host]
<fuzzyhorns>
Antiarc: i can starve it out repeatedly :c
<Antiarc>
How long does it take?
<Antiarc>
Also, you're on jruby-1.7.13, try upgrading to .19, I know there were lots of thread-related fixes in that general timeframe
<fuzzyhorns>
in prod, like a weekish usually, until recently, when it crashed and burned way faster
<fuzzyhorns>
good to know Antiarc
<Antiarc>
Okay, a weekish is what I'd expect with things like Timeout leaks
<enebo>
headius: fwiw I like your error message better than theirs
<Antiarc>
Basically, over time, the stars align and timeout kills a thread before it can check in its connection
KevinCorcoran has joined #jruby
havenwood has joined #jruby
fkchang has joined #jruby
Osho has joined #jruby
cprice404 has joined #jruby
Aethenelle has quit [Read error: Connection reset by peer]
<Antiarc>
Do that enough times and your pool empties and you're left with threads that want to check out connections and there are never any connections to check out
<fuzzyhorns>
yeah it seems true to me Antiarc
<enebo>
headius: actually I will correct this since I already know what is wrong
<Antiarc>
Audit your DB driver for usage of Timeout.timeout, too
gregorsc5 has joined #jruby
<Antiarc>
Some DB drivers do this and they are bad and should feel bad
<Antiarc>
That's where it's blocked, on that `synchronize` call
<Antiarc>
Probably trying to call `checkout` in the synchronize
<Antiarc>
oh hell
dumdedum has joined #jruby
<Antiarc>
And checkout calls synchronize as well, no wonder they're using monitors
<Antiarc>
Blegh
Aethenelle has joined #jruby
<Antiarc>
I wonder how much speed you could get out of that by eliminating monitor usage
<fuzzyhorns>
son of a bitch
dabradley has joined #jruby
<Antiarc>
That's not the problem, monitors are reentrant, so that won't deadlock like a mutex would
<Antiarc>
But it's stalled trying to get a connection, which is a great indicator that your connection pool is leaking for some reason
rcvalle has quit [Quit: rcvalle]
<fuzzyhorns>
so what's the mechanism here from the synchronize in ruby down?
<Antiarc>
hm?
<fuzzyhorns>
the db connection is itself a thread?
<Antiarc>
No, the db connection gets checked out from a pool to the calling thread
<Antiarc>
Then when the thread is done with it, it should be checked back in so another thread can use it
marr has quit [Ping timeout: 245 seconds]
<Antiarc>
The problem is that connections are occassionally not checked in, and the pool empties, so then eventually there are never any connections available to check out, and activerecord stalls forever waiting for one to become available
<kares>
fuzzyhorns: seen that - without detail analysis of your code there's nothing suspicious about not returning threads
<kares>
with many request + many jobs in SQ you get many threads
<enebo>
headius: yowch…but how many programs ask for name very often?
<kares>
you do not seem to manage them - they are managed by the server's request thread pool + Celluloid's own pool for workers
iamjarvo has joined #jruby
<enebo>
headius: I would largely think either IO logging ot exception reporting which are glacially slow activities already
<kares>
unless you suspect there's a leak somewhere around those ... it's fine the issue Antiarc helped you locate is that they start to compete on shared resources
<headius>
enebo: inspect on an instance has to do this
<enebo>
headius: default inspect
<headius>
right
<headius>
but that's pretty common
<enebo>
headius: but again only for logging or exceptions no?
<enebo>
or IO
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] enebo pushed 1 new commit to master: http://git.io/vJOkB
<JRubyGithub>
jruby/master 5da8955 Thomas E. Enebo: unbeautify our base :: constant errors to match MRI's
JRubyGithub has left #jruby [#jruby]
colinsurprenant has joined #jruby
<fuzzyhorns>
kares: so you're saying make the server manage them differently?
<fuzzyhorns>
server = torquebox atm
_kfpratt has joined #jruby
rsim has quit [Quit: Leaving.]
kfpratt has quit [Read error: No route to host]
_kfpratt has quit [Read error: Connection reset by peer]
kfpratt has joined #jruby
kfpratt has quit [Read error: Connection reset by peer]
kfpratt has joined #jruby
<Antiarc>
fuzzyhorns: Unfortunately, this is the really gnarly part about concurrent programming - you will probably have to get in there and audit both your application and driver code for any circumstances which could lead to leaked connections.
<fuzzyhorns>
Antiarc: what do you think of what kares was saying? should i consider this behavior under heavy load pathological or no?
_kfpratt has joined #jruby
kfpratt has quit [Read error: Connection reset by peer]
<Antiarc>
I think that heavy load just makes the issue appear faster, because you're providing more opportunities to hit the pathological case
<kares>
Antiarc: the driver will be fine ... it's mostly AR's pool that's greedy ... each request will reserve a connection even if it's not used (but it will close once it ends)
<fuzzyhorns>
what other data can i comb through to figure out what in the ruby code is hanging this up?
<Antiarc>
The problem is that the requests terminate and the connection isn't released to the pool, I suspect
<fuzzyhorns>
i can check the # of db connections
<kares>
... but application code of course might be an issue - we can not tell that without knowing what's going on
<fuzzyhorns>
kares: i would not be surprised if it were
<ponga>
anyone using Sequel+jdbc-postgres here?
pierreatkillbill has quit [Ping timeout: 252 seconds]
<fuzzyhorns>
this is a big app, and partially legacy :c
<Antiarc>
kares: Speaking from experience in fixing DB driver pooling/thread pinning issues, assuming the driver is fine is a dangerous assumption :)
<ponga>
Sequel::DatabaseConnectionError: Java::JavaSql::SQLException: No suitable driver found , even after 'Jdbc::Postgres.load_driver'
_kfpratt has quit [Read error: No route to host]
<kares>
fuzzyhorns: look for ActiveRecord::Base.connection or maybe any `grep connection` places if they're suspicious
<fuzzyhorns>
k
<kares>
Antiarc: OK no experience there :) but recent drivers are usually fine ... even from Oracle :)
kfpratt has joined #jruby
<jeremyevans>
ponga: I test Sequel+jdbc-postgres regularly
<jeremyevans>
ponga: What is your conenction string?
kfpratt has quit [Read error: Connection reset by peer]
<ponga>
jeremyevans: DB = Sequel.connect('jdbc:postgres://localhost/Lud', :user=>'Lud', :password=>'mypasswordishere')
<ponga>
is it string syntax to JDBC?
<fuzzyhorns>
Antiarc: looking in MAT, i see oracle.jdbc.driver.T4CPreparedStatement taking up a ton of space
<ponga>
the problem?
<jeremyevans>
ponga: PostgreSQL JDBC connection strings start with jdbc:postgresql://
kfpratt has joined #jruby
<ponga>
damn
<ponga>
jeremyevans: such simple mistake...
<kares>
ponga: such an unfortunately named gem ... srry!
<ponga>
omg kares you are one of the owner lol
* ponga
smirks
<kares>
ponga: yy but not the creator :) ... and the naming has bothered me!
<ponga>
kares: it sure has bothered my 70 mins of hassle
<Antiarc>
fuzzyhorns: I wouldn't immediately worry about that, but that might be an interesting clue that something is being held onto that shouldn't bem perhaps?
<ponga>
;(
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 1 new commit to master: http://git.io/vJOZW
<JRubyGithub>
jruby/master d34f7e9 Chris Seaton: [Truffle] FindBugs.
JRubyGithub has left #jruby [#jruby]
<fuzzyhorns>
Antiarc: yeah :/ we use a LOT of stored procedures too -_-
baroquebobcat has quit [Remote host closed the connection]
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<nirvdrum>
enebo: I ran FindBugs over the entire project this morning using the FindBugs-IDEA plugin. I had to restart IDEA so I lost the results. But it might be worth running through that. There was some stuff in IR that FindBugs highlighted as being a potential performance issue. E.g., using keySet() + get() instead of entrySet().
<enebo>
nirvdrum: ok but this lst build is failing with 300+ missing classes
<enebo>
nirvdrum: many of which must exist
<chrisseaton>
enebo: the fix for that failure is in the build pipeline
<nirvdrum>
chrisseaton committed a change to the FindBugs config
<enebo>
ah ok cool
<nirvdrum>
It's running right now, actually :-)
rcvalle has quit [Quit: rcvalle]
elia has quit [Quit: Computer has gone to sleep.]
rcvalle has joined #jruby
subbu has quit [Ping timeout: 256 seconds]
fuzzyhorns has quit [Read error: Connection reset by peer]
subbu has joined #jruby
MacRohard has joined #jruby
rcvalle has quit [Client Quit]
fuzzyhorns has joined #jruby
rcvalle has joined #jruby
elia has joined #jruby
cultureulterior1 has joined #jruby
<nirvdrum>
Argh.
<nirvdrum>
Our version of psych can't process MBC.
<chrisseaton>
fuzzyhorns: JRuby has made the deliberate choice not to synchronise user data structures, so you should synchronise yourself
<chrisseaton>
fuzzyhorns: providing automatic synchronisation of primitive operations would add huge overhead and wouldn't gain you much anyway as the synchronisation would not hold under composition
<fuzzyhorns>
also another newb question, how do i know when threads are not working in jruby? like, they get checked out, but i think arent being checked back in? jstack shows a bunch of waiting ones — but idk if it is pathological or not
<chrisseaton>
not sure what 'checked out' means? can you rephrase?
<fuzzyhorns>
there's only so many in a pool on a server right?
<fuzzyhorns>
(sorry my mental model is fuzzy)
<fuzzyhorns>
(im running jruby on torquebox if that matters)
<chrisseaton>
fuzzyhorns: if you're using some other software that might be the case - but in general JRuby can create as many threads as the system can support
x1337807_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<fuzzyhorns>
so unless the server is limiting it, it is going to just go up to system max?
subbu has quit [Ping timeout: 272 seconds]
<chrisseaton>
if you or something else does Thread.new, you get another real operating system thread
pjammer has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
bjfish2 has quit [Quit: bjfish2]
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fuzzyhorns>
what i see in jconsole for threads is system threads though, right?
pjammer has joined #jruby
<chrisseaton>
in OpenJDK and I think all other real JVMs yeah
<chrisseaton>
are you trying to fix a specific problem, or just trying to improve your understanding?
<fuzzyhorns>
well both lol
x1337807x has joined #jruby
<fuzzyhorns>
the context: in production, the app fell over, after having had increasing issues with java oom errors
<fuzzyhorns>
i changed some garbage collection settings for torquebox (it passes those options to java) and the heap size wasnt an issue anymore
<fuzzyhorns>
but i could still make the app fall over
<fuzzyhorns>
maybe im just hitting it too hard still
<fuzzyhorns>
but now im wondering if i can make it more robust
<chrisseaton>
I would imagine something simple is misconfigured, but it's very hard to say what
<chrisseaton>
For example, how much heap are you giving the app?
<fuzzyhorns>
well here's the thing, i'm not running out of heap anymore
<fuzzyhorns>
but at a certain point it can't take more requests
<fuzzyhorns>
the app doesnt crash either
<fuzzyhorns>
sometimes it can even process the requests at a trickle
<fuzzyhorns>
which made me wonder, ok, is it just maxing out of threads? of tcp connections? what other vars are there?
<chrisseaton>
sorry you're going beyond my knowledge - hang around here and see if there is anyone who knows the Ruby web stack better than I do
<fuzzyhorns>
basically im not seeing the heap go above 500mb, but threads keep climbing :c