Any idea what finally had to be re-built? This is another issue i've seen before, although I've never tracked it down to what dependency we're not capturing that we should be.
Ali On Nov 13, 2011, at 3:28 AM, Gabe Black wrote: > Apparently it was just some stale swig files. I've had problems with > that sort of thing before and thought I had already tried deleting what > are usually the problem, but I guess I didn't do that successfully. > > Gabe > > On 11/08/11 11:54, Steve Reinhardt wrote: >> Well, to start with a disclaimer, this is code that Nate wrote four years >> ago, so my interpretation may not be definitive... >> >> I don't see how this is directly related to providing an empty list as a >> default, which I think should work. (Note that you should *not* change the >> value of the param by appending to that empty list though; you should >> reassign the param with a different non-empty list. I hope we can find a >> long-term solution that didn't involve a default empty list just to >> discourage that behavior.) >> >> The particular issue seems at least superficially related to swig... >> basically what's going on here is that we're copying values from the python >> SimObject params list to the swig-wrapped C++ params struct. The C++ >> params struct should have a vector param represented as a std::vector<foo>, >> which swig should in turn wrap as a python list. I believe the assertion >> here is just checking that after we create an empty initial copy of the C++ >> params list, the vector is empty before we start adding elements to it, and >> python is complaining that it can't call len() because it's not even a >> vector. So something is going wrong in the vicinity of swig (either a bug >> in swig itself, or in what we're feeding it). >> >> Hope that's enough to help you trace it further... >> >> Steve >> >> On Mon, Nov 7, 2011 at 2:40 AM, Gabe Black <[email protected]> wrote: >> >>> Hey folks. I'm making progress on gluing SE and FS modes together (a >>> smoother integration will come later) and I've cornered the last >>> instances of FULL_SYSTEM to the cpu directory. I'm having some trouble >>> getting rid of the FULL_SYSTEM which guards the workload parameter. I'd >>> like to turn on the parameter in FS but set it to something inert like >>> []. When I tried that, though, I got the following error. I have no idea >>> what it's talking about, but it doesn't necessarily look like it's the >>> [] itself that's the problem. Maybe setting defaults on VectorParams >>> doesn't work? >>> >>> Gabe >>> >>> >>> >>> warn: Sockets disabled, not accepting vnc client connections >>> warn: Sockets disabled, not accepting terminal connections >>> Traceback (most recent call last): >>> File "<string>", line 1, in <module> >>> File "/home/gblack/m5/repos/gem5.sefs/src/python/m5/main.py", line >>> 356, in main >>> exec filecode in scope >>> File "tests/run.py", line 81, in <module> >>> m5.instantiate() >>> File "/home/gblack/m5/repos/gem5.sefs/src/python/m5/simulate.py", line >>> 78, in instantiate >>> for obj in root.descendants(): obj.createCCObject() >>> File "/home/gblack/m5/repos/gem5.sefs/src/python/m5/SimObject.py", >>> line 881, in createCCObject >>> self.getCCParams() >>> File "/home/gblack/m5/repos/gem5.sefs/src/python/m5/SimObject.py", >>> line 840, in getCCParams >>> assert not len(vec) >>> TypeError: object of type 'SwigPyObject' has no len() >>> _______________________________________________ >>> gem5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/gem5-dev >>> >> _______________________________________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/gem5-dev > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
