DomKM has quit [Quit: Connection closed for inactivity]
JohnBat26 has joined #jruby
slyphon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
tenderlove has quit [Quit: Leaving...]
havenwood has quit []
pgokeeffe has quit [Quit: pgokeeffe]
noop has joined #jruby
anaeem1 has joined #jruby
pchalupa has quit [Quit: Computer has gone to sleep.]
anaeem1__ has joined #jruby
anaeem1__ has quit [Remote host closed the connection]
anaeem1 has quit [Ping timeout: 255 seconds]
anaeem1 has joined #jruby
drbobbeaty_ has joined #jruby
drbobbeaty has quit [Read error: Connection reset by peer]
kl has quit [Ping timeout: 256 seconds]
pchalupa has joined #jruby
temporalfox has joined #jruby
josh-k has joined #jruby
elia has joined #jruby
josh-k has quit [Remote host closed the connection]
johnmuhl has quit [Quit: Connection closed for inactivity]
anaeem1 has quit [Quit: Leaving...]
anaeem1_ has joined #jruby
nirvdrum has joined #jruby
anaeem1_ has quit [Remote host closed the connection]
deobalds has joined #jruby
josh-k has joined #jruby
benlovell has joined #jruby
zorak8 has joined #jruby
<temporalfox>
Hi, I need some help on ruby rdoc tool :-)
<temporalfox>
I'm running it via the jruby maven plugin and getting No such file or directory on /META-INF/jruby.home/lib/ruby/shared/rdoc/generator/template/json_index
marr has joined #jruby
<nirvdrum>
temporalfox: The people that could probably best answer that are on US time, so you might have better luck asking again in a few hours.
<temporalfox>
nirvdrum good advice :-)
<temporalfox>
nirvdrum I'll retry if I'll won't have found the reason yet
kl__ has joined #jruby
Hobogrammer has quit [Ping timeout: 256 seconds]
deobalds has quit [Read error: Connection reset by peer]
anaeem1 has joined #jruby
djellemah has joined #jruby
deobalds has joined #jruby
nirvdrum has quit [Ping timeout: 264 seconds]
drbobbeaty has joined #jruby
drbobbeaty has quit [Client Quit]
drbobbeaty_ has quit [Ping timeout: 240 seconds]
drbobbeaty has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
zorak8 has quit [Read error: Connection reset by peer]
deobalds has quit [Ping timeout: 272 seconds]
zorak8 has joined #jruby
deobalds has joined #jruby
zorak8 has quit [Ping timeout: 276 seconds]
deobalds has quit [Ping timeout: 256 seconds]
shellac has joined #jruby
deobalds has joined #jruby
kl__ has quit [Ping timeout: 244 seconds]
vtunka has joined #jruby
mister_solo has joined #jruby
kl has joined #jruby
anaeem1 has quit [Remote host closed the connection]
anaeem1 has joined #jruby
deobalds has quit [Quit: Computer has gone to sleep.]
thsig has joined #jruby
djellemah has quit [Quit: Leaving]
thsig has quit [Remote host closed the connection]
JohnBat26 is now known as JohnBat26|NotHer
JohnBat26|NotHer is now known as JohnBat26
JohnBat26 is now known as JohnBat26|NotHer
thsig has joined #jruby
drbobbeaty has joined #jruby
mister_solo has quit [Ping timeout: 246 seconds]
josh-k has quit [Remote host closed the connection]
multibot_ has quit [Read error: Connection reset by peer]
multibot_ has joined #jruby
Aethenelle has quit [Quit: Aethenelle]
johnmuhl has joined #jruby
bbrowning_away is now known as bbrowning
vtunka has quit [Quit: Leaving]
<headius>
temporalfox: if it runs with a normal jruby install then it may be how we package it for the plugin
<headius>
some Ruby libraries run into unusual issues if they are loaded from within a jar file
<temporalfox>
headius ok, I'm trying yard at the moment it sounds like a modern alternative to rdoc
deobalds has joined #jruby
vtunka has joined #jruby
metadave has joined #jruby
<headius>
temporalfox: ok
calavera has joined #jruby
kl has joined #jruby
rcvalle has joined #jruby
vtunka has quit [Ping timeout: 252 seconds]
vtunka has joined #jruby
metadave has quit [Ping timeout: 240 seconds]
anaeem1 has quit [Remote host closed the connection]
anaeem1 has joined #jruby
colinsurprenant has joined #jruby
colinsurprenant has quit [Client Quit]
anaeem1 has quit [Ping timeout: 264 seconds]
anaeem1 has joined #jruby
zorak8 has quit [Ping timeout: 264 seconds]
anaeem1 has quit [Remote host closed the connection]
colinsurprenant has joined #jruby
anaeem1 has joined #jruby
deobalds has quit [Quit: Computer has gone to sleep.]
anaeem1 has quit [Ping timeout: 272 seconds]
<headius>
guess I'll spend some time today looking at this ThreadGroup#list spec and figuring out why it hangs
<headius>
I dun get it
triple_b has joined #jruby
josh-k_ has quit [Remote host closed the connection]
viking has joined #jruby
metadave has joined #jruby
tcrawley-away is now known as tcrawley
mrmargolis has joined #jruby
Who has joined #jruby
enebo has joined #jruby
slyphon has joined #jruby
<chrisseaton>
headius: the Truffle artefacts will be going up on Maven Central
<temporalfox>
I'm seing many maven plugin for jruby (in torquebox/jruby-maven-plugins) unfortunately I'm not able to find documentation for them, am I missing something ?
<headius>
chrisseaton: very good
iamjarvo has joined #jruby
<headius>
temporalfox: mkristian should be in here later today, he wrote those plugins
<headius>
I'm not sure what's available for docs
<temporalfox>
code completion in intellij :-)
<headius>
you can also check with torquebox guys, they might know since they use them
<headius>
#torquebox etc
e_dub has quit [Quit: e_dub]
noop has quit [Ping timeout: 255 seconds]
mitchellhenke has joined #jruby
<temporalfox>
ok thanks
slyphon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
triple_b has joined #jruby
gregorsc5 has joined #jruby
<enebo>
TIMECOP
slyphon has joined #jruby
nateberkopec has joined #jruby
<Antiarc>
headius: So, I've been working with a friend to chase down some issues related to timeout.rb being able to interrupt an ensure block
<Antiarc>
We all know that timeout is awful, but do you think there's a legitimate case to be made that Thread.raise shouldn't be able to prematurely terminate an ensure?
<Antiarc>
It seems like a bug to me.
<Antiarc>
You can work around it by trapping the timeout exception within your ensure block, duplicating all the ensure work in the inner rescue, and then re-raising the exception, but that only works if your ensure operations are idempotent and you have to do it *everywhere*, which feels very un-rubyish.
<headius>
yeah, it's pretty nasty
nirvdrum has joined #jruby
<headius>
I wonder what it would affect if code downstream from an ensure couldn't be interrupted
<headius>
if you had your whole program running in an ensure it would prevent all interrupts
slyphon has quit [Ping timeout: 240 seconds]
<headius>
I suppose you can sorta do that with handle_interrupts in 2.2... put that around your main script
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
calavera has joined #jruby
vtunka has quit [Quit: Leaving]
Who has quit [Quit: Who]
Who has joined #jruby
vtunka has joined #jruby
subbu has joined #jruby
mister_solo has joined #jruby
mkristian has joined #jruby
thsig has quit [Remote host closed the connection]
e_dub has joined #jruby
<enebo>
finally’s can raise in Java
thsig has joined #jruby
<enebo>
but I suppose control of thread execution is the main issue here
thsig has quit [Read error: Connection reset by peer]
slyphon has joined #jruby
slyphon has quit [Read error: Connection reset by peer]
mattwildig has joined #jruby
slyphon has joined #jruby
anaeem1 has joined #jruby
mister_solo has quit [Ping timeout: 245 seconds]
anaeem1 has quit [Ping timeout: 240 seconds]
gregorsc5 has quit [Quit: Leaving.]
<Antiarc>
Yeah, I'm not saying you shouldn't be able to raise from an ensure, but the problem is that you can raise at arbitrary points in another thread
<Antiarc>
So it's entirely possible to interrupt "ensure" code in ways the author didn't expect
<Antiarc>
This is a *huge* problem in any kind of pooling resource code; you can have resources that fail to get returned to a pool if timeout.rb kills it during the ensure that would check it back in
<Antiarc>
there are open issues on mperham's connection-pool gem and redis-rb WRT this issue, and I know for a fact that mongo-ruby-driver can leak connections because of this issue as well
<Antiarc>
I wouldn't be surprised if it manifests in other places, too
<chrisseaton>
headius: you should get an email about a sparc machine at some point - you might not recognise the address so look out for it
Aethenelle has joined #jruby
dfr|work has quit [Remote host closed the connection]
<Antiarc>
headius: My friend working on it said that handle_interrupt wasn't working on jruby, but he may have been working on 1.7
<Antiarc>
I'll ask him
<headius>
chrisseaton: oh great, thanks
<headius>
Antiarc: I wouldn't be surprised
<headius>
I ported some of the logic but never spent much time testing it
<Antiarc>
I'll see if I can get a failure cast
<headius>
I should add that to release notes
<Antiarc>
case*
<Antiarc>
ah, it was 1.7
<enebo>
Antiarc: which sort of pooling resource is it?
thsig_ has quit [Remote host closed the connection]
<Antiarc>
enebo: the connection-pool gem is a general connection pooling library, lemme find the ticket
<Antiarc>
They're triaging it there, but I've seen this issue come up a number of times, and it feels like since we're kind of stuck with timeout.rb, it might be something that might be a candidate for a language behavior enhancement
<enebo>
Antiarc: I am wondering though how many consumers of this generic lib should actually be using it instead of using the timeouts intrinsic to the resource they are managing
<enebo>
Antiarc: I know it is not universal but IO does have timeout baked into it
<enebo>
It is more of a question than a statement
subbu has quit [Ping timeout: 245 seconds]
<Antiarc>
Yeah, I definitely agree that socket timeouts are preferable, but the problem is that they *only* apply to sockets; if you have extra work not on the socket that you want timeout throttling for, timeout.rb is what people go to
<headius>
enebo: that's definitely the best way...I think they're trying to mitigate cases like web servers/containers that kill misbehaving request threads
<Antiarc>
And that tends to introduce unpredictable behavior
<Antiarc>
I think that *ideally* if an exception were raised from outside the thread, ensure blocks should finish and then raise the exception. If the exception is raised from within the thread, it would raise immediately.
<headius>
container decides to kill a thread taking too long, busts its ensure logic, connection doesn't go back into pool
<headius>
stuff like that
<Antiarc>
but I have no idea how that works WRT implementation
<enebo>
Antiarc: yeah the abstraction is the tempting thing and less work but ultimately on a shaky foundation
<Antiarc>
Well, it's really just that timeout.rb is a little bit like doing surgery with a sledgehammer :)
<enebo>
headius: yeah no doubt that is what they are doing
bbrowning_away is now known as bbrowning
<enebo>
headius: you say that jirb_swing is fixed?
<headius>
Antiarc: a suggestion I made to tenderlove: monkey patch the thread to not have kill/raise :-D
<Antiarc>
Hah!@
<Antiarc>
That's...clever and evil.
<headius>
a more productive answer might be to monkey-patch them to do something less invasive
<enebo>
headius: I see no output other than the prompt
<headius>
enebo: did you rebuild readline?
<Antiarc>
It's just an inherently nasty problem, since not being guaranteed that ensures will run can break *lots* of things in unexpected ways
<enebo>
headius: well I did a dist build?
<Antiarc>
So it feels like something that might be appropriate for a Ruby enhancement
<Antiarc>
Rather than a library fix
<Antiarc>
Even if it was just a change in default behavior, with a flag to switch to current behavior or something
<headius>
Antiarc: it's definitely a nasty problem and it has frustrated me that people didn't get why
<Antiarc>
Would be nice to set threads so that external kill/raise can't break ensures.
<enebo>
headius: although this is me taking src dist and just typing mvn
<enebo>
headius: let me make sure bin dist is right
<headius>
enebo: I think you need to build it separately
<Antiarc>
But that requires knowledge of when you're in an ensure, which takes us back into the language rather than the libs
<headius>
or something?
<headius>
enebo: I hope you don't have to rebuild it for dist :-\
<enebo>
bin dist is broken
<headius>
:'(
<enebo>
So mvn clean deploy -Psonatype-oss-release -Prelease does not generate something
Hobogrammer has joined #jruby
<mkristian>
enebo, ???
JRubyGithub has joined #jruby
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
[jruby] headius opened issue #2487: Dist has gotten too large due to new maven features http://git.io/dFDHDg
<headius>
oh, don't deploy
<headius>
but hmm
<headius>
enebo: running that where?
<enebo>
headius: that is how I generate releases
<headius>
I did get readline to build after installing jruby proper
<headius>
oh ok
<enebo>
headius: if testing works it is already at sonatype can get closed/released
<headius>
I am not clear what's broken
<enebo>
mkristian: jirb_swing is not working and it seems to be related to readline being not built? I don’t know
<headius>
I mean I'm not sure I understand
<headius>
let me confirm the fix
<mkristian>
try addind -Pext to your maven commandline
<headius>
working here
<enebo>
irb(main):001:0> 1
<enebo>
irb(main):002:0>
<enebo>
It looks like this for me
<enebo>
The ‘=> 1’ is missing
<headius>
try mkristian suggestion...it just seems like it didn't build when running dist
<headius>
which obviously needs fixing
<headius>
maybe it just didn't rebuild?
<headius>
oh
<headius>
and clean doesn't clean ext because it's not a module
<enebo>
well I am always in a fresh shallow clone
<headius>
hmm
<enebo>
So it is not that clean is actually neede
<headius>
out of .m2?
<enebo>
The reactor does not show it in the list?
<mkristian>
enebo, even with adding -Pext ?
josh-k has joined #jruby
<enebo>
heh well I didn’t ever do -Pext
<mkristian>
you can also just cd ext;mvn install
<headius>
he suggested -Pext above
<mkristian>
to build those gems
<enebo>
ah ok well I can add that certainly and rerun this
<mkristian>
and then they are in .m2/repository and will be used by the regular build
<enebo>
let me give that a go
dfr|work has joined #jruby
<headius>
I think we need to either make those build unconditionally for dist target or start really managing them as external libs
<enebo>
headius: definitely
<dfr|work>
morning foks
<dfr|work>
*dolks
<dfr|work>
...
<dfr|work>
**folks
<headius>
I can't remember why we pulled them out but never went all the way to separate projects
camlow325 has joined #jruby
<headius>
doesn't seem like we gain much from current setup
<enebo>
yay
<enebo>
[ERROR] Failed to execute goal on project openjdk-truffle: Could not resolve dependencies for project com.headius:openjdk-truffle:jar:0.6: Could not find artifact com.oracle:truffle:jar:0.6 in central (http://repo.maven.apache.org/maven2) -
<enebo>
headius: when was that released?
<headius>
enebo: heh
<headius>
don't build that ext
<headius>
:-D
<mkristian>
please remove <module>truffle</module> from ext/pom.xml
<enebo>
heh ok
<headius>
yeah that is better :-)
<headius>
that will go away soon anyway, chrisseaton mentioned oracle will start pushing to central
<mkristian>
I am sorry - for current build mess.
<mkristian>
will clean up after the release ;)
<headius>
mkristian: we just need to spend some time figuring out how to simplify things
<enebo>
yeah this is all fine
nirvdrum has quit [Ping timeout: 244 seconds]
<headius>
or not using maven to generate dist
<headius>
we have a lot of crazy maven stuff to build our dist right now and I'm not sure I see the value in having maven do it when it gets so complex
metadave has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<headius>
anyway, simplification
<headius>
enebo: looking better now?
<enebo>
headius: well it is building yeah
<headius>
that's a start
<enebo>
I sort of feel like Maven is an awful tool with a good repository and a trusted dependency graph
<headius>
yeah
baroquebobcat has joined #jruby
<enebo>
For our build purposes we don’t use many features of maven either past pushing artifacts. Shade? and whatever stuff is part of pushing to sonatype?
<headius>
yeah, and dependency fetching
<headius>
dist build could just be a rake target
<mkristian>
I do not think that maven/jruby-dist is the problem
<headius>
oh?
<headius>
I do feel like things have settled a lot but there's still a lot of complexity
dhinojosa has joined #jruby
<headius>
mkristian: and as always we appreciate your work on this stuff :-)
<enebo>
So maven itself also is useful for IDE integration
<mkristian>
definitely these ext module needs something better solution.
<headius>
they could be separate project
<enebo>
yeah ext probably should be externalized but then they also need to work on both versions
<headius>
if we're not going to do that we should just roll them back in
<headius>
enebo: only if they're published as gems
<enebo>
Or we did not really simplify maven if we need to build n repos to make a single dist
<enebo>
That is not a simplification
<headius>
right now I'd vote to roll them back in until we have a compelling reason to do them separate
<mkristian>
do those ext project change a lot ? I do not think so
<headius>
I wish I could remember why we stopped at this point when splitting them off
<headius>
mkristian: readline, almost never
colinsurprenant has quit [Ping timeout: 240 seconds]
<enebo>
well I have never been a fan of ext except for jruby-openssl which revs often but we do gemify that
<headius>
ripper, very little lately, but it will need an update to 2.2 logic
<headius>
enebo: and we made it a separate project with its own lifecycle too
<enebo>
headius: but it can lockstep with our releases
<headius>
these other two don't really benefit from being separate right now
<enebo>
headius: yeah I think we did this for maven-ruby integration for some reason no?
<headius>
they weren't jars in stdlib before, that's one difference
<headius>
they were just pseudo-libs
<mkristian>
it came around this time but not to simplify maven build ;)
<enebo>
default gems drove it but what drove default gems
<mkristian>
but ripper + readline are no default gems. just get embeded into stdlib
thsig has joined #jruby
<enebo>
doesn’t openssl as well?
<mkristian>
no openssl is default gem so you can up and downsgrade via installing gems
metadave has joined #jruby
<enebo>
mkristian: yeah I understand tht but where files are located I do not think matters…I can see though they are not in default directory of specificatios
<enebo>
mkristian: I guess since we never released as gems it would not really make sense to make them default since nothing would ever replace them
<mkristian>
yes yes
pchalupa has quit [Quit: Computer has gone to sleep.]
nirvdrum has joined #jruby
anaeem1 has joined #jruby
<headius>
74ff3f2843c88d5569c292c54c5bca400cde781f is where I first separated readline out
<headius>
in ant
<mkristian>
so my wish for the build would get those ext/ projects into own repo and release them via maven-central. and get maven/jruby-stdlib build where the actual code is located: lib/
kl has quit [Ping timeout: 255 seconds]
<headius>
oh, no it wasn't
<headius>
mkristian: we've talked about that scenario...it makes some sense
<headius>
I'm trying to figure out why I separated readline into its own jar right now
<headius>
if that's a requirement then we need it as a separate build to be sane, which probably means they should be own repo and pushed to maven
<mkristian>
I remember you guys talking about moving more extensions to ext/
<headius>
yeah
<headius>
it's a goal...I don't know if it's a good one, but it's a goal
<mkristian>
hah
<enebo>
yeah I am not sure either
<headius>
oh good, I made a nice commit message explaining why: fb264a04ccecb13d5f9e25de210d954ad7711d99
<headius>
it was because jline/jansi don't work from boot classloader
<enebo>
If we are lock-step releasing these exts as part of release that just made one task into n tasks
<headius>
primarily
<enebo>
headius: and this led to the maven slippery slope that no jars should be shipped in an artifact
<enebo>
which might be more of a packagers generic argument
<headius>
right, and we couldn't nicely script the jar to build
<enebo>
so that explains readline :)
<headius>
yeah
<headius>
and I think it could be a separate lib/repo
<mkristian>
so we move readline to its own repo for a reason
<headius>
it has had one commit in the past year
<enebo>
I think ripper might have been done because we thought it might need to rev more
<mkristian>
what about ripper ? it seems to be bound to the stdlib jruby has
<headius>
and yet we never made it a gem...and making it a gem is complicated
<enebo>
yeah versioning is important
<headius>
I'll spelunk logs
<enebo>
headius: so that works
<enebo>
jirb_swing
<headius>
whew
<enebo>
mkristian: should I commit that removal of truffle from ext pom.xml?
<JRubyGithub>
jruby/master a8c1898 Thomas E. Enebo: Yow old shipped JREs
JRubyGithub has left #jruby [#jruby]
<nirvdrum>
It looks like I missed a lot yesterday.
<headius>
nirvdrum: just the usual fun :-)
Who has quit [Quit: Who]
<nirvdrum>
Oh well. Better to find about issues now.
Who has joined #jruby
mister_solo has joined #jruby
multibot__ has joined #jruby
colinsurprenant has joined #jruby
vtunka has quit [Quit: Leaving]
<headius>
mkristian, enebo: I'm going to start jruby-readline repo
<mkristian>
cool
<enebo>
headius: wait so then every release I will need to release that as well?
<mkristian>
no only when it changes and then you first you release it. just like all thos jnr artifacts
multibot_ has quit [Ping timeout: 245 seconds]
<headius>
right
<enebo>
ok so we release once and then it will only need to be updated if it changes which I will need to periodically check
<headius>
it will just be another dep...one we almost never change
<headius>
yeah
<enebo>
and if we need to update it then it will just be like 5 hours if we want to do it at same time as our main release
<headius>
we could also have a policy to just rev it whenever there's a change
<enebo>
headius: yeah I definitely would like to have it long released before jruby release for the above scenario
<enebo>
I have to say I think jnr is fucking horrible to deal with but that is because it incesuously depends on itself so much. readline will not be like that
<headius>
yeah
yopp has left #jruby ["woop-woop-woop"]
djellemah has joined #jruby
<enebo>
I don’t remember why we are pushing these things into maven anymore?
josh-k has quit [Remote host closed the connection]
josh-k has joined #jruby
havenwood has joined #jruby
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
calavera has joined #jruby
Who has quit [Ping timeout: 255 seconds]
Specialist has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to master: http://git.io/q_F1hw
<JRubyGithub>
jruby/master 9a18855 Charles Oliver Nutter: Don't do native system logic on Windows.
JRubyGithub has left #jruby [#jruby]
<headius>
mkristian, enebo: jruby-readline repo is created and builds
<enebo>
ok
DrShoggoth has joined #jruby
subbu has joined #jruby
<enebo>
round and round we go
<mkristian>
so we could release jruby-readline afther jruby-9.0.0.0.pre1 is out ?
skade has quit [Quit: Computer has gone to sleep.]
<headius>
yeah
<headius>
or whatever we want to version it
<headius>
if we want to be able to rev it independent of release it probably doesn't make sense to use same versioning
mister_solo has quit [Read error: Connection reset by peer]
<headius>
so this would be 1.0
<mkristian>
I would say so
<headius>
enebo: Who828 figured out that if we switch from semaphore.acquire to semaphore.tryAcquire with a really long timeout we don't get that hang we've seen on travis
<headius>
I can't get a hang with that change locally either
camlow32_ has joined #jruby
<headius>
the hang in the ThreadGroup.list spec
<enebo>
yay
<headius>
makes me angry because it seems like acquire should just be tryAcquire(really long timeout)
<enebo>
soup made…entertain me
<headius>
or at least behave the same
camlow3__ has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to master: http://git.io/OI2-gg
<JRubyGithub>
jruby/master f48ebd7 Charles Oliver Nutter: Use tryAcquire since acquire seems prone to racy hangs. :-(
JRubyGithub has left #jruby [#jruby]
camlow325 has quit [Ping timeout: 272 seconds]
<headius>
I don't feel like wading into concurrency-interest to find out whether this qualifies as a bug in Semaphore
<enebo>
boo. I should respin this build now right :)
<headius>
hmm
<headius>
enebo: not necessary really
<headius>
but you can if you want
<headius>
I think this sleep hang is unlikely to affect anyone in the wild, but unsure
<enebo>
I won’t unless I find something else then I will pull it in
<headius>
ok
camlow3__ has quit [Remote host closed the connection]
<enebo>
headius: I don’t think people will use pre1 in production either
<headius>
someone will
<headius>
but that's not our problem :-)
<Antiarc>
headius: I just discovered independently that MRI won't allow mutex synchronization from within a trap context, presumably for similar reasons as what causes Thread.raise to be so nasty. JRuby permits it though
<Antiarc>
If you pkill -HUP -f trap.rb under MRI, that'll raise "trap.rb:3:in `synchronize': can't be called from trap context (ThreadError)"
<Antiarc>
Jruby prints "hi"
gregorsc5 has joined #jruby
<Antiarc>
(latest master, built 30 seconds before the test)
camlow325 has joined #jruby
kl__ has joined #jruby
<headius>
Antiarc: ahh interesting
<headius>
disallowing synchronization from a trap seems kinda weird though
<Antiarc>
Anyhow, it's not directly related to the Thread.raise problem, but I'd argue it's the same class of issue, and given that MRI has taken steps to solve it, seems like maybe progress might be welcome towards solving ensures?
<Antiarc>
You can solve it via Thread.new { synchronize { ... } }
<headius>
oh, right, I bet they do it because they run signal handlers on one of the running ruby threads
<Antiarc>
which makes sense
<headius>
I think usually main
<Antiarc>
Yup
<Antiarc>
It runs on main
<headius>
ours runs on JVM signal-handling thread
<Antiarc>
So it's possible to deadlock from a signal if you already hold the mutex and then signal
<headius>
right
<headius>
that would be possible for us too though
<headius>
and I don't think it shouldn't be
<headius>
or rather I don't think we should change anything
<enebo>
This does work after this massive backtrace
<enebo>
mkristian: Does this look familar to you?
<enebo>
oh hahah e.printStackTrace!!!!
<enebo>
mkristian: interesting from 12/12/14. I think this was just for debugging or is this error indicating something involving classpath: is broken?
<JRubyGithub>
jruby/master fed5d10 Thomas E. Enebo: Remove errant e.printStackTrace()
JRubyGithub has left #jruby [#jruby]
<enebo>
headius: ok well we will end up pulling in the last acquire change afterall
<enebo>
I am unclear if we should be seeing that error or not since I thought classpath: was something we registered?
<enebo>
The fact it does not know about it confuses me
subbu has quit [Ping timeout: 272 seconds]
mister_solo has joined #jruby
camlow325 has joined #jruby
<headius>
oops on that printStackTrace
<headius>
enebo: the protocol requested was "classloader"
<headius>
I wonder if someone commited "classloader" protocol meaning "classpath"
<headius>
mkristian: do you know anything about that?
<headius>
enebo: Who828 said it still hung with this change, but it didn't for me and must have taken longer for him
<headius>
so I dunno
<enebo>
I removed the print and I think things did work but I am guessing this is not on 1.7 codepath
<enebo>
headius: well it is in this spin regardless
camlow325 has quit [Remote host closed the connection]
<headius>
yeah it' sfine
<enebo>
headius: unless you think it potentially made things worse
<headius>
it just replaced acquire with tryAcquire for Long.MAX_VALUE ms
<headius>
I think that would be the heat death of the universe
<enebo>
HEAT DEATH
<enebo>
,,,,,,..,,
camlow325 has joined #jruby
subbu has joined #jruby
<mkristian>
enebo, sorry was away for a while. yes, I do know something about this.
<enebo>
mkristian: awesome
<enebo>
mkristian: so far as I can tell gem list worked but I don’t know if that exception is expected
<mkristian>
or it looks familiar.
marr has quit [Ping timeout: 245 seconds]
<mkristian>
enebo, I just pull the sources and build jruby-complete and then I should see the same error ?
<enebo>
mkristian: on windows since I did not see this on macos
<enebo>
mkristian: which is one reason I wondered that something is broken
JohnBat26 has joined #jruby
<enebo>
perhaps some UNC/driveletter parsing stripping uri: off?
<mkristian>
ok - windows, then. yes something like this.
<mkristian>
but since yesterday I have a windows VM for 90 days
<mkristian>
so I will see.
<mkristian>
could be related to the windows patch of mine yesterday
josh-k has joined #jruby
<enebo>
mkristian: without printStackTrace I get consistent behavior on windows for gem or running rake but I suspect if this is a problem it probably involves some OSGi/embedded scenario
<enebo>
mkristian: So we will run with this and fix any resulting issue in next preview/rc/whatever
djellemah has quit [Quit: Leaving]
e_dub has joined #jruby
towski has quit [Ping timeout: 246 seconds]
<mkristian>
enebo, well, I do not see the stacktrace here with java8 on windows8. could you at least have me a look at java -Djruby.debug.loadService=true -jar ... -S gem list
<mkristian>
just to see what is going on.
<headius>
enebo: you didn't land :"foo" or refinements at all, right?
<enebo>
mkristian: I did remove the printStacktrace
<enebo>
mkristian: So I am not sure if you are looking before or after?
<enebo>
headius: I did land :”foo"
<headius>
oh nice
<headius>
ok
<enebo>
headius: not refinements because I realized no JIT and I did not want a special instr made just for this release on JIT
<enebo>
headius: the callsitecache logic I had was fucked up somehow so I did not get off refinedcallinstr
<headius>
ok
<headius>
no worries
mattwildig has quit [Remote host closed the connection]
diegoviola has quit [Remote host closed the connection]
<enebo>
headius: looks good I am removing 3-address since I am not sure it conveys very much
<headius>
yeah I wanted something there but nothing felt right
yfeldblum has quit [Remote host closed the connection]
<mkristian>
ok that is why I do not see it. anyways I am not digging deeper since installing a gem gives me: Win32::Registry::Error - which beyond my windows skills ;)
<enebo>
yeah traditional compiler design is very squishy but it implies that if you have worked with compilers you will understand it
pietr0 has quit [Ping timeout: 264 seconds]
<enebo>
mkristian: from an install or jruby-complete?
pietr0 has joined #jruby
<mkristian>
jruby-complete
<enebo>
mkristian: I set GEM_HOME and it worked for me
<enebo>
but I am win7
<mkristian>
right I need to set GEM_HOME
baroquebobcat has quit [Quit: baroquebobcat]
<enebo>
set GEM_HOME=C:\OPT
<mkristian>
thanx
<enebo>
^ This is what I did just for completeness
<enebo>
but you should get some other error about not writing to the jar gem dir without it?
<enebo>
I mean not one involving registry
baroquebobcat has joined #jruby
<enebo>
so that is new to me
mister_solo has quit [Ping timeout: 245 seconds]
josh-k has quit [Remote host closed the connection]
<headius>
I'm tweaking some wording and added a line talking about IR potential
<enebo>
headius: ah great I was thinknig that was missing
<enebo>
headius: but I got distracted :)
<headius>
I want to put together a blog post after release too
<headius>
or a series of posts talking about key areas like IR, IO, etc
<headius>
once preview is out we should start making noise, now that we have something concrete for them to try
<enebo>
yeah that might be nice or we may want to save some of that nearer to final
<enebo>
not sure we should be tooting the horn so much for this release since it will not give impressive numbers yet
<enebo>
I agree we want people trying it though
towski has joined #jruby
<headius>
maybe a single post now that's just a long-form release notes plus HOWTO try out/contribute
<headius>
here's hoping we just get a bunch of "it works!" reports
<headius>
so we can focus on IR work until final
<enebo>
I mostly want enough curiousity to try it out and report problems and then when we hit out final details we start PR’ing a lot more on why and how awesome
<enebo>
I think the potential of what we have is awesome but this release I think will leave people mildly unimpressed because all of the awesome is not end-user visible yet
<headius>
sure
<headius>
I think a lot of folks will be thrilled just to have 2.2 features
<enebo>
yeah being close to 2.2 feature compat will be positive on its own
<enebo>
ok I am almost done testing
<enebo>
0 uri:classloader:/
<enebo>
hah
<enebo>
So gem install with no GEM_HOME makes this dir :)
<enebo>
which tells me that is not a windows-only issue
nirvdrum has joined #jruby
<enebo>
mkristian: ^
<enebo>
mkristian: That is on macOS. So it must hit the exception and treat it like a file at that point
<mkristian>
ok
<enebo>
mkristian: good to know it is not windows-specific I guess
<enebo>
but it means jruby-complete is probably throwing this exception commonly
<mkristian>
not sure - I was surprised to see uri:classloader: treated as URI should go to classloader instead
<mkristian>
this line should be only reached if this is NOT uri:classloader
<mkristian>
enebo, well, your windows hints did not change what I see
<enebo>
mkristian: you mean setting a GEM_HOME?
<mkristian>
yes
<enebo>
mkristian: well that is very odd
<enebo>
mkristian: you using CMD?
<mkristian>
wait, maybe I have no c:\OPT dir
<mkristian>
yes cmd.exe
<enebo>
mkristian: yeah the base dir should exist and then it will make gems dir under it
<enebo>
mkristian: I pick dirs off of C:\ so I don’t need to worry about windows perms complicating things
<enebo>
mkristian: you would hope you would get a nicer error message if GEM_HOME does not exist
<mkristian>
nope - same same
<enebo>
I don’t know
<enebo>
I did an install of rake gem
<enebo>
which has a bin stub
djellemah has joined #jruby
<enebo>
mkristian: Not sure what could be different
<enebo>
mkristian: unless it happens to magically work because I also have windows install of jruby9k and somehow subproc is doing something with installed version?
<mkristian>
enebo, it is bare windows with IE and java
<mkristian>
well, the uri:classloader: directory is something more concrete ;) - I file an issue
<enebo>
mkristian: ok hopefully we can narrow down env differences and isolate whatever is wrong more
thsig has quit []
<headius>
tagged!
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian opened issue #2488: "java -jar jruby-complete.jar -S gem install yard" creates uri:classloader: directory when GEM_HOME is not set http://git.io/IZYe-Q
JRubyGithub has left #jruby [#jruby]
yfeldblum has joined #jruby
nirvdrum has quit [Ping timeout: 245 seconds]
slyphon has quit [Read error: Connection reset by peer]
robbyoconnor has quit [Ping timeout: 252 seconds]
marr has joined #jruby
slyphon has joined #jruby
<subbu>
good afternoon from sf. how is the release going?
<enebo>
mkristian: You ever see stuff like this on sonatype: Missing Signature: '/org/jruby/jruby-core/9.0.0.0.pre1/jruby-core-9.0.0.0.pre1-complete.jar.asc' does not exist for 'jruby-core-9.0.0.0.pre1-complete.jar'.
<enebo>
mkristian: This is trying to close. Should I drop and just re-deploy perhaps?
<mkristian>
yes, I would say so
<enebo>
whoa…I just tried for third time to close and it made it past jruby-complete and now is failing jruby-core .asc file
<mkristian>
is this new to 9.0.0.0.pre1 or did you see this with 1.7.x before ?
<enebo>
new one
<mkristian>
let me have a look on sonatype - do not drop them right away
robbyoconnor has joined #jruby
calavera has joined #jruby
<mkristian>
enebo, no wait these are the extra shaded attached artifacts
<enebo>
mkristian: Actually I think there is some bogus file up
<enebo>
really?
<enebo>
jruby-core-9.0.0.0.pre1-complete.jar seems like an odd name
<headius>
yeah why is core in there
<mkristian>
it is just for internal use. but also jruby-core-9.0.0.0.pre1-noasm.jar has not .asc files
<headius>
ahh
<mkristian>
jruby-core-9.0.0.0.pre1-complete.jar is the shaded jar - it is the lib/jruby.jar with maven filename convention which I use to create jruby-complete
subbu has quit [Ping timeout: 256 seconds]
pietr0_ has joined #jruby
pietr0 has quit [Ping timeout: 272 seconds]
pietr0_ is now known as pietr0
colinsurprenant has quit [Quit: colinsurprenant]
colinsurprenant has joined #jruby
<mkristian>
enebo, I am doing a run on core/ and see if this deploys correct to sonatype and then drop it again. before I commit the change. there was difference between jruby-1_7
<enebo>
mkristian: ok thanks for investigating
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian pushed 1 new commit to master: http://git.io/AC74UQ
<JRubyGithub>
jruby/master d537cab Christian Meier: [build] moved phase where the shaded attached artifacts get build...
JRubyGithub has left #jruby [#jruby]
<mkristian>
enebo, -^ looked good all asc files get build now
<enebo>
mkristian: okie dokie…re-spinning
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] enebo force-pushed 1.7.12 from 643e292 to 21eb526: http://git.io/7PV0Kw
skade has quit [Quit: Computer has gone to sleep.]
gregorsc5 has joined #jruby
<chrisseaton>
I was going to do a PR to make the JRuby logo on jruby.org retina compatible, but I'm not sure how since it's actually a background image