Re: [m5-dev] namespaces for python SimObjects
Are instances of class objects uniquely identifiable and usable as keys? Only if they provide a __hash__ function, but in theory it should be possible. If so, you could use the class as a key using the same mechanism instead of the string name with Param.blah. So then you use class Foo to look up a param description rather than actually doing something fancy with Foo itself. I don't quite follow the subtleties of what you guys are talking about so I'm not sure if that helps. The problem is that we can now do this: class Foo(SimObject): bar = Param.Bar() class Bar(SimObject): foo = Param.Foo() Because of tricks we did with attribute lookup with Param, the parameter type isn't looked up until the objects are all constructed. In your case: class Foo(SimObject): bar = Param(Bar, ) class Bar(SimObject): foo = Param(Foo, ) The bar parameter would get an error because Bar is not yet defined. It's not particularly easy to get around this. Python 3.0 and the new way they do metaclasses can help you solve the problem, but unfortunately, that's not going to be mainstream for a while. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
On Jun 13, 2008, at 11:48 AM, nathan binkert wrote: Are instances of class objects uniquely identifiable and usable as keys? Only if they provide a __hash__ function, but in theory it should be possible. If so, you could use the class as a key using the same mechanism instead of the string name with Param.blah. So then you use class Foo to look up a param description rather than actually doing something fancy with Foo itself. I don't quite follow the subtleties of what you guys are talking about so I'm not sure if that helps. The problem is that we can now do this: class Foo(SimObject): bar = Param.Bar() class Bar(SimObject): foo = Param.Foo() Because of tricks we did with attribute lookup with Param, the parameter type isn't looked up until the objects are all constructed. In your case: class Foo(SimObject): bar = Param(Bar, ) class Bar(SimObject): foo = Param(Foo, ) The bar parameter would get an error because Bar is not yet defined. It's not particularly easy to get around this. Python 3.0 and the new way they do metaclasses can help you solve the problem, but unfortunately, that's not going to be mainstream for a while Where do we have circular references? You can't construct objects with circular references in C++, so why do we need it in Python? Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
The key difference here is between circular references amongst instances and amongst classes. Circular references amongst instances does not work in the python because it creates a cycle in the object hierarchy which is why the C++ trick is necessary. If you're circular references are in the classes and you fill them with -different- instances so as not to create a cycle, then apparently that will work in python. That would be something like class A - class B - class A where the two instances of class A are different objects. Gabe nathan binkert wrote: We do have circular references in the C++ objects but they're not setup through Python. The subobjects constructor sets the back pointer. For example the Tsunami object has a pointer to each Tsunami*Chip object so when the Tsunami*Chip object is constructed it has a pointer to Tsunami and sets the back pointer there. At Tsunami::init() all the pointers are setup. Python didn't need to handle the circular references for this to work though. Correct, but we also allow this to happen in the python code now and have for quite a while. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
Any comments anybody? I have a few to add. First, as I went through the SimObject definitions and was taking out cxx_namespace, there were a few cases where the class name was still the same as type, just in a different namespace. It's slightly redundant to have to put the class name in cxx_classname instead of just the namespace in cxx_namespace. Maybe cxx_classname should be able to optionally extend cxx_namespace? For instance, cxx_namespace = Foo::Bar cxx_classname = Baz would be the same as cxx_namespace = Foo cxx_classname = Bar::Baz That might be nice if you want some sort of inheritance to put a bunch of things in the same namespace but to change their class names, or if you want to put a bunch of similarly named classes into different namespaces, using inheritance. I don't know if that would necessarily come up in a realistic scenario, but maybe it would with something like TLBs. One other thing I figured out was what type does. What it looked like is that it's what you use after Params. to get the parameter description object/class/whatever for the right simobject. I'm sure that's not news to everybody, especially those that designed it that way :P, but I thought that might be a useful thing to know for everybody else. I also discovered that the way Params works now, as a flat dictionary of types like Enums, won't let you have as much naming freedom as python modules do with import x from y as z and import x; x.y and all that. I'm guessing there may be a way to make Params search in the current scope with some sort of __dict__ magic to find what class, for instance, Params.z.y mentioned previously goes with. This might be diverging so far from how python is supposed to work that it'd be hard for people to figure out how to use it, but on the other hand I'm not sure how else to do it. Then again I don't know if the language would even allow that, so it might be a moot point. In my mind, this is the biggest sticking point in getting rid of all the bottlenecks which make you collapse down to a flat namespace at some point. Gabe Gabe Black wrote: I agree. There are three different naming mechanisms that I'm aware of we need to work with, file names for the headers, python names which go in modules, and C++ names which go in namespaces. If all names can be hierarchical, which I think they should be, then there needs to be a way to map the names into each mechanism. For python, the names can be flat but contained in modules which is I think the python paradigm. That would hopefully be fairly straightforward, but it might be complicated by the Params.xxx mechanism and/or keeping information around in single namespace sorts of structures like the dicts of Enums of different flavors. For C++, using namespaces should be fairly easy. Python objects know if they're in a namespace already, so it shouldn't be too big of a deal to prepend the class and function names appropriately to make it all work out. We'd just want to make sure everything that ends up in C++, namely enums, has a cxx_type (and/or cxx_namespace if that survives), and that that gets reflected in it's definition and in pointers and all that. I'd also want to know what -exactly- the type field is for, and why it not matching the python class name causes it to break. Obviously somebody knows this, but it was a problem I had (or seemed to have) earlier that never really got resolved. If the names have to be the same and type affects the C++ names somehow, then you might force things to be the same in some way between mechanisms which can limit you're options. For files, there are a couple options I thought of off hand. First, you could just use the file name of the containing .py for the .hh and bring all that stuff in together. There are two flaws with that that I think rule it out. First, the names of the .py files are unique, but only in the scope of the directory they're in. The .hh files are in at most two different directories, params and enums, so they're could fairly easily be collions between, for instance, TLB.pys. Those are prefixed with the ISA at the moment, but I think that's a little redundant and we might want to change that. The second problem is that that creates a slightly stricter coupling between the C++ and the python which would be nice to avoid. The second option would be to put the C++ namespace hierarchy into the header file names. That's going to be truly unique, unlike the names in python which can be made locally unique through modules. We could for instance either do that with directories a la java, which I don't particular like the aesthetics of, or something like namespace1.namespace2.class.hh. Gabe nathan binkert wrote: What about making Enums recognize cxx_namespace too? That would be pretty handy although I'm not sure how feasible. There seems to be a global list of them that would probably get confused if there was more than one with the same name,
Re: [m5-dev] namespaces for python SimObjects
On Thu, Jun 12, 2008 at 11:26 AM, Gabe Black [EMAIL PROTECTED] wrote: How about instead of Params.some_class the syntax would be Params(some_class) where Params is more like a class than a module? Then you could look up the information for the class you're dealing with without ever having to give it a globally consistent name. Seems reasonable to me... I don't remember why we went with the current syntax instead of that... Nate? Gabe Black wrote: One other thing I figured out was what type does. What it looked like is that it's what you use after Params. to get the parameter description object/class/whatever for the right simobject. I'm sure that's not news to everybody, especially those that designed it that way :P, but I thought that might be a useful thing to know for everybody else. I was wondering why we had both 'type' and 'cxx_classname'... last time I recall working on that code (before Nate finished the params auto-gen stuff), the point of 'type' was to be the C++ class name. When is the Params.Foo thing different from the Python class name, and is there a good reason for it being that way? Seems to me like we ought to be able to have a single parameter that's the C++ classname including namespaces if any. I don't think that the Python inheritance should affect the C++ classname implicitly (though that's just a gut reaction, and if there are good counterexamples I'm willing to change). The second option would be to put the C++ namespace hierarchy into the header file names. That's going to be truly unique, unlike the names in python which can be made locally unique through modules. We could for instance either do that with directories a la java, which I don't particular like the aesthetics of, or something like namespace1.namespace2.class.hh. Why don't you like the java directory hierarchy method? It makes sense to me... What about making Enums recognize cxx_namespace too? That would be pretty handy although I'm not sure how feasible. There seems to be a global list of them that would probably get confused if there was more than one with the same name, even if they were in separate modules. Sounds reasonable to me... Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
How about instead of Params.some_class the syntax would be Params(some_class) where Params is more like a class than a module? Then you could look up the information for the class you're dealing with without ever having to give it a globally consistent name. Seems reasonable to me... I don't remember why we went with the current syntax instead of that... Nate? I'm not clear what exactly you're suggesting. Do you mean like Param.String and Param.LiveProcess? I'm missing some context or something. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
I was wondering why we had both 'type' and 'cxx_classname'... last time I recall working on that code (before Nate finished the params auto-gen stuff), the point of 'type' was to be the C++ class name. When is the Params.Foo thing different from the Python class name, and is there a good reason for it being that way? I'm not sure, but type was what was being used, not the class name. If we switch it to the class name, then we can probably use type and get rid of cxx_classname. There are several things going on here. One is that the python name and the c++ name can be different. Another is that there can actually be multiple c++ classes any one of which could be generated for one python class (think cache builder). Seems to me like we ought to be able to have a single parameter that's the C++ classname including namespaces if any. I don't think that the Python inheritance should affect the C++ classname implicitly (though that's just a gut reaction, and if there are good counterexamples I'm willing to change). I agree with steve. I'd like to just see something like type = Foo::Bar::Baz and have the code do the right thing. The second option would be to put the C++ namespace hierarchy into the header file names. That's going to be truly unique, unlike the names in python which can be made locally unique through modules. We could for instance either do that with directories a la java, which I don't particular like the aesthetics of, or something like namespace1.namespace2.class.hh. Why don't you like the java directory hierarchy method? It makes sense to me... Seems like it would be better to actually create directories for the files and do namespace1/namespace2/class.hh What about making Enums recognize cxx_namespace too? That would be pretty handy although I'm not sure how feasible. There seems to be a global list of them that would probably get confused if there was more than one with the same name, even if they were in separate modules. Sounds reasonable to me... Agreed. I have a little bit of code working on cleaning this stuff up, and it's on my list. I'll get back to it probably in about a month when I whittle down my outstanding changes list. I'm motivated to fix this stuff because I think it's one of the messiest parts of the code and as I work on adding stuff to the SimObject base class (for event queues and dprintf), I'm going to want to clean up the python as well. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
On Thu, Jun 12, 2008 at 5:44 PM, nathan binkert [EMAIL PROTECTED] wrote: How about instead of Params.some_class the syntax would be Params(some_class) where Params is more like a class than a module? Then you could look up the information for the class you're dealing with without ever having to give it a globally consistent name. Seems reasonable to me... I don't remember why we went with the current syntax instead of that... Nate? I'm not clear what exactly you're suggesting. Do you mean like Param.String and Param.LiveProcess? I'm missing some context or something. I believe what Gabe is suggesting is switching e.g. Param.String(...) to Param(String, ...). This would make it trivial to support parameters that reference objects in other modules, e.g.: Param(Foo.Bar.Baz, ...) (not that it couldn't be done with the current structure, but it wouldn't be so trivial). I guess the question is whether the standard Python class name lookup works for param types... the key thing we get with Param.String is complete control over that process. OK, after actually looking at the code, it's partially coming back to me; with Param.Foo we defer the lookup of Foo until later, though I still don't recall why that was necessary... perhaps to enable circular references? Is there a way to handle circular class references in Python? Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
On Thu, Jun 12, 2008 at 5:51 PM, nathan binkert [EMAIL PROTECTED] wrote: I was wondering why we had both 'type' and 'cxx_classname'... last time I recall working on that code (before Nate finished the params auto-gen stuff), the point of 'type' was to be the C++ class name. When is the Params.Foo thing different from the Python class name, and is there a good reason for it being that way? I'm not sure, but type was what was being used, not the class name. If we switch it to the class name, then we can probably use type and get rid of cxx_classname. There are several things going on here. One is that the python name and the c++ name can be different. Another is that there can actually be multiple c++ classes any one of which could be generated for one python class (think cache builder). I'm not sure any of that fully explains why we have both attributes though. It is important to remember as in the cache builder example that the 'type' is really something that identifies the function that creates the C++ object and isn't necessarily the type of the resulting object (or even a c++ type at all)... but in those cases there is no single c++ type, so there still isn't any point in having two different attributes. Seems to me like we ought to be able to have a single parameter that's the C++ classname including namespaces if any. I don't think that the Python inheritance should affect the C++ classname implicitly (though that's just a gut reaction, and if there are good counterexamples I'm willing to change). I agree with steve. I'd like to just see something like type = Foo::Bar::Baz and have the code do the right thing. Yup. The second option would be to put the C++ namespace hierarchy into the header file names. That's going to be truly unique, unlike the names in python which can be made locally unique through modules. We could for instance either do that with directories a la java, which I don't particular like the aesthetics of, or something like namespace1.namespace2.class.hh. Why don't you like the java directory hierarchy method? It makes sense to me... Seems like it would be better to actually create directories for the files and do namespace1/namespace2/class.hh That's what I meant by java directory hierarchy method (since Gabe made that analogy). Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
I'm not sure any of that fully explains why we have both attributes though. It is important to remember as in the cache builder example that the 'type' is really something that identifies the function that creates the C++ object and isn't necessarily the type of the resulting object (or even a c++ type at all)... but in those cases there is no single c++ type, so there still isn't any point in having two different attributes. We don't need it, it was just an ugly byproduct of the evolution of this code. I needs to be cleaned up for sure. That's what I meant by java directory hierarchy method (since Gabe made that analogy). I think it's the best way if we want namespaces. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
nathan binkert wrote: I'm not sure any of that fully explains why we have both attributes though. It is important to remember as in the cache builder example that the 'type' is really something that identifies the function that creates the C++ object and isn't necessarily the type of the resulting object (or even a c++ type at all)... but in those cases there is no single c++ type, so there still isn't any point in having two different attributes. We don't need it, it was just an ugly byproduct of the evolution of this code. I needs to be cleaned up for sure. Just for the record, I looked into changing this code and it was a bit too much to craziness to deal with without spending a lot of time figuring out what's going on. I respectfully defer/pass responsibility to the experts. That's what I meant by java directory hierarchy method (since Gabe made that analogy). I think it's the best way if we want namespaces. I remember at some point hearing about, or maybe even dealing with myself, some issue where the particulars of how filenames work in the OS making this annoying but I don't remember how specifically. It might have been a Java thing, or a Gabe doesn't know Java very well thing. I don't feel too strongly about it so if that's what people want to do it's fine. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
It won't, but if you use the attached patch it seems to. Let me know if
it looks good and I'll tack it onto my queue. Also, is there a solid
reason the create functions can't end up in a namespace other than the
global one? I'm ending up with some pretty horrible names trying to make
sure everything is unique.
Gabe
nathan binkert wrote:
I do think nested namespaces will work. When you do cxx_namespace,
you'd just say one::two::three
On Mon, Jun 2, 2008 at 6:59 PM, Ali Saidi [EMAIL PROTECTED] wrote:
I think Nate will have to say if Nested namespaces will work for SimObjects.
Perhaps a namespace like x86pc or something would be good for the tables.
I'm pretty sure most of that stuff is x86 only.
Ali
On Jun 2, 2008, at 9:53 PM, Gabe Black wrote:
This stuff is standardized for PCs but it might be useful for other
platforms as well. I'm not familiar enough with this stuff to really be able
to tell for sure, but if I had to guess I'd say it's not. I was thinking of
putting it in X86ISA and then into a nested BIOS namespace.
Gabe
Ali Saidi wrote:
Take a look at how the Alpha TLB is done for how to make
SimObjects/Python happy with namespaces. The Params builder function needs
to be in the global name space.
One question is should it go in the x86 name space or in something else?
Ali
On Jun 2, 2008, at 9:32 PM, Gabe Black wrote:
I'm just starting on making the BIOSey tables and configuration
information, like the e820 map which was forcing there to be 4 gigs of
memory, available through SimObjects. There are a bunch of hierarchical
tables for, for example, the DMI information, and I'm concerned that if I
add a bunch, maybe a few dozen, new names, I'll end up either colliding
with
things that exist or making collisions more likely later on. The obvious
C++
answer to that would be a namespace, but I'm not sure the best way to do
that in this circumstance. Regularly I think the python modules idea is
supposed to take care of this, but I'm not sure how that fits with our
stuff
and some of the fancy voodoo we've got making it all work. I'm going to
try
it that way and just see how it pans out, but if anyone has any input I'd
like to hear it.
Gabe
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Params: Allow nested namespaces in cxx_namespace
diff -r 4944b77f70bd src/python/m5/SimObject.py
--- a/src/python/m5/SimObject.py Mon Jun 09 02:54:20 2008 -0400
+++ b/src/python/m5/SimObject.py Mon Jun 09 04:53:36 2008 -0400
@@ -217,7 +217,10 @@ class MetaSimObject(type):
# just declaring a pointer.
decl = 'class %s;' % _cxx_class
if namespace:
-decl = 'namespace %s { %s }' % (namespace, decl)
+namespaces = namespace.split('::')
+namespaces.reverse()
+for namespace in namespaces:
+decl = 'namespace %s { %s }' % (namespace, decl)
cls._value_dict['cxx_predecls'] = [decl]
if 'swig_predecls' not in cls._value_dict:
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
What about making Enums recognize cxx_namespace too? That would be
pretty handy although I'm not sure how feasible. There seems to be a
global list of them that would probably get confused if there was more
than one with the same name, even if they were in separate modules.
Gabe
Gabe Black wrote:
It won't, but if you use the attached patch it seems to. Let me know if
it looks good and I'll tack it onto my queue. Also, is there a solid
reason the create functions can't end up in a namespace other than the
global one? I'm ending up with some pretty horrible names trying to make
sure everything is unique.
Gabe
nathan binkert wrote:
I do think nested namespaces will work. When you do cxx_namespace,
you'd just say one::two::three
On Mon, Jun 2, 2008 at 6:59 PM, Ali Saidi [EMAIL PROTECTED] wrote:
I think Nate will have to say if Nested namespaces will work for SimObjects.
Perhaps a namespace like x86pc or something would be good for the tables.
I'm pretty sure most of that stuff is x86 only.
Ali
On Jun 2, 2008, at 9:53 PM, Gabe Black wrote:
This stuff is standardized for PCs but it might be useful for other
platforms as well. I'm not familiar enough with this stuff to really be
able
to tell for sure, but if I had to guess I'd say it's not. I was thinking of
putting it in X86ISA and then into a nested BIOS namespace.
Gabe
Ali Saidi wrote:
Take a look at how the Alpha TLB is done for how to make
SimObjects/Python happy with namespaces. The Params builder function needs
to be in the global name space.
One question is should it go in the x86 name space or in something else?
Ali
On Jun 2, 2008, at 9:32 PM, Gabe Black wrote:
I'm just starting on making the BIOSey tables and configuration
information, like the e820 map which was forcing there to be 4 gigs of
memory, available through SimObjects. There are a bunch of hierarchical
tables for, for example, the DMI information, and I'm concerned that if I
add a bunch, maybe a few dozen, new names, I'll end up either colliding
with
things that exist or making collisions more likely later on. The obvious
C++
answer to that would be a namespace, but I'm not sure the best way to do
that in this circumstance. Regularly I think the python modules idea is
supposed to take care of this, but I'm not sure how that fits with our
stuff
and some of the fancy voodoo we've got making it all work. I'm going to
try
it that way and just see how it pans out, but if anyone has any input I'd
like to hear it.
Gabe
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Params: Allow nested namespaces in cxx_namespace
diff -r 4944b77f70bd src/python/m5/SimObject.py
--- a/src/python/m5/SimObject.py Mon Jun 09 02:54:20 2008 -0400
+++ b/src/python/m5/SimObject.py Mon Jun 09 04:53:36 2008 -0400
@@ -217,7 +217,10 @@ class MetaSimObject(type):
# just declaring a pointer.
decl = 'class %s;' % _cxx_class
if namespace:
-decl = 'namespace %s { %s }' % (namespace, decl)
+namespaces = namespace.split('::')
+namespaces.reverse()
+for namespace in namespaces:
+decl = 'namespace %s { %s }' % (namespace, decl)
cls._value_dict['cxx_predecls'] = [decl]
if 'swig_predecls' not in cls._value_dict:
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
It won't, but if you use the attached patch it seems to. Let me know if it looks good and I'll tack it onto my queue. Patch looks good. Also, is there a solid reason the create functions can't end up in a namespace other than the global one? I'm ending up with some pretty horrible names trying to make sure everything is unique. I don't understand the question. I don't have a problem with namespaces if that's what you're after. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
That makes sense to me. I can do that at some point or if you'd rather that'd be fine too. Gabe nathan binkert wrote: It won't, but if you use the attached patch it seems to. Let me know if it looks good and I'll tack it onto my queue. Patch looks good. Actually, does it make sense to get rid of cxx_namespace and just make it part of cxx_type? If you're going to do a split anyway, why bother to have two variables. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
Whoever gets to it. If you don't want to do it instead of the simple patch you wrote, we can put it on the todo list. In general, that code is getting pretty messy and needs some TLC. On Mon, Jun 9, 2008 at 11:21 AM, Gabe Black [EMAIL PROTECTED] wrote: That makes sense to me. I can do that at some point or if you'd rather that'd be fine too. Gabe nathan binkert wrote: It won't, but if you use the attached patch it seems to. Let me know if it looks good and I'll tack it onto my queue. Patch looks good. Actually, does it make sense to get rid of cxx_namespace and just make it part of cxx_type? If you're going to do a split anyway, why bother to have two variables. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
