From ben.boeckel at kitware.com Thu Feb 2 14:52:14 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 2 Feb 2017 14:52:14 -0500 Subject: [Smtk-developers] New merge request robot behaviors Message-ID: <20170202195214.GA12927@megas.kitware.com> Hi all, Recently, Brad and I have been working on revamping the kwrobot from its initial implementation. It now has unit tests and its source is available (see below). In addition, buildbot will be changing its default behavior from "test this and all future updates" to "test just this update". Basically, `--oneshot` is now assumed and the flag itself is ignored. This was announced a while ago without any disagreements, but is finally going into effect. Merge requests will need the new robot to check them. It will do this if the merge request changes or on a manual `Do: check`. # What does this mean for me? Ideally, not much. The only behavior changes (should) be: - If you select "Delete source branch" when creating a merge request, the robot will now delete it for you when it is merged. - No more "Failed to merge the tree because ???" errors. - Failures in git commits are now formatted better with Markdown rather than dumped out as a pre-formatted block. - The kwrobot user will mark comments with `Do:` commands with a robot emoji (?) to indicate that it handled the command. In the case of success, it will *not* make its own comment (buildbot will still make its comment for `Do: test` commands), but instead just do the action and put a status check on the latest commit on the merge request. - No more race conditions; saying `Do: test` before kwrobot gives its pass/fail check will not be ignored. - Lighter buildbot loads by only building explicitly requested merge requests. # Why this new code? The original robot was written with VTK and ParaView's workflows in mind, however the goal of porting the CMake workflow over exposed severe design limitations in it. With its lack of a test suite, it made making those changes potentially dangerous. It also lacked logging and robustness against errors, as evidenced by the "Failed to merge" problems of late. # Where can I report issues? In general, on the [ghostflow-director issues][] page. We may move your issue to a different repository depending on where it belongs. # Where is the code? All of the repositories are available under the [utils group][]. A general breakdown for the repositories relevant to the VTK, VTK-m, ParaView, and CMB projects: - rust-git-workarea: contains core building blocks for operations used elsewhere - rust-git-checks: checks performed for on git commits - rust-gitlab: communication with Gitlab - rust-ghostflow: implementation of the `Do:` commands (check, test, merge, ExternalData sync); mechanisms of the workflow live here - webhook-listen: listens for webhook events from Gitlab - ghostflow-director: the robot itself; handles jobs from Gitlab and performs the relevant actions; policies of the workflow live here Thanks, --Ben [ghostflow-director issues]: https://gitlab.kitware.com/utils/ghostflow-director/issues [utils group]: https://gitlab.kitware.com/groups/utils From bob.obara at kitware.com Fri Feb 3 14:32:20 2017 From: bob.obara at kitware.com (Bob Obara) Date: Fri, 3 Feb 2017 14:32:20 -0500 Subject: [Smtk-developers] 10.12 SDK and OpenCascade Message-ID: <376D7E60-62CC-43D6-95D5-B77BEA34280D@kitware.com> Hi All, For those of you who are building on the Mac, I just noticed that OpenCASCADE will not compile using Xcode?s 10.12 SDK (it will work using 10.11). The issue is that Apple now defines some of the time enums used in OCE. So if you are upgrading Xcode and want to build OpenCASCADE support make sure you have copied the 10.11 SDK and have put it in a safe place! Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michalwozniak at live.ca Fri Feb 24 13:08:15 2017 From: michalwozniak at live.ca (michal wozniak) Date: Fri, 24 Feb 2017 18:08:15 +0000 Subject: [Smtk-developers] Cmb superbuild gcm symbols Message-ID: Hi, Is someone working on https://gitlab.kitware.com/cmb/cmb-superbuild/issues/59 ? I can't build the cmb superbuild if gcm is enabled. Is this issue going to be fixed soon? I tried to export the required symbol by modifying a couple of cmakelists but was unsuccessful. Thanks Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From haocheng.liu at kitware.com Fri Feb 24 17:17:05 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Fri, 24 Feb 2017 17:17:05 -0500 Subject: [Smtk-developers] Cmb superbuild gcm symbols In-Reply-To: References: Message-ID: Hi michal, As far as I now, so far no one is working on this issue and CGM session also has some issues with VS 2015 compiler. If you want to use CGM session, Linux and mac are fine with it. Hope it helps. best regards Haocheng On Fri, Feb 24, 2017 at 1:08 PM, michal wozniak wrote: > Hi, > > Is someone working on https://gitlab.kitware.com/ > cmb/cmb-superbuild/issues/59 ? > > I can't build the cmb superbuild if gcm is enabled. Is this issue going to > be fixed soon? I tried to export the required symbol by modifying a couple > of cmakelists but was unsuccessful. > > Thanks > Michal > > _______________________________________________ > 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 Fri Feb 24 17:26:49 2017 From: bob.obara at kitware.com (Bob Obara) Date: Fri, 24 Feb 2017 17:26:49 -0500 Subject: [Smtk-developers] Possible new way of dealing with color Message-ID: <93A9211F-3041-4B13-8847-EF7FF18DDD01@kitware.com> Hi All, We are in the process of cleaning up the color mechanism of CMB. The main issue we are trying to address is the following: Introduce ?default colors? for various model entity types (vertices, edges, faces, volumes, etc..) - For example being able to say all edges by default are to be blue while all faces should be white The ability to specify the color for the specific model entity The ability to tell default color from explicit color The Upper Left Image is the current Model Tree Display - the main problems I have with this is the following: You can?t tell if the model entities colors are white (or in this case unset) - also the fact that the colors have actually been assigned randomly as their defaults The icon is suppose to indicate if its a volume, face, edge, vertex, model, group, etc? We never did follow through with this patter and as a result the icon doesn?t have a lot of meaning Setting the color of a session or model doesn?t have an effect on rendering the geometry My first alternative (Left Middle) was to make the icon more of a defined area my enclosing then - in fact my complete idea was to dashed the circle to indicate the fact that the color was not explicitly set and was being inherited but when I showed people it was not obvious that was what I meant The third option removed the icon and used a simple circle to indicate color. This is expanded on the right side where Vol 1 is explicitly green and Vol 2 is explicitly yellow. Vols 3 and 4 are inheriting the default blue color of Element Blocks indicated by the hashed circle. Comments? Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: NewModelColorPanel.png Type: image/png Size: 112223 bytes Desc: not available URL: From jonathan.borduas at caboma.com Fri Feb 24 17:48:42 2017 From: jonathan.borduas at caboma.com (Jonathan Borduas) Date: Fri, 24 Feb 2017 22:48:42 +0000 Subject: [Smtk-developers] Cmb superbuild gcm symbols In-Reply-To: References: Message-ID: Hello all, I?m a colleague of Michal. Over the past few weeks we have been asking about the status of export CGM symbol in Windows. We received some proposition to fix the problem but were unsuccessful in implementing them. We really need this software to run on Windows and since we see that this task is in your backlog, I think we could meet a Win-Win situation there. With the implementation of a single working extract symbol from the community, it would kick-start us and we would be ready to implement the rest of them, making the superbuild of CGM compatible with Windows again. Best regards Jonathan Borduas CTO, Caboma Inc. From: Smtk-developers [mailto:smtk-developers-bounces at smtk.org] On Behalf Of Haocheng Liu Sent: Friday, February 24, 2017 5:17 PM To: michal wozniak Cc: smtk-developers at smtk.org Subject: Re: [Smtk-developers] Cmb superbuild gcm symbols Hi michal, As far as I now, so far no one is working on this issue and CGM session also has some issues with VS 2015 compiler. If you want to use CGM session, Linux and mac are fine with it. Hope it helps. best regards Haocheng On Fri, Feb 24, 2017 at 1:08 PM, michal wozniak > wrote: Hi, Is someone working on https://gitlab.kitware.com/cmb/cmb-superbuild/issues/59 ? I can't build the cmb superbuild if gcm is enabled. Is this issue going to be fixed soon? I tried to export the required symbol by modifying a couple of cmakelists but was unsuccessful. Thanks Michal _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Sat Feb 25 18:53:34 2017 From: david.thompson at kitware.com (David Thompson) Date: Sat, 25 Feb 2017 18:53:34 -0500 Subject: [Smtk-developers] Possible new way of dealing with color In-Reply-To: <93A9211F-3041-4B13-8847-EF7FF18DDD01@kitware.com> References: <93A9211F-3041-4B13-8847-EF7FF18DDD01@kitware.com> Message-ID: > ... > ? Introduce ?default colors? for various model entity types (vertices, edges, faces, volumes, etc..) - For example being able to say all edges by default are to be blue while all faces should be white > ? The ability to specify the color for the specific model entity > ? The ability to tell default color from explicit color > > > The Upper Left Image is the current Model Tree Display - the main problems I have with this is the following: > ? You can?t tell if the model entities colors are white (or in this case unset) - also the fact that the colors have actually been assigned randomly as their defaults Agreed. > ? The icon is suppose to indicate if its a volume, face, edge, vertex, model, group, etc? We never did follow through with this patter and as a result the icon doesn?t have a lot of meaning I would prefer to keep them because 1. I suspect we are about to get icons for the different entity types shortly ("Filter By" feature) 2. Because some sessions (e.g., exodus) present tessellations on groups or other entity types that may not be intuitive, the "Filter By" feature will benefit from tree views where the entity type is shown using the same icon. 3. It is a fast and simple change once we actually have the icons. > ? Setting the color of a session or model doesn?t have an effect on rendering the geometry > > ... > > The third option removed the icon and used a simple circle to indicate color. This is expanded on the right side where Vol 1 is explicitly green and Vol 2 is explicitly yellow. Vols 3 and 4 are inheriting the default blue color of Element Blocks indicated by the hashed circle. I like it. However, note that the Exodus reader creates those groups ("Node Sets", "Side Sets", "Element Blocks") explicitly since they are part of the file. The "Topology View" won't always have those same groups. The "Entity List View" will, and it will be easier to attach functions that set color defaults to them compared to the Exodus session groups. Since I believe CMB defaults to the "Entity List View," this should be fine. Where did you want the "default" or "inheritable" colors stored? As application settings (which then belong in CMB, not SMTK), per-session settings, per-model settings, per-group settings (which is what you have shown, but we do not currently create default groups and assign entities there)? If we use the "set entity property" operator to store the default colors (as well as per-entity colors), then it will be easier for the VTK adaptor to assign per-block colors. This would be easiest if we set default colors as properties on the model since CMB currently creates a VTK adaptor per model and groups all entities of the same type into one block of its output multiblock dataset (making it easy to discover the default color given only the VTK dataset). David From bob.obara at kitware.com Sun Feb 26 15:39:08 2017 From: bob.obara at kitware.com (Bob Obara) Date: Sun, 26 Feb 2017 15:39:08 -0500 Subject: [Smtk-developers] Possible new way of dealing with color In-Reply-To: References: <93A9211F-3041-4B13-8847-EF7FF18DDD01@kitware.com> Message-ID: Hey David, You raised some good points - see below. Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On Feb 25, 2017, at 6:53 PMEST, David Thompson wrote: > >> ... >> ? Introduce ?default colors? for various model entity types (vertices, edges, faces, volumes, etc..) - For example being able to say all edges by default are to be blue while all faces should be white >> ? The ability to specify the color for the specific model entity >> ? The ability to tell default color from explicit color >> >> >> The Upper Left Image is the current Model Tree Display - the main problems I have with this is the following: >> ? You can?t tell if the model entities colors are white (or in this case unset) - also the fact that the colors have actually been assigned randomly as their defaults > > Agreed. > >> ? The icon is suppose to indicate if its a volume, face, edge, vertex, model, group, etc? We never did follow through with this patter and as a result the icon doesn?t have a lot of meaning > > I would prefer to keep them because > > 1. I suspect we are about to get icons for the different entity types shortly ("Filter By" feature) > > 2. Because some sessions (e.g., exodus) present tessellations on groups or other entity types that may not be intuitive, the "Filter By" feature will benefit from tree views where the entity type is shown using the same icon. > I was thinking of the Exodus Session - what do you think of having the Exodus Session create faces for each side set and a volume for each element block? This way the session looks like all the other ones? In the future we could create an operator that would create proper partitioned model faces (as well as creating model edges and vertices) What do you think? > 3. It is a fast and simple change once we actually have the icons. > If we did stick with icons then we should provide the ability for a workflow to be able to swap them out - for example in Hydrology the edge symbol could be made to look like a coast line. The one thing is that they should be B/W images) >> ? Setting the color of a session or model doesn?t have an effect on rendering the geometry >> >> ... >> >> The third option removed the icon and used a simple circle to indicate color. This is expanded on the right side where Vol 1 is explicitly green and Vol 2 is explicitly yellow. Vols 3 and 4 are inheriting the default blue color of Element Blocks indicated by the hashed circle. > > I like it. However, note that the Exodus reader creates those groups ("Node Sets", "Side Sets", "Element Blocks") explicitly since they are part of the file. The "Topology View" won't always have those same groups. The "Entity List View" will, and it will be easier to attach functions that set color defaults to them compared to the Exodus session groups. My suggestion above would address this. > > Since I believe CMB defaults to the "Entity List View," this should be fine. > > Where did you want the "default" or "inheritable" colors stored? As application settings (which then belong in CMB, not SMTK), per-session settings, per-model settings, per-group settings (which is what you have shown, but we do not currently create default groups and assign entities there)? > > If we use the "set entity property" operator to store the default colors (as well as per-entity colors), then it will be easier for the VTK adaptor to assign per-block colors. This would be easiest if we set default colors as properties on the model since CMB currently creates a VTK adaptor per model and groups all entities of the same type into one block of its output multiblock dataset (making it easy to discover the default color given only the VTK dataset). I think that the default colors should be stored in the model?s SMTK file - the application would have a preference for what the application would set the default colors would be for new models being created. I guess we could have in the future a per session set of default colors. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: