pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
nowhereFast has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
<etehtsea>
ls
<etehtsea>
oops
pawnbox has quit [Ping timeout: 265 seconds]
pawnbox has joined #jruby
blaxter has joined #jruby
blaxter has quit [Client Quit]
raeoks has joined #jruby
kith has quit [Quit: kith]
shellac has joined #jruby
pawnbox_ has joined #jruby
pawnbox has quit [Read error: Connection reset by peer]
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
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
bbrowning_away is now known as bbrowning
bbrowning_ has joined #jruby
bbrowning has quit [Ping timeout: 244 seconds]
bbrowning_ is now known as bbrowning
claudiuinberlin has quit [Remote host closed the connection]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
<chrisseaton>
Why is JFFI's memory so complicated? allocate, allocateDirect, allocateTemporary, transient memory, bounded memory, direct memory, what is all of this?
tomjoro has joined #jruby
<chrisseaton>
MemoryIO, Foreign, the abstractions go on forever
blaxter has joined #jruby
blaxter has quit [Client Quit]
claudiuinberlin has joined #jruby
pawnbox has quit [Remote host closed the connection]
claudiuinberlin has quit [Remote host closed the connection]
claudiuinberlin has joined #jruby
blaxter has joined #jruby
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
tomjoro has quit []
cremes has joined #jruby
raeoks has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
johnsonch_afk is now known as johnsonch
raeoks has joined #jruby
raeoks has quit [Client Quit]
raeoks has joined #jruby
raeoks has quit [Client Quit]
pawnbox has quit [Remote host closed the connection]
cremes has quit [Quit: cremes]
cremes has joined #jruby
vtunka has quit [Quit: Leaving]
cremes has quit [Client Quit]
nicksieger has joined #jruby
prasunanand has quit [Remote host closed the connection]
pawnbox has joined #jruby
cremes has joined #jruby
pawnbox has quit [Ping timeout: 255 seconds]
pawnbox has joined #jruby
thedarkone2 has joined #jruby
<GitHub15>
[jruby] shahkia opened issue #4143: DRB Exception in thread Ruby-0-Thread-1 multiple connections https://git.io/viBIB
pawnbox has quit [Ping timeout: 265 seconds]
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
<headius>
ahh, so like what Panama will do for Hotspot
<headius>
yes, they all go through JNI, but how you go through JNI makes a big difference
<headius>
for something like malloc with only primitives in and out jffi will generate a tiny JNI stub that just does the native call and returns the pointer...so there's JNI overhead but in at least a couple cases I've seen it was better than a C impl of that jni endpoint
pawnbox has quit [Ping timeout: 264 seconds]
<headius>
I imagine NFI is not capturing errno...that's optional in jffi but nice to have
<headius>
jnr-ffi rather
<headius>
so if you did a blocking call through NFI you could hang the whole JVM I suppose, eh?
<headius>
GNFI
<headius>
we could also do a little work to make jffi use GNFI when it's available :-)
<chrisseaton>
Well GNFI puts the thread in a safe point like JNI does I presume
<chrisseaton>
GNFI is in GraalVM today so someone could try if they wanted
<chrisseaton>
Actually it may not be... it should be soon if it isn't
<chrisseaton>
Sulong should be in GraalVM soon as well
<headius>
given that jffi/jnr-ffi already have logic for generating and loading asm, it shouldn't be a big leap to have them just use GNFI
<chrisseaton>
Says here that the stub is created by the JIT in the caller
<headius>
that's what I figured
<headius>
so it's able to inline and optimize the stub
<chrisseaton>
I'm seeing this 'Could not resolve dependencies for project org.jruby:jruby-stdlib:jar:9.1.6.0-SNAPSHOT: Could not find artifact org.jruby:jruby-core:jar:9.1.6.0-SNAPSHOT in mavengems (mavengem:https://rubygems.org) -> [Help 1]'
<chrisseaton>
When I try to dependency:go-offline
<headius>
chrisseaton: I noticed that too...a full build fixes it for me, but it seems like something build-time started to depend on being-built artifacts
<chrisseaton>
christ
<headius>
like maven gem installation might have been modified to use "this JRuby" rather than a known release
<headius>
wasn't anything I did, though
dinfuehr_ has joined #jruby
<headius>
chrisseaton: do you see a message "using jruby ...."?
<chrisseaton>
using jruby 9.0.5.0
<headius>
hmph
<headius>
worst case you should be able to `mvn install` and have binaries for those in your local repo
<headius>
it should work ok then
<headius>
you're also trying to go offline but depending on snapshot builds that don't exist in maven central
<headius>
or at least maven thinks you're doing that
<chrisseaton>
I'll try installing into my offline repo
<headius>
yeah, I don't see anything obvious in the poms and no commits that would explain it
<headius>
I thought it was just me
<chrisseaton>
We like to have a checksum set of dependencies so we can always rebuild in isolation
<headius>
sure
<headius>
truffle depends on jruby-core/stdlib though so it's probably getting messed up with the snapshot
<headius>
there's nothing to offline
<chrisseaton>
it used to work a month ago
<headius>
I figured that too :-\ I assume something changed but I can't see it
<headius>
mkristian to the rescue? open an issue and maybe he'll know what happened
<GitHub118>
[jruby] chrisseaton pushed 1 new commit to truffle-head: https://git.io/viRTk
<GitHub118>
jruby/truffle-head 5a2277b Chris Seaton: [Truffle] While we're using 0.17 we can build offline.
temporalfox has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<GitHub120>
[jruby] chrisseaton deleted graal-vm-0.16 at d9da515: https://git.io/viRkI
<thedarkone2>
chrisseaton: "If I have a tag on a commit in git, but delete the branch, is the commit still accessible?" dunno if you've solved it: yes, the commit and the whole history should be there (they should be around even if you delete the tag, unless your git did its GC cleanup, there are git cmds to recover stuff)
<chrisseaton>
right but the gc sees the tag as a strong reference?
<thedarkone2>
dunno, but probably yes
<headius>
sorry
<headius>
I missed that question
<headius>
the commit stays until GCed
<headius>
I doubt the tag anchors the commit, myself
<headius>
since the commit has no parent
<headius>
or at least it has no root anymore
<headius>
why do you need this?
<headius>
chrisseaton: ^
<headius>
this article seems to say the tag will anchor the commit
<chrisseaton>
we used a random commit that's not actually on the truffle-head branch in GraalVM 0.16, and I want to tag it as being the tagged used in that release
<headius>
try git fsck --unreachable
<headius>
chrisseaton: whether tags anchor it or not, that seems incredibly fragile
<chrisseaton>
I thought a tag was as good of a 'top level name' as a branch
<headius>
if it were I'm not sure why you'd need both
<headius>
can't you cherry-pick the commit in and retag it?
<chrisseaton>
cherry pick means it's a different commit though
<headius>
so?
<chrisseaton>
well that means it's not the same code
<headius>
no it doesn't
<chrisseaton>
oh wait I can just merge the branch and then reset to one side of it
<headius>
it means it has a different parent
<headius>
that's all
<chrisseaton>
but the parent would have different code?
<headius>
there will be two commits, yes, but with identical changeset (merge tweaks notwithstanding)
<headius>
well maybe I'm not understanding why you want to reference this orphaned commit
<chrisseaton>
I think I can just do a merge - thanks though
<headius>
the release was done against the branch and then the branch was deleted?
<chrisseaton>
no, the release was done against a branch, but is it right to keep a branch like that around forever?
<chrisseaton>
I thought of branches as working things
<headius>
I think so
<headius>
we never release a branch that has been use for a release
<headius>
er delete a branch
<headius>
I think most projects would agree
<chrisseaton>
this was a bit of a shameful branch in the first place :)
<chrisseaton>
with a fix that shouldn't have been needed
<headius>
ahh, well then
<headius>
merge should be fine
<headius>
generally though I think it's pretty weird to have a tag to a commit that doesn't exist on any branch
<GitHub50>
[jruby] chrisseaton tagged graal-vm-0.14 at d2f2fcf: https://git.io/viRLg
<GitHub144>
[jruby] chrisseaton pushed 1 new commit to truffle-head: https://git.io/viRLz
<GitHub144>
jruby/truffle-head e32e17d Chris Seaton: Merge branch 'truffle-no-io-exception' into truffle-head
<GitHub185>
[jruby] chrisseaton tagged graal-vm-0.16 at 9c700dd: https://git.io/viRey
<GitHub92>
[jruby] chrisseaton deleted truffle-no-io-exception at dd4076b: https://git.io/viRLa
<headius>
chrisseaton: fwiw we also keep our branches around because we occasionally need to do one-off security fixes
<thedarkone2>
headius: some people hate having a bunch of branches...
<headius>
well, we also don't have a branch for every single release
<chrisseaton>
headius: changing the subject... how are you getting on with running JRuby on JDK 9? It's not trivial is it?
<headius>
but the tags are always pointing to a live branch
<headius>
chrisseaton: works fine
<headius>
I had to twiddle a few things
<headius>
I did all my work this week against 9 without realizing it
<chrisseaton>
what did you have to do to use unsafe?
<headius>
we don't need unsafe to run
<headius>
it may impact perf (synchronization instead of fences) but we can run...and we'll deal with the perf issues once varhandles etc land
<headius>
JRuby can usually run Ruby apps fully secured and non-native
<chrisseaton>
Right, so is there more work to do to be able to use unsafe and other things?
<headius>
well, unsafe can be replaced with varhandles
<headius>
at least the parts we use
<chrisseaton>
Oh I see
<chrisseaton>
Didn't realise you used that little of it
<chrisseaton>
We use the signals from sun.misc as well - not sure what has happened to them
<headius>
yeah that I'm not sure about
<headius>
we can't just start doing our own obviously
<headius>
or at least not without breaking the JVM
<chrisseaton>
Ok but sounds like I should at least be able to get JRuby+Truffle booting up
<headius>
jruby itself is ready for that...so you'd just need to guard any accesses to unsafe and friends and have a fallback
<headius>
chrisseaton: oh in case you start playing with that... the build doesn't work in 9 yet
<headius>
because it uses JRuby versions before my 9 patches
<thedarkone2>
re GNFI, if I remember it correctly, it wasn't safepointing and that passing java managed obj into GNFI call was allowed, exactly because it wasn't a safepoint..
<thedarkone2>
so its like "no overhead", but "lets hope the call returns reaaally fast"
<headius>
thedarkone2: that would explain why it beats JNI then
<headius>
if that's the case
<thedarkone2>
haha, like that Cliff Click's slide, where it looked like JNI prologue/epilogue must be summing Cthulhu (as a side effect of the native call)
<headius>
thedarkone2: yeah exactly :-)
nicksieger has quit [Remote host closed the connection]
<headius>
ok, I'm calling it a day...probably be hacking over the weekend
<headius>
ttfn folks
claudiuinberlin has quit []
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 250 seconds]
brauliobo has joined #jruby
<GitHub125>
[jruby] chrisseaton pushed 1 new commit to truffle-head: https://git.io/viRZu
<GitHub125>
jruby/truffle-head e708660 Chris Seaton: [Truffle] Update readme.