From bob.obara at kitware.com Mon Sep 4 17:05:59 2017 From: bob.obara at kitware.com (Bob Obara) Date: Mon, 4 Sep 2017 17:05:59 -0400 Subject: [Smtk-developers] SetupForDeveloper has an error Message-ID: <4903F80E-4180-472C-AE7E-B76377C30AD5@kitware.com> Hi Ben, When rerunning setup I got the following: Low level commands ------------------- * git lfs clean: Git clean filter that converts large files to pointers. * git lfs pointer: Build and compare pointers. * git lfs pre-push: Git pre-push hook implementation. * git lfs smudge: Git smudge filter that converts pointer in blobs to the actual content. Error: unknown flag: ?version It seems to setup things correctly 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 bob.obara at kitware.com Mon Sep 11 16:38:41 2017 From: bob.obara at kitware.com (Bob Obara) Date: Mon, 11 Sep 2017 16:38:41 -0400 Subject: [Smtk-developers] JSON in SMTK Message-ID: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> Hi Folks, It seems that we are using a C - library for JSON processing - has anyone looked at C++ 11 libs like: https://github.com/nlohmann/json 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 haocheng.liu at kitware.com Mon Sep 11 16:48:09 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Mon, 11 Sep 2017 16:48:09 -0400 Subject: [Smtk-developers] JSON in SMTK In-Reply-To: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> References: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> Message-ID: Hi Bob, On Mon, Sep 11, 2017 at 4:38 PM, Bob Obara wrote: > Hi Folks, > > It seems that we are using a C - library for JSON processing - has anyone > looked at C++ 11 libs like: > > https://github.com/nlohmann/json > > I know ADIOS2 is using nlohmann to parse json data and it works well for the tests I added. > 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 <(518)%20881-4931> > > > > > > _______________________________________________ > 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 ben.boeckel at kitware.com Mon Sep 11 16:48:48 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 11 Sep 2017 16:48:48 -0400 Subject: [Smtk-developers] JSON in SMTK In-Reply-To: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> References: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> Message-ID: <20170911204848.GA16917@megas.kitware.com> On Mon, Sep 11, 2017 at 16:38:41 -0400, Bob Obara wrote: > It seems that we are using a C - library for JSON processing - has > anyone looked at C++ 11 libs like: > > https://github.com/nlohmann/json Could we standardize with other Kitware projects on the same JSON libraries rather than just moving to a different camp? VTK and CMake both already use jsoncpp and it is prepped for proper mangling already by VTK: https://gitlab.kitware.com/third-party/jsoncpp --Ben From john.tourtellott at kitware.com Mon Sep 11 17:43:48 2017 From: john.tourtellott at kitware.com (John Tourtellott) Date: Mon, 11 Sep 2017 17:43:48 -0400 Subject: [Smtk-developers] JSON in SMTK In-Reply-To: <20170911204848.GA16917@megas.kitware.com> References: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> <20170911204848.GA16917@megas.kitware.com> Message-ID: If we standardize on a json library, this one would rank pretty high on my list, mostly because (i) it supports a compact/binary format, and (ii) it supports incremental parsing. (I keep thinking that we will someday be sending big data via json, I guess). Main downside is weak documentation, same as every other json library I've seen... On Mon, Sep 11, 2017 at 4:48 PM, Ben Boeckel wrote: > On Mon, Sep 11, 2017 at 16:38:41 -0400, Bob Obara wrote: > > It seems that we are using a C - library for JSON processing - has > > anyone looked at C++ 11 libs like: > > > > https://github.com/nlohmann/json > > Could we standardize with other Kitware projects on the same JSON > libraries rather than just moving to a different camp? > > VTK and CMake both already use jsoncpp and it is prepped for proper > mangling already by VTK: > > https://gitlab.kitware.com/third-party/jsoncpp > > --Ben > _______________________________________________ > 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 Sep 11 18:24:46 2017 From: david.thompson at kitware.com (David Thompson) Date: Mon, 11 Sep 2017 18:24:46 -0400 Subject: [Smtk-developers] JSON in SMTK In-Reply-To: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> References: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> Message-ID: <88F0D80E-B269-4C41-9C9D-1165B53D40A4@kitware.com> > It seems that we are using a C - library for JSON processing - has anyone looked at C++ 11 libs like: > https://github.com/nlohmann/json It looks nice. I would like to kick the tires a little, but it looks good enough to replace cJSON if it doesn't have any fatal flaws. @Ben jsoncpp is really terrible: + it is not concise to use (I'm not sure nlohmann is either because it lives in the "nlohmann" namespace); + it is slow -- see https://github.com/miloyip/nativejson-benchmark#parsing-time where cJSON takes 25ms and jsoncpp takes 166ms; nlohmann takes 71 ms which is not great but look at how easy it is to use; and + it is heavy (243k-LOC vs 42k for nlohmann and 27k for cJSON) We should help move CMake/VTK away from jsoncpp instead of designing software by seniority. David From haocheng.liu at kitware.com Tue Sep 12 09:49:27 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Tue, 12 Sep 2017 09:49:27 -0400 Subject: [Smtk-developers] JSON in SMTK In-Reply-To: <88F0D80E-B269-4C41-9C9D-1165B53D40A4@kitware.com> References: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> <88F0D80E-B269-4C41-9C9D-1165B53D40A4@kitware.com> Message-ID: On Mon, Sep 11, 2017 at 6:24 PM, David Thompson wrote: > > It seems that we are using a C - library for JSON processing - has > anyone looked at C++ 11 libs like: > > https://github.com/nlohmann/json > > It looks nice. I would like to kick the tires a little, but it looks good > enough to replace cJSON if it doesn't have any fatal flaws. > > @Ben jsoncpp is really terrible: > + it is not concise to use (I'm not sure nlohmann is either because it > lives in the "nlohmann" namespace); > + it is slow -- see https://github.com/miloyip/ > nativejson-benchmark#parsing-time where cJSON takes 25ms and jsoncpp > takes 166ms; nlohmann takes 71 ms which is not great but look at how easy > it is to use; and > + it is heavy (243k-LOC vs 42k for nlohmann and 27k for cJSON) > > We should help move CMake/VTK away from jsoncpp instead of designing > software by seniority. > While browsing, I come across this data serization format as protobuf developed by Google. It's four times faster than JSON and using much less space . Is there any reason why we stick to JSON or can we move to a better data format? 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 sebastien.jourdain at kitware.com Tue Sep 12 10:22:02 2017 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Tue, 12 Sep 2017 08:22:02 -0600 Subject: [Smtk-developers] JSON in SMTK In-Reply-To: References: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> <88F0D80E-B269-4C41-9C9D-1165B53D40A4@kitware.com> Message-ID: Protobuf is used inside ParaView for the message format over the network. I think the question here is related about reading (and maybe writing) JSON (configuration) files which is different than what protobuf has to offer. Just my 2 cents... Seb On Tue, Sep 12, 2017 at 7:49 AM, Haocheng Liu wrote: > > > On Mon, Sep 11, 2017 at 6:24 PM, David Thompson < > david.thompson at kitware.com> wrote: > >> > It seems that we are using a C - library for JSON processing - has >> anyone looked at C++ 11 libs like: >> > https://github.com/nlohmann/json >> >> It looks nice. I would like to kick the tires a little, but it looks good >> enough to replace cJSON if it doesn't have any fatal flaws. >> >> @Ben jsoncpp is really terrible: >> + it is not concise to use (I'm not sure nlohmann is either because it >> lives in the "nlohmann" namespace); >> + it is slow -- see https://github.com/miloyip/nat >> ivejson-benchmark#parsing-time where cJSON takes 25ms and jsoncpp takes >> 166ms; nlohmann takes 71 ms which is not great but look at how easy it is >> to use; and >> + it is heavy (243k-LOC vs 42k for nlohmann and 27k for cJSON) >> >> We should help move CMake/VTK away from jsoncpp instead of designing >> software by seniority. >> > While browsing, I come across this data serization format as protobuf > developed by Google. It's four times faster > than JSON and using much less space > . Is > there any reason why we stick to JSON or can we move to a better data > format? > > 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> > > _______________________________________________ > 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 Tue Sep 12 10:24:15 2017 From: david.thompson at kitware.com (David Thompson) Date: Tue, 12 Sep 2017 10:24:15 -0400 Subject: [Smtk-developers] JSON in SMTK In-Reply-To: References: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> <88F0D80E-B269-4C41-9C9D-1165B53D40A4@kitware.com> Message-ID: <12FF142A-F27B-438E-9096-759D95C86F6F@kitware.com> > ...While browsing, I come across this data serization format as protobuf developed by Google. It's four times faster than JSON and using much less space. Is there any reason why we stick to JSON or can we move to a better data format? JSON is a standard and widely accepted. Until flatbuffers is omnipresent, I would be hesitant to depend on it. I suspect that nlohmann's binary format is significantly faster than string parsing. David From ben.boeckel at kitware.com Tue Sep 12 10:38:44 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 12 Sep 2017 10:38:44 -0400 Subject: [Smtk-developers] JSON in SMTK In-Reply-To: <88F0D80E-B269-4C41-9C9D-1165B53D40A4@kitware.com> References: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> <88F0D80E-B269-4C41-9C9D-1165B53D40A4@kitware.com> Message-ID: <20170912143844.GA4843@megas.kitware.com> On Mon, Sep 11, 2017 at 18:24:46 -0400, David Thompson wrote: > @Ben jsoncpp is really terrible: > + it is not concise to use (I'm not sure nlohmann is either because it lives in the "nlohmann" namespace); What do you mean by "concise"? > + it is slow -- see > https://github.com/miloyip/nativejson-benchmark#parsing-time where > cJSON takes 25ms and jsoncpp takes 166ms; nlohmann takes 71 ms which > is not great but look at how easy it is to use; and Those results are from 2015 which I'll considere "out of date" to say the least. I'm running it again today. Even so, is performance that much of an issue? I'm more worried about the maintenance side. If it isn't jsoncpp, someone else needs to do the mangling and preparation of the library for inclusion. > + it is heavy (243k-LOC vs 42k for nlohmann and 27k for cJSON) I suspect that's a naive count. In VTK, it is alagamated into a single file: % sloccount ThirdParty/jsoncpp/vtkjsoncpp Creating filelist for vtkjsoncpp Categorizing files. Finding a working MD5 command.... Found a working MD5 command. Computing results. SLOC Directory SLOC-by-Language (Sorted) 5464 vtkjsoncpp cpp=5464 Totals grouped by language (dominant language first): cpp: 5464 (100.00%) > We should help move CMake/VTK away from jsoncpp instead of designing > software by seniority. CMake can move whenever; it doesn't have it in its API. VTK is harder. FWIW, ITK is also using jsoncpp. --Ben From ben.boeckel at kitware.com Tue Sep 12 11:37:32 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 12 Sep 2017 11:37:32 -0400 Subject: [Smtk-developers] JSON in SMTK In-Reply-To: <20170912143844.GA4843@megas.kitware.com> References: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> <88F0D80E-B269-4C41-9C9D-1165B53D40A4@kitware.com> <20170912143844.GA4843@megas.kitware.com> Message-ID: <20170912153732.GA26627@megas.kitware.com> On Tue, Sep 12, 2017 at 10:38:44 -0400, Ben Boeckel wrote: > > + it is slow -- see > > https://github.com/miloyip/nativejson-benchmark#parsing-time where > > cJSON takes 25ms and jsoncpp takes 166ms; nlohmann takes 71 ms which > > is not great but look at how easy it is to use; and > > Those results are from 2015 which I'll considere "out of date" to say the > least. I'm running it again today. Even so, is performance that much of an > issue? I'm more worried about the maintenance side. If it isn't jsoncpp, > someone else needs to do the mangling and preparation of the library for > inclusion. I have new benchmarks. And the benchmarks are by no means comprehensive, but looking at details, it makes it obvious where some deficiencies in jsoncpp is (compared to rapidjson at least). And FWIW, cJSON and nlohmann have the same weak point. I would be hesitant to base any conclusions on the benchmark solely. It tests a grand total of 3 files for performance and I suspect the "hard" one is really there just to showcase rapidjson rather than be an actual test case? The conformance tests are of interest though (and I doubt the comprehensiveness of the corpus there as well). More at 1 :) . --Ben From ben.boeckel at kitware.com Wed Sep 13 10:46:49 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 13 Sep 2017 10:46:49 -0400 Subject: [Smtk-developers] Changelog thread on paraview-developers Message-ID: <20170913144649.GA19551@megas.kitware.com> Hi, I've posted to paraview-developers about a proposed changelog process for ParaView. CMB (and SMTK?) would probably adopt it as well, so if you'd like to chime in, please do so. --Ben From david.thompson at kitware.com Wed Sep 13 17:37:49 2017 From: david.thompson at kitware.com (David Thompson) Date: Wed, 13 Sep 2017 17:37:49 -0400 Subject: [Smtk-developers] JSON in SMTK In-Reply-To: <20170912153732.GA26627@megas.kitware.com> References: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> <88F0D80E-B269-4C41-9C9D-1165B53D40A4@kitware.com> <20170912143844.GA4843@megas.kitware.com> <20170912153732.GA26627@megas.kitware.com> Message-ID: Hi all, I've looked a little more into jsoncpp and nlohmann_json. Attached is my experiment with syntax and getting UUIDs and arrays of UUIDs serialized. nlohmann does not require calls to converter functions nor does it even require a converter... UUIDs just worked (however, we probably want a converter as its default behavior writes UUIDs as JSON arrays of unsigned integers). I continue to like nlohmann and dislike jsoncpp in terms of terseness and legibility of the resulting code. The one thing I dislike about nlohmann is that the repo seems to contain super-huge test files, making it slow to clone. Attached are example programs for each library that do the same thing (create JSON data including UUIDs). I have not tried parsing/dumping large objects. David -------------- next part -------------- A non-text attachment was scrubbed... Name: json.tar.gz Type: application/x-gzip Size: 1752 bytes Desc: not available URL: From tj.corona at kitware.com Thu Sep 14 08:48:41 2017 From: tj.corona at kitware.com (TJ Corona) Date: Thu, 14 Sep 2017 08:48:41 -0400 Subject: [Smtk-developers] TalosIV, Praxis issues on SMTK dashboard Message-ID: <86FB91BD-C2AB-4F74-848C-51B12E4079DF@kitware.com> Hi all, SMTK dashboards are starting to look not-so-great. TalosIV is having the following rendering issues: INFO: translate: operation succeeded _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL. ERROR: In /Users/dashboard/Dashboards/buildbot/smtk-talosiv-osx-shared-release_cgm_superbuild/build/superbuild/paraview/src/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 846 vtkCocoaRenderWindow (0x7fd193a1cc00): GLEW could not be initialized. Meanwhile, Praxis? superbuild testing is reporting failures where the regular dashboard succeeds. Perhaps there is something wrong with Praxis superbuild?s environment configuration? On the VTK side, I think Ben?s fixes to vtkGDAL? override should be in place, so we should hopefully see some of those warnings go away when ParaView updates VTK and then we update ParaView. 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 bob.obara at kitware.com Thu Sep 14 08:52:24 2017 From: bob.obara at kitware.com (Bob Obara) Date: Thu, 14 Sep 2017 08:52:24 -0400 Subject: [Smtk-developers] TalosIV, Praxis issues on SMTK dashboard In-Reply-To: <86FB91BD-C2AB-4F74-848C-51B12E4079DF@kitware.com> References: <86FB91BD-C2AB-4F74-848C-51B12E4079DF@kitware.com> Message-ID: <97A8D585-7493-4A0F-A4B6-A55D32D58CCB@kitware.com> Hi T.J., I?ve asked been to reboot Talos - if you are in the office already can you reboot it? Ben - if the override changes are pushed to ParaView - let me know and I will at least do a trial build on my machine to see if there are any issues. 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 Sep 14, 2017, at 8:48 AMEDT, TJ Corona wrote: > > Hi all, > SMTK dashboards are starting to look not-so-great. TalosIV is having the following rendering issues: > INFO: translate: operation succeeded > _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL. > ERROR: In /Users/dashboard/Dashboards/buildbot/smtk-talosiv-osx-shared-release_cgm_superbuild/build/superbuild/paraview/src/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 846 > vtkCocoaRenderWindow (0x7fd193a1cc00): GLEW could not be initialized. > Meanwhile, Praxis? superbuild testing is reporting failures where the regular dashboard succeeds. Perhaps there is something wrong with Praxis superbuild?s environment configuration? > > On the VTK side, I think Ben?s fixes to vtkGDAL? override should be in place, so we should hopefully see some of those warnings go away when ParaView updates VTK and then we update ParaView. > > 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 tj.corona at kitware.com Thu Sep 14 08:54:26 2017 From: tj.corona at kitware.com (TJ Corona) Date: Thu, 14 Sep 2017 08:54:26 -0400 Subject: [Smtk-developers] TalosIV, Praxis issues on SMTK dashboard In-Reply-To: <97A8D585-7493-4A0F-A4B6-A55D32D58CCB@kitware.com> References: <86FB91BD-C2AB-4F74-848C-51B12E4079DF@kitware.com> <97A8D585-7493-4A0F-A4B6-A55D32D58CCB@kitware.com> Message-ID: Hi Bob, You and John are currently logged into Talos, and I don?t have admin privileges to log you guys out. 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 Sep 14, 2017, at 8:52 AM, Bob Obara wrote: > > Hi T.J., > > I?ve asked been to reboot Talos - if you are in the office already can you reboot it? > > Ben - if the override changes are pushed to ParaView - let me know and I will at least do a trial build on my machine to see if there are any issues. > > 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 Sep 14, 2017, at 8:48 AMEDT, TJ Corona > wrote: >> >> Hi all, >> SMTK dashboards are starting to look not-so-great. TalosIV is having the following rendering issues: >> INFO: translate: operation succeeded >> _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL. >> ERROR: In /Users/dashboard/Dashboards/buildbot/smtk-talosiv-osx-shared-release_cgm_superbuild/build/superbuild/paraview/src/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 846 >> vtkCocoaRenderWindow (0x7fd193a1cc00): GLEW could not be initialized. >> Meanwhile, Praxis? superbuild testing is reporting failures where the regular dashboard succeeds. Perhaps there is something wrong with Praxis superbuild?s environment configuration? >> >> On the VTK side, I think Ben?s fixes to vtkGDAL? override should be in place, so we should hopefully see some of those warnings go away when ParaView updates VTK and then we update ParaView. >> >> 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 bob.obara at kitware.com Thu Sep 14 08:55:24 2017 From: bob.obara at kitware.com (Bob Obara) Date: Thu, 14 Sep 2017 08:55:24 -0400 Subject: [Smtk-developers] TalosIV, Praxis issues on SMTK dashboard In-Reply-To: References: <86FB91BD-C2AB-4F74-848C-51B12E4079DF@kitware.com> <97A8D585-7493-4A0F-A4B6-A55D32D58CCB@kitware.com> Message-ID: Thanks T.J. - I?ll reboot it when I get in. Do you know who was currently logged into the machine? 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 Sep 14, 2017, at 8:54 AMEDT, TJ Corona wrote: > > Hi Bob, > > You and John are currently logged into Talos, and I don?t have admin privileges to log you guys out. > > 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 Sep 14, 2017, at 8:52 AM, Bob Obara > wrote: >> >> Hi T.J., >> >> I?ve asked been to reboot Talos - if you are in the office already can you reboot it? >> >> Ben - if the override changes are pushed to ParaView - let me know and I will at least do a trial build on my machine to see if there are any issues. >> >> 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 Sep 14, 2017, at 8:48 AMEDT, TJ Corona > wrote: >>> >>> Hi all, >>> SMTK dashboards are starting to look not-so-great. TalosIV is having the following rendering issues: >>> INFO: translate: operation succeeded >>> _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL. >>> ERROR: In /Users/dashboard/Dashboards/buildbot/smtk-talosiv-osx-shared-release_cgm_superbuild/build/superbuild/paraview/src/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 846 >>> vtkCocoaRenderWindow (0x7fd193a1cc00): GLEW could not be initialized. >>> Meanwhile, Praxis? superbuild testing is reporting failures where the regular dashboard succeeds. Perhaps there is something wrong with Praxis superbuild?s environment configuration? >>> >>> On the VTK side, I think Ben?s fixes to vtkGDAL? override should be in place, so we should hopefully see some of those warnings go away when ParaView updates VTK and then we update ParaView. >>> >>> 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 ben.boeckel at kitware.com Thu Sep 14 10:27:45 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 14 Sep 2017 10:27:45 -0400 Subject: [Smtk-developers] JSON in SMTK In-Reply-To: References: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> <88F0D80E-B269-4C41-9C9D-1165B53D40A4@kitware.com> <20170912143844.GA4843@megas.kitware.com> <20170912153732.GA26627@megas.kitware.com> Message-ID: <20170914142745.GB10285@megas.kitware.com> On Wed, Sep 13, 2017 at 17:37:49 -0400, David Thompson wrote: > The one thing I dislike about nlohmann is that the repo seems to > contain super-huge test files, making it slow to clone. Well, if we don't submodule it, it'd either be a tarball (superbuild) or we'd drop those in a third-party import :) . --Ben From bob.obara at kitware.com Thu Sep 14 10:44:07 2017 From: bob.obara at kitware.com (Bob Obara) Date: Thu, 14 Sep 2017 10:44:07 -0400 Subject: [Smtk-developers] JSON in SMTK In-Reply-To: References: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> <88F0D80E-B269-4C41-9C9D-1165B53D40A4@kitware.com> <20170912143844.GA4843@megas.kitware.com> <20170912153732.GA26627@megas.kitware.com> Message-ID: <1B266B12-30F0-4CC7-82A9-9FFADFE8830D@kitware.com> I definitely like the nlohmann version better - did we determine if we need to mangle it? So should it and pugiXML be moved into the superbuild in the near future as external projects? 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 Sep 13, 2017, at 5:37 PMEDT, David Thompson wrote: > > Hi all, > > I've looked a little more into jsoncpp and nlohmann_json. Attached is my experiment with syntax and getting UUIDs and arrays of UUIDs serialized. nlohmann does not require calls to converter functions nor does it even require a converter... UUIDs just worked (however, we probably want a converter as its default behavior writes UUIDs as JSON arrays of unsigned integers). > > I continue to like nlohmann and dislike jsoncpp in terms of terseness and legibility of the resulting code. The one thing I dislike about nlohmann is that the repo seems to contain super-huge test files, making it slow to clone. > > Attached are example programs for each library that do the same thing (create JSON data including UUIDs). I have not tried parsing/dumping large objects. > > David > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Thu Sep 14 10:52:47 2017 From: david.thompson at kitware.com (David Thompson) Date: Thu, 14 Sep 2017 10:52:47 -0400 Subject: [Smtk-developers] JSON in SMTK In-Reply-To: <1B266B12-30F0-4CC7-82A9-9FFADFE8830D@kitware.com> References: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> <88F0D80E-B269-4C41-9C9D-1165B53D40A4@kitware.com> <20170912143844.GA4843@megas.kitware.com> <20170912153732.GA26627@megas.kitware.com> <1B266B12-30F0-4CC7-82A9-9FFADFE8830D@kitware.com> Message-ID: <24A4E6FE-F733-46CA-A00F-C7DCEA1FA628@kitware.com> I think since it is header-only that we would not need to mangle it, but rather install it inside the smtk include tree (e.g., include/smtk/thirdparty/nlohmann_json) so that others can use exactly the version SMTK is compiled with. We can define a macro (yes!) for nlohmann's include path so that it is possible to use an external version or third party version: #include "smtk/Options.h" #include SMTK_NLOHMANN_JSON_H David > On Sep 14, 2017, at 10:44, Bob Obara wrote: > > I definitely like the nlohmann version better - did we determine if we need to mangle it? > > So should it and pugiXML be moved into the superbuild in the near future as external projects? > > 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 Sep 13, 2017, at 5:37 PMEDT, David Thompson wrote: >> >> Hi all, >> >> I've looked a little more into jsoncpp and nlohmann_json. Attached is my experiment with syntax and getting UUIDs and arrays of UUIDs serialized. nlohmann does not require calls to converter functions nor does it even require a converter... UUIDs just worked (however, we probably want a converter as its default behavior writes UUIDs as JSON arrays of unsigned integers). >> >> I continue to like nlohmann and dislike jsoncpp in terms of terseness and legibility of the resulting code. The one thing I dislike about nlohmann is that the repo seems to contain super-huge test files, making it slow to clone. >> >> Attached are example programs for each library that do the same thing (create JSON data including UUIDs). I have not tried parsing/dumping large objects. >> >> David >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Sep 14 11:06:07 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 14 Sep 2017 11:06:07 -0400 Subject: [Smtk-developers] JSON in SMTK In-Reply-To: <24A4E6FE-F733-46CA-A00F-C7DCEA1FA628@kitware.com> References: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> <88F0D80E-B269-4C41-9C9D-1165B53D40A4@kitware.com> <20170912143844.GA4843@megas.kitware.com> <20170912153732.GA26627@megas.kitware.com> <1B266B12-30F0-4CC7-82A9-9FFADFE8830D@kitware.com> <24A4E6FE-F733-46CA-A00F-C7DCEA1FA628@kitware.com> Message-ID: <20170914150607.GA10841@megas.kitware.com> On Thu, Sep 14, 2017 at 10:52:47 -0400, David Thompson wrote: > I think since it is header-only that we would not need to mangle it, > but rather install it inside the smtk include tree (e.g., > include/smtk/thirdparty/nlohmann_json) so that others can use exactly This only works if when `FindNLohmann.cmake` (or whatever) is run, they find *this* one. If they find another, they have to disagree on what `json::value_t` is at the symbol level (because it's part of our symbol mangling for functions in C++). I don't think this removes the need for mangling actually, even though it is just header-only. > the version SMTK is compiled with. We can define a macro (yes!) for > nlohmann's include path so that it is possible to use an external > version or third party version: This better not make SMTK not relocatable when SDKs become required? > #include "smtk/Options.h" > #include SMTK_NLOHMANN_JSON_H RIP clang-format ;) . --Ben From bob.obara at kitware.com Thu Sep 14 11:06:29 2017 From: bob.obara at kitware.com (Bob Obara) Date: Thu, 14 Sep 2017 11:06:29 -0400 Subject: [Smtk-developers] JSON in SMTK In-Reply-To: <24A4E6FE-F733-46CA-A00F-C7DCEA1FA628@kitware.com> References: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> <88F0D80E-B269-4C41-9C9D-1165B53D40A4@kitware.com> <20170912143844.GA4843@megas.kitware.com> <20170912153732.GA26627@megas.kitware.com> <1B266B12-30F0-4CC7-82A9-9FFADFE8830D@kitware.com> <24A4E6FE-F733-46CA-A00F-C7DCEA1FA628@kitware.com> Message-ID: Sounds like a plan - I?d say lets go ahead - unless anyone has any questions/objections. I?m wondering if the same mechanism you used to have it understand UUID would work with our other objects (attributes, models, etc..)? We would still need to have the ability to deal with different versions when storing the JSON info in files. 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 Sep 14, 2017, at 10:52 AMEDT, David Thompson wrote: > > I think since it is header-only that we would not need to mangle it, but rather install it inside the smtk include tree (e.g., include/smtk/thirdparty/nlohmann_json) so that others can use exactly the version SMTK is compiled with. We can define a macro (yes!) for nlohmann's include path so that it is possible to use an external version or third party version: > > #include "smtk/Options.h" > #include SMTK_NLOHMANN_JSON_H > > David > > On Sep 14, 2017, at 10:44, Bob Obara > wrote: > >> I definitely like the nlohmann version better - did we determine if we need to mangle it? >> >> So should it and pugiXML be moved into the superbuild in the near future as external projects? >> >> 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 Sep 13, 2017, at 5:37 PMEDT, David Thompson > wrote: >>> >>> Hi all, >>> >>> I've looked a little more into jsoncpp and nlohmann_json. Attached is my experiment with syntax and getting UUIDs and arrays of UUIDs serialized. nlohmann does not require calls to converter functions nor does it even require a converter... UUIDs just worked (however, we probably want a converter as its default behavior writes UUIDs as JSON arrays of unsigned integers). >>> >>> I continue to like nlohmann and dislike jsoncpp in terms of terseness and legibility of the resulting code. The one thing I dislike about nlohmann is that the repo seems to contain super-huge test files, making it slow to clone. >>> >>> Attached are example programs for each library that do the same thing (create JSON data including UUIDs). I have not tried parsing/dumping large objects. >>> >>> David >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From haocheng.liu at kitware.com Thu Sep 14 11:19:03 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Thu, 14 Sep 2017 11:19:03 -0400 Subject: [Smtk-developers] JSON in SMTK In-Reply-To: <24A4E6FE-F733-46CA-A00F-C7DCEA1FA628@kitware.com> References: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> <88F0D80E-B269-4C41-9C9D-1165B53D40A4@kitware.com> <20170912143844.GA4843@megas.kitware.com> <20170912153732.GA26627@megas.kitware.com> <1B266B12-30F0-4CC7-82A9-9FFADFE8830D@kitware.com> <24A4E6FE-F733-46CA-A00F-C7DCEA1FA628@kitware.com> Message-ID: On Thu, Sep 14, 2017 at 10:52 AM, David Thompson wrote: > I think since it is header-only that we would not need to mangle it, but > rather install it inside the smtk include tree (e.g., > include/smtk/thirdparty/nlohmann_json) so that others can use exactly the > version SMTK is compiled with. We can define a macro (yes!) for nlohmann's > include path so that it is possible to use an external version or third > party version: > > Not a lover for MACRO:( I vote for a tarball in superbuild or a submodule of SMTK. > #include "smtk/Options.h" > #include SMTK_NLOHMANN_JSON_H > > David > > On Sep 14, 2017, at 10:44, Bob Obara wrote: > > I definitely like the nlohmann version better - did we determine if we > need to mangle it? > > So should it and pugiXML be moved into the superbuild in the near future > as external projects? > > 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 <(518)%20881-4931> > > > > > On Sep 13, 2017, at 5:37 PMEDT, David Thompson > wrote: > > Hi all, > > I've looked a little more into jsoncpp and nlohmann_json. Attached is my > experiment with syntax and getting UUIDs and arrays of UUIDs serialized. > nlohmann does not require calls to converter functions nor does it even > require a converter... UUIDs just worked (however, we probably want a > converter as its default behavior writes UUIDs as JSON arrays of unsigned > integers). > > I continue to like nlohmann and dislike jsoncpp in terms of terseness and > legibility of the resulting code. The one thing I dislike about nlohmann is > that the repo seems to contain super-huge test files, making it slow to > clone. > > Attached are example programs for each library that do the same thing > (create JSON data including UUIDs). I have not tried parsing/dumping large > objects. > > 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 Thu Sep 14 11:30:38 2017 From: bob.obara at kitware.com (Bob Obara) Date: Thu, 14 Sep 2017 11:30:38 -0400 Subject: [Smtk-developers] JSON in SMTK In-Reply-To: References: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> <88F0D80E-B269-4C41-9C9D-1165B53D40A4@kitware.com> <20170912143844.GA4843@megas.kitware.com> <20170912153732.GA26627@megas.kitware.com> <1B266B12-30F0-4CC7-82A9-9FFADFE8830D@kitware.com> <24A4E6FE-F733-46CA-A00F-C7DCEA1FA628@kitware.com> Message-ID: <9643F786-F84F-4D97-A898-F11DFA8B9A7E@kitware.com> I think we should just move both pugiXML and this into the superbuild - SMTK will need a find pugiXML and find nlohmann_JSON methods but since both of these are simple header only projects I don?t this will cause non-superbuild developers any headaches in terms of ?installing? them. This solves the external issues, doesn?t require any macros, simplifies the SMTK?s third party directory, and no issue with clang-format. 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 Sep 14, 2017, at 11:19 AMEDT, Haocheng Liu wrote: > > > > On Thu, Sep 14, 2017 at 10:52 AM, David Thompson > wrote: > I think since it is header-only that we would not need to mangle it, but rather install it inside the smtk include tree (e.g., include/smtk/thirdparty/nlohmann_json) so that others can use exactly the version SMTK is compiled with. We can define a macro (yes!) for nlohmann's include path so that it is possible to use an external version or third party version: > > Not a lover for MACRO:( I vote for a tarball in superbuild or a submodule of SMTK. > #include "smtk/Options.h" > #include SMTK_NLOHMANN_JSON_H > > David > > On Sep 14, 2017, at 10:44, Bob Obara > wrote: > >> I definitely like the nlohmann version better - did we determine if we need to mangle it? >> >> So should it and pugiXML be moved into the superbuild in the near future as external projects? >> >> 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 Sep 13, 2017, at 5:37 PMEDT, David Thompson > wrote: >>> >>> Hi all, >>> >>> I've looked a little more into jsoncpp and nlohmann_json. Attached is my experiment with syntax and getting UUIDs and arrays of UUIDs serialized. nlohmann does not require calls to converter functions nor does it even require a converter... UUIDs just worked (however, we probably want a converter as its default behavior writes UUIDs as JSON arrays of unsigned integers). >>> >>> I continue to like nlohmann and dislike jsoncpp in terms of terseness and legibility of the resulting code. The one thing I dislike about nlohmann is that the repo seems to contain super-huge test files, making it slow to clone. >>> >>> Attached are example programs for each library that do the same thing (create JSON data including UUIDs). I have not tried parsing/dumping large objects. >>> >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Thu Sep 14 11:47:39 2017 From: bob.obara at kitware.com (Bob Obara) Date: Thu, 14 Sep 2017 11:47:39 -0400 Subject: [Smtk-developers] UUIDGenerator Instance Message-ID: <6904BB2A-0141-4C0F-B74D-8C507F8DB4A1@kitware.com> Hi All, T.J. commented in my Resource merge request that creation of the UUID Generator can have costly initialization (Resource and ResourceComponent created a generator when they need to get a UUID) - if that is case, does it make sense to have a static instance() method on the generator class and have SMTK use it? 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 david.thompson at kitware.com Thu Sep 14 11:51:08 2017 From: david.thompson at kitware.com (David Thompson) Date: Thu, 14 Sep 2017 11:51:08 -0400 Subject: [Smtk-developers] UUIDGenerator Instance In-Reply-To: <6904BB2A-0141-4C0F-B74D-8C507F8DB4A1@kitware.com> References: <6904BB2A-0141-4C0F-B74D-8C507F8DB4A1@kitware.com> Message-ID: <1A38D29B-C250-45E4-8CA8-D20E2C918A62@kitware.com> > T.J. commented in my Resource merge request that creation of the UUID Generator can have costly initialization (Resource and ResourceComponent created a generator when they need to get a UUID) - if that is case, does it make sense to have a static instance() method on the generator class and have SMTK use it? Yes. Currently each model manager creates an instance. Since we are switching to having multiple managers instead of just one, this makes sense. David From bob.obara at kitware.com Thu Sep 14 11:55:08 2017 From: bob.obara at kitware.com (Bob Obara) Date: Thu, 14 Sep 2017 11:55:08 -0400 Subject: [Smtk-developers] UUIDGenerator Instance In-Reply-To: <1A38D29B-C250-45E4-8CA8-D20E2C918A62@kitware.com> References: <6904BB2A-0141-4C0F-B74D-8C507F8DB4A1@kitware.com> <1A38D29B-C250-45E4-8CA8-D20E2C918A62@kitware.com> Message-ID: <5DC81EA8-6EE0-40F8-BE2B-2BD40590A759@kitware.com> I?ll do it :) 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 Sep 14, 2017, at 11:51 AMEDT, David Thompson wrote: > >> T.J. commented in my Resource merge request that creation of the UUID Generator can have costly initialization (Resource and ResourceComponent created a generator when they need to get a UUID) - if that is case, does it make sense to have a static instance() method on the generator class and have SMTK use it? > > Yes. Currently each model manager creates an instance. Since we are switching to having multiple managers instead of just one, this makes sense. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Thu Sep 14 14:33:43 2017 From: bob.obara at kitware.com (Bob Obara) Date: Thu, 14 Sep 2017 14:33:43 -0400 Subject: [Smtk-developers] UUIDGenerator Instance In-Reply-To: <5DC81EA8-6EE0-40F8-BE2B-2BD40590A759@kitware.com> References: <6904BB2A-0141-4C0F-B74D-8C507F8DB4A1@kitware.com> <1A38D29B-C250-45E4-8CA8-D20E2C918A62@kitware.com> <5DC81EA8-6EE0-40F8-BE2B-2BD40590A759@kitware.com> Message-ID: <4121178E-EBE6-4D92-8647-49B476DE5355@kitware.com> Question about PybindUUIDGenerator.h Now that the class has an instance() method does anything need to be done to the wrapper file? 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 Sep 14, 2017, at 11:55 AMEDT, Bob Obara wrote: > > I?ll do it :) > > 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 Sep 14, 2017, at 11:51 AMEDT, David Thompson > wrote: >> >>> T.J. commented in my Resource merge request that creation of the UUID Generator can have costly initialization (Resource and ResourceComponent created a generator when they need to get a UUID) - if that is case, does it make sense to have a static instance() method on the generator class and have SMTK use it? >> >> Yes. Currently each model manager creates an instance. Since we are switching to having multiple managers instead of just one, this makes sense. >> >> David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tj.corona at kitware.com Thu Sep 14 14:35:46 2017 From: tj.corona at kitware.com (TJ Corona) Date: Thu, 14 Sep 2017 14:35:46 -0400 Subject: [Smtk-developers] UUIDGenerator Instance In-Reply-To: <4121178E-EBE6-4D92-8647-49B476DE5355@kitware.com> References: <6904BB2A-0141-4C0F-B74D-8C507F8DB4A1@kitware.com> <1A38D29B-C250-45E4-8CA8-D20E2C918A62@kitware.com> <5DC81EA8-6EE0-40F8-BE2B-2BD40590A759@kitware.com> <4121178E-EBE6-4D92-8647-49B476DE5355@kitware.com> Message-ID: Hi Bob, If you want to expose the static instance of the UUID Generator, you will need to add the method to the pybind11 code. 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 Sep 14, 2017, at 2:33 PM, Bob Obara wrote: > > Question about PybindUUIDGenerator.h > Now that the class has an instance() method does anything need to be done to the wrapper file? > > 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 Sep 14, 2017, at 11:55 AMEDT, Bob Obara > wrote: >> >> I?ll do it :) >> >> 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 Sep 14, 2017, at 11:51 AMEDT, David Thompson > wrote: >>> >>>> T.J. commented in my Resource merge request that creation of the UUID Generator can have costly initialization (Resource and ResourceComponent created a generator when they need to get a UUID) - if that is case, does it make sense to have a static instance() method on the generator class and have SMTK use it? >>> >>> Yes. Currently each model manager creates an instance. Since we are switching to having multiple managers instead of just one, this makes sense. >>> >>> David >> > > _______________________________________________ > 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 Thu Sep 14 17:50:14 2017 From: david.thompson at kitware.com (David Thompson) Date: Thu, 14 Sep 2017 17:50:14 -0400 Subject: [Smtk-developers] Python wrapping Message-ID: <6BDE1FBB-F414-4D01-B00D-A6B44FDB7DCE@kitware.com> Hi TJ (at al.), I'm having problems running the script to generate Pybind11 bindings after making some changes to smtk::model. The generate_pybind11_module.py script dies because it cannot find moab includes. Adding additional "-I" arguments to specify where the extra headers exist does not seem to work, nor does passing in CXXFLAGS environment variables like so: cd /path/to/SMTK/source export CXXFLAGS=" -I/Stage/Build/cmb/common-superbuild/install/include" python2.7 utilities/python/generate_pybind11_module.py \ -I /path/to/build/dir -i smtk/model -o /tmp/pybind11 -m smtk.model -s `pwd` Do you have an example of how to run the script? The docs[1] don't go over the options or how to handle missing includes. Thanks, David [1]: http://smtk.readthedocs.io/en/latest/userguide/bindings/generating-pybind11-bindings.html The error message is: INFO Parsing source file "/path/to/smtk/model/AttributeListPhrase.h" ... In file included from /path/to/smtk/model/AttributeListPhrase.h:14: In file included from ./smtk/model/DescriptivePhrase.h:14: In file included from ./smtk/mesh/MeshSet.h:17: In file included from ./smtk/mesh/CellSet.h:18: In file included from ./smtk/mesh/Handle.h:17: ./smtk/mesh/moab/HandleRange.h:20:10: fatal error: 'moab/EntityHandle.hpp' file not found #include "moab/EntityHandle.hpp" ^ 1 error generated. From tj.corona at kitware.com Fri Sep 15 08:50:48 2017 From: tj.corona at kitware.com (TJ Corona) Date: Fri, 15 Sep 2017 08:50:48 -0400 Subject: [Smtk-developers] Python wrapping In-Reply-To: <6BDE1FBB-F414-4D01-B00D-A6B44FDB7DCE@kitware.com> References: <6BDE1FBB-F414-4D01-B00D-A6B44FDB7DCE@kitware.com> Message-ID: Hi David, This MR adds an example for passing multiple include paths to the python script. I?d be happy to make the interface less clunky if you think that would help (you are not the first person who found this syntax unintuitive). 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 Sep 14, 2017, at 5:50 PM, David Thompson wrote: > > Hi TJ (at al.), > > I'm having problems running the script to generate Pybind11 bindings after making some changes to smtk::model. The generate_pybind11_module.py script dies because it cannot find moab includes. Adding additional "-I" arguments to specify where the extra headers exist does not seem to work, nor does passing in CXXFLAGS environment variables like so: > > cd /path/to/SMTK/source > export CXXFLAGS=" -I/Stage/Build/cmb/common-superbuild/install/include" > python2.7 utilities/python/generate_pybind11_module.py \ > -I /path/to/build/dir -i smtk/model -o /tmp/pybind11 -m smtk.model -s `pwd` > > Do you have an example of how to run the script? The docs[1] don't go over the options or how to handle missing includes. > > Thanks, > David > > [1]: http://smtk.readthedocs.io/en/latest/userguide/bindings/generating-pybind11-bindings.html > > The error message is: > > INFO Parsing source file "/path/to/smtk/model/AttributeListPhrase.h" ... > In file included from /path/to/smtk/model/AttributeListPhrase.h:14: > In file included from ./smtk/model/DescriptivePhrase.h:14: > In file included from ./smtk/mesh/MeshSet.h:17: > In file included from ./smtk/mesh/CellSet.h:18: > In file included from ./smtk/mesh/Handle.h:17: > ./smtk/mesh/moab/HandleRange.h:20:10: fatal error: 'moab/EntityHandle.hpp' file not found > #include "moab/EntityHandle.hpp" > ^ > 1 error generated. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri Sep 15 09:09:07 2017 From: david.thompson at kitware.com (David Thompson) Date: Fri, 15 Sep 2017 09:09:07 -0400 Subject: [Smtk-developers] Python wrapping In-Reply-To: References: <6BDE1FBB-F414-4D01-B00D-A6B44FDB7DCE@kitware.com> Message-ID: > ... This MR adds an example for passing multiple include paths to the python script. I?d be happy to make the interface less clunky if you think that would help (you are not the first person who found this syntax unintuitive). Thanks, TJ. The example helps. In the longer term, it would be nice to work out what include paths are passed to the compiler for a given module so it is easier to run this. I fear the bindings are getting stale in places where API has been added since they were first generated because the process is mysterious to us ignoramuses and because it can be hard to reconcile manual changes to the generated code if you weren't the one who made the manual changes to begin with. David From tj.corona at kitware.com Fri Sep 15 09:18:00 2017 From: tj.corona at kitware.com (TJ Corona) Date: Fri, 15 Sep 2017 09:18:00 -0400 Subject: [Smtk-developers] Python wrapping In-Reply-To: References: <6BDE1FBB-F414-4D01-B00D-A6B44FDB7DCE@kitware.com> Message-ID: > I fear the bindings are getting stale in places where API has been added I totally agree. The original plan was to bootstrap our bindings with the scripts and then tend to them by hand. We may be able to put together something runs the generator script and diffs it with the files in the code base. That way, we would only need to keep around a list of the custom-omitted methods. Either way, it is definitely true that maintenance plans for pybind bindings have been neglected to date. What does everyone else think? Thomas J. Corona, Ph.D. Kitware, Inc. Senior R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4443 > On Sep 15, 2017, at 9:09 AM, David Thompson wrote: > >> ... This MR adds an example for passing multiple include paths to the python script. I?d be happy to make the interface less clunky if you think that would help (you are not the first person who found this syntax unintuitive). > > Thanks, TJ. The example helps. In the longer term, it would be nice to work out what include paths are passed to the compiler for a given module so it is easier to run this. > > I fear the bindings are getting stale in places where API has been added since they were first generated because the process is mysterious to us ignoramuses and because it can be hard to reconcile manual changes to the generated code if you weren't the one who made the manual changes to begin with. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri Sep 15 09:18:14 2017 From: david.thompson at kitware.com (David Thompson) Date: Fri, 15 Sep 2017 09:18:14 -0400 Subject: [Smtk-developers] JSON in SMTK In-Reply-To: References: <3692BD2A-606D-4535-AFCF-E10A9EB0EEB2@kitware.com> <88F0D80E-B269-4C41-9C9D-1165B53D40A4@kitware.com> <20170912143844.GA4843@megas.kitware.com> <20170912153732.GA26627@megas.kitware.com> <1B266B12-30F0-4CC7-82A9-9FFADFE8830D@kitware.com> <24A4E6FE-F733-46CA-A00F-C7DCEA1FA628@kitware.com> Message-ID: <26916366-6730-4851-9C2A-0C5502771853@kitware.com> Hi Bob, > Sounds like a plan - I?d say lets go ahead - unless anyone has any questions/objections. OK. > I?m wondering if the same mechanism you used to have it understand UUID would work with our other objects (attributes, models, etc..)? We would still need to have the ability to deal with different versions when storing the JSON info in files. Since the serializers are template specializations, if they are only available in one specific implementation file (tied to a particular version), then that implementation file will serialize/deserialize differently. So it seems feasible to use the helpers to control how SMTK objects get saved. David From david.thompson at kitware.com Fri Sep 15 14:43:15 2017 From: david.thompson at kitware.com (David Thompson) Date: Fri, 15 Sep 2017 14:43:15 -0400 Subject: [Smtk-developers] Changes to model manager Message-ID: Hi all, I've just merged changes to the model system into SMTK master; they are significant enough to warrant this e-mail. These changes are work towards SMTK 2.0 and particularly toward making the mesh, model, and attribute systems more consistent: + smtk::model::Manager now inherits smtk::common::Resource, just as smtk::attribute::Collection does. This means each model manager has a UUID and a URL (location) indicating where it is on disk. + smtk::model::Manager now stores smtk::model::Entity instances by mapping UUIDs to shared pointers instead of directly to instances. This is necessary because: + smtk::model::Entity now inherits smtk::common::ResourceComponent, just as smtk::attribute::Attribute does. ResourceComponents are managed via shared pointers and store their UUID directly. At some point, + smtk::model::Manager will be renamed smtk::model::Collection to match the attribute system. + smtk::mesh::Collection will inherit smtk::common::Resource. This way, each of the 3 main systems in SMTK (model, mesh, attribute) will each have resources (things stored in files) named Collection which contain components (model entities, mesh sets, attribute instances) that are all referenced by UUID. This merge also removes sparsehash storage as an option. We weren't using it, we weren't testing it, and it has different semantics than std::map for when iterators are invalidated. If anyone is really interested in it, speak up soon and we can revert it -- but I would prefer not to. David From bob.obara at kitware.com Sat Sep 16 15:01:12 2017 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Sat, 16 Sep 2017 15:01:12 -0400 Subject: [Smtk-developers] Crazy idea for representing View information Message-ID: <3D976D3B-0397-44D7-B47D-4227BA50B493@kitware.com> Hi All, Since we had the discussion about which JSON library we should be using I've been wondering if instead of the current View Data structure in Common, maybe we should just use a JSON data structure instead? Any comments? Bob Sent from my iPad From david.thompson at kitware.com Sat Sep 16 15:50:47 2017 From: david.thompson at kitware.com (David Thompson) Date: Sat, 16 Sep 2017 15:50:47 -0400 Subject: [Smtk-developers] Crazy idea for representing View information In-Reply-To: <3D976D3B-0397-44D7-B47D-4227BA50B493@kitware.com> References: <3D976D3B-0397-44D7-B47D-4227BA50B493@kitware.com> Message-ID: <983D0BF7-34C8-400E-951D-6AD4321E2847@kitware.com> > Since we had the discussion about which JSON library we should be using I've been wondering if instead of the current View Data structure in Common, maybe we should just use a JSON data structure instead? Any comments? +1 ... while it does tie SMTK to using JSON in its user-facing API, it should simplify the view code. David From david.thompson at kitware.com Sat Sep 16 16:05:21 2017 From: david.thompson at kitware.com (David Thompson) Date: Sat, 16 Sep 2017 16:05:21 -0400 Subject: [Smtk-developers] Crazy idea for representing View information In-Reply-To: <983D0BF7-34C8-400E-951D-6AD4321E2847@kitware.com> References: <3D976D3B-0397-44D7-B47D-4227BA50B493@kitware.com> <983D0BF7-34C8-400E-951D-6AD4321E2847@kitware.com> Message-ID: >> Since we had the discussion about which JSON library we should be using I've been wondering if instead of the current View Data structure in Common, maybe we should just use a JSON data structure instead? Any comments? > > +1 ... while it does tie SMTK to using JSON in its user-facing API, it should simplify the view code. One question is how this translates to the Python bindings. It seems like there are 2 paths: 1. Convert view info to/from a string when crossing the C++/Python boundary. 2. Bind nlohmann_json objects using pybind11. David From david.thompson at kitware.com Sat Sep 16 16:29:56 2017 From: david.thompson at kitware.com (David Thompson) Date: Sat, 16 Sep 2017 16:29:56 -0400 Subject: [Smtk-developers] Crazy idea for representing View information In-Reply-To: <3D976D3B-0397-44D7-B47D-4227BA50B493@kitware.com> References: <3D976D3B-0397-44D7-B47D-4227BA50B493@kitware.com> Message-ID: <13378DFB-1B7B-4BCF-B295-A1294ACEDBE7@kitware.com> > Since we had the discussion about which JSON library we should be using I've been wondering if instead of the current View Data structure in Common, maybe we should just use a JSON data structure instead? Any comments? Besides the view data structure, there may be other classes that would benefit from becoming JSON data. At least smtk::io::Logger comes to mind. If you are worried about logs accumulating records that do not adhere to a convention, we could class Logger : public json { public: void addRecord( Severity s, const json& message, const std::string& file, unsigned int line) { this->push_back( { "severity": s }, { "message", message }, { "file", file }, { "line", line } ); } json record(int recNum) { return (*this)[recNum]; } } The same kind of thing could be done for views if need be. David From ben.boeckel at kitware.com Mon Sep 18 07:51:05 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 18 Sep 2017 07:51:05 -0400 Subject: [Smtk-developers] Crazy idea for representing View information In-Reply-To: References: <3D976D3B-0397-44D7-B47D-4227BA50B493@kitware.com> <983D0BF7-34C8-400E-951D-6AD4321E2847@kitware.com> Message-ID: <20170918115105.GC19877@megas.kitware.com> On Sat, Sep 16, 2017 at 16:05:21 -0400, David Thompson wrote: > > +1 ... while it does tie SMTK to using JSON in its user-facing API, > > it should simplify the view code. > > One question is how this translates to the Python bindings. It seems like there are 2 paths: > 1. Convert view info to/from a string when crossing the C++/Python boundary. > 2. Bind nlohmann_json objects using pybind11. Neither. Just convert them to dictionaries. --Ben From david.thompson at kitware.com Mon Sep 18 08:57:58 2017 From: david.thompson at kitware.com (David Thompson) Date: Mon, 18 Sep 2017 08:57:58 -0400 Subject: [Smtk-developers] Crazy idea for representing View information In-Reply-To: <20170918115105.GC19877@megas.kitware.com> References: <3D976D3B-0397-44D7-B47D-4227BA50B493@kitware.com> <983D0BF7-34C8-400E-951D-6AD4321E2847@kitware.com> <20170918115105.GC19877@megas.kitware.com> Message-ID: >>> +1 ... while it does tie SMTK to using JSON in its user-facing API, >>> it should simplify the view code. >> >> One question is how this translates to the Python bindings. It seems like there are 2 paths: >> 1. Convert view info to/from a string when crossing the C++/Python boundary. >> 2. Bind nlohmann_json objects using pybind11. > > Neither. Just convert them to dictionaries. That's a good idea but it may not satisfy the principle of minimum astonishment; I could get a Python dict for the view info but if I modify it, the view spec would be unchanged. #1 above would behave the same way, but #2 would force them to be synchronized. David From david.thompson at kitware.com Mon Sep 18 09:38:20 2017 From: david.thompson at kitware.com (David Thompson) Date: Mon, 18 Sep 2017 09:38:20 -0400 Subject: [Smtk-developers] nlohmann_json and SMTK Message-ID: <579E48D9-F207-47B5-9817-4A856317A051@kitware.com> Hi all, I've pushed a branch here: https://gitlab.kitware.com/dcthomp/smtk/tree/nlohmann-json that adds some nlohmann_json converters along the lines we discussed. It gets a surprising amount done with very little code and could be much smaller if we were willing to change the JSON file format. See smtk/io/jsonUUID.h smtk/io/jsonTessellation.h smtk/io/jsonEntity.h smtk/io/jsonModelCollection.h for what happens when this line (njson jmmgr = sm): https://gitlab.kitware.com/dcthomp/smtk/blob/nlohmann-json/smtk/io/testing/cxx/exploreNLohmannJSON.cxx#L107 is evaluated. A sample of some of the output (running the exploreNLohmannJSON test on a polygon model) is below. Note that it is not precisely like existing JSON in that 1. arrangement information is not included (just not implemented yet) and 2. the entity type bit data (the "e" key) is presented as a string, not an integer; this would be easy to change but does improve legibility. David { "models": { "ad1e2e89-ba18-4b2f-9570-eedc24f758ac": { "00377c6b-0956-4975-baf4-56c1c892219a": { "d": 1, "e": "vertex", "f": { "_boundingBox": [ 254.499935, 254.499935, 82.999971, 82.999971, 0.0, 0.0 ] }, "i": { "_tessgen": [ 3 ], "block_index": [ 62 ], "pedigree id": [ 32 ], "visible": [ 0 ] }, "r": [ null, null, "6de5744d-525f-4b26-87ac-c99573813fa2", null, null, null, "d876e692-f7f6-4723-988a-1a4f428ed6f9", null, "af19eb3d-9bd5-43d4-832e-a5d0cbf5753b" ], "s": { "name": [ "vertex 32" ] }, "t": { "faces": [ 512, 0 ], "metadata": [ "formatVersion", "3" ], "vertices": [ 254.499935, 82.999971, 0.0 ] } }, "015fb605-9bba-4eb6-9229-63011491d4c8": { "d": 2, "e": "edge_use", "i": { "pedigree id": [ 30 ] }, "r": [ "af19eb3d-9bd5-43d4-832e-a5d0cbf5753b", "2a8c6e26-01ed-4823-ad2d-9bf1efaaaca4" ], "s": { "name": [ "edge use 30" ] } }, "020e48a9-bb4c-46e2-b7c5-510a4dc12247": { "d": 0, "e": "group|nodim", "i": { "membership mask": [ 271 ], "visible": [ 1 ] }, "r": [ "36ccbcf5-240a-4f99-88ba-c5418fcfef10", "ad1e2e89-ba18-4b2f-9570-eedc24f758ac", "3885d08e-c9bb-4d29-aa80-0143e50bea81" ], "s": { "name": [ "drum" ] } }, "04fa7479-5d03-4b7c-8fbd-1a3e2341baf6": { "d": 4, "e": "face", "f": { "_boundingBox": [ 299.499977, 347.499973, 107.499992, 175.499987, 0.0, 0.0 ], "color": [ 0.529412, 0.784314, 0.509804, 1.0 ] }, "i": { "_tessgen": [ 0 ], "block_index": [ 9 ], "pedigree id": [ 20 ], "visible": [ 1 ] }, "r": [ "32391f3a-b8f8-46b6-af94-a6e84163de5c", "ad1e2e89-ba18-4b2f-9570-eedc24f758ac", "54350ca2-4701-4a87-91f6-452c265c2a28" ], "s": { "name": [ "face 20" ] }, "t": { "faces": [ 0, 0, 1, 2, 0, 0, 2, 3, 0, 0, 3, 4, 0, 5, 6, 7, 0, 5, 7, 8, 0, 5, 8, 9, 0, 10, 11, 12, 0, 10, 12, 13, 0, 10, 13, 14, 0, 15, 16, 17, 0, 15, 17, 18, ... 0, 543, 547, 548 ], "metadata": [ "formatVersion", "3" ], "vertices": [ 299.999977, 120.499991, 0.0, 299.499977, 119.999991, 0.0, 299.499977, 118.999991, 0.0, 299.999977, 118.499991, 0.0, 299.999977, 120.499991, 0.0, 300.499977, 120.999991, 0.0, 299.999977, 120.499991, 0.0, 299.999977, 118.499991, 0.0, 300.499977, ... 0.0, 347.499973, 169.999987, 0.0, 347.499973, 170.999987, 0.0 ] }, ... } } } } From ben.boeckel at kitware.com Mon Sep 18 09:41:16 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 18 Sep 2017 09:41:16 -0400 Subject: [Smtk-developers] Crazy idea for representing View information In-Reply-To: References: <3D976D3B-0397-44D7-B47D-4227BA50B493@kitware.com> <983D0BF7-34C8-400E-951D-6AD4321E2847@kitware.com> <20170918115105.GC19877@megas.kitware.com> Message-ID: <20170918134116.GA24263@rotor.kitware.com> On Mon, Sep 18, 2017 at 08:57:58 -0400, David Thompson wrote: > That's a good idea but it may not satisfy the principle of minimum > astonishment; I could get a Python dict for the view info but if I > modify it, the view spec would be unchanged. #1 above would behave the > same way, but #2 would force them to be synchronized. Hmm, true. I guess pybind11 wrapping that maps it to a dict-like interface is best. --Ben From david.thompson at kitware.com Tue Sep 19 16:13:04 2017 From: david.thompson at kitware.com (David Thompson) Date: Tue, 19 Sep 2017 16:13:04 -0400 Subject: [Smtk-developers] Reshape edge test failure Message-ID: <02410AF2-D31B-4988-AC1E-09BEDD980048@kitware.com> Hi Bob, The reshape edge test in CMB that you mentioned today appears to be failing because of an unrecorded button press in the XML test script. The test attempts to run "Edge - Split" after the reshape but because the "Split Edges" button in the operator view is never pressed, the mouse clicks have no effect. I am fine with (1) updating the baseline and removing the "Edge - Split" stuff from the XML or (2) adding the missing button click ? assuming we can find some XML to simulate it ? so that the split operation gets tested. Do you have a preference? David https://open.cdash.org/testDetails.php?test=583994406&build=5067897 From haocheng.liu at kitware.com Tue Sep 19 16:27:56 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Tue, 19 Sep 2017 16:27:56 -0400 Subject: [Smtk-developers] Reshape edge test failure In-Reply-To: <02410AF2-D31B-4988-AC1E-09BEDD980048@kitware.com> References: <02410AF2-D31B-4988-AC1E-09BEDD980048@kitware.com> Message-ID: Hi David, On Tue, Sep 19, 2017 at 4:13 PM, David Thompson wrote: > Hi Bob, > > The reshape edge test in CMB that you mentioned today appears to be > failing because of an unrecorded button press in the XML test script. The > test attempts to run "Edge - Split" after the reshape but because the > "Split Edges" button in the operator view is never pressed, the mouse > clicks have no effect. > > I am fine with (1) updating the baseline and removing the "Edge - Split" > stuff from the XML or (2) adding the missing button click ? assuming we > can find some XML to simulate it ? so that the split operation gets tested. > Do you have a preference? > > I just played with it, adding ```xml --- a/Source/Applications/ModelBuilder/Testing/XML/PolygonReshapeEdge.xml +++ b/Source/Applications/ModelBuilder/Testing/XML/PolygonReshapeEdge.xml @@ -27,6 +27,10 @@ + + + + diff --git a/ThirdParty/SMTK b/ThirdParty/SMTK ``` seems able to trigger the missing button click. Would you mind give it a try :) ? A patch file is attached. > David > > https://open.cdash.org/testDetails.php?test=583994406&build=5067897 > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: reshape.patch Type: text/x-patch Size: 2029 bytes Desc: not available URL: From david.thompson at kitware.com Tue Sep 19 20:42:37 2017 From: david.thompson at kitware.com (David Thompson) Date: Tue, 19 Sep 2017 20:42:37 -0400 Subject: [Smtk-developers] Reshape edge test failure In-Reply-To: References: <02410AF2-D31B-4988-AC1E-09BEDD980048@kitware.com> Message-ID: <283671F9-4135-4B9B-821A-0BE6B3F00ECC@kitware.com> Hi Haocheng, > ... (1) updating the baseline and removing the "Edge - Split" stuff from the XML or (2) adding the missing button click ? assuming we can find some XML to simulate it ? so that the split operation gets tested. Do you have a preference? > > I just played with it, adding > ... > seems able to trigger the missing button click. Would you mind give it a try :) ? A patch file is attached. Works for me! +2 David From robert.maynard at kitware.com Wed Sep 20 10:42:34 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 20 Sep 2017 10:42:34 -0400 Subject: [Smtk-developers] Changes to model manager In-Reply-To: References: Message-ID: Just a clarification. smtk::mesh::MeshSets are never stored in files and don't have UUIDS. Recently I have come to regret that name for the class as it really should be named something like smtk::mesh::View. The reason for this is that a smtk::mesh::MeshSets reference numerous meshes from the underlying database, which might or might not have the optional UUID field. That is why the smtk::mesh::MeshSets::modelEntityIds() returns a vector of UUIDS which doesn't need to be the same length as smtk::mesh::MeshSets::size() On Fri, Sep 15, 2017 at 2:43 PM, David Thompson wrote: > Hi all, > > I've just merged changes to the model system into SMTK master; they are significant enough to warrant this e-mail. These changes are work towards SMTK 2.0 and particularly toward making the mesh, model, and attribute systems more consistent: > > + smtk::model::Manager now inherits smtk::common::Resource, just as smtk::attribute::Collection does. This means each model manager has a UUID and a URL (location) indicating where it is on disk. > > + smtk::model::Manager now stores smtk::model::Entity instances by mapping UUIDs to shared pointers instead of directly to instances. This is necessary because: > > + smtk::model::Entity now inherits smtk::common::ResourceComponent, just as smtk::attribute::Attribute does. ResourceComponents are managed via shared pointers and store their UUID directly. > > At some point, > > + smtk::model::Manager will be renamed smtk::model::Collection to match the attribute system. > + smtk::mesh::Collection will inherit smtk::common::Resource. > > This way, each of the 3 main systems in SMTK (model, mesh, attribute) will each have resources (things stored in files) named Collection which contain components (model entities, mesh sets, attribute instances) that are all referenced by UUID. > > This merge also removes sparsehash storage as an option. We weren't using it, we weren't testing it, and it has different semantics than std::map for when iterators are invalidated. If anyone is really interested in it, speak up soon and we can revert it -- but I would prefer not to. > > David > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers From david.thompson at kitware.com Wed Sep 20 12:02:54 2017 From: david.thompson at kitware.com (David Thompson) Date: Wed, 20 Sep 2017 12:02:54 -0400 Subject: [Smtk-developers] Changes to model manager In-Reply-To: References: Message-ID: <5F07DF91-98C7-475E-9891-D5746EF9B452@kitware.com> Hi Rob, Thanks for mentioning this. I did not mean to be confusing, but was talking about our plans going forward: we will be making smtk::mesh::Collection inherit smtk::common::Resource. Resources each have a URL and reference components by UUID. So we will probably have to store a map from MeshSet IDs (integers) to UUIDs. SMTK will only present those MeshSets with UUIDs assigned to them as components of the resource. I agree that MeshSet might be better named View. David > Just a clarification. > > smtk::mesh::MeshSets are never stored in files and don't have UUIDS. > Recently I have come to regret that name for the class as it really > should be named something like smtk::mesh::View. > > The reason for this is that a smtk::mesh::MeshSets reference numerous > meshes from the underlying database, which might or might not have the > optional UUID field. That is why the > smtk::mesh::MeshSets::modelEntityIds() returns a vector of UUIDS which > doesn't need to be the same length as smtk::mesh::MeshSets::size() > > On Fri, Sep 15, 2017 at 2:43 PM, David Thompson > wrote: >> Hi all, >> >> I've just merged changes to the model system into SMTK master; they are significant enough to warrant this e-mail. These changes are work towards SMTK 2.0 and particularly toward making the mesh, model, and attribute systems more consistent: >> >> + smtk::model::Manager now inherits smtk::common::Resource, just as smtk::attribute::Collection does. This means each model manager has a UUID and a URL (location) indicating where it is on disk. >> >> + smtk::model::Manager now stores smtk::model::Entity instances by mapping UUIDs to shared pointers instead of directly to instances. This is necessary because: >> >> + smtk::model::Entity now inherits smtk::common::ResourceComponent, just as smtk::attribute::Attribute does. ResourceComponents are managed via shared pointers and store their UUID directly. >> >> At some point, >> >> + smtk::model::Manager will be renamed smtk::model::Collection to match the attribute system. >> + smtk::mesh::Collection will inherit smtk::common::Resource. >> >> This way, each of the 3 main systems in SMTK (model, mesh, attribute) will each have resources (things stored in files) named Collection which contain components (model entities, mesh sets, attribute instances) that are all referenced by UUID. >> >> This merge also removes sparsehash storage as an option. We weren't using it, we weren't testing it, and it has different semantics than std::map for when iterators are invalidated. If anyone is really interested in it, speak up soon and we can revert it -- but I would prefer not to. >> >> David >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/mailman/listinfo/smtk-developers From robert.maynard at kitware.com Wed Sep 20 12:05:17 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 20 Sep 2017 12:05:17 -0400 Subject: [Smtk-developers] Changes to model manager In-Reply-To: <5F07DF91-98C7-475E-9891-D5746EF9B452@kitware.com> References: <5F07DF91-98C7-475E-9891-D5746EF9B452@kitware.com> Message-ID: Sorry I am confused this time. Since MeshSets are never stored in the underlying file how is SMTK going to reconstruct the MeshSets? On Wed, Sep 20, 2017 at 12:02 PM, David Thompson wrote: > Hi Rob, > > Thanks for mentioning this. I did not mean to be confusing, but was talking about our plans going forward: we will be making smtk::mesh::Collection inherit smtk::common::Resource. Resources each have a URL and reference components by UUID. So we will probably have to store a map from MeshSet IDs (integers) to UUIDs. SMTK will only present those MeshSets with UUIDs assigned to them as components of the resource. > > I agree that MeshSet might be better named View. > > David > >> Just a clarification. >> >> smtk::mesh::MeshSets are never stored in files and don't have UUIDS. >> Recently I have come to regret that name for the class as it really >> should be named something like smtk::mesh::View. >> >> The reason for this is that a smtk::mesh::MeshSets reference numerous >> meshes from the underlying database, which might or might not have the >> optional UUID field. That is why the >> smtk::mesh::MeshSets::modelEntityIds() returns a vector of UUIDS which >> doesn't need to be the same length as smtk::mesh::MeshSets::size() >> >> On Fri, Sep 15, 2017 at 2:43 PM, David Thompson >> wrote: >>> Hi all, >>> >>> I've just merged changes to the model system into SMTK master; they are significant enough to warrant this e-mail. These changes are work towards SMTK 2.0 and particularly toward making the mesh, model, and attribute systems more consistent: >>> >>> + smtk::model::Manager now inherits smtk::common::Resource, just as smtk::attribute::Collection does. This means each model manager has a UUID and a URL (location) indicating where it is on disk. >>> >>> + smtk::model::Manager now stores smtk::model::Entity instances by mapping UUIDs to shared pointers instead of directly to instances. This is necessary because: >>> >>> + smtk::model::Entity now inherits smtk::common::ResourceComponent, just as smtk::attribute::Attribute does. ResourceComponents are managed via shared pointers and store their UUID directly. >>> >>> At some point, >>> >>> + smtk::model::Manager will be renamed smtk::model::Collection to match the attribute system. >>> + smtk::mesh::Collection will inherit smtk::common::Resource. >>> >>> This way, each of the 3 main systems in SMTK (model, mesh, attribute) will each have resources (things stored in files) named Collection which contain components (model entities, mesh sets, attribute instances) that are all referenced by UUID. >>> >>> This merge also removes sparsehash storage as an option. We weren't using it, we weren't testing it, and it has different semantics than std::map for when iterators are invalidated. If anyone is really interested in it, speak up soon and we can revert it -- but I would prefer not to. >>> >>> David >>> _______________________________________________ >>> Smtk-developers mailing list >>> Smtk-developers at smtk.org >>> http://public.kitware.com/mailman/listinfo/smtk-developers > From david.thompson at kitware.com Wed Sep 20 12:39:45 2017 From: david.thompson at kitware.com (David Thompson) Date: Wed, 20 Sep 2017 12:39:45 -0400 Subject: [Smtk-developers] Changes to model manager In-Reply-To: References: <5F07DF91-98C7-475E-9891-D5746EF9B452@kitware.com> Message-ID: <2E001419-A52B-43B0-B0A9-EBED2A267D16@kitware.com> > Sorry I am confused this time. > > Since MeshSets are never stored in the underlying file how is SMTK > going to reconstruct the MeshSets? We already serialize the classification of meshsets onto models in the SMTK json file. This would happen the same way. It is also possible we will add some metadata to the HDF5 file and store the map there. It's HDF5, so as long as we don't use any reserved paths for the metadata, MOAB will be oblivious to it. David From david.thompson at kitware.com Mon Sep 25 16:40:04 2017 From: david.thompson at kitware.com (David Thompson) Date: Mon, 25 Sep 2017 16:40:04 -0400 Subject: [Smtk-developers] Failing SMTK test Message-ID: <3F98FEB8-E8A1-485F-853C-8F9D49817752@kitware.com> Hi all, I've been trying to track down why discreteSmtkModelfrom2dmTest is failing on the dashboards. The bug occurs because the discrete model's edge operator can't determine the ID of the point chosen for the split. The problem appears to be in smtk/bridge/discrete/operators/EdgeOperator.cxx: int EdgeOperator::convertToGlobalPointId(int localPid, vtkDiscreteModelEdge* cmbModelEdge) which is called with `localPid` set to a value from the operator's MeshSelectionItem. Inside convertToGlobalPointId, an error occurs because hasTessellation() returns a null pointer. The edge selected also has no mesh backing (i.e., edge.meshTessellation().isValid() is false). I am still confused as to why my recent change (SMTK MR 856) caused this to surface; all it does is stop a model file from being loaded twice -- and when it does, it prints out error messages that do not appear when running smtkModelfrom2dmTest. Does anyone who knows more about MeshSelectionItem, particularly what its integers index into, have a clue? Thanks, David From david.thompson at kitware.com Tue Sep 26 08:51:39 2017 From: david.thompson at kitware.com (David Thompson) Date: Tue, 26 Sep 2017 08:51:39 -0400 Subject: [Smtk-developers] Failing SMTK test In-Reply-To: <3F98FEB8-E8A1-485F-853C-8F9D49817752@kitware.com> References: <3F98FEB8-E8A1-485F-853C-8F9D49817752@kitware.com> Message-ID: <1A71DCA6-ECBE-4FC5-BFA1-5302C0C75EF7@kitware.com> ... Also, I've run valgrind on the test with no reported errors, so if it is stomping on memory, it's most probably happening with statically-allocated array bounds being exceeded. David > I've been trying to track down why discreteSmtkModelfrom2dmTest is failing on the dashboards. The bug occurs because the discrete model's edge operator can't determine the ID of the point chosen for the split. > > The problem appears to be in smtk/bridge/discrete/operators/EdgeOperator.cxx: > > int EdgeOperator::convertToGlobalPointId(int localPid, vtkDiscreteModelEdge* cmbModelEdge) > > which is called with `localPid` set to a value from the operator's MeshSelectionItem. Inside convertToGlobalPointId, an error occurs because hasTessellation() returns a null pointer. The edge selected also has no mesh backing (i.e., edge.meshTessellation().isValid() is false). > > I am still confused as to why my recent change (SMTK MR 856) caused this to surface; all it does is stop a model file from being loaded twice -- and when it does, it prints out error messages that do not appear when running smtkModelfrom2dmTest. > > Does anyone who knows more about MeshSelectionItem, particularly what its integers index into, have a clue? > > Thanks, > David From tj.corona at kitware.com Tue Sep 26 10:24:26 2017 From: tj.corona at kitware.com (TJ Corona) Date: Tue, 26 Sep 2017 09:24:26 -0500 Subject: [Smtk-developers] Failing SMTK test In-Reply-To: <1A71DCA6-ECBE-4FC5-BFA1-5302C0C75EF7@kitware.com> References: <3F98FEB8-E8A1-485F-853C-8F9D49817752@kitware.com> <1A71DCA6-ECBE-4FC5-BFA1-5302C0C75EF7@kitware.com> Message-ID: <0D8F4005-529C-4E17-8534-7BB2128104C5@kitware.com> Hi David, When I remove the changes introduced in MR 856, the test does pass. All I need to do to cause the test to fail is uncomment ?findEntity? (LoadJSON.cxx:868) (and the loops leading up to the call, but they don?t seem to effect the test), which is weird. Looking at Manager.cxx:923, findEntity is not really a const call? Passing trySessions=false to the findEntity call in LoadJSON.cxx:868 also seems to fix the problem. 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 Sep 26, 2017, at 7:51 AM, David Thompson wrote: > > ... Also, I've run valgrind on the test with no reported errors, so if it is stomping on memory, it's most probably happening with statically-allocated array bounds being exceeded. > > David > >> I've been trying to track down why discreteSmtkModelfrom2dmTest is failing on the dashboards. The bug occurs because the discrete model's edge operator can't determine the ID of the point chosen for the split. >> >> The problem appears to be in smtk/bridge/discrete/operators/EdgeOperator.cxx: >> >> int EdgeOperator::convertToGlobalPointId(int localPid, vtkDiscreteModelEdge* cmbModelEdge) >> >> which is called with `localPid` set to a value from the operator's MeshSelectionItem. Inside convertToGlobalPointId, an error occurs because hasTessellation() returns a null pointer. The edge selected also has no mesh backing (i.e., edge.meshTessellation().isValid() is false). >> >> I am still confused as to why my recent change (SMTK MR 856) caused this to surface; all it does is stop a model file from being loaded twice -- and when it does, it prints out error messages that do not appear when running smtkModelfrom2dmTest. >> >> Does anyone who knows more about MeshSelectionItem, particularly what its integers index into, have a clue? >> >> Thanks, >> David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue Sep 26 10:50:32 2017 From: david.thompson at kitware.com (David Thompson) Date: Tue, 26 Sep 2017 10:50:32 -0400 Subject: [Smtk-developers] Failing SMTK test In-Reply-To: <0D8F4005-529C-4E17-8534-7BB2128104C5@kitware.com> References: <3F98FEB8-E8A1-485F-853C-8F9D49817752@kitware.com> <1A71DCA6-ECBE-4FC5-BFA1-5302C0C75EF7@kitware.com> <0D8F4005-529C-4E17-8534-7BB2128104C5@kitware.com> Message-ID: > When I remove the changes introduced in MR 856, the test does pass. All I need to do to cause the test to fail is uncomment ?findEntity? (LoadJSON.cxx:868) (and the loops leading up to the call, but they don?t seem to effect the test), which is weird. Looking at Manager.cxx:923, findEntity is not really a const call? Passing trySessions=false to the findEntity call in LoadJSON.cxx:868 also seems to fix the problem. Oooh. Thanks, that helps. MR coming shortly. David From david.thompson at kitware.com Tue Sep 26 10:55:20 2017 From: david.thompson at kitware.com (David Thompson) Date: Tue, 26 Sep 2017 10:55:20 -0400 Subject: [Smtk-developers] High Sierra, Xcode 9 Message-ID: <2E90425B-00BD-4B9E-BB8D-EC08BF22F3FD@kitware.com> Hi all, Last night I upgraded a machine to High Sierra and Xcode 9. After a "brew upgrade", CMB5-develop and its superbuild succeeded with only issues beyond those already in the tracker: gdal requires two 1-line patches. I'll submit a superbuild MR shortly. My configuration was Qt 5.9.1, Python 2.7, and pybind11. David From bob.obara at kitware.com Wed Sep 27 11:03:54 2017 From: bob.obara at kitware.com (Bob Obara) Date: Wed, 27 Sep 2017 11:03:54 -0400 Subject: [Smtk-developers] High Sierra, Xcode 9 In-Reply-To: <2E90425B-00BD-4B9E-BB8D-EC08BF22F3FD@kitware.com> References: <2E90425B-00BD-4B9E-BB8D-EC08BF22F3FD@kitware.com> Message-ID: Hey David, Did you submit the MR for the fix? 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 Sep 26, 2017, at 10:55 AMEDT, David Thompson wrote: > > Hi all, > > Last night I upgraded a machine to High Sierra and Xcode 9. After a "brew upgrade", CMB5-develop and its superbuild succeeded with only issues beyond those already in the tracker: gdal requires two 1-line patches. I'll submit a superbuild MR shortly. My configuration was Qt 5.9.1, Python 2.7, and pybind11. > > David > _______________________________________________ > 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 Sep 27 11:06:30 2017 From: david.thompson at kitware.com (David Thompson) Date: Wed, 27 Sep 2017 11:06:30 -0400 Subject: [Smtk-developers] High Sierra, Xcode 9 In-Reply-To: References: <2E90425B-00BD-4B9E-BB8D-EC08BF22F3FD@kitware.com> Message-ID: > Did you submit the MR for the fix? Yes, https://gitlab.kitware.com/cmb/cmb-superbuild/merge_requests/356 was merged last night. Are you having other issues? David From bob.obara at kitware.com Wed Sep 27 11:24:26 2017 From: bob.obara at kitware.com (Bob Obara) Date: Wed, 27 Sep 2017 11:24:26 -0400 Subject: [Smtk-developers] High Sierra, Xcode 9 In-Reply-To: References: <2E90425B-00BD-4B9E-BB8D-EC08BF22F3FD@kitware.com> Message-ID: <6098ECFD-1BF9-4DC7-AD64-447A5445A69C@kitware.com> Nope - was waiting for the MR prior to upgrading :) Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Nope Phone: (518) 881- 4931 > On Sep 27, 2017, at 11:06 AMEDT, David Thompson wrote: > >> Did you submit the MR for the fix? > > Yes, https://gitlab.kitware.com/cmb/cmb-superbuild/merge_requests/356 was merged last night. Are you having other issues? > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Wed Sep 27 11:30:54 2017 From: david.thompson at kitware.com (David Thompson) Date: Wed, 27 Sep 2017 11:30:54 -0400 Subject: [Smtk-developers] High Sierra, Xcode 9 In-Reply-To: <6098ECFD-1BF9-4DC7-AD64-447A5445A69C@kitware.com> References: <2E90425B-00BD-4B9E-BB8D-EC08BF22F3FD@kitware.com> <6098ECFD-1BF9-4DC7-AD64-447A5445A69C@kitware.com> Message-ID: <942F7D23-0343-44EA-8B1A-6326F78A9AD7@kitware.com> > Nope - was waiting for the MR prior to upgrading :) One other issue I've had (independent of High Sierra) is MOAB not installing a MOABTargets.cmake and MOABTargets-.cmake file in addition to MOABConfig.cmake. Has anyone else had this problem? I worked around it (hacked my own versions), but it is odd. David > >> On Sep 27, 2017, at 11:06 AMEDT, David Thompson wrote: >> >>> Did you submit the MR for the fix? >> >> Yes, https://gitlab.kitware.com/cmb/cmb-superbuild/merge_requests/356 was merged last night. Are you having other issues? >> >> David >> >