04:11 <meals> Hi. Is there an option, property, environment variable, etc. that I can set so that jruby on Windows launches with javaw.exe instead of java.exe?

05:22 <nirvdrum> meals: The channel is more active during US business hours, I'm afraid. I'd hang out here if you can. You might get your question answered tomorrow.

07:16 <avinash_prat> Hi, everyone

07:19 <avinash_prat> we're using Jruby for rails, and we are using warble to deploy war in tomcat,

07:19 <avinash_prat> predicate(value &block)

07:19 <avinash_prat> we have a code which is not workig correctly after compilation

07:19 <avinash_prat> when we are colling this method as

07:19 <avinash_prat> predicate(:is_ref?) do |value, option|

07:19 <avinash_prat> #doing something

07:19 <avinash_prat> end

07:19 <avinash_prat> we're getting error only 1 argument is passed instead of 2

10:53 <headius> good morning

10:54 <headius> cremes: we do track what thread they're associated with but it's not exposed normally through any standard API

10:55 <headius> The Thread.current issue is a side effect of using some Ruby constructs for synchronizing fiber threads...it's actually using a normalish ruby Queue, which uses normal Thread synchronization primitives

11:00 <headius> that could be improved but not in a minor

11:01 <headius> cremes: I'd like to see your use cases in depth...they might advise a better Fiber impl for us. The current one has been the best because it still participates in the usual thread sync logic, but that has the ugly Thread.current side effect

11:01 <headius> our fibers are really not fibers as much as they are synchronous actors

11:08 <headius> chrisseaton: hey, do you know of a simple way to get graal running on Mac JDK9?

11:09 <headius> it's only included in JDK9 on Linux because that's the only platform jaotc works on right now

11:09 <chrisseaton> Build it yourself

11:10 <headius> chrisseaton: I guessed that might be the answer

11:10 <headius> still would be really nice if there were official graal builds somewhere

11:10 <chrisseaton> I think there’s an issue to include it in OpenJDK on all platforms

11:11 <chrisseaton> The official Graal build is GraalVM right now

11:11 <headius> yeah but that's still 8

11:11 <headius> I need 9

11:12 <headius> I'm trying to see if Graal does a better job optimizing non-static method handles than Hotspot

11:13 <headius> Hotspot doesn't run them much faster than reflected method unless they're static final

11:13 <headius> if they're static final it's like a direct call

11:30 <headius> nirvdrum: finally got back to Gilles

11:31 <headius> if the main problem is that JVMCI is a moving target, that absolutely needs to be fixed

11:31 <headius> but I'd be surprised if minor JDK9 updates are making breaking changes to JVMCI

12:18 <GitHub172> [jruby] mkristian pushed 2 new commits to jruby-9.1: https://git.io/vNNmK

12:19 <GitHub172> jruby/jruby-9.1 34e6c11 Christian Meier: upgrade jruby-readline version

12:19 <GitHub172> jruby/jruby-9.1 e7f0954 Christian Meier: upgrade jar-dependencies version

12:19 <headius> neato

12:27 <cremes> headius: I’m preparing for a alpha gem release of my ruby-io lib. I’ll include examples and some benchmarks in it. We can discuss the implementation in depth then.

12:27 <cremes> as of now, code is still very alpha… really a lot of “stream of consciousness” to get things working, test out api ideas, etc.

12:28 <cremes> but it’s working nicely and shaping up well. at some point i’ll wrap it all up in specs so the method semantics are well defined

12:28 <cremes> i’ll post a note here when things are closer to release

12:41 <headius> sounds good...if numbers aren't looking good in JRuby give me a ping first; there's probably simple things we can tweak

12:58 <nirvdrum> headius: Heh.

12:58 <nirvdrum> headius: Hopefully you guys can work something out.

12:58 <headius> hopefully

13:47 <chrisseaton> headius: why can't these method handle call sites use an inline cache as they would with any other dynamic receiver?

13:49 <headius> chrisseaton: good question

13:50 <headius> signature-polymorphic calls should optimize like indy + call site

13:50 <headius> should but don't

13:57 <chrisseaton> Maybe there just isn't a convenient place to store a cache in whatever implementation they use

13:57 <chrisseaton> If there isn't storage, it can be very hard to create some

14:04 <headius> it's really unfortunate that there's still no way to emit an invokedynamic with Java code, other than for booting lambdas

14:04 <headius> I think Remi Forax and others are trying to make that happen for 10 or 11 though

14:27 <meals> Hi. Is there an option, property, environment variable, etc. that I can set so that jruby on Windows launches with javaw.exe instead of java.exe?

14:29 <headius> meals: JAVACMD I believe will set the command used in most of our launchers...hopefully the native one as well

14:32 <meals> Thanks headius! That worked (set JAVACMD=javaw.exe).

14:32 <headius> excellent! I wonder where we could put that tip in the wiki

14:32 <headius> maybe just in the faq

14:33 <meals> My vote would be for the faq

14:37 <headius> meals: scroll up a bit from https://github.com/jruby/jruby/wiki/FAQs#general and let me know if it looks ok

14:37 <headius> I wish github had proper TOC support

14:39 <meals> looks good to me, thanks again.

14:39 <headius> thanks for stopping by :-)

14:56 <GitHub198> [jruby] areman opened pull request #5027: Andre Kullmann make the profiling service configurable via java prope… (master...master) https://git.io/vNN0g

17:22 <bga57> Why does the Jruby-launcher makefile use a hardcoded g++ instead of $(CXX) even though it uses $(CXXFLAGS)?

17:24 <bga57> Is there really a dependency on the gnu compiler? It appears to work fine with the native c++ compiler on FreeBSD.

20:59 <enebo> bga57: yeah I have no idea. That code came originally from netbeans launcher and I am not sure how much of that is from us or just what we pinched

22:05 <bga57> enebo: In order for me to build it on FreeBSD, I needed to a symlink for g++ to my c++ compiler added to my path. I can open an issue, but I don't know what environments you use to test it.

22:06 <enebo> bga57: that change seems like a no-brainer. I find it hard to believe we are forcing gcc for any reason (unless it is windows for some reason)

22:10 <lopex> enebo: look how fancy is this on another note https://github.com/Intoli/exodus

22:12 <lopex> enebo: btw how far ahead is next release?, I wanted to enable 7bit matching at some point

22:17 <bga57> My ubuntu laptop uses gcc underneath, but has cc and c++ in /usr/bin. I don't remember is this is default or because I installed a package.

22:32 <cremes> headius: I devised a work-around for the Thread.current bug in Fibers. I need to enforce no more than one FiberScheduler (my class) per parent thread, I detect when the scheduler is no longer accessible via thread-local variables and re-add the known, proper FiberScheduler to the new thread-backed Fiber. Works fine.

22:33 <cremes> I still need to sift through the jruby issues and make sure there’s an open one for this bug… I’ll add to it anything relevant.

22:33 <cremes> true multi-threading perf is a wonder… so glad I got this working on jruby