Show enters and exits. Hide enters and exits.
| 06:57:25 | boyscout | Adjust checking for GCC version to build on Fedora 8. - a707475 - Brian Ford |
| 07:01:27 | postmodern | damn people still run fedora 8 :P |
| 07:01:49 | brixen | postmodern: yeah, right |
| 07:01:55 | brixen | like, fedora 13 is out :) |
| 07:02:13 | postmodern | thats what im running on my netbook |
| 07:03:41 | postmodern | ironically they now ship with openssl 1.0.0 |
| 07:03:54 | postmodern | which breaks ruby 1.8.x and 1.9.1 in half |
| 07:04:02 | postmodern | if you try compiling them against the system openssl |
| 07:04:10 | brixen | ugh |
| 07:04:15 | postmodern | 1.9.2, jruby and i think rubinius compile just fine |
| 07:04:17 | brixen | do the ruby packages work? |
| 07:04:24 | postmodern | oh yeah |
| 07:04:31 | postmodern | fedora13 still provides ruby 1.8.6 |
| 07:04:37 | brixen | lovely |
| 07:04:41 | postmodern | which i hate having to install, just to compile rubinius |
| 07:04:48 | brixen | I know :P |
| 07:04:54 | brixen | you're near the top of my list |
| 07:04:55 | postmodern | rage furry |
| 07:05:06 | brixen | in fact, probably tomorrow I'll get 1.9.x building |
| 07:05:10 | postmodern | oh uh |
| 07:05:35 | brixen | wait, it is tomorrow |
| 07:05:38 | brixen | later today :) |
| 07:05:50 | postmodern | nice! |
| 07:06:33 | boyscout | Added stub weakref.rb. Closes #368. - a49a7b8 - Brian Ford |
| 07:18:59 | boyscout | CI: rubinius: a707475 successful: 3455 files, 13599 examples, 41163 expectations, 0 failures, 0 errors |
| 07:27:05 | brixen | hmm, I wonder if we should put a canary symbol in C exts when we compile and only load them if that symbol exists |
| 07:27:18 | brixen | to avoid this problem of ppl loading MRI C ext is rbx |
| 07:27:26 | brixen | s/is/in/ |
| 07:29:29 | boyscout | C-API specs for rb_to_int. - ad5af4b - Brian Ford |
| 07:29:29 | boyscout | Added rb_to_int. Closes #367. - 234f095 - Brian Ford |
| 07:39:01 | boyscout | CI: rubinius: 234f095 successful: 3455 files, 13599 examples, 41163 expectations, 0 failures, 0 errors |
| 16:01:55 | brixen | morning |
| 16:02:14 | evan | morning. |
| 16:03:05 | brixen | so, add __getobj__ alias to WeakRef? |
| 16:03:12 | brixen | #370 |
| 16:05:13 | evan | sure |
| 16:05:34 | evan | i wonder if anyone will report that WeakRef isn't a Delegate |
| 16:05:40 | evan | i really don't want it to be. |
| 16:05:50 | brixen | tell em too bad :) |
| 16:06:26 | brixen | going to this talk this morning http://www.galois.com/blog/2010/06/11/tech-talk-introducing-well-founded-recursion/ |
| 16:07:12 | brixen | evan: re #346, lib/io/nonblock.rb looks fine to add, lib/io/wait is a C ext |
| 16:07:23 | evan | yeah, i was looking at them. |
| 16:07:25 | brixen | do we want to rewrite wait.c or try to make it work? |
| 16:07:33 | evan | welp. |
| 16:07:49 | evan | no one has requested it |
| 16:07:53 | evan | so lets just do nonblock.rb for now. |
| 16:07:57 | brixen | ok |
| 16:08:01 | evan | i don't know why they're in the same directory |
| 16:08:04 | evan | they're totally unrelated. |
| 16:08:14 | brixen | heh |
| 16:08:25 | brixen | they are IO-y or something |
| 16:09:29 | brixen | BrianRice-work: galois this morning? |
| 16:09:43 | BrianRice-work | brixen, hm |
| 16:10:24 | brixen | BrianRice-work: I got conceptual mathematics, looks great |
| 16:10:28 | BrianRice-work | brixen, I'll pass on this one. I'm probably too familiar with the principles |
| 16:10:47 | brixen | heh, yeah, not exactly an advanced topic |
| 16:10:52 | BrianRice-work | oh, that book should be a breeze for the most part |
| 16:10:53 | brixen | it's only 5 min away for me |
| 16:11:02 | BrianRice-work | half hour from here :/ |
| 16:11:28 | brixen | CM is a lot more text-bookie than category theory for computer scientists |
| 16:12:24 | brixen | but the extra hand-holding is appreciated at this point |
| 16:12:37 | BrianRice-work | ok |
| 16:12:53 | BrianRice-work | it's kind of a prototype of a book it wants to be, math-from-scratch |
| 16:17:28 | evan | brixen: i, hopefully, have this signal stuff sorted out. |
| 16:17:40 | evan | there are so many moving parts. |
| 16:18:14 | evan | and the fact that you can't use a pthread_mutex / pthread_cond in a signal handler is the suck. |
| 16:20:21 | brixen | yeah, sounds crazy fun |
| 17:24:46 | boyscout | CI: rubinius: 277cca2 successful: 3455 files, 13599 examples, 41163 expectations, 0 failures, 0 errors |
| 18:23:58 | kronos_vano | Hi everyone |
| 18:26:30 | brixen | hi kronos_vano |
| 18:26:48 | kronos_vano | brixen, I find new case when Bignum#>> is wrong) |
| 18:28:31 | brixen | excellent :) |
| 18:36:19 | kronos_vano | hm... it's known issue. |
| 18:36:25 | kronos_vano | brixen, http://gist.github.com/439486 why ? |
| 18:36:30 | kronos_vano | it's from rubyspec |
| 18:36:38 | kronos_vano | It's easy to fix that |
| 18:38:43 | evan | no |
| 18:38:48 | evan | don't change that. |
| 18:39:09 | kronos_vano | np, but i want to know the reason |
| 18:39:26 | evan | MRI has a crazy boundary case there |
| 18:39:35 | evan | it will fail if the argument doesn't fit in a long |
| 18:39:46 | evan | so a very tiny subset of Bignums are accepted |
| 18:40:01 | evan | we decided to have a easy, strict boundary |
| 18:40:15 | evan | that was decided after fighting with that code a lot. |
| 18:40:30 | kronos_vano | ok. |
| 18:40:42 | kronos_vano | brixen, never mind |
| 18:42:37 | brixen | kronos_vano: hm, that commit should have an explanation |
| 18:42:43 | brixen | but anyway, we can document that |
| 18:43:12 | brixen | kronos_vano: but rule of thumb, if I committed it to rubyspec, always double-check with me :) |
| 18:43:23 | kronos_vano | :) |
| 18:43:54 | evan | 100% of deviates_on guards have a good story associated with them. |
| 18:44:07 | evan | because thats not a failure |
| 18:44:11 | evan | thats a deliberate decision. |
| 18:45:00 | brixen | I just checked the commit, I didn't explain in the commit msg |
| 18:45:11 | brixen | usually I do, and I'll try to in the future |
| 18:45:28 | evan | we forgive you brixen. |
| 18:45:38 | evan | we should powwow about pack |
| 18:45:45 | evan | i think it's quickly becoming "the thing" |
| 18:46:43 | kronos_vano | evan, you mean Array#pack? |
| 18:46:53 | evan | yeah |
| 18:46:56 | evan | and String#unpack. |
| 18:47:21 | kronos_vano | I refactor one in ruby, but it is still slow |
| 18:47:35 | evan | brixen and I have a solution. |
| 18:47:39 | kronos_vano | ragel? |
| 18:47:39 | evan | we just need to implement it. |
| 18:47:45 | brixen | yeah |
| 18:48:06 | brixen | I can start on that today actually |
| 18:48:15 | brixen | I want to get 1.9 building |
| 18:48:29 | kronos_vano | brixen, if you implement one of them I can implement another one. |
| 18:48:32 | kronos_vano | ;) |
| 18:48:54 | brixen | evan: this cool? http://gist.github.com/439509 |
| 18:49:25 | brixen | kronos_vano: I need to get the infrastructure in place, then we can implement them one at a time easily |
| 18:49:32 | brixen | doing the most important ones first |
| 18:49:41 | evan | why not call the prim method __setobj__ ? |
| 18:49:52 | evan | and alias it to object= |
| 18:50:02 | brixen | evan: sure, I was going with __object__ |
| 18:50:04 | kronos_vano | brixen, ok |
| 18:50:05 | brixen | I can change it |
| 18:50:24 | evan | the inferfacing being what it is, just do the simplest thing. |
| 18:50:25 | brixen | I mean, I was going with the convention with __object__ vs __getobj__ |
| 18:50:44 | brixen | do you want to change __object__ to __getobj__ ? |
| 18:50:57 | evan | no |
| 18:51:00 | evan | because we use __object__ |
| 18:51:09 | evan | as I recall. |
| 18:51:14 | brixen | but we could invoke_primitive there |
| 18:51:18 | evan | nah. |
| 18:51:21 | brixen | instead of wrapping it |
| 18:51:22 | brixen | ok |
| 18:51:24 | evan | no no. |
| 18:53:21 | brixen | evan: http://gist.github.com/439509 |
| 18:53:46 | brixen | also, :weakref_set_object should not be a safe primitive, or should it? |
| 18:54:05 | brixen | I really need to document primitives |
| 18:54:52 | evan | that looks fine |
| 18:54:57 | brixen | k |
| 18:55:03 | evan | the safe prim stuff is not well used or documented. |
| 18:55:10 | brixen | yeah |
| 18:55:11 | evan | i'm not positive it has much benefit |
| 18:55:16 | evan | so i haven't used it much. |
| 18:55:22 | brixen | ok |
| 18:55:30 | evan | it just simplifies the glue code is all |
| 18:55:35 | brixen | I had to go figure out what + did |
| 18:55:38 | evan | but it just eliminates one condition |
| 18:55:41 | brixen | I had forgotten |
| 18:55:42 | brixen | yep |
| 18:55:58 | evan | it's hard to see that one condition effecting much |
| 18:56:02 | evan | except in a tight loop |
| 18:56:04 | evan | even then, it's hard. |
| 18:56:05 | brixen | right |
| 18:56:11 | evan | esp now that we've got the JIT |
| 18:56:26 | evan | well, we had the JIT then |
| 18:56:42 | evan | most of the pure prims (Fixnum#+, etc) are JIT custom logic now |
| 18:56:44 | evan | which is better. |
| 18:57:13 | brixen | yeah |
| 18:59:01 | brixen | I have yet to be able to reserve an iphone |
| 18:59:18 | brixen | someone needs to introduce apple and at&t to the cloud :) |
| 18:59:28 | evan | oh oh |
| 18:59:33 | brixen | I even went to an apple store on the way to this coffee shop |
| 18:59:35 | evan | use the iphone Apple Store app |
| 18:59:36 | evan | it works |
| 18:59:43 | evan | the website doesn't. |
| 18:59:44 | brixen | I tried |
| 18:59:48 | evan | abby and I reserved ours |
| 18:59:49 | evan | oh ? |
| 18:59:51 | brixen | it took my info and just sits ther |
| 18:59:56 | evan | oh noes! |
| 19:00:26 | brixen | no confirmation or anything |
| 19:00:38 | evan | :( |
| 19:00:39 | brixen | now when I click on the iphone 4 button, nothing happens |
| 19:00:42 | brixen | heh |
| 19:00:43 | brixen | lame |
| 19:01:31 | brixen | the punks at the store are hilarious |
| 19:02:36 | brixen | "yeah sorry dude good luck" in response to my suggestion that apple should have gotten the data from at&t and handled the whole transaction |
| 19:03:19 | brixen | also "you're welcome to wait around here" when the reserve button fails to load a page |
| 19:03:41 | evan | hah |
| 19:03:42 | evan | :( |
| 19:03:47 | brixen | heh |
| 19:04:22 | brixen | I'm looking forward to some facetime... with steveo |
| 19:04:36 | evan | tell him that perhaps webobjects is past it's prime. |
| 19:04:41 | brixen | heh |
| 19:04:47 | Zoxc | why would you buy a iPhone? =P |
| 19:04:50 | evan | and that webobjects shouldn't be apples core competecy anymore. |
| 19:05:12 | brixen | Zoxc: because it kicks ass on every other device out there |
| 19:05:39 | brixen | Zoxc: and because my subversive strategy is to continue buying apple to force linux to actually make interfaces |
| 19:06:07 | brixen | ubuntu 10.04 is pretty good |
| 19:06:55 | brixen | hopefully they continue the apparent strategy of not trying to emulate Windoze and trying to emulate Mac instead |
| 19:07:21 | brixen | next up, get rid of menu-per-app horrid design crap |
| 19:07:32 | evan | ok, think i'm ready to say that the new signal code is good enough. |
| 19:07:50 | brixen | zweet! |
| 19:08:03 | evan | but thats all i'll admit to. |
| 19:08:05 | evan | good enough. |
| 19:08:47 | Zoxc | Ubuntu needs less Mac and huge interfaces =P |
| 19:08:52 | boyscout | Conform WeakRef API to MRI. Closes #370. - 3fca490 - Brian Ford |
| 19:09:29 | brixen | Zoxc: what exactly do you mean? what is a huge interface? Win7 start menu? |
| 19:17:10 | Zoxc | Ubuntu/Gtk/Mac has huge fonts/interfaces |
| 19:21:11 | boyscout | CI: rubinius: 3fca490 successful: 3455 files, 13599 examples, 41163 expectations, 0 failures, 0 errors |
| 19:36:04 | BrianRice-work | brixen, quick review of the galois talk? |
| 19:36:54 | brixen | BrianRice-work: heh, you dissuaded me from attending :P |
| 19:37:04 | BrianRice-work | oh, that was not my intention :) |
| 19:37:18 | brixen | actually, I was most interested in seeing agda in practice |
| 19:37:29 | BrianRice-work | ok |
| 19:37:59 | brixen | I tried to reserve an iphone instead, but failed |
| 19:39:01 | BrianRice-work | yeah, a co-worker is going quietly insane in that process. |
| 19:44:08 | evan | I guess I just got lucky. |
| 21:18:47 | somebody | evan, So ruby-head and 1.8 wrong? |
| 21:19:01 | evan | you mean your block ticket? |
| 21:19:05 | kronos_vano | yes |
| 21:19:05 | evan | they're not wrong |
| 21:19:17 | evan | the default scope of methods in a script body is private |
| 21:19:21 | evan | thats what you're seeing. |
| 21:19:35 | evan | if you did that in a class body, the method would be public, since public is the default |
| 21:19:50 | kronos_vano | blk = lambda { def a; puts 'a'; end }; klass = Class.new { blk.call }; klass.new.a |
| 21:20:00 | evan | exactly. |
| 21:20:04 | evan | you're confusing yourself. |
| 21:20:04 | kronos_vano | rubinius outputs 'a' |
| 21:20:08 | evan | i know. |
| 21:20:13 | evan | you're making yourself confused. |
| 21:20:34 | evan | the default visibility of a script is private |
| 21:20:41 | evan | thats why it doesn't work in 1.8 |
| 21:20:47 | evan | there is a bug in rubinius |
| 21:21:02 | evan | the block at the script level is not seeing that it should private visibiity |
| 21:21:12 | evan | i understand the issue |
| 21:21:16 | evan | it's tricky to fix |
| 21:21:23 | evan | i'll work on it this week. |
| 21:21:42 | kronos_vano | is it compiler level issue? |
| 21:21:51 | evan | no. |
| 21:22:02 | evan | until very recently |
| 21:22:09 | evan | we still had public as the script level visibility |
| 21:22:14 | evan | that fix was hard |
| 21:22:18 | evan | so i know this is also going to be a pain. |
| 21:36:16 | nicksieger | config.gems['sinatra'] by itself doesn't modify anything |
| 21:36:24 | nicksieger | whoops wrong ch |
| 21:37:56 | evan | i forgive you. |
| 21:38:03 | evan | besides, you won. |
| 21:38:13 | evan | i hope start lording that over brian and carl soon. |
| 21:45:19 | brixen | there was poor requirements gathering on my part in that contest |
| 21:45:34 | brixen | I thought I had to give the other guy time to respond :) |
| 21:46:38 | evan | heheh |
| 21:56:49 | kstephens | evan: I'm pretty close to having SprintfCompiler finished. |
| 21:57:21 | kstephens | Would you consider a similar technique for pack/unpack? |
| 21:57:30 | evan | mmm |
| 21:57:34 | evan | we've got an idea for them already |
| 21:57:41 | kstephens | cool |
| 23:18:37 | evan | man these signals suck ass. |
| 23:19:00 | brixen | :( |
| 23:21:16 | evan | I thought I had it working |
| 23:21:27 | evan | and now it fails a really simple case that the process#kill specs used |
| 23:24:06 | tarcieri | tony@virtualmac:~/src/gems/idtv (master)$ rvm use rbx |
| 23:24:06 | tarcieri | info: Using rbx 1.0.1 20100603 |
| 23:24:49 | evan | tarcieri: ? |
| 23:25:02 | tarcieri | :D |
| 23:25:19 | tarcieri | heh, sorry, just upgraded |
| 23:27:27 | kstephens | In the past, I resorted to having all signal handlers append to a statically-allocated signal queue and poll the signal queue periodically in a safe/critical section. Kinda sucked but it worked. |
| 23:27:50 | kstephens | Gets around the problem of what is safe to call in a signal handler. |
| 23:28:50 | evan | thats what i'm doing |
| 23:29:01 | evan | the wrinkle is the ability to have the signal interrupt what is going on. |
| 23:29:04 | evan | which has to be supported. |
| 23:30:20 | kstephens | trying to "deliver" the signal to the main thread? |
| 23:30:29 | kstephens | or an arbitrary thread? |
| 23:30:46 | evan | main thread |
| 23:32:37 | kstephens | Maybe spawn a thread (when a signal handler is installed) to poll the signal queue and have it interrupt the main thread? |
| 23:32:56 | evan | yep |
| 23:32:58 | evan | thats what i'm doing :) |
| 23:33:07 | evan | it's still tricky. |
| 23:33:38 | evan | i'm actually use a pipe+select trigger to the other thread |
| 23:37:21 | kstephens | what about using the exception fd_set in select()? Not sure how that would work on a pipe fd or be different than the read fd_set. |
| 23:37:29 | evan | FUDGE |
| 23:37:31 | evan | tries something. |
| 23:38:38 | evan | if I just fixed it |
| 23:38:40 | evan | it's going to be funny. |
| 23:38:44 | evan | we'll all have a good laugh. |
| 23:38:50 | kstephens | flush(fd)? |
| 23:38:54 | evan | hah |
| 23:38:57 | evan | thankfully, no |
| 23:39:04 | evan | i'm using read/write(2) |
| 23:39:13 | evan | BUT you're close! |
| 23:39:22 | evan | BINGO. |
| 23:39:22 | evan | haha |
| 23:39:24 | evan | hilarious. |
| 23:39:46 | evan | I should have just jabbed my eyes in with a breadstick instead |
| 23:39:47 | evan | anyway |
| 23:39:56 | evan | the test i'm using uses Process.fork |
| 23:40:15 | evan | and in the forked rbx, i restart the background query thread |
| 23:40:20 | evan | but i forgot to recreate the pipe fds |
| 23:40:27 | evan | so it was sharing them with the parent |
| 23:40:32 | brixen | heh |
| 23:40:34 | evan | so the parent would send a signal to the child |
| 23:40:47 | evan | the child would go "oh signal!" and write a byte to it's pipe fd |
| 23:41:00 | evan | at which time the background thread IN THE PARENT would wake up and go |
| 23:41:06 | evan | "um, huh? nothing to do." |
| 23:41:27 | brixen | evan: you should do a skit of that at next railsconf :) |
| 23:41:41 | evan | it's going to end with http://skitch.com/evanphx/n9bc6/cam |
| 23:41:56 | brixen | hah, I knew it |
| 23:44:43 | evan | anyway, perhaps I've got it now. |
| 23:49:02 | kstephens | I always thought libc fork() should have had an at_fork() callback mechanism, like at_exit(). |
| 23:50:54 | evan | there is one |
| 23:50:58 | evan | pthread_at_fork() |
| 23:51:20 | evan | er, whats it called... |
| 23:51:46 | evan | pthread_atfork |
| 23:55:53 | evan | though that function is a mega fail. |
| 23:56:05 | evan | it's arguments are pointers to functions that take no args |
| 23:56:12 | evan | so you have to do everything via global variables. |