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
>>>>> [email protected]
>>>>> http://m5sim.org/mailman/listinfo/m5-dev
>>>>>
>>>> _______________________________________________
>>>> m5-dev mailing list
>>>> [email protected]
>>>> http://m5sim.org/mailman/listinfo/m5-dev
>>> _______________________________________________
>>> m5-dev mailing list
>>> [email protected]
>>> http://m5sim.org/mailman/listinfo/m5-dev
>>>
>> _______________________________________________
>> m5-dev mailing list
>> [email protected]
>> http://m5sim.org/mailman/listinfo/m5-dev
>>
>>
> _______________________________________________
> m5-dev mailing list
> [email protected]
> 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
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
