>> Ignore the ship it tag above. I was testing what happens if I check the
>> box provided. Is it a vote in favor of the patch?
Yes.
One other thing. Can you make your future comments inline in the
patch if they are about specific things? It's not always obvious
otherwise.
Thanks,
Nate
> On 2010-06-07 20:11:13, Nilay Vaish wrote:
> > 1. Should we use resize() or should we use reserve() for setting the
> > capacity of a vector? Especially during initialization, reserve() might be
> > faster since it does not initialize the allocated memory where as resize()
> > carries out so
> On 2010-06-07 20:11:13, Nilay Vaish wrote:
> > 1. Should we use resize() or should we use reserve() for setting the
> > capacity of a vector? Especially during initialization, reserve() might be
> > faster since it does not initialize the allocated memory where as resize()
> > carries out so
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/22/#review38
---
Ship it!
1. Should we use resize() or should we use reserve() for setting t
This shouldn't change the nightly regressions at all, since those are
built with RUBY=True globally. If you build with RUBY=False, then you
didn't get an MI_example build before and you still won't get one now,
but at least the builds named ALPHA_SE_ will actually
use Ruby and the named protocol r
I think one problem with this commit is that now we don't build an
MI_example. Does this break any existing regressions?
Nate
On Mon, Jun 7, 2010 at 4:16 PM, Steve Reinhardt wrote:
> changeset 2302e04c506e in /z/repo/m5
> details: http://repo.m5sim.org/m5?cmd=changeset;node=2302e04c506e
> des
changeset 2302e04c506e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=2302e04c506e
description:
scons: make RUBY a regular (non-global) sticky var
and force it to True for builds that imply Ruby protocols
(else unexpected things happen when testing these
> Isn't that fundamentally impossible, in that if you get rid of
> sticky_vars completely then there's no way to have distinct builds?
> In other words, what would distinguish ALPHA_FS from ARM_SE w/o
> sticky_vars? Not complaining, just confused...
I just want to limit the exact set of things th
On Mon, Jun 7, 2010 at 8:24 AM, nathan binkert wrote:
> Only that I'm eventually trying to get rid of the whole sticky_vars
> thing and get to what is in effect global_sticky_vars.
Isn't that fundamentally impossible, in that if you get rid of
sticky_vars completely then there's no way to have di
> Is there any particular reason that RUBY is a global build option, and
> not a per-build one? (That is, I can't build MIPS_SE w/o Ruby and
> then build ALPHA_SE or even ALPHA_SE_MOESI_hammer with Ruby in the
> same build directory.) Nate, you're the one that added RUBY to
> global_sticky_vars a
* build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby
passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic
passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello
11 matches
Mail list logo
