<chrisseaton>
you are probably using a 'snapshot' version - those get deleted when the release is made, so you can normally just remove the snapshot part of the version number
e_dub has quit [Quit: ZZZzzz…]
pawnbox has quit [Remote host closed the connection]
tcrawley-away is now known as tcrawley
pawnbox has joined #jruby
Jamo has quit [Ping timeout: 246 seconds]
Jamo has joined #jruby
pil-afk is now known as pilhuhn
Jamo has quit [Ping timeout: 240 seconds]
prasunanand has quit [Ping timeout: 244 seconds]
Jamo has joined #jruby
tcrawley is now known as tcrawley-away
vtunka has quit [Remote host closed the connection]
vtunka has joined #jruby
<ebarrett>
ah ha!
<ebarrett>
chrisseaton: thanks i'll have a look
prasunanand has joined #jruby
<ebarrett>
oh this is exactly what I need :)
Aethenelle has joined #jruby
bbrowning has joined #jruby
bbrowning_away has quit [Quit: Leaving]
<ebarrett>
chrisseaton: so is this only for the latest version of jruby>
<ebarrett>
?
e_dub has joined #jruby
<chrisseaton>
yes, but you can run the same commands and get dependencies for your version
<chrisseaton>
if you get stuck because of a snapshot (which is what I guess you are getting), just remove the -SNAPSHOT part of the version and I'm pretty sure it will work
<chrisseaton>
ebarrett: ^
<ebarrett>
i think we can update to the latest release
<chrisseaton>
I think graal-core and truffle are tagged now - so if you get latest JRuby, you should be able to get the graal-vm-0.12 of everything else
<chrisseaton>
in fact you could also use the graal-vm-0.12 tag of JRuby as well
<ebarrett>
you should add tags for each release
<ebarrett>
i think we use graal 0.13
<ebarrett>
i built that separately, hope that is ok
<chrisseaton>
that's the latest version then, not a release
<ebarrett>
oh, right
<ebarrett>
I think we used it because it was the latest tagged version
bbrowning has quit [Quit: Leaving]
<chrisseaton>
I recommend you build graal-vm-0.12 of everything
<chrisseaton>
Each month there should be a new version with consistent tags
bbrowning has joined #jruby
<chrisseaton>
I think we'll be trying to stick to that this time :)
<chrisseaton>
I will even start tagging the jruby-build-pack for you
enebo has joined #jruby
<ebarrett>
alright
<ebarrett>
I wish we had known
<chrisseaton>
about the build-pack? I only set it up a few days ago
<lopex>
subbu: oh you can say something about that ^^
<enebo>
lopex: about how similar Japanese and Chinese is?
<subbu>
:)
<lopex>
enebo: I guess ?
<lopex>
oh, nope
<lopex>
subbu: sorry
<enebo>
I do know something about written language enough to see telltale of Japanese but knowing if an all kanji block is one or the other is not easy
<enebo>
audilbly they sound a lot different
<lopex>
yeah, but ppl knowing none of that conflate them
norc has quit [Read error: Connection reset by peer]
<GitHub42>
[jruby] chrisseaton created truffle-gem-pack (+1 new commit): https://git.io/voRyD
<GitHub42>
jruby/truffle-gem-pack 6dbb597 Chris Seaton: [Truffle] Install gems for testing in one go and then have a configurable GEM_HOME
<GitHub36>
[jruby] chrisseaton opened pull request #3971: [Truffle] Install gems for testing in one go and then have a configur… (master...truffle-gem-pack) https://git.io/voRyF
<enebo>
lopex: this video is fun but wtf is up with the background music
<enebo>
lopex: I feel like I have another tab open
<lopex>
enebo: dont ask me
<enebo>
lopex: TELL ME
<lopex>
enebo: what's the state of JI and java Strings, are they cached ?
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
yfeldblum has quit [Remote host closed the connection]
<enebo>
lopex: RubyString does save a field if you mean that
<lopex>
enebo: and it leaks ?
<lopex>
I mean hard ref
<enebo>
lopex: well only if you retain the Ruby string
<lopex>
enebo: lol, what if jruby supplied it's own j.l.String just as that Click hashmap ?
<enebo>
lopex: actually we have no cache table for ruby strings so I would say we only cache in the sense that it is useful to have String version from Java handy
<lopex>
though j.l.String is deeper in the bootstraping than the util package
<enebo>
lopex: that is madness
<lopex>
enebo: hmm but in runtime you can know (on IR) that you'll using j.l.String to call via JI right ?
<lopex>
oh, that might help literals only
<enebo>
lopex: nope not at present
<enebo>
lopex: IR has no JI knowledge
<lopex>
enebo: but it seems doable
<enebo>
lopex: we could definitely make special JI call instr which can potentially use unboxed Java Strings but I have not thought about it
<lopex>
otherwise it would be cool for supply own impl and reuse same buffers everywhere
<enebo>
lopex: we make live values in much of the system Object and not IRubyObject so we should be able to use non Ruby objects whereever
bga57 has joined #jruby
<chrisseaton>
enebo: we allow Java strings for calls
<GitHub53>
jruby/master 3a37205 Thomas E. Enebo: EQQInstr has added a splattedValue field. This new field is used...
<enebo>
chrisseaton: yeah if we could know a particular call accepted String we could do it too
<enebo>
chrisseaton: beyond JI I htink we could probably do this in limited cases for some Ruby-native-impld methods but we have never tried to figure that out
<enebo>
our IR is pretty limited to only knowing about Ruby objects atm
<enebo>
we did our numeric unboxing experiments so we can go in that direction but we haven’t
<enebo>
and the unboxing is stranger in a sense since we had to add lots of crud for primitives
<enebo>
Java Objects should be a little easier to make work since we store values as Object already
<chrisseaton>
did you know Rubinius actually has a custom LLVM phase to unbox floats by looking for the call that does the boxing? I think it's their only custom optimisation
<enebo>
s/has/had
<enebo>
chrisseaton: no I did not know that
<chrisseaton>
enebo: you know headius removed the restriction on the branches that Travis runs on? It will *double* your load on Travis for pull requests if the branches are in the jruby repo - https://github.com/jruby/jruby/pull/3971
<chrisseaton>
see it's triggered for /pr and /push
<chrisseaton>
don't know if he realised that
<enebo>
chrisseaton: he may not have
<enebo>
chrisseaton: we limited to test_ and our because we fell behind
<enebo>
chrisseaton: I will try and remember to bring that up but you could also email that too him since I do not think he is around
<GitHub118>
[jruby] chrisseaton force-pushed truffle-gem-pack from 6dbb597 to 03d6923: https://git.io/voRQ2
<GitHub118>
jruby/truffle-gem-pack 03d6923 Chris Seaton: [Truffle] Install gems for testing in one go and then have a configurable GEM_HOME
enebo has quit [Quit: enebo]
skade has joined #jruby
skade has quit [Client Quit]
bga57 has quit [Quit: Leaving.]
yfeldblum has joined #jruby
<GitHub177>
[jruby] chrisseaton force-pushed truffle-gem-pack from 03d6923 to 2ed334f: https://git.io/voRQ2
<GitHub177>
jruby/truffle-gem-pack 2ed334f Chris Seaton: [Truffle] Split test gems and ecosystem, and allow gems to be used from somewhere else rather than installing.
prasunanand has quit [Read error: Connection reset by peer]
lanceball is now known as lance|afk
yfeldblum has quit [Remote host closed the connection]
yfeldblum has joined #jruby
yfeldblu_ has joined #jruby
skade has joined #jruby
yfeldblum has quit [Read error: Connection reset by peer]
<GitHub179>
[jruby] chrisseaton pushed 1 new commit to master: https://git.io/voRAB
<GitHub179>
jruby/master 3acdc1d Chris Seaton: [Truffle] Split test gems and ecosystem, and allow gems to be used from somewhere else rather than installing.
<GitHub135>
[jruby] chrisseaton closed pull request #3971: [Truffle] Install gems for testing in one go and then have a configur… (master...truffle-gem-pack) https://git.io/voRyF
<GitHub80>
[jruby] chrisseaton deleted truffle-gem-pack at 2ed334f: https://git.io/voRA6
quadz has joined #jruby
<lopex>
chrisseaton: do you have perf-ci history for each bench ?
enebo has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
eam has quit [Changing host]
eam has joined #jruby
<chrisseaton>
lopex: benchmark results? yeah. they're not public I'm afraid
enebo has quit [Quit: enebo]
<lopex>
chrisseaton: you have an idea how vm boxes skew the numbers ?
<lopex>
like what os, what nice levels etc
<lopex>
I'm totally blind here
<chrisseaton>
results seem to be generally rather stable across os. we aren't looking at this in more depth, but ebarett, who was talking above, is looking in more depth about this effects benchmarking
<lopex>
but I was more leaning towards os process time stability
<chrisseaton>
i'm not sure what you mean by process time? isn't process time a function of code execution time?
<lopex>
yes
<lopex>
er, sorry, what I mean is just the noise
<lopex>
can the os/scheduler noise affect the benchmarks you run ?
<chrisseaton>
yes, but it's so so hard to control for it
<chrisseaton>
as I said in my phd, if we were talking 0.5% increases due to new compiler optimisations, it's really important, but we're dealing with 10x increases in performance so it's less critical
<lopex>
but nice can reduce that right to certain level ?
<chrisseaton>
but you shouldn't have anything running in the background to be affected by nice
<lopex>
yeah, I know, it's not the time to talk about that yet