Show enters and exits. Hide enters and exits.
| 00:00:54 | slava | dgtized: its an article about macruby, not rubinius though |
| 00:03:19 | jptix | yakischloba: you don't think jruby is among the primary implementations? |
| 00:03:44 | yakischloba | jptix: *sigh* that was definitely not what I was insinuating |
| 00:15:45 | brixen | are the core foundation classes thread safe? |
| 00:15:53 | brixen | ie in the same way Java's are |
| 00:16:06 | brixen | the DT invariants hold but your code may have races etc |
| 00:16:54 | brixen | (I can't write core foundation without thinking of asimov :) |
| 00:22:08 | evan | brixen: I highly doubt core foundation classes are thread safe |
| 00:22:18 | evan | and thus, i'm betting it's very easy to segfault macruby |
| 00:22:50 | brixen | yeah, I was wondering about that |
| 00:22:50 | evan | played hooky this afternoon and went to transformers |
| 00:22:57 | brixen | heh, how was it |
| 00:23:10 | brixen | haven't decided whether to watch it in theatre yet |
| 00:23:25 | evan | it was "GIANT ROBOTS FIGHTING OTHER GIANT ROBOTS" |
| 00:23:27 | evan | as I expected. |
| 00:23:34 | brixen | no way! |
| 00:23:41 | evan | seriously! |
| 00:23:51 | brixen | heh |
| 00:24:15 | evan | http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/Threa dSafetySummary.html |
| 00:24:39 | brixen | ahh |
| 00:24:55 | brixen | heh "Immutable objects are generally thread-safe." |
| 00:24:57 | brixen | no way |
| 00:25:30 | evan | way! |
| 00:25:34 | brixen | interesting, put cocoa into multithreaded mode |
| 00:25:41 | evan | "Giant robots generally consider city-unsafe." |
| 00:25:42 | evan | WAY. |
| 00:25:50 | evan | considered |
| 00:26:25 | brixen | hmm, NSMutableString not generally thread-safe |
| 00:26:40 | brixen | but NSArray is |
| 00:27:21 | brixen | eww, is this current? "Of course, when using immutable objects, you still need to remember to use reference counts correctly. If you inappropriately release an object you did not retain, you could cause an exception later. |
| 00:27:50 | evan | course |
| 00:27:52 | evan | silly huh. |
| 00:28:16 | brixen | well, I'm happy to see MacRuby passes the thread specs |
| 00:28:29 | brixen | I look forward to seeing it pass the specs in general |
| 00:28:34 | evan | yep |
| 00:30:07 | brixen | somehow, this line feels like a contradiction of what I read above in that page |
| 00:30:10 | brixen | "Core Foundation is sufficiently thread-safe that, if you program with care, you should not run into any problems related to competing threads." |
| 00:30:20 | brixen | seems like plenty to watch out for |
| 00:30:30 | brixen | which means things to overlook |
| 00:30:35 | brixen | which means human errors |
| 00:31:04 | brixen | I guess for certain values of "program with care" |
| 00:33:31 | evan | well |
| 00:33:39 | evan | especially because ruby programmers don't use mutexs |
| 00:33:40 | evan | generally. |
| 00:34:14 | brixen | mu-what? |
| 00:34:16 | brixen | heh |
| 00:40:07 | evan | exactly |
| 00:40:32 | evan | they use them when their high level logic needs orchestrating |
| 00:40:37 | evan | not when they use a string in 2 threads |
| 00:42:15 | brixen | yep |
| 00:42:44 | brixen | I think that's basically what charles was referring to |
| 00:43:13 | brixen | he didn't get the warmest response via twitter |
| 00:44:34 | evan | response where? |
| 00:46:09 | ddub | there is that whole bridges being set on fire thing |
| 00:46:33 | evan | who needs bridges WHEN YOU CAN FLY |
| 00:46:57 | ddub | I think the macruby folk took his attitude toward benchmarking, then the whole 'macruby is a fork' the wrong way |
| 00:47:07 | ddub | and now read his posts with FUD-colored glasses |
| 00:47:16 | ddub | is not sure what color FUD is |
| 00:49:12 | brixen | evan: http://twitter.com/MacRuby/status/2407895158 and http://twitter.com/MacRuby/status/2407928178 |
| 00:50:00 | evan | yeah, i found them. |
| 00:59:22 | evan | ARG |
| 00:59:29 | evan | why is popen hanging?! |
| 00:59:32 | evan | GR |
| 01:27:06 | evan | DAMNIT. |
| 01:27:17 | evan | shakes his fist towards cleveland |
| 01:27:28 | evan | thats why LeBron, my new god, lives. |
| 01:27:35 | evan | seems that doing |
| 01:27:41 | evan | signal(SIGPIPE, SIG_IGN); |
| 01:27:49 | evan | pretty much breaks IO in interesting ways. |
| 01:36:10 | brixen | hmm |
| 01:37:16 | brixen | I never actually knew what SIGPIPE was for before |
| 01:37:33 | evan | well, i can tell ya this |
| 01:37:42 | evan | yes, the unix command |
| 01:37:52 | evan | will not exit if SIGPIPE is ignored |
| 01:38:04 | evan | because it uses the default SIGPIPE handler |
| 01:38:07 | evan | which exits the process |
| 01:38:17 | evan | and if you fork and exec yes |
| 01:38:23 | evan | the signal handlers are inherited |
| 01:38:39 | brixen | interesting |
| 01:39:11 | brixen | so, is this wikipedia page wrong when it says "One can ignore SIGPIPE (using, for example, the signal system call). In this case, all system calls that would cause SIGPIPE to be sent will return -1 and set errno to EPIPE." ? |
| 01:39:31 | evan | one can do that |
| 01:39:33 | evan | but yes does not! |
| 01:39:44 | brixen | ahh |
| 01:39:46 | evan | to avoid this future situation |
| 01:40:01 | evan | i think i'm going to have perform_exec reset all signal handlers |
| 01:40:47 | brixen | what were they thinking making 'yes' a command? |
| 01:40:58 | brixen | it makes for very hard to grok sentences at first glance |
| 01:42:11 | evan | i'll refer to it as yes(1) |
| 01:42:17 | brixen | heh |
| 01:42:19 | brixen | that works! |
| 01:42:25 | evan | hahahah |
| 01:42:28 | evan | from the man page |
| 01:42:35 | evan | SYNOPSIS yes [expletive] |
| 01:42:40 | evan | DESCRIPTION yes outputs expletive, or, by default, ``y'', forever. |
| 01:42:45 | evan | ie |
| 01:42:51 | evan | #> yes fuck |
| 01:42:54 | evan | outputs "fuck" forever. |
| 01:42:58 | brixen | heh |
| 01:43:39 | brixen | I like "be repetitively affirmative" |
| 01:43:53 | brixen | should make for some good insults |
| 01:44:14 | evan | #> yes please |
| 01:44:15 | brixen | "dammit, what are you, the yes command? you are being repetitively affirmative" |
| 01:44:55 | brixen | #> yes no |
| 01:45:01 | evan | confused |
| 01:45:03 | evan | confused |
| 01:45:03 | evan | confused |
| 01:45:04 | evan | :D |
| 01:45:05 | brixen | heh |
| 01:45:22 | brixen | dammit, almost spit water on my laptop |
| 01:45:59 | evan | hah |
| 01:46:13 | evan | ok, so, i'm going to tag 2 thread specs |
| 01:46:21 | brixen | k |
| 01:46:27 | evan | or make us not_compliant |
| 01:46:33 | evan | because the behavior contradicts itself. |
| 01:47:24 | evan | mainly |
| 01:47:45 | evan | the behavior as it relates to how exceptions are handled when a thread is "dying" |
| 01:48:49 | evan | hi ben. |
| 01:49:04 | evan | ok |
| 01:49:18 | evan | the FTP specs are being unhappy. |
| 01:49:51 | benschwarz | whatup ev |
| 01:50:17 | brixen | probably because they have to sit next to the HTTP specs all day |
| 01:50:31 | evan | and get neglected. |
| 01:50:38 | brixen | yep |
| 01:50:44 | brixen | who wants FTP |
| 01:50:59 | benschwarz | not me |
| 01:51:15 | benschwarz | ftp is like the fat sister |
| 01:51:19 | brixen | heh |
| 01:56:19 | evan | UG. |
| 01:56:36 | evan | these FTP server specs leave something to be desired. |
| 01:56:38 | evan | mainly, the server. |
| 14:21:31 | morris1 | rubinius does not try to cope with ruby 1.9 language stuff, correct? |
| 14:37:49 | morris1 | what are the "components borrowed" from MRI, currently? |
| 14:39:31 | morris1 | is there a way to create a sort of sandbox (like a sub-instance of rubinius) in rubinius? |
| 14:57:55 | morris1 | is just cloned rubinius from git, "rake" gives: rake aborted! no such file to load -- rakelib/git |
| 14:59:19 | sbryant_work | morris1: rubinius is still matching 1.8.6 |
| 15:00:10 | sbryant_work | As for as spawning new multiple vms' from a vm, not sure. |
| 15:00:32 | sbryant_work | There's a bunch of readmes for building |
| 15:43:08 | dbussink | morris1: weird, i do have that file |
| 15:43:39 | morris1 | its not a rubinius problem, so nevermind :) was myself having a screwed up ruby environment |
| 15:51:32 | dbussink | morris1: btw, there has been support for multiple vm's, but i don't know what state it is |
| 17:32:56 | evan | morning. |
| 18:22:58 | sbryant_work | Afternoon |
| 18:25:21 | evan | sbryant_work: how are you today? |
| 18:26:01 | sbryant_work | Terrible. |
| 18:26:09 | sbryant_work | This application is making me angry. |
| 18:26:24 | evan | thats too bad. |
| 18:26:33 | sbryant_work | Yeah, more and more things are just plain wrong with it. |
| 18:28:34 | sbryant_work | I'm trying to rip out a custom mailer solution and replace it with ActionMailer |
| 18:29:24 | sbryant_work | But everything is tied to the state of the controller |
| 18:29:30 | sbryant_work | Which is just strange. |
| 18:29:41 | evan | sounds... unfun. |
| 18:30:18 | sbryant_work | it is. |
| 18:30:34 | sbryant_work | I'd love to work on something else |
| 18:31:00 | sbryant_work | And when I'm done with this at the end of the day I don't even want to touch code because of how unfun this is. |
| 18:32:24 | evan | :( :( :( |
| 18:32:30 | evan | on the up side! |
| 18:32:45 | evan | i'm going to do a little experiment |
| 18:33:05 | evan | i'm going to lace Fixnum addition inline code with using the uncommon code |
| 18:33:27 | evan | that should give LLVM a clear alias path |
| 18:33:56 | evan | and I believe something like a + b + c should result in some simple code |
| 18:34:00 | evan | testing now! |
| 18:34:08 | evan | actually, testing in a sec! |
| 18:34:54 | sbryant_work | Nice. |
| 18:37:13 | sbryant_work | What is going on with the jit failures? |
| 18:38:48 | evan | i dunno |
| 18:38:53 | evan | i'm going to check it out soon |
| 18:39:13 | sbryant_work | And I just found a disparity in rails. |
| 18:39:35 | sbryant_work | or at least I think |
| 18:39:39 | sbryant_work | Today is not going well |
| 18:42:50 | dbussink | sbryant_work: you usually know a crappy day right from the start |
| 18:44:55 | sbryant_work | Yeah. |
| 18:44:57 | sbryant_work | Today is one. |
| 18:45:02 | sbryant_work | I blame the great night I had. |
| 18:46:06 | evan | could be. |
| 18:46:37 | dbussink | hehe |
| 19:38:32 | sbryant_work | Finally. This finally works! |
| 19:39:03 | brixen | I think the number of compilation errors a statically typed language compile finds is misleading because the syntax usually has way more things to trip you up |
| 19:40:23 | brixen | that said, I find potion's syntax terrible http://hackety.org/potion/ |
| 19:40:30 | brixen | especially the block example |
| 19:41:52 | evan | yeah, i don't really like the look either. |
| 19:42:47 | brixen | whether . is used in english as a separator or full stop is mostly irrelevant |
| 19:42:57 | brixen | decoding the white space takes way too much time |
| 19:44:17 | evan | agreed |
| 19:44:31 | evan | to me, white space seperates to independent elements |
| 19:44:39 | evan | s/to/two/ |
| 19:45:23 | sbryant_work | _why is so crazy |
| 19:46:05 | brixen | I looked up 'so crazy' in the dictionary. it said, see _why |
| 19:51:31 | sbryant_work | brixen: well yeah but that's _why for ya |
| 19:56:04 | brixen | heh, yeah |
| 21:02:47 | boyscout | Reforge local access to use StackVariales - 448c0a5 - Evan Phoenix |
| 21:02:47 | boyscout | Merge branch 'vs_internal' - a7024cd - Evan Phoenix |
| 21:03:09 | evan | there we go |
| 21:03:11 | evan | ! |
| 21:03:25 | brixen | copy-pastes from #rubyspec |
| 21:03:35 | brixen | yeah, lunch for me too |
| 21:03:48 | evan | now a method can manipulate it's own locals quickly |
| 21:03:59 | brixen | sweet |
| 21:04:11 | evan | and accessing a parent's locals is slower |
| 21:04:13 | evan | the way it should be. |
| 21:14:32 | boyscout | CI: a7024cd success. 2723 files, 10827 examples, 33840 expectations, 0 failures, 0 errors |
| 22:13:45 | brixen | evan: bin/mspec ci -B full ... Finished in 39.235279 seconds |
| 22:14:05 | evan | YAY!! |
| 22:14:10 | brixen | heh |
| 22:14:36 | brixen | so, when you have a minute, could you write up a list of all the things off the top of your head we need to fix with the GC |
| 22:15:18 | brixen | ~10 million method calls is about the same time cost as 15,000 allocations |
| 22:15:36 | evan | oh interesting |
| 22:15:36 | evan | ok |
| 22:16:21 | brixen | I wrote the Array::Iterator in pure ruby, and while the method call count went up about 1m, the time I saved from shaving > 10 million calls got eaten |
| 22:16:33 | brixen | I've redone it as primitives for now |
| 22:16:44 | brixen | it's really easy to implement either way actually |
| 22:16:51 | brixen | I might leave the ruby code in as comments |
| 22:17:23 | evan | surely |
| 22:17:40 | brixen | so, there appear to be a ton of bugs in Array |
| 22:17:55 | brixen | almost no code that loops respects the @start slot |
| 22:18:03 | brixen | just loops from 0 to @total |
| 22:18:07 | brixen | @total being size |
| 22:18:17 | brixen | so, having an Iterator will help with this |
| 22:18:36 | brixen | and allow experimenting with other Array structures possibly |
| 22:18:50 | brixen | just need to keep the Iterator#next invariant |
| 22:19:35 | evan | um |
| 22:19:37 | evan | ug. |
| 22:19:38 | evan | that sucks. |
| 22:19:39 | evan | :/ |
| 22:19:49 | evan | i found some bugs in our IO buffering yesetrday |
| 22:19:56 | evan | not sure why they suddenly appeared |
| 22:19:58 | evan | likely timing |
| 22:20:04 | brixen | interesting |
| 22:20:07 | evan | because they showed up in the FTP specs |
| 22:20:19 | evan | which writes to sockets between 2 threads |
| 22:20:30 | brixen | ahh |
| 22:28:56 | dgtized | brixen: I think what we need with the Array code is the standard external behavior tests in rspec, but we also need some internal specs for sizing / resizing / start point behavior |
| 22:30:44 | dgtized | brixen: and secondly what is the code that is not respecting @start, is it stuff that is external to array? |
| 22:30:47 | brixen | I have tests/specs |
| 22:31:42 | evan | nothing external to array should look at @start |
| 22:32:08 | dgtized | right, it should all use get which respects start, so that's what I'm confused about what's broken |
| 22:32:20 | dgtized | sorry aref I mean |
| 22:32:35 | evan | i don't know what you're saying |
| 22:33:56 | dgtized | brixen just said there was a bunch of code that loops from 0 to @total, and I'm pretty sure all the code in Array itself loops from @start to @total unless it's initializing a new Array and then it knows for certain it can go from 0 to @total |
| 22:34:08 | dgtized | so I'm trying to find out what code he is referring to that doesn't |
| 22:34:34 | evan | ok. |
| 22:35:07 | dgtized | and for external looping it all uses Array#at which uses Primitive#array_aref which respects the @start variable as well |
| 22:36:38 | brixen | well, le'see... does rindex allocate an array? |
| 22:36:39 | brixen | no |
| 22:36:47 | brixen | does it loop from @total |
| 22:36:50 | brixen | -1 to 0 |
| 22:36:51 | brixen | yes |
| 22:37:26 | dgtized | but it uses at which respects @start |
| 22:37:38 | brixen | huh? |
| 22:37:47 | dgtized | it's using Array#at to access each member |
| 22:37:52 | brixen | so? |
| 22:38:03 | dgtized | Array#at does a index + @start in order to get that element |
| 22:38:10 | brixen | and? |
| 22:38:40 | brixen | that's a serious mismatch between algos |
| 22:38:49 | brixen | and brittle if one part changes |
| 22:38:53 | brixen | that's my point |
| 22:39:35 | evan | if it uses Array#at() |
| 22:39:38 | evan | it should not look at the ivars |
| 22:39:42 | evan | it should use size |
| 22:40:04 | brixen | right |
| 22:40:29 | dgtized | ok, that makes sense, my guess is there are a number that use @total instead of size, but I'm pretty sure everything that uses a loop from 0 to @total is using at to access each index |
| 22:41:00 | evan | using size is almost the same as using @total now |
| 22:41:02 | evan | with the JIT |
| 22:41:03 | dgtized | brixen: do you want to clean those up, or do you want me to do it? |
| 22:43:05 | brixen | leave it |
| 22:43:10 | brixen | I just said I'm working on it |
| 22:45:02 | dgtized | the other thing is most of those loops were inlined because at the time using each was killing us in speed, it's possible a lot of those are fast enough now |
| 22:45:53 | evan | that code should try not to use each |
| 22:46:06 | evan | for a while still |
| 23:01:02 | evan | mmm |
| 23:01:06 | evan | uncommon traps |
| 23:01:07 | evan | love them. |
| 23:01:58 | morris1 | do you somehow create html docs from the markdown stuff in /doc ? |
| 23:03:00 | brixen | morris1: not yet, but it's planned |
| 23:03:06 | brixen | morris1: also, see rake -T doc |
| 23:03:24 | brixen | there's some tasks for creating the doxygen docs for the C++ code |
| 23:03:33 | brixen | but I think they need some help |
| 23:17:33 | boyscout | Add guards for Symbol and Fixnum - f9bd0dc - Evan Phoenix |
| 23:20:43 | boyscout | CI: f9bd0dc success. 2723 files, 10827 examples, 33840 expectations, 0 failures, 0 errors |