Da
Show enters and exits. Hide enters and exits.
| 00:01:07 | fbuilesv | seydar: rubuildus 64 died running the specs but I couldnt see anything on OS 10.5/Ubuntu 32bits |
| 00:01:27 | seydar | i'm on tiger/ppc, though |
| 00:01:34 | seydar | the problem child |
| 00:01:52 | fbuilesv | seydar: any idea of what's rubuildus_ppc running? It seemed to finish the specs just fine |
| 00:02:05 | seydar | 10.5, IIRC |
| 00:02:45 | seydar | i think mine's about to finish (yay), but looks like its been failing >= 7 bajillion tests |
| 00:03:11 | jnicklas enters the room. | |
| 00:03:53 | perdiy leaves the room. | |
| 00:04:17 | seydar | take that back |
| 00:05:14 | seydar | its hanging |
| 00:05:44 | seydar | zomfg, i'll just wait untill they get fixed |
| 00:05:53 | seydar | nothing quite like being lazy to fix a problem |
| 00:06:23 | fbuilesv | seydar: would you mind resetting those changes to like 5883dd78a and see if it still happens? ;-) |
| 00:06:34 | seydar | uh, how? |
| 00:07:25 | fbuilesv | git reset --soft 5883dd78a |
| 00:07:59 | seydar | then a git pull or no? |
| 00:08:17 | seydar | too late, running bin/mspec |
| 00:08:21 | fbuilesv | nope, just run the specs |
| 00:09:42 | seydar | ugh. bajillionz of failures and errors. hanging atm |
| 00:10:21 | fbuilesv | seydar: after the reset? |
| 00:10:35 | seydar | after the reset |
| 00:10:48 | seydar | i ran the git cmd, then the tests, then cried to myself |
| 00:10:51 | fbuilesv | seydar: well, seems like my patches didn't break it after all, I wonder where's it hanging |
| 00:11:12 | fbuilesv | seydar: I cry in public a bit just to look interesting! |
| 00:11:58 | seydar | youre a better person because of it |
| 00:12:01 | seydar | must leave now |
| 00:12:03 | seydar | adiaux |
| 00:12:08 | qwert666 leaves the room. | |
| 00:12:09 | fbuilesv | see ya |
| 00:12:09 | seydar leaves the room. | |
| 00:13:53 | cored enters the room. | |
| 00:18:39 | dysinger leaves the room. | |
| 00:23:05 | srbaker leaves the room. | |
| 00:27:54 | hornbeck enters the room. | |
| 00:44:34 | anteaya_ enters the room. | |
| 00:48:14 | wmoxam enters the room. | |
| 00:51:06 | anteaya leaves the room. | |
| 00:53:42 | aotearoa enters the room. | |
| 00:54:52 | fbuilesv leaves the room. | |
| 01:01:38 | zimbatm_ leaves the room. | |
| 01:02:10 | stepheneb enters the room. | |
| 01:06:46 | stepheneb_ enters the room. | |
| 01:09:25 | AndrewO enters the room. | |
| 01:19:18 | stepheneb leaves the room. | |
| 01:27:52 | srbaker enters the room. | |
| 01:30:26 | jnicklas leaves the room. | |
| 01:33:20 | wmoxam leaves the room. | |
| 01:47:33 | srbaker leaves the room. | |
| 02:03:51 | srbaker enters the room. | |
| 02:06:39 | fbuilesv enters the room. | |
| 02:08:05 | d2dchat enters the room. | |
| 02:12:41 | srbaker leaves the room. | |
| 02:20:12 | lstoll leaves the room. | |
| 02:29:49 | KirinDav enters the room. | |
| 02:31:18 | tlockney_ enters the room. | |
| 02:31:36 | tlockney leaves the room. | |
| 02:31:54 | AndrewO leaves the room. | |
| 02:34:15 | KirinDav leaves the room. | |
| 02:37:28 | seydar enters the room. | |
| 02:37:49 | AndrewO enters the room. | |
| 02:43:27 | hornbeck leaves the room. | |
| 02:45:50 | _VVSiz_ enters the room. | |
| 02:46:40 | trythil enters the room. | |
| 02:47:51 | trythil_ enters the room. | |
| 02:48:02 | srbaker enters the room. | |
| 02:53:16 | VVSiz_ leaves the room. | |
| 02:55:12 | mkescher enters the room. | |
| 02:59:02 | srbaker leaves the room. | |
| 03:00:54 | hornbeck enters the room. | |
| 03:02:56 | hornbeck leaves the room. | |
| 03:04:57 | trythil leaves the room. | |
| 03:05:06 | RyanTM leaves the room. | |
| 03:05:24 | seydar | rubinius has posix threads |
| 03:05:30 | seydar | but why isn't rubinius parallel? |
| 03:06:39 | RyanTM enters the room. | |
| 03:07:37 | djwhitt | you can have parallel VMs |
| 03:08:03 | djwhitt | threads themselves are just green threads though |
| 03:08:05 | seydar | and how do you run multiple VMs? |
| 03:08:13 | djwhitt | heh, no idea |
| 03:08:16 | djwhitt | it can be done though |
| 03:08:18 | seydar | and whats stopping the threads from being POSIX or MPi? |
| 03:08:43 | benny enters the room. | |
| 03:08:58 | djwhitt | MPI is just message passing mechanism as far as I know |
| 03:09:17 | djwhitt | as far as why it doesn't use POSIX threads yet... |
| 03:09:18 | djwhitt | not sure |
| 03:09:38 | benburkert leaves the room. | |
| 03:09:45 | djwhitt | probably it's just more difficult to implement them |
| 03:10:43 | benny leaves the room. | |
| 03:10:48 | seydar | cuz parallel threads = teh 1337h4x |
| 03:11:33 | djwhitt | I'm pretty sure they're going to be implemented at some point |
| 03:13:31 | djwhitt | but I don't think it's planned for 1.0 |
| 03:18:47 | benny enters the room. | |
| 03:19:35 | seydar | i completely forgot about 1.0! |
| 03:19:42 | seydar | when's it planned for release? |
| 03:20:52 | djwhitt | I think they're trying to get preview release out before Railsconf |
| 03:23:26 | d2dchat leaves the room. | |
| 03:26:39 | stepheneb enters the room. | |
| 03:27:01 | seydar | thats cutting it close |
| 03:27:16 | seydar | tiger/PPC has bajilionz of bugs after a recent release |
| 03:27:58 | stepheneb_ leaves the room. | |
| 03:30:13 | headius | I don't think the railsconf milestone is intended to be a full 1.0 release |
| 03:30:24 | headius | I think that would be pretty unlikely |
| 03:30:37 | seydar | ah. PREVIEW release, djwhitt said |
| 03:30:39 | seydar | i'm dumb |
| 03:30:51 | seydar | anyways, j'ai une questione pour vous |
| 03:31:17 | headius | fire away, no guarantees |
| 03:31:47 | seydar | how is code packaged up in C - threads? |
| 03:32:00 | djwhitt | yeah, perhaps 1.0 preview is a bit strong. last I head they're going for something that can run rails at least a bit |
| 03:32:01 | seydar | does using threads set up an enviroment thing? |
| 03:32:25 | headius | is this a rubinius question? |
| 03:32:37 | seydar | yes |
| 03:32:59 | seydar | by C threads i meant normal threads, i guess |
| 03:33:00 | seydar | like |
| 03:33:06 | seydar | GRR i cant describe it |
| 03:33:18 | seydar | oh wait |
| 03:33:24 | seydar | i have boiled it down to a C question |
| 03:33:52 | headius | I've never done pthreads before, but on other threading systems it's usually just passing a function pointer to a thread-starting function |
| 03:34:04 | headius | then that function begins executing in another thread |
| 03:34:08 | seydar | gotcha |
| 03:34:34 | seydar | then how would you get a function pointer from rubinius compiled method to say, POSIX threads |
| 03:34:38 | seydar | thread* |
| 03:34:46 | djwhitt | seydar: little pthreads example: https://computing.llnl.gov/tutorials/pthreads/#Management |
| 03:35:02 | headius | rubinius doesn't compile ruby into C functions or normal procedures it could pass a pointer to |
| 03:35:35 | headius | rubinius's threads are virtual, and scheduled by a thread scheduler in Rubinius rather than the OS scheduler |
| 03:35:38 | seydar | headius: thats what i thought. so how would one implement Pthreads |
| 03:36:25 | headius | in rubinius's case, assuming you'd made sure the VM structures themselves were safely protected, it would be a matter of starting up another virtual CPU I suppose |
| 03:36:46 | headius | but that "assuming" is pretty big...hard to do on C/C++ which have little or no memory safeguards |
| 03:37:11 | ezmobius leaves the room. | |
| 03:43:53 | seydar | so..... little hope for pthreads? |
| 03:44:08 | seydar | pthreads run on multiple CPUs (when the can), right? |
| 03:46:06 | srbaker enters the room. | |
| 03:46:29 | nicksieger leaves the room. | |
| 03:46:50 | KirinDav enters the room. | |
| 03:47:07 | seydar | my life seems.... empty now |
| 03:49:09 | mkescher leaves the room. | |
| 03:49:30 | srbaker leaves the room. | |
| 03:52:11 | seydar | headius: method dispatch stuff now |
| 03:52:28 | seydar | ruby doesn't really even *have* methods |
| 03:52:44 | seydar | they're more like messages in synchronous Actors |
| 03:52:56 | headius | interesting thought |
| 03:53:03 | seydar | and when the actor gets a message it doesn't know, it calls method missing |
| 03:53:16 | seydar | the matrix deal is sweet for jarva, tho |
| 03:53:25 | seydar | but it just wont work with ruby |
| 03:53:35 | seydar | possibly nothing will |
| 03:54:16 | seydar | the most you can do is like cache the messages or something, and try to determine them ahead of time |
| 03:54:55 | seydar | but i'm speaking out of my ass here |
| 03:55:40 | seydar | so headius what are your thoughts? |
| 03:56:04 | headius | are you thinking of ways to speed up dispatch? |
| 03:56:09 | headius | or parallelizing? |
| 03:57:03 | seydar | dispatch, although parallelization came into my head for a bit |
| 03:57:24 | headius | well both rubinius and jruby employ inline caching to speed up dispatch |
| 03:57:38 | headius | so if the target of a call is the same as the previous time, it doesn't bother to look up the method again |
| 03:57:57 | seydar | cool |
| 03:58:27 | seydar | should i even bother to interview some professors at dartmouth about method dispatching and report my findings? can it possibly help? |
| 04:00:09 | headius | well I think actually there are some good papers you should look into |
| 04:00:26 | headius | look for papers on a language called "self" and also on "polymorphic inline caching" |
| 04:00:38 | headius | neither rubinius nor jruby are using a PIC yet, but we're considering it |
| 04:00:48 | seydar | cool |
| 04:00:53 | seydar | i'll read up on them |
| 04:01:04 | seydar | also |
| 04:01:11 | headius | other options for speeding up dispatch include generating vtables at runtime, after you've decided that there will be few additional changes |
| 04:01:27 | seydar | what if we modeled the base after strongtalk? |
| 04:02:20 | seydar | like the base shogun, or if we produced strongtalk bytecode? |
| 04:05:09 | seydar | nah, docs are too sparse |
| 04:11:49 | seydar | headius: can you tell me something cool about rubinius? |
| 04:12:03 | headius | when it starts up, the lights dim a little |
| 04:12:16 | headius | modeling after strongtalk is a pretty good though |
| 04:12:23 | headius | that's kinda what I'm trying to do on JRuby too |
| 04:14:12 | seydar | you work at sun now, don't you? |
| 04:14:19 | headius | that I do |
| 04:14:31 | seydar | so you have access to their developers' brains, right? |
| 04:15:06 | djwhitt | yeah, there's this cabinet where they keep them... |
| 04:15:36 | headius | I only get the keys on alternate thursdays |
| 04:15:55 | seydar | the developer got hired by sun, didn't he? |
| 04:18:30 | seydar | and what would it take to include libjit in rubinius? |
| 04:22:05 | ezmobius enters the room. | |
| 04:23:38 | seydar | is libjit even the preferred jitting system ti yse? |
| 04:23:45 | seydar | to use* |
| 04:24:35 | GMFlash leaves the room. | |
| 04:24:42 | GMFlash enters the room. | |
| 04:25:13 | seydar | its ok. dont be shy people |
| 04:26:16 | srbaker enters the room. | |
| 04:27:32 | seydar | and for those of you going to GoRuCo, please wear your nametags around the city so I may recognize someone |
| 04:27:46 | ezmobius | i'll be there |
| 04:27:54 | seydar | awesome |
| 04:28:09 | seydar | i'm there viewing my cousin's movie, but no guarentees about me popping into goruco |
| 04:29:26 | seydar | ezmobius: nametag around the city, remember |
| 04:30:23 | ezmobius | will do |
| 04:33:31 | benburkert enters the room. | |
| 04:33:33 | seydar | so ezmobius, lets talk parallelism |
| 04:33:43 | ezmobius | one sec.. brb |
| 04:34:28 | headius | I'm not sure any of the standard jit libraries are going to work easily with rubinius since it's stackless |
| 04:35:04 | seydar | headius: it is? |
| 04:35:20 | headius | yes |
| 04:35:39 | seydar | so what does this mean, besides its lackage of stackage? |
| 04:36:34 | headius | well, I think it will complicate generating callable native procedures since you can't actually deepen a standard call stack |
| 04:36:52 | headius | but I don't know much about such things |
| 04:37:32 | seydar | not a problem if you dont know it. make some guess. |
| 04:38:21 | headius | heh |
| 04:39:01 | seydar | its computers. everything is based off logic. guessing is my first resort |
| 04:41:13 | seydar | headius: couldn't you just jit each faux-stack? |
| 04:43:35 | cored leaves the room. | |
| 04:43:35 | ezmobius leaves the room. | |
| 04:44:04 | wmoxam enters the room. | |
| 04:44:56 | seydar | headius: does rubinius use multiple stacks of its own, like pypy? |
| 04:45:10 | headius | I believe so |
| 04:45:20 | headius | things are always in flux |
| 04:45:22 | MenTaLguY enters the room. | |
| 04:45:27 | MenTaLguY | hello |
| 04:46:11 | seydar | howdy |
| 04:47:34 | seydar | is it even possible for the individual stacks to have a separate jitter? |
| 04:51:16 | antares enters the room. | |
| 04:54:07 | KirinDav leaves the room. | |
| 04:56:27 | jlindley leaves the room. | |
| 04:56:48 | srbaker leaves the room. | |
| 04:56:50 | benburkert leaves the room. | |
| 04:57:52 | benburkert enters the room. | |
| 05:01:58 | be9 enters the room. | |
| 05:06:16 | antares leaves the room. | |
| 05:07:00 | trythil_ leaves the room. | |
| 05:08:40 | antares enters the room. | |
| 05:13:23 | antares leaves the room. | |
| 05:15:40 | headius leaves the room. | |
| 05:18:07 | stepheneb_ enters the room. | |
| 05:19:36 | KirinDav enters the room. | |
| 05:21:45 | anteaya_ leaves the room. | |
| 05:21:47 | stepheneb leaves the room. | |
| 05:23:34 | KirinDav leaves the room. | |
| 05:25:41 | trythil enters the room. | |
| 05:26:21 | KirinDav enters the room. | |
| 05:29:06 | antares enters the room. | |
| 05:32:51 | KirinDav leaves the room. | |
| 05:32:55 | seydar leaves the room. | |
| 05:38:03 | benny leaves the room. | |
| 06:05:03 | RyanTM leaves the room. | |
| 06:05:49 | RyanTM enters the room. | |
| 06:06:48 | wycats enters the room. | |
| 06:11:39 | wmoxam leaves the room. | |
| 06:16:08 | mernen enters the room. | |
| 06:20:49 | antares leaves the room. | |
| 06:22:24 | madsimian leaves the room. | |
| 06:22:40 | antares enters the room. | |
| 06:24:33 | rby enters the room. | |
| 06:37:16 | RyanTM leaves the room. | |
| 06:37:54 | benburkert leaves the room. | |
| 06:38:33 | benburkert enters the room. | |
| 06:39:04 | jtoy enters the room. | |
| 06:43:19 | trythil leaves the room. | |
| 06:46:34 | mernen leaves the room. | |
| 06:49:52 | antares leaves the room. | |
| 06:51:51 | KirinDav enters the room. | |
| 06:54:45 | smparkes leaves the room. | |
| 07:22:34 | KirinDav leaves the room. | |
| 07:55:42 | ezmobius enters the room. | |
| 08:02:29 | AndrewO leaves the room. | |
| 08:02:58 | smparkes enters the room. | |
| 08:03:13 | smparke1 leaves the room. | |
| 08:07:14 | trythil enters the room. | |
| 08:17:56 | benburkert leaves the room. | |
| 08:18:31 | benburkert enters the room. | |
| 08:21:33 | dlee enters the room. | |
| 08:22:30 | stepheneb_ leaves the room. | |
| 08:29:39 | wycats_ enters the room. | |
| 08:37:52 | wycats leaves the room. | |
| 08:38:03 | trythil leaves the room. | |
| 08:55:24 | trythil enters the room. | |
| 08:55:28 | benburkert leaves the room. | |
| 08:56:29 | benburkert enters the room. | |
| 08:56:38 | benburkert leaves the room. | |
| 08:59:21 | benburkert enters the room. | |
| 08:59:39 | benburkert leaves the room. | |
| 09:00:17 | benburkert enters the room. | |
| 09:17:39 | benburkert leaves the room. | |
| 09:17:46 | Maledictus enters the room. | |
| 09:18:55 | benburkert enters the room. | |
| 09:25:55 | ezmobius leaves the room. | |
| 09:26:21 | cypher23 enters the room. | |
| 09:35:10 | gnufied leaves the room. | |
| 09:45:02 | qwert666 enters the room. | |
| 09:51:03 | jnicklas enters the room. | |
| 09:57:58 | Skip enters the room. | |
| 10:19:36 | benny enters the room. | |
| 10:41:36 | JimRoepcke_ leaves the room. | |
| 11:20:42 | olabini enters the room. | |
| 11:25:43 | trythil leaves the room. | |
| 11:29:31 | chris2 enters the room. | |
| 11:35:58 | benburkert leaves the room. | |
| 11:37:01 | benburkert enters the room. | |
| 11:37:45 | bovi enters the room. | |
| 11:44:27 | brennanc enters the room. | |
| 11:45:53 | brennanc | hello, I'm trying to learn rubinius and play around with it |
| 11:46:02 | brennanc | rbx is the equivalent of irb correct? |
| 11:46:49 | brennanc | require 'ruby2ruby' doesn't work in rbx but it does in irb |
| 11:46:59 | brennanc | do I have more configuring to do or something? |
| 11:49:18 | benburkert leaves the room. | |
| 11:50:52 | benny leaves the room. | |
| 11:57:04 | imajes enters the room. | |
| 12:01:22 | mentz enters the room. | |
| 12:05:04 | mentz leaves the room. | |
| 12:05:20 | mentz enters the room. | |
| 12:10:20 | womble enters the room. | |
| 12:47:26 | brennanc leaves the room. | |
| 13:03:16 | RyanTM enters the room. | |
| 13:29:48 | yugui enters the room. | |
| 13:30:20 | hornbeck enters the room. | |
| 13:34:05 | yugui leaves the room. | |
| 13:53:24 | rby leaves the room. | |
| 13:54:38 | yaroslav enters the room. | |
| 13:59:13 | EugZol leaves the room. | |
| 14:00:48 | rby enters the room. | |
| 14:00:55 | jtoy enters the room. | |
| 14:02:29 | zimbatm_ enters the room. | |
| 14:08:57 | RyanTM_ enters the room. | |
| 14:09:24 | aotearoa leaves the room. | |
| 14:09:55 | smparke1 enters the room. | |
| 14:15:42 | RyanTM leaves the room. | |
| 14:21:47 | hornbeck leaves the room. | |
| 14:26:02 | srbaker enters the room. | |
| 14:26:22 | Fullmoon leaves the room. | |
| 14:26:50 | Fullmoon_ enters the room. | |
| 14:48:57 | smparke1 leaves the room. | |
| 14:48:57 | context leaves the room. | |
| 14:49:22 | headius enters the room. | |
| 14:50:46 | zimbatm_ leaves the room. | |
| 14:55:42 | yaroslav leaves the room. | |
| 14:56:27 | enebo enters the room. | |
| 15:00:06 | rby leaves the room. | |
| 15:06:20 | benny enters the room. | |
| 15:18:05 | rby enters the room. | |
| 15:26:59 | jtoy leaves the room. | |
| 15:36:38 | fbuilesv_ enters the room. | |
| 15:37:11 | mentz leaves the room. | |
| 15:45:42 | mentz enters the room. | |
| 15:50:44 | Cosmos95 enters the room. | |
| 15:53:35 | fbuilesv_ leaves the room. | |
| 15:53:55 | RyanTM_ leaves the room. | |
| 15:54:05 | fbuilesv leaves the room. | |
| 15:55:11 | fbuilesv enters the room. | |
| 15:56:32 | obvio leaves the room. | |
| 15:57:13 | jtoy enters the room. | |
| 15:59:05 | benny leaves the room. | |
| 15:59:35 | benny enters the room. | |
| 16:00:05 | smparke1 enters the room. | |
| 16:04:42 | mentz leaves the room. | |
| 16:06:59 | obvio enters the room. | |
| 16:07:18 | bovi leaves the room. | |
| 16:07:59 | mentz enters the room. | |
| 16:11:09 | dewd enters the room. | |
| 16:13:39 | jtoy leaves the room. | |
| 16:23:51 | anteaya enters the room. | |
| 16:24:38 | GMFlash leaves the room. | |
| 16:24:46 | GMFlash enters the room. | |
| 16:32:11 | ttmrichter leaves the room. | |
| 16:45:03 | obvio leaves the room. | |
| 16:48:31 | antares enters the room. | |
| 16:50:42 | KirinDav enters the room. | |
| 16:56:15 | octopod enters the room. | |
| 16:57:22 | obvio enters the room. | |
| 16:58:02 | antares leaves the room. | |
| 17:07:10 | stepheneb enters the room. | |
| 17:07:12 | rype leaves the room. | |
| 17:13:45 | brainopia enters the room. | |
| 17:16:33 | thehcdreamer leaves the room. | |
| 17:19:20 | seydar enters the room. | |
| 17:19:31 | seydar | a/join #squeak |
| 17:19:32 | Skip leaves the room. | |
| 17:19:33 | seydar | whoops |
| 17:25:30 | brainopia enters the room. | |
| 17:32:20 | anteaya leaves the room. | |
| 17:40:16 | Skip enters the room. | |
| 17:53:01 | stepheneb leaves the room. | |
| 17:57:39 | Cosmos95 leaves the room. | |
| 18:11:47 | valdo enters the room. | |
| 18:12:24 | seydar leaves the room. | |
| 18:24:59 | qwert666 leaves the room. | |
| 18:29:21 | benny leaves the room. | |
| 18:29:49 | KirinDav leaves the room. | |
| 18:32:33 | acm enters the room. | |
| 18:35:14 | dewd leaves the room. | |
| 18:41:43 | qwert666 enters the room. | |
| 18:42:00 | brainopia leaves the room. | |
| 18:42:47 | brainopia enters the room. | |
| 18:47:53 | MenTaLguY enters the room. | |
| 18:55:43 | RyanTM_ enters the room. | |
| 19:04:22 | madsimian enters the room. | |
| 19:11:18 | brainopia_ enters the room. | |
| 19:13:00 | brainopia_ leaves the room. | |
| 19:13:23 | benny enters the room. | |
| 19:13:47 | brainopia_ enters the room. | |
| 19:25:48 | benburkert enters the room. | |
| 19:27:49 | brainopia leaves the room. | |
| 19:44:25 | peeja_ enters the room. | |
| 19:56:56 | benburkert_ enters the room. | |
| 19:56:56 | benburkert leaves the room. | |
| 19:59:32 | peeja leaves the room. | |
| 20:05:04 | wycats_ leaves the room. | |
| 20:14:47 | trythil enters the room. | |
| 20:20:26 | GMFlash leaves the room. | |
| 20:43:47 | valdo leaves the room. | |
| 20:46:33 | tokengeek enters the room. | |
| 20:47:43 | olabini leaves the room. | |
| 20:53:42 | trythil leaves the room. | |
| 20:56:16 | rubuildius_ppc leaves the room. | |
| 20:57:26 | benny leaves the room. | |
| 20:58:11 | benny enters the room. | |
| 21:04:05 | acm leaves the room. | |
| 21:08:02 | RyanTM_ leaves the room. | |
| 21:09:26 | RyanTM_ enters the room. | |
| 21:09:50 | context enters the room. | |
| 21:09:51 | octopod leaves the room. | |
| 21:10:20 | context leaves the room. | |
| 21:10:29 | context enters the room. | |
| 21:13:19 | olabini enters the room. | |
| 21:14:08 | GMFlash enters the room. | |
| 21:14:59 | boyscout | 1 commit by MenTaLguY |
| 21:15:00 | boyscout | * elminate Mailbox#clear; difficult to implement with sane semanitics; ae738f2 |
| 21:15:11 | EugZol enters the room. | |
| 21:18:25 | tarcieri | heh |
| 21:19:05 | MenTaLguY | I'm really not a fan of this guy's code at this point |
| 21:19:13 | MenTaLguY | he put timeouts on filter rather than maibox#receive |
| 21:19:36 | MenTaLguY | and then I've already been whinging about all the other serious concurrency problems |
| 21:19:40 | tarcieri | that's what I did... |
| 21:19:51 | MenTaLguY | hm, why? |
| 21:20:19 | tarcieri | because #after takes a proc, just like #when |
| 21:21:46 | MenTaLguY | I was looking for a conceptual reason, not one that's an accident of the API |
| 21:22:09 | MenTaLguY | you could, for example, have a receive_timeout which takes a block |
| 21:22:20 | MenTaLguY | or simply raises an exception on timeout |
| 21:22:28 | VVSiz_ enters the room. | |
| 21:23:04 | tarcieri | how would the filter object work with receive_timeout? |
| 21:23:17 | MenTaLguY | just like regular recieve |
| 21:23:28 | tarcieri | but then you'd need two blocks |
| 21:23:38 | tarcieri | one for the filter object and one for the timeout action |
| 21:23:58 | tarcieri | both on receive_timeout? |
| 21:24:18 | MenTaLguY | hm, good point; you could do it, but it wouldn't look nice |
| 21:25:01 | MenTaLguY | I guess my main concern is that filter is for extracting messages from the main message stream |
| 21:25:22 | MenTaLguY | timeouts aren't really part of that stream; they're part of a "private" stream, local to an individual receive, which is multiplexed with that main stream |
| 21:25:45 | Cosmos95 enters the room. | |
| 21:26:19 | tarcieri | true enough, it's uglier internally that way |
| 21:26:38 | MenTaLguY | the internals don't necessarily need to dictate the API in this case though |
| 21:26:43 | tarcieri | yep |
| 21:27:02 | tarcieri | the API is a lot cleaner that way, imo |
| 21:30:56 | MenTaLguY | let's keep this API then |
| 21:31:54 | tarcieri | ok |
| 21:32:00 | RyanTM_ leaves the room. | |
| 21:32:04 | tarcieri | Mailbox#clear on the other hand :) |
| 21:32:21 | oGMo enters the room. | |
| 21:32:44 | MenTaLguY | I was going to leave it since it wasn't part of the exposed actor API, but ... yeah |
| 21:32:54 | MenTaLguY | then I started thinking about what it meant, sanely |
| 21:33:17 | RyanTM_ enters the room. | |
| 21:37:13 | oGMo | so i need to interrupt a thread and make a call in a new stack frame. plain ruby can't, and i'm hoping rubinius can |
| 21:37:56 | oGMo | interrupt the execution, that is, much like a signal, except actual signals are always iffy |
| 21:38:19 | wycats_ enters the room. | |
| 21:38:30 | benburkert_ leaves the room. | |
| 21:39:07 | MenTaLguY | that's an insane idea, from a concurrency standpoint |
| 21:39:12 | _VVSiz_ leaves the room. | |
| 21:39:15 | oGMo | ? |
| 21:39:36 | MenTaLguY | interrupting a thread at an arbitrary point and running code in its context |
| 21:40:01 | MenTaLguY | there's no way to (in the general case) make the code correct under such circumstances |
| 21:40:32 | MenTaLguY | a lot of people ask for it, they just haven't thought through the consequences |
| 21:40:53 | oGMo | heh |
| 21:40:56 | oGMo | common lisp does it :p |
| 21:41:00 | MenTaLguY | is there a reason that the thread you want to interrupt can't poll periodically to see if there are any requests waiting, and service them if so? |
| 21:41:08 | MenTaLguY | (assuming the thread is actively running) |
| 21:41:17 | MenTaLguY | (if it is blocked on something you should be able to handle that as part of the blocking) |
| 21:41:34 | benburkert enters the room. | |
| 21:41:42 | oGMo | yes, because manual polling defeats the point of automating concurrency |
| 21:41:44 | oGMo | ;) |
| 21:42:11 | MenTaLguY | arbitrary interruption defeats the point of writing robust concurrent programs |
| 21:42:41 | tarcieri | oGMo: you might consider using Actors instead of threads... |
| 21:42:47 | tarcieri | and rather than interrupting it, send it a message |
| 21:42:50 | MenTaLguY | it's essential that threads communicate at mutually agreed-upon points |
| 21:42:52 | oGMo | ...your idea of concurrent programming is almost certainly wrong |
| 21:42:58 | tarcieri | *boggle* |
| 21:42:58 | oGMo | ah. yes, it is. |
| 21:43:10 | oGMo | tarcieri: mm. |
| 21:43:20 | MenTaLguY | any unilateral attempts at communication by one thread "into" another introduce non-determinism and (usually) intractable problems |
| 21:43:24 | oGMo | the idea is actually to eliminate concurrency and write single-threaded code |
| 21:43:37 | oGMo | well, eliminate *threads* as the mechanism for concurrency |
| 21:43:50 | tarcieri | eliminating threads is good |
| 21:44:39 | oGMo | however the ability to fork at a given point without having to retry a whole call is important |
| 21:45:07 | tarcieri | fork? |
| 21:45:09 | MenTaLguY | unless you make those points explicit, you won't be able to make things work reliably |
| 21:45:15 | tarcieri | like Kernel.fork? |
| 21:45:29 | oGMo | ah the debugger is not implemented the CL way i suppose |
| 21:45:34 | oGMo | tarcieri: right |
| 21:45:46 | oGMo | MenTaLguY: that assumes a lot of things you shouldn't |
| 21:45:53 | tarcieri | sounds like you're writing something pretty crazy |
| 21:46:04 | oGMo | there are a lot of ways to do concurrency other than manually creating threads and locking between them |
| 21:46:10 | oGMo | tarcieri: actually, it's really, really simple |
| 21:46:16 | MenTaLguY | oGMo: believe me, I know that |
| 21:46:38 | MenTaLguY | and in fact I've been trying to promote that as much as possible in the Ruby community |
| 21:46:41 | oGMo | single threaded event processor. run each event. if an event takes too long, fork it and continue. |
| 21:46:55 | MenTaLguY | aha. |
| 21:46:59 | oGMo | (functions that do global updates can be marked to avoid forks) |
| 21:47:22 | KirinDav enters the room. | |
| 21:47:38 | oGMo | sadly there are one or two critical pieces missing from vanilla ruby to really make it work |
| 21:48:05 | tarcieri | oGMo: sounds like you want the deferrable pattern, not that I really think it's that great of a solution |
| 21:48:21 | oGMo | tarcieri: sortof |
| 21:48:29 | tarcieri | Reactor frameworks are annoying to program in |
| 21:48:38 | tarcieri | I really dislike IoC |
| 21:48:41 | oGMo | IoC? |
| 21:48:45 | MenTaLguY | rather than migrating tasks across threads, I'd recommend keeping a pool of worker threads |
| 21:48:45 | tarcieri | inversion of control |
| 21:49:03 | MenTaLguY | tarcieri: he's trying to do it by migrating contexts across threads |
| 21:49:16 | MenTaLguY | tarcieri: to avoid IoC |
| 21:49:38 | oGMo | MenTaLguY: *no threads* |
| 21:49:44 | oGMo | this is important. |
| 21:49:48 | oGMo | it's all about what fork() does for you |
| 21:50:14 | oGMo | if you do threads, you immediately have to worry about locking; with fork(), you get a snapshot and you never have to lock |
| 21:50:15 | MenTaLguY | ah, so you're actually spinning off these events into separate processes, then? |
| 21:50:19 | oGMo | right |
| 21:50:31 | chris2 leaves the room. | |
| 21:50:53 | MenTaLguY | yikes |
| 21:51:33 | MenTaLguY | you're definitely going to need to explicitly place "checkpoints" at which forks can happen in the event handlers |
| 21:51:39 | oGMo | er no |
| 21:51:41 | MenTaLguY | fork is not really safe in a lot of contexts |
| 21:52:23 | tarcieri | or have a worker pool... collect the state you want the workers to operate on, and send it as a message |
| 21:52:38 | tarcieri | then only fork immediately at the start of your program |
| 21:53:21 | oGMo | the idea is to minimize forks and to not do manually do them |
| 21:54:16 | MenTaLguY | if you can't re-use processes, that actually becomes pretty heavyweight then |
| 21:54:27 | oGMo | you find an event-processing-limit such that it's less than a "too long" threshold, yet most events get processed within the limit, and you don't have "really fast exits" from any forks |
| 21:54:39 | MenTaLguY | even not pooling threads can hurt badly performance-wise; I wouldn't want to think about the implications of not pooling processes |
| 21:54:45 | oGMo | MenTaLguY: the idea is that anytime you fork, it was a really long process anyway |
| 21:54:57 | oGMo | you can pool processes, too, but that doesn't always work |
| 21:55:13 | oGMo | pooled processes require you determine ahead of time something is going to take awhile |
| 21:55:56 | MenTaLguY | I don't think, loosely speaking, that the principle you're going for is bad. |
| 21:55:59 | oGMo | sometimes that's possible, sometimes you're not sure, especially if you're adjusting the schedule dynamically |
| 21:56:11 | MenTaLguY | But it's badly mismatched with Ruby's semantics, to the point where there's not a sane way to implement it in Ruby. |
| 21:56:43 | MenTaLguY | In the specific way you're going for. |
| 21:56:44 | oGMo | sortof. vanilla ruby is like one function short of being able to accomplish it |
| 21:57:23 | MenTaLguY | implementing that one function would involve a lot of changes to the language semantics |
| 21:57:26 | oGMo | sadly there doesn't seem to be any sort of timer mechanism.. exceptions don't work becuase they unwind the stack... so hrm |
| 21:57:33 | oGMo | MenTaLguY: um, how? :p |
| 21:57:46 | oGMo | you can already catch SIGALRM, there's just no setitimer |
| 21:58:09 | oGMo | (yes, setitimer in vanilla is used for thread scheduling with SIGVTALRM) |
| 21:58:16 | tarcieri | there's no interface to alarm() in Ruby |
| 21:58:28 | oGMo | that too |
| 21:58:35 | MenTaLguY | well, in that case we're moving outside Ruby semantics and into POSIX stuff as well |
| 21:58:55 | oGMo | this is actually really simple to do in C, but i want to write ruby ;) |
| 21:59:00 | MenTaLguY | POSIX signals are something that sort of happens to work rather than being well-integrated with Ruby language semantics |
| 21:59:21 | oGMo | heh |
| 21:59:33 | MenTaLguY | obviously they integrate with C's semantics a little better :) |
| 21:59:34 | oGMo | i think they're that way even in C ;) |
| 21:59:42 | MenTaLguY | yes, actually |
| 21:59:48 | MenTaLguY | but there's less of an impedence mismatch |
| 21:59:50 | oGMo | MenTaLguY: sortof, but they're still a kludge |
| 22:00:01 | MenTaLguY | yes |
| 22:00:03 | oGMo | heh |
| 22:00:12 | tarcieri | I prefer them in Ruby, if only because you don't need to shuffle data out of them with a commonly coupled volatile |
| 22:00:13 | tarcieri | ugh |
| 22:00:27 | oGMo | rubinius is 64-bit clean no? |
| 22:00:33 | headius leaves the room. | |
| 22:00:35 | tarcieri | in theory! |
| 22:00:37 | oGMo | heh |
| 22:00:40 | MenTaLguY | tarcieri: there are a lot of gotchas around that ... yeah |
| 22:00:48 | MenTaLguY | er, signals in Ruby I mean |
| 22:00:58 | tarcieri | yeah |
| 22:01:18 | oGMo | daily failed to build with some odd errors, so hm |
| 22:01:46 | oGMo | er wait maybe it's another reason |
| 22:02:07 | MenTaLguY | tarcieri: I'm thinking about reverting the timeout stuff altogether actually ... the way it is right now, timeouts can "leak" from one receive to another |
| 22:02:20 | tarcieri | how are they implemented? |
| 22:02:34 | MenTaLguY | tarcieri: using Scheduler.send_in_milliseconds to the mailbox channel |
| 22:02:51 | tarcieri | hmmm |
| 22:02:54 | MenTaLguY | tarcieri: and it doesn't even cancel the timeout |
| 22:03:05 | MenTaLguY | tarcieri: so there is guaranteed to be a "stale" nil sitting in the channel |
| 22:03:18 | MenTaLguY | if you get an existing message from @skipped rather than timing out |
| 22:03:23 | tarcieri | awesome |
| 22:03:25 | tarcieri | heh |
| 22:03:27 | MenTaLguY | well, or even get one from the channel |
| 22:03:58 | tarcieri | yeah, at least in Revactor I wrote the scheduler so I didn't have to deal with implementing timeouts using message passing |
| 22:04:17 | tarcieri | it just sets a flag in the Actor and resumes it |
| 22:04:27 | tarcieri | that flag gets cleared when it starts the next Actor.receive |
| 22:04:36 | tarcieri | so there's no potential for timeouts to leak like that |
| 22:05:02 | MenTaLguY | there's also the problem that if you have a sequence of successul receives, you'll accumulate a lot of pending timeout events in the Rubinius scheduler itself |
| 22:05:19 | MenTaLguY | and a minor problem that nil can no longer be a valid actor message |
| 22:05:21 | tarcieri | yeah |
| 22:08:05 | MenTaLguY | oGMo: anyway, I think the biggest problem you'll find with the approach you're looking at (even in C), is that it isn't easily to guarantee that a third-party library used by an event handler doesn't manipulate global state or perform IO in a way that could be damaged by a fork() |
| 22:08:26 | MenTaLguY | s/easily/easy/ |
| 22:09:00 | MenTaLguY | that state or IO is not necessarily going to be part of that library's published interface |
| 22:09:35 | oGMo | well, this isn't meant to be a catchall |
| 22:09:51 | diegal enters the room. | |
| 22:11:06 | MenTaLguY | tarcieri: actually the reason why I hadn't implemented timeout yet was that I'd wanted to add the ability to send a specific object via send_in_milliseconds |
| 22:11:30 | MenTaLguY | tarcieri: things get much simpler if a particular timeout can be represented by a unique object |
| 22:12:34 | tarcieri | yeah, I need that to implement a Reactor too :/ |
| 22:12:41 | brainopia_ leaves the room. | |
| 22:12:48 | MenTaLguY | maybe we should work on that |
| 22:13:05 | tarcieri | I looked at what was involved a little... it seemed... non-trivial |
| 22:13:06 | MenTaLguY | I'd really prefer to fix the timeout stuff rather than revert it |
| 22:13:08 | brainopia enters the room. | |
| 22:14:09 | diegal | hey. I'm fairly new here. Just saw Evan's presentation on MW conf. I'm reading the site now and I think I found a problem with the instructions on the git workflow on http://rubinius.lighthouseapp.com/projects/5089/using-git . Step 3 seems incomplete. |
| 22:14:17 | diegal | anybody can confirm? |
| 22:14:53 | fbuilesv | diegal: Why does it seem incomplete? |
| 22:15:26 | diegal | well... I'm not a native english speaker, but this phrase seems incomplete: "Create a branch for your work. What happens is that your working directory" |
| 22:15:47 | fbuilesv | diegal: Oh, the description, yes, it's bad. |
| 22:15:55 | diegal | :) |
| 22:15:55 | benburkert leaves the room. | |
| 22:16:26 | diegal | fbuilesv: do you have the knowledge and access to fix it? |
| 22:16:31 | benburkert enters the room. | |
| 22:17:21 | zimbatm_ enters the room. | |
| 22:17:47 | fbuilesv | diegal: yup, just say that the command will create a new branch for you to work in |
| 22:18:16 | aotearoa enters the room. | |
| 22:18:25 | diegal | fbuilesv: I thought so. But it would be nice to fix it on the page for others. |
| 22:18:32 | fbuilesv | diegal: on it |
| 22:18:39 | diegal | fbuilesv: cool. |
| 22:19:22 | diegal | fbuilesv: I see on http://rubinius.lighthouseapp.com/projects/5089/irc-info-and-who-s-who that your mother thonge is not english too. :) I'm from Uruguay. |
| 22:19:37 | fbuilesv | diegal: Yup, Colombian here :) |
| 22:21:31 | fbuilesv | diegal: Check it out and tell me if that makes more sense to you |
| 22:22:07 | jlindley enters the room. | |
| 22:22:28 | diegal | fbuilesv: much better. |
| 22:25:20 | imajes_ enters the room. | |
| 22:26:26 | imajes leaves the room. | |
| 22:33:01 | jlindley leaves the room. | |
| 22:42:18 | jlindley enters the room. | |
| 22:42:32 | KirinDav leaves the room. | |
| 22:43:29 | diegal | fbuilesv: hey. I think I found another MINIMAL error. :) on http://rubinius.lighthouseapp.com/projects/5089/specs-continuous-integration it says "The rake spec:ci task prints our the revision of the VM build" and I think you should s/our/out/ . |
| 22:44:51 | fbuilesv | diegal: Fixed! |
| 22:45:21 | diegal | fbuilesv: cool. :) (sent you a private message too) |
| 22:46:22 | Maledictus leaves the room. | |
| 22:46:24 | fbuilesv | diegal: Through where? |
| 22:46:58 | diegal | fbuilesv: through here, IRC. if you didn't get it, I'll email you. |
| 22:47:12 | fbuilesv | diegal: federico.builes@gmail.com, it never got here :) |
| 22:47:25 | diegal | fbuilesv: cool. |
| 22:49:00 | mentz leaves the room. | |
| 22:54:08 | dlee enters the room. | |
| 23:04:00 | probablycorey enters the room. | |
| 23:14:12 | dbussink leaves the room. | |
| 23:15:32 | trythil enters the room. | |
| 23:18:06 | rby leaves the room. | |
| 23:19:27 | jnicklas leaves the room. | |
| 23:19:32 | MenTaLguY leaves the room. | |
| 23:25:17 | enebo leaves the room. | |
| 23:28:02 | jlindley leaves the room. | |
| 23:47:33 | agardiner enters the room. | |
| 23:51:51 | diegal leaves the room. | |
| 23:52:54 | zimbatm_ leaves the room. |