<|jemc|>
and I had a process working for getting the rubinius build to install my local gem but I think I'm doing too much work
<yorickpeterse>
also you should be able to just Gem install them locally
<|jemc|>
yorickpeterse: even for the $RBX/runtime/gems?
<yorickpeterse>
Not 100% sure if we still have that hack in place where we always load the bundled versions
<brixen>
|jemc|: you can clone into runtime
dzhulk has quit [Quit: Leaving.]
<|jemc|>
my process last night was: clone rubinius to a clean directory, start rake build, interrupt it after it downloads melbourne and replace the downloaded gem, then continue with build
<|jemc|>
brixen: so yes, that sounds much easier :)
<brixen>
the setup is done with configure
<|jemc|>
do I need to RBC them somehow first, or is that unnecessary?
<brixen>
after that, you can swap things
<brixen>
the build system will build what's there
<|jemc|>
well, I was getting confused about the order of build operations and what caches I had to replace
<brixen>
configure sets up everything
<|jemc|>
there's the ./vendor/cache, the ./runtime and the ./staging
<brixen>
'rake build' builds it
<brixen>
you shouldn't configure to install if you're doing dev
<brixen>
so, there shouldn't be any staging in the mix
<brixen>
./runtime is set up by configure
<|jemc|>
brixen: when you say I shouldn't configure to install, you mean, just don't run 'rake install' right? Not any special configure options?
<brixen>
I mean, only use './configure' and then 'rake build'
<|jemc|>
yep, okay
<brixen>
if you really need to run you dev build elsewhere, use chruby
<brixen>
it's exquisitely simple :)
<|jemc|>
thanks for the breakdown
<yorickpeterse>
brixen: we still don't allow manually installed rubinius-* Gems to be used during runtime right?
<brixen>
otherwise, PATH=path/to/clone/bin:/path/to/clone/gems/bin:PATH and go
<yorickpeterse>
That is, Gems installed _after_ Rbx is built
<brixen>
there's no simple mechanism now, you'd have to build them manually so the .rbc files can be loaded
<brixen>
but all that is changing asap
<yorickpeterse>
Ah yes
<brixen>
so I can kill Ruby as a build dep
<yorickpeterse>
what isn't changing by this point :P
<brixen>
we're still stuck with Encoding :P
<brixen>
although adding a switch for a single code set at runtime :)
<yorickpeterse>
but imagine the applications of being able to use KOI-8R for Ruby
<yorickpeterse>
err KOI8-R
goyox86 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<brixen>
you can
<yorickpeterse>
brixen: other subject: metrics. Am I correct in thinking that "memory.large.objects.total" is the total amount of allocated objects, ever?
<brixen>
yes
<brixen>
it's a "total"
<brixen>
not a "current"
<yorickpeterse>
Yeah that's what I need, the total amount "ever"
<yorickpeterse>
And "gc.immix.count" is the major/mature GC right?
<brixen>
it's the immix count
goyox86 has joined #rubinius
<brixen>
the large object is also "mature"
<yorickpeterse>
Hm
<brixen>
and basically, symbols would be, too, once those are collected
<brixen>
the set of metrics we're going to emit from Rubinius::Metrics is the minimum set
<brixen>
it can't be summarized or subsetted
<yorickpeterse>
I think for NR wise the only metric we're missing is....
<yorickpeterse>
how many free heap slots we have
<yorickpeterse>
if that even applies to Rbx
<brixen>
it doesn't
<yorickpeterse>
Right, so we always reclaim/free them when we no longer need them?
<brixen>
not necessarily, immix allocates into holes
geekbri has quit []
<brixen>
but what fits in those depends on the allocation
<yorickpeterse>
euh, so we we-use whenever possible and only allocate what we need on top of that?
<yorickpeterse>
(not sure why MRI has free heap slots to begin with, seems a bit of a waste to keep them around unused)
<brixen>
mapping any of these ideas to MRI's GC is wrong
<brixen>
I can't say it any more simply
<brixen>
NR needs to just stop doing that
<yorickpeterse>
Oh that part I got, I'm curious as to why we don't have this idea of "free heap slots"
<brixen>
it's an implementation detail
|jemc| has quit [Quit: WeeChat 1.0.1]
|jemc| has joined #rubinius
mamantoha has quit [Quit: No Ping reply in 180 seconds.]
<yorickpeterse>
bbl, train
mamantoha_ has joined #rubinius
<|jemc|>
brixen: cloning into $rubinius_source_root/runtime works like a charm, thanks :)
<|jemc|>
and much less of a hassle than I was going through last night
<brixen>
|jemc|: sweet :)
<brixen>
looking at rubocop spec failures
<brixen>
"RuboCop::Formatter::BaseFormatter how the API methods are invoked #finished when RuboCop finished inspecting all files normally the passed files paths is frozen"
<brixen>
who even knows...
amsi has joined #rubinius
mamantoha_ has quit [Ping timeout: 250 seconds]
goyox86 has joined #rubinius
benlovell has joined #rubinius
benlovell has quit [Ping timeout: 240 seconds]
<headius>
yorickpeterse: MRI, like most GCed VMs, allocates memory in large chunks and then bites off pieces of that as objects are needed, rather than doing a malloc for every new object
<headius>
I believe the heap slots are the open slots in those chunks
elia has quit [Quit: Computer has gone to sleep.]
pietr0 has joined #rubinius
<cremes>
|jemc|: if you have a chance after figuring out your workflow, pls update the rubinius docs to include your steps. if you don’t want to, at least write something simple up and send it to me and i’ll add it to the docs. thanks!
<|jemc|>
seems like what is really needed here is require_relative but that would break 1.8 melbourne
<|jemc|>
does mspec do some kind of $LOAD_PATH magic that is working on travis and not working right on my machine or the machines of those others who in the linked issue?
goyox86 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<|jemc|>
I've seen that mspec has the -I option but it doesn't seem to actually affect the $LOAD_PATH
dzhulk has quit [Quit: Leaving.]
goyox86 has joined #rubinius
amsi has joined #rubinius
goyox86 has quit [Ping timeout: 250 seconds]
tenderlove has quit [Remote host closed the connection]