Index

Show enters and exits. Hide enters and exits.

03:00:41davidruanI am new to rubinius, I just build the rubinius in ubuntu linux 9.04. The source is cloned from github.
03:01:03davidruanThere is an error when running code in bin/rbx:NameError: Missing or uninitialized constant: MethodContext
03:01:17davidruanAny body know the cause? Thanks!
08:45:37ruedavidruan: An old class that is somehow getting activated still
08:47:47davidruanthanks! what should I use to replace MethodContext.current?
08:49:46davidruanIs there new class to replace the function of MethodContext?
08:51:36davidruanrue: I read tutorial and try the sample code on rubinius
10:30:56rueWhich sample code?
10:35:22davidruanrue: http://programblings.com/2008/11/25/rubinius-for-the-layman-part-3-try-rubinius-in-20-minutes/
14:21:34rueThat is amusingly outdated :/
17:02:24seacreaturebrixen: ping
17:03:33seacreatureFor the RubySpec web prototype, we put together a simple XML formatter. It may evolve over time, but right now exposes all the detail we need.
17:03:36seacreaturehttp://is.gd/LBdA
17:03:49seacreatureinterested in having this upstream?
17:04:15rueIf not required to support it, probably :)
17:04:40seacreaturerue: We'll support it, obviously
17:04:51seacreatureat least as much as our needs dictate
17:05:03rueHeh
17:05:18seacreatureWe're moving along pretty quick, we may have something dumb but usable to show by tonight
17:05:31rueCool
17:06:13rueThe manual XML is a bit ucky, but definitely less demanding of the implementation than using a builder would be
17:06:58seacreaturerue: yeah, definitely. If it got more gnarly, we'd think about adding a builder
17:08:35rueI think it would be OK to add an optional builder dependency if it is needed for more advanced stuff, so long as it is electable
17:08:49brixenseacreature: is there a reason yaml wouldn't work?
17:09:07seacreaturebrixen: we were just having trouble emitting by line without escaping issues
17:09:24brixenemitting what by line?
17:09:26seacreatureA yaml emitter that outputs the same information would be better for our purposes
17:09:29seacreaturethe yaml
17:09:57seacreatureit was tedious to escape things like stack traces, but actually, I didn't work on this stuff, Brad did.
17:10:06seacreatureI was working on the database modeling last night.
17:10:19brixenthe yaml formatter already escapes the backtraces
17:10:32brixenI'm just trying to understand where the yaml formatter was falling down
17:10:42brixenI'd much prefer to fix it than maintain xml
17:10:48seacreatureUnderstandable
17:10:53brixenthat said, I don't care if you add a formatter
17:11:08brixenI just don't want to add them arbitrarily
17:11:31seacreaturebrixen: completely understand.
17:11:40seacreatureLet me get some extra info from Brad here
17:12:07brixenok
17:13:36seacreaturebrixen: The only concern is that this formatter is wildly different than your existing yaml formatter in the kind of information it produces
17:14:03seacreatureI mean, we could call it something like verbose yaml format or something...
17:14:19seacreatureI'm not sure how you'd like us to integrate it
17:14:37seacreaturebut Brad said that it's probably doable to move this over to yaml
17:14:56brixenwell, the existing yaml formatter can be extended
17:15:13brixenthe idea for it was to emit the spec info in a machine-processable format
17:16:12brixenyou can make the yaml formatter behave more like -fs
17:17:53rueJSON :)
17:18:02seacreaturerue: JSON came up last night as well :)
17:18:41brixenjson is fine, too, but what is the advantage over yaml?
17:18:53rueIt sucks less :/
17:19:09seacreaturebrixen: We're considering adding a :verbose key to keep the existing formatter backwards compatible
17:19:17seacreatureand then just put all our data in there
17:19:26seacreatureDoes that sound like a good way to go?
17:19:40brixenseacreature: there's really no reason to keep it backward compatible unless you plan to change the info it emits now
17:19:47brixenwhich I don't see a need for
17:20:06seacreaturebrixen: the info it emits now is per spec only, showing only the exceptions
17:20:09brixenyou can add all the description/example strings without modifying anything
17:20:29seacreaturewe do this at a much more granular level
17:20:43brixensure, but that doesn't conflict with the existing info
17:20:47brixenjust add to it
17:21:07seacreatureBut we're not reporting only exceptions
17:21:11brixenit emits the aggregate tallies and exceptions
17:21:14brixenyes yes
17:21:18brixenI understand
17:21:20brixenadd to it
17:21:21seacreatureThis is how I saw it...
17:21:30seacreaturedata[:exceptions] #=> ... existing stuff
17:21:38seacreaturedata[:verbose] (or :full_report)
17:21:46seacreaturewould be all of our additional data
17:22:28seacreaturethis is no trouble for us, we can easily hang all our data off a single key
17:22:42seacreaturewithout breaking anything that depended on the existing format
17:22:59seacreatureDoes this sound reasonable?
17:23:13brixenhttp://gist.github.com/121580
17:23:19brixenthat's the existing, with exceptions
17:23:42seacreatureright, so what I'm proposing is that verbose: ...
17:23:50seacreatureis our complete report at the per example level
17:23:56brixenright
17:24:02brixenthat should be fine
17:24:02seacreatureis that cool with you then
17:24:05brixensure
17:24:08evanmorning.
17:24:08seacreatureOkay, we'll prepare a patch
17:24:14brixenmorning evan
17:24:17seacreaturemorning evan
17:24:29seacreatureI'm keeping good on my word and breaking ground on the spec web stuff :)
17:24:49seacreatureproject will materialize at: http://github.com/madriska/unity
17:25:38seacreaturenothing to see there yet, though
17:26:52brixencool
17:27:36evanmy personal opinion, verbose is for human consumed data
17:27:44evanif it's yaml, it's probably for a machine
17:27:47seacreaturehave a better name?
17:28:07evanjust do it all the time
17:28:09evanwhy turn it off?
17:28:39seacreatureOh, I think there was a source of confusion here
17:28:45seacreatureWe will emit it all the time
17:28:50brixenright
17:28:54seacreatureI just need a name for the key we hang our data from
17:28:58brixenjust needs a key
17:28:59brixenyeah
17:29:07evanwhats in the data?
17:29:08brixencall it something like :specs
17:29:15seacreatureah, that'd probably be okay
17:29:34brixenit should be hierarchical I think
17:29:43seacreatureYeah, it will be
17:29:50brixenso the example strings are a list under the describe string
17:29:57rueMorning
17:30:04brixenyou could use serial #'s for all the specs
17:30:18brixenthe problem I see is relating this data over time
17:30:24brixensince the specs can change at any time
17:30:33seacreatureyeah... We have a solution to that
17:30:34brixenand even the example strings change
17:30:41seacreatureWe plan to explode the database on every import
17:30:43seacreature:)
17:30:49brixenok
17:30:55rueWe have a heat wave of 80.1 degrees on silly imperial scale
17:30:58seacreatureWe'll see how that goes and example something more robust
17:31:00brixenyou can relate the data by class and method
17:31:13seacreatureyeah, that's what our current implementation does
17:31:13brixenseacreature: you should check out the profiles in mspec
17:31:49brixenseacreature: ok, I'll let you guys work :)
17:32:10evanyou should sha1 the specs as the key for each spec
17:32:19brixenahh, that'd be cool
17:32:25seacreaturethat's an interesting idea
17:32:29evanand then have a 'set' of specs, thats just a list of sha1s
17:32:31brixenthe actual code of the specs
17:32:49evanthen, as the specs change, the latest set is the one you use
17:33:20evansince the vast majority don't change
17:33:29evanthe spec data will be pretty constant
17:34:37seacreatureYeah, that'd speed up import for sure. We'll keep it in mind and add it when the time comes
17:34:49evank
17:34:53evanjust a thought.
17:34:55seacreatureBut for now we're just trying to get something running before Brad goes back to Chicago tomorrow
17:35:05evanawesome!
17:35:05seacreatureevan: totally helps us out, we'll do it.
17:35:45seacreatureRight now, we're focusing on basically just getting a snapshot. The first prototype will be more about the sort of functionality a user can expect than it will be able how we'll actually do the infrastructure
17:36:36brixenseacreature: the thing to keep in mind is you want this to run on beginning, and sometimes very limited, implementations
17:36:46brixenseacreature: so you need to keep the data collection code very simple
17:38:16brixenis out for some errands, bbl..
17:38:32seacreaturebrixen: yeah, we'll keep an eye on that. Anyway, just give us a little while and we'll have a patch to review. We're hoping to finish that part before lunch
17:39:07brixenseacreature: don't worry too much about the patch now, just work on it till you got in going
17:39:16brixens/in/it/
17:39:52seacreatureyeah, sure. That's our plan but we also want to keep things in line with the project
17:39:59seacreatureif there is cleanup that needs to be done later, so be it
17:40:09brixensure, n/p
17:48:07seacreaturebrixen et. al : http://is.gd/LCU0
17:48:24seacreatureThis would do what we need
20:12:28evanyay.
20:12:39boyscoutAdd ability to profile JITd methods - 0db4d66 - Evan Phoenix
20:12:47evanoops
20:12:51evanthink I made a booboo.
20:15:58boyscoutInitialize include_profiling - 80d33f6 - Evan Phoenix
20:25:01boyscoutSupport RBX_OPTIONS as a way to set options - 98cfb93 - Evan Phoenix
21:49:44dgtizedevan: something isn't right about JIT profiling
21:51:12dgtizedfor the bm_array_each benchmark there are not enough calls to Array#each -- or is it simply it's uplifting the entire code into the body of the times loop?
22:58:39evandgtized: parton?
22:59:08evandgtized: profiling may not be working properly
22:59:14evani realized at lunch.
23:21:16boyscoutAdd flag for enabling profiling of JITd methods - 94c725b - Evan Phoenix
23:21:28evandgtized: try using -Xjit.profile with -P
23:21:30evanthat should fix it
23:49:53rueYes, doctor, but now I see all in triple