<mkristian>
enebo, hi - I was just asked about when 1.7.20 will be released - well I do remember to hear the same question last week ?
cpuguy83_ has joined #jruby
<enebo>
mkristian: oh yeah? That is a good question. I am not sure offhand. I have been so focused on master I have not examined what needs to be done yet for 1.7.20. Do you want a new release? Are you waiting on some fix?
mcclurmc_ has quit [Ping timeout: 250 seconds]
cpuguy83_ has quit [Client Quit]
cpuguy83_ has joined #jruby
cpuguy83_ has quit [Remote host closed the connection]
cpuguy83_ has joined #jruby
<mkristian>
enebo, the jffi is one and the fix on the load_service problem with jar filenames containing "+" - that is what lookout is "waiting" for. jffi might be possible to use the released jffi jar.
<enebo>
mkristian: ah ok good to know
<enebo>
later in the week I should have an answer
Hobogrammer has quit [Ping timeout: 255 seconds]
<mkristian>
ok that is answer :)
<enebo>
we will talk about what is unresolved and marked against the release on github but I need to fix master (and I am getting much closer)
cpuguy83_ has quit [Client Quit]
subbu is now known as subbu|afk
<mkristian>
just needed some hint ...
phrinx has quit [Read error: Connection reset by peer]
<headius>
mkristian: can you give me the one line pitch about what this improves? I'm having trouble getitng the details out of that PR
<headius>
I guess I'm concerned about adding another loading mode that's off by default
<headius>
assuming I read that part right
<mkristian>
removing the old load-service and allowing to "reactivate" it via system property. command line switch
<mkristian>
headius, well, I can remove the switch ;) but in case there is a regression then there is a regression
<headius>
so what does the new load service improve, in 140 characters or less
<headius>
I will review the commits as well, but give me high level
<mkristian>
it will not use findLibraryWithClassloaders of the "old" loadService anymore but just look into uri:classloader:/ to load the kernel or ruby files from required jars
<kares_>
mkristian: would keep a hidden "non-public" System.property instead of the switch if you feel it might be handy for edge case bug verification
<headius>
mkristian: what I mean is what changes, functionality-wise, performance-wise, etc...that sounds good, but I want to understand the risk
<mkristian>
headius, ok :)
<headius>
my gut is to go with it enabled if it isn't expected to break things
<kares_>
also aren't we using ClasspathResource in jruby-openssl ?
<headius>
your desire to leave it off makes me worry that things are expected to break :-)
<mkristian>
required jar which needs directory globs need .jrubydir files inside their directories
<mkristian>
the switch was only there because I expected someone of you guys will as for it ;)
nateberkopec has joined #jruby
<headius>
so does this mean globbing arbitrary jar contents won't work anymore?
<mkristian>
performance wise it should be better since "not found" does not go through findLibraryWithClassloaders anymore
<headius>
so this is only for loading .rb code out of jars, but you'll have to have a special file in there to do it?
<mkristian>
globing will only work if they have extra dir info files. but it never worked on certain environments like my usual candidates: websphere, osgi, wildfly
<mkristian>
classlaoder do not provide directory info in general (some do) so when using the classloader API there is no way get the directory info
<headius>
you mean literally Dir.glob or just the searching we do in LoadService?
<headius>
right that's true
<headius>
and even jars sometimes don't include directory entries
<mkristian>
with jruby-stdlib those extra files are packed and globing there works
<headius>
why a special file and not just a jar index?
<headius>
jar -i
<mkristian>
is just a list of directories ! not about files inside the directories.
<headius>
a related concern is what happens to released artifacts that have .rb files in them...they'll have to release a new version with this file, yes?
<mkristian>
the index.list could be used to improve the lookup performance. they need the release a new version if they use Dir.globs
<headius>
mmm ok
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 2 new commits to master: http://git.io/x6Bl
<JRubyGithub>
jruby/master ec1bf31 Chris Seaton: [Truffle] Most of the Hash#each specs.
<JRubyGithub>
jruby/master edd7034 Chris Seaton: [Truffle] Hash#each_key and #each_value specs passing.
JRubyGithub has left #jruby [#jruby]
e_dub has quit [Quit: e_dub]
<headius>
I'm just not sure all projects will be able to do that, if for example they're using an upstream project
<mkristian>
kares_, we use JRubyFile to find the resources jruby-openssl - that is be fine
<mkristian>
headius, you might remember we talked about adding required jars to laod_path a few month back.
<mkristian>
this is still possible.
<headius>
mkristian: right, I remember
<mkristian>
headius, either I add this or keep findLibraryWithClassloaders for those Dir.glob cases !
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 1 new commit to master: http://git.io/x60Y
<JRubyGithub>
jruby/master d7ca496 Chris Seaton: [Truffle] Hash#keys and #values specs passing.
JRubyGithub has left #jruby [#jruby]
<headius>
hmmm
<headius>
it would be nice to not have Dir.glob change behavior
<mkristian>
headius, maybe if findLibraryWithClassloaders really finds something there is deprecated warning ?!
<mkristian>
I mean use findLibraryWithClassloaders only for those Dir.glob cases
<headius>
right...so if I understand, you introduced the .jrubydirs thing solely because globbing doesn't work in all envs using current logic
<headius>
seems like perhaps the current logic should be the fallback behavior if .jrubydirs or jar index aren't present
<mkristian>
and OSGi can not use default gems otherwise
<headius>
ok, explain that :-)
pitr-ch has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 1 new commit to master: http://git.io/x6uJ
<JRubyGithub>
jruby/master ab8c9e4 Chris Seaton: [Truffle] Hash#invert specs passing.
JRubyGithub has left #jruby [#jruby]
marr has quit []
jeremy04 has joined #jruby
<mkristian>
OSGi does not allow to find the jar and without the jar there are no Dir.glob and without them rubygems can not find specification/default/*gemspec, i.e. not default gems
Aethenelle has joined #jruby
<mkristian>
some with embedded gems. some with websphere
<mkristian>
some =same
<mkristian>
and there are gems using DIr.globs which only works when adding .jrubydir when packing the jar with embedded gems on those "exotic" classloaders - actually thing is mainly it is just a classloader and not a URLClassLoader ;)
jeremy04 has quit [Ping timeout: 265 seconds]
<mkristian>
headius, using findLibraryWithClassloaders after our new LoadService did not find anything is the "current logic" and it is the fallback as you said
<headius>
ok I see
<headius>
I have no problem making the change then if we preserve existing Dir.glob functionality
<mkristian>
so we load everything we can with the new code and only those Dir.glob inside jars will be loaded with this findLibraryWithClassloaders to stay backwards compatible
<headius>
it won't work everywhere, but where it is working for people now it will continue to work
<mkristian>
yes
<headius>
ok
<headius>
enebo: you might want to read back a bit, but it sounds now like this change will improve loading from classloader (required for osgi) and should not break any functionality
<mkristian>
and then no switch since there is nothing to switch ;)
anaeem1_ has quit [Remote host closed the connection]
<mkristian>
headius, one more thing which I mentioned in PR - once you put back the old io so it works for jossl-0.9.5 - I reverted this but could also just fix it to work with the change in URLResource
zorak8 has quit [Ping timeout: 246 seconds]
<headius>
oh that was the fix you meant
<mkristian>
jossl-0.9.6 does not need the old IO code anymore
<headius>
I think we will leave it in place for now with massive deprecation warnings all over it
<mkristian>
ok
<nirvdrum>
MRI 2.2.1 is out.
<enebo>
headius: mkristian: I did just read this and I mainly only worry about backwards compat. As long as we do not regress behavior I am ok. Also adding a new file if it makes a previous unglob’able directory start working sounds like a nice improvement assuming anyone ever knows we have that feature
<nirvdrum>
In case you guys missed it.
<enebo>
nirvdrum: yeah we should update out stdlib stuff and junk
codefinger has joined #jruby
<enebo>
going to do some epic shovelling…my house and my parents…the adventure awaits…afk a while
<nirvdrum>
Might be worth considering pre2 just for that.
codefinger has quit [Client Quit]
<headius>
I will update stdlib so it has time to bake
anaeem1_ has joined #jruby
marr has joined #jruby
<mkristian>
enebo, gem-maven-plugin does this already when packing gems into a jar. warbler is on my list - at least for gems.jar which will improve things for some app-servers. and gradle-jruby-plugin I will help to get it in there as well. so some people will get the extra file without knowing it
e_dub has joined #jruby
mcclurmc has quit []
<nirvdrum>
chrisseaton: What in our case would cause a primitive node to fail over to the Ruby code after the primitive call?
calavera has joined #jruby
<chrisseaton>
You return null
<chrisseaton>
You mean a Rubinius primitive right?
mcclurmc has joined #jruby
<nirvdrum>
Yeah.
<nirvdrum>
So, add a specialization that just returns null?
<chrisseaton>
Yeah
<chrisseaton>
Not the prettiest I know
<nirvdrum>
It's not so bad. It'd be nice if no specializations match that it falls back to Ruby, too.
<nirvdrum>
Although that might make it harder to see what should maybe be implemented.
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
colinsurprenant has quit [Quit: colinsurprenant]
iamjarvo has joined #jruby
pitr-ch has quit [Quit: Leaving]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 7 new commits to master: http://git.io/x658
<JRubyGithub>
jruby/master e6fdfbc Kevin Menard: [Truffle] Untagged passing String specs.
<JRubyGithub>
jruby/master 9132b54 Kevin Menard: [Truffle] String#<< now taints results.
<JRubyGithub>
jruby/master 594b08e Kevin Menard: [Truffle] String#b now taints results.
<nirvdrum>
chrisseaton: If you prefer, I can just go through and make all of the clauses look in both locations.
Aethenelle has joined #jruby
<headius>
not a ton of stdlib changes in 2.2.1
<nirvdrum>
headius: Is there a game plan for pre2?
<headius>
I think we should shoot for the next week or two, but we need to tally up open tasks
<headius>
I still need to finish up missing AOT and JIT bits for feature-completeness with 1.7, and ideally that would get into a preview before an RC or final
<nirvdrum>
My personal take is do them more frequently and just plan on having several.
<headius>
yeah
<headius>
we're always afraid of releases because something goes haywire
<nirvdrum>
We don't want to lose momentum behind 2.2.1. I.e., we don't want the story to be "JRuby is lagging even more".
<headius>
there's no reason a pre2 couldn't go out now...it's a matter of deciding what we want in it and weighing that
mistergibson has joined #jruby
<nirvdrum>
It'd probably be good to get the bottom of why releases keep going haywire, too. I realize I'm speaking obvious stuff there. But I thought a big part of the maven move was to prevent those sorts of problems.
baroquebobcat has quit [Quit: baroquebobcat]
baroquebobcat has joined #jruby
<nirvdrum>
If I can help out there, let me know.
subbu is now known as subbu|lunch
<headius>
yeah I know
<headius>
I think the build has settled down mostly now
<headius>
around pre1 we were still patching it up
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 2 new commits to master: http://git.io/x6hd
<JRubyGithub>
jruby/master 2b7f1da Charles Oliver Nutter: Update Ruby stdlib and version to 2.2.1.
<JRubyGithub>
jruby/master ac4fea1 Charles Oliver Nutter: Remove patchlevel from Ruby version, since MRI doesn't use it now.
<lopex>
nirvdrum: I have always wondered how rubinius manages those things, since having "primitives" on one side and most of the impls in ruby on the other - that can b hard
anaeem1_ has quit [Remote host closed the connection]
<knowtheory>
headius: thanks for the help last week
skade has joined #jruby
<knowtheory>
turns out, it wasn't anything we were doing. the lib we are wrapping had a memory leak, which we ended up digging out.
<nirvdrum>
MRI can be infuriating.
<lopex>
it's an impl by accident
<lopex>
how can you wonder
<nirvdrum>
"If passed a single Fixnum, returns a substring of one byte at that position."
<lopex>
and the design is the "design by overhead"
<knowtheory>
(the top right corner there is 5.5gb of memory used)
<nirvdrum>
headius: Checking the to_int seems okay. But I don't see the need for <=>. Especially in this case where the range begin and end are just extracted passed in as arguments to something else.
kith has quit [Quit: kith]
kith has joined #jruby
subbu has quit [Ping timeout: 252 seconds]
mattwildig has quit []
<headius>
nirvdrum: it looks like it does it to make sure from is lower than to
<headius>
at least in JRuby
mister_solo has quit [Ping timeout: 256 seconds]
<nirvdrum>
Thanks. I'll take a look and see if we're doing something wrong then.
enebo has joined #jruby
<lopex>
headius: lately I benchmarked sinatra and heavent found any dominating jruby methods
<lopex>
headius: does that sound suspicious ?
<headius>
you mean no Java methods?
<lopex>
headius: just nio.* and then jit* but quite far below
<lopex>
and that was torquebox 4
<nirvdrum>
Block overhead?
<nirvdrum>
Sinatra likes to use blocks.
<lopex>
maybe on 15-20-ish
<lopex>
the ruby code was non-negligible logic
<lopex>
headius: some pre jit, post etc, etc but non dominating
<headius>
lopex: it's not unreasonable...perhaps we've pushed all core down below ruby overhead again
<lopex>
ale there was no substantial difference bewteen nio* and jruby.*
<lopex>
*s/ale/and/
<headius>
do an allocation profile
<headius>
usually if a perf profile doesn't show me anything useful an allocation profile makes clear why
<lopex>
how do I do that ?
enebo has quit [Ping timeout: 256 seconds]
<lopex>
headius: in the past there where more substantial waits, but that's new torquebox maybe ?
enebo has joined #jruby
<lopex>
headius: in any case, compared to an as/400 db2 access times, the jruby code overhead seems to be negligible
<lopex>
I know it doesnt do too much to, but I'm happy with the ratio
<lopex>
lots of caching etc
<bbrowning>
I could see that if your code is spending most of its time waiting on a database then you wouldn't really see any ruby methods bubbling up in a profile
<lopex>
on jruby side
Aethenelle has quit [Quit: Aethenelle]
<lopex>
bbrowning: oh sure, that comment was about pure response
<bbrowning>
there are some thread tunings you can do on the TB4 side, but they aren't really useful except in 'hello world' style benchmarking
e_dub has quit [Quit: e_dub]
<lopex>
bbrowning: for now tb is performing marvellously
<bbrowning>
great!
<lopex>
the alpha4
<bbrowning>
yeah
<lopex>
well, just for having th newset one
<lopex>
*newest
e_dub has joined #jruby
<lopex>
bbrowning: oh, and throw/catch is also quite negligible on jruby side - that sinatra uses
<lopex>
headius: yeah, rescue is much worse than mri
dinfuehr has joined #jruby
<lopex>
bbrowning: any update on tb4 soon ? :)
<bbrowning>
lopex: I want to get an alpha2 out by next week with some fixes that are already in
<bbrowning>
it doesn't have 100% of my focus these days, so things are progressing slower than expected
camlow325 has quit [Ping timeout: 264 seconds]
camlow32_ has joined #jruby
<lopex>
bbrowning: also, cool thing is that non xmx-ed jvm is at 350-400MB at heavy concurrent nechmark
<lopex>
*benchamrk
<bbrowning>
not bad!
dinfuehr has quit [Ping timeout: 246 seconds]
<lopex>
sure, most it's just a json responses, but 100% is driven by engine/framework metadata
<lopex>
not just simple hardcoded responses
<lopex>
all real functions
tcrawley-away is now known as tcrawley
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 1 new commit to master: http://git.io/xids
<JRubyGithub>
jruby/master 8e7db2f Kevin Menard: [Truffle] Pass a lot more of String#byteslice.
JRubyGithub has left #jruby [#jruby]
colinsurprenant has quit [Quit: colinsurprenant]
camlow32_ has quit [Remote host closed the connection]
camlow325 has joined #jruby
<nirvdrum>
headius: Where are ranges created in JRuby? I'm still having trouble making sense of this.
<headius>
BuildRangeInstr I believe
<nirvdrum>
Thanks.
camlow325 has quit [Remote host closed the connection]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to master: http://git.io/xijV
<JRubyGithub>
jruby/master 81a5ac5 Charles Oliver Nutter: defined? returns frozen strings; fix JIT....
JRubyGithub has left #jruby [#jruby]
jeremy04 has joined #jruby
<nirvdrum>
headius: It's kinda weird that it's checked, but the result ignored essentially. But this wouldn't be the first odd thing I've run into with Ruby.
mister_solo has joined #jruby
x1337807x has joined #jruby
jeremy04 has quit [Ping timeout: 246 seconds]
baroquebobcat has joined #jruby
camlow325 has joined #jruby
camlow325 has quit [Remote host closed the connection]
camlow325 has joined #jruby
camlow325 has quit [Remote host closed the connection]
erikhatcher has quit [Quit: erikhatcher]
JRubyGithub has joined #jruby
<JRubyGithub>
jruby/master 13b160b Kevin Menard: [Truffle] Fixed checks for range literals on arbitrary objects.
<JRubyGithub>
jruby/master 6353556 Kevin Menard: [Truffle] Untagged a spec passing now because of improved Range support.
<JRubyGithub>
[jruby] nirvdrum pushed 3 new commits to master: http://git.io/xPTS
<JRubyGithub>
jruby/master 894a37c Kevin Menard: [Truffle] Untagged a bunch of passing Range specs.
JRubyGithub has left #jruby [#jruby]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] enebo created test-hypernugget (+29 new commits): http://git.io/xPIo
<JRubyGithub>
jruby/test-hypernugget 54bcd35 Thomas E. Enebo: IRScope.ascquireInterpreterContext to localize this common logic
<JRubyGithub>
jruby/test-hypernugget 6a494f9 Thomas E. Enebo: Things we are minimally building and interpreting will now be more obvious BEGIN/END/eval
<JRubyGithub>
jruby/test-hypernugget d823301 Thomas E. Enebo: acquireInterpreterContext replaces prepareForInterpretation
JRubyGithub has left #jruby [#jruby]
enebo has quit [Ping timeout: 244 seconds]
enebo has joined #jruby
<nirvdrum>
Sweet. I'm not sure when it changed (maybe my byteslice stuff), but there no longer appear to be any infinite loops in Truffle RubyString. I can mass untag specs now :-)
<headius>
yay
<headius>
HYPERNUGGET
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 1 new commit to master: http://git.io/xPYc
<JRubyGithub>
jruby/master 8697907 Kevin Menard: [Truffle] Untagged a bunch of passing String specs.
JRubyGithub has left #jruby [#jruby]
<enebo>
headius: names are tough
camlow325 has joined #jruby
<chrisseaton>
nirvdrum: the irony of your specs reports is that they are going to get less and less useful until one day they are pointless
<nirvdrum>
Yeah. But they've been very helpful in figuring out where to focus. I wish it didn't take 3 days to get them this far, but it's done.
<headius>
you know, I'd really love if travis queued up fifteen minutes of pushes rather than running for every push
<headius>
especially when you're push-happy like us
dfr|work has joined #jruby
<chrisseaton>
headius: you'd spend your life bisecting for regressions
<headius>
I don't think so
<headius>
15 minutes isn't that bad
<headius>
but it would keep us from shotgunning dozens of commits at travis
elux_ has joined #jruby
elux_ has quit [Client Quit]
<headius>
besides, whenever we're doing that and actually need the results, they're coming out hours later
<headius>
self-defeating
<chrisseaton>
We push a lot to specifically make sure our CI system does run
<chrisseaton>
But that's benchmarks rather than tests
<headius>
yeah
<headius>
travis is pretty slow, so giving it a dozen pushes to build in an hour backs us waaaaay up
<subbu>
headius, sorry .. was chatting with tom and then was pulled into a work channel.
<headius>
no problem
<headius>
I removed ConstantLiteralString because it was almost the same as FrozenString...except FrozenString extended ImmutableLiteral to get interp caching
<subbu>
so, what is the issue?
<subbu>
what expects frozen strings to not be frozen strings?
<headius>
but other code expected StringLiteral
<subbu>
is that just an ir builder issue .. of using the wrong type?
<headius>
so I had to change superclass and lose caching
<headius>
it's a builder issue, yes
elux has quit [Ping timeout: 252 seconds]
<headius>
the JIT will still cache because it knows FrozenString can be cached
<bjfish2>
jenkins calls it quiet period
<headius>
bjfish2: yeah, exactly
<headius>
I would love for us to CI every minute change but there's practical aspects here
<headius>
not to mention we're killing the earth
yfeldblum has quit [Ping timeout: 256 seconds]
<subbu>
so, we need to split uses of FrozenString in IRBuilder into FrozenString and StringLiteral and use the appropriate one ..
<subbu>
and make FrozenString an Immutable as it was.
<headius>
yeah that's probably the right move
<bjfish2>
chrisseaton do we have a way to do this in ruby? Rubinius::Type.infect str, pattern
<subbu>
I don't know where you encountered the wrong type .. but, could you make those changes in the IR builder?
<headius>
ok, I'll try to sort out where it was coming from
<subbu>
k.
<headius>
it was a blind cast of an operand in interpreted code
<chrisseaton>
bjfish2: we should support Rubinius::Type methods already - there could be missing ones though - bootstrap/type.rb usually