Index

Show enters and exits. Hide enters and exits.

16:59:21evanmorning
17:01:01rueGood 70,92h
17:02:09evan:)
17:17:48brixenmorning
17:22:35evanbrixen: thoughts? http://gist.github.com/325369
17:24:12evanall those specs seem unnecessary
17:27:03brixenhmm
17:27:23brixenyes
17:27:40brixenspecs for methods should spec expected args
17:27:48brixenno specs for "undefined" methods
17:28:17brixengenerally
17:28:32brixenthe spec for interpolation calling #to_s is borderline
17:28:55brixenI don't see a point in the NoEach specs
17:29:08brixenjust spec that #each is called
17:30:49evanright, and thats done above.
17:31:08evanbut why the specs for ArgumentError?
17:31:16evanthey seem entirely unnecessary
17:31:44evanoh, I removed the #to_s one because the spec ABOVE it tests that #to_s is called.
17:32:47brixenah ok
17:33:03evanso, let me discuss briefly why i hit these
17:33:03brixenyes, ArgumentError specs for arity are a no-no
17:33:31evani changed our Kernel#method_missing to be able to detect a private call
17:33:32evanie
17:33:46evan"foo 1" now raises a NameError, like in MRI.
17:33:55brixenahh
17:34:06evanBUT it complicates things
17:34:27evanbecause, for instance, our Enumerable calls each as "each { ... }"
17:34:34evanand thusly will raise a NameError if there is no #each
17:34:39evanwhere as MRI does not do that
17:34:47evanbecause rb_funcall always raises NoMethodError
17:35:00brixenhmm
17:35:08evanso it's a choise of never raising NameError
17:35:17evanor raising NameError a lot more often than MRI does
17:36:25brixenwell, since a NoMethodError is_a NameError, seems like it shouldn't be too bad to substitute NameError
17:36:37evanagreed
17:36:41evanthat was my thinking
17:36:47evanthe only wrinkle is people that do
17:36:50evanrescue NoMethodError
17:36:57brixenhmm
17:37:04evanthat is a latent bug
17:37:09brixenyeah
17:37:16evanso we could always just deal with it if it's reported
17:37:29rueIllustrating, once again, the dangers of both inconsistent error usage and the precariousness of caring about which error exactly occurred
17:37:40evanrue: *nod*
17:37:47brixenevan: well, what about setting up an exception that would be called if dispatch failed
17:38:08brixencan you know ahead of time, "if nothing interferes, if this fails, raise NameError"
17:38:27evannot sure what you mean
17:38:47brixenI'm trying to sort out when to call NME and when NE
17:38:53evanah.
17:38:55brixener raise
17:39:25brixenso that sending #each {} would raise NME
17:39:26evanby setting up to you mean a config variable?
17:39:27brixeneg
17:39:35evanah.
17:39:37evanug.
17:39:51evanyou'd just change #ecah {} to self.each {}
17:39:56evanand now in raises NME
17:39:57brixenwell, you have that exception state vs current exception now
17:40:01brixenjust thinking out loud
17:40:04evanif you wan to control it
17:40:05evansure
17:40:08evanyou've got control
17:40:14brixenhm
17:40:15evanjust use self. to use NME
17:40:30evanwhich we can do in Enumerable
17:40:44brixensure
17:40:46evanit's just a little gross having to use the verbose syntax
17:40:47brixenbut that's confusing
17:41:05brixenit's gross and nothing explicit about why we're doing self.blah here and there
17:41:14evanyep
17:41:20brixenbut I dislike the latent bugs from not supporting MRI oddities
17:41:22brixenle sigh
17:41:54brixenlike defined?(X) not calling #const_missing, but defined?(A::X) calling it
17:42:09evanwell, that makes sense to me
17:42:23brixendefined?(X) still does total search, it just doesn't call #const_missing
17:42:31evanright.
17:42:40brixenand if A doesn't define it, Module#const_missing is called
17:42:46brixenthe exception is just swallowed
17:42:56dbussinkevan: looks like someone has a reliable crash: http://github.com/evanphx/rubinius/issues#issue/204
17:43:26evandbussink: wtf is this code.
17:43:27evan:(
17:44:03evanok
17:44:11evanwell, i'm off for the rest of the day shortly
17:44:14evanso i'll look at that tomorrow
17:44:30dbussinkevan: looks like it crashes during gc
17:44:34dbussinkok, have a nice day :)
17:44:37evanyep, i see.
17:44:58brixenevan: so, for defined?(), would you prefer 2 primitives, or one primitive that takes a flag for when to call #const_missing?
17:45:09brixener defined?(A) et al
17:45:30evanseems like a flag
17:45:33brixenk
17:45:34evanif thats the only difference
17:45:38brixenthat's what I was thinking
17:45:52brixenwell, I think that's the only difference
17:46:18brixenI've got 246 expectations now
17:46:29brixen5f/4e to fix
17:47:20evansweet!
17:47:52brixenoriginally 43 expectations, so we have a wee bit more coverage now
17:48:07evanhehe
17:48:45brixenI refactored defined?() in general for when it needs to produce values yesterday
17:49:05brixenI'll finish up defined?() for constants now that I can see more clearly
17:49:09evanrad.
17:49:36evani'm still pushing on rails 3
17:49:42brixensweet
17:49:42evangot activemodel to pass
17:49:45brixennice!
17:51:27evanle sigh.
17:51:41evanmore subclasses violating the contract of the superclass
17:52:17evansubclass Array, override #sort! to take an argument, then call #sort
17:52:25evanour #sort does dup.sort!
17:52:31brixenugh
17:52:34evanthus hitting the subclasses #sort!
17:52:39evanand raising an ArgumentError
17:54:18evanpeople really need to use their own method names
17:54:36evanand stop reusing the superclasses method names when the method IS NOT THE SAME.
17:54:46brixennames are hard, let's use Ruby's
17:54:46evanthere is absolutely no reason for this method to be called #sort!
17:55:07dbussinkevan: rails3 stuff?
17:55:15evanyep
17:55:32dbussinkevan: you should bitch wycats to get rid of it :)
17:55:36evani do.
17:55:38evan:D
17:56:10evanin this case, it's actually mail
17:56:13evanit does
17:56:18evanclass PartsList < Array
17:56:23evanthen mucks about.
17:56:35evanpretty needlessly.
17:56:48dbussinkthe wonders of c implementation hiding this
17:58:49evanyeah
17:59:03evanwell, I think i'll have to write a blog post about this.
18:00:09dbussinkevan: i guess PartsList could also very well have an array internally and duck type where needed right?
18:02:29rueI think there was a post about Composition > Inheritance already :)
18:04:18evandbussink: yep.
18:04:43evanif it IS an Array, fine, subclass, but don't break the superclass method contracts
18:05:03evanin this case
18:05:12evaneven if they didn't have #sort! take another arg
18:05:14evanwe still have a problem
18:05:20evanbecause they use #sort in their #sort!
18:05:27evanbut our #sort is implemented with #sort
18:05:35evanso that is a design flaw in our code too.
18:05:54evaner. our #sort is implemented with #sort!
18:06:20evani think we'll need to do a little renaming and using some internal helpers and aliases
18:06:25evanfor this pattern
18:06:27evanwell, i'm off
18:06:33evanbe back later tonight
18:07:31brixenyeah, generally we can't implement our methods using other API methods
18:07:41brixenthat lead to a lot of troubly with Hash too
18:07:50brixentroubly?
18:07:53brixenanyway :)
18:09:04dbussinkbrixen: sound troubly to me
18:09:11brixenheh
18:10:19jvoorhishello
18:10:41jvoorhisevan: this reminded me of our conversation about my 'functional' version of ruby-llvm: http://www.yosefk.com/blog/api-users-api-wrappers.html
18:10:51jvoorhis(the version that is no more)
20:33:34kstephens1http://github.com/evanphx/rubinius/issues#issue/204 : is generated code, sorry for the lack of formatting. :)
20:34:37kstephens1I'm writing a performance survey of common ruby code idioms and how they perform across different Ruby implementations.
20:35:27benschwarzevan: !