Show enters and exits. Hide enters and exits.

00:06:11jaribthere are other problems here as well, #call, #location, and #to_proc all fail if it's not a CompiledMethod
00:06:22jaribperhaps i'm barking up the wrong tree
00:06:27evanno no
00:06:32evanyou're right on track.
00:06:40evanwe need to fix all those things
00:06:50jaribok, good
00:07:02evanthis is just a neglected corner
00:07:19jaribi'm happy i found something i could almost understand ;)
00:13:14jaribi'll do some specs first
00:15:13evangood call.
00:15:28evanit's pretty rare for people to use method() on accessors
00:15:32evanthat's why we haven't hit this
00:16:46jaribi ran into the other day trying to pass all of Array.instance_methods to Rubinius.jit :)
00:17:10evanyou were being adventerous!
00:17:17jaribyep :)
00:18:47evanheh, yep
00:18:51evanby the time rbx exists
00:19:03evan21 of 88 jit queued methods have been completed
00:27:09boyscoutAdding rb_rescue{2} to capi, specs included. - 21fb94d - Cezar Sa Espinola
00:27:39headiusevan: did you add anything to jit all methods?
00:28:00evanadd anything?
00:28:06evanlike chocolate sauce?
00:28:11evanperhaps gummy bears?
00:28:13headiusI don't think there was any way to trigger that before
00:28:27evanstill no way to jit all methods
00:28:35evanthats an interesting case, but it's not as useful
00:28:42evanbecause you'd jit methods that haven't ever been run
00:28:49evanso the JIT can't make a very good decision
00:28:53headiuswell, without heuristics for when to jit it's a little cumbersome to test anything nontrivial
00:28:55slavaif you don't have a way to save machine code to disk, then compiling everything really sucks
00:29:14headiusdid you add heuristics?
00:29:21evanheadius: locally, yes
00:29:22brixenevan: step 2, list the methods that jit completed and those it didn't
00:29:27evanheadius: a simple call counter
00:29:37evangoing to commit shortly.
00:29:58evanoh woops!
00:30:10evanjust realized a flaw in how the background thread processes requests
00:30:28evanit isn't emptying the queue
00:30:35evanit's doing one, waiting to be signalled
00:30:38evandoing one, waiting again
00:33:30boyscoutCI: 21fb94d success. 2682 files, 10327 examples, 32876 expectations, 0 failures, 0 errors
00:39:08rueMm, related to dumping object code to disk, what about dumping an "image" from a training run? Say, running some web server with some artificial requests until stuff has gotten JITted, then dumping that data out so that production can run straight off the object code where previously deemed necessary?
00:39:28rue('Course you could always just have a list of methods but that seems much less fun)
00:39:57evanwell, we could dump out the pre-trained LLVM IR
00:40:14evanand compile and link that offline
00:40:19evanthen dlopen it back in
00:40:51evani've discussed with the LLVM guys a little about the ability for the JIT to report relocation info
00:41:06evanso that we could save machine to disk in a simple format
00:41:10evanmachine code
00:47:51rueYes, it would be a pretty handy feature to have for many use cases
00:49:26headiusis llvm that slow to compile?
00:51:04rueDepends on how much you are compiling?
00:52:52headiusthat makes no sense
00:53:07headiusthat's like saying whether or not a car is slow depends on how far you're driving
00:55:59evanheadius: i'd imagine it's probably about the same speed as hotspots optimizing compiler
00:56:32headiuswell, we could check's possible to force hotspot to compile up front
00:59:22headiusI was just wondering if it's worth the hassle of dumping native code to disk and having to validate it all the time
00:59:55evanheadius: when hotspot compiles up front
01:00:15evani guess that means it's compiling without many optimizations?
01:00:18headiusthat's the main reason JVM folks have given me for not dumping, validation, avoiding staleness
01:00:42headiusno inlining, etc, except where it's possible to statically analyze
01:01:12evanwhats the use in that?
01:01:19evani mean, does anyone do that?
01:01:27headiusnobody does that
01:01:46headiusbut there's knobs for everything
01:02:05headiusso here's a fairly unscientific measurement
01:02:31evansure, knobs knobs galore
01:04:02headiusgenerating a rails app with default settings, JRuby compiling everything in advance, hotspot compiling all methods immediately (threshold 0), no background compilation = 1m27s
01:04:32evanthats pretty darn good.
01:05:00evanwhen is it compiling them then?
01:05:00headiussame generation with jruby compilation off and default settings in hotspot (probably mostly interpreted) = 5.5s
01:05:08evanwhen a class loader imports them?
01:05:23headiusno, first invocation
01:05:27headiusI'm not sure there's a setting to compile on load
01:05:32evanso it's not all methods
01:05:42headiusall invoked methods, sure
01:05:48evanby all methods, I thought you meant ALL methods
01:05:50headiusbut that's still thousands
01:05:51evanregardless of running.
01:05:58headiustends of thousands counting jruby internals
01:06:24headiusnot that we wouldn't love to have a native code cache
01:06:28headiussave that warmup time
01:06:34evani can't give a speed on LLVM really
01:06:43evani'm sure if you look around, you can get some info
01:07:06headiusI just remember you saying it was slow
01:07:24evanthere were a number of factors then
01:07:33evan1) we were compiling all methods when they we imported to the system
01:07:44evan2) we were leaning on LLVM's inliner WAY too much
01:07:59evan3) complication was inline with execution
01:08:11evanwe're trying to eliminate all 3 of those
01:09:07evan1) use call counters and explicit complication
01:09:20headiushey, did you fix that float issue?
01:09:32evan2) drive IR generation more explicitly, using specific code for every opcode
01:09:39evan3) use a background complication thread
01:09:45evanheadius: yeah, thats solved
01:09:49evanjit'd code wasn't calling the GC
01:11:47headiushmph, I need to get your build working in jruby
01:12:06headiusbuilding rubinius is the only thing I have to use MRI for
01:45:22jaribbrixen: so the ci run seems to be a subset of all known good specs, is that right?
01:46:19jaribit's not actually all of them?
01:49:59brixenjust bin/mspec ci run spec/default.mspec :ci_files
01:50:04brixena subset, yes
01:50:17brixenrake runs bin/mspec ci -B full
01:50:28brixenwhich is spec/full.mspec :ci_files
01:50:42brixenwhich is still a subset if you consider the exclusions
01:50:51brixenbut it's a fuller subset :)
01:51:11jaribi see
02:11:25headiusevan: hey, I did a rebuild and .jit doesn't seem to be jitting
02:11:29headiusstill need a property set somewhere?
02:12:30headiusalso, evan or brixen: is it still possible to turn on ruby_parser?
02:13:47headiusor anyone that knows, I suppose :)
02:17:51brixenyeah, you can enable ruby_parser from the cmd line
02:18:19brixenwe try to keep things cryptic :)
02:18:35brixenas for the jit, dunno, I haven't even gotten to play with it yet
02:20:16headiusbrixen: actually I meant in the build
02:20:26headiusI want to be able to build rubinius with JRuby so I don't have to keep switching to MRI
02:20:35headiusI think the PT dependency is the only thing keeping it from working
02:20:54brixenwe use pt in the build?
02:21:00headiusok, for jit it still needs RBX_LLVM=1 for build
02:21:04headiusso that's one question answered
02:21:26headiusbrixen: for compiling kernel, I thought that's what it did
02:21:34brixenit uses ruby_parser
02:21:37brixenfrom MRI
02:22:12headius~/projects/rubinius ➔ /Users/headius/projects/jruby/bin/jruby vm/instructions.rb
02:22:19headius /Users/headius/projects/jruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require': no such file to load -- parse_tree (LoadError)
02:22:25headiusI call BS
02:22:37brixenwhat file?
02:22:53brixenwell, that's the only one
02:22:59brixenand that is not kernel ;)
02:23:05headiusI just said build
02:23:08brixenI assure you kernel is built with ruby_parser
02:23:09headiusand "or something"
02:23:22headiuslooking at instructions.rb now
02:24:07headiusseems to be codegen/instructions_gen
02:25:21headiusit doesn't appear to be possible to run this with ruby_parser anymore
02:27:55headiusI was hoping it was just a simple switch I could throw
02:28:24brixenwell, we'll be removing that requirement anyway
02:28:31brixenjust suffer with mri for a bit longer
02:28:51headiuswell, I'll see if I can fix it
02:37:23headiushmm, I just thought of a way we could support parsetree in a limited way
02:38:31headius➔ jruby -X-C -rjruby/ext -e "def foo; [1,2].each {|a| puts a}; end; p method(:foo).sexp"
02:38:40headius"(newline (callnoargblock each (array (fixnum 1) (fixnum 2)) (iter (dasgn a (nilimplicit)) (newline (fcallonearg puts (array (dvar a)))))))"
02:39:22headiusthat's an internal sexp we build for jit purposes
03:04:52evanheadius: i haven't committed it.
03:05:01headiuscommitted what?
03:05:12headiusI was using .jit still
03:05:22headiusjust didn't realize it still needed RBX_LLVM set
03:07:18evani thought you meant it was doing it automatically
03:07:25evanwhich it's not.
03:07:45evanthat PT dep in instructions.rb can easily go away
03:07:51headiusyeah, I'm working on it
03:07:54evanit was just to generate nice #line entries
03:08:00evanwhich I think we disabled a while ago anyway
03:08:04evanso it's just cruft.
03:09:59headiusmmm, yeah, does seem to only be doing that
03:11:13evanheadius: when you JIT a method
03:11:21evanhow does that get installed?
03:12:10headiusthere's another layer of indirection that encapsulates InterpretedMethod when running in jit mode
03:12:20headiuswhen it jits, the reference flips to a JittedMethod
03:12:40headiusjit execution is a bit slower than precompiled execution as a result of the indirection right now as well
03:13:52boyscoutSmall compatibility change in capi's ruby.h - 60f62b7 - Cezar Sa Espinola
03:13:52boyscoutAdding rb_gc_start() to capi. - 84e6679 - Cezar Sa Espinola
03:13:52boyscoutAdding rb_exc_raise() to capi, with specs. - bf5ccd9 - Cezar Sa Espinola
03:15:15headiusthe array that decode_methods produces is used for other things afterwards
03:15:16headiuswith the sexp in it
03:16:04headiusthe output of RubyParser.parse appears to not be completely compatible with parse_tree_for_method
03:16:44evancezarsa: if you wanna, would ya do rb_ensure too?
03:17:24evanheadius: yeah, it's not.
03:17:43evanheadius: because zenspider changed it to be the unified_ruby format
03:17:51cezarsaevan: sure, i'll take a look into it
03:17:51headiusand you aren't using the unified format
03:18:08evanwe're not?
03:18:10evani thought we were.
03:18:25headiuswell something's preventing it from being compatible, right?
03:18:30headiusI don't know, you tell me :)
03:18:35evannot that I know of.
03:18:48evani'm not aware of any troubles.
03:18:53cezarsaevan: it took a while until I figured out how to make rb_rescue, things a clearer now :)
03:18:53headiusmy first attempt was to parse instructions.rb offline and put all the methods in hashes
03:19:01headiusso you have the parse trees available
03:19:20headiusbut there's no flatten, for example
03:19:40evani don't follow.
03:19:59evanwell, cavs game is back on.
03:20:07headiusinstructions_gen pulls sexps out of all the methods defined in instructions.rb
03:20:18headiusflattens them, monkeys with lines, and then builds the structure
03:20:38evanoh that
03:20:41evanit's crap code
03:20:48evanwe should just remove it entirely
03:20:51evanit's really crufty
03:20:57evanformat wise, i've got NO clue what it does
03:20:59headiuswell, then I tried to just noop the sexp+line stuff and now it doesn't generate a valid.cpp
03:21:05evanit's a complete hack.
03:21:10headiusI'll fiddle with it a bit more
03:21:29boyscoutCI: bf5ccd9 success. 2682 files, 10328 examples, 32877 expectations, 0 failures, 0 errors
03:59:46headiuswhere are these #ruby directives in the instructions template handled?
04:08:46headiushey, I think I have it
04:14:26headiusevan: got up to the point of compiling .rb files
04:14:36headiusthen it hit your oniguruma match_start call
04:26:48headiushmm, getting there
04:26:52headiusimplemented something pretty close to match_start and got further
04:30:45headiusyakischloba: looks like wayne just landed your get_array_of_strings in jruby
04:31:12yakischlobaheadius: yeah, that's what he said. i've been slacking on getting him the specs and a few other fixes he wanted. suppose i should do that now.
04:31:19headiusyes :)
04:31:26yakischlobanot slacking. busy rather :)
04:32:13headiusbusy schmusy
04:33:03yakischlobaheh. we just got 3 months worth of commits on eventmachine released *finally*
04:34:44headiusjruby stuff being kept up to date too?
04:35:04yakischlobait hasn't been, but in the last month has received some special attention (even a cash bounty, heh)
04:35:16yakischlobaso I think it'll be worked up pretty good in the next release
04:35:34headiuswow, cash bounty?
04:35:50yakischlobayeah. couple guys put up $250 bucks for work on the java reactor.
04:36:34yakischlobaI think EM runs some serious production systems, that most of us never hear too much about
04:36:47headiussounds familiar
04:36:54headiusI think jruby runs a lot more stuff than we ever hear about too
04:37:03yakischlobayeah, which is unfortunate
04:37:14yakischlobapeople think they're shit because 'no one big is using it'
04:37:40headiushopefully there will be a couple big names coming out with jruby stuff soon
04:38:23yakischlobaheh. it would be nice if the heavy users would come forward and say it, so everyone doesn't think ruby or project Foo is simply a toy
04:39:56headiusyeah, I think it takes a good year or two of steady progress and quiet users for things to start coming out
04:40:17headiuswe've had production users for three years now but most people still don't come out and say it
04:44:33headiusso hey, answer me a quick question
04:44:45headiussomeone told me EM couldn't host a multi-threaded server...why is that?
04:44:59headiusI think events and I think asynchronous and I think threading
04:45:14yakischlobait certainly can. there were reasons not to, up until recently, but it should be pretty safe now.
04:45:28headiusbecause it seems like that could be the server to beat all servers with jruby
04:45:51yakischlobaI know precisely nothing about how the java reactor works
04:45:52headiusmakes it very similar to the best http servers in Java then
04:46:05yakischlobaso if that's what you're asking about, I have no idea heh
04:46:07headiusbut in C...if the impl had parallel threads, would it work?
04:46:15headiusor what would be required to make it work?
04:46:32yakischlobaso you're saying the C++ reactor?
04:46:46yakischlobahooked up to jruby somehow? or to mri as it normally is
04:47:02headiusjust MRI but imagining an MRI with real parallel threading
04:47:21headiusI'm just trying to understand what the current state is and what it would take to make it work with a real threaded impl
04:48:02yakischlobathe current MRI implementation just has a thread-safe EM.next_tick(&blk) method that schedules a proc to be executed on the next reactor turn
04:48:25yakischlobaso you just use that to do shit from threads
04:48:52headiuswell that's easy enough
04:50:12yakischlobaso what *is* the deal right now with mri and real parallel threads? i've been trying to grasp this. just the stdlib/core/whatever you want to call it (array, string etc) is not thread safe?
04:53:49headiuseverything in C is not thread safe
04:54:10headiusand they only have since global locations for VM state
04:54:48headiusso the entire execution engine would have to be rewritten and fine-grained locks or bounds checks put around all data mutating methods
04:55:05headiusYARV comes a bit closer with execution engine, but does nothing for core classes
04:55:25yakischlobasorry, YARV is what I was referring to. my bad
04:55:37headiusyarv handles runtime state a bit more sanely
04:55:42headiusbut not core class data
04:55:57yakischlobawhich is a super pain in the ass to do?
04:56:07headiusjruby kinda gets a free pass...we don't guarantee core classes are thread-safe, but the worst that happens is a single thread might raise a concurrency or array out of bounds exception
04:56:22headiusbecause the JVM makes certain guarantees for us
04:56:28headiusyeah, super pain in the ass
04:56:29yakischlobai see.
04:57:06headiusit could still be done, certainly, but not without a lot of work
04:57:16yakischlobaso we were all debating this a bit the other day. obviously you have significant interest in jruby and consider it a viable long term prospect
04:57:26yakischlobabut what is a good concurrency plan for ruby?
04:57:51headiusfor the C impls? beats me...seems way too hard for me to contemplate a solution
04:58:19headiusif I were to make a harsh recommendation...rewrite on top of a real VM
04:58:37headiusnot necessarily JVM
04:58:53headiusjust anything that's solved parallel threading for userland code already
04:59:21yakischlobai see
04:59:47yakischlobai learned to program on EM, with reactor pattern, so threading is somewhat foreign to me
05:00:08yakischlobabut I am pretty interested in seeing ruby not be constrained to 1 processor
05:00:19headiuswell, in jruby there's not a whole lot to it if you keep data structures pretty isolated and use something safe to communicate between them
05:00:22headiusthreads just work
05:01:22yakischlobaso i guess this leads into another thing that i've been meaning to ask you about for a while
05:01:53yakischlobai often see you seem a little exasperated that more people aren't using jruby
05:02:01yakischlobaand logically i understand the reasons why it is good
05:02:10yakischlobabut for whatever reason, I have never used it
05:02:20yakischlobaso i guess i'm just curious how you can interest more people
05:02:28headiusheh, does it show?
05:02:40yakischlobahah, does it ever
05:02:48headiusI know I grouse about it a lot
05:03:07headiusit's an uphill battle to make JRuby's coolness overcome Java's ultra uncooleness
05:03:11yakischlobawhich is fine. you have a large personal investment in it, and it has a disproportionately small following (that i am aware of, anyway)
05:03:32headiusI think there's going to be a tipping point
05:03:51headiusenough of the native gems ported over, enough visible users, enough of the little gotchas finally ironed out
05:04:24headiusI don't think I'm too far off saying it's a superior implementation to the other production impls right now...maybe not the most advanced out of all the impls, but darn good
05:04:46yakischlobasure, i don't doubt it. and i don't really think thats what keeps people from using it
05:04:58headiusthere's just enough pain points and enough association with Java that we haven't hit that tipping point
05:05:01yakischlobayeah, i think a lot of it is just that it's related to java
05:05:04headiusstartup time for example
05:05:12headiusthose native extensions
05:05:22headiusoccasional bugs
05:05:29headiusall of which improve release on release
05:05:38yakischlobais FFI the only way to access C libraries?
05:05:42headiusit is
05:05:50yakischloba(not saying there should be another way)
05:06:19yakischlobaso I think maybe you need to do a little more fanboy appeal intensive stuff maybe?
05:06:46yakischlobashow me how easy it is to install and setup, show me its the ruby i know
05:06:47headiusI guess part of our problem is that everyone interested in jruby right now is a pragmatist, not a fanboy :)
05:06:51headiusso we don't really have those kinds of people
05:06:59headiusthey get their job done and keep pretty quiet
05:08:16headiusI guess we don't really know what else we can do
05:08:22headiusbut keep improving, keep bridging the gap
05:08:35headiuskeep working 14 hours a day :)
05:09:30yakischlobathe website is not very approachable
05:09:44yakischlobalooking at it now, i remember i've looked at it before and havent gotten past the landing page
05:09:57headiuswebsite is frigging horrible
05:10:04yakischlobawell, theres your first place heh
05:10:07yakischlobamake it easy for me to get started
05:10:16headiuswe'd be better off dropping them on a damn wiki
05:10:19yakischlobadont make my eyes bounce 30 different places before I find the "getting started" link :)
05:10:26headiusconfluence is the ugliest thing ever
05:10:30yakischlobathat's where I end up after the landing page, heh
05:10:50headiusin contrast, look at rubinius or macruby's pages
05:11:01headiusmillion times better
05:11:39yakischlobashrug. i have recently developed an appreciation for extreme simplicity on web pages. rubinius gets it, macruby is still even a little cluttered
05:12:49yakischlobathough, they do put it pretty well in your face
05:12:57headiusit's definitely better than ours though
05:13:04yakischloba1. 2. 3.
05:13:05headiusours has had a handful of edits in the past 3 years
05:13:08yakischlobabam, thats how i do it
05:13:10yakischlobawith jruby im like
05:13:37headiuswe should put up a radiantcms or something
05:13:40yakischlobado i have to install some crazy java shit? is it like when i was working on an android app and i had to battle my package manager to get the right versions of everything? what the fuck am i doing?
05:13:42headiusso we can have it be easly editable by users
05:14:07headiusfor almost everyone it's like a two-step process
05:14:16headiusunpack ; add to $PATH
05:14:25headiuson some linuxes it's just a package install
05:14:36yakischlobaokay, well show people that
05:14:53yakischlobai guarantee you fix that shit website, advertise it for a day or two, and you'll get a bunch of users
05:15:14headiusperhaps that's better than me spending another day improving performance 5%
05:15:42yakischlobaperformance is important, but remember everyone is still running on mri 1.8.6 or 1.8.7 even though YARV is way faster
05:15:49yakischlobaand it's just because ruby peopel are silly sometimes
05:15:50headiusvery true
05:16:08headiusI've been wanting to put up more information on gem equivalencies and stuff too
05:16:15yakischlobaand that can be solved by providing clarity
05:16:16headiusif you use A on MRI, you can switch to B
05:16:33headiuslike imagescience versus imagevoodoo
05:16:37yakischlobaI'm pretty sure if you made up a screencast of "here are the things that 1.9.1 breaks, and here's how to fix them" then people would start using it
05:16:47headiusrmagick versus rmagick4j
05:17:03yakischlobabut everyones like err uhhh but isnt there that thing that doesnt work? im not sure. i heard it wasnt that much faster anyway. this other thing doesnt work
05:17:32headiusheh, yeah, I think I've heard that exact conversation :)
05:17:47yakischloba1.9.1 isn't production, blah blah
05:17:59headiusit's like the 1.8.7 thing
05:18:09headiusit broke some stuff initially, and now it's forever tainted
05:18:28headiuseven though nobody can now say what it breaks, probably because there's nothing anymore
05:18:46yakischlobafor fucks sake, users of this language that is the most dynamic thing to ever be created, are scared shitless of changes to it
05:18:52headiuswe've only recently gotten people to realize we run rails
05:18:55headiusI mean, seriously
05:19:14headius"So, JRuby is neat, but can I run Rails on it?"
05:19:25yakischlobastop crying about how YARV doesn't work, change all your calls to String#each to String#each_line, and enjoy the fucking benefits
05:19:51yakischlobayeah that's another great example
05:20:08yakischlobabut that's something I barely even knew
05:20:20yakischlobaso resolving those murky things is key
05:20:45yakischlobalay it out real simple for those people that develop and get hung up on the stigma
05:20:57headiusif only sun's marketing dept weren't totally clueless
05:21:01headiuswe might have some real help
05:21:49yakischlobatrue, though i think it's not as hard as you think
05:22:05headiusprobably's just not my thing
05:22:16yakischlobaconveying truth, dispelling rumor, and making it approachable
05:22:16headiusneither evan nor lrz did the rbx pages
05:22:48headiusbut of course I'm just making excuses at that point
05:23:25yakischlobaright. there are plenty of design-er-ish people who would be happy to contribute a weekend of their time to getting jruby a nice website
05:23:37headiusyeah, we need to just pull the trigger on that
05:23:42yakischlobaso find one you like and do it heh
05:23:51headiuswe've had offers but never followed damn busy
05:24:07yakischlobayeah well, you have a great impl now, so make it a priority
05:24:38headiusyou know, you're right...I think it's long past due
05:25:11yakischlobai'm certain that's why you don't have the user base you want
05:26:20headiusyeah, it could be that simple
05:26:23yakischlobai'm a nerd so i'll spend time going through other peoples code to figure out how to use it etc, but a lot of people will turn straight away if they don't see immediately how it will benefit them and how little work they have to do to achieve it
05:28:11headiusyeah, some of my best-received blog posts have been step-by-step instructions to do X with jruby
05:28:15headiusseems obvious in retrospect
05:28:55headiushell, even maglev has a better site than us, and theirs has nothing at all
05:30:46slavaheadius: remember the pointless tree benchmark?
05:31:01headiusI remember lots of pointless tree benchmarks
05:31:05slavahaskell's compiler makes it linear-time by doing common subexpression elimination
05:31:23slavamake_node(x-1) and make_node(x-1) are pure functions right? :) so you don't have to compute it twice
05:31:33slavait was that ironpython -vs- jython blog post
05:32:15headiusheh, doesn't surprise me
05:32:44yakischlobapart if me wishes there weren't so many ruby impls. it makes it hard for someone to decide which one they might want to learn about and work on :p
05:33:10headiusyakischloba: well, there's only one alternative impl that's actually used in production
05:33:34yakischlobayeah, but that's not what I mean
05:33:34headiusso at least for usage, the choice isn't too hard
05:33:44headiusyeah, I know :)
05:33:55headiusif I weren't working on jruby I'd probably work on rubinius
05:34:20headiusI think it's the most likely to be open and community-driven
05:35:14yakischlobado you think it will achieve good performance and beyond?
05:35:26headiusshould I give my honest opinion on #rubinius? :)
05:35:35yakischlobadepends on what it is :)
05:35:42headiusI just realized we've been talking about all this in here instead of in #jruby
05:35:53headiuseverything hoped for rubinius is possible
05:35:57headiusit just hasn't even been done yet
05:35:59yakischlobashrug. it's applicable.
05:36:42yakischlobaof course. i'm not someone who looks at a project and says "it isn't done, therefore it's shit and i won't look at it"
05:36:49slavaheadius: who cares if maglev has a better web site
05:36:54slavathey don't have a product
05:37:03headiusif I were going to work on rubinius I'd be building it atop java 7
05:37:18slavaIf I was working on java 7, I'd build it on top of llvm
05:37:19headiuswith the upcoming dynamic language support
05:37:28headiusslava: well, that's already under way :)
05:37:31yakischlobait's a tough thing I guess. people have different goals for ruby.
05:37:49slavaheadius: so did people figure out how to do inline caching with llvm?
05:37:57headiusbeats me, I don't follow llvm
05:38:39headiusyakischloba: truly
05:42:52yakischlobabtw I hate kenai. its slower than molasses
05:43:09headiushmm, it never seems very slow to me
05:43:10yakischlobaffi has the approachability issue as well :p
05:43:32headiusno slower than any other site anyway
05:44:34headiusthough I'm probably biased...kenai is a jruby on rails site
05:45:11headiusany perf concerns are not jruby's fault, I assure you
05:45:24yakischlobaof course not!
05:50:33headiuswell, I've spent enough time yapping tonight
05:50:41headiusyakischloba: thanks for the insight
05:50:53yakischlobahaha same. am just finally getting started on the ffi thing.
05:51:43yakischlobaheadius: sure man. i hope i'm right and changing those things will help :)
05:52:20headiusme too :) nite
15:24:39boyscoutAdding rb_ensure() to capi, with specs. - ce4fe4e - Cezar Sa Espinola
15:31:10boyscoutCI: ce4fe4e success. 2682 files, 10332 examples, 32881 expectations, 0 failures, 0 errors
21:11:51marcandreAnyone has clues on to reason with Matz?
21:12:03slavawhat did Matz do?
21:12:35marcandreWell, in 1.8.7, I noticed that str.each_char returns str.dup and not str.
21:12:49marcandreNow he wants me to _justify_ my patch.
21:13:00slavawhy should each_char return anything?
21:13:07rueI agree, it does need justification
21:13:08slavaiterating over characters is something you'd do for side-effect
21:13:10tarcierimarcandre: be part of the Japanese ruby-core in-group
21:13:12slavamap-char would return a new string
21:13:18rueslava: Ruby is all expressions
21:13:34marcandreYeah, the discussion is on ruby-core.
21:13:40slavarue: sure, but that doesn't mean everything has to evaluate to something arbitrary
21:13:49tarcierimarcandre: otherwise you are no good gaijin out-group person
21:13:51ruemarcandre: You cannot just drop a patch without any reason for the change
21:14:10rueThat said, the consistency argument is simple
21:14:36marcandreOK. Can I respond, without sounding too arrogant:
21:14:43slavaI think at some point once JRuby and Rubinius gain enough momentum you can stop trying to remain compatible with MRI braindamage
21:14:45marcandrePlease name one single method that returns a dupped copy of self
21:14:50marcandrePlease name one single reason why each_char should return a dupped copy of self instead of self
21:15:12tarcierislava: hopefully... 1.8.7+ sounds like it's going to be a train wreck
21:15:29marcandrePlease bet $10k against me that a survey of rubyists would find that a third or more would expect each_char to return a dupped copy of str?
21:15:34tarcierislava: the Python people totally had it figured out with from __future__ import
21:15:45ruemarcandre: Um, why be snotty about it?
21:16:18marcandreBecause, last time I checked, I was not compensated for my time spent arguing about things that shouldn't be arguable!
21:16:30tarcieriwant some 1.9 feature in your 1.8 program? then elect to turn it on
21:16:59rueI am not aware of any international agreements that require #each must return self, not a copy
21:17:02marcandreI'm gladly issuing a patch for what is clearly a bug, and instead of thanks, that has been committed, I get a "please justify"
21:17:27marcandrerue: can you name me one method (apart for each_char) that returns self.dup.
21:17:52marcandrerue: alternatively, please name one single reason why each_char should return a dupped copy of self instead of self
21:17:54rueNo. So why not give that reason?
21:18:02rueAnd not be an asshole about it
21:18:59rue"This change was made to bring #each_char in line with all the other #each* methods which all return self, not a copy. It should follow the same pattern unless there is a crucial reason not to, and in that case it must be clearly documented."
21:19:00marcandreIf _nobody_ can see a _single_ reason why the current behavior is correct, and _nobody_ can show me another method with the behavior I'm calling a bug...
21:19:10marcandreThen why do I have to justify it?
21:19:15rueSeriously, I do not understand the attitude
21:20:37marcandreIt probably has something to do with my perception of an enormous entropy on ruby-core.
21:20:56marcandreSee for instance my 1 line patch submitted 3 months ago (#1165)
21:21:28marcandreRecalled 2 or 3 times to n0kada.
21:22:01marcandreI have the feeling I am fighting with ruby-core to improve Ruby, while I should be feeling I am collaborating with ruby-core.
21:22:35slavatime to make your own language
21:22:38rueYou cannot do much about the other people, but I would recommend you stop "fighting"
21:22:51marcandreslava: :-)
21:23:01rueIt really is not much to ask to provide a reason for making a change
21:23:09marcandrerue: Do you mean I should stop submitting patches?
21:23:22slavacontribute to rbx instead, evan is a very reasoanble guy
21:23:35rueNo, you should stop "fighting"
21:23:57marcandreslava: I am :-) And it's been a really enjoyable experience, contrary to the really frustrating experience of contributing to ruby-core
21:24:40marcandrerue: I don't want to fight! But I don't feel respected when asked unreasonable questions and when my humble contributions are not being addressed in a reasonable fashion.
21:24:51tarcierislava: YES!
21:25:12ruemarcandre: Addressing this one instance only, there is just the patch. No comment why it was made and what it was intended to do
21:26:17marcandrerue: I did address talk with n0kada and tought I had addressed his questions about it. Moreover, this is another case where I don't see why a discussion is needed.
21:26:25marcandreOr how about #1385.
21:26:47marcandreIt took 3 weeks for Matz to say "I confirm". Ticket still opened, change to the doc not made.
21:27:44rueSeriously, man, *I* would reject the patch if you could not tell me why you made the change
21:27:53rueBut you can!
21:29:03marcandreI thought I had given the example for the bug in 1165. The fact that the == doesn't do what the official documentation states, in addition to common sense, should be justification enough, no?
21:29:59marcandreI guess what I don't understand is: isn't the goal of ruby-core to improve Ruby and MRI?
21:31:07tarcieriyes, but the culture/process is a bit... jacked
21:31:15rueOK, I am done talking about this.
21:31:27tarcierirue's message was great
21:31:30tarcieriyou should send them that
21:32:18marcandreI agree rue's message is very good, and I'll answer that then.
21:32:43marcandreI'm still wondering why I have to.
21:32:59tarcierito be diplomatic
21:33:03tarcierito their in-group
21:33:10yakischlobamarcandre: if it is this frustrating, perhaps it would be more healthy for you to concentrate your efforts elsewhere
21:34:01marcandremaybe I should. My real wish though would be that the (very small) issues I'm raising would be resolved!
21:37:43marcandreThanks to everyone for the discussion.
21:39:33tarcierihey slava
21:39:42tarcieriyou implement eval using a metacircular evaluator?
21:39:57tarcieriErlang does the same thing, except their eval is a ginormous hack
21:40:00rueI *think* the reason for the current implementation is what Matz is intimating; if there is a modification to the string, returning the dup is the only way to get both (as dumb as I think the overall idea of protecting against mutation there is)
21:40:05slavatarcieri: no, I don't have a metacircular interpreter
21:40:23tarcieribecause iiuc rbx just compiles a temporary bytecode object thing
21:40:27slavaeval parses and compiles the code using the various runtime APIs for this purpose, its just a convenience library
21:40:28tarcieriand that's what I'd like to do as well
21:40:48slavaits slower though
21:40:51tarcieriyeah I'd like to just build a temporary module and call a function on it then unload it
21:40:55slavaI don't really care about eval at all
21:41:01tarcieriwell you have a repl right?
21:41:15slavayeah, but it doesn't matter if repl input takes an extra millisecond or two to compile
21:41:20tarcieriZyeah exactly
21:41:25slavajavascript people really abuse eval so badly
21:41:27tarcieriI mean, I *need* eval for a repl
21:41:33slavaV8 and SquirrelFish have an LRU cache to map string -> AST even
21:41:41slavaand they fast-path some forms of eval where its just getting a local variable value or something
21:41:46slavaand they don't JIT eval'd code
21:41:53tarcierii c
21:41:59tarcieriI just want eval to like... work properly
21:42:01slavaits just a pain in the ass and its only needed because of all the shitty web designer javascript coders
21:42:15slavafor a REPL you'd be OK by compiling the string to bytecode and running that
21:42:27tarcierimy eval is broken in all sorts of places because I'm thunking to another language's metacircular interpreter which is already wonky to begin with
21:42:33slavaa metacircular interpreter specially for eval would be faster sure but its not worth the effort IMO
21:42:51slavalike you can skip the compilation step and just walk the AST
21:42:59slavabut now you have to ensure the semantics match 100%
21:43:05tarcierithat's the problem
21:43:30tarcierithat's why I like the compiled solution
21:43:34tarcierithere's no impedence mismatch
21:43:39slavaeval of an empty string takes 0.000153 seconds heh
21:43:48slavain factor
21:43:58slavathat's pretty slow if you're a webtard doing eval in a loop
21:44:50slavaif you expose the AST then most uses of eval for meta-programming go away
21:45:01slavaeval is really string -> AST -> bytecode/native code
21:45:04tarcierimy main interest is the repl
21:45:18slavain common lisp, the AST -> code step is the 'compile' function
21:45:23tarcierithat's why I don't compile to core erlang right now
21:45:27marcandrerue: That argument would hold for any other method. My 5 cent bet is simply that it's an oversight (and in my mind that should not be insulting at all!). In any case, I have responded with your very diplomatic phrase (and I tried not to talk in your place)
21:45:32slavaand that's a generally more useful thing to have than eval
21:45:56slavait sounds like rbx has a good separation of concerns here too, which is nice to hear
21:46:07tarcierislava: yeah, that's why I was wanting to copy rbx's approach
21:46:24tarcieriright now I'm basically creating my own equivalent of CompiledMethod
21:46:43tarcieriand as I understand rbx uses CompiledMethod to implement eval
21:48:23tarcierislava: I think my general roadmap is something like... implement my CompiledMethod equivalent, add a few more language features, then rewrite the compiler in Reia itself, and have it output Core Erlang
21:48:46slavajust don't lose your only working copy of the bootstrapped compiler
21:48:53tarcieriyeah definitely
21:49:10slavaimagine if all copies of gcc in the world just stopped working
21:49:20slavaoh noes! time to write new C compiler in asm
22:30:52evanallo kids
22:31:45evanbeen buying beer and cleaning up the loft
22:36:11evanas it applies to the return value of #each and friends
22:36:22evani'd say that if consistence is a worry
22:36:26evanthey should return nil
22:36:48evanand require the user to use the more explicit methods to define the behavior
22:39:09marcandreThanks evan. I just noticed that the patch has been applied by Matz. :-)
22:39:25marcandreI've updated my older tickets too.
22:39:32yakischlobamarcandre: maybe the world is not stacked against you after all :)
22:41:04marcandreActually, I doubt I'm the only one who would like changes to ruby-core applied more easily!
22:41:09marcandreI'll try to get my patches applied one by one :-)
22:41:40evanmarcandre: oh? he changed each_char back to returning self? yay.
22:42:06evani didn't like the change mainly because it's an overhead burdon
22:42:20evanie, if each_char can function without having to make an internal opy
22:42:32marcandreOh, the dup is still there.
22:42:32evanit shouldn't be burdoned with having to make on just to mean the API definition
22:42:43evanas long as the dup is completely internal
22:42:44evanthats fine.
22:42:47evanthats an impl detail
23:50:11evandoing phase 2 of GIL removal
23:50:22evanthe ability to communicate the intend to stop the world
23:55:43marcandreevan: I'd love some help...
23:56:07marcandreI noticed that a couple of String methods have arg = nil, when it should be arg = Undefined. (e.g. gsub, initialize, ...)
23:56:23marcandreBut changing them creates really funky problems.
23:56:41marcandreirb(main):001:0> 1+1
23:56:42marcandre=> 1
23:56:48marcandreAny clue?
23:57:04marcandreNote that it quits after any input
23:58:12rueOne thing is you must be sure that Undefined is not getting returned
23:59:28rueAnd you changed the checks to be against Undefined specifically, right?
23:59:56marcandreI'm doing them one by one to see which one causes that.