Show enters and exits. Hide enters and exits.
| 00:05:42 | lopex leaves the room. | |
| 00:08:23 | imajes leaves the room. | |
| 00:26:39 | nari leaves the room. | |
| 00:39:47 | fbuilesv enters the room. | |
| 00:43:25 | wmoxam enters the room. | |
| 00:49:28 | trythil leaves the room. | |
| 00:51:37 | fbuilesv leaves the room. | |
| 00:52:55 | imajes enters the room. | |
| 01:05:34 | nari enters the room. | |
| 01:07:06 | fbuilesv enters the room. | |
| 01:18:07 | imajes leaves the room. | |
| 01:39:34 | imajes enters the room. | |
| 01:41:16 | brapse leaves the room. | |
| 01:41:51 | yugui enters the room. | |
| 01:43:18 | Defiler | dbussink: Sure. Feel free to complain about Vlad to me |
| 01:53:12 | binary42 leaves the room. | |
| 01:53:16 | binary42 enters the room. | |
| 02:02:18 | rue leaves the room. | |
| 02:10:34 | imajes leaves the room. | |
| 02:23:22 | robin_dewd leaves the room. | |
| 02:30:50 | robin_dewd enters the room. | |
| 02:45:04 | lchin leaves the room. | |
| 02:46:31 | fbuilesv_ enters the room. | |
| 02:47:57 | fbuilesv_ leaves the room. | |
| 02:50:17 | lchin enters the room. | |
| 02:53:28 | fbuilesv_ enters the room. | |
| 03:02:05 | fbuilesv leaves the room. | |
| 03:09:13 | mernen leaves the room. | |
| 03:25:39 | headius_ leaves the room. | |
| 03:32:57 | nari leaves the room. | |
| 03:43:27 | fbuilesv enters the room. | |
| 03:43:52 | benburkert enters the room. | |
| 03:45:21 | cremes leaves the room. | |
| 03:55:20 | fbuilesv_ leaves the room. | |
| 03:58:59 | dysinger leaves the room. | |
| 04:05:02 | dysinger enters the room. | |
| 04:19:30 | trythil enters the room. | |
| 04:20:51 | headius enters the room. | |
| 04:37:58 | headius | I have a proposal for ffi I think is necessary to make it a good cross-impl library |
| 04:38:13 | headius | I think it needs to be included in rather than available on all modules |
| 04:38:51 | headius | if by loading ffi all these methods are added to all modules, we're polluting a lot of namespaces |
| 04:40:11 | headius | it's problematic enough that rubinius doesn't have to require 'ffi' |
| 04:40:31 | headius | also, I'm having some trouble getting some basic ffi stuff to work in rubinius, not sure if I'm doing something wrong.. |
| 04:40:47 | headius | module Foo; attach_function :getuid, :getuid, [], :uint; end doesn't seem to find uint |
| 04:41:04 | headius | nor does it find it if I set_ffi_lib "c" or "libc" |
| 04:41:51 | headius | drbrain: anything look wrong with that? |
| 04:43:22 | trythil leaves the room. | |
| 04:46:59 | qrush_ leaves the room. | |
| 04:50:15 | headius | actually I guess it would be extend |
| 04:50:23 | headius | module Foo; extend FFI; set_ffi_lib ..... |
| 04:51:37 | lxb enters the room. | |
| 05:00:15 | benburkert leaves the room. | |
| 05:08:03 | benburkert enters the room. | |
| 05:10:25 | enebo enters the room. | |
| 05:10:58 | nari enters the room. | |
| 05:11:50 | enebo leaves the room. | |
| 05:12:56 | enebo enters the room. | |
| 05:15:08 | enebo leaves the room. | |
| 05:15:26 | enebo enters the room. | |
| 05:16:55 | enebo leaves the room. | |
| 05:18:13 | enebo enters the room. | |
| 05:19:40 | enebo leaves the room. | |
| 05:20:34 | lxb leaves the room. | |
| 05:21:00 | enebo enters the room. | |
| 05:23:04 | enebo leaves the room. | |
| 05:23:47 | enebo enters the room. | |
| 05:25:22 | enebo leaves the room. | |
| 05:26:18 | enebo enters the room. | |
| 05:28:06 | enebo leaves the room. | |
| 05:29:05 | enebo enters the room. | |
| 05:30:33 | enebo leaves the room. | |
| 05:31:53 | enebo enters the room. | |
| 05:55:30 | trythil enters the room. | |
| 05:58:40 | brapse enters the room. | |
| 06:12:30 | jackdempsey leaves the room. | |
| 06:13:40 | nari leaves the room. | |
| 06:15:46 | antares_ enters the room. | |
| 06:20:34 | antares_ leaves the room. | |
| 06:31:45 | ezmobius enters the room. | |
| 06:31:57 | obvio171 enters the room. | |
| 06:35:01 | jackdempsey enters the room. | |
| 06:42:05 | jackdempsey leaves the room. | |
| 06:44:39 | benburkert leaves the room. | |
| 06:44:53 | imajes_office leaves the room. | |
| 06:45:36 | imajes enters the room. | |
| 06:48:54 | botanicus enters the room. | |
| 06:51:40 | nari enters the room. | |
| 06:54:32 | antares_ enters the room. | |
| 07:12:05 | yugui leaves the room. | |
| 07:19:00 | brapse leaves the room. | |
| 07:46:15 | dysinger leaves the room. | |
| 07:57:57 | jgre enters the room. | |
| 08:03:35 | wvdschel enters the room. | |
| 08:19:57 | w1rele55 enters the room. | |
| 08:24:46 | ezmobius leaves the room. | |
| 08:27:53 | trythil leaves the room. | |
| 08:30:18 | headius leaves the room. | |
| 08:32:19 | rodimius leaves the room. | |
| 08:42:38 | yugui enters the room. | |
| 08:48:13 | srbaker enters the room. | |
| 09:13:16 | obvio171 leaves the room. | |
| 09:15:31 | headius enters the room. | |
| 09:16:12 | antares_ leaves the room. | |
| 09:24:30 | NoKarma enters the room. | |
| 09:26:36 | headius leaves the room. | |
| 09:39:43 | Maledictus enters the room. | |
| 09:40:41 | imajes_ enters the room. | |
| 09:48:23 | imajes leaves the room. | |
| 09:55:16 | pauldix enters the room. | |
| 10:19:53 | octopod enters the room. | |
| 10:27:46 | chris2 enters the room. | |
| 10:28:03 | rodimius enters the room. | |
| 10:29:52 | rue enters the room. | |
| 10:37:31 | lchin leaves the room. | |
| 10:45:43 | nari leaves the room. | |
| 11:00:20 | benny leaves the room. | |
| 11:12:23 | yugui leaves the room. | |
| 11:24:43 | BlackEdder enters the room. | |
| 11:25:33 | BlackEdder enters the room. | |
| 11:27:31 | nari enters the room. | |
| 11:33:44 | Maledictus leaves the room. | |
| 11:36:50 | BlackEdder enters the room. | |
| 11:48:51 | inspired enters the room. | |
| 12:10:18 | thehcdreamer enters the room. | |
| 12:11:41 | thehcdreamer leaves the room. | |
| 12:26:07 | qrush enters the room. | |
| 12:27:30 | enebo enters the room. | |
| 12:39:38 | inspired leaves the room. | |
| 12:47:31 | gnufied enters the room. | |
| 12:56:25 | cremes enters the room. | |
| 13:00:48 | imperator leaves the room. | |
| 13:03:20 | qrush leaves the room. | |
| 13:03:43 | qrush enters the room. | |
| 13:08:08 | cremes leaves the room. | |
| 13:10:10 | enebo leaves the room. | |
| 13:12:47 | weepy enters the room. | |
| 13:12:52 | weepy | hello - |
| 13:13:03 | weepy | - will rubinius support any kind of compilation ? |
| 13:13:10 | weepy | to byte code |
| 13:21:03 | qrush leaves the room. | |
| 13:22:09 | gnufied | weepy, it already supports |
| 13:22:40 | weepy | so e.g. one of the downsides for ruby as a vendor is obviously that all your code is open |
| 13:22:55 | weepy | this shouldn't be a problem with Rbus |
| 13:22:57 | weepy | ? |
| 13:24:19 | gnufied | yes, thats right. although, I am not sure, if bytecode are [yet] redistributable or not. |
| 13:24:57 | weepy | gnufied: ah ok thanks for the headsu |
| 13:26:33 | hemulen enters the room. | |
| 13:30:56 | inspired enters the room. | |
| 13:45:25 | jw_cub leaves the room. | |
| 13:59:30 | cremes enters the room. | |
| 14:03:28 | AndrewO enters the room. | |
| 14:04:35 | dbussink | weepy: byte code is the same everywhere |
| 14:04:48 | weepy | sweet |
| 14:04:55 | dbussink | but i don't see the downside of open code |
| 14:05:02 | weepy | ?? |
| 14:05:03 | dbussink | because bytecode is still decompilable of course |
| 14:05:15 | dbussink | and we do everything as services :P |
| 14:05:16 | weepy | more like u don't see the upside |
| 14:05:21 | weepy | to compiled code |
| 14:05:26 | dbussink | well, bytecode is really nice to have |
| 14:05:33 | weepy | yes |
| 14:05:35 | dbussink | but this is like the last point on my advantages list :P |
| 14:06:04 | weepy | but do u see the problem for vendors if they have to ship their code open |
| 14:06:20 | dbussink | well, obfuscation is not security |
| 14:07:21 | fbuilesv | weepy: you can pretty much disassemble everything from C to Java so compiled code != security :) |
| 14:07:57 | weepy | yes |
| 14:07:59 | weepy | i know this |
| 14:08:12 | weepy | but it does make it alot harder |
| 14:09:47 | dbussink | well, not imho :P |
| 14:10:12 | dbussink | because the people who want to do that are probably persistent in their effort anyway |
| 14:11:14 | dbussink | but offer your stuff as a service, problem solved ;) |
| 14:12:53 | weepy | sure thing |
| 14:13:32 | weepy | you can't deny that it raises the barrier to entry |
| 14:14:06 | NoKarma leaves the room. | |
| 14:17:28 | fbuilesv | weepy: that really depends a lot on the language. JBuilder was able to open a .class file a few years ago and it'd show you must of the source code. That's pretty easy by my standards :) |
| 14:18:23 | weepy | ok how about compiled C++ :) :) |
| 14:18:49 | rue leaves the room. | |
| 14:18:54 | weepy | with optimization turn on :D |
| 14:19:20 | fbuilesv | weepy: harder I agree, that's why I said it depends on the language :) |
| 14:19:34 | fbuilesv | and actually, C++ is unreadable from source code too so it's not a valid point :) |
| 14:19:57 | weepy | compiled brainfuck .. |
| 14:20:17 | blakewatters enters the room. | |
| 14:20:59 | fbuilesv | that's probably easier to read than original brainfuck! |
| 14:21:08 | weepy | haha |
| 14:23:34 | AndrewO leaves the room. | |
| 14:34:38 | yukito enters the room. | |
| 14:38:43 | dysinger enters the room. | |
| 14:41:28 | wmoxam leaves the room. | |
| 14:42:47 | yasuhito enters the room. | |
| 14:51:17 | wvdschel leaves the room. | |
| 14:52:46 | weepy leaves the room. | |
| 14:59:50 | wmoxam enters the room. | |
| 15:00:07 | inspired leaves the room. | |
| 15:02:20 | antares_ enters the room. | |
| 15:36:55 | rubuildius_amd64 leaves the room. | |
| 15:43:35 | rue enters the room. | |
| 15:46:39 | rubuildius_amd64 enters the room. | |
| 15:50:09 | rubuildius_amd64 leaves the room. | |
| 15:51:14 | rubuildius_amd64 enters the room. | |
| 15:55:54 | rubuildius_amd64 leaves the room. | |
| 15:56:56 | rubuildius_amd64 enters the room. | |
| 16:00:03 | VVSiz enters the room. | |
| 16:07:19 | rue | Moo-rning |
| 16:08:33 | benburkert enters the room. | |
| 16:10:49 | yasuhito leaves the room. | |
| 16:24:50 | srbaker leaves the room. | |
| 16:31:24 | AndrewO enters the room. | |
| 16:33:52 | wmeissner enters the room. | |
| 16:37:00 | benburkert leaves the room. | |
| 16:39:09 | hemulen leaves the room. | |
| 16:50:05 | evan | morning |
| 16:51:05 | botanicus leaves the room. | |
| 16:53:20 | botanicus enters the room. | |
| 16:57:18 | brixen | morning |
| 16:57:32 | yukito leaves the room. | |
| 16:58:50 | dbussink | afternoon :) |
| 16:58:52 | dbussink | people up early here or late? :P |
| 17:00:07 | headius enters the room. | |
| 17:01:36 | jgre leaves the room. | |
| 17:03:49 | brixen | dbussink: heh, both :) |
| 17:05:18 | brixen | evan: here's the ticket you requested: http://rubinius.lighthouseapp.com/projects/5089-rubinius/tickets/674 |
| 17:05:35 | headius | g'day |
| 17:05:42 | lopex enters the room. | |
| 17:05:46 | brixen | evan: also, when you have a sec, can you further review my commits from yesterday? |
| 17:05:52 | brixen | headius: g'day mate |
| 17:09:09 | evan | sure. |
| 17:11:07 | brixen | evan: one of the big things I need to know is how to raise ruby exceptions from c++ |
| 17:11:17 | evan | yep |
| 17:11:19 | evan | i don't even know yet |
| 17:11:23 | brixen | heh ok |
| 17:11:25 | evan | i haven't coded that ayet. |
| 17:11:29 | brixen | yeah |
| 17:12:57 | jbarnette enters the room. | |
| 17:14:00 | shayarnett enters the room. | |
| 17:14:04 | benburkert enters the room. | |
| 17:17:11 | c0sin enters the room. | |
| 17:17:51 | benburkert_ enters the room. | |
| 17:24:14 | jgre enters the room. | |
| 17:27:11 | wmeissner leaves the room. | |
| 17:29:36 | Yurik enters the room. | |
| 17:30:57 | Maledictus enters the room. | |
| 17:33:44 | Fullmoon enters the room. | |
| 17:36:08 | w1rele55 leaves the room. | |
| 17:37:24 | ijcd enters the room. | |
| 17:37:34 | benburkert leaves the room. | |
| 17:38:13 | ijcd leaves the room. | |
| 17:38:17 | ijcd enters the room. | |
| 17:38:32 | w1rele55 enters the room. | |
| 17:38:45 | moofbong enters the room. | |
| 17:39:31 | ijcd leaves the room. | |
| 17:39:40 | nexcastellan | Brief discussion on parallel garbage collectors in Java on JoelOnSoftware discussion forum: http://discuss.joelonsoftware.com/default.asp?joel.3.658424.6 |
| 17:41:27 | moofbong leaves the room. | |
| 17:41:41 | moofbong enters the room. | |
| 17:41:48 | evan | oh cool |
| 17:41:58 | hemulen enters the room. | |
| 17:44:17 | hemulen leaves the room. | |
| 17:44:57 | hemulen enters the room. | |
| 17:45:51 | nicksieger leaves the room. | |
| 17:46:51 | nicksieger enters the room. | |
| 17:47:57 | headius | not much of a discussion unfortunately |
| 17:48:07 | evan | nope |
| 17:48:21 | evan | headius: any idea how much people change those options? |
| 17:48:23 | evan | just curious |
| 17:48:25 | nexcastellan | No, but the linked blog is interesting. |
| 17:48:51 | headius | in large java deployments it's pretty common to tweak some of them |
| 17:49:08 | headius | most apps don't require the performance that comes from perfecting all those settings |
| 17:49:29 | nexcastellan | I know the company I work for recently switched to "Ruby Enterprise Edition" because the GC exhibited better characteristics for our Ruby site. That's nothing to do with Java, of course. |
| 17:49:55 | headius | we keep meaning to provide a better set of options for JRuby, for example...several benchmarks perform better with a different new gen size ratio |
| 17:50:20 | headius | nexcastellan: yeah, I'm not sure I understand what's better about Ruby EE GC |
| 17:50:53 | headius | it still can't be compacting or paralell |
| 17:50:56 | nexcastellan | Ruby EE offers copy-on-write, a big win if you fork a lot of processes. And tcmalloc is much better than the system allocator for many people. |
| 17:51:14 | headius | yeah, COW doesn't help GC perf in any way though |
| 17:51:14 | nexcastellan | But no, not compacting, not parallel. We have big hopes for Rubinius's ability to do better GC. |
| 17:51:17 | headius | actually makes it a bit slower |
| 17:51:32 | nexcastellan | True but boy can you save a chunk of memory if you fork a lot of processes. |
| 17:52:13 | headius | well hopefully that won't be necessary soon |
| 17:52:23 | headius | er, though I guess it will always be necessary on MRI |
| 17:52:32 | nexcastellan | What won't be necessary? Forking? |
| 17:52:36 | headius | yeah |
| 17:53:14 | nexcastellan | Why do you say that? Are you thinking of high-quality ruby thread implementations as an alternative? |
| 17:54:18 | Fullmoon leaves the room. | |
| 17:55:44 | headius | well, jruby is already native threaded |
| 17:56:01 | nexcastellan | Yeah. Green threads for the lose. |
| 17:56:02 | headius | so for example, you could run an entire merb site off one instance, across cores |
| 17:56:27 | headius | when/if rails gets that ability, there wouldn't be any need to have multiple rails instances either |
| 17:57:07 | Defiler | evan: Any idea how I can work around this? It's pretty irritating.. http://gist.github.com/2274 |
| 17:57:31 | Defiler | evan: When llvm gets built, it changes the modes on its Makefiles, but doesn't regenerate them from scratch |
| 17:57:46 | evan | Defiler: git status >> .gitignore |
| 17:57:49 | Defiler | So I can't just put them in gitignore and expect them to appear, but they cluter up the status and make it irritating to pull |
| 17:58:07 | Defiler | Can a file be checked into git but then ignored? |
| 17:58:13 | evan | yep |
| 17:58:53 | Defiler | http://pastie.org/242585 |
| 17:58:55 | Defiler | so that change is OK |
| 17:59:11 | evan | yea |
| 17:59:13 | evan | thats fine |
| 18:01:21 | rue | Can we get boyscout to report the cpp commits too? |
| 18:01:27 | Defiler | OK.. another retarded git question.. |
| 18:01:41 | Defiler | Let's say I have A, B, and C as the three most recent hashes in git log |
| 18:01:53 | headius leaves the room. | |
| 18:01:57 | Defiler | A is that change to .gitignore, C is somebody else's most-recent change to the remote cpp brnach |
| 18:01:58 | rue | The hashing algo is pretty poor |
| 18:02:09 | evan | rue: yes. i'll get that going today |
| 18:02:12 | Defiler | I want B to go away without a trace |
| 18:02:20 | Defiler | (and its changes) |
| 18:02:22 | rue | evan: Ta |
| 18:02:35 | Defiler | neither 'A' nor 'B' has been pushed |
| 18:03:26 | rue | I think git-cherry-pick would be the one |
| 18:03:44 | Defiler | I thought that did the reverse.. created a new commit from an existing one? |
| 18:04:29 | headius enters the room. | |
| 18:04:37 | evan | Defiler: one sec. |
| 18:05:00 | rue | Defiler: You are right, I thought it just selected the commit |
| 18:05:12 | Defiler | The way I know to do it currently is to create a diff for 'A', reset to C, and then apply the patch and re-commit A |
| 18:05:18 | Defiler | but I was wondering if there was a better idea |
| 18:05:23 | rue | Defiler: How about rebase --interactive? Squash the ones you do not want |
| 18:05:28 | evan | Defiler: easiest is to just extract the commit, reset back to C, and reapply |
| 18:05:30 | evan | oh yeah! |
| 18:05:38 | evan | rebase --interactive will set you skip |
| 18:06:50 | rue | Provided B is not shared, mind you |
| 18:07:04 | rue | If it is, reverting is best |
| 18:07:36 | ijcd enters the room. | |
| 18:07:54 | Defiler | Yeah, un-pushed.. cool |
| 18:09:44 | gnufied leaves the room. | |
| 18:13:40 | octopod leaves the room. | |
| 18:17:43 | Defiler | llvm is fun to build. |
| 18:17:51 | brixen | heh, takes a long time |
| 18:18:15 | brixen | evan: I'm going to make some changes to code in kernel/** in the cpp vm unless you object |
| 18:18:30 | brixen | I figure we can cherry pick when merging |
| 18:18:42 | brixen | s/cpp vm/cpp branch/ |
| 18:19:10 | evan | brixen: thats fine |
| 18:21:06 | josb enters the room. | |
| 18:21:22 | brixen | k |
| 18:23:14 | Defiler | cpp files just generally take vastly longer to compile than c, right? |
| 18:23:20 | Defiler | (even these days? My C++ is all old) |
| 18:23:27 | Fullmoon enters the room. | |
| 18:23:54 | evan | yes |
| 18:30:53 | Defiler | Is there an easy way to run just one file worth of cpp tests? |
| 18:32:15 | rue | They should not take _vastly_ longer. Slightly so if you use templates a bunch |
| 18:32:29 | rue | The typechecking is the main drag |
| 18:37:02 | Arjen_ enters the room. | |
| 18:45:26 | brixen | Defiler: there was an :only task (see 34616e105) |
| 18:47:44 | Defiler | brixen: OK, so that uses an option to the 'test runner builder' perl script, it seems |
| 18:48:00 | Defiler | and would therefore replace vm/test/runner, I guess |
| 18:48:27 | Defiler | So if we have an 'only' env/task, we would need to also make 'rake test' rebuild test/runner if needed |
| 18:48:49 | Defiler | Though I guess it might be convenient to have 'rake test' run the subset you selected until told otherwise |
| 18:56:14 | brixen | I must say I'm spoiled with rspec, using cxxtest feels like using 2 lb sledge hammer to drive finish nails |
| 18:59:13 | Defiler | whereas rspec is an 8# sledge used to drive jewelled Cartier pens |
| 18:59:14 | Defiler | :) |
| 19:00:10 | brixen | heh |
| 19:01:45 | brixen | Defiler: this is what rue's got http://gist.github.com/2808 |
| 19:02:23 | brixen | seems possible to do without deviating from rspec syntax |
| 19:02:37 | brixen | using collector/emitter objects |
| 19:02:38 | Defiler | neat |
| 19:03:13 | Defiler | I like this |
| 19:04:38 | brixen | yeah |
| 19:04:51 | Fullmoon leaves the room. | |
| 19:05:01 | brixen | still would like to wrap that in normal rspec syntax |
| 19:14:28 | pauldix leaves the room. | |
| 19:14:53 | headius | perl script? |
| 19:18:20 | brixen | speaking of perl, I didn't get to any of the perls talks at oscon, but supposedly parrot is alive and well, for some values of well |
| 19:18:41 | brixen | sadly, I even missed the state of the onion :( |
| 19:21:55 | headius | I think duke nukem forever is alive and well too |
| 19:25:57 | brixen | evan: for the sampler primitives, do we want to make a proper Sampler cpp class? |
| 19:27:48 | brixen | I guess we don't really want a bag of misc primitives |
| 19:31:47 | Fullmoon enters the room. | |
| 19:32:46 | headius | with the current cpp vm, are any of those cpp types holding methods actually used? |
| 19:34:09 | brixen | how do you mean? |
| 19:34:15 | imajes enters the room. | |
| 19:34:56 | Fullmoon leaves the room. | |
| 19:48:59 | ezmobius enters the room. | |
| 19:49:38 | wyhaines enters the room. | |
| 19:55:42 | octopod enters the room. | |
| 19:57:24 | headius_ enters the room. | |
| 19:57:24 | headius leaves the room. | |
| 20:03:23 | headius | brixen: well, is the Fixnum class ever used as the type of a fixnum object? |
| 20:03:50 | headius | behind the scenes, is there a "new Fixnum" constructed to back the ruby object? |
| 20:04:52 | drbrain | how do exceptions get raised in a primitive in the new vm? |
| 20:07:08 | tarcieri | heh, headius's initials are CON? :) |
| 20:07:32 | dbussink | headius: nope, not afaik |
| 20:08:16 | headius | dbussink: ok, I guess i'm a little fuzzy on how separating them into these classes is more useful than just namespacing them, since they're not virtual and not attached to an actual object instance |
| 20:08:36 | headius | seems like classes are being used as namespaces |
| 20:08:37 | dbussink | well, imho it's clearer now then in the old vm |
| 20:08:54 | dbussink | that's the main reason behind it |
| 20:09:45 | headius | ok, but why classes instead of namespaces |
| 20:10:37 | brixen | drbrain: raising exceptions hasn't been implemented yet |
| 20:11:02 | brixen | drbrain: see the logs about 9:11 pdt today |
| 20:11:31 | Defiler | headius: The idea is to be able to 'typecast' a regular Ruby object into a matching C++ object |
| 20:11:39 | Defiler | To make writing the VM code cleaner and easier |
| 20:12:11 | brapse enters the room. | |
| 20:12:13 | drbrain | thanks |
| 20:12:14 | Defiler | Instead of having to explain to, say, gdb that this thing is a Hash object |
| 20:12:35 | headius | Defiler: so although it's not constructed as a Fixnum, you can typecast it to Fixnum? |
| 20:12:54 | Defiler | Fixnum isn't a great example because we don't really 'allocate' one even in Ruby |
| 20:12:56 | brixen | drbrain: also, you can add to the list of questions in #674 |
| 20:13:03 | sunblush enters the room. | |
| 20:13:04 | Defiler | but, say, Array |
| 20:13:36 | Defiler | The idea (as I understand it) is to have the Ruby object we create for that be in a data format that the C++ system can handle without a conversion |
| 20:13:50 | brixen | Defiler: yep, you are right |
| 20:13:51 | Defiler | via as<Array>blah |
| 20:14:16 | Defiler | Fixnum is still just a tagged pointer, though |
| 20:14:36 | Defiler | I say 'just' even though they are awesome |
| 20:14:57 | drbrain | brixen: done! |
| 20:15:22 | drbrain | how does tcmalloc compare to jemalloc? |
| 20:16:32 | nexcastellan | I had good luck with tcmalloc compared to jemalloc. |
| 20:16:45 | nexcastellan | I'll see if I can find stats, probably not. |
| 20:16:46 | headius | Defiler: how does gdb know it's anything other than object with that logic though |
| 20:17:14 | drbrain | I'm looking for something like the benchmark results they've got on the tcmalloc page |
| 20:17:20 | dbussink | drbrain: http://blog.pavlov.net/2007/12/06/more-allocator-data-tcmalloc-edition/ |
| 20:17:21 | drbrain | pretty graphs for a wide range of tests |
| 20:17:27 | dbussink | maybe that's helpful |
| 20:17:31 | Defiler | The allocation system marks the object with its type I believe |
| 20:19:12 | nexcastellan | Nope, I have no useful stats. We were looking at using jemalloc or tcmalloc for MRI Ruby (with gc-cow patch, so essentially Ruby Enterprise Edition). |
| 20:19:22 | drbrain | "Well you have to be careful there, tcmalloc apparently defers frees, and is not really a general purpose malloc." |
| 20:19:27 | drbrain | I wonder what that means |
| 20:19:28 | brixen | headius: http://pastie.org/242680 |
| 20:19:31 | nexcastellan | We ended up going with Ruby Enterprise Edition and using tcmalloc. There was a weird socket error that would occur with jemalloc that I could never track down. |
| 20:19:53 | headius | obj_type |
| 20:20:03 | headius | so it isn't really that object, it just gets a field to say what it is |
| 20:20:32 | headius | so again, I'm still a bit fuzzy on the benefit of the subtypes if no objects are actually the subtypes |
| 20:20:34 | drbrain | also, since ruby is single-threaded, you're not going to see any of the benefits of jemalloc |
| 20:20:47 | nexcastellan | tcmalloc was better than system allocator wrt CPU usage _and_ memory usage. |
| 20:21:22 | nexcastellan | jemalloc had better memory usage than the system allocator (but was beaten by tcmalloc), but at a CPU hit. We fork quite a bit, though, so your usage pattern may be different. |
| 20:21:43 | Defiler | headius: They come directly from having it be a huge hassle in shotgun |
| 20:22:01 | nexcastellan | You could strip out much of the threading code from jemalloc for a fair amount of win, but tcmalloc was still better. |
| 20:22:01 | Defiler | It provides a unified way of working with Ruby objects in the C code |
| 20:22:18 | binary42 leaves the room. | |
| 20:22:49 | headius | fwiw, hotspot at least also has a thread-local allocation buffer for those reasons |
| 20:23:02 | headius | of course it's also native threaded, so there's a real benefit there, but same concept |
| 20:23:39 | tarcieri | Rubinius could really do with thread-local heaps |
| 20:24:11 | tarcieri | since it's effectively shared-nothing between threads |
| 20:24:54 | headius | wouldn't help normal execution perf though |
| 20:25:09 | tarcieri | nope, only matters for MVM |
| 20:28:09 | botanicus leaves the room. | |
| 20:29:20 | w1rele55 leaves the room. | |
| 20:29:43 | w1rele55 enters the room. | |
| 20:31:10 | w1rele55 leaves the room. | |
| 20:34:06 | drbrain | "TCMalloc currently does not return any memory to the system." |
| 20:34:11 | drbrain | ah, that's a real bummer |
| 20:37:32 | hemulen | has anyone looked at the ravenbrook memory pool system project? |
| 20:38:14 | nexcastellan | I'm sitting in gdb with a couple of OBJECTs I need to investigate. I'm trying to track down a namespace issue. What additional information can I get from gdb with an OBJECT? |
| 20:38:46 | Defiler | beyond what _inspect() shows, I guess you mean? |
| 20:38:58 | drbrain | I thought there was an inspect-esque function floating around in there |
| 20:39:09 | nexcastellan | Ahh, _inspect is helpful. |
| 20:39:12 | Defiler | p _inspect(some_gdb_thing) |
| 20:39:29 | nexcastellan | Thanks! That actually may be sufficient, at least to get to the next step of debugging. |
| 20:39:49 | Arjen_ leaves the room. | |
| 20:40:02 | Defiler | Cool |
| 20:40:16 | ijcd enters the room. | |
| 20:41:11 | dfg59 enters the room. | |
| 20:44:52 | ryanlowe enters the room. | |
| 20:46:47 | headius leaves the room. | |
| 20:46:59 | headius enters the room. | |
| 20:56:23 | Defiler | brixen: You know, we should take that paste you did from gdb a minute ago, and turn it into a doc |
| 20:56:47 | Defiler | with comments on each piece |
| 20:57:47 | brixen | sure |
| 20:58:06 | Defiler | Though hopefully 'IsFrozen = 0' doesn't need a comment |
| 20:58:33 | brixen | I added this also, to give evan (and us) a skeleton to add explanation to: http://rubinius.lighthouseapp.com/projects/5089/adding-dir-to-c-vm |
| 20:58:47 | Defiler | Damn, nice |
| 20:58:49 | brixen | I'd be in favor of converting all this to rdoc in our doc dir |
| 20:59:00 | brixen | all of our LH how-tos |
| 20:59:07 | Defiler | Gah this is the best document we have ever had |
| 20:59:09 | brixen | and be able to auto-gen pages for rubini.us |
| 20:59:43 | brixen | it needs a lot of added explanation |
| 21:01:00 | Defiler | How do I edit this page? |
| 21:01:10 | Defiler | Oh, somehow I am not signed in? |
| 21:01:13 | brixen | should have an edit page link below Overview |
| 21:01:14 | brixen | yeah |
| 21:02:02 | brixen | grabbing some food, bbiab.. |
| 21:06:49 | twbray enters the room. | |
| 21:09:02 | brixen | hmm, actually, how about an rdoc->html xform written in javascript and we'll serve our docs directly from the git repo |
| 21:10:36 | nicksieger leaves the room. | |
| 21:13:53 | jgre leaves the room. | |
| 21:14:03 | dbussink | brixen: if you want some examples for the raises, i've written one in test_fixnum afaik |
| 21:14:54 | nicksieger enters the room. | |
| 21:22:22 | brixen | dbussink: those are cpp exceptions, not ruby exceptions. evan hasn't implemented the latter yet |
| 21:22:57 | dbussink | brixen: ah, i thought they were forwarded in some way |
| 21:25:01 | shayarnett leaves the room. | |
| 21:35:35 | heycarsten enters the room. | |
| 21:38:04 | jayWHY enters the room. | |
| 21:40:10 | chris2 leaves the room. | |
| 21:41:35 | qrush enters the room. | |
| 21:45:13 | NoKarma enters the room. | |
| 21:47:07 | antares enters the room. | |
| 21:50:50 | jayWHY leaves the room. | |
| 21:51:30 | jayWHY enters the room. | |
| 21:51:57 | jayWHY leaves the room. | |
| 21:55:15 | nexcastellan | Rubinius defines a class called Task in the global namespace. That's kernel/bootstrap/task.rb. This conflicts with a class our application defines. (more) |
| 21:55:29 | nexcastellan | I'm wondering if perhaps Rubinius-specific classes shouldn't be in a namespace or something. |
| 21:55:30 | nexcastellan | Feedback? |
| 21:56:41 | nexcastellan | I think we should particularly be careful of common names like "Task", but I am wondering if perhaps we shouldn't have a standard policy for uncommon names, too. |
| 21:56:49 | nexcastellan | Sort of like C++ and the std:: namespace. |
| 21:57:04 | brixen | nexcastellan: yeah, we've talked about it |
| 21:57:09 | brixen | sounds like a good idea |
| 21:57:22 | nexcastellan | Was there any specific argument against? |
| 21:57:28 | brixen | nope |
| 21:57:34 | nexcastellan | Is Evan away on conferences again this week? |
| 21:57:41 | brixen | just didn't do it initially because it was more work probably |
| 21:57:52 | brixen | not that I know of, but he seems to be away atm |
| 21:58:02 | nexcastellan | Any likely argument against using Rubinius for the namespace? |
| 21:58:14 | brixen | seems ok to me |
| 21:58:46 | brixen | although, there is some joint work on a standard ruby core lib, so there might be a different namespace at some point |
| 21:59:01 | nexcastellan | Okay, I'm going to write up a quick post to the mailing list. It's hitting me now but I'm certainly not planning on fixing all the namespace issues atm. |
| 21:59:16 | brixen | sure |
| 22:07:52 | nicksieger leaves the room. | |
| 22:08:25 | nicksieger enters the room. | |
| 22:10:07 | nexcastellan | Done. |
| 22:10:13 | fbuilesv leaves the room. | |
| 22:13:23 | binary42 enters the room. | |
| 22:14:39 | ijcd leaves the room. | |
| 22:18:35 | blakewatters leaves the room. | |
| 22:22:43 | Defiler | We could just rename Task to something else |
| 22:23:11 | Defiler | Since the other classes legitimately need to be in the top namespace, e.g. String, Array |
| 22:23:24 | nexcastellan | I'm not suggesting renaming String, Array, etc. of course. |
| 22:23:34 | Defiler | Yeah, I assumed not |
| 22:23:38 | nexcastellan | And yes, Task could be something else and provided we pick a name that cannot conflict, no problem. |
| 22:23:48 | nexcastellan | But a namespace solution would be better imho. |
| 22:23:53 | nexcastellan | No possibility of conflict. |
| 22:23:55 | Defiler | Yeah. |
| 22:24:03 | Defiler | VM::Task maybe? |
| 22:24:26 | nexcastellan | I was thinking Rubinius::Task and putting all Rubinius stuff there, but would have no objection to VM::Task if that's what people thought best. |
| 22:24:36 | nexcastellan | Or heck, Rubinius::VM::Task. |
| 22:24:49 | Defiler | I guess Task is Rubinius specific at this point |
| 22:25:05 | Defiler | but we would want other impls that wanted to use the kernel to have it as well, presumably |
| 22:25:08 | nexcastellan | Defiler, did you see my post to the rubinius-dev mailing list? |
| 22:25:11 | Defiler | rather than loading only part of the kernel |
| 22:25:19 | tarcieri | Rubinius defines 'VM'? |
| 22:25:27 | pauldix enters the room. | |
| 22:26:03 | Defiler | Not at the moment, but 'VM' is the current name of the thing replacing shotgun |
| 22:26:11 | tarcieri | aah |
| 22:26:41 | nexcastellan | I guess I'd just like to see all Rubinius stuff under Rubinius::, but it's not a strong opinion. |
| 22:26:43 | sunblush leaves the room. | |
| 22:27:37 | Defiler | It defines class VM in C++, at least |
| 22:27:39 | octopod leaves the room. | |
| 22:27:53 | Defiler | Yeah, it seems reasonable |
| 22:28:16 | Defiler | We just need to figure out which parts are Rubinius-only and which are meant to be shared by things that don't want our 'brand' |
| 22:28:49 | ijcd enters the room. | |
| 22:28:53 | Defiler | It would be weird to have a bunch of ruby code running on MRI someday that defined the Rubinius constant |
| 22:28:54 | nexcastellan | Also, someone needs to do the work to move everything over. I worry that that is non-trivial (though straightforward). |
| 22:28:57 | Defiler | but maybe that's just me |
| 22:29:42 | nexcastellan | It'd also be perfectly reasonable to start with everything in Rubinius:: and then stuff meant to be shared could be moved out or to a different namespace. |
| 22:30:07 | nexcastellan | For some definition of "perfectly reasonable", of course. |
| 22:30:54 | nexcastellan | I certainly envision only Rubinius-internal stuff going in Rubinius::. |
| 22:34:13 | Defiler | I replied to your email to share my opinion with people who aren't watching IRC right now |
| 22:34:19 | Defiler | heh |
| 22:35:17 | binary42 leaves the room. | |
| 22:35:44 | nexcastellan | Thanks! |
| 22:37:21 | nexcastellan | If I place Task inside Rubinius::, should the inspect method still return "#<Task..." or should it return "#<Rubinius::Task..."? |
| 22:37:30 | nexcastellan | (Not going to commit without a consensus, mind you) |
| 22:37:34 | Defiler | the latter, I would think |
| 22:37:54 | drbrain | Rubinius::Task |
| 22:39:01 | evan | so |
| 22:39:05 | evan | namespace wise |
| 22:39:12 | nexcastellan | Hello, Evan. |
| 22:39:21 | evan | I agree that we should move a number of classes under the Rubinius namespace |
| 22:39:23 | evan | Task being a good one |
| 22:39:34 | evan | we'll have to decide where to cut it |
| 22:39:40 | evan | ie, should Tuple be under Rubinius ? |
| 22:39:47 | drbrain | evan: yes |
| 22:39:51 | evan | or FFI, or Platform |
| 22:40:07 | drbrain | unless somebody releases a 100% compatible Tuple as a gem |
| 22:40:12 | nexcastellan | What's the difference between class Rubinius::Task and module Rubinius class Task ? |
| 22:40:16 | drbrain | FFI, no, as there are alternate implementations |
| 22:40:20 | evan | nexcastellan: nothing. |
| 22:40:24 | drbrain | but, FFI = Rubinius::FFI |
| 22:40:28 | nexcastellan | Okay, just syntax, thanks. |
| 22:40:31 | drbrain | nexcastellan: less indentation |
| 22:40:53 | evan | drbrain: so, we should make it explicitly under Rubinius, and explicitly import it to the toplevel |
| 22:41:08 | drbrain | evan: I'm just saying it's an option |
| 22:41:21 | drbrain | I'd say FFI goes at top level since JRuby has one |
| 22:41:22 | evan | k, agreed. |
| 22:41:29 | drbrain | and it isn't a very common thing to call a class |
| 22:41:35 | nexcastellan | Is our FFI compatible with theirs? |
| 22:41:39 | evan | other way around |
| 22:41:42 | evan | and yes. |
| 22:41:42 | drbrain | Task, Channel, Tuple are much more general |
| 22:41:45 | drbrain | nexcastellan: yup |
| 22:41:54 | evan | drbrain: agreed |
| 22:41:56 | drbrain | they run our zlib.rb.in |
| 22:42:04 | evan | plus, if someone wants them, they can just do 'include Rubinius' |
| 22:42:13 | Defiler | Are there any other Tuple implementations for Ruby out there? |
| 22:42:16 | Defiler | I haven't run into any |
| 22:42:19 | Defiler | but the world is wide |
| 22:42:22 | evan | not that I know of |
| 22:42:27 | evan | well, there is one |
| 22:42:30 | evan | class Tuple < Array; end |
| 22:42:32 | evan | DONE! |
| 22:42:33 | tarcieri | Defiler: I have one in Revactor but it should be API-compatible with Rubinius's |
| 22:42:47 | nexcastellan | It's also worth considering just putting Rubinius INTERNAL stuff in Rubinius::. Or perhaps we should consider Rubinius::Internal:: |
| 22:43:10 | evan | nexcastellan: no |
| 22:43:12 | nexcastellan | Or Rubinius::Now::Has::Lots::Of::Namespaces. |
| 22:43:17 | evan | thats a bad idea. |
| 22:43:20 | drbrain | yeah |
| 22:43:20 | Defiler | horrible idea |
| 22:43:24 | Defiler | kill it |
| 22:43:25 | evan | there is no 'internal' things |
| 22:43:29 | evan | are no. |
| 22:43:30 | AndrewO leaves the room. | |
| 22:43:35 | tarcieri | Defiler: All I really use Tuple for is a non-retarded Tuple#=== |
| 22:43:58 | drbrain | ./test/test_dir.hpp:36: warning: unused variable ‘path’ |
| 22:44:03 | drbrain | whose fault is that? |
| 22:44:09 | Defiler | So if Revactor were running on Rubinius, would you avoid loading your version? |
| 22:44:22 | Defiler | drbrain: unimplemented test that isn't commented out |
| 22:44:33 | tarcieri | Revactor will never run on Rubinius... it just implements an API which is mostly compatible with Rubinius's Actor, etc. |
| 22:44:45 | tarcieri | hard to say what to do about Actor |
| 22:44:50 | Defiler | aah |
| 22:45:16 | drbrain | tarcieri: there's always the Actor = Rubinius::Actor approach |
| 22:45:32 | brixen | drbrain: the rest of the machinery isn't there for the test, as you can see from the comment |
| 22:45:38 | brixen | drbrain: you can comment that part of the test as well |
| 22:45:49 | tarcieri | drbrain: yeah, I do that with Revactor... it defines everything in the Revactor namespace and also places it under Actor |
| 22:46:15 | Defiler | Are we proposing our Task API as something that another implementation might provide for its users, in a compatible way? |
| 22:46:48 | Defiler | I think the answer is no, right? |
| 22:46:54 | tarcieri | I don't think having Actor in the toplevel scope is necessarily a bad thing |
| 22:47:07 | tarcieri | considering that both Revactor and Omnibus are more or less API-compatible |
| 22:47:19 | evan | btw |
| 22:47:30 | evan | module Rubinius; class Task; end; end |
| 22:47:33 | evan | isn't exactly the same as |
| 22:47:34 | tarcieri | my goal is to take projects I've written with Revactor and port them over to Rubinius |
| 22:47:36 | evan | class Rubinius::Task |
| 22:47:38 | brixen | tarcieri: I thought the point was to make Revactor, Omnibus and rbx Actor 100% api compat? |
| 22:47:41 | evan | there are differest scopes openned |
| 22:47:47 | evan | that one needs to be aware of. |
| 22:47:50 | tarcieri | brixen: they can't be 100% API compatible |
| 22:47:57 | Defiler | I hate how long it is, but Rubinius::Task is probably where that should go |
| 22:48:10 | tarcieri | brixen: among other things Revactor's Actors aren't pre-emptive |
| 22:48:13 | Defiler | but I think Actor should be toplevel, until we hear about an exciting conflict |
| 22:48:17 | brixen | tarcieri: ahh ok |
| 22:48:40 | brixen | Defiler: anything that uses Task could include Rubinius, couldn't it? |
| 22:49:00 | dysinger leaves the room. | |
| 22:50:06 | moofbong leaves the room. | |
| 22:50:32 | evan | I don't think Actor should be in the kernel. |
| 22:50:50 | evan | just like mutex and such aren't in the kernel. |
| 22:51:07 | brixen | it's in lib currently |
| 22:51:17 | evan | thats where it should continue to live |
| 22:51:27 | tarcieri | evan: yeah, that's fine |
| 22:51:27 | evan | anything in lib/ can use whatever namespacing it wants. |
| 22:51:30 | drbrain | brixen: no, you'd import stuff you didn't want |
| 22:51:48 | drbrain | I ran into a library that did include REXML once, it was terrible |
| 22:51:54 | drbrain | we had a class Document defined elsewhere |
| 22:52:11 | drbrain | include for namespace shuffling is usually a lose-lose situation |
| 22:54:32 | heycarsten leaves the room. | |
| 22:56:05 | headius | why wouldn't you put everything that's nonstandard under a Rubinius package without question? |
| 22:56:22 | headius | except in cases where it's already likely to be promoted to a separate project |
| 22:56:23 | evan | headius: I think thats the way we're leaning |
| 22:56:52 | drbrain | it's something I've wanted to do since a month or so after I started |
| 22:57:04 | drbrain | but it's so unglamorous that I've resisted the temptation |
| 22:57:11 | evan | heheh |
| 22:57:12 | headius | it's certainly possible we'd want to introduce an actor framework in JRuby or as a separate project that could be top-level |
| 22:57:16 | evan | the temptation of the dr. brain. |
| 22:57:36 | tarcieri | headius: but would you use something different from the Actor object protocol that MenTaLguY and I came up with? |
| 22:57:42 | evan | i'd almost prefer that, eventually, stuff like actor.rb goes into a gem |
| 22:57:46 | evan | rather than in lib/ |
| 22:57:52 | evan | so that someone else can maintain it's life |
| 22:58:02 | evan | I want to try and avoid the situation with MRI's lib/ |
| 22:58:07 | tarcieri | heh |
| 22:58:11 | tarcieri | indeed |
| 22:58:25 | evan | in a gem == need RUBY_ENGINE |
| 22:58:26 | evan | :D |
| 22:58:30 | evan | for those following ruby-core |
| 22:58:35 | headius | tarcieri: if it depended on rubinius specifics, might not have a choice |
| 22:58:49 | drbrain | hrm, I should chime in with that |
| 22:58:57 | drbrain | but, Tanaka's objection still stands |
| 22:59:09 | drbrain | which, I think, most respondents did not understand |
| 22:59:26 | evan | drbrain: which objection? |
| 22:59:27 | tarcieri | headius: It doesn't, from an API perspective |
| 22:59:40 | tarcieri | headius: I think it'd be really nice if there were a common Actor API across all implementations |
| 22:59:46 | drbrain | he basically asked "Why does MRI need RUBY_ENGINE?" |
| 23:00:06 | drbrain | and I don't think anybody has answered it |
| 23:00:35 | drbrain | (the only reason I can see is it allows you to avoid defined?(RUBY_ENGINE) and RUBY_ENGINE == "XXX" |
| 23:00:44 | brixen | that's a good enough reason |
| 23:00:46 | drbrain | but, you have to do that anyway as supported MRIs don't define it |
| 23:00:46 | headius | yeah, that's not a very good objection |
| 23:01:02 | tarcieri | or an implicit "unless defined?(RUBY_ENGINE)" == MRI |
| 23:01:05 | ezmobius | tarcieri: hey want to present on reia at the erlang exchange in SF in a few months? |
| 23:01:20 | headius | defined? doesn't return the contents of the constant |
| 23:01:22 | tarcieri | ezmobius: heh, maybe if it's farther along... |
| 23:01:42 | headius | oh, nevermind |
| 23:01:47 | headius | I see what you're saying |
| 23:02:12 | headius | tarcieri: yes, no reason we couldn't have the same actor API implemented in JRuby |
| 23:03:04 | drbrain | builtin_dir.cpp:63: warning: control reaches end of non-void function |
| 23:03:08 | drbrain | :( |
| 23:03:43 | Defiler | Dir::control appears not to be implemented |
| 23:03:47 | brixen | it is |
| 23:03:49 | brixen | git pull |
| 23:04:06 | Defiler | aah |
| 23:04:16 | drbrain | how did I get a half-implemented version? |
| 23:04:16 | brixen | drbrain: all those things are in there for evan to have stuff to point to |
| 23:04:22 | evan | Defiler: i've almost got the instructions situation all ironed out. |
| 23:04:22 | brixen | comment if you must |
| 23:04:25 | Defiler | Yeah, we need boyskizzle for the cpp branch notifikizzle |
| 23:04:42 | drbrain | can we have them commented by default? |
| 23:04:47 | drbrain | I don't like warnings |
| 23:04:56 | tarcieri | ezmobius: the general reaction to Reia among the Erlang community is pretty negative |
| 23:05:16 | ezmobius | heh |
| 23:05:48 | ezmobius | i just met with the guy organizing the conference and he asked me to ask you to speak |
| 23:06:02 | tarcieri | well, nice |
| 23:06:10 | tarcieri | I'll consider it |
| 23:06:15 | ezmobius | cool |
| 23:08:13 | nexcastellan | http://rafb.net/p/SjCr8h33.html What am I missing? I get: http://rafb.net/p/8pihp535.html |
| 23:09:51 | evan | nexcastellan: it's not that easy. |
| 23:10:00 | evan | you have to hook it up right in the VM. |
| 23:10:03 | nexcastellan | Yeah, figured. |
| 23:10:08 | evan | since it's the VM that creates the Task class. |
| 23:11:41 | nexcastellan | Where? bootstrap.c? |
| 23:12:27 | brixen | yeah |
| 23:13:25 | brixen | nexcastellan: the Rubinius module is created below task |
| 23:13:38 | GemBob enters the room. | |
| 23:14:05 | evan | GemBob: hi there bob. |
| 23:14:32 | GemBob | evan: hi |
| 23:15:03 | GemBob | evan: got a minute? |
| 23:15:07 | evan | sure |
| 23:15:45 | GemBob | Cool. I'm trying to build rubinius on a linux box, and am running into a problem |
| 23:16:07 | evan | ex |
| 23:16:08 | evan | o |
| 23:16:08 | Defiler | See? Even IRC has namespaces |
| 23:16:09 | evan | k |
| 23:16:49 | GemBob | it's down in libev |
| 23:16:51 | GemBob | Entering directory `/abaco6/users/bobw/rubinius-evanphx/shotgun/external_libs/libev' |
| 23:16:52 | GemBob | gcc -DHAVE_CONFIG_H -I. -I. -I. -fPIC -O3 -c ev.c -fPIC -DPIC -o .libs/ev.o |
| 23:16:52 | GemBob | ev.c: In function 'infy_add': |
| 23:16:52 | GemBob | ev.c:1960: error: 'IN_DONT_FOLLOW' undeclared (first use in this function) |
| 23:16:52 | GemBob | ev.c:1960: error: (Each undeclared identifier is reported only once |
| 23:16:52 | GemBob | ev.c:1960: error: for each function it appears in.) |
| 23:16:54 | GemBob | ev.c:1960: error: 'IN_MASK_ADD' undeclared (first use in this function) |
| 23:17:10 | drbrain | GemBob: rafb.net/paste please :) |
| 23:17:26 | GemBob | sorry... |
| 23:17:33 | drbrain | np |
| 23:17:34 | headius | ugh...mvm can be pretty hard to debug |
| 23:17:53 | headius | get a syntax error somewhere in a sub vm and it tanks, leaving parent sitting there |
| 23:17:59 | nicksieger leaves the room. | |
| 23:18:24 | evan | GemBob: you're missing system headers |
| 23:18:25 | pauldix leaves the room. | |
| 23:18:25 | evan | on linux |
| 23:18:26 | headius | we should try to iron out some failure cases for sub-vms |
| 23:18:29 | evan | i'm guessing. |
| 23:18:54 | GemBob | evan: ok - thanks |
| 23:19:19 | GemBob | :evan, any clue which ones? |
| 23:19:25 | evan | what distro? |
| 23:19:31 | GemBob | sles 10 |
| 23:19:35 | evan | whats that? |
| 23:19:39 | evan | never heard of it. |
| 23:19:40 | GemBob | suse |
| 23:19:43 | evan | oh |
| 23:19:49 | evan | there is usually a lib6 header package |
| 23:19:57 | evan | you should make sure thats installed |
| 23:20:09 | evan | and a linux header package |
| 23:20:18 | evan | i don't (obviously) know anything about suse |
| 23:20:21 | GemBob | Sounds right - I'll check with the admins - many thanks! |
| 23:20:23 | Defiler | make sure the 'kernel-headers' package is installed |
| 23:20:24 | Defiler | yeah |
| 23:20:24 | headius | btw, not sure if anyone saw my messages the other day, but I want to iron out a few things before FFI goes out in the next JRuby release |
| 23:20:33 | evan | headius: k |
| 23:20:51 | headius | like making it require include FFI so it's not immediately polluting all modules' namespaces |
| 23:20:55 | GemBob | Defiler: excellent - thanks! |
| 23:21:14 | wmoxam leaves the room. | |
| 23:21:30 | headius | or I guess it would be extend FFI to add them to the module's instance methods |
| 23:21:38 | evan | ah, ok. |
| 23:21:40 | drbrain | headius: I like that |
| 23:21:42 | headius | module Foo; extend FFI; end |
| 23:21:46 | evan | sure |
| 23:21:49 | evan | makes sense. |
| 23:21:50 | drbrain | we should do that |
| 23:21:51 | Defiler | hrm.. you also might need libc devel headers, GemBob |
| 23:22:10 | headius | other than that it would be nice to be able to specify attach_function :getuid with :getuid as as a symbol |
| 23:22:15 | Defiler | Not sure if SuSE installs those by default |
| 23:22:18 | headius | right now it seems to just fail unless you specify it as a string |
| 23:22:27 | headius | jruby coerces to string so it works either way |
| 23:22:32 | evan | headius: i don't think it should |
| 23:22:37 | evan | I went back and forth on that |
| 23:22:37 | headius | why not? |
| 23:22:41 | headius | it's a name |
| 23:22:43 | Defiler | extend FFI even looks cool |
| 23:23:03 | headius | or at the very least, why require a string for the function name and then use a symbol for the method name it gets bound to? |
| 23:23:15 | headius | I think it's the nonuniformity that got me |
| 23:23:38 | evan | well, to me (and trying to recall) |
| 23:23:51 | evan | it's that you specify the method name as a symbol |
| 23:23:53 | evan | like it always should be. |
| 23:24:12 | headius | but not the function name? |
| 23:24:13 | evan | and, since you're asking for an external thing, you use a String |
| 23:24:22 | evan | because the rest of the world understands Strings, not Symbols. |
| 23:24:36 | headius | fuck the rest of the world |
| 23:24:38 | headius | we're in ruby |
| 23:24:39 | evan | you don't have to specify it anyway |
| 23:24:43 | evan | if the names are the same. |
| 23:24:53 | headius | but I have to specify a string in that case :) |
| 23:25:00 | headius | so it's not uniform that way either |
| 23:25:01 | drbrain | wtf? |
| 23:25:09 | drbrain | you can't comment out tests in cxxtest |
| 23:25:36 | evan | drbrain: nope. |
| 23:25:42 | evan | cxxtest sucks in that way |
| 23:25:45 | drbrain | WHY? |
| 23:25:45 | evan | you have to rename the test |
| 23:25:46 | headius | brb |
| 23:25:52 | drbrain | stabs somebody |
| 23:25:54 | evan | drbrain: because it parses the file |
| 23:26:04 | drbrain | no it doesn't |
| 23:26:06 | evan | and doesn't understand comment markers |
| 23:26:08 | evan | yes |
| 23:26:09 | evan | it does. |
| 23:26:18 | drbrain | if it parsed the file, it would know what a comment was |
| 23:26:19 | evan | it scans the .hpp files to find all the names of the tests |
| 23:26:23 | drbrain | it scans the file |
| 23:26:23 | evan | sorry |
| 23:26:29 | evan | it badly scans the .hpp files |
| 23:27:43 | evan | from what I found, cxxtest just sucks the least. |
| 23:27:50 | evan | and it still sucks a lot. |
| 23:28:10 | evan | other options where some crazy ass ones that required making every test a template |
| 23:28:46 | drbrain | is a hater |
| 23:29:07 | evan | i can tell. |
| 23:29:19 | evan | maybe I should hire some care bears to pair with everyone |
| 23:29:21 | evan | to cheer them up |
| 23:29:33 | evan | can you imagine zenspider pairing with a care bear! |
| 23:29:35 | evan | that would be awesome. |
| 23:29:47 | Defiler | I thought that was what I was for *sob* |
| 23:30:10 | evan | you're in Florida though. |
| 23:30:22 | drbrain | let me tell you, I was shocked beyond shocking while adding EXIF and ID3 support to my media server |
| 23:30:26 | drbrain | so easy |
| 23:31:18 | Defiler | Keen |
| 23:31:18 | drbrain | simply because the libraries were perfectly sane |
| 23:31:50 | brixen | evan: did you look at CppSpec? |
| 23:31:59 | Maledictus leaves the room. | |
| 23:32:03 | evan | I don't recall. |
| 23:32:33 | Defiler | I believe I remember that name being on the rant-list |
| 23:32:54 | brixen | I think with const_missing and method_missing we could write this in rspec-syntax and emit the test files |
| 23:32:59 | drbrain | why does CompiledMethod::formalize write to stdout? |
| 23:33:16 | evan | cause it hates you. |
| 23:33:18 | brixen | perhaps I'll tackle that after the cpp vm is live |
| 23:33:22 | evan | and loves to make you sad. |
| 23:33:23 | evan | it told me. |
| 23:33:40 | evan | thats just debugging |
| 23:33:49 | drbrain | in that case, I think I'm going to stab it in the inspecT() |
| 23:33:53 | drbrain | with a // |
| 23:37:19 | imajes_ enters the room. | |
| 23:41:18 | sunblush enters the room. | |
| 23:44:33 | imajes leaves the room. | |
| 23:46:01 | NoKarma leaves the room. | |
| 23:49:09 | headius leaves the room. | |
| 23:52:27 | brixen | drbrain: shotgun_primitives.txt is the definitive list of which primitives we have, yes? |
| 23:52:55 | drbrain | brixen: it's slightly reduced from what you would see by grepping shotgun, but yes |
| 23:53:24 | brixen | k, I'm going to replace the ticket body in 658 with a reference to that file |
| 23:53:27 | drbrain | I've removed some here and there where they either should be reimplemented as FFI or aren't hooked up anymore |
| 23:53:36 | drbrain | brixen: there's also `rake missing_primitives` |
| 23:53:43 | brixen | so that ticket is not so unwieldy |
| 23:53:50 | brixen | yeah |
| 23:53:53 | drbrain | yeah |
| 23:54:00 | brixen | drbrain: are you adding to that ticket which prims you're working on? |
| 23:54:37 | drbrain | I haven't been, since they've all been about an hour's work |
| 23:54:53 | drbrain | or, there's been a group that's all an hour or two's work |
| 23:55:58 | brixen | ok, updated ticket |
| 23:56:02 | drbrain | although, I'll claim several of the bignum_* ones because zenspider wants to work on some |
| 23:56:09 | drbrain | and they seem like a good introduction |
| 23:56:11 | brixen | I think it would still help to use that ticket to coordinate |
| 23:56:17 | brixen | since we're all mucking with them atm |