-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
global object registry to simplify Moose.C #10952
Conversation
672ae97
to
a5851ac
Compare
Job Precheck on b9cb2be : invalidated by @rwcarlsen |
also remove unique_id stuff from ActionFactory
and update special case registrations
Also fix moose docs tests
FYI, Robert requested that we turn off the clang format check for this PR due to the "update tutorial" b21d151 commit having troubles with clang format. Any commits after that will not be guaranteed to be clang format clean. |
There is quite a bit of work to do in examples. I'm not sure we want to
hold up this PR for it. I'll keep working on it, but in the mean time
let's see if we can get this in without it. Also - that will leave us with
fewer changes not being checked by clang-format.
…On Thu, Mar 8, 2018 at 3:28 PM, brianmoose ***@***.***> wrote:
FYI, Robert requested that we turn off the clang format check for this PR
due to the "update tutorial" b21d151
<b21d151>
commit having troubles with clang format.
Any commits after that will not be guaranteed to be clang format clean.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#10952 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABSeSiC_oEO40byabhf-hvZjVSIaWsowks5tcbB9gaJpZM4SdYXN>
.
|
|
||
using paramsPtr = InputParameters (*)(); | ||
using buildPtr = std::shared_ptr<MooseObject> (*)(const InputParameters & parameters); | ||
using buildActionPtr = std::shared_ptr<Action> (*)(const InputParameters & parameters); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
ent->addChild(new hit::Field("type", hit::Field::Kind::String, "action")); | ||
ent->addChild(new hit::Field("task", hit::Field::Kind::String, act._name)); | ||
ent->addChild(new hit::Field("class", hit::Field::Kind::String, act._classname)); | ||
ent->addChild(new hit::Field("file", hit::Field::Kind::String, act._file)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lots of new raw allocations... I'm going to turn on the Valgrind target.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW - I do realize that these are normally cleaned up in the tree destruction. I just know better than to assume that it always works when something changes.
follow up to idaholab#10952
Follow on to idaholab#10952
follow up to idaholab#10952
Follow on to idaholab#10952
follow up to idaholab#10952
follow up to idaholab#10952
follow up to idaholab#10952
The typo caused the generated static var for the macro to not be unique resulting in name clashes if more than one call exists in the same file. ref idaholab#10952
This creates a global object registry and new object registration macros that use it. Objects are now registered in their own .C files like this:
instead of in a central location (e.g. Moose.C). I modified the [Foo]App::registerObjects functions to just pull registrations from the global registry. This preserves backward compatibility and allows us to easily migrate to the new registration macros. This has several benefits:
I wanted to get feedback/thoughts before I work to polish this up, add docs, etc. Does this seem like an okay approach?