<bbrowning>
enebo: hmm TB build failed during part of its build w/ 1.7.18-SNAPSHOT - let me roll back to 1.7.17 and make sure it's actually jruby at fault here and not some other external thing
subbu|away is now known as subbu
<bbrowning>
the failure was "Gem::LoadError: Could not find 'builder' (= 3.0.0) among 38 total gem(s)" which is odd, since I see the gem there in the directory it's looking in
lanceball is now known as lance|afk
<bbrowning>
any changes around gem loading, file loading, etc between 1.7.17 and 1.7.18?
<enebo>
bbrowning: I don’t know offhand
<enebo>
bbrowning: we fixed a bunch of things in a flurry a week ago
<bbrowning>
if it fails under 1.7.17 then I'll know it's something else creeping in - will know that in a bit
<nirvdrum>
Just a friendly reminder than commit messages like "Fix #xyz" are annoying when not viewed through github, since they require a cross-reference to get any semantic meaning out of it. :-/
<enebo>
nirvdrum: yeah sorry I realized that after I did it
<nirvdrum>
locks: Can a MatchData's values ever be anything other than a string?
<nirvdrum>
lopex: ^
<nirvdrum>
Sorry locks.
<enebo>
nirvdrum: I normally paste the description after that but I was in a hurry
benweint has joined #jruby
<nirvdrum>
enebo: No worries. But we had to play out the entire scenario.
<enebo>
then I felt guilty :)
<nirvdrum>
At least you didn't force push to fix it :-P
<enebo>
nirvdrum: yeah that is never my style :P
<enebo>
so jvisualvm lies on heap graphs
<enebo>
sometims the heap graph is like 1/3 of actual heap dump and sometimes it isn’t
<nirvdrum>
Retained vs total?
<enebo>
Used in the graph I guess I mean
<enebo>
vs what sample histogram says
<bbrowning>
enebo: TB3 built fine w/ jruby 1.7.17 - trying 1.7.18-SNAPSHOT again just to be sure I can reproduce
dyer|away is now known as dyer
<enebo>
I might expect the sample histogram to be less accurate but the thing is once in every 4-5 connects the heap used graph does show triple the heap used
<enebo>
bbrowning: If so then either a reduction or a bisect would be great.
<bbrowning>
yeah
zorak8 has joined #jruby
<enebo>
I think there was a change to LOAD_PATH normalization
<bbrowning>
hopefully I can reproduce outside of TB since it's almost the last step in our build that fails :/
<bbrowning>
although if the build fails I'm sure some integration tests would fail as well
shellac has joined #jruby
<enebo>
bbrowning: :|
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian pushed 1 new commit to test-jossl-0.9.6-master: http://git.io/-rHBaQ
<JRubyGithub>
jruby/master 61f745e Thomas E. Enebo: Make global TemporaryVariableCache to dramatically reduce allocation of this highly repetitive immutable object
JRubyGithub has left #jruby [#jruby]
camlow325 has joined #jruby
benweint has quit [Quit: Computer has gone to sleep.]
mcclurmc has joined #jruby
tenderlove has quit [Remote host closed the connection]
tenderlove has joined #jruby
<headius>
enebo: you weren't looking at one generation, were you?
tenderlove has quit [Remote host closed the connection]
tenderlove has joined #jruby
<nirvdrum>
That looks like a big savings.
elia has quit [Quit: Computer has gone to sleep.]
<rtyler>
chrisseaton: ping
subbu|breakfast is now known as subbu
<headius>
enebo: have you incorporated anything from my branch? I knocked off the top several items in an allocation trace
<headius>
enebo: unrelated...I am tempted to fix this File.realpath classpath: bug by just inserting a check for classpath: that returns it as-is
<enebo>
headius: I almost all were things to directed graph right?
<headius>
enebo: no, many to IR itself
elia has joined #jruby
shellac has quit [Read error: Connection reset by peer]
<headius>
I tried to keep them separate commits
<enebo>
headius: I will reexamine. I have not touched some larger items at all yet like deleting pass data
<headius>
ok
<headius>
yeah the logic for JIT to dump that stuff is there too
<headius>
but that doesn't really help in general
<enebo>
That will mostly add up once a lot of things JIT
<enebo>
so it will not show up as much early
<headius>
right
<headius>
so not useful for test run OOM for example
mcclurmc has quit [Remote host closed the connection]
djellemah has quit [Quit: Leaving]
subbu is now known as subbu|away
tenderlove has quit [Remote host closed the connection]
<nirvdrum>
headius: It looks like IO.popen4 was removed in 9k. That broke a couple gems I maintain. Is there a recommended replacement?
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 1 new commit to master: http://git.io/cfNo4Q
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
jruby/master 6658212 Kevin Menard: [Truffle] Allow blocks to be passed to String#scan.
<bbrowning>
nirvdrum: That hit me as well. I tried to replace with Open3.popen3, but that failed because there's some kind of bug around the pid not being populated from the returned io objects
<bbrowning>
that reminds me I need to reproduce and file a bug on that
elia has quit [Ping timeout: 258 seconds]
<rtyler>
bheck the backlog, there's already a open3 bug or two in there
<bbrowning>
cool
<bbrowning>
there are also a few tests excluded that would show this bug as well
<nirvdrum>
I don't recall what the differences between open3 and open4 off-hand, but I think one was getting access to stdout and stderr as independent streams.
<nirvdrum>
It certainly seems to happen more frequently then.
<asarih>
headius: not sure. it was a long time ago.
<headius>
asarih: thank you, that's very useful
anaeem1_ has quit [Remote host closed the connection]
<nirvdrum>
The jamesgolick one is a bunch of patches he wrote. Like how there was a "falcon" one at one point, I believe.
anaeem1_ has joined #jruby
<headius>
and last question, or suggestion really: it would be nice if the build list showed elapsed *realtime* rather than aggregate job time
anaeem1_ has quit [Remote host closed the connection]
<headius>
e.g. so I can tell how long it's actually taking to complete all jobs
<nirvdrum>
enebo: If you think it's a Truffle quirk, I can start tracing more on my end.
<enebo>
nirvdrum: well I definitely introduced something unexpected removing the bogus scope from simple evals. We end up with a completely empty context stack now. In a sense this makes sense since shutdown hooks run after script has ran off the edge (meaning scripts scope would be gone). This is something wrong with how we implement shutfown hooks and has always been wrong
<headius>
right now it looks really weird...
<headius>
ran for 5 hrs 52 min 24 sec
<headius>
6 minutes ago
bbrowning_away is now known as bbrowning
camlow325 has quit [Remote host closed the connection]
<headius>
and it was not started 5 hours ago
<enebo>
nirvdrum: I think we never saw the issue I worked around because we were stuff extra scopes
<enebo>
nirvdrum: but why this would affect truffle I don’t know since I have not see those errors at all locally
<bbrowning>
enebo: headius: so, it looks like the update to rubygems 2.4.5 is the culprit for TB build failures w/ 1.7.18-SNAPSHOT
<enebo>
nirvdrum: The backtrace itself almost insinuates getCurrentContext has never ever been run and initialized fiber via adoptThread
<bbrowning>
before rubygems 2.4.5 jruby was on 2.1.9?
<enebo>
nirvdrum: but that makes no sense to me
<enebo>
bbrowning: correct
<bbrowning>
hmm now to see what all they changed
<bbrowning>
but it makes sense, since my error is around installing a gem
<enebo>
bbrowning: :|
<bbrowning>
I can sometimes get around that error and then get an error from the nokogiri gem before integs start
mister_solo has joined #jruby
<bbrowning>
so two gem-related errors
mister_s_ has joined #jruby
camlow325 has joined #jruby
<enebo>
nirvdrum: doRunFromMain shutdowns TruffleBridge before the finalizers run. I don’t know how truffle relates to finalizer execution but perhaps there is a connection?
<nirvdrum>
chrisseaton: ^
mister_solo has quit [Ping timeout: 265 seconds]
<chrisseaton>
i was trying to follow but can't find where this conversation began
mister_s_ has quit [Ping timeout: 272 seconds]
<nirvdrum>
The root of the chain was: "enebo: As of 0f4adc34b63b47f88e113fb5ca2f95817ef8e30b I now see a lot of output when running specs that wasn't there before: https://gist.github.com/nirvdrum/81c7fb319c30e4c1e739"
mister_solo has joined #jruby
brycek_ is now known as brycek
<enebo>
nirvdrum: yeah I understand but looking at the backtrace I don’t understand how that is possible so that is why I wonder if it is something to do with Truffle in some way
<nirvdrum>
enebo: I was letting Chris know where to start reading from :-)
<enebo>
ah ok I will add more for him to read :)
<enebo>
We definitely have a bug still too. finalizers are running after script scope and frame are gone
camlow325 has quit [Remote host closed the connection]
camlow325 has joined #jruby
camlow325 has quit [Remote host closed the connection]
<enebo>
So my change last night was to add one back but I think we were always evaluating in a not-real scope
<enebo>
or on a not-real one
<chrisseaton>
wow Google has indexed that gist already
<headius>
enebo: realpath is fixed...I also have a fix for the long-standing ChannelDescriptor leak the Puppet folks reported, but I am ambivalent about pushing it into 1.7.18
camlow325 has joined #jruby
<headius>
given the holidays I could go either way...either nobody will care until after the holidays, or they'll care a lot and not get a fix until after the holidays
<enebo>
I think we need to execute finalizers as part of main Script execution before we pop stuff off
<headius>
chrisseaton: it's scary sometimes, isn't it
<headius>
I wonder if someone who looked at it is using that google chrome caching service
<dfr|work>
morning folks.
<headius>
that has to cull a ton of updates for them
<headius>
dfr|work: morning! I fixed a File.realpath regression today that wasn't your fault :-D
nateberkopec has quit [Ping timeout: 244 seconds]
<headius>
all of the File.*path* methods really need cleanup
<headius>
awful awful mess
<dfr|work>
headius, does it use resources or not yet?
<nirvdrum>
headius, enebo: It looks like I could facilitate more sharing by retooling some of the RubyString methods to accept and return ByteLists, letting each RubyString implementation then do the proper thing with that list. Do you have any objections to me making some private instance methods public static instead?
<headius>
dfr|work: a few do but most don'w
<headius>
nirvdrum: I think if they are private now and become public static they should move to a central location rather than dangling off RubyString
<headius>
StringSupport probably
<headius>
that has become a bit of a grab bag but what are you going to do with a million functions?
<nirvdrum>
headius: Okay. No concerns about 1.7 merges?
<headius>
well, if they'd merge with just a visibility change they'll probably merge with a wholesale move
<enebo>
nirvdrum: headius: I agree with headius to make static helpers
<headius>
oh, wait
<headius>
yeah, I'm not concerned
<headius>
the pace of core class changes in 1.7 has slowed to a trickle
<nirvdrum>
A lot of these methods are still the is19 variants.
<dfr|work>
headius, *sigh* I really do wish a day had 27 hours. =/
<headius>
we may need to manually pick over some changes in the future, but that's inevitable
<enebo>
yeah I think we are beyond caring and manually merging the few fixes we have are ok
<headius>
dfr|work: me too
<enebo>
headius: plus we will be doing the remove all number changes soon I think
<enebo>
methods with numbers
<enebo>
probably leave in cat19 and a few others
<nirvdrum>
enebo: Want me to clean up the ones I'm touching?
<enebo>
nirvdrum: private methods are safe
<enebo>
nirvdrum: public ones I am less certain on now :) but I would like to
<headius>
enebo: I have been removing them as I encounter them
<enebo>
headius: I have a few myself
<headius>
because 9k will be out in a month, RIGHT?
<headius>
january is going to be busy busy busy
<enebo>
headius: but cat19 makes me leery
<nirvdrum>
enebo: Well, dump19() just calls dumpCommon(true), where the argument is "is1_9"
<enebo>
headius: yeah I really want it out :)
<enebo>
nirvdrum: the boolean should be removed regardless
<nirvdrum>
I can keep the public method and just change call, dropping the boolean arg. Unless you think you need that switching behavior still for whatever reason.
<nirvdrum>
Cool.
<enebo>
I need to eat…bbiab
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 1 new commit to master: http://git.io/Rrka_g
<JRubyGithub>
jruby/master d2a0d62 Kevin Menard: Moved a helper method from RubyString to StringSupport.
<headius>
oh christ, another 1.9-only method I guess
phrinx has joined #jruby
marr has quit [Remote host closed the connection]
marr has joined #jruby
<headius>
but hey, thanks to asarih, I didn't have to wait an entire day to find out
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to jruby-1_7: http://git.io/l5JQZg
<JRubyGithub>
jruby/jruby-1_7 467ccfb Charles Oliver Nutter: Mask 1.9-only test.
JRubyGithub has left #jruby [#jruby]
<asarih>
headius: at your service
marr has quit [Ping timeout: 245 seconds]
<headius>
enebo: saw your comment about finalization and popping stuff... yeah maybe true, or we need to push a finalization frame/scope before running them
<enebo>
headius: yeah. I am unsure. I need to see what happens with at_exit and captured vars
<headius>
we did not have to before, but we pushed a bunch of bogus crap frames on boot
<enebo>
headius: we still have one bogus frame I think
<headius>
probably
<headius>
nobody likes an AIOOB in the core runtime, after all
<enebo>
yeah for static/dynscope it should not matter really since it is all indexed on depth
<enebo>
but since we pop the scope before running these last things that is clearly broken but has always been clearly broken
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 5 new commits to master: http://git.io/hBfaUA
<JRubyGithub>
jruby/master 371ba62 Kevin Menard: Removed the forking 1.9 logic from RubyString#dump.
<JRubyGithub>
jruby/master 63a4d7f Kevin Menard: Updated String#dumpCommon to take and return a ByteList.
<JRubyGithub>
jruby/master d77e59e Kevin Menard: Made String#dumpCommon a static method.
JRubyGithub has left #jruby [#jruby]
<enebo>
nirvdrum: does cat just call cat19?
<enebo>
nirvdrum: your translation for the .force_encoding stuff completely ignore encoding name being non-ASCII but that is probably ok since I think they are all ASCII?
subbu is now known as subbu|lunch
<nirvdrum>
enebo: cat looks like an internal method for resizing the RubyString itself. The ruby call seems to come from append19.
<enebo>
nirvdrum: So I think the change is fine especially based on what it was doing before
<headius>
MRI checks the name when retrieving encoding and blows up if it's not
<nirvdrum>
enebo: I believe I maintained the semantics of what was there. I split them up until multiple commits so tracking it should be a lot easier.
<headius>
for encoding names coming from userland, that is... all encoding names in jcodings should be US-ASCII already
<nirvdrum>
*them up into
<enebo>
nirvdrum: but this is a weird aspect of the codebase…cat is dumb assume it is bytes and cat19 works and interacts with both encoding and corerange
<enebo>
nirvdrum: yeah I believe you made it no worse than what was there
<enebo>
nirvdrum: Your change made me wonder if encoding name could ever be non-ascii 7bit
<enebo>
nirvdrum: and headius just gave a good answer I think
<enebo>
nirvdrum: so it is safe
<headius>
enebo: yeah, 99% sure MRI guards against that everywhere
<headius>
they don't want to have to decode encoding names
<headius>
using encodings
<headius>
he
<headius>
heh
<nirvdrum>
I suspect a lot more of these could be made utility methods. It might be good to just split between the stuff that really needs a RubyString and the stuff that just needs a ByteList w/ an Encoding.
<enebo>
headius: perhaps though we should change cat to catBytes and have cat19 be cat or something … I hate the thought of that change and still supporting 1.7.x though
<headius>
enebo: I need your review for that leak bug because I'm stepping out of office this afternoon and we need to decide if it's in
<enebo>
nirvdrum: well I am all for that if it helps aid in readability
<headius>
enebo: that would make sense... MRI has similar conventions for mbc versus non-mbc
<enebo>
headius: ok I will look at it a little more…It already scares me :)
<headius>
I will ask how critical this is for them
<headius>
apparently puppet does a lot of jruby embedding
<headius>
puppet-server perhaps
<enebo>
headius: so tearDown and usage of tearDown is my only concern
<nirvdrum>
enebo: Cool. The benefit to me is I don't have to reimplement all this crazy stuff for the Truffle class hierarchy, since RubyString in Truffle-land is basically a ByteList and Encoding wrapper as well.
<headius>
enebo: I think I told you the story of singleton container teardown on master a few months ago
<enebo>
headius: The fix is clearly right and not risky in what it does but if tearDown is called as a matter of cource on SINGLETON what happens?
<headius>
basically, teardown of a singleton container worked ok *accidentally* because it left those stdio descriptors registered
<enebo>
I guess the singleton just gets boned
<enebo>
oh
<headius>
well look at the commit I did on master
<enebo>
That sounds vaguely familar
<headius>
I compromised and made teardown also clear the global runtime, so a subsequent SINGLETON would just spin up a new one
<enebo>
ah yeah that’s right
<headius>
so singleton, teardown, singleton would still work, but not see previous runs' state anymore
<enebo>
so that was my main concern
<headius>
that's a visible behavior change
mcclurmc has joined #jruby
<enebo>
We decided back then the intent of tearDown was I don’t want that runtime
<headius>
it's not possible to fix the leak without fixing that issue
<headius>
right
<enebo>
So even in Singleton it just means I want another singleton later
<headius>
yeah
<enebo>
if you make another one later
<headius>
I can do that on 1.7 but it's scarier there than in 9k
<enebo>
yeah it all comes flooding back :)
<enebo>
So let’s gastalt this a bit
mcclurmc_ has joined #jruby
<enebo>
If you terminate a runtime you are using embedded and these do not get unregistered then what positive outcome could there be?
mcclurmc has quit [Read error: Connection reset by peer]
<enebo>
Perhaps that you don’t GC them ever because they basically stayed pinned?
<headius>
your subsequent singleton runtims would still work as though you never did teardown
<enebo>
Is there anything in ChannelDescriptor which could benefit from accidentally keeping an extra reference and not letting it GC. Seems like it would expose some other bug of ours at worst
<headius>
modulo state changes actually caused by teardown (non-IO and object finalization, for example)
<headius>
hmm
<headius>
reopened stdio
<headius>
or otherwise modified stdio objects
<enebo>
headius: ah meaning the second startup would have the reopened version perhaps?
<headius>
but that leaks behavior across instances and past terminate/teardown anyway
<headius>
which seems bad
rsim has quit [Quit: Leaving.]
<enebo>
headius: I agree that sounds undesirable
<headius>
really singleton should not exist
<headius>
I think we should consider deprecating it for 9k
<headius>
it's almost never what you want...it's just easy
<enebo>
Probably easily argued as a bug since it does not match documentation on runtimes in embedding
<enebo>
yeah agreed. static kills us
<enebo>
almost without exception :)
<headius>
so yeah, with leak fix we need singleton teardown fix
<headius>
behaviorally, singleton changes such that teardown will cause next singleton instance to look completely new
<headius>
I think that about sums it up
<enebo>
yeah
<enebo>
so was the other singleton fix ever put on 1.7?
<headius>
no
<headius>
only on master...I found the bug because of IO rework
<enebo>
hmm seems right but I don’t like the idea of testing this a day or two before release and running with it unless it is super important
<enebo>
I would rather delay a week on the whole release or drop it for next point release
<headius>
if you're ok with an xmas-week release of 1.7.19 I can delay
mister_solo has quit [Ping timeout: 264 seconds]
<headius>
or week-after-xmas
<headius>
whatever
<headius>
I can push this to a branch so puppet folks can verify it
<headius>
that seems like best option anyway
<headius>
let a big embedder verify the embedding fix
<enebo>
I am confused. If we delay point release then just put it on jruby-1_7
<enebo>
oh 19
<headius>
oh you meant delay 18?
<headius>
I think 18 without the leak fix is ok to do tomorrow
<enebo>
I mean delay 18 or wait until 19 for this fix
<headius>
it has the realpath regression and a few other good fixes that aren't big
<enebo>
but 19 does not mean 19 is one week
<headius>
this is not a regression
<enebo>
I would say 19 in beginning of January but each of these points is eating into our 9k work
<headius>
I know
<headius>
we need a team of interns to maintain 1.7
<enebo>
I guess I am very happy with 18 as it stands (but I want to fix the last one marked and we need to know what the rg upgrade broke)
<headius>
oh, I didn't see that bug
<enebo>
well I somewhat agree but I also feel like a handoff would detach us too much from support of it
<headius>
I'm going to push this to a branch and update issue...if puppet guys make a fuss I'll tell them to test the branch and we'll consider it
<headius>
I'd rather it go into 19 than delay 18
<enebo>
If we want this to work as a long term branch I think we need to keep working on both
<enebo>
headius: ok that is my take as well
<headius>
yeah I know...maybe we just need a team of interns to do the actual work :-)
<enebo>
we do have some good PRs coming in so perhaps it is not so bad :)
<enebo>
someday perhaps coverage will be so good it is a button click but it seems like system/integration/acceptance testing always finds stuff
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius created test-fix-2333 (+1 new commit): http://git.io/HyY_3g
<JRubyGithub>
jruby/test-fix-2333 bd79165 Charles Oliver Nutter: Unregister stdio filenos from descriptor map, so they don't leak....
JRubyGithub has left #jruby [#jruby]
<enebo>
Adding note to issue on the plan
<enebo>
Added
<enebo>
and you just made a branch :) nice
mcclurmc_ has quit [Remote host closed the connection]
<bbrowning>
enebo: an update on the rubygems issue - I was able to change some of the TB3 build code that uses the RubyGems API to fix that part under the newer RubyGems. But, now I'm struggling with an issue where it appears nokogiri is getting required but the java extension isn't being loaded properly
<bbrowning>
have to figure out this before I can actually run TB3 integs against 1.7.18
<enebo>
bbrowning: ick. Sorry about this but the RG problem was something you were hoooking in tb3?
<enebo>
so that one is not really us but your integration right?
<bbrowning>
enebo: yeah the TB3 build was using rubygems during out build some
<bbrowning>
correct
<enebo>
ok. Well that is good from a 1.7.18 release perspective
<bbrowning>
the nokogiri issue is a bit weird though - trying to track it down now
<enebo>
now to hope the same thing of nokogiri but I thanks a ton for your support :)
<enebo>
hmm bad english
<bbrowning>
I see nokogiri.jar in $LOADED_FEATURES but it's like the jruby methods defined there aren't being loaded
zzak has joined #jruby
<bbrowning>
anything change around how java native gem extensions get loaded?
<zzak>
heay
<headius>
bbrowning: I don't think so
<headius>
not on 1.7
<headius>
-Xdebug.loadService=true
<headius>
see what you can see
<headius>
nokogiri.jar being loaded should trigger the *Service logic and boot it
<bbrowning>
ahh yeah I forgot about loadservice debug flag
<headius>
I'm not sure if we log whether a service is found
<enebo>
headius: canonic. of LOADPATH?
<headius>
should affect service load
<headius>
shouldn't
<asarih>
zzak: yo
<headius>
zzak: thanks for reminding me about the whitespace in that PR
<headius>
it's not a big deal but it noises up blame and history
<enebo>
haeiouy
<bbrowning>
headius: I do see LoadService: found fileResource: /home/bbrowning/src/torquebox3/integration-tests/target/rubygems-test/gems/nokogiri-1.5.3-java/lib/nokogiri/nokogiri.jar
<bbrowning>
so it shows me it found the jar, but not whether it did anything with the jar
<enebo>
bbrowning: can you just load nokogiri from command-line -e script?
<bbrowning>
enebo: yeah playing with that now
<enebo>
wondering if it is jar in jar action
<headius>
jc00ke: I'm not sure what I'm going to test locally, since it passed all the relevant suites on travis
<enebo>
oh but you explode tb3
<headius>
oh, I could look for MRI tests for FNM_EXTGLOB
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] lumeet opened pull request #2334: Replace array flattening with manual handling in java_import (master...2324) http://git.io/5rClIg
JRubyGithub has left #jruby [#jruby]
<headius>
yay, both MRI tests that hit FNM_EXTGLOB work too
<headius>
I'm satisfied
pchalupa has quit [Quit: Leaving]
<bbrowning>
enebo: works fine from jruby -e, so dunno what's up
<zzak>
enebo: what douome?
<zzak>
so does anyone know how to apply a patch to rvm build like i could use with travis? i know such hook exists in rvm `--patch` but i'd need it at runtime
<headius>
at runtime, as in .travis.yml ruby specification?
<headius>
mpapis: is that possible?
<zzak>
im not sure where it goes
<zzak>
maybe rake
<headius>
zzak: I'm about to merge that PR anyway, but it would be useful to know
<headius>
you could always just fork jruby and do whatever you want travis-wise
subbu|lunch has quit [Ping timeout: 265 seconds]
<headius>
oh, but you need to run OTHER tests on top of some rvm-friendly JRuby, and you need the patch in there
<headius>
righto
<zzak>
i would love to know how for future reference mainly
<headius>
once I push this and we get a green master build, then travis "jruby-head" will reflect the change immediately
<headius>
so there's that
<jc00ke>
headius: where are those MRI tests? I might add them to the specs if I'm missing something
<headius>
jc00ke: test/mri/ruby/test_fnmatch.rb in test_extglob and test_unmatched_encoding
<headius>
NYT likes the Cuba move, WP hates it...surprise surprise
<headius>
ok, out of office for a while
zeroecco has joined #jruby
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
subbu has joined #jruby
zorak8 has joined #jruby
cultureulterior1 has joined #jruby
<zzak>
bbl
zzak has quit [Quit: Page closed]
zorak8 has quit [Read error: Connection reset by peer]
zorak8 has joined #jruby
<bbrowning>
headius: enebo: I can get this to fail under 'jruby -e' when I require 'capybara/dsl' vs require 'nokogiri' - the former has a dependency on and ends up requiring nokogiri, but it fails at that point
tenderlove has quit [Remote host closed the connection]
tenderlove has joined #jruby
robbyoconnor has quit [Ping timeout: 272 seconds]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] enebo pushed 1 new commit to jruby-1_7: http://git.io/emZIUg
<JRubyGithub>
jruby/jruby-1_7 91444d1 Thomas E. Enebo: Fix #2291. Dir[] fails if path does not exist instead of returning nil
JRubyGithub has left #jruby [#jruby]
marr has joined #jruby
rsim has joined #jruby
JRubyGithub has joined #jruby
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
[jruby] enebo opened issue #2335: File.exist? and many others do not try system dir on wnidows if path starts with bare / http://git.io/bXM1LA
elia has joined #jruby
erikhatcher has quit [Quit: erikhatcher]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] enebo closed issue #2291: Dir[] fails if path does not exist instead of returning nil http://git.io/fJ916w
JRubyGithub has left #jruby [#jruby]
bbrowning_away is now known as bbrowning
mcclurmc has joined #jruby
balo_ has quit [Remote host closed the connection]
balo has joined #jruby
multibot_ has quit [Remote host closed the connection]
<lopex>
well it cant, but the conditionals are independent
<nirvdrum>
It looks like it.
yfeldblu_ has joined #jruby
<nirvdrum>
Yeah. It just seems you're doing twice as many comparisons for positive numbers. Unless this was intended to guard against timing attacks somehow.
<nirvdrum>
Ruby seems like the wrong language in that case.
<lopex>
just and an else
<lopex>
*an
<lopex>
no fun_call there so it wont be visible to ruby
yfeldblum has quit [Ping timeout: 245 seconds]
<lopex>
nirvdrum: jruby was so incomplete at that time, we just went fast porting aproach
<lopex>
nirvdrum: I remember a single patch that was a rewrite of all ruby numerics
<lopex>
and Ola bashed me for it, since it didnt pass the tests then
yfeldblu_ has quit [Ping timeout: 264 seconds]
erikhatcher has quit [Quit: erikhatcher]
<lopex>
nirvdrum: but the problem is still there, since even for truffle you'll have to obey the shortcircuits
<lopex>
and that means introducing inconsistency
<lopex>
nirvdrum: I recommmend looking at rubinius impls for these things
yfeldblum has quit [Remote host closed the connection]
mcclurmc has quit [Remote host closed the connection]
balo has quit [Ping timeout: 250 seconds]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 3 new commits to master: http://git.io/0b19_Q
<JRubyGithub>
jruby/master 53e64de Kevin Menard: [Truffle] Be tighter with the bounds when comparing double to integer types to account for loss of precision.
<JRubyGithub>
jruby/master 8330db3 Kevin Menard: [Truffle] At this point we've already determined we can't cast to long without losing precision, so use BigDecimal to preserve data.
<JRubyGithub>
jruby/master 6b6e370 Kevin Menard: [Truffle] Implemented Float#to_i.
JRubyGithub has left #jruby [#jruby]
balo has joined #jruby
subbu has quit [Ping timeout: 250 seconds]
balo has quit [Ping timeout: 265 seconds]
mister_s_ has joined #jruby
mister_solo has quit [Ping timeout: 264 seconds]
balo has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 1 new commit to master: http://git.io/tmDXhQ
<JRubyGithub>
jruby/master bf0ebab Kevin Menard: [Truffle] Untagged some passing Float specs.