From david.thompson at kitware.com Sat Nov 4 14:17:44 2017 From: david.thompson at kitware.com (David Thompson) Date: Sat, 4 Nov 2017 14:17:44 -0400 Subject: [Smtk-developers] Resource manager question Message-ID: <94F8F4F6-8514-412C-A231-F1719778EE9D@kitware.com> Hi TJ (et al.), I have some questions about how to use the resource manager: Let's say I have a VTK reader class that loads SMTK model files (one which is perhaps named vtkSMTKModelReader and located in smtk/extension/paraview/server). Since a file is a resource, making the reader behave as expected as far as both VTK and SMTK will be interesting. 1. VTK expects the reader object to work if the filename changes. This means the same reader can read multiple resources into the resource manager. Should the previous resource be removed when the reader's filename changes? If not, there will be things in memory that aren't shown on the screen. 2. Now let's say the file changes on disk or someone calls Modified() on the VTK reader... should it re-read the file? If it does, how should it go about this? By deleting the previous resource and calling read() again on the resource manager? This seems like it might work for PV-based applications where there's client-server separation. But in a standalone VTK app, it could be annoying since related GUI state like a model-tree view would get reset to empty before being re-populated with a default view in a different state than before. 3. Finally, there doesn't appear to be a way for the resource manager to find resources by location. If we don't do this, it will be possible to have the same file loaded into the application multiple times. That might seem like a feature at first ("But I wanted to load it twice and render different things on each copy!") until someone clicks save ("Why did it overwrite my model with an old copy!?"). David From haocheng.liu at kitware.com Sat Nov 4 17:52:04 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Sat, 4 Nov 2017 17:52:04 -0400 Subject: [Smtk-developers] Resource manager question In-Reply-To: <94F8F4F6-8514-412C-A231-F1719778EE9D@kitware.com> References: <94F8F4F6-8514-412C-A231-F1719778EE9D@kitware.com> Message-ID: Hi David, On Sat, Nov 4, 2017 at 2:17 PM, David Thompson wrote: > Hi TJ (et al.), > > I have some questions about how to use the resource manager: > > Let's say I have a VTK reader class that loads SMTK model files (one which > is perhaps named vtkSMTKModelReader and located in smtk/extension/paraview/server). > Since a file is a resource, making the reader behave as expected as far as > both VTK and SMTK will be interesting. > > 1. VTK expects the reader object to work if the filename changes. This > means the same reader can read multiple resources into the resource > manager. Should the previous resource be removed when the reader's filename > changes? If not, there will be things in memory that aren't shown on the > screen. > I would say no... > 2. Now let's say the file changes on disk or someone calls Modified() on > the VTK reader... should it re-read the file? If it does, how should it go > about this? By deleting the previous resource and calling read() again on > the resource manager? This seems like it might work for PV-based > applications where there's client-server separation. But in a standalone > VTK app, it could be annoying since related GUI state like a model-tree > view would get reset to empty before being re-populated with a default view > in a different state than before. > > It should not re-read the file. Would it makes sense that once a file is read, then the application does not care about its state any more? For instance, CMB loads a file called bar.smtk. Then a user changes the filename to bar42.smtk outside CMB. CMB doesn't care until user tries to quit CMB or save current state. In the first condition, if there is no such file called bar.smtk then CMB should warn user. In the second condition, CMB would not provide the overwrite option.( Sublime uses this logic and I think it makes sense). > 3. Finally, there doesn't appear to be a way for the resource manager to > find resources by location. If we don't do this, it will be possible to > have the same file loaded into the application multiple times. That might > seem like a feature at first ("But I wanted to load it twice and render > different things on each copy!") until someone clicks save ("Why did it > overwrite my model with an old copy!?"). > > I would vote against allowing user to load the same file twice or more(As long as I recall, we used to call it a bug in discrete session :) ). If the user needs to render different things, fine then the user should use two seperate resources bar and foo though they are structurally identical in SMTK world. > David > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers > -- Best regards Haocheng Haocheng LIU Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4421 <(518)%20881-4421> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Sat Nov 4 19:27:38 2017 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Sat, 4 Nov 2017 19:27:38 -0400 Subject: [Smtk-developers] Resource manager question In-Reply-To: References: <94F8F4F6-8514-412C-A231-F1719778EE9D@kitware.com> Message-ID: Hi David, Since we have said that a resource does not have to have an resource manager to be loaded into memory I would say that a VTK reader would simply not use one - there really is no need since the filter is not trying to maintain any type of resource tracking or linkage between resources. Now if there was a reader that would take in a resource manager state file then yes - it would create a manager. Bob Sent from my iPad > On Nov 4, 2017, at 5:52 PM, Haocheng Liu wrote: > > Hi David, > >> On Sat, Nov 4, 2017 at 2:17 PM, David Thompson wrote: >> Hi TJ (et al.), >> >> I have some questions about how to use the resource manager: >> >> Let's say I have a VTK reader class that loads SMTK model files (one which is perhaps named vtkSMTKModelReader and located in smtk/extension/paraview/server). Since a file is a resource, making the reader behave as expected as far as both VTK and SMTK will be interesting. >> >> 1. VTK expects the reader object to work if the filename changes. This means the same reader can read multiple resources into the resource manager. Should the previous resource be removed when the reader's filename changes? If not, there will be things in memory that aren't shown on the screen. > I would say no... >> 2. Now let's say the file changes on disk or someone calls Modified() on the VTK reader... should it re-read the file? If it does, how should it go about this? By deleting the previous resource and calling read() again on the resource manager? This seems like it might work for PV-based applications where there's client-server separation. But in a standalone VTK app, it could be annoying since related GUI state like a model-tree view would get reset to empty before being re-populated with a default view in a different state than before. >> > It should not re-read the file. > Would it makes sense that once a file is read, then the application does not care about its state any more? > For instance, CMB loads a file called bar.smtk. Then a user changes the filename to bar42.smtk outside CMB. CMB doesn't care until user tries to quit CMB or save current state. In the first condition, if there is no such file called bar.smtk then CMB should warn user. In the second condition, CMB would not provide the overwrite option.( Sublime uses this logic and I think it makes sense). >> 3. Finally, there doesn't appear to be a way for the resource manager to find resources by location. If we don't do this, it will be possible to have the same file loaded into the application multiple times. That might seem like a feature at first ("But I wanted to load it twice and render different things on each copy!") until someone clicks save ("Why did it overwrite my model with an old copy!?"). >> > I would vote against allowing user to load the same file twice or more(As long as I recall, we used to call it a bug in discrete session :) ). If the user needs to render different things, fine then the user should use two seperate resources bar and foo though they are structurally identical in SMTK world. >> David >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/mailman/listinfo/smtk-developers > > > > -- > Best regards > Haocheng > > Haocheng LIU > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4421 > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon Nov 13 13:20:58 2017 From: david.thompson at kitware.com (David Thompson) Date: Mon, 13 Nov 2017 13:20:58 -0500 Subject: [Smtk-developers] Follow-up on resource metadata Message-ID: <165D4658-E62D-41C4-A44E-AB152E6E131B@kitware.com> Hi TJ et al., I wanted to follow up a little on the discussion we had last week about resources. As I understand it, we are now talking about having the model manager (renamed to Resource?) and each subclass (call them smtk::bridge::xxx::Resource) register themselves like so: smtk::resource::Manager::registerResource( new smtk::resource::Metadata("xxx", type_id(smtk::bridge::xxx::Resource)); somewhere in their static initializer. If so, it seems to make sense to do some combination of 1. Subclass metadata for smtk::model as shown below so that the inherited setup() method can fill out the create/read/write members; and/or 2. Change the create/read/write methods in the metadata to point to operators (but which ones?). The subclass below shows some of the questions that pop up. Note in particular that as we change the model manager into a resource, it goes from being a single instance with potentially multiple sessions to multiple instances, each with a single session. That seems to indicate that the smtk;:model::Session and SessionRegistrar classes should change a little. A session should not ask for its (sole) model manager, but rather a model resource should ask for its sole session. It would be easy for the SessionRegistrar to find an existing session or create one as required. Is this what you had in mind? One variation of the below would be to make subclasses of Metadata templated on their resource type... then at least the create() member of Metadata could be implemented as "return T::create()->setId(uid);". If we add methods to Resource to return read/write (/import/export?) methods, then Metadata could be entirely templated. David #ifndef smtk_model_Metadata_h #define smtk_model_Metadata_h #include "smtk/model/Manaager.h" #include "smtk/resource/Metadata.h" namespace smtk { namespace model { class Metadata : public smtk::resource::Metadata { typedef smtk::resource::Metadata Superclass; public: Metadata() : Superclass("model", typeid(smtk::model::Manager)) { this->setup(); } void setup() { this->create = [](const smtk::common::UUID& uid) { auto rsrc = smtk::model::Manager::create(); rsrc->setId(uid); return rsrc; }; this->read = [](const std::string& url) { // Find a session of the proper type auto sess = smtk::model::SessionRegistrar::createSession(m_uniqueName); if (sess) { // Order is important here: the session should be registered to the // model resource before running operations. However, note that this // causes a chicken and egg problem because the reader should obtain // a UUID for the model resource. Assume the reader will modify its // resource's UUID? Only on load and not import? auto rsrc = smtk::model::Manager::create(); rsrc->registerSession(sess); auto rdr = sess->op("load smtk model"); if (rdr) { rdr->findFile("filename")->setValue(0, url); auto res = rdr->operate(); // Success returns the shared pointer, keeping the model resource alive. // Failure discards the model resource. if (res->findInteger("outcome")->value() == smtk::operation::OPERATION_SUCCEEDED) { return rsrc; } } } return nullptr; }; this->write = [](const ResourcePtr& rawRsrc) { auto rsrc = dynamic_pointer_cast(rawRsrc); if (!rsrc) { return false; } auto wri = rsrc->session()->op("save smtk model"); if (wri) { // This will require changes to the "save smtk model" operator. // Should we associate all the models in the resource? // Should we have an attribute::ResourceItem just like we have // attribute::ComponentItem so that an entire resource can be // associated to an attribute? We could also abuse ComponentItem // a little bit... if we have a way to create a Component with a // null UUID but a valid parent resource, it could be interpreted // as "the component that is the set of all components in the // resource," making it a stand-in for the entire resource. wri->associatedComponents()->setValue(0, xxx); // Associate all models in rsrc? wri->findFile("filename")->setValue(0, rsrc->location()); auto res = wri->operate(); return res->findInteger("outcome")->value() == smtk::operation::OPERATION_SUCCEEDED; } return false; } } }; } } From tj.corona at kitware.com Tue Nov 14 08:59:49 2017 From: tj.corona at kitware.com (TJ Corona) Date: Tue, 14 Nov 2017 08:59:49 -0500 Subject: [Smtk-developers] Follow-up on resource metadata In-Reply-To: <165D4658-E62D-41C4-A44E-AB152E6E131B@kitware.com> References: <165D4658-E62D-41C4-A44E-AB152E6E131B@kitware.com> Message-ID: <4E451ABA-9DDA-47CA-BC4C-6296EE9A7601@kitware.com> Hi David, Sorry about the radio silence yesterday. Bob and I have a guest in the office this week (Mike Jackson from BlueQuartz); I will try to be better about breaking away to answer email. We could definitely subclass Metadata, but I don?t see why we need to. Currently, the create(), read() and write() functors are public fields that can be reassigned (once operators are more decoupled from smtk::model, they should become operators); as such, I don?t see any benefit to subclassing. > as we change the model manager into a resource, it goes from being a single instance with potentially multiple sessions to multiple instances, each with a single session. For the model system (and each of its derived bridges), something needs to be "the resource? that is unique to the bridge and is serializable. If the manager becomes the resource, that?s fine; it could then be given the responsibility of session management for its particular set of models. If the model itself becomes the resource (as Bob mentioned as an option last week), that?s fine too. Having a model as the top-level thing that can be written/read to/from disk makes sense to me, and operators would be able to access session-specific routines through the models associated with them. It would also be nice if a set of operators specific to a given session could be identified by their input or output type, obviating the need for an additional operator management system (instead, we could simply filter by input/output type to get all operators appropriate for a given model/component). > One variation of the below would be to make subclasses of Metadata templated on their resource type... then at least the create() member of Metadata could be implemented as "return T::create()->setId(uid);". If we add methods to Resource to return read/write (/import/export?) methods, then Metadata could be entirely templated. I do love templates :) I think that, if we stick to the idea of our functors converting to operators, then we may not need that level of specialization though. I think that it?s probably better if we require the writer of a session to explicitly define what the create()/read()/write() methods are, rather than providing an implicit default. Sincerely, T.J. Thomas J. Corona, Ph.D. Kitware, Inc. Senior R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4443 > On Nov 13, 2017, at 1:20 PM, David Thompson wrote: > > Hi TJ et al., > > I wanted to follow up a little on the discussion we had last week about resources. As I understand it, we are now talking about having the model manager (renamed to Resource?) and each subclass (call them smtk::bridge::xxx::Resource) register themselves like so: > > smtk::resource::Manager::registerResource( > new smtk::resource::Metadata("xxx", type_id(smtk::bridge::xxx::Resource)); > > somewhere in their static initializer. > > If so, it seems to make sense to do some combination of > > 1. Subclass metadata for smtk::model as shown below so that the inherited setup() method can fill out the create/read/write members; and/or > 2. Change the create/read/write methods in the metadata to point to operators (but which ones?). > > The subclass below shows some of the questions that pop up. Note in particular that as we change the model manager into a resource, it goes from being a single instance with potentially multiple sessions to multiple instances, each with a single session. > > That seems to indicate that the smtk;:model::Session and SessionRegistrar classes should change a little. A session should not ask for its (sole) model manager, but rather a model resource should ask for its sole session. It would be easy for the SessionRegistrar to find an existing session or create one as required. > > Is this what you had in mind? One variation of the below would be to make subclasses of Metadata templated on their resource type... then at least the create() member of Metadata could be implemented as "return T::create()->setId(uid);". If we add methods to Resource to return read/write (/import/export?) methods, then Metadata could be entirely templated. > > David > > #ifndef smtk_model_Metadata_h > #define smtk_model_Metadata_h > > #include "smtk/model/Manaager.h" > > #include "smtk/resource/Metadata.h" > > namespace smtk > { > namespace model > { > > class Metadata : public smtk::resource::Metadata > { > typedef smtk::resource::Metadata Superclass; > public: > Metadata() > : Superclass("model", typeid(smtk::model::Manager)) > { > this->setup(); > } > > void setup() > { > this->create = [](const smtk::common::UUID& uid) > { > auto rsrc = smtk::model::Manager::create(); > rsrc->setId(uid); > return rsrc; > }; > this->read = [](const std::string& url) > { > // Find a session of the proper type > auto sess = smtk::model::SessionRegistrar::createSession(m_uniqueName); > if (sess) > { > // Order is important here: the session should be registered to the > // model resource before running operations. However, note that this > // causes a chicken and egg problem because the reader should obtain > // a UUID for the model resource. Assume the reader will modify its > // resource's UUID? Only on load and not import? > auto rsrc = smtk::model::Manager::create(); > rsrc->registerSession(sess); > auto rdr = sess->op("load smtk model"); > if (rdr) > { > rdr->findFile("filename")->setValue(0, url); > auto res = rdr->operate(); > // Success returns the shared pointer, keeping the model resource alive. > // Failure discards the model resource. > if (res->findInteger("outcome")->value() == smtk::operation::OPERATION_SUCCEEDED) > { > return rsrc; > } > } > } > return nullptr; > }; > this->write = [](const ResourcePtr& rawRsrc) > { > auto rsrc = dynamic_pointer_cast(rawRsrc); > if (!rsrc) > { > return false; > } > auto wri = rsrc->session()->op("save smtk model"); > if (wri) > { > // This will require changes to the "save smtk model" operator. > // Should we associate all the models in the resource? > // Should we have an attribute::ResourceItem just like we have > // attribute::ComponentItem so that an entire resource can be > // associated to an attribute? We could also abuse ComponentItem > // a little bit... if we have a way to create a Component with a > // null UUID but a valid parent resource, it could be interpreted > // as "the component that is the set of all components in the > // resource," making it a stand-in for the entire resource. > wri->associatedComponents()->setValue(0, xxx); // Associate all models in rsrc? > wri->findFile("filename")->setValue(0, rsrc->location()); > auto res = wri->operate(); > return res->findInteger("outcome")->value() == smtk::operation::OPERATION_SUCCEEDED; > } > return false; > } > } > }; > > } > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue Nov 14 17:59:57 2017 From: david.thompson at kitware.com (David Thompson) Date: Tue, 14 Nov 2017 17:59:57 -0500 Subject: [Smtk-developers] Follow-up on resource metadata In-Reply-To: <4E451ABA-9DDA-47CA-BC4C-6296EE9A7601@kitware.com> References: <165D4658-E62D-41C4-A44E-AB152E6E131B@kitware.com> <4E451ABA-9DDA-47CA-BC4C-6296EE9A7601@kitware.com> Message-ID: <45F15439-7300-4F63-8429-F5D709E2B853@kitware.com> Hi TJ, > ... We could definitely subclass Metadata, but I don?t see why we need to. Currently, the create(), read() and write() functors are public fields that can be reassigned (once operators are more decoupled from smtk::model, they should become operators); as such, I don?t see any benefit to subclassing. My point is that every model resource should override create/read/write with the same 3 functors. It would be nice to inherit them. >> as we change the model manager into a resource, it goes from being a single instance with potentially multiple sessions to multiple instances, each with a single session. > > For the model system (and each of its derived bridges), something needs to be "the resource? ... I think we are on the same page and I did not mean to imply that turning the model manager into a resource was bad; merely that it has this implication for sessions. That's going to require some changes as the model manager now owns its sessions but now what will own them? I guess the SessionRegistrar. Also, we did this funky thing where the model manager adds an Entity record to itself for each of the session instances it owns -- that way an smtk::model::Model could report the session running its backend. At some point (please not now), we might eliminate that since all the models in the manager/resource will have the same session. > It would also be nice if a set of operators specific to a given session could be identified by their input or output type, obviating the need for an additional operator management system (instead, we could simply filter by input/output type to get all operators appropriate for a given model/component). If by "input or output type" you literally mean typeid(modelResource), then that will be a problem for operators inherited from the "base" session. We have said we want derived sessions to be able to pick and choose their operators, but having to explicitly import every one seems painful and error-prone as new ones are added. David From tj.corona at kitware.com Wed Nov 15 09:55:10 2017 From: tj.corona at kitware.com (TJ Corona) Date: Wed, 15 Nov 2017 09:55:10 -0500 Subject: [Smtk-developers] Follow-up on resource metadata In-Reply-To: <45F15439-7300-4F63-8429-F5D709E2B853@kitware.com> References: <165D4658-E62D-41C4-A44E-AB152E6E131B@kitware.com> <4E451ABA-9DDA-47CA-BC4C-6296EE9A7601@kitware.com> <45F15439-7300-4F63-8429-F5D709E2B853@kitware.com> Message-ID: <8F0112D9-D322-4584-8A20-87D46EE43292@kitware.com> > On Nov 14, 2017, at 5:59 PM, David Thompson wrote: > > Hi TJ, > >> ... We could definitely subclass Metadata, but I don?t see why we need to. Currently, the create(), read() and write() functors are public fields that can be reassigned (once operators are more decoupled from smtk::model, they should become operators); as such, I don?t see any benefit to subclassing. > > My point is that every model resource should override create/read/write with the same 3 functors. It would be nice to inherit them. I?m not sure I follow. If we assume that the three functors are instead smtk::operator::Operators (which is my intention, as soon as smtk::operator::* is usable), then these three operators will need to be explicitly provided by whoever registers the resource. >>> as we change the model manager into a resource, it goes from being a single instance with potentially multiple sessions to multiple instances, each with a single session. >> >> For the model system (and each of its derived bridges), something needs to be "the resource? ... > > I think we are on the same page and I did not mean to imply that turning the model manager into a resource was bad; merely that it has this implication for sessions. That's going to require some changes as the model manager now owns its sessions but now what will own them? I guess the SessionRegistrar. Also, we did this funky thing where the model manager adds an Entity record to itself for each of the session instances it owns -- that way an smtk::model::Model could report the session running its backend. At some point (please not now), we might eliminate that since all the models in the manager/resource will have the same session. If sessions can be accessed via the model resource, then maybe it doesn?t really matter where they live (perhaps simply a shared or weak pointer within the resource?). >> It would also be nice if a set of operators specific to a given session could be identified by their input or output type, obviating the need for an additional operator management system (instead, we could simply filter by input/output type to get all operators appropriate for a given model/component). > > If by "input or output type" you literally mean typeid(modelResource), then that will be a problem for operators inherited from the "base" session. We have said we want derived sessions to be able to pick and choose their operators, but having to explicitly import every one seems painful and error-prone as new ones are added. Why would this be a problem for operators associated with the base session? Using the same inheritance chain trick that is in resource, we can automatically determine that an operator that applies to the base session can apply to a derived session (so no need to manually white-list it). Also using the same trick used in resource, the container of operators will be multi-indexed, so if the user/developer is interested in operators by name, by input type or output type (or anything else we want to use as an index), it will be only a couple lines of code. > David From david.thompson at kitware.com Wed Nov 15 10:03:32 2017 From: david.thompson at kitware.com (David Thompson) Date: Wed, 15 Nov 2017 10:03:32 -0500 Subject: [Smtk-developers] Follow-up on resource metadata In-Reply-To: <8F0112D9-D322-4584-8A20-87D46EE43292@kitware.com> References: <165D4658-E62D-41C4-A44E-AB152E6E131B@kitware.com> <4E451ABA-9DDA-47CA-BC4C-6296EE9A7601@kitware.com> <45F15439-7300-4F63-8429-F5D709E2B853@kitware.com> <8F0112D9-D322-4584-8A20-87D46EE43292@kitware.com> Message-ID: <48A5E7AD-77FC-4221-AD95-AD75EEC0DB32@kitware.com> Hi TJ, >>> ... We could definitely subclass Metadata, but I don?t see why we need to. Currently, the create(), read() and write() functors are public fields that can be reassigned (once operators are more decoupled from smtk::model, they should become operators); as such, I don?t see any benefit to subclassing. >> >> My point is that every model resource should override create/read/write with the same 3 functors. It would be nice to inherit them. > > I?m not sure I follow. If we assume that the three functors are instead smtk::operator::Operators (which is my intention, as soon as smtk::operator::* is usable), then these three operators will need to be explicitly provided by whoever registers the resource. But at least the read and write operators will be the same for all: read = "load smtk model", write = "save smtk model". I thought that we agreed native model files would be handled by import/export operators. >>>> as we change the model manager into a resource, it goes from being a single instance with potentially multiple sessions to multiple instances, each with a single session. >>> >>> For the model system (and each of its derived bridges), something needs to be "the resource? ... >> >> I think we are on the same page and I did not mean to imply that turning the model manager into a resource was bad; merely that it has this implication for sessions. That's going to require some changes as the model manager now owns its sessions but now what will own them? ... > > If sessions can be accessed via the model resource, then maybe it doesn?t really matter where they live (perhaps simply a shared or weak pointer within the resource?). Maybe, but I think I prefer the SessionRegistrar so that there is a way to get a list of open sessions to present to the user. David From tj.corona at kitware.com Wed Nov 15 10:06:32 2017 From: tj.corona at kitware.com (TJ Corona) Date: Wed, 15 Nov 2017 10:06:32 -0500 Subject: [Smtk-developers] Follow-up on resource metadata In-Reply-To: <48A5E7AD-77FC-4221-AD95-AD75EEC0DB32@kitware.com> References: <165D4658-E62D-41C4-A44E-AB152E6E131B@kitware.com> <4E451ABA-9DDA-47CA-BC4C-6296EE9A7601@kitware.com> <45F15439-7300-4F63-8429-F5D709E2B853@kitware.com> <8F0112D9-D322-4584-8A20-87D46EE43292@kitware.com> <48A5E7AD-77FC-4221-AD95-AD75EEC0DB32@kitware.com> Message-ID: > On Nov 15, 2017, at 10:03 AM, David Thompson wrote: > > Hi TJ, > >>>> ... We could definitely subclass Metadata, but I don?t see why we need to. Currently, the create(), read() and write() functors are public fields that can be reassigned (once operators are more decoupled from smtk::model, they should become operators); as such, I don?t see any benefit to subclassing. >>> >>> My point is that every model resource should override create/read/write with the same 3 functors. It would be nice to inherit them. >> >> I?m not sure I follow. If we assume that the three functors are instead smtk::operator::Operators (which is my intention, as soon as smtk::operator::* is usable), then these three operators will need to be explicitly provided by whoever registers the resource. > > But at least the read and write operators will be the same for all: read = "load smtk model", write = "save smtk model". I thought that we agreed native model files would be handled by import/export operators. Ah, gotcha. That?s a pretty good reason to subclass Metadata for model resources. From tj.corona at kitware.com Fri Nov 17 08:23:11 2017 From: tj.corona at kitware.com (TJ Corona) Date: Fri, 17 Nov 2017 08:23:11 -0500 Subject: [Smtk-developers] Follow-up on resource metadata In-Reply-To: References: <165D4658-E62D-41C4-A44E-AB152E6E131B@kitware.com> <4E451ABA-9DDA-47CA-BC4C-6296EE9A7601@kitware.com> <45F15439-7300-4F63-8429-F5D709E2B853@kitware.com> <8F0112D9-D322-4584-8A20-87D46EE43292@kitware.com> <48A5E7AD-77FC-4221-AD95-AD75EEC0DB32@kitware.com> Message-ID: <8BCE54A7-C40D-4DE6-855D-60ADCA907AB6@kitware.com> Hi David, I was thinking about our conversation below, and how the ?load smtk model? and ?save smtk model? operators perform load and save operations for all sessions. These operations must either directly or indirectly defer to the sessions for the actual reading and writing by looking for operators with specific ?read? and ?write? names, right? I worry that the implicit requirement of the existence of operators with specific names could be confusing to new developers (it sure threw me for a loop with the Capstone session). Rather than having the resource manager call the ?load smtk model? and ?save smtk model? operators, do you think these operators could call the resource manager?s methods? That way, there is a single, explicitly declared location where the author of a resource must state how the resource is written and read to/from disk. Please let me know what you think! Sincerely, T.J. > On Nov 15, 2017, at 10:06 AM, TJ Corona wrote: > >> On Nov 15, 2017, at 10:03 AM, David Thompson wrote: >> >> Hi TJ, >> >>>>> ... We could definitely subclass Metadata, but I don?t see why we need to. Currently, the create(), read() and write() functors are public fields that can be reassigned (once operators are more decoupled from smtk::model, they should become operators); as such, I don?t see any benefit to subclassing. >>>> >>>> My point is that every model resource should override create/read/write with the same 3 functors. It would be nice to inherit them. >>> >>> I?m not sure I follow. If we assume that the three functors are instead smtk::operator::Operators (which is my intention, as soon as smtk::operator::* is usable), then these three operators will need to be explicitly provided by whoever registers the resource. >> >> But at least the read and write operators will be the same for all: read = "load smtk model", write = "save smtk model". I thought that we agreed native model files would be handled by import/export operators. > > Ah, gotcha. That?s a pretty good reason to subclass Metadata for model resources. From david.thompson at kitware.com Fri Nov 17 09:36:01 2017 From: david.thompson at kitware.com (David Thompson) Date: Fri, 17 Nov 2017 09:36:01 -0500 Subject: [Smtk-developers] Follow-up on resource metadata In-Reply-To: <8BCE54A7-C40D-4DE6-855D-60ADCA907AB6@kitware.com> References: <165D4658-E62D-41C4-A44E-AB152E6E131B@kitware.com> <4E451ABA-9DDA-47CA-BC4C-6296EE9A7601@kitware.com> <45F15439-7300-4F63-8429-F5D709E2B853@kitware.com> <8F0112D9-D322-4584-8A20-87D46EE43292@kitware.com> <48A5E7AD-77FC-4221-AD95-AD75EEC0DB32@kitware.com> <8BCE54A7-C40D-4DE6-855D-60ADCA907AB6@kitware.com> Message-ID: <6658703D-603B-448D-A782-821BAC1772BD@kitware.com> Hi TJ, > I was thinking about our conversation below, and how the ?load smtk model? and ?save smtk model? operators perform load and save operations for all sessions. These operations must either directly or indirectly defer to the sessions for the actual reading and writing by looking for operators with specific ?read? and ?write? names, right? Not entirely correct, but mostly. As part of loading the JSON file, they locate/create sessions (either existing ones in the model manager or create new ones via the SessionRegistrar) as specified in the file and then call createDelegate to get a SessionIODelegate object. If the session returns one, then a method is called on it to parse session-specific JSON. This **could** be (and was intended to be) a chance for the session to import native model files. However, the default implementation of the method asks the session for import/export operators by name. (I did not write that bit.) > I worry that the implicit requirement of the existence of operators with specific names could be confusing to new developers (it sure threw me for a loop with the Capstone session). Rather than having the resource manager call the ?load smtk model? and ?save smtk model? operators, do you think these operators could call the resource manager?s methods? I think you mean "the resource's methods." If so, that is possible and not objectionable, although I would prefer to return to original design above, with the exception that now the SessionRegistrar, not the model manager, would be queried for pre-existing sessions of the proper type. David From tj.corona at kitware.com Sat Nov 18 09:16:20 2017 From: tj.corona at kitware.com (TJ Corona) Date: Sat, 18 Nov 2017 09:16:20 -0500 Subject: [Smtk-developers] No nightly ES build for windows Message-ID: <65B7CE18-627B-4DC0-AE2E-2BE16CF0ECB8@kitware.com> Hi all, I do not understand why praxis did not post an ES master build last night. The packaging test succeeded , and the release build posted. How would I look into why the build didn?t upload? Sincerely, T.J. Thomas J. Corona, Ph.D. Kitware, Inc. Senior R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4443 -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.tourtellott at kitware.com Sat Nov 18 10:44:22 2017 From: john.tourtellott at kitware.com (John Tourtellott) Date: Sat, 18 Nov 2017 10:44:22 -0500 Subject: [Smtk-developers] No nightly ES build for windows In-Reply-To: <65B7CE18-627B-4DC0-AE2E-2BE16CF0ECB8@kitware.com> References: <65B7CE18-627B-4DC0-AE2E-2BE16CF0ECB8@kitware.com> Message-ID: I am 90% sure that the nightly's on Praxis redirect the console to log files. So if you can find the log file on Praxis... On Sat, Nov 18, 2017 at 9:16 AM, TJ Corona wrote: > Hi all, > > I do not understand why praxis did not post an ES master build last night. > The packaging test succeeded > , > and the release build posted. How would I look into why the build didn?t > upload? > > Sincerely, > T.J. > > Thomas J. Corona, Ph.D. > Kitware, Inc. > Senior R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4443 <(518)%20881-4443> > > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.tourtellott at kitware.com Sat Nov 18 11:06:39 2017 From: john.tourtellott at kitware.com (John Tourtellott) Date: Sat, 18 Nov 2017 11:06:39 -0500 Subject: [Smtk-developers] No nightly ES build for windows In-Reply-To: References: <65B7CE18-627B-4DC0-AE2E-2BE16CF0ECB8@kitware.com> Message-ID: Hmmm, the upload script seems to be looking at a different directory than where the build is done on Praxis. Ben made some changes to CMBDashboard yesterday to shorten path lengths again (I presume), but apparently something got missed. Some places were changed to a folder name "bme", others use "build-es". I presume that "bme" is the new one and should be used. I don't have time right now, but unless anyone objects, I'll double check this afternoon and update CMBDashboard (CTEST_BINARY_DIRECTORY in praxis-cmb-es-master.cmake). On Sat, Nov 18, 2017 at 10:44 AM, John Tourtellott < john.tourtellott at kitware.com> wrote: > I am 90% sure that the nightly's on Praxis redirect the console to log > files. So if you can find the log file on Praxis... > > On Sat, Nov 18, 2017 at 9:16 AM, TJ Corona wrote: > >> Hi all, >> >> I do not understand why praxis did not post an ES master build last >> night. The packaging test succeeded >> , >> and the release build posted. How would I look into why the build didn?t >> upload? >> >> Sincerely, >> T.J. >> >> Thomas J. Corona, Ph.D. >> Kitware, Inc. >> Senior R&D Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-881-4443 <(518)%20881-4443> >> >> >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/mailman/listinfo/smtk-developers >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.tourtellott at kitware.com Sat Nov 18 11:12:41 2017 From: john.tourtellott at kitware.com (John Tourtellott) Date: Sat, 18 Nov 2017 11:12:41 -0500 Subject: [Smtk-developers] No nightly ES build for windows In-Reply-To: References: <65B7CE18-627B-4DC0-AE2E-2BE16CF0ECB8@kitware.com> Message-ID: Oh, and to answer your original question, TJ, the console logs from nightly builds on Praxis can be found at C:\dashboards\nightly\logs On Sat, Nov 18, 2017 at 11:06 AM, John Tourtellott < john.tourtellott at kitware.com> wrote: > Hmmm, the upload script seems to be looking at a different directory than > where the build is done on Praxis. Ben made some changes to CMBDashboard > yesterday to shorten path lengths again (I presume), but apparently > something got missed. Some places were changed to a folder name "bme", > others use "build-es". I presume that "bme" is the new one and should be > used. I don't have time right now, but unless anyone objects, I'll double > check this afternoon and update CMBDashboard (CTEST_BINARY_DIRECTORY in > praxis-cmb-es-master.cmake). > > > On Sat, Nov 18, 2017 at 10:44 AM, John Tourtellott < > john.tourtellott at kitware.com> wrote: > >> I am 90% sure that the nightly's on Praxis redirect the console to log >> files. So if you can find the log file on Praxis... >> >> On Sat, Nov 18, 2017 at 9:16 AM, TJ Corona wrote: >> >>> Hi all, >>> >>> I do not understand why praxis did not post an ES master build last >>> night. The packaging test succeeded >>> , >>> and the release build posted. How would I look into why the build didn?t >>> upload? >>> >>> Sincerely, >>> T.J. >>> >>> Thomas J. Corona, Ph.D. >>> Kitware, Inc. >>> Senior R&D Engineer >>> 21 Corporate Drive >>> Clifton Park, NY 12065-8662 >>> Phone: 518-881-4443 <(518)%20881-4443> >>> >>> >>> _______________________________________________ >>> Smtk-developers mailing list >>> Smtk-developers at smtk.org >>> http://public.kitware.com/mailman/listinfo/smtk-developers >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.tourtellott at kitware.com Sat Nov 18 13:06:12 2017 From: john.tourtellott at kitware.com (John Tourtellott) Date: Sat, 18 Nov 2017 13:06:12 -0500 Subject: [Smtk-developers] No nightly ES build for windows In-Reply-To: References: <65B7CE18-627B-4DC0-AE2E-2BE16CF0ECB8@kitware.com> Message-ID: Change committed to cmake files in CMBDashboard repo. Fingers crossed... On Sat, Nov 18, 2017 at 11:12 AM, John Tourtellott < john.tourtellott at kitware.com> wrote: > Oh, and to answer your original question, TJ, the console logs from > nightly builds on Praxis can be found at C:\dashboards\nightly\logs > > On Sat, Nov 18, 2017 at 11:06 AM, John Tourtellott < > john.tourtellott at kitware.com> wrote: > >> Hmmm, the upload script seems to be looking at a different directory than >> where the build is done on Praxis. Ben made some changes to CMBDashboard >> yesterday to shorten path lengths again (I presume), but apparently >> something got missed. Some places were changed to a folder name "bme", >> others use "build-es". I presume that "bme" is the new one and should be >> used. I don't have time right now, but unless anyone objects, I'll double >> check this afternoon and update CMBDashboard (CTEST_BINARY_DIRECTORY in >> praxis-cmb-es-master.cmake). >> >> >> On Sat, Nov 18, 2017 at 10:44 AM, John Tourtellott < >> john.tourtellott at kitware.com> wrote: >> >>> I am 90% sure that the nightly's on Praxis redirect the console to log >>> files. So if you can find the log file on Praxis... >>> >>> On Sat, Nov 18, 2017 at 9:16 AM, TJ Corona >>> wrote: >>> >>>> Hi all, >>>> >>>> I do not understand why praxis did not post an ES master build last >>>> night. The packaging test succeeded >>>> , >>>> and the release build posted. How would I look into why the build didn?t >>>> upload? >>>> >>>> Sincerely, >>>> T.J. >>>> >>>> Thomas J. Corona, Ph.D. >>>> Kitware, Inc. >>>> Senior R&D Engineer >>>> 21 Corporate Drive >>>> Clifton Park, NY 12065-8662 >>>> Phone: 518-881-4443 <(518)%20881-4443> >>>> >>>> >>>> _______________________________________________ >>>> Smtk-developers mailing list >>>> Smtk-developers at smtk.org >>>> http://public.kitware.com/mailman/listinfo/smtk-developers >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tj.corona at kitware.com Sat Nov 18 14:49:08 2017 From: tj.corona at kitware.com (T.J. Corona) Date: Sat, 18 Nov 2017 14:49:08 -0500 Subject: [Smtk-developers] No nightly ES build for windows In-Reply-To: References: <65B7CE18-627B-4DC0-AE2E-2BE16CF0ECB8@kitware.com> Message-ID: Thanks for the info and the fix John! Sent from my iPhone > On Nov 18, 2017, at 1:06 PM, John Tourtellott wrote: > > Change committed to cmake files in CMBDashboard repo. Fingers crossed... > > >> On Sat, Nov 18, 2017 at 11:12 AM, John Tourtellott wrote: >> Oh, and to answer your original question, TJ, the console logs from nightly builds on Praxis can be found at C:\dashboards\nightly\logs >> >>> On Sat, Nov 18, 2017 at 11:06 AM, John Tourtellott wrote: >>> Hmmm, the upload script seems to be looking at a different directory than where the build is done on Praxis. Ben made some changes to CMBDashboard yesterday to shorten path lengths again (I presume), but apparently something got missed. Some places were changed to a folder name "bme", others use "build-es". I presume that "bme" is the new one and should be used. I don't have time right now, but unless anyone objects, I'll double check this afternoon and update CMBDashboard (CTEST_BINARY_DIRECTORY in praxis-cmb-es-master.cmake). >>> >>> >>>> On Sat, Nov 18, 2017 at 10:44 AM, John Tourtellott wrote: >>>> I am 90% sure that the nightly's on Praxis redirect the console to log files. So if you can find the log file on Praxis... >>>> >>>>> On Sat, Nov 18, 2017 at 9:16 AM, TJ Corona wrote: >>>>> Hi all, >>>>> >>>>> I do not understand why praxis did not post an ES master build last night. The packaging test succeeded, and the release build posted. How would I look into why the build didn?t upload? >>>>> >>>>> Sincerely, >>>>> T.J. >>>>> >>>>> Thomas J. Corona, Ph.D. >>>>> Kitware, Inc. >>>>> Senior R&D Engineer >>>>> 21 Corporate Drive >>>>> Clifton Park, NY 12065-8662 >>>>> Phone: 518-881-4443 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Smtk-developers mailing list >>>>> Smtk-developers at smtk.org >>>>> http://public.kitware.com/mailman/listinfo/smtk-developers >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.tourtellott at kitware.com Sun Nov 19 09:56:44 2017 From: john.tourtellott at kitware.com (John Tourtellott) Date: Sun, 19 Nov 2017 09:56:44 -0500 Subject: [Smtk-developers] No nightly ES build for windows In-Reply-To: References: <65B7CE18-627B-4DC0-AE2E-2BE16CF0ECB8@kitware.com> Message-ID: TJ et al, - I think the commit to CMBDashboard yesterday was the right fix. - However, ES master failed to build on Praxis last night. - But this time the problem is that Praxis is out of disk space. That's right, we've managed to fill the 1TB drive. - I presume there's alot we can delete on Praxis. I started by emptying the trash, which is at 20GB and counting... On Sat, Nov 18, 2017 at 2:49 PM, T.J. Corona wrote: > Thanks for the info and the fix John! > > Sent from my iPhone > > On Nov 18, 2017, at 1:06 PM, John Tourtellott < > john.tourtellott at kitware.com> wrote: > > Change committed to cmake files in CMBDashboard repo. Fingers crossed... > > > On Sat, Nov 18, 2017 at 11:12 AM, John Tourtellott < > john.tourtellott at kitware.com> wrote: > >> Oh, and to answer your original question, TJ, the console logs from >> nightly builds on Praxis can be found at C:\dashboards\nightly\logs >> >> On Sat, Nov 18, 2017 at 11:06 AM, John Tourtellott < >> john.tourtellott at kitware.com> wrote: >> >>> Hmmm, the upload script seems to be looking at a different directory >>> than where the build is done on Praxis. Ben made some changes to >>> CMBDashboard yesterday to shorten path lengths again (I presume), but >>> apparently something got missed. Some places were changed to a folder name >>> "bme", others use "build-es". I presume that "bme" is the new one and >>> should be used. I don't have time right now, but unless anyone objects, >>> I'll double check this afternoon and update CMBDashboard >>> (CTEST_BINARY_DIRECTORY in praxis-cmb-es-master.cmake). >>> >>> >>> On Sat, Nov 18, 2017 at 10:44 AM, John Tourtellott < >>> john.tourtellott at kitware.com> wrote: >>> >>>> I am 90% sure that the nightly's on Praxis redirect the console to log >>>> files. So if you can find the log file on Praxis... >>>> >>>> On Sat, Nov 18, 2017 at 9:16 AM, TJ Corona >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I do not understand why praxis did not post an ES master build last >>>>> night. The packaging test succeeded >>>>> , >>>>> and the release build posted. How would I look into why the build didn?t >>>>> upload? >>>>> >>>>> Sincerely, >>>>> T.J. >>>>> >>>>> Thomas J. Corona, Ph.D. >>>>> Kitware, Inc. >>>>> Senior R&D Engineer >>>>> 21 Corporate Drive >>>>> >>>>> Clifton Park, NY 12065 >>>>> >>>>> -8662 >>>>> Phone: 518-881-4443 <(518)%20881-4443> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Smtk-developers mailing list >>>>> Smtk-developers at smtk.org >>>>> http://public.kitware.com/mailman/listinfo/smtk-developers >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tj.corona at kitware.com Mon Nov 20 08:37:31 2017 From: tj.corona at kitware.com (TJ Corona) Date: Mon, 20 Nov 2017 08:37:31 -0500 Subject: [Smtk-developers] No nightly ES build for windows In-Reply-To: References: <65B7CE18-627B-4DC0-AE2E-2BE16CF0ECB8@kitware.com> Message-ID: Hi John, Success! Last night?s ES Master is up on data.kitware.com . Thanks again for looking into this! Sincerely, T.J. > On Nov 19, 2017, at 9:56 AM, John Tourtellott wrote: > > TJ et al, > I think the commit to CMBDashboard yesterday was the right fix. > However, ES master failed to build on Praxis last night. > But this time the problem is that Praxis is out of disk space. That's right, we've managed to fill the 1TB drive. > I presume there's alot we can delete on Praxis. I started by emptying the trash, which is at 20GB and counting... > > On Sat, Nov 18, 2017 at 2:49 PM, T.J. Corona > wrote: > Thanks for the info and the fix John! > > Sent from my iPhone > > On Nov 18, 2017, at 1:06 PM, John Tourtellott > wrote: > >> Change committed to cmake files in CMBDashboard repo. Fingers crossed... >> >> >> On Sat, Nov 18, 2017 at 11:12 AM, John Tourtellott > wrote: >> Oh, and to answer your original question, TJ, the console logs from nightly builds on Praxis can be found at C:\dashboards\nightly\logs >> >> On Sat, Nov 18, 2017 at 11:06 AM, John Tourtellott > wrote: >> Hmmm, the upload script seems to be looking at a different directory than where the build is done on Praxis. Ben made some changes to CMBDashboard yesterday to shorten path lengths again (I presume), but apparently something got missed. Some places were changed to a folder name "bme", others use "build-es". I presume that "bme" is the new one and should be used. I don't have time right now, but unless anyone objects, I'll double check this afternoon and update CMBDashboard (CTEST_BINARY_DIRECTORY in praxis-cmb-es-master.cmake). >> >> >> On Sat, Nov 18, 2017 at 10:44 AM, John Tourtellott > wrote: >> I am 90% sure that the nightly's on Praxis redirect the console to log files. So if you can find the log file on Praxis... >> >> On Sat, Nov 18, 2017 at 9:16 AM, TJ Corona > wrote: >> Hi all, >> >> I do not understand why praxis did not post an ES master build last night. The packaging test succeeded , and the release build posted. How would I look into why the build didn?t upload? >> >> Sincerely, >> T.J. >> >> Thomas J. Corona, Ph.D. >> Kitware, Inc. >> Senior R&D Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065 -8662 >> Phone: 518-881-4443 >> >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/mailman/listinfo/smtk-developers >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Wed Nov 22 15:56:52 2017 From: david.thompson at kitware.com (David Thompson) Date: Wed, 22 Nov 2017 15:56:52 -0500 Subject: [Smtk-developers] Operation manaer Message-ID: <2375E4DD-782A-4EC7-96D0-55C333584B6F@kitware.com> Hi all (but esp. TJ since you are working on it), Should the resource manager own an operation manager? Arguments for: 1. Resources will be read in by operations which resource metadata may point to. These operators should be managed by the same thing, not different ones or inconsistencies may creep in and cause difficult-to-diagnose bugs. 2. Operators are expected to register their acceptable inputs (and maybe outputs some day). Currently inputs can only be specified in terms of their SMTK representation (e.g., I only accept SMTK model edges) and not modeling kernel data (e.g., I only accept polygon-session model edges). We are talking about moving to a system where operators specify kernel-specific inputs using smtk::resource::Index values. But the mapping between these values and their associated metadata are aggregated by the resource manager. 3. It makes life easy for application developers. Arguments agains: 1. Resource metadata may use any means to read/write/create resources and there is nothing currently that constrains these methods to use the same operation manager (or any at all, although at some point something has to own an attribute collection specifying operator defs -- the operators themselves don't). 2. Maybe there's something clever we can do to reference ResourceSubclass::Index at build time to explicitly register operators? 3. It constrains application developers (but I'm not sure whether it is a significant constraint). David From david.thompson at kitware.com Thu Nov 30 11:03:57 2017 From: david.thompson at kitware.com (David Thompson) Date: Thu, 30 Nov 2017 11:03:57 -0500 Subject: [Smtk-developers] Heads up Message-ID: <22C1C49A-BB60-4C5A-9D49-D8425C029B9F@kitware.com> Hi all, I've just merged some changes to SMTK that might be of interest. Notably, + Adds an abstract PhraseModel class and a concrete ResourcePhraseModel class. A PhraseModel owns a DescriptivePhrase hierarchy and the SubphraseGenerator instances attached to it. The PhraseModel class maintains the hierarchy as operations and selections are performed by users. A PhraseModel may be configured by an smtk::view::View instance. PhraseModel provides some methods for its children to override that make managing the hierarchy much simpler. In particular, you may call updateChildren() on the phrase model and it will call observers (such as the new qtDescriptivePhraseModel) with a sequence of insert/remove/move changes that will update the GUI. + Adds a JSON deserialization for smtk::view::View and test that it matches the equivalent XML description. + Adds an observe() method to resource manager. Now it is possible to get notified when a resource is added/removed. Note that the notification comes *after* the operation that reads the resource has completed, so if you are observing the operation manager and the resource manager, you may be surprised at the order in which your listeners are called. + Both resources and resource managers are tracked with instances of pqProxy subclasses. + Adds a ParaView plugin panel that presents resources in a model-tree view. This has a bug currently where each resource is presented twice, but I'll fix that shortly. + Minimal registration of the model manager and attribute collection to the resource manager (no read/write/create methods are supplied) so that the resource manager can hold these resources. + Adds a DescriptivePhrase::visitChildren() method for traversing a phrase hierarchy. + Fixes issues with operator result creation. Model operators still need to use their Session's attribute collection to create the result while the new-style operators should use the operator manager. This will change again when the new operation manager is modified to use an attribute collection per operator rather than a single instance for the manager. + Implement more of ComponentItemDefinition and partially implement XML I/O of attributes with ComponentItems. (The associated components of an attribute are still not synchronized/serialized/deserialized, but child items of the attribute should be.) + Provides some model-operator-specific code to copy result summary items from ModelEntityItems to ComponentItems with similar names (now also defined in Session.cxx). In the long term, ModelEntityItem should disappear. + Makes Resource store a weak pointer to its manager, not a raw pointer. Since the manager may not hold the only shared pointer to a resource, the resource may outlive its manager and should still behave. I tested CMB's ModelBuilder against this before merging and all but the usual suspects passed, so we should be OK bumping CMB to use these changes. David