Da
Show enters and exits. Hide enters and exits.
| 00:02:47 | octopod leaves the room. | |
| 00:03:09 | lopex leaves the room. | |
| 00:03:58 | chris2 leaves the room. | |
| 00:04:05 | pauldix enters the room. | |
| 00:04:43 | enebo leaves the room. | |
| 00:06:00 | crafterm enters the room. | |
| 00:12:33 | mutle leaves the room. | |
| 00:19:35 | cored enters the room. | |
| 00:32:21 | wifelette leaves the room. | |
| 00:35:04 | wmoxam leaves the room. | |
| 00:37:50 | brixen | kamal_fariz: what ruby version and os are you on? |
| 00:38:22 | brixen | kamal_fariz: the Module#instance_method specs are failing for me on leopard, 1.8.6, patch 111 |
| 00:43:01 | pauldix leaves the room. | |
| 00:54:30 | hurdlea enters the room. | |
| 00:54:36 | zenspider | brixen: is there a way to add a note to an exclude? |
| 00:55:35 | wifelette enters the room. | |
| 00:56:34 | radarek leaves the room. | |
| 00:56:50 | defunkt enters the room. | |
| 00:57:02 | hurdlea leaves the room. | |
| 01:00:58 | hornbeck leaves the room. | |
| 01:01:08 | hornbeck enters the room. | |
| 01:02:41 | jessop leaves the room. | |
| 01:05:39 | brixen | zenspider: not yet |
| 01:05:59 | bburcham leaves the room. | |
| 01:06:41 | zenspider | brixen: I've been poking at the excludes and found some that while they pass, they destabilize the system as a whole, it'd be nice to add that note to the exclude file |
| 01:12:31 | obvio171 enters the room. | |
| 01:16:03 | evan | so |
| 01:16:05 | evan | in MRI |
| 01:16:14 | evan | fork() causes all Thread's to die except for the current one |
| 01:16:50 | tarcieri | whoa |
| 01:16:58 | evan | did people know that? |
| 01:17:03 | evan | i've always wondered |
| 01:17:16 | tarcieri | that certainly simplifies forking + mvm |
| 01:17:17 | tarcieri | heh |
| 01:17:18 | zenspider | never knew that |
| 01:19:03 | evan | it makes sense for what most people expect fork to do |
| 01:19:11 | drbrain | evan: I knew that, but forgot |
| 01:19:18 | Defiler | same |
| 01:19:18 | evan | i have to figure out a mild workaround for rubinius |
| 01:19:22 | pauldix enters the room. | |
| 01:19:25 | evan | because signal handlers inherit |
| 01:19:29 | evan | but THreads don't |
| 01:19:37 | evan | and rubinius uses Threads to handle signals. |
| 01:19:41 | tarcieri | evan: did libev reconcile the problems with forking + event loops? |
| 01:19:44 | obvio_ leaves the room. | |
| 01:20:04 | evan | i'm not sure. |
| 01:20:17 | evan | shoe didn't document the failure he was seeing |
| 01:20:20 | evan | so i don't know. |
| 01:21:10 | evan | there is still an issue with fork/threads/channels |
| 01:21:16 | evan | but i've worked around it for the moment. |
| 01:21:44 | zenspider | so, should I be trying to figure out these destabilization problems? Or are we content with excluding the specs for now and moving on? |
| 01:22:24 | evan | someone has to figure them out eventually |
| 01:22:32 | evan | i'd love for someone to take the lead on at least one of them |
| 01:22:38 | brixen | zenspider: tracking those can be very frustrating, as they are not typically the POF |
| 01:22:42 | evan | or at the very least |
| 01:23:17 | evan | show me how to get a list of all of them |
| 01:23:21 | evan | so I can try and bang them out. |
| 01:23:23 | brixen | afaik, #callcc is the biggest problem |
| 01:23:29 | brixen | it runs fine in isolation |
| 01:23:32 | brixen | the specs that is |
| 01:23:41 | boyscout | 2 commits by Evan Phoenix |
| 01:23:42 | boyscout | * More fixes to get signals/channels running properly; 173068d |
| 01:23:43 | boyscout | * The zombie pit. Fixes a bunch of thread and GC problems; baedb2e |
| 01:23:51 | brixen | zenspider: Module would be much more productive |
| 01:23:53 | evan | drbrain: there ya go. |
| 01:23:56 | brixen | and affect more code |
| 01:24:03 | zenspider | brixen: yeah. I fucked with those too |
| 01:24:05 | drbrain | yay |
| 01:24:18 | evan | the destabilization causes VM sigbus |
| 01:24:19 | evan | yes? |
| 01:24:23 | zenspider | I found a number of them taht ran fine in isolation but failed when run via bin/ci |
| 01:24:28 | zenspider | I fixed Symbol#all_symbols for that |
| 01:24:33 | evan | because those last 2 commits fixed some NASTY task GC problems |
| 01:24:37 | drbrain | evan: now, get the guy illegally parked in front of my driveway towed |
| 01:24:42 | drbrain | so I can park my car |
| 01:24:45 | brixen | evan: iirc, just remove the callcc excludes and run bin/ci |
| 01:26:01 | evan | zenspider: failed being VM sigbus? |
| 01:26:13 | evan | or the spec reports failure |
| 01:27:17 | evan | ok, abby and I are at a coffee shop, we're going to head home now. |
| 01:27:17 | Defiler | http://rafb.net/p/yhNFDl42.txt |
| 01:27:23 | zenspider | sigbus, mostly |
| 01:27:27 | Defiler | Does that give us any idea of what really caused the fault? |
| 01:27:34 | Defiler | I think it's a coincidence, but I could be wrong |
| 01:27:43 | evan | if it's callcc related |
| 01:27:50 | evan | there is a distinct posibility it's fixed now. |
| 01:28:03 | evan | the cpu_task (ie, Task class) was a VERY bad GC citizen. |
| 01:28:15 | brixen | evan: I'll run them right quick |
| 01:28:18 | evan | it was hiding pointers from the write barrier |
| 01:28:31 | zenspider | evan: ok. I think that is the main problem I'm having here atm... but I've not fully isolated yet |
| 01:28:37 | zenspider | BAD BAD Task class! |
| 01:28:45 | evan | very bad! |
| 01:28:48 | evan | my fault too. |
| 01:28:50 | evan | oh well. |
| 01:29:03 | evan | if someone else wants to look |
| 01:29:14 | evan | anytime data is written to a task object (ie, cpu_task struct) |
| 01:29:22 | evan | the cpu_task_run_wb function has to be called. |
| 01:29:37 | evan | having someone else do a quick audit would help |
| 01:29:52 | evan | for ref |
| 01:30:04 | evan | a Task object is tagged as storing bytes |
| 01:30:17 | evan | and it's body is a 'struct cpu_task' |
| 01:30:43 | agardiner | evan: presumably you mean any object data is written to the task? setting flags on the struct doesn't require this check does it? |
| 01:31:10 | evan | agardiner: you alteration of the contents of the body of a Task |
| 01:31:31 | evan | struct cpu_task *t = (struct cpu_task*)BYTES_OF(task_object); |
| 01:31:37 | evan | t->main = something_else; |
| 01:31:41 | evan | anything like that. |
| 01:31:48 | olabini leaves the room. | |
| 01:31:51 | evan | you can wait to run the cpu_task_run_wb until after a bunch of them have been done |
| 01:32:17 | agardiner | i am looking at the change to yield to the debugger on a context change... |
| 01:32:24 | evan | you don't have to run it after every write to the struct (though, i'm going to revise that code to use redirect code so the write barier is always run right away) |
| 01:32:29 | evan | ok, |
| 01:32:33 | evan | we're off. |
| 01:32:34 | evan | bbiab. |
| 01:32:44 | agardiner | i was thinking about using task->flags to set a bit |
| 01:33:02 | rubuildius | Evan Phoenix: 173068d91; 4446 examples, 16792 expectations, 0 failures, 0 errors |
| 01:35:06 | nicksieger enters the room. | |
| 01:35:30 | zenspider | anyone know why attr_writer uses __symbol_lookup__ instead of to_sym? |
| 01:36:45 | tmornini | zenspider: I worked on attr and friends. Let me take a look |
| 01:37:27 | agardiner | i'm guessing, but i'd say it's because to_sym may not be defined in bootstrap... |
| 01:37:52 | zenspider | it is now, so I'll move over to it |
| 01:39:04 | zenspider | argh... I think this is one of those that passes in isolation but fails in combination... poopy |
| 01:40:00 | djwhitt leaves the room. | |
| 01:40:16 | tmornini | zenspider: Oh, I see, you're working in bootstrap. I never touched those, other than moving them from object to module, per brixen. |
| 01:40:29 | tmornini | Sorry, make that class to module. |
| 01:40:30 | vintrepid_ enters the room. | |
| 01:41:08 | drbrain | dyld: lazy symbol binding failed: Symbol not found: _ev_default_loop |
| 01:41:15 | drbrain | trying distclean :( |
| 01:41:27 | zenspider | yeah. I think I got that too |
| 01:43:33 | drbrain | yay! |
| 01:44:00 | drbrain | I wish the Rakefile was properly plumbed into external_libs |
| 01:44:39 | crafterm_away leaves the room. | |
| 01:44:56 | defunkt leaves the room. | |
| 01:45:03 | vintrepid leaves the room. | |
| 01:45:18 | zenspider | hrm... I don't understand respond_to?'s implementation... :( |
| 01:47:06 | pauldix leaves the room. | |
| 01:47:22 | zenspider | man I have fucking around in bootstrap... it is fragile and I keep messing it up |
| 01:47:25 | brixen | it seems like the callcc issue might be fixed. I've run bin/ci -C, bin/ci -C -fs, bin/ci -fs, and bin/ci with 1 sigbus out of 6 runs |
| 01:47:44 | brixen | that sigbus might have just been one of the random ones I see now and then |
| 01:48:35 | zenspider | you see random ones? |
| 01:48:39 | brixen | I'll unexclude #callcc specs and push, we can revert if it's causing problems |
| 01:48:54 | brixen | zenspider: yeah, but I probably run bin/ci about 100x more than anyone else |
| 01:49:08 | zenspider | brixen: I'm already in there if you want to ignore |
| 01:49:24 | zenspider | I would like autotest to work again. :( |
| 01:49:31 | zenspider | otherwise, I'd beat you. :P |
| 01:49:42 | brixen | I pastied you a fix |
| 01:49:53 | brixen | if it would run without asking for rspec, I'd work on it |
| 01:50:37 | brixen | zenspider: you will unexclude #callcc then? |
| 01:50:47 | zenspider | all you have to do is write a discovery routine and autotest subclass |
| 01:51:06 | zenspider | I don't have the fix, or something else broke |
| 01:52:49 | brixen | well, pastie.caboo.se is unavailable, so I don't have it either |
| 01:53:12 | brixen | all I did was update the directories for the specs and e.g. compiler |
| 01:53:19 | zenspider | getting it to work with new systems is actually really easy. I did a lot of work with chelimsky to make it very flexible |
| 01:54:28 | zenspider | well... I also see the all-exclude.txt thing I added which is dead now |
| 01:54:35 | zenspider | wha do you mean about the compiler? |
| 01:54:40 | zenspider | what |
| 01:55:24 | boyscout | 2 commits by Brian Ford |
| 01:55:25 | boyscout | * Removed use of `pwd -P` as at least ubuntu bin/pwd doesn't support it.; d36b3f6 |
| 01:55:26 | boyscout | * Unexclude Kernel#callcc specs as Evan's recent commits seems to fix it.; 6d7a829 |
| 01:55:59 | brixen | zenspider: paths need to be updated for the spec move to spec/ruby/1.8 |
| 01:56:10 | brixen | and at the time I updated it, we had compiler[12] |
| 01:56:31 | brixen | point is, it basically just needs paths updated, unless you want to change stuff |
| 01:56:42 | zenspider | brixen: you're talking about the add_mapping section, yes? |
| 01:56:49 | zenspider | that doesn't matter |
| 01:57:11 | brixen | heh, that's why you should fix it, what do I know ;) |
| 01:57:37 | zenspider | the problem is that autotest used to respect the excludes, and now it doesn't, making using autotest unreasonable as a number of the excludes cause the system to die |
| 01:57:54 | brixen | well, they've just moved |
| 01:58:15 | brixen | but your find command will still find them |
| 01:58:17 | brixen | actually |
| 01:58:50 | brixen | maybe because you named it all-exclude.txt~ ? |
| 01:59:12 | tmornini | Hey guys. Did rake distclean get broken recently? |
| 01:59:28 | zenspider | brixen: so? |
| 01:59:30 | brixen | tmornini: I don't think so, what are you seeing? |
| 01:59:43 | zenspider | tmornini: just got a "YAY" from drbrain wrt it |
| 02:00:16 | tmornini | brixen: Well, it was breaking on shotgun, but now it seems OK. weird. |
| 02:00:21 | boyscout | 3 commits by Eric Hodel |
| 02:00:22 | boyscout | * Use C versions of getsockname(2) and getpeername(2).; c8b1636 |
| 02:00:23 | boyscout | * File::Stat#inode is really named File::Stat#ino.; 1a11d09 |
| 02:00:24 | boyscout | * Make ffi_getsockname only wrap getsockname(2); 7238595 |
| 02:00:37 | brixen | tmornini: yeah, sometimes it fails with something about task clean |
| 02:00:49 | tmornini | OK. |
| 02:00:52 | tmornini | Never seen that before. |
| 02:01:11 | brixen | tmornini: I saw it once, but I can't reproduce it |
| 02:01:30 | tmornini | OK, I'll try to isolate if it comes around again |
| 02:01:45 | tmornini | I didn't know Rubinius has a zombie pit! |
| 02:01:56 | tmornini | I'm happy, because every project of this size should have one. |
| 02:02:24 | tmornini | I was going to add it to the project plan, but looks like Evan beat me too it. :-) |
| 02:02:55 | tmornini | Command failed with status (2): [cd shotgun; make distclean...] |
| 02:03:18 | tmornini | /Users/tmornini/Desktop/rbx/rakefile:452 |
| 02:03:30 | zenspider | brixen: all-excludes.txt~ was supported via spec/mini_rspec.rb, which is apparently now gone and the equivalent functionality gone afaik... so I'm not sure _how_ to fix this in the new system |
| 02:04:57 | zenspider | is kinda afraid to git:pull |
| 02:06:12 | drbrain | tmornini: I'm having no problems with a fresh pull |
| 02:06:17 | drbrain | boyscout: sup? |
| 02:06:17 | boyscout | of course not |
| 02:06:38 | drbrain | boyscout: oh, I didn't see you there |
| 02:07:09 | brixen | zenspider: I have no idea what you're talking about, mSpec uses exactly the same mechanism to enable or exclude specs |
| 02:07:20 | brixen | even the command options to bin/mspec are the same |
| 02:07:37 | tmornini | drbrain: OK, thx |
| 02:07:49 | tmornini | I think it might be the zombie pit |
| 02:08:04 | zenspider | brixen: git show 092e0081c26eeda2ca6561eb19123b468965c84a | head -100 |
| 02:08:05 | tmornini leaves the room. | |
| 02:08:09 | zenspider | crap |
| 02:08:16 | zenspider | that head isn't big enough |
| 02:08:31 | zenspider | 125 is fine |
| 02:10:26 | brixen | zenspider: bin/mspec -h ;) |
| 02:10:45 | brixen | everything in that commit is available as a command line option |
| 02:11:02 | zenspider | brixen: yes. that's great. that really doesn't help, does it? |
| 02:11:12 | brixen | and it already outputs "started" and finished in blah seconds by default |
| 02:11:26 | brixen | what doesn't help? |
| 02:12:00 | brixen | bin/mspec -x spec/data/critical.txt -x all-excludes.txt~ -f d |
| 02:12:06 | zenspider | *sigh* nevermind. |
| 02:12:39 | brixen | zenspider: point me to some docs so I can understand this and I'll fix it |
| 02:13:40 | rubuildius | Eric Hodel: c8b1636e4; 4453 examples, 16802 expectations, 0 failures, 0 errors |
| 02:13:41 | rubuildius | Brian Ford: d36b3f65f; 4453 examples, 16802 expectations, 0 failures, 0 errors |
| 02:15:42 | istarex enters the room. | |
| 02:17:58 | cout | I really need to fix my nick highlighting. |
| 02:23:03 | dodecaphonic leaves the room. | |
| 02:23:17 | djwhitt enters the room. | |
| 02:23:39 | jbarnette leaves the room. | |
| 02:23:39 | _mutle leaves the room. | |
| 02:23:50 | VVSiz_ enters the room. | |
| 02:26:21 | rue | Evening |
| 02:27:30 | brixen | evening rue |
| 02:27:44 | brixen | rue: can you check the Module#instance_method specs on whatever ruby you have, please |
| 02:28:01 | slava leaves the room. | |
| 02:28:24 | rue | #instance_method or +s? |
| 02:28:45 | brixen | just instance_method |
| 02:28:55 | rue | 2/5/0/0 |
| 02:29:08 | brixen | I'm getting 2 failures |
| 02:29:09 | rue | A couple hours behind though if something just changed |
| 02:29:58 | brixen | rue: what ruby version? |
| 02:30:27 | VVSiz leaves the room. | |
| 02:30:43 | obvio171_ enters the room. | |
| 02:33:26 | brixen | rue: Module#instance_method returns an UnboundMethod representing the instance method with the given name |
| 02:33:41 | mutle enters the room. | |
| 02:34:07 | brixen | rue: fails for me on ruby 1.8.6 p111 (leopard), 1.8.6 p36 ubuntu 32bit, and 1.8.5 p2 gentoo 64bit |
| 02:41:56 | warren_s leaves the room. | |
| 02:43:03 | skaar enters the room. | |
| 02:47:38 | obvio leaves the room. | |
| 02:52:38 | turtletime enters the room. | |
| 02:52:45 | _mutle enters the room. | |
| 02:53:30 | kofno enters the room. | |
| 02:55:38 | brixen | drbrain: why does rubygems change the visibility of Kernel#require from private? |
| 02:55:56 | drbrain | because it's redefined |
| 02:56:21 | brixen | waits for the rest of the story ;) |
| 02:56:29 | cored leaves the room. | |
| 02:56:33 | drbrain | there is no rest |
| 02:57:04 | brixen | does it not work as a private method after redefinition? |
| 02:57:14 | drbrain | I have no idea |
| 02:57:19 | brixen | could it not be marked module_function, private, etc? |
| 02:57:21 | brixen | ok |
| 02:57:34 | drbrain | it could, nobody's complained |
| 02:57:58 | brixen | yeah, I just ran into it in the specs |
| 02:58:06 | brixen | running with rspec vs mspec |
| 02:58:09 | istarex leaves the room. | |
| 02:58:25 | headius | evening |
| 02:58:38 | brixen | evening |
| 02:59:07 | headius | someday I hope to climb out of IO hell |
| 02:59:21 | headius | should have some buffered IO specs reasonably soon though |
| 02:59:35 | brixen | sweet |
| 03:00:08 | mutle leaves the room. | |
| 03:00:27 | headius | I don't suppose either of you know whether sockets can be full-duplex buffered |
| 03:00:49 | headius | our current socket impl has bidir buffers, which seems to conflict with FILE only having a single buffer in C |
| 03:01:38 | brixen | hmm, such low level implementation details |
| 03:02:04 | headius | yeah |
| 03:02:05 | headius | libc low |
| 03:02:06 | brixen | I wish, to elaborate on rue's vision Socket < File < BufferedIO < IO |
| 03:02:12 | headius | but I'm implementing buffered IO |
| 03:02:35 | brixen | yeah |
| 03:02:42 | ezmobius leaves the room. | |
| 03:02:50 | smartocci_ leaves the room. | |
| 03:02:54 | headius | implementing libc semantics by hand...wheee |
| 03:03:16 | brixen | heh, as if there existed such a thing as "libc" :P |
| 03:03:25 | headius | so I have a single-buffered impl in one hand and a bidir buffered impl in the other |
| 03:03:30 | headius | and I need to reconcile the two |
| 03:03:30 | brixen | I've got 17 spec failures for core on ubuntu, 4 on leopard |
| 03:03:36 | brixen | I think they both use libc |
| 03:04:01 | brixen | of course, different patch levels |
| 03:04:03 | headius | I think single is correct because MRI wraps whatever fd in a FILE |
| 03:04:10 | headius | socket or otherwise |
| 03:04:10 | brixen | yep |
| 03:04:20 | brixen | well, not sure about socket, but yes for fd |
| 03:04:27 | headius | socket is just another fd |
| 03:05:30 | brixen | io.c is one of the most awful pieces of ruby, I think |
| 03:06:10 | headius | unfortunately I have grown to understand it |
| 03:10:24 | manveru | just wondering, anybody working on the IPAddr issue already? :) |
| 03:12:04 | drbrain | manveru: ? |
| 03:12:51 | manveru | i think IPSocket::getaddress was the problem |
| 03:13:22 | emphatic leaves the room. | |
| 03:13:24 | drbrain | manveru: I #addr and #peeraddr work as of about an hour ago |
| 03:13:39 | manveru | oh |
| 03:14:03 | manveru | so 2 down, 2 left? |
| 03:14:18 | drbrain | ? |
| 03:14:43 | mad_phoenix leaves the room. | |
| 03:15:12 | manveru | well, my grep shows that addr and peeraddr are two methods of 4 on IPSocket, left are #recvfrom and ::getaddress |
| 03:15:23 | drbrain | ah |
| 03:15:52 | drbrain | I don't see a getaddress on the socket classes in ri... |
| 03:16:03 | boyscout | 1 commit by Brian Ford |
| 03:16:04 | manveru | stdlib/ext/socket/socket.c: rb_define_singleton_method(rb_cIPSocket, "getaddress", ip_s_getaddress, 1); |
| 03:16:04 | boyscout | * Protect String#% specs from segfaulting on linux (ubuntu gutsy).; c09b3da |
| 03:16:11 | drbrain | weird |
| 03:16:24 | manveru | ri is weird |
| 03:16:36 | drbrain | getaddress should be easy to implement with the C code already there |
| 03:16:49 | manveru | with that IPAddr should pass as well |
| 03:17:02 | manveru | and open-uri proxy handling |
| 03:17:40 | manveru | i don't know C so i haven't attacked it |
| 03:17:51 | context | IPAddr doesnt have a getaddress on 1.8.6 |
| 03:18:05 | manveru | no |
| 03:18:19 | manveru | but it uses it |
| 03:18:28 | drbrain | IPSocket does |
| 03:18:28 | context | o |
| 03:18:49 | context | :/ yeah srry, confusin myself |
| 03:19:04 | manveru | heh, usually i'm the confused one :) |
| 03:19:34 | vintrepid_ leaves the room. | |
| 03:19:40 | manveru | sometimes the code in stdlib makes me wanna cry... |
| 03:20:34 | manveru | http://p.ramaze.net/268 |
| 03:20:39 | context | manveru: mmm feel lucky, you dont have to look at hte java stdlib all day |
| 03:21:07 | context | manveru: WOW ! |
| 03:21:25 | d2dchat__ leaves the room. | |
| 03:22:05 | context | manveru: serious? that could be done in 1-2 regex's |
| 03:22:05 | manveru | that is IPAddr#to_s |
| 03:22:05 | manveru | well, part of it |
| 03:22:11 | ko1_away0 enters the room. | |
| 03:23:06 | manveru | sometimes i suspect genetic coding would produce better looking stuff... |
| 03:24:31 | context | haha |
| 03:26:31 | rue | headius: Looks good, but the comparison to the rdoc is striking |
| 03:26:52 | rue | headius: Should we seek clarity from ruby-core? |
| 03:27:23 | headius | on which points do you think we need more clarity? |
| 03:27:44 | headius | it's a pretty detailed rundown of the current algorithm for each |
| 03:27:55 | headius | of course we want to distill out real specifiable behavior |
| 03:28:04 | rubuildius | Brian Ford: c09b3da39; 4451 examples, 16798 expectations, 0 failures, 0 errors |
| 03:28:36 | boyscout | 1 commit by Brian Ford |
| 03:28:37 | boyscout | * Explicitly run /bin/sh to get around limited /bin/pwd on linux.; 05a180e |
| 03:28:50 | MenTaLguY enters the room. | |
| 03:29:49 | rue | headius: Oh yeah, yours is an excellent summary of what happens right now |
| 03:30:14 | MenTaLguY | tarcieri: around? |
| 03:30:21 | headius | I don't claim to understand the pipe stuff all that well yet |
| 03:30:25 | headius | black box for the moment |
| 03:30:35 | tarcieri | hey |
| 03:30:37 | headius | but the flushing semantics and fileno handling I think I get |
| 03:30:48 | rue | But it is a lot more than what the docs promise, possibly some completely unnecessary stuff (as in no-one relies on it) |
| 03:30:51 | headius | I wish fileno/fd handling were also a black box to Ruby, but it doesn't appear to be |
| 03:31:07 | headius | IO.new and such |
| 03:31:27 | ko1_away leaves the room. | |
| 03:31:44 | rue | Heh, I was going to ask ko1 if he had planned an IO cleanup |
| 03:31:56 | boyscout | 1 commit by Brian Ford |
| 03:31:57 | boyscout | * Exclude Kernel#require is private spec when running with RSpec.; 14c811a |
| 03:32:22 | headius | I'd be surprised |
| 03:32:27 | headius | I wouldn't want to touch that code |
| 03:32:34 | tarcieri | MenTaLguY: did you see I released revactor? |
| 03:32:51 | headius | JRuby has an OpenFile and FILE impl now though...trying to map impl a bit more closely |
| 03:32:55 | headius | refactoring can follow |
| 03:33:02 | brixen | rue: do you get any Marshal#dump failures on whatever ruby you have? |
| 03:33:25 | rue | headius: I was looking at eigenclass and looks like just additional API stuff |
| 03:33:29 | headius | you guys could drop to FILE and fd and f* functions of course...is that the plan right now? |
| 03:33:36 | rue | brixen: Sec |
| 03:33:56 | rue | headius: I think the plan would be "sane IO" but not sure how that will pan out |
| 03:34:01 | headius | hah |
| 03:34:18 | headius | yeah, if you find a way I'd gladly help fill it out |
| 03:34:20 | brixen | headius: right now, buffered IO on read is done without using FILE |
| 03:34:24 | rue | I have a strong tendency to do the least possible on this |
| 03:34:29 | brixen | headius: evan just added it recently |
| 03:34:30 | headius | I've essentially been gutting JRuby IO right now |
| 03:34:38 | headius | how's it buffering? |
| 03:34:53 | brixen | headius: heh, it's ruby code man :P |
| 03:35:02 | brixen | le'me look right quick |
| 03:35:03 | headius | seems like a lot of extra effort...most of what i'm working on is duplicating libc behavior |
| 03:35:11 | brixen | I know is uses channels and fill_from |
| 03:35:13 | headius | if I could just use FILE you can bet I would |
| 03:35:41 | MenTaLguY | tarcieri: yeah, congratulations |
| 03:35:55 | crafterm enters the room. | |
| 03:36:08 | brixen | headius: IO::Buffer kernel/core/io.rb |
| 03:36:24 | MenTaLguY | tarcieri: I've been thinking more about remote actors |
| 03:36:43 | tarcieri | MenTaLguY: on other VMs in the same environment, or on remote hosts? |
| 03:36:51 | MenTaLguY | and/or |
| 03:36:59 | MenTaLguY | plus possibly other coexisting actor implementations |
| 03:37:11 | rue | brixen: Does bin/mspec take excludes into account? |
| 03:37:16 | vruz enters the room. | |
| 03:37:20 | brixen | rue: not unless you tell it to |
| 03:37:22 | tarcieri | MenTaLguY: yeah, I've been talking to the guy who wrote rbridge |
| 03:37:23 | brixen | -x <file> |
| 03:37:34 | tarcieri | MenTaLguY: about Ruby Actors talking to Erlang Actors |
| 03:37:39 | rue | brixen: Cool, I think I may have just run into an old file or something |
| 03:37:56 | MenTaLguY | tarcieri: it occurred to me that as long as we have a standard object protocol for things like linking and message sending, we should be able to duck-type any actor implementation in |
| 03:38:17 | MenTaLguY | tarcieri: ah, cool, the erlectricity guy contacted me a while back about the concurrent actors stuff, but nothing ever really came of it :/ |
| 03:38:18 | rue | evan: Around? dbussink and I were trying to figure out how to raise exceptions from regexp_new() last night |
| 03:38:33 | tarcieri | MenTaLguY: my plan was to implement DRb on top of (Rev)actor::TCP, and use that as the basis of a distributed Actor protocol |
| 03:38:36 | rue | MenTaLguY: CORBA actors :) |
| 03:38:57 | headius | brixen: ok |
| 03:39:01 | tarcieri | MenTaLguY: but for VM-to-VM communication it isn't needed, since evan's message queues largely accomplish the same thing |
| 03:39:22 | agardiner | tarcieri: congrats on Revactor |
| 03:39:30 | tarcieri | agardiner: yeah thanks |
| 03:39:31 | MenTaLguY | tarcieri: yes, I think DRb over-Revactor::TCP is a good start, although long-term we will want something lighter-weight (marhsal's representation is extremely heavyweight) |
| 03:39:58 | tarcieri | MenTaLguY: yeah, I'm trying to keep everything as simple as possible for the time being |
| 03:40:08 | MenTaLguY | nods |
| 03:40:20 | agardiner | the web site provids an excellent write-up of actors etc |
| 03:40:35 | agardiner | makes me want to use them! |
| 03:40:37 | tarcieri | MenTaLguY: but the next two things on my slate are getting linked processes going (and supervisors) then DRb |
| 03:40:41 | MenTaLguY | part of what got me thinking about this was I was considering whether to drop actors from the omnibus library, when I realized that you and I are really going for somewhat different things in our use of threads/fibers |
| 03:40:46 | tarcieri | agardiner: heh, thanks |
| 03:41:04 | tarcieri | MenTaLguY: oh yeah? |
| 03:41:11 | tarcieri | I mean, Fibers prevent preemption |
| 03:41:14 | tongueroo leaves the room. | |
| 03:41:15 | MenTaLguY | but then I realized that as long as the actors duck-type the same for linking and message sending, it shouldn't matter, we should be interoperable |
| 03:41:19 | tarcieri | That's the biggest difference |
| 03:41:22 | tarcieri | Yeah, for sure |
| 03:41:43 | MenTaLguY | so since you've got linking on the brain right now, let's see if we can work out the protocol for that |
| 03:41:46 | MenTaLguY | and I guess object sending too |
| 03:41:48 | tarcieri | The biggest difference is blocking calls will hang Revactor so it's important you use "Actor-safe" stuff for everything, which kind of sucks, but has performance benefits |
| 03:42:08 | MenTaLguY | that's fine; it's internal to the actor isn't it? |
| 03:42:19 | MenTaLguY | the parts where they interface are external to the actor |
| 03:42:30 | MenTaLguY | and asynchronous |
| 03:42:48 | MenTaLguY | are you using << for message sending, OOC? |
| 03:42:48 | tarcieri | Yeah, I mean, ultimately the whole goal is to give you a synchronous imperative interface on top of an asynchronous API |
| 03:42:57 | tarcieri | Yes, << is aliased to #send |
| 03:42:58 | MenTaLguY | I've not taken a close look at Revactor's implementation yet |
| 03:43:08 | MenTaLguY | ok, cool |
| 03:43:26 | tarcieri | I don't particularly like redefining #send, but it's not like it's a big problem... most stuff uses __send__ and such anyway |
| 03:43:31 | MenTaLguY | let's use #<< as the "standard" message sending thing for the actor object protocol |
| 03:43:37 | tarcieri | Yes |
| 03:43:40 | tarcieri | That's what I've been doing |
| 03:43:41 | rubuildius | Brian Ford: 14c811ada; 4451 examples, 16798 expectations, 0 failures, 0 errors |
| 03:43:42 | rubuildius | Brian Ford: 05a180e00; 4451 examples, 16798 expectations, 0 failures, 0 errors |
| 03:43:47 | MenTaLguY | okay, next up |
| 03:43:48 | MenTaLguY | linking |
| 03:44:08 | tarcieri | MenTaLguY: heh, some guy suggested an alternative to the Case gem |
| 03:44:13 | MenTaLguY | I saw that |
| 03:44:18 | tarcieri | Although his stuff isn't released as a Gem at all |
| 03:44:20 | tarcieri | So... |
| 03:44:23 | MenTaLguY | I think it might be a little overkill |
| 03:44:33 | MenTaLguY | one of the reasons I'm trying to exploit #=== is performance |
| 03:44:38 | tarcieri | I don't need anything you haven't already implemented |
| 03:45:08 | MenTaLguY | (well, aside from being sort of what Ruby normally does for matching) |
| 03:45:21 | tarcieri | I haven't run into a need for Case.guard yet, even, but I wanted to make sure something like that was available just in case, heh |
| 03:45:26 | jtoy enters the room. | |
| 03:45:43 | MenTaLguY | I've been thinking about Case::Any (without brackets) as a universal wildcard |
| 03:45:49 | MenTaLguY | I realized that not everything descends from Object |
| 03:45:59 | MenTaLguY | (BasicObject anyone?) |
| 03:46:08 | rightondev leaves the room. | |
| 03:46:08 | tarcieri | Yeah, originally I had something like Revactor::ANY_OBJECT |
| 03:46:14 | tarcieri | but got rid of that |
| 03:51:24 | rightondev enters the room. | |
| 03:54:36 | MenTaLguY | Will it cause any problems for you if I pull case.rb from Rubinius for the moment? |
| 03:54:46 | MenTaLguY | I think the implementation of case is still fairly in flux |
| 03:54:50 | tmornini enters the room. | |
| 03:54:53 | tarcieri | Nope |
| 03:55:13 | MenTaLguY | okay, co ol |
| 03:55:19 | tarcieri | In order to get something like Revactor on top of Rubinius I need nested loops |
| 03:55:29 | tarcieri | Like uhh, libev nested event loops |
| 03:55:36 | MenTaLguY | elaborate? |
| 03:55:57 | boyscout | 1 commit by MenTaLguY |
| 03:55:58 | boyscout | * remove case.rb for now; the gem will do for most people; 6f5308c |
| 03:55:59 | tarcieri | Stateful sets of descriptors I can enable and disable monitoring on |
| 03:56:09 | MenTaLguY | I see |
| 03:56:21 | tarcieri | libev originally supported nested event loops |
| 03:56:29 | tarcieri | So you could add one loop to the other |
| 03:56:43 | MenTaLguY | nods |
| 03:56:47 | tarcieri | I think the author may have removed that feature because it couldn't be done reliably in a cross-platform manner |
| 03:57:01 | tarcieri | I'll have to find out |
| 03:57:13 | MenTaLguY | hm, it seems like it should be doable |
| 03:57:28 | tarcieri | iirc he was having trouble with kqueue |
| 03:57:29 | MenTaLguY | the nesting stuff shouldn't have any platform-specific elements |
| 03:57:45 | MenTaLguY | unless he's trying to do it at too low a level of abstraction |
| 03:58:01 | MenTaLguY | so, wait, if libev removed them what are you doing for Revactor? |
| 03:58:22 | tarcieri | In Ruby 1.9 I have a thread-specific event loop |
| 03:58:23 | GMFlash leaves the room. | |
| 03:58:32 | GMFlash enters the room. | |
| 03:58:52 | tarcieri | But, more than that, I have a #run_once method on the event loop |
| 03:59:11 | tarcieri | So all the event-processing callbacks can get called in a single batch |
| 03:59:24 | tarcieri | Then the Actor loop switches back to processing Actor mailboxes |
| 03:59:31 | tarcieri | And then back to waiting for events with libev |
| 03:59:58 | tarcieri | Each thread runs as a single event loop |
| 04:02:06 | MenTaLguY | hm |
| 04:02:16 | MenTaLguY | so, back to linking |
| 04:02:21 | tarcieri | yeah |
| 04:02:23 | MenTaLguY | I think we basically need three things |
| 04:02:35 | tarcieri | a big thing is a serializable exception object |
| 04:02:39 | tarcieri | that'd be super-handy |
| 04:02:51 | MenTaLguY | well, yeah, although I think that's a nicety |
| 04:03:14 | tarcieri | you could return the exception as a string :/ |
| 04:03:22 | MenTaLguY | yes, or some other form |
| 04:03:23 | nicksieger leaves the room. | |
| 04:03:32 | MenTaLguY | it doesn't really matter for the basic protocol I don't think |
| 04:03:36 | tarcieri | yeah |
| 04:03:45 | tarcieri | all you really need is a reason message of some sort |
| 04:03:47 | headius leaves the room. | |
| 04:03:54 | MenTaLguY | yeah |
| 04:03:55 | nicksieger enters the room. | |
| 04:04:15 | MenTaLguY | well, plus maybe a symbol for a program-interpreted code |
| 04:04:17 | headius enters the room. | |
| 04:04:21 | MenTaLguY | if not an exception type |
| 04:04:41 | MenTaLguY | so, here's what I'm thinking |
| 04:05:00 | tarcieri | For Revactor I'm probably just going to use exceptions |
| 04:05:07 | MenTaLguY | nods |
| 04:05:13 | MenTaLguY | similarly in Concurrent |
| 04:06:20 | MenTaLguY | so, I think besides messages there are three other asynchronous signals actors can send to one another |
| 04:06:51 | MenTaLguY | "link" (register the supplied actor as a linked actor), "unlink" (unregister the supplied actor as a linked actor), and "exit" (an actor exit notification) |
| 04:07:19 | tarcieri | yeah |
| 04:07:23 | MenTaLguY | I'm thinking that actors could have corresponding #notify_link, #notify_unlink, and #notify_exit methods |
| 04:07:39 | tarcieri | I've been using on_* for that stuff in Rev |
| 04:07:58 | MenTaLguY | on_* sounds like event handlers though |
| 04:08:04 | rubuildius | MenTaLguY: 6f5308c79; 4451 examples, 16798 expectations, 0 failures, 0 errors |
| 04:08:12 | mdmurray leaves the room. | |
| 04:08:21 | tarcieri | Isn't that what you had in mind? |
| 04:08:37 | MenTaLguY | I'm thinking of an external inter-actor interface |
| 04:08:41 | sudoer enters the room. | |
| 04:09:02 | tarcieri | okay, so when would those be called? |
| 04:09:15 | MenTaLguY | so, Concurrent::Actors::Actor#link might look like: |
| 04:09:15 | MenTaLguY | def link(actor) |
| 04:09:15 | MenTaLguY | actor.notify_link(self) |
| 04:09:15 | MenTaLguY | notify_link(actor) |
| 04:09:15 | MenTaLguY | end |
| 04:09:31 | tarcieri | okay |
| 04:09:41 | tarcieri | so just that as a generic wrapper for sending the messages |
| 04:09:52 | MenTaLguY | yes |
| 04:09:54 | tarcieri | Sure |
| 04:10:05 | MenTaLguY | unlink would work the same way basically |
| 04:10:07 | djwhitt leaves the room. | |
| 04:10:37 | MenTaLguY | when an actor dies it would be responsible for walking its own list of linked actors and calling notify_exit on them |
| 04:10:55 | MenTaLguY | notify_exit takes two arguments, the exited actor and some sort of exception/error object |
| 04:11:03 | tarcieri | "reason" |
| 04:11:05 | tarcieri | ok |
| 04:11:48 | MenTaLguY | nil for a normal/successful exit |
| 04:12:01 | tarcieri | sounds good |
| 04:12:03 | MenTaLguY | hm, I think that may be all the protocol we need; can you think of anything else? |
| 04:12:12 | tarcieri | the #trap interface |
| 04:12:18 | tarcieri | but yeah |
| 04:12:20 | tarcieri | message-wise |
| 04:12:22 | tarcieri | that's fine |
| 04:12:34 | MenTaLguY | #trap's internal to the actor implementation though, I think different actor implementations may want to do different things |
| 04:12:47 | MenTaLguY | also I haven't been able to find an interface for trap-like functionality that I'm happy with yet :) |
| 04:12:50 | tarcieri | I assume you're thinking [:link, actor], [:unlink, actor], and [:exit, actor, reason] ? |
| 04:13:02 | tarcieri | where those messages could be tuples |
| 04:13:20 | MenTaLguY | actually link/unlink and exit signals need to be out-of-band with respect to messages |
| 04:13:30 | tarcieri | oh right |
| 04:13:47 | MenTaLguY | an exit signal to a non-trapping actor needs to terminate that actor even if it has messages waiting |
| 04:13:54 | tarcieri | They need to be "system" messages |
| 04:14:00 | MenTaLguY | yeah |
| 04:14:37 | MenTaLguY | if the actor is trapping an exit then it is responsible for submitting an appropriate message into its own mailbox |
| 04:15:12 | MenTaLguY | I'm not sure the form of that message needs to be standardized between actor implementations |
| 04:15:57 | rue | I have a feeling I will somehow learn this concurrency stuff through osmosis |
| 04:16:07 | tarcieri | Well, if an Actor is trapping exit shouldn't it be delivered a message in a standard form? |
| 04:16:16 | tarcieri | Not necessarily through its standard mailbox, but through Actor.reeive |
| 04:16:47 | tarcieri | There should be a standard pattern you can match for exit messages |
| 04:16:53 | tarcieri | That's all that's really important, imo |
| 04:17:05 | tarcieri | err |
| 04:17:06 | MenTaLguY | yes |
| 04:17:07 | tarcieri | Actor.receive |
| 04:17:29 | MenTaLguY | I am saying that trapped exit notifications should be available as messages via Actor.receive |
| 04:17:47 | jtoy leaves the room. | |
| 04:17:51 | MenTaLguY | but those messages will always be produced by the local actor for itself, not by the remote actor sending the notification |
| 04:18:09 | tarcieri | do you want an overridable method to do that? |
| 04:18:25 | MenTaLguY | so the standard form need only be standard to the particular actor implementation |
| 04:18:30 | MenTaLguY | er, huh? |
| 04:18:35 | tarcieri | I don't follow |
| 04:19:06 | MenTaLguY | I don't follow either :/ |
| 04:19:49 | tarcieri | heh |
| 04:19:51 | tarcieri | basically |
| 04:20:01 | tarcieri | what's your equivalent to {'EXIT', Pid, Reason} |
| 04:20:32 | MenTaLguY | Actors::ActorExit[actor, reason] I think. been a while since I looked |
| 04:20:43 | MenTaLguY | but those are never passed between actors directly, are they? |
| 04:20:50 | rue | brixen: Marshal#load 64/64/13/1, Marshal#dump 80/89/2/0 |
| 04:20:51 | tarcieri | it doesn't matter |
| 04:21:01 | tarcieri | you still have to match against it with Mailbox::Filter |
| 04:21:14 | rue | brixen: One minor float error on MRI in #dump |
| 04:21:15 | tarcieri | to multiplex the reception of other types of messages with exit events |
| 04:21:25 | tarcieri | if you so desire |
| 04:21:29 | MenTaLguY | yes |
| 04:21:36 | MenTaLguY | but that's trivial |
| 04:21:41 | tarcieri | granted it will generally be wrapped up in supervisors, but supervisors still have to get other types of messages |
| 04:21:49 | MenTaLguY | it doesn't need to be specified as part of the inter-actor protocol |
| 04:21:49 | tarcieri | well, it should still be standard across different Actor implementations |
| 04:21:56 | MenTaLguY | I don't see why it has to be |
| 04:21:56 | tarcieri | not inter-Actor |
| 04:22:08 | tarcieri | Just what the actor that's trapping exit receives |
| 04:22:10 | tarcieri | should be standard |
| 04:22:20 | MenTaLguY | shrugs |
| 04:22:21 | MenTaLguY | why? |
| 04:22:22 | tarcieri | [:exit, actor, reason] |
| 04:22:24 | tarcieri | fine? |
| 04:22:24 | tarcieri | heh |
| 04:22:45 | tarcieri | because Actors that are trapping exit need to specify a filter for processing exit messages |
| 04:22:56 | MenTaLguY | sure |
| 04:23:01 | tarcieri | and that filter should be standard |
| 04:23:04 | MenTaLguY | but people are going to be writing for specific actor implementations |
| 04:23:05 | tarcieri | so the message needs to be standard |
| 04:23:18 | tarcieri | you don't have to |
| 04:23:21 | tarcieri | heh |
| 04:23:30 | tarcieri | I dunno, I'd just like it to be as standard as possible |
| 04:23:40 | tarcieri | My goal is to write stuff for Revactor then move it all onto Rubinius |
| 04:24:13 | MenTaLguY | well, portability between those two implementations is important certainly |
| 04:24:20 | MenTaLguY | so that's a reason |
| 04:24:36 | tarcieri | I mean, you're not planning on doing anything other than [:exit, actor, reason] right? |
| 04:24:37 | tarcieri | heh |
| 04:24:48 | MenTaLguY | [:exit, actor, reason] is fine as far as I'm concerned |
| 04:24:52 | tarcieri | cool |
| 04:25:09 | MenTaLguY | I may do something different in the Omnibus implementation, but I'll follow your lead in the Rubinius built-in thingy |
| 04:25:15 | tarcieri | cool |
| 04:25:54 | MenTaLguY | evan: how would you feel about making Rubinius' Array#=== structural? |
| 04:26:22 | tarcieri | or at least with Tuple |
| 04:26:31 | MenTaLguY | well, [:exit, actor, reason] is an Array though |
| 04:26:41 | tarcieri | urgh |
| 04:26:45 | tarcieri | yeah that decision is a bitch |
| 04:26:55 | MenTaLguY | if we did Array#=== we should certainly do Tuple#=== too though |
| 04:26:55 | tarcieri | I'm using Tuples for everything atm :/ |
| 04:28:04 | MenTaLguY | it would be nice if Tuples implemented Enumerable |
| 04:28:05 | tarcieri | Case matches either with Case[] though, right? |
| 04:28:18 | MenTaLguY | just Arrays |
| 04:28:39 | MenTaLguY | I went back and forth on that a lot, but there would be portability problems between Rubinius and MRI otherwise |
| 04:28:42 | tarcieri | I guess becuase I implement Tuple as a subclass of Array it's fine |
| 04:28:49 | MenTaLguY | yeah |
| 04:28:53 | MenTaLguY | and there is Case::Tuple[] |
| 04:28:57 | MenTaLguY | if you are on Rubinius |
| 04:29:08 | tarcieri | Hmmm, heh |
| 04:29:28 | MenTaLguY | or more generally if Case is loaded when there is a ::Tuple defined |
| 04:29:39 | tarcieri | Yeah, that's what I'm doing |
| 04:29:51 | MenTaLguY | should get Case::Tuple in that case too then |
| 04:30:37 | MenTaLguY | also I'm considering adding a case/core which adds structural #=== to Array, Struct and Tuple (when applicable) |
| 04:30:47 | MenTaLguY | I mean, the top-level ones, not just the Case versions |
| 04:30:48 | tarcieri | that'd definitely be the way to go |
| 04:30:59 | tarcieri | yeah |
| 04:31:00 | MenTaLguY | so require 'case/core' if you want to live dangerously :) |
| 04:31:06 | tarcieri | nice |
| 04:31:17 | tarcieri | it's not like people use Array#=== for anything else really |
| 04:31:29 | tarcieri | at least, in such a way that redefining it in that way would break it |
| 04:31:38 | MenTaLguY | yeah |
| 04:33:44 | evan | MenTaLguY: we can't change the behavior of Array#=== |
| 04:33:48 | evan | sorry. |
| 04:34:09 | MenTaLguY | why not? |
| 04:34:18 | tarcieri | what if it's 99.9% backwards compatible? |
| 04:34:20 | MenTaLguY | you're doing more dangerous stuff like making loop a keyword |
| 04:34:37 | MenTaLguY | unless you've changed your mind about that |
| 04:34:39 | evan | not really. |
| 04:34:56 | evan | the loop API is braindead. |
| 04:35:00 | tarcieri | evan: what would break is if someonce compared [:foo, Object, Object] === [:foo, :bar, :baz] and expected it to be false |
| 04:35:04 | evan | and if we find a conflict, i'll change it back. |
| 04:35:23 | evan | but Array#=== needs to have the same behavior as MRIs |
| 04:35:27 | MenTaLguY | [:foo, Object, Object] === [:foo, Object, Object] would still work |
| 04:35:29 | evan | the current loop optimization does. |
| 04:35:42 | evan | (have the same behavior) |
| 04:35:54 | MenTaLguY | not if it takes precedence over a private method named "loop" (does it?) |
| 04:36:08 | evan | it does |
| 04:36:17 | evan | but it has the same behavior as the Kernel one |
| 04:36:26 | evan | and if someone writes a loop method that we conflict with |
| 04:36:28 | evan | we'll remove it |
| 04:36:34 | MenTaLguY | I have, actually ... |
| 04:36:34 | tarcieri | evan: the change vs MRI would be certain cases involving arrays with constants or regexes in them would be true |
| 04:36:40 | evan | it was a fun test |
| 04:36:44 | evan | MenTaLguY: then it's out. |
| 04:37:07 | brixen | jero5: you around? |
| 04:37:43 | jero5 | brixen: yeah |
| 04:37:58 | brixen | jero5: what os and version of ruby? |
| 04:38:40 | brixen | jero5: I'm getting a failure on Marshal#dump at line 457 of the spec on leopard 1.8.6 p111 |
| 04:41:49 | tarcieri | evan: in the end how is that really any different from massign? |
| 04:42:05 | evan | how is what different? |
| 04:42:27 | tarcieri | evan: do you think there are a lot of real world cases were people depend on Array#=== with constants and/or regexes in it to not match against other arrays? |
| 04:42:28 | jero5 | brixen: 1.8.6 p111, unbuntu gutsy. let me pull the latest rbx version and see if i get the error too |
| 04:42:31 | TheVoice | evening to you all |
| 04:42:32 | tarcieri | s/were/where/ |
| 04:42:37 | rue | evan: Raising errors from functions accessed through primitives when you have the chance to lay out the plan? (regexp_new is not passed cpu) |
| 04:42:41 | evan | tarcieri: the problem is I don't want to find out. |
| 04:42:45 | tarcieri | heh |
| 04:42:51 | evan | rue: not allowed. |
| 04:42:58 | evan | rue: you may not raise an exception in a primitive. |
| 04:43:10 | brixen | jero5: it's mri that concerns me, not rbx |
| 04:43:12 | tarcieri | evan: I suppose, I just can't possibly conceive of a real world example where someone would actually be relying on the behavior that changes |
| 04:43:29 | tarcieri | evan: But, that aside, could you do it for Tuple#=== ? |
| 04:43:31 | brixen | jero5: I'm still on p36 on ubuntu, I'm going to install p111 tomorrow |
| 04:43:38 | evan | rue: a primitive may fail, then the code that declares the primitive raises an exception |
| 04:43:50 | evan | tarcieri: Tuple#=== sure |
| 04:43:56 | tarcieri | evan: awesome |
| 04:44:04 | rue | evan: Hm, I have some bad news for you.. :) grep -Rn 'cpu_raise' shotgun/lib/primitives.rb | wc -l => 8 |
| 04:44:05 | evan | we don't have to worry about API compatibility with Tuple |
| 04:44:09 | MenTaLguY | while we're on the subject of Tuple, what about having Tuple implement Enumerable? |
| 04:44:28 | evan | rue: then someone has to be hanged. |
| 04:44:54 | MenTaLguY | yay git-blame |
| 04:44:58 | evan | rue: every single one of those has to be removed. |
| 04:44:59 | rue | evan: But I remember that part now, we just fail and then the method body gets executed |
| 04:45:09 | evan | NEVER raise an exception in a primitive. |
| 04:45:11 | evan | NEVER. |
| 04:45:36 | evan | looks like agardiner |
| 04:45:41 | evan | and whoever worked on IO. |
| 04:46:11 | evan | the only valid one is in thread_raise |
| 04:46:37 | evan | I might have done a couple of those because I was being lazy |
| 04:46:37 | jero5 | brixen: i get no errors under mri. does it need a patch level guard or something? |
| 04:46:39 | evan | but i should not have. |
| 04:47:02 | brixen | evan: the one in task_raise? |
| 04:47:37 | brixen | jero5: that's what is so odd, this is p111 on leopard :( |
| 04:47:47 | evan | that one is ok |
| 04:47:53 | evan | though task_raise isn't used anymore. |
| 04:47:54 | brixen | begins to hate mri with a passion |
| 04:48:02 | brixen | evan: ok, just checkin |
| 04:49:41 | rue | evan: What would be the recommended way of getting the "exception" up from the C? Do the FALSE and bind a regexp_last_onig_error() or similar? |
| 04:49:48 | agardiner | evan: i copied the cpu_raise in task_get_stack_value from one of the other primitives... |
| 04:49:52 | agardiner | how should that be handled? |
| 04:50:59 | evan | the primitive should fail |
| 04:51:08 | agardiner | how do i get it to fail? |
| 04:51:08 | evan | and an exception raise |
| 04:51:28 | rue | Or wait, can you use the stack with FALSE? |
| 04:51:32 | evan | return FALSE |
| 04:51:33 | evan | is ok. |
| 04:51:52 | evan | do NOT pass things on the stack. |
| 04:51:55 | evan | it will not work. |
| 04:52:13 | rue | WOuld seem like.. OK |
| 04:53:40 | brixen | ok, this is what I'm thinking: mri stable is 1.8.6 p111, I think the spec *have* to use this version |
| 04:53:53 | brixen | all this shit with platforms is enough trouble, without the version crap on top of it |
| 04:54:07 | brixen | all objections should be raised now ;) |
| 04:54:15 | MenTaLguY | the patchlevel stuff for 1.8.6 has been kind of insane :/ |
| 04:54:29 | brixen | yeah, tell me about it :) |
| 04:54:44 | MenTaLguY | it wouldn't be so bad if all of the release download stuff was consistently updated to recent patchlevels |
| 04:55:11 | brixen | MenTaLguY: yeah, that is such a pain, distros that package really old versions of ruby |
| 04:55:20 | MenTaLguY | no, I mean ruby-lang.org downloads |
| 04:55:30 | MenTaLguY | depending on which file you get it may not be p111 |
| 04:55:32 | MenTaLguY | at least, last I looked |
| 04:55:37 | brixen | yikes, are you serious? |
| 04:55:38 | MenTaLguY | I bitched about it a while back on the mailing list |
| 04:55:42 | tarcieri | MenTaLguY: have you thought about making Case::Tuple match Arrays with === and Case.[] use Case::Tuple if available? |
| 04:55:49 | MenTaLguY | maybe it was for an earlier patchlevel |
| 04:56:04 | MenTaLguY | Tony: I might consider it |
| 04:56:19 | tarcieri | that'd eliminate the whole Array/Tuple distinction nicely, I think |
| 04:56:45 | tarcieri | I mean |
| 04:56:57 | tarcieri | If Tuple#=== compared the way Case::Tuple does now |
| 04:56:58 | MenTaLguY | brixen: the catalyst was someone complaining about problems with builtin fastthread that had been fixed in p110 I think |
| 04:57:14 | tarcieri | Case.[] could just call Tuple.[] |
| 04:57:36 | brixen | MenTaLguY: ok, thanks |
| 04:57:38 | MenTaLguY | brixen: turned out they were using p63 or something like that and that was the latest version available from the particular file they downloaded |
| 04:57:51 | brixen | ok |
| 04:57:53 | MenTaLguY | maybe it's been fixed since I bitched about it |
| 04:57:59 | brixen | I hope so :/ |
| 04:58:01 | MenTaLguY | I haven't looked |
| 04:58:06 | evan | brixen: any chance you could have radient deployed tonight? |
| 04:58:11 | brixen | well, this will only affect folks writing specs |
| 04:58:27 | MenTaLguY | tarcieri: well, Case::Tuple#=== and Tuple#=== should certainly always do the same thing |
| 04:58:33 | MenTaLguY | if you are using case/core |
| 04:58:38 | brixen | evan: hmm, I was working on a bit of a change to the theme, the white on black needs to go |
| 04:58:45 | brixen | evan: can it wait till tomorrow? |
| 04:58:56 | evan | brixen: why theme are you changing it to? |
| 04:59:10 | tarcieri | MenTaLguY: sounds like evan was cool with Tuple#=== doing the Case thing in Rubinius core... |
| 04:59:22 | brixen | pretty much the same for the logo (i.e. black background) with the page a lighter gray and the sides a darker grey |
| 04:59:29 | brixen | evan: the readability right now sucks really bad |
| 04:59:34 | tarcieri | MenTaLguY: and I'd certainly implement the same behavior... |
| 04:59:41 | evan | brixen: ok. tomorrow is fine. |
| 04:59:43 | brixen | evan: and it's really limited for adding more info regions |
| 04:59:54 | MenTaLguY | tarcieri: right now case/core won't nuke an existing Tuple#=== if one is defined on Tuple |
| 04:59:56 | evan | brixen: remember, up and ugly is better than down and pretty. |
| 05:00:03 | brixen | evan: ok, yeah, gotcha |
| 05:00:08 | tarcieri | MenTaLguY: ok |
| 05:00:14 | evan | even something dead simple |
| 05:00:14 | brixen | evan: you can update info right now, if you want |
| 05:00:17 | evan | theme wise |
| 05:00:24 | MenTaLguY | I need to start writing more code on paper |
| 05:00:28 | brixen | evan: or did you want something changed with the structure? |
| 05:00:31 | tarcieri | MenTaLguY: so sounds like Case::Tuple isn't really needed then |
| 05:00:46 | MenTaLguY | tarcieri: hmm, good point! |
| 05:00:53 | evan | brixen: i want to get a solution we want to move forward with in place |
| 05:01:00 | evan | brixen: since we don't like the current setup |
| 05:01:05 | jbarnette enters the room. | |
| 05:01:13 | evan | i want to get the system we want in place |
| 05:01:16 | brixen | evan: yep, I've got a git repo with it imported, need to work on the theme |
| 05:01:17 | evan | then we can pretty it up and add content. |
| 05:01:24 | brixen | evan: I can have it up tomorrow |
| 05:01:57 | evan | ok |
| 05:02:14 | evan | even just changing the colors on the default theme is fine. |
| 05:02:17 | evan | honestly. |
| 05:02:23 | brixen | yeah, it's not a big change |
| 05:02:35 | brixen | but it will help readability a lot |
| 05:02:41 | evan | no problem. |
| 05:02:50 | rue | evan: Oh.. one more. The coercion issue with #kind_of? |
| 05:03:02 | evan | which? |
| 05:03:04 | evan | i'm unaware. |
| 05:03:16 | rue | evan: #265 |
| 05:03:53 | rue | evan: Basically Rake::FileList overrides #kind_of?(Array) == true which means coerce_to does not call #to_ary on it |
| 05:04:26 | rue | evan: Which will end up ugly particularly with stuff that uses @total and @tuple etc. |
| 05:04:32 | evan | rue: lets alias kind_of? to __kind_of__ |
| 05:04:41 | evan | and use it in the low level, system methods. |
| 05:05:11 | rue | evan: Generally workable, what about delegation though? |
| 05:05:42 | rue | Rake::FileList is fscking awful there, though, so it might be better to just fix it |
| 05:05:43 | evan | in what way? |
| 05:06:22 | evan | i don't see a problem with __kind_o__ |
| 05:06:26 | evan | __kind_of__ |
| 05:06:31 | rue | It will delegate __kind__of_P__ to its internal Array too |
| 05:06:38 | evan | please indicate the problem. |
| 05:06:51 | agardiner | wow... bin/ci is faster! |
| 05:06:59 | evan | rue: still don't see the problem. |
| 05:07:04 | agardiner | first time i've seen < 60s! |
| 05:07:40 | rue | evan: Well, I am trying to figure out whether this is something we need to do or something whoever exploits kind_of? needs to fix |
| 05:08:04 | evan | rue: huh? |
| 05:08:17 | evan | i still don't see why making Type.coerce_to using __kind_of__ is a problem. |
| 05:08:25 | evan | that is a better solution than the attached patch |
| 05:08:31 | evan | i need to eat |
| 05:08:33 | evan | bbiab. |
| 05:09:48 | tongueroo enters the room. | |
| 05:09:57 | rue | evan: In this case FL will fake kind_of?, it will also delegate __kind_of__. So even if Type.coerce_to uses __kind_of__, it still will not call #to_ary. So, if we break encapsulation accessing it anywhere in code where it should have been coerced, it will break |
| 05:10:21 | rue | I do not want to revisit this later |
| 05:11:16 | d2dchat enters the room. | |
| 05:12:38 | rue | Erm ~~so I was trying to figure out whether A) kind_of?(Whatever) == true means exactly that and library author needs to fix or B) should we go defensive and #equal? ancestors or whatever |
| 05:14:01 | tarcieri | MenTaLguY: you still around? |
| 05:14:03 | MenTaLguY | yeah |
| 05:14:08 | brynary enters the room. | |
| 05:14:16 | tarcieri | MenTaLguY: why do you need a reciprocal relationship for linked actors? |
| 05:14:17 | tarcieri | cl |
| 05:14:19 | tarcieri | geh |
| 05:14:55 | tarcieri | shouldn't any Actor interpret any exit message sent to the system mailbox as a reason to exit? |
| 05:15:51 | MenTaLguY | Tony: well, if we're following Erlang it should be reciprocal |
| 05:16:13 | MenTaLguY | as far as linking goes |
| 05:16:18 | tarcieri | oh right, it's not a digraph, it's a graph |
| 05:16:19 | tarcieri | my bad |
| 05:16:26 | MenTaLguY | link_notify just does half the link though |
| 05:16:36 | tarcieri | err, #notify_link? |
| 05:16:38 | tarcieri | heh |
| 05:16:39 | MenTaLguY | since each of the two participants is responsible for their own link table |
| 05:16:41 | MenTaLguY | er, yeah |
| 05:16:43 | MenTaLguY | notify_link |
| 05:17:06 | MenTaLguY | as far as exit messages sent to the system mailbox, could you elaborate? |
| 05:17:24 | tarcieri | well, here's the problem I forsee now |
| 05:18:05 | tarcieri | if you follow Erlang ! semantics, sending a message to a process that has already exited it doesn't raise any error... what about linking to a process that's exited? |
| 05:18:07 | tarcieri | tests... |
| 05:18:26 | MenTaLguY | linking to an exited process will error if it is a local actor |
| 05:18:31 | MenTaLguY | it will fail silently for a remote actor |
| 05:18:33 | MenTaLguY | IIRC |
| 05:18:54 | tarcieri | yeah, it certainly fails in the local case... |
| 05:18:56 | MenTaLguY | IMO linking to a dead actor should be an error whenever it is possible to do so |
| 05:19:01 | tarcieri | yeah |
| 05:19:18 | d2dchat leaves the room. | |
| 05:19:21 | tarcieri | I have Actor#dead? by the way... |
| 05:19:33 | rue | I hate it when that happens on IMDB |
| 05:19:41 | tarcieri | heh |
| 05:20:01 | MenTaLguY | tarcieri: Yeah, I'm relying on #notify_link to raise an exception if the actor is dead |
| 05:20:26 | tarcieri | I also have ActorError for Actor-related exceptions |
| 05:20:31 | MenTaLguY | tarcieri: hence the "local" notify_link was done after the remote one in my implementation of Actor#link given above |
| 05:20:41 | MenTaLguY | as do I, I think |
| 05:20:45 | tarcieri | Cool |
| 05:20:57 | MenTaLguY | it's not the _same_ ActorError though I guess |
| 05:21:01 | tarcieri | well, I'll make Actor#notify_link raise that if you attempt ot link to a dead Actor... |
| 05:21:06 | MenTaLguY | I'm not sure if that's an issue |
| 05:21:08 | MenTaLguY | yet |
| 05:21:24 | sudoer leaves the room. | |
| 05:21:27 | MenTaLguY | yes, do that for now |
| 05:21:37 | MenTaLguY | actually I think I have a DeadActorError subclass |
| 05:21:46 | MenTaLguY | (it's been so long since I've looked at the omnibus actor stuff :/) |
| 05:21:50 | tarcieri | heh |
| 05:22:08 | tarcieri | do you raise an error if you send a message to a dead actor? |
| 05:22:27 | tarcieri | I don't |
| 05:22:33 | MenTaLguY | I don't think I do either |
| 05:22:44 | tarcieri | it just goes into a black hole |
| 05:23:04 | MenTaLguY | I think in mine it still gets enqueued, that's probably not desirable |
| 05:23:10 | MenTaLguY | since the queue will never get emptied |
| 05:23:25 | MenTaLguY | (not that the distinction is visible to user code) |
| 05:23:39 | MenTaLguY | I should blackhole the mailbox on actor death |
| 05:23:46 | tarcieri | my Actor#<< checks if the recipient is dead and just returns if it is |
| 05:23:54 | MenTaLguY | I think that's as it should be |
| 05:24:32 | MenTaLguY | I'm starting to wonder if we should have a gem which provides the basic actor protocol stuff |
| 05:24:37 | MenTaLguY | basic exception classes and things |
| 05:24:39 | MenTaLguY | that we can all use |
| 05:24:46 | tarcieri | sure |
| 05:24:51 | MenTaLguY | it would be nice if everyone had the same ActorError |
| 05:24:56 | tarcieri | yeah |
| 05:25:08 | tarcieri | mine's class ActorError < StandardError; end |
| 05:26:28 | MenTaLguY | okay, I just released case-0.4 with the changes we discussed |
| 05:26:33 | MenTaLguY | including adding case/core |
| 05:26:35 | tarcieri | cool |
| 05:28:06 | tarcieri | hmm, guess I'll hope that the dispatching of system messages doesn't kill an Actor before it's able to process the link message |
| 05:28:35 | MenTaLguY | don't worry about it for now |
| 05:28:49 | MenTaLguY | just make sure that notify_unlink and notify_exit can't kill the caller :) |
| 05:28:54 | tarcieri | heh |
| 05:28:59 | tarcieri | yeah that too |
| 05:29:15 | tarcieri | anothe reason why sending messages to dead actors should silently fail |
| 05:29:33 | dewd enters the room. | |
| 05:29:34 | tarcieri | it all comes down to cases where you'd have to handle errors during error handling |
| 05:29:42 | tarcieri | and that just gets stupid |
| 05:29:53 | jtoy enters the room. | |
| 05:30:02 | tarcieri | if you're trying to notify another actor an error occured and that actor is dead, give up |
| 05:30:15 | MenTaLguY | I'm pretty chuffed about the prospect of having a standard actor object protocol |
| 05:30:21 | tarcieri | yeah |
| 05:30:23 | tarcieri | that'd be sweet |
| 05:30:28 | MenTaLguY | I was trying to make the omnibus stuff totally general, but it really messed up the library IMO |
| 05:30:37 | tarcieri | especially if it could be implemented on top of DRb |
| 05:30:39 | MenTaLguY | a lot of the complexity you commented on was from that |
| 05:30:45 | MenTaLguY | and it's not needed really |
| 05:31:01 | MenTaLguY | we can just have different libraries implementing the same object protocol for different uses |
| 05:31:11 | tarcieri | yeah |
| 05:31:24 | MenTaLguY | oh, by protocol I mean in the Smalltalk sense |
| 05:31:30 | tarcieri | I mean, I'm going to start moving my peer-to-peer thingy to Revactor tonight |
| 05:31:32 | MenTaLguY | akin to Java interfaces |
| 05:31:37 | tarcieri | and I want to run that on top of Ruby 1.9 now |
| 05:31:47 | tarcieri | but umm, down the road Rubinius is certainly my target |
| 05:31:53 | MenTaLguY | nods |
| 05:33:22 | MenTaLguY | argh, what's the -S equivalent for shotgun? |
| 05:33:28 | MenTaLguY | I'm suddenly drawing a mental blank |
| 05:33:52 | boyscout | 1 commit by Adam Gardiner |
| 05:33:52 | boyscout | * Fix Task#get_stack_value to not raise exception from primitive; 41f07f0 |
| 05:34:53 | MenTaLguY | never mind |
| 05:36:35 | MenTaLguY | tarcieri: thanks for picking up the actor stuff btw, I think I would have let it rot for quite some time otherwise |
| 05:37:12 | MenTaLguY | now I don't feel so guilty :) |
| 05:38:02 | boyscout | 2 commits by MenTaLguY |
| 05:38:03 | boyscout | * rebuild stable with Tuple#===; 73b4264 |
| 05:38:04 | boyscout | * structural Tuple#===; e23c72b |
| 05:40:19 | tmornini leaves the room. | |
| 05:40:32 | tarcieri | MenTaLguY: heh, well hopefully I can actually build some useful stuff on top of it |
| 05:41:55 | jtoy leaves the room. | |
| 05:44:06 | rue | Aargh this damn splatting and unsplatting is driving me nuts |
| 05:45:54 | MenTaLguY | tarcieri: hm, so do you have any other actor errors besides dead actors? |
| 05:46:14 | MenTaLguY | tarcieri: it seems in Concurrent, I only had DeadActorError rather than a general ActorError |
| 05:48:21 | squeegy leaves the room. | |
| 05:48:44 | tarcieri | yeah, but you probably have it implemented so you don't encounter them |
| 05:48:49 | rubuildius | MenTaLguY: 73b4264b6; 4451 examples, 16651 expectations, 71 failures, 2 errors; http://rafb.net/p/PEZnZP95.html |
| 05:48:49 | rubuildius | Adam Gardiner: 41f07f025; 4451 examples, 16798 expectations, 0 failures, 0 errors |
| 05:49:02 | kofno leaves the room. | |
| 05:49:14 | tarcieri | I raise ActorError if Actor.current is called outside "Actor world" :/ |
| 05:49:28 | MenTaLguY | I see |
| 05:49:45 | MenTaLguY | let's just define DeadActorError in the protocol then |
| 05:49:53 | tarcieri | ok |
| 05:50:12 | tarcieri | as a subclass of ActorError? |
| 05:50:22 | tarcieri | or do you not have an ActorError... |
| 05:50:26 | MenTaLguY | dunno, we'd need to include ActorError in the protocol then too |
| 05:50:30 | MenTaLguY | no, I don't actually at the moment |
| 05:50:34 | tarcieri | ok |
| 05:50:53 | MenTaLguY | I think I'll need to sleep on the exceptions-in-the-protocol thing |
| 05:50:59 | tarcieri | heh |
| 05:51:21 | MenTaLguY | something else I'm pondering is to have an (entirely abstract) module which an actor class can include to assert that it implements the protocol |
| 05:51:21 | tarcieri | yeah, I mean, it's already a problem for Rubinius |
| 05:51:44 | MenTaLguY | not really, I can do whatever to accomodate Rubinius |
| 05:52:06 | tarcieri | well, right now at least you can't serialize/unserialize an exception across VMs |
| 05:53:29 | MenTaLguY | that actually raises a general question |
| 05:53:43 | MenTaLguY | in terms of sending inter-VM messages, if you send something that doesn't serialize, who gets the resulting exception? |
| 05:53:54 | rue | brixen: Hm, semantics of #platform are a bit weird |
| 05:54:26 | drbrain | MenTaLguY: in DRb, if it can't be serialized, the sender gets the error |
| 05:54:39 | drbrain | and if it can't be unserialized, the reciever gets the error |
| 05:54:42 | tarcieri | that'd make the most sense |
| 05:54:46 | drbrain | I don't know if you have the latter issue |
| 05:54:50 | tarcieri | yes |
| 05:54:54 | tarcieri | definitely |
| 05:55:38 | drbrain | so, it would be up to the application to define what needs to happen when those things happen |
| 05:55:56 | d2dchat enters the room. | |
| 05:56:03 | MenTaLguY | yeah, the main thing is I guess the receive loop needs to be prepared for stuff that doesn't unserialize |
| 05:56:17 | tarcieri | yeah |
| 05:56:35 | tarcieri | in the inter-VM actor stuff I implemented, it'd actually be the thread reading messages off the inter-VM message queue |
| 05:57:05 | tarcieri | I have no idea how evan handles that... |
| 05:58:30 | unagi-san leaves the room. | |
| 05:58:32 | tarcieri | i.e. what happens when a VM receives a mesasge it can't unserialize |
| 05:59:04 | MenTaLguY | I guess ideally the message should be ignored |
| 05:59:14 | MenTaLguY | killing the VM is probably the other option :P |
| 06:00:16 | tarcieri | haha |
| 06:00:49 | tarcieri | yeah, or at least the Actor that was the intended recipient |
| 06:01:17 | tarcieri | that'd probably be the way to go about it |
| 06:07:11 | dbussink enters the room. | |
| 06:07:47 | ezmobius enters the room. | |
| 06:07:58 | tongueroo_ enters the room. | |
| 06:08:53 | drbrain | you may want to be able to tell the sender "WTF are you doing?" |
| 06:09:01 | defunkt enters the room. | |
| 06:09:07 | drbrain | or, you may want to load something so you can handle the message |
| 06:10:51 | tarcieri | it'd be great to have ActiveSupport-style const_missing |
| 06:10:52 | agardiner | evan: i'm going to update README_DEVELOPERS to include that primitives should not raise exceptions |
| 06:11:11 | tarcieri | that'd be closer to what Erlang does |
| 06:11:20 | jtoy enters the room. | |
| 06:11:21 | agardiner | but what is the rationale? |
| 06:11:38 | drbrain | I don't think you need it const_missing at the protocol level |
| 06:11:51 | tarcieri | well, initially bootstrapping a remote VM, but that can just be done with requires |
| 06:12:58 | dbussink | agardiner: hmmm, i did just that for fixing regexp |
| 06:13:05 | drbrain | I've never done dynamic loading with DRb, but I have found notification of missing classes useful for debugging |
| 06:13:12 | MenTaLguY | if you can't unserialize the message, you don't know which actor to give it to, I don't think? |
| 06:13:18 | dbussink | agardiner: or was that the reason for reconsidering? |
| 06:13:33 | MenTaLguY | if you did, it might make sense to give the recipient a special message which contained the unserialized message, I dunno |
| 06:13:35 | agardiner | yeah, it exists in a number of primitives, but evan wasn't happy... |
| 06:13:37 | tarcieri | MenTaLguY: well, my inter-VM protocol relied on Tuple, Fixnum, and Symbol |
| 06:13:57 | tarcieri | MenTaLguY: but yeah, I suppose the serialization would gib before you could even get that |
| 06:14:01 | dbussink | agardiner: ah ok, but what is the way to go to pass an error then? |
| 06:14:25 | drbrain | I'm not sure how many features the actor protocol has compared to DRb protocol |
| 06:14:28 | dbussink | agardiner: i already had to do something dirty to fix regexp new, because i wanted to extract the error message from onigurama |
| 06:14:50 | tarcieri | drbrain: linking is probably the biggest... |
| 06:15:03 | agardiner | return FALSE from the primitive, and raise the exception from Ruby-land in the code immediately following the Ruby.primitive |
| 06:15:20 | agardiner | i don't know how you are supposed to pass the error message though... |
| 06:16:09 | drbrain | agardiner: if you need to pass an error message, perhaps the primitive protocol needs to be expanded |
| 06:17:07 | emphatic enters the room. | |
| 06:17:10 | dbussink | agardiner: but we'll need a way of passing an error message in that case, like drbrain says |
| 06:17:18 | agardiner | i agree |
| 06:17:31 | MenTaLguY | primitives can put arbitrary stuff on the stack right? |
| 06:17:50 | MenTaLguY | seems like users of those primitives can expect an error message on the stack if the result was failure |
| 06:18:04 | agardiner | yes, but then the Ruby code following the Ruby.primitive is not executed |
| 06:18:17 | dbussink | could return the exception instead of false, maybe that's the way to go |
| 06:18:56 | agardiner | i think we need evan to suggest how this should work - i don't know the reasoning for why exceptions should not be raise from the C side |
| 06:19:48 | tarcieri | definitely need evan to explain handling of non-unserializable messages between VMs |
| 06:19:59 | agardiner | dbussink: you must return FALSE to have the Ruby code executed following the primitive, and if you do return FALSE, you cannot use the stack |
| 06:20:12 | tarcieri | perhaps that could raise an error on the sending VM's side |
| 06:20:55 | rue | Phew. |
| 06:21:51 | rue | Primitives cannot currently use the stack if they return FALSE |
| 06:22:12 | rue | Ah, tarcieri beat me to it |
| 06:22:28 | agardiner | rue: do you know why primitives are not supposed to use cpu_raise*? |
| 06:22:36 | tim_w enters the room. | |
| 06:23:03 | dbussink | rue agreed in my current implementation of the regexp error handling, so i guess not ;) |
| 06:23:19 | rue | dbussink, agardiner: My suggestion has always been that primitives use normal exception handling semantics instead of the current unintuitive execute-rest-if-fail |
| 06:23:46 | rue | Presumably some technical detail |
| 06:23:49 | tongueroo leaves the room. | |
| 06:25:34 | agardiner | presumably... be nice to know what it is though, since i got a rap over the knuckles for doing it! :-S |
| 06:26:06 | rue | I never got more than 'no' so I dunno |
| 06:26:16 | rue | He should be back from boar hunting or wherever soonish |
| 06:27:08 | boyscout | 3 commits by Adam Gardiner |
| 06:27:09 | boyscout | * Add support for setting a context iseq directly; 7c4cbfa |
| 06:27:10 | boyscout | * Make cpu_compile_method reuse compiled byte_array; d3990cb |
| 06:27:11 | boyscout | * Fixed set_debugging to allow channels to be cleared; 60ce6ac |
| 06:28:52 | dbussink | but i'm off to work, will read up on this discussion later :) |
| 06:30:08 | headius | tarcieri: I can't imagine something that can be serialized but not deserialized would ever be useful, so that sounds like a bug |
| 06:30:28 | MenTaLguY | headius: well, it all depends on which classes exist at the sending and receiving ends, and how they're defined |
| 06:30:40 | tarcieri | yeah, exactly |
| 06:30:41 | MenTaLguY | headius: if both ends don't match you won't necessarily be able to deserialize |
| 06:30:43 | dbussink leaves the room. | |
| 06:30:59 | headius | I mean data that can't ever deserialize...like it's just not catching that it shouldn't be able to serialize |
| 06:31:20 | headius | obviously if you can't reconstitute the type on the other side it can't deserialize, but that's an application issue |
| 06:31:26 | tarcieri | what if you serialize an object whose class is defined in the local VM but not in the remote one? |
| 06:31:44 | tarcieri | particularly if the remote VM has just been booted and is effectively a blank slate |
| 06:31:53 | headius | nothing you can do |
| 06:32:03 | headius | you need to negotiate known types ahead of time |
| 06:32:05 | tarcieri | in the inter-VM message queue case |
| 06:32:12 | tarcieri | you can raise an exception in the sender |
| 06:32:34 | tarcieri | which can be done entirely with messaging |
| 06:33:01 | drbrain | headius: have you ever used DRb? |
| 06:33:05 | headius | the client has to listen on another message queue then |
| 06:33:08 | headius | drb isn't async |
| 06:33:10 | drbrain | headius: you don't need to negotiate anything |
| 06:33:23 | headius | drb is a synchronous RPC call |
| 06:33:31 | headius | er, RPC. |
| 06:33:34 | MenTaLguY | sure |
| 06:33:49 | MenTaLguY | but we're talking about an asynchronous message thing built on Marshal |
| 06:33:54 | tarcieri | yeah |
| 06:33:55 | MenTaLguY | a lot of the same considerations apply |
| 06:33:57 | tarcieri | what'd really be useful |
| 06:33:59 | headius | yes |
| 06:34:10 | headius | don't serialize stuff that might not exist on the other side |
| 06:34:28 | headius | that's why most message queueing systems only allow sending integral types |
| 06:34:30 | headius | strings, numbers, maybe lists |
| 06:34:33 | drbrain | I don't see how that's useful |
| 06:34:40 | tarcieri | yeah |
| 06:34:53 | tarcieri | I've wanted a restricted subset of objects for messaging |
| 06:35:07 | headius | that's the way this generally gets solved |
| 06:35:22 | headius | if you want to be able to dump more complex objects you need to do the footwork yourself |
| 06:35:27 | agardiner leaves the room. | |
| 06:35:40 | tarcieri | for now I had VMActor.spawn accept symbols |
| 06:35:57 | tarcieri | Which effectively feigned the apply() that Erlang's call to a remote node does |
| 06:36:09 | drbrain | if we've got a high-level language, why limit ourselves to such low-level communication? |
| 06:36:26 | headius | drbrain: high level communication is built on low-level communication |
| 06:36:41 | tarcieri | drbrain: to avoid precisely these sorts of errors |
| 06:36:43 | evan | drbrain: what happens to DRb when you send an object of a class that the remote side doesn't have? |
| 06:36:48 | rue | Hah, I really need to work on these description strings |
| 06:37:01 | rue | headius: http://pastie.org/141779 bottom is the more interesting part to you |
| 06:37:07 | headius | you can certainly build a more robust protocol on top of an async message system |
| 06:37:11 | drbrain | I will double-check |
| 06:37:21 | tarcieri | evan: what happens with the inter-VM message queues if the recipient VM can't unserialize the message? |
| 06:37:35 | headius | but I'd strongly advise against trying to make the message queue try to do all that for you...build on something simple |
| 06:37:37 | evan | can't happen. |
| 06:37:51 | evan | tarcieri: because the sender will get an error |
| 06:37:55 | tarcieri | awesome |
| 06:38:10 | headius | so it's not async then? |
| 06:38:11 | tarcieri | okay, one less headache to worry about |
| 06:38:12 | rubuildius | Adam Gardiner: 7c4cbfaf1; 4451 examples, 16651 expectations, 71 failures, 2 errors; http://rafb.net/p/MPyyBi84.html |
| 06:38:27 | evan | headius: completely async. |
| 06:38:39 | headius | how can it be completely async and still give an error responds from the sender |
| 06:38:46 | evan | but because it goes through the VM, ie, using one serialization/unserialization mechanism |
| 06:38:57 | headius | that's not async, it's waiting for a result |
| 06:39:05 | rue | Uh-oh, that is not good |
| 06:39:16 | d2dchat leaves the room. | |
| 06:39:16 | evan | nothing is waiting. |
| 06:39:29 | rue | Like super-not good |
| 06:39:30 | headius | that means every message send will wait for the target VM to respond |
| 06:39:41 | evan | headius: you aren't listening to what i'm saying at all. |
| 06:39:46 | headius | well, explain it |
| 06:39:47 | evan | i have no clue what you're saying. |
| 06:40:07 | headius | if the caller tries to serialize an object type that doesn't exist on the target, what happens |
| 06:40:08 | evan | the sender gives the VM a message |
| 06:40:10 | evan | it returns |
| 06:40:16 | evan | at some time in the future |
| 06:40:24 | evan | the receiver asks the VM for the message |
| 06:40:26 | evan | and gets it. |
| 06:40:32 | headius | so it's two async pipes |
| 06:40:41 | headius | that's synchronous |
| 06:40:45 | evan | omg. |
| 06:40:51 | headius | you ask for the result |
| 06:41:10 | tarcieri | it's only synchronous if the sender blocks waiting for a response |
| 06:41:26 | tarcieri | I think what headius is asking is how does the sender know the recipient can successfully unserialize the message |
| 06:41:41 | evan | because the mechanism only supports the basic types currently. |
| 06:42:12 | MenTaLguY | that's all you needed to say, evan :) |
| 06:42:14 | mediogre enters the room. | |
| 06:42:43 | tim_w leaves the room. | |
| 06:43:28 | evan | atm. |
| 06:43:30 | evan | it's a hack. |
| 06:43:31 | tarcieri | that's certainly fine for now |
| 06:44:03 | drbrain | damn you IPv6 |
| 06:44:25 | evan | drbrain: get IPv4 to give it a talking to. |
| 06:46:04 | headius | heh |
| 06:46:06 | evan | so, we're still having a problem with LongReturnException |
| 06:46:07 | evan | right? |
| 06:46:07 | headius | well there you go |
| 06:46:13 | headius | integral types |
| 06:47:27 | headius | my only point was that if it's asynchronous, you can't know you've send something that can't be received until sometime later |
| 06:47:49 | MenTaLguY | I ... don't think anyone was arguing with that |
| 06:48:00 | tarcieri | the problem is how to deal with that |
| 06:48:01 | rue | I was |
| 06:48:11 | headius | evan said the sender would get an error |
| 06:48:17 | headius | it would not...unless it explicitly asked for a result |
| 06:48:31 | tarcieri | the sender gets an error because the sender can only serialize what the recipient can receive |
| 06:48:32 | headius | ...or if only integral types could be serialized in the first place |
| 06:48:35 | evan | it gets a serialization error. |
| 06:48:46 | evan | that has nothing to do with the receiver getting the message |
| 06:48:50 | tarcieri | if the sender can serialize something ther recipient can't receive that will have to be dealt with in the future |
| 06:48:59 | headius | because it's limited to integral types, like I suggested above |
| 06:49:03 | headius | that's perfectly fine |
| 06:49:12 | tarcieri | that's definitely the best way to deal with it |
| 06:49:14 | headius | tarcieri: exactly |
| 06:49:30 | tarcieri | s/best/most foolproof/ |
| 06:49:42 | headius | so composite types would require more footwork to deal with in an async system, since you would be able to toss stuff on the queue that the receiver might not be able to handle |
| 06:50:11 | tarcieri | the problem with dealing with errors in an async system is there's nothing on the receiver's side that could really handle the error without knowledge of the sender |
| 06:50:33 | MenTaLguY | if we've pushed the problem out to the actor protocol, I'm not sure there's really a huge problem |
| 06:51:00 | MenTaLguY | an un-deserializable message is just one that the receiver isn't filtering for (and will never filter for) |
| 06:51:02 | headius | that's fine too...something on top of the queue that negotiates or makes guarantees about available types on either side |
| 06:51:04 | tarcieri | yeah, so long as the message could unserialize to the point you knew the sending actor |
| 06:51:15 | tarcieri | then you could just send an error back to it |
| 06:51:24 | MenTaLguY | so you could safely discard an un-deserializable message |
| 06:51:33 | evan | if you want to support any object |
| 06:51:35 | headius | tarcieri: most message queueing systems I've used can be used such that they will deliver a partial envelope if they can't deliver the whole message |
| 06:51:43 | tarcieri | headius: yeah |
| 06:51:46 | evan | you just add a layer on top of the current mechanism |
| 06:51:49 | rue | HEAD is pretty broken here, anyone else check? |
| 06:51:50 | tarcieri | perhaps the solution is a placeholder for unserializable objects |
| 06:51:54 | rue | rubuildius agrees. |
| 06:51:55 | evan | to describe the object in some capacity |
| 06:51:56 | tarcieri | err |
| 06:52:03 | tarcieri | non-unserializable |
| 06:52:08 | headius | evan: sure, serialize a marshaled dump as a string for example |
| 06:52:08 | MenTaLguY | rue: trying to make sure it's not my fault |
| 06:52:09 | tarcieri | whatever the proper terminology is there |
| 06:52:10 | tarcieri | garbage |
| 06:52:28 | headius | you can do plenty with just integral types |
| 06:52:34 | tarcieri | yes |
| 06:52:47 | sudoer enters the room. | |
| 06:54:16 | turtletime leaves the room. | |
| 06:54:16 | jtoy leaves the room. | |
| 06:54:24 | drbrain | evan: you get a DRb::DRbUnknown object |
| 06:54:32 | tarcieri | yeah |
| 06:54:34 | tarcieri | that makes sense |
| 06:54:35 | drbrain | #<DRb::DRbUnknown:0x1d2630 @buf="\004\bo:\006X\000", @name="X"> |
| 06:54:55 | evan | drbrain: gotcha |
| 06:55:05 | tarcieri | if you got that on the other side, then the thread that waits for inter-VM messages could see if the message object couldn't be unserialized |
| 06:55:12 | evan | drb has the concept of intergral types |
| 06:55:20 | evan | that it layers it's data stream on top of |
| 06:57:19 | MenTaLguY | rue: hm, ci passes for me except for the setpriority spec |
| 06:57:31 | jbarnette leaves the room. | |
| 06:59:14 | headius | perhaps the build machine choked |
| 07:00:13 | MenTaLguY | tarcieri: released case-0.4 btw, if I forgot to mention earlier |
| 07:00:21 | tarcieri | yeah, I saw, cool |
| 07:01:12 | rue | MenTaLguY: Might be the iseq thing |
| 07:03:31 | MenTaLguY | tarcieri: hm, I just had a perverse idea |
| 07:03:49 | tarcieri | What's that? |
| 07:03:59 | MenTaLguY | tarcieri: use omnibus actors (which are per-thread) to communicate between revactor "silos" |
| 07:04:06 | MenTaLguY | or something |
| 07:04:14 | MenTaLguY | actually I see a lot of flaws with the idea |
| 07:04:21 | tarcieri | thing about Ruby 1.9 is native threads don't win you jack |
| 07:04:25 | tarcieri | besides high speed I/O :) |
| 07:04:36 | tarcieri | there's the Global VM Lock |
| 07:04:54 | tarcieri | about the only good that comes of it is doing blocking system calls |
| 07:05:08 | MenTaLguY | threads still are pre-emptively scheduled however |
| 07:05:24 | MenTaLguY | so you have to think about thread-safety a bit more |
| 07:05:27 | tarcieri | yeah, true enough, but they can only switch when Ruby decides to |
| 07:05:44 | MenTaLguY | revactor actors aren't actually safe to communicate cross-thread, are they? |
| 07:06:02 | tarcieri | not right now |
| 07:06:14 | tarcieri | the whole thing isn't thread-safe at all |
| 07:06:23 | MenTaLguY | I was thinking maybe using per-thread actors as intermediaries, rather than taking the performance hit to make revactor actors safe for direct cross-thread communication |
| 07:06:32 | tarcieri | yeah definitely |
| 07:06:37 | headius | thread safe would be slick |
| 07:06:38 | jtoy enters the room. | |
| 07:06:40 | tarcieri | that's certainly what should be done with Rubinius and inter-VM queues |
| 07:07:04 | tarcieri | it's what should've been done with the Erlang SMP scheduler but they have the weight of 100klocs of C code to deal with |
| 07:07:06 | MenTaLguY | I guess pretty much you have a layer of actors for each layer of the scheduling hierarchy |
| 07:07:18 | headius | could be done with native threads in JRuby as well, yes? |
| 07:07:39 | sudoer leaves the room. | |
| 07:07:52 | MenTaLguY | headius: Omnibus actors cover the JRuby case pretty well I think |
| 07:07:57 | tarcieri | JRuby could use a thread pool and Actors would work across mutliple CPU cores per default |
| 07:08:01 | MenTaLguY | headius: we don't really have a layer lower than Thread there |
| 07:08:23 | tarcieri | that's what Scala does |
| 07:08:35 | MenTaLguY | Scala's design actually has some problems |
| 07:08:45 | MenTaLguY | aside from the whole explicit continuations thing |
| 07:09:12 | MenTaLguY | it depends on a heuristic for determining inactive actors that can fail catastrophically under high load |
| 07:09:46 | MenTaLguY | (mainly, if an actor doesn't check in every so often, it's assumed to be blocking, and more threads are spun up) |
| 07:10:07 | MenTaLguY | (but if the actor isn't responding because the system is heavily loaded, spinning up more threads just creates a nasty feedback loop...) |
| 07:10:32 | MenTaLguY | I don't think it's been a huge problem in practice, but those kinds of things keep me up at night :P |
| 07:11:25 | loincloth enters the room. | |
| 07:12:03 | tarcieri | Re/cl |
| 07:12:05 | tarcieri | geh |
| 07:12:28 | tarcieri | I really like the idea of the underlying concurrency primitive that Actors are based on having a purely user context |
| 07:12:30 | headius leaves the room. | |
| 07:12:32 | MenTaLguY | anyway, the JVM is eventually going to have to add support for something like Fibers, although there are a lot of subtle issues that would need to be addressed |
| 07:12:41 | tarcieri | yeah |
| 07:13:01 | headius enters the room. | |
| 07:13:13 | MenTaLguY | I might eventually look into getting into the JSR process for that actually |
| 07:13:19 | tim_w enters the room. | |
| 07:13:25 | MenTaLguY | but I'm going to need to think about it for another 9 months or so at least |
| 07:13:34 | MenTaLguY | before I even have a good idea |
| 07:13:54 | tarcieri | heh |
| 07:14:08 | MenTaLguY | I'm really not kidding, the issues around fibers are a lot harder than I thought |
| 07:14:22 | MenTaLguY | been thinking it through heavily since the last Fiber conversation on ruby-core |
| 07:14:45 | tarcieri | for the most part any time I ask about Fibers on ruby-core I receive no response |
| 07:14:47 | MenTaLguY | fibers are nearly what we want, but actually not quite what we want I think |
| 07:14:52 | tarcieri | the only responses I think I've seen were from you |
| 07:14:52 | tarcieri | heh |
| 07:15:12 | MenTaLguY | oh, yes |
| 07:15:12 | tarcieri | yeah, if Fibers were serializable or something |
| 07:15:14 | tarcieri | that'd be awesome |
| 07:15:17 | MenTaLguY | maybe not the last conversation |
| 07:15:23 | MenTaLguY | but the last conversation where matz chimed in |
| 07:15:31 | MenTaLguY | which was some months ago |
| 07:15:40 | headius leaves the room. | |
| 07:15:42 | MenTaLguY | I mean, last conversation about fibers where matz chimed in |
| 07:15:55 | MenTaLguY | well, serializable fibers is a whole other thing |
| 07:15:58 | ezmobius_ enters the room. | |
| 07:16:04 | MenTaLguY | I think maybe that'd be the wrong level of abstraction |
| 07:16:07 | headius enters the room. | |
| 07:16:18 | MenTaLguY | the fiber-like solution does need to be migratable across hardware threads, though |
| 07:16:24 | tarcieri | I think the Erlang SMP scheduler is the wrong level of abstraction |
| 07:16:24 | MenTaLguY | which is where an awful lot of subtle issues start to come in |
| 07:16:31 | tarcieri | yes, migration across hardware threads is the important point |
| 07:17:23 | MenTaLguY | the most basic issue is that, if you migrate a fiber from one thread to another, you have to have a policy in place that the VM can use to determine which fiber to make active instead in the original thread |
| 07:17:32 | tarcieri | in the end you want: a shared heap per CPU, used for message passing (and in Ruby's case much much more), but the ability to load balance Actors across CPUs |
| 07:18:07 | MenTaLguY | and setting up a generally-useful policy framework for fiber scheduling is Hard |
| 07:18:18 | tarcieri | without any global locks (beyond the trivial sort used for VM ID lookup) |
| 07:18:22 | MenTaLguY | and then there's the whole thread-local thing we got into |
| 07:18:27 | tarcieri | yeah |
| 07:18:29 | tarcieri | that's a clusterfuck |
| 07:18:49 | MenTaLguY | which has sort of convinced me that fibers, as such, are the wrong way to expose the functionality |
| 07:18:53 | tarcieri | making Threads and Actors play nicely is just... aggrivating |
| 07:19:07 | tarcieri | they're trying to do the same thing in the end |
| 07:19:13 | MenTaLguY | threads and fibers; actors aren't a big deal per se |
| 07:19:14 | tarcieri | and that's what makes it hard |
| 07:20:04 | MenTaLguY | yes |
| 07:20:38 | MenTaLguY | anyway, when I think I have a rough idea of how something fiber-like could be reasonably done on the JVM I'll blog about it |
| 07:20:52 | tarcieri | cool |
| 07:21:03 | headius | man, IO's a pain |
| 07:21:21 | MenTaLguY | I think it might involve something like inside-out fibers |
| 07:21:29 | headius | both to spec and to implement |
| 07:21:35 | MenTaLguY | where an additional abstraction is introduced to represent hardware threads, onto which one or more Java threads can be mapped |
| 07:21:48 | MenTaLguY | by default we get the existing one hardware thread to one java thread arrangement |
| 07:22:15 | MenTaLguY | but multiple java threads can be manually "scheduled" on the same hardware thread |
| 07:22:17 | MenTaLguY | something along those lines |
| 07:22:32 | tarcieri | so an M:N threading model |
| 07:22:42 | MenTaLguY | not as that term is normally understood |
| 07:23:00 | tarcieri | with thread affinity? |
| 07:23:05 | tarcieri | or rather, cpu affinity |
| 07:23:20 | MenTaLguY | for multiple java threads on a single hardware thread, they should not be scheduled pre-emptively with respect to one another |
| 07:23:29 | tarcieri | yeah |
| 07:23:30 | MenTaLguY | that way lies madness; you basically just end up fighting the OS scheduler's heuristics |
| 07:23:44 | MenTaLguY | and yeah, you may as well add an API for CPU affinity with this |
| 07:23:54 | MenTaLguY | though that introduces some more issues like memory locality and so forth |
| 07:24:10 | tarcieri | the thing I like about Revactor is it provides some of the same guarantees as having multiple heaps and immutable state |
| 07:24:11 | MenTaLguY | so if we're talking JSR CPU affinity should probably be a separate one |
| 07:24:48 | tarcieri | like any sequence of operations you perform is effectively atomic unless you make a call that calls Actor.receive underneath |
| 07:25:10 | MenTaLguY | that's a little orthogonal to not having shared state |
| 07:25:38 | tarcieri | at least you're guaranteed the shared state isn't being mutated except between Actor.receive calls |
| 07:25:40 | MenTaLguY | it's really just having very strong serialization guarantees |
| 07:26:39 | evan | I wonder where the JVM puts locks to keep objects from being internally corrupt |
| 07:26:58 | MenTaLguY | it doesn't |
| 07:27:05 | evan | ie, if you don't use a Mutex, the JVM doesn't crash because of contention |
| 07:27:30 | MenTaLguY | generally speaking it's all memory barriers |
| 07:27:46 | MenTaLguY | at least in terms of programmer-visible Java objects |
| 07:28:00 | evan | how do the memory barriers make it work? |
| 07:28:13 | tongueroo_ leaves the room. | |
| 07:28:15 | evan | if you write to an object you don't own, you take a global lock or something? |
| 07:28:18 | evan | or a thread lock |
| 07:28:23 | MenTaLguY | no, not at all |
| 07:28:42 | MenTaLguY | I was thinking memory barriers for things like the initialization of final properties |
| 07:28:48 | MenTaLguY | otherwise it doesn't |
| 07:28:51 | MenTaLguY | generally speaking |
| 07:29:15 | MenTaLguY | the bytecode verifier makes sure that you can't do something that would harm the VM |
| 07:29:20 | evan | if 2 threads write to an object at the same time, how does it keep from getting a corrupt object? |
| 07:29:42 | MenTaLguY | it doesn't |
| 07:29:49 | MenTaLguY | and your program may well crash |
| 07:29:53 | evan | so the JVM crashes? |
| 07:29:54 | MenTaLguY | although the VM shouldn't |
| 07:29:56 | MenTaLguY | no |
| 07:29:57 | evan | because the object is corrupt |
| 07:30:28 | MenTaLguY | the VM can't crash because of that though |
| 07:30:37 | MenTaLguY | (assuming no bugs in the VM...) |
| 07:31:16 | evan | how come? |
| 07:31:46 | MenTaLguY | because user code can't touch VM internals? |
| 07:31:50 | headius | class and object metadata is made safe |
| 07:31:57 | MenTaLguY | all user code can do is screw itself up |
| 07:31:59 | headius | but object fields and whatnot are just normal in-memory data |
| 07:32:20 | headius | the worse you'd get is an exception |
| 07:32:31 | evan | so, say, setting a field in an object is an atomic operation? |
| 07:32:35 | headius | nope |
| 07:32:45 | MenTaLguY | not atomic in the normal concurrency sense |
| 07:32:49 | headius | and long fields, for example, require two operations |
| 07:32:55 | headius | two 32-bit slots |
| 07:32:59 | MenTaLguY | but there's no possible operation that will result in an invalid reference |
| 07:33:03 | evan | how do you not get corrupt objects then? |
| 07:33:10 | MenTaLguY | you do end up with corrupt objects |
| 07:33:17 | MenTaLguY | just nothing that violates VM invariants |
| 07:33:21 | headius | you don't end up with objects corrupted as far as the VM is concerned |
| 07:33:34 | evan | hm. ok. |
| 07:33:53 | MenTaLguY | all the VM needs to ensure is that whatever you do you can't do something to an object that results in a reference property pointing to an invalid object |
| 07:34:20 | evan | true, true. |
| 07:34:21 | evan | hm... |
| 07:34:21 | MenTaLguY | which is generally pretty easy as references are word-sized and word-sized stores are "atomic" inasmuch as the have "all-or-nothing" visibility to particula reads |
| 07:34:23 | headius | an in general it's impossible to get such an object in bytecode |
| 07:34:29 | evan | well, that's good news |
| 07:34:41 | evan | because that means, when the time comes, it will be easier to get native thread support into rubinius |
| 07:34:48 | headius | plus there's a verification phase that guarantees you're not shoving an int into a reference or something |
| 07:35:02 | headius | that's part of the startup hit, it verifies bytecode on startup |
| 07:35:03 | evan | since it should be easy to keep that invariant as well |
| 07:35:09 | tongueroo enters the room. | |
| 07:35:10 | headius | to guarantee it can't do illegal things |
| 07:35:12 | evan | since, like java, we'd field based at the base. |
| 07:35:25 | evan | er. we're field based. |
| 07:36:45 | headius | where you may have more trouble is areas the JVM disallows things Ruby allows |
| 07:36:56 | headius | like calling instance methods during object construction |
| 07:37:04 | MenTaLguY | yes |
| 07:37:14 | MenTaLguY | well, the JVM doesn't disallow that strictly |
| 07:37:23 | MenTaLguY | it's just, how you say... strongly discouraged |
| 07:37:23 | evan | bytecode verification is mainly making sure that indexes into the constant array are ok |
| 07:37:27 | evan | yes? |
| 07:37:27 | headius | the verifier doesn't allow it |
| 07:37:29 | headius | it will catch it |
| 07:37:42 | headius | or the javac compiler, I forget which |
| 07:37:56 | MenTaLguY | headius: hm, I think you can still "escape" a reference to the object from its constructor though |
| 07:38:04 | MenTaLguY | headius: at which point some bets are off |
| 07:38:06 | headius | evan: that and a lot more |
| 07:38:19 | MenTaLguY | headius: still nothing that can crash a VM, but you can get final fields with inconsistent values |
| 07:38:40 | MenTaLguY | evan: the verifier basically does a "proof-of-safety" |
| 07:38:47 | headius | remember it's also verifying types are as expected, stack depths are consistent for all paths through a method, explicitly scoped variables are controlled |
| 07:39:14 | headius | verifier also does some early footwork to determine where frame boundaries are necessary |
| 07:39:28 | headius | like for entering try/catch sections and such |
| 07:39:44 | MenTaLguY | headius: the "escape" issue was why I asked about whether initialize was called from the Java constructor or not (if it had been, we'd have a major issue since it is fairly common practice in Ruby to assign references to self from intiialize) |
| 07:40:39 | MenTaLguY | Rubinius has things easier in some ways |
| 07:40:57 | MenTaLguY | than it might |
| 07:41:02 | evan | yeah |
| 07:41:05 | MenTaLguY | since in Ruby, everything is an object reference |
| 07:41:15 | MenTaLguY | so you don't have quite the same concerns about validity |
| 07:41:23 | headius | initialize definitely isn't called from Java constructor |
| 07:41:29 | headius | initialize is more akin to allocate |
| 07:41:30 | evan | more dynamic means less verification. |
| 07:41:31 | headius | er |
| 07:41:54 | MenTaLguY | headius: yes, you had answered my question at the time :) |
| 07:41:58 | headius | I mean constructor is more akin to allocator |
| 07:41:59 | headius | ok |
| 07:42:19 | headius leaves the room. | |
| 07:42:26 | MenTaLguY | anyway, the main thing is you just need to disallow anything that could create an object reference from "whole cloth" |
| 07:42:35 | MenTaLguY | without checking in with the GC first |
| 07:42:39 | headius enters the room. | |
| 07:43:02 | MenTaLguY | (well, ideally it should not allow creating an object reference from "whole cloth" altogether, but then there's id2ref...) |
| 07:43:03 | evan | thats pretty easy |
| 07:43:30 | evan | SET_FIELD right now compiled into the same as setting a word in a struct |
| 07:43:36 | evan | then calling the write barrier function |
| 07:43:44 | headius | more dynamic also means less information |
| 07:44:07 | MenTaLguY | a lot of the security proofs the JVM doesn won't be possible for Rubinius |
| 07:44:17 | emphatic leaves the room. | |
| 07:44:38 | emphatic enters the room. | |
| 07:44:43 | MenTaLguY | yeah, you probably don't actually want a write barrier for every SET_FIELD though |
| 07:44:46 | MenTaLguY | not good for performance |
| 07:45:07 | headius | you can always look at the hotspot source |
| 07:45:09 | MenTaLguY | as long as your writes are word-sized and you're writing valid, aligned, values, you should be okay |
| 07:45:10 | evan | the problem is knowing when you don't need it. |
| 07:45:26 | headius | it's extensive, but it's very clean C++ |
| 07:45:32 | headius | extensively commented |
| 07:45:42 | pkondzior enters the room. | |
| 07:45:45 | MenTaLguY | well, basically if you want decent performance you will need to have barriers only when requested |
| 07:45:56 | MenTaLguY | and a decent memory model |
| 07:45:58 | evan | openjdk made my eyes bleed. |
| 07:47:05 | MenTaLguY | for the JVM, declaring a field volatile is how you get read/write barriers for it |
| 07:47:25 | MenTaLguY | there are pros/cons to doing that versus having explicitly requested read/write barriers for individual operations instead |
| 07:47:35 | evan | the write barrier is for keeping the GC sane. |
| 07:47:42 | evan | i don't see how you could not run it all the time. |
| 07:48:03 | MenTaLguY | ah, well, quiescing threads so that the GC sees a sane picture is a whole other matter |
| 07:48:13 | headius | that gets into the black arts |
| 07:48:17 | MenTaLguY | the JVM runs things a lot looser generally |
| 07:48:31 | MenTaLguY | things are put into "safe points" only when the GC needs to inspect |
| 07:49:03 | MenTaLguY | otherwise it's a party in a can |
| 07:49:50 | MenTaLguY | and yes, as charlie says, there are some dark arts involved |
| 07:50:53 | headius | I met the JVM guys behind the concurrent mark-sweep collector |
| 07:51:09 | headius | most of them have long white beards and wild eyes |
| 07:52:09 | headius | entertaining guys though...when I described various complications I was having with the JVM memory model, they started suggesting C++ code I could write to fix it |
| 07:52:47 | MenTaLguY | evan: for your own purposes, probably you want to look at something simpler to start -- a stop-the-world collector which stops all but the collecting thread at safe points |
| 07:52:52 | headius | stop the world m/s would be more than fine |
| 07:53:19 | tarcieri | with MVM stop-the-world is just stop-the-VM too :) |
| 07:53:24 | headius | or finding a way to reuse someone else's black arts |
| 07:53:40 | headius | tarcieri: not if the heap is allocated in chunks |
| 07:53:42 | MenTaLguY | once all the threads are stopped at safe points, they will have flushed all their writes, so the GC can see a consistent picture |
| 07:53:44 | headius | they can collect independently |
| 07:53:54 | MenTaLguY | headius: I think that's what he meant? |
| 07:54:00 | headius | oh ok :) |
| 07:54:06 | tarcieri | heh |
| 07:54:36 | tarcieri | Erlang |
| 07:54:37 | tarcieri | geh |
| 07:54:50 | tarcieri | Erlang's garbage collector has a problem if you enable the SMP scheduler and the shared heap |
| 07:54:55 | headius | ok, I need to get these jruby changes committed |
| 07:54:58 | tarcieri | garbage collecting the shared heap does stop the world |
| 07:55:06 | headius | I think I'm starting to climb out of IO hell now |
| 07:55:14 | MenTaLguY | well hopefully we can do better here |
| 07:55:16 | tarcieri | s/shared heap/hybrid heap/ |
| 07:55:28 | tarcieri | yeah |
| 07:55:30 | headius | tomorrow I start reading through each IO method I haven't already studied and rewriting our versions |
| 07:55:47 | headius | I will continue writing up textual specs and try to put some specs together soon |
| 07:56:02 | _emphatic enters the room. | |
| 07:56:26 | emphatic leaves the room. | |
| 07:57:29 | headius | IO is going to be a serious pain to spec out completely |
| 07:57:36 | MenTaLguY | tarcieri: thinking about it more, I definitely think having per-thread actors for communicating between different revactor threads is the way to go; limit fiber-based actors to only communicate with other actors in their thread (including the local thread-based actor) |
| 07:57:47 | MenTaLguY | tarcieri: and the per-thread actors can communicate with one another |
| 07:58:14 | headius | rue: does mspec report guarded specs as failures yet? |
| 07:58:27 | MenTaLguY | tarcieri: you may be able to hide that behind the scenes as far as having inter-thread fiber-actor messages routed through thread-actors |
| 07:58:53 | tarcieri | MenTaLguY: I just want Actors running on multiple VMs that can communicate over high-speed message queues |
| 07:59:01 | rue | headius: No, almost done though |
| 07:59:12 | headius | ok |
| 07:59:12 | rue | As you can see the spec wording needed some work |
| 07:59:25 | headius | sure |
| 07:59:37 | headius | the rest of IO is going to be pretty harsh |
| 08:00:15 | tarcieri | MenTaLguY: you can start up a set of registered services on each VM, multicall the service on each VM, and reduce the response |
| 08:01:23 | tarcieri | I think you're pretty much SOL in Ruby without MVM |
| 08:02:08 | tarcieri | JRuby could do a thread pool like Scala, but that's pretty much it (and suffers from whatever problems you mentioned, apparently) |
| 08:02:28 | headius | JRuby has had MVM for quite a while |
| 08:02:31 | headius | MVM doesn't solve anything though |
| 08:02:50 | headius | same issues apply...if a VM goes away into la-la land, it's pretty hard to get it back |
| 08:02:55 | tarcieri | at least in the case of Rubinius, it solves having a (nearly) lock-free way to scale across CPUs |
| 08:03:00 | crafterm leaves the room. | |
| 08:03:28 | tarcieri | the whole N times faster on N CPUs schtick |
| 08:03:33 | headius | same logic will work in JRuby then |
| 08:03:42 | tarcieri | yeah |
| 08:03:46 | headius | require 'jruby'; ruby = org.jruby.Ruby.new_instance |
| 08:03:48 | headius | that's about it |
| 08:03:57 | tarcieri | can you send messages between VMs? |
| 08:04:04 | tarcieri | in a quasi-sane way? |
| 08:04:17 | tarcieri | like avoiding the network stack if at all possible |
| 08:04:32 | headius | there's nothing explicit right now...but you can do anything you could do from Java code |
| 08:04:47 | headius | it's just another object |
| 08:04:47 | gnufied leaves the room. | |
| 08:05:02 | gnufied enters the room. | |
| 08:05:20 | tongueroo leaves the room. | |
| 08:05:22 | tarcieri | well, I hardly remember Java anymore but I don't think you have anything better than TCP sockets to go with |
| 08:05:36 | headius | they can share threads also...i.e. if you call from one VM to another with the same thread, it will know which VM's objects it's manipulating for any given call |
| 08:05:44 | headius | like I say, they're just objects |
| 08:05:54 | tarcieri | VMs can share objects? |
| 08:05:57 | headius | you want to implement a message queue, construct one and they can both use it |
| 08:06:00 | MenTaLguY | threads can share VMs |
| 08:06:06 | tarcieri | *boggle* |
| 08:06:08 | headius | and VMs can share threads |
| 08:06:09 | pkondzior leaves the room. | |
| 08:06:29 | tarcieri | I find that concept strangely unsettling |
| 08:06:35 | headius | not at all |
| 08:06:40 | tarcieri | If you say so |
| 08:06:41 | tarcieri | Heh |
| 08:06:44 | tarcieri | I'd have to try it out |
| 08:06:45 | pkondzior enters the room. | |
| 08:06:50 | context | headius: its just like watching two people drive a car at high scpeeds |
| 08:06:50 | boyscout | 1 commit by Evan Phoenix |
| 08:06:51 | boyscout | * Fix double free(); 3ce36dd |
| 08:06:54 | context | .. amusing .. |
| 08:06:55 | context | ;) |
| 08:07:01 | headius | context: not quite |
| 08:07:38 | tarcieri | Java used to be such a strong advocate of immutable state |
| 08:07:41 | tarcieri | What happened? :/ |
| 08:07:44 | headius | for what you're doing you'd just want to spin it up in another thread and hook it up to whatever message passing logic you like |
| 08:08:14 | headius | imagine it like this...if in rubinius anything written in C you could call directly from Ruby |
| 08:08:16 | headius | that's JRuby |
| 08:08:31 | headius | so obviously there's nothing you can't do |
| 08:08:35 | MenTaLguY | put another way, a thread can only be "in" one VM at a time, by nature |
| 08:08:35 | tarcieri | yeah, that part's definitely cool |
| 08:08:35 | headius | and a lot you shouldn't |
| 08:08:55 | headius | MenTaLguY: yeah, that's more clear |
| 08:08:58 | MenTaLguY | even if it is shared by multiple VMs (in terms of being "bound" and having a java.lang.Thread identies in each of them) |
| 08:09:00 | tarcieri | MenTaLguY: do you explicitly send it to another thread, or is that magic? |
| 08:09:13 | tarcieri | s/thread/VM/ |
| 08:10:04 | MenTaLguY | you don't send it from outside |
| 08:10:16 | MenTaLguY | it has an object representing the other VM which it calls a method on to "enter" |
| 08:10:20 | MenTaLguY | very loosely speaking |
| 08:11:01 | headius | yes |
| 08:11:02 | MenTaLguY | from that stack frame in, stuff is happening in that other VM |
| 08:11:04 | headius | it's just another object |
| 08:11:22 | MenTaLguY | not too different from the way the JRuby VM is embedded in the Java one as an object, which was the example Charlie was working up to |
| 08:11:26 | tarcieri | MenTaLguY: so in the linking API... |
| 08:11:32 | tarcieri | Actor#trap_exit= ? |
| 08:12:18 | MenTaLguY | tarcieri: I guess. I think that's what I did in Concurrent |
| 08:12:33 | tarcieri | cool |
| 08:12:50 | TheVoice leaves the room. | |
| 08:13:10 | MenTaLguY | there are actually some subtle issues with that which I haven't worked out yet though |
| 08:13:12 | evan | wtf. |
| 08:13:17 | MenTaLguY | race conditions about the arrival of exit messages |
| 08:13:22 | evan | anyone seeing CI failures? |
| 08:13:46 | MenTaLguY | evan: buildbot's been seeing them on and off, but I've not been able to replicate them locally, and I don't think the buildbot's been reporting them consistently :/ |
| 08:13:53 | evan | k |
| 08:13:54 | drbrain | I got a sigbus... |
| 08:14:31 | MenTaLguY | tarcieri: thinking back, before I got distracted with other things, trap_exit was the last thing I was working on, I think |
| 08:14:35 | drbrain | ... and it was a fluke |
| 08:15:08 | MenTaLguY | tarcieri: generally speaking it's not actually safe to do anything with trap_exit while you're linked to another actor |
| 08:15:35 | MenTaLguY | since you don't know when an exit signal might come in and kill you (or not kill you, if killing was what you wanted) |
| 08:16:01 | MenTaLguY | tarcieri: so I was looking for a variation on exit trapping that wasn't so prone to races |
| 08:16:17 | tarcieri | MenTaLguY: well, I do, since I know I won't do any message processing until the next call to Actor.receive... |
| 08:16:53 | tarcieri | The whole coroutine approach gets rid of a lot of those sort of conditions |
| 08:16:56 | MenTaLguY | it's not so much the message processing as other actors sending |
| 08:17:06 | MenTaLguY | but yes, I think I understand why Erlang did that |
| 08:17:09 | tarcieri | No other Actor can send while the current process is running |
| 08:17:14 | MenTaLguY | they started out with the coroutine thing |
| 08:17:15 | tarcieri | s/process/Actor/ |
| 08:17:30 | MenTaLguY | yeah, I guess it is fine for what you're doing |
| 08:17:39 | tarcieri | yeah, but they can safely preempt due to segmented heaps and immutable state |
| 08:17:57 | MenTaLguY | well, actually they still don't escape the problem completely |
| 08:18:09 | MenTaLguY | not sharing mutable state isn't ultimate protection against races |
| 08:18:12 | evan | shit |
| 08:18:14 | rubuildius | Evan Phoenix: 3ce36ddbe; 4451 examples, 16651 expectations, 71 failures, 2 errors; http://rafb.net/p/7bh0s647.html |
| 08:18:16 | evan | i'm seeing lots of CI failures. |
| 08:18:19 | evan | and so is rubuildius |
| 08:18:22 | evan | sweet. |
| 08:18:23 | evan | :P |
| 08:18:33 | jbarnette enters the room. | |
| 08:18:35 | MenTaLguY | well, if you're seeing them then you can replicate them and see what's going on :/ |
| 08:18:42 | MenTaLguY | I've not been having much luck |
| 08:21:20 | rue | Yes, HEAD broke sometime in the last 5 hours. I am pretty sure it is the iseq change but I have not gotten around to looking into it. |
| 08:21:34 | MenTaLguY | let me make sure I've got a clean build |
| 08:21:40 | rue | I am going to bed. |
| 08:22:19 | MenTaLguY | what's weird is stuff like: |
| 08:22:19 | MenTaLguY | (12:48:48 AM) rubuildius: MenTaLguY: 73b4264b6; 4451 examples, 16651 expectations, 71 failures, 2 errors; http://rafb.net/p/PEZnZP95.html |
| 08:22:19 | MenTaLguY | (12:48:49 AM) rubuildius: Adam Gardiner: 41f07f025; 4451 examples, 16798 expectations, 0 failures, 0 errors |
| 08:22:22 | thehcdreamer enters the room. | |
| 08:22:24 | MenTaLguY | and then the next commit failed again |
| 08:23:09 | rue | evan: Need to figure out the correct way to pass the "exceptions" up from primitives unless you have a plan in place. |
| 08:23:41 | rue | evan: Also, if you can briefly summarise why it is bad/not possible to directly raise from primitives for posterity, it would be helpful |
| 08:23:44 | rue | Night. |
| 08:27:04 | MenTaLguY | 'night |
| 08:27:59 | evan | MenTaLguY: it was you |
| 08:28:04 | evan | you updated stable. |
| 08:28:07 | MenTaLguY | ahhh |
| 08:28:12 | MenTaLguY | un-'night |
| 08:28:20 | evan | it's fine. |
| 08:28:31 | evan | i need to figure out why the new stables are blowing things up |
| 08:28:35 | evan | it's because of LongReturnError |
| 08:28:53 | MenTaLguY | hm |
| 08:29:17 | MenTaLguY | Wish it were more consistent |
| 08:29:22 | MenTaLguY | ci passed for me again :/ |
| 08:29:47 | MenTaLguY | I'll let you work it out then |
| 08:30:20 | MenTaLguY | as long as it wasn't my Tuple#=== core change which is the reason I rebuilt stable I'll go get some sleep |
| 08:30:58 | MenTaLguY | 'night |
| 08:31:34 | pkondzior leaves the room. | |
| 08:35:48 | evan | we need better guidelines on when to update stable |
| 08:35:54 | evan | mentalguy did it for exactly the wrong reazon. |
| 08:35:57 | evan | reason |
| 08:37:00 | octopod enters the room. | |
| 08:39:23 | obvio_ enters the room. | |
| 08:39:46 | obvio171 leaves the room. | |
| 08:41:07 | jessop enters the room. | |
| 08:42:03 | shingara | rubinius can work with windows or not now ? |
| 08:42:08 | evan | not currently, no. |
| 08:42:11 | evan | eventually it will |
| 08:42:17 | evan | but we've had no windows people help out yet. |
| 08:42:26 | shingara | I understand |
| 08:42:46 | shingara | I don't know windows too, I use only with my job :( |
| 08:43:14 | ezmobius leaves the room. | |
| 08:43:26 | evan | ah |
| 08:45:09 | zimbatm enters the room. | |
| 08:47:02 | evan | bingo. |
| 08:47:06 | evan | found the LRE problem. |
| 08:48:13 | drbrain | LRE? |
| 08:48:18 | evan | LongReturnException |
| 08:48:36 | evan | the reason kernel is being running badly when compiled with stable. |
| 08:50:27 | drbrain | http://flickr.com/photos/drbrain/2211092461/ |
| 08:50:30 | drbrain | bunny! |
| 08:50:31 | zimbatm | hi ppl ! |
| 08:50:34 | ragge leaves the room. | |
| 08:50:57 | evan | drbrain: dinner! |
| 08:51:21 | drbrain | maybe for one |
| 08:53:00 | drbrain | http://flickr.com/photos/drbrain/2211073559/ |
| 08:53:05 | drbrain | more bunny! |
| 08:53:33 | drbrain | also, bunny stew pot: http://flickr.com/photos/drbrain/2211859170/ |
| 08:54:04 | evan | drbrain: where was that? |
| 08:54:21 | drbrain | Arches National Park |
| 08:54:37 | evan | nice |
| 08:54:39 | evan | arches rocks. |
| 08:55:08 | drbrain | if you go, you must, must, must do the firey furnace tour |
| 08:57:13 | drbrain | fiery |
| 08:57:15 | tarcieri | heh |
| 08:57:19 | tarcieri | that's a fun place to get lost |
| 08:57:21 | evan | i've been a few times. |
| 08:57:23 | drbrain | http://www.nps.gov/arch/planyourvisit/programs.htm |
| 08:59:52 | drbrain | tarcieri: next time I'm going to get lost back there for sure |
| 09:01:58 | drbrain | I need to see if I can make better iPhoto tools |
| 09:03:14 | obvio_ leaves the room. | |
| 09:04:35 | evan | bollocks. how to fix this.... |
| 09:05:07 | evan | LRE's are terminating too early |
| 09:05:10 | evan | headius: you around? |
| 09:05:22 | headius | just barely |
| 09:05:27 | evan | ok |
| 09:05:30 | evan | real fast |
| 09:05:35 | headius | visions of file descriptors dancing in my head |
| 09:05:49 | evan | two { return 1 } |
| 09:06:18 | evan | er. |
| 09:06:35 | headius | two! |
| 09:06:46 | evan | ok |
| 09:06:52 | evan | eql? calls each_with_index with a block. |
| 09:06:56 | evan | and does a return in that block |
| 09:07:03 | evan | which should cause eql? to return |
| 09:07:09 | headius | ok |
| 09:07:12 | evan | each_with_index calls each with a block |
| 09:07:17 | evan | calling yield inside it |
| 09:07:34 | evan | so the blocks are nested. |
| 09:07:42 | headius | I see where you're going |
| 09:07:57 | headius | how do you make it bubble out to the right height? |
| 09:08:05 | evan | the return gets caught by each, rather than by each_with_index |
| 09:08:07 | evan | yes |
| 09:08:22 | headius | it's easy...store the target method context in the jump |
| 09:08:29 | headius | compare it at each step |
| 09:08:44 | evan | the name of the method? |
| 09:08:49 | headius | I don't know how you would do that in Ruby code, but that's how it's done in JRuby |
| 09:08:50 | drbrain | more like catch/throw |
| 09:08:58 | evan | ok. |
| 09:09:02 | evan | what a bother. |
| 09:09:06 | headius | actually, we store a reference to the method itself |
| 09:09:22 | headius | or rather, the activation |
| 09:09:29 | headius | but that's not necessary |
| 09:09:37 | headius | each activation just needs a unique target |
| 09:09:50 | evan | actually |
| 09:09:52 | evan | the context is easier. |
| 09:10:08 | headius | yes |
| 09:10:16 | evan | let me think.... |
| 09:10:20 | headius | the block will execute inside the method's context, right? so just get the context and use that as the target |
| 09:10:28 | evan | yeah |
| 09:10:38 | evan | i think i'll need a push_home_context instruction |
| 09:10:47 | evan | i'll do it with methods for now. |
| 09:11:10 | evan | i KNEW my implementation was too easy. |
| 09:11:11 | evan | :) |
| 09:11:18 | headius | heheh |
| 09:11:28 | headius | well, at least it's not hard to repair this way |
| 09:11:48 | evan | yep. |
| 09:11:48 | headius | ruby does something similar I believe since iternode wraps calls |
| 09:11:59 | headius | iter evaluation checks whether it's supposed to come back "here" or not |
| 09:12:05 | evan | aah |
| 09:12:10 | evan | i was looking at that code |
| 09:12:12 | jbarnette leaves the room. | |
| 09:12:15 | evan | perhaps thats what I was seeing |
| 09:12:19 | evan | i didn't grok it |
| 09:12:19 | headius | right |
| 09:12:49 | headius | we just ditched that by having the target on the frame |
| 09:12:56 | headius | before we had to visit returns and such to have them point at the right containing iter |
| 09:12:56 | Arjen_ enters the room. | |
| 09:13:08 | headius | I think MRI does something similar still |
| 09:13:46 | headius | it's still on my to-do list to actually use the frame as the jump target |
| 09:13:52 | headius | artificial target right now |
| 09:14:37 | evan | sweet. |
| 09:14:40 | evan | i can do this all in ruby |
| 09:14:47 | evan | no compiler changes |
| 09:14:58 | evan | just change LongReturnException.=== to check the target |
| 09:15:05 | evan | and save the target when I create one |
| 09:15:27 | headius | eventually to be something lower-level I hope |
| 09:15:40 | headius | that's going to be super expensive for blocks passed deep into a call chain |
| 09:16:43 | headius | in jruby the target gets checked only in calls that have blocks, since those are the only ones that could reasonable generate a return jump targeted at the current method |
| 09:17:08 | evan | course |
| 09:17:11 | headius | try { call } catch (ReturnJump rj) { if rj.getTarget == context.currentFrame() ... } |
| 09:17:12 | evan | thats what happens now for rubinius |
| 09:17:20 | evan | the only time this is run is if a call has a block attached. |
| 09:17:28 | headius | ok |
| 09:17:43 | crafterm enters the room. | |
| 09:17:51 | headius | for us it's also a reference comparison too...so hopefully you can eliminate the === check at some point |
| 09:18:22 | evan | hm. |
| 09:18:29 | evan | i could use the equal and kind_of instructions. |
| 09:18:32 | headius | the slowest part for us is the Java exception-handling logic |
| 09:19:10 | headius | time for me to go though |
| 09:19:25 | evan | laters |
| 09:19:59 | jessop leaves the room. | |
| 09:24:13 | headius leaves the room. | |
| 09:24:28 | jessop enters the room. | |
| 09:33:11 | ezmobius leaves the room. | |
| 09:37:06 | jessop leaves the room. | |
| 09:44:13 | hornbeck leaves the room. | |
| 09:46:19 | boyscout | 1 commit by Jeremy Roach |
| 09:46:20 | boyscout | * implement more of Marshal.load; 7b4ef13 |
| 09:54:02 | ragge enters the room. | |
| 09:56:06 | Fullmoon enters the room. | |
| 09:57:00 | dodecaphonic enters the room. | |
| 09:58:17 | rubuildius | Jeremy Roach: 7b4ef1344; 4464 examples, 16665 expectations, 71 failures, 2 errors; http://rafb.net/p/vLsNeF74.html |
| 10:03:04 | loincloth leaves the room. | |
| 10:04:37 | VVSiz leaves the room. | |
| 10:05:31 | zimbatm | where do these failures come from ? |
| 10:08:32 | boyscout | 1 commit by Jonas Pfenniger |
| 10:08:33 | boyscout | * new Module#name benchmark.; 91e4b80 |
| 10:08:34 | dodecaphonic leaves the room. | |
| 10:09:07 | headius enters the room. | |
| 10:11:27 | _emphatic leaves the room. | |
| 10:12:39 | emphatic enters the room. | |
| 10:13:39 | jtoy leaves the room. | |
| 10:14:43 | zimbatm | 73b4264b62be7484d3ed8efe58081d605ba7c598 seems to be the culprit |
| 10:18:06 | rubuildius | Jonas Pfenniger: 91e4b8063; 4465 examples, 16675 expectations, 67 failures, 2 errors; http://rafb.net/p/lf7qWO70.html |
| 10:21:56 | VVSiz enters the room. | |
| 10:25:51 | zimbatm | are there some good tricks to debug a "field of non-reference" ? |
| 10:31:15 | headius leaves the room. | |
| 10:44:28 | wycats leaves the room. | |
| 10:51:30 | crafterm leaves the room. | |
| 10:54:27 | pkondzior enters the room. | |
| 11:36:28 | agardiner enters the room. | |
| 11:41:20 | scoopr leaves the room. | |
| 11:52:30 | boyscout | 1 commit by Adam Gardiner |
| 11:52:31 | boyscout | * Fix implicit declaration warning for module_set_const; ce1e2ab |
| 11:57:50 | kofno enters the room. | |
| 12:03:06 | rubuildius | Adam Gardiner: ce1e2ab89; 4465 examples, 16675 expectations, 67 failures, 2 errors; http://rafb.net/p/dq1xdu65.html |
| 12:09:35 | emphatic leaves the room. | |
| 12:23:00 | ragge leaves the room. | |
| 12:30:53 | radarek enters the room. | |
| 12:38:50 | agardiner leaves the room. | |
| 12:50:01 | ctennis enters the room. | |
| 13:06:56 | scoopr enters the room. | |
| 13:29:23 | gnufied leaves the room. | |
| 13:29:58 | skaar leaves the room. | |
| 13:32:56 | ragge enters the room. | |
| 13:34:28 | mad_phoenix enters the room. | |
| 13:37:14 | smartocci enters the room. | |
| 13:41:31 | octopod leaves the room. | |
| 13:45:20 | mad_phoenix leaves the room. | |
| 13:47:23 | crafterm enters the room. | |
| 13:48:46 | turtletime enters the room. | |
| 13:49:20 | pd leaves the room. | |
| 13:50:52 | Arjen_ leaves the room. | |
| 13:57:41 | jtoy enters the room. | |
| 14:05:46 | brainopia enters the room. | |
| 14:15:19 | dysinger leaves the room. | |
| 14:21:21 | Arjen_ enters the room. | |
| 14:24:47 | mad_phoenix enters the room. | |
| 14:32:41 | djwhitt enters the room. | |
| 14:33:24 | skaar enters the room. | |
| 14:39:46 | moofbong enters the room. | |
| 14:45:28 | wmoxam enters the room. | |
| 14:47:59 | Arjen_ leaves the room. | |
| 14:49:03 | crafterm leaves the room. | |
| 14:56:17 | ttmrichter enters the room. | |
| 15:00:53 | mad_phoenix leaves the room. | |
| 15:02:07 | mad_phoenix enters the room. | |
| 15:02:43 | Arjen_ enters the room. | |
| 15:06:24 | pate enters the room. | |
| 15:17:03 | twshelton leaves the room. | |
| 15:19:43 | brainopia_ enters the room. | |
| 15:22:44 | binary42 enters the room. | |
| 15:24:41 | _mutle leaves the room. | |
| 15:25:47 | moofbong leaves the room. | |
| 15:30:35 | RyanTM leaves the room. | |
| 15:30:48 | RyanTM_ enters the room. | |
| 15:32:20 | brainopia leaves the room. | |
| 15:32:22 | shafire enters the room. | |
| 15:33:46 | mutle enters the room. | |
| 15:37:16 | daikini enters the room. | |
| 15:39:09 | d2dchat enters the room. | |
| 15:41:02 | nicksieger_ enters the room. | |
| 15:42:41 | nro leaves the room. | |
| 15:45:46 | enebo enters the room. | |
| 15:49:01 | nicksieger leaves the room. | |
| 15:54:57 | moofbong enters the room. | |
| 15:58:27 | GMFlash leaves the room. | |
| 15:58:32 | GMFlash enters the room. | |
| 16:03:49 | pauldix enters the room. | |
| 16:09:40 | dean-ero leaves the room. | |
| 16:09:40 | rue leaves the room. | |
| 16:12:47 | rue enters the room. | |
| 16:12:47 | dean-ero enters the room. | |
| 16:13:30 | brynary_ enters the room. | |
| 16:15:25 | shafire leaves the room. | |
| 16:16:07 | octopod enters the room. | |
| 16:26:54 | headius enters the room. | |
| 16:31:09 | Arjen_ leaves the room. | |
| 16:32:41 | brynary leaves the room. | |
| 16:39:17 | turtletime leaves the room. | |
| 16:39:37 | Arjen_ enters the room. | |
| 16:44:34 | Arjen_ leaves the room. | |
| 16:49:07 | tizianobis enters the room. | |
| 16:49:21 | ragge leaves the room. | |
| 16:49:33 | enebo leaves the room. | |
| 16:51:21 | dbussink enters the room. | |
| 16:51:28 | crayz_ leaves the room. | |
| 16:52:46 | Arjen_ enters the room. | |
| 16:53:11 | tongueroo enters the room. | |
| 16:54:18 | crayz_ enters the room. | |
| 16:54:19 | tongueroo leaves the room. | |
| 16:54:37 | tongueroo enters the room. | |
| 16:57:43 | jtoy leaves the room. | |
| 16:58:25 | jtoy enters the room. | |
| 17:00:48 | tongueroo leaves the room. | |
| 17:02:14 | nro enters the room. | |
| 17:02:48 | tongueroo enters the room. | |
| 17:04:08 | chris2 enters the room. | |
| 17:04:08 | chris2 leaves the room. | |
| 17:09:26 | thehcdreamer leaves the room. | |
| 17:09:43 | pkondzior leaves the room. | |
| 17:11:06 | sudoer enters the room. | |
| 17:11:13 | mad_phoenix | is anybody else getting build failures? im getting "dyld: lazy symbol binding failed: Symbol not found: _ev_default_loop" |
| 17:11:18 | jtoy leaves the room. | |
| 17:16:00 | tizianobis leaves the room. | |
| 17:16:42 | zimbatm | mad_phoenix, there are a lot of spec errors and failures since yesterday but the build should work |
| 17:16:59 | zimbatm | try running `rake distclean` or `rake rebuild` |
| 17:18:56 | chris2 enters the room. | |
| 17:21:13 | lopex enters the room. | |
| 17:25:27 | mdmurray enters the room. | |
| 17:25:57 | jeremydurham enters the room. | |
| 17:31:25 | joachimm enters the room. | |
| 17:32:59 | jbarnette enters the room. | |
| 17:33:36 | sudoer leaves the room. | |
| 17:34:12 | jtoy enters the room. | |
| 17:37:25 | turtletime enters the room. | |
| 17:37:41 | RyanTM_ leaves the room. | |
| 17:37:53 | RyanTM__ enters the room. | |
| 17:39:32 | joachimm_ leaves the room. | |
| 17:43:42 | mad_phoenix | zimbatm: thanks, that worked. kinda seems like the rake tasks for building/cleaning are a bit of a moving target at this point ;) |
| 17:46:29 | kofno_ enters the room. | |
| 17:46:38 | kofno leaves the room. | |
| 17:50:29 | essoepp enters the room. | |
| 17:52:22 | dgtized | alright so who broke the build? |
| 17:52:36 | djwhitt | don't know |
| 17:52:38 | dgtized | or at least drastically increased the number of bin/ci errors |
| 17:52:40 | djwhitt | I was wondering the same thing |
| 17:52:40 | Defiler | rubuildius needs more finger-pointing |
| 17:53:01 | Defiler | 7c4cbfaf1 appears to be the first one that had failures |
| 17:53:11 | Defiler | wait, no. 73b4264b6 |
| 17:53:21 | benny | "It was you, commit 73b42... who did all this!" |
| 17:54:02 | Defiler | Yeah, 73b4264b6 was a replacement of the stable runtime archives |
| 17:54:05 | Defiler | Which is risky at best |
| 17:54:32 | dodecaphonic enters the room. | |
| 17:55:17 | dgtized | hmm, should we just revert the archives? |
| 17:57:07 | Defiler | Seemingly, yeah |
| 17:57:13 | RyanTM__ leaves the room. | |
| 17:57:53 | RyanTM__ enters the room. | |
| 17:57:58 | boyscout | 1 commit by Wilson Bilkovich |
| 17:57:59 | boyscout | * Revert "rebuild stable with Tuple#==="; 9074bc1 |
| 18:04:33 | probablycorey enters the room. | |
| 18:04:43 | tarcieri | Tuple#=== eh? |
| 18:07:20 | rue | Morning |
| 18:08:24 | rubuildius | Wilson Bilkovich: 9074bc1ce; 4465 examples, 16821 expectations, 0 failures, 0 errors |
| 18:10:31 | dgtized | excellent |
| 18:11:26 | VVSiz | a question about String#to_f recently added spec... it verifies that "-".to_f --> -0.0 |
| 18:11:39 | VVSiz | JRuby doesn't do that, MRI 1.9 doesn't do that either |
| 18:12:33 | VVSiz | and "-" is not really a number indeed :) |
| 18:12:34 | tarcieri | heh negative zero |
| 18:12:38 | jeremydurham | MRI seems to |
| 18:12:49 | Arjen_ leaves the room. | |
| 18:13:05 | jeremydurham | "-".to_f => -0.01 ... ruby -v => ruby 1.8.6 |
| 18:13:12 | VVSiz | jeremydurham: only for MRI 1.8.6, bun *not* for MRI 1.9 |
| 18:13:13 | jeremydurham | er .. -0.0 .. you get the idea :) |
| 18:13:40 | jeremydurham | so it should be wrapped as being 1.8 and rubinius only. non jruby, non 1.9? |
| 18:13:47 | rue | No |
| 18:14:02 | VVSiz | so the rule it seeems that if the value is not understood, then 0.0 is returned. "-" is not understood by Jruby, MRI 1.9 |
| 18:14:04 | rue | "-".to_f.class.should == Float |
| 18:14:15 | rue | That is it |
| 18:14:54 | probablycorey leaves the room. | |
| 18:14:59 | jeremydurham | It seems pointless either way. You've seen actually code that does "-".to_f? :) |
| 18:15:36 | probablycorey enters the room. | |
| 18:16:45 | rue | I have seen code that does str.to_f, yes |
| 18:17:54 | jeremydurham | but didn't you just paste "-".to_f.class.should == Float ... doesn't that say, "-" to_f should be a float, not that any string to f should be a float? |
| 18:19:06 | jeremydurham | sorry, just being a pain :) |
| 18:19:08 | VVSiz | the actual spec is a bit more complicated: (1.0 / "-".to_f).to_s.should == "-Infinity" |
| 18:19:42 | rue | What does IEEE say? |
| 18:20:09 | rue | jeremydurham: If "-".to_f is undefined, it should be specced as such |
| 18:20:59 | VVSiz | well, to me "-" is not a number at all. and to_f should just return 0.0, if the value is not understood |
| 18:21:20 | brixen | where are you seeing "-".to_f => -0.0 in rbx? |
| 18:21:28 | brixen | I'm a few behind head, but I get 0.0 |
| 18:21:37 | rue | VVSiz: If the value is not understood, it should fail |
| 18:22:03 | VVSiz | rue: not in this case. this is from ruby-doc: If there is not a valid number at the start of str, 0.0 is returned. |
| 18:22:19 | VVSiz | "This method never raises an exception." |
| 18:22:26 | brixen | yeah |
| 18:23:00 | jeremydurham | so, mri returns -0.0, rubinius and jruby return 0.0, which seems to be the same as what the docs suggest. What does 1.9 return? |
| 18:23:21 | VVSiz | MRI 1.9 return 0.0 |
| 18:23:32 | rue | Hm, interesting. "If there is no valid number at the START" |
| 18:23:32 | jeremydurham | so, where's the problem? :) |
| 18:23:43 | VVSiz | I"m not sure about rubinius though. It *was* returning 0.0, but maybe it was changed lately |
| 18:24:25 | VVSiz | jeremydurham: problem is in the spec that fails on JRuby, MRI 1.9 and possibly rubinius (but passes on MRI 1.8.6) |
| 18:24:26 | dbussink | did evan already come up with a good solution on how to prevent the throwing exceptions in primitives? |
| 18:26:03 | jeremydurham | VVSiz: so it sounds like that spec should be mri only or removed, and "corrected". It sounds like a bug in MRI 1.8.6; even the docs contradict it. |
| 18:26:34 | jeremydurham | oh, well, I guess unless you are one of those people who considers - a number ;) |
| 18:26:41 | VVSiz | agree. :) |
| 18:26:46 | evan | morning. |
| 18:27:08 | brixen | "-".to_f == 0.0 => true |
| 18:27:10 | brixen | that works for me |
| 18:27:13 | brixen | change the spec to that |
| 18:27:26 | brixen | *works in 1.8.6 p111 |
| 18:27:31 | VVSiz | OK |
| 18:28:30 | rue | Morning |
| 18:29:14 | tongueroo_ enters the room. | |
| 18:29:18 | rue | dbussink: Dunno, let us find out |
| 18:29:21 | rue | evan: *nudge* |
| 18:29:56 | evan | omg. |
| 18:30:02 | evan | so not happy about the Module#name diff. |
| 18:31:05 | rue | A benchmark? |
| 18:31:06 | boyscout | 1 commit by Vladimir Sizikov |
| 18:31:07 | boyscout | * Corrected String#to_f spec.; ef5f448 |
| 18:31:15 | evan | the one that removed the full name calculation from the VM |
| 18:31:21 | evan | i see absolutely no reason for that. |
| 18:31:36 | evan | i really don't like the whole idea of calculating the name like this at access time. |
| 18:31:46 | dbussink | i know it started with fixing some failing specs |
| 18:31:51 | probablycorey leaves the room. | |
| 18:31:55 | dbussink | but you should ask zimbatm about that |
| 18:32:32 | evan | why did headius commit it? |
| 18:32:36 | evan | did he do the work? |
| 18:32:42 | joachimm_ enters the room. | |
| 18:33:17 | rue | It is some git weirdness if you are looking at the ticket |
| 18:33:47 | rue | I did not read the patch but it should be possible to do at assignment, not access |
| 18:34:07 | probablycorey enters the room. | |
| 18:34:10 | evan | i'm looking in git |
| 18:34:14 | evan | and charles was the committer. |
| 18:34:20 | evan | did he commit a patch from lighthouse? |
| 18:34:23 | dbussink | zimbatm: you there? |
| 18:34:39 | evan | no matter. |
| 18:34:43 | evan | after I get LRE fixed |
| 18:34:49 | evan | i'm going to mildly revert it. |
| 18:34:53 | headius | I didn't commit anything |
| 18:35:06 | evan | http://git.rubini.us/?p=code;a=commitdiff;h=7cd9fce4908aaeea9a35e273a3f15ed7ee7aa783;hp=7b4ef13448 12faa76018ab41cc7fba97a3af8448 |
| 18:35:06 | dbussink | evan: but any suggestions on how we're gonna handle the exception throwing issue |
| 18:35:10 | wycats enters the room. | |
| 18:35:11 | evan | is someone masquerading as you? |
| 18:35:15 | headius | nope |
| 18:35:17 | rue | Admit it, it is your secret identity, headius |
| 18:35:20 | evan | dbussink: it's almost fixed. |
| 18:35:23 | headius | wasn't me |
| 18:35:37 | evan | so someone committed it as your name? |
| 18:35:43 | rue | To the zimbatmcave! |
| 18:35:45 | headius | beats me |
| 18:35:52 | tongueroo leaves the room. | |
| 18:35:52 | dbussink | evan: http://rubinius.lighthouseapp.com/projects/5089/tickets/116-fixes-to-module-name-module-const_set# ticket-116-10 |
| 18:36:24 | dbussink | apparently his git-format-patch was doing strange things |
| 18:36:33 | evan | why the fuck is he committing patchs from other people. |
| 18:36:52 | evan | anyway |
| 18:37:11 | evan | i'm not happy with the solution outlined by him. |
| 18:37:36 | jtoy leaves the room. | |
| 18:37:40 | VVSiz | but it's a nice trick to commit as headius! |
| 18:37:48 | headius | everyone wants to beme |
| 18:38:18 | headius | very peculiar git feature |
| 18:38:38 | evan | i know why git has that feature |
| 18:38:47 | evan | but people are supposed to be adding Signed-Off-By |
| 18:38:54 | evan | plus, you didn't write the patch in the first place |
| 18:38:58 | jtoy enters the room. | |
| 18:39:06 | headius | so you can commit as someone else? |
| 18:39:22 | headius | I didn't have anything to do with the patch, no idea how my name got on it |
| 18:39:30 | dbussink | yeah, if you use for example git-am |
| 18:39:34 | evan | we need to find out how he generated those patches |
| 18:39:43 | evan | they all say from Charles Nutter in them. |
| 18:39:47 | headius | sweet |
| 18:39:52 | headius | CSotW! |
| 18:40:06 | evan | this is not a CS you want your name attached to |
| 18:40:11 | headius | hah |
| 18:40:18 | headius | so it's not about volume? |
| 18:40:27 | evan | no |
| 18:40:32 | evan | it's about peer nominations. |
| 18:40:32 | headius | darn |
| 18:40:43 | VVSiz | :) |
| 18:40:44 | headius | heh, I'll never get one then :) |
| 18:41:00 | dbussink | goes hiding because of introducing a exception raise in primitives :P |
| 18:41:08 | VVSiz | another really funny spec: "Module#instance_method raises a TypeError if the given name is not a string/symbol" |
| 18:41:27 | VVSiz | guess what it verifies... it verifies that the method actually raises ArgumentError |
| 18:41:32 | headius | awesome |
| 18:41:45 | VVSiz | and it fails on MRI 1.8.6, MRI 1.9, JRuby, Rubinius :) |
| 18:42:08 | VVSiz | well, not Rubinius :) |
| 18:43:03 | rubuildius | Vladimir Sizikov: ef5f4489c; 4465 examples, 16821 expectations, 0 failures, 0 errors |
| 18:43:41 | evan | headius: so, i saw that Java adds cause to exceptions |
| 18:43:44 | evan | which is another exception |
| 18:43:52 | evan | i'm thinking highly about adding that to rubinius |
| 18:44:04 | evan | and write a small gem that adds the behavior for MRI |
| 18:44:44 | headius | yeah, that was added officially in Java 1.4 or so I think |
| 18:44:45 | daikini leaves the room. | |
| 18:44:52 | evan | yeah |
| 18:44:55 | headius | everyone ended up implementing their own exceptions to do it anyway |
| 18:45:01 | evan | yeah |
| 18:45:04 | evan | it's pretty nice |
| 18:45:08 | probablycorey_ enters the room. | |
| 18:45:18 | evan | and I run into that need pretty often which something moderately complicated |
| 18:45:21 | rue | brixen, headius: I need a better term. Say, with #platform_is :version, "if current matches and target does not.." |
| 18:45:23 | headius | default output also automatically walks cause until == null |
| 18:45:23 | evan | that i need to normalize an exception |
| 18:45:31 | rue | Specifically the "current" |
| 18:45:57 | headius | host |
| 18:48:20 | evan | I've thought of 2 new ways to do LRE properly |
| 18:48:20 | rue | Mm, yeah, it works.. then "platform" to specifically mean the OS/hardware side |
| 18:48:47 | headius | yeah |
| 18:48:50 | joachimm leaves the room. | |
| 18:48:50 | evan | headius: 1) rather than using the context to figure out the depth, create the exception before you do the call and put it in a temp local |
| 18:49:00 | evan | headius: then compare against it directly to figure out depth |
| 18:49:19 | evan | and 2) only generate the rescue code if you see a return in the block attached |
| 18:49:32 | evan | otherwise let it travel through without checking |
| 18:50:13 | zimbatm | evan, dbussink , I have 5 min |
| 18:50:30 | evan | zimbatm: 1) why do all your patches say they are from Charles Nutter |
| 18:50:32 | zimbatm | sorry for that headius patch, I did a git-revert and it too headius' name |
| 18:50:32 | headius | 1) sounds fine...for illustration I have a field on our frame called jumpTarget...same sort of thing |
| 18:50:35 | evan | how have you been generating them. |
| 18:50:46 | probablycorey leaves the room. | |
| 18:50:51 | evan | zimbatm: please don't do that from now on then. |
| 18:51:03 | evan | it is very confusing. |
| 18:51:12 | evan | 2) i'm not sold on the solution |
| 18:51:12 | zimbatm | evan, 1) sorry, it won't happen again, I know |
| 18:51:20 | evan | why did you remove all the name calculation code in the VM? |
| 18:51:43 | headius | 2) also fine, though you need to remember stupid eval |
| 18:51:57 | zimbatm | evan, 2) actually I have another proposition. Instead of calculating @name on access, write the full path, and add a primitive for const_set to avoid duplication |
| 18:52:07 | headius | foo { eval 'return' }...edge case I know |
| 18:52:21 | evan | hm. thats a bother. |
| 18:52:23 | Defiler | headius: Haha.. what even appens there? |
| 18:52:24 | zimbatm | evan, I just centralized and it seemed to be ok |
| 18:52:26 | headius | imagine a larger piece of eval logic based on dynamic locals |
| 18:52:41 | headius | it's not totally unlikely to see something like that |
| 18:52:53 | headius | Defiler: it returns like a bare return would |
| 18:53:00 | jero5 | VVSiz: i disagree that your last commit is a correction. :) "-".to_f == 0.0 and "-".to_f == -0.0, these both evaluate to true |
| 18:53:02 | evan | zimbatm: i don't like that either. |
| 18:53:05 | Defiler | nice |
| 18:53:10 | headius | ruby -e "def foo; yield; puts 'here'; end; def bar; foo { eval 'return' }; end; bar" => nothing outputs |
| 18:53:11 | evan | i'm not really a fan of the whole solution |
| 18:53:17 | evan | trying to calculate name on access. |
| 18:53:30 | evan | i think we need to do something totally different. |
| 18:53:34 | jeremydurham | jero5: 0.0 == -0.0 => true ? |
| 18:53:37 | evan | the current way seems like a terrible hack. |
| 18:53:56 | headius | calculating on access could potentially be un-threadsafe too |
| 18:54:09 | headius | I haven't seen the patch |
| 18:54:09 | jero5 | jeremydurham: yes |
| 18:54:09 | VVSiz | jero5: right, but (1.0/ "-".to_f) would evaluate to "Infinity" on some impls, and "-Infinity" on others. |
| 18:54:16 | zimbatm | evan, I was not sure either but my code got acked.. I'm still not really familiar with shotgun |
| 18:54:32 | evan | then you should not be doing those fixes. |
| 18:54:37 | evan | if you're not comfortable. |
| 18:55:11 | zimbatm | .. |
| 18:56:02 | evan | well |
| 18:56:06 | evan | lets move on. |
| 18:56:07 | enebo enters the room. | |
| 18:56:37 | evan | i'd like all the parts that touched shotgun revert |
| 18:56:39 | evan | reverted |
| 18:56:47 | evan | either you can or I can |
| 18:56:47 | zimbatm | evan, I agree with you, next time I'll ask for your review for shotgun changes |
| 18:57:02 | zimbatm | I must go in 2 min. |
| 18:57:06 | evan | i'll do it then. |
| 18:57:10 | zimbatm | thx |
| 18:57:50 | zimbatm | I'll try to come up with a better solution tomorrow and I'll submit it to you |
| 18:57:56 | evan | ok. |
| 18:58:19 | jero5 | VVSiz: would a platform guard fix it, or is it just that the same version of mri has different behavior on different platforms? |
| 18:58:21 | zimbatm | thx, sorry again |
| 18:58:26 | evan | no problem |
| 18:58:28 | evan | live and learn. |
| 18:58:40 | zimbatm | cu |
| 18:58:40 | boyscout | 1 commit by Vladimir Sizikov |
| 18:58:41 | boyscout | * Corrected Module#instance_method spec, it was failing on MRI/1.8/1.9/JRuby.; c1d5923 |
| 18:59:41 | VVSiz | jero5: the behavior is not properly specified anywhere, different impls behave differently, so there is on point in placing this into the "specs" then |
| 19:00:14 | mad_phoenix leaves the room. | |
| 19:00:21 | VVSiz | hmm, expect one CI failure after my last commit. rbx behavior is incorrect. |
| 19:02:09 | probablycorey_ leaves the room. | |
| 19:02:24 | mad_phoenix enters the room. | |
| 19:02:34 | rue | brixen, headius: http://pastie.org/141991 bottom part has the new logic. Does it look sane? |
| 19:03:39 | probablycorey enters the room. | |
| 19:03:42 | rue | brixen: It does also have :version => '> 1.8.5' etc. support although we probably will not need it much |
| 19:04:06 | headius | looks good to me |
| 19:04:51 | rue | So the platform-specific stuff should not be considered a failure since those are (hopefully) legit differences |
| 19:06:05 | headius | yeah |
| 19:06:08 | headius | good to differentiate |
| 19:06:18 | headius | direct compliance failures are what most people want to know about anyway |
| 19:06:21 | enebo_ enters the room. | |
| 19:06:57 | yipstar enters the room. | |
| 19:07:19 | enebo_ leaves the room. | |
| 19:08:05 | rubuildius | Vladimir Sizikov: c1d59239d; 4465 examples, 16821 expectations, 1 failure, 0 errors; http://rafb.net/p/lekx5h72.html |
| 19:09:32 | headius | ka-ping! |
| 19:09:34 | rue | headius: Oh, I had one remaining TODO there. #deviates_on should probably fail if neither matches |
| 19:10:43 | pd enters the room. | |
| 19:10:59 | rue | headius: But the balancing concern was whether we want to report just in relation to the current host or overall |
| 19:11:29 | headius | so are you trying to make it so you can pretend to run for a specific platform? |
| 19:12:35 | headius | what do you mean "if neither matches" |
| 19:12:35 | rue | It is possible to do, yeah. MSpec just uses constants and rbconfig to determine the 'host' and those can be overridded (which is how I wrote the specs) |
| 19:13:06 | headius | well, but the target impl isn't going to care about that |
| 19:13:07 | rue | Say you run on JRuby, and encounter deviates_on(:some_other_impl) do ... end |
| 19:13:22 | headius | on unix JRuby's going to act like JRuby all the time |
| 19:13:26 | rue | Should that fail always or just when on some_other_impl |
| 19:13:49 | headius | oh, so you want to be able to selectively turn those things on to see how they actually differ, yes? |
| 19:14:03 | headius | so run on MRI with rubinius guards enabled to see what's actually differing |
| 19:14:06 | rue | headius: Sure, there is nothing we can do about how the system *actually* works. Prentending only goes so far |
| 19:14:28 | jtoy leaves the room. | |
| 19:14:33 | headius | that I get |
| 19:15:06 | rue | You could do a 'rbx test' when running on MRI but it would probably barf in some of the specs. But the guards would work according to whatever they are told the host is |
| 19:16:02 | rue | However, if you just run plain JRuby, identifying as such, and encounter that #deviates_on, I am not quite sure if that should be reported or not |
| 19:17:01 | headius | under normal exection I think deviates on (other platform) should just be ignored |
| 19:17:09 | zimbatm leaves the room. | |
| 19:17:43 | headius | I could see there would be two other modes of execution: 1) strict compliance, where deviates_on not matching will be a failure, and pretending, where deviates_on (specific impl we're pretending to run) would actually run |
| 19:17:55 | headius | er, 2) pretending... |
| 19:18:47 | rue | Right, so by default we would go more from the approach of how this platform complies rather than how the specs generally comply |
| 19:19:00 | headius | yes |
| 19:19:16 | headius | that will be by far the most interesting scenario |
| 19:19:40 | rue | Alright |
| 19:20:04 | rue | SpecTargetFailures strike sort of a middle ground |
| 19:20:49 | rue | For example if our target is :ruby, then saying not_compliant_on :ruby do .. end is a target failure (as opposed to a compliance failure) |
| 19:22:10 | headius | ok, I think :) |
| 19:22:21 | thehcdreamer enters the room. | |
| 19:22:24 | pauldix leaves the room. | |
| 19:22:24 | probablycorey leaves the room. | |
| 19:23:11 | enebo leaves the room. | |
| 19:23:19 | rue | The logic was a pain :P |
| 19:23:25 | brixen | rue: I don't want any ">< ..." etc |
| 19:23:37 | brixen | rue: 1. we're only spec'ing the current stable version of ruby |
| 19:23:48 | brixen | rue: 2. those are too easy to abuse and mask stuff |
| 19:24:09 | probablycorey enters the room. | |
| 19:24:52 | rue | I do not think they are useful for us, no |
| 19:26:19 | brixen | rue: it's kind of a bitch because so far no one from ruby core will work with us on the specs |
| 19:26:48 | brixen | rue: so essentially this is the situation, they change behavior, we spec it, and we conform or deviate |
| 19:27:01 | brixen | but either way, there is only one official ruby behavior: the most recent stable release |
| 19:27:17 | headius | I think we need to allow for multiple descriptions for each spec |
| 19:27:38 | brixen | ENOPARSE |
| 19:27:42 | headius | it :english => "foo", :japanese => "bar", :turkish => "yahoo" do |
| 19:27:43 | headius | :) |
| 19:27:56 | brixen | of course, my bloodsugar is at bottom |
| 19:28:00 | brixen | lunch, bbiab |
| 19:28:22 | Defiler | it :english => "foo", :日本語 => "blah" |
| 19:28:31 | evan | ha! |
| 19:28:32 | Defiler | If we want to get 'serious' about it, headius. Heh |
| 19:28:34 | evan | japanese symbol. |
| 19:28:35 | evan | nice. |
| 19:28:44 | headius | heheh |
| 19:28:52 | evan | headius: so, pre-allocating the exception, then comparing against it works nicely |
| 19:28:58 | brixen | describe Headius do it "should make sense" do fail end; end |
| 19:30:43 | Fullmoon leaves the room. | |
| 19:31:11 | headius | evan: excellent |
| 19:31:22 | headius | of course you're paying the cost to allocate even if it's never used |
| 19:31:26 | evan | yep |
| 19:31:30 | evan | right now, thats fine. |
| 19:32:19 | rue | brixen: There is a lot of work to be done in the specs |
| 19:33:19 | headius | no doubt |
| 19:33:23 | headius | only 804 lines of IO specs |
| 19:33:34 | evan | sweet, this code works quite well. |
| 19:33:40 | evan | only 1 error in ci |
| 19:33:55 | evan | and it's for Dir.mkdir |
| 19:34:00 | evan | for the mkdir spec |
| 19:34:05 | evan | anyone seen that? |
| 19:34:15 | rue | headius: Instead of #deviates_on :ruby, #target_bug, #bug_in_target or #bug_in :ruby ? |
| 19:34:53 | brixen | rue: #bug_in |
| 19:34:57 | headius | yeah |
| 19:35:00 | rue | Maybe even #target_bug "ruby-core:13456" or something |
| 19:35:01 | headius | or bug_on |
| 19:35:01 | evan | ah, it's from a spec blow up. |
| 19:35:06 | evan | er. system. |
| 19:35:12 | brixen | rue: if it's really a bug, but then, why are we spec'ing bugs in other impls? |
| 19:35:31 | brixen | headius: bug_off :P |
| 19:35:31 | TheVoice enters the room. | |
| 19:35:32 | rue | Right, that is why the other two |
| 19:35:50 | rue | By definition, so to speak, only the target can have a bug |
| 19:35:51 | brixen | rue: explain, why not just #bug ? |
| 19:35:53 | rue | The rest deviate |
| 19:36:10 | brixen | rue: i.e why does target matter? |
| 19:36:23 | headius | brixen: it's consistent with every other guard |
| 19:36:33 | brixen | headius: target doesn't matter |
| 19:36:34 | headius | deviates_on, fails_on |
| 19:36:42 | brixen | headius: target doesn't matter :P |
| 19:37:02 | brixen | we're not adding specs for bugs on other impls |
| 19:37:07 | rue | Just bug_in do ... end does not make sense |
| 19:37:15 | thehcdreamer leaves the room. | |
| 19:37:17 | brixen | bug do ... end |
| 19:37:28 | brixen | include a comment to the ruby-talk post or whatever |
| 19:37:38 | headius | well that wasn't my idea...I was just suggesting a name |
| 19:38:15 | brixen | rue: so, #bug will be ignored unless target is :ruby? |
| 19:38:23 | rue | Just #bug may be ambiguous |
| 19:38:44 | brixen | it shouldn't be |
| 19:38:54 | brixen | there's only one ruby standard, only that can have a bug |
| 19:38:57 | rue | In normal mode #bug runs unless platform == target |
| 19:39:20 | brixen | unless platform == :ruby |
| 19:39:36 | brixen | there's only two cases, ruby and everything else |
| 19:39:42 | brixen | given those two, when does #bug run? |
| 19:40:08 | rue | Target == :ruby18 |
| 19:40:15 | joachimm | $seen allan |
| 19:40:21 | rue | Actually, it should probably not run at all |
| 19:40:22 | brixen | joachimm_: no ;) |
| 19:40:28 | brixen | rue: yeah |
| 19:40:41 | rue | No guarantee that the other implementations have fixed it I guess |
| 19:40:51 | probablycorey leaves the room. | |
| 19:40:59 | rue | Alternatively it would require bug do; fails_on :rbx do; ... |
| 19:42:12 | brixen | rue: actually, I'm missing something.. |
| 19:42:29 | brixen | what specs are being guarded with #bug? 1. specs that pass ruby, or 2. specs that fail? |
| 19:42:37 | pkondzior enters the room. | |
| 19:42:39 | probablycorey enters the room. | |
| 19:43:06 | brixen | rue: IOW, do the specs describe the correct behavior, or the behavior we think is a bug? |
| 19:43:07 | rue | Specs that fail on target due to a (reasonably) confirmed incorrect implementation |
| 19:43:12 | rue | Correct behaviour |
| 19:43:19 | brixen | ok |
| 19:43:53 | brixen | so, #bug does not run on :ruby18 but does run on everything else |
| 19:44:54 | rue | Additionally exclude if needed, sure |
| 19:45:12 | rue | Actually I think the report string should probably be required |
| 19:45:49 | brixen | bug "ruby-core:1313435 this is silly" do ... end ? |
| 19:45:55 | brixen | that seems ok to me |
| 19:46:26 | evan | hey |
| 19:46:33 | evan | are those supposed to test that we HAVE the bug |
| 19:46:35 | evan | or that we don't |
| 19:46:38 | evan | that confuses me. |
| 19:46:52 | rue | See? #target_bug :) |
| 19:46:54 | mad_phoenix leaves the room. | |
| 19:46:55 | brixen | the specs should describe the correct behaviore |
| 19:46:59 | brixen | nonono |
| 19:47:07 | brixen | there is only one target that matters for bug |
| 19:47:09 | brixen | ruby |
| 19:47:13 | rue | evan: That means there is a bug in MRI |
| 19:47:18 | rue | Yes, that is correct. |
| 19:47:19 | brixen | the guard will not run the spec on ruby |
| 19:47:25 | rue | #target_bug. Target is MRI |
| 19:47:33 | brixen | specs should always describe the "correct" behaviore |
| 19:47:35 | evan | HAHAHAHAH |
| 19:47:35 | evan | http://www.flickr.com/photos/stutefish/959364633/ |
| 19:47:38 | rue | #bug. What bug? Where? |
| 19:47:44 | brixen | with the allowance that we can deviate |
| 19:48:00 | evan | so |
| 19:48:03 | evan | if there is a test for a bug |
| 19:48:07 | drbrain | evan: omg, hahaha |
| 19:48:07 | evan | MRI should fail that test? |
| 19:48:09 | evan | or pass it? |
| 19:48:10 | mad_phoenix enters the room. | |
| 19:48:11 | evan | drbrain: SO AWESOME |
| 19:48:14 | evan | drbrain: thats at comiccon |
| 19:48:23 | evan | shane, abby, and I are so going this year |
| 19:48:25 | drbrain | yes |
| 19:48:29 | evan | (again) |
| 19:48:31 | brixen | evan: MRI will fail if it exhibits the bug, pass otherwise |
| 19:48:37 | evan | brixen: ok |
| 19:48:47 | evan | i found one that tested that we HAD the bug |
| 19:48:57 | rue | Yeah |
| 19:49:04 | brixen | yeah, there's a lot of crap in there right now |
| 19:49:09 | rue | Going through the specs is going to take more time than I thought |
| 19:49:16 | brixen | first thing I'm doing is making everything 1.8.6p111 correct |
| 19:49:17 | mad_phoenix leaves the room. | |
| 19:49:32 | rue | I think I will just make sure that CI runs clean and push this so everyone can work on the cleanup |
| 19:49:41 | brixen | rue: that's fine |
| 19:50:17 | brixen | I wonder if we'd get a c&d from this "RubySpec: The Standard" ;) |
| 19:50:29 | rue | Heh |
| 19:50:35 | brixen | now with even more insurance |
| 19:51:02 | rue | brixen: Oh! Right now, per an earlier discussion, the guards are only allowed around #it blocks, not inside or other arbitrary locations |
| 19:51:10 | brixen | RubySpec: The Standard You Can Rely On |
| 19:51:21 | rue | Ready To Lead |
| 19:51:31 | rue | Totally No Terrorist Attacks |
| 19:51:31 | brixen | rue: *highly* discourage inside #it |
| 19:51:37 | evan | RubySpec: When You Need to Know What The Fuck It Should Do |
| 19:51:37 | brixen | unless it's to save a life or something |
| 19:52:05 | rubyconsumer enters the room. | |
| 19:52:40 | brixen | rue: guards might be reasonable around #describe too |
| 19:52:58 | rue | brixen: It is easier to just fail. What about #describe or #before/#after? It seems the latter would imply that the spec needs to go in spec/!ruby |
| 19:53:02 | rue | Yeah |
| 19:53:13 | brixen | but not inside #it, #before, etc |
| 19:53:20 | brixen | there's too much sloppy stuff in there |
| 19:53:22 | Fullmoon enters the room. | |
| 19:53:38 | brixen | and most of the guards in #before are on File stuff for windows |
| 19:53:48 | rue | target_bug "ruby-core:11575" do ... end |
| 19:53:57 | brixen | rue: please, #bug |
| 19:54:04 | boyscout | 1 commit by Vladimir Sizikov |
| 19:54:05 | boyscout | * Corrected Module#instance_method failing spec. It was failing on all impls.; f453121 |
| 19:55:57 | VVSiz | hmmm, in Module specs, MRI 1.9 fails about FORTY specs |
| 19:56:23 | rue | brixen: I do not understand the logic here. #target_bug is by no means ambiguous and it parses easier visually due to the length. I agree with #bug_in :ruby because that could imply #bug_in :rbx too |
| 19:56:52 | brixen | rue: target is a totally ambigous word in that context |
| 19:56:59 | brixen | please, just #bug |
| 19:57:01 | brixen | pretty please |
| 19:57:10 | kevinclark | with sugar and sexps on top |
| 19:57:23 | brixen | #standard_bug makes more sense than #target_bugh |
| 19:57:26 | dbussink | VVSiz: there are some known bugs in module eval at least |
| 19:57:34 | dbussink | VVSiz: in mri 1.9 that is |
| 19:57:35 | brixen | you don't even know the target until you run the specs with something |
| 19:57:36 | Arjen_ enters the room. | |
| 19:57:49 | VVSiz | dbussink: oh |
| 19:57:54 | brixen | VVSiz: those failures are because of breakage? or change in behavior? |
| 19:58:16 | rue | You always know the target. |
| 19:58:22 | brixen | not when reading the specs |
| 19:58:27 | rue | Target is the spec target |
| 19:58:33 | rue | OK, #ruby_bug ? |
| 19:58:34 | brixen | what? |
| 19:58:42 | VVSiz | brixen: I don't really know. MRI 1.8.6 passes about all of them (depending on patchlevel), but MRI 1.9 seems to be failing a lot. maybe, jut the MRI behavior changed |
| 19:58:58 | rue | Target is what the specs are written against. The specs /target/ X. |
| 19:59:03 | brixen | VVSiz: ok, I hope there's not that much behavior change, but who knows |
| 19:59:14 | brixen | rue: no, target is what runs the specs |
| 19:59:20 | rue | No, that is the host |
| 19:59:23 | brixen | huh? |
| 19:59:26 | brixen | -t target ? |
| 19:59:31 | brixen | why did I name it that? |
| 19:59:43 | rue | I have no idea |
| 19:59:50 | brixen | there is no host/target anymore |
| 19:59:56 | brixen | target is the impl running the specs |
| 20:00:01 | brixen | #ruby_bug if you insist |
| 20:00:30 | brixen | target was the impl running the specs even under the host/target config |
| 20:01:50 | rue | That is a completely different situation |
| 20:02:04 | rue | Which does not even exist anymore |
| 20:02:22 | brixen | rue: the point is, target is and always has been the specific impl running the specs |
| 20:02:33 | brixen | use #ruby_bug unless you disagree with that |
| 20:02:38 | mad_phoenix_ enters the room. | |
| 20:03:07 | rubuildius | Vladimir Sizikov: f453121dd; 4465 examples, 16821 expectations, 1 failure, 0 errors; http://rafb.net/p/N8MAr823.html |
| 20:04:04 | rue | brixen: #ruby_bug it is |
| 20:04:26 | rue | But you are saying that target is the host |
| 20:04:40 | brixen | rue: no, I'm not |
| 20:04:48 | brixen | host was the impl that would pass the specs to the target |
| 20:04:59 | brixen | the target would run them and pass the result back |
| 20:05:07 | brixen | that's where the word target came from |
| 20:05:20 | brixen | we could not host rspec, so we used mri to do it |
| 20:05:42 | dbussink | hmm, other people who get a sigbus error here? |
| 20:05:52 | rue | dbussink: HEAD? |
| 20:06:07 | dbussink | yeah |
| 20:06:20 | dbussink | did a clean build |
| 20:06:30 | dbussink | 0x128f2c Numeric#==+0 in kernel/core/numeric.rb:111 |
| 20:06:36 | evan | crap |
| 20:06:39 | evan | i've seen that too |
| 20:06:49 | evan | do a 'rake distclean' |
| 20:06:50 | evan | then build |
| 20:06:58 | evan | i haven't figured out what it is yet. |
| 20:07:21 | dbussink | already did that |
| 20:07:28 | evan | is in consistent? |
| 20:07:34 | evan | it consistent. |
| 20:07:48 | dbussink | nope, it fails at different points during a ./bin/ci run |
| 20:08:36 | dbussink | had it twice, both in numeric, but not on the same line |
| 20:08:54 | dbussink | i'll test this some more and do a debug build and gdb run |
| 20:09:47 | brixen | dbussink: run it with bin/ci -C -fs |
| 20:10:01 | octopod leaves the room. | |
| 20:10:10 | brixen | dbussink: sometimes issues that implicate the gc will fail differently with all those extra object created with -fs |
| 20:11:22 | binary42 leaves the room. | |
| 20:12:01 | dbussink | yeah, now a sigbus in a completely different place |
| 20:14:30 | brixen | dbussink: exclude the Kernel#callcc specs and see if it goes away |
| 20:14:54 | brixen | dbussink: easiest way to do that quickly is put Kernel#callcc in spec/data/critical.txt |
| 20:17:43 | enebo enters the room. | |
| 20:19:39 | dbussink | brixen: seems to fix it, running bin/ci a couple of times to make a better judgement on this |
| 20:26:12 | boyscout | 1 commit by Evan Phoenix |
| 20:26:13 | boyscout | * Fix LongReturnException to be terminated in the correct place; 996f9f4 |
| 20:26:21 | evan | why am I getting ci failures for instance_method |
| 20:26:22 | evan | ? |
| 20:26:25 | evan | are others getting that? |
| 20:28:40 | Defiler | Let me fetch and see |
| 20:29:48 | Defiler | Argh, I have to distclean again. That is getting irritating |
| 20:30:36 | dbussink | evan: getting the same failure |
| 20:31:07 | dbussink | Expected TypeError but got ArgumentError |
| 20:31:07 | evan | looks like someone committed this but didn't make rubinius pass it. |
| 20:31:11 | evan | or rather, change it. |
| 20:31:49 | dbussink | looks like VVSiz is to blame : |
| 20:31:50 | dbussink | :P |
| 20:31:57 | smtlaissezfaire enters the room. | |
| 20:32:09 | VVSiz | sure |
| 20:32:17 | VVSiz | the spec was wrong, I corrected it |
| 20:32:19 | brixen | evan: that's a broken spec |
| 20:32:28 | emphatic enters the room. | |
| 20:32:29 | brixen | yeah, we implemented the wrong behavior |
| 20:32:36 | boyscout | 1 commit by Evan Phoenix |
| 20:32:37 | boyscout | * Fix to_sym conversion; 280b074 |
| 20:32:38 | brixen | it *was* broken |
| 20:32:39 | evan | not any more! |
| 20:32:44 | brixen | hehe |
| 20:32:49 | VVSiz | :) |
| 20:33:13 | evan | too much of our code does a bunch of tests to raise exceptions |
| 20:33:23 | evan | we should be asking for forgiveness more |
| 20:33:33 | evan | i just changed the code to call to_sym in a begin/rescue |
| 20:33:38 | evan | and just raise TypeError if it fails. |
| 20:33:42 | VVSiz | just to check: my understanding is that when I commit/change specs, I don't exclude failures immediately, so that people would have a chance to look at them and act appropriatly (quick fix, discussion, spanking) |
| 20:33:59 | brixen | VVSiz: nah, exclude them |
| 20:34:13 | Defiler | I vote exclude them and open a ticket, if you aren't fixing it yourself before you push |
| 20:34:18 | brixen | ideal is specs that fail with code that makes them pass |
| 20:34:41 | VVSiz | :) |
| 20:34:57 | ezmobius enters the room. | |
| 20:34:58 | evan | btw |
| 20:35:01 | evan | we can build stables again |
| 20:35:04 | VVSiz | ok then, will try to exclude them. |
| 20:35:05 | evan | LRE is all fixed up |
| 20:35:15 | brixen | evan: sweet, thanks |
| 20:35:53 | VVSiz | brixen: but somebody would have to constantly monitor the exclusions. |
| 20:36:14 | brixen | VVSiz: well, I'll be monitoring commits that add them ;) |
| 20:36:22 | VVSiz | :) |
| 20:37:34 | evan | where is zenspider's rake task to print out the excludes? |
| 20:37:37 | evan | did it get deletede? |
| 20:38:40 | bburcham enters the room. | |
| 20:38:48 | dgtized | I think it's just todo, but it's not documented or something |
| 20:39:25 | brixen | rake todo |
| 20:39:44 | evan | i'm going to do a little cleanup of the Rakefile |
| 20:39:54 | evan | moving our utility classes and functions to a rakelib/ file |
| 20:40:02 | evan | so that Rakefile contains just tasks mainly |
| 20:41:14 | pauldix enters the room. | |
| 20:45:00 | pauldix leaves the room. | |
| 20:45:00 | rubuildius | Evan Phoenix: 280b07495; 4465 examples, 16821 expectations, 0 failures, 0 errors |
| 20:45:03 | rubuildius | Evan Phoenix: 996f9f4e5; 4465 examples, 16821 expectations, 1 failure, 0 errors; http://rafb.net/p/kXD9bE91.html |
| 20:45:19 | evan | rubuildius is out of order. |
| 20:45:25 | evan | 280b was the later commit |
| 20:45:26 | brixen | heh, race condition |
| 20:46:57 | pkondzior leaves the room. | |
| 20:47:27 | pkondzior enters the room. | |
| 20:47:46 | kofno_ leaves the room. | |
| 20:48:00 | jessop enters the room. | |
| 20:48:52 | VVSiz | guys, can somebody explain what this spec tests really: |
| 20:48:53 | VVSiz | http://pastie.caboo.se/142065 |
| 20:49:01 | boyscout | 1 commit by Evan Phoenix |
| 20:49:02 | boyscout | * Cleanup / reorganize Rakefile; a8bdc6b |
| 20:49:16 | evan | VVSiz: test that |
| 20:49:19 | evan | m = Module.new |
| 20:49:21 | evan | Blah = m |
| 20:49:23 | VVSiz | it fails for MRI 1.8.6 (latest trunk), MRI 1.9, JRuby. and the behavior is kind of weird, and I'd even say non-deterministic |
| 20:49:24 | evan | p m.name |
| 20:49:29 | evan | # => "Blah" |
| 20:51:17 | evan | i'm not thrilled about that code. |
| 20:51:58 | VVSiz | weird, in most cases that p returns nil, but in MRI 1.9 returns "Blah". but in all cases it prints "Blah" anyways. |
| 20:52:26 | brixen | that's one of the weirdest specs I've seen |
| 20:52:36 | brixen | and looks like some accident of implementation |
| 20:52:40 | evan | VVSiz: works for me in 1.8 |
| 20:52:42 | evan | in irb. |
| 20:52:50 | evan | doing exactly my steps from above. |
| 20:53:04 | VVSiz | I'd say all 1.8.6-level implementations behave as you, evan, listed above. |
| 20:53:12 | brixen | evan: Blah = m at least has some sense |
| 20:53:26 | VVSiz | but for the spec in the question, they behave differently |
| 20:53:33 | brixen | ModuleSpecs.const_set(:Y, m) |
| 20:53:38 | brixen | ? |
| 20:53:42 | VVSiz | I'd say the spec is not really a spec in this case. |
| 20:53:44 | brixen | what behavior is that really? |
| 20:54:25 | mutle leaves the room. | |
| 20:54:40 | evan | ok, lunch time. |
| 20:55:29 | VVSiz | and the weirdest part is that sometimes MRI behaves one way for a while, and sometimes switches and behaves another way (10 times passing the spec, 5 times failing, 20 times passing...) man, I'm going INSANE |
| 20:55:51 | kofno enters the room. | |
| 20:55:53 | brixen | VVSiz: yeah, I keep getting a failure on that spec randomly |
| 20:56:15 | VVSiz | oh, good! |
| 20:56:17 | mutle enters the room. | |
| 20:56:31 | brixen | VVSiz: if it were m = Module.new; Blah = m; p m.name |
| 20:56:35 | brixen | that would be ok, I think |
| 20:56:51 | brixen | this behavior with #const_set seems like some accident of implementation |
| 20:57:02 | VVSiz | agree |
| 20:57:08 | brixen | let's see some code that depends on that so we can make an example of someone ;) |
| 20:57:42 | evan | headius and I have talked about this behavior |
| 20:57:47 | evan | for the bottom one |
| 20:57:53 | jtoy enters the room. | |
| 20:57:56 | evan | where it picks up Y |
| 20:58:00 | VVSiz | that spec was part of HUUUGE commit: 970ede321d31ec75dd578866c683defe768fa356 |
| 20:58:03 | jtoy leaves the room. | |
| 20:58:07 | evan | that behavior is a 'quirk' |
| 20:58:10 | evan | and is gone in 1.9 |
| 20:58:14 | brixen | evan: excellent |
| 20:58:23 | evan | we will not be implementing it |
| 20:58:44 | VVSiz | well, you are already |
| 20:58:47 | brixen | evan: but the m = Module.new; Blah = m; m.name => "Blah" |
| 20:58:48 | VVSiz | with that huge patch |
| 20:58:55 | brixen | evan: that one we do? or don't? |
| 20:59:06 | rubuildius | Evan Phoenix: a8bdc6b71; 4465 examples, 16821 expectations, 0 failures, 0 errors |
| 20:59:35 | kofno leaves the room. | |
| 21:00:05 | brixen | VVSiz: looks like he accidentally checked in a autoconf changeset |
| 21:00:12 | evan | zambatiz implemented it |
| 21:00:16 | brixen | we should probably revert that and reapply with just the relevant code |
| 21:00:18 | evan | but i highly dislike it. |
| 21:00:24 | turtletime leaves the room. | |
| 21:00:25 | evan | and his commit should be reverted. |
| 21:00:36 | VVSiz | agree again |
| 21:00:57 | evan | http://git.rubini.us/?p=code;a=commitdiff;h=7cd9fce4908aaeea9a35e273a3f15ed7ee7aa783 |
| 21:01:05 | evan | thats his commit for our implementation of it |
| 21:01:32 | brixen | hears all chanting in unison: revert revert revert |
| 21:02:12 | emphatic leaves the room. | |
| 21:02:23 | evan | lunch! |
| 21:02:31 | VVSiz | and the problematic specs implemented here: http://git.rubini.us/?p=code;a=commitdiff;h=970ede321d31ec75dd578866c683defe768fa356 |
| 21:02:56 | VVSiz | but that configure patch looks scary :) |
| 21:03:08 | VVSiz | implemented -> added |
| 21:03:17 | brixen | VVSiz: care to do the honors? ;) |
| 21:03:44 | dbussink | he already reverted the configure patch if i recall correctly |
| 21:03:52 | VVSiz | please, be my guest. I might've missed some nuances... |
| 21:04:24 | brixen | VVSiz: got to head to class in 10, someone will do it |
| 21:04:29 | RyanTM__ leaves the room. | |
| 21:04:55 | RyanTM enters the room. | |
| 21:05:26 | VVSiz | dbussink: yeah, good! :) |
| 21:06:55 | boyscout | 1 commit by Vladimir Sizikov |
| 21:06:56 | boyscout | * Revert "Module#name memoization work."; cc0e45c |
| 21:07:47 | jessop leaves the room. | |
| 21:10:19 | essoepp leaves the room. | |
| 21:10:28 | boyscout | 1 commit by Vladimir Sizikov |
| 21:10:29 | boyscout | * Revert "Completed MRI's Module#name spec with corner case."; 68ae0b5 |
| 21:21:21 | drbrain | evan: shotgun/rubinius -rtempfile -e 'p Tempfile.new("tempfile_test").class' |
| 21:21:35 | drbrain | should report 'Tempfile', reports 'File' |
| 21:21:35 | drbrain | ideas? |
| 21:21:37 | drbrain | (this is for OpenURI |
| 21:22:52 | dbussink | hmm, probably because of the delegate stuff |
| 21:23:42 | drbrain | dbussink: I've gotten that far |
| 21:25:07 | rubuildius | Vladimir Sizikov: 68ae0b5ac; 4463 examples, 16804 expectations, 0 failures, 0 errors |
| 21:25:07 | rubuildius | Vladimir Sizikov: cc0e45cab; 4464 examples, 16812 expectations, 0 failures, 0 errors |
| 21:28:08 | drbrain | great, __FILE__ != $0 when it should |
| 21:28:48 | evan | yeah |
| 21:28:49 | evan | i know. |
| 21:28:58 | evan | i was going to work on that today |
| 21:29:25 | drbrain | well, at least delegates crappy little tests pass |
| 21:30:08 | evan | drbrain: seems like Tempfile.new("aoeu").class should report File |
| 21:30:17 | evan | since it delegates class to the File object |
| 21:30:52 | drbrain | from reading DelegateClass's implementation, I don't think so |
| 21:31:00 | drbrain | hrm, maybe it does something special |
| 21:31:20 | drbrain | hrm... |
| 21:31:27 | evan | why not? |
| 21:31:31 | evan | it sets up a proxy for class |
| 21:31:37 | evan | to call @_dc_obj.class |
| 21:31:48 | evan | oh |
| 21:31:52 | evan | maybe we have class on Object |
| 21:31:56 | evan | but it's on Kernel in MRI |
| 21:32:02 | evan | so the subtraction isn't working. |
| 21:32:07 | drbrain | that's what I was thinking |
| 21:32:30 | evan | MRI has so many methods in the wrong place. |
| 21:33:25 | dean-ero leaves the room. | |
| 21:33:53 | drbrain | yeah, that's it :( |
| 21:34:08 | essoepp enters the room. | |
| 21:34:31 | evan | drbrain: well, i guess we need to rearrange so we match MRI exactly |
| 21:34:41 | evan | for methods on Kerner and Object |
| 21:35:01 | drbrain | hrm, well, that doesn't actually fix my problem |
| 21:37:19 | drbrain | dd if=/dev/zero of=~/Sites/zeros bs=1024 count=11 |
| 21:37:19 | pauldix enters the room. | |
| 21:37:27 | drbrain | http://rafb.net/p/AlPqkU33.html |
| 21:37:39 | drbrain | I'm seeing #<Class:0x40099>(File)#status= (method_missing) at (eval):2 |
| 21:37:54 | drbrain | and I think the DelegateClass is getting in my way, since I'm going through one of the delegated methods |
| 21:39:06 | drbrain | hrm, #extend? |
| 21:40:04 | drbrain | yeah |
| 21:40:10 | pate leaves the room. | |
| 21:40:22 | agardiner enters the room. | |
| 21:40:50 | agardiner | morning |
| 21:41:22 | djwhitt enters the room. | |
| 21:41:31 | solarce | mornin mate, how are things down south? |
| 21:42:07 | agardiner | beautiful day. how 'bout up north? :-) |
| 21:42:27 | solarce | tis a cold day here in la |
| 21:43:10 | solarce | a fine day for me to rage at dell support |
| 21:43:28 | agardiner | good luck with that! |
| 21:45:00 | drbrain | evan: since we have so many more methods, there need to be many more excludes |
| 21:45:16 | drbrain | or, visibility needs to be changed |
| 21:45:47 | evan | we need to be marking a lot more things private than we currently are |
| 21:46:09 | drbrain | adding this: |
| 21:46:23 | drbrain | methods -= %w[class extend kind_of? respond_to? nil? object_id metaclass __verify_metaclass__ instance_exec] |
| 21:46:27 | drbrain | fixes #extend |
| 21:47:46 | headius leaves the room. | |
| 21:47:47 | dean-ero enters the room. | |
| 21:51:39 | evan | k |
| 21:52:19 | drbrain | does Object have any instance methods? |
| 21:52:23 | drbrain | (in MRI)? |
| 21:52:28 | drbrain | other than #initialize? |
| 21:52:30 | evan | check |
| 21:52:32 | evan | in irb. |
| 21:52:40 | drbrain | I'm seeing none |
| 21:52:47 | dodecaphonic_ enters the room. | |
| 21:53:04 | evan | i see a ton |
| 21:53:12 | evan | 41 to be exact. |
| 21:53:21 | drbrain | Object.public_instance_methods(false) |
| 21:53:27 | dodecaphonic_ leaves the room. | |
| 21:53:45 | drbrain | they're all from Kernel |
| 21:53:52 | yipstar leaves the room. | |
| 21:53:55 | evan | ah |
| 21:53:59 | evan | then there is your answer. |
| 21:54:01 | evan | which is so dumb. |
| 21:54:06 | evan | but thats MRI |
| 21:54:07 | drbrain | agreed |
| 21:54:38 | dean-ero enters the room. | |
| 21:57:30 | jessop enters the room. | |
| 21:57:50 | agardiner | evan: need to pin you down... :-) |
| 21:58:17 | agardiner | what is the reason we should not raise exceptions from a primitive? I want to put it into README_DEVELOPERS... |
| 21:58:58 | evan | it's bad form. |
| 21:59:22 | unagi-san enters the room. | |
| 21:59:22 | evan | it breaks encapsulation barriers |
| 21:59:46 | dewd leaves the room. | |
| 22:00:13 | dbussink | maybe we should add some pointers on how to do it properly? |
| 22:00:34 | agardiner | i'm not sure i follow... take dbussink's regexp.new problem |
| 22:00:35 | turtletime enters the room. | |
| 22:01:00 | agardiner | to get the error message back without raising an exception requires some other way of passing back the error message |
| 22:01:37 | dbussink | well, i don't like the current solution either |
| 22:01:53 | dbussink | but i don't know of any other solution that is currently possible |
| 22:03:10 | emphatic enters the room. | |
| 22:03:41 | evan | hm |
| 22:04:55 | agardiner | i'm not sure i agree that it breaks encapsulation either... why is it better for me to just raise an ArgumentError from the code following the primitive, rather than in the primitive itself? i'm now raising a range exception in Ruby land, but the check for the range is in C... |
| 22:05:19 | agardiner | (i'm talking about the task_get_stack_value prim now, btw) :-) |
| 22:08:09 | rubyconsumer leaves the room. | |
| 22:08:15 | evan | I might be ok raising an exception from primitives |
| 22:08:25 | evan | because it does seem like it simplifies some cases |
| 22:08:39 | evan | but if we do |
| 22:08:54 | evan | then there should be a RAISE() macro that does the right thing |
| 22:09:02 | evan | which should preserve the proper semantics. |
| 22:09:21 | dbussink | that's definitely true, constructing the exception by hand is ugly |
| 22:11:06 | evan | RAISE("RangeError", "you're way way way out of range"); |
| 22:11:08 | evan | something like that. |
| 22:11:29 | agardiner | yeah, that looks much nicer |
| 22:12:40 | evan | i'd be ok with that solution. |
| 22:14:19 | ragge enters the room. | |
| 22:15:14 | agardiner | hmm - looks like there are a number of different usages |
| 22:15:39 | evan | it should use rbs_const_get everytime |
| 22:15:46 | evan | rather than accessing state->global |
| 22:15:49 | evan | that simplifies the case. |
| 22:15:54 | agardiner | eg raise_from_errno |
| 22:16:04 | zenspider | here it comes |
| 22:16:12 | boyscout | 7 commits by Ryan Davis |
| 22:16:13 | boyscout | * Removed a lot of passing specs from the excludes; 2bf52de |
| 22:16:14 | boyscout | * Removed __old_send__; 00d6230 |
| 22:16:15 | boyscout | * Module should be using #to_sym, not #__symbol_lookup__; 8575b03 |
| 22:16:16 | boyscout | * Fixed Symbol::all_symbols; b0e5a9b |
| 22:16:17 | boyscout | * Added extra exceptions and removed all-exclude.txt~ generator since that mspec functi ...; 4d5a52d |
| 22:16:18 | boyscout | ... |
| 22:16:23 | evan | agardiner: so, perhaps 2 macros |
| 22:16:27 | zenspider | ...?!? |
| 22:16:30 | evan | zenspider: CI pasess properly, right? |
| 22:16:34 | zenspider | screw you boyscout! |
| 22:16:38 | zenspider | aye |
| 22:16:42 | evan | it always truncates at 5 |
| 22:17:02 | zenspider | unlike drbrain, I always pull and rerun bin/ci before I commit. :P |
| 22:17:12 | agardiner | evan: should these macros be only for use in primitives? |
| 22:17:23 | evan | agardiner: yes. |
| 22:17:26 | zenspider | 228 excluded specs to go |
| 22:17:38 | agardiner | k - i'll knock something up and run it by you |
| 22:18:09 | evan | k |
| 22:18:22 | dbussink | evan: do you have a suggestion for passing an error message from a deeper level? like with regexp_new? |
| 22:18:40 | dbussink | or just keep the current way of abusing the returned object? |
| 22:19:28 | evan | i don't like the current way. |
| 22:19:35 | evan | passing up a String |
| 22:19:44 | dbussink | me neither, but any other suggestion? |
| 22:20:14 | evan | better is pass down a &err |
| 22:20:17 | evan | and check it on return |
| 22:20:38 | evan | C error condition style |
| 22:20:59 | dbussink | ah ok, are there any existing structures for this? |
| 22:21:11 | dbussink | because i can imagine it could be useful in other places too |
| 22:21:37 | evan | i don't think we have needed it yet |
| 22:21:43 | evan | so no, no existing ones in our code base. |
| 22:23:32 | evan | i need to add to README-DEVELOPERS that people should use to_sym |
| 22:23:34 | evan | not intern. |
| 22:24:28 | zenspider | I still don't understand why #intern doesn't exist on Symbol... dumb |
| 22:24:44 | evan | me neither, but it's a good reason to not use it. |
| 22:26:26 | djwhitt | hmm... is the git server having trouble? |
| 22:26:39 | evan | not that I know of. |
| 22:26:45 | zenspider | yeah. makes me sad tho... intern is from my smalltalky days |
| 22:26:48 | djwhitt | ah, could just be my connection never mind |
| 22:29:17 | rubuildius | Ryan Davis: 2bf52de43; 4467 examples, 16815 expectations, 1 failure, 0 errors; http://rafb.net/p/PNgMyj25.html |
| 22:29:23 | drbrain | evan: how should I handle bootstrapping if I can't include Kernel in Object? |
| 22:30:07 | pkondzior leaves the room. | |
| 22:30:18 | evan | drbrain: not sure what ya mean. |
| 22:30:50 | drbrain | so, I move kind_of? from kernel/bootstrap/object.rb to kernel/bootstrap/kernel.rb |
| 22:31:01 | drbrain | but, Object.include Kernel happens in kernel/core/kernel.rb |
| 22:31:14 | evan | bugger |
| 22:31:21 | drbrain | so, kind_of? doesn't exist yet |
| 22:31:23 | evan | we're going to have to completely reorganize bootstrap. |
| 22:33:22 | evan | which is why it's stupid those methods aren't on Object. |
| 22:33:34 | drbrain | I'll keep fighting it |
| 22:33:39 | evan | you wont get it. |
| 22:33:58 | zenspider | no faith... |
| 22:34:01 | zenspider | haha |
| 22:34:04 | agardiner | dbussink: how do i trigger a regexp error in the primitive to make it raise the exception? |
| 22:34:10 | zenspider | yeah! screw you drbrain! :P |
| 22:34:27 | evan | the simplest is gonig to be just have the VM create Kernel and include it in Object |
| 22:34:30 | evan | before bootstrap even runs. |
| 22:34:35 | dbussink | agardiner: throw in something like $[^, it's in the specs too |
| 22:38:05 | VVSiz | heh: p o.methods.sort -- in new specs for attr_writer :) |
| 22:38:39 | zenspider | VVSiz: are you working on attr_writer? |
| 22:39:15 | evan | zenspider: he's a jruby guy, he doesn't write rubinius code. |
| 22:39:17 | evan | only specs. |
| 22:39:18 | chris2 leaves the room. | |
| 22:39:37 | zenspider | heh. ok... I'll keep poking then |
| 22:39:46 | evan | so |
| 22:39:49 | evan | bin/mspec spec/core |
| 22:39:54 | evan | and it should be destablized? |
| 22:40:09 | evan | wierd. |
| 22:40:11 | evan | yep |
| 22:40:17 | evan | it exits really early |
| 22:40:20 | zenspider | oops. I committed some debugging output. I'll have that fixed in a sec |
| 22:40:36 | evan | oh, wrong core. |
| 22:40:41 | evan | why do we just still have |
| 22:40:42 | evan | spec/core |
| 22:40:42 | evan | ? |
| 22:40:59 | zenspider | as compared to? ruby/1.8 ? |
| 22:41:04 | evan | yeah |
| 22:41:15 | zenspider | no clue |
| 22:41:38 | evan | running |
| 22:41:44 | evan | bin/mspec spec/ruby/1.8/core |
| 22:41:51 | evan | i get a bunch of failures |
| 22:41:55 | evan | but no destabilization |
| 22:42:05 | zenspider | *nod* |
| 22:42:09 | boyscout | 1 commit by Vladimir Sizikov |
| 22:42:10 | boyscout | * Removed debugging stdout from one spec.; 811cbe8 |
| 22:42:14 | evan | where is the attr_writer destablization? |
| 22:42:30 | evan | oh fired. |
| 22:42:37 | evan | someone used defined?() in specs. |
| 22:42:49 | zenspider | I didn't say there was destabilization with attr_writer... just failure. |
| 22:42:59 | evan | who did this... |
| 22:43:01 | zenspider | I think you fixed all the destabilization issues yesterday |
| 22:43:06 | evan | ah, ok. |
| 22:43:08 | dean-ero_ enters the room. | |
| 22:43:10 | drbrain | what's wrong with defined? |
| 22:43:13 | zenspider | doh. VVSiz beat me to the commit |
| 22:43:21 | VVSiz | hehehheeh :) |
| 22:43:32 | evan | it "File::RDONLY" do |
| 22:43:32 | evan | defined?(File::RDONLY).should == "constant" |
| 22:43:32 | evan | end |
| 22:43:39 | evan | thats stupid. |
| 22:43:51 | evan | and doesn't work on rubinius |
| 22:43:51 | dean-ero leaves the room. | |
| 22:43:58 | evan | because we don't support returning strings from defined? |
| 22:44:53 | drbrain | ah, yeah, agreed |
| 22:45:44 | zenspider | evan: we don't? |
| 22:45:53 | zenspider | any reason not to? |
| 22:46:03 | retnuH_ enters the room. | |
| 22:46:03 | evan | we're lazy fucks. |
| 22:46:08 | retnuH leaves the room. | |
| 22:46:17 | squeegy enters the room. | |
| 22:46:25 | evan | feel free to implement it |
| 22:46:29 | evan | it is 100% in the compiler |
| 22:46:38 | evan | because you have to have the full sexp to figure it out. |
| 22:46:59 | bburcham leaves the room. | |
| 22:47:27 | zenspider | yeah... :( |
| 22:47:45 | zenspider | is still highly tempted to nuke the parser |
| 22:47:53 | evan | in favor of what? |
| 22:48:19 | evan | i'm not a big fan of setting us back 6 months |
| 22:48:26 | enebo leaves the room. | |
| 22:48:28 | zenspider | we've discussed this |
| 22:48:39 | enebo enters the room. | |
| 22:48:42 | evan | refresh my memory. |
| 22:48:43 | zenspider | 6 months? |
| 22:49:05 | drbrain | ruby_parser... |
| 22:49:12 | evan | i thought it sucked |
| 22:49:17 | evan | thats from zenspider's own mouth. |
| 22:49:29 | zenspider | it does |
| 22:49:44 | zenspider | so does the current setup. just in different ways |
| 22:49:53 | evan | i think the current setup sucks less. |
| 22:50:01 | evan | then EVERYONE dealing with a broken parser. |
| 22:50:12 | zenspider | ??? |
| 22:50:18 | zenspider | what is broken about the parser? |
| 22:50:24 | evan | you said it sucks. |
| 22:50:29 | evan | that to me means it's borken. |
| 22:50:32 | drbrain | sucks != broken |
| 22:50:48 | zenspider | not in the slightest |
| 22:51:21 | evan | then please integrate it. |
| 22:51:32 | evan | there are only to methods |
| 22:51:35 | evan | s/to/two/ |
| 22:51:43 | evan | we should be able to have both at first |
| 22:51:48 | evan | then just remove using the old one. |
| 22:52:02 | evan | introduces zenspider's mouth to money |
| 22:53:02 | agardiner | evan: re primitive exceptions, task_raise and thread_raise both call cpu_raise_exception; do you want a macro for these two as well for consistency? |
| 22:53:13 | evan | no |
| 22:53:19 | evan | leave those alone. |
| 22:53:19 | enebo | zenspider: I had some weird mac irc issue so I missed the start of this...is your top down parser working well enough that you want to merge and use in rubinius? |
| 22:53:32 | agardiner | ok |
| 22:54:15 | rubuildius | Vladimir Sizikov: 811cbe8ef; 4467 examples, 16815 expectations, 1 failure, 0 errors; http://rafb.net/p/IU5VsB46.html |
| 22:54:31 | enebo | actually anyone listening could probably answer that question :) |
| 22:54:32 | zenspider | evan: you can stop being a jackass now... All I said was I was highly tempted. |
| 22:54:46 | evan | ok. |
| 22:54:47 | zenspider | enebo: want, yes... need/should, probably not. |
| 22:54:49 | evan | i'll stop. |
| 22:55:03 | zenspider | enebo: what irc client do you use? |
| 22:55:18 | enebo | zenspider: I am just interested because the IDE people would really like a top-down parser for better error reporting |
| 22:55:27 | zenspider | I switched to emacs' erc (on my mac) and LOVE it compared to the other clients available on osx |
| 22:55:38 | enebo | I am using Adium...for some reason no text was displaying in all but on window |
| 22:55:39 | zenspider | enebo: it is not there yet for position info |
| 22:55:55 | zenspider | adium for irc? |
| 22:56:08 | enebo | err...sorry |
| 22:56:13 | enebo | Colloquy |
| 22:56:32 | enebo | Yeah grafting position info into port of MRI parser was painful |
| 22:56:42 | enebo | I am hoping it will be easier for you |
| 22:56:53 | zenspider | evan: I'm looking into remove_method not raising NameError and found Module#__find_method. There is also Object#__find_method__... clue me? |
| 22:57:05 | zenspider | enebo: it will be, once I switch the lexer over and clean up stuff |
| 22:57:12 | enebo | cool |
| 22:57:12 | zenspider | it is #3 on my todo list |
| 22:57:47 | zenspider | evan: I think the Object#__find_method__ can go / merge with the Module one. or vice versa |
| 22:57:51 | evan | nope |
| 22:58:06 | evan | Module#__find_method (bad name btw) finds an instance method |
| 22:58:15 | evan | it should probably be removed with looking in the method_table |
| 22:58:24 | evan | Object#__find_method__ hooks into the VM method lookup logic |
| 22:58:40 | evan | to find an implementation of a method for an object, given a name. |
| 22:58:56 | zenspider | right... I'm not seeing where they are incompatible yet |
| 22:59:13 | evan | Module#__find_method looks in it's own instance method table |
| 22:59:25 | evan | Object#__find_method__ looks in other people's instance method tables |
| 22:59:34 | evan | they look different places. |
| 23:00:09 | zenspider | exported_cpu_find_method vs cpu_locate_method_on... |
| 23:00:45 | evan | yes, similar, but different starting points |
| 23:01:00 | evan | if you call __find_method__ on a Module |
| 23:01:09 | evan | it will look for methods that that object responds to |
| 23:01:17 | evan | not methods that instances of it respond to |
| 23:02:52 | dbussink leaves the room. | |
| 23:03:45 | boyscout | 2 commits by Evan Phoenix |
| 23:03:46 | boyscout | * Update Proc excludes; f45030d |
| 23:03:47 | boyscout | * Add Proc#==; 7f932fb |
| 23:03:54 | zenspider | ack. I'm lost |
| 23:04:48 | Defiler | What should Module#__find_method__ be named? |
| 23:04:59 | evan | wrong one. |
| 23:05:00 | Defiler | I was confused about what it did, prior to your explanation a moment ago |
| 23:05:18 | evan | Module#__find_method should be Module#lookup_instance_method |
| 23:05:44 | zenspider | hrm... so undef_method and remove_method both call instance_method just to get the NameError code. instance_method isn't raising tho and it goes down 5ish levels |
| 23:05:57 | evan | ack. |
| 23:05:58 | crafterm enters the room. | |
| 23:05:58 | zenspider | no double underscore on the front? |
| 23:06:06 | evan | doesn't really matter. |
| 23:06:14 | evan | either underscores on both sides |
| 23:06:16 | evan | or not at all. |
| 23:06:18 | zenspider | I do like the convention |
| 23:06:22 | zenspider | k |
| 23:06:26 | pauldix leaves the room. | |
| 23:09:28 | emphatic leaves the room. | |
| 23:11:51 | turtletime leaves the room. | |
| 23:12:00 | evan | zenspider: are you in the module excludes? |
| 23:12:01 | probablycorey leaves the room. | |
| 23:14:13 | rubuildius | Evan Phoenix: f45030d33; 4470 examples, 16824 expectations, 1 failure, 0 errors; http://rafb.net/p/0rCpKI25.html |
| 23:15:01 | pd leaves the room. | |
| 23:17:24 | turtletime enters the room. | |
| 23:18:21 | zenspider | evan: excludes and specs currently, yes |
| 23:18:31 | evan | k |
| 23:19:22 | zenspider | evan: what's up? |
| 23:19:32 | evan | just wanted to know where you were |
| 23:19:38 | zenspider | what is fails_on :rubinius for? |
| 23:19:40 | evan | i was going to tackled a few myself. |
| 23:19:52 | evan | a spec we know we don't pass |
| 23:20:01 | wycats leaves the room. | |
| 23:20:02 | evan | and we didn't know how to make pass for now |
| 23:20:04 | evan | i think. |
| 23:20:10 | evan | not sure why we have that AND excludes. |
| 23:20:13 | zenspider | I'm wondering why remove_method's instance_method isn't raising NameError when instance_method specs pass |
| 23:20:23 | wycats enters the room. | |
| 23:20:30 | zenspider | I just added some specs for instance_method to verify that it was broken and they pass. :( |
| 23:21:06 | evan | hm. does write reset eof? |
| 23:21:22 | zenspider | yeah. that's what I'm confused by |
| 23:22:11 | zenspider | ok. ok... I misunderstood the spec... |
| 23:22:16 | zenspider | it is wrong |
| 23:25:43 | crafterm leaves the room. | |
| 23:26:42 | zenspider | evan: is @method_table flattened? |
| 23:26:52 | zenspider | I need to check for method existance for current level only |
| 23:26:59 | evan | flattened how? |
| 23:27:14 | evan | it's only the methods for that Module |
| 23:28:23 | zenspider | ok. would you mind me digging in there for the existance check? or should I be using one of those __find_methods? |
| 23:28:46 | evan | we have it already |
| 23:28:51 | evan | look at |
| 23:28:56 | evan | find_method_in_hierarchy |
| 23:29:00 | zenspider | it looks like Module#__find_method looks up heirarchy |
| 23:29:02 | evan | you can of course look directly in a method_table |
| 23:29:15 | evan | cm = method_table[:name] |
| 23:29:34 | zenspider | "for current level only" |
| 23:29:41 | zenspider | ok. I'll look in method table |
| 23:30:11 | agardiner | evan: do you want to review the primitive exception macros before i push? |
| 23:30:27 | evan | if they pass ci |
| 23:30:28 | evan | go ahead. |
| 23:30:46 | agardiner | strange - they passed ci before i pulled and rebased... |
| 23:30:56 | agardiner | anyone else seeing ci failures on HEAD? |
| 23:31:27 | evan | not currently |
| 23:31:28 | evan | no. |
| 23:31:29 | agardiner | looks related to intern/to_sym, and Proc#== |
| 23:33:23 | evan | what are they? |
| 23:33:59 | agardiner | just trying clean && build |
| 23:34:43 | zenspider | *sigh* |
| 23:35:00 | agardiner | yeah, that seems to have fixed it |
| 23:35:11 | zenspider | so... that fails_on :rubinius thing? it means the block doesn't run at all... instead of running and rescuing or something |
| 23:35:17 | evan | yep |
| 23:35:21 | zenspider | 2 of the specs pass after removing those blocks |
| 23:35:36 | Arjen_ leaves the room. | |
| 23:35:49 | boyscout | 1 commit by Adam Gardiner |
| 23:35:50 | boyscout | * Added RAISE and RAISE_FROM_ERRNO macros; f3230b6 |
| 23:36:59 | turtletime leaves the room. | |
| 23:37:08 | boyscout | 2 commits by Evan Phoenix |
| 23:37:09 | boyscout | * Fix up sysread and syswrite, disable testing for warnings on rubinius; 62d93ac |
| 23:37:10 | boyscout | * Remove stale binding excludes; a482b17 |
| 23:37:45 | evan | ok, now to work on __FILE__ |
| 23:38:10 | zenspider | what's wrong with it? |
| 23:38:21 | zenspider | I eyeballed it the other day and it looked ok |
| 23:38:24 | evan | it reports the path to the file when compiled |
| 23:38:26 | evan | not when run |
| 23:38:53 | evan | cd lib; rbx compile test.rb; cd ..; rbx lib/test.rb # => "test.rb" |
| 23:39:03 | evan | it breaks the |
| 23:39:08 | evan | $0 == __FILE__ |
| 23:39:13 | evan | idiom in a few places |
| 23:39:23 | evan | and we've hit it already in a few places |
| 23:39:25 | evan | as a gotcha |
| 23:39:35 | zenspider | ouch. right... |
| 23:39:41 | zenspider | I missed that part. :) |
| 23:39:44 | evan | :) |
| 23:39:51 | evan | i'm going to disable the parser from doing it |
| 23:39:52 | moofbong leaves the room. | |
| 23:40:02 | evan | and just fill it in from runtime info entirely |
| 23:42:02 | zenspider | uh oh |
| 23:42:16 | zenspider | I've got a 'plosion on the latest pull |
| 23:42:27 | evan | eh? |
| 23:42:33 | zenspider | sigbus |
| 23:42:37 | zenspider | sec |
| 23:42:58 | zenspider | http://rafb.net/p/5jI6EZ27.html |
| 23:43:01 | zenspider | |
| 23:43:22 | evan | hrm |
| 23:43:23 | evan | thats new. |
| 23:43:32 | zenspider | your last build had a failure, but it at least finished |
| 23:44:15 | evan | the failure was the process specs |
| 23:44:17 | evan | AGAIN. |
| 23:44:56 | zenspider | yeah. they seem evil |
| 23:45:03 | zenspider | should I push anyhow? |
| 23:45:09 | evan | probably fine |
| 23:45:10 | evan | yeah. |
| 23:45:35 | zenspider | ok. I seem to have gotten farther |
| 23:46:52 | boyscout | 2 commits by Ryan Davis |
| 23:46:53 | boyscout | * removed remove_method_excludes.txt; c055a59 |
| 23:46:54 | boyscout | * Clarified undef/remove specs a bit.; 08cb274 |
| 23:46:59 | eventualbuddha enters the room. | |
| 23:47:07 | dodecaphonic_ enters the room. | |
| 23:47:27 | turtletime enters the room. | |
| 23:48:50 | zenspider | huh... I don't think that has one of my commits... checking |
| 23:49:15 | rubuildius | Evan Phoenix: 62d93ac79; 4473 examples, 16827 expectations, 1 failure, 0 errors; http://rafb.net/p/lZXiNM99.html |
| 23:55:36 | Defiler | sweeet |
| 23:55:36 | Defiler | http://rafb.net/p/xCzFbN60.html |
| 23:55:53 | evan | nice |
| 23:55:54 | Defiler | That has gotten a lot faster in the last month |
| 23:56:20 | zenspider | and yet, the number of specs is rocketing |
| 23:56:32 | Defiler | Everybody wins |
| 23:56:45 | zenspider | I've been running `rake todo` and pounding on what I can |
| 23:56:57 | zenspider | I suggest you guys do too... it is a nice way to look at it |
| 23:57:08 | evan | zenspider: i think i'll do a little every day |
| 23:57:13 | evan | in addition to the new work i need to do |
| 23:57:15 | evan | like __FILE__, etc. |
| 23:57:30 | defunkt enters the room. | |
| 23:58:54 | zenspider | is anyone addressing the rdoc issue? |
| 23:59:07 | evan | not at present |
| 23:59:08 | pauldix enters the room. | |
| 23:59:12 | evan | at least, i'm not aware of it. |
| 23:59:16 | rubuildius | Ryan Davis: c055a5981; 4479 examples, 16835 expectations, 1 failure, 0 errors; http://rafb.net/p/HS46rG40.html |
| 23:59:48 | zenspider | I wouldn't have to ask half the q's I do if there were rdoc on the new methods |