shellac has quit [Remote host closed the connection]
shellac has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
shellac has joined #jruby
nirvdrum has joined #jruby
lucasb has joined #jruby
shellac has quit [Remote host closed the connection]
rusk has quit [Remote host closed the connection]
nirvdrum has quit [Ping timeout: 265 seconds]
<headius[m]>
no
<headius[m]>
hmm I guess that weird path juggling in JarResource is at least being tested, but I'm not sure it should still be there
subbu is now known as subbu|afk
harpritsinghkohl has joined #jruby
<harpritsinghkohl>
Hi
<headius[m]>
hi there!
<harpritsinghkohl>
I have 2 web applications up and running. One is ROR and other is Java. Want to have single login and one menu. So, what I understand is first I have to convert ROR code to JRUBY and then merge JRUBY code inside java project. Thus, Java code will not change... Only JRUBY will be added to this Java application. So then I can compile this code together. Am I write?
Nathan2276 has joined #jruby
<harpritsinghkohl>
Or let me know what is the correct
<Nathan2276>
Hey all, sorry for the ignorance but I'm very new to Jruby. I'm trying to build the Ruby gem concurrent-ruby with `gem build concurrent-ruby`, but it complains about a missing jar file `concurrent-ruby.jar`. So that has to be generated somehow
<Nathan2276>
Does that mean I need Java or JRuby as a runtime dependency?
<headius[m]>
harpritsinghkohli: that's certainly one way to do it
<headius[m]>
Nathan2276: that should be what gets built by the concurrent-ruby build process
<headius[m]>
I'm not sure the BUILDING instructions are complete
<Nathan2276>
Yeah I get that feeling too
<Nathan2276>
ERROR: While executing gem ... (Gem::InvalidSpecificationException) ["lib/concurrent/concurrent_ruby.jar"] are not files
<headius[m]>
harpritsinghkohli: The most straightforward way would probably be to package the ROR app as a Java web application using Warbler, which is a tool for making JRuby webapps
<headius[m]>
Nathan2276: sounds like you have a working JRuby at least?
<Nathan2276>
From what I understand, it only builds the Jar if it's a Java platform. But that the Jar is listed on the Gem spec? If I just add that jar in manually without a JRE you think that's fine?
<headius[m]>
if the jar isn't building then we need to figure that out first
<Nathan2276>
Ahah..... I think I was talking to you yesterday about my struggles with rvm and JRuby. But ideally I would prefer to not rely on JRuby if possible
<headius[m]>
I have not built this library in a while, let me try it
<Nathan2276>
Thank you
<harpritsinghkohl>
<headius[m] "harpritsinghkohli: The most stra"> Ok thanks! Just one more question. Does JRUBY support all ROR Libraries.
<headius[m]>
Anything that is pure Ruby should work fine. If you have libaries that use a C extension there may or may not be a JRuby version available
<headius[m]>
your first step would be to try to get the ROR app to run on JRuby like you run it on CRuby, using the Puma server
<harpritsinghkohl>
Ok
<harpritsinghkohl>
My programmer encountered following issue in picture
subbu|afk is now known as subbu
<headius[m]>
Nathan2276: are you using JRuby or just trying to get the gem to build for CRuby purposes?
<headius[m]>
so there's at least two missing steps in the build instructions: you need to `bundle install` on CRuby to get appropriate dependencies, and then you also need a JRUBY_HOME env var pointing at a JRuby install
<headius[m]>
I don't think that should be strictly necessary though
<Nathan2276>
The reason I'm hesitant to rely on JRuby is there is CRuby integration into our build tool, but not JRuby
<headius[m]>
right
<headius[m]>
I think we should move this discussion back to concurrent-ruby gitter
<headius[m]>
there's nothing wrong with JRuby here but the build of the gem requires JRuby even to build the CRuby gem
<Nathan2276>
Very strange. For now I'm going to patch the gemspec and remove the line that checks for the jar
<Nathan2276>
I did post on the gitter but got no response, it seems inactive
<headius[m]>
yeah I'm one of the few folks who pays attention but have been busy with other stuff this week
<headius[m]>
harpritsinghkohli: I can't read that
<headius[m]>
can you get a text copy of the output somehow?
<enebo[m]>
I had that happen recently after I did a rvm get head
<headius[m]>
I did do that yesterday trying to help Nathan2276
<headius[m]>
ugh I hate software
<enebo[m]>
yeah I did not notice for a while either
<headius[m]>
rerunning
<headius[m]>
yeah it's fine
<enebo[m]>
well that is good
<headius[m]>
enebo: so an interesting patch I had to revert: ccec2e1f5d63ae4123c869856117425770850eb7
<headius[m]>
might need to fetch origin because it's on the graalvm branch
<headius[m]>
we are doing this extra logic to deal with leading / characters in jar resources
<headius[m]>
/ is not supposed to be there for jar! style URI and so I tried to delete this to just remove the characters
<headius[m]>
but some tests broke and I'm wondering if they are basically testing whether we fix bad URIs
<headius[m]>
I'm not going to look into it further today... I just reverted the change so my brnch would be green again. But I wanted to tell someone about it
<enebo[m]>
yeah that is interesting and I can believe we "fix" stuff we should probably error on
<enebo[m]>
In places where we know we are fixing bad things we could always remove via default option
<headius[m]>
it's possible my patch was wrong too but the comment there is right, I don't feel we should be trying twice
<headius[m]>
and never with a leading slash because it just won't work
<enebo[m]>
so if we release and it bites someone they can enable the option but by doing that they realize it will go away at a future point
<enebo[m]>
I am not a fan of options but I am less a fan of reports 1-2 days later that we broke something which people have been using for 10 years
<enebo[m]>
Not really sure what is the best strategy for this...which no doubt is an age-old question in software management
<headius[m]>
yeah this isn't anything that's a priority but maybe it's worth filing a bug to circle back and make this logic do the right thing
<headius[m]>
so far no new 9.2.10 issues it looks like
<headius[m]>
well other than that potential perf thing
<headius[m]>
enebo: so another consideration for 9.2.11: bundler is supposed to come along with RG 3.x, and 3.0.7+8 fix an issue that prevented users upgrading it
<headius[m]>
but if that's fixed we'd be more in line with RG 3.x to include bundler this time
<headius[m]>
we removed it before because of this bug
<enebo[m]>
At this point if we do 3.0.8 people can update on their own but if we update will we end up with a 9.0.12.0
<enebo[m]>
I feel like we want something stable but I have no feel or really much confidence in bundler itself
<headius[m]>
yeah I have concerns too
<enebo[m]>
not at the level of including a new version a couple of daysb efore we release again
<enebo[m]>
if we do not release it things will work with older version and people can opt to update because it will work with 3.0.8 and if we find an issue then people can still just use it as-is. If we ship it then we will have to probably immediately turn around on it
<headius[m]>
so you're thinking not update RG at all for .11
<headius[m]>
yeah the update of RG installs bundler into stdlib
<enebo[m]>
ah
<enebo[m]>
yeah I am a bit leery since we have not used it and with no testing we will push out a release
<enebo[m]>
I mean we will definitely try it and basically we will now it works to some degree
<enebo[m]>
but I would not have much confidence
<enebo[m]>
9.3 in theory is what a month out. I feel like we can update immediately on master and it is a big release
victori has quit [Ping timeout: 268 seconds]
ur5us has joined #jruby
subbu is now known as subbu|lunch
<rwilliams[m]>
headius: If I was to delve a bit into data science would jruby be good fit as I could leverage java for the processing intesive bits while sticking to ruby for the core of the app? Or should i just seperate the concerns.
<rwilliams[m]>
Also is it benficial form me to ping you guys or should i just ask questions?
<headius[m]>
enebo: big step for 9.3 is to wrap up the 2.6 branch and get that merged
<headius[m]>
that will include RG + Bundler because officially 2.6 was the first to include bundler
<headius[m]>
there's lots of failures but it's N * number of missing 2.6 features where N is pretty high
<headius[m]>
like 100 failures for one missing thing
<headius[m]>
yesterday I updated 2.6 branch to latest stdlib and yanked out the libraries that are gems now
<headius[m]>
rwilliams: seems like a fine idea to me
<headius[m]>
you can certainly separate them and make the Java side into a service, but it's sure nice to just call it directly
<headius[m]>
enebo: if you want some fun low-hanging fruit just look at 2.6 specs
<enebo[m]>
still trying to fix stuff on master but I will get there
subbu|lunch is now known as subbu
sagax has quit [Ping timeout: 272 seconds]
Nathan2276 has quit [Remote host closed the connection]
nirvdrum has quit [Ping timeout: 258 seconds]
nirvdrum has joined #jruby
lucasb has quit [Quit: Connection closed for inactivity]