Da
Show enters and exits. Hide enters and exits.
| 00:11:15 | boyscout | Make sure that a local addrinfo side is found. Fixes #989 - ee2bdc2 - Evan Phoenix |
| 00:14:01 | scoutmaster | rubinius#135: SUCCESS in 2 min 41 sec |
| 00:18:06 | scoutmaster | rubinius OS X 10.5#101: FIXED in 11 min |
| 00:18:21 | evan | huzzah! |
| 00:18:24 | evan | all green again. |
| 00:19:20 | scoutmaster | rubinius-2.0#116: FAILURE in 5 min 13 sec: http://ci.rubinius.net/job/rubinius-2.0/116/ |
| 00:21:39 | evan | oh damn. |
| 00:28:21 | boyscout | Don't use Kernel#sleep to know how much time has past. Fixes #986 - f6567b8 - Evan Phoenix |
| 00:31:07 | scoutmaster | rubinius#136: SUCCESS in 2 min 40 sec |
| 00:32:23 | scoutmaster | rubinius-2.0#117: FIXED in 5 min 5 sec |
| 00:39:25 | brixen | evan: what was the idea with fa151008a ? |
| 00:39:42 | evan | you can see his links |
| 00:39:53 | evan | for C++ iterators |
| 00:40:09 | evan | using preincrement avoids copying the current one to return |
| 00:40:18 | brixen | oh ok |
| 00:40:19 | evan | I just never bothered to care |
| 00:40:22 | evan | even though I knew that |
| 00:40:25 | evan | he went to the trouble |
| 00:40:27 | evan | so I rewarded him. |
| 00:40:31 | brixen | gotcha |
| 00:40:50 | brixen | I think the tradition probably goes back to K&R book |
| 00:40:54 | brixen | and it became ingrained |
| 00:41:07 | brixen | all example code was written with i++ |
| 00:41:15 | evan | yep |
| 00:41:24 | boyscout | Add HAVE_ macros for blocking region stuff. Fixes #977 - 45e0601 - Evan Phoenix |
| 00:46:03 | scoutmaster | rubinius#137: SUCCESS in 4 min 33 sec |
| 00:50:53 | brixen | evan: any reason to put those defines in ruby.h instead of defines.h ? |
| 00:51:08 | evan | i'm dumb? |
| 00:51:09 | evan | oops. |
| 00:51:13 | brixen | heh |
| 00:51:15 | brixen | ok |
| 00:51:24 | evan | well, it made sense to put them by the their they're declaring |
| 00:51:30 | brixen | yeah |
| 00:51:35 | brixen | MRI has defines.h though |
| 00:51:39 | evan | i can't wait until mkmf can detect shit properly. |
| 00:51:41 | brixen | it's the consistency bot in me |
| 00:51:43 | brixen | true |
| 01:05:25 | brixen | just installed jekyll on 2.0pre, which installed 7 gems, and it ran so fast |
| 01:05:37 | brixen | maybe I have really slow internet at home |
| 01:05:47 | evan | :) |
| 01:05:50 | evan | well, i'm off for a jog. |
| 01:05:52 | brixen | oh wait, hah |
| 01:05:55 | brixen | I'm on an ssd |
| 01:05:57 | brixen | I forget! |
| 01:05:59 | evan | ha! |
| 01:06:00 | brixen | evan: have fun! |
| 01:06:00 | evan | yep |
| 01:24:41 | jer | brixen: ssd makes everything nice and speedy |
| 01:27:04 | brixen | jer: yes, including closing your laptop and throwing it in your bag in the airplane with no concern for turbulence |
| 01:27:30 | brixen | and working for 5 hours on the plane with no concern for battery life is so rad |
| 01:33:04 | alexsuraci | evenin' |
| 01:33:14 | brixen | hey alexsuraci |
| 01:33:22 | alexsuraci | yo |
| 01:33:31 | brixen | turns out, one great way to find bugs is to actually read the code that is failing |
| 01:34:02 | brixen | creates a ProTip Bug Finding™ list |
| 01:34:25 | alexsuraci | i spent the day at work doing 99% reading and wrote about 10 lines of code :D |
| 01:34:32 | alexsuraci | baby steps |
| 01:34:36 | brixen | heh |
| 01:34:41 | brixen | that sounds like a very good day |
| 01:34:57 | alexsuraci | heh, it's my day 2, and the codebase is pretty large. thankfully it's all ruby. |
| 01:35:09 | brixen | fun! |
| 01:35:38 | brixen | would they be opposed to running it on rbx and you extending it with Atomy? :) |
| 01:36:11 | alexsuraci | hah, i wouldn't be surprised at all if they ended up with atomy runtime support down the line :P (as long as i'm there anyway) |
| 01:36:26 | alexsuraci | actually, it's open-source, so maybe either way |
| 01:37:36 | brixen | heh, cool |
| 01:38:05 | alexsuraci | brixen: so when are you in town on the weekend? :P |
| 01:38:17 | brixen | well, I leave sat |
| 01:38:22 | brixen | le'me check what time |
| 01:38:57 | brixen | flight is at 12:30 pm |
| 01:39:06 | alexsuraci | ah |
| 01:39:26 | brixen | alexsuraci: I'll likely be back in Jul |
| 01:39:48 | brixen | since you're just getting settled in, don't feel compelled to fit in an SF trip in the next 2 day |
| 01:39:49 | brixen | s |
| 01:40:13 | alexsuraci | yea, july would be nice, i think bakkdoor is back around then too? |
| 01:40:16 | brixen | and bakkdoor will be back in july |
| 01:40:17 | brixen | yeah |
| 01:40:24 | brixen | we can hang out and hack on some fun stuff |
| 01:40:41 | alexsuraci | sounds good |
| 01:40:44 | brixen | cool |
| 01:41:53 | brixen | why oh why are the deps for melbourne not causing a rebuild... |
| 01:47:46 | brixen | hell yeah! RBXOPT='-X19 -Xint' bin/mspec run -h |
| 01:50:28 | brixen | oh yeah https://gist.github.com/1041728 |
| 01:50:45 | brixen | as soon as I have a clean CI run in 1.9 mode, I'll enable it |
| 01:50:58 | brixen | now, to fix this jit issue (note the -Xint in those commands) |
| 01:51:02 | jdsiegel | Oooooo |
| 01:51:26 | brixen | jdsiegel: hehe, you have a 1.9 irc alert bouncer huh? :D |
| 01:51:55 | jdsiegel | hooked up to my home alarm system! |
| 01:52:19 | meh` | does it work? :> |
| 01:55:44 | petercooper | brixen: Does your tweet mean my post might be applicable soon? (The one where I show everyone how to use 1.9 right now in RBX ;-)) |
| 01:55:57 | brixen | petercooper: hah, yes, very soon |
| 01:56:03 | petercooper | Niiiice :) |
| 01:56:11 | brixen | I just need a sane spec run |
| 01:56:30 | brixen | since that ran 3 specs, I'm encouraged |
| 01:56:38 | brixen | but we currently have about 45,000 |
| 01:57:07 | brixen | of course, I'm not above tagging first and asking questions later |
| 02:06:31 | postmodern | http://pastie.org/2109191 |
| 02:06:36 | postmodern | having trouble building 2.0.0pre |
| 02:06:43 | postmodern | did a clean build just now |
| 02:07:33 | brixen | postmodern: clean build before or after that? |
| 02:08:05 | postmodern | brixen, both, i tried ./configure && rake and that failed, so i rake cleaned |
| 02:08:06 | brixen | postmodern: also, when you have an issue, please pastie me *everything* |
| 02:08:16 | brixen | you do me no favors by cutting that content |
| 02:08:43 | postmodern | k |
| 02:08:53 | brixen | I'm tracking down an issue with the deps for melbourne not causing recompiles correctly |
| 02:08:58 | brixen | it's puzzling |
| 02:09:06 | postmodern | will install script |
| 02:09:21 | brixen | install what? |
| 02:10:16 | brixen | postmodern: ok, I got your issue |
| 02:10:28 | brixen | you're building with 1.9.2 and I messed up the location of that define |
| 02:10:42 | postmodern | brixen, ah excellent |
| 02:11:32 | brixen | dang, I don't want to push this without fixing the deps issue though :-/ |
| 02:12:01 | jer | brixen, indeed... Though, i use my iPad on airplanes, just easier that way :) Leave my laptop for the ambassadors lounges on layovers :) |
| 02:12:20 | brixen | jer: ahh, do you do dev on your ipad? |
| 02:13:36 | tarcieri | dev on an iPad? o.O |
| 02:13:59 | brixen | tarcieri: sounds fun, huh? :) |
| 02:14:20 | brixen | gesture-based, graphical assembly |
| 02:16:05 | tarcieri | COSA? heh |
| 02:16:49 | tarcieri | look at how easy quicksort is: http://www.rebelscience.org/Art/qsort.png |
| 02:17:20 | brixen | yep, awesome |
| 02:17:43 | brixen | also, what's with all those comments? |
| 02:17:53 | brixen | if the code isn't clear enough without comments, refactor |
| 02:17:58 | brixen | :D |
| 02:18:50 | tarcieri | heh |
| 02:19:04 | brixen | wow, rvm install ruby-1.8.7 builds fast on an ssd |
| 02:19:08 | brixen | crazy |
| 02:19:09 | tarcieri | heh |
| 02:19:12 | tarcieri | ssds rock! |
| 02:20:48 | jer | brixen: sometimes yes :) |
| 02:21:54 | brixen | jer: I knew it! |
| 02:21:57 | jer | brixen: i was writing an ipad code editor on an ipad for a while (granted, through ssh to my mac...) idea was to also build some bonjour service that'd interface with an xcode project, hit xcodebuild for you, push the build out to an http server for over the air sync to the ipad |
| 02:22:03 | jer | so you could one command build & run from your ipad, to your ipad |
| 02:22:04 | jer | :) |
| 02:22:10 | brixen | nice |
| 02:22:43 | jer | i occsaionally suffer from "ooo, shiney" syndrome and that project ended up on the back burner |
| 02:24:51 | brixen | heh |
| 02:25:25 | jer | but yeah, writing code on the ipad isn't so bad when you carry your bluetooth keyboard with you everywhere =p |
| 02:40:30 | brixen | postmodern: I'll push this in a bit, going to grab some food and see if I can fix this deps issue |
| 02:40:53 | brixen | postmodern: I fixed a couple other issues building with MRI 1.9 too |
| 02:56:27 | postmodern | brixen, sweet, thank you |
| 04:00:32 | brimil01 | evan: you around sir? |
| 04:57:01 | brimil01 | Question on documentation of the core lib, does 1.8.7 docs supersede documentation already in rubinius? |
| 07:08:51 | gaffo | evan or brian here? |
| 07:10:55 | boyscout | Fixed another ID issue in 1.9 parser. - 8127d12 - Brian Ford (2.0.0pre) |
| 07:10:55 | boyscout | Regen'd 1.9 parser. - d2a88c1 - Brian Ford (2.0.0pre) |
| 07:10:55 | boyscout | Fixed rebuilding melbourne from dependencies. - fc85189 - Brian Ford (2.0.0pre) |
| 07:11:02 | brixen | hey gaffo |
| 07:11:28 | brixen | postmodern: there's a fix for building with MRI 1.9 |
| 07:11:45 | brixen | postmodern: I'm working on fixing the warnings you'll see when melbourne builds |
| 07:13:19 | brixen | brimil01: did you check out the rubyspec/readruby stuff? |
| 07:13:45 | brixen | brimil01: it doesn't make any sense to me to keep importing MRI rdoc into separate impl source code |
| 07:13:48 | scoutmaster | rubinius#138: SUCCESS in 2 min 48 sec |
| 07:14:02 | brixen | brimil01: we should have a central repo for the rdoc and reference that from the other impls |
| 07:14:19 | brixen | brimil01: ideally, we could then get people to help translate it along with the other rbx docs |
| 07:17:18 | gaffo | hey brix |
| 07:17:23 | gaffo | er brixen |
| 07:17:31 | brixen | heh |
| 07:17:43 | gaffo | (forgot about prompts) |
| 07:17:58 | brixen | no worries, some people call me brix |
| 07:18:13 | brixen | so, the issue with embedding is that we need an API |
| 07:18:28 | brixen | because we don't want to have the same situation that exists with MRI |
| 07:18:42 | gaffo | kk |
| 07:18:45 | brixen | which is that C extensions use internal MRI stuff and it causes a lot of problems |
| 07:19:03 | brixen | evan and charlie (jruby) are talking about working on a better C-API |
| 07:19:23 | brixen | do you have an idea of what features you need for embedding? |
| 07:19:26 | gaffo | so which way are you talking about |
| 07:19:35 | gaffo | c/et al > ruby |
| 07:19:40 | gaffo | or ruby > et al? |
| 07:19:52 | brixen | not sure what you mean by that |
| 07:20:27 | gaffo | well, currently I had looked at rbx and saw that bootstrapping an environment wasn't that hard |
| 07:20:33 | brixen | ah sure |
| 07:20:40 | gaffo | and ffi looked like I could call back into c |
| 07:20:45 | gaffo | well, lemme step back |
| 07:20:46 | brixen | so, we need something like rb_interpreter_new() |
| 07:21:12 | gaffo | I'm currently looking at it as a games engine. I work for a good sized games developer |
| 07:21:17 | brixen | ok |
| 07:21:31 | brixen | so you want to embed rbx to enable Ruby scripting inside the game? |
| 07:21:33 | gaffo | but it's more for home stuff at the moment (we have our own scriptiing) |
| 07:21:39 | brixen | ah ok |
| 07:21:56 | banister`hero | brixen internal stuff is fun though ;) let's us write whacky stuff like http://github.com/banister/free ;) (very naughty i know) |
| 07:21:59 | gaffo | I want to do it personally but move my work tech towards what I learn here. It's how I work. |
| 07:22:10 | brixen | banister`hero: you're banned :P |
| 07:22:22 | brixen | gaffo: ok, sure |
| 07:22:47 | brixen | gaffo: do you want to have multiple segregated Ruby interpreters running in one process? |
| 07:23:04 | gaffo | brixen, that would be good |
| 07:23:15 | gaffo | but I think better would be just one that can either reload classes on the fly |
| 07:23:20 | banister`hero | ;) |
| 07:23:22 | gaffo | well, whole source |
| 07:23:28 | brixen | sure |
| 07:23:28 | gaffo | or just re-start |
| 07:23:32 | gaffo | and |
| 07:23:49 | gaffo | one that doesn't depend on the filesystem |
| 07:24:10 | brixen | well, we need to load the kernel from something |
| 07:24:18 | gaffo | eg it can libload off of some other source (usually a pack file) |
| 07:24:24 | brixen | ok |
| 07:24:32 | gaffo | I think the loading is secondary |
| 07:24:43 | gaffo | well, and 3 is |
| 07:24:44 | brixen | we can certainly have options there |
| 07:24:52 | gaffo | and the most important |
| 07:25:01 | gaffo | just getting it linked into other apps easily |
| 07:25:06 | brixen | yeah |
| 07:25:12 | gaffo | which I think would be step 1. er 3, er 1 |
| 07:25:19 | brixen | so, I'm going to be in LA with evan next week |
| 07:25:25 | gaffo | kk |
| 07:25:26 | brixen | we can spend some time on this |
| 07:25:41 | brixen | gaffo: what TZ are you in? |
| 07:25:45 | gaffo | Seattle |
| 07:25:48 | brixen | ah ok |
| 07:25:52 | gaffo | RainyTZ |
| 07:25:58 | brixen | heh |
| 07:25:59 | gaffo | well now it's SunnyTZ |
| 07:26:01 | brixen | yeah, I'm in pdx |
| 07:26:05 | gaffo | oh cool man |
| 07:26:10 | gaffo | I'll be there this weekend |
| 07:26:11 | brixen | normally, but I'm in SF at the moment |
| 07:26:23 | brixen | ahh, I'll be heading to LA this weekend |
| 07:26:30 | brixen | anyway, do you have time to pop in tomorrow? |
| 07:26:35 | gaffo | sure |
| 07:26:42 | brixen | ok, let's discuss more with evan |
| 07:26:50 | brixen | and we can set up some stuff to look into next week |
| 07:26:51 | gaffo | sounds good. I get in around 10 |
| 07:26:55 | brixen | ok |
| 07:27:11 | gaffo | talk to ya tomorrow |
| 07:27:18 | brixen | cool, cheers |
| 07:27:25 | brixen | I'm gonna crash |
| 07:27:28 | gaffo | me too |
| 07:27:32 | gaffo | night |
| 07:27:35 | brixen | night |
| 07:27:57 | brixen | banister`hero: I'll add the KERNEL_PATH stuff tomorrow, so it's easier to find the source |
| 07:28:05 | brixen | banister`hero: I haven't forgotten about you :) |
| 07:28:30 | brixen | sleeps |
| 07:28:31 | banister`hero | brixen awesome thanks |
| 07:28:38 | banister`hero | sleep wel! |
| 07:28:42 | brixen | thanks! |
| 07:43:25 | flavio | brixen: good night! |
| 09:55:20 | diegoviola | hi |
| 12:56:19 | Zr40 | I'm looking into writing a code coverage tool that reports branch coverage. MRI doesn't seem to support this; set_trace_func only reports line info. Would this be possible to do with Rubinius, and where should I start? |
| 13:53:31 | diegoviola | will rbx be used as the default interpreter for ruby 2.0? if rbx is so much better than mri why not drop mri and develop on RBX? |
| 13:54:15 | diegoviola | i don't see the point of having both mri and rbx, could someone enlighten me? |
| 13:54:17 | diegoviola | :D |
| 13:54:53 | diegoviola | i see the point of having a c interpreter and a java one though |
| 13:54:58 | diegoviola | c/c++ |
| 13:55:07 | diegoviola | and ruby one |
| 13:55:32 | Mon_Ouie | They're different, RBX isn't better than MRI regarding every single aspect. |
| 13:59:05 | diegoviola | ok |
| 14:04:23 | Zr40 | would Rubinius support branch code coverage, and how would I go about implementing it? |
| 14:19:12 | dbussink | Zr40: you could look at how the profiler is implemented |
| 14:19:17 | dbussink | Zr40: and use that as an example |
| 14:19:45 | dbussink | it probably needs additional info though |
| 14:25:36 | dbussink | evan: ping? |
| 14:27:58 | cremes | diegoviola: competition is good; it results in better runtimes for all cases |
| 14:28:10 | diegoviola | cremes: agreed, thanks |
| 14:28:17 | cremes | diegoviola: and no, there is no plan for rubinius to supplant mri |
| 14:34:55 | Zr40 | dbussink: the profiler appears to be implemented in C++ code (vm_tooling_*) |
| 14:35:05 | dbussink | Zr40: that's right yeah |
| 14:35:22 | dbussink | but there's probably some change there needed to be able to do coverage |
| 14:55:39 | Zr40 | dbussink: would the debugger interface be suitable? |
| 14:57:53 | Mon_Ouie | It could be; maybe you could do it by adding a breakpoint on both targets of branchments? |
| 14:58:26 | Zr40 | I don't think breakpoints are suitable, it would create tons of them |
| 14:59:17 | Mon_Ouie | As far as I can see, the debugger thread doesn't get any information about what happens in the code if there is no breakpoint |
| 15:13:25 | Zr40 | hmm, temporary breakpoints might actually be ideal. Can I use them to call a method when the breakpoint hits? |
| 15:24:13 | Mon_Ouie | They will send information to a Rubinius::Channel in a thread (both of which you must create) |
| 15:24:30 | Mon_Ouie | Once you received information you can do whatever you want with them |
| 16:20:18 | cremes | evan: ping |
| 16:43:35 | dbussink | cremes: tried that, didn't seem to work yet ;) |
| 16:43:57 | dbussink | cremes: we should have a way to poke him irl :p |
| 16:47:59 | cremes | dbussink: yeah, we need a way to poke him in meatspace so that he has no life at all |
| 16:48:07 | cremes | he must know that he CANNOT ESCAPE US! |
| 16:48:11 | dbussink | he doesn't need a life, does he? ;) |
| 16:48:28 | dbussink | and he has this big excuse shortly anyway :P |
| 16:49:37 | dbussink | have something i want to run by him too |
| 17:08:52 | evan | morning. |
| 17:11:01 | brixen | morning sailors |
| 17:13:35 | dbussink | evan: question for you |
| 17:13:43 | evan | ok |
| 17:13:51 | dbussink | evan: currently immix does conservative marking, is that for a specific reason? |
| 17:14:04 | evan | conservative marking being what? |
| 17:14:08 | dbussink | does not, sorry |
| 17:14:19 | dbussink | it now exactly marks the lines an object consists of |
| 17:14:27 | dbussink | and not conservative like in the immix paper |
| 17:15:00 | dbussink | evan: a gist is probably easier: https://gist.github.com/4af420b55874a1f5d36f |
| 17:15:55 | evan | I don't recall off hand |
| 17:15:56 | evan | honestly. |
| 17:16:01 | evan | perhaps I was worried about bugs |
| 17:16:11 | evan | I decided to do the way that I could fully understand at the time |
| 17:16:30 | evan | your way adds just that extra condition? |
| 17:16:40 | dbussink | yeah, a shortcut for small objects |
| 17:16:49 | dbussink | it can mark a line too much though |
| 17:16:58 | dbussink | but the immix paper claims that's worth it performance wise |
| 17:16:59 | evan | ok |
| 17:17:03 | evan | i'd have to look at the paper |
| 17:17:12 | evan | I don't recall why they do that |
| 17:17:15 | evan | but if it works fine |
| 17:17:17 | evan | go for it. |
| 17:17:20 | dbussink | search for "Conservative Marking" in the paper |
| 17:17:30 | dbussink | basically because otherwise the marking is more expensive |
| 17:17:43 | dbussink | because of the additional computations needed to determine the number of lines |
| 17:17:56 | brixen | dbussink: did you profile to see how expensive the marking is? |
| 17:18:00 | shevy | hmm when there are multiple ruby versions like 1.8.7 1.8.8 1.9.1 1.9.2 does Rubinius aim to support all of them? or only the latest always |
| 17:18:10 | dbussink | brixen: nope, just something i wanted to play it a bit it |
| 17:18:14 | brixen | since now a single object will use an entire line |
| 17:18:20 | dbussink | i thought it would be more complex honestly |
| 17:18:30 | dbussink | brixen: not use |
| 17:18:42 | brixen | dbussink: keep in use |
| 17:18:44 | dbussink | but it can overmark stuff and keep a little too long alive |
| 17:18:48 | brixen | yes |
| 17:18:51 | dbussink | yeah that's true |
| 17:19:09 | brixen | shevy: rbx is 1.8.7 compatible and we're working on 1.9.2 |
| 17:19:15 | dbussink | shevy: right now 1.8.7, near future both 1.8.7 and 1.9.2 |
| 17:19:29 | dbussink | shevy: luckily they cancelled 1.8.8 |
| 17:19:49 | brixen | dbussink: if you want to investigate, I'd like to know the marking cost as well as how many objects of what size are in a line on something like a rails app doing requests |
| 17:20:20 | cremes | evan: any chance we could bump speed.rubyspec.org from a micro to a small ec2 size? |
| 17:20:34 | evan | dbussink: ok, so it's for speed |
| 17:20:35 | cremes | evan: the database i/o is beyond what the micro can reasonably handle |
| 17:20:42 | dbussink | evan: yeah |
| 17:20:46 | evan | dbussink: you should do some quick tests then to show that it speeds up collections |
| 17:20:49 | dbussink | evan: i wonder how to properly benchmark it though |
| 17:20:59 | evan | cremes: sure |
| 17:21:00 | dbussink | evan: any suggestion for doing that? |
| 17:21:12 | dbussink | i think some gc benchmarks could be useful in general :) |
| 17:21:14 | evan | i'm not sure how to change it without tearing it down and setting up another one |
| 17:21:29 | cremes | evan: hang on a sec... i have a stackoverflow article that discusses how to do that |
| 17:21:34 | evan | ok |
| 17:22:12 | dbussink | evan: suggestions for how to benchmark it? |
| 17:22:12 | cremes | evan: http://stackoverflow.com/questions/5898308/upgrade-amazon-ec2-micro-instance-to-large |
| 17:25:06 | dudleyf | It's not a bug when Rubinius differs from MRI on undefined behavior, is it? |
| 17:25:22 | brixen | dudleyf: what is the behavior |
| 17:25:24 | brixen | ? |
| 17:25:27 | dudleyf | i.e. modifying an array while iterating over it |
| 17:25:37 | brixen | no |
| 17:25:46 | brixen | matz has explicitly said that is undefined |
| 17:25:49 | brixen | we do not support it |
| 17:25:49 | Mon_Ouie | That behaviour isn't quite consistent in MRI |
| 17:26:06 | dudleyf | brixen: Good. Just making sure. |
| 17:26:19 | Mon_Ouie | At least for hashes it behaves differently in 1.8 and 1.9 |
| 17:26:52 | cremes | evan: let me know when you might have a chance to try that upgrade |
| 17:27:04 | cremes | evan: i want to shut down the site, tar it up and copy it off just in case |
| 17:27:07 | dbussink | brixen: maybe as it's undefined behavior, we could throw an exception? |
| 17:27:39 | brixen | dbussink: why? |
| 17:27:40 | evan | dbussink: benchmark wise, i guess write code that holds onto a bunch of objects |
| 17:27:44 | evan | then time how long collection takes? |
| 17:27:52 | dudleyf | dbussink: that would have saved me a couple of hours :) |
| 17:27:58 | dbussink | brixen: ^^ |
| 17:28:03 | dbussink | brixen: that's the reason ;) |
| 17:28:03 | brixen | not a good reason |
| 17:28:22 | brixen | that's a cost for everyone so one programmer doesn't do something he should never have done |
| 17:28:47 | brixen | I've never accidentally written code to modify a collection I'm iterating |
| 17:29:04 | evan | cremes: i'll do it now |
| 17:29:08 | evan | cremes: if you want to backup first |
| 17:29:13 | brixen | so let's make everyone's code slower so you don't have to think much? :P |
| 17:29:19 | dudleyf | brixen: Neither have I, I was tracking down an instance of someone doing it intentionally in a library I was using |
| 17:29:20 | evan | the IP might change so we'll have to update DNS |
| 17:29:23 | cremes | evan: ok, i'll ping you when i'm done (gimme 10m) |
| 17:29:58 | brixen | dudleyf: thankfully, that code is few and far between, and not worth the cost to everyone's code IMO |
| 17:30:04 | dbussink | evan: i guess this would be a time to call explicit GC right? ;) |
| 17:30:16 | evan | nope. |
| 17:30:37 | evan | you'll just time the whole application |
| 17:30:40 | dudleyf | brixen: fair enough |
| 17:30:55 | dbussink | evan: because i was going to try to put it in a benchmark some way |
| 17:31:08 | evan | hm |
| 17:31:56 | evan | dbussink: you can use GC.run(true) |
| 17:32:02 | evan | sure |
| 17:32:03 | evan | go for it. |
| 17:32:25 | cremes | evan: done |
| 17:32:37 | brixen | dbussink: the problem I see with that is you don't know when the GC may run |
| 17:34:29 | brixen | dbussink: also, if you are just creating synthetic objects, that's not giving you the line profiles that a real application may have |
| 17:34:49 | brixen | I'd much rather see this under a rails app being hit by ab, for example |
| 17:35:42 | evan | where the fuck is XMALLOC |
| 17:35:44 | evan | in capi |
| 17:35:46 | evan | anyone know? |
| 17:35:58 | evan | I grep for it and it's nowhere |
| 17:36:06 | brixen | I don't believe it's defined |
| 17:36:13 | evan | wait what? |
| 17:36:19 | evan | someone deleted it? |
| 17:36:28 | evan | because it was definitely defined at one point. |
| 17:37:52 | brixen | I remember it being defined in shotgun |
| 17:38:30 | evan | :/ |
| 17:38:34 | evan | thats bad. |
| 17:38:36 | dbussink | evan: vm/capi/18/include/ruby.h:void* XMALLOC(size_t bytes); |
| 17:38:39 | evan | yeah |
| 17:38:41 | evan | i see what |
| 17:38:46 | dbussink | vm/objectmemory.cpp:void* XMALLOC(size_t bytes) { |
| 17:38:48 | evan | but where is the definition? |
| 17:38:51 | evan | ACK |
| 17:38:59 | evan | i've been greping just vm/capi |
| 17:39:01 | evan | thanks dbussink |
| 17:39:55 | evan | I knew I remembered seeing it at the bottom of a file |
| 17:40:03 | evan | that file was just vm/objectmemory.cpp |
| 17:40:21 | brixen | ah yeah, I just went looking for that recently |
| 17:40:27 | evan | I should move these. |
| 17:40:35 | evan | they don't need to be in objectmemory.cpp |
| 17:45:56 | evan | huh. funny. |
| 17:46:13 | evan | I think that libxml2 uses XMALLOC to allocation memory internally |
| 17:46:20 | evan | and, by sheer coincidence |
| 17:46:23 | evan | we have a symbol of that name. |
| 17:46:28 | evan | that happens to allocate memory. |
| 17:46:36 | evan | because there is no XMALLOC in MRI |
| 17:46:47 | evan | so in MRI, libxml2 uses it's own symbol. |
| 17:47:30 | brixen | ah interesting |
| 17:47:45 | brixen | and we define xmalloc to be XMALLOC, MRI does have xmalloc |
| 17:48:32 | brixen | confusing |
| 17:52:03 | evan | yeah |
| 17:52:11 | brixen | evan: at the moment, we are not inlining methods with rest args? |
| 17:52:12 | evan | that ends up causing us the thrash inside the GC |
| 17:52:22 | brixen | I'm reading the comment in jit_inline_method.cpp |
| 17:52:26 | evan | because we GC every 10Mb worth of calls to XMALLOC |
| 17:52:33 | evan | brixen: no, we're not. |
| 17:52:37 | evan | thats correct. |
| 17:52:40 | brixen | I see |
| 17:52:58 | brixen | I'm looking at adding the argument processing for inlined blocks |
| 17:53:07 | brixen | that's a blocker right now for running 1.9 mode |
| 17:53:14 | brixen | with the jit on |
| 17:53:21 | evan | why is that a blocker? |
| 17:53:40 | brixen | because eg Enumerable#find_all jits and yields nils forever after ;) |
| 17:53:56 | brixen | I can run the specs with -Xint -X19 |
| 17:53:59 | evan | i don't follow. |
| 17:54:06 | brixen | which part? |
| 17:54:09 | evan | because how does the rest args come into play? |
| 17:54:16 | brixen | oh, it doesn't |
| 17:54:25 | brixen | I'm looking at how the args are handled for inline methods |
| 17:54:32 | brixen | to see how to do it for inlined blocks in 1.9 mode |
| 17:54:40 | evan | ah |
| 17:54:47 | brixen | I was surprised we're not inlining methods with rest args |
| 17:54:52 | evan | yes, that will have to change radically |
| 17:55:06 | evan | never got around to it |
| 17:55:11 | brixen | sure |
| 17:55:19 | brixen | just excited about future possibilities :) |
| 17:55:25 | evan | :D |
| 17:55:32 | brixen | evan: do you have time to do the block inlining? |
| 17:56:03 | evan | i'm confused again |
| 17:56:04 | evan | :) |
| 17:56:15 | evan | are we talking about arg process of a block when it's inlined |
| 17:56:20 | brixen | yep |
| 17:56:22 | evan | or when a block is JITd standalone? |
| 17:56:30 | evan | both need work probably |
| 17:56:33 | brixen | yes |
| 17:56:33 | evan | now that I think about it. |
| 17:56:48 | evan | cremes: 174.129.177.167 |
| 17:56:50 | brixen | anytime we call a block, we have to set up local values for the args |
| 17:57:20 | brixen | evan: oh, do I need to update dns? |
| 17:57:25 | brixen | did that IP change? |
| 17:57:27 | evan | yeah |
| 17:57:28 | brixen | ok |
| 17:57:29 | evan | so |
| 17:57:34 | evan | could you set it up as a CNAME |
| 17:57:45 | brixen | ok |
| 17:57:46 | evan | to codespeed.rubinius.net |
| 17:58:05 | brixen | and an A for codespeed. |
| 17:58:07 | brixen | will do |
| 17:58:24 | evan | no no |
| 17:58:26 | evan | remove the A |
| 17:58:28 | evan | just a CNAME |
| 17:58:38 | brixen | ok |
| 17:58:46 | brixen | oh you have that |
| 17:58:48 | brixen | nevermind |
| 17:58:53 | evan | the dns for rubinius.net updates instantly |
| 17:58:56 | brixen | yeah |
| 17:58:57 | brixen | got it |
| 17:59:20 | brixen | rubinius. and rubyspec. just blurred in my mind |
| 17:59:30 | evan | thursday does that to a person |
| 17:59:37 | evan | so |
| 17:59:44 | evan | do you want me to do the block arg code for 1.9? |
| 17:59:46 | evan | JIT wise |
| 18:00:24 | brixen | sure |
| 18:00:30 | evan | ok |
| 18:00:35 | evan | i'm working on this nokogiri perf bug |
| 18:00:36 | brixen | I'd like to work on it, but in the interest of SPEED |
| 18:00:38 | evan | then i'll do it. |
| 18:00:43 | brixen | ok |
| 18:01:01 | brixen | linode confirmation button "Sure, delete that sucker" |
| 18:01:35 | brixen | rather "Yes, ..." |
| 18:01:36 | brixen | but funny |
| 18:01:53 | evan | hehe |
| 18:08:37 | evan | brixen: so, i'd like to fix this malloc/xmalloc/XMALLOC/ruby_xmalloc issue |
| 18:08:52 | evan | the easiest way is to change XMALLOC to ruby_xmalloc |
| 18:08:56 | evan | and adjust some #define's |
| 18:09:00 | evan | but that will break the ABI |
| 18:09:07 | evan | so people will have to reinstall their C extensions |
| 18:09:10 | evan | you think thats an issue? |
| 18:09:23 | brixen | are you fixing it on master or 2.0? |
| 18:09:31 | evan | was doing it on master. |
| 18:09:55 | brixen | perhaps then we should do it with 1.3 release |
| 18:10:04 | brixen | and announce that you'll have to reinstall C-exts |
| 18:10:07 | evan | I could make XMALLOC a pass through to just normal malloc |
| 18:10:14 | evan | and add ruby_xmalloc to have the current behavior |
| 18:10:16 | evan | no ABI change then |
| 18:10:19 | brixen | or that |
| 18:10:34 | evan | the only diff would be that existing C extensions wouldn't force a GC when they allocate a bunch of external memory |
| 18:10:38 | evan | unless they recompile |
| 18:10:42 | evan | which I think is ok actually. |
| 18:11:30 | brixen | that seems reasonable |
| 18:11:39 | evan | k |
| 18:12:23 | brixen | with 2.0, we should probably remove XMALLOC and friends though, yes? |
| 18:12:40 | evan | yeah |
| 18:12:46 | brixen | ok |
| 18:14:40 | evan | ARG |
| 18:14:51 | evan | someone changed ALLOC to use malloc |
| 18:14:53 | evan | instead of xmalloc |
| 18:15:07 | evan | which means that no C extensions has used the "GC after a lot of allocations" logic |
| 18:15:17 | evan | which could be the source of issues. |
| 18:15:59 | evan | zoinks |
| 18:16:04 | evan | I think it's been a long damn time. |
| 18:16:07 | brixen | hmm |
| 18:16:09 | mrb_bk | time to git blame |
| 18:16:09 | evan | maybe I should just delete this logic. |
| 18:16:46 | cremes | evan: thanks for the ec2 upgrade; i/o is still pokey but at least it's *consistent* |
| 18:16:55 | evan | cremes: cool. |
| 18:17:12 | evan | cremes: am I fine to shutdown the other one? |
| 18:17:20 | cremes | evan: yes |
| 18:17:23 | evan | k |
| 18:19:19 | evan | geez |
| 18:19:28 | evan | yeah, i think that ALLOC never used this logic |
| 18:19:29 | evan | wow. |
| 18:19:33 | evan | ok |
| 18:19:39 | brixen | yeah, this is so confusing |
| 18:19:50 | brixen | I was looking through the additions of those macros |
| 18:20:07 | brixen | memory management is hard, let's all be senile |
| 18:20:50 | evan | yeah, we never idd. |
| 18:20:50 | evan | did. |
| 18:20:51 | evan | zoinks. |
| 18:21:36 | evan | well, wtf. |
| 18:24:02 | evan | there are extensions that use xmalloc directly |
| 18:24:09 | evan | like bigdecimal |
| 18:24:16 | evan | i'll bet thats what i'm thinking |
| 18:25:00 | brixen | yeah, MRI stuff uses xmalloc/xfree |
| 18:26:07 | brixen | and at least 1.9 has 2 defines for xmalloc |
| 18:26:16 | brixen | regint.h defines it as malloc |
| 18:26:25 | brixen | ruby.h defines it as ruby_xmalloc |
| 18:26:50 | brixen | that's not confusing at all |
| 18:31:07 | evan | sure, i mean in extensions |
| 18:31:14 | evan | thats why I added our versions |
| 18:50:03 | evan | OH GEEZ. |
| 18:50:07 | evan | I was wrong. |
| 18:50:26 | evan | libxml2 has a way to register the allocator to use |
| 18:50:35 | evan | and nokogiri explicitly passes ruby_xmalloc |
| 18:50:38 | evan | ok, thats better actually. |
| 18:58:43 | dwaite | I wish they would hurry up with libxml3 already |
| 19:01:22 | dbussink | evan: but you're wondering now about the strategy of gc'ing when allocating memory that way? |
| 19:02:09 | Mon_Ouie | So if someone uses this in a C extension, ruby (be it Rubinius, MRI, or JRuby) would know how much memory it is using? |
| 19:02:39 | evan | right |
| 19:02:44 | evan | so that the GC can be trigger |
| 19:02:55 | evan | so that Data_Wrap_Struct free functions can run |
| 19:02:59 | evan | and free external memory |
| 19:03:04 | evan | it's a kludge |
| 19:13:37 | brixen | heh, the rubinius tshirt expo photo is being used in Rubinius announcements now |
| 19:13:47 | brixen | so, I think people think that's the rubinius dev team |
| 19:16:21 | evan | hehe |
| 19:16:26 | evan | well, when you're here next week |
| 19:16:28 | evan | we'll take some pics |
| 19:23:35 | brixen | yeah, I'll be known as the one without the beard :) |
| 19:30:45 | brixen | evan: grabbing lunch, bbiab |
| 19:31:05 | evan | ha |
| 19:49:20 | pkondzior | what is the fastest way to rebuild some part of rbx (for example after string optimisations that i want to benchmark) |
| 19:49:29 | pkondzior | i can find step by step scenerio in doc ? |
| 19:51:25 | pkondzior | nvm, found it |
| 19:58:54 | cremes | pkondzior: run 'rake build' to skip running all of the specs |
| 19:59:01 | cremes | pkondzior: that's the fastest way i know to rebuild it |
| 20:03:19 | pkondzior | cremes: actually i neede rake kernel |
| 20:39:49 | brixen | hm, we had at least one duplicate HAVE_ define in ruby.h |
| 20:39:59 | brixen | surprised we didn't get compile warning about that |
| 20:41:58 | boyscout | Added Rubinius::KERNEL_PATH and install kernel .rb files. - 0219009 - Brian Ford |
| 20:41:58 | boyscout | Moved HAVE_ C-API defines to defines.h. - 83b0158 - Brian Ford |
| 20:42:14 | brixen | banister`sleep: wake up, I added KERNEL_PATH for you :) |
| 20:48:50 | scoutmaster | rubinius#139: SUCCESS in 6 min 47 sec |
| 20:51:41 | gaffo | brixen, hola |
| 20:51:48 | brixen | hey gaffo |
| 20:52:00 | brixen | I think evan is at lunch, should probably be back soon |
| 20:52:30 | gaffo | kk |
| 20:52:34 | gaffo | I'll check back in a bit |
| 20:53:36 | brixen | ok |
| 21:39:51 | evan | ok, i'm back |
| 21:39:58 | evan | was talkin' with shane |
| 21:40:06 | evan | gaffo: poke |
| 21:40:07 | evan | brixen: poke |
| 21:40:12 | brixen | yeah |
| 21:40:20 | gaffo | poked |
| 21:40:36 | evan | so |
| 21:40:39 | evan | librubinius |
| 21:41:05 | gaffo | yes |
| 21:41:06 | evan | what is needed is a new .cpp and .hpp files |
| 21:41:18 | evan | which whould describe and implement an API that embedders would use |
| 21:41:22 | gaffo | kk |
| 21:41:33 | evan | the .hpp file would be installed into a rbx include directory |
| 21:41:34 | gaffo | and I'm guessing have the declspec / _dll on them |
| 21:41:44 | evan | i don't know about that |
| 21:41:55 | evan | never needed those for unix shared libraries |
| 21:41:59 | evan | but if you say so, yes. |
| 21:42:06 | gaffo | for windows you do |
| 21:42:13 | gaffo | but yeah but default EVERYTHING is exported |
| 21:42:24 | gaffo | but contine. |
| 21:42:35 | evan | the idea is to consider all the existing classes/functions/headers as private |
| 21:42:51 | evan | and build a new API that would interface those private APIs to a public embed API |
| 21:43:01 | evan | the embed API doesn't have to be C++, of course. |
| 21:43:06 | evan | it could be C |
| 21:43:26 | evan | which would make it possible to embed rubinius more places |
| 21:43:27 | brixen | for embedding, is the idea just to be able to invoke the interpreter to run some Ruby code? |
| 21:43:44 | evan | yes, so brixen brings up the next point |
| 21:43:44 | brixen | or do we expect to twiddle a bunch of stuff at the C/C++ api level when embedding? |
| 21:43:52 | evan | what is needed from an embedding API? |
| 21:44:13 | evan | at the basic level, there are 4 primary functions |
| 21:44:19 | evan | rbx_create_context() |
| 21:44:26 | evan | rbx_require_file(ctx, file) |
| 21:44:33 | evan | rbx_eval(ctx, file) |
| 21:44:37 | evan | rb_close_context(ctx) |
| 21:44:46 | evan | rbx_close_context(ctx) |
| 21:45:29 | evan | gaffo: is there anything else that you'd want? |
| 21:45:32 | brixen | it seems like if the embedding environment wants to expose stuff, it should provide that with a Ruby FFI lib that utilizes it |
| 21:45:37 | brixen | at least, that would be one way |
| 21:45:57 | evan | right |
| 21:46:01 | brixen | and then those 4 functions would handle the invocation of the interpreter+context |
| 21:46:02 | evan | thats actually a seperate API discussion |
| 21:46:10 | evan | namely, how does an embedded rubinius communicate with it's embedder |
| 21:46:15 | brixen | yeah |
| 21:46:29 | brixen | well, those 4 are the minimum, is what you're saying |
| 21:46:31 | evan | in some cases, there won't be the need for that |
| 21:46:37 | evan | exactly |
| 21:46:52 | evan | there are use cases where the embedded ruby code doesn't know it's embedded |
| 21:46:57 | brixen | sounds like we should start there |
| 21:46:57 | evan | where there are no special APIS |
| 21:46:59 | brixen | yeah |
| 21:48:27 | brixen | evan: does the create_context load the Kernel? |
| 21:48:34 | evan | yes |
| 21:48:36 | brixen | ok |
| 21:48:48 | evan | or it could be a separate function to do so |
| 21:48:50 | brixen | so it's fully booted and ready to run userland ruby code |
| 21:49:03 | evan | create_context() + set_data_path() + boot_context() |
| 21:49:08 | brixen | yeah |
| 21:49:14 | brixen | we could expose the others |
| 21:49:17 | evan | sure |
| 21:50:39 | brixen | this would be rad |
| 21:50:40 | evan | the reason i haven't done this is time and knowledge |
| 21:50:45 | evan | i'd like an embedder to guide the process |
| 21:50:54 | brixen | yeah |
| 21:50:54 | evan | embedder being someone who wants to embed |
| 21:50:59 | evan | gaffo: you following along? |
| 21:51:26 | brixen | I want to start playing with android |
| 21:51:45 | brixen | I have a case-sensitive file system on my usb external drive |
| 21:51:56 | brixen | so I can actually run the sdk stuff |
| 21:53:05 | evan | ok |
| 21:53:07 | brixen | may need to use embedding for that |
| 21:53:20 | brixen | I'm hoping not, but the docs are rather confusing |
| 21:53:30 | gaffo | sorry... had to step out for a sec, catching up. light fliped on our big brother |
| 21:55:37 | gaffo | okay, so those basic functions sound like what we need. I've seen some other ones where you can get a value refernce to an object iniside of ruby /python, whatever but I don't think we need to go that far |
| 21:55:57 | gaffo | I was thinking at first that the embedded ruby would just call out to the embedded language with ffi |
| 21:56:45 | evan | we can add the ability to call methods and get objects back and call methods on those |
| 21:56:56 | evan | we can use the handle APIs for that. |
| 21:57:12 | brixen | yeah, an object lifetime API would be good |
| 21:57:33 | gaffo | yeah, I've usually seen like handle = bind_object("MyObject::Core") or somthing |
| 21:57:39 | brixen | or whatever you call managing object liveness when a reference lives in another GC's space |
| 21:57:51 | gaffo | aah |
| 21:58:06 | brixen | ie, therubyracer use case |
| 21:58:54 | evan | sure |
| 21:59:00 | brixen | where references to Ruby objects are maintained in Javascript objects |
| 21:59:43 | brixen | gaffo: but yes, I like the FFI option a lot |
| 22:00:00 | gaffo | well, that's where you get a bit more complicated. but you can simplify by just keeping handles to Pointers (or whatever ffi's Managed Pointer is) |
| 22:00:03 | brixen | but it does move the locus inside Ruby code |
| 22:00:05 | brixen | which can be fine |
| 22:00:10 | gaffo | locus? |
| 22:00:20 | brixen | if you have to drive a bunch from the C side, you need a C api |
| 22:00:23 | brixen | locus of control |
| 22:00:30 | gaffo | aah |
| 22:00:50 | brixen | ie, invoke the Ruby code and the embedding environment becomes more like a library to Ruby code |
| 22:01:00 | brixen | most C-ext are the opposite, it seems like |
| 22:01:05 | gaffo | yeah, I guess our game usually fires events into the scripting language like OnUpdate |
| 22:01:08 | brixen | Ruby becomes a library driven by the C code |
| 22:01:25 | brixen | gaffo: you could do that with callbacks in FFI |
| 22:01:48 | gaffo | true, register with things when you create the object |
| 22:01:50 | brixen | FFI adds an interesting dimension to this |
| 22:02:06 | brixen | Ruby didn't have FFI when a lot of C-interfacing stuff was written |
| 22:03:24 | evan | well |
| 22:03:37 | evan | it could be done with FFI callbacks, yes. |
| 22:03:48 | gaffo | but it does now :) |
| 22:03:49 | evan | but I think that having an explicit reference API would be more useful |
| 22:04:00 | evan | that could be used. |
| 22:04:12 | brixen | sure, it's not either/or |
| 22:04:13 | gaffo | evan, so a handle to a ruby object in c and vice versa? |
| 22:04:21 | evan | and given it would only have a few APIs, it would be easy to implement |
| 22:04:34 | evan | gaffo: you'd get a handle to a ruby object in C |
| 22:04:40 | evan | and you could call methods on that object |
| 22:04:43 | gaffo | inspecting ruby in c makes sense to me |
| 22:04:52 | gaffo | ruby's duck typed |
| 22:04:56 | evan | and there would be APIs to manage the lifetime of the reference |
| 22:05:07 | brixen | yeah, calling a method explicitly on a ruby object is just the dual of an FFI callback |
| 22:05:09 | evan | ie, you'd have to explicitly release/retain them |
| 22:05:14 | evan | to keep the ruby object alive. |
| 22:05:17 | gaffo | aah |
| 22:05:17 | brixen | both would be great depending on what you're doing |
| 22:05:33 | gaffo | hrm, so I'd think geting a reference would just mark it as held |
| 22:05:37 | evan | basically, it would be your responsibility to inform the GC what you're doing with the handle |
| 22:05:45 | gaffo | and you'd have to specifically release it |
| 22:05:46 | evan | so it can keep things happy |
| 22:05:53 | evan | yep |
| 22:05:57 | evan | thats the typical API |
| 22:06:07 | evan | i'd throw a reference counting step in there too |
| 22:06:12 | gaffo | yeah |
| 22:06:15 | evan | to make it less painful on the user |
| 22:06:20 | gaffo | might make an autopointer style handle |
| 22:06:25 | evan | so you can release/retain as you go along |
| 22:06:36 | evan | and the last retain would clear the handle so the GC could collect the object if it wishes |
| 22:06:50 | evan | gaffo: autopointer style? |
| 22:06:53 | evan | you mean C++ wise? |
| 22:06:56 | gaffo | yeah |
| 22:07:00 | gaffo | sorry, I think c++ |
| 22:07:02 | gaffo | :) |
| 22:07:09 | evan | oh yeah, we'd have that |
| 22:07:16 | evan | i'm thinking in terms of a simple C API atm |
| 22:07:22 | evan | then we can layer some C++ niceness on top of that |
| 22:07:26 | gaffo | true |
| 22:07:35 | evan | that makes the embedding API usable to a wider audience. |
| 22:07:49 | gaffo | I thing c people (and c++) would like the more explicit control as well where they had to tell it to release |
| 22:08:01 | gaffo | is rubinius mostly c or c++? |
| 22:08:01 | evan | yep |
| 22:08:06 | evan | C++ |
| 22:08:35 | evan | but the embedder shouldn't have to know that |
| 22:08:41 | evan | they just know "there is this C API I use." |
| 22:08:49 | evan | if we want to implement it in haskell, we can. |
| 22:09:07 | evan | paging dr. curry, dr. curry report to the operating room. |
| 22:09:53 | gaffo | that's a good point. I was thinking more that if they have the c++ compiler up then they can bind from c... but yes other languages can't talk to c++, just c |
| 22:10:36 | gaffo | so the other thing is the dependency on the filesystem |
| 22:12:46 | gaffo | as opposed to a java classloader style framework. I haven't dug that far into how it works though in rubinius. |
| 22:13:39 | gaffo | cool, the license is bsd so that makes it good for embedding too as you only have to include the copyright. GPL / LGPL sucks for games due to the linking issue |
| 22:14:13 | brixen | yeah, we don't use [L]GPL stuff either |
| 22:14:35 | brixen | gaffo: we can work out loading Ruby code however you need to |
| 22:14:43 | brixen | network, archive, whatever |
| 22:15:49 | evan | yes, loader wise |
| 22:15:51 | gaffo | brixen, cool. I'd think possibly just being able to provide a method that gives you the bytes for a given path would be good. |
| 22:15:54 | evan | we can do almost anything |
| 22:15:56 | gaffo | er to the interpreter |
| 22:16:00 | evan | we just need you to help guide us. |
| 22:16:30 | gaffo | kk. just thinking games guys typically pack everything down and want it obfuscated :) dirty proprietary coders :) |
| 22:16:38 | gaffo | so should I just work off master or stable or what? |
| 22:17:02 | brixen | master is good |
| 22:17:10 | brixen | you could also work in 2.0.0pre |
| 22:17:47 | brixen | gaffo: yeah, what we serialize bytecode to/from is already pretty pluggable |
| 22:17:54 | brixen | we use the filesystem because that's easy |
| 22:18:03 | brixen | and we don't do any obfuscation because we don't need it |
| 22:18:10 | brixen | but we can easily support it |
| 22:18:25 | gaffo | yeah, I didnt' need to do it until I switched to a games development company |
| 22:18:42 | gaffo | and realized why people hate LGPL so much. No shared objects on the playstation |
| 22:19:08 | brixen | if you look at lib/compiler/stages.rb at the Writer stage, and lib/compiler/compiled_file.rb |
| 22:19:16 | brixen | you can see how we write bytecode to disk |
| 22:19:39 | brixen | in the VM, we'd need to write some C++ load from a different format |
| 22:19:49 | brixen | what I'd actually like to do is make an API to the loader |
| 22:20:16 | brixen | ie, load normal bytecode from this file, then invoke X method to load the loader bytecode |
| 22:20:46 | brixen | so we can support infinitely many loader schemes without modifying the VM loader |
| 22:21:32 | brixen | your Ruby loader code could load a C ext with some fancy crypto-anarcho-super-duper-ofuscuatorilator |
| 22:21:52 | gaffo | true, making the loader be extensible in ruby would be badass |
| 22:22:09 | gaffo | very much like the classloader stuff in java, which allows all sorts of tomfoolery |
| 22:22:14 | brixen | yeah |
| 22:26:32 | gaffo | okay so compiled_file is doing the bytecode stuff. |
| 22:27:22 | gaffo | what does the loading of actual ruby code > rbc? |
| 22:27:48 | brixen | so, we marshal out in Ruby, because we run that in eg MRI during bootstrap build |
| 22:27:55 | brixen | but we marshal in in C++ |
| 22:28:02 | brixen | see vm/environment.cpp |
| 22:28:16 | brixen | run_file |
| 22:28:28 | brixen | and vm/marshal.cpp |
| 22:30:31 | gaffo | kk |
| 22:33:44 | gaffo | marshall.cpp looks very much like the compiled_file.rb stuff |
| 22:34:03 | gaffo | so where would I put my C api layer? and what's the best way to include it in your build? |
| 22:34:50 | evan | well, what do you want to do? |
| 22:36:21 | gaffo | the simple 4 functions I guess to start. It'd be nice to be able to just exec some ruby as well... lemme do a gist |
| 22:37:54 | evan | you can put them anywhere under vm |
| 22:38:04 | evan | we automatically compile all .c and .cpp files |
| 22:39:59 | brixen | perhaps vm/api ? |
| 22:40:04 | gaffo | kk |
| 22:40:10 | evan | sure |
| 22:40:20 | gaffo | basically I think the first step would be to have a trivial thing like this compile: https://gist.github.com/1043798 |
| 22:40:39 | gaffo | and of course work |
| 22:41:16 | brixen | oh, you want it to work, too?! |
| 22:41:20 | brixen | kids these days |
| 22:41:24 | gaffo | :) |
| 22:41:24 | brixen | yeah, that would be rad |
| 22:41:49 | gaffo | so is there a decent way to hook it into specs? |
| 22:42:02 | brixen | hmm |
| 22:42:03 | gaffo | well, do you even have any c++ specs/tests? |
| 22:42:09 | brixen | we have C++ tests |
| 22:42:10 | brixen | vm/test |
| 22:42:40 | gaffo | aah, cxxtest... |
| 22:42:59 | gaffo | (had to write my own testing framework for the ps3... that was enlightening) |
| 22:43:05 | brixen | heh |
| 22:43:16 | gaffo | I just stoled from cxx test and google test |
| 22:43:19 | brixen | yeah, we try to test the minimum possible in C++ tests and do the rest in specs |
| 22:43:30 | brixen | but I think you'd need some C++ tests for this api |
| 22:43:42 | gaffo | yeah, especially binding |
| 22:43:48 | gaffo | and ffi stuff |
| 22:43:49 | brixen | yeah |
| 22:44:01 | brixen | well, probably not FFI |
| 22:44:35 | gaffo | well, I was thinking a end to end test maybe to make sure it was working... just a simple sanity c > ruby > c , verify call |
| 22:44:44 | brixen | yep, sounds great |
| 22:45:14 | Zr40 | ah, I need to register a 'debugger' thread. |
| 22:45:15 | brixen | gaffo: you'll need to add some install stuff to copy the vm/api/embed.h to <include>/rubinius/embed.h |
| 22:45:21 | brixen | see rakelib/install.rake |
| 22:45:25 | Zr40 | nevermind that |
| 22:46:16 | gaffo | so does rubinius run in it's own thread? is it blocking, what's the model do you think? |
| 22:46:41 | brixen | should be able to do whatever you want in the embedding app |
| 22:46:44 | gaffo | kk |
| 22:46:45 | brixen | we're thread-safe |
| 22:46:59 | gaffo | as far as you know :) |
| 22:47:02 | brixen | in that we have explicit thread state that we pass in |
| 22:47:05 | brixen | yes, afaik :) |
| 22:47:21 | brixen | we don't use globals |
| 22:47:33 | evan | there are a couple places some thread locals are used |
| 22:47:46 | evan | so rbx_require_file should do VM::set_current(ctx->state) |
| 22:47:52 | evan | before calling down |
| 22:47:56 | evan | to set the thread local |
| 22:47:58 | evan | but thats it. |
| 22:49:19 | gaffo | yeah, I could see an embedded app wanting to do either or. having c++ and rbx running at the same time (maybe the eval call blocks), or just step into and evaluate "update" on all objects in a game loop. |
| 22:49:55 | evan | you can have both |
| 22:50:00 | evan | you can easily spawn another thread |
| 22:50:03 | evan | and have it run |
| 22:50:06 | gaffo | yep |
| 22:50:27 | gaffo | you guys are going with native threads, correct? |
| 22:52:07 | evan | yep |
| 22:54:39 | gaffo | cool, well that sounds like a good place to get started. when I compiled rubinius before I saw it pulled llvm. What all dependencies does rubinius have and I'm assuming that you guys are just building it all into the executable instead of using .so's? |
| 22:55:26 | evan | yep |
| 22:55:39 | evan | zlib and llvm are the main ones |
| 22:55:46 | evan | extensions need readline and openssl |
| 22:55:52 | evan | we should them listed in the readme |
| 22:56:05 | gaffo | so the trick will be getting that all to compile on android / ios / ps3 / palm :) |
| 22:56:26 | brixen | http://rubini.us/doc/en/getting-started/ |
| 22:56:32 | brixen | there's a requirements page |
| 22:56:44 | brixen | readline is no longer a hard requirement, we can fall back to rb-readline |
| 22:57:37 | gaffo | I would think that readline is a special case for embedding, then again maybe someone is creating a scripting shell :) |
| 22:58:01 | brixen | could be |
| 22:58:03 | evan | for an embedded platform |
| 22:58:09 | evan | readline and ssl can be left out |
| 22:58:09 | brixen | I wish I had IRB on my iphone |
| 22:58:11 | evan | pretty easily. |
| 22:58:22 | evan | we don't have switches for that now |
| 22:58:26 | evan | but you can just comment out building them |
| 22:58:47 | brixen | I can add them easily too |
| 22:58:56 | gaffo | so how do you guys like c++ compiling in rake? |
| 22:59:04 | gaffo | first major project I've seen do it... |
| 22:59:04 | evan | gaffo: it sucks. |
| 22:59:07 | evan | we built our own tool. |
| 22:59:18 | evan | called daedalus |
| 22:59:29 | evan | that we use to build the bulk of the C++ |
| 22:59:41 | evan | but it's run from rake |
| 23:00:07 | evan | gaffo: also, you can disable using llvm |
| 23:00:23 | evan | which will just mean things are quite a bit slower |
| 23:01:07 | gaffo | llvm is a vm framework I think? |
| 23:01:23 | evan | sort of |
| 23:01:28 | evan | it's really a compiler framework |
| 23:01:31 | evan | that we use for the JIT |
| 23:03:46 | gaffo | aah |
| 23:04:29 | gaffo | now I gotta figure out what ide to use for c++ / ruby coding. stupid aptana taking over all ruby eclipseishness. |
| 23:04:56 | evan | i'll be of no help there. |
| 23:05:23 | gaffo | you guys all mac guys? |
| 23:06:03 | evan | yep |
| 23:06:39 | brixen | gaffo: gvim |
| 23:10:18 | evan | rad |
| 23:10:24 | evan | I added a Bytes configuration type |
| 23:10:26 | evan | so you can do |
| 23:10:36 | evan | -Xgc.young_bytes=10M |
| 23:10:41 | evan | for 10Mbs |
| 23:12:04 | brixen | yay! |
| 23:12:11 | brixen | I was going to ask you about that |
| 23:12:20 | evan | SUUURE you were |
| 23:12:20 | evan | :D |
| 23:12:21 | brixen | but everything was constants in immix |
| 23:12:25 | brixen | I was! |
| 23:12:38 | evan | RIIIGHT |
| 23:12:38 | evan | :D |
| 23:12:43 | brixen | I think 5mb may be a better "scripting" default |
| 23:13:03 | brixen | if people are really worried about rbx startup footprint |
| 23:13:06 | evan | k |
| 23:13:54 | brixen | I think we're much closer to the neighborhood of MRI on startup |
| 23:14:22 | brixen | but it looks like we're heavier than we are |
| 23:14:54 | jdsiegel | just big boned, that's all |
| 23:14:55 | brixen | oh wait, you added that for young_bytes |
| 23:15:03 | brixen | I want it for mature_bytes! |
| 23:15:15 | brixen | Bytes is handy though |
| 23:15:22 | brixen | we also need RadioButton |
| 23:16:46 | evan | what did you want to tune, mature_bytes wise? |
| 23:16:48 | evan | the chunk size? |
| 23:17:29 | brixen | yeah |
| 23:18:40 | brixen | pretty soon, the configuration code will turn into ActiveRecord |
| 23:18:45 | brixen | complete with validations |
| 23:19:15 | brixen | "You have chosen a 10MB young generation. This will actually slow you down. Press Y to continue" |
| 23:20:06 | brixen | no wonder zed wanted to use a db for mongrel2 configuration |
| 23:20:22 | tarcieri | haha |
| 23:20:35 | brixen | it's actually a great idea |
| 23:21:13 | evan | hehe |
| 23:28:31 | boyscout | Increase the malloc threshold to 100M - b0bf4fc - Evan Phoenix |
| 23:33:40 | scoutmaster | rubinius#140: SUCCESS in 5 min 4 sec |
| 23:43:53 | jdsiegel | brixen: then specs for your configuration! |
| 23:45:43 | brixen | jdsiegel: heh |
| 23:46:49 | brixen | if I never, ever saw the MRI parser again it would be too soon |
| 23:55:30 | jdsiegel | brixen: is there ever a good time to use the "freeze" method? I'm a little fuzzy on problems with it. |
| 23:55:50 | brixen | jdsiegel: never a good reason, imo |
| 23:56:53 | jdsiegel | that's what I thought. Just see it a lot in libs with constant strings |
| 23:57:17 | brixen | that's pure cargo culting |