scons: *** [build/ALPHA_SE/params/params_wrap.fo] Error 1
scons: *** [build/ALPHA_SE/python/swig/core_wrap.fo] Error 1
scons: *** [build/ALPHA_SE/python/swig/event_wrap.fo] Error 1
scons: *** [build/ALPHA_SE/python/swig/random_wrap.fo] Error 1
scons: *** [build/ALPHA_SE/python/swig/trace_wrap.fo]
Thanks everyone for the comments. I won't be able to check in my patch(es)
today, but will work on it more next week and try to commit them in a week or
two.
First to answer Nate:
- In hindsight, one may see the items in this patch as unrelated, but I
initially created this patch with the
Quoting Beckmann, Brad brad.beckm...@amd.com:
Thanks everyone for the comments. I won't be able to check in my
patch(es) today, but will work on it more next week and try to
commit them in a week or two.
First to answer Nate:
- In hindsight, one may see the items in this patch as
- In hindsight, one may see the items in this patch as unrelated, but I
initially created this patch with the sole goal of adding large memory
support to Ruby. It turned out I encountered a lot of issues throughout the
code, and there are more to come. That being said, I have no problem
- In hindsight, one may see the items in this patch as unrelated,
but I initially created this patch with the sole goal of adding
large memory support to Ruby. It turned out I encountered a lot of
issues throughout the code, and there are more to come. That being
said, I have no problem
Darn...I was hoping -X would work. So by manually creating multiple patches,
you mean qnew a few almost empty patches and then cut-and-paste the one patch
into those new patch files, right?
It may be just me, but I have a hard time determining in real time when a
modification requires a new
On Fri, Sep 18, 2009 at 12:25 PM, Beckmann, Brad brad.beckm...@amd.com wrote:
Darn...I was hoping -X would work. So by manually creating multiple patches,
you mean qnew a few almost empty patches and then cut-and-paste the one patch
into those new patch files, right?
Or alternatively you
Darn...I was hoping -X would work. So by manually creating multiple
patches, you mean qnew a few almost empty patches and then cut-and-paste the
one patch into those new patch files, right?
Or alternatively you can just create the new patch files and import
them with 'hg qimport -e'.
I
To clarify Nate's statement (since it confused me at first): 'hg qdel
-r' (which appears to be aliased to the much more logically named 'hg
qfinish' in recent versions)
huh, didn't know about qfinish.
When you've already got a big monolithic patch like Brad does and want
to split it up, then
On Fri, 18 Sep 2009 11:52:14 -0700, nathan binkert n...@binkert.org
wrote:
- In hindsight, one may see the items in this patch as unrelated,
but I initially created this patch with the sole goal of adding
large memory support to Ruby. It turned out I encountered a lot of
issues throughout
On Fri, Sep 18, 2009 at 12:38 PM, nathan binkert n...@binkert.org wrote:
I generally start with much smaller
patches now that I'm used to it, but I often have many patches
qpushed, fix many bugs create a patch on top called progress and
then pull the bits out of progress and put them into the
The record/crecord extension might be useful to handle some of this.
crecord looks very cool. Have you used it?
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Yes... 'hg qfold' makes it trivial to combine smaller patches into
larger ones, so it's better to err on the small side.
The one thing about qfold is that is very crudely just sticks the
commit messages from the two patches together, so make sure you fix
it.
Nate
i tried it once or twice, but I haven't been managing lots of code
recently.
Ali
On Sep 18, 2009, at 5:45 PM, nathan binkert wrote:
The record/crecord extension might be useful to handle some of this.
crecord looks very cool. Have you used it?
Nate
14 matches
Mail list logo
