<robin850>
hello there! Excuse me but is it normal that Rubinius 2.3.0 implements Kernel#itself while its RUBY_VERSION is still 2.1.0 (c.f. http://git.io/8sRPYA) ?
<yorickpeterse>
robin850: yes
<yorickpeterse>
robin850: it was merged in too quickly :P
<yorickpeterse>
also our current compatibility sits somewhere between 2.0 and 2.2
<yorickpeterse>
e.g. not all 2.1 stuff is there yet I believe
<robin850>
yorickpeterse: Okay, thanks you very much for the answer! Do you have any plans to bump this `@ruby_version` anytime soon to 2.2.0 ? Actually Rails 5.0 will only support 2.2+ for the garbage collection of symbols ; it'd be sad to stop testing against Rubinius just for that :/
<yorickpeterse>
robin850: isn't Rails 5 still like years away?
<yorickpeterse>
Also why the fuck are they specifically testing for that feature?
<yorickpeterse>
btw the version will be updated when our ABI is basically 2.2 only
<diegoviola>
hi
<robin850>
yorickpeterse: Nope, Rails will be bumped to 5.0 in the next few weeks (once 4.2.0 gets out) and it should be released during spring/summer 2015. They are requiring this feature to avoid problems such as http://bit.ly/1GAWxNM I think.
diegoviola has quit [Quit: WeeChat 1.0.1]
<robin850>
(I mean Symbol DoS ; since there are several vulnerabilities in the aforementioned topic)
meh` has joined #rubinius
carlosgaldino has joined #rubinius
josh-k has quit [Remote host closed the connection]
josh-k has joined #rubinius
josh-k_ has joined #rubinius
JohnBat26 has joined #rubinius
josh-k has quit [Ping timeout: 255 seconds]
josh-k_ has quit [Remote host closed the connection]
josh-k has joined #rubinius
josh-k has quit [Ping timeout: 264 seconds]
carlosgaldino has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<brixen>
a tool to check ruby version, ruby engine, and engine version
<brixen>
also, there is no DDoS mitigation that *requires* garbage collecting Symbols
<brixen>
this is a stupid direction Rails is going following on the "Hash DDoS must require a change to hash function" nonsense
<brixen>
that said, Rubinius 3.0 will garbage collect symbols
<brixen>
also, if Ruby quit using Symbols like immutable Strings instead of just having immutable Strings, it would greatly simplify many things
<robin850>
Ah didn't know that project, seems pretty cool! I will let them know but genrally they prefer feature-detection over version-checks
<robin850>
Also, as for the garbage collection of symbols I *may* misunderstand the purpose of that. There's a bunch of other points described here: http://weblog.rubyonrails.org/2014/8/20/Rails-4-2-beta1/ (and search for "Maintenance consequences and Rails 5.0" on the page)
slaught has joined #rubinius
slaught has quit [Client Quit]
havenwood has joined #rubinius
slaught has joined #rubinius
diegoviola has joined #rubinius
<brixen>
robin850: feature detection is something I want to add to redcard, but features are not "is this method defined"
<brixen>
features are things like encoding, fork, etc
<brixen>
in the past, Rails and other Ruby code have checked eg if Encoding is defined for whether to use : Hash syntax
<brixen>
that's just dumb
<brixen>
rubygems checks if Array#bsearch is defined, then calls Range#bsearch
<brixen>
things like that are brittle and wrong
<brixen>
if specific methods are needed, and that needs to be conditionalized, we use OO principles
<brixen>
ie polymorphism and objects
<robin850>
brixen: Do you have an example that uses polymorphism/objects please ?
<brixen>
robin850: it depends on where you need this method
<brixen>
the simplest may simply be to define the method on the object that uses it
<brixen>
with a conditional on #method_defined?
<brixen>
or it could be requiring a completely different class
<brixen>
my main point is NOT to use a proxy for the thing
<brixen>
by proxy, I mean what I wrote above: eg checking that Encoding exists to decide whether to emit { a : foo } instead of { :a => foo }
<yorickpeterse>
wtf why would you even use Encoding for that
<yorickpeterse>
(well yeah it's also only there since 1.9 but still)
<robin850>
brixen: Okay, so you're ok with checks like respond_to?(:foo) as long as it is to decide whether we should use the foo method or another one ? You're simply against checking whether String#scrub is present to know whether the Ruby version is >= 2.1 for example ?
<cremes>
so i’m going to start hacking again on replacing all of the C++ in our IO class with Ruby + FFI
<cremes>
step one is to write some more benchmarks so i can track how well (or poorly) the replacements are.
<brixen>
robin850: ye
<brixen>
er yes
<brixen>
cremes: awesome
<cremes>
my question… what’s the best way to do before/after comparisons? switch back-and-forth between branches and rerun?
<brixen>
you can
<cremes>
heh, i know that i *can* but is that a good way to accomplish the comparison? ;)
<brixen>
whichever is easiest, and correct, is the good way
<brixen>
comparisons need to account for both of time used and memory used
<cremes>
well, i can’t really think of an alternative so i’ll use branches to compare.
<brixen>
and time used on Rubinius needs to account for wall clock and CPU time
<brixen>
you can use feature flags
<brixen>
instead of branches
<brixen>
depends how invasive your changes are
<brixen>
for example, we load chained-bucket Hash and HAMT Hash with a config flag
<cremes>
so is benchmark_suite insufficient to the task? i don’t think it does CPU time and it definitely doesn’t measure memory usage.
<brixen>
s/and/or/
<brixen>
it's probably not sufficient, no
<brixen>
but it may be a good first step
<brixen>
I haven't looked super close at the recent IPS changes, but they're probably not usefuls
<brixen>
er useful
<cremes>
my intention is to hoist IO up on blocks and replace all code related to the “read” path. then i’ll do the “write” path. then i’ll do select + friends.
<brixen>
unless they changed the fundamental problems with IPS design
<robin850>
brixen: Okay, seems pretty fair! :-)
<brixen>
robin850: it's definitely a painful area, Ruby provides almost no help here
<brixen>
robin850: I'd really like to improve redcard, especially around feature detection
<cremes>
i’m sure my plans will change once i have deeper contact with the “enemy” (the C++ code)
<brixen>
robin850: but a lot of work needs to be done at the framework level too
<brixen>
robin850: eg ActiveSupport
<brixen>
cremes: I have worked out some things around IO, but I'm curious what you come up with :)
<brixen>
cremes: I'm assuming you already know this, but the point about CPU time is important
<brixen>
if we just push work to parallel, we may shorten wall clock time but impair the system under load
<brixen>
this isn't usually in any benchmark analysis I see :)
<brixen>
certainly not in hello, world raptor-style benchmarks
<robin850>
brixen: Yup, agree!
<robin850>
brixen yorickpeterse : Thanks a ton for your answers/input on this ! I will try to talk with the core team about that! :-)
<brixen>
robin850: thanks for all your work on stuff like this
<brixen>
robin850: could you pls open an issue about #itself?
<brixen>
I'm hoping to release 2.3.1 in the next day or two
<brixen>
and I'll fix that
<cremes>
brixen: i would agree that cpu time is important but i’m unsure how to accurately measure it during testing. separating signal from noise seems like it would be tough to do.
<cremes>
plus most tests are over so quick it’s hard to get a good sample
<brixen>
that's a problem with methodology
<brixen>
focus on getting accurate data
<brixen>
then analyze it
<cremes>
really i was just hoping to move most of this to Ruby so the burden of making it fast would fall on the JIT (i.e. you) :)
<brixen>
accurate doesn't mean not noisy
<brixen>
but it shouldn't be "wrong"
<cremes>
will do
<brixen>
hah, the "JIT" :p
<cremes>
yeah, you know, that thing which came about from a few weeks of evan banging on it ;)
<robin850>
brixen: Sure thing! I will do that shortly.
<brixen>
that's what we have here, tin cans and sticks
<brixen>
and banging
<brixen>
:)
<cremes>
haha
<brixen>
pretty soon we're going to have songs though :)
<cremes>
you hacking this morning or just hanging out?
<brixen>
trying to write 10,000 words this weekend
<brixen>
I'd love to be hacking on the stuff I'm writing about, but sometimes communicating is more important
<cremes>
+1
slaught has quit [Quit: slaught]
JohnBat26 has joined #rubinius
diegoviola has quit [Quit: WeeChat 1.0.1]
meh` has joined #rubinius
<yorickpeterse>
brixen: most recent ips changes were just cleanups
<yorickpeterse>
and comparing bench blocks is now easier
<brixen>
that's what I assumed, based on a quick scan of some diffs
max96at is now known as max96at|off
<yorickpeterse>
cremes: when benchmarking IO, be sure to also measure SSD vs HDD
<yorickpeterse>
I'd expect less consistent results on an HDD
<brixen>
yes, as well as relative chassis vibration and be sure to categorize by chip manufacturer
<brixen>
:)
<Rotonen>
how about io schedulers and filesystems? :-)
<brixen>
heh
<yorickpeterse>
Rotonen: actually the former would be a non issue with SSDs
<brixen>
and definitely benchmark on openbsd
<yorickpeterse>
e.g. linux basically uses no scheduled automatically when it detects an SSD (or something along those lines)
<Rotonen>
i kinda like how NOOP is valid for SSDs since the firmware keeps up with the load better than any old cpu solution trying to shield the disk IO from hanging up
<yorickpeterse>
s/scheduled/scheduling
<Rotonen>
yorickpeterse: nifty, since when? i have missed that and did not use to be that way
<Rotonen>
but considering ATA TRIM is also handled, would make sense
<yorickpeterse>
A while ago, at least in the past 2 years or so
<yorickpeterse>
lemme see what kernel release that was
<Rotonen>
i'm mostly on 3.2
<Rotonen>
but a non-issue as you can selectively set the scheduler to noop where applicabble
<yorickpeterse>
TRIM is supported since 3.7
<Rotonen>
in ext4, yes
<Rotonen>
in other filesystems YMMV, IIRC XFS only got it recently (relevant due to RHEL 7 defaulting to it)
<Rotonen>
(but then again redhat backports stuff like there is no tomorrow, so the .0 release kernel spec tells not too much of the EOL picture of a release)
<yorickpeterse>
hm, can't find the exact release
<Rotonen>
can also be distro specific whether or not
<yorickpeterse>
Doubt Arch does that kind of stuff
<yorickpeterse>
I'm on a fairly new kernel though, 3.16
<Rotonen>
arch goes pretty much vanilla on most things
<Rotonen>
IIRC 3.16 is what jessie is going to roll with
<Rotonen>
after the freeze dust settling after february 5th next year i'm going to start taking debian jessie for a spin
<Rotonen>
freeze begin to freeze settle is the worst time for debian testing, packages going out, coming in, going out, coming in :>