r0bby_ has quit [Read error: Connection reset by peer]
robbyoconnor has joined #jruby
pawnbox has quit [Remote host closed the connection]
tomjoro has quit [Remote host closed the connection]
robbyoconnor has quit [Ping timeout: 248 seconds]
tcrawley-away is now known as tcrawley
robbyoconnor has joined #jruby
nirvdrum has joined #jruby
robbyoconnor has quit [Ping timeout: 264 seconds]
pawnbox has joined #jruby
brightball has joined #jruby
mattwildig has joined #jruby
subbu has quit [Ping timeout: 244 seconds]
pitr-ch has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
pitr-ch has joined #jruby
subbu has joined #jruby
lanceball is now known as lance|afk
lance|afk is now known as lanceball
<kares_>
nirvdrum: hey! thanks for the feedback
<nirvdrum>
kares_: No problem.
<kares_>
sounds like using a ThreadLocal in the SecureRandom ruby impl would do?
<nirvdrum>
I think so. What's the problem with using ThreadContext?
<kares_>
... (or at least being lazy with Java SecureRandom creation on ThreadContext)
<nirvdrum>
Ahh. Yeah, I can't see why not.
<kares_>
good - seen it block a bit under some heavy thread creation
<kares_>
kind of wondered why is there SecureRandom to start with
<nirvdrum>
I think doing one per ThreadContext should be unnecessary to begin with. But, since we were moving from a completely new SecureRandom on every call to something based on a SHA1PRNG seeded from SecureRandom (/dev/random), I think headius wanted to keep ThreadContexts at least completely separate from each other.
<nirvdrum>
The reason for SecureRandom is a mix of confusion and conservatism.
<kares_>
yep - still if I recall right Java SecureRandoms internally still uses one seeder
<nirvdrum>
The Linux kernel docs clearly say to use /dev/random, not /dev/urandom, if you care about security. Many security professionals think that statement is incorrect.
<kares_>
oh, why's that?
<nirvdrum>
Which part?
<kares_>
not a security pro but why they feel /dev/random should not be favored over urandom?
<nirvdrum>
The former is blocking, the latter is not.
<nirvdrum>
IIRC, on *BSD, they're the same exact thing.
<nirvdrum>
On Linux, /dev/urandom is seeded from /dev/random.
<nirvdrum>
And then values are generated from that using something like SHA1PRNG.
<nirvdrum>
Which should make them just as random as you get reading from /dev/random.
<kares_>
ok - though your implying that urandom is more secure :)
<nirvdrum>
No. Just that by the time you can start Java, /dev/urandom is just as secure.
<nirvdrum>
This is becoming very problematic in the world of virtualization and containers.
<kares_>
yep
<nirvdrum>
Because /dev/random can DoS an app.
<nirvdrum>
Anyway, people keep pointing at the kernel headers. The JVM clearly still reads from /dev/random. And barring anything else, we want to be secure by default.
<nirvdrum>
And that's the "confusion" part I was talking about.
Aethenelle has joined #jruby
robbyoconnor has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
<GitHub3>
jruby/master 9a82781 Thomas E. Enebo: Reduce # of java runs to reduce time spent on appveyor
<GitHub73>
[jruby] enebo pushed 2 new commits to jruby-1_7: https://git.io/vaIzo
<GitHub73>
jruby/jruby-1_7 5cf7975 Thomas E. Enebo: Add appveyor hook for 1.7 branch
<GitHub73>
jruby/jruby-1_7 80daa93 Thomas E. Enebo: Reduce # of java runs to reduce time spent on appveyor
subbu has quit [Ping timeout: 252 seconds]
<GitHub111>
[jruby] enebo opened issue #3720: ScriptingContainer.getHomeDirectory() and getCurrentDirectory() return / paths and no \\ paths on Windows https://git.io/vaI2Y
mkristian has joined #jruby
davidpgero has quit [Ping timeout: 244 seconds]
subbu has joined #jruby
brightball has quit [Quit: Leaving...]
pawnbox has quit [Remote host closed the connection]
<GitHub29>
[jruby] enebo closed issue #3720: ScriptingContainer.getHomeDirectory() and getCurrentDirectory() return / paths and no \\ paths on Windows https://git.io/vaI2Y
skade has quit [Quit: Computer has gone to sleep.]
nirvdrum has quit [Ping timeout: 268 seconds]
subbu has quit [Ping timeout: 240 seconds]
subbu has joined #jruby
brightball has joined #jruby
rcvalle has joined #jruby
olle has quit [Remote host closed the connection]
subbu has quit [Ping timeout: 244 seconds]
subbu has joined #jruby
shellac has quit [Quit: Ex-Chat]
camlow32_ has joined #jruby
camlow32_ has quit [Read error: Connection reset by peer]
bbrowning is now known as bbrowning_away
camlow32_ has joined #jruby
camlow325 has quit [Ping timeout: 276 seconds]
brightball has quit [Quit: Leaving...]
subbu has quit [Ping timeout: 244 seconds]
skade has joined #jruby
subbu has joined #jruby
brightball has joined #jruby
<mkristian>
kares_, the jruby-openssl-0.9.16 release does break one jruby-1_7 test. going back to BC-1.50 will fix it again. the same test is broken for version 0.9.14 and 0.9.15 as well
<GitHub14>
jruby/jruby-1_7 bc7de11 Thomas E. Enebo: We need to use forward slashes in test if we are embedding that path into a ruby script on Windows
<enebo>
mkristian: I am setting up appveyor for windows CI and I was wondering how we can selectively run tests with maven
<enebo>
mkristian: right now it is just running -Ptest but I know we have something like COMMAND or some env which can run morew than our internal unit tests
<mkristian>
enebo, are you talking about core/src/test/java ?
<mkristian>
-Dtest=org.jruby.MyTest can pick a single test - need -Ptest as well with our setup
<enebo>
mkristian: I mean how do I get mvn to also do rake test:mri19
<enebo>
mkristian: as configured all unit tests are runnning but nothing past that
<enebo>
at least I think that
mattwildig has quit [Ping timeout: 260 seconds]
<mkristian>
on master -Ptest will run only the unit test under /core/src/test/java - the rake tests need -Prake -Dtask=test:mri19
<enebo>
aha
<enebo>
mkristian: can I also add a list of tasks for that?
mattwildig has quit [Remote host closed the connection]
Aethenelle has quit [Quit: Aethenelle]
<enebo>
mkristian: is it possible to not install jruby-launcher on windows?
<enebo>
mkristian: as in being a gem dep I think from pom.rb
<mkristian>
enebo, the launcher will be at most install one release versions but not on snapshot versions. let me see if there is something to avoid at all times
tenderlove has quit [Remote host closed the connection]
brightball has quit [Quit: Leaving...]
<enebo>
mkristian: my issue is that on windows it invokes make and aasume makes iwll exist and a compiler toolchain will be present
<mkristian>
enebo, so the launcher will only installed when using the -Pbootstrap profile. omiting this profile will not install the launcher
<mkristian>
the profile does only the launcher nothing else
nirvdrum has joined #jruby
<enebo>
mkristian: I am literally typing mvn -Ptest
<enebo>
mkristian: could that invoke bootstrap?
<enebo>
mkristian: This happens in the Integration Tests section
<mkristian>
enebo, hmm - I do believe you that something starts to install the launcher but without -Pbootstrap it should not happen. not sure why you see it.
<enebo>
mkristian: seems to be right after the epic app server mvn downloads
<mkristian>
ok this log could be helpful :)
<enebo>
mkristian: perhaps it only happens in new sandboxes so we never see this install phase
<enebo>
I am having one other head scratcher
<enebo>
If I run from within Idea the ScriptingContainer test user.dir is in /core/ but if I run from CLI it is jruby root dir. If I run from CLI on MacOS it is in /core/
<enebo>
so somehow windows is running it from a diffferent directory on windows
olle has joined #jruby
<mkristian>
enebo, you can use the system properties 'basedir' for such tests, which is always /core/ and set the user.dir as needed
<enebo>
mkristian: well it does
<enebo>
oh sorry no it doesn't
<enebo>
if calls it basedir :) but uses user.dir
mattwildig has joined #jruby
<enebo>
ao I will print out basedir and see if it is the same everywhere
<enebo>
ah unfortunately ScriptingContainer is based on user.dir implicitly
<enebo>
so I can make most of the test use basedir to know I am in core but the relative path tests I guess need to know what user.dir is to work
<enebo>
I am confused though why user.dir is changing on windows CLI to be different than on MacOs. something weird is happening
olle has quit [Ping timeout: 260 seconds]
camlow32_ has quit [Remote host closed the connection]
<headius>
yeah that will stop all jit..we usually use compiler modes
<dfr>
But seems like not really. I've ended up setting JitMax to 0
<headius>
if it doesn't, it should
<headius>
if you want to just run interpreted there's a cleaner way
<dfr>
oh, CompileMode will work.
<headius>
yeah that
<enebo>
should that be a live tunable?
<dfr>
headius, no, I want to turn it off mostly because it's causing JVM creashes
<headius>
oh! well that I want to see!
<headius>
if JIT is crashing JVM it could be bad bytecode not getting caught by verifier...a JVM bug
<dfr>
headius, actually I think what's going is that something gets Garbage collected incorrectly, then JVM tries to reference JIRTed symbols and blows up.
<headius>
that would be pretty weird
<headius>
you can reproduce this though eh?
<dfr>
headius, I've last detected it a few months ago, but have been so far working around it. Also, it seems to only happen with our own Mark/sweep GC, so yea
<dfr>
headius, with bunch of Google stuff, yes. Am trying to get a more sane repro case and give it to our java platform guys
<headius>
ok great
<dfr>
I'm still not sure whether the problem is with JRuby, Java or our garbage collector.
<headius>
well feel free to ping any time on that
<dfr>
headius, will do. Before I was turning off MethodFlushing, but that seems to be not reliable anymore. Turning off jit seems to work better :)
monkstone has joined #jruby
<headius>
so yeah, compile mode will be better because in JIT mode we never optimize interpreted code
<dfr>
once I can reproduce it with a java and a jar, I'll definitely ping. :)
<dfr>
sgtm
camlow325 has joined #jruby
<headius>
(enebo: we may want to improve that)
camlow325 has quit [Remote host closed the connection]
<dfr>
will try that, thanks :)
<headius>
interp mode will optimize interpreted code and run a bit better
camlow325 has joined #jruby
camlow325 has quit [Remote host closed the connection]
camlow325 has joined #jruby
camlow325 has quit [Read error: Connection reset by peer]
<enebo>
headius: which the tunable nature being live?
camlow325 has joined #jruby
camlow325 has quit [Read error: Connection reset by peer]
<headius>
enebo: I don't think we ever go to full interp in jit mode, right?
camlow325 has quit [Read error: Connection reset by peer]
<headius>
even if JIT fails, we'd be stuck in simple
camlow325 has joined #jruby
<headius>
perhaps jit failure should cascade into full interp build
<enebo>
headius: we don’t know
<enebo>
startup or JIT or bust
<enebo>
headius: it is a possibility but it is simpler for now
<enebo>
headius: this week has shown me that we need more cleanup in lifecycle before we can make that even more complicated
<enebo>
headius: but it is definitely possible
<headius>
sure
<enebo>
headius: although the other question is whether full is useful enough to matter
<headius>
as in, does it make enough difference in perf?
<enebo>
headius: yeah mostly that
<enebo>
headius: I mean if you know something does not JIT perf is already in the toilet
<enebo>
headius: so would being a little less in the toilet really give us any positive payback
<headius>
fair enough
<enebo>
headius: The next to revisit this past some cleanup is when profioled optimizations land
<enebo>
since profiled opts will force us to have potentially more than one fic
<enebo>
headius: in theory too the JIT fic shoudl execute in the full interp
pawnbox has quit [Remote host closed the connection]
<headius>
yeah so we have to prepare it anyway
<enebo>
headius: yeah we already made it at that point already
<headius>
really just needs to flip a bit so if JIT fails we continue from there with FIC
<enebo>
headius: I am not sure though how we hook that up
<enebo>
headius: I think right now mixed has a compiled object
<enebo>
headius: if it was a common type we could just replace it with a wrapper around fullinterp
<enebo>
but let’s just think about this one for now :)
<headius>
yeah I don't think it needs to care what type of DynamicMethod it delegates to after JIT
<enebo>
ah so dynamic method
<enebo>
hehe we could just set InterprtedIRMethod as JIT
<headius>
FIC looks around 15% faster on redblack
<enebo>
yeah Full can defintiely be faster
<enebo>
just not by a big emount
<enebo>
EMOUNT
<headius>
enebo: you made that interface for updating the source method...JITTask could just failover into full build task and be done
<headius>
unify all the mixed mode stuff in one place
<enebo>
yeah perhaps so
<enebo>
I think there might be some generics in the way?
<enebo>
I don’t remember how the generics played into that
camlow325 has quit [Read error: Connection reset by peer]
camlow325 has joined #jruby
olle has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
evenix has joined #jruby
<mkristian>
enebo, so I finally got at least the /test/ run with maven (core and lib both failed with me on windows8.1) but I do not see any jruby-launcher running -Ptest
<evenix>
kares mentioned a rake-cache file but I'm not sure what file he's talking about exactly.
<enebo>
mkristian: ok so I see it on both my local win7 box and on appveyor which I presume is probably a pretty different env
olle has quit [Ping timeout: 240 seconds]
<evenix>
Does he mean `rake cache:clear`
<enebo>
mkristian: and I made some headway on the ScriptingContainerTest 2 failures…there is special relative_path logic in the scripting container which is different on windows
<GitHub56>
[jruby] mohamedhafez opened issue #3721: Control-C doesn't do anything anymore when entering code in IRB https://git.io/vaLRV
<mkristian>
evenix, not sure, but kares_ meant some rack_cache files - but I dunno where they are stored on the filesystem
<evenix>
mkristian: ok. he wasn't specific. I'm guessing that he meant tmp/cache so `rails tmp:clear` would get rid of sprockets and cache files
<mkristian>
sounds about right
<mkristian>
enebo, mvn -Ptest -P-bootstrap does exclude the boostrap profile explicitly - maybe this helps
nirvdrum has quit [Ping timeout: 268 seconds]
<enebo>
mkristian: well I guess it depends on whether those gems are needed to run tests
<mkristian>
there is only the launcher gem and it is not needed, we usually never install it
<enebo>
mkristian: but you saw that rpsec and other gems were right above it
<enebo>
mkristian: I will try it though
<enebo>
heh so ENV[‘PWD’] is used in relative search logic in ScriptingContainer
<mkristian>
rspec gems are not part of the bootstrap profile. yes, the output looks exactly what I see when I use -Pbootstrap
<enebo>
I wish Java allows us to update those envs
<enebo>
mkristian: ok I am running it locally and so we shall see if we make it further
camlow32_ has joined #jruby
camlow325 has quit [Read error: Connection reset by peer]
<enebo>
mkristian: I ran mvn -Ptest -P-bootstrap and it still died trying to install jruby-launcher
<mkristian>
at least consistent :)
<enebo>
mkristian: this is also on jruby-1_7
<enebo>
mkristian: we are testing on same branch?
<mkristian>
no I am on master - sorry
<enebo>
mkristian: well hopefully that will be the difference then
<mkristian>
now it is clear as it is just part of the list of gems to be installed
<mkristian>
enebo, what shall we do with this ? remove it ? move into the bootstrap profile as on master ? not sure about the implication of any of this regarding rvm , etc
<enebo>
mkristian: I don’t know why this is even happening
<enebo>
mkristian: does rvm run -Ptest and integration tests?
<mkristian>
if might run -Pbootstrap which runs the /test/pom.xml - not test but installs the gems
<mkristian>
so moving it into the bootstrap profile should be ok
<enebo>
mkristian: I guess there are two questions 1) do we need some of these gems installed if they have not been for integration tests to run 2) wherever this kicks off these gem installs is it used by antything but these integration tests
<mkristian>
we do not need the ruby-launcher for the integration tests - one. I think the get started docu still says to run mvn -Pbootstrap to install gems for testing + ruby-launcher for faster startup of jruby
<enebo>
mkristian: but the documentation is helpful for CI how? I mean I am starting in a new directory evertime
<enebo>
mkristian: so does that mean I should have -Pbootstrap on every -Ptest on appveyor? And if so won’t it break since it will try and install jruby-launcher
<enebo>
mkristian: Also I think headius also was hoping we had some testing with jruby-lauincher installed so it got some use.
<mkristian>
no -Pbootstrap is for the use installing jruby from source tar or git repo. -Ptest does install everything needed for the tests
<enebo>
mkristian: ah ok
<mkristian>
on master -Ptest does not install jruby-launcher anymore . I see testing jruby-launcher as well. maybe we can come back to this later :)
<enebo>
mkristian: yeah I think we can revisit later. I find getting windows testing more important than coverage for this atm
<GitHub160>
[jruby] enebo pushed 1 new commit to jruby-1_7: https://git.io/vaLa3
<GitHub160>
jruby/jruby-1_7 ade7d56 Thomas E. Enebo: Some hinky env magic so these tests run on windows from CLI and from IDE. The logic on windows ends up being different from MacOS too...bleh
camlow325 has joined #jruby
skade has joined #jruby
camlow32_ has quit [Ping timeout: 244 seconds]
lance|afk is now known as lanceball
<GitHub90>
[jruby-openssl] ph opened issue #84: OpenSSL::X509::Store doesn't support an intermediate CA like in MRI. https://git.io/vaLVk
camlow325 has quit [Remote host closed the connection]
<enebo>
mkristian: you are removing the gem install right?
<mkristian>
yes, give me minute
<enebo>
mkristian: yeah np…I was just not 100% sure you were working on it or not :)
shellac has quit [Quit: Computer has gone to sleep.]
mattwildig has quit [Remote host closed the connection]
<GitHub59>
[jruby] mkristian pushed 1 new commit to jruby-1_7: https://git.io/vaL67
<GitHub59>
jruby/jruby-1_7 88cd8a5 Christian Meier: [build] do install jruby-launcher only on -Pbootstrap...
<mkristian>
enebo, here you are - could you give it a trial ?
<enebo>
sure
<enebo>
mkristian: fired off a run locally
<enebo>
mkristian: I run a bit faster than appveyor but that will also be running your change
<mkristian>
enebo, sorry not used to have a windows CI running my changes :)
<enebo>
mkristian: np. My results will be a lot faster than that
skade has quit [Quit: Computer has gone to sleep.]
<enebo>
mkristian: ran to completion…SUCCESS
<enebo>
mkristian: however it seems to have run no integration tests at all…which perhaps is correct
<enebo>
mkristian: I am much more interested in getting the mri tests loaded up now but I think you helped give us our first green appveyor run
<mkristian>
enebo, that was faster indeed. this runs only tests in /core/ and builds the test java classes used by various rake tasks
<mkristian>
will try to run it on my windows VM tomorrow - maybe it works better then on master :)
<enebo>
mkristian: It seeems to have run 0 tests
<enebo>
mkristian: 0 in integration tests that is…the unit tests in core do run before that
<mkristian>
you know on jruby-1_7 all those rake tasks are still using ant
<enebo>
weirdly your last commits has not even shown up on appveyor yet