<GitHub14>
jruby/master 70bad1f kares: [travis-ci] let's try excluding truffle module from mvn on targets that do not use it
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #jruby
<GitHub23>
[jruby] perlun closed issue #1256: __FILE__ is broken with -Djruby.compile.mode=FORCE when mixing forward and backward slashes https://git.io/vVVGx
<GitHub76>
jruby/master 755d7c6 kares: [test] a quick and dirty benchmark comparing our String split performance
<GitHub76>
jruby/master ab12014 kares: allow Java proxies to be coerced into our own Ruby type system e.g. IRubyObject...
<GitHub76>
jruby/master 6843b55 kares: [test] allow to specify a TEST_CONCURRENT_TIMEOUT for dead-lock analysis
<GitHub155>
[jruby] kares closed issue #1925: jruby can't use it's own java classes https://git.io/vVwIo
<GitHub123>
[jruby] kares closed issue #3204: java_signature cannot parse properly in a REPL after jruby/core_ext has been required https://git.io/vO39e
elia has joined #jruby
bbrowning_away is now known as bbrowning
shellac has quit [Remote host closed the connection]
pawnbox has quit [Remote host closed the connection]
bengt_ has quit [Read error: Connection reset by peer]
bengt_ has joined #jruby
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
<headius>
nirvdrum: the .freeze was my idea, since the proposed "string"f suffix would have been unparsable by anything prior to 2.2
<headius>
and behaviorally it's almost indistinguishable from non-optimized since it always just produces a frozen string... the optimization just makes it return the same object
<headius>
it's not a great hack but I still feel like it was better than the ugly, backwards-incompatible syntax
tcrawley-away is now known as tcrawley
brightball has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
<brauliobo_>
chrisseaton: is the jruby truffle still available to install with ruby-build?
pawnbox has joined #jruby
Scorchin has quit [Remote host closed the connection]
guilleiguaran__ has quit [Read error: Connection reset by peer]
deathy has quit [Remote host closed the connection]
<GitHub103>
jruby/master 1c3ae19 kares: make these java proxy internal methods final
<GitHub103>
jruby/master 33f883f kares: ArrayJavaProxy#setup can now be deleted + make op_aref final as well
<GitHub103>
jruby/master 7ad625f kares: [test] java proxy to IRubyObject coercion with Java arrays as well
Aethenelle has joined #jruby
skade has joined #jruby
pitr-ch has joined #jruby
<GitHub4>
[jruby] chrisseaton pushed 3 new commits to master: https://git.io/vVrkz
<GitHub4>
jruby/master 16e9fe8 Chris Seaton: [Truffle] Getting the time is safe.
<GitHub4>
jruby/master 851f6b7 Chris Seaton: [Truffle] Range is safe.
<GitHub4>
jruby/master 77ea9c4 Chris Seaton: [Truffle] Audit safety of TrufflePrimitiveNodes.
<headius>
eregon, chrisseaton: now is the time to get truffle support into mjruby
<headius>
don't know how much of truffle launching is tied up in jt, but mjruby will become the new native launcher and it should be easier to support truffle with it
<chrisseaton>
i had that on my todo list - what's the reason now is good?
<headius>
because we want to shil mjruby as launcher for 9.1
<headius>
ship
<headius>
or at least, around 9.1 jruby-launcher will becoming mjruby + jruby-launcher for older platforms
<headius>
not older, weird or unsupported platforms
<chrisseaton>
I'll take a look at it - I think there was just one bug
<headius>
ok
<headius>
it could certainly launch jt if that's necessary, but in any case it will all just be ruby to launch stuff now
<headius>
but needs to be built into mjruby ahead of time
<eregon>
headius: jt should not be needed, it should be just adding stuff to classpaths and translating some options
<enebo>
eregon: 1.7.0_99-b00
<enebo>
eregon: Those CLIs above show him on 1.7. Does that matter?
<enebo>
headius: jruby-launcher will add mrjuby into it
<enebo>
heheh sorry
<enebo>
You then said that next line
<eregon>
enebo: nope, since it was just not picking Graal
<headius>
eregon: cool
<headius>
there's a 1.7.0_99?
<headius>
I'm impressed
<headius>
not just that they got to 99 (they bump feature releases to next mod 20) but that they managed to have u80 with 19 small fixes
skade has quit [Quit: Computer has gone to sleep.]
Guest78435 is now known as Cyrus
Cyrus has joined #jruby
Cyrus has quit [Changing host]
rcvalle has joined #jruby
pawnbox has quit [Remote host closed the connection]
bb010g has quit [Quit: Connection closed for inactivity]
elia has quit [Quit: Computer has gone to sleep.]
xardion_ has joined #jruby
xardion has quit [Ping timeout: 244 seconds]
brightball has quit [Quit: Leaving...]
<donV>
enebo: head: all: We are running JRuby on in-vehicle systems with 512MB memory. We are now running JRuby 9K, and experience higher memory use. Any good settings to reduce memory use? “—dev” mode perhaps?
<donV>
heap has been limited to 256M for many years, but non-heap memory use has increased, it seems.
<GitHub2>
jruby/master 2403597 Kevin Menard: [Truffle] Removed the CodeRangeable wrapper for Symbol now that we can do everything through ropes.
<enebo>
donV: yeah but it is still being use in JVM6 bytecode generation unless you disable JT
<enebo>
donV: just not a ton of it
<donV>
enebo: We are running Oracle JVM 8. Does it still apply?
<enebo>
donV: right now largely with —dev we are I think about 20%ish more than 1.7
<enebo>
donV: with JIT on we copy all instrs so effective double memory for any JIT’d code in just IR representation
<enebo>
donV: once instrs can be shared and most are immutable we will get rid of most of that
<donV>
enebo: OK, I’ll run with —dev for now, then.
<enebo>
donV: I wanted to get to it earlier but I want 1.7.25 and 9.1.0.0 to be solid enough to spend a little less time on issues and more time on stuff like what I just talked about
<donV>
Fine by me :) You are doing great work!
<enebo>
donV: thanks. jobs is always fun at some level but some stuff is more enjoyable than other stuff :P
<donV>
enebo: I tried jruby-launcher in some of our projects today, but it did not fit our setup.
<donV>
enebo: We package on OS X and ship to Linux.
<enebo>
donV: look at mjruby
<enebo>
donV: it will be the future of jruby-launcher
<enebo>
donV: and if you run into issues then codefinger would love to know what they are
<codefinger>
yup
<donV>
enebo: Does it help? Our problem was that we package the OS X binary which fails on Linux.
skade has quit [Quit: Computer has gone to sleep.]
<donV>
codefinger: Hi!
<codefinger>
donV: heya
<donV>
codefinger: Regarding jruby-launcher / mjruby : We package on OS X, but ship to Linux. Is there a good way to do it?
<donV>
codefinger: jruby.bash works everywhere :)
<enebo>
donV: yeah codefinger can give a better explanation but it builds all common platforms via docker
<codefinger>
i've found jruby 9k uses a lot more off-heap mem too
<enebo>
codefinger: donV: hmm perhaps it is more native IO
<enebo>
that is another big 9k difference
<enebo>
I know we use more heap too :)
bjfish2 has quit [Ping timeout: 244 seconds]
<donV>
enebo: codefinger: The off-heap memory use has lead to swapping on our systems. The heap use is controlled.
<codefinger>
donV: for mjruby i use a project called mruby-cli that has the various platform build stuff all set up in Docker
<codefinger>
enebo: it's ok. i don't recall paying you any money ever, so no obligation :)
<enebo>
codefinger: yeah I just would like to know
<enebo>
codefinger: and if I remember it does not seem to be a leak
<enebo>
codefinger: but it grows a lot
<enebo>
initially
<codefinger>
yea, i think so
<enebo>
codefinger: It seems like a coincidence but nearly every day I talk to you I happen to talk to Terrence
<enebo>
codefinger: If I did not know you two were different people I would be suspicious
<enebo>
codefinger: although I mentioned you first today for something relevent
<codefinger>
yea, i'm good a usurping conversations to get things i need
<codefinger>
donV: did i help you at all? sorry.
<donV>
codefinger: I wonder if mjruby offers a way to package JRuby so it runs on both OS X and Linux.
<donV>
codefinger: And thanks for confirming the increased off-heap memory use!
<donV>
And thanks all for just being positive and helpful! :)
<codefinger>
donV: ah, maybe. it doesn't actually package JRuby (although I though a future project might be an auto-install step if it can't find JRUBY_HOME). but you could package mjruby *with* your app and JRuby runtime
<codefinger>
mjruby is smart and can find the JDK without much any help. it just needs the jruby home (either it needs to be in JRUBY_HOME/bin or the env var is set)
<enebo>
donV: codefinger: the build process can build all the normal platforms from any docker supporting platform though right?
<codefinger>
the build process for mjruby? yea: linux, mac, win (32 and 64)
<donV>
We deploy to limited in-vehicle systems with no compilers etc.
<donV>
We need to package everything up and just rsync over.
<donV>
jruby.bash does the job today. What are the benefits of mjruby?
<GitHub66>
[jruby] chrisseaton pushed 13 new commits to master: https://git.io/vVrD4
<GitHub66>
jruby/master 123c9a2 Chris Seaton: [Truffle] We'll call simple shell unsafe because of IO.
<GitHub66>
jruby/master 8055726 Chris Seaton: [Truffle] WeakRef is safe.
<GitHub66>
jruby/master 2e6e4f7 Chris Seaton: [Truffle] String is safe.
<codefinger>
most that it's not bash :)
<codefinger>
s/most/mostly/
<codefinger>
it's also better at finding the JDK
<codefinger>
even if it's not on PATH
<donV>
codefinger: By if you don’t cat jruby.bash you would never know :)
<enebo>
shebang lines in shell scripts work with options
<donV>
codefinger: We package the JVM as well.
<enebo>
ps will list it as jruby
<donV>
enebo: If you use “env” it works.
<enebo>
donV: does not sound like you get much from this
<enebo>
donV: sure if it does on your environment than good
<donV>
:)
<enebo>
donV: I guess not all ‘env’ will or some wrinkle
<donV>
enebo: Probably. We usually start our scripts explicitly using jruby.
<enebo>
donV: sounds like a native launcher would just complicate your builds
<donV>
Yeah, I think so.
<donV>
codefinger: enebo: Thanks for the insight.
pawnbox has quit [Remote host closed the connection]