Show enters and exits. Hide enters and exits.
| 00:00:08 | headius | pastie |
| 00:00:23 | dfg59 | headius: pastie the change? |
| 00:00:32 | headius | no, that's for me :) |
| 00:00:36 | headius | pay it no mind |
| 00:00:37 | dfg59 | :) |
| 00:01:06 | pastie | http://pastie.org/187774 by headius. |
| 00:01:23 | headius | dgtized: there's a rewritten "add" primitive and its output |
| 00:01:41 | mkrauskopf leaves the room. | |
| 00:02:13 | wycats enters the room. | |
| 00:02:22 | mkrauskopf enters the room. | |
| 00:02:57 | vertiginous enters the room. | |
| 00:05:23 | wycats leaves the room. | |
| 00:07:21 | agardiner leaves the room. | |
| 00:07:46 | agardiner enters the room. | |
| 00:09:03 | lopex leaves the room. | |
| 00:11:32 | boyscout | 4 commits by Drew Olson |
| 00:11:33 | boyscout | * File#join checks the id of the current part rather than the initially passed part; d5de703 |
| 00:11:34 | boyscout | * File#join now correctly handles recursive arrays at any level; 6cd1021 |
| 00:11:35 | boyscout | * Array#recursively_flatten now takes an optional argument for replacing recursive ...; 671b589 |
| 00:11:36 | boyscout | * Spec for File#join now describes correct behavior for arrays with recursive sub-arrays.; b287619 |
| 00:13:27 | agardiner leaves the room. | |
| 00:13:56 | Defiler | adamwiggins: There are already specs for the 'correct' behavior of defined? |
| 00:14:09 | Defiler | adamwiggins: I haven't bothered to pass them yet, though, since nobody has ever used the return value for anything, ever. |
| 00:14:16 | mkrauskopf_ enters the room. | |
| 00:14:41 | mkrauskopf_ leaves the room. | |
| 00:14:59 | mkrauskopf_ enters the room. | |
| 00:17:59 | AndrewO enters the room. | |
| 00:18:07 | mkrauskopf_ leaves the room. | |
| 00:18:59 | trythil enters the room. | |
| 00:21:14 | wycats enters the room. | |
| 00:21:51 | mkrauskopf leaves the room. | |
| 00:22:28 | fbuilesv | adamwiggins: wouldn't it be a good idea to add a check (a should) to the write only pipes spec? |
| 00:22:53 | rubuildius_amd64 | Drew Olson: d5de703d3; 2091 files, 6711 examples, 23594 expectations, 0 failures, 0 errors; http://rafb.net/p/ZL4z5M53.html |
| 00:23:28 | radarek leaves the room. | |
| 00:23:30 | headius leaves the room. | |
| 00:26:39 | rubuildius_ppc | Drew Olson: d5de703d3; 2091 files, 6714 examples, 23622 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/187785 |
| 00:26:55 | agardiner enters the room. | |
| 00:33:59 | dc_ leaves the room. | |
| 00:37:31 | rue | Rich_Morin_: Ordered (but mutable) |
| 00:42:05 | rue | dfg59: If there is a problem with the patch, something else would break etc. that is one thing. But if your patch provides new functionality/specs/whatever that was not there before, it does not need to be a full or perfect implementation so long as it does not actually break stuff |
| 00:42:57 | rue | So looks like those should be fine. Then fine-tune from there (or re-implement if you come up with something better) |
| 00:43:02 | dfg59 | rue: that's what i figured. it expands the functionality of File#join to pass several edge cases not previously in the spec. all ci specs are still passing so i've gone ahead and checked it in |
| 00:44:24 | rue | Yeah, that is fine. One question is always whether something is actual behaviour or just an implementation detail. Strings of all kinds, error messages and so on, are usually good candidates for fixing since no-one depends on their exact format |
| 00:45:45 | dfg59 | rue: ok, gotcha. thanks for the answer. wanted to make sure i wasn't missing some critical "last minute check". i'm assuming community members would be more clued into larger changes anyway and discussions would happen here anyway. |
| 00:46:32 | Arjen_ leaves the room. | |
| 00:55:35 | dysinger enters the room. | |
| 00:55:38 | vertiginou1 enters the room. | |
| 00:57:37 | rue | Broadly, but not on Sundays :) |
| 01:01:50 | imajes enters the room. | |
| 01:03:04 | imajes leaves the room. | |
| 01:03:24 | vertiginous leaves the room. | |
| 01:04:07 | adamwiggins | fbuilesv: check on the write-only pipe would be great, but I couldn't think of a (non-ugly) way to do it |
| 01:04:26 | adamwiggins | One option would be: popen("cat > /tmp/somefile.$$") and then look for the file afterward |
| 01:04:40 | dysinger leaves the room. | |
| 01:04:50 | adamwiggins | Just feels kinda nasty though, and the truth is that the spec I wrote exposed all the problems necessary to get it working |
| 01:04:56 | adamwiggins | In combination with the r+ spec working, that is. |
| 01:06:57 | trythil leaves the room. | |
| 01:08:24 | bitbang enters the room. | |
| 01:08:28 | wycats leaves the room. | |
| 01:10:34 | dblack enters the room. | |
| 01:10:58 | dfg59 leaves the room. | |
| 01:15:27 | adamwiggins leaves the room. | |
| 01:15:57 | benny leaves the room. | |
| 01:16:07 | ezmobius enters the room. | |
| 01:21:11 | agardiner_ enters the room. | |
| 01:22:13 | bitbang leaves the room. | |
| 01:28:13 | cremes enters the room. | |
| 01:39:07 | agardiner leaves the room. | |
| 01:39:20 | vertiginou1 leaves the room. | |
| 01:40:46 | luislavena enters the room. | |
| 01:45:41 | ezmobius leaves the room. | |
| 01:48:01 | headius enters the room. | |
| 01:49:31 | boyscout | 1 commit by Luis Lavena |
| 01:49:32 | boyscout | * Corrected small typo on File#join specs under Windows.; 1da58bb |
| 01:57:36 | rubuildius_amd64 | Luis Lavena: 1da58bb7f; 2091 files, 6711 examples, 23594 expectations, 0 failures, 0 errors; http://rafb.net/p/bKz2R890.html |
| 01:59:59 | manveru | Defiler: bugging you again about extend :) |
| 02:01:47 | rubuildius_amd64 leaves the room. | |
| 02:02:36 | rubuildius_amd64 enters the room. | |
| 02:02:44 | jtoy enters the room. | |
| 02:03:28 | rubuildius_ppc | Luis Lavena: 1da58bb7f; 2091 files, 6714 examples, 23622 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/187808 |
| 02:08:36 | rubuildius_amd64 leaves the room. | |
| 02:16:49 | lstoll leaves the room. | |
| 02:23:42 | benburkert_ leaves the room. | |
| 02:24:13 | VVSiz_ enters the room. | |
| 02:38:23 | benny enters the room. | |
| 02:38:39 | brapse enters the room. | |
| 02:40:22 | headius | does rubinius do any compiler peephole optimizations? |
| 02:41:29 | agardiner | not yet |
| 02:41:51 | headius | I'm looking at doing a round of compiler improvements in JRuby, looking for strategies |
| 02:41:52 | VVSiz leaves the room. | |
| 02:42:09 | headius | right now just comparing output with javac, which does a lot of peephole opts and whatnot |
| 02:42:12 | rue | Yeah, Rubinius should totally "optimize" some "peepholes" if you know what I mean |
| 02:44:42 | xmlhacker leaves the room. | |
| 02:45:22 | obvio leaves the room. | |
| 02:46:54 | xmlhacker enters the room. | |
| 02:48:24 | obvio enters the room. | |
| 03:09:24 | marnen enters the room. | |
| 03:09:49 | marnen | question about spec organization, if anyone's around... |
| 03:10:51 | MenTaLguY enters the room. | |
| 03:11:19 | RyanTM_ leaves the room. | |
| 03:12:16 | RyanTM_ enters the room. | |
| 03:14:49 | hornbeck leaves the room. | |
| 03:17:35 | xhanjian enters the room. | |
| 03:17:45 | trythil enters the room. | |
| 03:18:40 | marnen | do protected methods get their own specfiles like public ones? |
| 03:19:05 | benburkert enters the room. | |
| 03:22:25 | rue | Each method should have its own file |
| 03:29:13 | anteaya leaves the room. | |
| 03:29:13 | marnen leaves the room. | |
| 03:31:48 | brapse leaves the room. | |
| 03:31:59 | RyanTM_ leaves the room. | |
| 03:33:02 | rubuildius_ppc leaves the room. | |
| 03:33:04 | rubuildius_ppc enters the room. | |
| 03:34:56 | trythil leaves the room. | |
| 03:37:30 | Rich_Morin | I'm trying to understand some CompiledMethod information, as detailed in http://pastie.caboo.se/187856. Help? |
| 03:48:29 | rubuildius_ppc | Luis Lavena: 1da58bb7f; 2091 files, 6714 examples, 23622 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/187862 |
| 03:58:53 | jtoy | hmmh!?!? no more ruby in ruby?!?! http://headius.blogspot.com/2008/04/promise-and-peril-for-alternative-ruby.html |
| 03:59:34 | luislavena leaves the room. | |
| 03:59:54 | headius | it's still the goal |
| 03:59:59 | headius | but it's not the case right now |
| 04:01:31 | jtoy | headius: that was a real downer article, haha, but nice summary of the landscape |
| 04:01:48 | headius | hmm, most folks told me it was pretty fair |
| 04:01:53 | headius | but I haven't heard from everyone yet |
| 04:02:20 | jtoy | yeah, it was fair, it was just a downer to see rubinius not doing as well as i thought |
| 04:02:55 | headius | well, it's still early |
| 04:03:39 | headius | just don't expect to deploy rails on rubinius this summer or something :) |
| 04:05:39 | jtoy | headius ive been using java again lately because of android, too bad i cant run jruby on there, writing plain java isnt very fun for me |
| 04:06:04 | headius | there's a few folks likely to look at JRuby on ME/Android this summer |
| 04:06:10 | headius | it has been done before |
| 04:06:22 | headius | but not in a sustainable way (used an older version of JRuby) |
| 04:07:35 | be9 enters the room. | |
| 04:09:04 | yugui enters the room. | |
| 04:09:06 | yugui leaves the room. | |
| 04:09:08 | jtoy | it would be nice if macruby could be used for the iphone! |
| 04:17:00 | headius | ahh yeah, that's a scenario I didn't think of |
| 04:26:40 | rue | Nothing stopping that. |
| 04:36:27 | GMFlash leaves the room. | |
| 04:36:37 | GMFlash enters the room. | |
| 04:36:54 | twbray enters the room. | |
| 04:40:16 | twbray | poking around rubinius source looking for how a VM in an MVM situation receives a message. Anyone have a pointer to save me some time? |
| 04:40:49 | MenTaLguY | Rubinius::VM#<< |
| 04:40:56 | MenTaLguY | oh, that's send |
| 04:41:13 | MenTaLguY | receive is Rubinius::VM.get_message, Rubinius::VM.poll_message, or Rubinius::VM.each_message |
| 04:41:39 | MenTaLguY | I believe you can also use Rubinus::VM.send_message to send to a VM based on its id (obtained via Rubinius::VM#id) |
| 04:41:46 | rue | twbray: You already implementing MVM? :) |
| 04:42:06 | rue | Correct on last |
| 04:42:23 | rue | Then there is the VMActor abstraction |
| 04:42:30 | MenTaLguY | that's a layer on top though |
| 04:43:41 | twbray | Thinking of Erlang "receive" |
| 04:44:13 | MenTaLguY | get_message is basically half a receive |
| 04:44:34 | MenTaLguY | in the VMActor case, the VMActor stuff provides the other half of the infrastructure |
| 04:44:49 | MenTaLguY | filtering, and setting unmatched messages aside in a mailbox for future receives |
| 04:45:21 | jtoy | MenTaLguY: is revactor still alive? it seems dead |
| 04:45:37 | MenTaLguY | it's still alive |
| 04:45:49 | MenTaLguY | tony's just been distracted with Rubinius stuff lately |
| 04:45:56 | foysavas leaves the room. | |
| 04:46:34 | MenTaLguY | twbray: is there something more specific you've got in mind? |
| 04:46:36 | foysavas enters the room. | |
| 04:47:39 | twbray | Well, I was reading the implementors' summit, and the description of the Rubinius MVM message API had me thinking about Erlang. Seems to me that the Erlang messaging API is very good. It'd be nice to steal lots of it for Ruby. |
| 04:48:37 | MenTaLguY | yeah, that's pretty much what tony and I are on about |
| 04:48:48 | MenTaLguY | actors aren't really necessary at the lowest levels though |
| 04:49:12 | MenTaLguY | for the most part they can be built as a higher-level API |
| 04:49:24 | rue | I think the last consensus was that we can /almost/ get to the Erlang model due to some fundamental incompatibilities |
| 04:49:54 | MenTaLguY | as of right now I basically have the whole model implemented in Actor, for intra-VM actors |
| 04:50:15 | MenTaLguY | inter-VM actors is not a huge technical leap from there |
| 04:50:32 | MenTaLguY | the main thing is sorting out message serialization details |
| 04:50:51 | MenTaLguY | (particularly around actor references) |
| 04:51:10 | AndrewO leaves the room. | |
| 04:51:24 | MenTaLguY | the main difference is that actor death (due to linking, etc) only happens at specific points |
| 04:51:34 | jtoy | but it all required 1.9+ currently? |
| 04:51:36 | MenTaLguY | setting/clearing trap_exit, receives, and one other thing I forget |
| 04:51:46 | jtoy | requires |
| 04:51:53 | MenTaLguY | which is probably desirable in a language like Ruby with side-effects |
| 04:51:58 | MenTaLguY | um, no? |
| 04:52:06 | MenTaLguY | it works today, in Rubinius |
| 04:52:09 | twbray | well, you shouldn't have side-effects form one vm to another |
| 04:52:11 | MenTaLguY | require 'actor' |
| 04:52:14 | twbray | s/form/from/ |
| 04:52:38 | MenTaLguY | twbray: that's what's implied by actor linking, which is important for supervision trees, etc. |
| 04:52:53 | MenTaLguY | twbray: that being the case, the side-effects have to be carefully controlled when the language otherwise permits side-effects |
| 04:53:04 | twbray | Erlang has zero global data plus slick message passing. Seems to me that the MVM API might be able to deliver similar framework. |
| 04:53:06 | MenTaLguY | twbray: erlang's relatively pure-functional nature limits the damage |
| 04:53:26 | twbray | Because, no cross-VM global data, right? |
| 04:53:41 | MenTaLguY | up to a point |
| 04:54:16 | twbray | Hypothesis is that Erlang message-passing goodness is beneficial even if your language isn't rigorously functional like Erlang. |
| 04:54:31 | MenTaLguY | yes |
| 04:54:57 | MenTaLguY | perhaps we're talking past each other somehow? |
| 04:55:11 | twbray | So, Erlang messaging API is well-understood and well-debugged. Why not steal it for Ruby? That's not a rhetorical question, I really wonder if it's possible. |
| 04:55:42 | MenTaLguY | maybe you need to look more closely at what Tony and I have been doing :) |
| 04:56:21 | twbray | Sure. Pointer? But it seems to me that it's the MVM scenario where it's really interesting precisely because you don't think of globals or side-effects. |
| 04:56:36 | MenTaLguY | have a look at the Actor class in lib/actor.rb |
| 04:56:46 | MenTaLguY | and agreed |
| 04:57:45 | lstoll enters the room. | |
| 04:58:44 | MenTaLguY | FWIW, the plan is basically that out-of-VM actors will be represented by proxy objects which duck-type similarly to Actor |
| 04:59:07 | MenTaLguY | I think the main difficulty is that a Rubinius VM is significantly more heavy-weight than an Erlang process |
| 04:59:12 | MenTaLguY | (it's hard to beat 300 bytes :o) |
| 05:00:52 | MenTaLguY | so there's a tradeoff between memory usage and containment of side-effects |
| 05:01:16 | MenTaLguY | between plain Actor and VMActor I'm hoping we can let people chose the proportions which suit them best |
| 05:11:24 | headius | what does erlang use at a low-level for communicating between processes |
| 05:12:00 | headius | tony made some assertions about erlang being able to send so many more messages than a similar app in Java, which didn't make sense to me |
| 05:15:52 | trythil enters the room. | |
| 05:15:53 | MenTaLguY | well, versus Java the main reason is that Erlang message delivery usually doesn't require a native thread context switch |
| 05:15:57 | MenTaLguY | that really adds up |
| 05:17:42 | MenTaLguY | Erlang is ***extremely*** lightweight with respect to transfer of control between processes |
| 05:17:50 | MenTaLguY | which is very closely tied up with message passing performance |
| 05:19:26 | headius | mmm, I see |
| 05:21:35 | twbray | MenTaLguY: sorry, distracted. Based on the Wide Finder work, I lost some respect for lightweight Erlang processes. Winning Perl & Python programs used ordinary processes, and so did the fastest Erlang implementation. |
| 05:21:46 | aotearoa leaves the room. | |
| 05:22:28 | MenTaLguY | hm, that's right |
| 05:22:37 | MenTaLguY | I remember that surprised me a lot at the time when you wrote it up |
| 05:23:09 | MenTaLguY | I never sat down and looked/thought about their designs |
| 05:23:42 | MenTaLguY | One possibility would be that they had fewer participants in a more pipelined configuration |
| 05:23:50 | twbray | I'm relaunching in a couple of weeks with an internet-facing T2000 that I'll give anyone an account on. Looking forward to it |
| 05:26:32 | MenTaLguY | neat |
| 05:30:03 | lstoll leaves the room. | |
| 05:30:19 | headius | perhaps the value of erlang is really only when you get into hundreds or thousands of processes |
| 05:30:27 | trythil leaves the room. | |
| 05:30:54 | headius | for any lower values pipelined systems will perform as well or better |
| 05:31:02 | headius | it's a theory anyway |
| 05:31:48 | headius | so perhaps it wasn't "wide enough" or perhaps erlang's relatively poor execution performance kept it from coming out ahead |
| 05:31:50 | twbray | Perhaps the value of erlang is that reduces the global-data temptation to zero, and reduces the pain by a really intuitive messaging API. |
| 05:32:14 | MenTaLguY | the thousands of processes thing doesn't hurt |
| 05:32:34 | twbray | So... what problems really *need* hundreds or thousands of processes? (I don't claim to know the answer). |
| 05:32:38 | MenTaLguY | it also reduces the temptation to make things overly stateful |
| 05:33:21 | MenTaLguY | well, remember Erlang's original environment, telephony |
| 05:33:34 | MenTaLguY | it's not unreasonable to have at least an actor per active call or something |
| 05:33:44 | MenTaLguY | and in reality probably more |
| 05:33:48 | headius | yeah |
| 05:33:58 | headius | for telephony it's pretty obvious |
| 05:34:02 | headius | you want a process per call |
| 05:34:12 | headius | or per node perhaps |
| 05:34:14 | headius | but lots anyway |
| 05:34:40 | twbray | I understand the big switches typically have 10k+ processes. Not hundreds of thousands, but lots. |
| 05:34:56 | foysavas leaves the room. | |
| 05:35:03 | headius | here's a use case for ya |
| 05:35:05 | headius | second life :) |
| 05:35:36 | headius | bazillions of processes, for every active or scripted object in the system |
| 05:35:36 | foysavas enters the room. | |
| 05:36:12 | twbray | So the thinking is... you get a nice MVM interchange API, and maybe it's interesting to extend it across multiple machines. |
| 05:36:47 | twbray | To support this, Erlang has ultra-slick exception handling too, on the assumption that procs are gonna blow up routinely. |
| 05:37:05 | twbray | local or remote |
| 05:41:03 | MenTaLguY | nods |
| 05:41:40 | rue | The problem with ultra-slick is that it is hard to grasp |
| 05:41:49 | MenTaLguY | I think you'd actually want to use an actor API rather than the raw MVM API |
| 05:41:55 | MenTaLguY | but it certainly applies |
| 05:42:08 | MenTaLguY | I did replicate Erlang's trap/exit exception stuff |
| 05:49:09 | MenTaLguY | I don't think linked actors are especially hard to grasp, actually |
| 05:53:11 | mentz_ enters the room. | |
| 05:55:04 | yugui enters the room. | |
| 06:08:19 | lstoll enters the room. | |
| 06:09:21 | obvio leaves the room. | |
| 06:17:31 | yipstar leaves the room. | |
| 06:18:01 | marnen_ enters the room. | |
| 06:22:43 | yugui_ enters the room. | |
| 06:22:48 | yugui leaves the room. | |
| 06:25:40 | boyscout | 1 commit by Marnen Laibow-Koser |
| 06:25:41 | boyscout | * Correct implementation of BigDecimal#+ and #-. There's still a lot of repetition ...; dc93d06 |
| 06:26:15 | marnen__ enters the room. | |
| 06:28:20 | joachimm enters the room. | |
| 06:28:59 | marnen__ leaves the room. | |
| 06:29:09 | marnen__ enters the room. | |
| 06:29:34 | brixen | dgtized: ping |
| 06:31:59 | benburkert leaves the room. | |
| 06:32:00 | marnen | <vent>wow, this BigDecimal stuff is starting to be a pain in the neck...we're gettin' there, though!</vent> |
| 06:32:34 | Defiler | marnen: You're doing a great job. |
| 06:32:39 | marnen | thx |
| 06:32:55 | Defiler | I mean, other than the code and the specs :) |
| 06:33:04 | marnen | I'm just hoping my implementation performs acceptably |
| 06:33:32 | marnen | I'm building as much of it on top of Bignum as possible. |
| 06:33:37 | marnen | so that should help |
| 06:34:08 | marnen | but there's a lot of to_s.to_i.to_s.to_i that's making me go cross-eyed |
| 06:34:42 | Defiler | It looks like it will be fine. Or, stated another way, if we can't make Ruby code like that perform, we are screwed anyway |
| 06:35:52 | marnen | OK. Low-level performance optimization is not a strong point of mine, so I'm just hoping I don't come up with something that is logically correct but unusably slow. So far, the tests are not taking any unreasonable length of time, but I haven't tried any real benchmarks yet. |
| 06:36:11 | Defiler | correct first, fast after |
| 06:36:19 | marnen | yeah, that's how I'm approaching it |
| 06:36:44 | marnen | (says the guy who implemented a cubic-order algorithm, then wondered why his code was hanging...not on this project, though!) |
| 06:38:06 | marnen | addition made me go pretty cross-eyed...I'm thinking multiplication and division will be worse |
| 06:38:37 | marnen_ leaves the room. | |
| 06:38:59 | marnen | I'll just implement multiplication as iterated addition :D |
| 06:39:26 | marnen | and perhaps do the whole thing in EBCDIC for speed ;D |
| 06:39:32 | Defiler | heh |
| 06:40:22 | rubuildius_ppc | Marnen Laibow-Koser: dc93d0616; 2091 files, 6715 examples, 23629 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/187918 |
| 06:40:27 | marnen | the weird thing is that, for the past week, I've been doing this by day and playing piano in West Side Story by night...talk about mental overdrive |
| 06:40:47 | marnen | that's a hard score...this is a hard class...I must be nuts |
| 06:40:51 | rue | The benefit of avoiding low-level is that you have at least a slightly better algorithmic overview |
| 06:40:55 | marnen | yup |
| 06:40:57 | MenTaLguY | that's the kind of life I want to live |
| 06:41:19 | marnen | :) |
| 06:41:35 | marnen | I wish I could do that all the time, although my head would probably explode if I did |
| 06:44:47 | rubuildius_amd64 enters the room. | |
| 06:45:28 | Defiler | marnen: Brutal. I remember learning to play that |
| 06:45:45 | manveru | Defiler: ping :) |
| 06:45:52 | rue | You could probably make a fortune if your head exploded and you could still play the piano |
| 06:45:55 | marnen | what, WSS? Cool. |
| 06:45:58 | marnen | rue: lol |
| 06:45:59 | Defiler | Yeah |
| 06:46:05 | MenTaLguY | this is one of the things I like about Ruby culture |
| 06:46:30 | MenTaLguY | I don't see conversations like this, at least not to the same degree, in other programming language groups |
| 06:46:37 | marnen | really interesting production, too, with totally new choreography -- http://www.pacetheater.com/index.cfm/product/69/west-side-story.cfm |
| 06:46:42 | MenTaLguY | Ruby seems to be practically bursting with extremely interdisciplinary people |
| 06:46:43 | Defiler | manveru: Not ignoring you, just waiting for you to talk :) |
| 06:46:58 | manveru | Defiler: uh, oh, erm, anything new about extend? |
| 06:47:04 | marnen | MenTaLguY: I guess its Lisp background is showing |
| 06:47:14 | Defiler | manveru: No, but we're getting closer. |
| 06:47:19 | manveru | heh |
| 06:47:32 | Defiler | manveru: Ruled out a bunch of things over the weekend |
| 06:47:35 | MenTaLguY | maybe |
| 06:47:43 | MenTaLguY | it seems to lack a lot of the annoying things about Lisp culture though |
| 06:47:54 | manveru | wants shoes on rubinius |
| 06:48:10 | Defiler | Has anyone read any of these books? (stand by) |
| 06:48:15 | manveru | i hate when gtk just crashes and takes down the whole thing... |
| 06:48:16 | marnen | mental: (perhaps (right? (you are))) |
| 06:48:24 | Defiler | http://www.amazon.com/Parsing-Techniques-Practical-Monographs-Computer/dp/038720248X/ |
| 06:48:25 | MenTaLguY | I have a partial pure-Ruby port of shoes that I want to get back to some day |
| 06:48:41 | Defiler | http://www.amazon.com/Compiler-Design-Handbook-Optimizations-Generation/dp/084931240X/ |
| 06:48:56 | manveru | MenTaLguY: now that would be delicious... as good as shoes can taste anyway |
| 06:49:00 | Defiler | http://www.amazon.com/Optimizing-Compilers-Modern-Architectures-Dependence-based/dp/1558602860/ |
| 06:49:11 | marnen | no, but they're going on my programming wish list now |
| 06:49:53 | manveru | hmm |
| 06:50:06 | manveru | i tried 100_000_000 ** 100_000_000 in 1.8.6 today... |
| 06:50:21 | manveru | gave me some silly warning about right hand side being too big |
| 06:50:25 | jicksta enters the room. | |
| 06:50:25 | Defiler | haha |
| 06:53:17 | marnen | so would Shoes on Rubinius be Sandalius or something? |
| 06:55:19 | marnen | manveru: what? it can't handle 1e800_000_000? |
| 06:55:34 | marnen | Actually, I'm thinking BigDecimal probably can handle that...checking |
| 06:55:55 | manveru | marnen: it results in Infinity |
| 06:56:12 | marnen | I was kind of joking |
| 06:56:15 | Defiler | Cantor would spit out his drink if he saw that |
| 06:56:28 | marnen | but as it turns out, BigDecimal *can* handle a number that big *bounce* |
| 06:56:36 | manveru | ^^ |
| 06:56:47 | Defiler | nice |
| 06:56:51 | marnen | although God knows if one could do any useful calculations with it...one second |
| 06:57:53 | marnen | eek, I just ran into the exponent overflow issue |
| 06:58:05 | manveru | you can thank me later ;) |
| 06:58:09 | marnen | thanks |
| 06:58:58 | manveru | gets back wearing his shoes |
| 06:59:08 | marnen | see, right now, I've got BigDecimal storing both the mantissa and the exponent as Bignums if necessary, but BigDecimal#exponent returns 0 if the exponent overflows Fixnum.MAX, just like it does in MRI. |
| 06:59:25 | marnen | and most of the methods use #exponent. |
| 07:00:12 | marnen | If I were to change things so as not to copy that MRI (bug|mistake), I think I could add a couple of numbers that size and get a correct result. |
| 07:00:49 | Defiler | I don't have a problem with us supporting larger number than MRI, personally |
| 07:01:02 | Defiler | as long as any valid input that MRI would accept is also supported |
| 07:01:16 | joachimm leaves the room. | |
| 07:01:30 | marnen | Right. But if some part of MRI compatibility relies on #exponent overflowing to 0, then...well, you see where I'm going with this. |
| 07:01:45 | manveru | uh oh |
| 07:01:59 | marnen | Of course, I could also use a different method internally for calculations, so that we could have our sushi and eat it too... |
| 07:02:30 | manveru | Rubinius.bug_free! |
| 07:03:26 | marnen | hmmm...return fix_silly_MRI_bugs? ?@exponent : 0 |
| 07:03:51 | marnen | er, s/\?@/\? @/ |
| 07:03:57 | Defiler | I say we go with it and wait for a 'bug' report or some failing code in the wild |
| 07:04:07 | Defiler | but I guess I'm a 'cowboy' |
| 07:04:10 | marnen | me2 |
| 07:04:25 | marnen | I just don't want to be an overly stupid cowboy. :) |
| 07:04:38 | thehcdreamer leaves the room. | |
| 07:04:59 | marnen | although it's hard to imagine that anything relies on that behavior. |
| 07:05:07 | marnen | Ahhh, what the heck. I'll go for broke. |
| 07:07:24 | Somebee enters the room. | |
| 07:07:31 | marnen | Done. And now: |
| 07:07:41 | marnen | x = BigDecimal("1e800_000_000") |
| 07:07:58 | marnen | y = BigDecimal("5e800_000_300") |
| 07:08:30 | marnen | (x + y).to_s => "0.50000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000001E800000001" |
| 07:08:39 | marnen | I love arbitrary-precision arithmetic |
| 07:09:18 | Defiler | That is boss |
| 07:10:31 | marnen | At the moment, it would crap out if I did something like x + BigDecimal("1"), but it's a start. |
| 07:11:29 | marnen | Basically, addition takes more memory the greater the difference in exponents. |
| 07:14:08 | yugui enters the room. | |
| 07:14:49 | boyscout | 1 commit by Marnen Laibow-Koser |
| 07:14:50 | boyscout | * Make BigDecimal#exponent return Bignums as necessary, not just Fixnums.; 2172e2a |
| 07:15:09 | marnen | MRI, eat your heart out |
| 07:16:39 | marnen | manveru: there you go. |
| 07:16:52 | marnen | Well, except that I haven't written BigDecimal#** yet... |
| 07:17:32 | manveru | marnen: thanks :) |
| 07:19:31 | manveru | oh, does anyone know whether IO is still blocking on win32? |
| 07:19:55 | Defiler | You mean when running the specs under MRI? |
| 07:20:15 | marnen | ok, gotta sleep |
| 07:20:33 | marnen | "a number like that/could kill your brother/stick to your own base"... |
| 07:21:23 | Defiler | You could burn yourself, exponentiating like that |
| 07:22:12 | yugui leaves the room. | |
| 07:22:18 | manveru | marnen: sleep well |
| 07:22:19 | rubuildius_amd64 | Marnen Laibow-Koser: 2172e2ac2; 2091 files, 6712 examples, 23601 expectations, 0 failures, 0 errors; http://rafb.net/p/OCrjdA10.html |
| 07:22:33 | marnen | you too |
| 07:22:35 | manveru | Defiler: in MRI, in general... |
| 07:22:48 | manveru | Defiler: reading from file and writing to socket |
| 07:23:05 | Defiler | aha. I don't know for sure |
| 07:23:09 | manveru | have no win machine to test with, but i seem to remember problems |
| 07:23:29 | marnen | Defiler: I'm thinking it is a bug after all. Certainly http://www.ruby-doc.org/stdlib/libdoc/bigdecimal/rdoc/index.html says nothing about #exponent overflowing to 0. So I think I did the right thing. |
| 07:23:36 | Defiler | If you write a test I will run it on a win machine for you |
| 07:23:39 | Defiler | if you want |
| 07:24:51 | marnen | "I like to be a BigDecimal/OK by me with big exponent"......I think I'm getting punchy now...good night! |
| 07:25:29 | manveru | Defiler: no worries... it's a bit more complicated and you'd have to get latest shoes |
| 07:26:56 | manveru | i'll get a coworker to run this later today |
| 07:27:05 | Defiler | k |
| 07:27:29 | marnen leaves the room. | |
| 07:27:45 | rubuildius_ppc | Marnen Laibow-Koser: 2172e2ac2; 2091 files, 6714 examples, 23627 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/187927 |
| 07:34:00 | twbray leaves the room. | |
| 07:41:02 | Somebee leaves the room. | |
| 07:41:11 | benburkert enters the room. | |
| 07:43:11 | agardiner | hmm.. hit a parsing bug in rubinius |
| 07:44:22 | agardiner | e = b + listsize -1 |
| 07:44:40 | agardiner | complains about unexpected tUMINUS |
| 07:44:51 | manveru | that's e = b + listsize(-1) |
| 07:45:11 | agardiner | MRI doesn't have a problem with it though |
| 07:45:22 | agardiner | (this is from ruby-debug) |
| 07:45:46 | manveru | hm? |
| 07:45:57 | agardiner | i wonder if this was handled sometime between 1.8.2 and 1.8.6... |
| 07:45:59 | manveru | irb gives me |
| 07:46:00 | manveru | (irb):12: syntax error, unexpected tUMINUS_NUM, expecting kDO or '{' or '(' |
| 07:46:17 | agardiner | huh, that's strange |
| 07:46:26 | manveru | that's on 1.8.6 |
| 07:46:33 | agardiner | i wonder why i dont get this error running ruby-debug under MRI then? |
| 07:47:09 | manveru | well, don't run ruby-debug then? :) |
| 07:47:22 | manveru | or run ruby-debug under rubinius |
| 07:47:52 | agardiner | hehe |
| 07:48:36 | agardiner | it must be taking a path in rubinius it doesn't take under MRI... |
| 07:48:48 | agardiner | which is not surprising |
| 07:49:02 | agardiner | ok, thanks - i guess its a bug in ruby-debug |
| 07:49:19 | brixen | agardiner: is it misunderstanding 'b' in debug? |
| 07:49:32 | brixen | like thinking it's a b[reak] ? |
| 07:49:47 | agardiner | no, i'm just starting rdebug, and it was erroring on the line i showed above, which comes from the list command?!? |
| 07:50:04 | brixen | hmm |
| 07:50:23 | agardiner | oh, ok i know why |
| 07:50:28 | agardiner | we error on compilation |
| 07:50:46 | agardiner | so at startup, rdebug calls load_commands, which loads list.rb |
| 07:51:04 | agardiner | when we try to compile it we get that error |
| 07:52:55 | agardiner | weirder and weirder... |
| 07:53:09 | agardiner | manveru: that does not seem to error for me on MRI |
| 07:53:13 | agardiner | what version do you have? |
| 07:53:39 | nkpart leaves the room. | |
| 07:54:54 | manveru | agardiner: some custom build from 07-09-12 |
| 07:55:22 | agardiner | hmm.. so perhaps it is a quite recent fix? |
| 07:55:31 | manveru | lemme try p114 |
| 07:55:58 | manveru | you could grep svn for changes to that error |
| 07:56:49 | manveru | what would you expect does that result in anyway? |
| 07:57:18 | agardiner | hehe, i think i'll just post a fix for ruby-debug... might be easier, since this does appear to be incorrect usage |
| 07:57:38 | manveru | well, same error in p114 |
| 07:57:48 | agardiner | there are lines above that have the correct spacing |
| 07:59:29 | Defiler | I'm going to buy myself one book from this list.. anyone have a vote on which should be first? |
| 07:59:32 | Defiler | http://www.amazon.com/gp/registry/wishlist/3RB3KX2PIHTWE |
| 08:00:42 | mkrauskopf enters the room. | |
| 08:13:03 | Somebee enters the room. | |
| 08:17:13 | thehcdreamer enters the room. | |
| 08:18:20 | twbray enters the room. | |
| 08:38:18 | headius | Defiler: they all look so thrilling |
| 08:38:39 | headius | Parsing Techniques is my idea of hell |
| 08:39:05 | headius | get that $100 compiler book |
| 08:42:13 | agardiner leaves the room. | |
| 08:43:14 | Maledictus enters the room. | |
| 08:50:34 | twbray leaves the room. | |
| 08:52:11 | octopod enters the room. | |
| 08:52:44 | headius leaves the room. | |
| 08:53:04 | headius enters the room. | |
| 08:53:40 | d2dchat leaves the room. | |
| 09:02:16 | VVSiz | simple mention of word "compiler" adds at least $50 to the book cost, it seems |
| 09:24:56 | headius | it's an expensive word |
| 09:28:36 | headius leaves the room. | |
| 09:29:06 | headius enters the room. | |
| 09:29:59 | lstoll leaves the room. | |
| 09:30:02 | benburkert leaves the room. | |
| 09:32:48 | qwert666 enters the room. | |
| 09:41:18 | Arjen_ enters the room. | |
| 10:30:03 | kw leaves the room. | |
| 10:46:06 | xhanjian leaves the room. | |
| 10:52:01 | chris2 enters the room. | |
| 10:54:47 | maduyb__ enters the room. | |
| 10:55:04 | maduyb__ leaves the room. | |
| 10:58:41 | lstoll enters the room. | |
| 11:16:09 | Fullmoon enters the room. | |
| 11:21:22 | yugui_ leaves the room. | |
| 11:24:22 | JimMc enters the room. | |
| 11:26:11 | olabini enters the room. | |
| 11:30:29 | jtoy leaves the room. | |
| 11:32:49 | yaroslav enters the room. | |
| 11:34:48 | mkrauskopf leaves the room. | |
| 11:35:04 | mkrauskopf enters the room. | |
| 11:50:51 | webmat enters the room. | |
| 11:53:49 | imajes enters the room. | |
| 12:00:08 | imajes leaves the room. | |
| 12:29:47 | wvdschel enters the room. | |
| 12:34:00 | wvdschel leaves the room. | |
| 12:35:25 | radarek enters the room. | |
| 12:38:55 | RyanTM enters the room. | |
| 12:40:13 | ctennis leaves the room. | |
| 12:40:36 | ctennis enters the room. | |
| 12:41:13 | ctennis leaves the room. | |
| 12:52:31 | Fullmoon leaves the room. | |
| 12:52:33 | chris2 leaves the room. | |
| 13:03:34 | obvio enters the room. | |
| 13:09:17 | ctennis enters the room. | |
| 13:11:15 | Fullmoon enters the room. | |
| 13:18:25 | hornbeck enters the room. | |
| 13:20:24 | dodecaphonic enters the room. | |
| 13:25:08 | RyanTM leaves the room. | |
| 13:25:22 | RyanTM_ enters the room. | |
| 13:27:58 | dodecaphonic leaves the room. | |
| 13:32:04 | qwert666 leaves the room. | |
| 13:32:20 | qwert666 enters the room. | |
| 13:33:13 | RyanTM enters the room. | |
| 13:33:17 | RyanTM_ leaves the room. | |
| 14:00:36 | lstoll leaves the room. | |
| 14:09:46 | qwert666_ enters the room. | |
| 14:14:03 | lstoll enters the room. | |
| 14:15:48 | AndrewO enters the room. | |
| 14:15:49 | trythil enters the room. | |
| 14:17:37 | wmoxam enters the room. | |
| 14:23:31 | RyanTM leaves the room. | |
| 14:28:18 | agile leaves the room. | |
| 14:29:01 | qwert666 leaves the room. | |
| 14:31:49 | moofbong enters the room. | |
| 14:39:47 | macournoyer enters the room. | |
| 14:39:58 | moofbong leaves the room. | |
| 14:42:13 | smparke1 leaves the room. | |
| 14:58:37 | d2dchat enters the room. | |
| 14:59:49 | moofbong enters the room. | |
| 15:01:11 | trythil leaves the room. | |
| 15:03:14 | NoKarma enters the room. | |
| 15:06:15 | NoKarma leaves the room. | |
| 15:13:10 | fbuilesv enters the room. | |
| 15:14:28 | yugui enters the room. | |
| 15:14:37 | lstoll leaves the room. | |
| 15:17:10 | lstoll enters the room. | |
| 15:20:57 | lstoll leaves the room. | |
| 15:22:28 | headius | hey guys |
| 15:22:35 | headius | check this out: http://pastie.org/188061 |
| 15:22:40 | headius | look at 1.9's ivar get speed |
| 15:23:43 | marnen enters the room. | |
| 15:25:00 | srbaker leaves the room. | |
| 15:25:08 | probablycorey enters the room. | |
| 15:26:54 | benstiglitz enters the room. | |
| 15:28:32 | Defiler | The plot thickens |
| 15:31:31 | headius leaves the room. | |
| 15:31:36 | headius enters the room. | |
| 15:31:36 | Fullmoon leaves the room. | |
| 15:32:08 | headius leaves the room. | |
| 15:32:12 | headius enters the room. | |
| 15:32:59 | headius_ enters the room. | |
| 15:33:02 | headius leaves the room. | |
| 15:33:53 | headius enters the room. | |
| 15:39:16 | yaroslav leaves the room. | |
| 15:42:17 | Fullmoon enters the room. | |
| 15:46:35 | srbaker enters the room. | |
| 15:47:12 | jtoy enters the room. | |
| 15:47:44 | agile enters the room. | |
| 15:48:17 | qwert666_ enters the room. | |
| 15:48:40 | jtoy leaves the room. | |
| 15:49:01 | jtoy enters the room. | |
| 15:50:20 | headius | Defiler: seems to be a peephole optimization |
| 15:50:38 | headius | sequences of same ivar accesses getting reduced to a single access |
| 15:50:45 | headius | benchmark optimizations :) |
| 15:51:08 | headius_ leaves the room. | |
| 15:51:18 | Defiler | headius: hah |
| 15:51:46 | Defiler | Oh well; it isn't like I don't have sympathy for the difficulty level of implementing Ruby |
| 15:51:48 | headius | probably similar optimizations for sequences of other variables, so my benchmarks will be useless |
| 15:52:34 | Defiler | Sounds like you need a get/set random ivar benchmark |
| 15:56:05 | dblack leaves the room. | |
| 15:56:53 | yipstar enters the room. | |
| 15:59:43 | srbaker leaves the room. | |
| 16:01:21 | enebo enters the room. | |
| 16:05:45 | qwert666 leaves the room. | |
| 16:09:56 | boyscout | 1 commit by Marnen Laibow-Koser |
| 16:09:57 | boyscout | * Factor out some repetition.; 6c811f8 |
| 16:11:14 | twbray enters the room. | |
| 16:14:11 | smparke1 enters the room. | |
| 16:16:18 | marnen_ enters the room. | |
| 16:17:06 | marnen | I guess my connection is that flaky. :) |
| 16:17:18 | rubuildius_amd64 | Marnen Laibow-Koser: 6c811f8a9; 2091 files, 6712 examples, 23601 expectations, 0 failures, 0 errors; http://rafb.net/p/3OwcZb84.html |
| 16:19:37 | nicksieger leaves the room. | |
| 16:22:43 | Illocution leaves the room. | |
| 16:23:18 | rubuildius_ppc | Marnen Laibow-Koser: 6c811f8a9; 2091 files, 6714 examples, 23627 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/188089 |
| 16:24:41 | marnen leaves the room. | |
| 16:30:14 | twbray leaves the room. | |
| 16:31:11 | Illocution enters the room. | |
| 16:34:31 | jtoy leaves the room. | |
| 16:34:50 | benstiglitz | G'morning. |
| 16:35:02 | benstiglitz | Could someone apply the patch from #497? I don’t see outbound SSH ever working from this location =( |
| 16:35:19 | dblack enters the room. | |
| 16:36:31 | GMFlash leaves the room. | |
| 16:36:40 | GMFlash enters the room. | |
| 16:41:19 | Defiler | benstiglitz: I can as soon as I switch locations. Just aboiut to move |
| 16:41:29 | yugui leaves the room. | |
| 16:41:30 | benstiglitz | Sure, thanks. |
| 16:41:40 | benstiglitz | So annoying to not be able to do it myself. |
| 16:42:30 | lopex enters the room. | |
| 16:42:36 | Defiler | someone should make an offline internet :) |
| 16:44:37 | dgtized | brixen: ping |
| 16:44:51 | dgtized | evan: ping |
| 16:45:17 | brixen | dgtized: hey |
| 16:46:40 | brixen | dgtized: it seemed that DRb spec was failing because more than one process was trying to open port 9001 |
| 16:46:47 | lstoll enters the room. | |
| 16:47:22 | brixen | dgtized: regardless of whether DRb has a bug, that spec shouldn't use a hardwired port, because it is very reasonable to expect more than one spec process to run concurrently, and maybe hit that spec |
| 16:47:37 | brixen | dgtized: also, I'd like you to discuss something before reverting it |
| 16:53:00 | dgtized | brixen: sorry about reverting without asking, but it actually did not fix the problem on my machine, the spec still failed |
| 16:53:10 | nicksieger enters the room. | |
| 16:53:36 | dgtized | brixen: it's a combination problem, you are correct that if multiple spec runners were going that would cause an issue, but it's also just that the previous spec doesn't release the port |
| 16:54:07 | dgtized | brixen: and so you used Process.pid to fix it, when that doesn't actually change anything if it's still in process |
| 16:54:30 | brixen | dgtized: well, it will fix it for multiple processes |
| 16:54:43 | dgtized | brixen: yes, but it still fails on the default case |
| 16:54:46 | brixen | so, please check that back in and we can document/work on the other case |
| 16:55:03 | brixen | there's no reason to confound the two cases |
| 16:56:22 | dgtized | why, I view running specs concurrently as an edge case, just running the spec in a single run and not releasing the socket is not |
| 16:57:10 | dgtized | secondly, what exactly should we do about the actual bug in DRb or Rubinius or wherever it is |
| 16:57:29 | brixen | dgtized: does my commit prevent an issue when running the specs concurrently? |
| 16:57:43 | brixen | dgtized: in other words, as I've clarified that case, is the spec incorrect? |
| 16:58:50 | dgtized | brixen: I also note that the same fix was not applied to any of the TCPServer specs, so they will currently fail under the same issue |
| 16:59:19 | brixen | dgtized: so what, apply it then |
| 16:59:32 | brixen | don't confuse the different issues |
| 16:59:35 | dgtized | brixen: so it seems to me that you checked in that patch to fix the apparent spec failure and it worked because sometimes it doesn't fail because of the race condition |
| 16:59:40 | brixen | we can work on the bug separately |
| 16:59:53 | brixen | dgtized: stop! |
| 16:59:55 | dgtized | brixen: ok, I will add a spec for the bug |
| 17:00:11 | brixen | is the change I checked in wrong in and of itself? |
| 17:00:26 | dgtized | brixen: but I didn't realize we were actually fixing things to do concurrent results so in that sense, yes it is |
| 17:00:35 | brixen | yes it is wrong? |
| 17:01:18 | dgtized | brixen: because it was targeting to fix the spec failure, except the spec failure wasn't fixed -- if we actually want the specs to be concurrent then we need to patch a whole load of other things |
| 17:01:42 | brixen | yes, we want the specs to be sane running concurrently |
| 17:01:45 | dgtized | brixen: since it was targeting that spec failure it is wrong because it fails to fix the problem |
| 17:02:04 | brixen | it was targeting *my estimation of the spec failure* |
| 17:02:25 | brixen | which was different than yours |
| 17:02:26 | dgtized | brixen: but that style of fixing is more apt to mask problems |
| 17:02:35 | brixen | why? |
| 17:02:55 | dgtized | because if you fix the spec to work around a bug then what use is the spec |
| 17:03:04 | brixen | write a spec for the bug |
| 17:03:07 | NoKarma enters the room. | |
| 17:03:09 | brixen | you are stuck on this work around thing |
| 17:03:20 | brixen | it's *not* trying to work around anything |
| 17:04:48 | dgtized | brixen: I will write a spec for the bug, but yes your spec fix was an attempt to fix a bug that you perceived to be in the spec |
| 17:05:18 | dgtized | brixen: the reason this showed up, is because at some point our timing changed so it caused the bug more frequently, in all other cases we would have just tagged the spec as failing |
| 17:06:50 | dgtized | brixen: if you are actually worried about concurrent runs, please go and submit a patch for all of Socket |
| 17:07:05 | brixen | excuse me? |
| 17:07:15 | dgtized | brixen: all of socket will fail on concurrent runs |
| 17:07:18 | brixen | so, if I don't fix everything, I fix nothing? |
| 17:07:32 | dgtized | brixen: so I am curious why you singled out this spec for concurrency? |
| 17:07:40 | fbuilesv leaves the room. | |
| 17:07:48 | brixen | because it was failing, with a hardcoded port |
| 17:07:55 | brixen | because I just added a concurrent mode to mspec |
| 17:08:01 | brixen | because headius and I have talked about this issue |
| 17:08:06 | brixen | because I felt like it? |
| 17:08:20 | brixen | seriously, my only point is that my commit did not make an incorrect spec |
| 17:08:23 | dgtized | can you run the concurrent mode on Socket? |
| 17:08:28 | brixen | the issue of a bug is a *separate matter* |
| 17:08:50 | joachimm enters the room. | |
| 17:09:29 | dgtized | brixen: I will acknowledge that it did not actually make it incorrect, but in light of the fact that we don't have a bug spec, it did mask the bug, so your fix should have been applied concurrently with a patch to spec the bug, which I will do, but as a single checkin it attempts to fix the wrong thing |
| 17:09:39 | dgtized | and as a result would leave a bug in place |
| 17:09:46 | dgtized | which is what was so dangerous about it |
| 17:10:06 | brixen | sorry, that's a completely untenable criterion |
| 17:10:10 | brixen | we write specs in pieces |
| 17:10:28 | brixen | we don't always know the full behavior when we write a spec for part of it |
| 17:10:34 | brixen | it's an iterative process |
| 17:10:54 | brixen | identify a bug, write a spec *for* that bug |
| 17:11:04 | brixen | don't depend on a spec to fail for a collateral reason |
| 17:13:11 | dgtized | yes, but if you patch a spec that is acting strange make sure you don't mask a bug it did happen to reveal without including a spec for that as well |
| 17:14:40 | evan | morning |
| 17:14:41 | benny leaves the room. | |
| 17:14:49 | dbussink | evan: morning |
| 17:14:51 | dbussink | had a fun weekend? |
| 17:15:31 | RyanTM enters the room. | |
| 17:15:38 | dgtized | evan: cpp vm is missing the gen directory so can't test it |
| 17:15:46 | evan | dgtized: mkdir gen |
| 17:15:55 | dgtized | evan: did that but you have code in it |
| 17:16:11 | evan | it's autogenerated by running instructions.rb in vm/ |
| 17:16:22 | dgtized | gen/iseq_instruction_names.hpp |
| 17:16:26 | evan | gen/ would be a silly name if the code weren't autogenerated. |
| 17:16:27 | dgtized | is that in the rakefile then? |
| 17:16:32 | evan | it's all in instructions.rb |
| 17:16:35 | evan | creation wise. |
| 17:16:45 | dgtized | but does instructions.rb get called from the rakefile? |
| 17:17:41 | dgtized | ok that does fix it it looks like, it's just tricky to follow like that when it's not in the rake file |
| 17:20:10 | loincloth enters the room. | |
| 17:24:37 | evan | dgtized: could be an oversight |
| 17:30:44 | dgtized | brixen: so what is the suggested way to make concurrent specs run cleanly for this type of thing? |
| 17:31:01 | dgtized | brixen: because if I try incrementing the port from each run they will collide |
| 17:31:22 | brixen | dgtized: what's wrong with the way I did it? |
| 17:31:53 | dgtized | brixen: it's not what's wrong with it alone, it's what is also necessary to get a new port between specs |
| 17:32:16 | Somebee leaves the room. | |
| 17:32:23 | dgtized | brixen: namely that I have to increment the port number |
| 17:32:47 | moofbong leaves the room. | |
| 17:32:47 | dgtized | brixen: so if you use 9001 + Process.pid & 7 then it's still likely it will collide |
| 17:32:57 | Somebee enters the room. | |
| 17:33:37 | headius | morning gents |
| 17:34:00 | Somebee leaves the room. | |
| 17:34:35 | Somebee enters the room. | |
| 17:34:46 | dgtized | brixen: http://www.pastie.org/188117 |
| 17:35:28 | twbray enters the room. | |
| 17:35:49 | Somebee_ enters the room. | |
| 17:35:58 | dgtized | the port collision problem is that the socket is not getting freed inside that single process not multiple ones |
| 17:36:50 | dgtized | secondly I really don't like the idea of randomly pulling ports out of a hat for specs based on the process.pid |
| 17:37:01 | dgtized | because we are still going to get concurrent collisions with something that way |
| 17:37:49 | dgtized | also what are you doing about the linking/unlinking specs? |
| 17:38:07 | thehcdreamer leaves the room. | |
| 17:39:34 | brixen | dgtized: the 9001 + .. thing is unlikely to collide |
| 17:39:53 | dgtized | brixen: even if there are 7 different DRb spec files that each use it? |
| 17:39:59 | brixen | dgtized: the lower order digits likely to be distinct on multiple runs |
| 17:40:06 | brixen | dgtized: 7? |
| 17:40:23 | yaroslav enters the room. | |
| 17:40:23 | dgtized | ack, I misread the & as a % |
| 17:40:47 | brixen | dgtized: what's the linking/unlinking spec? |
| 17:41:20 | dgtized | the file existance / deletion specs, I don't know if we actually have them but presumably they need to be run in a set order |
| 17:41:29 | dgtized | and if they use the same filename |
| 17:41:40 | brapse enters the room. | |
| 17:42:33 | dgtized | brixen: http://git.rubini.us/?p=code;a=blob;f=spec/ruby/1.8/library/socket/fixtures/classes.rb;h=3c55328c3 2d5a7b4851e8cf6c03c3b831fbdb14c;hb=refs/heads/master |
| 17:45:31 | dgtized | brixen: http://git.rubini.us/?p=code;a=blob;f=spec/ruby/1.8/core/file/shared/unlink.rb;h=37f5d9e7bc59a1ab2 c4b6937627c7c8a9b4ed79e;hb=refs/heads/master |
| 17:45:42 | dgtized | brixen: that is shared so presumably more then one unlinking spec uses it |
| 17:45:43 | RyanTM leaves the room. | |
| 17:46:54 | brixen | dgtized: we can write helpers like #tmp for any of these cases |
| 17:47:07 | brixen | mspec/lib/mspec/helpers/tmp.rb |
| 17:47:57 | brixen | dgtized: there is probably not a "perfect" way to get uniqueness for these, but we can reduce the likelihood of a clash to statistically insignificant numbers |
| 17:51:25 | dgtized | brixen: I really don't feel like thinking about concurrent spec runs it's a painful problem to worry about -- so I will checkin my pseudo fix for DRb and then I would advise you deal with making sure it doesn't clash with Socket or anything else that uses port numbers |
| 17:52:48 | Somebee leaves the room. | |
| 17:55:26 | NoKarma | heya all |
| 17:57:15 | evan | ARG |
| 17:57:22 | evan | some fucking spammer is putting my email in the From header |
| 18:01:54 | evan | is there anything I can do about this? |
| 18:02:28 | TheProkrammer | Nope. :( |
| 18:02:55 | djwhitt | not totally true |
| 18:03:08 | djwhitt | you can make sure you have spf setup and hope that other mail servers honor it |
| 18:03:42 | djwhitt | http://www.openspf.org/Introduction |
| 18:04:42 | boyscout | 3 commits by Charles Comstock |
| 18:04:43 | boyscout | * hack to fix DRb.start_service spec to at least test start_service; f3f94c9 |
| 18:04:44 | boyscout | * spec for DRb.stop_service to see if it clears the socket correctly; 4c8d6d9 |
| 18:04:45 | boyscout | * Revert "Revert "Made DRb spec depend partially on PID so multiple runs don't clash.""; 03cb539 |
| 18:05:32 | TheProkrammer | And there's other things other server's should check (from domain vs sender domain for example), but you can't stop someone from spoofing the From header. |
| 18:05:39 | octopod leaves the room. | |
| 18:05:44 | dgtized | brixen: happy? |
| 18:11:15 | brixen | dgtized: we'll figure out something to better insulate the specs from false failures. it's an evolving process |
| 18:11:58 | benny enters the room. | |
| 18:12:19 | rubuildius_amd64 | Charles Comstock: f3f94c9b5; 2091 files, 6713 examples, 23606 expectations, 0 failures, 0 errors; http://rafb.net/p/oRdcWt83.html |
| 18:12:24 | dysinger enters the room. | |
| 18:15:38 | dysinger leaves the room. | |
| 18:17:45 | Ingmar leaves the room. | |
| 18:17:56 | rubuildius_ppc | Charles Comstock: f3f94c9b5; 2091 files, 6715 examples, 23632 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/188136 |
| 18:20:09 | probablycorey leaves the room. | |
| 18:21:02 | jp_tix | so anyone know what this maglev thing is? are they creating a commercial, smalltalkish Ruby VM? |
| 18:21:29 | Ingmar enters the room. | |
| 18:22:02 | dysinger enters the room. | |
| 18:28:27 | probablycorey enters the room. | |
| 18:30:05 | dambalah enters the room. | |
| 18:31:03 | danlucraft enters the room. | |
| 18:34:13 | joachimm leaves the room. | |
| 18:40:39 | moofbong enters the room. | |
| 18:41:05 | imajes leaves the room. | |
| 18:49:41 | bitbang enters the room. | |
| 18:50:09 | marnen_ leaves the room. | |
| 18:52:35 | brapse leaves the room. | |
| 18:54:48 | TheVoice enters the room. | |
| 18:54:53 | headius | good response evan |
| 18:55:09 | evan | thanks. |
| 18:55:30 | headius | the "ruby in ruby" thing is more a religious or opinionated discussion...we'll just have to agree to disagree there |
| 18:55:36 | evan | sure |
| 18:55:40 | headius | I wouldn't even have bothered if you didn't use it to put other impls in a bad light |
| 18:55:45 | imajes enters the room. | |
| 18:55:51 | headius | that whole "JRuby is Ruby for Java developers" thing |
| 18:55:57 | evan | i did open the door |
| 18:56:03 | evan | with my "hard hitting" slides. |
| 18:56:04 | evan | :) |
| 18:56:13 | headius | how about I start saying "Rubinius is for Ruby developers who think Ruby's too darn fast" |
| 18:56:23 | headius | I've been pulling punches til now |
| 18:56:30 | tarcieri | haha headius |
| 18:56:45 | evan | so you're taking the gloves off now? |
| 18:56:48 | headius | nah |
| 18:56:59 | headius | I just thought I'd toss one grenade out there and see what happens |
| 18:57:10 | headius | I'll be as publicly polite as ever |
| 18:57:13 | headius | :) |
| 18:57:22 | headius | and you know I DID warn you about the eval order thing |
| 18:57:26 | evan | you have a funny definition of public polite. |
| 18:57:28 | headius | and give you examples of why it was broken |
| 18:57:32 | evan | i'm sure you did. |
| 18:57:43 | dodecaphonic enters the room. | |
| 18:58:08 | evan | I worry you're putting me in a light of a guy who's turning Rubinius into something completely different |
| 18:58:15 | evan | a not Ruby. |
| 18:58:25 | evan | esp. since you used the work frequently |
| 18:58:28 | headius | I didn't mean to give that impression |
| 18:58:29 | evan | as though it happens daily. |
| 18:58:36 | imajes leaves the room. | |
| 18:59:01 | brixen | headius: it's disingenuous for you to say "ruby in ruby" meme must die and then advocate for use to develop the core libs so more impl can use them |
| 18:59:08 | brixen | s/use/us/ |
| 18:59:26 | brixen | we should be promoting "ruby in ruby" meme for everyone |
| 18:59:30 | headius | the "ruby in ruby" meme wouldn't have to die then |
| 19:00:07 | headius | if it were used entirely for positive reasons, such as to promote more folks helping to spec and write ruby impls of core classes and extensions, it wouldn't be a problem |
| 19:00:14 | headius | but using it as a club...well, that's asking for it |
| 19:00:37 | brixen | headius: well, it's used as a differentiator for sure |
| 19:00:40 | brixen | and it's quite true |
| 19:00:48 | brixen | true enough for you to get snarky about it often |
| 19:00:51 | headius | high road, gents...you've got enough glass in your house that you should avoid throwing those stones |
| 19:01:06 | brixen | heh |
| 19:01:12 | headius | and there have been plenty more of them lobbed at JRuby publicly than at Rubinius |
| 19:01:29 | evan | headius: you should consider giving some context to your objection to the RiR meme |
| 19:01:40 | brixen | ohh nice RiR |
| 19:01:51 | brixen | our RiR can beat up your RoR |
| 19:01:54 | evan | headius: ie, my RubyConf 2007 presentation |
| 19:02:05 | evan | it's too far back for people to recall without prompting. |
| 19:02:05 | headius | and subsequent presentations |
| 19:02:12 | headius | you love to call us out on LOC |
| 19:02:13 | evan | when? |
| 19:02:14 | VVSiz | hides behind the bushes... |
| 19:02:23 | evan | i haven't talked about it since RC07 |
| 19:02:27 | wycats enters the room. | |
| 19:02:32 | evan | mainly because it's just a stupid point. |
| 19:02:38 | evan | well, not stupid. |
| 19:02:43 | evan | but it's not helping anyone |
| 19:03:01 | evan | I talk about how the Rubinius kernel is written in Ruby |
| 19:03:01 | brixen | headius: with 180k loc java, our 12-22k loc of C++/C isn't really something to laugh at |
| 19:03:05 | evan | thats the extent of it. |
| 19:03:05 | brixen | or get upset about |
| 19:03:28 | headius | brixen: with performance better than 1.8, sometimes better than 1.9, and almost all Ruby apps working, our 180kloc of Java isn't really something to insult |
| 19:03:44 | brixen | headius: how does RiR insult jruby? |
| 19:03:55 | enebo | brixen: 180k? |
| 19:03:57 | brixen | I think you're perceiving an insult that might not be there |
| 19:04:07 | brixen | enebo: rough numbers, you tell me |
| 19:04:17 | evan | when I talk about the Rubinius kernel, it's not a dig at anyone else |
| 19:04:21 | brixen | enebo: find src -name '*.java' | xargs wc -l |
| 19:04:24 | enebo | I think like 140k, but that also includes things like the parser |
| 19:04:24 | wycats | headius: the fact is that the vast majority of the kernel actually is in Ruby |
| 19:04:28 | headius | I consider it an insult to claim rubinius is better solely because JRuby is written in "not ruby" |
| 19:04:34 | wycats | which means that most stack traces end in Ruby |
| 19:04:48 | evan | headius: other than RC07, when have I implied that? |
| 19:04:59 | brixen | headius: well, from me personally, it's not an insult |
| 19:05:11 | enebo | brixen: That command only gives me 143k |
| 19:05:14 | brixen | headius: unless you take me saying "this is a more sensible way to do it" as insulting :P |
| 19:05:24 | headius | that's an opinion |
| 19:05:32 | headius | too often presented as fact |
| 19:05:34 | brixen | enebo: dunno, just did svn update and that command |
| 19:05:40 | bitbang leaves the room. | |
| 19:05:43 | evan | headius: if you want us to take the high ground, then you must as well. |
| 19:05:48 | enebo | hmm, I have trunk checked out...weird |
| 19:05:58 | enebo | As you would expect me to :) |
| 19:06:00 | headius | evan: when have I not, other than this post? |
| 19:06:29 | evan | well, you see to be harboring illwill |
| 19:06:30 | brixen | enebo: http://pastie.org/188160 |
| 19:06:47 | evan | about some continuing RiR slight |
| 19:06:53 | evan | which I can tell you is not there. |
| 19:07:06 | enebo | brixen: so same number then |
| 19:07:08 | brixen | headius: we simply like our way better :P |
| 19:07:14 | headius | I'm sure you do :) |
| 19:07:21 | brixen | enebo: heh, misread, sorry |
| 19:07:27 | enebo | no problem |
| 19:07:31 | brixen | enebo: it was having to parse all those digits |
| 19:07:34 | brixen | :D |
| 19:07:42 | enebo | brixen: You guys still use MRI parser? |
| 19:07:47 | TheProkrammer | bah, the beauty of rubinius is if the base libraries are written in pure ruby, and base the specs, all impls can partake of the joyusness. |
| 19:07:50 | brixen | enebo: yeah |
| 19:08:04 | enebo | add several k to your lines of code |
| 19:08:11 | enebo | of subtract ours |
| 19:08:19 | enebo | (just being mildly pedantic) |
| 19:09:00 | headius | and I'd be interested in knowing how many of your 150 contributors have done more than a commit the past month |
| 19:09:02 | headius | or even one commit |
| 19:09:13 | headius | you put those numbers out there like you've got an army of contributors |
| 19:09:34 | headius | you misrepresent the truth |
| 19:09:41 | enebo | evan: Actually that one wrankled me a bit....Most committers seem to do near 100% spec work from what I have seen |
| 19:09:46 | headius | there's where a lot of the ill will comes from |
| 19:09:47 | wycats | headius: that's not quite true |
| 19:10:19 | enebo | At least from my RSS feed of rubinius check ins |
| 19:10:25 | brixen | enebo: find shotgun/lib/ -type f -name '*.[ch]' | xargs wc -l => 34383 |
| 19:10:31 | brixen | enebo: parser is in that, so... |
| 19:10:36 | enebo | oh ok |
| 19:10:37 | evan | headius: In presentation, I typically indicate that we have 100+ project committers, with 20+ actives at a time |
| 19:10:52 | enebo | I was not sure if it was...and that is after generation of bison file? |
| 19:10:55 | evan | i skipped that in my post for the sake of brevity |
| 19:11:10 | brixen | enebo: yeah, I imagine |
| 19:11:17 | enebo | ok |
| 19:11:18 | brixen | enebo: it's from a built co |
| 19:11:22 | evan | headius: but again, it's not a dig. i'm not trying to say that we're better, it's just the way it is. |
| 19:11:27 | headius | tracking non-spec changes, rubinius is no more active than JRuby...so I think there's a bit of bluster there |
| 19:11:34 | brixen | enebo: naive surely, but it's still a comparison |
| 19:11:38 | evan | headius: in the same way I don't consider it a slight when you constantly talk about using the best VM in the universe |
| 19:11:46 | imajes enters the room. | |
| 19:11:50 | evan | or that you have first class java integration |
| 19:11:57 | headius | *one of* the best :) |
| 19:11:57 | tarcieri | evan: did you see I compiled the Mongrel parser with your Ragel patch? |
| 19:12:02 | evan | tarcieri: i did! |
| 19:12:12 | evan | headius: but you need to consider other points of view here |
| 19:12:16 | enebo | brixen: It is tough too since we have quite a few optional pieces in our codebase which are not neccesary for 1.8 (like YARV, Rubinius, Optional parser) |
| 19:12:20 | evan | headius: i think you're getting bent out of shape for nothing |
| 19:12:21 | tarcieri | evan: there's one place I think you need a newline that you don't have one |
| 19:12:25 | evan | tarcieri: ack. |
| 19:12:27 | tarcieri | evan: on one of the Rubinius.asm blocks |
| 19:12:29 | headius | no, it's not nothing |
| 19:12:41 | VVSiz | btw, amount of non-commenting Java source code lines in JRuby: 88068 :) |
| 19:12:51 | brixen | enebo: ok, I'm not here to tell you your numbers, but subtract all that, I'm guess more java than ruby, and more java than our C/C++ :) |
| 19:12:54 | enebo | brixen: and a more complete 1.8 impl (at this point in time) |
| 19:12:55 | tarcieri | evan: the generated code was something to the effect of "Rubinius.asm { ... } begin" |
| 19:13:12 | enebo | brixen: yeah...we have a higher ratio |
| 19:13:18 | imajes leaves the room. | |
| 19:13:26 | evan | stop with the LOC comparison. |
| 19:13:27 | evan | please. |
| 19:13:32 | headius | brixen: and an interpreter, and a rubinius bytecode engine, and a yarv bytecode engine, and a JIT |
| 19:13:35 | evan | we all know LOC is bullshit anyway. |
| 19:13:37 | imajes enters the room. | |
| 19:13:38 | headius | so yeah, that's pointless |
| 19:13:44 | headius | there's a lot more *in* JRuby |
| 19:13:46 | headius | so there's more code |
| 19:14:11 |