Index

Show enters and exits. Hide enters and exits.

00:04:57brixenevan: rad screen cast
00:05:43evanit's pretty funny
00:05:44brixenDefiler: yeah, fascinating
00:05:54evansince it's straight me debugging
00:06:01evanso there are the pauses where i'm thinking
00:06:07evanor sentenses that just end
00:06:21brixenDefiler: my response to scala is getting to be "*yawn* le'me know how that works out for ya"
00:06:51brixenevan: yeah, I've been there in person, but I think it's pretty effective to show others this
00:06:56Defilerbrixen: to be honest that was my initial reaction after using it
00:07:23Defilerwe built a pub/sub system out of it at work, stepped back, laughed, and deleted it
00:08:01brixenDefiler: hah, that's funny
00:08:34Defilerscala people need to learn about redis, is my take
00:08:35brixenDefiler: you obviously would rather document your work style and practices in minute detail
00:08:54Defilerabsolutely
00:09:03DefilerI would hate to accidentally complete a project
00:09:09evanwhen you have static typing
00:09:13evaneverything is crystal clear
00:09:16evanyou didn't know that?
00:09:18brixeneverything
00:09:23evanC++ is like reading poetry
00:09:55evanit doesn't read like an instruction manual for putting together jet engine in russian
00:09:58evanno, not at all.
00:10:01Defilerand Scala is like reading Vogon poetry
00:10:33brixenstatic typing: handling the easy bugs you mostly won't have so you can pull you're hair out on the hard ones.
00:10:37brixen(tm)
00:10:49Defilerevery Scala developer needs to read The Black Swan
00:11:02Defilerhell, every static typing cheerleader
00:11:14DefilerI build for the bugs I will never hear about
00:11:18Defilernot the mistakes I plan to make
00:11:30evanI like to ask scala devs "thats amazing! everything works perfectly the as soon as it parses? never any bugs! awesome!"
00:11:36evans/ask/tell/
00:11:40Defilerhaha that is awesome
00:11:44Defilergoing to start doing that
00:12:05DefilerWith a really wide-eyed earnest look
00:12:10evantotally
00:12:24DefilerI am here to pick up some tablets, Lord
00:12:25evanand be really hurt when they say "well, no, it doesn't always work perfectly."
00:12:37Defiler"Oh, are they working on fixing that?"
00:12:54evanUm, yeah, Moses, I've got ticket number 16, sorry I'm late there was traffic in the desert.
00:13:05DefilerI had to set fire to a bush
00:13:12Defilerlong story
00:13:16evanheheheh
00:14:04DefilerIf you made me use the JVM and told me I couldn't use JRuby, I would probably go with Clojure
00:14:11Defilerwhich is at least fun
00:14:29DefilerScala is like peeling band-aids off hair, forever.
00:17:54boyscoutCI: Commit 7a928de failed. http://github.com/evanphx/rubinius/commit/7a928de9828d69fd4fc0d320fe27d9a1405b90da
00:18:40brixenahh the poetry spec
00:18:51brixencome to bid good day
00:24:09evanthat spec keeps failing randomly
00:24:13evanI change it in hydra
00:24:17evani should change it in master too.
00:24:36evananyway
00:24:39evanbrb.
02:43:35drnicif I require a file "foobar" and only the "foobar.rbc" file exists, should it find + load it ok?
05:19:17dbussinkevan: hmm, looks like your vm_spawn addition breaks gdb here on my system
05:19:53dbussinkevan: https://gist.github.com/4d3ccadc7fbfea907c06
16:40:10evandbussink: did you watch the video?
16:40:35tarcieriwtf @ precedence of **
16:40:41evaneh?
16:40:46tarcieri-2 ** 2 is -4 ?
16:41:16brixenyep
16:41:26tarcierithat's... odd
16:41:30evanwow, that is weird.
16:43:05boyscoutKeep reading if read(2) gets EINTR - 4a5227f - Evan Phoenix
16:43:21boyscoutKeep reading if read(2) gets EINTR - b59b0fe - Evan Phoenix (hydra)
16:48:24brixenwtf? http://github.com/rubyspec/rubyspec/issues/#issue/22
16:48:40evan*shrug*
16:49:08evanmaybe he's saying that capi shouldn't be spec'd at all
16:49:11evanin which case
16:49:14evan*eyeroll*
16:49:17brixenexactly
16:59:22brixenevan: thoughts on http://github.com/evanphx/rubinius/issues/#issue/441
16:59:44evanwe can support it
16:59:53evanbut we discussed it back when you were redoing require, as I recall
17:00:02evanand decided we didn't need it
17:00:14brixenyeah, I detail the 2 issues with supporting it in that ticket
17:00:26brixenbut the bigger issue is you really get nothing from it
17:01:27evanso
17:01:37evanmy position on this has always been leave the door open
17:01:38brixenwhat we have for loading the bytecode compiler would work for any case where you have a dir tree of compiled files
17:01:41brixenand you load the rood
17:01:45brixener root
17:02:43evani think all of those can be tabled while question 2 is considered
17:03:03evannamely: do .rbc files provide the level of obfustication that someone wants?
17:03:31evanuntil that question is answered to the users satisfaction, we don't need to worry about the other part
17:03:31brixennot at all, IMO
17:03:54evanie, we shouldn't worry about shipping a car from europe if the user doesn't even want the car.
17:03:57brixenthe bigger question for me is how this interacts with #require semantics and $L_F
17:04:11brixenif we have this facility, it will be used
17:04:21evanright, so we should get the semantics right
17:04:25brixenand the misunderstanding around it to this point means it will be misused
17:04:28evanbut the semantics need to be driven by a user case
17:04:39evani'm fine having drnic drive it that as a use case
17:04:40brixenwe have a nominal use case
17:04:42evanif he'd like to.
17:04:45brixenobfuscation
17:05:29brixenregardless of the strategy used for obfuscation (ie loading .rbc or encrypted files), we still need to have the #require semantics correct
17:05:37evanright
17:05:45brixenwe already side-step that with the special require that we have for the compiler
17:05:48evanso perhaps it should be a feature that can be turned on
17:05:50evanand is off by default
17:06:01brixenit's a completely different method
17:06:02evanhere are the semantics that feature would create:
17:06:10brixenso we can't be incompatible with MRI
17:06:39evanare you saying it's a completely different method, so we should never do it?
17:06:55brixenno, I'm saying it does not use #require to load a .rbc file
17:07:20brixenwe have the ability to load a tree of .rbc files that does not use #require
17:07:26evanso to support this, you'd require the users to use a different method to import code
17:07:33brixenI would, yes
17:07:44evanhm
17:08:08evanand this alternative import method would twiddle $L_F, so that a future call te require would return false
17:08:08evan?
17:08:23evanor you'd require the user to remove all require lines
17:08:39evanall #require lines (to be clear)
17:09:02brixenI think the method would insert .rb files into #L_F instead of .rbc files
17:09:43brixenthat's how it works now
17:10:08evanso given a directory precompiled/foo.rbc
17:10:15evanand Rubinius.import_tree("precompiled")
17:10:25evanrequire "foo" # => false
17:10:26evanyes?
17:11:43boyscoutCI: rubinius: 4a5227f successful: 3515 files, 15106 examples, 42950 expectations, 0 failures, 0 errors
17:11:55brixenwell, if require "foo" (through $:) were to resolve to the foo.rbc, then yes, #require would return false
17:12:14evanwait wait
17:12:18evannow you've confused me.
17:12:22brixenwe have CodeLoader.require_compiled "root" already
17:12:31brixenlook at $" in rbx
17:13:12brixen#require would return false (should) if you tried to require lib/compiler/ast/definitions.rb for example
17:13:18evanhold up.
17:15:03evani have to go back and look at codeloader to figure out how we have it working now.
17:16:30evanok, right. so require_compiled sets a flag saying that any call to require under here should consider lone .rbc files
17:16:44brixenyeah
17:17:24evanso what about setting that flag inside loader.rb if -Xallow_lone_rbc is set?
17:17:25brixenmore than that
17:17:33brixenit changes how require code looks for extensions
17:17:45evanhmrm.
17:17:52evani have to go look at that code now.
17:18:04brixenI can't say this enough, I really do not want #require to load .rbc files
17:18:14evanbut we already have it doing that
17:18:15evan:)
17:18:19brixenspecially
17:18:20evanas you just detailed
17:18:30brixenwe are not just allowing #require to load .rbc files
17:18:36evansure we can
17:18:42evanrequire_compiled does exactly that.
17:18:47evanit allows #require to load .rbc files.
17:18:52brixenI'm didn't say we can't
17:19:07brixenI'm saying, #require does not automatically load .rbc files
17:19:56brixenbrb, I need to proof read this post
17:19:57evanunless explicitly instructed to
17:20:01evanso you're against it doing it by default
17:20:03evanis what you mean
17:20:06brixenyes
17:21:32evanso thougts on having an option to turn this on
17:21:35evanthat a user could use
17:21:45evanknowing it changes the behavior of require
17:22:15evani agree with you that we shouldn't have this be the default behavior of #require
17:23:11brixenwell, we have that "flag" right now: CodeLoader.require_compiled "root"
17:23:21brixenthey really aren't going to want that in development
17:23:33evanright
17:23:35brixenwhen they deploy, their code is loaded from a root file with that
17:23:46evanso my point is to have a flag set via -X that they'd use it production
17:23:56evanthat would allow require to consider lone rbc files
17:24:09evanthey wouldn't have to put require_compiled in the code base then.
17:24:14brixenit would only consider .rbc files unless the current implementation is changed
17:24:35brixenie, in #require_compiled, no .rb file will even be considered
17:25:02evani don't understand "unless the current implemention is changed" comment
17:25:29brixen#require will only load .rb files (in MRI)
17:25:46brixenwhen you call #require_compiled, #require will only load .rbc files (in rbx)
17:25:50brixenthere is no mixing
17:26:02evanright
17:26:02brixenthere is no "consider lone .rbc files"
17:26:03evani know
17:26:04brixenok
17:26:12evani'm saying add new functionality
17:26:19evanthat is triggered by the new -X option
17:26:48brixenwell, I'm against #require mixing .rb and .rbc files
17:26:49evani think you meant "if" and not "unless"
17:26:58brixenunless?
17:27:01evannm.
17:27:29evanwhy are you against it?
17:27:47evangiven that this new functionality would be turned on by a rbx specific flag to enable rbx specific behavior
17:28:09evanbecause it could cause breakages in production not seen in dev?
17:28:32brixenthe semantics of mixing .rbc and .rb files is not yet defined
17:28:40brixenit will be confusing, yes
17:28:44evanwell, it is a litle now
17:28:48brixenI don't see a compelling need for it
17:28:51evanwe mix them to a certain degree atm.
17:29:00brixenonly in the case of the compiler
17:29:09evani think we need to define certain things
17:29:13brixenand it loads a tree of .rbc files "as if" they were .rb files
17:29:25evani consider the fact that #require will load a .rbc file when there is a .rb there as "mixing"
17:29:34evanwhat do you define as "mixing"
17:29:34evan?
17:29:40brixenok, very different :)
17:30:21brixen"mixing" is that on one line, I have 'require "foo.rbc"' on anther I have 'reqire "foo"' or 'require "bar"' or whatever
17:30:43brixenbasically, that require has to always be able to load a .rbc file
17:30:52brixenthat is very different than what we have now
17:31:10brixenwhich again is that we can require a tree of .rbc files as if they were a tree of .rb files
17:31:32evanyour last line lost me.
17:31:55evanactually, i don't get what you mean at all.
17:31:58brixenrequire_compiled makes #require think .rbc files are .rb files, basically
17:31:58evanlets switch to phone.
17:32:13brixenhold on
17:32:16evanthis is getting frusterating because we're talking past eachother.
17:32:21brixenI need to finish proofing this for melissa
17:32:26evank
17:56:33brixenevan: ok, back
17:56:40brixenwant to do a call?
17:56:45evanyep
17:58:29brixenevan: erg, call back pls
17:58:37evanyep
17:58:40brixenI touched the spot
17:58:42brixenhaha
18:31:24evanbrixen: thoughts on how to deal with http://github.com/evanphx/rubinius/issues#issue/439
18:31:32evanthe DNS related specs suck ass.
18:34:50brixenI know :(
18:35:15evanseems like we should just make sure it returns a valid DNS name
18:35:18evanie
18:35:29brixensure, that would work
18:35:54evan /([A-Za-z]+\.?)*[A-Za-z]+/
18:36:00evanactually, that should be
18:36:05evan /([A-Za-z]+\.)*[A-Za-z]+/
18:36:15brixenyeah
18:36:41brixenprobably a helper x.getnameinfo.should =~ valid_dns_name
18:36:46evanyeah.
18:36:53brixenok
18:37:50evanwe should look around, i'll bet there is a valid_dns_name regex already
18:42:16brixenk
18:45:29dbussinkevan: this piece of code was masking the exception with that vm_spawn bug: https://gist.github.com/df57f4449dffed434ea7
18:45:45dbussinkevan: should i remove that or do we want that to gobble up all the errors there?
18:45:46evansort of
18:45:56evanyou can remove it
18:46:55dbussinkevan: this was an assert that was caught there someone even
18:47:04dbussinkevan: and the process just exited with status -
18:47:06dbussinkstatus 0
18:47:09evanhuh?
18:47:28evancompletely lost me.
18:48:13dbussinkevan: well, i only saw this backtrace https://gist.github.com/4d3ccadc7fbfea907c06 after i made the following change https://gist.github.com/df57f4449dffed434ea7
18:48:37evanok.. and?
18:48:48evani don't get your comment about asserts and someone even and whatever
18:48:55dbussinkso that catch all there was masking that error and just printed "Unknown exception occured" and the process exited with status 0
18:49:17evanright
18:49:18evani know
18:49:21evanyou can remove that.
18:50:33dbussinkevan: i guess for completeness it also should return a non 0 exit state in the other catch blocks right?
18:50:46evanprobably.
18:53:00dbussinkevan: still need to watch your debug screencast, but i'm going to in a minute :)
18:53:13evani made it just for you!
18:53:38dbussinkdifferent tz's :P
18:55:53dbussinkevan: hah! i named the script thread_torture.rb :p
18:56:01evan:D
18:58:58dbussinkevan: it's a bit weird though, because i did have the crash happening with a full dev mode build
18:59:59evankeep watching.
19:00:09evanit's a timing bug, so thats why it mattered.
19:00:34evanit wasn't related to optimizations breaking it
19:00:38evanonly that optimizations changed the timing.
19:00:45evanand every machines timing is different.
19:02:45dbussinkthat's true yeah
19:02:57dbussinkmy laptop is getting a bit older already :P
19:08:17dbussink*burp*
19:09:26evanyeah, i was drinking coffee
19:09:28evanand it was post lunch
19:09:28evan:D
19:09:43dbussinkevan: so yeah, i missed the implication of gc_indepedent
19:09:48dbussinkafter that it's an easy ride
19:09:54evannope
19:09:57evankeep watching.
19:11:00dbussinkevan: you mean the removing twice (already saw the changeset ;) )
19:11:12evanremoving twice?
19:11:13evanhuh?
19:11:14evanno.
19:14:12dbussinkevan: bless you!
19:14:22evan:D
19:14:27evanok, i'm off to get some lunch.
19:14:28evanenjoy!
19:17:40dbussinkevan: there's a * by the current thread in that thread list btw
19:17:45dbussinkevan: or did you look over that?
19:18:06dbussinkevan: ah, you did :P
19:59:03dbussinkevan: it was the 0 after all too ;)
20:11:01evandbussink: yep.
20:17:59dbussinkevan: hmm, those llvm crashes aren't really useful right?
20:18:08evangenerally no.
20:29:47dbussinkevan: yay, got another one :) https://gist.github.com/4898242707d393fe2de2
20:30:25dbussinkevan: hmm, prune_handles there should be locked?
20:30:29evanno.
20:30:33evanit's running in the GC.
20:30:38evanget a backtrace of other threads.
20:32:40dbussinkevan: hmm, not much running: https://gist.github.com/2425eb69697233c862fd
20:32:46dbussinkthis is in interpreted mode btw
20:33:20dbussinkso that would mean they were corrupted before
20:38:00dbussinkevan: hmm, is it right that there are locks around the global_handles?
20:38:05dbussinkfor the capi?
20:38:11dbussinkare no locks i mean
21:19:06evandbussink: ah!
21:19:08evana good find!
21:19:27evanyes, we need to put locks around adding to global_handles
21:19:35evanand cached_handles
22:02:17evanso, i think for the time being
22:02:26evani'm making some parts of capi handle management thread-safe
22:02:34evanbut i'm going to put a lock around extensions
22:02:48evanso that there is no concurrent execution of extension methods for now.
22:03:03evanan extension GIL, if you will.
22:03:32evanit's a quiet thursday, so maybe i'm talking to myself.
22:03:32brixenok
22:03:38brixenare you hitting an issue?
22:03:45evandbussink did
22:03:51evanand it got me pondering
22:04:01evani can make managing the list of handles thread safe
22:04:18evanbut the business with cached_handles is another thing entirely.
22:04:35evanand we'll continue to hit issue with extensions using things that aren't thread safe
22:04:41evanthings we can't control
22:04:44evanlike strtok()
22:04:56brixenhmm, indeed
22:05:37evani'll release the GEL (Global Extension Lock) whenever control transitions back into ruby land
22:06:01evanso that just code running in the extensions is serialized
22:06:51brixenyou have to wait for your extensions to GEL
22:06:58evanexactly!
22:07:00brixenattempts humor
22:07:42brixenyeah, the calling to C functions with our pinned string is dicey
22:07:50evanright.
22:07:50brixendoesn't seem like that could ever be safe
22:07:59evaneh? which part
22:08:01brixenie, we just can't know (tm)
22:08:17brixenwell, if you have a ptr to it stashed somewhere
22:08:29brixenand something is writing to it while something else tries to
22:08:38brixenseems like it could always be a potential data race
22:08:50evanyeah, easi
22:08:52evaneasy.
22:09:03evanthats the reason the GEL seems like the best solution
22:09:07brixenyeah
22:09:11brixenI'm seeing that
22:09:28evanit's a decent compromise for now too
22:09:28brixenI was mostly thinking about modifying other Ruby structures before
22:09:35evanruby code == fast and safe and concurrent
22:09:40brixenor like you say, the handle management
22:09:42evanextension code == fast and unsafe and serial
22:09:45brixenyeah
22:12:13evanmy thoughts on concurrent extensions: http://img.skitch.com/20100819-84xcwes6hwbatamigaiy5b32ax.png
22:12:22brixenhah
22:12:30brixenyou were just waiting to use that :)
22:12:42evanall day!
22:12:46evani've been working it in all day.
22:12:47brixenheh
22:14:30brixenhrm, not a fan of the moniker JRubyists :/
22:14:52brixenI guess every group needs an identifier
22:14:55evanwhy aren't they just rubyists?
22:15:01brixenbut I hope we can all stay rubyists
22:15:04brixenI dunnod
22:15:05evani see people say "i'm using ruby/jruby!"
22:15:08evanwhich confuses me.
22:15:12brixenyeah
22:15:27brixenI don't like the suggestion that jrubyists do something rubyists don't
22:15:36brixenexcept maybe use Java?
22:15:42evan*shrug*
22:15:43brixenbut we don't call them CRubyists
22:15:53evani guess they feel like they've got unique issues?
22:16:00brixenperhaps
22:16:05evandealing with java libraries does seem like a unique issue.
22:16:12brixenI'd just like Ruby to stay a community of rubyists
22:16:23evanyeah
22:16:29brixenIronRubyists
22:16:37brixenMaglevites
22:16:45evanheh
22:16:49brixenthis way lies madness :)
22:18:13brixenJRuby folks seems less divisive than JRubyists
22:26:03kronos_vanoRubiniusists
22:26:23evan:)
22:27:03brixenor not :)
22:30:08mjijacksonbrixen: I personally made the Ruby/JRuby distinction in the tagline for a gem that I wrote that had some special advantages on JRuby, just to let folks know that special consideration had been made for the JRuby platform.
22:31:29evanmjijackson: what were the special considerations?
22:31:49evanmjijackson: i see you were already in the channel!
22:32:07jakedouglasat some point (not that long ago, really), people had to make conscious decisions about this stuff because not everything was supported seamlessly on mri, jruby, and rubinius. it may be a lot better or almost non-existent now, but lets not pretend like it was always so..
22:32:33evanjakedouglas: we're not pretending
22:32:46evanmainly curious what jrubyists feel makes them different from rubyists.
22:32:47evanis all.
22:33:08mjijacksonevan: it just used a jar under the hood. with JRuby i was able to import the Java classes directly. With MRI I needed to pipe I/O through the system shell. Naturally, the JRuby version ran quite a bit faster.
22:33:20evanah
22:33:21evangotcha
22:33:24evansure, that makes sense.
22:33:32jakedouglasi duno, i prefer the term 'software developer' or similar language-agnostic thing
22:33:37evanthats one place where the conscience decision still exists
22:33:41evanand likely won't go away.
22:34:24mjijacksonright.
22:34:43jakedouglasmaybe 'jrubyists' do a lot of ruby <-> java integration.
22:34:51evanright
22:36:00evanright
22:36:07evanmy guess is they don't give the label much thought actually
22:36:14evan"i'm using jruby, i'm a jrubyists."
22:36:18evanand leave it at that.
22:36:59mjijacksonevan: perhaps they say it more to the Java crowd than to the Ruby crowd.
22:37:29mjijacksoni know i would
22:37:34jakedouglasi don't really see anything wrong with saying you're committed to a particular platform
22:38:08mjijackson"ha! we're all working in java but *i'm* really using jruby!"
22:39:11mjijacksoni dunno
22:39:41brixenmjijackson: I realize each platform has peculiarities and special considerations
22:39:55brixenmjijackson: I'm concerned with that moniker though
22:40:06brixenwe don't say I'm a Windows Rubyists for example
22:40:20jakedouglasbrixen: is it really so different from calling yourself a 'rubyist' in the first place? (which i think is equally silly)
22:40:30brixenadmittedly, I'm pretty adamant about the whole "Ruby is Ruby" thing :)
22:40:45brixenjakedouglas: yep, I think it's quite different
22:40:47mjijacksonbrixen: i understand. the "jrubyist" term is a bit strange.
22:47:57BrianRice-workReia is probably the only real edge case
22:59:39evanmjijackson: you playing with anything specific in rubinius?
23:00:57mjijacksonevan: not really. just running the specs now and figuring out where work needs to be done.
23:01:59mjijacksonlanguages are kind of a hobby of mine, and i've been wanting to take a closer look at the rubinius source for a while.
23:02:47mjijacksoni'm interested in working towards 1.9 compatibility mainly.
23:03:09brixenexcellent
23:03:15brixenwe need encodings :)
23:03:30brixenand the rubyspecs have a nice with_feature guard
23:03:39brixenso you could actually start working on encodings in master
23:03:43mjijacksonbrixen: :) baptism of fire, eh?
23:03:52brixenit's not really a language feature
23:04:02brixenmjijackson: glory man :)
23:04:16brixenalso, glory, man
23:04:59krainboltgreeneflexes his design skillz.
23:05:23brixenkrainboltgreene: hopefully you have on a stretchy t-shirt
23:05:35brixenyou don't want to frighten folks with a shirt tearing off
23:05:44krainboltgreeneA ripped stretchy t-shirt. With the _why foxes on it.
23:05:45evanHulk style
23:05:50brixenheh
23:05:52evanHULK LIKE FOXES
23:07:43evan|Blaze|: Hulk is savvy with his word play.
23:07:51brixenor really big when they get angry hulk-like foxes
23:09:10evansee
23:09:18evanHulk is clever.
23:12:10mjijacksonIs the goal of RubySpec to be true to the bugs? For example, I'm looking at a bug that exists in 1.8 but was fixed in 1.9. There's a spec that was written to reproduce the bug.
23:12:22mjijacksonunder 1.8
23:12:49evanwhich one?
23:12:55evanthere is no hard and fast rule
23:13:15mjijacksonHash#merge! Inside Iterator Can Cause RuntimeError
23:13:21mjijacksonhttp://redmine.ruby-lang.org/issues/show/1535
23:13:23brixenrubyspec does not spec bugs, it always specs correct behavior
23:13:36evanoh that one.
23:14:29mjijacksoni see. in this it's debatable whether or not this was a bug in 1.8, so the spec exists to ensure the same behavior. right?
23:15:00brixenwhich spec?
23:15:58mjijacksonbrixen: spec/ruby/core/hash/merge_spec.rb
23:16:19mjijacksonline 63
23:16:36brixensee the ruby_bug guard?
23:16:43mjijacksonyup
23:16:58brixenthat guard does not yield on MRI less than 1.8.8
23:17:09brixenthe spec is for the correct behavior
23:17:16brixenall alt impls are expected to pass it
23:18:25mjijacksonwhy did it show up when i ran all the specs?
23:18:37brixenwhat did you use to run the specs?
23:19:03mjijacksonbin/mspec tag --list fails :files
23:19:11brixenok, so rbx
23:19:25mjijacksonif rubinius currently targets 1.8.7, that spec should not have run, right?
23:19:26brixenrbx is an alt impl, it is expected to pass it, but it does not
23:19:46brixenum, let's start with the command you ran
23:19:51brixenhave you read about rubyspec?
23:20:01mjijacksonbrixen: a little
23:20:10brixenok, so this is probably confusing then
23:20:18brixenyou should read up at rubyspec.org docs
23:20:23mjijacksonk
23:20:34brixenbut basically, mspec tag --list is listing tags for specs that fail
23:20:47brixenthat's what you asked it to do
23:21:06brixenthe spec is tagged because rbx does not pass it yet
23:21:28brixenthe spec is *guarded* because it was considered a bug in MRI and is fixed in later versions
23:21:46brixenthe guard prevents the spec from running on MRI versions that have the bug
23:21:55brixenbut the spec is expected to pass on all alt impls
23:24:11mjijacksoni don't understand. that spec will fail on versions that don't have the bug.
23:24:35mjijacksonseems like it should run on versions that have the bug, and not run on versions after the bug was fixed
23:25:52brixenrubyspec contains specs for only valid behavior
23:26:04brixenwe do not write specs that "pass" for bugs
23:26:12brixenmake sense?
23:26:28mjijacksonyes
23:26:30brixenok
23:26:45brixenversions of MRI that have bugs have already been released
23:26:55mjijacksonk
23:27:03brixencan't go back and fix a bug in an already released version
23:27:05brixenright?
23:27:07mjijacksonk
23:27:09brixenok
23:27:27brixenso, ruby_bug guard does not yield on versions with the bug
23:27:49brixenotherwise, the spec would fail, but there is nothing you can do to make it pass, so it's noise
23:27:50mjijacksonright
23:28:20brixenthe ruby_bug guard *always* yields if it is not running on MRI
23:28:35brixenie, if it's running on rbx, the guard yields and the spec runs
23:28:44brixenthe spec is expected to pass
23:28:51brixenbecause it's describing the correct ruby behavior
23:29:08brixenstill make sense?
23:29:31brixenwe have 2 more steps to go :)
23:29:56mjijacksongot it
23:30:07brixencurrently, rbx fails that spec
23:30:17brixenso we have it tagged so that CI process does not run it
23:30:26brixenso we can run a "known good" set of specs
23:30:42brixenmspec tag --list will list specs that are tagged
23:30:49brixenwhich is why it showed up for you
23:30:57mjijacksoni see
23:31:05brixenif you run mspec core/hash, the spec will run and you'll see a failure
23:31:11mjijacksoni told it to show me the specs that are tagged as failing
23:31:15brixenif you run mspec ci core/hash, the spec will not run
23:31:19brixenyep
23:32:03brixenthe tags are a way to select a particular set of specs to run per implementation
23:32:15brixenie, jruby has its own tags and may pass that spec
23:32:33brixenthe guards are for stuff that has to work across implementations
23:32:50brixenplatform, OS, endianness, word size, etc
23:37:31mjijacksonbrixen: i see. thx for your patience in explaining all this to me. there's a lot to learn coming from ruby userland.
23:39:46brixenabsolutely
23:39:49brixenno problem
23:40:02brixenit's quite a complex topic as well
23:40:13brixenhard to make everyone play nice together :)
23:40:29brixenand even harder to figure out what the heck in "Ruby" sometimes
23:40:35brixens/in/is/
23:41:47mjijacksontrue. hence the need for rubyspec.
23:43:30mjijacksonbrixen: just curious: are you or evan working out of SF?
23:43:50brixenI'm typically in portland, or and evan is in LA
23:44:05brixenwe're gonna be in SF mid next month
23:44:32mjijacksoni see. telecommute! that's the way to do it.
23:44:48brixenheh, it can be nice
23:45:09mjijacksoni'm actually moving to SF next month. i know EY is based there, so i was just wondering if you guys were around
23:45:18brixenah cool
23:45:28brixenwe try to get there about once a month
23:45:51mjijacksonare either of you planning on speaking at RubyConf about rbx?
23:46:04brixenI've submitted a proposal
23:46:19evanit's very likely i will be
23:46:31mjijacksonit would be totally awesome to have a talk geared toward getting rbx newbs involved in the project
23:46:31evanI gotta keep up my streak.
23:46:50evanmjijackson: what would ya like to hear about?
23:49:10mjijacksonevan: would be awesome to see a walk through of the mechanics of actually working on rbx
23:49:57mjijacksonhighlight areas where people can make contributions
23:50:11brixenevan: btw, did you use a mic for your screencast?
23:50:39brixenmjijackson: we like people to do something they are really interested in, rather than us saying, "work on x, y, z"
23:50:51evanbrixen: just the computer's builtin mic.
23:50:52brixenmjijackson: if you have a ruby project, run it on rbx
23:51:00brixenevan: ok, cool, cus it was really clear
23:51:05mjijacksonbrixen: that's a good strategy
23:51:23brixenI'll probably get a mic but maybe I should try a screencast without it
23:51:27mjijacksoni've been testing all my gems on rbx before releasing
23:51:30brixenI could do a bunch on rubyspec
23:51:35mjijacksonso far haven't had any problems with it
23:51:38brixenmjijackson: ah, cool!
23:52:26mjijacksonbrixen: the rubyspec project would be an excellent topic for rubyconf.
23:52:56brixenI did a talk a couple years ago
23:54:11brixenhttp://rubyconf2008.confreaks.com/what-does-my-ruby-do.html
23:54:43mjijacksonawesome. i'll take a look
23:55:35mjijacksong2g for now. we'll talk more later
23:55:38mjijacksonthanks again
23:56:15brixenn/p