<chrisseaton>
ebarrett: you're not going to like this.... it's a mis-matched version of graal I think
<chrisseaton>
'java.lang.NoSuchMethodError'
<ebarrett>
oh my
<ebarrett>
ive also noticed graal as a standalone java vm is saying: Exception in thread "main" java.lang.IllegalStateException: JVMCI server was not enabled.
<ebarrett>
i'll re-check my graal versin etc after lunch
<chrisseaton>
sigh ok can you give me the commit hashes of all your repos when you're ready
<ebarrett>
chrisseaton: are you around after lunch?
<chrisseaton>
yeah
<ebarrett>
i need to eat :)
<ebarrett>
see you in an hour or so
<ebarrett>
this may be my fault btw
pawnbox has joined #jruby
tobi__ has quit [Ping timeout: 272 seconds]
tcrawley-away is now known as tcrawley
tobi__ has joined #jruby
e_dub has quit [Quit: ZZZzzz…]
skade has joined #jruby
e_dub has joined #jruby
e_dub has quit [Client Quit]
pawnbox has quit [Remote host closed the connection]
<ebarrett>
especially since running a java benchmark under grall gives: Exception in thread "main" java.lang.IllegalStateException: JVMCI server was not enabled.
<ebarrett>
trying: '${MX} build' instead of '${MX} --vm server build'
<headius_>
chrisseaton: I just happen to be for a moment
<headius_>
what's up
<chrisseaton>
when you use JRuby from something like 223 (scripting API), or embedded in some other way, how can you add things to the load path?
<headius_>
load path or class path
<headius_>
?
<chrisseaton>
the Ruby -I load path
<headius_>
via 223, not really via any standard API...you would evaluate code that modifies load path before running the target code
<headius_>
223 is pretty blunt
<chrisseaton>
I'm thinking of doing a system properties that works like JRUBY_OPTS (only would work for options that don't need to do anything in the launcher) what do you think?
<headius_>
our embedding API I believe has a method for that
<headius_>
you can initialize it or otherwise set it up with a specific load path
<chrisseaton>
I have a similar embedded situation (not quite the same, but would take a long time to explain) and I need to add Ruby arguments
<headius_>
chrisseaton: isn't that RUBY_OPTS?
<headius_>
or whatever it is
<headius_>
RUBYOPT
<chrisseaton>
but that's handled by the launcher isn't it? or is it not? if not that's perfect
<headius_>
it's not...only JRUBY_OPTS has to be preprocessed
<chrisseaton>
great, that'll work thanks very much
<headius_>
RUBYOPT is handled in ArgumentProcessor I beleve
<headius_>
ok
<GitHub24>
[jruby] chrisseaton pushed 1 new commit to master: https://git.io/voK6U
<GitHub24>
jruby/master 192a408 Chris Seaton: [Truffle] Truffle::Interop.from_java_string
subbu is now known as subbu|afk
<GitHub178>
[jruby] chrisseaton pushed 1 new commit to master: https://git.io/voK6B
<GitHub178>
jruby/master d6489ff Chris Seaton: [Truffle] Fix bad tags.
subbu|afk is now known as subbu
pilne has joined #jruby
<GitHub161>
[jruby] chrisseaton pushed 2 new commits to master: https://git.io/voK1m
<GitHub161>
jruby/master 32ed526 Chris Seaton: [Truffle] Exporting Truffle::CExt isn't a shim.
<GitHub161>
jruby/master eda033a Chris Seaton: [Truffle] RUBYOPT now handled in contexts created by Polyglot.
<nirvdrum>
lopex: Do you have any thoughts on making Encoding#isAsciiCompatible a final field?
<nirvdrum>
It's only mutated for dummy encodings currently and I think that can be handled differently.
<GitHub6>
[jruby] chrisseaton pushed 1 new commit to truffle-head: https://git.io/voK1c
<GitHub6>
jruby/truffle-head 5b75da4 Chris Seaton: Merge branch 'master' into truffle-head
dinfuehr has joined #jruby
tcrawley-away is now known as tcrawley
Aethenelle has joined #jruby
<lopex>
nirvdrum: like passing it through constructor chain ?
<GitHub74>
[jruby] chrisseaton pushed 1 new commit to master: https://git.io/voKD2
<GitHub74>
jruby/master 3aeb07e Chris Seaton: [Truffle] 'targets', not 'target' in CI config.
bbrowning is now known as bbrowning_away
<nirvdrum>
lopex: It's already set in the constructor. It's just not final to support dummy encodings, I think.
<lopex>
yes
<lopex>
nirvdrum: you want to have it final and dont sacrifice additional checks right ?
<lopex>
I meant sacrifice single boolean check
<lopex>
nirvdrum: I think the problem is in somewhat divorced entry list dummy info
<nirvdrum>
lopex: The compiler would be happier if that field were final. I can work around it, but it seems making it final should be doable. I just wasn't sure how strongly you felt about the current dummy handling.
<GitHub59>
[jruby] chrisseaton pushed 2 new commits to truffle-head: https://git.io/voKSk
<GitHub59>
jruby/truffle-head 8b93dd1 Chris Seaton: Merge branch 'master' into truffle-head
<GitHub59>
jruby/truffle-head 4f2a7c3 Chris Seaton: [Truffle] Quiet mx build.
<lopex>
nirvdrum: so graal does care more about final fields than hotspot ?
<lopex>
nirvdrum: yeah, I'd like to have it final even from correctness perspective
<chrisseaton>
JRuby in general should care about final fields
<nirvdrum>
I think both care in this case. I can't do something like "if (encoding.isAsciiCompatible())" and have one of the branches compile away because the field could be either true or false.
<lopex>
I havent seen any perf diff wrt final instance fields but it was quite abit ago
<lopex>
nirvdrum: ideally isDummy could be final if you could pass that on construction
<lopex>
given entry dummy info
<nirvdrum>
I haven't looked at the dummy part much. headius_ did some work in there not too long ago, IIRC, though.
<lopex>
nirvdrum: hmm, I think static blocks in encoding classes might do the trick
<lopex>
nirvdrum: since it could do the lookup in encoding db
<lopex>
but that would require some rejigerring
<lopex>
but that would block making encoding db per runtime in the future
<GitHub185>
jruby/master 8ef7da7 Brandon Fish: [Truffle] Add hash flag to sprintf grammar for alternative formats
<nirvdrum>
lopex: You'd know better than me.
<nirvdrum>
I can take a crack at coming up with something if you don't have the time.
cheerfulstoic has joined #jruby
<cheerfulstoic>
I'm building a gem that uses a TCPSocket and I'm testing the support for jRuby now. I get the message "sendmsg is not implemented", but I'm not sure what would be an alternative (or if there even is one). Anybody know?