Index

Show enters and exits. Hide enters and exits.

10:17:56danlucraftmorning
10:19:08kronos_vanoัƒั‚ั€ะพ! (morning in russian =)
10:24:42dbussinkdanlucraft: testing the logging? ;)
10:25:15danlucraftwell spotted :)
12:24:16boyscoutAdded support to http proxy when download llvm source. - 62285dd - David Pinheiro
12:28:01boyscoutCI: rubinius: 62285dd successful: 3024 files, 11747 examples, 35948 expectations, 0 failures, 0 errors
15:52:19DefilerUgh, this is a terrible piece of sentence-building: Classical module systems support well the modular devel- opment of applications but do not offer the ability to add or replace a method in a class that is not defined in that module.
15:56:34DefilerSee, this classbox paper doesn't make sense to me
15:56:47DefilerWhy not just do what amounts to a copy-on-write setup for your constant tables?
17:19:38brixenDefiler: yeah, the classbox paper has some challenging sentences
17:20:01evani only looked at that one paper
17:20:14evanif no one else has implemented it without a 60% performance drop
17:20:21evanlets not even bother.
17:20:26brixenexactly
17:20:48brixenuntil there is a compelling use case that is neither mathn or wycats :D
17:20:57brixens/or/nor/
17:22:36BrianRice-workyeah they're not even that well known within squeak community
17:22:51evani get the idea
17:23:13evanit's extending method lookup to include some some other key in addition to the method name
17:23:15evanpretty simple
17:23:23evanbut comes with a huge cost.
17:23:31BrianRice-workmm
17:24:04BrianRice-workin Slate we have multi-methods and can add an additional argument for dispatch which is "contextual". that's a bit faster but not enough
17:24:32evanhow does the user construct that?
17:25:00evanmulti-method wise, that makes total sense, since multi-methods are really just a way of constructing a decision tree inside a method
17:25:25BrianRice-workusually with dynamic or lexical binding, i.e. inContext: x do: [messages which look normal but now have modified lookup]
17:26:00evanand previously, you've added methods explitely to that context?
17:26:21BrianRice-worktypically we just "uncurry" the method to make a new signature with an extra argument
17:26:48BrianRice-workso instead of "x decodeFrom: y" we do "z decode: x from : y"
17:26:50evanso, would every call within that scope be modified at compile time to include an extra argument?
17:27:09BrianRice-workno, runtime :( at least the way we implemented it
17:27:25evandoes the multi-method itself say "is there a context I should include in my lookup?"
17:27:39evanand the context is make active in a thread-local way
17:27:40BrianRice-workthe interpreter does
17:27:51BrianRice-workthe interpreter is also thread-local
17:28:27evanok, so the context works anywhere "below" where it's setup
17:28:27BrianRice-workthe closest thing to this is ContextL which came a bit after we did this for common lisp
17:28:31evanie, across method calls
17:28:32BrianRice-workright
17:28:36evanthats the sane thing
17:28:41evanand you obviouly have to do that at runtime
17:28:49BrianRice-workyep
17:28:56slavain factor we have 'hooks' which are generic functions that dispatch on the value of a dynamically scoped variable
17:29:21BrianRice-workthat is conceptually similar
17:29:54evani suppose if ruby had a way of installing a trampoline into a method slot in a class
17:30:11evanand that trampoline could consult some data to decide which method to actually call to
17:30:19evanbasically, multi-method injection
17:30:37evanthen at least it's a pay-per-usage system
17:31:56BrianRice-workaka "opt-in" ;)
17:32:05evan:D
17:32:09evanwhat a great term!
17:32:11evan:)
17:32:46BrianRice-workwe were actually considering using our setup to create sandboxes and "subjective dispatch". we may get back to that but via other means.
17:33:41BrianRice-workfocuses on the day-job...
17:33:56evanback to the perl house with you!
17:35:26slavaevan: any more thoughts on our heap discussion earlier?
17:35:42evannot since the last time
17:35:45evani haven't had time to play with it.
17:36:05slavawhat is the CodeManager change about?
17:36:10slavaGC for JITted code?
17:36:29evanyeah
17:36:33evanwell, eventually.
17:36:51evanthere is currently a backend structure for the interpreter to use, per method
17:37:04evanthat wasn't being cleaned up
17:37:08evanit is now
17:39:11slavaah
17:39:18slavabut JITted code is still not cleaned up?
17:40:13evannope
17:40:18evangetting to that soon.
17:41:26slavaany major changes that have to be made for that to work?
17:43:12evani don't think so.
17:45:54evanbtw, the fact that IO.new(fd).close can completely fuck up some random future IO is so bad.
17:50:34brixenevan: you mean the fact that IO.new(fd) is essentially an fd alias?
17:50:45brixenie dup is not called on the fd
17:50:51evanexactly
17:50:55brixenyeah, hate that
17:51:02brixenand that matz refuses to fix it
17:51:09evanand if you do
17:51:14evanf = File.open "/etc/hosts"
17:51:19evang = IO.new(f.fileno)
17:51:22evanf.close
17:51:28evanyou've just introduced a timebomb.
17:51:50brixenyeah, this issues was discussed in writing some specs
17:51:51evanbecause at some future time, g will be finalized and close will be called on f.fileno
17:52:02evanBUT if you open another file between those times
17:52:11evanyou'll close the fd of some other random IO
17:52:21brixenyes
17:52:30evanso fucked.
17:52:36brixenyep
17:54:32yakischlobanothing checks to see if it was closed already? i was having dicussion about this with someone literally like 3 minutes ago
17:54:56yakischlobaoh, it would not know
17:55:01evanright
17:55:07slavayakischloba: also it could be re-opened with a new file
17:55:10evanplus the suck ass part is this
17:55:16evanafter you've done the above code
17:55:29evanh = File.open "whatever"
17:55:32evanh.fileno == g.fileno
17:55:47yakischlobayea
17:55:48evan<g goes out of scope and is collected>
17:55:55evanh.gets # => raises Errno::EBADF
18:04:48Defilerevan: Wait, seriously?
18:04:56evanhttp://gist.github.com/277353
18:04:58DefilerThe finalizer for an IO closes the fd?
18:04:59evanrun that.
18:05:20DefilerThat is iiiinnnsaenaena8rarer
18:05:39evanbecause IO.new does not dup(2) it's argument
18:06:56DefilerYeah, it follows from that I guess, but wow that is ugly
18:08:57BrianRice-workI don't suppose there's some explanation of the design thinking behind ruby's taint concept, and maybe post-thinking about it now that its been in use for a while
18:09:26DefilerNope!
18:09:33BrianRice-workaww. oh well
18:09:34DefilerI was just reading the ruby source from 1995 actually
18:09:41evanthe post-think is that it's not very useful.
18:09:42Defilerand the changes are interesting
18:09:45evanimho.
18:11:06BrianRice-workok. I'll stick with my shared-nothing sandboxes goal, then.
18:11:27BrianRice-workwith asynchronous message-passing
18:12:10DefilerI guess my summary of the 'tainted?' post-think is 'blacklists don't work as well as whitelists'
18:12:44BrianRice-workah, good point
18:13:06brixennice, we pass all the existing #require specs and fail 1/2 of my rewritten one
18:13:10brixen*ones
18:13:13brixenWIN
18:13:18evanso, should I fix this in rubinius?
18:13:25BrianRice-workwhich goes right along with the things the E-rights / Caja guys have been saying
18:13:50brixenevan: did you see the ruby-core ticket on it, or want me to dig it up?
18:13:57Defilerevan: What can you do with two references to an un-duped fd that you can't do after duping?
18:13:58brixenevan: I think the fd should be dupped
18:14:10DefilerIOW, are there valid things that duping would prevent?
18:14:11brixenlooks for the ticket
18:14:12evanbrixen: nope, i don't see the ticket
18:14:38evanif I dup the fd passed to IO.new
18:14:42evanthen problem solved.
18:15:53brixenhum hum, where was this...
18:18:40DefilerAm I supposed to be smart enough to figure out rdoc?
18:18:46DefilerBecause, wow, I just have no idea how to use this nightmare
18:19:16DefilerI always always always run into errors like this: rdoc.rb:177:in `stat': No such file or directory - ./bin/ctags (Errno::ENOENT)
18:19:21Defilerthe instant I try to use it for anything
18:20:01evanwhy the fuck is rdoc using ctags?!
18:20:19Defilerand why does it think it would be installed somewhere relative to the current directory?
18:20:47evanwe need the drbrain
18:20:49evanto tell us.
18:21:13evanback on IO.new
18:21:15evansolution: https://gist.github.com/90ffaedb053391bf8268
18:21:57brixenevan: grr, I'm not finding it
18:22:27brixenI swear matz specifically answered the question of why the fd is not dupped
18:22:43evanhm, ok.
18:22:46evani'd love to know.
18:22:50brixenme too
18:22:53brixenheh
18:24:37brixenjredville is not responding to my ping, he wrote a spec about it
18:24:52DefilerThis? http://redmine.ruby-lang.org/issues/show/2250
18:26:27brixenI found that one, but it was not the one I was thinking of
18:27:04wyhainesOK. So.... I was able to successfully run Swiftiply under Rubinius, after a little hacking. It's not _quite_ so fast as MRI, and there seems to be a humungous memory leak, but nonetheless, it worked.
18:27:36evani'm betting I know the answer
18:27:37brixenwyhaines: woot, bummer, ugh, woot
18:27:40evanreading that ticket Defiler posted.
18:29:05evanthat example about using IO::for_fd from Socket#sysaccept
18:29:14evanif you dup it
18:29:24evanthen the socket is never closed.
18:29:36evanbecause the original fd is basically left dangling
18:29:41evannever closed
18:29:56evannever closed within the kernel
18:30:03evanbecause there will be 2 fds pointing to the same kernel object
18:31:51DefilerWhat if it was 'open' that duped it, not IO.new?
18:33:40evani don't see how that changes anything
18:33:50evanwe'd have the same issue
18:34:18DefilerHrm, yeah.
18:34:52DefilerI guess if we had an object that kept pointers to all the IOs that wrap a given fd
18:35:04DefilerWe could avoid collecting things that had side effects
18:35:56evanright
18:35:58evanthats what jruby does
18:36:03evanthe fd is an indirection
18:36:17evanto a table of backend objects
18:37:19brixenhmm, this is what I was thinking of http://bit.ly/4xaH9V
18:40:23evanbasically
18:40:32evanmatz is saying that you use IO.new at your own peril.
18:40:53Defilermmm peril
18:41:32wyhainesbrixen: evan: I do have a question, when you have a moment, about why rb_define_alloc_func was defined the way that it is in the CAPI. It doesn't match how it's defined in MRI, and I had to change the definition to match MRI's to get my code to compile. Ignorance is bliss, though, and I'm feeling pretty happy, so what am I missing?
18:41:54evanwhy was it wrong?
18:42:26evanseems fine to me
18:42:30brixenwyhaines: gist
18:42:43brixenwyhaines: it's hard to imagine what you may have changed :)
18:43:48brixenrb_define_alloc_func is used and working in our lib/ext
18:43:56brixendigest and syck
18:46:00evanwyhaines: ?
18:48:33wyhainesYeah, it's interesting, because my extension uses it exactly like your digest.c does, but I was getting an error out of it when building. Just a moment. I'll pull the error that I was getting and put everything into a gist.
18:48:53evanwhen building?
18:49:11evansounds like a function pointer cast problem
18:49:43brixenyeah
18:54:26wyhainesYeah, it is.
18:54:27wyhaineshttps://gist.github.com/676b35c627b1a8a956ea
18:54:49evanok...
18:54:51evanwhat did you change?
18:55:09evanis splaytree in C++
18:56:08wyhainesYeah, splaytree is in C++.
18:56:30evanI suspected as much
18:56:34evanwhat did youc hange?
18:57:33brixenyou should be able to use the RUBY_METHOD_FUNC macro I think
18:57:37wyhainesI just change ruby.h and module.h so that the rb_define_alloc_func didn't use CApiAllocFunction, and instead looked just like MRI: rb_define_alloc_func(VALUE class_handle, VALUE (*allocator) _((VALUE)));
18:57:51wyhainesIt built. :) But I figured it was wrong.
18:57:59evanwhy not change CApiAllocFunction to match that
18:58:05wyhainesBecause I was just hacking.
18:58:13evanyou should just change it.
18:59:08wyhainesOK. I figured there was something that I was missing, though, since, as Brixen pointed out, your use of it in your C code in digest.c works fine, as is.
18:59:13evani think thats just an oversight by rue
18:59:16evanwhen he coded that up.
18:59:28evanit's because splaytree is C++
18:59:40evanANYARGS is "..." if the file is C++
18:59:44evanotherwise it's ""
18:59:52wyhainesAh!
18:59:56brixenyeah, I added the _() __() macros much later too
18:59:57evanit works for digest because digest is in C
19:00:14evanand C allows any function pointer through if the type has () as the arguments
19:00:32evan() in C is not "no arguments" it's "any arguments"
19:00:39evan(void) is "no arguments"
19:00:55boyscoutAdd GC finalization support, fix IO close-on-cleanup bug - a9c471d - Evan Phoenix
19:00:55wyhainesOK. Do you want me to make a ticket for my changes? I added rb_equal and rb_yield_values to the CAPI, as well.
19:00:58boyscoutCI: Commit a9c471d failed. http://github.com/evanphx/rubinius/commit/a9c471decfaed2f469c52294ab4fac836871cc43
19:01:17evanack. forgot a file.
19:01:37boyscoutAdd missing file - 5171ef4 - Evan Phoenix
19:01:47evanwyhaines: sure, or commit them
19:01:50evanif you have a commit bit
19:02:22wyhainesI don't appear to.
19:03:34evanticket is fine then
19:06:37wyhainesCool. Will do.
19:08:14dbussinkwyhaines: also included tests?
19:08:18boyscoutCI: rubinius: 5171ef4 successful: 3024 files, 11747 examples, 35948 expectations, 0 failures, 0 errors
19:13:30brixenanyone know if Array#sort is stable in MRI by accident or design?
19:14:16brixenhm, maybe the iso draft says...
19:14:27DefilerLooked like it was by design to me when I was analyzing it
19:14:46Defilerand I've run into bugs in ruby libs that expected it to be stable
19:14:53Defiler..but were failing because the data was changing during the sort
19:15:00brixenyeah
19:15:09brixenironruby dev was asking on the rubyspec list
19:15:40wyhainesdbussink: I will provide tests, yes. In fact, if you all want to throw me a commit bit sometime, I'll work on filling in some more of the CAPI here and there.
19:15:55dbussinkwyhaines: cool :)
19:16:02dbussinkwyhaines: commit policy is very open
19:16:18evanwyhaines: sure. did you have a bit before?
19:16:20evani thought maybe you did.
19:16:22dbussinkbrixen: i think i remember that being discussed before
19:16:37dbussinkbrixen: i somewhat remember that it was a feature
19:16:40wyhainesevan: I thought I did, too. But I don't see it now. I know that I do for rubyspec.
19:16:58dbussinkbrixen: i think it was a discussion with the jruby guys
19:16:59evani'll add you on github
19:17:03evanpretty sure you had one before
19:17:41evanwyhaines: ok, added you
19:17:43evancommit away
19:18:02wyhainesevan: Cool. Thanks.
19:18:14dbussinkbrixen: looks like i remembered wrong: http://redmine.ruby-lang.org/issues/show/1089
19:18:33brixenso ISO draft only details Enumerable#sort and for the the result of #<=> only details < 0 and > 0
19:19:13brixendbussink: thanks
19:19:44dbussinkbrixen: from that discussion it seems that even mri doesn't have a completely stable sort
19:20:04brixendbussink: yeah, that's what I was inferring too
19:24:27Defilerinteresting thread
19:25:42ruewyhaines, evan: I am pretty sure I used the typedef for some particular reason, but it may just have been to either A) have a typedef to use or B) defensive coding to conform to C++'s function pointer types
19:26:06rueEither way if it works
19:26:08evanthe typedef is good
19:26:17evanmakes it clearer
19:26:19wyhainesrue: Yeah. No argument with the typedef.
19:26:31evanit's just a matter of using ANYARGS vs the exact signature
19:26:32evanbasically.
19:26:37wyhainesI just did it the way that I did because I was hacking, and it was faster to toggle it back if I left the typedef alone.
19:27:05rueYeh, dun remember what the rationale was. The change should work fine though
19:27:54rueWho was it that was rewriting Array#sort? Did that get finished?
19:28:20DefilerI think their username was \w+
19:28:23brixenrue: can't remember who that was but no
19:28:31DefilerSince Array#sort has been rewritten like 1123121 times in rbx heh
19:28:32brixenhaven't heard back from them
19:28:51rueMighta gotten discouraged with the edge cases :)
19:28:55brixenheh
19:28:59brixenthat tends to happen
19:29:14brixenprobably why MRI doesn't have a pluggable GC arch too
19:29:25brixenZING to all those wishers :)
19:30:24rueHeh
19:30:37rueThat discussion got good again
19:31:50evanif MRI had a pluggable GC arch, then I could write an Array#sort that is O(1)
19:35:18brixen*and* stable
19:35:21brixenuber stable
19:35:42brixeneven stable under #reverse and #reverse_each_other
19:35:45evanoh, mine is stable
19:35:47brixenand stuff
19:35:54evanit's also O(1) for all inputs.
19:36:15slavaif MRI had a pluggable GC arch, then you could write a stable ruby
19:36:49brixenslava: the standard ruby cut has a point and will never be stable unless it has high angular momentum
19:36:53brixenor something
19:36:58evanif you wanna see something wierd
19:37:03evana = []; a << a; a << a
19:37:04evana.sort
19:37:14evani don't understand that output at all.
19:37:28brixensweet
19:37:28slavawhoa
19:37:32brixenwhat the hell
19:37:38Defileraaaaaaaaah
19:37:41Defileraaaaaaaaaaaaaaaaaaah
19:37:44slava[[[...], [...]], [[...], [...]]]
19:37:54brixenthat screams bug to me
19:37:54DefilerOh, sure, I get it
19:38:05slavaits so weird that ruby attempts to do the right thing with circular structures
19:38:08slavalike making equality testing wor
19:38:10slavawork*
19:38:35slavawhen is that even useful?
19:38:46evanoh
19:38:46Defilercheck out a[0] and a[1]
19:38:47evanit's not.
19:39:02Defilerand therefore also a == a.first
19:39:45DefilerSo we're now sorting what looks like an array, but all three objects, the array and its two elements, are the same object
19:39:52evanI kind of hoped it would raise SortError::YourAnAsshat
19:40:11Defilerx = a.sort
19:40:16Defilerx == a
19:40:28slavaevan: raising that error in turn raises a GrammarNazi::YourIsNotYou're error
19:40:29Defilerbut of course they have different inspect outputs hehe
19:40:46evanslava: but via chained exceptions
19:45:00brixenDefiler: hmm, I dunno
19:45:29DefilerMy guess is that this is an artifact of what happens when you 'to_ary' a recursive array
19:45:36brixena = []; b = []; a == b; a << a; b << b; a != b
19:45:40brixenwhy is that?
19:46:23Defilerbecause as soon as you are recursive, you can't exhaustively check equality, you just have to go with the outermost wrapper
19:46:44Defilerso to == it probably looks like [object_12345] == [object_12346]
19:47:00brixenyes
19:47:14brixenbut that seems weird with the sort example
19:47:20Defilercheck this one out
19:47:26Defilera = []; a << a; a.sort
19:47:50evanyeah
19:47:51evanthats a wierd one.
19:48:25Defiler*b = *a
19:48:26Defilerhehe
19:48:40brixenheh
19:48:52DefilerThe result there surprises me
19:49:04Defilerand I think might be the underlying thing that is adding another wrapper around these
20:12:51rueevan: `class Array; alias sort non_const_sort; def sort(); t = Time.now.to_i; non_const_sort; sleep(O_1 - (Time.now.to_i - t)); end; end`
20:13:17rueO(1) !!
20:14:07Defileralias_method :awesome_sort, :to_a
20:19:19rueslava: Yeah, have to litter everything with a recursion guard because of it :)
20:19:51DefilerI don't understand the purpose of recursive arrays in ruby
20:20:00DefilerI have never seen them used in real code
20:23:38rueThere is no purpose
20:26:34brixenthey have a higher purpose
20:44:20dbussinkDefiler: they exists because they can
20:44:35dbussinkprobably someone trying to satisfy an intellectual challenge
20:45:57rueI venture it is strictly to protect users from the recursion
20:48:22brixenit is not hard to end up with a recursive structure
20:48:38brixenit's not the a = []; a << a case that matters
20:48:45DefilerYeah
20:48:59brixenit's some object that keeps an array of objects and that object ends up in the array
20:49:00Defilerfor example, ActiveRecord has a recursive structure in the 'errors' collection
20:49:05Defilerbut it isn't a ruby recursive array
20:49:18brixenpretty sure our AST or compiler ends up with recursive arrays
21:48:29evanobject graphs with cycles are quite common in ruby
21:48:45evanit's just that explicitly self recursive arrays are not very useful
21:55:54BrianRice-workare ruby collection libraries much like smalltalk in that deep copy methods assume no cycles in containership?
21:57:03brixenneither #clone nor #dup are deep copies
21:58:18BrianRice-workok, so there's no core copy method that recurses(?)
21:58:23ezmobiusthere isnt really a deep copy in ruby excpet for Marshal.load(Marshal.dump(foo)) which is kinda lame
21:58:33BrianRice-workok
21:59:53rueA generic deep copy is obviously difficult to do...but Array, Hash and so on should probably have standard-provided extra argument to #dup/#clone to allow specifying depth
22:00:08brixenDefiler: heh, I think that #sort behavior is from #dup
22:00:27brixena = []; a << a << a; a.dup # => [[[...], [...]], [[...], [...]]]
22:02:02evanfun.
22:04:43evanI should really add biomorphic IC optimizations
22:05:04evanthat would make #nil? much nicer
22:06:40brixenif #nil? is organic?
22:06:42brixen:D
22:06:50brixenoh, you mean bimorphic
22:09:01evanhah
22:09:01evanyes
22:09:03evanhehe
22:09:05evanbimorphic
22:09:07evannot biomorphic
22:09:19evanbiomorphic is when one lifeform turns into another?
22:09:22brixenwe really should add something biomorphic to rbx
22:09:48evanword.
22:09:59brixenbased on or resembling a living organism is what dashboard dict says
22:10:01evanmaybe turn carrots into buffalo
22:10:18brixenif I'm going to be a borg, I want rbx running my codes
22:10:27brixenthat's tweet worth haha
22:10:29evanheh
22:15:25dwaiteI thought the borg ran .Net?
22:16:03dwaiteyou better try talking to the ironruby folk if you want the nanobots in your blood to be able to run ruby
22:16:50brixenthe day nanobots from anywhere near M$ are in my blood is the day I'm in the morgue
22:17:01brixencus the bots would probably be suffering random BSOD
22:17:04dwaite'have you tried rebooting him?'
22:17:10brixenexactly
22:17:28Defilerbrixen: oooh dup huh? fun
22:17:35Defilerre: array fun
22:18:17brixenbesides, there's no one small enough to click the buttons on the tiny security exception confirm dialogs on the nanobots
22:18:28brixenso they'd just be frozen and not working
22:18:52Defilerso rad: http://github.com/mame/_
22:19:10brixenheh
22:19:22Defilerhttp://github.com/mame/_/blob/master/lib/_.rb
22:19:25Defilersweet at_exit
22:19:50dwaitewhat syntax is that?
22:20:54dwaiteoh no
22:23:00evanhehe
22:23:14evanit's like all the perl source filters
22:23:54brixenI feel like I could run this over these #require specs and they would be just as clear
22:24:03brixenno wait, they would be an improvement
22:25:08brixenyou think I jest, but I do not
22:25:09brixenhttp://gist.github.com/277578
22:25:18BrianRice-workit's like the hangman games that the ruby group's local nutty hacker likes to create
22:25:43brixensee that extended_on guard *inside* the Dir.chdir block using #`rm ??
22:25:49brixenthat is precious
22:27:28evanhah
22:27:38evanno, not hah.
22:27:40evanbad hah.
22:27:44evansorry brixen :/
22:27:49brixenweeps hah
22:27:50brixenyes
22:32:10ruebrixen: Pneumatic stegosauruses are biomorphic
22:32:23brixenrue: ahh indeed!
22:32:39brixenI wonder if one would fit in my living room...
22:32:52brixenmaybe a miniature
22:33:08evanhaha
22:35:33rueI have to say I will absolutely accept criticism for my part of the #require/#load specs. They were just flat-out ugly
22:37:08rueHowever, they also worked :) Plus doing it right would have taken #{brixen.been_working_on_them_how_long_now()} :/
22:37:57brixenrue: yeah, I know
22:38:11brixenI share as much blame to have ever let them exist
22:38:26brixenjust decoding them is painful
22:39:08rueNaw, they did the job, there was more important stuff to do
22:39:18brixenwell, they don't really do the job
22:39:27brixenrbx passes all the exiting ones
22:39:35brixenand fails half of my rewrites
22:39:41brixenso, yeah...
22:40:08rueHave you committed (parts of) the new stuff
22:40:12rue+?
22:40:17brixennot yet
22:40:38brixenwell, locally heh
22:40:45brixenincluding about 1000 git ci --amends
22:41:07evani was going to ask that
22:41:08evan:)
22:41:09rueHeh
22:41:37brixenI introduced a bug in it_behaves_like while fixing it for nested describes
22:41:58brixensomething needs to be dupped
22:42:04brixenduped
22:42:22evanoh goody
22:42:27evanFile.extname is at the top of this profile
22:42:35evani wonder what horror of performance i'm about to find
22:42:39brixenhehe
22:43:47evanactually not too bad
22:43:53evanthough the style is weird.
22:43:55dwaitewhat is the best way to profile a script?
22:44:01evan-P
22:44:03evanwell
22:44:05evan-Xint -P
22:44:10dwaiteI'm curious why that mandelbrot script I made a while back is so much slower than 1.9
22:44:34rueevan: How is the JITted profiling?
22:44:45evani need to fix it
22:44:47evanit's possible
22:44:56evanbut i need to move profiling up to a -X option
22:45:11evanit's not well tested either.
22:45:15DefilerOh, hey.. Python has exactly the same behavior of sorting recursive arrays
22:45:18evanso i just use -Xint while profiling
22:45:21Defiler(as in, it doubles the number of elements)
22:48:22rueevan: Hm. Do you have a hunch on whether there is anything that would skew the overall profile of some program between the two modes?
22:48:56evanit could
22:49:22brixendefinitely could
22:49:25rueAs in, for example, with JIT enabled some particular method would have a significantly better/worse than average runtime?
22:49:26brixenone would hope it would
22:49:38brixenotherwise the jit wouldn't be doing its job
22:49:38evanbut thats ok atm
22:49:49evanbecause i'm using the profile to measure algorithmic performance
22:49:55evannot overall performance
22:50:03rueTrue, I would not imagine it to be a huge problem
22:50:10evanrigh
22:50:12evanright
22:50:15brixenyeah, running with -Xint makes sense
22:50:25evangenerally profiling is because you want to know what the program is doing algorithmicly
22:50:27brixenunless you can tell the jit what to do from ruby code
22:50:32brixenyeah
22:50:49evannot how the algorithm is executed.
22:50:55brixenyep
22:51:04evanbut in time, we need to introduce a way to find out that info
22:51:08evanpossibly a sampler
22:51:22evanthat would at least tell you how much time was spent in JIT'd versus interpreted methods
22:51:24brixenI'd think shark/oprofile would be more useful then
22:51:28rueI suppose the main benefit I am thinking is just that using the real runtime i.e. JIT will allow concentrating the algo improvements on the parts that are the most troublesome at runtime
22:52:16rueDisclaimer: just musing, obviously it is not at the top of the list of priorities
22:52:37evanfunny enough
22:52:45evanif you try and profile the jit'd code
22:52:50evanyou influence it a bunch
22:52:53evanso it works less efficiently
22:53:04evanso it can become a loosing battle
22:53:11evanyou use profiling to find the hot areas
22:53:13evanyou improve them
22:53:17evanthen you rerun benchmarks
22:53:47rueTrue
23:16:39brixenheh, cool, just ran these specs under rbx using *rspec* 1.3.0
23:17:05brixenit is just wicked cool we run rspec
23:17:41brixenI spent so many weekends in early 2007 trying to even get a spec -v to print
23:17:46rueHeh
23:18:16evanoh nice!
23:18:21brixenit would just spin and use up all my memory and I couldn't figure out where that was happening
23:18:28brixennever figured it out
23:18:45brixenhad something to do with define_method inside an SClass
23:19:07evanhehe
23:19:10evannow it runs great!
23:19:15brixenit does!
23:19:28brixenI just gem installed it, installed mspec gem, and voila
23:20:00brixenheh fun side note...
23:20:05brixeninstalling rspec: rbx: Precompiling 312 files...
23:20:19evanrspec is big.
23:20:22brixeninstalling mspec: rbx: Precompiling 231 files...
23:20:33brixensame 3 digits!
23:20:34brixenheh
23:20:38evanhah
23:21:10brixenin fact, you can get it by rotating
23:21:11brixensweet
23:21:50evanversion << 1
23:36:10evanwell, thats a pleasent surprise
23:36:21evanfor a trivial String#split benchmark
23:36:27evanMRI: 4.45s
23:36:30evanRBX: 2.62s
23:37:05evan1.9: 1.2s
23:37:38evanMacRuby: 7.3s
23:37:46Defiler!!
23:38:18brixenwowsers
23:38:48evanjruby: 2.4s