Da
Show enters and exits. Hide enters and exits.
| 00:00:03 | dgtized | hmm ctrl-c seems to be broken again somewhere mid spec run |
| 00:01:45 | marcandre | evan: Just to let you know, 1.8.7 is done (with the exceptions of Process#exec and GC#stress= which raise NotImplemented errors) |
| 00:02:13 | boyscout | CI: ff156e9 success. 2683 files, 10346 examples, 32917 expectations, 0 failures, 0 errors |
| 00:04:09 | brixen | marcandre: sweet |
| 00:04:29 | marcandre | :-) |
| 00:05:33 | evan | marcandre: hurray! |
| 00:05:45 | evan | marcandre: how are you sure it's done? |
| 00:07:59 | marcandre | Well, I've checked the list of changes twice |
| 00:08:22 | marcandre | There are two methods that were missing from the list, actually. |
| 00:08:38 | marcandre | Three, if you count the undocumented Hash[] |
| 00:09:02 | marcandre | So unless there are more surprises... |
| 00:23:18 | evan | marcandre: hehe |
| 00:23:18 | evan | ok |
| 00:59:08 | evan | rspec makes me cry to often |
| 00:59:19 | evan | the specs should be EASY to figure out |
| 00:59:20 | evan | now hard. |
| 00:59:56 | brixen | rspec' specs or rubyspecs ? |
| 01:00:04 | evan | rspec specs |
| 01:00:08 | evan | i'm running extlib's specs |
| 01:00:12 | evan | trying to figure out the crash |
| 01:00:13 | evan | it's going well |
| 01:00:27 | evan | but i'm at the point where I need to figure out what the ruby code is expecting to do |
| 01:00:35 | evan | which is... not as easy as it should be. |
| 01:00:44 | brixen | ah I see |
| 01:01:37 | evan | like, wtf is |
| 01:01:39 | evan | action { ... } |
| 01:01:44 | evan | is that a normal rspec thing? |
| 01:02:23 | evan | this one spec seems to define it... |
| 01:02:43 | evan | why? no fucking clue. |
| 01:03:02 | evan | these specs are... |
| 01:03:03 | evan | wow. |
| 01:03:18 | evan | if the intend was to make them completely opaque to the next guy |
| 01:03:22 | evan | mission accomplished. |
| 01:04:18 | brixen | it "is very hard to understand" do ... end |
| 01:04:19 | evan | Next on TNT: When good specs go bad. |
| 01:04:29 | brixen | heh |
| 01:04:42 | brixen | sounds like a good jerry springer actually |
| 01:05:28 | evan | seriously |
| 01:05:30 | evan | look at this: http://github.com/datamapper/extlib/blob/64dc233929d9549c40bf7c559cbd64b21b30e3be/spec/lazy_array_ spec.rb |
| 01:05:58 | evan | this feels like they've composed an ever harder to understand testing layer ON TOP OF rspec |
| 01:08:59 | brixen | that is... so wrong |
| 01:09:03 | brixen | my goodness |
| 01:09:52 | brixen | why would you write a method that wraps one it block |
| 01:10:03 | brixen | there are shared describes |
| 01:10:30 | brixen | but then, extlib is pretty gross imho |
| 01:10:32 | evan | this whole thing seems to be so they don't have to use return values |
| 01:10:42 | evan | ie |
| 01:10:46 | evan | ary = @lazy_array.dup |
| 01:10:57 | evan | ary.should_be_kind_of(LazyArray) |
| 01:10:59 | evan | is that so hard? |
| 01:13:55 | brixen | it's really hard to conceive of code like this |
| 01:14:07 | brixen | in a way, it's nice people write it |
| 01:14:15 | brixen | otherwise I'd swear it was impossible |
| 01:14:46 | evan | yeah. |
| 01:18:06 | evan | this code is.. |
| 01:18:11 | evan | blargian. |
| 01:29:22 | dgtized | I get a "not supported yet" somewhere in the middle of the spec runs with -Xjit.enabled -- I'm guessing this is intended? |
| 01:29:59 | evan | yep |
| 01:30:13 | evan | just means the JIT hit a method it didn't know how to JIT |
| 01:30:19 | evan | i'm just missing one thing |
| 01:30:22 | evan | to get that all done |
| 01:30:28 | evan | set_call_flags |
| 01:30:31 | evan | to support |
| 01:30:36 | evan | ary[*a] = 3 |
| 01:31:40 | dgtized | k, just checking all was well -- other then that it works fine |
| 01:32:04 | evan | yay |
| 04:39:55 | headius | anyone know llvm C++ API well? |
| 07:00:55 | evan | dbussink: yay, finally found and fixed that LazyArray problem. |
| 07:12:27 | boyscout | Stub out ObjectSpace._id2ref - 609f6f1 - Evan Phoenix |
| 07:12:27 | boyscout | Be much more careful about not changing obj_type_ - e2b55c6 - Evan Phoenix |
| 07:18:49 | ddub | night everyone |
| 07:18:52 | ddub | for whom it is night |
| 07:19:03 | evan | nite |
| 07:23:59 | boyscout | CI: e2b55c6 success. 2683 files, 10346 examples, 32917 expectations, 0 failures, 0 errors |
| 16:50:27 | evan | morning. |
| 17:05:07 | brixen | morning |
| 17:10:34 | evan | so, what should the JIT do when there is a fork() |
| 17:11:05 | evan | restart the background thread in the new process? |
| 17:11:26 | brixen | seems reasonable |
| 17:12:15 | evan | ok |
| 17:05:01 | rue | There are some differences between platforms on how threads behave after a fork |
| 17:06:18 | rue | It would probably be best to enforce that, plus do some type of restart for the background thread(s) |
| 17:09:56 | rue | Could either kill them with a warning, or maybe even raise. Technically I suppose it would be possible to replay the execution state but it seems of dubious merit |
| 17:11:28 | rue | I have no doubt around 50-75% of users who have more than one thread running when forking would :P |
| 17:12:10 | rue | There is the question of system and ` though, I suppose |
| 17:17:41 | rue | Such a waste for those, too |
| 17:27:40 | sandal | evan: another newbie question that google failed to answer for me. |
| 17:27:49 | sandal | Is Rubinius running on Windows? |
| 17:28:16 | sandal | (I absolutely don't have that need, it's just for my talk) |
| 17:28:21 | brixen | sandal: not yet |
| 17:28:25 | brixen | we plan to |
| 17:28:36 | sandal | brixen: is there any concrete plan or is it just a goal for the future? |
| 17:28:48 | brixen | it may be possible to compile under cygwin now |
| 17:29:08 | brixen | the concrete plan is to have a goal to run in the future :) |
| 17:29:18 | sandal | I can try it under msys and report back if you'd like |
| 17:29:25 | brixen | sure |
| 17:29:44 | brixen | one issue will be getting rake to run |
| 17:29:45 | sandal | but windows is certainly not *supported* right now, is that right? |
| 17:29:50 | brixen | right |
| 17:31:13 | sandal | brixen: about that SomeClass#name= , should I ask on ruby-core as to whether that should be left undefined? If Matz says yes, it'd make a stronger case for Rubinius doing what it does now |
| 17:31:31 | brixen | sure |
| 17:31:39 | sandal | (and if he says no, I'll contrib to RubySpec) |
| 17:31:50 | brixen | it seems reasonable to me that if you override a defined method, you get what you deserve |
| 17:32:00 | sandal | yeah, I think so too. |
| 17:32:38 | sandal | I just feel itchy because every other implementation I've tried doesn't fail. |
| 17:33:06 | brixen | right |
| 17:33:21 | brixen | for the same reason MRI doesn't fail: they aren't written in ruby |
| 17:33:27 | sandal | :) |
| 17:33:37 | sandal | It's a pretty interesting issue |
| 17:40:12 | sandal | brixen: if it is undefined behavior, would it be possible to make it a little more friendly on the rubinius side? |
| 17:40:24 | sandal | so that attr_accessor :name would blow up with an error? |
| 17:40:40 | sandal | Or is that a slippery slope due to the 800 ways that name= can be defined? :) |
| 17:40:40 | brixen | possible I suppose |
| 17:40:45 | brixen | right |
| 17:40:53 | brixen | it blows up as it is |
| 17:41:03 | sandal | well, it blows up when you call it |
| 17:41:10 | brixen | yeah |
| 17:41:18 | sandal | I guess that's already okay |
| 17:41:56 | sandal | I really don't mean to push this issue. It's not that I think there's a problem with rubinius |
| 17:42:08 | sandal | I'm just uncomfortable with weird undefined behaviors in ruby :) |
| 17:42:26 | sandal | but I guess that's the price that comes with power and flexibility |
| 17:44:13 | brixen | yeah, it is |
| 17:44:25 | brixen | most languages would just disallow it entirely |
| 17:44:38 | brixen | but the fact remains, you have to play nice with other code |
| 17:44:49 | brixen | and in rubinius, other code is often ruby |
| 17:51:50 | sandal | brixen: For RubySpec, how do you guys figure out what behaviors are intentional and what are undefined? |
| 17:51:57 | sandal | Just ask matz whenever it's not crystal clear? |
| 17:52:04 | brixen | yeah |
| 17:53:25 | sandal | man, you guys really have your work cut out for you. :) |
| 17:54:16 | brixen | sandal: haha yes, indeed |
| 17:54:20 | sandal | http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/23593 |
| 17:56:06 | headius | why can't name= work? |
| 17:56:51 | headius | it's just a method added/replaced on class |
| 17:56:57 | brixen | headius: it's defining Module#name= and there is already a Module#name |
| 17:57:02 | headius | brixen: so? |
| 17:57:32 | headius | so store it in something else |
| 17:58:11 | headius | well, I'm not trying to be a dick, it just seems arbitrary |
| 17:58:14 | headius | this is ruby |
| 17:58:17 | headius | people do this stuff |
| 17:58:28 | headius | if it's not Class.name= today it will be something else tomorrow |
| 17:59:25 | headius | well, I would presume making monkey-patching of code methods undefined on a per-method basis is not the way to go |
| 17:59:33 | brixen | the point is asking what is expected if you override methods that exist in Ruby itself |
| 17:59:59 | headius | you mean like the oft-debated replacing of Fixnum#+ that everyone adamantly defends? |
| 18:00:07 | brixen | in this case, the way attr_accessor works steps on the existing Module#name |
| 18:00:23 | headius | it seems like we've been though this all a dozen times |
| 18:00:30 | headius | buyer beware, certainly, but it should work |
| 18:01:15 | headius | I'm not being gruff |
| 18:01:16 | sandal | A problem I see here is that it doesn't necessarily need to appear so evil |
| 18:01:25 | sandal | as in my example, a subclass or anonymous class still breaks |
| 18:01:45 | headius | well, that's not my fault, I'll add a smily to ever sentence :) |
| 18:01:51 | sandal | I feel like perhaps name should have a __name__ used internally |
| 18:02:02 | sandal | (In Ruby in general) |
| 18:02:06 | headius | so perhaps we agree that name isn't itself special ;) |
| 18:02:09 | brixen | the fact that it works in MRI is happenstance, I would dare say not intended |
| 18:02:19 | headius | well, MRI doesn't store name in an ivar |
| 18:02:22 | headius | :) |
| 18:02:25 | sandal | Because I usually don't think of changing a method on an anonymous subclass should break |
| 18:02:29 | brixen | the fact that it works in other impl is for the same reason as it works in MRI |
| 18:02:44 | sandal | But since name has a special meaning, I understand. |
| 18:02:48 | brixen | because there is a big separation between the language and it's implementation |
| 18:02:57 | brixen | it's fair to explore the issue |
| 18:03:00 | sandal | just, we've managed to do better about things like id and send |
| 18:03:02 | brixen | not just say, it should work |
| 18:03:03 | headius | so if it breaks on other impls that do store it in an ivar that seems to indicate that the other impls are divergent, and would have to cope with things like this, no? :) |
| 18:03:15 | brixen | divergent how? |
| 18:03:32 | headius | because the ivar table contains different things than in MRI |
| 18:03:45 | headius | so people expecting MRI's ivar table contents would see different behavior |
| 18:03:48 | headius | as in this case |
| 18:03:58 | brixen | the ivar table is a symptom in this case |
| 18:04:01 | brixen | it's not the issue |
| 18:05:23 | headius | perhaps I've misunderstood the intent of sandal's post? |
| 18:05:42 | brixen | the fact is, MRI and other impl are quite limited in how you can monkey patch them |
| 18:06:00 | headius | I have a knee-jerk reaction when someone says this behavior should be "undefined" because rbx is implemented in such a way that it breaks some piece of code that works on all other impls |
| 18:06:05 | brixen | so it's a little odd to say, I want to monkey patch however I want and I want it to work |
| 18:06:30 | headius | it just seems arbitrary in this case |
| 18:06:48 | brixen | because in fact, you can't monkey patch a lot |
| 18:06:50 | headius | sandal's post seemed to suggest that |
| 18:07:10 | headius | but perhaps just as one among many possible scenarios |
| 18:07:17 | sandal | headius: I don't know what the right behavior is. |
| 18:07:26 | sandal | Honestly, I think it should work like send and id |
| 18:07:29 | headius | I'll say it this way: I think it should work like MRI |
| 18:07:32 | brixen | the question is: what can I expect if I do this |
| 18:07:34 | sandal | (err object_id) |
| 18:07:57 | brixen | if the answer is: you can expect nothing in particular, then the behavior is undefined |
| 18:07:57 | headius | sandal: I don't feel like name is a particularly crucial method |
| 18:07:59 | sandal | it'd be nice if there were a lower level __name__ method or something that everything depended on |
| 18:08:05 | brixen | you can match MRI, but you don't have to |
| 18:08:05 | headius | since Class.new classes don't have a name |
| 18:08:33 | brixen | sure they do, it's "" |
| 18:09:14 | sandal | headius: I'm not that invested in it. I wanted to confirm whether or not it was an undefined behavior for the purpose of my talk. |
| 18:10:02 | sandal | Because I was about to say one thing dangerous about using any alternative implementation is that you need to be aware of what is defined behavior in ruby and what isn't |
| 18:10:07 | headius | I sympathize, honestly |
| 18:10:19 | brixen | headius: keep in mind that if you want to pursue your dream of rbx on jvm, you would deal with these issue eventually |
| 18:10:28 | headius | we've had to change more things than I can count to be compatible, a lot of them uglying jruby's core |
| 18:10:30 | brixen | headius: so, you may have a different tune than it should work |
| 18:10:34 | sandal | (which isn't any of your faults, it's the consequence of building a spec based on an implementation) |
| 18:11:25 | headius | brixen: for three years we've been blindsided by these sorts of things...trust me, I've had to develop a thick skin |
| 18:11:53 | brixen | headius: well, to me that suggests a more thorough investigation than 'it should work' |
| 18:12:03 | brixen | but that's just me |
| 18:12:15 | headius | is this something they're defining on Module or Class? |
| 18:12:30 | headius | if it's defining it on Class it's just hiding the Module version |
| 18:12:32 | sandal | evan: not on Class. |
| 18:12:43 | sandal | on an instance of Class |
| 18:12:55 | sandal | (anonymous) |
| 18:13:06 | headius | if it's actually replacing the existing Module.name and .name=, I don't see that it should break anything but it's obviously questionable |
| 18:13:07 | brixen | it's a class, no different than Array |
| 18:13:17 | headius | er, well not replacing .name=, since that doesn't exist |
| 18:13:26 | sandal | evan: correct |
| 18:13:40 | headius | it seems like at worst what would be expected is that it would break all access to existing Module#name |
| 18:14:02 | sandal | something like: obj = Class.new(Test::Unit::TestCase); obj.extend(ClassMethods) |
| 18:14:03 | headius | I guess I'm only a little surprised that doesn't break anything, but it's certainly weird |
| 18:14:30 | headius | I think several of us have complained about the fact that assigning a nameless class to a constant sets its name |
| 18:14:42 | headius | that's a side effect of not having real access to the class's name value |
| 18:16:20 | headius | and maybe this will sound gruff, but this is exactly the sort of challenge you guys are going to keep facing...having a ruby core means people can do things like this that totally hose your kernel |
| 18:16:36 | headius | a ruby core is obviously a blessing and a curse |
| 18:17:32 | headius | but I've said my piece...I just didn't want this to be the start of defining certain core monkeypatching as "undefined" because it breaks something in rbx |
| 18:17:53 | headius | certainly |
| 18:17:58 | headius | and we've pushed back together on several things |
| 18:18:17 | headius | I could still be convinced, but on this case I don't see where there's real harm in letting this work like MRI |
| 18:18:26 | sandal | wow, since when does rspec thank me for downloading it? |
| 18:18:29 | sandal | that's special |
| 18:20:26 | headius | so here's a different question |
| 18:20:26 | headius | if we decide it should be allowed, should we start spec'ing these cases? |
| 18:20:26 | headius | I guess I'm wondering in general about how far rubyspec should go |
| 18:20:26 | brixen | yeah, it should |
| 18:20:26 | headius | it seems like this should go in |
| 18:20:26 | brixen | if it's a defined behavior of mri, it should be in rubyspec |
| 18:20:46 | headius | I was going to be snide and suggest we add a rubyspec that blows up when you have hash args in the method definition |
| 18:20:59 | brixen | evan: alias_method :name, :my_name :P |
| 18:21:01 | headius | since it technically should be a syntaxerror on any impl other than macruby |
| 18:21:21 | headius | but I don't know how far we go specifying error cases, and adding just this one would obviously be mean |
| 18:21:42 | brixen | headius: that's what deviates_on is for |
| 18:22:28 | headius | you could just make it all hideous with __ everywhere |
| 18:22:38 | brixen | the use in this case of #name is lame anyway, it's not a name it's a description |
| 18:22:42 | headius | hah |
| 18:22:59 | headius | no, I meant that def a(foo:b, bar:c) should be a syntaxerror |
| 18:24:31 | sandal | But if someone says my_class.__name = "Foo", they deserve to be punched in the face |
| 18:24:44 | headius | right |
| 18:24:52 | headius | you'd have to be going out of your way to break it |
| 18:25:29 | rue | headius: Did you see the merbist article? :/ |
| 18:25:41 | headius | rue: inspirational, truly |
| 18:25:42 | sandal | BTW, folks asked me the other day about MacRuby 0.5 and Prawn's examples / tests. |
| 18:25:52 | sandal | It just totally doesn't work at all |
| 18:25:56 | sandal | Many missing stdlibs :-/ |
| 18:26:10 | headius | well, that's not surprising...it's a very partial impl so far |
| 18:26:21 | sandal | Then how the fuck is it the fastest Ruby ever? |
| 18:26:33 | headius | that's an excellent question |
| 18:27:11 | sandal | sighs... I've been getting really mad writing this talk. Not because of anything you implementers have done |
| 18:27:21 | sandal | but because of what I've read from random people |
| 18:27:43 | sandal | Seems like everyone likes to consult the magic 8-ball and act like it is fact |
| 18:28:35 | headius | at any rate...I don't really care all that much about Module#name because whatever's decided won't affect jruby |
| 18:29:29 | headius | sandal: I think in macruby's case there's a small group of really vocal advocates hyping it absolutely to death |
| 18:29:47 | headius | not really anyone that does day-to-day dev either, which is sad |
| 18:30:00 | sandal | It's a shame, because as a result of that hype, I've been going on a wild goose chase looking for something positive to say about it |
| 18:30:07 | sandal | there are good things I've found |
| 18:30:14 | headius | well, be sure you don't say something bad ;) |
| 18:30:15 | sandal | but buried under a mountain of unfounded hype |
| 18:30:21 | headius | I still have the scars |
| 18:30:36 | sandal | hah, that's how I feel about this whole talk. I didn't know what I was signing up for :) |
| 18:30:47 | scoopr | what's your talk? |
| 18:30:56 | sandal | But to both JRuby and Rubinius credit, I have mostly all good things to say |
| 18:31:17 | sandal | and MacRuby I'll be nice to as well, just I'm totally not into the "Let's get excited about everything all the time" attitude |
| 18:31:47 | sandal | scoopr: http://www.goruco.com/speakers.html |
| 18:31:53 | headius | sometimes I look back at the past three years and wonder whether I should have been using Groovy |
| 18:32:01 | rue | sandal: There are a bunch of easy solutions to this particular problem, obviously, on both sides |
| 18:32:03 | scoopr | nice |
| 18:32:15 | rue | Not many easy /reusable/ solutions, though |
| 18:32:20 | lopex | groovy! |
| 18:32:24 | headius | lopex: :) |
| 18:32:38 | sandal | rue: that particular problem isn't that important. |
| 18:32:49 | lopex | headius: lets perform global personal rolback |
| 18:32:55 | lopex | er, rollback |
| 18:33:26 | sandal | But seriously, a big problem is trying to define what the fuck Ruby is anymore |
| 18:33:41 | sandal | I'm not of the opinion it needs to be one, centralized thing. |
| 18:33:41 | rue | "Anymore"? :) |
| 18:33:45 | lopex | disease |
| 18:34:06 | sandal | Well, I felt like when I first started Ruby in 2004, at least in the practical sense, Ruby was Ruby |
| 18:34:12 | sandal | whatever the latest stable release was |
| 18:34:19 | lopex | haha |
| 18:34:42 | sandal | but even within core ruby, there are now 3 distinct languages. |
| 18:34:51 | brixen | sandal: the fact that ruby doesn't know what ruby is does make it a tidbit harder for the rest of us |
| 18:34:58 | sandal | I'm edging towards my definition of Ruby.... |
| 18:34:59 | lopex | and macruby introduced another one |
| 18:35:13 | sandal | It's basically anything that passes an idealized version of RubySpec that is 'complete' |
| 18:35:52 | sandal | I don't care :) |
| 18:36:24 | sandal | The thing is, we need an operational understanding of what Ruby means, otherwise, you implementer folks will be chasing your tails forever |
| 18:36:42 | brixen | well, and so will users in fact |
| 18:36:46 | headius | I won't do this forever :) |
| 18:36:51 | brixen | you write your code expecting it will run |
| 18:36:55 | sandal | right, I'm trying to suggest that these issues matter to users |
| 18:37:05 | sandal | It goes all the way down the chain |
| 18:37:36 | sandal | You know how much it pisses me off that just because someone wants to use Object#tap I get complaints about 1.8.7 incompatibilities in my libs I maintain? |
| 18:38:04 | rue | sandal: Here is my reading: Module#name= is intentionally missing, ergo Module#name should always be the "real" name |
| 18:38:47 | sandal | rue: you're still on that, eh? :) |
| 18:39:04 | rue | Well, working on a pattern for solvin |
| 18:39:07 | rue | Solving* |
| 18:39:54 | rue | So redefining #name could cause problems |
| 18:40:21 | headius | sandal: we have two categories in our bug tracker for 1.8.7 and 1.9 |
| 18:40:37 | lopex | and stable |
| 18:40:39 | lopex | :) |
| 18:40:45 | sandal | headius: That's not really what I'm getting at. |
| 18:41:37 | headius | well, I mean we have two categories...because there's enough reports we just have to shunt them somewhere |
| 18:41:49 | headius | it's a nuisance until we get 1.8.7 support in |
| 18:42:09 | sandal | I guess what I'm saying is that ruby-core creates problems that aren't easily seen by users |
| 18:42:14 | headius | and then people may moan about any 1.8.6 breakage (though I haven't heard any concrete reports of breakage in a long time) |
| 18:42:26 | sandal | but are blindingly clear to maintainers and implementers |
| 18:43:02 | sandal | So to be honest, I don't particularly care about ruby-core for Ruby < 1.9.1 anymore |
| 18:43:32 | sandal | I think JRuby is likely a better Ruby 1.8.6 than MRI, or will be over time :) |
| 18:44:03 | sandal | And probably true of Rubinius as well, over time |
| 18:44:17 | sandal | evan: yeah, I think that's pretty obvious |
| 18:44:26 | sandal | But this isn't obvious to users. |
| 18:44:42 | sandal | yeah. syntax incompatibilities, yikes |
| 18:44:59 | lopex | we've gone through that |
| 18:45:07 | lopex | (discussion) |
| 18:45:26 | sandal | My final message though is ultimately that people are going to be forced to migrate to Ruby 1.9 if they want growth |
| 18:45:41 | sandal | or there will be a huge divide |
| 18:46:01 | sandal | The problem is, 1.8.7's existence has caused some maintainers to say "I'm dropping support for 1.8.6" |
| 18:46:10 | sandal | But others... "I'm not supporting 1.8.7" |
| 18:46:31 | sandal | combine that, and library wise you get a clear divergence moving forward on 1.8 |
| 18:47:01 | dgtized | a long time ago in a time just after fortran there was one lisp, then they multiplied, then there was the common lisp standard, and then there was scheme |
| 18:48:06 | sandal | I guess what I'm saying is you're looking at two languages now. and in between those two languages, you have a disfigured zombie language |
| 18:48:15 | sandal | (1.8.7+) |
| 18:48:32 | dgtized | I'm pretty sure it's the same story for smalltalk, and it's definitely the case for C and C++ to this day in terms of compiler specific language changes |
| 18:48:54 | sandal | Okay, so be it. But when do we stop pretending we can unify them? |
| 18:49:28 | dgtized | my point is simply that we can try our best, but historically languages diverge -- so we can try to go towards a set of standards, and let things flop around different ways along the fringe |
| 18:49:33 | brixen | well, it's not that hard to unify them |
| 18:50:06 | sandal | brixen: that's right, it's basically easy. But it requires serious discipline |
| 18:50:08 | brixen | you just need a definition and a way to check it |
| 18:50:13 | headius | I don't really understand who is the target market for 1.8.8 |
| 18:50:22 | headius | why wouldn't those people just move to 1.9 |
| 18:50:24 | dgtized | brixen: not _technically_ hard, or _socially_ hard? |
| 18:50:33 | sandal | headius: FUD about m17n |
| 18:51:20 | sandal | which is partially justified because it forces even those who believe all programs should be written in and speak only AMERICAN to understand the m17n system |
| 18:51:26 | sandal | since it interferes with binary processing |
| 18:51:56 | headius | yeah, m17n isn't perfect, but it worked out better than I expected |
| 18:52:03 | headius | at least from an API/usability standpoint |
| 18:52:05 | sandal | Oh, I'm actually happy with it. |
| 18:52:18 | headius | it's devlishly complicate behind the scenes though |
| 18:52:20 | sandal | It's just that it will undoubtedly break code whether or not you actually need charset support |
| 18:52:36 | sandal | this is why zombie ruby exists |
| 18:52:45 | sandal | for those who want 1.9 without the m17n |
| 18:53:11 | sandal | and since YARV isn't nearly as fast as people thought it would be a few years ago |
| 18:53:27 | sandal | the case for moving is less compelling |
| 18:53:30 | sandal | evan: Ruby 1.8.7+ |
| 18:54:10 | sandal | Right. the m17n system will never be ported to MRI |
| 18:54:11 | sandal | AFAIK |
| 18:54:12 | brixen | enumerators and hashes |
| 18:54:16 | brixen | yay |
| 18:55:05 | brixen | and various other bits, but don't you worry your prettly little head about those :) |
| 18:55:41 | brixen | :D |
| 18:55:47 | brixen | we have work to do! :) |
| 18:56:17 | brixen | Exception#to_str is being removed in ruby2 |
| 18:56:33 | sandal | evan: People don't want to migrate to Ruby 1.9 because they don't want to change their app to work with the m17n system |
| 18:56:44 | brixen | well, you could want the Exception to act like a string |
| 18:56:46 | sandal | so these feature backports let them touch Ruby 1.9 without having to do that |
| 18:56:54 | brixen | but now that we have it, why remove it? |
| 18:57:19 | sandal | evan: Either do I. |
| 18:57:56 | sandal | Honestly, I think that these releases exist to appease whiny masses of non-hackers |
| 18:58:43 | sandal | I'm just theorizing here |
| 18:58:58 | sandal | I'm trying to come up with a reason for 1.8.7 to ever exist |
| 18:59:21 | sandal | And sadly, that's the best I've come up witth |
| 18:59:40 | sandal | lots of features? |
| 18:59:50 | sandal | whoops, here are hundreds of features |
| 19:00:08 | sandal | that sounds more like a giant oil spill to me |
| 19:01:00 | sandal | Okay, but there is still a fundamental problem there. |
| 19:01:23 | sandal | It seems amazing to me that every six months or whatever a bump of the tiny version number means "Oh, basically, a new API" |
| 19:01:53 | rue | Well, it is only a problem if you assume the changes are backward-compatible |
| 19:02:00 | sandal | If that's the case, and the trend continues on 1.9.x, we need to be prepared to treat Ruby less like a programming language and more like some random open source project |
| 19:02:11 | sandal | rue: it's a problem for library maintainers. |
| 19:02:20 | rue | Previous to 1.8.8, the idea seems to have been that all changes could conceivably be monkeypatched to earlier versions |
| 19:02:36 | sandal | If I use any new shiny feature in Prawn, I force all my users to update their Ruby |
| 19:02:50 | rue | (Or provide a patch) |
| 19:03:02 | sandal | or I support various parallel versions, creating a huge maintenance headache for me |
| 19:03:27 | sandal | Right now we do basically provide patches for the few 1.9 features we use that aren't present in 1.8 |
| 19:04:52 | sandal | If this is the model we're going to work with, so be it |
| 19:05:00 | sandal | but I should be able to do gem update ruby |
| 19:05:15 | sandal | and gem "ruby", "=1.8.6" |
| 19:05:27 | sandal | (Not necessarily RubyGems, but you get what I mean, hopefully) |
| 19:05:44 | sandal | The bottom line is that since our infrastructure doesn't support that, it's nasty. |
| 19:06:02 | sandal | Package managers on distros don't keep up, etc |
| 19:07:31 | brixen | I would say there are 2 main issues: ruby svn head means "I haven't gotten around to merging this in yet", there is no real dev branch |
| 19:07:48 | brixen | and 2, there is no way to rigorously check that a change does not affect the API |
| 19:08:20 | brixen | so there is no good way to release "bug fixes" that only fix bugs but do not change any APIs |
| 19:08:47 | headius | in yarv's defense, they were faster a few years ago |
| 19:08:55 | brixen | if there were a real dev branch, you could plan releases, even roadmap them, with very explicit API changes |
| 19:08:55 | headius | ruby compatibility is a harsh mistress |
| 19:10:00 | sandal | headius: understandable. I think it's a natural progression. |
| 19:10:24 | sandal | headius: It's that the same hype mill convinced people that YARV was made out of cheetah blood |
| 19:10:33 | headius | and I suppose another defense of ruby-core is that there's practically nobody paid to work on any of those branches |
| 19:10:48 | sandal | brixen: Does ruby-core integrate RubySpec? |
| 19:10:53 | headius | I think there's only a few people paid to work on ruby at all |
| 19:11:02 | brixen | sandal: there's a makefile rule for running the specs |
| 19:11:17 | brixen | sandal: which says nothing about whether they are actually run |
| 19:11:22 | sandal | headius: Yeah, to be honest, I feel much better supported in the alternative distros simply because there are people around invested in it |
| 19:11:58 | sandal | In an ideal world, users would understand that if they want a consistent experience, they could look at a comparative feature battery of the rubyspec on a website |
| 19:12:10 | sandal | and see which implementations pass what, at any given release |
| 19:12:25 | sandal | infrastructure wise, this is something that could be built, I imagine |
| 19:13:21 | sandal | Basically, I envision a matrix with the major Ruby implementations on it, and red/green for every class and method |
| 19:13:29 | sandal | yellow for missing specs |
| 19:13:36 | brixen | what would be pretty ginormous |
| 19:13:41 | rue | rubyspecresults? |
| 19:15:30 | sandal | it'd need to be three dimensional though |
| 19:15:46 | sandal | by version number |
| 19:15:54 | sandal | (1.8.6, 1.8.7, 1.9.1, etc) |
| 19:16:23 | sandal | If I had that list as a library implementer, I could find out what functions have an agreed upon definition |
| 19:16:38 | sandal | Sure, I'd run into false-positives sometimes |
| 19:16:49 | sandal | but I could contribute to the RubySpec to fix that |
| 19:18:07 | brixen | it would be simpler to just show failures |
| 19:18:51 | sandal | brixen: sure, actually, it'd be nice to just type in Class#method and get back a report |
| 19:19:33 | brixen | yeah, data driven |
| 19:19:47 | headius | 81 files, 890 examples, 2484 expectations, 1 failure, 2 errors |
| 19:20:03 | sandal | It'd be nice to be able to pull up the actual specs, too |
| 19:20:07 | headius | macruby's frozen specs (plus their own specs) |
| 19:20:23 | sandal | (or a link to them) |
| 19:21:00 | sandal | I just feel like we could use this test-obsessed culture to provide a central definition of Ruby, even if its heterogeneous across version / implementation |
| 19:22:25 | brixen | sandal: mspec can emit results in yaml format, so we can easily build that |
| 19:22:40 | sandal | Maybe it's time to abandon old ways of looking at language definitions |
| 19:22:48 | brixen | we could also explore using test-anything-protocol rather than yaml |
| 19:23:17 | sandal | Maybe we can say "Ruby changes fast and isn't necessarily unified, but here is exactly where it differs" |
| 19:23:38 | sandal | I think that could be pretty revolutionary, honestly. |
| 19:23:47 | brixen | sandal: I believe it is better to apply pressure to make it consistent |
| 19:23:58 | brixen | again, all you need is a precise definition and a way to test that |
| 19:24:06 | brixen | it's not so hard to be consistent |
| 19:24:15 | sandal | brixen: I agree |
| 19:24:22 | sandal | but the pressure is implicitly implied here |
| 19:24:23 | brixen | it doesn't benefit anyone to have confusion |
| 19:24:26 | sandal | err |
| 19:24:28 | sandal | applied |
| 19:24:37 | brixen | so, make it explicit ;) |
| 19:24:44 | brixen | shame is a great motivator |
| 19:24:47 | sandal | Nah, I mean it comes from this |
| 19:24:54 | sandal | I look up Class#method |
| 19:25:01 | sandal | and I see it green across everyone but Rubinius |
| 19:25:11 | sandal | I'm absolutely sure that I'll come in here and say |
| 19:25:16 | sandal | "Guys is this an accident?" |
| 19:25:20 | brixen | yeah |
| 19:25:30 | brixen | but you could remove the looking up part |
| 19:25:34 | brixen | and just show what fails |
| 19:25:52 | sandal | I think that's a possible future goal |
| 19:25:59 | brixen | that is effective and at a glance |
| 19:26:04 | sandal | but right now your idea of a consensus is too pie in the sky |
| 19:26:13 | sandal | It doesn't exist. |
| 19:26:34 | sandal | I think it's necessary to show the inconsistencies first |
| 19:26:43 | brixen | there's a lot of consensus among the alt impls |
| 19:26:55 | sandal | True. |
| 19:27:08 | sandal | But I guess what I'm saying is it'd be beneficial to see the data |
| 19:27:31 | brixen | I agree, just saying showing only the failures is manageable information |
| 19:27:43 | brixen | you can assume the rest pass or are false positives |
| 19:28:08 | sandal | I see where you're going with this. I think that's primarily an interface concern |
| 19:28:13 | brixen | you can't know the false positive until you have a bug report and realize there is no spec for this |
| 19:28:22 | brixen | information desing |
| 19:28:26 | brixen | design |
| 19:28:36 | brixen | anyway, this laggy irc is pissing me off :) |
| 19:29:18 | sandal | Sure, though if tests for a method don't exist, you definitely want to show that |
| 19:30:17 | headius | probably also important to remember that rubyspec doesn't necessarily show what *won't* work on a given impl |
| 19:30:20 | headius | since it's not complete |
| 19:30:35 | headius | I'm sure we pass all the openssl specs, for example :) |
| 19:30:54 | sandal | headius: True. That's why I think no tests should be a negative result |
| 19:30:59 | sandal | (Or small tests) |
| 19:31:09 | sandal | At least, you should easily be able to inspect what the tests are |
| 19:31:12 | headius | yeah, hard to quantify it I suppose |
| 19:31:28 | headius | if openssl passes with a half-dozen assertions, it's probably not complete |
| 19:32:16 | sandal | Just allowing inspection of the specs easily solves most of this. You could have reports of methods which are not covered at all, methods which seem to have very light coverage, etc |
| 19:32:40 | sandal | I guess the value of all of this would be that users and library maintainers could get a sense of just how well defined a given function is |
| 19:33:05 | sandal | The purpose is not for a seal of approval, but to define a level of trust |
| 19:34:10 | sandal | as a maintainer, if I could easily pull up the specs for openssl (without having to dig for them), if someone reported a JRuby related openssl issue for one of my libs, I could say... "Go write some specs, and make sure they work on JRuby" |
| 19:34:31 | sandal | Sure, definitely not a silver bullet because at the end of the day, someone needs to do real work |
| 19:34:59 | headius | yeah, makes sense...the trust aspect is definitely one that's missing right now |
| 19:35:05 | sandal | But this sort of resource might lower the barrier to entry, and be a good gateway drug for getting people involved in actually writing specs |
| 19:36:07 | sandal | headius: for example, when people complained about JRuby issues with TTF embedding in Prawn |
| 19:36:22 | sandal | My response was "go away, JRuby not supported. Let me know if you find out what's wrong" |
| 19:36:33 | headius | heheh |
| 19:36:46 | sandal | Where if this resource existed, I might have looked through the methods I was using and said "Looks like a problem in foo()" |
| 19:37:52 | headius | tbh application-breaking compat issues are really rare for us now, so usually it's just something no library has ever tested |
| 19:37:57 | headius | no library/testsuite |
| 19:38:08 | headius | but that underscores the difficulty of establishing trust |
| 19:38:13 | headius | we don't know what we don't know |
| 19:38:18 | sandal | anyway, I should probably stop monopolizing this channel. ;) |
| 19:38:50 | sandal | I just really want to be able to answer that question of "What's Ruby?" |
| 19:39:02 | sandal | And I think that just being able to clearly see the scenery would help |
| 19:40:41 | sandal | headius: but honestly, I think that you should RubySpec out things like the macruby hash syntax :) |
| 19:43:34 | headius | hah |
| 19:43:36 | headius | I cannot |
| 19:43:39 | headius | I'm already on the blacklist |
| 19:48:55 | rue | Tsk |
| 19:48:59 | rue | It is the iBlack list |
| 19:49:39 | sandal | evan, headius, brixen, et. al. is this idea interesting enough where you'd participate if it existed? |
| 19:49:51 | sandal | I may try to seek funding for the project and go ahead and build it |
| 19:50:23 | headius | sandal: I will contribute a portion of my copious spare time :) |
| 19:50:33 | headius | but yes, I'm definitely interested |
| 19:52:33 | sandal | Cool, I'm going to bug my work about it then (and/or RubyCentral and the community in general) |
| 19:53:23 | sandal | I am totally out of my depth here, but I really believe in the idea. So long as I can get technical support, I'll try to clear the time for it |
| 19:53:47 | sandal | evan: I assume this is something EngineYard could donate hosting for, right? |
| 19:54:06 | sandal | given more details on what I actually hoped to do. |
| 19:54:43 | sandal | During development I could just use my own VPS but obviously I want to turn this thing back over to the community and have it hosted somewhere I don't need to babysit |
| 20:19:11 | brixen | sandal: EY is already hosting rubyspec.org, I don't see why it couldn't be integrated |
| 20:19:19 | sandal | brixen: awesome |
| 20:19:44 | sandal | I just talked to my work, and they basically said I can take some of my paid time to work on this, and that they'd donate some dev hours to it too |
| 20:19:59 | brixen | nice |
| 20:20:22 | brixen | you should try getting in touch with ryan lowe, the guy who started rubyspecresults.org |
| 20:21:01 | brixen | he's in this channel sometimes, or I can email him |
| 20:21:08 | sandal | brixen: interesting, please email him and CC me |
| 20:21:15 | sandal | gregory.t.brown at gmail.com |
| 20:21:18 | brixen | k |
| 20:21:48 | sandal | rubyspecresults is basically the end result output? |
| 20:22:52 | brixen | it's very alpha |
| 20:23:08 | brixen | the idea is to accept submissions from bots and present the data |
| 20:23:15 | brixen | it could have search etc |
| 20:23:23 | brixen | sandal: do you go by Greg or Gregory? |
| 20:23:44 | sandal | it's interesting. I really want to have a lot deeper functionality than that, though |
| 20:24:17 | sandal | brixen: I always go by Greg informally, but don't like when people write Greg Brown because of data integrity issues :) |
| 20:24:25 | sandal | So Greg if one name, Gregory Brown if both |
| 20:24:52 | brixen | heh, ok |
| 20:29:07 | brixen | hrm, it shouldn't |
| 20:30:12 | headius | evan: what exactly would be the purpose of a ruby_exe that runs something multiple times? :) |
| 20:38:32 | brixen | ugh |
| 20:44:06 | sandal | hah, I just got permission from my girlfriend to do this RubySpec web project :) |
| 20:44:15 | sandal | (probably more important than permission from work) |
| 21:19:04 | rue | evan: Trying to let the threads live through fork()? |
| 21:27:21 | rue | On error? |
| 21:36:28 | brixen | the dir creation method could rm the mock dir tree before it creates it |
| 21:36:38 | brixen | or we can have every spec create and remove that tree |
| 21:37:16 | brixen | hm, actually, it does attempt to remove it first |
| 21:37:32 | brixen | evan: what is the specific failure? |
| 21:39:00 | brixen | that must be a specific spec |
| 21:40:52 | brixen | looks like just the Dir.rmdir/.unlink specs |
| 21:41:34 | brixen | these are just crappy specs |
| 21:41:44 | brixen | they don't even use before/after actions |
| 21:41:58 | brixen | or put stuff in tmp() dir |
| 21:59:19 | boyscout | Fix race condition in Process#kill specs - dfc6a94 - Evan Phoenix |
| 21:59:19 | boyscout | Healthy living through better thread management - 0c8eb66 - Evan Phoenix |
| 21:59:57 | brixen | sweet |
| 22:00:19 | boyscout | CI: Build 0c8eb66 failed. http://ci.rubini.us/rubinius/builds/0c8eb66455257d3e3eded68c99d0040901abbb0d |
| 22:05:17 | boyscout | Fix conditional includes - 410683c - Evan Phoenix |
| 22:14:39 | boyscout | CI: 410683c success. 2683 files, 10346 examples, 32917 expectations, 0 failures, 0 errors |
| 22:15:36 | boyscout | Add a SpinLock to Roots - 1df02d8 - Evan Phoenix |
| 22:16:12 | rue | Mm, Darwin's fork() retains threads, right? |
| 22:19:34 | slava | darwin's fork() does not keep threads afaik |
| 22:19:38 | slava | the new process only has one thread |
| 22:19:39 | rue | Mm, should test it...the man page does not mention it in its "differences" listing |
| 22:19:45 | slava | this is because exec() does not work in a process with mor than one thread |
| 22:19:53 | slava | so if fork() cloned all threads, you'd never be able to exec() :-) |
| 22:21:45 | rue | I meant the preamble in man 2 fork |
| 22:22:15 | rue | But I just misread the vm_fork() changes, thought it was unpausing it in the child (which would be pointless) |
| 22:23:00 | rue | Yep, I see it now. Have to add some intensity to the green of my #defines |
| 22:24:17 | rue | Comic Sans |
| 22:25:11 | rue | Yep |
| 22:25:27 | rue | Google Wave really does look stupid |
| 22:25:31 | boyscout | CI: 1df02d8 success. 2683 files, 10346 examples, 32917 expectations, 0 failures, 0 errors |
| 22:27:07 | rue | Hopefully we can keep the #defines to a minimum...I do not remember which lib it was that I was reading through where each function had 2-3 different conditionals for 3-4 different implementations |
| 22:28:16 | slava | my new vm has a few more #defines than the last one, because I've been adding #define FACTOR_DEBUG ... assertions here ... #endif |
| 22:28:39 | rue | Eek, dwarf exception handling :/ |
| 22:33:07 | headius | evan: solaris has "forkall" |
| 22:33:10 | headius | I've never used it |
| 22:42:21 | boyscout | Fix up Dir.rmdir/.unlink specs. - b6c8978 - Brian Ford |
| 22:42:31 | brixen | evan: those should be a little nicer |
| 22:42:40 | brixen | tell me if you still have issues |
| 22:43:05 | brixen | at some point, it's pretty hard to automatically clean up from segfault-type exits |
| 22:45:01 | brixen | yeah, these try to do that now |
| 22:45:21 | brixen | yep |
| 22:48:41 | sandal | brixen: matz says that Class#name= should be defined to work as is |
| 22:48:51 | sandal | brixen: want a spec for that? |
| 22:49:01 | sandal | As is in MRI |
| 22:49:10 | sandal | see ruby-core |
| 22:49:18 | sandal | No... letting you set it |
| 22:49:36 | rue | Sent a clarification question...did not seem he had given it full thought |
| 22:49:45 | sandal | rue: I think that's probably right |
| 22:49:51 | sandal | but evan he says "I expect Rubinius to work as others, so I choose 1)." |
| 22:50:52 | sandal | whoa, weird. *but* |
| 22:50:58 | rue | The lib uses #attr_accessor |
| 22:51:04 | sandal | In the case that I showed, the accessor works |
| 22:51:05 | rue | So it overrides #name, too |
| 22:52:07 | sandal | oh, because of the issue you mentioned |
| 22:52:13 | sandal | that the names are not stored in ivars |
| 22:52:28 | rue | evan: Ah, yes, I see what you mean. I asked that question in a different manner |
| 22:52:32 | sandal | this clears up the point a lot for me now |
| 22:52:44 | sandal | I wasn't getting it fully before. |
| 22:52:57 | sandal | Hopefully he'll provide some clarification on that |
| 22:54:31 | sandal | the use case was attr_accessor, not writer, but then there is a mismatch, for sure |
| 22:57:08 | dgtized | does anything actually use @name in the module? |
| 22:57:25 | dgtized | or could you just define a method that returns the static name? |
| 22:57:44 | rue | How does it find out what the static name is? |
| 22:59:03 | dgtized | set_name_if_necessary? |
| 23:11:41 | rue | Pretty sure that still needs a name provided |