digitalextremist has quit [Ping timeout: 248 seconds]
rjmilitante has quit [Ping timeout: 248 seconds]
djellemah has quit [Ping timeout: 248 seconds]
_ko1 has quit [Ping timeout: 248 seconds]
justinmcp has quit [Ping timeout: 248 seconds]
emakris has quit [Ping timeout: 248 seconds]
_ko10 has quit [Client Quit]
emakris has joined #jruby
_ko1 has joined #jruby
mjc_ has quit [Quit: Connection closed for inactivity]
e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
e_dub has quit [Read error: Connection reset by peer]
Aethenelle has joined #jruby
e_dub has joined #jruby
edub has joined #jruby
e_dub has quit [Quit: ZZZzzz…]
tomjoro has joined #jruby
mattwildig has quit [Remote host closed the connection]
tomjoro has quit [Ping timeout: 248 seconds]
_whitelogger has quit [Ping timeout: 260 seconds]
_whitelogger_ has joined #jruby
havenwood has quit [Read error: Connection reset by peer]
havenn is now known as havenwood
mysteriouspants_ is now known as mysteriouspants
mpapis has joined #jruby
clayton has joined #jruby
qmx has joined #jruby
Tristit1a has joined #jruby
edub has joined #jruby
codefinger has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
johnsonch_afk is now known as johnsonch
Tristit1a is now known as Tristitia
Antiarc has quit [Quit: No Ping reply in 180 seconds.]
Antiarc has joined #jruby
Antiarc has quit [Quit: No Ping reply in 180 seconds.]
Antiarc has joined #jruby
tomjoro has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
tomjoro has quit [Ping timeout: 276 seconds]
johnsonch is now known as johnsonch_afk
pawnbox has quit [Ping timeout: 276 seconds]
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 252 seconds]
pawnbox has joined #jruby
nirvdrum has quit [Ping timeout: 246 seconds]
tomjoro has joined #jruby
mattwildig has joined #jruby
tomjoro has quit [Ping timeout: 260 seconds]
mattwildig has quit [Ping timeout: 248 seconds]
djellemah_ is now known as djellemah
pawnbox has quit [Remote host closed the connection]
mpapis has quit [Ping timeout: 250 seconds]
pawnbox has joined #jruby
mpapis has joined #jruby
_whitelogger_ has quit [Excess Flood]
_whitelogger has joined #jruby
donV has joined #jruby
skade has joined #jruby
donV has quit [Quit: donV]
mysteriouspants has quit [Changing host]
mysteriouspants has joined #jruby
thedarkone2 has quit [Quit: thedarkone2]
jeremyevans has quit [Read error: Connection reset by peer]
skade has quit [Quit: Computer has gone to sleep.]
rsim has joined #jruby
norc has joined #jruby
skade has joined #jruby
pawnbox has quit [Remote host closed the connection]
tomjoro has joined #jruby
pawnbox has joined #jruby
mattwildig has joined #jruby
mattwildig has quit [Ping timeout: 260 seconds]
_whitelogger has quit [Excess Flood]
_whitelogger has joined #jruby
pawnbox has quit [Remote host closed the connection]
_whitelogger has quit [Excess Flood]
_whitelogger has joined #jruby
donV has joined #jruby
deobalds has joined #jruby
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
skade has quit [Quit: Computer has gone to sleep.]
_whitelogger has quit [Excess Flood]
_whitelogger has joined #jruby
_whitelogger has quit [Excess Flood]
_whitelogger has joined #jruby
pawnbox has joined #jruby
phlebas has joined #jruby
skade has joined #jruby
deobalds has quit [Quit: Computer has gone to sleep.]
vtunka has joined #jruby
mattwildig has joined #jruby
ITXpander has joined #jruby
mattwildig has quit [Ping timeout: 250 seconds]
deobalds has joined #jruby
rsim1 has joined #jruby
<GitHub10>
[jruby] eregon commented on commit 518703d: Really? The thread there is not registered with the SafepointManager and should never appear (it's not a "Ruby thread"). What would be the value of the `thread` variable? https://git.io/v2SjA
rsim has quit [Ping timeout: 240 seconds]
<GitHub78>
[jruby] eregon commented on commit 566807e: Why the `newVersion()`? https://git.io/v29ex
<GitHub106>
[jruby] eregon commented on commit 518703d: It seems the bug is caused by the buggy `context.getThreadManager().getCurrentThread()`. https://git.io/v29f6
pawnbox has quit [Remote host closed the connection]
rsim1 has quit [Read error: Connection reset by peer]
rsim1 has joined #jruby
rsim has quit [Ping timeout: 240 seconds]
bbrowning is now known as bbrowning_away
rsim1 has quit [Quit: Leaving.]
drbobbeaty has joined #jruby
donV has quit [Quit: donV]
<GitHub92>
[jruby] chrisseaton commented on commit 518703d: It just looked to me like `enterThread` always registers the current thread as a Ruby thread. I wasn't sure if that was intentional or not. https://git.io/v29uR
vtunka has quit [Quit: Leaving]
donV has joined #jruby
phlebas_ has joined #jruby
vtunka has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
tcrawley-away is now known as tcrawley
pawnbox has quit [Ping timeout: 240 seconds]
phlebas_ has quit [Ping timeout: 268 seconds]
deobalds has quit [Quit: Computer has gone to sleep.]
phlebas_ has joined #jruby
phlebas_ has quit [Read error: Connection reset by peer]
pawnbox has joined #jruby
tcrawley is now known as tcrawley-away
mattwildig has joined #jruby
mattwildig has quit [Read error: Connection reset by peer]
mattwildig has joined #jruby
vtunka has quit [Quit: Leaving]
<GitHub59>
[jruby-openssl] mkristian tagged v0.9.16 at master: https://git.io/v29DJ
tcrawley-away is now known as tcrawley
<GitHub20>
[jruby-openssl] mkristian pushed 1 new commit to master: https://git.io/v29DY
<GitHub20>
jruby-openssl/master b8bac99 Christian Meier: next dev version [skip ci]
<headius>
mkristian: I don't understand the integ fails right now, can you help?
<headius>
there's only two left but they've got me stumped
<headius>
for -Pmain I thought it was just a stale Gemfile.lock but updating it did not seem to help
kith_ has joined #jruby
<mkristian>
headius, sure I will have look right now - did not follow travis failures recently
vtunka has joined #jruby
<headius>
we merged 2.3 support to master before it was totally green, but -Pmain and -Pj2ee are the only failures now
kith has quit [Ping timeout: 276 seconds]
vtunka has quit [Client Quit]
<mkristian>
yes on -Pmain it looks like a stale Gemfile.lock - not sure what bundler wants to write out.
<mkristian>
headius, does this merge also comes with a new ruby gems version ?
<headius>
hmm not sure
<headius>
I'll check
<headius>
we don't update rubygems from CRuby repo normally
<headius>
2.5.1 versus 2.4.8
<headius>
so it is more recent
<headius>
we need to get 1.7 out of the 9k builds too, it has some flaky spots
vtunka has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
tomjoro has quit [Remote host closed the connection]
<mkristian>
1.7 ? I moved to jruby-9k with ruby DSL, will look if jruby build uses this already
beawesomeinstead has quit [Ping timeout: 276 seconds]
joast has joined #jruby
bbrowning_away is now known as bbrowning
beawesomeinstead has joined #jruby
brightball has joined #jruby
<headius>
I still see 1.7.x doing some tasks in the builds
<headius>
we may just be behind if the default has changed
<GitHub66>
[jruby] pitr-ch commented on commit 997e219: When I was testing just one PE test file it was getting in a way. I'll move it back to the else branch then. https://git.io/v2HCP
Prasun has joined #jruby
tjohnson has joined #jruby
johnsonch_afk is now known as johnsonch
Prasun has quit [Ping timeout: 276 seconds]
Prasun has joined #jruby
johnsonch is now known as johnsonch_afk
tomjoro has joined #jruby
<GitHub17>
[jruby] mkristian pushed 1 new commit to master: https://git.io/v2HR7
<GitHub17>
jruby/master 34623ff Christian Meier: Revert "use latest ruby DSL for maven"...
<headius>
mkristian: problem?
<headius>
I think I ran into issues when I tried to do that too
pawnbox has quit [Remote host closed the connection]
<mkristian>
headius, much more failures and after revert at least test:mri passed locally
<mkristian>
will do this maven update on test branch and step by step
<headius>
ok
pawnbox has joined #jruby
mattwildig has quit [Remote host closed the connection]
rcvalle has joined #jruby
<headius>
cremes: multithreaded IO eh? what's up?
vtunka has quit [Quit: Leaving]
nirvdrum has joined #jruby
baroquebobcat has joined #jruby
baroquebobcat has quit [Client Quit]
<enebo>
nirvdrum: heya did we ever set up a project for jruby on appveyor? I try to go to the logical url for it and I think it is private
<nirvdrum>
Nope :-/
<nirvdrum>
I think we got sidetracked by the memory model discussion with Matz.
<GitHub73>
jruby/master 2d9ff09 Charles Oliver Nutter: Implement optimized a["b"] with pre-frozen hash key and lazy dup....
<lopex>
nirvdrum: hey there, where did you need that encoding base thing ?
<lopex>
(the one in aliases)
<nirvdrum>
I think I deleted the code that uses it, but was looking to possibly resurrect it. It basically just eagerly loaded encodings to avoid runtime reflection.
<lopex>
why ?
<headius>
hopefully that opto doesn't break a bunch of stuff
<lopex>
it happens only once for every instance
<lopex>
nirvdrum: encodings can load potetially large tables too
<lopex>
*potentially
<nirvdrum>
lopex: Mostly just playing with things. One was for Substrate VM, which can't use runtime reflection. But I was also looking at caching more and having each loaded encoding update a static counter makes that a lot harder.
<lopex>
though the greater offender here is unocode ayways
<lopex>
*unicode
<lopex>
nirvdrum: aah
<nirvdrum>
I don't really expect it to land. I was just trying to make my life a bit easier in my workspace here.
bbrowning_away is now known as bbrowning
<enebo>
lopex: nirvdrum: I remember for common encodings they are 100% loaded already but if it is all possible encodings then that sounds like a hit
<lopex>
yeah, I recall that from a video
<lopex>
nirvdrum: maybe forName / newIstance as well ?
<nirvdrum>
lopex: If it's statically reachable, Substrate VM can handle it.
<lopex>
enebo: commons ?
<enebo>
lopex: common: utf-8,us-ascii, ...
<lopex>
yeah
<lopex>
enebo: I guess those loaded already prohibit bimorphic inlining
norc has joined #jruby
<nirvdrum>
enebo: Yeah, like I said, I don't expect this to land again. Particularly since at least one of these encodings is > 1 MB itself.
<lopex>
nirvdrum: we could generate a switch in jcodings
<lopex>
nirvdrum: the generators are already there
<enebo>
lopex: yeah very likely never possible to not load at least those two
<enebo>
too many negatives in that sentence :)
<cremes>
headius: my ffi-io branch removed all of the locks that the original C code had, so right now that branch isn’t “thread safe.”
<cremes>
headius: I was asking about specs because i want to add some of those locks back but also make sure i conform with current thread safety expecations
<cremes>
that’s all.
<lopex>
nirvdrum: but delayed class loading isnt an issue for Substrate ?
<headius>
cremes: oh yikes
<nirvdrum>
lopex: Anyway, I used to just run through the encoding DB iterator and for each entry, do a loadEncoding and loadDummyEncoding and store the pair.
<nirvdrum>
I was trying to figure out what the equivalent of that is now.
<headius>
yeah, we tried to get around IO locking but could not find a way, especially with efficient buffering
<cremes>
headius: that’s why I asked you (and the jruby) project becuase you have real threads. thread safety tests in MRI or probably… less than perfect. :)
<nirvdrum>
lopex: No, it's not.
<headius>
there's quite a few if I remember right, including tests for interrupting a thread blocked on IO, etc
<headius>
I have not looked at your impl much...what mutable state is there on the new FFI-based IO?
<enebo>
cremes: lots of extra bahavior is tests in MRI tests than spec
<cremes>
this wekeend I’ll get the MRI tests going again against that branch
<enebo>
cremes: so not just thread safety test are worth examining
mkristian has quit [Quit: This computer has gone to sleep]
<cremes>
headius: most of the “mutable state” is just related to seek positioning and anything that might be buffered via “unget"
<enebo>
man my typing is crap this morning
<cremes>
enebo: thanks, i’ll keep my eyes peeled for new or additional behavior
<enebo>
nirvdrum: I am sending you secret IRC messages :P
<nirvdrum>
Oops. Window was too small :-P
<cremes>
i don’t want to get too distracted by new 2.3-isms though… so some new behavior may get ignored for now.
<enebo>
cremes: oh I just meant in general…not specifically new behavior
<headius>
cremes: yeah you'll need locking for those at least
<GitHub42>
jruby/master ada6543 Charles Oliver Nutter: Add an indy run for spec:compiler.
<lopex>
enebo: I always wondered about the reasons the typing depends on the day
<headius>
cremes: there aren't many new 2.3isms for IO
<enebo>
lopex: new day new fingers
<lopex>
enebo: and no beer
<enebo>
lopex: I type better after beer
<enebo>
lopex: but code worse
<lopex>
enebo: depends how many :)
<enebo>
lopex: actually I type worse too…I just care a little bit less
<cremes>
headius: good to know that 2.3 didn’t change IO much… I saw something about new “flags” which I’ll address as soon as I get Socket working. :)
<GitHub27>
jruby/jruby-1_7 eb3d106 Thomas E. Enebo: exclude non-passing test and reanebld testing argf since we can run without hanging now
<headius>
gah
<headius>
nirvdrum: I didn't realize you implement the jnr.posix interfaces in Truffle too
<headius>
so whenever we add to those interfaces we need to fix truffle
<headius>
seems less than ideal
<chrisseaton>
well that's the problem with interfaces prior to 8 - adding new methods is a breaking change
<chrisseaton>
a semver major
<headius>
indeed it is
<chrisseaton>
We have one base class that implements the interface I think, with unimplemented, so I know it may be a little annoying, but it is also literally a two-second fix
<chrisseaton>
Maybe we should add a PosixBase class to JNR?
<headius>
we don't intend for these interfaces to be implemented outside of jnr-posix though
<headius>
interface changes aren't a breaking change if nobody's supposed to implement the interface :-)
<headius>
adds anyway
<chrisseaton>
We could push some of this down into jnr-posix if you wanted
<headius>
what do you implement them for?
<headius>
pushing down would work too
<chrisseaton>
We implement some posix things in Java that you don't, and we implement them just correctly enough to work for us, so it's probably not suitable for general use
<GitHub57>
jruby/master dd78c17 Charles Oliver Nutter: Implement missing methods for Truffle impls of jnr-posix ifcs.
<headius>
ahh, right
<chrisseaton>
we allocate fake file handles and redirect to Java streams
<headius>
depending on how close you're able to get to posix behavior, those might be good candidates for pushing down into jnr-posix's java logic
<headius>
yours can't be worse than doing nothing
<chrisseaton>
if you're happy with it I'll do that
<chrisseaton>
I thought there might be some reason you stopped where you did
<chrisseaton>
for example read on fd 0 can easily be done by reading System.in - I didn't know if there was a reason why you didn't do that yet?
<nirvdrum>
I think the sockets stuff might be worth pushing upstream. But the last time we talked about it, no one knew where to put it.
<chrisseaton>
and clock_gettime
<nirvdrum>
I think they're technically POSIX now. But we have a separate project for unixsockets. Should it land in jnr-posix or jnr-unixsockets, with the latter being renamed to jnr-sockets? Should it be a new project?
<chrisseaton>
I don't think that's posix is it? But it lives in libc
<chrisseaton>
jnr-unixsockets is a whole thing built on top of sockets - it isn't just the interfaces
<chrisseaton>
headius: did you update jnr-posix by installing a local snapshot or something? I'm not seeing the new version locally, and it's not compiling because of that
pawnbox has quit [Ping timeout: 246 seconds]
tcrawley is now known as tcrawley-away
<chrisseaton>
headius: it looks like our jnr-posix hasn't been updated since mid-january, but you've removed methods for those interfaces
<headius>
removed?
<chrisseaton>
added I mean
<headius>
I thought I pushed jnr-posix to snapshot repo but will do that now for sure
<chrisseaton>
does maven not look for new snapshots?
<headius>
I think it only looks once per day or if you pass -U
<headius>
I redeployed just in case
<headius>
I fixed Truffle's impls enough to compile, and nothing used the new stuff obviously
<chrisseaton>
right - I guess I just need to -U
<chrisseaton>
funny that there's no way to know to do that though, unless you had mentioned it
<chrisseaton>
headius: I'm looking at the POSIX interface, thinking about how to restructure it. The alternative would be to subclass JavaPosix, but it's final, so we can't do that either.
<headius>
we could perhaps soften that
<chrisseaton>
I might just copy-paste the methods we use from POSIX into our own interface, and then either back with that a POSIX implementation jnr-posix provides, or our own if we want a different behavior
<headius>
or we could add a more generic delegating posix impl
<chrisseaton>
one example is getpid - we want to return 0 instead of running /usr/bin/id
<headius>
new AbstractDelegatingPosix(javaPosix) { // override whatever you want }
<chrisseaton>
I'll create my own interface - that will solve your immediate problem of having to add methods to our impl of POSIX so you won't have that problem again
<headius>
ok
<chrisseaton>
You should document the interface if people aren't allow the implement it though - otherwise we have no way to know