yfeldblum has quit [Remote host closed the connection]
yfeldblum has joined #jruby
skade has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
headius2 has joined #jruby
headius2 has quit [Client Quit]
nirvdrum has quit [Ping timeout: 244 seconds]
skade has joined #jruby
skade has quit [Client Quit]
skade has joined #jruby
skade has quit [Client Quit]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
<eregon>
lopex: how is it working (Eclipse stuff)?
<eregon>
it's a bit of a mess because Eclipse does not support annotation processors outside jars, so we need to include the LayoutImpl from the regular maven build
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
skade has joined #jruby
mattwildig has joined #jruby
mattwildig has quit [Ping timeout: 240 seconds]
vtunka has joined #jruby
vtunka has quit [Quit: Leaving]
djellemah_ has joined #jruby
pietr0 has quit [Ping timeout: 240 seconds]
headius2 has joined #jruby
headius2 has quit [Client Quit]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
drbobbeaty has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
pietr0 has joined #jruby
vtunka has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
vtunka has quit [Quit: Leaving]
blaxter has joined #jruby
mattwildig has joined #jruby
djellemah_ has quit [Ping timeout: 250 seconds]
blaxter has quit [Ping timeout: 276 seconds]
mattwildig has quit [Ping timeout: 240 seconds]
blaxter has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
knu has joined #jruby
knu has quit [Client Quit]
bbrowning_away is now known as bbrowning
knu has joined #jruby
bbrowning is now known as bbrowning_away
yfeldblum has quit [Remote host closed the connection]
drbobbeaty has joined #jruby
sluukkonen has joined #jruby
<GitHub183>
[jruby] eregon commented on commit fa85b95: `final` https://git.io/v24wE
<GitHub166>
[jruby] eregon commented on commit 938d3c0: I would pass `declarationFrame` as an argument to `readFrameSlot`, otherwise the helper is doing more than just calling the helper node. https://git.io/v24rz
skade has joined #jruby
nirvdrum has joined #jruby
bbrowning_away has quit [Ping timeout: 244 seconds]
mattwildig has joined #jruby
mattwildig has quit [Ping timeout: 252 seconds]
bbrowning has joined #jruby
shellac has joined #jruby
tomjoro has quit [Remote host closed the connection]
vtunka has joined #jruby
HalcyonicStorm has joined #jruby
pawnbox has quit [Remote host closed the connection]
shellac has quit [Ping timeout: 255 seconds]
tcrawley-away is now known as tcrawley
headius2 has joined #jruby
djellemah_ has joined #jruby
djellemah has quit [Ping timeout: 255 seconds]
headius2 has quit [Client Quit]
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #jruby
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
mattwildig has joined #jruby
johnsonch_afk is now known as johnsonch
djellemah_ is now known as djellemah
vtunka has quit [Quit: Leaving]
donV has joined #jruby
donV has quit [Client Quit]
bjfish2 has joined #jruby
vtunka has joined #jruby
headius2 has joined #jruby
<headius2>
kares: I had to add -Djruby.home to another place...I missed the end of that thread where you asked about the first one, what was the conclusion?
<headius2>
I'm also looking into the integration test failures on ruby-2.3 since that's all that's left...seems like there's some issues with load path ordering or something
<kares>
headius2: yeah those seemed weird
<headius2>
the envutil thing is caused by it loading test/unit from the jar rather than from the load path
<kares>
about jruby.home I did not notice those tests weren't running on master
<headius2>
so it doesn't pick up the MRI test suite test/unit
<kares>
so false alarm on my end
<headius2>
ok
<headius2>
weird thing is load path looks fine...classloader entries come after test/mri/lib
<headius>
it loads up wildfly or something and tries to test jruby in a servlet environment, but it spews errors and noise whether it fails or not
<headius>
it has always confused me
mattwild_ has quit [Ping timeout: 240 seconds]
<headius>
FWIW other than the hangs in MRI suite, we should be down to just two integ suites in the red
<headius>
not counting the truffle suites that haven't been tagged off for 2.3
<headius>
chrisseaton: do you want to have your folks tag off failures before I merge to master or can I go ahead with it and move them to expected failures for now?
<headius>
I don't know whether you have cycles to tidy that up right now
<headius>
chrisseaton: enebo: this also brings up a question...do we care if truffle supports 2.3 features for 9.1?
<headius>
I'd say no since it's still experimental anyway
<headius>
oh, no enebo
<chrisseaton>
hello
<chrisseaton>
headius: I don't mind doing our tagging
<chrisseaton>
If you push it I'll do the tagging in an hour at most so you don't have to move it to allowed
<chrisseaton>
headius: we'll catch up on 2.3 features in the next few weeks
<headius>
ok
<headius>
there's not many big ticket items since you'll have a working parser right away
<chrisseaton>
yeah, ride those coat-tails
<headius>
obviously not going to make 9.1 by end of Feb but within the next couple weeks probably
<headius>
asarih: so I sent a support request in and was directed to use docker to try to reproduce
<headius>
unfortunately the docker shit is like 3GB of downloading and I'm not on a fast connection today
<headius>
any way you can arrange a hosted env old budy?
<headius>
docker will make my 15 minutes of investigation into many hours of sitting on my hands
yfeldblum has joined #jruby
pawnbox_ has quit [Ping timeout: 250 seconds]
pawnbox has joined #jruby
<chrisseaton>
headius: so after I opened that issue about flip-flops not being supported I went and looked for gems using it
<nirvdrum>
headius: If it helps any, DigitalOcean has a pre-built docker image/recipe/whatever.
<chrisseaton>
headius: and I found... one written by you!
<headius>
hah, I'm not surprosed
<headius>
which gem is that?
<headius>
I was enamored with that goofy syntax for a little while
<headius>
I haven't found a single case where the code was easier to understand than just having a boolean local var
blaxter has quit [Quit: foo]
<chrisseaton>
lazy-enumerator, which I guess is obsolete now
<robacarp>
chrisseaton: I'm not sure I understand "Another way to put it is that there are only 5 people who we can confirm have used a flip-flop in anger."
<enebo>
codefinger: he’s a man. a man with an ASCII touch
<headius>
ok so bringing everyone up to date
<codefinger>
i'm still waiting for shirley bassey to record my theme song
<headius>
mjruby is "ready" in codefinger estimation
n00bdev has joined #jruby
<headius>
jruby-launcher's days are numbered
camlow325 has quit [Ping timeout: 244 seconds]
<headius>
I think we should move to mjruby for platforms supported in 9.1 timeframe
<headius>
and I think perhaps the code should move into jruby-launcher so it's the same gem
<headius>
that way all our docs recommending that gem will continue to work
<headius>
codefinger: that answers the question about fallback too...on unsupported platforms jruby-launcher will just install the C++ version
<headius>
so one bit of overhead is that mjruby is built as binary for supported platforms
<headius>
so when we change it we'll need to rebuild for linux, windows, os x
<headius>
but I think that's largely automated?
rcvalle has joined #jruby
<codefinger>
headius: yes. docker
<headius>
ok
<codefinger>
headius: so yes we can do that. but it does mean the old jruby-launcher code will need to be maintained for a little longer. But it should only be needed on strange platforms, and i think that's ok.
<headius>
makes sense to merge mjruby into jruby-launcher then?
<codefinger>
the other thing we could do is remove all the old jruby-launcher, and fallback to the bash script. but i suppose that has it's downsides too.
<headius>
there are very few folks not on the big three platforms, and I have no idea how many use jruby-launcher
<codefinger>
headius: yes. i will need to improve the extconf.rb to either copy in the mjruby bins or compile jruby-launcher on the fly
<headius>
mjruby binaries could/would ship with jruby dists, where jruby-launcher could not
<enebo>
well if someone is on an esoteric platform then their shebang usage might break if we force them to shell script
<headius>
right
<headius>
right now the only platform to ship a native binary is Windows, a prebuilt jruby-launcher instance
<enebo>
codefinger: will there ever be a day where someone can type ‘make’ on an esoteric platform and we will get mruby and compile?
<codefinger>
enebo: unsure. will need to ask hone.
<headius>
enebo: sure, just have it pull down vbox + a build image :-)
<enebo>
codefinger: I don’t want to scare the crap out of you :)
mattwildig has joined #jruby
<headius>
outside that I think it's a long way off
<codefinger>
well, everyone will have docker by the end of the year right?
<codefinger>
</troll>
<enebo>
Yeah my limited experience is only with hone’s tools
<headius>
so for testing purposes, I could have our build install mjruby right now and see what happens
<headius>
we install jruby-launcher currently but I don't think we have anyone doing 9.1 dev outside the supported three platforms
<enebo>
Hmmm, I wonder if we can still extconf assuming mruby toolchain is around
hone has joined #jruby
<headius>
probably could
<enebo>
Meaning it will work if someone “properly” installed it
<headius>
codefinger: so it's a fat gem right?
hone has quit [Client Quit]
<headius>
all binaries are in there and get copied into place if available
<enebo>
I am not fixating on this part as much as realizing it is probably the only delta between the two projects
<codefinger>
headius: yes
<headius>
right, but if we (codefinger) can get extconf.rb to just build jruby-launcher on obscure platforms, I think that's solved for now
<codefinger>
yes, agree
hone has joined #jruby
<headius>
but yeah, that's a delta...bsd users will be stuck with C++ version for now
<headius>
all five of them
<hone>
hello!
<enebo>
fiveteen of them
<headius>
hone: hey buddy!
<hone>
codefinger told me to join
<enebo>
hone: sharp as a knfe buddy
<headius>
so we're in agreement that mjruby becomes new jruby-launcher
<codefinger>
hone: enebo was wondering about the future possibility of unsupported platforms building their own mjruby outside of the mruby tool chain
<headius>
with a major version rev or something
<enebo>
codefinger: yeah me too
<headius>
and I think we're in agreement to push forward with this for 9.1
<hone>
oh nice
bbrowning has quit [Ping timeout: 248 seconds]
<hone>
what other platforms are we looking at?
<headius>
*BSD obviously would be a good first target
<enebo>
codefinger: I mostly think a Makefile which assumes sensible buildchain locations with sensible overrides via ENVs and perhaps it will eventually work simply everywhere
<enebo>
codefinger: but I don’t know how well mruby has been spreading through the OS/distro-spheres
<codefinger>
there is one other approach, and that is working through RVM, rbenv, etc to have them use mjruby instead of jruby-launcher. but that would also require doc changes in jruby
<enebo>
codefinger: like on BSD can you package install mruby-dev
<hone>
and by package you mean not git clone ;)
<headius>
I'd say in order of userbase, after the big three we go BSD, Solaris, AIX or zLinux, and then dropping off fast toward OpenVMS
<headius>
most of those probably can't build jruby-launcher now
<enebo>
hone: what can’t git do?
<hone>
$ apt-cache search mruby
<hone>
libmruby-dev - lightweight implementation of the Ruby language (development files)
<hone>
mruby - lightweight implementation of the Ruby language
<hone>
interesting
<headius>
huh, I wonder how up to date they are
<enebo>
I guess the other route would be for extconf to clone mruby and assume it will build it and then build mjruby from that compile
<enebo>
Seems a bit heavy-handed but it is probably simpler to work out the kinks
<enebo>
OTOH it means a lot more bug reports due to mruby not compiling on platform Y
<hone>
right, but mruby-cli assumes our docker stuff is steup
<hone>
*setup
<hone>
so that seems hard to get that setup in a gem
<headius>
enebo: not to mention inability to clone in some envs
<enebo>
hone: yeah so I guess one thing I am thinking is that mruby-cli is not the only way to build this
<headius>
or other restrictions
<headius>
codefinger: what's the size of the binaries now?
<codefinger>
~1mb altogether compressed
<hone>
yeah, I mean you could make it work but then you deal with dependency fun.
<enebo>
headius: well MRI already compiles C code and stuff so I am less worried about that corner
<headius>
yeah but it doesn't clone anything for most exts
<headius>
it all comes in the gem
<enebo>
hone: yeah I guess if the deps are a snake pit then it is probably not worth doing it
<headius>
rubygems.org needs a "gem contents" browser
shellac has joined #jruby
<enebo>
hone: Do you think there is a path where someone on an outside platform (e.g. *BSD) could end up working with you to add it to mruby-cli?
<enebo>
hone: I am guessing it means working on cross-compiler for each one
<hone>
yeah, i mean it's just figuring out the cross compiler story
<enebo>
hone: similar to MacOS one
<hone>
yeah, who doesn't like recompiling gcc? ;)
<headius>
woah
<enebo>
ok well I guess we have a reasonably safe near term solution (except that we now have to update two sources on new feature adds)
<hone>
i mean, the alternative is to build mjruby on the platform itself
<headius>
$ ls -l bin/jruby
<headius>
-rwxr-xr-x 1 headius staff 66888 Feb 24 19:12 bin/jruby
<headius>
I guess we solved the size issue?
bbrowning has joined #jruby
<enebo>
hahah wow
<headius>
that's a super great size
<hone>
but that means setting up the whole toolchain sans docker and getting all the deps to get it to compile
<headius>
or is there some big fat .so somewhere?
<enebo>
I am surprised you did not send me a singing telegram over that size reduction
<hone>
but i like the cross compile solution when possible if codefinger or someone is responsible for releasing.
<headius>
oh
<headius>
I think this must be ours
<headius>
I mean jruby-launcher version
<headius>
-rwxr-xr-x 1 headius staff 478176 Feb 25 12:48 mjruby
<hone>
it's been a nightmare in the past at heroku to build our cli natively on each platform we want to support.
<headius>
codefinger: first thing to change would be to get a release out that uses "jruby" as executable name, and then we can pull it into build to see how CI likes it
<hone>
which was the impetus for building something like mruby-cli
<hone>
headius, enebo: how important is the stack rank of BSD?
<headius>
wish that binary were smaller but I don' tknow if we can do anything about that
<headius>
hone: our rank or someone else's?
<headius>
we get more BSD reports than all other *nix combined, but I don't feel like there's many people
<enebo>
headius: oh you were seeing jruby-launcher size
<headius>
enebo: yeah :-(
<enebo>
headius: you disappointmed me :)
<headius>
so it's still in 500k size
<enebo>
DISAPPOINTMED
<hone>
figuring out the freebsd story in mruby-cli will probably take some work
<headius>
oh, I didn't install the preview version...
<enebo>
hone: so I don’t know how important BSD is but I know we have had peope contribute fixes/FFI stuff for BSD
<hone>
also, when's 9.1 coming out?
<enebo>
hone: end of monthish most likely
<enebo>
hone: or early
<headius>
2.3 branch is basically done
<enebo>
early next month that is
<enebo>
At this point I think it will mostly be addressing outstanding reported issues marked against release
<hone>
next month being march?
<headius>
well preview mjruby is no smaller
<enebo>
hone: yes
<headius>
so like, next 2-3 weeks it will be out
<headius>
$ ls -l lib/ruby/gems/shared/cache/mjruby-1.0.0.rc2-java.gem
<headius>
-rw-r--r-- 1 headius staff 1042432 Feb 25 12:53 lib/ruby/gems/shared/cache/mjruby-1.0.0.rc2-java.gem
<headius>
those binaries compress down reasonably well at least
<headius>
still a much bigger gem than before
<headius>
(obv)
<hone>
well, we're also packing binaries vs just source
<headius>
yeah
<enebo>
headius: I believe they allocate some page space in the binaries for an IR of sources in mruby
<headius>
that's all of the size
<headius>
enebo: yeah there should be a way to pack that down
<hone>
enebo: yeah, that's my thought too. I wonder if we could get that down?
<enebo>
headius: I think that because I mucked with a bunch of changes removing methods and code and the binary ended up the exact same size every compile
<enebo>
hone: you would think so
<headius>
right
<hone>
enebo: i mean, in mruby config stuff
<headius>
and consistently right around 500k
<enebo>
hone: I tweet-asked Matz about this and did not get a meaningful config
<enebo>
hehe answer
<hone>
well, you also tweet asked matz :P
<headius>
and it's much more code now than when we started
<hone>
but on the plus side, not doing string manip in C++ is a win?
<enebo>
hone: ask matz about irep and whether it is a fixed pool size?
<hone>
matz never responds to me on twitter
<enebo>
hone: accuse him of killing Ruby
<hone>
heh.
<codefinger>
hone: technically we have the same boss. we should be able to do this
blandflakes has joined #jruby
<headius>
at this point the size doesn't concern me
<headius>
windows dist will be no bigger
<codefinger>
ok, so here's the plan: i update mjruby gem to install a "jruby" bin instead of an "mjruby" bin. Then we can test it with 9.1. Then I will merge jruby-launcher+mjruby, and create a jruby-launcher prerelease gem. test that.
<headius>
other dists will probably still ship just bash script
<hone>
enebo: looks like there's a irep struct?
<headius>
getting right binary in place on both linux and os x would require a user step anyway, so that step might as well remain "gem install jruby-launcher"
<enebo>
hone: yeah looks like it is the instructions for the mruby program
<enebo>
hone: and they must get saved into the .exe somehow
<headius>
codefinger: yeah, a preview with 'jruby' right now would let me roll it into 9.1 build
<headius>
the jruby-launcher fallback will just be needed before release
<enebo>
hone: not sure but based on sizing it feels like it may allocate more space than instrs + var tables etc...
<hone>
yeah, that's kind of weird given that it's built to be space efficient
<hone>
headius: so a preview jruby-launcher gem?
<headius>
hone: it can just be a preview mjruby gem for now too
<headius>
we'll just temporarily change build to install that instead of jruby-launcher
<hone>
cool
xardion_ has joined #jruby
<headius>
mjruby appears to be *slightly* slower than jruby-launcher, around 0.05s to 0.08s
<headius>
for -e 1
<headius>
that amount doesn't worry me
yfeldblum has joined #jruby
<hone>
hmm. i'd be surprised if it was faster than custom c++ code
<headius>
sure
<headius>
"fast" here is pretty relative of course... jruby itself is 1.8-1.9s of startup
<hone>
right
<headius>
with --dev
<hone>
I'm hoping codefinger actually implements the jruby shell idea
<headius>
I'm going to do a test:mri run with mjruby binary as jruby
<headius>
yeah jruby shell would be awesome
<codefinger>
:)
<headius>
codefinger: you have commit rights for jruby-launcher repo right?
<hone>
kind of exciting to see the collaboration from jrubyconf.eu turning into something.
<hone>
headius: for merging code, what do you think of using git submodules?
<headius>
hone: I'd prefer a subtree...submodules have never worked right for me
<codefinger>
headius: eh, not sure.
<headius>
we're using subtree for ruby/spec
<enebo>
hone: codefinger: It is great you guys have made all this infra
<headius>
works fine and preserves history
<headius>
codefinger: will get you that and gem access now
<headius>
what email?
<codefinger>
jpkutner at gmail
<headius>
ok
<hone>
I'll poke at the subtree/merge stuff with codefinger
<enebo>
codefinger: p is for puter?
<headius>
this will be jruby-launcher 2.0
<hone>
\o/
<headius>
so you can push a 2.0.whatever-prewhatever
<codefinger>
k
<headius>
codefinger: all set
<codefinger>
thx
<hone>
headius: can I get commit on jruby-launcher?
<headius>
sure
<headius>
hone: done
HalcyonicStorm has left #jruby [#jruby]
<hone>
thanks
<headius>
you need gem rights?
<headius>
I'll add ya, it will probably be useful at some point
<hone>
k
<headius>
email pleez
<hone>
i need to look this up :P sec
<hone>
hone02 at gmail
<headius>
ok
<headius>
codefinger, hone: all set
<headius>
test run looks fine
<hone>
sweet.
mattwildig has quit [Remote host closed the connection]
<hone>
can't wait to brain storm on post jruby-launcher 2.0
<hone>
i think there's some really neat things we can do with it now people aren't scared to touch it
<headius>
starting to think about all the features we might be able to do now, like daemonization and something preforking-like
<headius>
yeah
<headius>
oh!
<headius>
$0
<headius>
I bet we can find a way to make that work
<hone>
i thought codefinger found something?
<headius>
I don't recall now
<headius>
I know it's different across platforms
<hone>
what does it do now?
<codefinger>
oh yea. that works i think. like if you run `ps` you see the `jruby` command?
<headius>
codefinger: no, more than that
<headius>
linking and invoking libjvm fixes that
<headius>
and exec might too
<headius>
I mean being able to set $0 to something else in Ruby
<headius>
we can't do it atop exec'ed JVM because it's platform-specific native code, and on linux it requires access to the original argv array
<headius>
there may be other interesting things we can do that are hybrid mruby/native/jruby stuff
<hone>
interesting.
<headius>
ok, I'm going for lunch
<headius>
MRI suite runs the same with mjruby or jruby-launcher, so that's a good sign
<codefinger>
:)
<hone>
^5
<headius>
I can roll jruby-launcher-2 into 9.1 build any time
<headius>
bbiab
<hone>
headius: it'd be great if we could collab on a doc for jruby-launcher post 2.0
<hone>
not sure where we should track these things down
<headius>
yeah sure
<headius>
we don't really have a higher-level project plan than issues
<headius>
unfortunately we have hundreds of issues
skade has quit [Quit: Computer has gone to sleep.]
camlow32_ has quit [Remote host closed the connection]
<hone>
headius: in bundler, they setup a bundler-features repo
<hone>
and bundler was just for bugs
<headius>
huh, interesting
<hone>
or you could use labels
<hone>
but i think even a higher level text document is probably a good start before you drill it into issues
camlow325 has joined #jruby
<hone>
what does this new arch open us up to, what can we do at this level to really improve the experience
camlow325 has quit [Remote host closed the connection]
<headius>
9.1 at least has no references to EvalStaticScope anywhere
<headius>
yeah that's weird
<headius>
it has to be splicing together 1.7 and 9
<rjmilitante>
should i downgrade my jruby?
<headius>
well if you do and it fixes it, then someone else in classpath is pulling 1.7 in
pawnbox has quit [Ping timeout: 248 seconds]
<headius>
neither of those line numbers are even close on 9.1
<headius>
they're in the middle of ScriptingContainer's javadoc
<rjmilitante>
the thing i dont get is - i have 3 dependencies in gradle for jruby. for jruby.embed and jrubyparser - shouldn't jruby-complete take care of all 3?
<headius>
not jrubyparser
<headius>
jrubyparser is a separate library though
<headius>
unless you want to parse Ruby and get an AST, you don't need it
<headius>
jruby-complete should cover embedding, all of stdlib, rubygems, rake, everything you'd have in a full JRuby dist
<rjmilitante>
i removed my embed dependency and same error
<headius>
yank out jrubyparser too
<rjmilitante>
k
<headius>
just have jruby-complete
<headius>
next thing we'd try would be verbose classloading to see where they're coming from
<rjmilitante>
that did it
<rjmilitante>
thank you!
<rjmilitante>
i only have the one dependency now
<rjmilitante>
i think i added the other two when i was trying to fix
<headius>
ok great!
<headius>
fwiw if you only need jruby and not the Ruby standard lib you should be able to get away with just the jruby artifact
<headius>
if size is at all a concern
<hone>
headius: do we need nailgun support?
shellac has quit [Quit: Computer has gone to sleep.]
<headius>
hone: no
<headius>
but we never explicitly dropped support for it
<headius>
we don't recommend it anymore
<hone>
gotcha
<hone>
who needs nailgun when we have jrubys :P
<nirvdrum>
Is drip still active?
pawnbox has joined #jruby
<GitHub33>
[jruby] chrisseaton commented on commit fa85b95: Fixed. https://git.io/v2Ryl
<headius>
nirvdrum: I believe so
<headius>
somehow I got commit rights too
<headius>
hone: yeah I figure we can come up with our own approach now
<GitHub21>
[jruby] chrisseaton commented on commit 938d3c0: Well it doesn't say it only does one thing. And that'd be duplicated code then. https://git.io/v2Rya
<headius>
we have the flexibility to do it the way ruby wants it
<hone>
yeah
pawnbox has quit [Ping timeout: 276 seconds]
<headius>
huh, when did we change this... launcher doesn't install during -SNAPSHOT dev
<headius>
enebo: ?
<headius>
test/pom.rb:119
<headius>
looks like mkristian in october
<enebo>
headius: yeah I don’t recall
pawnbox has joined #jruby
<headius>
I don't see why though
<headius>
this might have gotten caught up in a different change
<enebo>
headius: or is was some limited env reason
<headius>
right
<enebo>
headius: maybe windows?
<headius>
I'm going to try to remove that and see if anything breaks here
<headius>
ahh that could be
<headius>
but it could just be a Windows check then
<headius>
and Windows should be able to install jruby-launcher anyway
<enebo>
yeah it is precompiled for windows
<enebo>
I just took a guess
<headius>
I'll push this and see if anything goes wacky on ci
<GitHub96>
jruby/ruby-2.3 1721092 Thomas E. Enebo: Fixes one yard regression. We should store any identifier in identValue (used by shadowingLVar check)