[gem5-dev] Re: gem5 namespace
ewhere: > test::var = 2; // Does not show deprecation warning > Test::var = 2; // Shows deprecation warning > > > Cheers, > > Daniel > Em quarta-feira, 5 de maio de 2021 23:28:31 BRT, Gabe Black via gem5-dev < > gem5-dev@gem5.org> escreveu: > > > Yeah, we don't have a ton of namespaces already, but having two copies of > all of them for a while might be messy. I also don't think you can really > mark a namespace as deprecated without even more macro trickery. > > Using snake case for the namespaces would be a change to acclimate to and > I'm not *excited* to make a big change like that, especially to something > I'm so used to, but importantly it would maintain consistency which is > arguably more important. It would bring us in line with namespaces like > "std" too, which, given how common it is, wouldn't be the worst thing. > > We would have to be careful that short, simple namespace names like > "loader" don't conflict with existing local variable names. Given the > potential for problems there and that we only have a handful of namespaces > currently, it might make sense to convert each namespace one by one, which > might make it easier to deal with fallout. > > Gabe > > On Wed, May 5, 2021 at 6:45 AM Giacomo Travaglini via gem5-dev < > gem5-dev@gem5.org> wrote: > > Hi all, > > I agree with Daniel's analysis and solution, as enforcing snake_case for > namespaces would probably make everyone happy. > We could in theory adopt namespace aliases for backward compatibility, to > transition smoothly from one "convention" (PascalCase for namespaces is not > mentioned in our coding style) to the other, but I think it will complicate > things even further. > > Kind Regards > > Giacomo > > > -Original Message- > > From: Jason Lowe-Power via gem5-dev > > Sent: 03 May 2021 21:27 > > To: gem5 Developer List > > Cc: Jason Lowe-Power > > Subject: [gem5-dev] Re: gem5 namespace > > > > Hey Daniel, > > > > Sorry, I didn't mean to add to the confusion :). I may have gotten my > case > > names confused! Also, I really appreciate the thoughtfulness and effort > > you're putting into this conversation! I believe I agree with your email > below. > > > > > > I think that most people don't care that much (which is why we haven't > heard > > from many). From my experience, our users only care when they get merge > > conflicts :D. That said, I'm not sure if "straightforward" is a way most > of our > > users ever feel about merge conflicts. IMO, stability and ease of update > > should be high priority. If we are going to be changing names, etc. in a > way > > that means external users of gem5 will have compiler errors, we should > > probably provide backwards compatibility and warnings. Most of our users > > are not software engineers and do not have as much experience with git, > > compilers, etc. as we do. > > > > > > Cheers, > > Jason > > > > > > On Mon, May 3, 2021 at 12:40 PM Daniel Carvalho via gem5-dev > d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote: > > > > > > I'm confused, Jason. I thought you were in favor of adopting snake > > case as a "general convention" (i.e., "the google way"), so by adopting > snake > > case we would be adopting the "general convention", not forging our own > > path. However, if by "general convention" you mean "the convention vastly > > adopted by gem5", I don't have the exact numbers, but I'd guess it is 70% > > pascal, 30% snake case - i.e., IMHO, not a "general convention", just a > > preference. Adding "gem5" or "Gem5" would only extend this mess, not add > > an exception. > > > > Regarding changing the name of the variable, indeed, it is not a > > necessary step. > > > > Again, as stated before, I don't care which solution is taken. The > > important thing is to come to a decision that appeases most community > > members; however, it is hard to reach a consensus when we seem to have > > strong opinions on both sides, yet we only have 5 votes. That is why I > have > > suggested officially adopting snake case namespaces: it would solve the > > "gem5 VS Gem5" problem, it is feasible to do it without having > exceptions (at > > least as of now), Giacomo expressed preference towards lowercase > > namespaces, Jason suggested affinity with the google approach (snake > case) > > and "gem5", Bobby prefers "gem5",
[gem5-dev] Re: gem5 namespace
how common it is, wouldn't be the worst thing. We would have to be careful that short, simple namespace names like "loader" don't conflict with existing local variable names. Given the potential for problems there and that we only have a handful of namespaces currently, it might make sense to convert each namespace one by one, which might make it easier to deal with fallout. Gabe On Wed, May 5, 2021 at 6:45 AM Giacomo Travaglini via gem5-dev wrote: Hi all, I agree with Daniel's analysis and solution, as enforcing snake_case for namespaces would probably make everyone happy. We could in theory adopt namespace aliases for backward compatibility, to transition smoothly from one "convention" (PascalCase for namespaces is not mentioned in our coding style) to the other, but I think it will complicate things even further. Kind Regards Giacomo > -Original Message- > From: Jason Lowe-Power via gem5-dev > Sent: 03 May 2021 21:27 > To: gem5 Developer List > Cc: Jason Lowe-Power > Subject: [gem5-dev] Re: gem5 namespace > > Hey Daniel, > > Sorry, I didn't mean to add to the confusion :). I may have gotten my case > names confused! Also, I really appreciate the thoughtfulness and effort > you're putting into this conversation! I believe I agree with your email > below. > > > I think that most people don't care that much (which is why we haven't heard > from many). From my experience, our users only care when they get merge > conflicts :D. That said, I'm not sure if "straightforward" is a way most of > our > users ever feel about merge conflicts. IMO, stability and ease of update > should be high priority. If we are going to be changing names, etc. in a way > that means external users of gem5 will have compiler errors, we should > probably provide backwards compatibility and warnings. Most of our users > are not software engineers and do not have as much experience with git, > compilers, etc. as we do. > > > Cheers, > Jason > > > On Mon, May 3, 2021 at 12:40 PM Daniel Carvalho via gem5-dev d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote: > > > I'm confused, Jason. I thought you were in favor of adopting snake > case as a "general convention" (i.e., "the google way"), so by adopting snake > case we would be adopting the "general convention", not forging our own > path. However, if by "general convention" you mean "the convention vastly > adopted by gem5", I don't have the exact numbers, but I'd guess it is 70% > pascal, 30% snake case - i.e., IMHO, not a "general convention", just a > preference. Adding "gem5" or "Gem5" would only extend this mess, not add > an exception. > > Regarding changing the name of the variable, indeed, it is not a > necessary step. > > Again, as stated before, I don't care which solution is taken. The > important thing is to come to a decision that appeases most community > members; however, it is hard to reach a consensus when we seem to have > strong opinions on both sides, yet we only have 5 votes. That is why I have > suggested officially adopting snake case namespaces: it would solve the > "gem5 VS Gem5" problem, it is feasible to do it without having exceptions (at > least as of now), Giacomo expressed preference towards lowercase > namespaces, Jason suggested affinity with the google approach (snake case) > and "gem5", Bobby prefers "gem5", and Gabe and I like consistency/patterns. > The (huge) downside to this solution is that it would affect users, but 1) > we'd > already be affecting users anyway with the new namespace, and 2) solving > the merge conflicts would be straightforward if the patches were created > with that in mind. > > > Regards, > Daniel > > Em segunda-feira, 3 de maio de 2021 15:44:46 BRT, Jason Lowe- > Power mailto:ja...@lowepower.com> > > escreveu: > > > Just a few quick replies below. Overall, I think we're being too > focused on "standards" and not on enough on ease of use. It's not a problem > if there are exceptions to guidance, if there's good reasons for the > exceptions. > > > On Mon, May 3, 2021 at 11:36 AM Daniel Carvalho via gem5-dev > mailto:gem5-dev@gem5.org> > wrote: > > > As mentioned by Gabe in the Jira issue, some of the > namespaces using snake declared in the codebase case are defined as parts > of a standard, and thus cannot be modified. Realistically, this means that if > we wanted to follow a namespace naming convention, it'd be snake case: > despite having way more occurrences of pascal case namespaces, they are all > "
[gem5-dev] Re: gem5 namespace
Be warned though, that there are some pitfalls with this namespace
deprecation approach. The namespaces here are not actually equivalent, and
so the old deprecated namespace can have things added to it that won't show
up in the new one. This is probably not that big a deal in practice, and
should be pretty useful letting people know what's going on, but it's still
important to be aware of limitations.
Gabe
On Thu, May 6, 2021 at 7:36 AM Jason Lowe-Power via gem5-dev <
gem5-dev@gem5.org> wrote:
> Thanks for putting this all together, Daniel!
>
> IMO, we should do our best with providing deprecation notices, but not
> bend over backwards. For things that are easy to add deprecations to (e.g.,
> function names / class names) we should do it, and for things that have a
> big impact on our users we should provide the warnings. However, if it's
> very difficult to provide the notice *and* if it's for something that is
> unlikely to affect users, then the deprecation warnings are less important.
>
> Example: if we change `panic` to `gem5_panic` (or `GEM5_PANIC`?) we
> definitely need a deprecation warning. This will significantly impact
> users. If, on the other hand, we change a macro that is used in exactly one
> place, it's probably less important
>
> Thanks for coming up with a way to do namespaces! This will be useful.
>
> Cheers,
> Jason
>
> On Thu, May 6, 2021 at 7:06 AM Daniel Carvalho via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Glad to see that we are reaching a consensus! Then we will create the
>> "gem5" namespace, rename (most) macros to use a "GEM5_" prefix, and will
>> rename all namespaces to snake case.
>>
>>
>> I agree that we should do the renaming on a case-by-case basis. I've
>> created a new Jira Epic to cover converting all namespaces to snake case:
>> https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-974
>> .
>>
>>
>> Regarding deprecating namespaces, aliases cannot be assigned attributes
>> (thus they cannot be marked as deprecated), but I believe this will do the
>> trick:
>>
>>
>> #define GEM5_DEPRECATE_NAMESPACE(old_namespace, new_namespace) \
>> namespace [[gnu::deprecated("Please use the new namespace: '" \
>> #new_namespace "'")]] old_namespace { \
>> using namespace new_namespace; \
>> }
>>
>>
>> Example:
>>
>>
>> // Suppose we want to rename a namespace from Test to test
>> namespace test {
>> int var;
>> }
>> // This can be added to the base file (i.e., the one we know
>> everybody will include)
>> GEM5_DEPRECATE_NAMESPACE(Test, test)
>>
>> ...
>>
>> // In code, somewhere:
>> test::var = 2; // Does not show deprecation warning
>> Test::var = 2; // Shows deprecation warning
>>
>>
>> Cheers,
>>
>> Daniel
>> Em quarta-feira, 5 de maio de 2021 23:28:31 BRT, Gabe Black via gem5-dev <
>> gem5-dev@gem5.org> escreveu:
>>
>>
>> Yeah, we don't have a ton of namespaces already, but having two copies of
>> all of them for a while might be messy. I also don't think you can really
>> mark a namespace as deprecated without even more macro trickery.
>>
>> Using snake case for the namespaces would be a change to acclimate to and
>> I'm not *excited* to make a big change like that, especially to something
>> I'm so used to, but importantly it would maintain consistency which is
>> arguably more important. It would bring us in line with namespaces like
>> "std" too, which, given how common it is, wouldn't be the worst thing.
>>
>> We would have to be careful that short, simple namespace names like
>> "loader" don't conflict with existing local variable names. Given the
>> potential for problems there and that we only have a handful of namespaces
>> currently, it might make sense to convert each namespace one by one, which
>> might make it easier to deal with fallout.
>>
>> Gabe
>>
>> On Wed, May 5, 2021 at 6:45 AM Giacomo Travaglini via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>> Hi all,
>>
>> I agree with Daniel's analysis and solution, as enforcing snake_case for
>> namespaces would probably make everyone happy.
>> We could in theory adopt namespace aliases for backward compatibility, to
>> transition smoothly from one "convention" (PascalCase for namespaces is not
>> mentioned in our coding style) to the other, but I think it will complicate
>> things even further.
&g
[gem5-dev] Re: gem5 namespace
Thanks for putting this all together, Daniel!
IMO, we should do our best with providing deprecation notices, but not bend
over backwards. For things that are easy to add deprecations to (e.g.,
function names / class names) we should do it, and for things that have a
big impact on our users we should provide the warnings. However, if it's
very difficult to provide the notice *and* if it's for something that is
unlikely to affect users, then the deprecation warnings are less important.
Example: if we change `panic` to `gem5_panic` (or `GEM5_PANIC`?) we
definitely need a deprecation warning. This will significantly impact
users. If, on the other hand, we change a macro that is used in exactly one
place, it's probably less important
Thanks for coming up with a way to do namespaces! This will be useful.
Cheers,
Jason
On Thu, May 6, 2021 at 7:06 AM Daniel Carvalho via gem5-dev <
gem5-dev@gem5.org> wrote:
> Glad to see that we are reaching a consensus! Then we will create the
> "gem5" namespace, rename (most) macros to use a "GEM5_" prefix, and will
> rename all namespaces to snake case.
>
>
> I agree that we should do the renaming on a case-by-case basis. I've
> created a new Jira Epic to cover converting all namespaces to snake case:
> https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-974 .
>
>
> Regarding deprecating namespaces, aliases cannot be assigned attributes
> (thus they cannot be marked as deprecated), but I believe this will do the
> trick:
>
>
> #define GEM5_DEPRECATE_NAMESPACE(old_namespace, new_namespace) \
> namespace [[gnu::deprecated("Please use the new namespace: '" \
> #new_namespace "'")]] old_namespace { \
> using namespace new_namespace; \
> }
>
>
> Example:
>
>
> // Suppose we want to rename a namespace from Test to test
> namespace test {
> int var;
> }
> // This can be added to the base file (i.e., the one we know everybody
> will include)
> GEM5_DEPRECATE_NAMESPACE(Test, test)
>
> ...
>
> // In code, somewhere:
> test::var = 2; // Does not show deprecation warning
> Test::var = 2; // Shows deprecation warning
>
>
> Cheers,
>
> Daniel
> Em quarta-feira, 5 de maio de 2021 23:28:31 BRT, Gabe Black via gem5-dev <
> gem5-dev@gem5.org> escreveu:
>
>
> Yeah, we don't have a ton of namespaces already, but having two copies of
> all of them for a while might be messy. I also don't think you can really
> mark a namespace as deprecated without even more macro trickery.
>
> Using snake case for the namespaces would be a change to acclimate to and
> I'm not *excited* to make a big change like that, especially to something
> I'm so used to, but importantly it would maintain consistency which is
> arguably more important. It would bring us in line with namespaces like
> "std" too, which, given how common it is, wouldn't be the worst thing.
>
> We would have to be careful that short, simple namespace names like
> "loader" don't conflict with existing local variable names. Given the
> potential for problems there and that we only have a handful of namespaces
> currently, it might make sense to convert each namespace one by one, which
> might make it easier to deal with fallout.
>
> Gabe
>
> On Wed, May 5, 2021 at 6:45 AM Giacomo Travaglini via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> Hi all,
>
> I agree with Daniel's analysis and solution, as enforcing snake_case for
> namespaces would probably make everyone happy.
> We could in theory adopt namespace aliases for backward compatibility, to
> transition smoothly from one "convention" (PascalCase for namespaces is not
> mentioned in our coding style) to the other, but I think it will complicate
> things even further.
>
> Kind Regards
>
> Giacomo
>
> > -Original Message-
> > From: Jason Lowe-Power via gem5-dev
> > Sent: 03 May 2021 21:27
> > To: gem5 Developer List
> > Cc: Jason Lowe-Power
> > Subject: [gem5-dev] Re: gem5 namespace
> >
> > Hey Daniel,
> >
> > Sorry, I didn't mean to add to the confusion :). I may have gotten my
> case
> > names confused! Also, I really appreciate the thoughtfulness and effort
> > you're putting into this conversation! I believe I agree with your email
> below.
> >
> >
> > I think that most people don't care that much (which is why we haven't
> heard
> > from many). From my experience, our users only care when they get merge
> > conflicts :D. That said, I'm not sure if "straightforward" is a way most
> of our
> > users ever feel about merge confl
[gem5-dev] Re: gem5 namespace
Glad to see that we are reaching a consensus! Then we will create the "gem5"
namespace, rename (most) macros to use a "GEM5_" prefix, and will rename all
namespaces to snake case.
I agree that we should do the renaming on a case-by-case basis. I've created a
new Jira Epic to cover converting all namespaces to snake case:
https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-974 .
Regarding deprecating namespaces, aliases cannot be assigned attributes (thus
they cannot be marked as deprecated), but I believe this will do the trick:
#define GEM5_DEPRECATE_NAMESPACE(old_namespace, new_namespace) \
namespace [[gnu::deprecated("Please use the new namespace: '" \
#new_namespace "'")]] old_namespace { \
using namespace new_namespace; \
}
Example:
// Suppose we want to rename a namespace from Test to test
namespace test { int var;
} // This can be added to the base file (i.e., the one we know everybody
will include)
GEM5_DEPRECATE_NAMESPACE(Test, test)
...
// In code, somewhere: test::var = 2; // Does not show deprecation
warning
Test::var = 2; // Shows deprecation warning
Cheers,
Daniel
Em quarta-feira, 5 de maio de 2021 23:28:31 BRT, Gabe Black via gem5-dev
escreveu:
Yeah, we don't have a ton of namespaces already, but having two copies of all
of them for a while might be messy. I also don't think you can really mark a
namespace as deprecated without even more macro trickery.
Using snake case for the namespaces would be a change to acclimate to and I'm
not *excited* to make a big change like that, especially to something I'm so
used to, but importantly it would maintain consistency which is arguably more
important. It would bring us in line with namespaces like "std" too, which,
given how common it is, wouldn't be the worst thing.
We would have to be careful that short, simple namespace names like "loader"
don't conflict with existing local variable names. Given the potential for
problems there and that we only have a handful of namespaces currently, it
might make sense to convert each namespace one by one, which might make it
easier to deal with fallout.
Gabe
On Wed, May 5, 2021 at 6:45 AM Giacomo Travaglini via gem5-dev
wrote:
Hi all,
I agree with Daniel's analysis and solution, as enforcing snake_case for
namespaces would probably make everyone happy.
We could in theory adopt namespace aliases for backward compatibility, to
transition smoothly from one "convention" (PascalCase for namespaces is not
mentioned in our coding style) to the other, but I think it will complicate
things even further.
Kind Regards
Giacomo
> -Original Message-
> From: Jason Lowe-Power via gem5-dev
> Sent: 03 May 2021 21:27
> To: gem5 Developer List
> Cc: Jason Lowe-Power
> Subject: [gem5-dev] Re: gem5 namespace
>
> Hey Daniel,
>
> Sorry, I didn't mean to add to the confusion :). I may have gotten my case
> names confused! Also, I really appreciate the thoughtfulness and effort
> you're putting into this conversation! I believe I agree with your email
> below.
>
>
> I think that most people don't care that much (which is why we haven't heard
> from many). From my experience, our users only care when they get merge
> conflicts :D. That said, I'm not sure if "straightforward" is a way most of
> our
> users ever feel about merge conflicts. IMO, stability and ease of update
> should be high priority. If we are going to be changing names, etc. in a way
> that means external users of gem5 will have compiler errors, we should
> probably provide backwards compatibility and warnings. Most of our users
> are not software engineers and do not have as much experience with git,
> compilers, etc. as we do.
>
>
> Cheers,
> Jason
>
>
> On Mon, May 3, 2021 at 12:40 PM Daniel Carvalho via gem5-dev d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote:
>
>
> I'm confused, Jason. I thought you were in favor of adopting snake
> case as a "general convention" (i.e., "the google way"), so by adopting snake
> case we would be adopting the "general convention", not forging our own
> path. However, if by "general convention" you mean "the convention vastly
> adopted by gem5", I don't have the exact numbers, but I'd guess it is 70%
> pascal, 30% snake case - i.e., IMHO, not a "general convention", just a
> preference. Adding "gem5" or "Gem5" would only extend this mess, not add
> an exception.
>
> Regarding changing the name of the variable, indeed, it is not a
> necessary step.
>
> Again, as stated before, I don't care which solution is taken. The
> important thing is to come t
[gem5-dev] Re: gem5 namespace
Yeah, we don't have a ton of namespaces already, but having two copies of all of them for a while might be messy. I also don't think you can really mark a namespace as deprecated without even more macro trickery. Using snake case for the namespaces would be a change to acclimate to and I'm not *excited* to make a big change like that, especially to something I'm so used to, but importantly it would maintain consistency which is arguably more important. It would bring us in line with namespaces like "std" too, which, given how common it is, wouldn't be the worst thing. We would have to be careful that short, simple namespace names like "loader" don't conflict with existing local variable names. Given the potential for problems there and that we only have a handful of namespaces currently, it might make sense to convert each namespace one by one, which might make it easier to deal with fallout. Gabe On Wed, May 5, 2021 at 6:45 AM Giacomo Travaglini via gem5-dev < gem5-dev@gem5.org> wrote: > Hi all, > > I agree with Daniel's analysis and solution, as enforcing snake_case for > namespaces would probably make everyone happy. > We could in theory adopt namespace aliases for backward compatibility, to > transition smoothly from one "convention" (PascalCase for namespaces is not > mentioned in our coding style) to the other, but I think it will complicate > things even further. > > Kind Regards > > Giacomo > > > -Original Message- > > From: Jason Lowe-Power via gem5-dev > > Sent: 03 May 2021 21:27 > > To: gem5 Developer List > > Cc: Jason Lowe-Power > > Subject: [gem5-dev] Re: gem5 namespace > > > > Hey Daniel, > > > > Sorry, I didn't mean to add to the confusion :). I may have gotten my > case > > names confused! Also, I really appreciate the thoughtfulness and effort > > you're putting into this conversation! I believe I agree with your email > below. > > > > > > I think that most people don't care that much (which is why we haven't > heard > > from many). From my experience, our users only care when they get merge > > conflicts :D. That said, I'm not sure if "straightforward" is a way most > of our > > users ever feel about merge conflicts. IMO, stability and ease of update > > should be high priority. If we are going to be changing names, etc. in a > way > > that means external users of gem5 will have compiler errors, we should > > probably provide backwards compatibility and warnings. Most of our users > > are not software engineers and do not have as much experience with git, > > compilers, etc. as we do. > > > > > > Cheers, > > Jason > > > > > > On Mon, May 3, 2021 at 12:40 PM Daniel Carvalho via gem5-dev > d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote: > > > > > > I'm confused, Jason. I thought you were in favor of adopting snake > > case as a "general convention" (i.e., "the google way"), so by adopting > snake > > case we would be adopting the "general convention", not forging our own > > path. However, if by "general convention" you mean "the convention vastly > > adopted by gem5", I don't have the exact numbers, but I'd guess it is 70% > > pascal, 30% snake case - i.e., IMHO, not a "general convention", just a > > preference. Adding "gem5" or "Gem5" would only extend this mess, not add > > an exception. > > > > Regarding changing the name of the variable, indeed, it is not a > > necessary step. > > > > Again, as stated before, I don't care which solution is taken. The > > important thing is to come to a decision that appeases most community > > members; however, it is hard to reach a consensus when we seem to have > > strong opinions on both sides, yet we only have 5 votes. That is why I > have > > suggested officially adopting snake case namespaces: it would solve the > > "gem5 VS Gem5" problem, it is feasible to do it without having > exceptions (at > > least as of now), Giacomo expressed preference towards lowercase > > namespaces, Jason suggested affinity with the google approach (snake > case) > > and "gem5", Bobby prefers "gem5", and Gabe and I like > consistency/patterns. > > The (huge) downside to this solution is that it would affect users, but > 1) we'd > > already be affecting users anyway with the new namespace, and 2) solving > > the merge conflicts would be straightforward if the patches were created > > with that in mind. > > > > > > Regards, > >
[gem5-dev] Re: gem5 namespace
Hi all, I agree with Daniel's analysis and solution, as enforcing snake_case for namespaces would probably make everyone happy. We could in theory adopt namespace aliases for backward compatibility, to transition smoothly from one "convention" (PascalCase for namespaces is not mentioned in our coding style) to the other, but I think it will complicate things even further. Kind Regards Giacomo > -Original Message- > From: Jason Lowe-Power via gem5-dev > Sent: 03 May 2021 21:27 > To: gem5 Developer List > Cc: Jason Lowe-Power > Subject: [gem5-dev] Re: gem5 namespace > > Hey Daniel, > > Sorry, I didn't mean to add to the confusion :). I may have gotten my case > names confused! Also, I really appreciate the thoughtfulness and effort > you're putting into this conversation! I believe I agree with your email > below. > > > I think that most people don't care that much (which is why we haven't heard > from many). From my experience, our users only care when they get merge > conflicts :D. That said, I'm not sure if "straightforward" is a way most of > our > users ever feel about merge conflicts. IMO, stability and ease of update > should be high priority. If we are going to be changing names, etc. in a way > that means external users of gem5 will have compiler errors, we should > probably provide backwards compatibility and warnings. Most of our users > are not software engineers and do not have as much experience with git, > compilers, etc. as we do. > > > Cheers, > Jason > > > On Mon, May 3, 2021 at 12:40 PM Daniel Carvalho via gem5-dev d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote: > > > I'm confused, Jason. I thought you were in favor of adopting snake > case as a "general convention" (i.e., "the google way"), so by adopting snake > case we would be adopting the "general convention", not forging our own > path. However, if by "general convention" you mean "the convention vastly > adopted by gem5", I don't have the exact numbers, but I'd guess it is 70% > pascal, 30% snake case - i.e., IMHO, not a "general convention", just a > preference. Adding "gem5" or "Gem5" would only extend this mess, not add > an exception. > > Regarding changing the name of the variable, indeed, it is not a > necessary step. > > Again, as stated before, I don't care which solution is taken. The > important thing is to come to a decision that appeases most community > members; however, it is hard to reach a consensus when we seem to have > strong opinions on both sides, yet we only have 5 votes. That is why I have > suggested officially adopting snake case namespaces: it would solve the > "gem5 VS Gem5" problem, it is feasible to do it without having exceptions (at > least as of now), Giacomo expressed preference towards lowercase > namespaces, Jason suggested affinity with the google approach (snake case) > and "gem5", Bobby prefers "gem5", and Gabe and I like consistency/patterns. > The (huge) downside to this solution is that it would affect users, but 1) > we'd > already be affecting users anyway with the new namespace, and 2) solving > the merge conflicts would be straightforward if the patches were created > with that in mind. > > > Regards, > Daniel > > Em segunda-feira, 3 de maio de 2021 15:44:46 BRT, Jason Lowe- > Power mailto:ja...@lowepower.com> > > escreveu: > > > Just a few quick replies below. Overall, I think we're being too > focused on "standards" and not on enough on ease of use. It's not a problem > if there are exceptions to guidance, if there's good reasons for the > exceptions. > > > On Mon, May 3, 2021 at 11:36 AM Daniel Carvalho via gem5-dev > mailto:gem5-dev@gem5.org> > wrote: > > > As mentioned by Gabe in the Jira issue, some of the > namespaces using snake declared in the codebase case are defined as parts > of a standard, and thus cannot be modified. Realistically, this means that if > we wanted to follow a namespace naming convention, it'd be snake case: > despite having way more occurrences of pascal case namespaces, they are all > "ours"; this means that, although inconvenient, it would be doable to > standardize all of them. > > > > If we just say "all namespaces should be PascalCase. gem5, the name > of this project, is an exception" would be OK with me. > > > > Would you be willing to adopt to enforce a snake case > namespace naming convention? From the previous replies to this thread, it > seems that this solution would app
[gem5-dev] Re: gem5 namespace
Hey Daniel, Sorry, I didn't mean to add to the confusion :). I may have gotten my case names confused! Also, I really appreciate the thoughtfulness and effort you're putting into this conversation! I believe I agree with your email below. I think that most people don't care that much (which is why we haven't heard from many). From my experience, our users only care when they get merge conflicts :D. That said, I'm not sure if "straightforward" is a way most of our users ever feel about merge conflicts. IMO, stability and ease of update should be high priority. If we are going to be changing names, etc. in a way that means external users of gem5 will have compiler errors, we should probably provide backwards compatibility and warnings. Most of our users are not software engineers and do not have as much experience with git, compilers, etc. as we do. Cheers, Jason On Mon, May 3, 2021 at 12:40 PM Daniel Carvalho via gem5-dev < gem5-dev@gem5.org> wrote: > I'm confused, Jason. I thought you were in favor of adopting snake case as > a "general convention" (i.e., "the google way"), so by adopting snake case > we would be adopting the "general convention", not forging our own path. > However, if by "general convention" you mean "the convention vastly adopted > by gem5", I don't have the exact numbers, but I'd guess it is 70% pascal, > 30% snake case - i.e., IMHO, not a "general convention", just a preference. > Adding "gem5" or "Gem5" would only extend this mess, not add an exception. > > Regarding changing the name of the variable, indeed, it is not a necessary > step. > > Again, as stated before, I don't care which solution is taken. The > important thing is to come to a decision that appeases most community > members; however, it is hard to reach a consensus when we seem to have > strong opinions on both sides, yet we only have 5 votes. That is why I have > suggested officially adopting snake case namespaces: it would solve the > "gem5 VS Gem5" problem, it is feasible to do it without having exceptions > (at least as of now), Giacomo expressed preference towards lowercase > namespaces, Jason suggested affinity with the google approach (snake case) > and "gem5", Bobby prefers "gem5", and Gabe and I like consistency/patterns. > The (huge) downside to this solution is that it would affect users, but 1) > we'd already be affecting users anyway with the new namespace, and 2) > solving the merge conflicts would be straightforward if the patches were > created with that in mind. > > Regards, > Daniel > Em segunda-feira, 3 de maio de 2021 15:44:46 BRT, Jason Lowe-Power < > ja...@lowepower.com> escreveu: > > > Just a few quick replies below. Overall, I think we're being too focused > on "standards" and not on enough on ease of use. It's not a problem if > there are exceptions to guidance, if there's good reasons for the > exceptions. > > > On Mon, May 3, 2021 at 11:36 AM Daniel Carvalho via gem5-dev < > gem5-dev@gem5.org> wrote: > > As mentioned by Gabe in the Jira issue, some of the namespaces using snake > declared in the codebase case are defined as parts of a standard, and thus > cannot be modified. Realistically, this means that if we wanted to follow a > namespace naming convention, it'd be snake case: despite having way more > occurrences of pascal case namespaces, they are all "ours"; this means > that, although inconvenient, it would be doable to standardize all of them. > > > If we just say "all namespaces should be PascalCase. gem5, the name of > this project, is an exception" would be OK with me. > > > Would you be willing to adopt to enforce a snake case namespace naming > convention? From the previous replies to this thread, it seems that this > solution would appease most - if not all - participants. > > > I really don't think this is too important. I would definitely prefer to > follow the *general* conventions rather than forging our own path. > > > > For this change to take place, we need to (not necessarily sorted): > 1) Rename the python variables named "gem5" in > src/systemc/tlm_bridge/TlmBridge.py (or remove them - I don't remember > finding where they are used); > > > Why does this need to be done? These are class names, not namespaces. > > > > 2) Add a section to our coding style mandating snake case for namespaces; > > 3) Change all existing namespaces to snake case; > > 4) Create a verifier to enforce this convention. > > 5) Rename/Move elements starting with gem5X/m5X as gem5::X > > > Finally, regarding macro names, we could improve the corresponding Jira > issue by listing all current macros so that we can start applying the > change and raise objections to particular instances. > > Cheers, > Daniel > > ___ > gem5-dev mailing list -- gem5-dev@gem5.org > To unsubscribe send an email to gem5-dev-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > > ___ > gem5-dev mailing list --
[gem5-dev] Re: gem5 namespace
I'm confused, Jason. I thought you were in favor of adopting snake case as a "general convention" (i.e., "the google way"), so by adopting snake case we would be adopting the "general convention", not forging our own path. However, if by "general convention" you mean "the convention vastly adopted by gem5", I don't have the exact numbers, but I'd guess it is 70% pascal, 30% snake case - i.e., IMHO, not a "general convention", just a preference. Adding "gem5" or "Gem5" would only extend this mess, not add an exception. Regarding changing the name of the variable, indeed, it is not a necessary step. Again, as stated before, I don't care which solution is taken. The important thing is to come to a decision that appeases most community members; however, it is hard to reach a consensus when we seem to have strong opinions on both sides, yet we only have 5 votes. That is why I have suggested officially adopting snake case namespaces: it would solve the "gem5 VS Gem5" problem, it is feasible to do it without having exceptions (at least as of now), Giacomo expressed preference towards lowercase namespaces, Jason suggested affinity with the google approach (snake case) and "gem5", Bobby prefers "gem5", and Gabe and I like consistency/patterns. The (huge) downside to this solution is that it would affect users, but 1) we'd already be affecting users anyway with the new namespace, and 2) solving the merge conflicts would be straightforward if the patches were created with that in mind. Regards,Daniel Em segunda-feira, 3 de maio de 2021 15:44:46 BRT, Jason Lowe-Power escreveu: Just a few quick replies below. Overall, I think we're being too focused on "standards" and not on enough on ease of use. It's not a problem if there are exceptions to guidance, if there's good reasons for the exceptions. On Mon, May 3, 2021 at 11:36 AM Daniel Carvalho via gem5-dev wrote: As mentioned by Gabe in the Jira issue, some of the namespaces using snake declared in the codebase case are defined as parts of a standard, and thus cannot be modified. Realistically, this means that if we wanted to follow a namespace naming convention, it'd be snake case: despite having way more occurrences of pascal case namespaces, they are all "ours"; this means that, although inconvenient, it would be doable to standardize all of them. If we just say "all namespaces should be PascalCase. gem5, the name of this project, is an exception" would be OK with me. Would you be willing to adopt to enforce a snake case namespace naming convention? From the previous replies to this thread, it seems that this solution would appease most - if not all - participants. I really don't think this is too important. I would definitely prefer to follow the *general* conventions rather than forging our own path. For this change to take place, we need to (not necessarily sorted):1) Rename the python variables named "gem5" in src/systemc/tlm_bridge/TlmBridge.py (or remove them - I don't remember finding where they are used); Why does this need to be done? These are class names, not namespaces. 2) Add a section to our coding style mandating snake case for namespaces; 3) Change all existing namespaces to snake case; 4) Create a verifier to enforce this convention. 5) Rename/Move elements starting with gem5X/m5X as gem5::X Finally, regarding macro names, we could improve the corresponding Jira issue by listing all current macros so that we can start applying the change and raise objections to particular instances. Cheers,Daniel ___ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s ___ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-dev] Re: gem5 namespace
Just a few quick replies below. Overall, I think we're being too focused on "standards" and not on enough on ease of use. It's not a problem if there are exceptions to guidance, if there's good reasons for the exceptions. On Mon, May 3, 2021 at 11:36 AM Daniel Carvalho via gem5-dev < gem5-dev@gem5.org> wrote: > As mentioned by Gabe in the Jira issue, some of the namespaces using snake > declared in the codebase case are defined as parts of a standard, and thus > cannot be modified. Realistically, this means that if we wanted to follow a > namespace naming convention, it'd be snake case: despite having way more > occurrences of pascal case namespaces, they are all "ours"; this means > that, although inconvenient, it would be doable to standardize all of them. > If we just say "all namespaces should be PascalCase. gem5, the name of this project, is an exception" would be OK with me. > Would you be willing to adopt to enforce a snake case namespace naming > convention? From the previous replies to this thread, it seems that this > solution would appease most - if not all - participants. > I really don't think this is too important. I would definitely prefer to follow the *general* conventions rather than forging our own path. > > For this change to take place, we need to (not necessarily sorted): > 1) Rename the python variables named "gem5" in > src/systemc/tlm_bridge/TlmBridge.py (or remove them - I don't remember > finding where they are used); > Why does this need to be done? These are class names, not namespaces. > 2) Add a section to our coding style mandating snake case for namespaces; > 3) Change all existing namespaces to snake case; > 4) Create a verifier to enforce this convention. > 5) Rename/Move elements starting with gem5X/m5X as gem5::X > > Finally, regarding macro names, we could improve the corresponding Jira > issue by listing all current macros so that we can start applying the > change and raise objections to particular instances. > > Cheers, > Daniel > ___ > gem5-dev mailing list -- gem5-dev@gem5.org > To unsubscribe send an email to gem5-dev-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s ___ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-dev] Re: gem5 namespace
As mentioned by Gabe in the Jira issue, some of the namespaces using snake declared in the codebase case are defined as parts of a standard, and thus cannot be modified. Realistically, this means that if we wanted to follow a namespace naming convention, it'd be snake case: despite having way more occurrences of pascal case namespaces, they are all "ours"; this means that, although inconvenient, it would be doable to standardize all of them. Would you be willing to adopt to enforce a snake case namespace naming convention? From the previous replies to this thread, it seems that this solution would appease most - if not all - participants. For this change to take place, we need to (not necessarily sorted):1) Rename the python variables named "gem5" in src/systemc/tlm_bridge/TlmBridge.py (or remove them - I don't remember finding where they are used);2) Add a section to our coding style mandating snake case for namespaces;3) Change all existing namespaces to snake case;4) Create a verifier to enforce this convention.5) Rename/Move elements starting with gem5X/m5X as gem5::X Finally, regarding macro names, we could improve the corresponding Jira issue by listing all current macros so that we can start applying the change and raise objections to particular instances. Cheers,Daniel ___ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-dev] Re: gem5 namespace
;> Room 2235,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
>>
>> On Sun, Apr 18, 2021 at 3:44 PM Daniel Carvalho via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>> Overall, there are way more uses of "gem5" than "Gem5" in the codebase,
>> and most of the instances that break the identity rule could be easily
>> fixed; however, there are cases that generate inconvenience: classes
>> starting with lowercase, and situations where gem5 is in the middle of the
>> var name (like "haveGem5Extension") make the code harder to
>> read/understand. In this sense, the uppercase version generates better
>> code.
>>
>>
>> I still favor namespace gem5 - it'd be the "external external" API, i.e.
>> we probably wouldn't be using it within src/ that much, and it would be
>> used by other simulators and within our SystemC bridge (more on that later)
>> - however, since we already have some exceptions, it wouldn't be the end
>> of the world having it start with a capital letter.
>>
>>
>> In the end, I personally do not care about which approach is taken, but
>> the decision taken must be taken as a community. Therefore, it would be
>> nice if we could have participation from other contributors to make the
>> final decision less susceptible to changes/complaints in the future.
>>
>>
>> Regarding when to use it:
>> IMHO (and not thoroughly thought out), all .cc and .hh and objects within
>> src/ should be subject to the namespace. Objects declared there are
>> declared and maintained by gem5. Because of that there would probably be
>> very few instances of namespace resolution within src/, so we should keep
>> avoiding "using namespace" and being verbose about it. Finally, we also
>> probably want to encourage users to define their objects inside the gem5
>> namespace to make it less unlikely that they will give up on uploading
>> their contributions due to the different styles, and the laziness to adapt
>> code. This means that disturbance in user code would be minimal: they would
>> simply add "namespace (G|g)em5 {" in the beginning and "} // namespace
>> (G|g)em5" at the end, instead of multiple "(G)|gem5::" instances.
>>
>>
>> Regards,
>>
>> Daniel
>> For the record, if the namespaces you found using snake_case start with
>> sc_, those are for systemc and are mandated by that standard. The one
>> exception, sc_gem5, is one I made up which is closely associated with the
>> other systemc namespaces and is named similarly to them for consistency.
>>
>> Gabe
>>
>> On Thu, Apr 15, 2021 at 1:51 AM Giacomo Travaglini <
>> giacomo.travagl...@arm.com> wrote:
>>
>> My vote goes to 1 and A as well
>>
>> My sole argument is consistency; in general I'd rather start a namespace
>> with a lowercase. So that when we have something
>> like a scope resolution we know we are dealing with a namespace and not a
>> class. But that's off-topic.
>>
>> Namespace names are anyway not covered by our coding style, so it's
>> probably worth adding an entry.
>>
>> https://www.gem5.org/documentation/general_docs/development/coding_style/
>>
>> From a quick grep I can see most of our namespaces follow the PascalCase
>> type, though there are some namespaces using snake_case convention.
>>
>> Giacomo
>>
>> > -Original Message-
>> > From: Gabe Black via gem5-dev
>> > Sent: 15 April 2021 09:03
>> > To: gem5 Developer List
>> > Cc: Gabe Black
>> > Subject: [gem5-dev] Re: gem5 namespace
>> >
>> > My vote is for 1 and A.
>> >
>> > We have style rules for a reason, and that is because not following them
>> > causes technical problems like name collisions, and makes it less
>> obvious
>> > when reading code what things are and what they're doing. It's a bit
>> > hypocritical to say that we should follow style rules and completely
>> ignore
>> > the aesthetic rule when capitalizing GEM5_, but then say that the
>> aesthetic
>> > rule should win when dealing with the namespace.
>> >
>> > This is further inconsistent with the Gem5Internal namespace, the Gem5
>> > class in SCons, the Gem5Op instruction format used for ARM, and the
>> > Gem5Imm constant used for ARM semihosting. It would also cause a
>> collision
>> > with any variable called gem5, a completely legal and reasonabl
[gem5-dev] Re: gem5 namespace
d be subject to the namespace. Objects declared there are
> declared and maintained by gem5. Because of that there would probably be
> very few instances of namespace resolution within src/, so we should keep
> avoiding "using namespace" and being verbose about it. Finally, we also
> probably want to encourage users to define their objects inside the gem5
> namespace to make it less unlikely that they will give up on uploading
> their contributions due to the different styles, and the laziness to adapt
> code. This means that disturbance in user code would be minimal: they would
> simply add "namespace (G|g)em5 {" in the beginning and "} // namespace
> (G|g)em5" at the end, instead of multiple "(G)|gem5::" instances.
>
>
> Regards,
>
> Daniel
> For the record, if the namespaces you found using snake_case start with
> sc_, those are for systemc and are mandated by that standard. The one
> exception, sc_gem5, is one I made up which is closely associated with the
> other systemc namespaces and is named similarly to them for consistency.
>
> Gabe
>
> On Thu, Apr 15, 2021 at 1:51 AM Giacomo Travaglini <
> giacomo.travagl...@arm.com> wrote:
>
> My vote goes to 1 and A as well
>
> My sole argument is consistency; in general I'd rather start a namespace
> with a lowercase. So that when we have something
> like a scope resolution we know we are dealing with a namespace and not a
> class. But that's off-topic.
>
> Namespace names are anyway not covered by our coding style, so it's
> probably worth adding an entry.
>
> https://www.gem5.org/documentation/general_docs/development/coding_style/
>
> From a quick grep I can see most of our namespaces follow the PascalCase
> type, though there are some namespaces using snake_case convention.
>
> Giacomo
>
> > -Original Message-
> > From: Gabe Black via gem5-dev
> > Sent: 15 April 2021 09:03
> > To: gem5 Developer List
> > Cc: Gabe Black
> > Subject: [gem5-dev] Re: gem5 namespace
> >
> > My vote is for 1 and A.
> >
> > We have style rules for a reason, and that is because not following them
> > causes technical problems like name collisions, and makes it less obvious
> > when reading code what things are and what they're doing. It's a bit
> > hypocritical to say that we should follow style rules and completely
> ignore
> > the aesthetic rule when capitalizing GEM5_, but then say that the
> aesthetic
> > rule should win when dealing with the namespace.
> >
> > This is further inconsistent with the Gem5Internal namespace, the Gem5
> > class in SCons, the Gem5Op instruction format used for ARM, and the
> > Gem5Imm constant used for ARM semihosting. It would also cause a
> collision
> > with any variable called gem5, a completely legal and reasonable name to
> use,
> > *especially* in code outside of gem5 which might be using it to refer to
> > something related to gem5 which it is interacting with.
> >
> > There are no other instances where we let superficial aesthetic
> conventions
> > like this overrule technical considerations. We don't add _tm to the end
> of
> > trademarked names, we don't call AtomicSimpleCPU the atomic simple CPU
> > since that's not a valid class name, and a hundred other examples of
> where
> > prose takes a back seat because this is not prose, this is a conceptual
> machine
> > people happen to be able to read.
> >
> > Our website is the place for branding and identity and marketing, our
> code is
> > not.
> >
> > Gabe
> >
> > On Wed, Apr 14, 2021 at 7:28 AM Jason Lowe-Power via gem5-dev > d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote:
> >
> >
> > Thanks for putting this all together, Daniel!
> >
> > My opinion is the same as yours: option 2 and macro A.
> >
> > One other thing we need to do is to standardize and document when
> > and where you need to use the gem5 namespace. For instance, do we need
> > to update *all* headers to be in the gem5 namespace? If not, when is an
> > object in the gem5 namespace and when it is not? What about `using
> > namespace gem5`? Can/must all .cc files include this?
> >
> > Since this is a relatively big change to the coding standards which
> > could cause significant frustration to our users, we should be sure to
> > document and standardize *before* we make any code changes.
> >
> > Cheers,
> > Jason
> >
> >
> > On Wed, Apr 14, 2021 at 6:48 AM Daniel Carvalho via gem5-dev
> > mailto:gem5-dev@gem5.org> > wrote:
> >
> >
> > Hello, de
[gem5-dev] Re: gem5 namespace
I'd rather start a namespace with a lowercase. So that when we have something like a scope resolution we know we are dealing with a namespace and not a class. But that's off-topic. Namespace names are anyway not covered by our coding style, so it's probably worth adding an entry. https://www.gem5.org/documentation/general_docs/development/coding_style/ >From a quick grep I can see most of our namespaces follow the PascalCase type, >though there are some namespaces using snake_case convention. Giacomo > -----Original Message- > From: Gabe Black via gem5-dev > Sent: 15 April 2021 09:03 > To: gem5 Developer List > Cc: Gabe Black > Subject: [gem5-dev] Re: gem5 namespace > > My vote is for 1 and A. > > We have style rules for a reason, and that is because not following them > causes technical problems like name collisions, and makes it less obvious > when reading code what things are and what they're doing. It's a bit > hypocritical to say that we should follow style rules and completely ignore > the aesthetic rule when capitalizing GEM5_, but then say that the aesthetic > rule should win when dealing with the namespace. > > This is further inconsistent with the Gem5Internal namespace, the Gem5 > class in SCons, the Gem5Op instruction format used for ARM, and the > Gem5Imm constant used for ARM semihosting. It would also cause a collision > with any variable called gem5, a completely legal and reasonable name to use, > *especially* in code outside of gem5 which might be using it to refer to > something related to gem5 which it is interacting with. > > There are no other instances where we let superficial aesthetic conventions > like this overrule technical considerations. We don't add _tm to the end of > trademarked names, we don't call AtomicSimpleCPU the atomic simple CPU > since that's not a valid class name, and a hundred other examples of where > prose takes a back seat because this is not prose, this is a conceptual > machine > people happen to be able to read. > > Our website is the place for branding and identity and marketing, our code is > not. > > Gabe > > On Wed, Apr 14, 2021 at 7:28 AM Jason Lowe-Power via gem5-dev d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote: > > > Thanks for putting this all together, Daniel! > > My opinion is the same as yours: option 2 and macro A. > > One other thing we need to do is to standardize and document when > and where you need to use the gem5 namespace. For instance, do we need > to update *all* headers to be in the gem5 namespace? If not, when is an > object in the gem5 namespace and when it is not? What about `using > namespace gem5`? Can/must all .cc files include this? > > Since this is a relatively big change to the coding standards which > could cause significant frustration to our users, we should be sure to > document and standardize *before* we make any code changes. > > Cheers, > Jason > > > On Wed, Apr 14, 2021 at 6:48 AM Daniel Carvalho via gem5-dev > mailto:gem5-dev@gem5.org> > wrote: > > > Hello, devs, > > > > We currently have a recurring issue, which is the lack of a > gem5 namespace. > This generates collision with other libraries and user code. > > > > A Jira ticket has been created to point out the issue last year: > > > https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/G > EM5-730 > > > And this topic has been brought up a few times: > > > https://www.mail-archive.com/gem5- > d...@gem5.org/msg37770.html > > https://gem5- > review.googlesource.com/c/public/gem5/+/40878 > > https://www.mail-archive.com/gem5- > d...@gem5.org/msg36453.html > > > Finally, there were already patches that were consequences > of lack of a gem5 > namespace: > > > https://gem5- > review.googlesource.com/c/public/gem5/+/32175 > > https://gem5- > review.googlesource.com/c/public/gem5/+/40878 > > > A similar issue exists for macros, and an existing proposal to > solve it already > exists, which is to add a "GEM5_" prefix. It follows the coding > style, which > dictates that "preprocessor symbols (constants and macros) > should be all > caps with underscores": > > > > https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/G > EM5-912 > > > It does not seem to be controversial to add this namespace; > however, there is > still one blocker to greenlight its creation: what will be its > name. There are > no explicit rules regarding namespace naming; however, they > are typically > declared starting with an uppercase letter followed by > lowercase letters. So, > theoretically, gem5's namespace should be "Gem5".
[gem5-dev] Re: gem5 namespace
>
> I still favor namespace gem5 - it'd be the "external external" API, i.e.
> we probably wouldn't be using it within src/ that much, and it would be
> used by other simulators...
This is why I'm strongly in favor of lowercase gem5. When external projects
link to gem5 (which is *going* to happen), I think it's much better to use
the normative gem5 spelling. It would be very confusing for people to use
Gem5 in the code but gem5 in documentation/papers.
```
class MyExternalObj: public gem5::SimObject
{
};
```
Jason
On Mon, Apr 19, 2021 at 6:40 AM Bobby Bruce via gem5-dev
wrote:
> Nothing gets software devs as engaged as when discussing naming
> conventions :).
>
> I vote for "gem5" (lowercase) namespace, with all caps MACROS, but my sole
> reason for this is I've grown to flinch whenever I see "Gem5", which I
> admit isn't the best argument.
>
> I echo Daniel's comment that I care more about having a rule and moving
> past this than what that rule should be.
>
> --
> Dr. Bobby R. Bruce
> Room 2235,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Sun, Apr 18, 2021 at 3:44 PM Daniel Carvalho via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Overall, there are way more uses of "gem5" than "Gem5" in the codebase,
>> and most of the instances that break the identity rule could be easily
>> fixed; however, there are cases that generate inconvenience: classes
>> starting with lowercase, and situations where gem5 is in the middle of the
>> var name (like "haveGem5Extension") make the code harder to
>> read/understand. In this sense, the uppercase version generates better
>> code.
>>
>>
>> I still favor namespace gem5 - it'd be the "external external" API, i.e.
>> we probably wouldn't be using it within src/ that much, and it would be
>> used by other simulators and within our SystemC bridge (more on that later)
>> - however, since we already have some exceptions, it wouldn't be the end
>> of the world having it start with a capital letter.
>>
>>
>> In the end, I personally do not care about which approach is taken, but
>> the decision taken must be taken as a community. Therefore, it would be
>> nice if we could have participation from other contributors to make the
>> final decision less susceptible to changes/complaints in the future.
>>
>>
>> Regarding when to use it:
>> IMHO (and not thoroughly thought out), all .cc and .hh and objects within
>> src/ should be subject to the namespace. Objects declared there are
>> declared and maintained by gem5. Because of that there would probably be
>> very few instances of namespace resolution within src/, so we should keep
>> avoiding "using namespace" and being verbose about it. Finally, we also
>> probably want to encourage users to define their objects inside the gem5
>> namespace to make it less unlikely that they will give up on uploading
>> their contributions due to the different styles, and the laziness to adapt
>> code. This means that disturbance in user code would be minimal: they would
>> simply add "namespace (G|g)em5 {" in the beginning and "} // namespace
>> (G|g)em5" at the end, instead of multiple "(G)|gem5::" instances.
>>
>>
>> Regards,
>>
>> Daniel
>> For the record, if the namespaces you found using snake_case start with
>> sc_, those are for systemc and are mandated by that standard. The one
>> exception, sc_gem5, is one I made up which is closely associated with the
>> other systemc namespaces and is named similarly to them for consistency.
>>
>> Gabe
>>
>> On Thu, Apr 15, 2021 at 1:51 AM Giacomo Travaglini <
>> giacomo.travagl...@arm.com> wrote:
>>
>> My vote goes to 1 and A as well
>>
>> My sole argument is consistency; in general I'd rather start a namespace
>> with a lowercase. So that when we have something
>> like a scope resolution we know we are dealing with a namespace and not a
>> class. But that's off-topic.
>>
>> Namespace names are anyway not covered by our coding style, so it's
>> probably worth adding an entry.
>>
>> https://www.gem5.org/documentation/general_docs/development/coding_style/
>>
>> From a quick grep I can see most of our namespaces follow the PascalCase
>> type, though there are some namespaces using snake_case convention.
>>
>> Giacomo
>>
>> > -Original Message-
>> > From: Gabe Black via gem5-dev
>> > Sent: 15 April 2021 09:03
&g
[gem5-dev] Re: gem5 namespace
Nothing gets software devs as engaged as when discussing naming conventions
:).
I vote for "gem5" (lowercase) namespace, with all caps MACROS, but my sole
reason for this is I've grown to flinch whenever I see "Gem5", which I
admit isn't the best argument.
I echo Daniel's comment that I care more about having a rule and moving
past this than what that rule should be.
--
Dr. Bobby R. Bruce
Room 2235,
Kemper Hall, UC Davis
Davis,
CA, 95616
web: https://www.bobbybruce.net
On Sun, Apr 18, 2021 at 3:44 PM Daniel Carvalho via gem5-dev <
gem5-dev@gem5.org> wrote:
> Overall, there are way more uses of "gem5" than "Gem5" in the codebase,
> and most of the instances that break the identity rule could be easily
> fixed; however, there are cases that generate inconvenience: classes
> starting with lowercase, and situations where gem5 is in the middle of the
> var name (like "haveGem5Extension") make the code harder to
> read/understand. In this sense, the uppercase version generates better
> code.
>
>
> I still favor namespace gem5 - it'd be the "external external" API, i.e.
> we probably wouldn't be using it within src/ that much, and it would be
> used by other simulators and within our SystemC bridge (more on that later)
> - however, since we already have some exceptions, it wouldn't be the end
> of the world having it start with a capital letter.
>
>
> In the end, I personally do not care about which approach is taken, but
> the decision taken must be taken as a community. Therefore, it would be
> nice if we could have participation from other contributors to make the
> final decision less susceptible to changes/complaints in the future.
>
>
> Regarding when to use it:
> IMHO (and not thoroughly thought out), all .cc and .hh and objects within
> src/ should be subject to the namespace. Objects declared there are
> declared and maintained by gem5. Because of that there would probably be
> very few instances of namespace resolution within src/, so we should keep
> avoiding "using namespace" and being verbose about it. Finally, we also
> probably want to encourage users to define their objects inside the gem5
> namespace to make it less unlikely that they will give up on uploading
> their contributions due to the different styles, and the laziness to adapt
> code. This means that disturbance in user code would be minimal: they would
> simply add "namespace (G|g)em5 {" in the beginning and "} // namespace
> (G|g)em5" at the end, instead of multiple "(G)|gem5::" instances.
>
>
> Regards,
>
> Daniel
> For the record, if the namespaces you found using snake_case start with
> sc_, those are for systemc and are mandated by that standard. The one
> exception, sc_gem5, is one I made up which is closely associated with the
> other systemc namespaces and is named similarly to them for consistency.
>
> Gabe
>
> On Thu, Apr 15, 2021 at 1:51 AM Giacomo Travaglini <
> giacomo.travagl...@arm.com> wrote:
>
> My vote goes to 1 and A as well
>
> My sole argument is consistency; in general I'd rather start a namespace
> with a lowercase. So that when we have something
> like a scope resolution we know we are dealing with a namespace and not a
> class. But that's off-topic.
>
> Namespace names are anyway not covered by our coding style, so it's
> probably worth adding an entry.
>
> https://www.gem5.org/documentation/general_docs/development/coding_style/
>
> From a quick grep I can see most of our namespaces follow the PascalCase
> type, though there are some namespaces using snake_case convention.
>
> Giacomo
>
> > -Original Message-
> > From: Gabe Black via gem5-dev
> > Sent: 15 April 2021 09:03
> > To: gem5 Developer List
> > Cc: Gabe Black
> > Subject: [gem5-dev] Re: gem5 namespace
> >
> > My vote is for 1 and A.
> >
> > We have style rules for a reason, and that is because not following them
> > causes technical problems like name collisions, and makes it less obvious
> > when reading code what things are and what they're doing. It's a bit
> > hypocritical to say that we should follow style rules and completely
> ignore
> > the aesthetic rule when capitalizing GEM5_, but then say that the
> aesthetic
> > rule should win when dealing with the namespace.
> >
> > This is further inconsistent with the Gem5Internal namespace, the Gem5
> > class in SCons, the Gem5Op instruction format used for ARM, and the
> > Gem5Imm constant used for ARM semihosting. It would also cause a
> collision
> > with any variable called gem5, a completely legal and reasonable name to
> use,
> &g
[gem5-dev] Re: gem5 namespace
Overall, there are way more uses of "gem5" than "Gem5" in the codebase, and
most of the instances that break the identity rule could be easily fixed;
however, there are cases that generate inconvenience: classes starting with
lowercase, and situations where gem5 is in the middle of the var name (like
"haveGem5Extension") make the code harder to read/understand. In this sense,
the uppercase version generates better code.
I still favor namespace gem5 - it'd be the "external external" API, i.e. we
probably wouldn't be using it within src/ that much, and it would be used by
other simulators and within our SystemC bridge (more on that later) - however,
since we already have some exceptions, it wouldn't be the end of the world
having it start with a capital letter.
In the end, I personally do not care about which approach is taken, but the
decision taken must be taken as a community. Therefore, it would be nice if we
could have participation from other contributors to make the final decision
less susceptible to changes/complaints in the future.
Regarding when to use it:IMHO (and not thoroughly thought out), all .cc and .hh
and objects within src/ should be subject to the namespace. Objects declared
there are declared and maintained by gem5. Because of that there would probably
be very few instances of namespace resolution within src/, so we should keep
avoiding "using namespace" and being verbose about it. Finally, we also
probably want to encourage users to define their objects inside the gem5
namespace to make it less unlikely that they will give up on uploading their
contributions due to the different styles, and the laziness to adapt code. This
means that disturbance in user code would be minimal: they would simply add
"namespace (G|g)em5 {" in the beginning and "} // namespace (G|g)em5" at the
end, instead of multiple "(G)|gem5::" instances.
Regards,
Daniel
For the record, if the namespaces you found using snake_case start with sc_,
those are for systemc and are mandated by that standard. The one exception,
sc_gem5, is one I made up which is closely associated with the other systemc
namespaces and is named similarly to them for consistency.
Gabe
On Thu, Apr 15, 2021 at 1:51 AM Giacomo Travaglini
wrote:
My vote goes to 1 and A as well
My sole argument is consistency; in general I'd rather start a namespace with a
lowercase. So that when we have something
like a scope resolution we know we are dealing with a namespace and not a
class. But that's off-topic.
Namespace names are anyway not covered by our coding style, so it's probably
worth adding an entry.
https://www.gem5.org/documentation/general_docs/development/coding_style/
>From a quick grep I can see most of our namespaces follow the PascalCase type,
>though there are some namespaces using snake_case convention.
Giacomo
> -Original Message-
> From: Gabe Black via gem5-dev
> Sent: 15 April 2021 09:03
> To: gem5 Developer List
> Cc: Gabe Black
> Subject: [gem5-dev] Re: gem5 namespace
>
> My vote is for 1 and A.
>
> We have style rules for a reason, and that is because not following them
> causes technical problems like name collisions, and makes it less obvious
> when reading code what things are and what they're doing. It's a bit
> hypocritical to say that we should follow style rules and completely ignore
> the aesthetic rule when capitalizing GEM5_, but then say that the aesthetic
> rule should win when dealing with the namespace.
>
> This is further inconsistent with the Gem5Internal namespace, the Gem5
> class in SCons, the Gem5Op instruction format used for ARM, and the
> Gem5Imm constant used for ARM semihosting. It would also cause a collision
> with any variable called gem5, a completely legal and reasonable name to use,
> *especially* in code outside of gem5 which might be using it to refer to
> something related to gem5 which it is interacting with.
>
> There are no other instances where we let superficial aesthetic conventions
> like this overrule technical considerations. We don't add _tm to the end of
> trademarked names, we don't call AtomicSimpleCPU the atomic simple CPU
> since that's not a valid class name, and a hundred other examples of where
> prose takes a back seat because this is not prose, this is a conceptual
> machine
> people happen to be able to read.
>
> Our website is the place for branding and identity and marketing, our code is
> not.
>
> Gabe
>
> On Wed, Apr 14, 2021 at 7:28 AM Jason Lowe-Power via gem5-dev d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote:
>
>
> Thanks for putting this all together, Daniel!
>
> My opinion is the same as yours: option 2 and macro A.
>
> One other thing we need to do is to standardize and document when
>
[gem5-dev] Re: gem5 namespace
For the record, if the namespaces you found using snake_case start with sc_, those are for systemc and are mandated by that standard. The one exception, sc_gem5, is one I made up which is closely associated with the other systemc namespaces and is named similarly to them for consistency. Gabe On Thu, Apr 15, 2021 at 1:51 AM Giacomo Travaglini < giacomo.travagl...@arm.com> wrote: > My vote goes to 1 and A as well > > My sole argument is consistency; in general I'd rather start a namespace > with a lowercase. So that when we have something > like a scope resolution we know we are dealing with a namespace and not a > class. But that's off-topic. > > Namespace names are anyway not covered by our coding style, so it's > probably worth adding an entry. > > https://www.gem5.org/documentation/general_docs/development/coding_style/ > > From a quick grep I can see most of our namespaces follow the PascalCase > type, though there are some namespaces using snake_case convention. > > Giacomo > > > -Original Message- > > From: Gabe Black via gem5-dev > > Sent: 15 April 2021 09:03 > > To: gem5 Developer List > > Cc: Gabe Black > > Subject: [gem5-dev] Re: gem5 namespace > > > > My vote is for 1 and A. > > > > We have style rules for a reason, and that is because not following them > > causes technical problems like name collisions, and makes it less obvious > > when reading code what things are and what they're doing. It's a bit > > hypocritical to say that we should follow style rules and completely > ignore > > the aesthetic rule when capitalizing GEM5_, but then say that the > aesthetic > > rule should win when dealing with the namespace. > > > > This is further inconsistent with the Gem5Internal namespace, the Gem5 > > class in SCons, the Gem5Op instruction format used for ARM, and the > > Gem5Imm constant used for ARM semihosting. It would also cause a > collision > > with any variable called gem5, a completely legal and reasonable name to > use, > > *especially* in code outside of gem5 which might be using it to refer to > > something related to gem5 which it is interacting with. > > > > There are no other instances where we let superficial aesthetic > conventions > > like this overrule technical considerations. We don't add _tm to the end > of > > trademarked names, we don't call AtomicSimpleCPU the atomic simple CPU > > since that's not a valid class name, and a hundred other examples of > where > > prose takes a back seat because this is not prose, this is a conceptual > machine > > people happen to be able to read. > > > > Our website is the place for branding and identity and marketing, our > code is > > not. > > > > Gabe > > > > On Wed, Apr 14, 2021 at 7:28 AM Jason Lowe-Power via gem5-dev > d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote: > > > > > > Thanks for putting this all together, Daniel! > > > > My opinion is the same as yours: option 2 and macro A. > > > > One other thing we need to do is to standardize and document when > > and where you need to use the gem5 namespace. For instance, do we need > > to update *all* headers to be in the gem5 namespace? If not, when is an > > object in the gem5 namespace and when it is not? What about `using > > namespace gem5`? Can/must all .cc files include this? > > > > Since this is a relatively big change to the coding standards which > > could cause significant frustration to our users, we should be sure to > > document and standardize *before* we make any code changes. > > > > Cheers, > > Jason > > > > > > On Wed, Apr 14, 2021 at 6:48 AM Daniel Carvalho via gem5-dev > > mailto:gem5-dev@gem5.org> > wrote: > > > > > > Hello, devs, > > > > > > > > We currently have a recurring issue, which is the lack of a > > gem5 namespace. > > This generates collision with other libraries and user code. > > > > > > > > A Jira ticket has been created to point out the issue last year: > > > > > > https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/G > > EM5-730 > > > > > > And this topic has been brought up a few times: > > > > > > https://www.mail-archive.com/gem5- > > d...@gem5.org/msg37770.html > > > > https://gem5- > > review.googlesource.com/c/public/gem5/+/40878 > > > > https://www.mail-archive.com/gem5- > > d...@gem5.org/msg36453.html > > > > > > Finally, there were already patches that were consequences >
[gem5-dev] Re: gem5 namespace
My vote goes to 1 and A as well My sole argument is consistency; in general I'd rather start a namespace with a lowercase. So that when we have something like a scope resolution we know we are dealing with a namespace and not a class. But that's off-topic. Namespace names are anyway not covered by our coding style, so it's probably worth adding an entry. https://www.gem5.org/documentation/general_docs/development/coding_style/ From a quick grep I can see most of our namespaces follow the PascalCase type, though there are some namespaces using snake_case convention. Giacomo > -Original Message- > From: Gabe Black via gem5-dev > Sent: 15 April 2021 09:03 > To: gem5 Developer List > Cc: Gabe Black > Subject: [gem5-dev] Re: gem5 namespace > > My vote is for 1 and A. > > We have style rules for a reason, and that is because not following them > causes technical problems like name collisions, and makes it less obvious > when reading code what things are and what they're doing. It's a bit > hypocritical to say that we should follow style rules and completely ignore > the aesthetic rule when capitalizing GEM5_, but then say that the aesthetic > rule should win when dealing with the namespace. > > This is further inconsistent with the Gem5Internal namespace, the Gem5 > class in SCons, the Gem5Op instruction format used for ARM, and the > Gem5Imm constant used for ARM semihosting. It would also cause a collision > with any variable called gem5, a completely legal and reasonable name to use, > *especially* in code outside of gem5 which might be using it to refer to > something related to gem5 which it is interacting with. > > There are no other instances where we let superficial aesthetic conventions > like this overrule technical considerations. We don't add _tm to the end of > trademarked names, we don't call AtomicSimpleCPU the atomic simple CPU > since that's not a valid class name, and a hundred other examples of where > prose takes a back seat because this is not prose, this is a conceptual > machine > people happen to be able to read. > > Our website is the place for branding and identity and marketing, our code is > not. > > Gabe > > On Wed, Apr 14, 2021 at 7:28 AM Jason Lowe-Power via gem5-dev d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote: > > > Thanks for putting this all together, Daniel! > > My opinion is the same as yours: option 2 and macro A. > > One other thing we need to do is to standardize and document when > and where you need to use the gem5 namespace. For instance, do we need > to update *all* headers to be in the gem5 namespace? If not, when is an > object in the gem5 namespace and when it is not? What about `using > namespace gem5`? Can/must all .cc files include this? > > Since this is a relatively big change to the coding standards which > could cause significant frustration to our users, we should be sure to > document and standardize *before* we make any code changes. > > Cheers, > Jason > > > On Wed, Apr 14, 2021 at 6:48 AM Daniel Carvalho via gem5-dev > mailto:gem5-dev@gem5.org> > wrote: > > > Hello, devs, > > > > We currently have a recurring issue, which is the lack of a > gem5 namespace. > This generates collision with other libraries and user code. > > > > A Jira ticket has been created to point out the issue last year: > > > https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/G > EM5-730 > > > And this topic has been brought up a few times: > > > https://www.mail-archive.com/gem5- > d...@gem5.org/msg37770.html > > https://gem5- > review.googlesource.com/c/public/gem5/+/40878 > > https://www.mail-archive.com/gem5- > d...@gem5.org/msg36453.html > > > Finally, there were already patches that were consequences > of lack of a gem5 > namespace: > > > https://gem5- > review.googlesource.com/c/public/gem5/+/32175 > > https://gem5- > review.googlesource.com/c/public/gem5/+/40878 > > > A similar issue exists for macros, and an existing proposal to > solve it already > exists, which is to add a "GEM5_" prefix. It follows the coding > style, which > dictates that "preprocessor symbols (constants and macros) > should be all > caps with underscores": > > > > https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/G > EM5-912 > > > It does not seem to be controversial to add this namespace; > however, there is > still one blocker to greenlight its creation: what will be its > name. There are > no explicit rules regarding namespace naming; however, they > are typically > declared starting with an uppercase letter followed by > lowercase letters.
[gem5-dev] Re: gem5 namespace
My vote is for 1 and A.
We have style rules for a reason, and that is because not following them
causes technical problems like name collisions, and makes it less obvious
when reading code what things are and what they're doing. It's a bit
hypocritical to say that we should follow style rules and completely ignore
the aesthetic rule when capitalizing GEM5_, but then say that the aesthetic
rule should win when dealing with the namespace.
This is further inconsistent with the Gem5Internal namespace, the Gem5
class in SCons, the Gem5Op instruction format used for ARM, and the Gem5Imm
constant used for ARM semihosting. It would also cause a collision with any
variable called gem5, a completely legal and reasonable name to use,
*especially* in code outside of gem5 which might be using it to refer to
something related to gem5 which it is interacting with.
There are no other instances where we let superficial aesthetic conventions
like this overrule technical considerations. We don't add _tm to the end of
trademarked names, we don't call AtomicSimpleCPU the atomic simple CPU
since that's not a valid class name, and a hundred other examples of where
prose takes a back seat because this is not prose, this is a conceptual
machine people happen to be able to read.
Our website is the place for branding and identity and marketing, our code
is not.
Gabe
On Wed, Apr 14, 2021 at 7:28 AM Jason Lowe-Power via gem5-dev <
gem5-dev@gem5.org> wrote:
> Thanks for putting this all together, Daniel!
>
> My opinion is the same as yours: option 2 and macro A.
>
> One other thing we need to do is to standardize and document when and
> where you need to use the gem5 namespace. For instance, do we need to
> update *all* headers to be in the gem5 namespace? If not, when is an object
> in the gem5 namespace and when it is not? What about `using namespace
> gem5`? Can/must all .cc files include this?
>
> Since this is a relatively big change to the coding standards which could
> cause significant frustration to our users, we should be sure to document
> and standardize *before* we make any code changes.
>
> Cheers,
> Jason
>
> On Wed, Apr 14, 2021 at 6:48 AM Daniel Carvalho via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Hello, devs,
>>
>>
>> We currently have a recurring issue, which is the lack of a gem5
>> namespace.
>> This generates collision with other libraries and user code.
>>
>>
>> A Jira ticket has been created to point out the issue last year:
>>
>> https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-730
>>
>>
>> And this topic has been brought up a few times:
>>
>> https://www.mail-archive.com/gem5-dev@gem5.org/msg37770.html
>>
>> https://gem5-review.googlesource.com/c/public/gem5/+/40878
>>
>> https://www.mail-archive.com/gem5-dev@gem5.org/msg36453.html
>>
>>
>> Finally, there were already patches that were consequences of lack of a
>> gem5
>> namespace:
>>
>> https://gem5-review.googlesource.com/c/public/gem5/+/32175
>>
>> https://gem5-review.googlesource.com/c/public/gem5/+/40878
>>
>>
>> A similar issue exists for macros, and an existing proposal to solve it
>> already
>> exists, which is to add a "GEM5_" prefix. It follows the coding style,
>> which
>> dictates that "preprocessor symbols (constants and macros) should be all
>> caps with underscores":
>>
>> https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-912
>>
>>
>> It does not seem to be controversial to add this namespace; however,
>> there is
>> still one blocker to greenlight its creation: what will be its name.
>> There are
>> no explicit rules regarding namespace naming; however, they are typically
>> declared starting with an uppercase letter followed by lowercase letters.
>> So,
>> theoretically, gem5's namespace should be "Gem5". This, however, conflicts
>> with gem5's identity: "“gem5” should always have a lowercase “g”"
>> (see http://www.gem5.org/getting_started/).
>>
>>
>> We should decide as a community what is the best approach to take, so I'll
>> list the options and will request you to cast your votes. If you would
>> like
>> to add remarks to the discussion, feel free to do so.
>>
>>
>> NAMESPACE:
>>
>> *1 - namespace Gem5 {}*
>>
>> *2 - namespace gem5 {}*
>>
>>
>> MACROS:
>>
>> *A - GEM5_MACRO_NAME*
>>
>> *B - gem5_MACRO_NAME*
>>
>>
>> Personally, I think that identity precedes coding style, so **option 2**
>> should
>> be taken. Yet, in a slightly inconsistent manner, I would vote for macro
>> **option A**. My argument being that it would be more convenient to type
>> it
>> with all caps, and that it would be implied from the identity that it
>> refers to
>> instances of the identity containing lowercase letters, which is not the
>> case
>> of "GEM5_".
>>
>> Best,
>> Daniel
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
[gem5-dev] Re: gem5 namespace
Thanks for putting this all together, Daniel!
My opinion is the same as yours: option 2 and macro A.
One other thing we need to do is to standardize and document when and where
you need to use the gem5 namespace. For instance, do we need to update
*all* headers to be in the gem5 namespace? If not, when is an object in the
gem5 namespace and when it is not? What about `using namespace gem5`?
Can/must all .cc files include this?
Since this is a relatively big change to the coding standards which could
cause significant frustration to our users, we should be sure to document
and standardize *before* we make any code changes.
Cheers,
Jason
On Wed, Apr 14, 2021 at 6:48 AM Daniel Carvalho via gem5-dev <
gem5-dev@gem5.org> wrote:
> Hello, devs,
>
>
> We currently have a recurring issue, which is the lack of a gem5 namespace.
> This generates collision with other libraries and user code.
>
>
> A Jira ticket has been created to point out the issue last year:
>
> https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-730
>
>
> And this topic has been brought up a few times:
>
> https://www.mail-archive.com/gem5-dev@gem5.org/msg37770.html
>
> https://gem5-review.googlesource.com/c/public/gem5/+/40878
>
> https://www.mail-archive.com/gem5-dev@gem5.org/msg36453.html
>
>
> Finally, there were already patches that were consequences of lack of a
> gem5
> namespace:
>
> https://gem5-review.googlesource.com/c/public/gem5/+/32175
>
> https://gem5-review.googlesource.com/c/public/gem5/+/40878
>
>
> A similar issue exists for macros, and an existing proposal to solve it
> already
> exists, which is to add a "GEM5_" prefix. It follows the coding style,
> which
> dictates that "preprocessor symbols (constants and macros) should be all
> caps with underscores":
>
> https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-912
>
>
> It does not seem to be controversial to add this namespace; however, there
> is
> still one blocker to greenlight its creation: what will be its name. There
> are
> no explicit rules regarding namespace naming; however, they are typically
> declared starting with an uppercase letter followed by lowercase letters.
> So,
> theoretically, gem5's namespace should be "Gem5". This, however, conflicts
> with gem5's identity: "“gem5” should always have a lowercase “g”"
> (see http://www.gem5.org/getting_started/).
>
>
> We should decide as a community what is the best approach to take, so I'll
> list the options and will request you to cast your votes. If you would like
> to add remarks to the discussion, feel free to do so.
>
>
> NAMESPACE:
>
> *1 - namespace Gem5 {}*
>
> *2 - namespace gem5 {}*
>
>
> MACROS:
>
> *A - GEM5_MACRO_NAME*
>
> *B - gem5_MACRO_NAME*
>
>
> Personally, I think that identity precedes coding style, so **option 2**
> should
> be taken. Yet, in a slightly inconsistent manner, I would vote for macro
> **option A**. My argument being that it would be more convenient to type
> it
> with all caps, and that it would be implied from the identity that it
> refers to
> instances of the identity containing lowercase letters, which is not the
> case
> of "GEM5_".
>
> Best,
> Daniel
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
