<bbrowning>
hmm it's looking like rubygems 2.4.5 does in fact expose a bug in jruby's loading of BasicLibraryService impls
<bbrowning>
tracking down the exact cause now, but basically under certain circumstances rubygems expands the thing being required to an absolute path and passes that to the original require
<bbrowning>
and when that happens, it breaks loading any jruby extensions from the jar being required
<bbrowning>
bingo! require "nokogiri/nokogiri" ends up trying to load the class nokogiri.NokogiriService but require "/path/to/nokogiri" ends up trying to load the class path.to.nokogiri.NokogiriService
<bbrowning>
err that 2nd require should be "/path/to/nokogiri.jar"
zorak8 has quit [Ping timeout: 264 seconds]
_gautam_ has quit [Quit: Be back later ...]
SynrGyy is now known as SynrG
dyer is now known as dyer|away
dyer|away is now known as dyer
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] bbrowning opened issue #2336: RubyGems 2.4.5 Upgrade Triggers Bug in Java Extension Loading http://git.io/kkgXQA
anaeem1 has quit [Read error: Connection reset by peer]
anaeem1 has joined #jruby
<headius>
chrisseaton: I forgot to tag the new specs that came in for truffle, and I can't do it now...you might see this before I get a chance, so if you please....
<headius>
FNM_EXTGLOB stuff
tcrawley is now known as tcrawley-away
x1337807x has joined #jruby
subbu has joined #jruby
calavera has joined #jruby
havenwood has quit [Remote host closed the connection]
noop has joined #jruby
rcvalle has quit [Quit: rcvalle]
noop has quit [Ping timeout: 264 seconds]
subbu has quit [Ping timeout: 245 seconds]
tenderlove has quit [Remote host closed the connection]
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
tenderlove has joined #jruby
tenderlove has quit [Remote host closed the connection]
tenderlove has joined #jruby
nateberkopec has quit [Quit: Leaving...]
Hobogrammer has quit [Read error: Connection reset by peer]
calavera has joined #jruby
robbyoconnor has joined #jruby
deobalds has joined #jruby
Hobogrammer has joined #jruby
rsim has joined #jruby
byteit101 has quit [Remote host closed the connection]
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius>
I can think of no way to fix ext loading to work with an absolute path
<bbrowning>
yeah I can't think of anything that would work in all cases other than trying all package permutations, which is gross
<bbrowning>
matching the absolute path up to a $LOAD_PATH entry and subtracting off the load path may work for the rubygems case, but that's also a bit gross
skade has quit [Remote host closed the connection]
<headius>
that's still a ton of work to do too
<headius>
in both cases
<headius>
well shucks
<bbrowning>
obviously the easiest thing is to get rubygems to revert this specific change
<bbrowning>
and might be good to get java extension authors to move to a more robust method of loading their extension
<headius>
we need to design a more robust method of loading their extension first
tenderlove has quit [Remote host closed the connection]
<headius>
manifest entry?
<bbrowning>
not all extensions use *Service, right?
tenderlove has joined #jruby
<headius>
they use *Service or they use JI to boot a specific class
<headius>
that's the only options currently
<bbrowning>
yeah
<bbrowning>
java has a way to do stuff like this iirc - service loader mechanism or something?
<headius>
yeah, but I'm not sure any of that really applies
<headius>
all we need is a way to know what class to boot in the jar
<bbrowning>
right
<headius>
I think manifest is the right way to go
<bbrowning>
some convention - manifest entry like you said, or some file in META-INF/
<headius>
JRuby-Extension: NokogiriService
<headius>
though...hmmm
<headius>
specific file is tricky because we'd have to manually walk jar to get it before loading into classloader
<headius>
otherwise we could get someone else's copy of that file
<headius>
we have to do some of that anyway for manifest
<headius>
manifest may complicate building the jar too much
<headius>
need to maintain a manifest file and add a jar flag however the build is doing that
<bbrowning>
headius: do we know the list of files in the jar at this point? could we just look at all files named *Service? :D
<headius>
hahah
<headius>
yeah, O(n) scan of all jar contents
<headius>
it would "work"
<bbrowning>
well I didn't know if we already had an index of its contents
<bbrowning>
headius: the only problem is of course getting all java extension gems to add that to their manifest
<bbrowning>
over time, sure, but for 1.7.18?
<headius>
yep, that's a problem
<headius>
the new ext mechanism can be added alongside the service mechanism, but the libs have to be rebuilt
<headius>
bugger
tlarevo has joined #jruby
skade has joined #jruby
djbender has left #jruby [#jruby]
johnmuhl has quit [Quit: Connection closed for inactivity]
skade has quit [Remote host closed the connection]
havenwood has joined #jruby
elux has joined #jruby
camlow325 has joined #jruby
teo- has joined #jruby
e_dub has quit [Quit: e_dub]
Aethenelle has joined #jruby
calavera has joined #jruby
anaeem1_ has joined #jruby
diegoviola has joined #jruby
diegoviola has quit [Client Quit]
<bbrowning>
headius: here's a silly idea - with the new rubygems, the require path comes in for the nokogiri jar like "/home/bbrowning/src/torquebox3/integration-tests/target/rubygems-test/gems/nokogiri-1.5.3-java/lib/nokogiri/nokogiri"
diegoviola has joined #jruby
<bbrowning>
that's when nokogiri's ruby code does require "nokogiri/nokogiri"
<bbrowning>
what if we just look for "/lib/" as part of the path and strip it and everything before it off, only after trying the path as-given
skade has joined #jruby
<bbrowning>
basically when we catch the ClassNotFoundException look for lib in the path, strip all that out, and try again?
<bbrowning>
building a new className of course, based on the new path
<headius>
bbrowning: we'd have to look for at least lib and ext
<bbrowning>
would we? hmm
<bbrowning>
foo-gem/lib and foo-gem/ext both get added to $LOAD_PATH?
<bbrowning>
I guess this method would only catch the cases where the previous relative require was relative to the default foo-gem/lib load path
<bbrowning>
if a gem was adding something to the load path then doing a relative require to find its java extension this would still break
<headius>
bbrowning: a gem can put it anywhere
<headius>
ext is probably as common as lib
<bbrowning>
but the require statement that was working before only works when the .jar is found relative to some load path entry, right?
<bbrowning>
headius: does jruby have any rubygems patches? what about just patching the one problematic line? :)
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] vladson opened issue #2337: Is there a way to declare `java_field` with interface type? http://git.io/iWYD4Q
JRubyGithub has left #jruby [#jruby]
vtunka has quit [Quit: Leaving]
<headius>
bbrowning: no, we got rid of that because people and installers want to upgrade on their own
<headius>
got rid of our patching I mean
<bbrowning>
ahh
<Aethenelle>
w/ prepend working, we could monkey patch it without much of a problem to add the functionality needed...
<headius>
enebo: if we still want to get .18 out today I can go back to 2.4.4
<enebo>
headius: I believe we should do that regardless
<headius>
ok
<enebo>
headius: but he have a second unresolved issue now
<enebo>
headius: someone emailed on ubuntu and native is not loading
<headius>
omg, yosemite is pissing me off
<enebo>
headius: I suspect it is install without libcrypt
<headius>
ugh
<enebo>
headius: I did test on ubuntu so I don’t know…wfm. but if that is the issue I may need to add optional loading support to libffi or build some one at a time thing for jnr-posix
<headius>
travis is ubuntu
<enebo>
headius: yeah I am betting this is not something most ubuntu users are seeing since I also tested on it
<enebo>
headius: but they had no issue on 1.7.16 and it started in 1.7.17
<enebo>
ppid
<enebo>
which should not really be an issue unless posix did not load
<enebo>
so regressionish
<headius>
this was on ML?
<enebo>
tough to know
<enebo>
yeah
<headius>
do we have an open issue?
<enebo>
I asked for more details but we do not have an issue open
<enebo>
IT could be that the person comes back and says something like, oh we had no space on /tmp
<headius>
yeah, I don't see anything actionable ight now
<headius>
right
<enebo>
headius: so I am hoping to hear something but I think this potentially could be a big problem if it is real
<headius>
indeed
<headius>
back to the RG issue
<headius>
we could try up to N trailing elements of the path
<headius>
and copy the fix on master that looks up .class resourcse rather than triggering CNFE
<bbrowning>
the only downside is we'd try N trailing elements for every .jar that gets loaded, whether it has an extension or not?
<bbrowning>
since we don't know at this point
<headius>
yes
<headius>
that complexity mixed with the resource fix may still end up faster than old logic with CNFE
<headius>
but we're also guessing at the path
<headius>
maybe someone has lib/my/library/with/many/deep/nested/paths/before/myext.jar
<bbrowning>
yeah
<headius>
damn Service model, I never should have done that
<headius>
we could also limit this to only when the path is absolute
<bbrowning>
if we go that route, we can also know to chop off quite a few of the front bits of the package name, right? ie home.bbrowning.src.torquebox3.integration-tests.target.rubygems-test.gems.nokogiri-1.5.3-java.lib.nokogiri.NokogiriService
<bbrowning>
can we be smart enough to know that everything up-to-and-including "nokogiri-1.5.3-java" doesn't have to be looked at?
e_dub has joined #jruby
<bbrowning>
so now we just have lib.nokogiri.NokogiriService, nokogiri.NokogiriService, and NokogiriService to try
mcclurmc has quit [Remote host closed the connection]
mcclurmc has joined #jruby
skade has quit [Remote host closed the connection]
<headius>
oh yeah
<headius>
- isn't a valid class or package naming character
skade has joined #jruby
<bbrowning>
will every gem containing a jar with a java extension be a -java gem?
<bbrowning>
or do some people publish a single gem that has both java and native extensions? is that even possible?
<headius>
bbrowning: they don't have to be
<headius>
they should, but they don't have to
<bbrowning>
k
<headius>
but the version number will always be there
<bbrowning>
ahh true
<bbrowning>
so that lets you immediately get down to just the paths inside the gem itself
<headius>
and if it isn't, it's not loading through RubyGems so we're ok?
<bbrowning>
headius: I think so, yes
<bbrowning>
I've never seen a gem without a version number, at least.
<headius>
so if we look for absolute path and then only scan until we see invalid package/class characters, it will work
<headius>
and if we start with single trailing element first, most exts out there will load immediately anyway
<bbrowning>
yeah
<headius>
what a hack :-( we need to get a new mechanism into 1.7 and 9k ASAP so we can start to deprecate the old way
<headius>
I'm still leaning toward manifest, and if nobody gives me a good reason not do I'll probably go with it
<headius>
enebo: how does that sound?
<headius>
not manifest, the hacky fix
bbrowning is now known as bbrowning_away
<enebo>
Explain it again
<headius>
explain it to you like you're 5?
yfeldblum has joined #jruby
yfeldblum has quit [Remote host closed the connection]
<headius>
when a mommy and a daddy love each other VERY much
<enebo>
well I don’t know if I ever seen you explain anything to a 5 year old…tell me how you would do that?
yfeldblum has joined #jruby
<headius>
very carefully
<headius>
so here's the thing
<enebo>
ok perfect
<headius>
if it's not an absolute path, none of this matters
<headius>
we can detect that
<headius>
if it is an absolute path, we can walk back from end trying trailing path segments as package+class for service
pietr0 has joined #jruby
<enebo>
since the jar is on the LOADPATH
<headius>
well, we have the original require line
<headius>
that's what we look at
<headius>
that passes through into the loader stuff
<headius>
the only cases we know of where someone might end up doing a require of a full path to an ext is this RG thing
<headius>
normally they're going to do it relative, because it would not have worked before with full path
<headius>
SO
<headius>
the path is almost always going to have a - in it for the gem version, so we'd never end up walking higher than the gems dir
<headius>
ya dig?
<enebo>
yeah I guess so since this is in a gem
skade has quit [Remote host closed the connection]
<enebo>
I don’t know of any gem which wouldn’t I guess
<headius>
I will do an experiment to see how much it costs to try N different .class resource lookups
<enebo>
unless someone is doing something weird in a private gem server
<headius>
it would have to be really weird
<headius>
so given that this currently only affects gems and only happens when the require name is an absolute path, I don't think we need to cap the number of segments we try
<enebo>
ok. I guess my main concern would largely just be speed as you saw we already routinely throw often enough already
<headius>
we won't throw at all because I'll pull in the fix from master
<headius>
we'll do N getResource(segments + .class)
<enebo>
ah ok well so we have some budget though
<headius>
that should still be cheaper than even one CNFE
<headius>
right
<enebo>
I am trying to think if you can accidentally find the wrong class
<headius>
yeah, I'm wondering that too
<enebo>
Does this still need to end in Service?
<headius>
most of the time the ext is going to be only one segment down
<headius>
some will be two or three
<headius>
it does
<enebo>
That does limit things quite a lot
<headius>
this is basically an "enhancement" of the Service ext model
<enebo>
but it is not a super uncommon name
<headius>
and since we'll go from no package to one package element to two package elements...unlikely we'll walk into someone else's namespace
skade has joined #jruby
<enebo>
unfortunately finding a resource and knowing what it actually is is not possible
mcclurmc has quit [Remote host closed the connection]
<headius>
right
<enebo>
I guess if you make native gem and happen to have a FooService for the Foo ext which is not the ext class you deserve it
<headius>
so at that point we try to load and it may LinkageError or not extend from Service or whatever
<headius>
right
<headius>
I think this will work ok even though it sucks nuts
<enebo>
headius: I don’t think we should keep trying in that case
<enebo>
headius: we probably could but that sucks even more nuts
mcclurmc has joined #jruby
colinsurprenant has quit [Quit: colinsurprenant]
<headius>
fine with me
<headius>
if it actually impacts someone we'll hear about it and tell them not to do that
<headius>
because they're the 1%
nateberkope has joined #jruby
<headius>
I guess I will hack this BS together
<headius>
we might as well get a release out that supports latest RG
<enebo>
yeah
<enebo>
and we can at least make sure things like nokogiri load :)
nateberkopec has quit [Ping timeout: 255 seconds]
<headius>
yes
skade has quit [Remote host closed the connection]
<headius>
enebo: mkristian believes jruby-openssl is ready to release
<enebo>
heh
<headius>
have faith, brother enebo
<enebo>
well if we release it then I think it should be bundled as part of release too
<enebo>
but it does make me want some more testing
bbrowning_away is now known as bbrowning
colinsurprenant has joined #jruby
mcclurmc has quit [Remote host closed the connection]
<headius>
yeah, agree on both counts...so maybe bump back another day to fix RG ext loading and get jruby-openssl out
<enebo>
headius: and give some time to know about ubuntu issue
<enebo>
headius: I could speculatively implement soft loading in jffi but I would rather not :)
skade has joined #jruby
havenwood has quit [Remote host closed the connection]
<headius>
ok
englishm_ is now known as englishm
englishm has joined #jruby
englishm has quit [Changing host]
mcclurmc has joined #jruby
camlow32_ has joined #jruby
mcclurmc has quit [Remote host closed the connection]
<tarcieri>
headius: if you want jruby-openssl tested, just ask Square, lol
camlow32_ has quit [Remote host closed the connection]
phrinx has joined #jruby
djellemah has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 1 new commit to master: http://git.io/AdrUYA
<JRubyGithub>
jruby/master 40ba655 Kevin Menard: [Truffle] Removed Math.floor and Math.ceil calls since JVM truncation seems to provide the same semantics.
JRubyGithub has left #jruby [#jruby]
camlow325 has joined #jruby
e_dub has quit [Quit: e_dub]
<headius>
tarcieri: hey, if you're offering, we can give you a prerelease gem
e_dub has joined #jruby
<tarcieri>
headius: I'm OoO today, but if you do spin one I can point some Squares at it
yfeldblum has quit [Ping timeout: 240 seconds]
<tarcieri>
I know they had some things they wanted to get upstream
<tarcieri>
I think they did?
e_dub has quit [Client Quit]
josh-k has quit [Remote host closed the connection]
tlarevo has quit []
<headius>
ok
<headius>
tarcieri: I'm not sure...upstream into jossl or jruby?
<headius>
bbrowning: how can I reproduce the RG issue?
Hobogrammer has joined #jruby
<bbrowning>
headius: I linked to a way to reproduce the absolute path extension failure in the issue
<headius>
ok cool
<bbrowning>
it doesn't actually use rubygems directly though - just loads using an absolute path like rubygems does
<bbrowning>
uses your atomic gem as an example
havenwood has joined #jruby
Hobogrammer_ has joined #jruby
Hobogrammer_ has quit [Client Quit]
<headius>
ok
<headius>
absolute paths work
<headius>
relative paths work
<headius>
zing, first time
<bbrowning>
yay!
<bbrowning>
although, as that test script is written, I just realized that if absolute paths work then it will print that relative paths also work
<bbrowning>
but they should still work if you're checking for absolute paths before doing new logic
marr has quit [Remote host closed the connection]
<bbrowning>
I can build jruby and run the TB build against this to verify, since it's where the breakage was first found
marr has joined #jruby
anaeem1_ has quit [Remote host closed the connection]
<headius>
yeah ok, I'm refining this now
yfeldblum has joined #jruby
bbrowning is now known as bbrowning_away
yfeldblum has quit [Remote host closed the connection]
kotk_ has joined #jruby
pietr0_ has joined #jruby
chrisseaton_ has joined #jruby
multibot__ has joined #jruby
r0bby_ has joined #jruby
zacts has joined #jruby
qmx_ has joined #jruby
dbussink_ has joined #jruby
<chrisseaton_>
we don't have the RubySpec specs for core libraries in JRuby do we? As in the ones that are currently in rubysl (not sure if they were ever actually in RubySpec). Is there a reason for that? Or just not got around to importing them?
pietr0 has quit [Ping timeout: 244 seconds]
multibot_ has quit [Ping timeout: 244 seconds]
dbussink has quit [Ping timeout: 244 seconds]
chrisseaton has quit [Ping timeout: 244 seconds]
kotk has quit [Ping timeout: 244 seconds]
diegoviola has quit [Ping timeout: 244 seconds]
jimbaker has quit [Ping timeout: 244 seconds]
kith has quit [Ping timeout: 244 seconds]
qmx has quit [Ping timeout: 244 seconds]
robbyoconnor has quit [Ping timeout: 244 seconds]
vpereira has quit [Ping timeout: 244 seconds]
vpereira has joined #jruby
pietr0_ is now known as pietr0
qmx_ is now known as qmx
dbussink_ is now known as dbussink
vpereira has quit [Changing host]
vpereira has joined #jruby
chrisseaton_ is now known as chrisseaton
jimbaker has joined #jruby
jimbaker has quit [Changing host]
jimbaker has joined #jruby
<headius>
chrisseaton: those are called standard libraries, and no we don't
<headius>
they used to live in rubyspec but now all the library specs have been moved into their rubysl projects
<headius>
// avoid blank elements from leading or double slashes
<headius>
if (elts[firstElement + offset].isEmpty()) continue;
<enebo>
ah yeah nice
<headius>
that will catch absolutized paths with // in them
<headius>
it didn't before
<enebo>
since you didn’t write this do change that for loop
<enebo>
Or I suspect it changed at some point where j needed to be both zero and +firstElement
<headius>
this logic passes bbrowning_away's test
<headius>
I changed it to offset
<enebo>
I keep staring at that loop and itching
<headius>
it looks better
<headius>
I'm going to run -Ptest at least and push
<enebo>
int j = offset?
<nirvdrum>
enebo: Making count and tr shareable is kinda ugly. I'm going to escalate visibility of a few fields in the interim. But I'd appreciate review of the commits once I have them up. If you'd prefer, I can do this one as a PR.
<headius>
int offset = firstElement; (firstElement + offset) < ....
<enebo>
firstElement + offset can go away
<enebo>
offset < length - 1
r0bby_ has quit [Quit: Konversation terminated!]
<headius>
oh sorry
<headius>
offset is 0
<headius>
I see what you're saying
<enebo>
heh ok…yeah the 0 was my complaint
<headius>
I thought you didn't like the name :-)
<enebo>
j is something common enough where I don’t complain
skade has quit [Quit: Computer has gone to sleep.]
<headius>
ok
<enebo>
I feel like I wasted both of our times since it is sooo unimportant :)
<headius>
hey, might as well do it right
<enebo>
I could have just corrected it after the commit
<headius>
yeah, whiner
<enebo>
-m HEADIUS!
diegovio1 is now known as diegoviola
<enebo>
asarih: sorry I missed your statement until now
<headius>
updated gist with doco and changes
<asarih>
enebo: no worries
<enebo>
asarih: So I should be asking you want we need to include this
<enebo>
asarih: he just defined some static Strings
diegoviola has quit [Quit: WeeChat 1.0.1]
<enebo>
nirvdrum: You can just commit unless it makes you feel dirty enough to want someone else look and then a PR is fine
<nirvdrum>
Tests are passing.
<nirvdrum>
All of this stuff is dirty :-)
<nirvdrum>
And most of it is fairly old.
<enebo>
nirvdrum: we don’t mind looknig at PRs. It is a matter of confidence. If you feel in doubt ever just make a PR
<enebo>
headius: Since I have been whining…make those appends one line :)
<headius>
no :-)
<headius>
they get too long for me to parse quickly
<nirvdrum>
I'm fairly confident. The tests pass. I'm using automated tools. I'm committing incrementally. But to the casual observer, it's going to look like I changed a lot more than I really did.
<headius>
enebo: I did it after I almost forgot one of the trailing appends
<enebo>
heh
<enebo>
geez :)
zacts has quit [Quit: leaving]
<nirvdrum>
I have a newfound appreciation for what you guys have done over the past decade :-P
anaeem1 has joined #jruby
triple_b has joined #jruby
<enebo>
headius: If this is built with / instead of . won’t it sometimes never need to rewrite the string when it finds it as a resource right away?
<asarih>
enebo: I meant, implementing these ciphers.
<headius>
that's true
<headius>
asarih: I don't know how we "support" them...I am guessing we have a list
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<asarih>
some ciphers are not available for creating TLS connections.
<headius>
bleh, why isn't there String.isJavaIdentifier
<headius>
there's only the character versions
<enebo>
asarih: I am confused though he implies many of these are part of Java 7/8 so is this about providing an impl or just hooking up existing impls somehow?
<asarih>
enebo: not sure about the actual implementation of jruby-openssl.
<headius>
asarih: we do not know what we are *not* doing
<asarih>
what we are *not* doing is using those more recent ciphers usable.
<enebo>
asarih: actually nahi’s tweet also confuses me. Is he saying what we have was ported from openssl and these new ones need to be ported or they were already ported
<enebo>
ignoring whatever he meant about mozilla :)
<asarih>
my guess is the former.
havenn has joined #jruby
<enebo>
asarih: ah well that is some amount of work I have no idea about then. I wonder who did it? Ola?
<asarih>
I would look at openssl source to see what ciphers are there now, but openssl.org seems down at the moment.
<asarih>
enebo: Ola, I bet.
<enebo>
yeah a looooong time ago
<enebo>
asarih: I think porting like 50 more ciphers is not going to be done any time soon but perhaps there is a much smaller number of common ones
havenwood has quit [Ping timeout: 250 seconds]
havenn is now known as havenwood
<enebo>
asarih: well of course if someone had the interest porting them all would be great but from a priority perspective I think more people would rather have 9000 out than thse supported
<asarih>
enebo: agreed.
<asarih>
enebo: I was just wondering if it's quick, or you remembered anything. :-D
<enebo>
asarih: but we try and support stuff as much as we can and still work on 9000 so perhaps we can do something? I don’t know though. Things are backing up :)
<enebo>
asarih: yeah I actually am freaked they were all hand ported from C with unsigned math to Java :)
<enebo>
asarih: ola was probably in a red bull and cocaine-induced trance when he ported all that
<headius>
bbiab, comcast
<enebo>
headius: so you hope
<headius>
they said between 10 and 12, so 2 is about what I expected
<headius>
they did call though...guy got bogged down in a job, they just issued a different guy that will be here in 15
<asarih>
enebo: we should send him more Red Bulls.
<headius>
RBDD
<enebo>
asarih: The issue report does imply Java has these somewhere though
<enebo>
asarih: hmmm perhaps we can integrate jruby-openssl to these providers
codefinger has joined #jruby
<headius>
huh, dragon ball and dbz are on hulu plus
<enebo>
asarih: but I have zero idea
<headius>
quality looks pretty good too
<enebo>
headius: censored or uncensored…that is the question
<asarih>
enebo: that's exactly how much clue I have, too.
<headius>
uncensored
<enebo>
w00t
<headius>
japanese + eng sub only though
<enebo>
asarih: I suggest opening this on jruby-openssl since kares and others might take more interest
<asarih>
"It's over 8000!"
<asarih>
enebo: kk.
<headius>
bbrowning_away: test
<headius>
er
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to jruby-1_7: http://git.io/dglFig
<JRubyGithub>
jruby/jruby-1_7 a0624ee Charles Oliver Nutter: Rework service lookup to allow absolute paths. Fixes #2336.
JRubyGithub has left #jruby [#jruby]
<asarih>
8000以上だ！
<headius>
bbrowning_away: test this please ^
<headius>
really bbiab now
<enebo>
asarih: although kares said he will not have any time until early next year to spend on it
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] BanzaiMan pushed 1 new commit to jruby-1_7: http://git.io/i02v2Q
<JRubyGithub>
jruby/jruby-1_7 38d064f Hiro Asari: Move jobs to container-based infrastructure
JRubyGithub has left #jruby [#jruby]
e_dub has joined #jruby
bbrowning_away is now known as bbrowning
mcclurmc has quit [Remote host closed the connection]
<bbrowning>
headius: testing now
anaeem1 has quit [Remote host closed the connection]
mcclurmc has joined #jruby
mcclurmc has quit [Remote host closed the connection]
rcvalle has quit [Quit: rcvalle]
subbu|lunch is now known as subbu
mcclurmc has joined #jruby
<bbrowning>
headius: with your change I get past that point in the TB build but then it dies during one of the integs with a stack level too deep error I have to figure out
<bbrowning>
looks unrelated to your change though - something coming out of drb of all places
<headius>
you need to renegotiate, this is the standard $109 package now
<headius>
I feel like I need to download something now
<bbrowning>
rm -rf ~/.m2/repository
<bbrowning>
and then build something ;)
<headius>
oh hey, xcode update
<headius>
ahh yeah, that would work too :-)
<headius>
12 minutes to download 2.46GB...I can live with that
subbu has joined #jruby
<enebo>
headius: yeah we were offered it a while back with no price change but we had to agree to two more years with them
<enebo>
headius: and perhaps we should do it since I see nothing over the horizon but it was weird…just upgrade us amirite?
codefinger has quit [Quit: Leaving...]
diegoviola has joined #jruby
<headius>
yeah I am on the two-year thing to get free install
<headius>
if this is as stable as it sounds I don't see it changing until I move or die
djellemah has quit [Ping timeout: 272 seconds]
<bbrowning>
headius: I have no idea what's up with my stack level too deep stuff - notning obvious is jumping out and the stack trace it spits out is definitely not too deep
<bbrowning>
I probably won't be able to figure it out today - it could be something to do with the rubygems update again, it could be something else - who knows at this point
<bbrowning>
hmm I can turn debug logging on to see more perhaps
mcclurmc has quit [Remote host closed the connection]
bbrowning is now known as bbrowning_away
mcclurmc has joined #jruby
multibot__ has quit [Read error: Connection reset by peer]
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
diegoviola has quit [Ping timeout: 256 seconds]
<mkristian>
enebo, headius can I go ahead and push the jruby-openssl-0.9.6.gem to rubygems.org ?
mcclurmc has quit [Remote host closed the connection]
<enebo>
mkristian: I have not been involved with it but it sounds like headius was happy with it for release
mcclurmc has joined #jruby
<mkristian>
enebo, just wanted to make sure there are no new issues or so.
<enebo>
mkristian: yeah I guess I cannot answer that directly
djellemah has joined #jruby
diegovio1 is now known as diegoviola
<mkristian>
enebo, since kares was OK with it, travis was green - guess that is enough then.
<enebo>
mkristian: yeah we can always put out another one too
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 1 new commit to truffle-head: http://git.io/Q7x93w
<JRubyGithub>
jruby/truffle-head 8b16e6b Chris Seaton: Merge branch 'master' into truffle-head...
JRubyGithub has left #jruby [#jruby]
SynrG has quit [Read error: Connection reset by peer]
<headius>
mkristian: yeah, go for it
<headius>
mkristian: 1.7.18 is pushed to monday to accommodate these last issues, and tarcieri has offered to have some folks at Square test jossl 0.9.6 for us
<headius>
I think it's just as well we go ahead and release it, since we can always rev again if there's something we missed
SynrG has joined #jruby
<mkristian>
headius, it would be anyways nice to have the gem released a while and then include it to jruby-1.7.19 or so - as far I understood kares
<headius>
enebo was hoping to put it in 1.7.18, but if we don't get enough verification that's probably not a good idea
mister_solo has joined #jruby
<headius>
we've been doing well knocking down regressions
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian pushed 2 new commits to master: http://git.io/o7bowg
<JRubyGithub>
jruby/master 58a493a Christian Meier: Merge branch 'test-jossl-0.9.6-master'
<JRubyGithub>
jruby/master 5fb1882 Christian Meier: use jruby-openssl-0.9.6
<headius>
hmm, was there anything else I planned on doing today
camlow325 has joined #jruby
<nirvdrum>
headius: Although if you're that worried about class file compatibility, my refactorings are probably going to cause heartache for someone.
<headius>
yeah I know
Neomex has joined #jruby
<headius>
9k will cause some heartache
<nirvdrum>
I guess the open question is where's the line?
<headius>
I suspect 9k.1 will add some critical items back
<headius>
there aren't that many JRuby exts out there
<headius>
embedders might be going at those APIs directly, but we'll deal with it on a case-by-case basis
<headius>
that's my position, anyway
<nirvdrum>
Also, in lieu of an annotation, would it be worthwhile to create some package that indicates the classes in there shouldn't be relied upon? "private", "internal", or "unsafe" maybe?
camlow325 has quit [Remote host closed the connection]
<nirvdrum>
headius: Finally, any update on that C1 crash?
<headius>
I suggest we just add @API right now and use it
<headius>
re C1 crash: I need to file a bug in openjdk bug tracker, but my account is not working...need to get mreinhold to fix it for me
<nirvdrum>
enebo: I think this was intended to make it clear that some things are public simply for convenience rather than an API that could or should be relied upon.
mkristian has quit [Quit: bye]
<enebo>
nirvdrum: ah ok well I am cool with there being those too
<enebo>
nirvdrum: but this was intended for telling native extension authors what it supported
<nirvdrum>
I wouldn't be surprised if you have people just embedding the lib jar and expecting that to never change.
<enebo>
nirvdrum: but more restrictive annos saying it is public but we definitely do not want you using it is fine as well
<enebo>
nirvdrum: @Extension is nice because we can use it to generate blessed API docs
<enebo>
@internal is nice in a linting tool to say do not use this in jrlint
<multibot_>
Unknown command, try @list
<headius>
I'd rather whitelist the API than blacklist
<enebo>
bah :)
<enebo>
well I want whitelist specifically to generate docs
<enebo>
but blacklist might still give someone a clue while we fill out this API we know we don’t want people using it
x1337807x has quit [Ping timeout: 245 seconds]
<enebo>
blacklist would be more for us than them
<enebo>
but it would have added benefit of an extra red warning in lint tool
<Aethenelle>
enebo: couldn't that also be accomplished by a whitelist?
<enebo>
headius: blacklisting just means supporting shit you forgot to blacklist before a release
<enebo>
Aethenelle: yeah definitely so long as you review every method we have the in 200,000 lines of our source
x1337807x has joined #jruby
<enebo>
I suggest whitelist is our goal but that adding a blacklist won’t hurt the goal of making a whitelist
<enebo>
with that said I was just going to only add @Extension and slowly fill that out over time
<Aethenelle>
so it sounds like both approaches are needed for now.
<enebo>
Anthing not on it is potentially black
<enebo>
but adding definitely black does not sound horrible to me
<enebo>
we would at least know someone finds the method as not a candidate to be part of embedding API
<enebo>
If someone could write a Java API tool to tell us every method a Java jar is using of ours this would be much simpler in figuring out everything too
<enebo>
I am really surprised one doesn’t exist
<enebo>
I have not found it yet though
<Aethenelle>
there are no call graph tools for Java?
<nirvdrum>
That's essentially what proguard does.
<nirvdrum>
Or any of the obfuscation tools.
<enebo>
Aethenelle: I think there are some for purposes of finding coding mistakes but I am not aware of one which you can give it a package and say spit out all users
<enebo>
nirvdrum: Can we simply run nokogiri.jar through something like proguard and get all the org.jruby.* methods called?
<enebo>
and by simply I mean a little time to make a definition to do that sort of thing?
<Aethenelle>
anything that'll dump the relationships as text will work really...
<nirvdrum>
I'd imagine so. But I say that with knowing next to nothing of its internals. I've just used it in the past to reduce JARs down to the stuff I actually use. E.g., https://github.com/mogotest/localtunnel-jvm-client reduces down to just the parts of scala's stdlib I actually use.
<nirvdrum>
The practice is fairly common with Android devs, too, since they have much harder constraints.
<enebo>
neat
<nirvdrum>
It does get tripped up over reflection.