Show enters and exits. Hide enters and exits.
| 00:01:52 | jarib | evan: ah, ok |
| 00:02:03 | evan | what version of rack do you have installed in rbx? |
| 00:02:21 | jarib | 1.2.1 |
| 00:02:28 | evan | and in 1.9? |
| 00:02:42 | jarib | 1.1.0 |
| 00:02:45 | jarib | ok |
| 00:02:54 | evan | yep, thats the reason |
| 00:02:59 | evan | please close that issue. |
| 00:03:08 | evan | you're supposed to use Rack::Server now |
| 00:03:09 | evan | i guess. |
| 00:03:59 | jarib | seems so |
| 00:04:55 | jarib | i'm having a hard time isolating the assertion failure |
| 00:05:04 | jarib | lots of moving parts in this code. |
| 00:05:12 | jakedouglas | evan: i discovered that rb_marshal_load is already implemented in capi/util.cpp. should I move rb_marshal_dump to that file, or vice versa? |
| 00:05:18 | evan | jarib: can you make it happen everytime? |
| 00:05:29 | jarib | yes |
| 00:05:54 | evan | jakedouglas: you only list one file |
| 00:06:01 | evan | you can move them out of util.cpp though |
| 00:06:08 | evan | i'm not sure where you're moving them to |
| 00:06:08 | jarib | any clever tricks for gdb in a forked process? |
| 00:06:10 | jakedouglas | evan: i created marshal.cpp in the last commit to implement it. |
| 00:06:11 | evan | but they should be together |
| 00:06:53 | evan | jarib: you can use follow-fork mode |
| 00:06:55 | evan | but it's a pain. |
| 00:07:26 | jarib | i can try |
| 00:07:41 | jarib | alternatively, add something to linkedlist.hpp and recompile maybe? |
| 00:08:45 | jarib | this isn't the only process forked even |
| 00:09:12 | evan | sure |
| 00:09:21 | evan | you can have linkedlist.hpp use rubinius::abort |
| 00:09:24 | evan | which will print out a backtrace |
| 00:09:58 | jarib | instead of the assertion? |
| 00:10:09 | evan | as the assertion |
| 00:10:24 | evan | if(cocondition) rubinius::abort(); |
| 00:10:34 | jarib | ok |
| 00:10:44 | jarib | i'll try that |
| 00:12:55 | jarib | vm/linkedlist.hpp:36:35: error: ârubiniusâ has not been declared |
| 00:13:05 | evan | um |
| 00:13:05 | evan | ok |
| 00:13:11 | evan | you'll have to leave that for me. |
| 00:13:32 | jarib | aye |
| 00:26:02 | boyscout | add capi spec for rb_marshal_load - 5bf23ba - Jake Douglas |
| 00:26:02 | boyscout | move rb_marshal_load to marshal.cpp - 26de7b3 - Jake Douglas |
| 00:34:53 | boyscout | CI: rubinius: 26de7b3 successful: 3503 files, 14374 examples, 42151 expectations, 0 failures, 0 errors |
| 00:35:56 | jakedouglas | evan: for some reason im now getting slayed by the bundler seg fault before i can get to the AR one. not sure why that's different now. |
| 00:36:08 | evan | ok |
| 00:36:22 | evan | i've got a repro for the bundler one |
| 00:36:25 | evan | it's stumping me atm. |
| 00:36:33 | jakedouglas | repro is good :P |
| 00:36:43 | evan | I might work around a symptom without figuring out the cause. |
| 00:37:00 | evan | because i've made it go away |
| 00:37:03 | evan | by changing a few things |
| 00:37:09 | evan | but i don't yet know why those changes cause it to go away. |
| 00:37:12 | evan | it's one of those bugsy. |
| 00:37:14 | evan | bugs. |
| 00:37:17 | evan | it's a bugsy. |
| 00:37:19 | evan | thats a good name. |
| 00:38:21 | jakedouglas | cool. dinner, bbl |
| 00:38:26 | evan | later. |
| 00:45:50 | evan | hrm |
| 00:45:53 | evan | i think i've been chasing my tail. |
| 01:16:56 | slava | brixen: are you guys getting beer later? |
| 01:19:06 | brixen | slava: hey, just thinking about plans |
| 01:19:21 | brixen | what do you have in mind? |
| 01:19:32 | brixen | we're over by F152 |
| 01:19:40 | slava | I'm at powell's |
| 01:19:49 | brixen | that's a long ways away man |
| 01:19:53 | brixen | :) |
| 01:20:21 | brixen | are you going to rogue again? |
| 01:20:30 | slava | no |
| 01:21:29 | brixen | another place? |
| 01:22:22 | slava | do you have anything in mind? |
| 01:22:50 | brixen | possibly making some plans on this side of the river, waiting to hear... |
| 01:23:40 | slava | are you meeting up with ola later? |
| 01:23:53 | brixen | they took off, not sure where they went |
| 01:24:01 | brixen | I'm up for meeting up with them later though |
| 01:24:11 | brixen | I think we're going to grab some dinner near here |
| 01:25:46 | brixen | slava: tweet @ me if you guys pick a place for beer later |
| 01:26:07 | bakkdoor | slava: amos and me will go with brixen i think |
| 01:26:53 | bakkdoor | slava: i'm off for now. we can meet later and drink something. tweet us, like brixen said |
| 01:27:41 | slava | alright |
| 04:41:55 | jakedouglas | sup |
| 07:27:32 | dbussink | morning |
| 07:32:28 | kronos_vano | morning |
| 08:47:18 | kronos_vano | hehe, a = [0]; a.shift; a.delete(nil) makes rubinius cry |
| 08:57:26 | dbussink | kronos_vano: ah, tricky find :) |
| 10:09:40 | kronos_vano | dbussink, it is not mine, #422 ;) |
| 13:06:48 | jarib | heh, still getting these weird Ar failures on my work machine |
| 13:07:11 | jarib | http://gist.github.com/484455 |
| 13:13:20 | dbussink | jarib: no stale files floating around? |
| 13:15:05 | jarib | dbussink: don't think so |
| 13:15:48 | dbussink | jarib: what platform are you on? |
| 13:16:20 | jarib | dbussink: i recall mentioning this before, IIRC it's caused by my Process.uid being pretty high |
| 13:16:24 | jarib | leopard |
| 13:16:41 | jarib | >> Process.uid |
| 13:16:41 | jarib | => 323354445 |
| 13:18:23 | dbussink | huh, how can that happen? |
| 13:20:15 | jarib | i'm not a unix expert, but why wouldn't it happen? |
| 13:20:39 | dbussink | jarib: could be related then yeah, that something caps it |
| 13:20:39 | dbussink | but i wonder what that would be then |
| 13:20:39 | dbussink | jarib: how do you get them that high? :) |
| 13:20:40 | dbussink | well, because they usually start numbering at 1 |
| 13:20:49 | dbussink | and you need to be spawning processes pretty hard for this |
| 13:21:12 | dbussink | and i've never had any above 100000 i think |
| 13:21:37 | jarib | does it have anything to do with processes though? |
| 13:21:52 | jarib | http://en.wikipedia.org/wiki/User_identifier_(Unix) |
| 13:22:06 | jarib | i work in a big company. |
| 13:22:16 | dbussink | well, there's a 323354445 in the gist |
| 13:22:16 | dbussink | ah wait, uid |
| 13:22:16 | dbussink | sorry, read it wrong |
| 13:22:32 | dbussink | probably some domain account then right? |
| 13:22:37 | jarib | probably, yeah |
| 13:22:59 | jarib | funny that wikipedia says "ranging between 0 and 32767" |
| 13:23:40 | dbussink | looks it's an unsigned integer on os x |
| 13:25:19 | dbussink | uid = io.read( 6).to_i |
| 13:25:27 | dbussink | looks like the uid is limited to 6 characters |
| 13:25:29 | dbussink | in kernel/common/ar.rb |
| 13:25:51 | dbussink | you could check if there are more of those hardcoded limits and see if changing them fixes it |
| 13:26:19 | jarib | dbussink: interestingly, doing `id` in the shell says my uid=1000 |
| 13:26:28 | jarib | dbussink: ok, i'll take a look |
| 13:27:31 | jarib | ah |
| 13:27:40 | jarib | never mind the `id` comment. that was an ssh session :P |
| 13:33:53 | jarib | i guess the bug is really in the spec |
| 13:38:42 | dbussink | jarib: well, it's probably in the implementation then too, because it's only reading those 6 characters |
| 13:39:03 | dbussink | which you can see in the spec because it truncates it at 6 characters |
| 13:46:57 | jarib | dbussink: isn't that the ar(5) format though? |
| 13:48:21 | dbussink | jarib: true yeah, but that means that ar files are inherently broken with these huge uid's |
| 13:48:55 | jarib | well, if it's always truncated to 6 chars |
| 13:48:58 | jarib | except in the spec |
| 13:49:06 | jarib | really has no idea |
| 13:53:06 | dbussink | jarib: just get a sane uid on your machine ;) |
| 16:08:15 | evan | We should remove Ar and it's test for now. |
| 16:08:17 | evan | we're not using it. |
| 17:25:32 | evan | huzzah |
| 17:25:40 | evan | slayed a crash bug. |
| 17:27:04 | sbryant | ! |
| 17:27:07 | sbryant | what was the bug? |
| 17:28:21 | evan | frames for jit'd blocks weren't marked as being jit'd frames |
| 17:28:45 | sbryant | ah |
| 17:28:46 | evan | which caused their jit'd code to not be strongly referenced |
| 17:28:59 | evan | which causes the jit'd code to be deleted while the block was still running |
| 17:29:10 | evan | which cause the CPU to run invalid x86 |
| 17:29:32 | sbryant | oh, that would be quite a problem. |
| 17:29:39 | evan | quite. |
| 17:44:40 | boyscout | Make sure a JITd block strongly references it's JITd code. Fixes #413. - bdb802d - Evan Phoenix |
| 17:44:40 | boyscout | Add some code to aid in debug JITd code being destroyed - b3ca6bb - Evan Phoenix |
| 17:50:05 | dbussink | evan: https://gist.github.com/f8a507f74b2aecfec259 shall i commit that? :) |
| 17:51:34 | evan | dbussink: sure |
| 17:55:20 | boyscout | CI: rubinius: b3ca6bb successful: 3503 files, 14374 examples, 42151 expectations, 0 failures, 0 errors |
| 17:55:55 | dbussink | evan: was that the cause of some reported crashes? |
| 17:56:03 | evan | yep |
| 18:00:25 | tarcieri | yay crashfix :) |
| 18:00:30 | evan | :) |
| 18:03:28 | boyscout | Remove Ar since it's not used anymore - 80cbe44 - Dirkjan Bussink |
| 18:03:55 | Defiler | yay less code |
| 18:04:00 | dbussink | jarib: there you go :) |
| 18:04:06 | dbussink | Defiler: removing stuff is always good :P |
| 18:04:07 | tarcieri | a mother from Ar who has lost her 3 kids? |
| 18:12:08 | boyscout | CI: rubinius: 80cbe44 successful: 3498 files, 14361 examples, 42133 expectations, 0 failures, 0 errors |
| 18:15:03 | jarib | dbussink: thanks! |
| 18:15:10 | jarib | what was it intended for? |
| 18:15:42 | evan | we used to have .rba |
| 18:15:51 | evan | which stored .rbc files as one file |
| 18:15:59 | jarib | ah |
| 18:16:05 | evan | but we stopped using them long ago |
| 18:16:11 | evan | and hadn't maintained it for a while |
| 18:16:15 | evan | better to cut it loose |
| 18:16:20 | evan | and come back to it later if we still want it. |
| 18:17:03 | jarib | how's that ruby archive rsoc project going, btw? |
| 18:17:46 | evan | good good |
| 18:17:52 | evan | he's using zip atm. |
| 18:18:02 | jarib | is the code public? |
| 18:18:13 | evan | there is some on github |
| 18:18:17 | evan | he told me he's got it torn apart atm. |
| 18:18:20 | evan | let me find the url. |
| 18:18:26 | jarib | ok |
| 18:18:56 | evan | jarib: http://github.com/byuni/rark |
| 18:19:42 | jarib | thanks |
| 18:22:51 | boyscout | Cleanup old rba task - 0a02737 - Dirkjan Bussink |
| 18:22:52 | boyscout | Remove ar.rbc from load_order.txt - 4f05e29 - Dirkjan Bussink |
| 18:22:53 | dbussink | forgot that :S |
| 18:22:59 | evan | np. |
| 18:23:46 | brixen | dbussink: only shows up after a clean build huh? :) |
| 18:24:38 | jarib | evan: i have some time if you want to look into that linkedlist assertion btw |
| 18:25:02 | evan | jarib: can you repro it? |
| 18:25:28 | jarib | not isolated |
| 18:25:44 | jarib | and not outside the forked child |
| 18:26:04 | jarib | which was why we considered adding rubinius::abort() if the condition failed |
| 18:26:52 | jarib | i could try follow-fork-mode as well. |
| 18:31:28 | boyscout | CI: rubinius: 4f05e29 successful: 3498 files, 14361 examples, 42133 expectations, 0 failures, 0 errors |
| 18:37:11 | jarib | hmm, nvm, doesn't happen on OS X it seems |
| 18:37:24 | jarib | will have to wait until i'm back on linux |
| 18:37:53 | evan | k |
| 18:41:20 | jakedouglas | yay, bundler works again :p |
| 18:41:45 | evan | :) |
| 18:42:26 | jakedouglas | let me try the other thing now. |
| 18:44:19 | jakedouglas | success :) |
| 18:44:42 | dbussink | brixen: yeah, only clean build triggers that |
| 18:44:42 | jakedouglas | well. the spec fails, but it doesn't crash. |
| 18:44:48 | dbussink | brixen: easy to forget :) |
| 18:45:20 | brixen | dbussink: yep :) |
| 18:46:17 | jakedouglas | evan: do you want me to close the ticket? |
| 18:46:23 | evan | sure |
| 18:46:31 | jakedouglas | k. |
| 18:47:56 | jakedouglas | thanks |
| 18:48:22 | jakedouglas | theres something funny going on with AR or machinist now i think. all of my specs that try to use db objects fail, and mysql is around 30% CPU the whole time (usually only 5% during spec run) |
| 19:03:15 | dbussink | jakedouglas: what kind of spec failures are you seeing? |
| 19:03:32 | jakedouglas | talking about my own specs |
| 19:09:37 | dbussink | jakedouglas: yeah, but curious where it's something consistent you could reproduce |
| 19:16:28 | jakedouglas | dbussink: i dont know the cause yet. its obscured by some other stuff. |
| 19:32:59 | dbussink | kronos_vano: you there? |
| 19:33:06 | boyscout | Use the correct exception constant in generator. - 603b45d - Brian Ford |
| 19:35:59 | kronos_vano | dbussink, |
| 19:36:02 | kronos_vano | yep |
| 19:36:12 | dbussink | kronos_vano: i was look at that fix you wrote |
| 19:36:37 | kronos_vano | which one |
| 19:36:48 | dbussink | but i wonder what happens if you have a total of 3 elements with a start at 2 http://github.com/evanphx/rubinius/issues#issue/422 |
| 19:38:47 | dbussink | kronos_vano: https://gist.github.com/e9b41a746eadfabd4a5a |
| 19:40:08 | kronos_vano | bad. |
| 19:42:51 | boyscout | CI: rubinius: 603b45d successful: 3498 files, 14361 examples, 42133 expectations, 0 failures, 0 errors |
| 19:45:36 | kronos_vano | dbussink, then instead of @start <= @total condition we can use @total > 0 |
| 19:50:18 | kronos_vano | May be better solution is change the c++ code? hm... |
| 20:15:42 | dbussink | evan: on tht fix for #422, what do you think? should we add a length check in Fixnum* Tuple::delete_inplace ? |
| 20:15:48 | dbussink | vm/builtin/tuple.cpp |
| 20:51:39 | evan | dbussink: sounds good. |
| 20:56:50 | dbussink | evan: how do you feel about the suggested spec kronos|inception added? http://gist.github.com/484235 |
| 20:57:15 | dbussink | it's a bit tricky because this bug occurs because of how we do a shift and set a different start pointer |
| 20:57:34 | dbussink | and a side effect of that is what causes this bug |
| 20:57:50 | evan | dbussink: ah hm |
| 20:58:01 | evan | his spec seems fine |
| 20:58:15 | evan | well, the description should be better |
| 20:58:33 | evan | perhaps: it "is not confused by shift" |
| 20:58:59 | dbussink | it "returns nil if the array is empty due to a shift" ? |
| 21:00:04 | evan | sure |
| 21:00:11 | evan | it neesd to mention shift |
| 21:00:13 | evan | needs. |
| 21:01:24 | dbussink | evan: hmm, this change to delete_inplace does mean it doesn't throw object bounds exceeded if somecall calls some weird start with a lenght of 0 |
| 21:01:27 | dbussink | is that problematic? |
| 21:01:50 | evan | well, we never said what the boundary cases are for delete_inplace |
| 21:01:56 | evan | ie, does it just ignore out of bounds |
| 21:04:26 | dbussink | evan: this is what i have now: https://gist.github.com/5c5f5eeca78905b96dc9 |
| 21:05:35 | evan | dbussink: seems fine. |
| 21:14:38 | boyscout | Add spec that asserts Array#shift doesn't trip up Array#delete - 9a203fa - Dirkjan Bussink |
| 21:14:39 | boyscout | Shortcircuit deleting elements if the part to be deleted as 0 elements - 7508201 - Dirkjan Bussink |
| 21:23:05 | khaase | evan: you know what would be a fun idea? packaging the ruby archive code and the zip in one rb file (the zip after __END__), so ppl wont have to install anything |
| 21:23:16 | boyscout | CI: rubinius: 7508201 successful: 3498 files, 14362 examples, 42134 expectations, 0 failures, 0 errors |
| 21:23:26 | evan | __END__ abuse! |
| 21:23:30 | evan | :D |
| 21:23:48 | evan | sadly DATA only works once in the whole system |
| 21:23:59 | evan | and only on the script given on the command line |
| 21:24:07 | evan | so it's pretty limiting. |
| 21:48:49 | boyscout | Add ability for inlining to request send as the fallback - 8c5d701 - Evan Phoenix |
| 21:57:35 | boyscout | CI: rubinius: 8c5d701 successful: 3498 files, 14362 examples, 42134 expectations, 0 failures, 0 errors |
| 22:33:03 | goyox86 | evan: i have a question, I just playing a bit, and i want inside a primitive i want to call "Exception::frozen_error" |
| 22:33:11 | evan | why? |
| 22:33:18 | evan | what primitive? |
| 22:34:29 | goyox86 | evan: i'm just playing with c++ code trying to understand, yesterday i saw a Module failing spec |
| 22:34:57 | evan | ok, what is your question? |
| 22:35:25 | goyox86 | evan: wait a moment please :) |
| 22:35:37 | evan | k |
| 22:40:04 | goyox86 | evan: yesterday i was looking at this tagged failing spec "Module#class_variable_set raises a TypeError when self is frozen" |
| 22:41:31 | evan | ok |
| 22:41:42 | goyox86 | evan: and i started looking for how to fix it, i found in the implementation of Module#class_variable_set |
| 22:42:18 | goyox86 | evan: i found -> Ruby.primitive :module_cvar_set |
| 22:42:34 | evan | yep |
| 22:42:46 | evan | ok |
| 22:44:58 | goyox86 | evan so i went to the implementation of the primitive, Object* Module::cvar_set(STATE, Symbol* name, Object* value) in vm/builtin/module.cpp |
| 22:45:12 | evan | yep. |
| 22:45:52 | goyox86 | evan: and my question is it right to call "Exception::frozen_error" here inside? |
| 22:46:05 | evan | well, lets see.. |
| 22:46:33 | evan | well |
| 22:46:41 | evan | you'd have to change the primitive |
| 22:46:52 | evan | because frozen_error has to be passed the current CallFrame* |
| 22:46:56 | evan | which it isn't passed atm. |
| 22:47:11 | evan | an easier way would be to have the primitive fail if self is frozen |
| 22:47:18 | evan | and put Ruby.check_frozen in the ruby method |
| 22:48:04 | goyox86 | evan: oh man! this is my point i almost went nutz trying to get the current CallFrame* |
| 22:48:20 | goyox86 | evan: /me is a noob |
| 22:48:26 | evan | right |
| 22:48:28 | goyox86 | is a noob |
| 22:48:30 | evan | it's not passed into primitives by default. |
| 22:50:43 | goyox86 | evan: actually i get the spec pass by throwing a Ruby Exception directly from inside primtive, but this was just for testing |
| 22:51:16 | evan | what code did you add? |
| 22:53:58 | goyox86 | evan: mmm let me get home and (i'm at work), i'll gist that (i don't like that code :]) , i live at walking distance let me get home :-) 30 min at most |
| 22:54:16 | evan | ok |
| 22:54:57 | goyox86 | leaving office |
| 23:18:36 | goyox86 | at home |
| 23:19:15 | goyox86 | evan: here is what i've done http://gist.github.com/485291, don't expulse me from de rbx church please :] |
| 23:20:36 | evan | goyox86: thats ok to do |
| 23:20:41 | evan | there are a few changes |
| 23:20:50 | evan | it should just be |
| 23:21:04 | evan | if(RTEST(frozen_p(state)) { |
| 23:21:44 | evan | you can access TypeError by doing |
| 23:21:47 | evan | G(exc_type) |
| 23:21:54 | evan | which accesses the global object exc_type |
| 23:21:58 | evan | which is the TypeError class |
| 23:22:20 | evan | actually |
| 23:22:25 | evan | there is Exception::type_error |
| 23:22:28 | evan | so you should just do |
| 23:22:46 | evan | if(RTEST(frozen_p(state)) { Exception::type_error(state, "unable to change frozen object"); } |
| 23:24:22 | jakedouglas | so 'tagged' spec is disabled right? so i can look at tags and find ones to fix like goyox86? |
| 23:25:18 | evan | yep |
| 23:25:37 | goyox86 | evan: so, it wasn't that bad as i was thinking after all :] ? |
| 23:25:54 | jakedouglas | looks like lots of approachable stuff |
| 23:25:56 | evan | goyox86: nope, you had the right idea |
| 23:28:09 | jakedouglas | so i just have to delete the tag line or something to make it run? |
| 23:28:30 | goyox86 | evan: and if(RTEST(frozen_p(state)) { Exception::type_error(state, "unable to change frozen object"); } should not be in some primitive just to dry up things? (noob question) |
| 23:28:40 | evan | no |
| 23:28:41 | evan | it should not. |
| 23:30:29 | goyox86 | evan: so in conclusion i can create a patch with the modifications an open a ticket? |
| 23:30:37 | evan | yep |
| 23:30:54 | goyox86 | thinks if evan has been in southamerica? |
| 23:31:03 | evan | a couple of times |
| 23:31:12 | goyox86 | evan: where? |
| 23:31:16 | evan | Santiago Chile and Beanos Aires |
| 23:31:53 | evan | going to Sao Paulo in October |
| 23:37:01 | jakedouglas | is rbx supposed to support utf8? |
| 23:39:04 | evan | the same way MRI does |
| 23:39:04 | jakedouglas | actually i dont even know enough about encoding stuff to ask that question. i should have asked something else |
| 23:39:05 | evan | yes. |
| 23:39:15 | jakedouglas | what i meant to ask was |
| 23:39:30 | jakedouglas | Expected ["Q", "u", "i", " ", "?"] to equal ["Q", "u", "i", " ", "è"] <- should i bother trying to fix this? should it work? |
| 23:39:43 | evan | i'd find something else |
| 23:39:46 | jakedouglas | k |
| 23:39:46 | evan | thats going to be tricky probably |
| 23:39:53 | evan | find something you feel more confident about. |
| 23:39:59 | jakedouglas | :) |
| 23:44:29 | goyox86 | thinks evan must come Venezuela an eat some arepas :] |
| 23:44:44 | evan | goyox86: heh |
| 23:55:07 | jakedouglas | do i have to do something to make changes take effect when i edit stuff in kernel/ ? |
| 23:55:20 | evan | run rake build |
| 23:55:23 | jakedouglas | thanks |