Show enters and exits. Hide enters and exits.
| 06:42:33 | boyscout | 1.8.7: Integer#odd?, #even?, #ord, #pred (new methods implementation) - 31e84c6 - Marc-Andre Lafortune |
| 06:42:33 | boyscout | 1.8.7: Kernel#tap (new method implementation) - f5d4ad5 - Marc-Andre Lafortune |
| 06:42:33 | boyscout | 1.9: Kernel#define_singleton_method (implementation of new method) - 4d5a9e8 - Marc-Andre Lafortune |
| 06:42:33 | boyscout | 1.9: #methods, #constants, etc.., returns symbols in 1.9 - 390dc77 - Marc-Andre Lafortune |
| 06:42:33 | boyscout | 1.8.7: ObjectSpace#each_object (returns enumerator when no block) - d3a9948 - Marc-Andre Lafortune |
| 06:42:34 | boyscout | 1.8.7: Proc#call now aliased as Proc#yield - 7c0bc7f - Marc-Andre Lafortune |
| 06:42:36 | boyscout | 1.8.7: Range#each, #step: enumerator returned when no block - 8af731d - Marc-Andre Lafortune |
| 06:42:38 | boyscout | Regexp.union (rewrote to pass specs. 1.8.7+ compatible too) - fba5c51 - Marc-Andre Lafortune |
| 06:42:40 | boyscout | Moving some io stuff around - bcb33f3 - Marc-Andre Lafortune |
| 06:42:42 | boyscout | 1.9: String.try_convert (implementation of new method) - 09e59d0 - Marc-Andre Lafortune |
| 06:42:44 | boyscout | 1.8.7: String#each_char (implementation of new method) - 97d99b9 - Marc-Andre Lafortune |
| 06:43:09 | evan | geez. |
| 06:43:19 | marcandre | lol |
| 06:43:32 | marcandre | Am I cutting my commits in too small chunks? |
| 06:43:42 | evan | no, thats ok. |
| 06:44:07 | marcandre | Cool. Mostly done with 1.8.7 stuff. |
| 06:44:17 | evan | rad. |
| 06:44:34 | evan | though |
| 06:44:41 | evan | global private methods are generally a nono |
| 06:44:52 | evan | like convert_to_constant_names |
| 06:44:56 | evan | plus, thats not what it does |
| 06:45:10 | evan | that method seems needless. |
| 06:45:20 | marcandre | Guilty as charged. |
| 06:45:42 | evan | oh, i see what you did. |
| 06:45:51 | evan | so you could override it |
| 06:46:02 | evan | yeah, move that to something with a much more sensible name |
| 06:46:04 | evan | perhaps |
| 06:46:32 | slava | hi evan |
| 06:46:41 | marcandre | Ok, I'll think of something more sensible. |
| 06:46:42 | evan | Rubinius.convert_to_names |
| 06:46:51 | marcandre | Sounds good. |
| 06:47:00 | evan | slava: allo sir. |
| 06:47:33 | evan | also |
| 06:47:36 | evan | why did you change fileutils.rb? |
| 06:47:50 | evan | that METHODS constant can be an array of strings, thats fine. |
| 06:48:19 | marcandre | I changed it to an array of symbols (I prefer symbols). It had to be one or the other, for 1.9 compatibility. |
| 06:48:44 | marcandre | It used to do methods - %w(....), which doesn't work if methods returns symbols. |
| 06:49:02 | evan | right |
| 06:49:03 | evan | but why change it? |
| 06:49:09 | evan | doesn't seem necessary |
| 06:49:31 | boyscout | CI: 97d99b9 success. 2682 files, 10322 examples, 32867 expectations, 0 failures, 0 errors |
| 06:49:46 | marcandre | Well, it's either I did a map{|m| m.to_s} or map{|m| m.to_sym} |
| 06:49:48 | evan | we try hard to not go changing things like fileutils |
| 06:50:05 | marcandre | Oh, you mean someone might rely on that constant? |
| 06:50:07 | evan | ah, because singleton_methods changed. |
| 06:50:09 | evan | i see. |
| 06:50:11 | evan | ok |
| 06:50:14 | evan | in the future, when you do that |
| 06:50:19 | evan | throw a comment above it |
| 06:50:22 | evan | to indicate why |
| 06:50:39 | marcandre | Ok. What's so special about fileutils? |
| 06:51:27 | evan | nothing particular |
| 06:51:35 | evan | mainly that we try hard to not modify the stdlib |
| 06:51:46 | evan | because it's craziness is found in the real world |
| 06:51:51 | evan | so we have to deal with it being weird |
| 06:52:02 | evan | it's a good test bed. |
| 06:52:06 | marcandre | Ah, sorry, I didn't realize it was straight from the ruby lib. |
| 06:52:16 | evan | 99% of it is. |
| 06:52:21 | evan | we didn't reimplement any of it. |
| 06:52:27 | evan | figured that would be silly |
| 06:52:31 | evan | there are a couple exceptions |
| 06:52:35 | marcandre | BTW, the 1.9 version is Symbols. |
| 06:52:35 | evan | weakref and a minor irb extension |
| 06:52:51 | evan | version of what? |
| 06:52:59 | marcandre | I'll throw in a comment then, and double check when I modify the stdlib. |
| 06:53:05 | marcandre | fileutils.rb in the 1.9 distribution |
| 06:54:07 | marcandre | You might want to double check what I'm doing for Kernel#__method__ is OK. It's in lib/1.8.7/kernel.rb |
| 06:56:34 | evan | ok, checking now. |
| 06:57:36 | evan | it just returns the name of the currently running method, yes? |
| 06:58:02 | marcandre | yup |
| 06:58:19 | evan | you can probably get rid of the scope check then |
| 06:58:26 | evan | just walk the backtrace until you find the first non-block |
| 06:58:31 | evan | oh wait.. |
| 06:58:39 | evan | the block call path will obscuret hat |
| 06:58:41 | evan | i see... |
| 06:58:44 | marcandre | yup |
| 06:59:13 | evan | yeah, i think this is ok |
| 06:59:19 | evan | there might be a nicer way |
| 06:59:23 | evan | but it's not coming to me off hand |
| 06:59:30 | evan | i'm happy that you came up with this on your own actually :D |
| 06:59:38 | marcandre | Cool! |
| 06:59:41 | marcandre | :-) |
| 07:00:09 | evan | the delegated method thing might break |
| 07:00:32 | evan | i'd have to think about it |
| 07:00:36 | evan | i guess thats for define_method? |
| 07:00:49 | marcandre | Exactly |
| 07:01:20 | marcandre | Took me a while to understand what was going on, and it's a bit ugly but I didn't see any other way |
| 07:01:36 | evan | yeah |
| 07:01:44 | evan | thats probably an area I should clean up a little |
| 07:02:14 | evan | also |
| 07:02:25 | evan | should __method__ report the name the method calls itself, or the name it was called as |
| 07:02:28 | marcandre | I don't know. I took the tests from MRI and they have special checks for define_method, so I guess it has to be a bit more difficult |
| 07:02:30 | evan | ie, if a method is aliased |
| 07:02:35 | evan | which name is shown? |
| 07:02:46 | marcandre | the defined name. |
| 07:02:51 | evan | ok |
| 07:03:10 | marcandre | Good thing, coz I didn't see a way to get the name it was called as! |
| 07:03:22 | evan | it's in Location |
| 07:03:24 | evan | .name |
| 07:03:33 | evan | thats how our backtraces show both names |
| 07:04:04 | marcandre | Ah, yes. |
| 07:04:31 | marcandre | Actually now I think I used to use that until I realized the specs had changed from one version of MRI to the next. |
| 07:04:42 | evan | :/ |
| 07:04:48 | marcandre | (no comment! ;-) |
| 07:05:08 | evan | perhaps what I should do is make Location generation smarter |
| 07:05:15 | marcandre | Anyways, it passes the same specs as Ruby 1.9 |
| 07:05:15 | evan | it can see the lowlevel structure |
| 07:05:27 | evan | it should be aware of calls via DelegatedMethod |
| 07:05:38 | evan | so it can simply pull in the proper info |
| 07:05:49 | marcandre | You probably have some more important things to do right now! |
| 07:05:55 | evan | :D |
| 07:06:02 | evan | btw |
| 07:06:14 | evan | thank you for not duplicated the entire ObjectSpace#each_object |
| 07:06:17 | evan | to add enumerator support |
| 07:06:21 | marcandre | lol |
| 07:06:27 | marcandre | Yeah. |
| 07:06:28 | evan | thats clearly one place where the stategy of keeping them seperate was a bad idea |
| 07:06:38 | evan | doing a simple alias trick is fine. |
| 07:06:49 | marcandre | I thought that the alias thing would be fine there. |
| 07:07:33 | marcandre | I've never used ObjectSpace and I doubt it's used by many. Those will have to "suffer" a backtrace showing the alias jump. |
| 07:07:55 | evan | people use it for debugging |
| 07:08:08 | evan | and for a couple of places that MRI doesn't provide some info |
| 07:08:11 | evan | like the list of subclasses |
| 07:09:28 | brixen | and rails uses it as a class registry :/ |
| 07:10:00 | brixen | evan: some data for you to ponder http://gist.github.com/113844 |
| 07:10:28 | brixen | in particular, see the # of array instances running rails -h (bottom file) |
| 07:10:31 | evan | this is for array or hash? |
| 07:10:47 | evan | ah ok |
| 07:11:23 | brixen | I'm wondering if the # of arrays is the sexp during eval |
| 07:11:40 | brixen | but I don't know off hand how much rails does eval for -h |
| 07:12:10 | evan | geez. |
| 07:12:14 | brixen | I didn't run string_spy for rails -h yet because the array one took a very long time (~30 min) |
| 07:12:16 | evan | it uses it a bunch I think |
| 07:12:28 | evan | to create a whole bunch of methods |
| 07:12:37 | evan | i'm not sure exactly to what extent |
| 07:12:42 | brixen | k |
| 07:13:01 | brixen | well, it is interesting to see that most objects do not get methods called on them much |
| 07:14:13 | brixen | I'm finishing up the hash benchmarks now and I'll push the class_spy and bm's |
| 07:14:19 | evan | sweet. |
| 07:14:41 | brixen | it is interesting to profile from the perspective of each object |
| 07:14:53 | brixen | the class spy would let you do quite a bit of analysis |
| 07:15:08 | brixen | you could see if # of method calls was correlated with size, for instance |
| 07:15:27 | evan | sweet. |
| 07:15:36 | evan | i'm interested to see how it spys :D |
| 07:15:51 | brixen | it's not sophisticated |
| 07:15:54 | brixen | just aliasing methods |
| 07:16:01 | brixen | btw, got some strange results |
| 07:16:17 | scoopr | fedora, cigar and nightvision goggles. |
| 07:16:27 | brixen | shouldn't you be able to #send to any method and that be equivalent to an actual call? |
| 07:16:42 | evan | i'd think so |
| 07:16:48 | evan | unless that class has it's own #send |
| 07:16:55 | evan | which we've got a couple that do |
| 07:16:58 | evan | use __send__ |
| 07:16:59 | brixen | I could not alias String#=~ |
| 07:17:00 | evan | but otherwise, yes. |
| 07:17:03 | evan | in MRI? |
| 07:17:07 | brixen | it would break things |
| 07:17:10 | brixen | in rbx |
| 07:17:12 | evan | hm. |
| 07:17:15 | evan | in MRI, it's not called. |
| 07:17:16 | brixen | I haven't run this in MRI |
| 07:17:19 | evan | ok |
| 07:17:32 | evan | break how? |
| 07:17:34 | brixen | here, I'll push it and push the bm's later |
| 07:17:37 | evan | k |
| 07:17:38 | marcandre | In MRI, you can't alias_method gsub |
| 07:17:43 | brixen | I need to update my branch though |
| 07:18:00 | brixen | marcandre: interesting, #gsub was another that was breaking things |
| 07:18:05 | evan | 10-4 |
| 07:18:06 | brixen | like the irb prompt formatting |
| 07:18:08 | evan | oh |
| 07:18:10 | evan | i know why. |
| 07:18:12 | marcandre | Yeah. Well, you can, but it's a b*tch |
| 07:18:15 | evan | it's $~ |
| 07:18:18 | marcandre | It's because of $1 and stuff |
| 07:18:20 | evan | same for MRI |
| 07:18:22 | marcandre | Exactly. |
| 07:18:27 | evan | you can fix it in rubinius though |
| 07:18:27 | brixen | ok makes sense |
| 07:18:32 | marcandre | So you need to set it manually. Pretty ugly. |
| 07:18:52 | marcandre | So you can actually alias_chain it, but you have to do extra stuff. |
| 07:18:57 | evan | Rubinius::VariableScope.of_sender.last_match = last_match |
| 07:19:03 | evan | if you do that in the alias |
| 07:19:05 | evan | well, it would be |
| 07:19:11 | evan | Rubinius::VariableScope.of_sender.last_match = $~ |
| 07:19:18 | evan | to push it one level up |
| 07:20:25 | marcandre | Similarly in MRI, you get the binding of the block and use that to set $~. |
| 07:20:39 | evan | i don't think MRI exposes it though. |
| 07:20:46 | evan | so you have to do it in C land. |
| 07:20:51 | marcandre | For gsub, you have the block. |
| 07:21:00 | marcandre | For =~, you're probably toast in MRI |
| 07:21:03 | evan | not sure that helps |
| 07:21:10 | evan | this is why $~ sucks. |
| 07:21:46 | marcandre | Yeah, I was able to do it. I needed to alias_method_chain gsub for 1.8.7 in backports, but in the end I said 'f*ck this', I'm not implementing this change. |
| 07:21:55 | evan | brixen: check out String#gsub! |
| 07:22:02 | evan | thats an example of conditionally pushing $~ up one level |
| 07:22:07 | evan | throw that in your alias code |
| 07:22:54 | brixen | k |
| 07:23:06 | brixen | well, we can add that |
| 07:23:16 | brixen | class_spy boilerplates the alias chains |
| 07:23:26 | brixen | but you can do individual ones |
| 07:23:44 | evan | you could just have it add the code if the method name is in a list |
| 07:23:51 | evan | :=~, :gsub, etc. |
| 07:23:56 | brixen | sure |
| 07:24:07 | evan | :=~ looks like an anteater |
| 07:24:21 | brixen | or a tadpole |
| 07:24:27 | evan | heh |
| 07:24:29 | brixen | with big eyes |
| 07:24:48 | evan | oh humans and their symbology.... |
| 07:24:53 | evan | the source of so many problems |
| 07:24:55 | evan | and so much fun. |
| 07:25:56 | brixen | one of the other things the aliasing was messing up was Array#sort |
| 07:26:06 | brixen | I ended up implementing a sort on the Stat class |
| 07:26:22 | evan | ah yeah |
| 07:26:30 | evan | you could just include Enumerable too |
| 07:26:33 | evan | it's got sort. |
| 07:26:42 | brixen | investigating that I came to think that we might do better with a variation of Heap sort instead of qsort in core lib |
| 07:27:01 | brixen | well, this sort is 2 methods |
| 07:27:14 | brixen | performs very well compared to core qsort |
| 07:27:18 | evan | nice |
| 07:27:35 | brixen | and doesn't have pathological behavior with sorted data sets |
| 07:27:52 | brixen | most of these 10's of thousand element arrays are already mostly sorted |
| 07:27:58 | brixen | long runs of the same values |
| 07:28:12 | evan | sure |
| 07:29:15 | boyscout | Added ClassSpy for gathering usage statistics. - dcc65fc - Brian Ford |
| 07:29:23 | brixen | ok, have a gander at that |
| 07:29:39 | brixen | idea was to make it really easy to add a class spy |
| 07:29:49 | brixen | as you can see from the Array and String examples |
| 07:30:06 | brixen | but still be able to do the stuff Hash spy does |
| 07:30:13 | brixen | ie, the key stats |
| 07:30:58 | boyscout | Clean up - 69c3422 - Marc-Andre Lafortune |
| 07:31:00 | brixen | main problem is it can be very slow feeding all the data to the Stat instances |
| 07:31:23 | evan | hah |
| 07:31:28 | evan | + :'^' => 'hat' |
| 07:31:30 | evan | love it. |
| 07:31:34 | brixen | heh |
| 07:31:54 | brixen | anyway, feel free to mess with it |
| 07:31:59 | brixen | just don't break it :P |
| 07:32:35 | evan | breaks |
| 07:32:42 | brixen | :) |
| 07:32:44 | evan | you guys break my stuff all the time! |
| 07:32:49 | evan | it's only right that I return the favor |
| 07:32:53 | brixen | yeah |
| 07:33:08 | boyscout | CI: dcc65fc success. 2682 files, 10322 examples, 32867 expectations, 0 failures, 0 errors |
| 07:33:16 | brixen | if only the world were a fair place :) |
| 07:33:35 | evan | true enough. |
| 07:38:30 | brixen | evan: so something that really surprised me in this http://gist.github.com/113844 |
| 07:38:45 | brixen | look at how few calls to Array#== and #<=> in the bottom one |
| 07:38:55 | brixen | rails -h |
| 07:39:28 | brixen | basically, the distribution of calls across the array methods |
| 07:52:27 | brixen | another very interesting thing is the ratio of calls to Hash#[] and []= |
| 07:52:32 | brixen | for rails -h |
| 07:52:43 | brixen | at 80%, they are equal |
| 07:53:20 | brixen | > 80%, the ratio inverts and #[]= is quite a bit more than #[] |
| 13:53:15 | rue | brixen: You can add heuristics for the sorting, too |
| 17:19:16 | rue | Hah, "caret" not common enough name? |
| 17:20:47 | brixen | hat is shorter and hence the program will run faster |
| 17:21:29 | rue | Oh, true |
| 17:21:43 | rue | Is your syntax highlight set for red strings? |
| 17:21:58 | brixen | red strings? |
| 17:22:21 | rue | Red will make it at least double faster |
| 17:39:43 | rue | evan: Do you have a gauge on the jit time for a method? |
| 17:42:19 | evan | not off hand, no. |
| 17:42:26 | evan | I should go add some timing code in though. |
| 17:42:41 | rue | Purely empirically it seems not obscene |
| 17:42:58 | rue | (High praise, eh?) |
| 17:43:21 | evan | thank you mi lord |
| 17:44:18 | rue | Anytime |
| 17:46:35 | brixen | I really like this benchmark harness |
| 17:47:07 | evan | which? |
| 17:47:46 | brixen | the one I wrote that ouputs to yaml |
| 17:47:59 | brixen | I'm running the hash benches with cuckoo now |
| 17:48:08 | brixen | should have some results shortly |
| 17:53:45 | ddub | it should be obscene |
| 17:53:47 | ddub | obscenely fast |
| 17:53:49 | ddub | ;-) |
| 18:57:09 | rue | Maby |
| 18:58:36 | devinus | how do i install gems for rubinius? |
| 19:02:07 | rue | `vm/vm gem install ...` |
| 19:02:20 | rue | Or `bin/rbx` if you feel like typing extra ;) |
| 19:03:57 | devinus | rue: how do i enable the external gem sources? |
| 19:04:53 | rue | The gem command should take all the normal parameters, although I thought -r was already default |
| 19:05:11 | rue | You can do `vm/vm gem {env,help,sources}` etc. |
| 19:05:13 | brixen | use a .gemrc or the --source URL option |
| 19:05:37 | brixen | bin/rbx gem env to see what is set |
| 19:08:35 | dbussink | running the ci set with jit enabled fails for more people? |
| 19:09:07 | brixen | haven't tried it |
| 19:09:22 | brixen | everybody wants the shiny |
| 19:09:30 | brixen | :) |
| 19:11:02 | rue | I had a segfault in Float last time |
| 19:11:33 | dbussink | brixen: shhhiiiiinyyyy |
| 19:11:35 | dbussink | muhahaha |
| 19:12:29 | devinus | can you install merb through rbx? |
| 19:13:31 | rue | Think so, give it a try |
| 19:13:48 | rue | Was I dreaming when I thought someone already fixed the __STDC_LIMIT_MACROS problem? |
| 19:13:51 | dbussink | rue: segfaults in bignum for me |
| 19:14:39 | rue | ...Wtf, now it did include it? |
| 19:14:45 | brixen | devinus: yeah you can |
| 19:15:04 | brixen | devinus: most gems install, but if they have C ext they might not build |
| 19:15:12 | brixen | devinus: if you encounter that, just let us know |
| 19:15:22 | devinus | brixen: on leopard do_sqlite3 fails to build |
| 19:15:30 | devinus | brixen: latest git pull |
| 19:15:33 | rue | You should blame dbussink for that ;) |
| 19:15:34 | brixen | yeah, the 0.9.11 right? |
| 19:15:47 | brixen | devinus: or the do next branch? |
| 19:15:52 | dbussink | devinus: hmm, why does it fail? |
| 19:16:00 | devinus | dbussink: one sec |
| 19:16:04 | rue | I never understood this "next" branch idea |
| 19:16:46 | brixen | rue: just comes down to whether you want your head living in the past or the future |
| 19:17:11 | brixen | I prefer to live in the future |
| 19:17:18 | brixen | not much of a retro guy I guess |
| 19:17:24 | devinus | brixen, dbussink: http://pastie.org/483057 -- that's all i know |
| 19:17:32 | rue | Why would you want stuck on some previous point? That is what tags are for :P |
| 19:17:45 | brixen | oh nasty |
| 19:17:46 | brixen | bus error |
| 19:18:04 | brixen | rue: as with all things opinion... |
| 19:18:05 | dbussink | is not going to take the blame (hopefully) |
| 19:18:26 | brixen | devinus: again, was that DO head or next branch? |
| 19:18:32 | rue | brixen: Well, sure, but this one is going actively against the tool |
| 19:18:32 | brixen | or is next now head |
| 19:18:36 | dbussink | brixen: just released DO a few days ago |
| 19:18:40 | rue | Though I am not sure why I am arguing with you |
| 19:18:43 | dbussink | so should be all good |
| 19:18:48 | brixen | dbussink: sweet |
| 19:18:48 | rue | dbussink: Why are you using "next" ;) |
| 19:18:52 | devinus | brixen: uhh the latest on rubygems i suppose |
| 19:19:01 | dbussink | rue: actually, this is the same arrangement as the git guys themselves use |
| 19:19:21 | brixen | devinus: ah, you said latest git pull, so I was confused |
| 19:19:24 | dbussink | rue: so i think dkubb took it after that, i don't really care that much |
| 19:21:36 | brixen | google docs not showing the formula in a bar when you click on a formula-havin cell is mega annoying |
| 19:22:22 | brixen | like, why would I need to see my formula without double-clicking in a cell |
| 19:22:54 | brixen | ahh there it is |
| 19:23:03 | brixen | no sensible in that default |
| 19:23:14 | rue | I think that is a _repository_ |
| 19:23:57 | brixen | rue: public IRC isn't a forum for your bathroom issues |
| 19:25:25 | dbussink | the failure is consistent |
| 19:32:32 | rue | Yeah, probably not. Christ. |
| 19:32:43 | rue | dbussink: Bignum still? |
| 19:32:50 | dbussink | rue: yeah |
| 19:37:57 | devinus | holy crap |
| 19:38:00 | devinus | is it just me |
| 19:38:07 | devinus | or does rubinius take forever to install gems? |
| 19:38:18 | rue | Should figure out what exactly is breaking in -O2 on 4.2.1 |
| 19:38:42 | rue | devinus: The first one definitely takes a bit of time because stuff is getting compiled |
| 19:38:59 | rue | After that it has been reasonably fast for me |
| 19:39:07 | devinus | rue: yeah, but ri and rdoc generation is slooooow |
| 19:40:04 | devinus | how do i have an .irbrc for rbx? |
| 19:40:32 | rue | Oh, yeah, I have --no-ri and --no-rdoc in .gemrc |
| 19:44:14 | brixen | we should make --no-ri and --no-rdoc default |
| 19:44:23 | devinus | brixen: why? why does it take so long? |
| 19:46:09 | brixen | devinus: because rdoc is pure ruby and it takes rbx about 4x as long to run it right now |
| 19:46:15 | brixen | we're working on that |
| 19:46:32 | devinus | brixen: ah |
| 19:46:41 | brixen | so, unless you need rdoc generated by rbx (it's the same as mri, promise), you should turn it off |
| 19:47:06 | dbussink | brixen: btw, is rubygems still customized? because a gem update --systems gives an error for me |
| 19:49:40 | brixen | dbussink: it is |
| 19:49:44 | brixen | and we should remove it |
| 19:50:02 | brixen | and just do the normal rubygems install and check it in |
| 19:50:28 | brixen | but we may need to do some rbconfig updates |
| 19:50:29 | dbussink | brixen: this is what it gives me now: http://gist.github.com/114315 |
| 19:50:41 | brixen | I asked what rubygems depends on but got less than helpful responses |
| 19:50:58 | brixen | dbussink: yeah, not surprised |
| 19:51:04 | brixen | are you having an issue with rubygems? |
| 19:51:09 | brixen | the one we ship? |
| 19:51:41 | dbussink | brixen: there's some new stuff in 1.3.2+ i want to use, so i can package stuff without using hoe |
| 19:52:05 | brixen | ah good reason |
| 19:52:08 | dbussink | couldn't find how to release prebuilt binaries with hoe, so took some stuff from luis |
| 19:52:18 | brixen | well, I can take a look at it or you can |
| 19:52:33 | dbussink | brixen: any idea where i should look for that bug? |
| 19:52:33 | brixen | I'm working on Hash atm |
| 19:52:41 | brixen | not without looking at it |
| 19:52:56 | brixen | I know very little about the joy that is rubygems |
| 19:52:59 | dbussink | brixen: ah ok, no rush :) |
| 19:54:23 | brixen | dbussink: are you shipping rbx gems for DO? |
| 19:54:42 | dbussink | brixen: nope, rbx should be able to use the regular mri gems |
| 19:54:47 | brixen | ok |
| 19:54:53 | dbussink | the prebuilt ones are for windows and jruby |
| 19:55:40 | brixen | but you want to use rbx to make the prebuilt jruby gems? that would be... fantastic :) |
| 19:56:15 | dbussink | brixen: hehe, if rbx could build everything at once :P |
| 19:57:12 | dbussink | brixen: i wanted to see why rbx failes on the extconf, and to test it from the git clone easiest way was to upgrade rubygems |
| 19:57:18 | dbussink | so that's how i got to the failure |
| 19:57:23 | brixen | ah I see |
| 20:02:11 | devinus | rbx(1991,0xa06c0720) malloc: *** error for object 0x218ca60: double free |
| 20:02:11 | devinus | *** set a breakpoint in malloc_error_break to debug |
| 20:02:17 | devinus | finding a lot of those |
| 20:10:19 | dbussink | brixen: any tests that i should run to check whether the updated rubygems works? |
| 20:10:45 | dbussink | it installs stuff into lib/rbx/gems/1.8 now btw |
| 20:11:18 | brixen | the rubygems tests+ |
| 20:11:19 | brixen | ? |
| 20:11:39 | devinus | dbussink: installing thin bus errors too |
| 20:11:58 | dbussink | devinus: yeah, there's something up in rubinius, not in the gems |
| 20:12:10 | rue | dbussink: Installed rbx? |
| 20:13:26 | dbussink | rue: no, running it from within the clone |
| 20:13:39 | rue | Oh, with a new Gems? |
| 20:14:04 | dbussink | rue: yeah, updated rubygems |
| 20:14:11 | rue | Otherwise everything should go into ./gems |
| 20:14:37 | dbussink | brixen: did all the rubygems tests pass? |
| 20:15:41 | brixen | dbussink: dunno |
| 21:15:14 | dgtized | brixen: what is the default sort order on -P profiler? I can't work it out |
| 21:16:24 | dgtized | for instance: http://gist.github.com/114357 |
| 21:19:08 | dgtized | that and using -Ptime -Pcalls and the like don't seem to have any effect |
| 21:20:05 | rue | Mm, yeah, similar result here...but I do not recall that having been the result |
| 21:20:32 | dgtized | oh it's not time, it's percent, but still |
| 21:25:33 | rue | Think the sort is never initialised |
| 21:27:18 | dgtized | it's in set_options I thought |
| 21:27:45 | dgtized | though not sure why it's not in init |
| 21:31:27 | devinus | is there going to be a 100% compatible 1.8 C-API and then a newer -you-should-be-using-this API? |
| 21:32:31 | dgtized | rue: oh check out sort_order, I think the Array call just isn't using all the keys |
| 21:38:17 | rue | Mm, think the sorting itself...got it working with sort_by |
| 21:39:01 | dgtized | yea, I caught that, except sort_by makes it tricky to do the ordering if you wanted to use multiple columns |
| 21:39:13 | dbussink | brixen: hmm, rubygems doesn't even pass the tests on mri |
| 21:39:31 | rue | dgtized: Nah |
| 21:41:06 | dgtized | but I guess there is no way to set multiple columns anyway |
| 21:41:09 | dgtized | so maybe that's silly |
| 21:41:45 | dgtized | but yea the break cmp in the data.sort! block in flat is what is to blame |
| 21:41:50 | rue | You can give the switch multiple times |
| 21:42:03 | dgtized | no append |
| 21:42:22 | dgtized | and the default's not even an array |
| 21:42:43 | dgtized | and how would you determine if the first one is an append to the sort order, or a whole new sort order? |
| 21:43:47 | rue | Assume append? |
| 21:44:35 | dgtized | then you can't set the primary column |
| 21:44:51 | dgtized | if you want to sort by cumulative and not by percent |
| 21:45:04 | dgtized | -Pcumulative would set the order to [:percent, :cumulative] |
| 21:45:22 | dgtized | when what you want is [:cumulative,:percent] |
| 21:45:28 | dgtized | I guess you could just push to the front |
| 21:46:23 | dgtized | anyway, I don't really think we need to be able to sort on two columns |
| 21:46:37 | brixen | dgtized: why do you think that? |
| 21:46:50 | dgtized | brixen: well it's not working at all now |
| 21:46:50 | brixen | btw, evan changed the return to a break in that sort code |
| 21:46:57 | brixen | did you test that? |
| 21:47:00 | dgtized | yes |
| 21:47:06 | dgtized | look at my gist a ways back |
| 21:47:09 | rue | I think this sort_by may be cleaner anyway |
| 21:47:12 | dgtized | it's not worting at all |
| 21:47:16 | brixen | it was working fine before |
| 21:47:17 | dgtized | sorry sorting |
| 21:47:20 | dgtized | well it's not now |
| 21:47:29 | brixen | so? |
| 21:47:58 | brixen | if it's not the code that changed, then why are you looking at code that didn't change to understand why sort is not working? |
| 21:48:28 | dgtized | the only way to get sorted order as it currently stands, ignoring the fact that the sort simply DOES NOT WORK, is if you wanted to sort on multiple columns you would have to do a manual set_options call, it won't work through the commandline options |
| 21:48:51 | brixen | why is it not working now? |
| 21:49:16 | dgtized | because break cmp is returning to the inner block, and then it's always returning 0 from the sort block |
| 21:49:27 | brixen | don't change code unless you understand the root cause |
| 21:51:20 | dgtized | I understand the root cause, break doesn't break out of two blocks, it only breaks out of one block |
| 21:51:24 | dgtized | the code is wrong |
| 21:51:38 | brixen | so why is break being used there? |
| 21:51:57 | rue | dgtized: Actually, you are right, it does not allow two currently I think |
| 21:52:25 | dgtized | the break is not the problem, it's that the return value from break doesn't get passed into cmp, and cmp is not returned it just always returns 0 so it never sorts on anything |
| 21:54:41 | rue | The multicolumn sorting add is a bit nasty, probably best support it with -Pcol1,col2 or something |
| 21:55:14 | boyscout | Simplify profiler output sorting logic. Need to add multicolumns still. - b3e1bb0 - Eero Saynatkari |
| 21:55:53 | rue | dgtized: That should have -P and single-specified-column working |
| 21:56:59 | dgtized | yea I see that |
| 21:57:45 | dgtized | heh, the sort order thing is actually a place to use throw, catch |
| 21:57:51 | rue | If you want to add the multicolumn, just need to figure out how exactly to get the column names (-Pn,m,z ?) and just add it |
| 21:57:52 | dgtized | if you use the sort! |
| 21:58:15 | boyscout | CI: b3e1bb0 success. 2682 files, 10322 examples, 32867 expectations, 0 failures, 0 errors |
| 21:58:39 | dgtized | it's in loader.rb, I'll look at it |
| 22:01:28 | dgtized | sort_by is really hard to sort on multiple columns though |
| 22:07:34 | rue | Hm? |
| 22:09:01 | rue | Something like `e#-row[sort_order.first] } |
| 22:09:35 | rue | Erm, `data = data.sort_by {|row| columns.map {|col| row[col]} }.reverse` |
| 22:10:54 | brixen | that's some nice code |
| 22:12:16 | brixen | this has a very simple solution |
| 22:12:27 | brixen | which I shall push straight away |
| 22:12:55 | dgtized | alright, cause I have one two but ok |
| 22:13:00 | dgtized | two == too I mean |
| 22:13:33 | brixen | oh? |
| 22:13:38 | brixen | what's yours? |
| 22:14:15 | dgtized | http://gist.github.com/114409 |
| 22:15:21 | brixen | why did you move it to initialize? |
| 22:15:54 | dgtized | because it's clear there, it's a default, otherwise it's only a default when you set options |
| 22:16:01 | brixen | and why would you guys think sorting and then reversing is a good idea? |
| 22:16:25 | brixen | it's a default period |
| 22:16:40 | dgtized | no, because set_options has to get called |
| 22:16:45 | brixen | you put that code right above the call to set_options in initialize |
| 22:16:52 | brixen | it does get called |
| 22:16:56 | brixen | from #initialize |
| 22:17:12 | dgtized | right, but why put it over there when what's what it's always going to do? |
| 22:17:23 | brixen | what? |
| 22:17:44 | dgtized | if you look at the code, you don't initially see where @options is initialized, or where the default value for sort is when you look at initialize |
| 22:17:57 | dgtized | you have to check set_options for that |
| 22:18:05 | rue | dgtized: You could default to :percent in #sort_options |
| 22:18:05 | brixen | so? |
| 22:18:16 | brixen | that's why it's there |
| 22:18:24 | rue | Or explicitly set it when just -P is given |
| 22:18:52 | dgtized | why is it clearer to initialize @options in set_options and not just in initialize |
| 22:19:39 | dgtized | secondly why would you do an ||= every time you call set_options? |
| 22:19:52 | dgtized | if you are just doing a merge on top of it anyway? |
| 22:21:41 | dgtized | rue: the problem with setting it in -P is if someone is initializing the Profiler by doing a require 'profile' |
| 22:22:02 | dgtized | it does need to be in set options, but since it's a default why not just put it in where you initialize the @options var anyway? |
| 22:22:06 | rue | dgtized: Mm, true. Then I would go with defaulting it when requested |
| 22:22:41 | dgtized | when you initialize Profiler you are requesting a default sort order that's how the old code works, that's how the new code works |
| 22:22:55 | rue | Well, you would have to (possibly) remove it if someone does _not_ want to sort by percentage |
| 22:23:09 | dgtized | but then you have to set it to another value |
| 22:23:28 | dgtized | it's a default that you are merging over |
| 22:23:53 | rue | 'S a toggle, though, you would need to implement an on/off. So it seems simplest to check if any preferences have been given and use percentage if not |
| 22:24:59 | dgtized | how is it a toggle, as soon as the old code hit set_options, which is also called from initialize it put in a value for :sort using an ||= |
| 22:25:38 | brixen | dgtized: that's fine |
| 22:25:41 | dgtized | the only difference between the way I did it, and the old way, is that you won't get confused looking at the code and wondering if :sort has a value like you did earlier today |
| 22:25:54 | brixen | dgtized: I suggest you use this code instead of sorting and reversing http://gist.github.com/114416 |
| 22:27:03 | dgtized | brixen: yea that makes sense, I didn't like the reverse either |
| 22:27:32 | rue | I would go with whatever is easiest to read |
| 22:27:36 | brixen | and you should leave the Array() in there |
| 22:27:49 | rue | This is not exactly the place to worry about performance |
| 22:28:16 | brixen | #reverse seems so much clearer to me, you're right |
| 22:28:37 | brixen | dgtized: the client should be able to do :sort => :field |
| 22:29:12 | dgtized | yea that makes sense |
| 22:32:42 | rue | Well, whichever way you prefer. It seems the previous version was a bit trickier to decode. |
| 22:35:48 | boyscout | Fixed flat profiler sorting and added multi-columns from commandline (pair brixen, rue) - 4092d98 - Charles Comstock |
| 22:36:35 | dgtized | that acceptable to all parties? |
| 22:41:12 | rue | I like curly braces, but sure |
| 22:41:23 | boyscout | CI: 4092d98 success. 2682 files, 10322 examples, 32867 expectations, 0 failures, 0 errors |
| 22:41:27 | brixen | um, the sort_by and reverse is inscrutable to me |
| 22:41:43 | dgtized | ah, your sarcasm earlier was misread |
| 22:41:53 | brixen | the code I had is exactly what a person would do with a selection sort |
| 22:42:07 | brixen | is this column less? ok go here, else go to the next |
| 22:42:46 | dgtized | well i'm sorry, I read your sarcasm as accepting it |
| 22:43:02 | brixen | why is sorting and reversing sensible? |
| 22:43:50 | dgtized | honestly if we had reverse_each I would say sorting and then walking backwards through the list would be the most clear |
| 22:44:37 | brixen | ri Array#reverse_each ? |
| 22:44:42 | brixen | whatever |
| 22:44:44 | dgtized | it's in 1.8.7 |
| 22:45:53 | dgtized | anyway, if you want to change it to your way that's fine, I think the sort_by reverse is equivalently clear to the column one, I don't have a problem with it either way -- and again I'm sorry I misread your sarcasm as acceptance or I would have done it the other way |
| 22:46:05 | brixen | http://gist.github.com/114438 |
| 22:46:51 | dgtized | ack I'm sorry, I looked for it in array and forgot that it was one of the ones that has moved into array_186 and 187 |
| 22:47:05 | dgtized | so I presumed it was new to 1.8.7 because it wasn't in 186 |
| 22:50:08 | dgtized | anyway, it actually works for all the cases right now versus before, so if you feel that level of clarity is necessary you are welcome to change it |
| 23:11:30 | dgtized | are the send site / selector profilers no longer wired up in the kernel or just on the display end? |
| 23:50:29 | tarcieri | heh |
| 23:50:36 | tarcieri | wtf @ Ruby's parser |
| 23:50:45 | tarcieri | [:foo => 1, :bar => 2, :baz => 3] |
| 23:51:22 | loop | what did you expect? |
| 23:52:08 | tarcieri | parse error? |
| 23:52:11 | tarcieri | or |
| 23:52:18 | tarcieri | [1, 2, :foo => 1, :bar => 2, :baz => 3] |
| 23:52:21 | tarcieri | ^^^ for that to work |
| 23:52:45 | slava | sup tarcieri |
| 23:52:55 | tarcieri | slava: boggling at oddities in the Ruby parser, heh |
| 23:56:51 | rue | tarcieri: The new keyword arg syntax? |
| 23:57:06 | tarcieri | rue: this is in 1.8 |
| 23:57:26 | tarcieri | [:foo => 1, :bar => 2, :baz => 3] is apparently equivalent to [{:foo => 1, :bar => 2, :baz => 3}] |
| 23:57:37 | rue | Ah, yeah |
| 23:57:53 | tarcieri | however [1, 2, :foo => 1, :bar => 2, :baz => 3] is a parse error instead of being [1, 2, {:foo => 1, :bar => 2, :baz => 3}] |
| 23:58:16 | slava | syntax sucks |
| 23:58:43 | rue | Wee |