Da
Show enters and exits. Hide enters and exits.
| 00:17:11 | sandal | Finally officially announced that I'll be starting on Unity (the web based RubySpec interface) |
| 00:17:15 | sandal | http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/338428 |
| 00:17:26 | sandal | Now I can maybe stop pandering and start coming up with a plan :) |
| 00:34:12 | brixen | sandal_: nice post on RBP :) |
| 00:35:05 | brixen | sandal_: small typo, it's Brain Fart not Brain Ford :P |
| 00:35:16 | sandal | hahaha |
| 01:09:21 | ddub | I should go home and see what happened with my new roomba |
| 01:11:21 | brixen | ddub: like see if it washed your couch or gave birth? |
| 01:13:37 | ddub | little roombas running around :D |
| 01:14:21 | ddub | how tiny are baby roombii though? are they like cleaning nanites? |
| 01:14:48 | evan | more like scrubbing bubbles |
| 01:15:07 | ddub | great minds think alike :) |
| 01:15:35 | ddub | makes sure he can feed them lots of dust and metal shavings so they grow up big and strong |
| 01:16:37 | brixen | that would be pretty awesome, little scrubbers consuming dirt and growing into big scrubbers |
| 01:16:54 | brixen | might get big enought to consume cities thoug :/ |
| 01:19:17 | brixen | wtf vim, why did you suddenly quit wrapping my text |
| 01:20:21 | evan | are you in paste mode? |
| 01:20:46 | brixen | um, how would I tell? |
| 01:20:52 | evan | do |
| 01:20:53 | evan | :se nopaste |
| 01:20:55 | evan | just to be sure |
| 01:22:09 | brixen | ok, did that, but it still doesn't wrap |
| 01:22:16 | evan | hm. |
| 01:22:36 | brixen | it was wrapping and I reopened the file and it quit |
| 01:22:38 | brixen | weird |
| 01:24:48 | dgtized | evan: so I see you changed Array#at to do the work of the primitive -- I guess we can't actually strip that primitive since the the vm needs it? |
| 01:25:15 | evan | i didn't disable the primitive |
| 01:25:20 | evan | we're still using it |
| 01:25:29 | evan | I just left a feature complete version of Array#at there |
| 01:25:45 | evan | which is what all performance prims should do |
| 01:26:12 | dgtized | ah nm, I misread |
| 01:27:15 | dgtized | would it make sense to include feature complete versions of say Tuple#copy_from in ruby? |
| 01:27:45 | evan | yes. |
| 01:29:07 | dgtized | also it was probably my fault that there was a large number of if('s in array, I'll try and remember to avoid that |
| 01:30:21 | evan | yes, it was :) |
| 01:30:24 | evan | git blame said so |
| 01:32:04 | dgtized | ok for Tuple#copy_from, currently the alternate case is just to fall back to a raise PrimitiveFailure, I guess if we have an actual fall back solution that should be the case? |
| 01:32:16 | dgtized | what is the actual usage intended for PrimitiveFailure? |
| 01:32:41 | evan | TypeErrors and explicit calls to Primitive::failure() |
| 01:32:49 | evan | ie, the primitive itself can say "nope, this isn't going to work" |
| 01:32:52 | evan | then the ruby code is run |
| 01:33:38 | dgtized | hmm, so I guess in this case it means the ruby solution needs to guard the arguments as fixnum's? |
| 01:34:01 | dgtized | as extra work beyond the prim failure? |
| 01:34:37 | evan | "needs to guard" |
| 01:34:38 | evan | whats that mean? |
| 01:36:19 | dgtized | well currently the only case that would cause the PrimitiveFailure is if the arguments are not Array, Fixnum, Fixnum, Fixnum |
| 01:36:37 | evan | right |
| 01:36:54 | evan | there are a couple ways to handel things |
| 01:37:00 | dgtized | so in replacement for the PrimitiveFailure that triggers if that is not the case, we should explicit type guards correct? |
| 01:37:00 | evan | you could just convert them and call the method again |
| 01:37:57 | dgtized | well presumably this is a method that if possible it would be nice to inline in the jit at some point if we could remove the primitive |
| 01:38:09 | dgtized | so just calling the method again is kind of silly |
| 01:39:24 | evan | i'd prefer we not design any code around "this is going to be inlined" |
| 01:39:31 | evan | we've got no clue how thats going to work yet |
| 01:39:39 | evan | i don't want us to make those kinds of decisions |
| 01:40:53 | rue | Inlining pretty much does not work if the code cannot be assumed to work on its own |
| 01:41:01 | rue | Except *actually* inlining it |
| 01:41:44 | dgtized | wait wait -- copy_from is purely a performance primitive to move whole regions of a tuple into another tuple |
| 01:42:04 | dgtized | so what I'm doing is rewriting the primitive failure case so that it just executes the copy code in ruby |
| 01:42:40 | dgtized | but I'm just making sure that we aren't changing the possible error conditions by reverting to the ruby code from the primitive dispatch |
| 01:43:26 | evan | ok |
| 01:43:33 | dgtized | the same can be done for Tuple#delete |
| 01:43:36 | evan | so you're assuming that it should raise a TypeError if someone doesn't pass in a Fixnum? |
| 01:44:03 | slava | evan: I think a good strategy is to do all type checks in ruby-land |
| 01:44:09 | slava | this way the compiler can 'see' them and optimize them out |
| 01:44:43 | dgtized | oh right -- I'd forgetten, ok so actually there is no case in which the PrimitiveFailure can occur, just the TypeErrors from the primitive bridge code |
| 01:45:34 | evan | dgtized: ruby code thats not boilerplate fallback code for a primitive should NOT raise PrimitiveFailure |
| 01:46:12 | dgtized | evan: ah -- that makes sense, ok |
| 01:58:55 | dgtized | slava: we do most of our type checks there, but the primitive code is a weird special case |
| 02:16:07 | dgtized | actually, this would be pretty good if we had pure ruby implementations of all these things, it should speed up attempts like jruby to use our kernel |
| 02:21:18 | sandal | brixen: I totally didn't catch your ref to the typo before... sorry! |
| 02:21:23 | sandal | Updating now |
| 02:21:47 | brixen | sandal_: heh, n/p |
| 02:22:59 | sandal | http://github.com/sandal/rbp-blog/commit/9314b664ecc1ee06b37e0170499d0f027e916fbe |
| 02:24:04 | brixen | hehe |
| 02:24:05 | brixen | nice |
| 02:25:33 | brixen | well, the 70 mph winds have died down, so I'm going to drive home |
| 02:25:38 | brixen | bbiab.. |
| 02:45:27 | rue | Maybe it was just laying low to trick brixen into exiting |
| 08:29:08 | boyscout | Added correct max_loop calculation for cuckoo hash. - be4b11a - Brian Ford |
| 08:29:08 | boyscout | Convert cuckoo hash to a single, divided table. - ac34fae - Brian Ford |
| 08:29:08 | boyscout | Reworked cuckoo hash insert. - 09e9635 - Brian Ford |
| 08:29:08 | boyscout | Added place for experiments to the documentation. - 3fd6627 - Brian Ford |
| 08:29:08 | boyscout | Added code, results for Hash performance experiments. - 57acca5 - Brian Ford |
| 08:29:38 | brixen | evan: take a look at doc/experiments |
| 08:30:07 | brixen | make sure I didn't make any obvious blunders in explanation :) |
| 08:39:22 | evan | ok |
| 08:39:25 | evan | i'm about to head to bed |
| 17:45:16 | evan | morning |
| 17:46:37 | marcandre | afternoon |
| 17:47:20 | brixen | morning |
| 17:47:31 | brixen | mornings win, 2-1 :) |
| 17:48:15 | marcandre | brixen: I'm still thinking about that nil <=> 0 business. |
| 17:48:28 | marcandre | I was amazed at how < and > work for Modules... |
| 17:48:39 | marcandre | It works the way you were suggesting! |
| 17:49:02 | brixen | oh? |
| 17:49:06 | marcandre | I.e. it returns true, false, or nil if they are both modules but have no relation to each other! |
| 17:49:13 | brixen | I see |
| 17:49:45 | brixen | in a sense a < b => nil makes sense in a boolean context |
| 17:50:03 | brixen | it _is_ false in the extended set { nil, true, false } |
| 17:50:15 | brixen | I doubt that change will fly with matz though |
| 17:50:16 | marcandre | Also, Module.is_a? Comparable returns false |
| 17:50:25 | evan | for instance, how can you compare a car to an apple? |
| 17:50:32 | evan | that would return nil |
| 17:50:58 | marcandre | Module will raise an error if you try to compare a Module with other stuff, say a string. |
| 17:51:03 | brixen | yeah, not comparable for the relational ops could raise or return nil |
| 17:51:25 | marcandre | It will return nil only if they both are Modules but can't be ordered. |
| 17:52:20 | marcandre | So the graph or set example of partially ordered objects could therefore return nil between themselves and raise when comparing with other classes. |
| 17:52:33 | evan | consistency! |
| 17:52:34 | evan | :/ |
| 17:53:13 | marcandre | The problem is that if we follow this logic, Object.new < Object.new should return nil, and not raise an error. |
| 17:53:40 | marcandre | I mean if we push to have an Object#<=> defined (and >, ...) |
| 17:55:14 | marcandre | So I'm even less sure what to suggest to ruby-core anymore. |
| 18:09:13 | rue | I do not think an Object#<=> is appropriate |
| 18:10:35 | rue | Set semantics, fix Comparable and any core stuff that defines <=> |
| 18:11:05 | rue | I do not understand what the aversion to a NoMethodError is (unless I have misinterpreted that point of contention) |
| 18:11:35 | brixen | rue: well, why should it ever get a NME |
| 18:11:52 | brixen | any 2 objects a, b have a well defined result for #<=> |
| 18:12:19 | rue | Not if you have not defined such a result |
| 18:12:40 | rue | `someobject <=> other` should raise a NoMethodError, if #<=> is not implemented |
| 18:12:41 | brixen | the asymmetry between 0 <=> nil and nil <=> 0 is just nonsense |
| 18:13:06 | brixen | rue: the result of #<=> is easily defined |
| 18:13:15 | brixen | there is no reason to have NME raised |
| 18:13:39 | rue | Not really |
| 18:15:28 | rue | The two above are distinctly different things |
| 18:16:40 | rue | I suppose my formulation is that you cannot fully define Object#<=> |
| 18:17:05 | rue | You can, sure, define it to always return nil or raise or whatever, but not to return the "real" result of -1, 0, 1 |
| 18:17:17 | rue | Therefore it is inappropriate to implement it that way |
| 18:17:21 | boyscout | Fixed bench:to_csv to emit the correct bench name. - 8ef4866 - Brian Ford |
| 18:26:32 | marcandre | rue: I think the main points of contention are: 0 <=> nil returns nil, but nil <=> 0 raises a NME. 0 > nil and nil < 0 raise different errors. Finally, nil == 0 returns false, but nil <=> 0 raises an error. |
| 18:27:26 | marcandre | What I'm wondering is: what is the downside of having Object#<=>(obj) being defined and returning obj<=>(self), or nil if recursing? |
| 18:28:17 | brixen | marcandre: well, one downside I see is sanity, there's far too much of that around /sarcasm :) |
| 18:28:19 | rue | Well, first, you would have to implement it as the *reverse* of that |
| 18:29:41 | marcandre | Yes, indeed, -1 and 1 need to be mapped to 1 and -1 respectively. |
| 18:30:19 | rue | Secondly, the recursion |
| 18:30:23 | rue | Self- and mutual |
| 18:30:39 | marcandre | rb_exec_recursive will take care of that easily. |
| 18:31:15 | rue | Thirdly, NoMethodError means "invalid operation" |
| 18:32:00 | rue | Why are we hiding the fact that you cannot compare nil with shit? |
| 18:32:08 | marcandre | Yes. I'm wondering how that is more useful than getting 'nil' |
| 18:32:36 | marcandre | If you really couldn't compare nil with anything, why is 0 <=> nil not raising an error? |
| 18:32:55 | rue | Because Fixnum is stupid enough to somehow "convert" nil to a value it can use |
| 18:33:00 | rue | Which is its choice |
| 18:33:34 | marcandre | Same with "" <=> nil, btw... |
| 18:34:30 | marcandre | I think that's the crux of the problem. 0 <=> nil should have the same (inverse) behavior as nil <=> 0. |
| 18:34:37 | rue | No, it should not |
| 18:34:43 | marcandre | Be that raising a meaningful error, or returning nil. |
| 18:34:55 | rue | Sorry, no, it should not /have to/ have |
| 18:35:11 | marcandre | Of course, I mean, "I think". |
| 18:35:36 | rue | It would set a precedent that either coercion is disallowed, or then expected |
| 18:36:21 | rue | One thing is clear, though: if using #<=> raises an error (of any kind), it means the user done fucked up |
| 18:36:21 | marcandre | I'm not sure I follow. |
| 18:37:24 | marcandre | Yes, indeed. |
| 18:37:58 | marcandre | But why is "nil <=> 0" a f*ck up but not "0 <=> nil"? |
| 18:38:11 | rue | Because that is what Fixnum#<=> decided to do |
| 18:38:30 | marcandre | Well, is that the right thing to do? |
| 18:38:33 | rue | So, the problem is not a missing Object#<=>, but (possibly) the definitions of #<=> in the core |
| 18:39:38 | rue | Right, that is the question. It has two aspects |
| 18:40:02 | rue | 1. Should #<=> be "allowed" to coerce its argument? (I.e., is this conventionally used) |
| 18:41:06 | rue | 2. Should an invalid object given to a defined #<=>, say, Fixnum's, raise (something), return nil, or do one or the other? |
| 18:41:18 | marcandre | When doing 0 <=> nil, is nil coerced to a fixnum? |
| 18:41:52 | rue | #<=> is defined to return -1, 0, or 1; not nil. Therefore, I think the answer to #2 is to always raise if the argument is not understood |
| 18:42:41 | marcandre | I think you are mistaken |
| 18:42:56 | marcandre | #<=> is defined to return any of -1, 0, 1 or nil. |
| 18:43:15 | rue | Nope |
| 18:43:31 | rue | Let me rephrase |
| 18:44:15 | rue | The semantics of #<=> call for a return value of -1, 0 or 1. The normal way to handle errors is with errors. nil is not a semantically valid result of #<=> |
| 18:44:28 | ddub | rue look at Module#<=> |
| 18:44:36 | rue | That it is *currently implemented* that way is a different matter |
| 18:45:14 | marcandre | Oh, please don't look at Module#<=>, because Module order is different than everywhere else! |
| 18:45:35 | rue | ddub: Conversely, look at the documentation of Fixnum#<=> |
| 18:45:42 | rue | Not that it actually follows it but anyway |
| 18:45:54 | rue | There is nothing gained by returning nil |
| 18:45:59 | marcandre | Section 4.6.6 from Matz's book states "And if the two operands are not comparable, it returns nil." |
| 18:46:22 | evan | elk <=> airplane # => nil |
| 18:46:24 | rue | Whereas raising allows users to do a simple rescue, which will catch both NoMethodError and whatever else |
| 18:46:54 | rue | evan: No, `elk <=> airplane # => NoMethodError` (or TypeError if you prefer) |
| 18:47:07 | marcandre | I can understand that personal preferences may differ, but I think this is moot. |
| 18:47:47 | marcandre | I believe the definition of <=>, as per Matz's book and implementation of all <=> operators are clear: one should return nil when not comparable. |
| 18:47:52 | evan | rue: I do prefer |
| 18:47:54 | rue | And never raise? |
| 18:48:02 | rue | #<=> should never raise? |
| 18:48:35 | marcandre | Well, I'd like that to be the case! |
| 18:49:10 | marcandre | And the rationale is as follows: there is a return value already defined for stuff that can't be compared and that's "nil". |
| 18:49:26 | marcandre | Some may or may not like that, but that's the current definition. |
| 18:49:40 | rue | When using the method, you then have two branches for processing the result |
| 18:50:01 | marcandre | Maybe this could be changed for "nil" if things are of the same "kind" but can't be ordered (e.g. Graphs, Modules, etc...) and raise otherwise |
| 18:50:18 | rue | I think that is overloading the method |
| 18:50:27 | rue | Or, more impolitely, using the wrong method |
| 18:50:27 | ddub | O |
| 18:50:56 | marcandre | But the current situation is a mix of the two: sometimes return nil, sometimes raise, and I think that's the worst situation. |
| 18:51:22 | ddub | it would be nice if it did raise a type error when it wasn't able to do a comparison, vs. returning nil. Although I suppose you can catch that case and attempt to reverse the arguments (and negate the result) |
| 18:52:24 | rue | So, to use more traditional version of evan's line above: |
| 18:52:32 | rue | "Compare these apples with these oranges" |
| 18:52:43 | rue | My answer is "N-uh, can't do that sah" |
| 18:53:24 | marcandre | As long as you give one answer, I'll be happy :-) |
| 18:53:40 | brixen | returning nil and raising are equivalent, one returns an undefined value for the function, one modifies state |
| 18:54:00 | brixen | here the advantage of returning nil is that it has a boolean semantic |
| 18:54:06 | rue | They are not equivalent, because the set of possible return values is not the same. |
| 18:54:59 | rue | And, since -1, 0, 1 do not have boolean semantics, nil having is of little value. It means there is a branch at the return value |
| 18:55:43 | marcandre | I believe we have to see <=> as an operator returning one of four possibilities. |
| 18:55:53 | rue | I disagree |
| 18:55:59 | marcandre | It could have been :equal, :smaller, :bigger, :different |
| 18:56:02 | rue | It returns one of three, or fails |
| 18:56:06 | marcandre | It is 0, -1, 1, nil |
| 18:56:21 | marcandre | It could have been 0, -1, 1, raise |
| 18:56:44 | marcandre | No matter what, you have four possibilities. |
| 18:57:20 | marcandre | But currently there are 5. I'd like to have nil and raise be "merged". |
| 18:57:26 | rue | I am not sure I have confidence that never raising will be adhered to. |
| 18:58:12 | marcandre | Or else given different meanings, like nil is for partially ordered objects that can't be ordered (e.g. Modules) and raise for different classes that can't be compared |
| 18:58:16 | rue | Plus it leaves the difficulty of an undefined #<=>. raising seems to be a simpler solution, and it does not require adding an unnecessary method |
| 18:59:42 | rue | marcandre: I would raise in both cases, the comparison is not possible and the user should not try to do it. 'Course can define different error classes, if so desired |
| 18:59:54 | rue | AmbiguousError |
| 19:00:12 | marcandre | You mean that String <=> FalseClass should raise an error? |
| 19:00:27 | marcandre | Wow, that's very extreme! |
| 19:00:37 | rue | Yes |
| 19:00:40 | marcandre | I see exceptions as signs you have screwed up. |
| 19:00:45 | rue | You HAVE |
| 19:01:09 | marcandre | And if I have two classes and want to know if there's a relationship between them, I don't feel that asking the question is a screw up! |
| 19:01:13 | rue | If you cannot define the -1, 0, 1 relationship, then you should use a different comparison method |
| 19:01:32 | brixen | that is totally not true |
| 19:01:37 | rue | marcandre: Ah, but you are not asking IF there is a relationship |
| 19:01:41 | brixen | 1 / 0 is not defined on reals |
| 19:01:46 | rue | You are asking WHAT the relationship is |
| 19:01:50 | brixen | but extended reals have Inf |
| 19:02:13 | brixen | you can extend the set { -1, 0, 1 } to include nil the same way |
| 19:02:54 | marcandre | rue: Indeed, I'm asking the question "is there a relationship and if so what is it" |
| 19:03:00 | rue | marcandre: To find out IF they are related, you could conceivably use #< or #>, or check #ancestors, or #include? |
| 19:03:03 | marcandre | That's the efficient way to define it. |
| 19:04:40 | marcandre | The efficient (and I feel natural) way to ask that is <=>. I think that's what it was meant to be (as per the doc), and I find if (again, that's personal) very efficient and useful that it returns nil. |
| 19:04:40 | rue | #<=> is not relation, it is comparison |
| 19:05:20 | brixen | um ok |
| 19:05:21 | marcandre | yes. And the natural comparison for Modules, Sets, Graphs, ..., is inclusion. |
| 19:06:17 | marcandre | Damn, gotta go... |
| 19:07:37 | marcandre | I'll try to put some of these thoughts properly on paper and come back here before sending it to ruby-core. rue, you can write the dissent ;-) |
| 19:08:17 | rue | I am not going to bother to do that |
| 19:08:44 | marcandre | Indeed, Matz will probaly do that really quickly anyways ;-) |
| 19:08:46 | rue | You guys are way, way overloading one single method, and you all can figure out how in the fuck to support the construct |
| 19:09:19 | evan | we're not doing it |
| 19:09:21 | evan | ruby does it. |
| 19:09:37 | marcandre | brixen: not sure what you mean by boolean stuff for { -1, 0, 1, nil }. Maybe you can tell me later? |
| 19:09:44 | rue | Always raising is the simplest way both to implement, and for the user to work with, but it does not support overloaded semantics. |
| 19:10:03 | brixen | marcandre: sure, it's elementary function stuff |
| 19:10:13 | brixen | marcandre: you already understand the math |
| 19:10:34 | rue | Nice passive-aggressiveness again, asshole |
| 19:10:35 | brixen | marcandre: just use the reals and extended reals as an analogue |
| 19:11:04 | marcandre | rue: who are you calling that? |
| 19:11:10 | brixen | marcandre: me |
| 19:11:13 | brixen | don't worry |
| 19:11:14 | brixen | :) |
| 19:11:18 | evan | dude. |
| 19:11:20 | evan | le sigh. |
| 19:11:44 | brixen | it's a matter of opinion whether raising or returning nil is "correct" |
| 19:11:54 | brixen | precendence favors nil |
| 19:12:10 | brixen | analogous stuff with the reals for instance does too |
| 19:12:14 | brixen | anyway... |
| 19:12:38 | marcandre | Wow. |
| 19:13:04 | marcandre | Anyways. It's sunny outside, I'm going to play beach-volley. |
| 19:13:09 | brixen | fun! |
| 19:13:14 | brixen | it's rainy here :( |
| 19:14:47 | marcandre | I have a lot of difficulty coping with aggresivity and I seriously hope not to witness it. |
| 19:14:56 | marcandre | Cheers, and talk to you later. |
| 19:16:22 | brixen | marcandre: cheers mate |
| 19:16:27 | brixen | don't let it bother you |
| 19:23:16 | aiclus | Do you know Diamondback Ruby (DRuby) http://www.cs.umd.edu/projects/PL/druby/ |
| 19:23:27 | evan | yeah, we've seen it. |
| 19:23:27 | aiclus | would rubinius benefit from type inference? |
| 19:23:48 | evan | maybe |
| 19:23:54 | evan | dunno |
| 19:24:00 | evan | we'd have to figure out a way to use it. |
| 19:24:22 | aiclus | I like the idea of annotations as comments! |
| 19:25:14 | evan | TI in ruby is hard |
| 19:25:19 | evan | for instance |
| 19:25:22 | evan | def foo(a) |
| 19:25:24 | evan | a + 50 |
| 19:25:25 | evan | end |
| 19:25:30 | evan | even if you can reason that a is a Fixnum |
| 19:25:40 | evan | you can't reason about the return value of + without knowing a's value |
| 19:25:55 | evan | well, you can't reason that it's Fixnum |
| 19:26:02 | brixen | aiclus: I like the idea of class methods better: http://gist.github.com/124415 |
| 19:26:17 | brixen | aiclus: more like haskell |
| 19:27:08 | aiclus | hmm but it changes code |
| 19:27:10 | brixen | but yes, the bigger issue is that "type" is not well defined in Ruby |
| 19:27:26 | brixen | aiclus: it's easy to define Module#type as a noop |
| 19:27:40 | brixen | I dislike magic comments for the most part |
| 19:27:49 | brixen | encoding magic comments work ok |
| 19:28:38 | brixen | aiclus: it'd be interesting to add some static analysis stuff to rbx |
| 19:28:45 | brixen | aiclus: are you interested in that? |
| 19:29:22 | aiclus | but type information is beneficial I some simple format should be defined for it ... |
| 19:32:09 | brixen | only 8 failures, 7 errors in mspec ci after updating rubyspec |
| 19:32:12 | brixen | that's pretty cool |
| 19:32:25 | brixen | lots of rubyspec activity lately too |
| 19:32:45 | brixen | one is a bytecode generation error though, hmm |
| 19:34:43 | brixen | evan: who was working on AccessVariable? adding #arity and stuff? |
| 19:35:00 | evan | um.... |
| 19:35:07 | evan | i don't recall |
| 20:26:12 | boyscout | implemented pure ruby fallback for Tuple#copy_from - 36cc23d - Charles Comstock |
| 20:26:12 | boyscout | implemented pure ruby fall back from primitive for Tuple#delete - f57a8fc - Charles Comstock |
| 23:22:32 | tarcieri | heh, weird |
| 23:23:04 | brixen | indeed |
| 23:23:09 | tarcieri | so I guess the PyPy guy I talked to is Maciej Fijalkowski |
| 23:23:24 | tarcieri | and rumor has it he's about to announce a JIT that's faster than CPython |
| 23:23:32 | brixen | wow, sweet |
| 23:23:38 | brixen | any code we can see? |
| 23:24:27 | tarcieri | lol, so the way this was phrased in the email |
| 23:24:38 | slava | a jit faster than cpython? something sounds wrong here |
| 23:25:05 | tarcieri | " Maciej asked me not to pre-announce that his JIT might be working and running Python faster than CPython does. So, I'm not pre-announcing that, so if it does, then it will be a surprise." |
| 23:25:13 | tarcieri | lol |
| 23:25:17 | brixen | heh |
| 23:27:14 | slava | why would a jit not be as fast or faster than CPython? |
| 23:27:30 | tarcieri | I think the important thing is that it's working |
| 23:27:40 | slava | that's not so impressive either :) |
| 23:27:44 | tarcieri | heh |
| 23:27:53 | tarcieri | working code is always more impressive than non-working code! |
| 23:58:34 | brixen | jarib: ping |