Show enters and exits. Hide enters and exits.
| 00:05:08 | rue | Actually, about 85MiB is where we start.. lessee where we fall. |
| 00:09:27 | rue | Meh, marginal improvement |
| 00:11:05 | rue | Foiled again |
| 00:11:27 | rue | Next time, Gidget, next time! |
| 00:29:31 | headius | rue: wowsers, 100MB |
| 00:29:38 | headius | JRuby repo is only 39MB |
| 00:29:53 | headius | Rubinius > JRuby! |
| 00:30:29 | blowmage | ^ so tempted to tweet that |
| 00:30:33 | brixen | JRuby < Rubinius |
| 00:30:38 | brixen | yep, about right :D |
| 00:38:08 | boyscout | Fix UnboundMethod#arity and refactored. - 7e66b73 - Maximilian Lupke |
| 00:38:08 | boyscout | Fix ObjectSpace#define_finalizer. - 314b9e2 - Maximilian Lupke |
| 00:38:08 | boyscout | Fixes several Module instance methods. - f18150a - Maximilian Lupke |
| 00:39:37 | boyscout | CI: f18150a success. 1444 files, 7122 examples, 23440 expectations, 0 failures, 0 errors |
| 01:23:46 | rue | Alright, now I am done |
| 01:40:33 | shoe | pokes rue with a fork, just to check. |
| 04:15:37 | brixen | evan: problem with sending allocate in Object::dup is ByteArray::allocate takes an argument |
| 04:37:34 | brixen | I think ByteArray, Tuple or any other object that must be created at a particular size should not be allocate'able |
| 04:37:56 | brixen | and allocate should always have arity 0 |
| 05:00:13 | brixen | perhaps we need the idea of a "dependent" object that cannot be alloc'd, dup'd etc independent of it's owner |
| 05:06:30 | headius | I agree |
| 07:05:37 | evan | brixen: hm, ok. |
| 08:39:46 | tilman | evan: can i kill off the c++ Marshaller class? afaics on the c++ side, we only use UnMarshaller |
| 08:55:55 | rue | Wth, stupid lag reconnects |
| 15:54:22 | evan | morning |
| 15:54:39 | slava | hi |
| 15:54:49 | evan | slava: saw your tweet |
| 15:54:52 | evan | what are users reporting? |
| 15:54:54 | evan | i'm curious |
| 16:07:23 | malumalu | hm, shouldn't ::Foo be a valid constant name? |
| 16:07:33 | evan | sure |
| 16:07:40 | evan | where are you having a problem with it? |
| 16:08:11 | malumalu | a wrong spec which expects ::Name to be a invalid const name |
| 16:08:26 | evan | weird |
| 16:08:27 | evan | where at? |
| 16:08:31 | evan | maybe it's a strange edge case |
| 16:08:57 | malumalu | frozen/core/module/remove_const_spec.rb:40 |
| 16:10:03 | evan | ah |
| 16:10:06 | evan | ok |
| 16:10:13 | evan | so thats likely correct |
| 16:10:15 | evan | that spec |
| 16:10:30 | evan | because thats accessing the constant as an explicit string passed to the remove_const method |
| 16:10:42 | evan | and remove_const doesn't parse the string to figure out scoping |
| 16:10:53 | brixen | yeah |
| 16:10:58 | brixen | it passes in MRI |
| 16:11:02 | brixen | it's correct |
| 16:11:09 | malumalu | ok |
| 16:11:10 | brixen | unless you file a bug report for MRI |
| 16:18:27 | rue_XIV | Similar case to const_get, I suppose. Perhaps the spec should make it clearer? |
| 17:18:03 | radarek | hello |
| 17:18:16 | radarek | rubinius is not building on 64bit |
| 17:18:19 | radarek | http://pastie.org/442970 |
| 17:18:27 | radarek | I don't know if it's correct patch |
| 17:18:54 | radarek | but compiler was complaining about "control reaches end of non-void function" |
| 17:19:16 | evan | radarek: yeah, i've got that patch to apply |
| 17:19:19 | evan | i'll do that shortly. |
| 17:19:35 | tilman | evan: pushed rbc stuff to my fork at gh, the branch is called rbc-rework |
| 17:20:13 | radarek | evan: ok |
| 17:20:57 | tilman | vm startup time (as measured by running a hello world script) improved ~19%. the compiled kernel is now ~35% smaller |
| 17:21:34 | tilman | loading rbc with rbx in ruby is mostly the same i think. same with compiling stuff |
| 17:24:24 | evan | k |
| 17:24:24 | evan | one sec. |
| 17:24:33 | slava | tilman: what did you optimize? |
| 17:25:11 | tilman | evan: take your time. |
| 17:26:07 | tilman | you'll notice the varint stuff in marshal.cpp can need a refactor. i didn't bother to do that yet -- if you're going to accept that stuff, i'll clean things up first |
| 17:26:19 | tilman | slava: went from ascii to a binary format |
| 17:38:01 | evan | tilman: i don't get the varint code |
| 17:38:04 | evan | could you explain it? |
| 17:38:29 | evan | seems like it keeps adding bytes while the high bit of the byte is set? |
| 17:39:53 | tilman | evan: 8 bits on the wire contain 7 bits of payload. the msb is set if there's more data to read |
| 17:40:23 | evan | so the last byte doesn't have the high bit set? |
| 17:40:35 | tilman | exactly |
| 17:40:45 | evan | so if the value < 128, it's just a raw binary rep of the number |
| 17:40:52 | evan | ie, 1 is \1 |
| 17:40:52 | tilman | yep |
| 17:41:04 | evan | but 128 is |
| 17:41:15 | evan | \129\1 |
| 17:42:15 | evan | yes? |
| 17:42:39 | tilman | 128 is \128\1 |
| 17:43:34 | tilman | in 128, none of the 7 lsbs are set, so we'd end up with a payload of 0 |
| 17:43:46 | tilman | but we need to set the msb to indicate there's more data to come |
| 17:43:53 | tilman | so: 0 | 128 = 128 |
| 17:44:19 | tilman | evan: see http://code.google.com/apis/protocolbuffers/docs/encoding.html#varints |
| 17:46:18 | evan | ah |
| 17:46:18 | evan | ok |
| 17:46:44 | evan | so \129\1 is 129? |
| 17:47:48 | evan | I wish bit twiddle math in ruby wasn't so slow. |
| 17:47:53 | tilman | yes |
| 17:48:42 | evan | seems weird to me that the bytes presense alone carries a value |
| 17:48:46 | evan | but whatevs. |
| 17:50:35 | evan | tilman: are you going to write a standalone decoder? |
| 17:51:06 | tilman | why? to prove it's not slower? |
| 17:51:18 | evan | so that I can check out the contents of a .rbc |
| 17:51:20 | evan | for debugging. |
| 17:51:41 | tilman | okay, will do |
| 18:28:54 | boyscout | Pruned silly instructions from the set - f975946 - Evan Phoenix |
| 18:37:09 | boyscout | CI: f975946 success. rbx: vm/exception.cpp:114: void rubinius::abort(): Assertion `0' failed. |
| 18:38:57 | evan | i guess brixen committed that abort |
| 18:38:58 | evan | :/ |
| 20:02:30 | malumalu | are immediate objects garbage collected? |
| 20:03:20 | evan | no |
| 20:03:22 | evan | they're immediate |
| 20:03:26 | evan | they don't use any memory. |
| 20:03:43 | malumalu | hm, yes, that makes sense ^^ |
| 20:13:48 | brixen | evan: nope, didn't commit that |
| 20:13:56 | brixen | I was going to poke at it some more |
| 20:14:08 | brixen | try to see why the vm* is NULL |
| 20:15:43 | brixen | we should probably sweep all the places that are calling abort() |
| 22:57:33 | evan | muhah |
| 22:57:40 | brixen | heh |
| 22:57:42 | evan | luis commited the pure ruby readline he told me about |
| 22:57:43 | evan | http://github.com/luislavena/rb-readline/tree/master |
| 22:57:52 | evan | rbreadline.rb is 256k |
| 22:57:54 | evan | wowzers. |
| 22:57:55 | headius | cool |
| 22:57:59 | evan | it's a straight port of the C lib. |
| 22:58:06 | evan | literally |
| 22:58:09 | evan | function name for function name |
| 22:58:13 | headius | that's nuts |
| 22:58:17 | brixen | hah |
| 22:58:18 | evan | yeah |
| 22:58:19 | brixen | um yeah |
| 22:58:24 | headius | github chokes trying to display it |
| 22:58:41 | evan | yep |
| 22:58:48 | evan | awesome huh. |
| 22:58:57 | headius | awesome in an "is that useful" sort of waty |
| 22:59:08 | headius | I know koichiro has been working on an ffi readline |
| 22:59:41 | brixen | evan: you tried it in rbx yet? |
| 22:59:45 | evan | nope |
| 22:59:57 | evan | go for it |
| 23:00:07 | brixen | yeah, cloning now |
| 23:00:34 | brixen | looks like park heesob did the port |
| 23:00:41 | evan | yeah |
| 23:00:44 | evan | you know who that is? |
| 23:00:50 | evan | luis had it done as a bounty |
| 23:00:52 | malumalu | is "USZ!" some kind of debug message? i just got it right before a seg fault |
| 23:01:01 | evan | malumalu: yeah |
| 23:01:18 | evan | malumalu: means the GC detected an erro |
| 23:01:23 | evan | and dumped the program |
| 23:01:35 | malumalu | ok |
| 23:01:37 | brixen | evan: I don't know him, just see his posts on ruby-core |
| 23:01:51 | evan | malumalu: best is to try and get it to happen consistently |
| 23:01:55 | evan | and report how you're doing it |
| 23:02:00 | evan | so we can fix it |
| 23:02:26 | evan | it could be worse code |
| 23:02:33 | evan | at least there are a lot of comments |
| 23:02:47 | malumalu | no, i messed around with the gc myself |
| 23:02:58 | evan | it strangly mixes ivars-in-class-body and constants |
| 23:02:59 | malumalu | so i think it was my fault |
| 23:03:01 | evan | malumalu: ah! you're fault! |
| 23:03:04 | evan | your |
| 23:03:16 | malumalu | :P |
| 23:03:18 | evan | it means, basically, that the GC, while walking the heap |
| 23:03:22 | evan | detected an invalid object |
| 23:03:33 | evan | usually means that, on a previous walk of the heap, it wasn't seen and the memory was reclaimed |
| 23:03:41 | evan | but it has since then come back into view |
| 23:03:48 | evan | our GC is accurate |
| 23:04:01 | evan | so you have to describe accurately where objects are stored |
| 23:04:20 | headius | evan: btw, there's a small snag with the talk |
| 23:04:34 | evan | rutrow |
| 23:04:44 | headius | I don't have Keynote (officially supposed to use OO for everything) |
| 23:04:48 | headius | so I'll have to pick up a copy |
| 23:04:53 | evan | oh |
| 23:04:58 | brixen | evan: it works! |
| 23:05:02 | evan | brixen: no way. |
| 23:05:03 | brixen | should I import it |
| 23:05:06 | brixen | yes way |
| 23:05:07 | evan | you're pulling my leg. |
| 23:05:09 | evan | stop it. |
| 23:05:10 | brixen | nope |
| 23:05:12 | brixen | hehe |
| 23:05:13 | evan | :D |
| 23:05:15 | evan | thats awesome! |
| 23:05:18 | headius | I wonder if there's any performance consideration |
| 23:05:21 | brixen | ok, I'll double check |
| 23:05:22 | headius | I'd almost boot what we have for that |
| 23:05:24 | evan | for readline? nah |
| 23:05:30 | evan | if you use readline in a loop |
| 23:05:31 | headius | it's all user interaction |
| 23:05:33 | evan | you're insane. |
| 23:05:35 | headius | heheh |
| 23:05:40 | evan | a fast loop |
| 23:05:41 | evan | i should say |
| 23:05:56 | evan | unless the idea is to see how fast the user can hit the return key |
| 23:06:01 | evan | READY.. |
| 23:06:02 | evan | GO! |
| 23:06:08 | headius | there is one catch you should be aware of...we use a pure-java readline, but it still needs a native lib on windows to set the terminal into the right state |
| 23:06:15 | headius | so pure ruby won't be enough forever |
| 23:06:22 | evan | headius: yeah, luis mentioned that to me actually |
| 23:06:25 | headius | ok |
| 23:06:30 | evan | he had this written because there was no readline for windows |
| 23:06:33 | headius | stoopid windows |
| 23:06:36 | evan | i'm looking for that code now actually |
| 23:06:50 | headius | readline-ffi may be a way out for that though |
| 23:06:54 | evan | if we can get at the terminal state functions via FFI |
| 23:06:56 | evan | we're golden |
| 23:07:17 | evan | brixen: it's GPL :/ |
| 23:07:18 | evan | crap. |
| 23:07:25 | brixen | oh yeah, just saw that too |
| 23:07:26 | evan | we should ask if he'd release it under BSD |
| 23:07:27 | brixen | wtf |
| 23:07:32 | brixen | yeah |
| 23:07:40 | brixen | it really seems to work though |
| 23:07:47 | evan | thats.. |
| 23:07:49 | evan | SO AWESOME. |
| 23:08:11 | brixen | yeah |
| 23:08:50 | headius | does anyone willingly pick GPL anymore? |
| 23:08:56 | evan | bingo |
| 23:09:00 | headius | I think people do it just because they don't know |
| 23:09:02 | evan | it uses Win32API |
| 23:09:12 | headius | oh yak |
| 23:09:18 | evan | we should rebuild Win32API on top of FFI |
| 23:09:19 | headius | win32api is based on dl right? |
| 23:09:19 | evan | if we can |
| 23:09:30 | evan | i think so, yeah |
| 23:09:33 | headius | if it's on dl, it may just work with wmeissner's dl/ffi stuff |
| 23:09:34 | evan | it's almost exactly the same |
| 23:09:42 | headius | two birds, etc |
| 23:09:49 | brixen | it's not really that complex of code |
| 23:09:56 | evan | library, name, [arg_types], ret_type |
| 23:10:14 | evan | it returns them as .call'able objects |
| 23:10:32 | evan | to support what rbreadline uses |
| 23:10:35 | evan | it would take probably 10 minutes |
| 23:11:08 | headius | evan: you should look into wmeissner's dl stuff first |
| 23:11:13 | evan | ok |
| 23:11:13 | headius | if we could get that 100% it would be sweet |
| 23:11:25 | evan | yep. |
| 23:11:44 | evan | hehe |
| 23:11:48 | evan | this code is actually pretty neat |
| 23:11:53 | evan | like |
| 23:11:57 | brixen | I think that license is a copy of the C readline license |
| 23:11:59 | evan | he defines methods inside rescue's |
| 23:12:07 | evan | brixen: but it's a port |
| 23:12:12 | evan | it's not required to be the same license |
| 23:12:13 | brixen | ok |
| 23:12:15 | evan | it doesn't share anycode |
| 23:12:17 | brixen | right |
| 23:12:24 | brixen | that's what I wondered |
| 23:12:31 | evan | at least thats how I understand it |
| 23:12:34 | brixen | cool |
| 23:12:39 | evan | i'm sure RMS disagrees with me |
| 23:12:43 | brixen | heh |
| 23:12:55 | evan | but we should email him |
| 23:13:04 | evan | actually |
| 23:13:08 | evan | I think that luis owns the code |
| 23:13:16 | evan | because he paid for it |
| 23:13:18 | evan | via a bounty |
| 23:13:22 | brixen | yeah, too bad he's no lurking in our channel |
| 23:13:30 | evan | so luis can rerelease it |
| 23:13:35 | brixen | cool |
| 23:13:38 | evan | i'll ask him. |
| 23:13:42 | brixen | k |
| 23:14:28 | headius | it could be argued as a derivative work |
| 23:14:32 | headius | but fuck all that |
| 23:14:35 | evan | yeah |
| 23:14:40 | evan | you can agrue that about everything |
| 23:14:48 | headius | RMS is a nut |
| 23:14:50 | evan | no one has written anything in a bubble since 1960 |
| 23:15:12 | headius | GPL is tantamount to software patents, going by his definition |
| 23:15:14 | evan | and that work was probably done in actual geodesic dome |
| 23:16:06 | evan | we should put out a bounty for someone to write specs for this |
| 23:16:08 | evan | so we can refactor it |
| 23:17:25 | headius | I wonder if koichiro has done anything for readline-ffi |
| 23:17:53 | evan | well, sadly readline-ffi won't work on windows anyway |
| 23:18:06 | evan | and i want to try and not put myself too much into a hole |
| 23:18:11 | evan | anymore than we already are :D |
| 23:18:19 | headius | why wouldn't it work on windows? |
| 23:18:27 | evan | there is no libreadline.dll |
| 23:18:28 | headius | it would just need to make those additional win32 calls as well |
| 23:18:29 | evan | i'd imagine |
| 23:18:37 | headius | ahh, well that's true |
| 23:18:48 | evan | and i'm assuming readline-ffi is a binding to libreadline |
| 23:18:50 | headius | it would have to ship a build libeditline |
| 23:19:01 | headius | built |
| 23:19:26 | headius | but I was more talking about whether he's written tests/specs for it |
| 23:19:46 | evan | ah ah. |
| 23:19:58 | evan | that would be hard |
| 23:20:02 | evan | but one thing I love about rbreadline |
| 23:20:13 | evan | we could pretty easily hook it up to the web |
| 23:20:15 | evan | or anything |
| 23:20:32 | evan | ie, a real readline that doesn't depend on a terminal |
| 23:20:41 | evan | you could use it in cocoa, or something |
| 23:20:42 | headius | yeah, our readline is used for a swing IRB console too |
| 23:20:52 | headius | because it's just a virtual buffer |
| 23:21:15 | headius | hmm, I think we even ship that still |
| 23:21:26 | headius | run jirb_swing |
| 23:21:35 | headius | tab completion pops up a small dropdown |
| 23:21:49 | evan | luis wrote me back |
| 23:21:53 | evan | he says he'll ask park |
| 23:24:44 | rue | Alright, so I am going to just stop using Ruby and move to Clean instead |