Index

Show enters and exits. Hide enters and exits.

06:29:29thirtysixthspanIm new to running rubinius. Should I be able to run .rbc files and require them? I'm on 1.0.1 on Mac os x.
08:28:27dbussinkthirtysixthspan: the best approach is to just ignore rbc files and run the rb files
08:28:37dbussinkthirtysixthspan: the rbc handling will happen for you
12:20:26manveruwhat are the plans with dbm/sdbm/gdbm from stdlib?
13:14:17dbussinkmanveru: no plans so far
13:14:30dbussinkmanveru: you can try if the mri extension works
13:14:40dbussinkmanveru: if you gemify it
13:15:01dbussinkmanveru: no idea how much those depend on mri internals or that they are nice c api users
15:57:20evanmorning.
15:58:59dbussinkevan: morning :)
15:59:47jeremyevansevan: Morning
16:13:05dbussinkevan: ah whole welcoming committee ;)
16:13:14evanheh
16:13:27evani'm reading headius blog post about snoracle/google
16:13:44dbussinkas always, the patents are laughable
16:14:03BrianRice-workyeha, only an extremely-greedy lawyer would pick those
16:14:09BrianRice-workyeehaw, even
16:14:57BrianRice-worksilver lining: JVM FUD might result in more diverse language platform usage
16:20:52dbussinkevan: so, let's change rbx to be not a mixed vm? :P
16:21:24evansince the patent office has now, finally, changed their tune somewhat
16:21:39bougymanhowzzat?
16:21:47bougymanthat such patents are ever approved just baffled me.
16:21:54evanagreed
16:22:12evanbut the patent office recently announced that they're changing their patent policy
16:22:20evanafter the baliski (wrong sp) case.
16:22:27bougymaniirc someone patented the 'double click'
16:22:42dbussinkwell, they just allow everything until it's challenged somehow
16:23:36bougymani was at a place that wanted to patent the way we used an open source stack!
16:23:43bougymani quickly bailed after hearing that.
16:23:49bougymanbut... they did indeed get that patent.
16:24:35dbussinkevan: which case was that?
16:25:26bougymanbilski v kappos
16:26:33evanhttp://www.groklaw.net/article.php?story=2010072913012223
16:26:33bougymanthey basically just reaffirmed the machine-or-transformation test
16:27:00jeremyevansevan: rb_gv_get("$~") appears not to work, any ideas?
16:27:11evanit will have to be special cased
16:27:16jeremyevansevan: OK
16:27:17evaninside rb_gv_get
16:27:35jeremyevansevan: OK. How should it be accessed?
16:28:07evani'll let you figure that out.
16:28:09jeremyevansevan: BTW, this appears to be the last issue preventing full support for my extension
16:28:12evanbut i'll set you on the right path.
16:28:19jeremyevansevan: OK :) Help is appreciated
16:28:26evanput $~ in a .rb file and do
16:28:32evanrbx compile -B <file>
16:28:45evanthe implementation of instructions is in instructions.def
16:28:50evannow go!
16:28:56jeremyevansevan: Fun fun. :)
16:29:49jeremyevansevan: I used -e "$~", but I'm guessing regexp_last_match_result is what I need :)
16:30:03evani'll let you figure that out.
16:36:45dbussinkevan changed into a bot!
16:40:11evan:)
16:40:15evanif i do it for him
16:40:19evanthen i might as well write the code.
16:40:35sbryantMorning
16:40:41sbryantAfternoon, rather
16:41:00evanno, morning.
16:41:02evanit's only morning.
16:41:44sbryantNot for us east coasters.
16:44:10dbussinkevan: i was wondering, how much 1 to 1 compatibility is needed with mri for networking stuff?
16:44:21dbussinkevan: because i was adding some stuff and trying to simplify things
16:44:22evan*shrug*
16:44:24evanexact?
16:44:29dbussinkwhich still result in perfectly sane answers
16:44:34dbussinkwell something like Socket.pack_sockaddr_in 0, ''
16:44:53dbussinkif i make it simpler in rbx, it will return a sockaddr for ::1
16:45:10jeremyevansevan: How do I get a CallFrame from a NativeMethodEnvironment?
16:45:45evannme->current_call_frame()
16:45:51jeremyevansevan: Thanks
16:51:04dbussinkevan: quick question, are ffi called methods already interruptable?
16:51:21evanffi called methods?
16:55:33dbussinkevan: yeah, look at socket stuffn ow
16:55:38dbussinkevan: if you have a dns timeout etc.
16:55:41evani don't know what you mean.
16:56:01dbussinkevan: can other things run while that is happening?
16:56:08dbussinkevan: is a ctrl c properly processed?
16:56:11evanyes, ffi unlocks the GIL
16:56:16evanno, ^C isn't processed
16:56:18evanbecause it can't be.
16:56:48evanwell, it *might* be, ie a function might return EINTR
16:56:51evanbut no promises.
16:57:00evanbasically, FFI can't be used for stuff you'd want to interrupt.
16:58:35dbussinkevan: do you know if this is the case for mri too or not?
16:58:45evanyou'd have to check.
16:58:49evansometimes yes, sometimes no.
17:05:13jeremyevansevan: http://pastie.org/1095862.txt <- Patches for rb_gv_get("$~")
17:05:14dbussinkevan: i'm already looking too much at mri code trying to improve some in rbx :P
17:05:24dbussinktrying to understand why it's behaving in certain ways
17:05:29jeremyevansevan: With these patches, rbx fully supports my extension
17:05:54evanjeremyevans: there is a subtle buffer overflow issue
17:06:07evanyou assume name to be at least 3 bytes for this to work
17:06:22evanuse strlen
17:06:24evanand then do
17:06:27jeremyevansevan: OK. Wouldn't short circuiting handle that?
17:06:39jeremyevansstrlen is going to scan for '\0'
17:06:40evanif(len == 1 && name[0] == '~' ....
17:06:55evansure, but what if name is just a one byte?
17:06:57evanyou still read 2
17:07:30jeremyevansevan: if name[0] is '\0', shouldn't it never access name[1]
17:07:40evanyou don't do it in that order.
17:07:49evan(name[0] == '~' && name[1] == '\0')
17:07:58evanwhat if it's just ~
17:08:00evanno \0
17:08:10evani guess in that case strlen would blow up too.
17:08:12evananyway
17:08:16jeremyevansevan: The argume is a char *, you don't know the length
17:08:19evani'd prefer you be more explicit, less tricky.
17:08:31jeremyevansevan: To get the length you'd have to scan for '\0' using strlen
17:08:33evando the next guy a favor
17:08:39evanthats fine.
17:08:48evani know you scan twice
17:08:49evanno biggy.
17:08:56evanunless you'd like to profile it for me :)
17:09:19jeremyevansevan: No, I doubt it makes enough difference considering the calling overhead
17:09:34evanright, so do the next guy a favor.
17:09:39jeremyevansevan: Please change it if you feel it would be more readable with strlen
17:09:45evanwell, no
17:09:48evanyou please change it.
17:09:54jeremyevansevan: OK :)
17:16:29jeremyevansevan: http://pastie.org/1095881.txt
17:16:46evanlooks good
17:16:50evango ahead and commit it.
17:17:07jeremyevansevan: OK
17:18:31jeremyevansevan: I don't think I have the commit bit for my github account (jeremyevans)
17:18:38evanok
17:18:40evani'll fix that.
17:19:16evanok, added.
17:19:53dbussinkah, found a bug in rubyspec itself :)
17:19:58dbussinkevan: that explains my confusion :)
17:20:02dbussinkeven mri fails this test
17:20:31evanah
17:20:34dbussinkevan: on that socket / rubyspec issue :)
17:20:41evangotcha.
17:20:49dbussinki was getting back [5000, "::ffff:0.0.0.0"], but 0.0.0.0 was expected
17:20:54dbussinkbut even mri returns [5000, "::ffff:0.0.0.0"]
17:21:00dbussinkyay for a bit of cleanup :)
17:21:06evaneeer
17:21:10evanwait wait.
17:21:25evanyou're getting that because you have ipv6
17:21:27evanif you didn't
17:21:32evanyou'd get 0.0.0.0
17:21:45dbussinkevan: yeah, i know
17:21:49evanthats not a rubyspec failure.
17:21:53evanthats a platform difference.
17:21:53dbussink0.0.0.0 is one of the expected values in the spec
17:22:07dbussinkwell, apparently mri on my platform also fails that
17:22:15evanright
17:22:19evani understand that
17:22:29evanbut don't change the spec to expect "::ffff:0.0.0.0"
17:22:36evanit will just break for someone else then.
17:22:53evanat least it should see if it's either one
17:23:11dbussinkevan: the expentancy already has a [].include? construct
17:23:18dbussinkthis just needs to be added
17:23:21dbussinkas a possible value
17:23:35evank
17:23:36dbussink["::", "0.0.0.0"].include?(sockaddr[1]).should be_true
17:23:46evangotcha.
17:24:12boyscoutAdd spec for rb_gv_get("$~") - 2ac2c64 - Jeremy Evans
17:24:12boyscoutAdd support for rb_gv_get("$~") - 0e265b9 - Jeremy Evans
17:24:57dbussinkevan: if you want to check, this is what i have now: https://gist.github.com/08dd22b6b2835cdff05b
17:25:05dbussinkalso added a method that wasn't there yet
17:25:52evani'm not going to look through it
17:25:56evani've been through that code
17:25:59evanit makes my brain hurt.
17:26:05evanif it passes and you think it's fine
17:26:06dbussinkhehe, i can imagine :)
17:26:07evanthats enough for me.
17:26:16evanI trust you.
17:30:49jeremyevansevan: Looks like C API speed has come a long way since last month
17:30:58evanoh?
17:31:07evanhm, I wonder what we did!
17:31:19evanI assume you mean in the good direction :)
17:31:28jeremyevansevan: I was only getting about 6x speedups on some things, now I'm getting up to 55x
17:31:39evan@_O
17:31:50evancan you double check you're getting the right data?
17:32:03jeremyevansevan: Yep, all the specs passed before I ran the benchmarks
17:32:13evannice.
17:32:26jeremyevansevan: 55x is still less than MRI, but it's a big improvement
17:32:35evan55x from what?
17:32:42evanwhats the baseline?
17:33:02jeremyevansevan: Date.civil. The baseline being the stdlib, the comparison being my library
17:33:12evanah
17:33:12evanok
17:33:13jeremyevansevan: so on rubinius, they are 55x faster
17:33:20evangotcha
17:33:34evanbut they're still slower, over all, than MRI
17:33:49boyscoutCI: rubinius: 0e265b9 successful: 3512 files, 15089 examples, 42926 expectations, 0 failures, 0 errors
17:34:48jeremyevansevan: Unlike on MRI, on Rubinius, some things are slower with my extension, but I'm pretty sure it'll still be a major performance boost
17:35:54jeremyevansevan: I haven't yet compared the rbx results to MRI. I just remember the MRI speedup being more than 55x. That might have been a different machine, though.
17:36:16evanah ok
17:36:19evanso in other words
17:36:23evanMRI is slower than Rubinius
17:36:24evan:)
17:36:39evanwhich means your extension has a higher boost.
17:36:58jeremyevansevan: I'll try to post the results when they finish
17:37:18jeremyevansevan: The benchmarks take a long time to run
17:37:44evank
17:40:38dbussinkjeremyevans: you won't be able to squeeze as much out of it as on mri
17:40:55dbussinkjeremyevans: because rbx is a lot faster in running the ruby code used in date
17:41:54jeremyevansdbussink: True. I believe the speedup on rbx is less than on MRI (1.8), but greater than on YARV (1.9)
17:42:28dbussinkevan: btw, which socket specs where unstable for you when you tagged them? i can vaguely remember you doing something like that
17:42:36evan*shrug*
17:42:45dbussinkevan: i'll check the log then
17:56:48dbussinkbrixen: ping?
18:00:51dbussinkjust grabbed a stroopwafel
18:03:01dbussinkevan: you probably don't remember what exactly was the error with 3ddf2c15724c19d3ae6e2d1312a1aef61417e7da right?
18:03:20dbussinkbecause i did fix a ipv6 / udp case
18:14:36dbussinkugh, BasicSocket.do_not_reverse_lookup is one ugly construct
18:15:47Defilertruly.
18:26:53evandbussink: i don't recall exactly.
18:42:51dbussinkevan: can imagine yeah, was this occuring on elle?
18:43:08evanmost likely.
18:43:12evanit's our primary linux test machine.
18:44:22dbussinkgot a 64 bit debian etch machine i semi regularly use to test stuff too
18:44:25dbussinkseems to work fine
18:44:42evanthat seems to have something to do with the tcp/ip stack
18:44:47evanelle is a slightly older machine
18:44:49evanmaybe thats why.
18:45:10dbussinkwell, i found an issue where udp / ipv6 doesn't work
18:45:44dbussinkso if it was doing :ffff:0.0.0.0 style stuff that could be the issue
18:48:10evanok
18:48:11evani dunno.
18:48:41dbussinki could remove the quarantine and investigate if it occurs again?
18:48:50evanif you like
18:48:51evansure.
19:11:18jeremyevansevan: http://pastie.org/1096128.txt <- Comparative benchmarks for rubinius, ruby 1.8.7, ruby 1.9.2 for my extension
19:12:02evanyikes
19:12:06evancould you give me a summary?
19:12:36jeremyevansevan: Rubinius seems to be substantially slower in some cases
19:13:22jeremyevansevan: Date.civil for example. 17.3 secs on rbx, 5.4 on ruby 1.8.7, 1.4 on ruby 1.9.2
19:13:36evanok
19:13:41jeremyevansevan: That's for the standard lib
19:13:50evanah ah
19:13:50evanok
19:13:54evanwhat about for your extension?
19:14:29jeremyevansevan: For my library, 0.313 rbx, 0.084 1.8.7, 0.071 1.9.2
19:14:41evanok
19:14:49evani'd suggest you ratched the iterations up
19:14:50evanfor that
19:15:01evani generally tell people any benchmark less than 2 seconds is invalid.
19:15:20evannot just for rubinius, for anything.
19:15:31jeremyevansevan: It's at 100000 iterations for all cases. I suppose I could switch to a time basis
19:15:48evani'd do a lot more iterations with your extension
19:16:06evanand divide or multiply the results for comparison
19:17:17jeremyevansevan: Maybe in the future I'll do that. The problem there is that sometimes the speedup is significant, and sometimes it's not.
19:17:25evangotcha
19:17:29evananyway, just a suggestion.
19:17:42jeremyevansevan: For example, on rbx, the extension is slower for simple lookups
19:17:59evanslower than the ruby code?
19:18:07jeremyevansevan: rbx seems to do really well on memory, though
19:18:22jeremyevansevan: Yes. stdlib is faster than the extension for a lot of the simpler methods
19:18:29evanah, interesting.
19:18:36evanthat makes sense, rbx wise.
19:18:41evanruby code is the currency of the VM
19:18:49evanextension code is handled with boxing gloves on
19:19:42jeremyevansevan: The largest speedup: Date#<<,51.52381,0.30047,171.48
19:19:53jeremyevansevan: That's 171x faster for the extension on rbx
19:20:15evanI should checkout this Date code
19:20:16jeremyevansevan: I picked the worse case performance in the stdlib for that
19:20:17evansee what it's doing.
19:20:39jeremyevansevan: It's doing an expensive calculation multiple times
19:21:10jeremyevansevan: My library doesn't support the date of calendar reform, so I only need to do the calculation once
19:21:37evanwhy not improve the ruby code to do the same?
19:22:33jeremyevansevan: I probably could, but upstream has not cared much about my other performance related patch
19:22:45evanI do though.
19:22:51evanregardless if MRI doesn't.
19:22:56evan:)
19:23:29jeremyevansevan: My eventually hope is that the C extension I'm working on replaces the stdlib one, though I'm not very optimistic about that
19:24:41jeremyevansevan: So the worse the ruby code performs, the greater the need for my extension :)
19:24:58evanwell, i don't really want more C extensions :)
19:25:09evanbut it's fine we work at odds
19:25:20evanperhaps i'll try and get the JIT to optimize Date and beat you!
19:25:24dbussinkthe biggest hit in date is actually gcd
19:25:45jeremyevansYep. Is rbx's rational written in C?
19:25:52evanno
19:25:53dbussinkevan: so making gcd (greatest common denominator) fast is probably a good way to go
19:25:54evancourse not.
19:26:04dbussinkwe have as much in ruby as we can
19:26:23dbussinkopenssl is in c, because it's horrible to turn that into ruby :P
19:27:06dbussinkbigdecimal was basically reused because it was the easiest way to get that bootstrapped
19:27:23dbussinkjeremyevans: in general the move is towards more ruby code
19:27:32dbussinkand not to more c code how mri is going
19:27:45jeremyevansThere's a few reasons why date performance is slow. One is the use of rational, another is supporting the date of calendar reform, third is probably the string handling (_strptime/strftime/_parse)
19:27:46boyscoutFix spec, MRI also returns "::ffff:0.0.0.0" on my system - cf88ee9 - Dirkjan Bussink
19:27:46boyscoutSlight cleanup of Socket and adding Socket.getnameinfo - dfb1465 - Dirkjan Bussink
19:27:46boyscoutRemove tags for now passing specs - 6cd2d53 - Dirkjan Bussink
19:27:46boyscoutDequarantine UDPSocket#bind spec - 683004e - Dirkjan Bussink
19:28:06dbussinklet's see what boyscout thinks of this
19:31:05jeremyevansdbussink: I know. That's one of the reasons I'm not optimistic
19:31:31dbussinkjeremyevans: how do you mean, mri is moving more and more to c, so that should make you more optimistic ;)
19:31:54jeremyevansdbussink: Ah, my bad. :)
19:32:48jeremyevansdbussink: The main reason I'm not very optimistic is that tadayoshi funaba (the stdlib date maintainer) doesn't appear interested in increasing the performance of Date
19:53:47ph0rsehey guys, is the Core Library section of http://rubini.us/about/roadmap#steps still areas for improvement?
19:56:34boyscoutCI: Commit 683004e failed. http://github.com/evanphx/rubinius/commit/683004e5c182b46a6e756feabbdf87f9df6e0fa4
20:10:00dbussinkph0rse: String could still use some attention for example
20:10:17dbussinkevan: how's that story on the String#% compiler? was never finished right?
20:15:30ph0rsecool, thanks. I'll start looking into it
20:15:51boyscoutDon't call to_s on given host - ec5b665 - Dirkjan Bussink
20:15:54dbussinkph0rse: and spec failures are always a good place to start
20:16:55ph0rsedbussink: do you work for Nedap?
20:18:16dbussinkph0rse: yeha
20:18:17dbussinkyeah
20:19:08ph0rseI did a little work for you guys about a year ago
20:19:41ph0rsebrb, thanks for the pointers
20:20:05dbussinkph0rse: ah yeah, name in the whois sounded familiar :)
20:44:28boyscoutCI: rubinius: ec5b665 successful: 3512 files, 15101 examples, 42941 expectations, 0 failures, 0 errors