<headius>
RC probably at xmas when MRI 2.2 is released
noop has joined #jruby
<headius>
janitrix: can you file an actual issue too, please?
<headius>
we have others that can help who probably aren't monitoring IRC
<janitrix>
headius: sure
<janitrix>
headius: I will try the latest JRuby as well
<nirvdrum>
headius: Ahh. Because I still want to lobby for the suffix changes in LoadService :-)
<headius>
nirvdrum: well let's settle that with enebo right now
<headius>
I have also thought about writing AOT compiled code to something other than .class, since .class seems to make people think you can use them from Java
<headius>
silly people
<enebo>
nirvdrum: headius: I like the idea of jrubyc to make .rb file which uses method to load .class
<enebo>
Then it will stop searching for .class but no ones existing code will break if they just recompile
skade has joined #jruby
<enebo>
and for AOT they will definitely need to recompile in 9k since internally it will change
<headius>
for sure they need to recompile
<headius>
I don't like having jrubyc modify the source though
<enebo>
so generating .class + .rb stub file
<enebo>
headius: it will not modify source but I guess it means it cannot put output files in same dir as input which is a wrinkle
<headius>
yeah, trying to think of other ideas
<nirvdrum>
headius: Unless I'm crazy, you could write it out as .class.rb and it'd be picked up fine.
<nirvdrum>
Or if it's a .class file on the classpath, that should work too, I think.
<headius>
nirvdrum: we'd need logic to know .class.rb loads as bytecode, but I was just thinking about that too
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] gmalkas opened issue #2232: Uncaught Ruby Exception on JRuby 1.7.16 http://git.io/-b_rEA
JRubyGithub has left #jruby [#jruby]
<headius>
if we did something more python-like perhaps we could just look alongside each file for a compiled version?
<enebo>
so classpath load is a single check that happens before ordinary requires?
<headius>
that would be an additional stat for every found file
<headius>
but only for found files then
<headius>
like, we find foo.rb, we check first for foo.class.rb
<headius>
but we'd still need to find foo.rb first
<headius>
so it would have to get nulled out if you wanted AOT for obfuscation sorts of purposes
<nirvdrum>
Just to recap, my two biggest issues are: 1) the default set of suffixes is large and unnecessary in the common "I just want to run Ruby" case, causing a large number of unnecessary FS accesses; 2) partially as a result of #1, but fixable by caching, requiring a file is generally O(n).
<enebo>
yeah so n-1 stats in search but +1 stat on every found file
<headius>
enebo: right
mbj has left #jruby [#jruby]
paulswilliamsesq has quit [Ping timeout: 244 seconds]
mbj has joined #jruby
<enebo>
nirvdrum: It will still be O(n) :trollface:
<headius>
hah
<enebo>
I still question whether people should be compiling into the same dir as their source but I guess it depends on the usecase
<headius>
so here's a different though
<enebo>
If they are doing it as very poor man’s obfusc. which most are then they should be AOT’nig to a different dir
<headius>
the usecase most people are using is warbler, which precompiles your app before packaging
<headius>
but I don't remember what it does with .rb...it might replace with stubs
<nirvdrum>
Granted I don't use AOTC, but I still think requiring a flag for its use is in the realm of being reasonable.
<enebo>
but for obfuscation?
kares has quit [Ping timeout: 258 seconds]
<nirvdrum>
And just skip all that stuff in the non-AOT case.
<nirvdrum>
I still need to figure out what .jar.rb was from donV.
<headius>
if we add a flag for current behavior and check for alongside .class, that might be an acceptable transition away from always looking for .class
<headius>
or just move to the flag and change nothing else
<nirvdrum>
If the .class is on the classpath, I think it'll be found anyway. I'd need to trace each of those phases to be sure.
<enebo>
yeah so explicit source change requirement for users would not work if AOT files depend on requiring AOT files
<headius>
nirvdrum: it doesn't quite work that way because the package in AOT .class did not match any dir structure
<headius>
they had to be loaded specially
<nirvdrum>
Ahh.
<nirvdrum>
Well, fix that :-)
<headius>
it's not really possible to pick a package for them at AOT since load path can find them from anywhere
<nirvdrum>
Gotcha.
<enebo>
default package!
<headius>
I say we just add the flag for now and think more about how to reenable AOT in a logical way
<nirvdrum>
And as a tertiary step, it'd be nice to get rid of that service loader.
<headius>
the old way was a big of a hack anyway
<headius>
bit
<nirvdrum>
Since as best as I can tell, that's just a CNFE factory.
<headius>
the service loader can't go away without breaking existing exts, but perhaps we could add the requirement that the .class has to be a resource
<nirvdrum>
I think it's used for one or two internal JRuby services and the rest of the time it's just overhead.
<headius>
then it's just an existance check
<headius>
there are some third-party gems that still use it
<headius>
because we haven't come up with a better alternative that's automatic
<nirvdrum>
Ahh. What was it for?
<headius>
it was to make those .jar act like .so and be directly requirable
havenwood has quit [Remote host closed the connection]
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<headius>
in retrospect I should have put somethin in the Manifest
<headius>
my bad
<nirvdrum>
But there's already a .jar lookup for require.
<headius>
right, it does double duty
<nirvdrum>
This seems to looking for a class with base name + Service
<headius>
originally it was just for magic ext load, but because it has to put the jar in classpath to load the service, it also acted like adding jar to classpath
<headius>
the latter behavior became widely used while the former is only known by a handful of people
<nirvdrum>
Okay.
<nirvdrum>
Well, it might be worth just documenting when, if ever, that can be excised.
<headius>
I propose this...
<nirvdrum>
There were already ext. breaking changes. Some were put back in.
<headius>
1. add flag for .class search and default it to off (don't include .class in search)
<headius>
2. modify service lookup to try to find a .class resource rather than loading class and failing
<headius>
and probably add a warning that this mechanism is deprecated
<headius>
and implement a better mechanism like Manifest entry :-)
<enebo>
#2 with warning seems ok to me
paulswilliamsesq has joined #jruby
<enebo>
#1 is probably also ok but I want to discuss this one more
mister_solo has joined #jruby
e_dub has quit [Quit: ZZZzzz…]
<enebo>
#1 can be a punt for now I guess but I feel like we can solve this one if we make AOT authors change their pattern of packaging
<nirvdrum>
I have no idea how popular AOT is. Is there a large group of users out there?
<headius>
we don't have a good pattern to follow
<headius>
nirvdrum: there are commercial packages that do it
<headius>
I don't think there's many
<enebo>
If we make a) require_class ‘foo’ b) make wrapper foo.rb: require_class ‘foo’ c) require AOT to compile to a different dir than source
<headius>
we generally discourage it because it takes a lot longer to boot
<nirvdrum>
And this stuff done with jrubyc, right? Not the force JIT?
pchalupa has quit [Quit: Leaving]
<headius>
nirvdrum: that's right
<enebo>
I would argue this change is acceptable because AOT is not done for performance reasons and people do not actually want their original source distributed
<headius>
you have to actively jrubyc to get AOT output
<enebo>
It also follows the same pattern/conventions of Java for compilation
<nirvdrum>
Generally, I'm not a fan of breaking things on people. But 9k represents an opportunity for a bit of breakage because the language level is already going to cause issues.
<nirvdrum>
At least, IMHO.
<headius>
nirvdrum: indeed, and we better make those choices now :-)
<headius>
enebo: I dunno...it bugs me
<enebo>
why is that?
<headius>
it's like javac rewriting your java sources
<enebo>
why?
<enebo>
WHY?
<enebo>
:)
<headius>
well who makes the wrapper?
<enebo>
jrubyc
<enebo>
It makes .class and .rb stub into different dir
<headius>
so you have to output to a separate dir or it wipes out original sources
<enebo>
your source is untouched
<enebo>
headius: well I would not allow them to compile to same dir
<headius>
that might be ok
<enebo>
headius: I would output an error saying it would overwrite their sources and bomb out
<headius>
harumph
<enebo>
The beauty of this solution is it removes even needing a flag for .class resources
<headius>
so if src_to_compile == src_stub_from_compile it errors
<enebo>
yeah it would need to stat to make sure you are not overrwring the same source file you are reading from
<headius>
looking to see how warbler does this now
<headius>
if it uses stubs I'm on board
<enebo>
but this is possible so I would not be worried about someone picking ‘./../../foo/src’
<nirvdrum>
Well, I leave that to you guys. I'd be okay with -Xrequire_search.include_class_files=true and just add the .class suffix back in.
<enebo>
I guess my only reservation on the idea is that the process for generating AOT will need to change but if people nearly universally use Warbler to accomplish this I think it can be made transparent to almost all AOT users by changing warbler
havenwood has joined #jruby
<enebo>
That argument would also apply to a flag but I hate the idea of another environmental property
iamjarvo has joined #jruby
<enebo>
I would much rather only spec out ‘require_class’ method
<enebo>
for that matter perhaps we could eliminate require_class as well
<headius>
warbler rewrites them into stubs while building the jar/war
<headius>
that also fixes issues with .rb files being read and evaluated directly, as some loaders/reloaders might do
havenwood has quit [Remote host closed the connection]
<headius>
I think we should still add the property for old behavior and warn
<headius>
I'd rather get an idea who's using the feature before we nuke it
tenderlove has joined #jruby
<enebo>
headius: yeah with PHONE HOME
<nirvdrum>
Next up is who expects "require 'foo'" to find foo.jar? I had no idea JRuby even did that. Whenever I need to require a jar, I use "require 'foo.jar',"
<headius>
nirvdrum: ext authors using *Service :-D
<enebo>
So just to recap we will output to new dir for jrubyc and make .class and .rb
<enebo>
We will abort if they try and use their source dir
<enebo>
And we will allow a flag for old behavior
<enebo>
with warning
<headius>
that sounds right...we need an issue to track the change
<enebo>
impl of .rb stub still a TODO
<headius>
AOT is still a TODO :-D
<enebo>
well I have soln for AOT I think as well
<enebo>
which is just IR persistence unbitrott'd
<enebo>
which is pretty cool since as we were saying the other day it works for 100% of all code to AOT since it starts interpd
<headius>
ahh yes
<headius>
so not even .class anymore
<headius>
.rbj files or something :-D
<nirvdrum>
headius: Hmm . . . it'd be good to drop that search, too. I figured exts wrapped in gems would handle this more gracefully.
<enebo>
headius: It could also be .class if we want too
havenwood has joined #jruby
<enebo>
static initializer could process compiled byte[] of persisted code
<headius>
nirvdrum: that's tougher because MRI require searching does try to load ext for the bare name
<headius>
so we'd diverse
<headius>
diverge
<nirvdrum>
I didn't know that. So, it'll look up a .so?
noop has quit [Ping timeout: 240 seconds]
<headius>
yes
<headius>
e.g. require 'openssl'
<nirvdrum>
Does it also have a .so.rb lookup?
<headius>
I don't think so but I'm not sure
<nirvdrum>
I guess I always assumed that had an openssl.rb that loaded the ext.
<headius>
now you know!
<nirvdrum>
So much performance to be gained if the world could be bothered to type upwards of 4 extra chars.
<headius>
and that's why require searches do twice as many stats as necessary
anaeem1_ has quit [Remote host closed the connection]
<nirvdrum>
I hope donV pops on. I'd love to get to the bottom of the .jar.rb.
<headius>
he was around earlier
<headius>
I missed him too
<headius>
nirvdrum: wanna throw these items into a couple issues please?
<nirvdrum>
Sure.
<enebo>
We could at least open an issue for Ruby3 to kill this behavior
<headius>
I think we're all agreed about fixing service lookup to require a .class resource
<headius>
so that's one item
<enebo>
MRI is not so happy with amount of searching for requires either
<headius>
and the other is AOT as discussed
benlovell has joined #jruby
<nirvdrum>
And getting require down from O(n) is a big gain. In my crazy FS cache implementation, it was shaving seconds off a simple gem require for me.
<headius>
enebo: I'd be surprised if that got accepted, but we could try
<headius>
I think they like having it be opaque whether require 'foo' loads a .rb or an ext
<enebo>
headius: well I think based on stub strategy outlined we can argue it can be invisble to most users
paulswilliamsesq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
anaeem1_ has joined #jruby
<enebo>
we need to put all files into a db with a cached index
<headius>
this isn't for AOT, this is for exts
<nirvdrum>
The problem being new entries are always added to the end of the load path. Each require out of that gem is a fully linear scan through the load path just to get back to the end.
<enebo>
headius: yeah I understand but I am saying the soln can be the same
<enebo>
you just make your ext have a .rb stub which loads the explicit .so
<headius>
enebo: yeah, I've been recommending new ext authors just write code to load and boot the ext class directly, but it's cumbersome
<enebo>
yeah me too for our stuff
<enebo>
I pont out ripper as an example
<enebo>
It is tedious as a soln for our extensions though
<enebo>
but still much preferrable to the magic *Service soln
<headius>
nirvdrum: we could add logic to RG that builds a listing of contained source files, but we can't know if something earlier in load path will beat it
<headius>
we're getting out of jruby improvement into new features though
<nirvdrum>
headius: What I was doing was globbing each directory as I visited them and built up a lookup hash based upon recursively built partial paths.
<nirvdrum>
That part is pretty easy.
<nirvdrum>
The issue is people can write new files to existing load path entries, busting the cache.
<nirvdrum>
To compensate, I was using a file system watcher, but that's Java 7+ only. And doesn't work terribly great on Mac from what I gather.
<headius>
can and often do in dev, e.g. while inside a console
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mjgpy3 opened pull request #2233: Comparable#== raises SystemStackError when calling classes don't impleme... (master...fix_comparables_that_dont_define_op_cmp_4) http://git.io/an4Obw
JRubyGithub has left #jruby [#jruby]
benlovell has quit [Ping timeout: 264 seconds]
<headius>
yeah for some reason the FS watcher in openJDK still polls on mac
<nirvdrum>
headius: You write a new .rb file to the FS in a dev console?
<nirvdrum>
I've never seen anyone do that.
<headius>
I mean you're in the console and modifying files
<headius>
or adding files
<headius>
and then you go to require
<headius>
I believe it's typical to have e.g. a rails console up while doing dev, right?
<nirvdrum>
Ahh. I usually end up doing a reload! in Rails, which would change all that anyway.
<headius>
right, and that may make my point moot, I don't know
<headius>
it's a visible behavior change from MRI, though
<nirvdrum>
It's not required though. There's just some stuff Rails caches at boot, so reload! makes it so I don't have to think about it.
<nirvdrum>
Anyway, that's the hurdle I had with the constant lookup.
<nirvdrum>
It could work and be faster in a lot of cases, with a potential failure case since the FS watcher isn't guaranteed.
<nirvdrum>
Incidentally, that same work made the suffix list size mostly moot.
<nirvdrum>
But, it's nice to see that it's doable in some way in any event.
<headius>
yeah, in most cases it would work fine :-\
mcclurmc has joined #jruby
<enebo>
For warbled stuff this should be 100% doable though
<enebo>
As packaged source it could precalculate all requires and have no lookup overhead
<enebo>
It probably makes more sense for us to generate load index as a feature in JRuby itself
<enebo>
Then people could elect to remove live fs changes to speed up loading if they wanted
<JRubyGithub>
[jruby] nirvdrum opened issue #2234: Change AOT class generation for speedier requires http://git.io/G_RLmA
JRubyGithub has left #jruby [#jruby]
paulswilliamsesq has joined #jruby
<nirvdrum>
Oh, I guess issue notifications come here now.
<enebo>
nirvdrum: cool thanks
<enebo>
I believe we also already have an open issue on no AOT support
<nirvdrum>
I think I excerpted enough IRC to job your memory. I can go further back, but it was mostly us discussing ideas that got tossed.
<enebo>
nirvdrum: yeah that was great context
<enebo>
I don’t see a make AOT work issue so I will make one
<nirvdrum>
headius: It might be good to come up with a timetable on maybe changing extension loading behavior. Maybe deprecate in 9k and remove in the next. It'd just be nice to not have to pay that cost because of a decision made in 2007 that lacked 7 years of additional context.
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] enebo opened issue #2235: Make AOT work on 9k http://git.io/p9DehQ
JRubyGithub has left #jruby [#jruby]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius opened issue #2236: Ant must be installed to run rake targets, but we don't use ant anymore http://git.io/V-y5LQ
JRubyGithub has left #jruby [#jruby]
drbobbeaty_ has joined #jruby
drbobbeaty has quit [Ping timeout: 255 seconds]
vtunka has quit [Quit: Leaving]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to master: http://git.io/4aCmBQ
<JRubyGithub>
jruby/master 13b6fc3 Charles Oliver Nutter: Add Ant to build prerequisites for now (#2236)
JRubyGithub has left #jruby [#jruby]
calavera has joined #jruby
<headius>
yeah I tweaked github hooks to send new and closed issue updates
mamantoha has quit [Ping timeout: 250 seconds]
nirvdrum has quit [Ping timeout: 255 seconds]
janitrix has quit [Quit: Page closed]
nirvdrum has joined #jruby
benlovell has joined #jruby
nirvdrum has quit [Remote host closed the connection]
Aethenelle has joined #jruby
kares has joined #jruby
e_dub has joined #jruby
benlovell has quit [Ping timeout: 255 seconds]
paulswilliamsesq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
iamjarvo has joined #jruby
drbobbeaty has joined #jruby
drbobbeaty_ has quit [Ping timeout: 256 seconds]
Hobogrammer has quit [Ping timeout: 255 seconds]
mkristian has joined #jruby
dabradley has quit [Ping timeout: 264 seconds]
anaeem1_ has quit [Remote host closed the connection]
dabradley has joined #jruby
mamantoha has joined #jruby
cprice404 has joined #jruby
bbrowning_away is now known as bbrowning
mbj has quit [Ping timeout: 240 seconds]
claudiuinberlin has quit [Quit: Leaving.]
mamantoha has quit [Quit: No Ping reply in 180 seconds.]
mamantoha_ has joined #jruby
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<nirvdrum>
Sorry to bail on the earlier conversation. The silly electrician drilled through a wire. So I went to go read for a bit.
<headius>
hah
<headius>
nice
<nirvdrum>
I just noticed I got left off the "who's using JRuby?" slide. After all that regression testing I did for IR, too :-P
<headius>
ahh well point me at a logo and I'll add it :-)
<headius>
there's only a couple on there I added before hearing from the users
<nirvdrum>
The company is shutting down in a week. Not all that necessary :-)
mcclurmc_ has quit [Ping timeout: 264 seconds]
<nirvdrum>
I'm an Oracle man now!
<nirvdrum>
I just wanted to complain, I guess.
<nirvdrum>
I wish I could have made RubyConf. Oh well.
<headius>
Antiarc: around? I see you made some fixes for exceptions similar to the current test:mri failure on CI and wanted to chat
<headius>
joda ArithmeticException I get locally and IllegalFieldValueException on Travis
<headius>
I am going to exclude the failure and file a bug for the moment
elia has quit [Quit: Computer has gone to sleep.]
pietr0 has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius opened issue #2237: Joda exceptions recently in mri/ruby/test_time.rb http://git.io/tkndbw
JRubyGithub has left #jruby [#jruby]
iamjarvo has joined #jruby
<Antiarc>
headius: Just clocked in, let me take a look
<headius>
Antiarc: thanks...pushing exclude now
<Antiarc>
nirvdrum: Should we expect torquebox-sidekiq-service to still work?
<headius>
should be almost back to green, but that blasted fiber/thread exception test is a pain
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 2 new commits to master: http://git.io/GGO_Bw
<JRubyGithub>
jruby/master 6414b4b Charles Oliver Nutter: Exclude regressed MRI test for #2237.
<JRubyGithub>
jruby/master 6e5f32e Charles Oliver Nutter: Different strategy for weak cache test.
JRubyGithub has left #jruby [#jruby]
<Antiarc>
headius: Vaguely off the top of my head this has to do with time zone offsets that are too big? Joda doesn't handle anything out of a reasonableish range I think?
<nirvdrum>
Antiarc: Were you actually using that?
<headius>
Antiarc: that sounds right
<Antiarc>
nirvdrum: Not yet, but we're looking at it. We're on torquebox, wondering if it would be reasonable to let TB manage Sidekiq for us
anaeem1 has quit [Remote host closed the connection]
<Antiarc>
headius: I don't think I fixed any tests relating to TZ overflow. Couldn't we just mod the timezone by 86400, though? If MRI is substracting days due to the offset we can compute that easily
<headius>
Antiarc: maybe? I just looked through logs and saw you fixed another ArithmeticError
<Antiarc>
Lemme go back and refresh
<headius>
I can circle back and sort out what's actually wrong with this in a bit
<nirvdrum>
Antiarc: I ended up not using it any longer for a variety of reasons. One was that Sidekiq kept changing its CLI class and things kept breaking. But the bigger one, IIRC, is TorqueBox wouldn't reload the app (e.g., on redeploy) until all services stopped. And that was a problem because we had long-running jobs.
<Antiarc>
headius: are you using openjdk or the oracle jdk? Maybe the difference is there?
<Antiarc>
nirvdrum: Ah, okay. Good to know!
<nirvdrum>
Antiarc: I think the other issue was job load was impacting web load. And there was no easy way to account for that.
<nirvdrum>
So, it works, but probably not at scale.
<headius>
Antiarc: perhaps, but joda should be the same
<headius>
it's certainly possible though
<nirvdrum>
I settled on writing a HornetMQ facade to Rails cache to access that stuff out of container.
<nirvdrum>
It works pretty well. I could open that up.
<Antiarc>
headius: Oh, just looked at the exceptions again, yeah, you're right
<Antiarc>
nirvdrum: It's no big deal to run Sidekiq separately, I'm just being lazy and looking for places where I can avoid wheel reinvention :)
<mkristian>
headius, Antiarc the update to joda 2.5 brought this new ArithmeticError (or locally with me some InvalidFieldException)
<headius>
mkristian: ahh, I wondered if it might be that
<headius>
so it has made something more strict
<mkristian>
the test allows an RangeError so on jruby-1_7 I "translated" that into a RangeError
<headius>
oh, and that change just hasn't made it to master?
<headius>
I saw you did some branch merging
<mkristian>
somehow got lost in the merge
<headius>
unfortunate
<headius>
well at least we can find it again :-)
<headius>
I was afraid of doing that merge myself
<headius>
got too behind
<mkristian>
I added the commit to the issue ;) and can redo on master - if it is the right way of fixing this
noop has joined #jruby
<headius>
yeah I'm not sure...that will still cause this test to error
<headius>
I think we need to translate the value into something joda will accept
<mkristian>
on jruby-1_7 the tests allow a RangeError !
<headius>
bleh, of course :-)
<headius>
I think we should install the RangeError commit and leave the bug open
<headius>
so at least people don't get a joda exception
<mkristian>
IMO a RangeError for such case is OK
<headius>
I wish I could get that fiber/thread spec to fail locally
<headius>
I need a more constrained machine
<Antiarc>
headius: is it possible to get the full travis env? It shouldn't be too hard to set up a VM to match it
<Antiarc>
Could even ship a vagrantfile with the env for bootstrapping development :)
<headius>
asarih_ set up an ssh'able temporary instance for us recently
<headius>
that was pretty slick
<headius>
I'm going to set this up to run in a loop with more logging locally and get some lunch
dfr|work has joined #jruby
<headius>
mkristian: the ASM rewrite test is failing in -Pdist, do you know why?
skade has joined #jruby
drbobbeaty has quit [Ping timeout: 256 seconds]
<Aethenelle>
should NOT_ALLOCATABLE_ALLOCATOR be weeded out where possible?
<mkristian>
headius, let me see -Pdist
mister_solo has joined #jruby
<headius>
mkristian: failing consistently on travis
<headius>
Aethenelle: weeded out?
<Aethenelle>
i guess it's just the usage in FFI that i'm not sure on... elsewhere it's only used where it makes sense
<Aethenelle>
VariadicInvoker is not allocatable ... just seems odd
<headius>
it's basically just used when we don't want someone to be able to .allocate a given class's objects directly
<headius>
i.e. if there's a specific "new" logic that must be run
mamantoha_ has joined #jruby
erikhatcher has joined #jruby
<Aethenelle>
i'm going to look over the stuff in FFI and compare to MRI's...
<headius>
yeah cool...we really need to finish syncing that stuff up
SynrG has quit [Ping timeout: 256 seconds]
subbu has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian pushed 3 new commits to master: http://git.io/mn_1tA
<JRubyGithub>
jruby/master f9190ce Christian Meier: fix another joda-2.5 exception...
<JRubyGithub>
jruby/master 461f315 Christian Meier: Merge branch 'master' of github.com:jruby/jruby
<JRubyGithub>
jruby/master e526e61 Christian Meier: fix the ASM test on -Pdist
JRubyGithub has left #jruby [#jruby]
anaeem1_ has joined #jruby
tobleronegordon has joined #jruby
<headius>
mkristian: thank you
<headius>
I think only one suite is left failing now
<headius>
bbiab, coffee shop
tobleronegordon is now known as tobleronelunch[a
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
yfeldblum has joined #jruby
drbobbeaty has joined #jruby
yfeldblum has quit [Ping timeout: 245 seconds]
calavera has joined #jruby
iamjarvo has quit [Ping timeout: 240 seconds]
<headius>
mkristian: btw, thank you for adding so many tests to the different dist forms
shellac has joined #jruby
anaeem1_ has quit [Remote host closed the connection]
<mkristian>
headius, it was something I missed personally for a long and I was surprised how much did work - I expected a few more "errors"
x1337807x has joined #jruby
<headius>
yeah I'm amazed you got that much to run
anaeem1_ has joined #jruby
paulswilliamsesq has joined #jruby
ted_ has joined #jruby
<ted_>
Hello (wave)
<ted_>
How do one profile jruby within rails c?
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius>
ted_: rails c is based on IRB, which might make it problematic for profiling
<headius>
it's better to create a test script that does what you want
<ted_>
headius: I see, thank you
purplefox has quit [Ping timeout: 240 seconds]
tcrawley is now known as tcrawley-away
bga57 has quit [Ping timeout: 258 seconds]
<Antiarc>
ted_: You might look at using visualvm to connect to your jruby process and use the CPU sampling
<Antiarc>
That's how I do most of my production profiling and it works like a charm
<ted_>
Antiarc: sorry, don't have much experience with visualvm. Does it show the timestamp, memory and time spent on actions?
x1337807x has joined #jruby
tcrawley-away is now known as tcrawley
<Antiarc>
ted_: It's a sampling profiler, so it accumulates which methods are seen most often when sampling threads; it's less about "how long did this take" and more about the relative time that one method takes to another (or the rest of the process)
x1337807x has quit [Client Quit]
<Antiarc>
Measuring memory usage is a bit outside of its scope, but if you suspect a leak you can take heap dumps for analysis
<Antiarc>
If your goal is "find the slow spot in my process" it's the right tool
<Antiarc>
If your goal is to microbenchmark code, write a standalone benchmark using the benchmark gem
<Antiarc>
(also, microbenching jruby is fraught with peril, make sure you properly warm up the JVM first)
<ted_>
"find the slow spot in my process" is what I'm trying to do. Thank you! :)
subbu has quit [Ping timeout: 240 seconds]
<Antiarc>
Some terms to google would be jmx and jvisualvm - you'll start your process with some switches to turn on JMX, and then can connect to your JVM with jvisualvm
mbj has quit [Quit: leaving]
x1337807x has joined #jruby
<ted_>
yeah, you're right. already see the "failed to create JMX connection"
<byteit101>
enebo: then why does it? should I report this as a bug?
blinsay is now known as blinsay_
<enebo>
byteit101: yeah report it. RubyGlobal itself stores all globals in Ruby (runtime) so I am guessing ScriptnigContainerProvider must be doing something odd
andreanastacio has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<enebo>
ok I somewhat rescind but we should warn it is deprecated behavior at a minimum
codefinger has joined #jruby
calavera has joined #jruby
<mkristian>
headius, I think this was just forgotten to add when the version changed recently (or the mapping of maven-version to rubygem-version) which is inside jruby-jars.gemspec
paulswilliamsesq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
e_dub has joined #jruby
<Antiarc>
Is there a simple way to determine the minimum viable encoding for a group of strings?
<Antiarc>
Or do I basically need to build a hierarchy of encodings?
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian pushed 1 new commit to master: http://git.io/iNLeEw
<JRubyGithub>
jruby/master 20f81da Christian Meier: fix -Pjruby-jars...
JRubyGithub has left #jruby [#jruby]
<Antiarc>
Encoding#compatible? seems like it'd do the trick, but I'm wanting to go a step further and "downgrade" to US-ASCII if both strings pass ascii_only?
shellac has joined #jruby
lanceball is now known as lance|afk
JohnBat26 has quit [Ping timeout: 272 seconds]
baroquebobcat has quit [Quit: baroquebobcat]
mitchellhenke has quit [Quit: Computer has gone to sleep.]
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
rsim has joined #jruby
iamjarvo has joined #jruby
yfeldblu_ has quit [Remote host closed the connection]
yfeldblum has joined #jruby
bbrowning is now known as bbrowning_away
Aethenelle has quit [Quit: Aethenelle]
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
andreanastacio has joined #jruby
lidaaa has joined #jruby
e_dub has quit [Quit: It's a hard knock life]
tenderlove has quit [Remote host closed the connection]
e_dub has joined #jruby
<headius>
Antiarc: I think there's a function for that but I don't remember where
<headius>
it's used to negotiate a common encoding for e.g. dynamic strings
codefinger has quit [Quit: Leaving...]
fridim_ has quit [Ping timeout: 272 seconds]
<Antiarc>
I'm just building a concatenated string and taking its encoding for now
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bocaj_ has quit [Quit: Connection closed for inactivity]
<trobrock>
I have a java interface that I am trying to implement in a jruby class, but this interface requires me to define a method named "initialize" when I define this method in my jruby class it assumes it is the object constructor, is there a way of doing this?