<eonwe>
We're currently a bit between a rock and a hard place as the concurrency problems in java class proxy creation (https://github.com/jruby/jruby/issues/1621) that's supposedly fixed in upcoming 1.7.20, but we cannot use that as autoloading is currently broken in versions > 1.7.17
skade has joined #jruby
vtunka has quit [Quit: Leaving]
pitr-ch has joined #jruby
pierreatkillbill has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
drbobbeaty has joined #jruby
vtunka has joined #jruby
<kares>
eonwe: hopefully not only for 9K
<kares>
but you need to make some noise - could you confirm that it's still an issue in 1.7 and if so comment/create an issue?
<kares>
... also I'm not sure if you've meant the same code sample
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
skade has quit [Remote host closed the connection]
skade has joined #jruby
lopex has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] eregon pushed 3 new commits to master: http://git.io/vfvKR
<JRubyGithub>
jruby/master 2c38858 Benoit Daloze: Squashed 'spec/ruby/' changes from 44248dc..45d075c...
skade has quit [Remote host closed the connection]
e_dub has quit [Quit: Leaving]
djellemah_ has joined #jruby
dinfuehr has quit [Remote host closed the connection]
djellemah has quit [Ping timeout: 272 seconds]
djellemah_ is now known as djellemah
erikhatcher has joined #jruby
mcclurmc has joined #jruby
tcrawley-away is now known as tcrawley
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] enebo pushed 1 new commit to master: http://git.io/vffSQ
<JRubyGithub>
jruby/master 1630b58 Thomas E. Enebo: Tag out new test failures?
JRubyGithub has left #jruby [#jruby]
iamjarvo has joined #jruby
iamjarvo has quit [Client Quit]
oko has joined #jruby
mrmargolis has joined #jruby
pierreatkillbill has joined #jruby
<bbrowning>
did IO.select change a lot between 1.7.x and 9k? I've got some code that worked fine under 1.7 but doesn't under 9k that uses IO.select
<a5i>
how much fatser is 9k than 1.7 now?
<bbrowning>
the wrinkle is that it's using IO.select against a RubyIO I construct in Java-land with my own nio Channel
<a5i>
faster*
<nirvdrum>
bbrowning: IO was completely rewritten in 9k.
<bbrowning>
nirvdrum: yeah I thought that sounded familiar
<nirvdrum>
You'll need to ping headius when he pops on.
skade has joined #jruby
<bbrowning>
guess I'll have to dig in and figure out why IO.select never ends up calling read on my underlying Channel
skade has quit [Remote host closed the connection]
<bbrowning>
looks like perhaps it's because the Channel I pass doesn't implement SelectableChannel
<bbrowning>
which would make sense, I guess
<headius>
good morning!
<headius>
bbrowning: hello there
<headius>
eonwe: what's broken about autoloading exactly?
erikhatcher has quit [Quit: erikhatcher]
<headius>
is it the double loading issue?
<bbrowning>
headius: hi! I'll be in-and-out today, but it looks like in 1.7 a ReadableByteChannel was enough to use w/ IO.select and in 9k I need a SelectableChannel
<bbrowning>
not the end of the world I don't think - I'll have to look and see if I can get something Selectable from my underlying IO layer
<headius>
bbrowning: ahh ok...that can be repaired
<headius>
I think it just marked them as ready though
<headius>
not much else it can do
<headius>
the new logic *should* be doing the same, but I'll look into it
<bbrowning>
yeah I'll need to step through it with a debugger again to see what's up
<bbrowning>
so I have to work through and see how it got there
<headius>
I can reproduce with: io = java.nio.channels.Channels.newChannel(java.io.ByteArrayInputStream.new('hello'.to_java_bytes)).to_io; p IO.select([io], nil, nil, 1000)
tcrawley is now known as tcrawley-away
<enebo>
bbrowning: it does say forever…what is your problem!
<bbrowning>
enebo: haha yeah it does say forever :)
<bbrowning>
headius: cool
<headius>
so the new logic is a very loose port of MRI's code, but within the central select it diverages a lot because the API is totally different
<headius>
where select(2) will just return an unselectable stream as ready (I think, or some useful errno) we have to maintain a separate list of them
<headius>
I wasn't considering that list when going into the select call, and it didn't see any selectable channels registered, so it just does a hard wait
rsim has quit [Ping timeout: 265 seconds]
<bbrowning>
headius: my IO never gets added to unselectableReadFDs, if that's the list you're referring to
e_dub has joined #jruby
<headius>
yes, that's a second problem
<headius>
I was conservative in what I considered ready by default and only did it for files
drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty has joined #jruby
<headius>
enebo: I think your question is why this needs to be a separate project at all, rather than just rolled into jruby proper, yeah?
<mkristian>
enebo, not getting the question about the application.jar
<headius>
mkristian: we chatted a bit and are not sure why we shouldn't just put this into jruby directly
<headius>
the extra dependency for just 9 classes seems unnecessary
<mkristian>
headius, so the idea is to get all those mains into jruby-mains ? would sound ok to me.
<headius>
mkristian: well I mean, why wouldn't jruby-mains just roll into jruby?
<headius>
one of them is already semi-duplicate
shellac has quit [Quit: Computer has gone to sleep.]
oblutak has joined #jruby
<headius>
and it seems like it would be more convenient to have all the logical launchers out of the box in jruby
skade has quit [Ping timeout: 264 seconds]
<rtyler>
headius: I would want to be able to take later versions of jruby-mains and not wait for a full jruby cycle
<enebo>
yeah each spelled out use-case should just be part of jruby-complete.jar or possibly even jruby.jar
<enebo>
could it be a gem?
<enebo>
perhaps that is weird
<rtyler>
a fully java-based gem? :P
<headius>
rtyler: yeah I get the separate versioning aspect
<enebo>
rtyler: I am guessing there is the generate a jar part of this which would be a script/tool though also
<headius>
enebo: that's rmvn/gradle :-)
<enebo>
headius: is it?
<mkristian>
headius, yes, there was a reason. when I want to have an runnable war. then I need to have some java code at the root of the war file. basically like a jar. just for the launcher code.
dinfuehr has joined #jruby
<headius>
mkristian: do you see the JRubyMain/JarMain changing much?
<headius>
that's really the one that makes sense to me to be available in JRuby right away
<mkristian>
headius, not really.
<headius>
the others are pretty domain-specific
<headius>
I mean if we want to go with the project that has more main() methods, I think JRuby wins with nailgun and drip :-D
<enebo>
headius: jruby-mains instrs make no mention of rmvn nor gradle…isn’t this to generate something which can work within gradle? mkristian rtyler ?
<eregon>
headius: Hi! Would you mind if I slightly alter syntactically the EXCLUDE code in test/mri/lib/minitest/unit.rb? It's hard right now to find the right class to define on in an instance_eval and we would like to run MRI tests in Truffle
<mkristian>
enebo, there is no direct link to gradle or maven. they just can use it.
<eregon>
headius: MRI has integrated some EXCLUDE support but the code is wildly different and we don't use it yet in JRuby
<rtyler>
enebo: jruby-mains means the jruby-gradle toolchain isn't providing some separate (and probably wrong) runtime environment/startup
shellac has joined #jruby
<mkristian>
headius, JRubyMain is the actual main. the other three JarMain and ExtractingMain and WarMain just uses the JRubyMain after preparing how to launch jruby.
<headius>
mkristian: mmm ok
<headius>
eregon: they did?
<headius>
I suggested it but never got back to working with them
<headius>
what I have I hacked together
<headius>
any improvements are fine
<enebo>
ok I think my confusion was how application.jar is made and thinking a tool could help but that is just a separate activity you have to know how to do
<mkristian>
headius, currently a runnable war just unpacks jruby-mains and adds it to war file and I just can bit the complete jruby-mains jar to do so without cherry picking the classes I need.
<eregon>
ok :) yeah, have a look at their test/lib/test/unit.rb history if you feel curious
<mkristian>
jruby-mains is small enough for this
<headius>
mkristian: ok, I understand
<rtyler>
mkristian: if these classes were in jruby-complete, and I loaded new versions of those classes into my classpath, would the new overwrite the old?
<rtyler>
i.e. is there any downside to distributing as a jar and in jruby-complete?
<eregon>
headius: and thanks for the stdlib update!
<JRubyGithub>
[jruby] eregon pushed 2 new commits to master: http://git.io/vfJ7y
JRubyGithub has left #jruby [#jruby]
<headius>
eregon: easy one!
JRubyGithub has joined #jruby
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
[jruby] eregon closed issue #2838: [Truffle] Method not added during instance_eval for MRI Test Excludes http://git.io/vv6md
<eregon>
headius: yeah :)
kfpratt has quit [Remote host closed the connection]
donValentin has quit [Quit: donValentin]
<enebo>
mkristian: jar-dependencies. I have a feature request
<enebo>
mkristian: Could the vendoring step have an option to be made as a dev-mode bundling?
<enebo>
mkristian: For image-voodoo I do not want to depend on mvn to be installed for people to install it
ypasmk_ has joined #jruby
<enebo>
mkristian: right now I manually vendor the jars I am using
<headius>
there's some unifying tool here we have never quite had
<headius>
there's so many different ways people structure apps though :-\
ypasmk has quit [Ping timeout: 256 seconds]
<mkristian>
enebo, so jruby-openssl does do this - embed the jars before building the gem. ```bundle install``` with reference to you gemspec should vendor those jars into
<mkristian>
the lib directory
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mkristian>
enebo, but for this jar-dependencies needs to be development gem not runtime. the runtime bit triggers the mvn
<eonwe>
headius: (re: autoloading) at least in our case we get the same file loaded twice, once by require and second time by rails loading it. I haven't really looked into the issue myself so I can get my colleague open a clean issue about it
<headius>
eonwe: ok...I fixed that on master and may have fixed for 1.7.20 as well
<headius>
do you have cycles to test 1.7 head?
<mkristian>
enebo, but if mvn is not installed then the post install phase will first install ruby-maven and then use it. well, it still uses maven and it first use does trigger loads of downloads in the background
<enebo>
mkristian: ok. I understood all of that I just need to remember it once I get around to image_voodoo again
<enebo>
mkristian: on gem install?
pierreatkillbill has quit [Read error: Connection reset by peer]
<eonwe>
yeah, that was fixed in the master, but is it in 1.7.20? Or what is 1.7.20 actually, the head of 1.7-branch?
<mkristian>
yes on gem install
<headius>
hmm, maybe not in 1.7
pierreatkillbill has joined #jruby
<headius>
eonwe: we will fix for 1.7.20
<enebo>
mkristian: oh well that is a deal breaker for me using it then
<headius>
enebo: ^
<eonwe>
headius: oki, that's nice
<enebo>
headius: yay
<headius>
I think that's next on my agenda then
<headius>
unless you have something else pre2-related for me
pitr-ch has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<mkristian>
enebo, but only if jar-dependencies is a runtime dependency. I do everything so you will use it
<enebo>
mkristian: so since I would only use it dev time it is fine
<mkristian>
but you come with jars embedded inside the gem which is OK if it is only one or two jars
<enebo>
mkristian: as a dev dependency it will vendor into my local repo and I can package it and it will load without needing to hit maven
<enebo>
mkristian: it has no transitive deps
<enebo>
mkristian: these are two standalone jars
<mkristian>
enebo, this is the idea.
<enebo>
mkristian: ok
<enebo>
mkristian: I will try hopefully some time this week
<pierreatkillbill>
Is there an update on a release date for 1.7.20?
iamjarvo has joined #jruby
iamjarvo has quit [Max SendQ exceeded]
<mkristian>
enebo, please have a look at jruby-openssl on how to require the jars so it works for older jruby versions
<enebo>
mkristian: ok will do
iamjarvo has joined #jruby
<enebo>
pierreatkillbill: hopefully at beginning of next week. pre2 will be out in a day and then we will spend effort finalizing blockers for 1.7.20
<pierreatkillbill>
enebo: great, thanks!
<mkristian>
rtyler, about the classpath question. the problem is that it is depends on the classpath order. for example WEB-INF/lib is basically the classpath but the order depends can vary from servlet container to servlet container. never a good idea to the same classes twice on the classpath or classloader hierachy
<headius>
eonwe: do you have a way to reproduce your double-load case?
<headius>
enebo: maybe I should pull RG 2.4.5 into 1.7 and just start working through any issues
<headius>
it and rails should hit all the double-loading and canonical path issues I fixed on master
<enebo>
headius: yesh
<enebo>
YESH
<enebo>
headius: It is our main blocker really
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<headius>
ok
<enebo>
headius: which is probably same problem as autoload when you get right down to it
<headius>
I may have to go underground for this today then...this code is even worse in 1.7
donV has joined #jruby
<enebo>
headius: so I am trying to solve nirvdrum issue
<nirvdrum>
Antiarc: What was the context for the for stuff again?
<Antiarc>
nirvdrum: Someone asked a stackoverflow question about which was faster
<Antiarc>
I benchmarked it in MRI to answer, then was curious about jruby's relative perf
<nirvdrum>
Ahh, that's what I thought.
<nirvdrum>
I was just hoping there was something more substantive to it ;-)
<chrisseaton>
Antiarc: these all *should* compile to nothing on Truffle, but apparently they don't yet - our compilation strategy doesn't always interact will with benchmark/ips yet
<Antiarc>
nirvdrum: Nah, just mindless microbenchmarks :)
<chrisseaton>
Yeah - how fast can I run this code that produces no value and has no side effects
<Antiarc>
I only mentioned it because the relative change in between 1.7 and head was interesting
mitchellhenke has joined #jruby
subbu is now known as subbu|lunch
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] bjfish pushed 1 new commit to master: http://git.io/vfTnS
<nirvdrum>
headius: Did you say you had the resources to set up a Windows CI server now?
iamjarvo has quit [Max SendQ exceeded]
<headius>
yes, either using a license I got through red hat or via one of the windows cloud services
iamjarvo has joined #jruby
<nirvdrum>
Does CloudBees support that?
iamjarvo_ has joined #jruby
iamjarvo_ has quit [Max SendQ exceeded]
<headius>
hmm, I'm not sure
iamjarvo_ has joined #jruby
mkristian has quit [Ping timeout: 256 seconds]
lanceball is now known as lance|afk
iamjarvo has quit [Ping timeout: 245 seconds]
iamjarvo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dinfuehr has joined #jruby
kritter has joined #jruby
zorak8 has quit [Read error: Connection reset by peer]
<kritter>
hey guys, anyone here ever tried programming a multithreaded SSL-Server with JRuby?
<kritter>
I can't wrap my hand around how to do it best
zorak8 has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
<headius>
it's pretty hard with the way SSLSocket is made
<headius>
you can't properly select and such
<kritter>
yeah, at the moment I'm looping in a management thread, waiting for socket = sslserver.accept to happen and creating 2 threads afterwards
rsim has joined #jruby
<kritter>
one for incoming, one for outgoing
<kritter>
that's the way it would suit my scenario best
<kritter>
but I have to fight with old, already closed sockets being used in those threads and it hinders my progress greatly :D
iamjarvo has joined #jruby
subbu|lunch is now known as subbu
lance|afk is now known as lanceball
<headius>
hmmm yeah
kares has quit [Ping timeout: 244 seconds]
<headius>
SSLSocket has a lot of internal buffering that complicates this
<kritter>
aye, that seems to be true
<mberg>
What about a framework like MINA? (Note: not an expert by any means; somewhat familiar since that's what Zimbra users for their POP, IMAP and LMTP implementations.)
<kritter>
not gonna work in my case, I'm stuck with JRuby and its possibilites
<headius>
yeah calling out to a JVM lib that does a better job with multithreaded SSL would work
<kritter>
my code should ideally run under either JRuby or Ruby
<kritter>
yeah, that might be an option
<kritter>
*sigh*
<mberg>
Doesn't work if you need MRI support, but it works fine under JRuby.
<mberg>
(I'm actually doing a small daemon right now. No SSL, but I'm pretty sure you just need to configure and insert an SSLFilter into the filter chain.)
<kritter>
I'll figure out a way to check if Ruby or JRuby is running :D
<kritter>
that sounds interesting
<mberg>
Think there is a RUBY_ENGINE constant, if memory serves. I'd have to google to be sure.
<nirvdrum>
I usually use: defined?(JRUBY_VERSION)
<mberg>
I largely use JRuby as a more convient way to use JVM libraries these days. Generally need the performance or robustness.
<headius>
kritter: another option might be nio4r but I'm not sure if it handles ssl at all
<headius>
it tries to mimic io reactor APIs from JDK on Ruby
tcrawley-away is now known as tcrawley
<kritter>
well, I'm grasping for everything at this point
<kritter>
so thank you anyway, headius :)
<kritter>
will look into that
<headius>
ok
<kritter>
nio4r seems to be too far down the stack
<mberg>
My current project is crawling through five billion objects in a 400 node storage cloud, looking for references to them across ~ 12,000 databases.
<mberg>
After that I may kneecap the people responsible for the bugs that lost the object references in the first place. :P
_djbkd has quit [Remote host closed the connection]
<headius>
hah nice
anaeem1 has quit [Remote host closed the connection]
subbu is now known as subbu|busy
tcrawley is now known as tcrawley-away
<mberg>
Definitely one task I'm glad for JRuby. I can't imagine how a pure ruby bloom filter implementation would perform.
<chrisseaton>
mberg: that's a challenge I'd take on
<mberg>
It's actually kind of fun. And it gave me an excuse to spend work ours reading interesting papers on how network folk are handling IPv6, since that's also a large, potentially sparse keyspace.
rsim has quit [Quit: Leaving.]
<chrisseaton>
Is the Java bloom filter library you're using publicly available?
e_dub has joined #jruby
<mberg>
Right now just using Guava, which seems to perform Well Enough.
skade has joined #jruby
erikhatcher has joined #jruby
_djbkd has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
mitchellhenke has quit [Quit: Computer has gone to sleep.]
bbrowning_away is now known as bbrowning
Aethenelle has joined #jruby
mitchellhenke has joined #jruby
x1337807x has quit [Ping timeout: 265 seconds]
erikhatcher has quit [Quit: erikhatcher]
pierreatkillbill has quit [Ping timeout: 250 seconds]