<GitHub3>
jruby/truffle-head 6c0ee33 Chris Seaton: [Truffle] Properly handle interruptible process.waitFor() during Kernel#`
<GitHub3>
[jruby] chrisseaton pushed 1 new commit to truffle-head: https://git.io/vXYiE
tcrawley-away is now known as tcrawley
shellac has joined #jruby
tcrawley is now known as tcrawley-away
<GitHub171>
[jruby] andy-twosticks opened issue #4259: Identical Regexp are not equal to each other https://git.io/vXYXK
donValentin has quit [Quit: donValentin]
donV has joined #jruby
_whitelogger has joined #jruby
tcrawley-away is now known as tcrawley
drbobbeaty has joined #jruby
tcrawley is now known as tcrawley-away
donV has quit [Quit: donV]
tcrawley-away is now known as tcrawley
claudiuinberlin has quit [Remote host closed the connection]
claudiuinberlin has joined #jruby
claudiuinberlin has quit [Ping timeout: 260 seconds]
bbrowning_away has joined #jruby
bbrowning_away is now known as bbrowning
donV has joined #jruby
claudiuinberlin has joined #jruby
pawnbox has quit [Read error: Connection reset by peer]
pawnbox has joined #jruby
pawnbox_ has joined #jruby
pawnbox has quit [Read error: Connection reset by peer]
yahonda has joined #jruby
lance|afk is now known as lanceball
<GitHub145>
[jruby] nirvdrum force-pushed add-default-encodings-to-encoding-manager from bbfd8db to 5cb84b2: https://git.io/vXmH0
<GitHub145>
jruby/add-default-encodings-to-encoding-manager a9535a9 Kevin Menard: [Truffle] Keep track of default_external and default_internal encondings in EncodingManager....
<GitHub145>
jruby/add-default-encodings-to-encoding-manager 96e52df Kevin Menard: [Truffle] Switched to a jnr-posix-backed version of Encoding.locale_charmap.
<GitHub145>
jruby/add-default-encodings-to-encoding-manager 42be57c Kevin Menard: Fixed an issue with alias names being converted to constant names when they shouldn't be.
bbrowning has quit [Ping timeout: 260 seconds]
bbrowning has joined #jruby
<GitHub11>
[jruby] nirvdrum force-pushed add-default-encodings-to-encoding-manager from 5cb84b2 to 8f80540: https://git.io/vXmH0
<GitHub11>
jruby/add-default-encodings-to-encoding-manager f55227a Kevin Menard: [Truffle] Simplified setting default_external and default_internal encodings....
<GitHub11>
jruby/add-default-encodings-to-encoding-manager c358f16 Kevin Menard: [Truffle] Keep track of default_external and default_internal encondings in EncodingManager....
<GitHub11>
jruby/add-default-encodings-to-encoding-manager 3d876bf Kevin Menard: [Truffle] Switched to a jnr-posix-backed version of Encoding.locale_charmap.
bbrowning_ has joined #jruby
bbrowning has quit [Ping timeout: 248 seconds]
bbrowning_ is now known as bbrowning
djellemah_ has quit [Ping timeout: 250 seconds]
enebo has joined #jruby
<GitHub47>
[jruby] bjfish pushed 1 new commit to truffle-head: https://git.io/vXOtS
<GitHub47>
jruby/truffle-head e93d9c7 Brandon Fish: [Truffle] Add license header in RbConfig for RbConfig::expand method
<enebo>
olle: cool. detailed enough where they can even glance at the C commit
prasunanand has quit [Ping timeout: 260 seconds]
<olle>
enebo: I'm using Puma, so it was fun finding this .
<enebo>
olle: yeah it would be awesome if you were just finding random problems but it is much more satisfying if you know it will help you in the future
<enebo>
olle: for OSS I think it is much easier to stay engaged when it helps your non-OSS work
<olle>
enebo: Oh, indeed.
<enebo>
olle: they call me captain obvious
<olle>
enebo: On Hutch, I added an error handler and tracer for Opbeat, both projects I use at work,
<olle>
enebo: and I got lots of support from the Opbeat people while doing it. They were all high-fives and micro-edits.
<olle>
enebo: About that search on Github. Let's try!
<rafa11>
Hi, I have a problem installing a custom Gem in jruby on Windows. It is trying to create a folder with the name C:, is there some way to avoid or solve that?
bbrowning_away is now known as bbrowning
drbobbeaty has quit [Ping timeout: 252 seconds]
<nirvdrum>
headius: Kicking around?
donV has quit [Quit: donV]
subbu is now known as subbu|lunch
drbobbeaty has joined #jruby
rafa11 has quit [Ping timeout: 260 seconds]
claudiuinberlin has joined #jruby
prasunanand has quit [Ping timeout: 250 seconds]
bbrowning_ has joined #jruby
bbrowning has quit [Ping timeout: 248 seconds]
prasunanand has joined #jruby
bbrowning_ is now known as bbrowning
shellac has joined #jruby
claudiuinberlin has quit [Remote host closed the connection]
claudiuinberlin has joined #jruby
claudiuinberlin has quit [Remote host closed the connection]
shellac has quit [Quit: Computer has gone to sleep.]
claudiuinberlin has joined #jruby
subbu|lunch is now known as subbu
<headius>
I'm here
<headius>
didn't realize IRC was not up
<headius>
rafa11: what JRuby version? We have fixed some issues with Windows paths over the past year
pawnbox has quit [Remote host closed the connection]
mtoy has joined #jruby
nicoulaj has joined #jruby
<headius>
mtoy: yo
nicoulaj_ has joined #jruby
<mtoy>
headius: i'm hanging out in IRC if you want th throw me a patch or a branch for #$185
<mtoy>
#4185
nicoulaj has quit [Read error: Connection reset by peer]
nicoulaj_ has quit [Remote host closed the connection]
nicoulaj has joined #jruby
<headius>
yeah let me try this patch to restore nested jar caching quick
<headius>
I had either forgotten we removed that caching or I never knew
<headius>
if you have a lot of nested jar content this could easily be the problem
<headius>
enebo: this could be a problem for other setups that boot JRuby from a stack of nested jars
<mtoy>
i like it because it explains why a similarly sized app doesn't experience the slowdown
<headius>
the jar caching, when it was added, made a tremendous difference for some uses
<enebo>
headius: yeah for some reason this now makes me think it was removed but I do not remember if by mkristian or dfr
<headius>
I'm hoping that just copying 9.1.6.0 complete jar into jruby-jars gem will pick it up
<headius>
enebo: cprice/rubocop etc problems could be related too
<headius>
or whichever app that was
<enebo>
headius: maybe?
<headius>
well they're booting embedded JRubies from scratch repeatedly
<enebo>
jars do not change so I do not know why we would remove it…I guess memory concern?
<headius>
if this slows down boot of one runtime it would slow down all of them
<headius>
well I'm wondering if it had to do with flipping the lookup priority to top-first
<headius>
mkristian listed many reasons why we should have our classloader search self before parents, mostly relating to embedding and isolation
<headius>
very likely my blindly copying 1.7's classloader will break that, but it may give us a path forward
pawnbox has joined #jruby
<GitHub23>
[jruby] headius created fix_fat_jar_startup (+2 new commits): https://git.io/vX3kT
<GitHub23>
jruby/fix_fat_jar_startup 0dbe73c Charles Oliver Nutter: Restore 1.7's caching JRubyClassLoader for nested jars....
<GitHub23>
jruby/fix_fat_jar_startup 99dda63 Charles Oliver Nutter: Eagerly retrieve and cache JarEntry from all jars....
<headius>
mtoy: ^^ the two commits (JarEntry caching and nested jar caching) are on that branch
<headius>
I think you have a setup to build and swap in a new complete jar, yes?
<headius>
the commits are independent of each other...you may want to test the nested jar caching first
<headius>
assuming I swapped my complete jar propertly this did at least boot ok...but not any faster for your example
<mtoy>
headius: i can do that ... still new to the mechanisms, so give me a bit
<headius>
and the difference between your example loading from jar and loading from filesystem may be expected...I'd expect 1.7 to be faster from filesystem too
<headius>
mtoy: ok
pawnbox has quit [Ping timeout: 244 seconds]
<headius>
enebo: d02e9ed14c4552a1d7256933336591dbe841062c removed the caching
<headius>
claims mkristian: the jar protocol handler was unsupported by some envs
<headius>
seems like it would be better to just not cache on those envs
<enebo>
headius: yeah it is unclear to me from this
<enebo>
headius: assuming you can know based on how you prefix it then I agree
<headius>
right...I have no idea how "unsupported" manifests
<enebo>
headius: in any case adding zillions of seconds onto load is not good for us
<headius>
I wish the damn JVM would do this right
<headius>
it may be time to revisit that jboss project for nested jars
<headius>
that Aslak recommended
<enebo>
shrinkwrap?
<headius>
yeah I think that was it
<nirvdrum>
headius: Hey, there you are.
<headius>
ahh yes, part of Arquillian
<nirvdrum>
After your comment re: tagging on jnr-constants, I looked at jnr-posix and virtually none of the PRs there have been tagged with a milestone :-/
<headius>
yeah I'm not sure we've got that policy in place on all the jnr projects yet
<headius>
but I think we should
<nirvdrum>
Do you want to backfill? Or just adopt it moving forward?
<headius>
in the past I've created a milestone for "pre-1.2.3.4" and used that to backfill anything that was never marked
<nirvdrum>
Cool.
<nirvdrum>
CI is good again on jnr-posix, too.
<nirvdrum>
That /dev/zero thing was annoying.
<headius>
oh nice
<headius>
yeah :-\ I got tied up and didn't get back to finding a better test
<nirvdrum>
I pinged you on the commit. But /dev/zero evidently isn't seekable on Linux.
<headius>
enebo: shrinkwrap supports tar and tar.gz too...we could run from .gem files
<headius>
yeah I remember
camlow325 has quit [Quit: WeeChat 1.5]
<headius>
thanks for dealing with it
<nirvdrum>
No problem. Teamwork!
<headius>
Yeah! ^5
<enebo>
nirvdrum: I see you are touching some non-truffle encoding logic…does that fix something for us too?
<enebo>
nirvdrum: in your latest pr
<headius>
looked like it just moves some utility code to a utility class
<headius>
I didn't read the whole thing closely
<nirvdrum>
Sorta. I pinged you on that jnr-posix PR.
<enebo>
ok so it is related
<nirvdrum>
I was looking to move Encoding.locale_charmap out to a native call.
<nirvdrum>
That java.io.Console logic always looked funky to me.
<nirvdrum>
So I looked at what MRI is doing and landed on nl_langinfo.
<headius>
ah, nice
<enebo>
nirvdrum: so it should work on windows?
<nirvdrum>
No :-/
<nirvdrum>
And that's why I split out our own version.
<nirvdrum>
But I plan to revisit that.
<nirvdrum>
MRI calls something else instead.
<nirvdrum>
Which I'd be fine with doing, but nl_langinfo is one of those uber functions like fcntl.
<headius>
strange...maven refuses to find the shrinkwrap jar in maven
<nirvdrum>
The replacement code that MRI calls is a narrower Win32 function, I believe.
<headius>
oh, it's a pom dep
<nirvdrum>
The other clean-up was removing those visitors I introduced for setting up a couple years back. I realized they really didn't add anything over the jcodings iterators, so I pulled them out. A good chunk of that is making EncodingService look more like it did before I added that.
drbobbeaty has quit [Ping timeout: 250 seconds]
<nirvdrum>
I think basically this was me now having used jcodings for a couple years and understanding it better. Trying to clean up a bit.
<nirvdrum>
But, I'd like to push more the locale_charmap thing. My fear is with Java 9 you won't be able to use that reflection hack any longer.
drbobbeaty has joined #jruby
<mtoy>
headius: i cherry picked your two commits to my branch were i has previously disabled the lastModified checking on the Jar Index and the load time is now 24 seconds.
<headius>
mtoy: down from 60+?
<mtoy>
right
<nirvdrum>
headius, enebo: If you've looked at the PR, one question I had is whether wrapping IllegalArgumentException that way is sensible. I don't think you were using the actual stacktrace anyway. But they way I'm wrapping at the moment, you'd lose some of the stack.
<headius>
mtoy: I guess we have a good lead then :-)
<mtoy>
and that is within the margin of error for me, if we could get something around that performance
<headius>
mtoy: ok, this is good news
<headius>
you said 1.7 is 15s?
<mtoy>
as i recall ... i could re-run to get more exact numbers ... there have been so many experiments
<headius>
that would be great, but I'm glad we're at least in the neighborhood
<headius>
mtoy: might be interesting to try both with -XX:TieredStopAtLevel=1 also
<headius>
that disables from JVM optimizations but starts up fast...not something you'd use in a production setting where perf is important, but it would be interesting to see how it changes
<headius>
that's a JVM flag
<enebo>
headius: jar is always in memory?
<mtoy>
yeah, i think those numbers already exist
<headius>
enebo: JRubyClassLoader dumps jar to disk and then tries to use it from there
<enebo>
headius: I just wonder about buffering in passing
<headius>
but that is apparently still slower than pre-caching jar contents
<mtoy>
headius: i was scattershot all over that issue, but in the middle there is a comment on messing with the -dev related flags ... of the original 110 second startup those saved 10 seconds
<mtoy>
headius: these timings are from the time the first "require" happens to the time the last one returns, so JVM startup itself is not a factor
<headius>
mtoy: ahh ok
<headius>
can you try the new jar with that flag?
<mtoy>
yup .... just a sec
<headius>
the constant jar indexing may have clouded the gains
<headius>
and yes, jvm startup itself should be negligible
<mtoy>
headius: -XX:+TieredCompilation -XX:TieredStopAtLevel=1 doesn't seem to affect it that much ... maybe 1 second ?
<headius>
ok
rcvalle has quit [Quit: rcvalle]
<headius>
mtoy: can you update the issue with your new numbers? I'll follow up with additional details
<mtoy>
headius: will do, thanks so much
<headius>
the modified jruby is doing pretty good in CI so we'll have to debate this change with mkristian and others