Index

Show enters and exits. Hide enters and exits.

03:25:48evanlibc_: don't bother with the jit/* code.
03:25:50evanit's going away.
03:27:02evanlibc_: i'll be back later
03:27:10evani don't know what you mean by "irb doesn't run"
03:27:41evani see you're in jit_visit.hpp
03:27:48evanwhich is the right place, but i'm not sure what your patch is doing.
03:27:53evanok, later.
03:28:17rueReplaced by what?
03:30:30slavahi evan
03:35:39libcevan, it fixes several things
03:36:05libcevan, like 0 - 1 = 1073741823
04:01:17boyscout1.8.7: IO#getbyte (implemented new method) - f7c1522 - Marc-Andre Lafortune
04:01:17boyscout1.8.7: IO#bytes (implemented new method) - 8e0312f - Marc-Andre Lafortune
04:01:17boyscout1.8.7: IO#each_char (implementation of new method) - 39aa2f6 - Marc-Andre Lafortune
04:01:17boyscout1.8.7: IO#chars, #readbyte, #lines (implemented new methods) - a34f420 - Marc-Andre Lafortune
04:01:17boyscout1.8.7: ARGF#bytes, chars, each_char, getbyte, lines, readbyte (implemented new methods) - c810fec - Marc-Andre Lafortune
04:01:19boyscout1.8.7: ENV.delete_if, .each, .each_key, .each_pair, .each_value, .reject!, .select (optional block) - fbb991a - Marc-Andre Lafortune
04:01:22boyscoutNot implementing GC.stress= and Process.exec - ebf0f64 - Marc-Andre Lafortune
04:01:24boyscout1.8.7: StringIO#getbyte, #readbyte, #each_char, #chars (implemented new methods) - e6d2b19 - Marc-Andre Lafortune
04:04:45boyscoutCI: e6d2b19 success. 2683 files, 10344 examples, 32915 expectations, 0 failures, 0 errors
05:56:29evanlibc_: why have you not committed those fixes?
05:56:52libcevan, I didn't finished, I can commit them
05:56:58evanalso
05:57:09evanthe jit isn't hooked up to run automatically
05:57:24evan-Xrbx.jit.enabled isn't running it.
05:57:28evani'm working on that now
05:57:37evanwhy do you say it doesn't run irb?
05:57:39libchm, runs for me
05:57:45evanit's not the LLVM JIT
05:57:52evanit's likely the old one
05:57:52libcit is llvm jit
05:57:55evanwhich is completely busted.
05:58:02evanthen you must have hooked it up yourself
05:58:05evanbecause i haven't yet.
05:58:53evanah hrm.
05:58:56libcevan, my evidence :) -Xrbx.jit.show_compiling puts JIT compiling method name, and when I change jit_visit.hpp errors messages are actually go away
05:58:58evani guess it might actually sort of work
05:59:07evancompletely by accident
05:59:20evannow that I look at it.
05:59:27evanbecause I wired it into make_machine_method
05:59:33evanwhich is what the current JIT uses
05:59:39libcyeah
05:59:43evanok, nm!
05:59:44evanmy mistake
05:59:51evani didn't intend for it to work :D
06:00:08evanyou should commit those fixes
06:00:08libcbackground thread still should have broken primitives
06:00:14evanhuh?
06:00:39libcthe last hunk in diff, I reresolve_primitives after jitting
06:00:50evanwhy?
06:00:53evanwhy did you do that?
06:01:08libcactivate overwrites it, at least as far as I understand
06:01:31libcmachinemethod::activate
06:01:48evanhm
06:01:51evanthen your fix is wrong
06:02:01evanbecause it shouldn't change it if it points to a primitive
06:02:05evanie, they should be completely ignored
06:02:13evanresolving it early doesn't help
06:02:37libcevan, I reresolve it after jit, not before
06:02:46evanoh
06:02:52evanthats the wrong way to handle that
06:02:53libcit helped me :) got prov_from_env error
06:03:00libcI know
06:03:05evanthats the error i'm getting now too
06:03:09evanwas going to work on it shortly
06:03:18evani'll fix the primitive override problem now
06:03:31evanwhats the fixnum_tag fix for?
06:03:38evanwhat code was behaving incorrectly?
06:03:48libc0-1 = 1073741823
06:03:56libcand 0 + -1
06:04:50evanhm, let me check.
06:05:22evanhuh
06:05:22evanweird.
06:05:27evanso why that change?
06:05:30evani'm trying to understand it
06:05:37evanbecause i'm worried we've got a similar problem elsewhere
06:06:11libcbecause you store them in 31bit
06:06:13libcand <<
06:06:25libcthen cast to 32bit
06:07:01libc1073741823 is 30 ones (31 ones in fixnum representation)
06:07:48evanhm.
06:09:15evani guess the integer types don't work the way I thought they did in LLVM
06:12:31evanlibc_: i guess if a 31bit is used throughout
06:12:38evanthe upper bits aren't properly cleared?
06:12:53libcthe upper bit is a sign
06:13:15libcwhen you shl in 31bits you lose it, and when cast to 32bit the upper bit is always zero
06:13:38evanah
06:13:40evani see
06:14:00evanmy problem was asking the question "which 31bits of a 32bit int are used"
06:14:11evani had the wrong assumption about which section of bits was used
06:14:41libcheh, strange assumption
06:14:47evani guess so.
06:16:17evanso why haven't you commited these fixes?
06:16:37evanother than you've got a weird coding style
06:16:50evan'Value * tagged' mmm, no.
06:16:55evan'Value* tagged' please
06:17:59evanalso
06:18:06evanwhy are you reloading vars_?
06:18:10evanthat doesn't seem right at all.
06:18:23evanoh oh
06:18:25evani know why.
06:18:34evanbecause create_block causes it to move.
06:18:35evannm!
06:18:41evanwe should only need to do that once
06:18:57evanbut i guess we don't know which create_block is run first
06:18:59evanso this is fine.
06:19:30evanlibc_: ?
06:19:33evanhello?
06:19:34libcdoing rebase
06:20:43evani've got a whole bunch of changes locally
06:20:48evanbut i can wait until you commit these
06:22:23libcevan, I also added check_serial instruction, should I left it out, or push?
06:22:59evanif you've got it
06:23:02evango ahead and push it
06:23:04evani didn't do it yet.
06:23:28libcyou did rbx_check_serial though
06:23:51boyscoutFor loops skip the most recent variable scope - cbbec37 - Eugene Pimenov
06:23:51boyscoutCheck serial instruction for llvm JIT - 2ef2dbc - Eugene Pimenov
06:23:51boyscoutLLVM jit fixes - 77f77e7 - Eugene Pimenov
06:23:57evanlibc_: so I did!
06:24:02evanbut I guess i never wired up the JIT to call it.
06:24:07evani did a bunch of the util functions at once
06:24:14evanand then went back and wired them up to be called
06:24:17evanmust have missed that one
06:24:43evanlibc_: on these fixes, try and be a little more details in your commit message :)
06:24:52libcevan, I put details after first line
06:24:58evanok good!
06:24:59evannm then!
06:25:42evanoh, you finally commited your for fix too
06:25:46evanthanks for the attention to detail!
06:26:11libcyeah :)
06:30:52slavaevan: so llvm converts stack usage into registers for you, right
06:32:10boyscoutCI: 77f77e7 success. 2683 files, 10346 examples, 32917 expectations, 0 failures, 0 errors
07:03:57evanslava: if it can, yes.
07:04:45slavawhat scope does it operate on for this?
07:04:51slavajust basic blocks or the whole procedure?
07:07:29evani'd imagine it tries to cross basic blocks
07:07:39evanit has to be careful though
07:07:47evansince while they can be registers
07:07:54evanthe stack is seen globally
07:08:00evanso the GC can see it
07:10:55slavaevan: how does your GC sweep values that were saved in registers between procedure calls?
07:11:53evanthey're not in registers at that point
07:11:54evanthats how.
07:12:15slavaok
07:19:26slavaI'm extending my stack->register pass to work on more than just basic blocks. I've got it doing diamonds now, I'm going to test it more then make it do loops
07:20:17evanslava: is it just tracking when the flush from registers needs to happen more carefully?
07:20:44slavayeah
07:21:15slavafor gc, I'm going to build a list of live registers at every gc point, and if the gc check actually succeeds it will save/restore those registers to a known memory area when calling gc
07:21:30evanah
07:21:36evanso you're going to allow it to scan register contents
07:21:48slavayeah, otherwise its unsound
07:21:56evanwont that really be scanning the stack for where the registers get spilled to?
07:22:12evansince by the time you get to the scanning code, those registers will have spilled
07:22:16slavayeah, and generating the code that performs the spilling, even
07:22:37evanah, so at each gc point, it spills the registers to some memory and lets the GC know where it spilled them and how many there are
07:22:37slavawhen the gc actually gets called, the values are still in registers though
07:22:43slavayeah
07:24:26evanand after the gc finishes
07:24:26evanit restores from that memory
07:24:26slavaexactly
07:24:26evanthat the GC has updated
07:24:26evanthat seems like about the same thing i'm doing now
07:24:26slavabut llvm does it for you?
07:24:26evani suppose it's more coarse
07:24:27evanit handles all the registers itself
07:24:27evanthe output code thus far is pretty nice
07:24:27evani haven't thrown anything super complex at it yet
07:24:27slavaand generates info that your gc can look at?
07:24:27evani should check
07:24:28evani could generate code for each safe point
07:24:28evansure
07:26:57slavaI haven't even tested it for real yet. I'm just throwing IR at it, spotting mistakes, and adding unit tests that assert some invariant or another
07:28:32evanwell, let me know how it goes
07:28:34slavadoes your jit itself have unit tests?
07:28:37evanhows C++ going for ya?
07:28:43slavaor do you just run your ordinary ruby specs against it
07:28:56evanrunning the ordinary ruby specs against it
07:29:07slavahaven't done much on the VM side for a while, but I have an on-and-off project to refactor it to not use GNU extensions, so that I can use other C++ compilers
07:29:07evani've been thinking about jit unit tests
07:30:49evanbut non written
07:38:06dbussinkevan: don't know whether you've seen it, but looks like i've stumbled on a gc bug http://github.com/evanphx/rubinius/issues#issue/5
07:42:41evandbussink: interesting.
07:42:53evanthats kind of a GC bug
07:43:11evandbussink: is it easy to make happen?
07:49:39dbussinkevan: yeah, well, i think it's related to the fact that there is one spec in do_postgres that tries to connect with an incorrect password and that timeouts after a few seconds (some sort of security measure in postgres)
07:50:06dbussinkevan: so it doesn't do anything for a short period and during that time the gc runs and exposes the issue
07:50:16dbussinkso it's reliably reproducable
07:52:33evandid you reproduce it with DEV=1 ?
07:52:50evancould you update that issue and tell me how I can make it happen?
07:58:21dbussinkevan: yeah, i can do that, gotta go now to a customer first though
08:00:09evanok.
11:39:45rueWoo
11:40:31scooprhoo?
16:23:09balinthey, I created a ticket for my first patch: https://rubinius.lighthouseapp.com/projects/5089/tickets/775-patch-dirglob-recursively-matches-any-n ondot-subdirectories-with
16:23:21balintshould I do anything else?
17:07:42ruebalint: No, that should be fine
17:09:08balintrue: thank you. I guess I am just kind of impatient :)
17:09:24ruebalint: Does that affect any other specs in either direction?
17:10:26balintrue: no, there were two less failures than without the patch (that's because Dir.[] is an alias for Dir.glob so two specs were fixed with one 'stone')
17:16:18rueHm. The existing logic seems a bit suspect
17:19:12balintrue: ?
17:27:49rueThe logic seems a bit odd, to check the "file" separately...but maybe it is the best way to do it.
17:28:14evanmorning
17:28:46evanbalint: you need to write a spec for it
17:29:07evanoh, there were specs? must have been tagged
17:29:09balintevan: there was a failing spec, my patch is a fix
17:29:43evanokey
17:29:45evanone sec!
17:32:12rueevan: Do you have changes to vm.{c,h}pp incoming? The header is pretty cluttered
17:32:22evanbalint: nice! ok, i'm going to commit this shortly
17:32:28evanbalint: and you get your free commit bit!
17:32:36evanyes
17:32:38evani have changes incoming.
17:32:43evangoing to commit them shortly
17:33:02evanit's not really that cluttered
17:33:05evananyway
17:34:04rueYeah, it is :)
17:34:09evannah.
17:34:17evanthere are much more cluttered ones.
17:35:42rueThat I shall not dispute
17:36:01balintevan: thank you! my github user name is balinterdi
17:36:06evanif you're going to spruce them up, please try and stick with the existing style
17:36:59rueevan: Mm, oh, is there any reason to not make constructors explicit and prohibit copy construction by default?
17:37:43evanbetter question: is there a reason to do those things?
17:42:21rueIn short, yes. It prevents errors
17:42:35rue(It is one of the "Efficient C++" items, too.)
17:44:12rueErm, also the more well-known "Effective C++"
17:45:38evanso, you'd add explicit to all constructors
17:45:54scooprisn't explicit more useful only when a constructor happens to take excatly one param
17:45:59evanand declare a copy construct thats not defined?
17:48:54rueYes, explicit is only for constructors taking one parameter
17:48:57scooprhiding copyconstructor is occasionally nice, but I wouldn't care to do that *everywhere* .. though you can do that in a base class (like call it, say Uncopyable)
17:49:24radhruinWell, it is also useful for constructors that take multiple parameters but the others have a default value.
17:49:45rueMm, yeah, /requiring/ one parameter
17:49:58scooprwell, that's implictly single param constructor, point still stands
17:50:06evansure, for ones that take one param, explicit seems ok
17:50:10evanthats a small subset of ones
17:50:14evanas for copy collector
17:50:25evanmaking a superclass Uncopyable that things inherit from seems logical
17:50:39evanthat explains to future users why it's there
17:50:44evanfor ObjectHeader though
17:50:51evandefine the copy collector right in there
17:50:55evanwith a comment about why it's there
17:51:18evanto keep the class hierarchy clean for Object and friends
17:53:35rue'Es
17:54:08evanis that a yes?
17:54:09evan:D
17:55:32rue'Es
17:55:42evanrecursive answers!
17:59:43scooprI would start speaking in unlamdas, if I only knew how!
18:01:45evanhm
18:01:49evanis gh slow this morning...?
18:02:04evanbah, it is.
18:02:10boyscoutfixes Dir.glob recursively matches any nondot subdirectories with '**/' - 99ac594 - Balint Erdi
18:02:11boyscoutIgnore directories with no access to - ed149ac - Evan Phoenix
18:02:11boyscoutFix args to show_backtrace - b53ec2e - Evan Phoenix
18:02:11boyscoutHandle ArgumentErrors and #exit's that bubble to the top - 8ee0821 - Evan Phoenix
18:02:11boyscoutAdd ability to turn on GIL debugging at runtime - bf09647 - Evan Phoenix
18:02:11boyscoutMake thread::Mutex recursive by default - 042144b - Evan Phoenix
18:02:13boyscoutUpdate CallFrame::ip so backtraces in JITd code is correct - 0f20e45 - Evan Phoenix
18:02:15boyscoutWire background compiling thread into JIT mode - e53284c - Evan Phoenix
18:02:19evanthere we go!
18:02:40evan-Xjit.enabled turns the JIT on, using the background thread
18:02:57evan-Xjit.show will print out whenever the JIT queues and finishes compiling a method
18:03:17rueExcellent
18:03:25boyscoutCI: Build e53284c failed. http://ci.rubini.us/rubinius/builds/e53284c829c3357fb35ccc8abd05abcc389af96d
18:03:31evanBOO
18:03:43evanah crap.
18:04:17evanone sec
18:08:39rueevan: Build-time RBX_LLVM still required?
18:09:16evanyes.
18:09:24evani'm fixing things right now.
18:10:21boyscoutProperly protect code that uses LLVM - e8de010 - Evan Phoenix
18:14:14scooprif I have llvm in odd place, what would be the best way to tell rbx that? LDFLAGS="-L/opt/llvm/lib" CXXFLAGS="-I/opt/llvm/include" rake build ?
18:14:22evanno
18:14:32evanwell, are you using SVN head?
18:14:35evanof llvm
18:14:45scoopryes, but that's maybe month old
18:14:53evanprobably won't work then.
18:14:59evanmy patch made it in a week ago
18:15:01scooprwilling, to update it =)
18:15:23scoopr(willing to learn comma placement too)
18:16:02evanheh
18:17:03ruescoopr: Just symlink it?
18:29:55boyscoutDisable the JIT for methods with primitives installed - ead8407 - Evan Phoenix
18:43:38evanwell, irb runs under the JIT when it's pre-compiled
18:44:01evangoing to figure out why it doesn't compile
19:03:53sandalevan: is rubinius targeting Ruby 1.8.7+ or mostly aiming for 1.8.6 compat?
19:04:38scooprah right, the llvm c/ldflags come from llvm-config.. it's in my path though, and it doesn't find it in rake
19:04:55evansandal: 1.8.6
19:04:58scooprah wait
19:05:07sandalevan: great, thanks
19:05:19scooprit tries to find it from external_libs, so that was the symlink rue ment :P
19:05:26evansandal: but marcandre has been coding up 1.8.7 and 1.9 support for us
19:05:37evansandal: in lib/1.8.7 and lib/1.9
19:05:43evanthey're overlays for the current code
19:05:44sandalevan: how will that work? Enabled via flag?
19:05:53evanyeah, a flag probably
19:06:01evanhe just started, we haven't worked out the details yet.
19:06:11sandalrequest. please make 1.8.7 an explicit choice != 1.8
19:06:27evanhow do ya mean?
19:07:04sandalI mean... I wouldn't like to see 1.8.7 supplant 1.8.6
19:07:22evansure, thats our plan
19:07:31evani'm curious why you're requesting it
19:08:21sandaloh... just because it makes some book authors, library maintainers, and distro managers frustrated that 1.8.7 exists
19:08:33sandalIt would have been fine as an experimental branch
19:08:46sandalbut its frustrating as the mainline Ruby 1.8
19:08:57evancertainly.
19:09:24sandalanyway, if that's already the plan, that's great
19:09:32sandalI just wanted to make sure I was reporting accurately in my talk
19:09:52evangotcha
19:10:11brixensandal: 1.8.7 make some rubyspec writers frustrated it exists too :)
19:10:20sandalMy personal opinion is that soon enough, most alternative implementations will be a better Ruby 1.8 than core Ruby 1.8, if they aren't already
19:11:09sandalBut I think that'll be more likely to be the case if they lock to 1.8.6, which seems like what everyone is doing
19:11:31sandalIt's just sort of scary to think of things like Ruby 1.8.8 backporting 1.9 *syntax*
19:12:07brixenI'm just glad we run out of digits after 1.8.9
19:12:16sandalahaha, good point!
19:12:21jptix1.8.10!
19:12:33sandaljptix: not going to happen due to matz's preference
19:12:35brixenjptix: noooo, unbounded craziness
19:12:43scooprwhoa, Resolv#getaddresses resolves localhost FAILED
19:12:44scooprExpected 0 to be greater than 0
19:13:12sandalbrixen: then maybe they'll just redefine the meaning of patchlevels
19:13:19sandalbrixen: to include new features :)
19:13:37brixensandal: yes! as bit patterns
19:13:53brixenbit 12, new Array#first protocal
19:13:57brixenetc
19:14:02brixenit will be wicked cool
19:15:35sandalis there any sort of official rubinius logo?
19:15:49brixenkinda sorta
19:15:55evanthe lower case r is usually used
19:16:10brixensandal: http://twitter.com/rubinius
19:16:22brixenwe, um, need to tweet a bit on that account
19:16:24brixenheh
19:16:27evanheh
19:16:31sandalcool, thanks
19:16:47brixenevan: we're falling behind the cool kids like maglev and macruby
19:16:55brixenwe better get on it
19:17:01evanyeah we are.
19:17:24evani'm so happy I built the JIT as an explicit thing first
19:17:36evansince I can debug it by just explicitly JIT'ing one method
19:18:49scooprguess what Socket.getaddrinfo("127.0.0.1", nil)[0][2] is for me? :P
19:20:01evan*shrug*
19:20:03evan42?
19:20:46scoopra host that passenger.prefPane has set up for me..
19:20:50sandaloh man, putting all these various logos in one place looks disgusting. Time to revise to use text :)
19:20:52scoopr(namely, gems.local)
19:21:30evanthose specs suck
19:21:37evanthey assume all kinds of stuff
19:21:37brixenscoopr: those type of Socket specs could use a better approach
19:21:51brixenscoopr: suggestions/patches welcome :)
19:23:51scooprah, I know nothing about how that should work, I'm actually more worried that has passenger.prefpane "broken" my system by changing something that some apps might assume as well
19:24:42evanno
19:24:48evanthose specs just assume too much
19:25:13scooprk
19:49:26dbussinkevan: i was trying with a debug build to reproduce the gc bug resulted in some other error
19:49:43dbussinkevan: my debug build gobbles up 4gb of virtual memory and can't mmap any more
19:50:58evanwow.
19:51:01evannever seen that.
19:51:12evanthe main thing i need to know is how to repro it.
19:51:15evanyou didn't specify that
19:55:38dbussinkevan: hmm, now i'm getting another one :S
19:57:26evan:/
19:58:38brixenevan: ok, I've got one that I can repro unless I'm in gdb :/
19:58:40brixenevan: http://gist.github.com/118219
19:58:55brixenevan: how would you track that down?
19:58:55evanthe best kind!
19:59:10brixenor the most frustrating...
19:59:11evanhm.
19:59:24evanthats a really big number.
19:59:29evan2147487744
19:59:32brixenyeah, look at the bit pattern
19:59:38brixen4096 + bit 32 set
19:59:52evanalmost like it's a truncation error
20:00:15evanor a casting problem.
20:00:21brixenyeah
20:00:32brixenif only I could get to a code location
20:00:58evanset a breakpoint on mmap
20:01:03evanor malloc
20:01:09evanthat might throw a lot though..
20:01:10evanhm.
20:01:22brixenit doesn't happen if I run rbx under gdb
20:01:45brixenI could try that though
20:03:27dbussinkevan: i've updated the issue with how to reproduce it, it needs a postgres setup atm though
20:03:36dbussinkevan: sqlite3 doesn't show the issue
20:03:41evank
20:07:17dgtizedhmm, I've got a spec hanging at Process.fork - return nil for the child process
20:09:16dgtizedlooks like wait_pid never returns because something is going wrong in the child's exit
20:11:04dgtizedbut there are 3 rbx processes alive, one is <defunkt>, one is blocked on a wait_pid, and the other is in pthread_mutex_lock from thread::Mutex::lock
20:12:24evanprocesses or threads?
20:12:42dgtizedps -a | grep rbx lists 3 processes
20:12:49evannot sure why that would be
20:12:56dgtizedit's in the middle of a fork
20:13:25evanis this a tagged spec?
20:13:38dgtizedit's just a normal ci run
20:14:25dgtizedbin/mspec ci -B full and I tried it once with -fs to diagnose which spec was hanging
20:15:01dgtizedI also cleaned, and rebuilt just to make sure
20:15:08dgtizednot using llvm though
20:17:04evanthats fine
20:17:10evanin every one of these cases
20:17:17evani'm looking for a clean repro
20:17:28evanthe quicker you get that too me, the faster we get it fixed!
20:17:35dgtizedit happens every time for me right now
20:17:39evanif you get the repro, open an issue, nad send me the url
20:17:45evanthen you get a cookie!
20:17:53dbussinkevan: http://github.com/evanphx/rubinius/issues/#issue/5
20:18:00dbussinkevan: now where's the cookie?
20:18:06evanyou already did that
20:18:09evanPRE-cookie offer.
20:18:11evansorry
20:18:12evannext one!
20:18:20evani do owe you cookies though.
20:18:30brixenoffers good only while supplies last...
20:18:39brixenoops, I ate all the cookies
20:18:47evanBRIXEN!
20:18:51evanshakes head.
20:18:52evansorry guys
20:18:53brixenheh
20:18:57evanbrixen ate all the cookies.
20:23:10evandgtized: open up an issue
20:23:18evandgtized: so we can track it.
20:25:01boyscoutAdd -Xgc.show to print out when the GC runs - 720b6a4 - Evan Phoenix
20:25:01boyscoutLocation objects now indicate if the running method was JITd - dd35e12 - Evan Phoenix
20:25:01boyscoutRead VariableScope out of CallFrame on every use - a4ed51b - Evan Phoenix
20:26:13evanrad.
20:26:30evanbin/rbx -Xjit.enabled -S irb
20:26:31evanruns
20:31:04dgtizedfuck markdown for code examples -- how the hell are you supposed to indent that many lines in a browser editor
20:33:38ruePretty sure <code /> works too.
20:33:58dbussinkdgtized: put in links to gists also works
20:34:14rueBut I use It's All Text, so I types in the vims
20:37:44dgtizedhttp://github.com/evanphx/rubinius/issues/#issue/7 -- yea <pre><code> does work, it's just the indent syntax is such an annoying shortcut
20:40:00rueI usually indent(ed) code in e-mails and such
20:43:56evanI use <pre>
20:44:03evanok, lunch!
21:22:18evanoh, backtraces when running with -d now show which frames are running via JITd method
21:22:21evans
21:33:39evandgtized: is this hanging happening everytime
21:33:42evanand what commands are you runing
21:33:44evanjust 'rake' ?
21:36:40evanok, i see it happening on elle
21:36:43evanchecking it out now.
21:47:34boyscoutCI: e8de010 success. .................................................................................................... .................................................................................................... .................................................................................................... ...............................................................................
21:47:39evanthat was me.
21:48:43rueYou do not have to print all the dots yourself
21:49:00evanno, i've got a script to do that.
21:54:59boyscoutManage the GIL around fork() properly - 5562ec6 - Evan Phoenix
21:55:07evandgtized: that should fix it for ya
22:00:36rueevan: Should there be some special marker for the JITted frames in the bt?
22:01:08evanthere is, yes.
22:01:13evanLocation#is_jit
22:01:23evanit's not showed in backtrace unless $DEBUG is on
22:02:26boyscoutCI: 5562ec6 success. 2683 files, 10346 examples, 32917 expectations, 0 failures, 0 errors
22:02:29evanyay.
22:04:17rueAh, I see it now
22:04:46rueBy the by, -X should probably warn if it gets an option it does not recognise such as *cough* jit.enable
22:05:27evanhehe
22:05:30evanyeah, i did the same
22:05:33evannot sure how though
22:05:44evansince, by default, there is no closed set of options
22:06:02evan-X just throws stuff into the general RUBY_CONFIG
22:08:28rueMm. Could maybe restrict e.g. the "vm." and "jit." namespaces to require definitions, if not all?
22:09:23evanhm
22:09:34evanwell, -Xconfig.print is useful to figure out if they got set properly
22:09:50evanbut yes, i suppose we could close the set of options with certain prefixes
22:11:39rueOr alternatively only send "config." without further checks
22:11:46evanhuh?
22:15:17rueNm.
22:27:05dgtizedevan: thanks that fixed it
22:27:31dgtizedquestion, do we have a timeout on the build bots if they take too long running mspec ci?
22:27:48evannot atm, no.
23:02:43yakischlobaevan: i notice rubinius ffi does not have get_array_of_foo like ruby-ffi does. do you know the reason for this inconsistancy?
23:04:07evanruby-ffi added a whole bunch of stuff
23:04:11evanthat wasn't in the original API
23:04:18evanand I haven't ported their stuff back in
23:04:33yakischlobaokay, so its not bad, just a matter of getting it in there?
23:04:37evanyaeh
23:04:49yakischlobaok
23:07:48yakischlobamaybe i will do a little of that soon then
23:26:34evanyakischloba: ok
23:26:59yakischlobalooks pretty straightforward
23:27:25slavahi evan
23:27:37slavai'm pestering jrose with stupid questions about dataflow analysis
23:28:29evanhehe
23:28:31evanover email?
23:29:32boyscoutAllocate storage for the strings, since they're freed - 2ec98ab - Evan Phoenix
23:29:35slavain #mlvm
23:30:08evanah! I didn't know he was on IRC
23:30:10evanthats rad.
23:32:05boyscoutCI: 2ec98ab success. 2683 files, 10346 examples, 32917 expectations, 0 failures, 0 errors
23:43:20boyscoutWarn for unrecognized vm options - f68f4b1 - Evan Phoenix
23:43:28evansee how fast I fix bugs when you guys open issues?
23:43:28evan:D
23:47:58boyscoutCI: f68f4b1 success. 2683 files, 10346 examples, 32917 expectations, 0 failures, 0 errors
23:59:27boyscoutAdd descriptions to config variables - 2bc8d00 - Evan Phoenix
23:59:30evanbin/rbx -Xconfig.print=2 -v
23:59:35evanfor all your configuration variable fun