10:39 <travis-ci> jruby/jruby-openssl (master:d15da1c by Karol Bucek): The build has errored. (https://travis-ci.org/jruby/jruby-openssl/builds/737026082)

10:42 <kares[m]> Hey 0xd I used to do that, until I went with a full-time job. I'll be interested knowing who's up for it ...

10:42 <kares[m]> In general it's not a one time show as some expect (except for some low hanging fruits) - you will need to learn and experiment with settings such as GC a bit, ideally if you have some kind of monitoring set up for the JVM applications.

12:30 <GGibson[m]> Anyone know if there is a jruby gem/way to call a Kernel32.dll function on Winderz?

12:33 <chrisseaton[m]> Can you use Fiddle or FFI to do it?

12:33 <GGibson[m]> I don't know those

12:33 <GGibson[m]> I was wondering if there was a gem to make those calls

12:33 <chrisseaton[m]> https://github.com/ffi/ffi https://ruby-doc.org/stdlib-2.5.3/libdoc/fiddle/rdoc/Fiddle.html

12:34 <chrisseaton[m]> These are those gems (well Fiddle is builtin, and I think JRuby ships FFI as well)

12:34 <GGibson[m]> I see - so I have to delve into the dark arts of lib interfacing?

12:34 <chrisseaton[m]> Are you already doing that if you're calling functions in `Kernel32.dll`?

12:35 <GGibson[m]> no, I'm just researching such a move

12:35 <GGibson[m]> I've not done FFI before -- noob

12:35 <chrisseaton[m]> Well it's not much more than a one-liner to call a simple function.

12:36 <GGibson[m]> cool

14:54 <M0xd[m]> kares: Yes, we are aware of the challenge, that's why we want to get training for all the engineers and let them do the tunning. Let me know if you happen to know any company or contractor specialized in this area. I would be pretty happy to get someone involved in JRuby if possible.

16:01 <GGibson[m]> Question : Does anyone know how many bytes of memory are used for each object reference in jruby? (in C Ruby it is 40 bytes on 64-bit machines).

17:03 <chrisseaton[m]> Each reference? Usually 4 bytes, sometimes 8 bytes.

18:14 <GGibson[m]> Anyone know what I'm doing wrong here: "5004000990000.0001".to_f => 5004000990000.0 (should be: 5004000990000.0001)

18:17 <havenwood> GGibson[m]: That's just Floats, whatever the Ruby.

18:18 <havenwood> GGibson[m]: require 'bigdecimal'; require 'bigdecimal/util'; "5004000990000.0001".to_d

18:18 <GGibson[m]> I forgot but isn't there a way to set float precision?

18:18 <havenwood> 0.50040009900000001e13.to_digits #=> "5004000990000.0001"

18:19 <havenwood> GGibson[m]: BigDecimal is arbitrary precision, but no way to change Float precision afaik.

18:58 <headius[m]> Correct

18:58 <headius[m]> There's some minor differentness with CRuby also

19:00 <chrisseaton[m]> I'd like to work out and write down exactly what those differences are -not sure I've ever seen a blog post about it. I think it's taken from the mantissa.

19:01 <headius[m]> <GGibson[m] "I've not done FFI before -- noob"> There are examples in the stdlib win32.rb code also

19:01 <GGibson[m]> thanks

19:05 <GGibson[m]> odd. in C Ruby I could freely use 0.0001 and not lose the digits. JRuby chops them off

19:05 <GGibson[m]> funky

19:05 <headius[m]> That's worth reporting as an issue

19:05 <headius[m]> It may be a rounding difference

19:06 <havenwood> GGibson[m]: I can't reproduce CRuby not chopping them off.

19:06 <havenwood> "5004000990000.0001".to_f #=> 5004000990000.0

19:07 <GGibson[m]> odd

19:07 <havenwood> GGibson[m]: 64-bit system?

19:07 <headius[m]> They have changed rounding modes over time and we try to keep up

19:07 <GGibson[m]> Well, it is pretty clear that if I'm going to get fully portable numbers - I better use BigDecimal

19:07 <headius[m]> That could be a factor

19:07 <headius[m]> Yeah that much is certain

20:27 <travis-ci> jruby/jruby (no_sourceposition:a8f8b72 by Thomas E. Enebo): The build was broken. https://travis-ci.org/jruby/jruby/builds/737193924 [208 min 29 sec]

20:49 <byteit101[m]> Interesting: (1..10).to_enum(:map){1}.size is ~20x slower than MRI

20:49 <chrisseaton[m]> In a bips benchmark?

20:50 <chrisseaton[m]> Seems like that should possibly constant fold if it all goes well!

20:50 <byteit101[m]> no, one off

20:51 <chrisseaton[m]> You aren't going to see JRuby's potential with one-off code.

20:52 <byteit101[m]> Very true! trying to write a test for a library to ensure that .size is cached for a custom enumerator, and my first though was just to time it and ensure an order of magnitude difference in results.

20:54 <chrisseaton[m]> JRuby is a dynamically optimising system built on top of another dynamically optimising system - it just isn't reasonable to measure as you're doing.

20:55 <byteit101[m]> Indeed!

21:11 <headius[m]> The block there probably doesn't inline currently because the enum code is pretty generalized

21:12 <headius[m]> Enums are so heavy and so commonly used with fibers that has not been a priority to optimize

21:22 <byteit101[m]> headius: Oh, whenever you get a chance, I'd like your thoughts on the java ctor stuff, what should/shouldn't be in scope, etc