<|jemc|>
and I think I heard something about 3.6 maybe dropping support for the old JIT (in favor of MCJIT) - if this is true 3.6 will not work because rubinius is not migrated to MCJIT yet
<|jemc|>
but I'm not sure about that point
havenwood has quit []
benlovell has joined #rubinius
tenderlove has quit [Remote host closed the connection]
benlovell has quit [Ping timeout: 256 seconds]
tenderlove has joined #rubinius
tenderlove has quit [Remote host closed the connection]
tenderlove has joined #rubinius
byprdct has joined #rubinius
benlovell has joined #rubinius
tenderlove has quit [Ping timeout: 256 seconds]
byprdct_ has joined #rubinius
dzhulk has joined #rubinius
benlovell has quit [Ping timeout: 272 seconds]
byprdct has quit [Ping timeout: 244 seconds]
dzhulk has quit [Quit: Leaving.]
havenwood has joined #rubinius
dzhulk has joined #rubinius
|jemc| has quit [Ping timeout: 244 seconds]
JohnBat26 has joined #rubinius
benlovell has joined #rubinius
benlovell has quit [Ping timeout: 255 seconds]
byprdct_ has quit []
diegoviola has quit [Read error: Connection reset by peer]
benlovell has joined #rubinius
benlovell has quit [Ping timeout: 245 seconds]
benlovell has joined #rubinius
dimday has quit [Quit: Leaving.]
noop has joined #rubinius
flavio has joined #rubinius
flavio has joined #rubinius
jnh has quit [Remote host closed the connection]
<yorickpeterse>
morning
postmodern has quit [Quit: Leaving]
jnh has joined #rubinius
benlovell has quit [Ping timeout: 245 seconds]
stass has quit [Ping timeout: 265 seconds]
stass has joined #rubinius
jnh has quit [Ping timeout: 255 seconds]
benlovell has joined #rubinius
havenwood has quit [Remote host closed the connection]
<brixen>
you seem to be trying to use brew openssl without linking it
tenderlove has joined #rubinius
<johnmuhl_>
thanks that fixed it
<yorickpeterse>
Hm, seems we didn't sync rubyspec for quite some time
<brixen>
yorickpeterse: how are you determining that?
<brixen>
johnmuhl_: btw, it seems to me that brew openssl is playing very badly with 10.10 ssl
<brixen>
I have no been able to confirm, but it seems like a process is loading brew libssl and 10.10 libcrypto
<yorickpeterse>
brixen: copied over spec/ruby/core from Rbx to rubyspec, going through all files one by one and comparing Git logs
<brixen>
and segfaulting
<brixen>
yorickpeterse: don't do that
<brixen>
you git fp and git am
<yorickpeterse>
Though I've bumped into a particular spec that seems to've been present in rubyspec, no longer is, but should
<brixen>
and you find how many commits by using git log spec/ruby
<yorickpeterse>
eh, doesn't that mean I have to change the patches to correct the filepaths?
<brixen>
thats what -p
<brixen>
is for
<yorickpeterse>
also git fp?
<brixen>
do not commit a big blob of crap
<brixen>
format-patch
<yorickpeterse>
oh right
<yxhuvud>
That article from chrisseaton on jit:ing c was pretty interesting.
<yorickpeterse>
hm, lets see
<brixen>
actually apply the commits
<brixen>
otherwise I can't figure shit out
<yorickpeterse>
also I was doing everything in separate commits
<brixen>
the separate commits already exist
<chrisseaton>
yxhuvud: thanks
<yorickpeterse>
aaaah, interesting
<yorickpeterse>
rubyspec has core/kernel/hash_spec.rb, rbx has core/kernel/Hash_spec.rb
<yorickpeterse>
which on my filesystem is not the same
<yorickpeterse>
brixen: should I in this case go with Hash_spec, or hash_spec? There are some other capitalized specs such as Complex_spec.rb in both projects
<yorickpeterse>
so I'd say Hash_spec would be more logical
<brixen>
I don't have Hash_spec.rb
<yorickpeterse>
You're on HFS right?
<yorickpeterse>
I believe that's still case-insensitive by default
<brixen>
weird, all the others are capitalized but Hash_spec isn't
<yorickpeterse>
Hm, I'll import it as capitalized into rubyspec
<yorickpeterse>
well, I'll just mv the file
<brixen>
is git am actually giving you a problem?
<yorickpeterse>
No, but that will be the next step
<brixen>
yorickpeterse: git fp -86 spec/ruby/
<yorickpeterse>
not correcting this particular file name other people will most likely bump into the same problem in the future
<yorickpeterse>
-86 ?
<brixen>
you need to apply those one at a time
<brixen>
so you can deal with conflicts correctly
<yorickpeterse>
oh, last 86 commits?
<yxhuvud>
brixen: regarding the test failure of sleep earlier, it seems the matchers uses < to compare, which isn't inclusive of the tolerance interval endpoints. Did sleep change return value to be of the same kind that it was called with?
<brixen>
yxhuvud: could you link to code please
<yxhuvud>
I havn't looked at the implementation of sleep yet, I'm just guessing
<yxhuvud>
or are you asking for the code of the matcher?
<brixen>
I'm wondering what you're referring to
<brixen>
oh, the paste earlier
<yxhuvud>
yes
<yorickpeterse>
brixen: how did you come up with the -86?
<yorickpeterse>
as in, how did you figure out it's 86 commits
<yorickpeterse>
trying to see a correlation here between the two repos, but it's not entirely clear