fidothe has quit [Read error: Connection reset by peer]
amdprophet has quit [Read error: Connection reset by peer]
olleolleolle has quit [Read error: Connection reset by peer]
asarih has quit [Read error: Connection reset by peer]
knowtheory has quit [Ping timeout: 252 seconds]
lopex has quit [Ping timeout: 252 seconds]
mccraig has quit [Read error: Connection reset by peer]
guilleiguaran__ has quit [Write error: Connection reset by peer]
Scorchin has quit [Read error: Connection reset by peer]
bruceadams has quit [Read error: Connection reset by peer]
Guest85414______ has quit [Read error: Connection reset by peer]
chrisseaton has quit [Read error: Connection reset by peer]
jeregrine has quit [Read error: Connection reset by peer]
mjc_ has quit [Read error: Connection reset by peer]
AckZ has quit [Read error: Connection reset by peer]
aemadrid has quit [Read error: Connection reset by peer]
n1ftyn8_ has quit [Read error: Connection reset by peer]
zph has quit [Write error: Connection reset by peer]
bffff_ has quit [Write error: Connection reset by peer]
flavorjones has quit [Read error: Connection reset by peer]
amdprophet has joined #jruby
olleolleolle has joined #jruby
fidothe has joined #jruby
Scorchin has joined #jruby
bruceadams has joined #jruby
chrisseaton has joined #jruby
jeregrine has joined #jruby
mjelen has joined #jruby
n1ftyn8_ has joined #jruby
mccraig has joined #jruby
guilleiguaran__ has joined #jruby
aemadrid has joined #jruby
zph has joined #jruby
lopex has joined #jruby
Guest85414______ has joined #jruby
knowtheory has joined #jruby
rsim has joined #jruby
mjc_ has joined #jruby
rsim1 has joined #jruby
flavorjones has joined #jruby
AckZ has joined #jruby
bffff_ has joined #jruby
rsim has quit [Ping timeout: 258 seconds]
asarih has joined #jruby
pitr-ch has quit [Ping timeout: 264 seconds]
shellac has joined #jruby
pitr-ch has joined #jruby
vtunka has joined #jruby
donValentin has quit [Quit: donValentin]
DomKM has joined #jruby
pitr-ch has quit [Ping timeout: 256 seconds]
mdedetrich has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bffff_ has quit [Quit: Connection closed for inactivity]
donV has joined #jruby
mdedetrich has joined #jruby
mdedetrich has quit [Client Quit]
donV has quit [Quit: donV]
pgokeeffe has quit [Quit: pgokeeffe]
donV has joined #jruby
camlow325 has joined #jruby
pitr-ch has joined #jruby
camlow325 has quit [Ping timeout: 240 seconds]
arturaz has joined #jruby
arturaz has quit [Client Quit]
pitr-ch has quit [Ping timeout: 265 seconds]
pitr-ch has joined #jruby
cristianrasch has joined #jruby
vtunka has quit [Quit: Leaving]
yfeldblum has quit [Ping timeout: 248 seconds]
donV has quit [Quit: donV]
cristianrasch has quit [Quit: Leaving]
mjelen has quit [Remote host closed the connection]
dinfuehr has joined #jruby
pitr-ch has quit [Ping timeout: 256 seconds]
donV has joined #jruby
dinfuehr has quit [Ping timeout: 240 seconds]
cristianrasch has joined #jruby
tcrawley-away is now known as tcrawley
vtunka has joined #jruby
nirvdrum has joined #jruby
bbrowning has joined #jruby
Locke23rus has joined #jruby
<donV>
kares: I see the tests are run with PostgreSQL 9.1. Locally I run with 9.4. That enables a lot more tests, and many fail. Over time we should change travis to run with PG 9.4, but not until we have green tests for it :)
ivan\ has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
nirvdrum has quit [Remote host closed the connection]
vtunka has quit [Quit: Leaving]
dinfuehr has joined #jruby
vtunka has joined #jruby
ivan\ has joined #jruby
dinfuehr has quit [Ping timeout: 248 seconds]
brightball has joined #jruby
rsim1 has quit [Quit: Leaving.]
aramisbear has joined #jruby
brightball has quit [Ping timeout: 264 seconds]
lance|afk is now known as lanceball
benlovell has joined #jruby
vtunka has quit [Quit: Leaving]
brightball has joined #jruby
kfpratt has joined #jruby
pitr-ch has joined #jruby
pitr-ch has quit [Client Quit]
colinsurprenant has joined #jruby
vtunka has joined #jruby
mje113 has joined #jruby
benlovel1 has joined #jruby
benlovell has quit [Ping timeout: 252 seconds]
nirvdrum has joined #jruby
bffff_ has joined #jruby
dinfuehr has joined #jruby
colinsurprenant has quit [Quit: colinsurprenant]
benlovel1 has quit [Ping timeout: 264 seconds]
benlovell has joined #jruby
vtunka has quit [Quit: Leaving]
dinfuehr has quit [Ping timeout: 240 seconds]
vtunka has joined #jruby
benlovell has quit [Ping timeout: 246 seconds]
pitr-ch has joined #jruby
havenwood has joined #jruby
bjfish2 has joined #jruby
<kares>
donV: k ... we just use whatever travis has by default
enebo has joined #jruby
brightball has quit [Quit: Leaving...]
pitr-ch has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
colinsurprenant has joined #jruby
pitr-ch has joined #jruby
pitr-ch has quit [Client Quit]
pitr-ch has joined #jruby
enebo_ has joined #jruby
colinsurprenant_ has joined #jruby
bruceadams_ has joined #jruby
Locke23rus has quit [Ping timeout: 250 seconds]
nateberkopec has joined #jruby
Locke23rus has joined #jruby
lopex_ has joined #jruby
zph_ has joined #jruby
donValentin has joined #jruby
rtyler_ has joined #jruby
joevandy1 has joined #jruby
donV has quit [Ping timeout: 248 seconds]
zph has quit [Ping timeout: 248 seconds]
Guest50994 has quit [Ping timeout: 248 seconds]
enebo has quit [Ping timeout: 248 seconds]
lopex has quit [Ping timeout: 248 seconds]
bruceadams has quit [Ping timeout: 248 seconds]
joast has quit [Ping timeout: 248 seconds]
rtyler has quit [Ping timeout: 248 seconds]
colinsurprenant has quit [Ping timeout: 248 seconds]
joevandyk has quit [Ping timeout: 248 seconds]
emakris has quit [Ping timeout: 248 seconds]
yipdw has quit [Ping timeout: 248 seconds]
yipdw has joined #jruby
bf4 has joined #jruby
yipdw has joined #jruby
colinsurprenant_ is now known as colinsurprenant
enebo_ is now known as enebo
yipdw has quit [Changing host]
bf4 is now known as Guest6069
mkristian has joined #jruby
emakris has joined #jruby
bruceadams_ is now known as bruceadams
lopex_ is now known as lopex
zph_ is now known as zph
pitr-ch has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dinfuehr has joined #jruby
benlovell has joined #jruby
dabradley has quit [Quit: WeeChat 0.4.2]
dinfuehr has quit [Ping timeout: 250 seconds]
mdedetrich has joined #jruby
benlovell has quit [Ping timeout: 252 seconds]
joast has joined #jruby
dabradley has joined #jruby
pitr-ch has joined #jruby
chamila has joined #jruby
mjelen has joined #jruby
DomKM has quit [Quit: Connection closed for inactivity]
mjelen_ has joined #jruby
pitr-ch has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<enebo>
mkristian: howdy
<mkristian>
hi
<enebo>
mkristian: I am tinkering with animationloop but I wondered if this problem is related to us removing . from classpath?
mjelen has quit [Read error: Connection reset by peer]
<mkristian>
we did remove "." from the load_path. not sure if this is related. I still unclear what is going wrong but did not actually start checking out this project
mjelen_ has quit [Remote host closed the connection]
vtunka has quit [Quit: Leaving]
mjelen has joined #jruby
<mkristian>
yes. maybe some jars are not found because of the missing "."
<mkristian>
but that should give an error when requiring this jar
<enebo>
mkristian: yeah
<enebo>
mkristian: I just started looking but I feel we need to block on 9k due to this since ruby-processing is a pretty popular project using JRuby
<mkristian>
will give also have a look now
<enebo>
mkristian: thanks. I feel like you will figure this out faster than me too :P
camlow325 has joined #jruby
camlow325 has quit [Remote host closed the connection]
camlow325 has joined #jruby
camlow325 has quit [Client Quit]
dfr has joined #jruby
pitr-ch has joined #jruby
rtyler_ is now known as rtyler
<mberg>
Herm. So zimbra ends up importing a jline from jython? That seems to be the only jar containing it. At least on this old ass 7.2 install I'm working on.
camlow325 has joined #jruby
<nirvdrum>
enebo: Is today the day?
<enebo>
nirvdrum: at least a processing bug we should figure out
<enebo>
nirvdrum: http.rb has one bug with a NoMethodError but I don’t know if that is serious enough or not
<enebo>
nirvdrum: but needless to say we got some late reports on some popular libs
<mberg>
Oh, whoops, wrong channel for that one. :/
<nirvdrum>
enebo: Sucky.
<enebo>
nirvdrum: yeah but it happens and I feel better solving this processing issue before final release than discovering afterwards
dinfuehr has joined #jruby
rsim has joined #jruby
<nirvdrum>
enebo: Well, this is why I thought a Friday release would be problematic. Invariably people haven't been testing the RCs :-/
<enebo>
nirvdrum: yeah and to be fair I never release on Fridays but I want people to think so to get it all worked out
<enebo>
nirvdrum: at least I don’t think we have in a long time
<nirvdrum>
Heh.
dinfuehr has quit [Ping timeout: 240 seconds]
mjelen_ has joined #jruby
_djbkd has joined #jruby
<enebo>
nirvdrum: to me a release mens getting all bits in a releasable state vs actually putting the bits up and announcing it
<enebo>
the corollary is we need windows CI :)
mjelen has quit [Ping timeout: 244 seconds]
_djbkd has quit [Remote host closed the connection]
pitr-ch has quit [Ping timeout: 244 seconds]
<rtyler>
moinmoin
ddarkpassenger has joined #jruby
tvo has joined #jruby
tvo has joined #jruby
pietr0 has joined #jruby
<headius>
yo yo yo
shellac has quit [Quit: Ex-Chat]
<nirvdrum>
Howdy.
benlovell has joined #jruby
mdedetrich has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<rtyler>
kares: have you started tinkering with netty-rack?
benlovell has quit [Ping timeout: 244 seconds]
mjelen_ has quit [Remote host closed the connection]
<mkristian>
enebo, I got the sketch working with two minimal patches on the animationloop. but 9k really acts very different regarding these javax.media.opengl.awt.* classes - I can produce all kind of java.lang.NoClassDefFoundError
<olleolleolle>
Anyone has any idea what could be wrong?
<headius>
olleolleolle: what jruby ver?
<headius>
1.7 something looks like
<olleolleolle>
Sorry, 1.7.21
<olleolleolle>
This is running from the complete-jar distribution, if that matters.
<headius>
probably not...could be a straightforward algorithm bug or something with concurrency
<headius>
reproducible?
<olleolleolle>
Yes.
<enebo>
mkristian: headius: kares: So this also seems to be giving same visiilibty error on my 1.7 build
<headius>
maybe they changed the visibility recently?
<enebo>
although I did just compile this with 9k
<enebo>
hmm
<headius>
olleolleolle: ok, open a bug and provide whatever you can
<enebo>
let me recompile it back with 1.7
<headius>
NPEs are usually not hard to diagnose if we can repro
<olleolleolle>
headius: Cool, we will try to make a minimal repro in a bug report.
dinfuehr has joined #jruby
<headius>
thank you!
dinfuehr has quit [Ping timeout: 246 seconds]
<headius>
olleolleolle: if it's possible to test on 9k, we'd also appreciate that...pushing for release this week and it would be good to know if it's broken there too
_djbkd has quit [Remote host closed the connection]
<headius>
hmm
<headius>
that line shouldn't be able to NPE
<headius>
may be off because I'm looking at head
<olleolleolle>
headius: Does head have a jar distribution?
<headius>
ahh yeah, off by a couple lines
<headius>
olleolleolle: ci.jruby.org
_djbkd has joined #jruby
<headius>
oh but we don't have a complete jar there
<headius>
we should add that
<headius>
enebo: -Pcomplete builds complete jar right?
<enebo>
headius: I think so yeah
donV has joined #jruby
<headius>
olleolleolle: clone jruby and run ./mnvw -Pcomplete
<headius>
er ./mvnw
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius opened issue #3154: Add complete jar and other release artifacts to ci.jruby.org builds http://git.io/vmbNS
JRubyGithub has left #jruby [#jruby]
bb010g has joined #jruby
<headius>
enebo: this is weird
<headius>
HTTP::Request does not appear to define headers as a method but it's there eventuall
<enebo>
It does a mixin doesn’t it?
<headius>
I can't find `headers` outside comments *anywhere* in net/http
<enebo>
include HTTP::Headers::Mixin
<headius>
I mean in net/*
xardion has quit [Ping timeout: 265 seconds]
<headius>
oh I see
<headius>
bingo
<headius>
it's not a net/http request, it's their request object
<headius>
ok
<enebo>
ok
xardion has joined #jruby
tenderlove has joined #jruby
<headius>
bingo bingo
<headius>
headers method is added to HTTP::Request *after* they create the DelegateClass wrapper for it
<headius>
so DelegateClass doesn't define a direct method and goes through method_missing
<headius>
from there it may be a respond_to? protocol problem with a double-delegated object and m_m
bjfish2 has quit [Quit: bjfish2]
<headius>
I CAN HAZ REPRO
<enebo>
yuck so it will end up coming back to IR and respond_to?
<enebo>
hmmm ok starting to freak out…this seems to happen with 1.7.20 too
<mkristian>
enebo, headius this method problem. it is the same with juby-9k and 1.7 BUT with 1.7 I can load all the jars with require and then it works. which fails with 9k
<headius>
enebo: added comment
<headius>
with repro
<headius>
I am pretty sure it is a respond_to? protocol issue exposed by double-delegation and delegation via method_missing
<enebo>
headius: ok…I guess technically we should have closed that issue and made a new one but we can always change the subject
<headius>
yeah I'll do that since the original issue wasn't still broken
<headius>
hijacking but whatever
<enebo>
headius: so we expose it as instr but we also use it internally or something like that?
<headius>
I'm not sure
<enebo>
mkristian: ah thanks…yeah once I removed the 9k logic he added this works
<enebo>
mkristian: so this is not a regression but because it is loading differently it exposed this behavior
<mkristian>
yes
<enebo>
mkristian: so for the sake of this issue I think we need to understand why we need to refer to a class before performing the require
<headius>
enebo: I can take this through to completion
<enebo>
headius: you mean fix it
<headius>
the smaller repro based on my comment is p MyDel.new(MyClass.new).respond_to? :each_with_index
<headius>
we return false, MRI returns true
<headius>
yes
<enebo>
headius: cool. I can jump on if there is something where my head will help
<headius>
I mean fix it
<mkristian>
enebo, this I just added to make both jruby-9k and jruby-17 cases to work. you do not want to require a jar which is already on the classpath
<headius>
ok
blaines_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<mkristian>
enebo, I updated the gist which is reduced to add ALL jars to classpath and this public identifier on the code. with this the runner works for both 9k and 1.7
<enebo>
mkristian: Assuming we do not load the jar in the CL it seems ‘require_relative 'lib/rpextras’’ should still be workable
<enebo>
mkristian: yeah but I want to know if what he had is still reasonable and possible
<enebo>
mkristian: naively I don’t see why I can no longer require a jar
<enebo>
mkristian: I guess I have done something similar to what he is doing (I think) on more than one occasion
blaines has joined #jruby
<headius>
olleolleolle: ok...toss all this in a bug
<mkristian>
you mean why it is not working in 9k when all the jars get required ? no idea and I will dig more into this. any simpler framework with similar error is helpful :)
<mkristian>
enebo, -^
<enebo>
mkristian: yeah ok.
<enebo>
mkristian: sorry I thought you were suggesting this is the solution
_djbkd has joined #jruby
<mkristian>
enebo, not a solution but a working work-around. jruby-1.7 works without the runner.rb and that is the goal :)
<enebo>
mkristian: ah yeah true…this should just require them all and work
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] olleolleolle opened issue #3155: NullPointerException on compacting an Array http://git.io/vmNtV
JRubyGithub has left #jruby [#jruby]
<olleolleolle>
headius: thanks for being here, digging deep.
<enebo>
headius: what is weird is I knew some methods had changed visibility at some point but how much of this will cascade
<headius>
I'm not sure the exact mechanism that breaks, but because the base respond_to_missing? isn't private, DelegateClass decides it should be delegated
<enebo>
headius: I mean do we have code which is assuming we can dispatch to a non-private version of the builtin?
<headius>
that means it skips Delegate's respond_to_missing? that's aware of the wrapped object's method table
<headius>
then if you fall into m_m logic it doesn't see it when calling respond_to? and boom
<enebo>
wow
<headius>
it ends up using base respond_to_missing? because it bypasses Delegate's
<headius>
e.g. pretty effing fragile
<enebo>
well that is the definition of fragile
<enebo>
hah yeah
<headius>
er, i.e.
<headius>
I'll see if I can come up with a clean spec for this
<enebo>
on the one hand they optimized typing away by using visibility
<headius>
yeah
<enebo>
but it is really limiting if you want to add methods which should not be delegated in the future
<enebo>
Perhaps the language is so far along that will no longer happen
<enebo>
OTOH user-defined methods will be confusing
<enebo>
anyways. I guess respond_to_missing? itself is not called internally in too many places
<enebo>
bascally in a some protocol helper methods
<headius>
I added a nice explanation in the bug...I understand the whole mechanism now
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian closed issue #3065: make the IsolatedScriptingContainer work from ruby itself and set GEM_HOME as well http://git.io/vLg7F
JRubyGithub has left #jruby [#jruby]
<headius>
the "magic" private behavior of ruby-based respond_to_missing? comes into play here too
<headius>
it doesn't show up in Delegate's public API because of that special casing in the runtime, so it doesn't get subtracted from the incoming class's methods
<headius>
magic magic magic
<headius>
we probably should have made module = true in JRubyMethod default to private, my bad
<enebo>
headius: I guess on one hand most people never realize how magical it is
<headius>
right...it is an internal protocol
blaines has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius>
but this shows how fragile it is relying on visibility to know if it's there or not
<enebo>
headius: yeah and so every non-private marked private method in our codebase is broken with delegate
<headius>
that's right
<headius>
but the others aren't as important
<headius>
(we should still audit them of course)
mike___1234 has quit [Ping timeout: 240 seconds]
<enebo>
yeah delegating to bigdecimal might not be common
<headius>
I should say the others aren't as fatal
<headius>
enebo: actually that's not a problem... Delegate extends BasicObject so only those methods are a concern
<headius>
oh but no, your'e right
<headius>
because it gets the source list of methods from the target
<headius>
but I guess it's only a problem if they disagree with Delegate's public API
<enebo>
headius: when it comes down to it this will largely get noticed by container types and by common included modules
<headius>
let's see if we have any tags to remove from this...I'll wager we don't
<enebo>
headius: but writing yet another methods in the system script might help us
<enebo>
headius: in fact I seem to think eregon_ wrote one a couple of years back
<enebo>
coffee
yfeldblum has joined #jruby
<headius>
enebo: yeah that might not be a bad idea
<headius>
specific to JRuby since we do have some extra Kernel methods
<headius>
also just occurred to me that java, javax, etc methods should probably be private
<headius>
heh, there's no DelegateClass specs at all
<headius>
there's a test in MRI's suite though
xkickflip has quit [Quit: xkickflip]
<headius>
I will add a spec anyway to be a bit more specific
mike___1234 has joined #jruby
<bbrowning>
mkristian: enebo: I know it doesn't really help, but I have a NoClassDefFoundError I can only reproduce on 9k as well
<bbrowning>
and only when the program is started using jruby's Main
<enebo>
bbrowning: solve it!!!!
<mkristian>
:)
<enebo>
bbrowning: This is scaring the crap out of me atm
<headius>
hmm, what's the proper way to run specs under truffle now?
<headius>
I have not done it in a long time
<chrisseaton>
jt test fast
<mkristian>
bbrowning, it is easy to reproduce - without downloading whole TB ?
<chrisseaton>
tool/jt.rb
slyphon has joined #jruby
<bbrowning>
mkristian: hmm - you'd need at least some TB4 gems, but I think I can make a simple reproducer app
slyphon has quit [Client Quit]
<mkristian>
cool - thanx
<headius>
chrisseaton: thank you!
<headius>
adding a spec, need to check it
dinfuehr has joined #jruby
dinfuehr has quit [Ping timeout: 256 seconds]
nirvdrum has quit [Ping timeout: 264 seconds]
bjfish2 has joined #jruby
<headius>
chrisseaton: do you want bugs for new tags or what?
<headius>
for jruby proper we typically consider the tag the bug
<chrisseaton>
just tags for now thanks
<headius>
ok
<chrisseaton>
when we get to 99% or something we might start creating bugs
<headius>
yeah
blaines has joined #jruby
nirvdrum has joined #jruby
blaines has quit [Ping timeout: 244 seconds]
blaines has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius closed issue #3151: Twitter and http.rb gem specs fail on JRuby 9.0.0.0.pre2 and greater http://git.io/vmSwy
JRubyGithub has left #jruby [#jruby]
<headius>
enebo: ^
<headius>
bbiab
<enebo>
headius: cool although twitter did not fail any specs
<bbrowning>
mkristian: enebo: hey - maybe I did solve it? The problem seems to only happen when the main jruby program exits but other threads are still running
<bbrowning>
s/exits/finishes/
<bbrowning>
ie main.rb does some stuff that calls into java libs creating other threads and whatnot
<bbrowning>
if I add a 'sleep 15' to the end of main.rb everything's fine - w/o the sleep, I start to get NCDFE
<bbrowning>
so user error, perhaps? works in 1.7, but that just might be accidental
<enebo>
bbrowning: OMFG!!!!
<enebo>
bbrowning: adding a sleep also fixes ruby-processing
<enebo>
mkristian: ^
<bbrowning>
so same issue I guess - when the script being run finishes but the JVM hangs around things go south
<mkristian>
enebo, really - a sleep where ?
<enebo>
mkristian: put at end of fail.rb
<enebo>
mkristian: this launch is async but we walk off end of script and start shutting down
<enebo>
mkristian: so nothing loads
<enebo>
mkristian: well not properly
<bbrowning>
same thing in my case - I have an async jms message listener that gets called only after the script finishes
<enebo>
So I am confused how this changed between master and jruby-1_7
<mkristian>
cool - even the sketch.rb is running with this sleep
<bbrowning>
are URLs added and removed dynamically from the jrubyclassloader? during teardown, does it walk all required jars and remove them from the classloader?
<bbrowning>
that's the only thing I can think of that would cause NCDFE from java code like this
<mkristian>
so this is the third time that adding a sleep does help to fix classloader problems
<mkristian>
I think the teardown call the close on this classloader
<enebo>
tearDownClassLoader
<Antiarc>
FWIW when I restart my app I get all kinds of undefined constant issues for the first few seconds of execution
<Antiarc>
1.7.20
<Antiarc>
I assumed I was just doing something OoO WRT my loading though
<Antiarc>
And it all corrects itself and does its thing just fine
<Antiarc>
(high concurrency webcrawler, actor model with celluloid)
<mkristian>
enebo, there is this unloadJDBCDriver hook when the jrubyClassloader gets a tearDown
<enebo>
mkristian: but these are the same between 1.7 and 9k other than having a new method holding the old logic
<mkristian>
no - 9k also does a close on the classloader itself. just checking if this is the culprit
xkickflip has joined #jruby
<mkristian>
yes the close is creating the problems
<enebo>
mkristian: ok so on 1.7 tearDown on JRubyClassLoader has no close but has the JDBC driver hack
<bbrowning>
mkristian: I can confirm removing the close fixes my problem as well.
<enebo>
mkristian: if we remove the close on a CLI invocation the CL will still get cleaned up so this is more an embedding scenario right?
<enebo>
mkristian: perhaps ScriptingContainer or a wrapper should perform this close and not bake it into internals or Ruby
<mkristian>
yes. right the embedded case was the reason I added this
<bbrowning>
is the systemExit boolean flag the thing we need?
<enebo>
So the base problem is that we execute a main script but launch code which runs async later but not from a Ruby thread but a Java thread
<bbrowning>
enebo: yeah
<enebo>
Since we have no way of detecting this (do we?) I do not think we can know that we need to close the CL
<enebo>
we could definitely change this behavior based on whether it is CLI invocation or not I guess
<mkristian>
the ScriptingContainer also has a terminate which does call the tearDown on the runtime. there we also could close the classloader
<enebo>
mkristian: that might be the right fix. I can see why this is desirable but I don’t tihnk we can detect the particular case we are seeing
<enebo>
this == what we have atm
<mkristian>
ok will do the close inside the SCriptingContainer then
<enebo>
bbrowning: it is so funny we have been debugging this same problem now multiple times and we did not think that it would be the same cause
<bbrowning>
heh yeah
<enebo>
mkristian: ok. great. Thanks for all your time debugging this
<enebo>
concurrent behavior never appears to be what it is
<enebo>
mkristian: is you can also mention the Swing.invokeLater issue in the commit
<mkristian>
will do
goyox86 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
dinfuehr has joined #jruby
tvo has quit [Read error: Connection reset by peer]
tvo has joined #jruby
tvo has quit [Changing host]
tvo has joined #jruby
nirvdrum has quit [Remote host closed the connection]
tvo has quit [Read error: Connection reset by peer]
tvo has joined #jruby
tvo has quit [Changing host]
tvo has joined #jruby
bbrowning is now known as bbrowning_away
tvo has quit [Read error: Connection reset by peer]
tvo has joined #jruby
tvo has quit [Read error: Connection reset by peer]
tvo has joined #jruby
tvo has quit [Changing host]
tvo has joined #jruby
tvo has quit [Read error: Connection reset by peer]
<headius>
usually that means something's double-loading, which would be bad-ish
<Antiarc>
various stuff that should be loaded already, lemme go look
<headius>
cause will vary depending on the library and how the constants are defined
<Antiarc>
uninitialized constant ActiveSupport::TimeWithZone - that's a common one
<Antiarc>
called from activesupport-3.2.22/lib/active_support/core_ext/time/calculations.rb:13
<Antiarc>
Though IIRC AS should be fully loaded before that could be reached
<Antiarc>
Lots of NMEs, too, though those resolve pretty quickly
<Antiarc>
Odd stuff, very hard to reproduce, I'd just chalked it up to a concurrency logic error in the app
<Antiarc>
Only happens when the app is booting up right after all the worker threads start doing their thing
<Antiarc>
Those actors crash and are restarted and everything works fine from then on, so I haven't really pursued it
temporal_ has joined #jruby
kwando has joined #jruby
dabradley has joined #jruby
kwando_ has quit [Ping timeout: 256 seconds]
temporalfox has quit [Ping timeout: 240 seconds]
benlovell has joined #jruby
tvo has quit [Read error: Connection reset by peer]
tvo has joined #jruby
tvo has quit [Changing host]
tvo has joined #jruby
benlovell has quit [Ping timeout: 256 seconds]
nirvdrum has joined #jruby
<headius>
hmmm
<headius>
Antiarc: concurrent loading could definitely be related
<headius>
if it's not happening every time that's most likely the problem
<Antiarc>
This happens on 1-2 boxes out of 50-60 per app restart
<headius>
you could try loading the related libraries outside the threads and see if it consistently goes away
_djbkd has quit [Remote host closed the connection]
<Antiarc>
I believe I am, which is the curious part
<Antiarc>
I'm wondering if the require is finishing before something is available or something
<Antiarc>
The general form is "require everything, instantiate all the actors, start celluloid"
<Antiarc>
I'll see if I can make sure all my loading is happening before threads start up - I've just assumed it was a logic error. If you think it might be a symptom of a jruby bug though I can try to instrument it more finely and work out what's up
<headius>
if it's inconsistent (whether it happens, how it manifests) then it's less likely to be a JRuby bug, but it's still possible
<headius>
well, it's always possible it's a JRuby bug in my book :-)
<headius>
that's my policy
<headius>
"It's probably our fault"
<Antiarc>
haeheh, that's the same reason I haven't raised it
<Antiarc>
"It's probably my fault"
<Antiarc>
I need to try the app out on 9k anyhow
<Antiarc>
Now that we're close to release
<Antiarc>
Not too hard to install jruby-head via RVM and try out a deploy
<headius>
close is an understatement
<Antiarc>
I've been developing on 9k locally for a while
<headius>
if we hadn't gotten some bugs over the weekend we might be releasing today or tomorrow
<Antiarc>
But deploying across several hundred cores is a little bit different workload :)
<headius>
modulo blog.press/noise prep
<Antiarc>
did you ever make any significant headway on the bootup time stuff?
<Antiarc>
That's the most consistent complaint I see from people. Would love to have an answer to it
<chrisseaton>
Antiarc: sorry to hijack with Truffle-talk, but we've got someone working full-time on our static build of JRuby now that does a lot to lower boot time
<chrisseaton>
so we hope to have some results for that this year
<Antiarc>
chrisseaton: Never apologize for hijacking with truffle-talk :D
<Antiarc>
That's exciting!
<Antiarc>
I think that in most realistic Ruby contexts boot time isn't REALLY too much of an issue, but it does make a bad first impression unfortunately
<nirvdrum>
Well, it certainly sucks for TDD.
<chrisseaton>
last time it was working it was running hello-world in the order of 10ms, but that was ages ago and might not apply any more
<Antiarc>
holy cow, you can get the JVM to boot that fast, let alone jruby?
<chrisseaton>
it's not a conventional JVM, it's an ahead of time compiled build of JRuby, statically linked, with no dependency on a JVM
<chrisseaton>
it's just a big ol static executable file
<Antiarc>
Ohhh. Wow, that's even more exciting.
<chrisseaton>
The reason it does well is that things like the lexer and parser are already native code
<Antiarc>
Yup, makes sense
<Antiarc>
I know that lexing and parsing is a huge part of boot time in typical apps right now
Papipo has joined #jruby
<chrisseaton>
I have a recorded talk on it that I need to encode and upload
<Antiarc>
roughly what percentage complete would you say truffle is right now, in terms of language features?
<chrisseaton>
90%
<Antiarc>
So only the last 90% left to go, eh? :)
<headius>
chrisseaton: it's a static VM that only does Ruby though, no? I mean, we can't do substrate + java integration