From andrew.amaclean at gmail.com Sun Mar 1 03:06:39 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Sun, 1 Mar 2015 19:06:39 +1100 Subject: [vtk-developers] A note regarding: std::min and std::max. In-Reply-To: <20150227153217.GB6233@megas.kitwarein.com> References: <20150227153217.GB6233@megas.kitwarein.com> Message-ID: Hi Ben, I've been watching nemesis for the past few days, the segfaults are caused by a GL version mismatch. On the plus side the compiles are showing no errors! I downloaded MS-MPI and discovered the FindMPI does not work with it so I created a test and manually entered paths etc. and tried that. I suspect you are using the 2012 version of MPI, FindMPI works with that version. Anyway, I have contacted Todd with some suggested fixes to FindMPI. Regards Andrew On 28/02/2015 2:32 AM, "Ben Boeckel" wrote: > On Thu, Feb 26, 2015 at 16:21:55 +1100, Andrew Maclean wrote: > > Would it be possible to set up one of the CDash machines to use VS2013? I > > am not testing the parallel implementations so there could be problems > > there that I haven't detected. > > nemesis runs VS2013: > > https://open.cdash.org/viewBuildError.php?buildid=3711838 > > > However if someone can walk me through setting up MPI on a laptop with > > VS2013 Community Edition I would be glad to test the Parallel > > implementations. > > MSMPI is here: > > https://msdn.microsoft.com/en-us/library/bb524831%28v=vs.85%29.aspx > > IIRC, it was just an install-and-go setup (now that VTK's FindMPI can > find it ;) ). > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Sun Mar 1 19:49:12 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Sun, 1 Mar 2015 19:49:12 -0500 Subject: [vtk-developers] A note regarding: std::min and std::max. In-Reply-To: References: <20150227153217.GB6233@megas.kitwarein.com> Message-ID: <20150302004912.GA17534@bronto-burt.dev.benboeckel.net> On Sun, Mar 01, 2015 at 19:06:39 +1100, Andrew Maclean wrote: > I've been watching nemesis for the past few days, the segfaults are caused > by a GL version mismatch. On the plus side the compiles are showing no > errors! Unfortunately, Windows doesn't give real hardware access to more than one session and a separate user is logged in right now (I'm in the process of moving all dashboards to that user), so all it gets is whatever Windows' kernel supports. That should be fixed on the runs Monday night). It is also my main Windows development machine, so there may need to be some setup so I can use it without disrupting the dashboards (I can't run as the user with the dashboards running continuously because of ParaView's windows stealing focus and other window management deficiencies in Windows). > I downloaded MS-MPI and discovered the FindMPI does not work with > it so I created a test and manually entered paths etc. and tried that. I > suspect you are using the 2012 version of MPI, FindMPI works with that > version. Anyway, I have contacted Todd with some suggested fixes to FindMPI. What errors have you seen? It would be nice to get the fixes into CMake itself as well. Maybe we need to look in other registry keys for the right path? Did you install it to your user or the machine? --Ben From andrew.amaclean at gmail.com Sun Mar 1 20:16:08 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Mon, 2 Mar 2015 12:16:08 +1100 Subject: [vtk-developers] A note regarding: std::min and std::max. In-Reply-To: <20150302004912.GA17534@bronto-burt.dev.benboeckel.net> References: <20150227153217.GB6233@megas.kitwarein.com> <20150302004912.GA17534@bronto-burt.dev.benboeckel.net> Message-ID: Thanks for letting me know about that. In summary, the VTK version of FindMPI.cmake works perfectly so there is no problem. Maybe these changes need to be propagated to the CMake version. I was testing using the CMake version of FindMPI. I also had uninstalled an older version of MPI but the registry key was still there and this meant that it couldn't find mpiexec.exe in C:/Program Files/Microsoft MPI/Bin. Once I removed this key everything worked but the CMake version doesn't find the the lib or include files as it doesn't know the path C:/Program Files (x86)/Microsoft SDKs/MPI. I have just run the VTK version of FindMPI and it works perfectly so there are no issues there. It found the lib and include directories using the paths set by the install of MS-MPI. I'm doing a build now on the master and will run the tests and will let you know how it goes. Regards Andrew On Mon, Mar 2, 2015 at 11:49 AM, Ben Boeckel wrote: > On Sun, Mar 01, 2015 at 19:06:39 +1100, Andrew Maclean wrote: > > I've been watching nemesis for the past few days, the segfaults are > caused > > by a GL version mismatch. On the plus side the compiles are showing no > > errors! > > Unfortunately, Windows doesn't give real hardware access to more than > one session and a separate user is logged in right now (I'm in the > process of moving all dashboards to that user), so all it gets is > whatever Windows' kernel supports. That should be fixed on the runs > Monday night). > > It is also my main Windows development machine, so there may need to be > some setup so I can use it without disrupting the dashboards (I can't > run as the user with the dashboards running continuously because of > ParaView's windows stealing focus and other window management > deficiencies in Windows). > > > I downloaded MS-MPI and discovered the FindMPI does not work with > > it so I created a test and manually entered paths etc. and tried that. I > > suspect you are using the 2012 version of MPI, FindMPI works with that > > version. Anyway, I have contacted Todd with some suggested fixes to > FindMPI. > > What errors have you seen? It would be nice to get the fixes into CMake > itself as well. Maybe we need to look in other registry keys for the > right path? Did you install it to your user or the machine? > > --Ben > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Sun Mar 1 22:18:10 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Sun, 1 Mar 2015 22:18:10 -0500 Subject: [vtk-developers] A note regarding: std::min and std::max. In-Reply-To: References: <20150227153217.GB6233@megas.kitwarein.com> <20150302004912.GA17534@bronto-burt.dev.benboeckel.net> Message-ID: <20150302031810.GA9141@bronto-burt.dev.benboeckel.net> On Mon, Mar 02, 2015 at 12:16:08 +1100, Andrew Maclean wrote: > Thanks for letting me know about that. > > In summary, the VTK version of FindMPI.cmake works perfectly so there is no > problem. Maybe these changes need to be propagated to the CMake version. > > I was testing using the CMake version of FindMPI. I also had uninstalled an > older version of MPI but the registry key was still there and this meant > that it couldn't find mpiexec.exe in C:/Program Files/Microsoft MPI/Bin. > Once I removed this key everything worked but the CMake version doesn't > find the the lib or include files as it doesn't know the path C:/Program > Files (x86)/Microsoft SDKs/MPI. I made the changes in parallel; it is a recent CMake change though; Git says it is in 3.2.0-rc1. So it makes sense that it fails there. > I have just run the VTK version of FindMPI and it works perfectly so there > are no issues there. It found the lib and include directories using the > paths set by the install of MS-MPI. > > I'm doing a build now on the master and will run the tests and will let you > know how it goes. Thanks. It had been a mostly clean dashboard before the user switch started (< 20 OpenGL2-related test failures IIRC). --Ben From andrew.amaclean at gmail.com Mon Mar 2 02:27:20 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Mon, 2 Mar 2015 18:27:20 +1100 Subject: [vtk-developers] A note regarding: std::min and std::max. In-Reply-To: <20150302031810.GA9141@bronto-burt.dev.benboeckel.net> References: <20150227153217.GB6233@megas.kitwarein.com> <20150302004912.GA17534@bronto-burt.dev.benboeckel.net> <20150302031810.GA9141@bronto-burt.dev.benboeckel.net> Message-ID: Ben, It looks really good, check out the Experimental submission for Libre,I have only 9 failures and 1985 passed! Fantastic ... checkout the Dashboard! This is a release build MSVC 2013, OpenGL2, MS-MPI, QT 5.4 build Thanks for the help with MPI. VTK is looking really good from my perspective only 9 failures in testing. TestParalleNumpy will pass when I install mpi4py.For a few others I get "Shader object was not initialized, cannot attach it." ... not sure how to fix htis one. Andrew PS: The failures in the earlier submission relate to the fact the wrong python dlls were used. On Mon, Mar 2, 2015 at 2:18 PM, Ben Boeckel wrote: > On Mon, Mar 02, 2015 at 12:16:08 +1100, Andrew Maclean wrote: > > Thanks for letting me know about that. > > > > In summary, the VTK version of FindMPI.cmake works perfectly so there is > no > > problem. Maybe these changes need to be propagated to the CMake version. > > > > I was testing using the CMake version of FindMPI. I also had uninstalled > an > > older version of MPI but the registry key was still there and this meant > > that it couldn't find mpiexec.exe in C:/Program Files/Microsoft MPI/Bin. > > Once I removed this key everything worked but the CMake version doesn't > > find the the lib or include files as it doesn't know the path C:/Program > > Files (x86)/Microsoft SDKs/MPI. > > I made the changes in parallel; it is a recent CMake change though; Git > says it is in 3.2.0-rc1. So it makes sense that it fails there. > > > I have just run the VTK version of FindMPI and it works perfectly so > there > > are no issues there. It found the lib and include directories using the > > paths set by the install of MS-MPI. > > > > I'm doing a build now on the master and will run the tests and will let > you > > know how it goes. > > Thanks. It had been a mostly clean dashboard before the user switch > started (< 20 OpenGL2-related test failures IIRC). > > --Ben > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Mon Mar 2 10:03:46 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 2 Mar 2015 10:03:46 -0500 Subject: [vtk-developers] Migrating Git repository to Gitlab Message-ID: Folks, In August 2014, there was a discussion on the mailing list [1] about development workflows. A conclusion of that conversation was that we will look at a Github-like approach to make contributing easier. The time has come to act on those discussions, and we will outline plans to do that below. Since those initial discussions developers at Kitware have been evaluating Github and Github clones to see what would work for our projects, including the large ones like ParaView and VTK. Here is a summary of that evaluation and the proposed plan. * We have settled on using Gitlab (an open source Github clone) as the platform for hosting the official repositories. There are several advantages to using a self-hosted Gitlab instance, including support for customized server-side hooks. * Gitlab is very Github-like. Thus we can use Gitlab for code-review instead of Gerrit. For simplicity, let?s call this Kitware hosted instance of Gitlab, KWGitlab. * For VTK, we can use what is commonly called a *Forking Workflow* [2,3]. Essentially, developers can create a fork of the VTK repository on KWGitlab. They can then create branches on their fork to develop new features or bug fixes. They can publish their branches to the world on their personal forks. Once developers are ready to merge that change into VTK, they go to the KWGitlab web application and create a *Merge Request*. Once a merge request is made, we can use testing infrastructure to run dashboards on the merge request (similar to what we currently do for Gerrit). We can decide on a convention as to what constitutes an approval of the merge request. Once approved, the merge request can be ?accepted? and merged into the master repo. * Gitlab provides a nicer UI for inspecting changes and posting comments etc, as compared with Gerrit, and one that would be familiar to many Github users. Reviewing code will be easier, especially for topic branches with a number of commits. Attached are a few miscellaneous screenshots from the Gitlab instance we're testing out internally. * For testing we have been experimenting with Buildbot to act as the scheduler that triggers a dashboard run when an ?authenticated? merge-request is received and ready for testing. Authenticated could mean something like the following: - The merge request has a specific label e.g. ?do-tests? AND - The merge request was created by a user registered as a VTK developer OR - A VTK developer has made a specific comment to trigger the builds. We can set up a few buildbot-slaves to test merge requests in addition to the traditional continuous and nightly testing. We will endeavor to make these changes as painless as possible, but ask that you bear with us as we make the transition. We will flesh out low-level details for contributing changes, dealing with conflicts, and so forth. Q&A === 1. What is the timeline? We are testing this out internally right now. There are a few things that need to be ironed out like managing ExternalData, updating SetupforDevelopment.sh, updating documentation etc. Once VTK 6.2 is out the door, we plan to go live with this initiative. This needs to happen by April 20th, since Google stops supporting OpenID 2.0 [4] then and our current instance of Gerrit (with patches to support topic branches) uses OpenID 2.0. Thus VTK gerrit users will not be able to sign in to Gerrit after April 20th. 2. Does the git url for checking out VTK change? Yes. The git url will indeed change. The current plan is to abandon the old URL to avoid confusion. 3. What happens to the Github clone of VTK? That will continue as before. We will keep the Github clone updated as earlier. Eventually, we can start accepting pull requests on Github that can then be migrated to KWGitlab for testing/merging. 4. Are we also moving the bug tracker? The general consensus is that it will indeed be nice to start using the integrated issue tracker in Gitlab instead of the separate Mantis bug tracker. As a first pass however, let?s keep the changes limited. Once we have all settled in to using Gitlab we can start a separate thread to discuss how the bug tracker evolves. 5. Do I have to update all my dashboards? For most part, the only thing that needs to change on the dashboards is where the checkout VTK from. We are currently testing a Buildbot+CDash-based exhaustive testing model for ParaView to test individual merge requests. We?ll post details on how that experiment goes and then we can decide how VTK testing infrastructure can be expanded in time. We will certainly migrate the current Gerrit topic testing machines to test merge requests either using CDash at Home or Buildbot when all this goes live. [1] http://public.kitware.com/pipermail/vtk-developers/2014-August/030755.html [2] https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow [3] https://guides.github.com/introduction/flow/ [4] https://developers.google.com/accounts/docs/OpenID -------------- next part -------------- A non-text attachment was scrubbed... Name: merge_request_commits.png Type: image/png Size: 207591 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: merge_requests.png Type: image/png Size: 261858 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: network_view.png Type: image/png Size: 255075 bytes Desc: not available URL: From ken.martin at kitware.com Mon Mar 2 10:16:28 2015 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 2 Mar 2015 10:16:28 -0500 Subject: [vtk-developers] Odd gerrit error Message-ID: <5aad1f5dbb1454ff57b4eeda7dda64eb@mail.gmail.com> Does the following ring a bell with anyone? For some reason gerrit is rejecting my branch and I?m not understanding the issue. I have tried renaming the branch and I get the same error. TIA - Ken ken.martin at ATHENA ~/Documents/vtk/vtk (fix_recent_opengl2_regressions) $ git gerrit-push Fetching gerrit master Pushing to gerrit Counting objects: 568, done. Delta compression using up to 8 threads. Compressing objects: 100% (148/148), done. Writing objects: 100% (371/371), 124.97 KiB, done. Total 371 (delta 141), reused 256 (delta 60) remote: Resolving deltas: 12% (17/141) error: failed to push some refs to 'martink at review.source.kitware.com:VTK' To martink at review.source.kitware.com:VTK ! HEAD:refs/for/master/fix_recent_opengl2_regressions [remote rejected] (The modified changes doesn't belong to the same topic.) Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Mon Mar 2 10:30:39 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 2 Mar 2015 10:30:39 -0500 Subject: [vtk-developers] Odd gerrit error In-Reply-To: <5aad1f5dbb1454ff57b4eeda7dda64eb@mail.gmail.com> References: <5aad1f5dbb1454ff57b4eeda7dda64eb@mail.gmail.com> Message-ID: Try a git commit --amend and take out the ChangeId line (which probably belongs to some other commit already in gerrit). Commit hooks will make a new one and gerrit will most likely accept it. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Mon, Mar 2, 2015 at 10:16 AM, Ken Martin wrote: > Does the following ring a bell with anyone? For some reason gerrit is > rejecting my branch and I?m not understanding the issue. I have tried > renaming the branch and I get the same error. TIA - Ken > > > > ken.martin at ATHENA ~/Documents/vtk/vtk (fix_recent_opengl2_regressions) > > $ git gerrit-push > > Fetching gerrit master > > Pushing to gerrit > > Counting objects: 568, done. > > Delta compression using up to 8 threads. > > Compressing objects: 100% (148/148), done. > > Writing objects: 100% (371/371), 124.97 KiB, done. > > Total 371 (delta 141), reused 256 (delta 60) > > remote: Resolving deltas: 12% (17/141) > > error: failed to push some refs to 'martink at review.source.kitware.com:VTK' > > To martink at review.source.kitware.com:VTK > > ! HEAD:refs/for/master/fix_recent_opengl2_regressions [remote > rejected] (The modified changes doesn't belong to the same topic.) > > > > Ken Martin PhD > > Chairman & CFO > > Kitware Inc. > > 28 Corporate Drive > > Clifton Park NY 12065 > > ken.martin at kitware.com > > 518 881-4901 (w) > > 518 371-4573 (f) > > > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Mar 2 11:21:33 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 2 Mar 2015 11:21:33 -0500 Subject: [vtk-developers] Odd gerrit error In-Reply-To: <5aad1f5dbb1454ff57b4eeda7dda64eb@mail.gmail.com> References: <5aad1f5dbb1454ff57b4eeda7dda64eb@mail.gmail.com> Message-ID: <20150302162133.GA21889@megas.kitwarein.com> On Mon, Mar 02, 2015 at 10:16:28 -0500, Ken Martin wrote: > ! HEAD:refs/for/master/fix_recent_opengl2_regressions [remote > rejected] (The modified changes doesn't belong to the same topic.) This happens when you either win the lottery (get the same Change-Id as another) or cherry-pick'd a commit from a branch already on Gerrit. Dave's solution should work. Shouldn't be a problem anymore once Gitlab is in use :) . --Ben From ken.martin at kitware.com Mon Mar 2 11:23:01 2015 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 2 Mar 2015 11:23:01 -0500 Subject: [vtk-developers] Odd gerrit error In-Reply-To: References: <5aad1f5dbb1454ff57b4eeda7dda64eb@mail.gmail.com> Message-ID: Ahh, I had pulled some unmerged changes from gerrit to test them out and then based my branch off of that point. I think that was the issue. Will retry based off of an origin/master starting point. Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. *From:* David E DeMarle [mailto:dave.demarle at kitware.com] *Sent:* Monday, March 2, 2015 10:31 AM *To:* Ken Martin *Cc:* vtkdev *Subject:* Re: [vtk-developers] Odd gerrit error Try a git commit --amend and take out the ChangeId line (which probably belongs to some other commit already in gerrit). Commit hooks will make a new one and gerrit will most likely accept it. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Mon, Mar 2, 2015 at 10:16 AM, Ken Martin wrote: Does the following ring a bell with anyone? For some reason gerrit is rejecting my branch and I?m not understanding the issue. I have tried renaming the branch and I get the same error. TIA - Ken ken.martin at ATHENA ~/Documents/vtk/vtk (fix_recent_opengl2_regressions) $ git gerrit-push Fetching gerrit master Pushing to gerrit Counting objects: 568, done. Delta compression using up to 8 threads. Compressing objects: 100% (148/148), done. Writing objects: 100% (371/371), 124.97 KiB, done. Total 371 (delta 141), reused 256 (delta 60) remote: Resolving deltas: 12% (17/141) error: failed to push some refs to 'martink at review.source.kitware.com:VTK' To martink at review.source.kitware.com:VTK ! HEAD:refs/for/master/fix_recent_opengl2_regressions [remote rejected] (The modified changes doesn't belong to the same topic.) Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Mon Mar 2 11:30:01 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 2 Mar 2015 11:30:01 -0500 Subject: [vtk-developers] Renderman Announces new pricing policy In-Reply-To: References: Message-ID: There is also the pixie project, a high quality rendering engine that accepts RIB input. http://www.renderpixie.com seems to compile and run easily enough. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Fri, May 30, 2014 at 5:08 PM, Bill Lorensen wrote: > Folks, > > Mike Halle referred me to this article regarding RenderMan: > http://renderman.pixar.com/view/non-commercial > > Many years ago, I wrote the vtkRIBExporter that produces RenderMan > files. At that time, there was a free package BMRT that accepted > RenderMan files and created high quality renderings from VTK models. > In fact, almost all of the images in the VTK book centerfold plates > were produced using vtkRIBExporter and BMRT. > > The new free license has commercial restrictions, but they seem > lenient unless you want to sell your animations. > > I've requested a free license. I'll keep the group informed... > > Bill > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://www.vtk.org/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Mar 2 11:34:38 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 2 Mar 2015 11:34:38 -0500 Subject: [vtk-developers] Renderman Announces new pricing policy In-Reply-To: References: Message-ID: I'll take a look. Thanks, Bill On Mon, Mar 2, 2015 at 11:30 AM, David E DeMarle wrote: > There is also the pixie project, a high quality rendering engine that > accepts RIB input. > http://www.renderpixie.com > seems to compile and run easily enough. > > > > > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Fri, May 30, 2014 at 5:08 PM, Bill Lorensen > wrote: >> >> Folks, >> >> Mike Halle referred me to this article regarding RenderMan: >> http://renderman.pixar.com/view/non-commercial >> >> Many years ago, I wrote the vtkRIBExporter that produces RenderMan >> files. At that time, there was a free package BMRT that accepted >> RenderMan files and created high quality renderings from VTK models. >> In fact, almost all of the images in the VTK book centerfold plates >> were produced using vtkRIBExporter and BMRT. >> >> The new free license has commercial restrictions, but they seem >> lenient unless you want to sell your animations. >> >> I've requested a free license. I'll keep the group informed... >> >> Bill >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://www.vtk.org/mailman/listinfo/vtk-developers >> > -- Unpaid intern in BillsBasement at noware dot com From dave.demarle at kitware.com Mon Mar 2 11:40:33 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 2 Mar 2015 11:40:33 -0500 Subject: [vtk-developers] Renderman Announces new pricing policy In-Reply-To: References: Message-ID: I'll let you know when I get past the black screen rendered with VTK cells.py's cells.rib file. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Mon, Mar 2, 2015 at 11:34 AM, Bill Lorensen wrote: > I'll take a look. > > Thanks, > > Bill > > > On Mon, Mar 2, 2015 at 11:30 AM, David E DeMarle > wrote: > > There is also the pixie project, a high quality rendering engine that > > accepts RIB input. > > http://www.renderpixie.com > > seems to compile and run easily enough. > > > > > > > > > > > > David E DeMarle > > Kitware, Inc. > > R&D Engineer > > 21 Corporate Drive > > Clifton Park, NY 12065-8662 > > Phone: 518-881-4909 > > > > On Fri, May 30, 2014 at 5:08 PM, Bill Lorensen > > wrote: > >> > >> Folks, > >> > >> Mike Halle referred me to this article regarding RenderMan: > >> http://renderman.pixar.com/view/non-commercial > >> > >> Many years ago, I wrote the vtkRIBExporter that produces RenderMan > >> files. At that time, there was a free package BMRT that accepted > >> RenderMan files and created high quality renderings from VTK models. > >> In fact, almost all of the images in the VTK book centerfold plates > >> were produced using vtkRIBExporter and BMRT. > >> > >> The new free license has commercial restrictions, but they seem > >> lenient unless you want to sell your animations. > >> > >> I've requested a free license. I'll keep the group informed... > >> > >> Bill > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Follow this link to subscribe/unsubscribe: > >> http://www.vtk.org/mailman/listinfo/vtk-developers > >> > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Mon Mar 2 14:34:17 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 2 Mar 2015 14:34:17 -0500 Subject: [vtk-developers] VTK accepted for Google Summer of Code 2015 Message-ID: Good news everyone - VTK was chosen to be a mentor organization for Google's Summer of Code program! If you have the urge hone your development skills and want an internship working on VTK from the comfort of your own home this summer, please apply. See the list of project ideas that we've come up with so far ( http://www.vtk.org/Wiki/VTK/GSoC_2015) and apply through the Summer of Code web site (https://www.google-melange.com/gsoc/homepage/google/gsoc2015). Thank you and good luck to all applicants! David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Mar 2 14:52:06 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 2 Mar 2015 14:52:06 -0500 Subject: [vtk-developers] VTK module system uplift to CMake 3.0 features Message-ID: <20150302195206.GA28834@megas.kitwarein.com> Hi, We are currently toying with the idea to update the module system to use more modern CMake features such as usage requirements, interface libraries, etc. The benefits for end-users include: - find_package(COMPONENTS) will be simpler. * basically, COMPONENTS will become nothing more than a check that the components are available; all available components will always be loaded. This means VTK_INCLUDE_DIRS and friends no longer change values based on the last find_package() call. - no need to do include_directories(), link_directories(), add_definitions() for each dependent module (for libraries not using module.cmake). Instead target_link_libraries(myapp vtkmod1 vtkmod2) would get everything necessary. * this also means vtk_mpi_link will not be necessary anymore; linking to vtkMPI (or similar) should bring in everything. Currently, the way it is set up, include(vtkMPI) is required and then vtk_mpi_link(mymodule) is needed to properly get everything MPI needs. - during the transition, VTK's module dependencies will likely be audited and can hopefully be made more accurate (e.g., removing unnecessary dependencies, making dependencies private where possible, etc.). - faster configure time since lots of CMake code won't be running anymore and instead handled by CMake itself in C++ code. There are other factors which should help here (such as greatly reducing the number of variables floating around). The CMake code for modules themselves is already highly declarative, so it is unlikely that many changes will be necessary for them. It would mean bumping the CMake minimum version to at least 3.0 though. Thoughts? Thanks, --Ben From david.thompson at kitware.com Mon Mar 2 14:54:54 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 2 Mar 2015 14:54:54 -0500 Subject: [vtk-developers] VTK module system uplift to CMake 3.0 features In-Reply-To: <20150302195206.GA28834@megas.kitwarein.com> References: <20150302195206.GA28834@megas.kitwarein.com> Message-ID: > We are currently toying with the idea to update the module system to use > more modern CMake features such as usage requirements, interface > libraries, etc. > ... > Thoughts? +1 From sean at rogue-research.com Mon Mar 2 15:21:34 2015 From: sean at rogue-research.com (Sean McBride) Date: Mon, 2 Mar 2015 15:21:34 -0500 Subject: [vtk-developers] VTK module system uplift to CMake 3.0 features In-Reply-To: <20150302195206.GA28834@megas.kitwarein.com> References: <20150302195206.GA28834@megas.kitwarein.com> Message-ID: <20150302202134.391991153@mail.rogue-research.com> On Mon, 2 Mar 2015 14:52:06 -0500, Ben Boeckel said: >It would >mean bumping the CMake minimum version to at least 3.0 though. > >Thoughts? Sound good to me. I guess getting all the dashboards updated would be one of the first tasks... Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From robert.maynard at kitware.com Mon Mar 2 15:26:49 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 2 Mar 2015 15:26:49 -0500 Subject: [vtk-developers] VTK module system uplift to CMake 3.0 features In-Reply-To: References: <20150302195206.GA28834@megas.kitwarein.com> Message-ID: With the move to target based usage requirements will the ability to create external vtk modules still exist, and will they be able to use things such as vtkMPI? On Mon, Mar 2, 2015 at 2:54 PM, David Thompson wrote: > > We are currently toying with the idea to update the module system to use > > more modern CMake features such as usage requirements, interface > > libraries, etc. > > ... > > Thoughts? > > +1 > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Mar 2 15:37:05 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 2 Mar 2015 15:37:05 -0500 Subject: [vtk-developers] Renderman Announces new pricing policy In-Reply-To: References: Message-ID: Ooops... Here is the source and cmake file: On Mon, Mar 2, 2015 at 3:35 PM, Bill Lorensen wrote: > Dave, > > I was able to create this image dented.tif > which very similar to an image I created years ago: > http://web.archive.org/web/19970630025047/http://www.crd.ge.com/~lorensen/vtkrib/ > > I had to hand edit the .rib file. I need to update the RIB exporter. > Don't waste time on this until I fix the RIB exporter and property. > > It is encouraging since that example uses a shader that I wrote. > > I also attached the c++ code that almost produced a good rib file. > > Bill > > > On Mon, Mar 2, 2015 at 11:40 AM, David E DeMarle > wrote: >> I'll let you know when I get past the black screen rendered with VTK >> cells.py's cells.rib file. >> >> >> David E DeMarle >> Kitware, Inc. >> R&D Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-881-4909 >> >> On Mon, Mar 2, 2015 at 11:34 AM, Bill Lorensen >> wrote: >>> >>> I'll take a look. >>> >>> Thanks, >>> >>> Bill >>> >>> >>> On Mon, Mar 2, 2015 at 11:30 AM, David E DeMarle >>> wrote: >>> > There is also the pixie project, a high quality rendering engine that >>> > accepts RIB input. >>> > http://www.renderpixie.com >>> > seems to compile and run easily enough. >>> > >>> > >>> > >>> > >>> > >>> > David E DeMarle >>> > Kitware, Inc. >>> > R&D Engineer >>> > 21 Corporate Drive >>> > Clifton Park, NY 12065-8662 >>> > Phone: 518-881-4909 >>> > >>> > On Fri, May 30, 2014 at 5:08 PM, Bill Lorensen >>> > wrote: >>> >> >>> >> Folks, >>> >> >>> >> Mike Halle referred me to this article regarding RenderMan: >>> >> http://renderman.pixar.com/view/non-commercial >>> >> >>> >> Many years ago, I wrote the vtkRIBExporter that produces RenderMan >>> >> files. At that time, there was a free package BMRT that accepted >>> >> RenderMan files and created high quality renderings from VTK models. >>> >> In fact, almost all of the images in the VTK book centerfold plates >>> >> were produced using vtkRIBExporter and BMRT. >>> >> >>> >> The new free license has commercial restrictions, but they seem >>> >> lenient unless you want to sell your animations. >>> >> >>> >> I've requested a free license. I'll keep the group informed... >>> >> >>> >> Bill >>> >> _______________________________________________ >>> >> Powered by www.kitware.com >>> >> >>> >> Visit other Kitware open-source projects at >>> >> http://www.kitware.com/opensource/opensource.html >>> >> >>> >> Follow this link to subscribe/unsubscribe: >>> >> http://www.vtk.org/mailman/listinfo/vtk-developers >>> >> >>> > >>> >>> >>> >>> -- >>> Unpaid intern in BillsBasement at noware dot com >> >> > > > > -- > Unpaid intern in BillsBasement at noware dot com -- Unpaid intern in BillsBasement at noware dot com -------------- next part -------------- cmake_minimum_required(VERSION 2.8) PROJECT(dented) find_package(VTK REQUIRED) include(${VTK_USE_FILE}) add_executable(dented MACOSX_BUNDLE dented) target_link_libraries(dented ${VTK_LIBRARIES}) -------------- next part -------------- A non-text attachment was scrubbed... Name: dented.cxx Type: text/x-c++src Size: 3716 bytes Desc: not available URL: From andrew.amaclean at gmail.com Mon Mar 2 16:48:13 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 3 Mar 2015 08:48:13 +1100 Subject: [vtk-developers] VTK module system uplift to CMake 3.0 Message-ID: > > From: Ben Boeckel > To: vtk-developers at vtk.org > Cc: > Date: Mon, 2 Mar 2015 14:52:06 -0500 > Subject: [vtk-developers] VTK module system uplift to CMake 3.0 features > Hi, > > We are currently toying with the idea to update the module system to use > more modern CMake features such as usage requirements, interface > libraries, etc. > ... > > Thoughts? > > Thanks, > > --Ben > > > > +1 Good idea. -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon Mar 2 16:53:41 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 2 Mar 2015 16:53:41 -0500 Subject: [vtk-developers] VTK module system uplift to CMake 3.0 features In-Reply-To: References: <20150302195206.GA28834@megas.kitwarein.com> Message-ID: <348B29AC-1F8C-49FA-9CDD-2159340D164B@kitware.com> Hi Rob, > With the move to target based usage requirements will the ability to create external vtk modules still exist, and will they be able to use things such as vtkMPI? Why would target-based usage requirements prevent external VTK modules? Thanks, David From marcus.hanwell at kitware.com Mon Mar 2 17:49:42 2015 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 2 Mar 2015 17:49:42 -0500 Subject: [vtk-developers] VTK module system uplift to CMake 3.0 features In-Reply-To: <348B29AC-1F8C-49FA-9CDD-2159340D164B@kitware.com> References: <20150302195206.GA28834@megas.kitwarein.com> <348B29AC-1F8C-49FA-9CDD-2159340D164B@kitware.com> Message-ID: On Mon, Mar 2, 2015 at 4:53 PM, David Thompson wrote: > Hi Rob, > >> With the move to target based usage requirements will the ability to create external vtk modules still exist, and will they be able to use things such as vtkMPI? > > Why would target-based usage requirements prevent external VTK modules? > Perhaps because removing/deprecating vtkMPI.cmake etc would change the build system interface. Traditionally the VTK build system has been fairly static, and people come to rely on CMake code. Not sure that is a major consideration at this stage, but it should be considered. I know we have had a number of people ask about the instantiator CMake code... My main objection is that Ubuntu LTS 14.04 has CMake 2.8.12.2, and that is the most recent LTS (next is out next year I believe). CMake is reasonably easy to obtain/install locally updated versions, but LTS/distro CMake versions present an additional barrier. If people agree it is worth it then we should go with it, but a number of people tend to use LTS/enterprise versions to simplify upgrade cycles (3.0 was tagged June 10 from the looks of it). Marcus From david.thompson at kitware.com Mon Mar 2 17:57:33 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 2 Mar 2015 17:57:33 -0500 Subject: [vtk-developers] VTK module system uplift to CMake 3.0 features In-Reply-To: References: <20150302195206.GA28834@megas.kitwarein.com> <348B29AC-1F8C-49FA-9CDD-2159340D164B@kitware.com> Message-ID: > ... My main objection is that Ubuntu LTS 14.04 has CMake 2.8.12.2, and > that is the most recent LTS (next is out next year I believe). CMake > is reasonably easy to obtain/install locally updated versions, but > LTS/distro CMake versions present an additional barrier. If it helps, I made a PPA: https://launchpad.net/~dcthomp/+archive/ubuntu/smtk/+packages for building some software (SMTK) on Travis that requires CMake 3.x. If you are going to install a modern VTK (instead of whatever version LTS comes with), then it seems reasonable to depend on a modern CMake. David From marcus.hanwell at kitware.com Mon Mar 2 18:05:59 2015 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 2 Mar 2015 18:05:59 -0500 Subject: [vtk-developers] VTK module system uplift to CMake 3.0 features In-Reply-To: References: <20150302195206.GA28834@megas.kitwarein.com> <348B29AC-1F8C-49FA-9CDD-2159340D164B@kitware.com> Message-ID: On Mon, Mar 2, 2015 at 5:57 PM, David Thompson wrote: >> ... My main objection is that Ubuntu LTS 14.04 has CMake 2.8.12.2, and >> that is the most recent LTS (next is out next year I believe). CMake >> is reasonably easy to obtain/install locally updated versions, but >> LTS/distro CMake versions present an additional barrier. > > If it helps, I made a PPA: > > https://launchpad.net/~dcthomp/+archive/ubuntu/smtk/+packages I think it does help, I have been meaning to figure out how to do this for a while for some of the stuff I am working on. > > for building some software (SMTK) on Travis that requires CMake 3.x. If you are going to install a modern VTK (instead of whatever version LTS comes with), then it seems reasonable to depend on a modern CMake. > It does if the features are really worth it. You are moving from git clone, to add my PPA, upgrade these packages, git clone... Doable, but raising the bar. I don't know enough about the advantages of the upgraded features on VTK's build system, and don't feel strongly if there is consensus that it's worth the cost. Just pointing out the additional hoops (mostly don't exist on Mac OS X/Windows). Personally, I would love to see us move to C++11 sooner rather than later, remove more workarounds for ancient compilers/OpenGL versions. I know compilers and OpenGL versions are far less self-contained than CMake is, especially when considering supercomputers, NDKs, etc. Marcus From ben.boeckel at kitware.com Mon Mar 2 19:49:40 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 2 Mar 2015 19:49:40 -0500 Subject: [vtk-developers] VTK module system uplift to CMake 3.0 features In-Reply-To: References: <20150302195206.GA28834@megas.kitwarein.com> <348B29AC-1F8C-49FA-9CDD-2159340D164B@kitware.com> Message-ID: <20150303004940.GD24452@bronto-burt.dev.benboeckel.net> On Mon, Mar 02, 2015 at 17:49:42 -0500, Marcus D. Hanwell wrote: > Perhaps because removing/deprecating vtkMPI.cmake etc would change the > build system interface. Traditionally the VTK build system has been > fairly static, and people come to rely on CMake code. Not sure that is > a major consideration at this stage, but it should be considered. I > know we have had a number of people ask about the instantiator CMake > code... My plan was to keep all changes, to start, local to vtkModuleMacros.cmake. This would ensure that code written for the old API would still work (well, as far as CMake uses the API at least). Any functions which would now be unnecessary would cause warning messages based on a flag so that users/developers would have an upgrade path (though whether to default to ON or OFF is a valid question). > My main objection is that Ubuntu LTS 14.04 has CMake 2.8.12.2, and > that is the most recent LTS (next is out next year I believe). CMake > is reasonably easy to obtain/install locally updated versions, but > LTS/distro CMake versions present an additional barrier. If people > agree it is worth it then we should go with it, but a number of people > tend to use LTS/enterprise versions to simplify upgrade cycles (3.0 > was tagged June 10 from the looks of it). I think a PPA is fine for developers. I don't expect VTK 6.3 or whatever version it ends up in to even be a thought for LTS. --Ben From ben.boeckel at kitware.com Mon Mar 2 19:50:38 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 2 Mar 2015 19:50:38 -0500 Subject: [vtk-developers] VTK module system uplift to CMake 3.0 features In-Reply-To: <20150302202134.391991153@mail.rogue-research.com> References: <20150302195206.GA28834@megas.kitwarein.com> <20150302202134.391991153@mail.rogue-research.com> Message-ID: <20150303005038.GE24452@bronto-burt.dev.benboeckel.net> On Mon, Mar 02, 2015 at 15:21:34 -0500, Sean McBride wrote: > Sound good to me. I guess getting all the dashboards updated would be > one of the first tasks... Yes. We could certainly put a warning in CMake to start if we go down this road to make the dashboards using older CMake versions stand out. --Ben From marcus.hanwell at kitware.com Tue Mar 3 10:40:44 2015 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 3 Mar 2015 10:40:44 -0500 Subject: [vtk-developers] VTK module system uplift to CMake 3.0 features In-Reply-To: <20150303004940.GD24452@bronto-burt.dev.benboeckel.net> References: <20150302195206.GA28834@megas.kitwarein.com> <348B29AC-1F8C-49FA-9CDD-2159340D164B@kitware.com> <20150303004940.GD24452@bronto-burt.dev.benboeckel.net> Message-ID: On Mon, Mar 2, 2015 at 7:49 PM, Ben Boeckel wrote: > On Mon, Mar 02, 2015 at 17:49:42 -0500, Marcus D. Hanwell wrote: >> Perhaps because removing/deprecating vtkMPI.cmake etc would change the >> build system interface. Traditionally the VTK build system has been >> fairly static, and people come to rely on CMake code. Not sure that is >> a major consideration at this stage, but it should be considered. I >> know we have had a number of people ask about the instantiator CMake >> code... > > My plan was to keep all changes, to start, local to > vtkModuleMacros.cmake. This would ensure that code written for the old > API would still work (well, as far as CMake uses the API at least). Any > functions which would now be unnecessary would cause warning messages > based on a flag so that users/developers would have an upgrade path > (though whether to default to ON or OFF is a valid question). Sounds like a good plan. > >> My main objection is that Ubuntu LTS 14.04 has CMake 2.8.12.2, and >> that is the most recent LTS (next is out next year I believe). CMake >> is reasonably easy to obtain/install locally updated versions, but >> LTS/distro CMake versions present an additional barrier. If people >> agree it is worth it then we should go with it, but a number of people >> tend to use LTS/enterprise versions to simplify upgrade cycles (3.0 >> was tagged June 10 from the looks of it). > > I think a PPA is fine for developers. I don't expect VTK 6.3 or whatever > version it ends up in to even be a thought for LTS. > Just to be clear I wasn't thinking about packaging VTK, I was thinking about the experience for a developer/user compiling from master or a release. We have generally managed to keep our initial compile instructions to (more or less) clone/download VTK sources, run system CMake, compilers, OpenGL etc. We would likely bump that to download/compile CMake/add a PPA, then do the other stuff. If we can make it even easier for end users not wanting to compile the latest and greatest by providing PPAs and similar for other distros that would be a big step forward for those cases (although we would need to see how much extra effort was involved too). There are several projects doing this already in order to get the latest releases without any need for downloading, unpacking, compiling, etc for thoese just wanting to use their binaries. Marcus From marcus.hanwell at kitware.com Tue Mar 3 10:42:02 2015 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 3 Mar 2015 10:42:02 -0500 Subject: [vtk-developers] [vtkusers] VTK accepted for Google Summer of Code 2015 In-Reply-To: References: Message-ID: On Mon, Mar 2, 2015 at 2:34 PM, David E DeMarle wrote: > Good news everyone - VTK was chosen to be a mentor organization for Google's > Summer of Code program! > > If you have the urge hone your development skills and want an internship > working on VTK from the comfort of your own home this summer, please apply. > See the list of project ideas that we've come up with so far > (http://www.vtk.org/Wiki/VTK/GSoC_2015) and apply through the Summer of Code > web site (https://www.google-melange.com/gsoc/homepage/google/gsoc2015). > This is great news, looking forward to seeing what our students propose this year. If you know students thinking about taking part not on this list please let them know about our participation too. Marcus From ben.boeckel at kitware.com Tue Mar 3 12:51:19 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 3 Mar 2015 12:51:19 -0500 Subject: [vtk-developers] VTK module system uplift to CMake 3.0 features In-Reply-To: References: <20150302195206.GA28834@megas.kitwarein.com> <348B29AC-1F8C-49FA-9CDD-2159340D164B@kitware.com> <20150303004940.GD24452@bronto-burt.dev.benboeckel.net> Message-ID: <20150303175119.GA19931@megas.kitwarein.com> > On Mon, Mar 2, 2015 at 7:49 PM, Ben Boeckel wrote: > > (though whether to default to ON or OFF is a valid question). For the default, how about we default to OFF to start while turning it ON for the dashboards. When work completes, we can wait for X weeks then default it to ON. On Tue, Mar 03, 2015 at 10:40:44 -0500, Marcus D. Hanwell wrote: > Just to be clear I wasn't thinking about packaging VTK, I was thinking > about the experience for a developer/user compiling from master or a > release. We have generally managed to keep our initial compile > instructions to (more or less) clone/download VTK sources, run system > CMake, compilers, OpenGL etc. We would likely bump that to > download/compile CMake/add a PPA, then do the other stuff. I think adding a PPA is fine here. We might need to consider those who don't have root and can't use PPAs as well and provide from-source instructions. > If we can make it even easier for end users not wanting to compile the > latest and greatest by providing PPAs and similar for other distros > that would be a big step forward for those cases (although we would > need to see how much extra effort was involved too). There are several > projects doing this already in order to get the latest releases > without any need for downloading, unpacking, compiling, etc for thoese > just wanting to use their binaries. Fedora has 2.8.12.2 in F20 and F19 and below are EOL anyways. I have a copr for CMake master here[1] I update sporadically and can spin up another for 3.x if wanted. I think I can build against EPEL5 as well, but I'd have to double check (EPEL6 is definitely possible). --Ben [1]http://copr.fedoraproject.org/coprs/mathstuf/cmake-master/ From cory.quammen at kitware.com Tue Mar 3 14:03:06 2015 From: cory.quammen at kitware.com (Cory Quammen) Date: Tue, 3 Mar 2015 14:03:06 -0500 Subject: [vtk-developers] Approved gerrit topic branches ready for merging Message-ID: Dear VTK Developers, Spring isn't that far away (at least in the northern hemisphere), so a little spring cleaning is in order. There are a number of topic branches on gerrit that have been approved but have not yet been merged. If they are yours and you can merge them, please do so. If the topic branch is no longer needed, please abandon the topic. I have listed the owners and the approved topics below. Sean McBride - http://review.source.kitware.com/#/t/5510/ Chris Harris - http://review.source.kitware.com/#/t/5425/ Sankhesh Jhaveri - http://review.source.kitware.com/#/t/5536/ Will Schroeder - http://review.source.kitware.com/#/t/5300/ Joachim Pouderoux - http://review.source.kitware.com/#/t/5207/ Sean McBride - http://review.source.kitware.com/#/t/5158/ Will Schroder - http://review.source.kitware.com/#/t/4821/ Utkarsh Ayachit - http://review.source.kitware.com/#/t/4963/ Paul Edwards - http://review.source.kitware.com/#/t/3855/ Paul Edwards - http://review.source.kitware.com/#/t/3854/ Marcus Hanwell - http://review.source.kitware.com/#/t/4340/ Thanks! Cory -- Cory Quammen R&D Engineer Kitware, Inc. From bill.lorensen at gmail.com Tue Mar 3 14:54:57 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 3 Mar 2015 14:54:57 -0500 Subject: [vtk-developers] Mac compile errors after recent check in Message-ID: Will, This continuous Mac: https://open.cdash.org/viewBuildError.php?buildid=3717336 fails to compile your new sample function. These are the same errors I get on my Mac. Bill -- Unpaid intern in BillsBasement at noware dot com From will.schroeder at kitware.com Tue Mar 3 14:56:30 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Tue, 3 Mar 2015 14:56:30 -0500 Subject: [vtk-developers] Mac compile errors after recent check in In-Reply-To: References: Message-ID: Time for a new Mac! Seriously it's probably the typename-related stuff. I'll get on it, W On Tue, Mar 3, 2015 at 2:54 PM, Bill Lorensen wrote: > Will, > > This continuous Mac: > https://open.cdash.org/viewBuildError.php?buildid=3717336 fails to > compile your new sample function. These are the same errors I get on > my Mac. > > Bill > > -- > Unpaid intern in BillsBasement at noware dot com > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Mar 3 15:12:30 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 3 Mar 2015 15:12:30 -0500 Subject: [vtk-developers] Renderman Announces new pricing policy In-Reply-To: References: Message-ID: Dave, I need to do some repair work on the RIB classes. I think I know how to proceed. Hopefully I'll have a gerrit topic soon. Bill On Mon, Mar 2, 2015 at 3:37 PM, Bill Lorensen wrote: > Ooops... Here is the source and cmake file: > > > On Mon, Mar 2, 2015 at 3:35 PM, Bill Lorensen wrote: >> Dave, >> >> I was able to create this image dented.tif >> which very similar to an image I created years ago: >> http://web.archive.org/web/19970630025047/http://www.crd.ge.com/~lorensen/vtkrib/ >> >> I had to hand edit the .rib file. I need to update the RIB exporter. >> Don't waste time on this until I fix the RIB exporter and property. >> >> It is encouraging since that example uses a shader that I wrote. >> >> I also attached the c++ code that almost produced a good rib file. >> >> Bill >> >> >> On Mon, Mar 2, 2015 at 11:40 AM, David E DeMarle >> wrote: >>> I'll let you know when I get past the black screen rendered with VTK >>> cells.py's cells.rib file. >>> >>> >>> David E DeMarle >>> Kitware, Inc. >>> R&D Engineer >>> 21 Corporate Drive >>> Clifton Park, NY 12065-8662 >>> Phone: 518-881-4909 >>> >>> On Mon, Mar 2, 2015 at 11:34 AM, Bill Lorensen >>> wrote: >>>> >>>> I'll take a look. >>>> >>>> Thanks, >>>> >>>> Bill >>>> >>>> >>>> On Mon, Mar 2, 2015 at 11:30 AM, David E DeMarle >>>> wrote: >>>> > There is also the pixie project, a high quality rendering engine that >>>> > accepts RIB input. >>>> > http://www.renderpixie.com >>>> > seems to compile and run easily enough. >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > David E DeMarle >>>> > Kitware, Inc. >>>> > R&D Engineer >>>> > 21 Corporate Drive >>>> > Clifton Park, NY 12065-8662 >>>> > Phone: 518-881-4909 >>>> > >>>> > On Fri, May 30, 2014 at 5:08 PM, Bill Lorensen >>>> > wrote: >>>> >> >>>> >> Folks, >>>> >> >>>> >> Mike Halle referred me to this article regarding RenderMan: >>>> >> http://renderman.pixar.com/view/non-commercial >>>> >> >>>> >> Many years ago, I wrote the vtkRIBExporter that produces RenderMan >>>> >> files. At that time, there was a free package BMRT that accepted >>>> >> RenderMan files and created high quality renderings from VTK models. >>>> >> In fact, almost all of the images in the VTK book centerfold plates >>>> >> were produced using vtkRIBExporter and BMRT. >>>> >> >>>> >> The new free license has commercial restrictions, but they seem >>>> >> lenient unless you want to sell your animations. >>>> >> >>>> >> I've requested a free license. I'll keep the group informed... >>>> >> >>>> >> Bill >>>> >> _______________________________________________ >>>> >> Powered by www.kitware.com >>>> >> >>>> >> Visit other Kitware open-source projects at >>>> >> http://www.kitware.com/opensource/opensource.html >>>> >> >>>> >> Follow this link to subscribe/unsubscribe: >>>> >> http://www.vtk.org/mailman/listinfo/vtk-developers >>>> >> >>>> > >>>> >>>> >>>> >>>> -- >>>> Unpaid intern in BillsBasement at noware dot com >>> >>> >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com > > > > -- > Unpaid intern in BillsBasement at noware dot com -- Unpaid intern in BillsBasement at noware dot com From dave.demarle at kitware.com Tue Mar 3 15:15:01 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 3 Mar 2015 15:15:01 -0500 Subject: [vtk-developers] Renderman Announces new pricing policy In-Reply-To: References: Message-ID: Great thanks! Let me know if you need anything, I'm working on something related and can chip in some time if needed. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Mar 3, 2015 at 3:12 PM, Bill Lorensen wrote: > Dave, > > I need to do some repair work on the RIB classes. I think I know how > to proceed. Hopefully I'll have a gerrit topic soon. > > Bill > > > On Mon, Mar 2, 2015 at 3:37 PM, Bill Lorensen > wrote: > > Ooops... Here is the source and cmake file: > > > > > > On Mon, Mar 2, 2015 at 3:35 PM, Bill Lorensen > wrote: > >> Dave, > >> > >> I was able to create this image dented.tif > >> which very similar to an image I created years ago: > >> > http://web.archive.org/web/19970630025047/http://www.crd.ge.com/~lorensen/vtkrib/ > >> > >> I had to hand edit the .rib file. I need to update the RIB exporter. > >> Don't waste time on this until I fix the RIB exporter and property. > >> > >> It is encouraging since that example uses a shader that I wrote. > >> > >> I also attached the c++ code that almost produced a good rib file. > >> > >> Bill > >> > >> > >> On Mon, Mar 2, 2015 at 11:40 AM, David E DeMarle > >> wrote: > >>> I'll let you know when I get past the black screen rendered with VTK > >>> cells.py's cells.rib file. > >>> > >>> > >>> David E DeMarle > >>> Kitware, Inc. > >>> R&D Engineer > >>> 21 Corporate Drive > >>> Clifton Park, NY 12065-8662 > >>> Phone: 518-881-4909 > >>> > >>> On Mon, Mar 2, 2015 at 11:34 AM, Bill Lorensen < > bill.lorensen at gmail.com> > >>> wrote: > >>>> > >>>> I'll take a look. > >>>> > >>>> Thanks, > >>>> > >>>> Bill > >>>> > >>>> > >>>> On Mon, Mar 2, 2015 at 11:30 AM, David E DeMarle > >>>> wrote: > >>>> > There is also the pixie project, a high quality rendering engine > that > >>>> > accepts RIB input. > >>>> > http://www.renderpixie.com > >>>> > seems to compile and run easily enough. > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > David E DeMarle > >>>> > Kitware, Inc. > >>>> > R&D Engineer > >>>> > 21 Corporate Drive > >>>> > Clifton Park, NY 12065-8662 > >>>> > Phone: 518-881-4909 > >>>> > > >>>> > On Fri, May 30, 2014 at 5:08 PM, Bill Lorensen < > bill.lorensen at gmail.com> > >>>> > wrote: > >>>> >> > >>>> >> Folks, > >>>> >> > >>>> >> Mike Halle referred me to this article regarding RenderMan: > >>>> >> http://renderman.pixar.com/view/non-commercial > >>>> >> > >>>> >> Many years ago, I wrote the vtkRIBExporter that produces RenderMan > >>>> >> files. At that time, there was a free package BMRT that accepted > >>>> >> RenderMan files and created high quality renderings from VTK > models. > >>>> >> In fact, almost all of the images in the VTK book centerfold plates > >>>> >> were produced using vtkRIBExporter and BMRT. > >>>> >> > >>>> >> The new free license has commercial restrictions, but they seem > >>>> >> lenient unless you want to sell your animations. > >>>> >> > >>>> >> I've requested a free license. I'll keep the group informed... > >>>> >> > >>>> >> Bill > >>>> >> _______________________________________________ > >>>> >> Powered by www.kitware.com > >>>> >> > >>>> >> Visit other Kitware open-source projects at > >>>> >> http://www.kitware.com/opensource/opensource.html > >>>> >> > >>>> >> Follow this link to subscribe/unsubscribe: > >>>> >> http://www.vtk.org/mailman/listinfo/vtk-developers > >>>> >> > >>>> > > >>>> > >>>> > >>>> > >>>> -- > >>>> Unpaid intern in BillsBasement at noware dot com > >>> > >>> > >> > >> > >> > >> -- > >> Unpaid intern in BillsBasement at noware dot com > > > > > > > > -- > > Unpaid intern in BillsBasement at noware dot com > > > > -- > Unpaid intern in BillsBasement at noware dot com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Mar 4 11:21:18 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 4 Mar 2015 11:21:18 -0500 Subject: [vtk-developers] announce: vtk 6.2.0 release candidate 1 is ready In-Reply-To: References: <20150219200444.933334771@mail.rogue-research.com> <20150219212511.1505792326@mail.rogue-research.com> <20150219214749.727843881@mail.rogue-research.com> <20150225165255.967467100@mail.rogue-research.com> Message-ID: <20150304162118.1188265019@mail.rogue-research.com> So I untangled this... In the Insert...() methods of the various vtk*Array classes there are calls to ResizeAndExtend() within which there are code paths like: if (newSize <= 0) { this->Initialize(); return 0; } if ( (newArray = new unsigned char[(newSize+7)/8]) == NULL ) { vtkErrorMacro(<< "Cannot allocate memory\n"); return 0; } So 'return 0' looked (looks!) like an error-only path to me, and I added a vtkErrorMacro to the first 'if'. (That's now reverted.) But 'newSize' of 0 is not an error path, it's an acceptable size to resize to. Q1) What's the return value of ResizeAndExtend() mean? It's not well documented. Q2) Should resize to 0 be returning null? Initialize() sets the 'Array' ivar to null. But the callers of ResizeAndExtend() don't check the return value and then have code paths that dereference 'Array'. Hence the analyzer warning. Alas, the Insert...() methods don't have any return value to notify _their_ callers of failure. So there's no beautiful fix that I see. This is most reasonable thing I could come up with: Sean On Wed, 25 Feb 2015 10:42:40 -0700, David Gobbi said: >It looks like the added vtkErrorMacro() will be called whenever Squeeze() >is called on an empty array, which is a common occurrence and should >definitely not generate an error. > >I think the patch should be reverted (though I was the reviewer... oops!). > > - David > > >On Wed, Feb 25, 2015 at 9:59 AM, David E DeMarle >wrote: > >> Keep us informed. If it needs fixing we're still making fixes and taking >> patches based off anywhere upstream of the release branch point and tested >> in master. >> >> We'll make a decision on turning the release branch into either rc2 or >> final on Monday some time. >> >> On Wed, Feb 25, 2015 at 11:52 AM, Sean McBride >> wrote: >>> >>> >>> No serious issues found. >>> >>> Maybe found a mistake I made though: >>> >>> >>> >>> I think some of the vtkErrorMacros I added should maybe not be there, as >>> I see them running my app where I don't believe I saw them before. Then >>> again, they are maybe flagging a real issue that was not flagged before. >>> Haven't had time to dig... From sean at rogue-research.com Wed Mar 4 11:41:37 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 4 Mar 2015 11:41:37 -0500 Subject: [vtk-developers] VTK module system uplift to CMake 3.0 features In-Reply-To: References: <20150302195206.GA28834@megas.kitwarein.com> <348B29AC-1F8C-49FA-9CDD-2159340D164B@kitware.com> Message-ID: <20150304164137.270263843@mail.rogue-research.com> On Mon, 2 Mar 2015 18:05:59 -0500, Marcus D. Hanwell said: >Personally, I would love to see us move to C++11 sooner rather than >later, I have been playing with clang-modernize to migrate to nullptr: >remove more workarounds for ancient compilers/OpenGL versions. >I know compilers and OpenGL versions are far less self-contained than >CMake is, especially when considering supercomputers, NDKs, etc. I have in the past pruned #if crud for ancient compilers... I could do more. Do we have an agreed upon list of minimum compiler versions supported? FYI: My oldest dashboard uses gcc 4.2 (Apple fork). Only list I know is here: Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From saurabh.iitd02 at gmail.com Thu Mar 5 00:54:18 2015 From: saurabh.iitd02 at gmail.com (saurabh bhadada) Date: Thu, 5 Mar 2015 11:24:18 +0530 Subject: [vtk-developers] gsoc'15 Message-ID: Hey guys, I am Saurabh Bhadada 3rd year student of Indian Institute of Technology, Delhi. I'm interested to work on gsoc'15 project " improvements to earth and space science visualization". I have previously worked on OpenGL and I am proficient in c++. And I am learning VTK right now. please tell if i am suitable candidate. Thank You Saurabh Bhadada 3rd Year Integrated Mathematics and Computing IIT Delhi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Thu Mar 5 09:58:22 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 5 Mar 2015 09:58:22 -0500 Subject: [vtk-developers] gsoc'15 In-Reply-To: References: Message-ID: On Thu, Mar 5, 2015 at 12:54 AM, saurabh bhadada wrote: > Hey guys, > I am Saurabh Bhadada 3rd year student of Indian Institute of Technology, > Delhi. I'm interested to work on gsoc'15 project " improvements to earth > and space science visualization". I have previously worked on OpenGL and I > am proficient in c++. And I am learning VTK right now. > > please tell if i am suitable candidate. > > Sure. Your background sounds sufficient. The fact that you are discussing things on the mailing list is a good indicator of success too. More advice: * If you work with the list and a project mentor your proposal is much more likely to be a good one and be chosen. * Google SoC organizers say that across all projects, students who manage to submit even the tiniest patch (say fixing a typo in documentation for instance) to their mentoring organization early on are 90% more likely to get a passing mark than those who do not. good luck > Thank You > > Saurabh Bhadada > 3rd Year Integrated Mathematics and Computing > IIT Delhi. > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens.g.w.schmidt at gmx.de Thu Mar 5 10:39:54 2015 From: jens.g.w.schmidt at gmx.de (Jens Schmidt) Date: Thu, 05 Mar 2015 16:39:54 +0100 Subject: [vtk-developers] Website lists VTK 6.2.0 as available Message-ID: <54F878CA.5030104@gmx.de> Hello Everybody, vtk is just awesome! Unfortunately there might be a hicup with the website: the vtk website states vtk 6.2.0 as available stable release. However, i am unable to download the tar.gz. Also: the git tag is reported as 6.2.0-rc1 Sincerely Jens Schmidt From dave.demarle at kitware.com Thu Mar 5 10:56:05 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 5 Mar 2015 10:56:05 -0500 Subject: [vtk-developers] gsoc'15 In-Reply-To: References: Message-ID: To clear up any misreading of my intent on that second piece of advice about submitting patches... It really only applies to accepted students. Submitting patches, although a great thing to do for any project at any time, has no bearing on whether or not your proposal will be accepted by the mentoring organization. It just meant that the program administrators at google have consistently found that students who submit patches early on in their projects are highly correlated with students who get a passing grade at the end of the summer. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Mar 5, 2015 at 9:58 AM, David E DeMarle wrote: > On Thu, Mar 5, 2015 at 12:54 AM, saurabh bhadada > wrote: > >> Hey guys, >> I am Saurabh Bhadada 3rd year student of Indian Institute of Technology, >> Delhi. I'm interested to work on gsoc'15 project " improvements to earth >> and space science visualization". I have previously worked on OpenGL and I >> am proficient in c++. And I am learning VTK right now. >> >> please tell if i am suitable candidate. >> >> > Sure. Your background sounds sufficient. The fact that you are discussing > things on the mailing list is a good indicator of success too. > > More advice: > * If you work with the list and a project mentor your proposal is much > more likely to be a good one and be chosen. > * Google SoC organizers say that across all projects, students who manage > to submit even the tiniest patch (say fixing a typo in documentation for > instance) to their mentoring organization early on are 90% more likely to > get a passing mark than those who do not. > > good luck > > > > >> Thank You >> >> Saurabh Bhadada >> 3rd Year Integrated Mathematics and Computing >> IIT Delhi. >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Thu Mar 5 11:00:06 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 5 Mar 2015 11:00:06 -0500 Subject: [vtk-developers] Website lists VTK 6.2.0 as available In-Reply-To: <54F878CA.5030104@gmx.de> References: <54F878CA.5030104@gmx.de> Message-ID: Thanks Jens. The download should work now and the tag text will be fixed later today. I was just waiting for one more thing before making that announcement and now that is uploaded... David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Mar 5, 2015 at 10:39 AM, Jens Schmidt wrote: > Hello Everybody, > > vtk is just awesome! Unfortunately there might be a hicup with the > website: the vtk website states vtk 6.2.0 as available stable release. > However, i am unable to download the tar.gz. > Also: the git tag is reported as 6.2.0-rc1 > > Sincerely > Jens Schmidt > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Thu Mar 5 11:09:04 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 5 Mar 2015 11:09:04 -0500 Subject: [vtk-developers] ANNOUNCE: vtk 6.2.0 is ready! Message-ID: The VTK development team is happy to announce that VTK 6.2.0 is ready. Special thanks go out to everyone who tested and provided input and fixes during the release candidate cycle. You can find the source, data, and vtkpython binary packages here: http://www.vtk.org/VTK/resources/software.html You can read the release notes at: http://www.kitware.com/blog/home/post/858 And you can see the list of changes in the attachment or by: git shortlog --no-merges --format="%h %s" v6.1.0..v6.2.0 We hope you find this release of VTK useful and bug free. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Aashish Chaudhary (261): 0e0fcf4 Fixed headlight not working right when using the ext renderer d230223 Fixed missing display, window, and context id not being set a75302c Fixed splitviewport stereo rendering 684b075 Added new volume rendering code f28ada9 Fixed texture state being dirty 5f8896c Use correct local bounds 30078b3 Fixed rotation bug 8aa2703 Fixed style 61a439f Fixed geometry beign missing after volume render 935f90a Fixed indent 6da7caf Silenced cast warnings 63bc6e5 Fixed style and naming conventions f1ab262 Added copyright f06c64d Embedded volume shaders into C++ units 2b9940e Fixed broken volume rendering because of uninitialized variable dbbe3e6 Fixed code document style a bit d929be5 Added method to validate volume rendering d7e882e Enable sample distance control e150d08 Enabled additive and composite blend mode 115d356 Use depth buffer to terminate ray d42a771 Fixed incorrect mix geometry and volume rendering 5b43621 Added string replacement code 2ad1d38 First pass on compositing shader for the rendering f405ada Formalizing the grammar for the shader replacement 06eac96 Updated volume code to use new compositing mode 3bd9852 Updating shader to be fully programmable b2a58bc Fixed loose ends 0825af0 Using appropriate variable names 7e81213 Rebuild shader if necessary 7b743c9 Rename Helper to ShaderComposer as thats best suited d1972c3 Added tests for the new volume mapper dcd4d56 Consolidating shading and color accumulation 3a9bd5d Got maximum intensity working 8dfdba9 Pass mapper to composer calls as its needed to query volume params adf766c Simplified the code a bit 6f5d0c9 Fixed minor calculation bug 1266ed1 Got rid of hard-coded maximum number of samples d8a14f8 Removed references to vtkgl ee3674d Separated lookup for clarity 371c900 Compute and store actual max value 25b42ab Fixed bad gl state at the start of volume rendering 32f0a22 Implemented cropping feature 015a5ea Using a better amplitude for the noise texture cdf1bc5 Use boolean to skip or consider a pixel for rendering 1673f76 Build cropping shader dynamically 2597bd3 Condensed preprocessor tags 57939c2 Perform close bounds check b46c7cb Updated tests af6164a Got clipping working c7d687a Passing size and data for clip planes in a single uniform array d928a47 Implemented clipping via substitution 6ab3311 Fixed clipping for multiple clip planes 6d74191 Fixed normals not getting passed correctly 9898eef Fixed crash on resizing 591be8c Updated clip test planes to reasonable values 6761103 Following consistent way of checking for uninitiliazed values 663a115 Removed hard-coded sample distance 88bc4f5 Adding minimum intensity blend capability 4817b6e Fixed wrong initial value of the min value 5cb00aa Fixed biased not being passed to the shader 7210c83 Some more minor fixes b66de99 Fixed rendering of short and some other types d50fe29 Added support for double (and other 8 bytes) datatypes 6d7faf1 Adding alpha blending bce3935 Fixed issues with additive blending da263ce Renaming so that we can replace the old one with the new one 9134625 Porting new volume mapper to proper vtk d49491f Got new mapper working 7532e7d Renamed the new volume module edb4b72 Fixed cropping 9b2033d Some more fixes 4b8e7ec Removed experimental code on cropping flags 59c68e1 Updated lighting parameters 28ae0ea Adding gradient opacity d5d4ad8 Implementing gradient opacity e9e0b43 Added gradient opacity table to the mapper 6146a77 Added some more pieces for the gradient opacity 1ae30d9 Enabled auto-adjust sample distance 047dab8 Fixed style ad7ce0e Added new gradient opacity test e7e1f51 Added debug code ad25032 Adding gradient opacity calculation 2ba296e Fixing / cleaing variables that are not required cf4648a Fixed access from the texture abd043f Fixing the scaling of the gradients 4346bff Fixing long data types volumes 3dd6f6b Using GLSL version 120 7688fb2 Making gradient opacity optional c0e834e Removed check for gl error for now d28bffe Fixed shader issues on MAC bc09dde Fix white edge showing up 836b161 Fixed wrong invert matrix being passed 7addcd0 Revert "Removed experimental code on cropping flags" 56d1890 Fixed cropping test 1dd3a61 Fixing gradient vector computation 0c05997 Added support for 4 components ed6d089 Adding support for mask type a7e2f7b Fixing shading 93a2879 Adding support for label mask type eda4eeb Fixing issues 88a9522 Restructured the code a bit more to make it flexible 312b8be Fixed some more issues adb970e Fixed lighting issues 089a441 Clean up some code 346a98a Improvig code readability 0a4c068 VTK style fixes 6d45706 Adding support for parallel projection 3152f1b Got parallel projection working 2deb615 Disabled the gradient opacity test for now e517274 Fixed cpp issues 1ddcb2e Silenced compiler warnings a5ae367 Implemented release graphics method 55895e9 For now set reduction ratio to 1.0 a05eb08 Fixed texture units 5496810 Fixed wrong bounds used to pass bound values to shader f147880 Few style fixes 949b862 Updated vtk point picker 1480032 Added support for rendering when clipping by near plane 4c9403a Fixed volume geomety not updated 9dbe622 Using smallest possible delta to offset precision issues d2d49e0 Fixed release graphics resources 85b6fbf Re-added gradient opacity 3b60ff0 Wrapped long lines bad034c Organzied the code bit better ff4d608 Disabled the gradient opacity test for now 59a2a48 Fixed failing tests edf97a3 Added missing API to set uniform 83935cf Updating to use vtk shader API 8c0ce91 Removed calls to old API a8b5e02 Fixed volume not showing up a50a814 Removed unused files 412d909 Fixed licensing 2f9ab04 Removed unused file from cmake 5dbb076 Updated to use vtkTextureObject 1a12533 Use vtkTextureObject if set ea17e38 Updated ray cast image display helper to use GL2 8001b00 Removed unused code 8c6595b Fixed casting to wrong type; copy-paste error bb87f6f Updated headers a298620 Fixed test failing by restoring defaults eec0137 Updated logic for testing for translucency ebec322 Updated logic to check for external texture object ee0b13a Updated display helper 9d8c17f Improved code by removing redundant code 2b180ca Fixed style issues 8a4c62d Added more volume tests that are passing now 16b7022 Removed unused header files 3c16bcb Set referencee to render window for external texture object 23a6be3 Fixed typo df24324 Mark as translucent if 1,2 or 4 components cca0af8 With Ken, fixed resources not release issue 420e22a Added notes, comments 0c38ee5 Updated volume rendering to use shader cache c5e5788 Added error checks for volume render calls f1826be Using render window shader cache 454e0db Fixed volume tests failing because of shader cache 652d736 ShaderCache should release its graphics resources e3eb473 Removed unnecessary call and added notes 4ef3390 Let shader cache invoke release graphics resources on shader 5948b78 Attempt to fix failing test by removing calls to interactor 746fbdd Added second baseline to fix failing test on some systems a1f2ddd Adding support for light kit 323130d Passing required parameters to the shaders ca3bb98 Handling more lighting cases c8468b6 Fixing headlight 3bf32ff Fixed gradient opacity computation 3c42ad2 Implementing positional light 7baf76e Adding test for testing light kit and fixed shader issues 5afbd4e Enabling reduction factor for large volumes 48e8739 Updated so that we can compute the time to draw correctly 451e28d Updating tests for consistent dashboard results 82cb30c Silenced compiler warnings 126f5bf Updated baseline and test for light kit 18ee696 Removed dead code 6c5d054 Fixing lighting computation for lightkit 68efb79 Added convenient method to check for gradient opacity d50999b Updated code to use check on availability of gradient opacity 258afec Removed dead code fded3eb Check for two sided lighting a8c5e8b Attempt to fix failing tests 4c15cbd Added a note on the workaround as well c47bd6e Commented out debug code e4addeb Renamed for consistency 94f5a75 Fixed positional light calculation cc41e9b Fixing positional light bugs adc0b49 Clean up code 7a40c5e Compute appropriate matrix for normal transformation 85240e2 Fixed variable not found 761a289 Fixing variable names 39d54d5 Fixed style issues 58bf3e0 Fixed various lighting and formatting issues 3b473dd Silenced compiler warnings d296e25 Fixed smart volume mapper crashes because of gradient opacity 7c3dc82 Fixed smart volume mapper level test 2de16ee Added GDAL based raster reader 781d1b5 Fixed various minor issues 2cd1a32 Added baseline and data for the testing 7f9c70a Addressed minor code clean up issues 61e7f03 Fixed various cleanup issues 08e8c63 Fixed bad sampling issues when dealing with large sample distances 414e869 Fixed incorrect name used for the test file 84644d2 Update texture with the data 66c813d Fixed data not showing up 2dfab11 Use last texture units for 3D textures 3ed3f22 Added ability to set depth mode formats 301a81c Added ability to use texture modes ed2e827 Set texture parameters before creating the texture 5452f58 Adding support for 3D textures d979a74 Fixed check for depth texture mode 0eb6439 Apply scale and bias in the shader 919018c Added ability to set texture attributes directly 83f30b5 Make sure to release graphics resources 5765faf Updating volume masks 7037d5a Handle large data type textures f9b00c4 Fixing various issues 6952fd3 Updated and improved texture object implementation 0b0ef00 Allow reuse of texture units 1ccf1f8 Removed debug messages f9b07be Fixing MIP issues 708b18d Fixing some more issues 2536b8a Fixed memory leaks and release of textures f88fd40 Removed dead code 1c77710 Removed code for depth texture mode as they are deprecated f731704 Style fixes cb670a9 Fixed loose ends 0605765 Removed extra flag to force re-computation of texture format 1c0929b Updated code so that applications will still work in OpenGL2 ca6c800 Fixed when mappers try to reuse the same texture 8cc19bb Re-added volume benchmark test 60c27a5 Typedef the volume test 625d9b8 Updated volume test 7bb827a Tweaked opacity function to force more computation 66db2b2 Clean up cmake a bit 20e0604 Adding GPU independent component feature 7719149 Updated test to highlight mappings 29ee16d Adding support for multiple components in GPU RayCast afe1ffd Remove limiting check for independent components 417aafb Adding support for multi RGB tables bd7c9cd Fixed erroneous logic e1d9351 Updating shader code to support independent components 74941a4 Adding support for independent components for opacity and color function bcba5b6 Some more updates to support independent components ffb3685 Fixed composite blend mode cefa131 Added independent support for min and max projections 222c367 Pass component weights to the shader 0288952 Fixed testing 9793e11 Renaming classes for consistency 06d9f79 Added support for independent components for gradient opacity eae5750 Improved the test a bit 212252c Reinitialize transfer functions if the property changes 96e31ff Independent component is not supported in OpenGL GPU mapper 109e45e Fixed MIP independent shader bd80e07 Fixed independent component computing for min intensity projection c773710 Fixing volume tests not passing on intel machine 2fa5b37 Removed unused code and check c588664 Do not assume initial min and max values 0e02a94 Attempt to fix failing independent component tests ea65926 GLSL 120 does not support sampler arrays 555f804 Added missing header 24361f8 Fixed errors found using valgrind leak check ed36361 Silenced compiler warnings Andrew Bauer (28): 2e8ba2b Need to check for static targets before adding abi visibility flags. cd5c9af Composite data writers weren't passing down the HeaderType info. 91b3b3e Passing missing parallel writer options to piece writers. 48f2dc0 Fixing overflow issue that appeared with GCC compilers. bde1886 Fix the way point and cell data arrays are marked for reading. c6cea54 Adding in arctan2 through numpy. 8e6b1a3 Adding the ability to not delete the passed in arrays. 18b94cf Fixed memory leak in test and added in comments for clarification. b3399fd Adding in a filter to append structured grids together. f47c96b Adding the ability to merge structured grids for composite data sets. 9cd28a6 Fixed issue with ghost cells not being deleted properly. 4615e59 Removing temporary file that accidentally got added. cfaedbb Fixed issue of possibly modifying other polydatas. f9ecca4 Removing Tcl tests the duplicate existing Python testing. 1e441c1 Fixed incorrect cell data output. d21be2b Making some cell locators more efficient. 00146d3 Giving a warning if trying to create a subcontroller with 0 procs. d72325b Temporary fixes for finding ADIOS. ca1f2ef Fixing flow paths correct injection time and ability to add extra arrays. 1eaa829 Renaming CurrentTime to CurrentTimeValue due to windows mangling issues. 3f86167 Fixing particle paths to have proper SimulationTime output. be2d7b8 Adding in SimulationTimeStep output for particle paths. 409086c Getting rid of clang analyzer warnings. cc551eb Skipping the wasteful and unnecessary inverse sin computation. f86c5f8 Cosmetic change to be consistent with file codeing convention. 3e9bd6e Fix parallel flow paths filters. 0aa6822 Improving testing of deleting cells from a polydata. 5c44bfe Getting rid of compiler warnings. Andrew Maclean (15): 1bc76b6 Remove WindowLevelInterface.tcl and WindowLevelInterface.py 50ea232 Revert Remove WindowLevelInterface.tcl and WindowLevelInterface.py 7e09ea9 Sphere widget behaves better when scaled down to zero 51adcdc ENH: VTK Parametric surfaces - modernised the code. da50514 ENH: Remove the need to manually regenerate the hill data. 728b6a6 DOC: Update vtkRandomHills documentation. e6ac3bf BUG: Fix by adding a new keyword. 2ad6753 ENH: Add option to return an ordinal lookup table. b898432 Make the generation of random hills consistent across all platforms. b0f0948 Add a missing header in vtkCompositePolyDataMapper2 0a0ff7a ENH: Restore / convert Infovis examples 249fd50 Lots of minor changes for Examples to build with OpenGL2 c81b621 This fixes the c2039 error in VS2013. 75cd8a3 Visual Studio 2013 requires the header. 6765c9c Remove the unnecessary find_package command. Antonio Cervone (1): 588fc24 Fixed the BiQuadraticQuad interpolator Arnaud Gelas (2): 6d50f43 Handle properties are not properly set up when starting vtkBoxwidget2 75b0ecb Limiting number of ModifiedEvent when calling vtkTransform::SetMatrix Ben Boeckel (254): 9a00db8 STLWriter: Raise an error for non-triangles 37d058e STLReader: Close the file when an error occurs a1f1505 ExodusIIReader: Add the title to the field data 486b71e STLReader: Fix error signaling when reading files 3e7585c AVIWriter: Don't overflow the fourcc storage d7ec6c1 AVIWriter: Fix a comment typo e073d6d Exodus: Always attach the title to the output fields cd4fc15 Rewrite the testing macros 3d11639 Update the Cxx test call sites bcc9c5a Update the MPI test call sites 3c87d75 Update the Python test call sites 40e594a Update Tcl test call sites 6519612 Minor CMake logic simplification a6faf42 Copy Statistics tests to StatisticsGnuR 3c35e55 Infovis: Add an include for newer Boost versions b6e69cb ParallelMPI: Add missing return statement b7535ca Allow arguments to be passed directly to Python e05e78f Skip adding the executable if no tests are created f79be06 Allow for overriding the data directory in tests 910a306 Allow overriding the baseline directory in tests e04656f Build the VTK test data directory properly 5b742fd Support custom baselines in tests d1548cd Store VTK's ExternalData in its source directory 72cc9e3 Support VTKExternalData_OBJECT_STORES as well e785182 Support custom ExternalData targets for tests 063ddda Support flags to tests common at the module level 3b70ea8 Support JUST_VALID for Python tests e2d1a14 Support Python+MPI testing 9bb5faf Use VTK_TEST_OUTPUT_DIR rather than rebuilding the path e697da8 examples: Fix typo in testing calls bde39fa ParallelGeometry: Fix Grid symbol scoping 6e1350c testing: Use vtk-example as a fallback for prefix 7f6395a Fix test function signatures 2c11e59 testing: Don't look for tests when making an executable 56a6e7b FiltersGeometry: Remove unnecessary links 2b67930 Filters/Geometry: Remove some unused functions from tests 964d6c8 Filters/Geometry: Hide WriteGrid if ENABLE_IO isn't on 64a98b4 testing: add some missing TEST_DEPENDS c92ae44 python: use typedef names 6db00fe python: add reference counting to the object map a2f0bf4 FindPythonModules: use a function 9b2bba1 FindPythonModules: search if not found 6056e10 pythoncore: extract python objects from arguments da8808b wrapping: add function to check for Python objects 9ef52a5 wrapping: wrap PyObject* in python code cae065e python: accept any argument for PyObject* arguments e8ba24a vtkAlgorithm: fix a typo 6691160 FiltersPython: create a vtkPythonAlgorithm class 9955338 python: fix leaks when setting constants in wrappers 4b74588 vtkPythonAlgorithm: support older pythons 0843035 vtkpython: add site-packages to the path 523e3c0 vtkFiltersPython: Disable without Python wrapping ba55146 wrapping: add variables to exclude from language-specific wrapping 0cf8889 vtkFiltersPython: exclude from Java and Tcl wrapping b1b31c9 java: get the list of java modules properly 788a28b testing: append the tests to the given variable 0b1ca3a pythonalg: use keyword arguments rather than members adf3b4d pythonalg: raise an error in RequestData by default 21d93e9 wrapping: remove the ${module}_WRAP_PYTHON variable 5acb230 vtkStructuredImplicitConnectivity: fix msvc warnings 5cbcdfc typo: fix some typos 79724c2 unused: remove unused functions 647b890 mpi4py: add module information 1493ff0 mpi4py: link to CMAKE_DL_LIBS 103bcc0 testing: skip test executables with no tests 118eeca IOVPIC: include MPI headers as SYSTEM headers d510cc5 cmake: set policy 0053 if available a6ccb14 cmake: set policy 0053 in thirdparty cmake 09edf3f mpi4py: add a class to convert communicators 8e09aec wrapping: check for Tcl wrapping exclusion for warnings e64416c vtkAMRUtilities: split out vtkParallelAMRUtilities 050395f hierarchy: use a .txt extension 383f2be GenerateExportHeader: support object libraries as well 4606d0e vtk_module: support a KIT argument e520344 modules: add modules to "kits" 3cd0686 linking: wrap tll() with a module-aware function 3c59cd2 export: OBJECT libraries may not be exported 5ba0639 modules: output kit information in the module tree b192a25 modules: topo-sort modules with kits as well e0757e9 modules: build kits from the member modules b36716a module: depend on the dependent module object library 987f1f4 python: add an option to disable vtkpython 3e937df testing: check for pvtkpython before using it 3a06166 vtkpython: don't install if not enabled 997f2ae vtkAVIWriter: make a more informative error message 81ff451 IO/Geometry: add obj index tests 577c9f4 FiltersParallelGeometry: move functions to the sources 3a86ca4 vtkMPICommunicator: avoid deprecated MPI functions 5c3241b vtkInstantiator: remove instantiator macro from main sources 301afc4 typo: remove duplicate source listing 43d7a64 vtkCompositePolyDataMapper2: cache opacity check f6777cd vtkCompositePolyDataMapper2: include for std::max ea87122 vtkCompositePolyDataMapper2: avoid a NULL dereference ea34fd8 OpenGL: use STATUS for the OSMesa message 5183d0f vtkPStreamTracer: conditionalize functions 8a5c8c1 vtkPTemporalStreamTracer: remove useless code f36df9c unused: add a macro to mark functions as "unused" eda45be vtkChartBox: initialize segmentIndex a09107c nit: remove extra semicolon ff3f8ed vtkMPI: install so that vtk_mpi_link is available 8e8f647 python: install packages properly 161541c opengl2: use STATUS for the OSMesa message 8fa12ca Maintenance: recognize the KIT keyword in scripts 0714be9 vtkmpi4py: empty out Py_{UN,}BLOCK_THREADS f130f0f module: add comment to update maintenance scripts too f76aeee Maintenance: recognize language exclusion keywords ede46c8 warnings: fix narrowing warnings fba50fb TestSurfacePlot: loop using vtkIdType db92b37 vtkQuaternionInterpolator: call the constructor properly 830ef1b warnings: remember values with the proper type 76a3ce4 warnings: use static casts to point out precision loss 37aad40 warnings: use floating point intermediate values 3ed64fc warnings: resolve unused variables 72fd202 vtkOpenGLImageMapper: fix unintentional shadowing 6bd7e61 warnings: fix signed/unsigned comparison warnings 6e38c6b vtkOpenGLProperty: remove unused function f4eece1 unused: use the vtkNotUsed macro 69465e4 Q4VTKWidgetPlugin: only define qDebug if not already defined 97df2a8 mpi4py: use the output, not the result b673e36 cmake: remove unnecessary condition copies f8430ae vtkSmartPyObject: ignore warning C4127 on MSVC 0fe880d mpi4py: use old code with Python 2.6 as well 7cce0e5 web: support Image from PIL in testing 2f81a64 web: print the traceback from errors as well 359f53b vtkPStreamTracer: remove unused function ca90d28 vtkModuleMacros: use STREQUAL rather than MATCHES fc1320b cmake: use functions instead of macros 44f7c75 cmake: minor style nits b0cd19b vtkPythonAlgorithm: print out all the error information 9f4afe4 tk: update to support 8.6 8427822 vtkEnSightReader: use memmove for overlapping regions 16b25ba vtkFFMPEGWriter: use av_malloc to match the av_free 458c079 vtkChartXY: check the scene before use dd542c6 otherByteSwap: fix calls for byteswapping 473036d netcdf: don't use the cache to set variables in the parent scope 2247d89 HeaderTesting: skip non-vtk* files e48e110 HeaderTests: only run if VTK_SOURCE_DIR is set 81eb3de vtkChartXYZ: use dummy bounds rather for bounds calculation 93dac76 vtkChartXYZ: don't copy the points out 9455c61 RenderingOpenGL: remove unused file 900f851 cmake: fix CMP0054 warnings 5a8610c cmake: remove variable dereferences in if statements 581598f windows: use the proper format specifier for DWORD 0ba047df windows: put parentheses around mixed && and || operators fd5e0ef vtkWin32OpenGLRenderWindow: avoid narrowing warnings 695a847 vtkWin32Header: support 64-bit properly on non-MSVC 18f64da vtkWin32Header: always use {Get,Set}WindowLongPtr 40db4ab hdf5: avoid CMP0054 warning 4392ae6 vtkPythonPackages: use IN LISTS syntax in foreach 18f6b27 vtkPythonPackages: avoid CMP0054 warnings a866bb3 vtkOpenGLTexture: don't check for a mapped window fd26999 cmake: remove arguments to else and endfoo commands e196886 cmake: remove arguments from else and endfoo in alglib a934d7a cmake: remove arguments from else and endfoo in exodusII adf2060 cmake: remove arguments from else and endfoo in expat 25399d2 cmake: remove arguments from else and endfoo in freerange de3f6b5 cmake: remove arguments from else and endfoo in freetype 6673e0d cmake: remove arguments from else and endfoo in ftgl 355a11c cmake: remove arguments from else and endfoo in gl2ps 8c9e5e3 cmake: remove arguments from else and endfoo in hdf5 251e4f6 cmake: remove arguments from else and endfoo in jpeg 739b9df cmake: remove arguments from else and endfoo in libproj4 5a07d43 cmake: remove arguments from else and endfoo in libxml2 5e888f7 cmake: remove arguments from else and endfoo in mpi4py 8ce4ee9 cmake: remove arguments from else and endfoo in netcdf 56952ae cmake: remove arguments from else and endfoo in oggtheora f1a6939 cmake: remove arguments from else and endfoo in png 15f6a87 cmake: remove arguments from else and endfoo in sqlite 7f499c1 cmake: remove arguments from else and endfoo in TclTk 41d2d07 cmake: remove arguments from else and endfoo in tiff 49bcf3a cmake: remove arguments from else and endfoo in verdict 9bf393d cmake: remove arguments from else and endfoo in VPIC df306ed cmake: remove arguments from else and endfoo in xdmf2 cf5b134 cmake: remove arguments from else and endfoo in xdmf3 b10c002 cmake: remove arguments from else and endfoo in zlib 08c5b97 cmake: remove arguments to else and endfoo commands 37782ad cmake: remove @var@ expansions 8b04a0b FindTBB: fix up typo'd logic 22b4552 cmake: fix up some version checks 058e722 zlib: remove empty if statements 6b4ea15 vtkInformationDataObjectKey: move to CommonDataModel 28c4633 numpy_support: always support [u]int64 00877bc numpy_support: raise an error if a type cannot be found 5b0ae06 Revert "vtkInformationDataObjectKey: move to CommonDataModel" a400d83 numpy_support: support using dtype array types 3bf2fb7 cmake: use COPYONLY rather than COPY_ONLY d7f7154 vtkWrap: some uses of COPY_ONLY weren't even wrong ef8735a numpy_support: don't convert array types if possible 7e9456a numpy_support: deep copy for type mismatched array data 7ef36ba numpy: test numpy_to_vtk when requesting specific types 0351c12 vtkParticleTracerBase: remove unused function cd783b3 vtkImageCanvasSource2D: add missing newline at eof 222fe37 vtkKdNode, vtkOctreePointLocatorNode: don't assign after a short-circuit 7de9cf0 vtkPolyhedron: initialize the iterator 984e010 HyperTree example: use the iterator before invalidating it 7ff34b7 Widgets example: fix up logic around planeSource 146abbb vtkYoungsMaterialInterface: plug memory leaks 6fc3969 vtkUnstructuredGridGeometryFilter: plug memory leak c64d49f vtkPKdTree: plug memory leak 88ceae4 vtkDistributedDataFilter: plug memory leaks f0a8ac1 vtkKMeansStatistics: plug memory leak d66053f vtkAMRFlashReaderInternal: don't return a pointer to temporary memory 529f85b vtkExodusIIWriter: use a larger buffer 806912b TestIncrementalOctreePointLocator: close file handles 25baa62 vtkCGMWriter: fix typo 69601ed vtkNIFTIImageReader: plug memory leaks 9a78aa1 vtkSLCReader: plug memory leak b4b8206 vtkPLY: handle realloc errors properly e736ad4 vtkEnSightWriter: terminate buffers properly b0bd046 vtkImagePlaneWidget: avoid divide-by-zero f4e756f vtkResliceCursorRepresentation: avoid divide-by-zero 9aef0e7 vtkParseMain: handle realloc errors properly d28c44a vtkParseMain: close the input file 8aa578f vtkParsePreprocess: handle realloc errors properly 86e47ae vtkParsePreprocess: fix up some free() logic for params 79abddf vtkWrapHierarchy: handle realloc errors properly d6d6e8f TestIncrementalOctreePointLocator: use malloc ae3fa6e vtkParse: regenerate lex.yy.c 529dccb vtkParse: address cppcheck messages a59bd8c vtkReebGraph: add a comment about realloc usage 898b425 vtkOpenGLPolyDataMapper2D: comment possible divide-by-zero 87935c2 TestIncrementalOctreePointLocator: remove dead code 1932e6c vtkWin32OpenGLRenderWindow: use size_t for integer storage of pointers a5d30fb vtkWin32OpenGLRenderWindow: wrap assignments in while() in parens ca540cb hdf5: check for the right policy 2b89523 python: remove echo from custom target 04a3ca3 FindMPI: search for msmpi as well 26290c8 FindMPI: fix a CMP0054 warning for CMake e5b02b9 FindMPI: add in the SDK path 3990e92 FindMPI: support newer MSMPI d3c3bde hdf5: remove conflict markers 402aaa2 FindMPI: convert to a safer path representation. 2a17ac3 vtkDataArrayTemplate: fix support for compilers without explicit instantiation 1f32a46 Copyright: bump the year 5c9fa2b vtkRenderingVolumeOpenGL2: remove copy_shaders target ded5ebe IOXdmf3: remove excess MPI stuff 27c0ec4 install: install missing module-related files b06009a netcdf: support a system netcdf 2028be3 cmake: reformat java compilation commands 8384af6 java: add an option to set the target for java compiles 5a49848 wxVTKRenderWindow: support wxPython 3.0 59b38c8 wrapping: find superclasses that are templates be21c18 examples: add shebang lines 200c23e doxygen: remove obsolete options 3d5063d doxygen: add an option to disable CHM files 6286f0c release: add scripts for release maintenance 5cc298e python: don't export Python modules as targets b6e726a maint: use "git checkout" rather than reset 3af86a2 maint: ignore css files for ctags as well eb1ab4b metaio: remove stray reject file 0f7244b vtkModuleTop: handle UsrMove-like setups 7c1083d vtkWrap: use size_t for sizes 4e229e5 vtkPistonMapper: fix a overload-virtual warning d0b86eb vtkWrapTcl: hide dString when there are no methods Berk Geveci (64): 575ebda Removed priority based streaming and fast path. 790115c Removed unused code from vtkModelMetaData and vtkExodusModel ee55278 COMP: Fixed compiler error - needed to remove functions from .h. 2d6d6a6 Improved test to increase vtkDistributedDataFilter's coverage. 2b1a0e3 Cleaned up the Exodus metadata. 0110b9d Fixed minor typo - case sensitivity issue. d67d5db Removed verts from streaklines - lines are enough. 9c95cee Removed unnecessary recursion in pipeline streaming. dca4464 Filter was modifying self in request. Fixed. e5f7953 Fixed minor typo in documentation. ccb8acf Added test for vtkTableBasedClipDataSet. ad3b1a2 Added caching to temporal interpolator. 6066b78 Fixed minor bug in the ensight gold reader. 37dc617 Added EnSight tests to increase coverage. 6f12002 Added initial ghost points support to vtkDataSetSurfaceFilter. f82238e PERF: Parallel streamline was slow. Fixed. 1a0b4e9 Refactored how pieces and extents are handled. 32cf800 Update the XML readers and writers to work with pipeline changes. 24a324e Cleaned up and fixed transmit filters for structured data. dbbef3f Fixed bug in send structured data. 10c6913 Fixed legacy parallel reader and writer. bc4dbe8 BUG: Was using array of wrong size. a4c8e85 Fixed compiler warnings. b33d318 Changed synchronized templates class for new pipeline behavior. e27ae6a Removed unused keys. 747b780 Updated filters and sources to work with new pipeline logic. ac6f185 Moved key. 19e6914 Cleaned up extent translators. ece82ee Removed unnecessary reference to extent translator 4003183 ExtractSelection was not managing pieces corretly. Fixed. 16e20f2 Filters should silently handle empty input 2354c78 Fixed multiple issues with resample/probe filters. a4944a4 Fixed contour filters 3517e2a Fixed issues in the group filter. 05ad827 Fixed crash in the empty input test. 06685ac Fixed vtkXdmfReader for parallel structured data. beb1efe Parallel Exodus writer was not asking for pieces. Fixed. be27951 Added new meta-data and request capability to the pipeline. 3885112 PERF: Removed unnecessary function call. e253292 Added an ensemble source. 4787c7a Added documentation and testing to vtkPythonAlgorithm. 0f703d2 Fixed no newline at end of file warnings. 8c0040f Executive was setting update extent initialized falsely. a4ee641 PERF: Removed unnecessary garbage collection. b0a9b57 Fixed indentation and style to match VTK's. 6168892 BUG: Filter was overwriting input scalars. Fixed. 79a80ae Added modules that create a numpy type interface. 8b73e3b Certain MPI types were not being recognized by mpi4py. 3c80a0a Improved TestNumpyInterface to cover various append implementations. 14a9c30 Added sum and mean per block to Python algorithms. 191f3c2 Added support for CompositeDataSet.Points. 710f73f Fixed innaccurate comments. 07b7459 Added a SeedIds array to the output of stream tracer. d8bdbb6 Added support for specifying split mode. f5af80d Added VTKPythonAlgorithmBase - base class for Python algorithms. 869c2d1 Fixed vtkImageGradient in parallel. eb42bb7 Added Python support for making new information keys. 4bbd890 Removed mrmpi ThirdParty, which was not used. fe3ff3b Fixed quadratic quad and biquadratic quad derivatives. d9e442f Added a new example demonstrating developing SMP algorithms. c3b9d7b Added another SMP example. 24211a1 Fixed bug in vtkExecutive::CopyDefaultInformation. 86bd7ac Fixed bug in vtkMaskPoints that caused corrupt output. 7401095 Improved unstructured grid support in dataset_adapter. Bill Hoffman (2): 14cfa48 Fix build with mingw 4.8.2 and qt 5.3.2, bug #14735 ecbf79e Detect win32 or pthread model in a mingw gcc build. Bill Lorensen (39): 2808d60 COMP: Test driver array bounds error 0f41f22 BUG0013829: vtkAssembly::GetBounds adds bounds which are uninitialized fcaf269 BUG0014331: Filter skips VTK_CUBIC_LINE 4afabe1 COMP: Restore TestTessellator test b4e0146 ENH: Added tests that were removed during modularization ce5bab0 COMP: Refactored TestDataObjectIO 9bce5da COMP: test require NO_VALID modifier 5881e35 ENH: Add removed tests 4831f68 COMP: Improve coverage of vtkMeshQuality 84087f5 COMP: Missing NO_VALID 0e9cfd9 ENH: Improve code coverage script 2df673a BUG: Flawed logic for NO_OUTPUT d6dc375 COMP: Python unittest requies NO_OUTPUT 43fa8b7 COMP: Performance warning: int to bool af25106 COMP: Remove QtInitialization from otherPrint test 9200beb ENH: Remove ThirdParty code from coverage results 4241580 COMP: Remove bogus line info from generated files e2b5f16 ENH: Unit test for ParametricSpline f3311d5 ENH: Coverage for MultiThreshold. b347042 BUG: CreateDefaultLookupTable crashes if Input is NULL. 6cb7f08 ENH: Add some more coverage for MultiThreshold 94a6311 ENH: Improve code coverage for UnicodeStringArray 5988b55 ENH: Unit test for vtkMath 7748359 COMP: Adjust tolerances 4f30bff COMP: Guard against infinite loop in vtkClearOpenGLErrors eb1a585 ENH: Provide PlaybackFile for recorded interaction events 28abc76 BUG14463 vtkMy does not work for vtk6 55a7f9d BUG: 0013057: bad xml input to XML Reader's causes exception 901e7e6 BUG14527: Subdivision fails for non-manifold data a952720 BUG: ImageAccumulate overflows for large images 55902e2 BUG: Some types of files are not closed after processing ab29d10 COMP: A more robust way to check file descriptor leaks 84f9a17 ENH: Add support to read tiled tiff images 0bee648 COMP: Add execption for vtkJSONWriter bac2c9c ENH: Restore missing Infovis classes 5f3f837 ENH: Unit Test FunctionParser baa76c2 COJMP: More robust fuzzy results checking 8597cc5 BUG: Memory leaks detectd by valgrind 5f25d2f COMP: Prefix HDF5 cmake messages with HDF5:. Brad King (37): 7df9a25 COMP: Drop invalid custom commands from HDF5 d19b4db COMP: Drop missing dependencies of target 'vtkpython_pyc' ee1c753 vtkhdf5: Remove extra calls to cmake_minimum_required 08df7a8 Accelerators/Dax: Remove extra call to cmake_minimum_required 5983605 Refactor top-level CMake Policy settings as loop 3a04542 Examples: Set required CMake version and policies before project() 2ad9f47 Set CMake Policies CMP0025 and CMP0042 as necessary 73431db Rendering/Volume: Convert new baseline to ExternalData content link e2d3123 Wrapping/Tcl: Fix CMake Policy CMP0050 warnings d8a7442 IO/XML: Remove unnecessary include 4327fce IO/XML: Add missing include f2a2eea IO/XML: Fix HeaderTest for this module 7feab87 vtkOStreamWrapper: Support std::string ec258e2 Revert "vtkOStreamWrapper: Support std::string" 54003c6 vtkOStreamWrapper: Support std::string 25b191b Revert "vtkOStreamWrapper: Support std::string" 0ad98de vtkOStreamWrapper: Support std::string 1de7c32 Allow custom TestTM3DLightComponents timeout ba0984b Allow custom TestProp3DFollower timeout 82a116b Honor VTK_INSTALL_NO_DEVELOPMENT for archive libraries c05001d Use vtkMPI.cmake helper for all module MPI tests cd0b6e6 Set MACOSX_RPATH property default consistently across CMake versions 94f1281 ExternalData: Add backtrace to missing file warning 23fbbeb Export the locations of Qt5 packages on which modules depend ff7c659 Allow configuration of external module dependency locations 5782e17 Views/Infovis: Add another baseline for TestConeLayoutStrategy 622d753 Allow custom Interaction/Widgets test timeouts b55c8eb Fix ExternalData pre-commit hook on msysGit fec99e5 Add option to exclude VTKData target from default build 644096b mpi4py: Suppress warnings in third-party code 63b5bc7 vtkFFMPEGWriter: Fix build with libavcodec55 2926834 Exclude classes requiring a QApplication from VTK smoke tests 094a09a module: fix export macros with kits 4998c13 vtkglew: Install glew header files d2a8a93 IO/ADIOS: Exclude module from VTK_BUILD_ALL_MODULES 1f35801 ENH: Use if(DEFINED) to simplify conditions c2db066 COMP: Include "vtk_glew.h" instead of "GL/glew.h" Burlen Loring (3): 070b6ea surface LIC - stl and NULL 90c9a29 vtkweb: buffering issue 47bd9e8 vtkweb: connect to existing session issue Casey Goodlett (4): fa84797 Ignore files in project.xcworkspace fb034ce Fix names of texture and normal arrays in the OBJ reader f555a21 Fix libpng "Not recognizing known sRGB profile that has been edited" 3c9e67a Skip install of .pdb files for hdf5 on windows Chris Harris (27): 4b03a9b Add failure filter to session.auth(...) deferred fa652b6 Add error function to vtk:mouseInteraction RPC 584838a vtkWeb: Add newline to end of each proxy map entry 9d81e15 vtkWeb: Teach launcher.py to wait for ready_line 1d12532 vtkWeb: Add appropriate error codes for launch requests 5968172 vtkWeb: Don't reset viewer to null on updateViewer(...) 7b0dae9 vtkWeb: Propagate mouse events to VGL 175d3dd vtkWeb: Fix calls to old VGL API 10e70c5 vtkWeb: Rename ogs.vgl => vgl dfb8481 Rename md5 => sceneMD5 to avoid confusion 333a654 Update canvas size before creating viewer 49ae1cb Prevent mouse event handlers be bound multiple times b0953ee Update VGL to master 04de702 Update version of VGL 1241e99 Prevent scene and clipping range from being reset 8fd3926 Update VGL to lastest version 3bf2493 vtkWeb: Refactor fetchObject(..) to use cached objects 61eb46e Add code to clean of VGL actor cache f34cba0 Add missing initialization of member c976fb4 Fix typo introduce by 06aaa805 session => m_session fa04ced Update to modern CMake style deae524 Allow location of OSMesa install to be specified d8933d5 vtkWeb: parseObject now returns an array of actors 2699fc9 Export same scalar bar title as is displayed by actor 8b4e567 Update VGL version 3ce7a5e vtkWeb: Use unbuffered file read/write for stdout a53a88b vtkWeb: Cleanup python processes that timeout on startup Christoph Kolb (1): 87b5c8c Add a method to enable multisampling in the QVTKWidget2 Chuck Atkins (22): 4eb181f Initial ADIOS readers and writers e27d172 Remove leftover debug messages 23942b2 Expose WriteAllTimeSteps as a setable parameter for ADIOS c2ae0a6 Properly handle WriteAllTimeSteps = false for vtkADIOSWriter ba13e88 vtkIOADIOS: Fix incorrect multi-block multi-step scalar values. 2b27d50 vtkIOADIOS: Ensure time values always get written, even if just the step. 1a8ba95 vtkIOADIOS: Collection of small fixes 2115545 jsoncpp: Update to use the seperate-file version 250f311 vtkIOGeometry: Correct typos in older jsoncpp API calls 6b4f8cb jsoncpp: Fix vs7 build error from missing C99 functions 71ef2ea COMP: Suppress warnings on PGI with commonly used patterns 2ef1a2c COMP: Remove unreachable break; statements following returns c9fefb7 BUG: Replace a few previously removed exit conditions b9c8245 BUG 14681: Allow for early exit when no data can be decoded. 2433c36 BUG 14681: Close leftover file handles on exit 03f893b XMLReader: Prevent streams from being closed when they don't exist. 874279a ADIOS: Resize the write buffer to the known required size. 3c8af89 ADIOS: Update FindADIOS to match upstream 149064b ADIOS: Add an initial polydata write-readback test a5cee75 HDF5: Fix build errors for PGI on Linux ad47d6a ADIOS: Properly handle variable sized data. 63c2269 ADIOS: Fix memory leaks by adding deletes Cory Quammen (34): f61175e BUG: Fix build failure in RenderingParallelLIC on Intel compiler 5040362b Added "sticky" axes mode to vtkCubeAxesActor 36d9e0e Fixed linkage problem in Windows d4d486a Improved comment handling 69a06e4 KW00001404: Major overhaul of vtkAppendFilter 1ae1b52 Fixed memory leak and improper erasing of std::set elements ab0254a Fixed error in appending cell data e893f1d Removed unused types and member variables, fixed formatting 8160c63 Rename local functions and embed in anonymous namespace b807a6d Change clamping range for texture coordinates 95686b6 Turn on edge clamping 56b9236 Fixed errors exposed by changes to clamping of texture coordinates a4af85b Replaced buggy and redundant implementation of GetRGBPoints() 53c340d Updated baseline for when test uses alpha blending c723181 Improved comments and made some formatting improvements 6259f17 Removed code mistakenly introduced during a merge b2452da Updated test baseline 15504ad Removed unneeded function argument 55c7dad Enabled easier specification of custom test name aba9515 Re-enabled some tests overlooked by vtk_add_test_* 75d2d4b Fixed some file extensions in documentation 238163f 6657: Add out-of-range colors to color maps 4a1259c CMake was complained about unknown arguments to find_package 8f3d921 BUG: Fixed how the header size is computed 37259c0 BUG 10708: Fix vtkPolyDataMapper2D color mapping 371f18a Avoid insertion of extra newlines when adding comments b3b0536 BUG: Added missing build of lookup table a07731a Handle coloring by field data 9449836 Enable coloring by indexed lookup for vtkStringArrays dafe5a0 Added previous signature back for MapScalars() method 3a27c8e Fixed memory errors in newly added tests 8a30862 Fixed test to work on older graphics hardware 1ce9d47 Added alternative baseline image for TestActor2D 93642e6 Fixed memory leak when RGBPoints are read Dan Lipsa (38): b604c23 Report an error when writing a file with changing topology. 9ac19b7 Update documentation. 1d7c454 Remove debugging printouts. 410e53c Name enum LEFT, BOTTOM, ... Location. 5d41775 Add component-wise set functions for Border and Gutter (vtkChartMatrix) de01f9e Set Bold and Italic axis label properties for ScatterPlotMatrix. 063b174 vtkMultiProcessStream: Add insert and extract operators for bool 94f3790 Fix Windows compilation warning. afed075 Forces the compiler to convert a char* to a string rather than a bool. 1519303 FIX: Get rid of dependent properties. bf8a001 FIX: Set the hue range for the default lookup table. 27ddad4 FIX: NULL data in RequestInformation causes a segfault. f3a9d33 Fix compilation after upgrade to hdf5-1.8.13 14e8f63 Build static hdf5 and build on VS 2003 7.1 973e57a Fix mingw release build. 132fec1 snprintf from HDF5 conflicts with the one from GMVReader db8d3e2 Make hdf5 properties advanced. 00de9a9 Add VTK_COLOR_MODE_DIRECT_SCALARS. See vtkScalarsToColors::MapScalars. 6dee6fd Fix KdTree::GenerateRepresentation and add test. 2d61dea Add a test for VTK_COLOR_MODE_DIRECT_SCALARS 1d32010 Fix hdf5 library names. 09f0204 Remove lib prefix from windows libraries and mangle additional symbols. 55b75e4 Fix hdf5 library names for VTK (and ParaView). 8c7db60 FIX: We don't select 2D annotations. 9c7135b Add data_index to Exodus driver d3ba9c7 FIX: remove warning declaration of ?? shadows a previous local 4bcf0dc Prefix BUILD_STATIC_EXECS with HDF5 and make it advanced. 7c7c3ca Add missing numpy functions previously available in ParaView 4.1. 084b0bb Rename data_index to mode_shape in Exodus reader. 699deb9 BUG: Writing an Exodus file in parallel segfaults. b45e6b6 Stop all processes if one process stops. 193be6a Reshape VTKArrays so that they can be combined through operators. ed860dc BUG: Account for gradient G + mean(G,0) b2bdadb Fix conflicts in cmake files from hd5 upgrade. cfc422e Accumulate strings printed to console by Python and send them in one piece. 57c9fa4 Fix style problems. 11da86a BUG: Buffer output only for RunSimpleString. 7d2de7b BUG: Fix mispelled excluded class and print out all exclusions. Dave DeMarle (56): ab78408 Increment version to VTK 6.2.0 274c07b Add a test for the VPIC reader a797d0d document arguments to test macros 5736031 move dashboard management scripts into better place 039d1d9 fix link errors that happened when I turned on InfovisParallel 17804f3 deprecate this module 1d754ec fix a compilation warning 252798f make rubber band look correct on scenes with textures bd3c09e optimize geojson writer 0e46e31 more optimization of geojson writer 0adb5f1 fix variety of dashboard problems 1519103 Put libxdmf into a namespace so that libxdmf3 can coincide with it. 12616e0 Adapt libxdmf to build within VTK. 5760a37 add cmakescript infrastructure to make libxdmf a VTK module 471a830 Add a reader and writer for the new xdmf library. 55b3940 Fixes for xdmf3 regression test data. c4b66ca Fix issues the dashboards turned up. 5a23147 Fix more issues the dashboards turned up. 7564b9b Really fix on of the issues the dashboards turned up a5c1b7b Fix a regression in the xdmf bump 271bfcd STYLE: improve comments and organize internal classes 8c9c5cf fix a case of discarded arrays 17c88a3 Remove stray debugf. 31ba4ac bring back subsets 34ae408 put array reuse in d7fb5d3 Fix dashboard warnings and test failure. 3bb7f74 disable a balky test until we can fix it 1e6c66b Add file series reading and top level spatial partitioning f085338 fill in time varying graphs d8bf033 STYLE: pull helpers out and format all for vtkstyle 56e9a94 move strict partition multipiece constuction out to reader level c5bace8 disable oggtheora on cray too 26694e1 Fix problems that the dashboards turned up. 5f95be4 remove MetaIO to replace with updated content c71ad1b exclude matlab from the "all" modules set f8c5c67 Add render mode in which values are drawn as recoverable 24bit colors. c46f50c fix a compilation warning 9446581 Fix test failure 7a49dbf Fix test failure fbb9829 Revert "Fix test failure" bee4434 Revert "Fix test failure" 115f9bc now 000 is reserved as the no value (background) color 9ed4765 fix dashboards that lack multisampling 391ddff make area picker respect prop transformations 9944a86 prevent possibly uninitialized ivar use 87ceeea java install shouldn't delete /usr/bin ! 71c55e8 shrink size of xdmf3 written files 7810863 fix a bug in value painting for cell arrays 35df848 fix a bug in triangle frustum intersection 7bcf231 COMP: fix a valgrind leak in new test bf4b407 update cdash scrapers to use https 611ab74 COMP: fix unused warning fc1a008 edge clipping fallback path needs correct edges 7efc254 COMP: fix macro redefinition comp warning c8313b8 per bug 14586 fix external vtkLocal 59f9b0f allow examples to be built without tests David C. Lonie (67): e9f66ba Tie vtkUnstructuredGridBase into the dataset type system. 6f3b654 Update baseline 90d7592 Handle empty array initialization in numpy_support. a43fb6a Don't reset traversal location in each iteration of box clip filter. 42b0733 Process facestream in vtkExtractUnstructuredGridPiece::RequestData. c8bec1f Handle polyhedra in vtkUnstructuredGridWriter. 16368b4 Disable FP frame buffer when GL_ARG_texture_float is not present. f521f41 Return early if ProjectedTetrahedra volume rendering is unsupported. f61c11b Add new baseline for rendering without floating point buffers. 0e07b09 Add new baseline for dashlin1. c49b9c1 Pass std::strings through the OStreamWrapper. c78a1e6 Revert "Pass std::strings through the OStreamWrapper." e52eff0 Return early in TransformPoints if input is NULL. 67ee41e Update system font test baseline. 81a76c7 Check if the selection array exists before dereferencing it. 7bb258f Ignore blanked cells in vtkCellDataToPointData. ba2e348 Error if attribute arrays are incorrectly sized in vtkGlyph2D. 25a270d Remove unused variable. 5d32344 Don't attempt to render NULL strings. 973e7b2 Add DebugTextures to FreeTypeTools to show texture background. d5de865 Use unrotated faces to determine text height metrics. bc5f6f3 Move templated methods to private visiblity. 1e93449 Style cleanup in vtkTextActor3D. ae47eef Remove pointer tests for ImageActor in vtkTextActor3D. 0edc256 Strip newlines from GL2PS comments. 6c7cdbf Always upload test image if a regression test fails. 125149a Improve aligned and rotated text. e04dcf8 Update tests and baselines. d2dca71 Account for frame width in ScalarBarActor title position. 6401873 Use Round vs Floor(+.5). 20d5ae1 Update baselines due to text rendering changes. eff2e37 Fix shadowed variable warning. 951527c Cache number of points used in asserts. 892b788 Simplify and inline much of the logic in vtkStructuredData. 600f681 Update vtkExtractStructuredGridHelper to remove data descriptions args. b4b79f0 Batch copy point data. 3d68c23 Add API to copy ranges of tuples efficiently. 713d44c Copy ranges of points during VOI extraction, if possible. 49406af Move InsertTuples implementation to helper class. 73de835 Fix "uninitialized usage" warnings. 275bb6c Make a clear distinction between extent indices and values. 7394359 Add helper functions for computing partitioned structured data. e335ba4 Fix bugs in vtkStructuredImplicitConnectivity. fd4b3e5 Fix vtkPExtractRectilinearGrid extent issues. 79ada2a Fix vtkPExtractVOI extent issues. 22f5428 Fix vtkPExtractStructuredGrid extent issues. d0f557b Fix a buffer overrun in vtkExtractStructuredGridHelper. 105578d Remove redeclared variable. 0f5053c Fix bool -> int conversion. 2e04a0f Clamp global VOI to the output whole extent in subset filters. 81ec43c More warning cleanup from nightly dashboards. 4f3655c Rearrange inline methods in vtkStructuredData.h. 978e894 Move vtkTextActor and vtkTextActor3D into Rendering/Core. be714c1 Add unary minus (negation) to vtkVectorOperators.h. dbf5b5f Fix c/v qualifier on vtkVector::Normalized and Cross methods. f23c7b2 Manually mark text buffer images as modified. 2129cf5 Add a vtkLabeledContourMapper for producing inline labels on isolines. a678f18 Added ability to turn label visibility ON/OFF 1347e42 Add vtkTextPropertyCollection. 3272193 Allow multiple text properties to be used in vtkLabeledContourMapper. 034dc39 Reenable GL2PS MathText tests. 7e7306e Add background color/opacity settings to vtkTextProperty. 3f8164a Use the new background color rendering for the labeled contour test. add0f25 Fix an error in setting an array length. 00bb019 Fix conic point identification in the path renderer. 3b07940 Fix warning in vtkLabeledContourMapper.cxx 7b2091a Allow the initial GL2PS buffer size to be set. David Cole (14): 80498e4 Add a vtkMath method to compute the angle between two vectors aeb9689 Tests: Re-activate the old TestResliceCursorWidget tests 4943d65 Tests: Add test for the vtkCornerAnnotation class 67cf482 - Follow on commit to use the right style #include ("", not <>) 65c686a BUG: Add missing header files to enable try_run tests to run without crashing c3e5209 Testing: Call SetMultiSamples(0) from tests 8a86671 Rendering: Use AdjustWindowRect to ensure pixel perfect client size 432f06b Rendering: Retrieve the full screen size in GetScreenSize 4386c03 Rendering: Use AdjustWindowRect to ensure pixel perfect client size 37c4a68 vtkTesting: Refactor RegressionTest, eliminating hard-coded cout e136e01 vtkTesting: If test fails with back buffer, try front buffer too a9e025f VRMLImporter: Fix memory leaks and crashes ba5bb9f VRMLImporter: Fix crash. Avoid dereferencing NULL pointer (#1624) 8450ddd vtkVRMLImporter: if non-NULL, delete CurrentTransform in destructor David Gobbi (93): a162be1 14196: Allow unicode path in vtkLoadPythonTkWidgets.py. c8c78cd In wrappers, guard against #including dirs. 8eb00d2 Fix cell picker for images with negative spacing. f0825f4 Fix uninitialized array warnings. d80ccfb Fix unreachable code warning in otherCellTypes.cxx. cbd4884 Fix a crash when deleting vtk-python objects. 170d664 Fix bad SetColor/GetColor interaction in vtkProperty. 0fe573e Fix the extent for tiled tiff files. 7ff8bfd Two fixes for certain lsm (zeiss) tiff images. e7aa61d Add reader/writer for NIFTIv1 and NIFTIv2 files. 048419f Add SetSlabModeToSum() to vtkImageResliceMapper. 21f10c8 Clean up vtkMedicalImageProperties PrintSelf. 1f77744 NIFTI makes IOImage module depend on vtkzlib. 050c2df Fix warning about trailing comma in enum list. ddf898a Bad null pointer check in vtkBSplineTransform. 006d4d4 Fix segfault if vtkImageWeightedSum's inputs don't match. be0b2e5 Rewrite the comments for vtkDataArray::GetRange. 04fbc0e Add generic PyObject support to vtkPythonOverload. f1a720c Provide a method to set the sample spacing for slab modes. 0541472 Add wrap hints for vtkPoints2D and vtkRenderWindow. b8d9b19 Reactivate the RenderingImage tests. ab5b27f Replace python mutable with its value in GetValue(). 9a2c201 Clean up cocoa input event handling. e27035d Interpret OS X Command key as Ctrl instead of Alt. 59850c7 Initialize interactor in Start() if not done yet. 2426564 Fix illegal extent request in ImageThresholdConnectivity. c68bd98 14445: Fix vtkImageStencilData IsInside upper bound. 52a5b97 14552: Check python interp and lib versions. e12eb1f 12098: Mangle void_p like other swig pointers. 723ec48 Exit the Cocoa event loop when the window closes. 0d30647 Readability improvements to vtkCocoaGLView event code. cc5740c 14999: Python Tk widgets fail to load on Tcl 8.6. abad5e11 Remove InstallMessageProc flag from OS X interactors. 5dbbc8e Reduce code duplication for Start() method. 8d2ae20 Ensure python header version matches lib version. 698f17d Remove the deprecated PYTHON_INCLUDE_PATH variable. 55e5b2e Fix Initialize() and Start() interactor documentation. 530bc43 Revert "Remove the deprecated PYTHON_INCLUDE_PATH variable." 18e5fa2 Remove obsolete PYTHON_INCLUDE_PATH from CMakeLists. a901d1e Do not cache deprecated PYTHON_INCLUDE_PATH. 5e2432f Make streaming optional for the 3D image mappers. 88ab5f7 14042: Numerical stability of vtkPolyDataToImageStencil. 00f6ec4 BlackmanHarris4 fourth coefficient was ignored. 904b415 Default parameter for Kaiser window is wrong. d080585 Fix copy-paste parameter name. 59e9a2b Add missing newline to end of file. 4a57067 Fix handling of tolerance in vertical direction. 257c8b1 Deprecate the obsolete InsertLine method signature. c8b25c8 Add test for LassoStencilSource orientations. 8ef9c88 Re-enable vtkPolyDataToImageStencil tolerance. 9d8e8a7 Python init config used COPYONLY instead of ONLY. cdc8d8a Fix unreachable-code-break warnings. 0a78976 Check whether volume property is null. 9791802 Before c99, variable decls go before other statements. 9771254 Before c99, variable decls go before other statements. 12130b2 Before c99, variable decls go before other statements. afeea15 Before c99, variable decls go before other statements. a73ab65 Refactor vtkWrapPython into smaller source files. f642f51 Wrap enum constant members for non-vtkObject types. ba693ad Add an enum type to the python wrappers. 57b4795 Fix two previously undetected wrapper bugs. b271e76 Wrap namespaces in python. 67a70a8 Allow use of all enum types as method parameters. a5948d9 Move VTK_BUILD_SHARED_LIBS check to generated code. d5cb238 Wrap constants more efficiently. 3e10054 Avoid creating duplicate wrapped namespaces. e13d9ae Only wrap namespaces that have useful contents. f747542 Update the readme file for new wrapping capabilities. a9314ac Fix compile warnings for vtkParse.tab.c. d1f7875 Use a wider integer for the parser stack. 153473f Fix warnings due to anonymous namespace. 0564cbb Revert "Use a wider integer for the parser stack." 1bb3de0 Allow enum types to be used as method parameters. 456a8ff Fix "conversion from size_t to int" warning. 9bdc484 Remove NULL check on reference. e0292d0 Fix potential vtkUnicodeStringArray instability. 323f6a3 Fix warnings due to anonymous namespace. ac95ec8 Fix type-punned pointer dereference warning. 18f678a Fix warning about comma at end of enum list. 80797eb Fix incorrect index types for loops. 2b07326 NumberOfArrays is int, so use int as counter type. f29e564 Fix warning for possible uninitialized array access. ad43e25 Fix a bug caused by recent tolerance fixes. 8749c2f Fix error when kernel size is greater than slab thickness. 8c45343 Remove some unecessary casts. af54136 Revert "Remove some unecessary casts." ef02d78 Allow absence of i64 suffix when __int64 exists. 87868ac Increase tolerance for UnitTestParametricSpline. 349692b Increase numerical tolerance in UnitTestFunctionParser. 2383e1e A "Set" method in the constructor caused a UMC. 877e062 Revert last commit to UnitTestFunctionParser.cxx. 248da99 Make wrappers ignore scoped class definitions. a051d50 Fix arg conversion of const ref arg via constructor. David Stoup (1): 5872add Add multi-layer support to the vgl interface. David Thompson (8): e4061e5 Bug 14713: Read LS-Dyna point coordinates properly. d5c3987 Add a regression test for bug 14713. 0693db0 Small fixes to docs, comments, and formatting. 52eb52d Add support for reading polyhedra. c7aa834 Test reading a polyhedral Exodus dataset. e142138 Add test data with multiple polyhedra. 868c552 Remove MD5 test-data MD5 file. 905de37 Fix SetAllArrayStatus on the ExodusII reader. D?enan Zuki? (1): 757d996 VS2013 compile fix Eli Kahn (4): 4fc0088 Adding mousewheel support to Java GUI components. 9d8b4ee Fix java code formatting. 14902f4 Add java file to generated jar file. aef8403 In java code, handle situation when wheel rotation value is zero. Georg Hammerl (1): 9cc56d4 Add caching for time steps in EnSightGoldReader binary reader. George Zagaris (18): 8beb89a Disable I/O in TestStructuredAMRGridConnectivity 271954a ENH: DuplicateNodes property to RCB partitioners f41f521 BUGFIX: Fix integer overflow in vtkStructuredData e4c0566 ENH: FieldData deserialization to a subextent 071f143 ENH: Add blanking to vtkXMLUniformGridAMRReader e42bbf8 ENH: Implicit structured data connectivity 843bd4d COMP: Update vtkFiltersParallelMPI tests 9bfa169 ENH: Rename nodes to points in vtkStructuredData 33920cf BUGFIX: Add guards for NULL ivars in PrintSelf df25648 BUGFIX: Fix issue with unigrid enzo datasets 8c347ee COMP: Correct ParallelMPI module test dependencies 0165b0a COMP: Remove HyperTreeGridGeometry::UpdateExtent() 296ace0 ENH: Update extract structured data filters 8a4e1cf ENH: Use vtkImageData in implicit connectivity ef1611f ENH: RectilinearGrid implicit connectivity support 0769d8f ENH: MPI structured data extraction filters 37afe25 COMP: Fix a few compiler warnings 1a80cf6 ENH: Added broadcast implementation for RMI triggers HDF Group (1): 8d8063f hdf5-1.8.13-r25462-reduced Hans Johnson (1): ddd9497 DOC: Remove documentation that is not relevant to VTK6 Jacob Becker (1): 00bb43b Fix bad check for incomplete polygons, fix div-by-zero. Jameson Merkow (1): eec6db3 Add files, and made modifications for MatlabMex to wotk in vtk 6 Jean-Christophe Fillion-Robin (9): 50d601b vtkPythonCommand - Add support for additional call data types 176861d vtkPythonCommand - Fix indent and variable names 253b2a9 Fix regression ensuring macro VTK_MAKE_INSTANTIATOR3 configure files ffbac85 Fix component names in "vtkhdf5-hl" install rules. Fixes #15282 a0e4387 Fix MacOSX build error related to OpenGL2/vtkOpenGL.h. See #15285 e3545f6 vtkRenderer: Fix null pointer crash in ViewToWorld() with no active camera 7aa65b6 vtkhdf5: Fix build error when building on system with glic >= 2.19 95b3d50 per bug 14826 make find_package vtk more lenient 8455317 vtkCornerAnnotation: Add convenience TextPosition enum Jeffrey Baumes (1): a1958d2 Fixing array bounds issue Joachim Pouderoux (40): 5a31f33 Introduce Robust PCA. 999ed2a Introduce box plot and the corresponding chart. aac4386 Introduce Compute Quartiles filter to generate box plots tables. 39efc95 Enhance bag plot API to allow specify line and points properties. e0911e4 Fix bag plot legends. 23d97ae Fix black box plots issue. 3526113 Fix double to unsigned char cast error on clang compiler. 5d42650 Fix bag plot and functional bag plots tests. cee00a0 Fix and enhance the box plot and chart df6c71a Fix and enhance bag plots. ba7959d Fix bug in picking of invisible props in an assembly. d0c862b Clean an enhance hypertree grids. a2d8d41 Fix potential compiler error with ternary operator. ee53b25 Replace a verbose cout by a vtkDebugMacro() d24747f Fix clang errors on array initialization 98fcc71 Fix and clean vtkWin32OpenGLRenderWindow class. d64a835 Fix functional bag plot. cb93b88 Clean and uniformize vtkPoints & vtkPoints2D. 6035b81 Fix crash on normal computation when polygon is empty. ec1d00d Fix code formating & style to VTK coding-style rules. 823571b Add algorithm header for std::lower_bound function call. 85e985e Fix non Delaunay internal edges added by RecoverEdge(). 36622ab Add missing NoBlockSend(vtkIdType) method. b6e22e1 Remove compilation warnings on some platforms. 8efe5ef Add support for EDGEFLAG attributes in legacy reader & writer. 7b86976 Add a new test for EDGEFLAGS point attributes. 743c380 Fix vtkHyperOctree copy functions. 18de520 Disable edgeflag test if Mesa driver is detected. 565c1b8 Fix and clean VRML importer code. c80a4db Make vtkContextScene ButtonPress/ReleaseEvent invoke a button event. 6a6f0f1 Fix a memory leak that occures when Uniform Variables are updated c909189 Fix Xdmf3 CMake file to export symbols in DLL. 1dcc3d9 Add functions to get data bounds and number of plotted bars. 2cc28ea Fix Xdmf2 writer: array type was not respected. Also save block name. acb4095 Enhance Xdmf3 writer to save block names. 451a1fb Fix a warning (variable shadows a parameter) 488e2f8 Optimize data array range computation functions. d89695c Clean and fix STL reader. ce95340 Small fixes to allow empty cells. db86c67be Fix EnSight Reader BUG 0015268 Johan Andruejol (1): f8eee62 Refactor parts of vtkLookupTable John Stark (2): 070b804 Add a test for vtkImageImport / vtkImageExport 0f6d745 Fix pipeline update issues in vtkImageExport John Tourtellott (7): e20239e Fix memory leak in vtkGDALRasterReader::RequestData() ed4759c Set geo-origin and -spacing in RequestInformation() call bb592fb Add vtkGDAL class & MAP_PROJECTION key for pipeline data and field data 7a3af77 Change missing geotransform from error to warning. 527ad90 Fix ctest errors 9b41015 Turn off wrapping for vtkGDAL.h da25875 Declare vtkGDAL constructor & destructor private, since class is static Jorge Perez (1): 6653cd0 Upgrading the Tcl examples wrt. VTK 6.x Julien Finet (11): c62a84d Prevent error message when deep copying vtkGridTransform 1d7b0a7 Change GetInputConnection error message into a debug warning message f8fe12a Fix vtkAbstractPolygonalHandleRepresentation3D visibility 7a2f6bf Fix crash in vtkFixedSliceHandleRepresentation3D 520548c Add vtkPlot::SelectionPen and vtkPlot::SelectionBrush 9a3f0f1 vtkPlotPoints selections must be sorted 089067d Add vtkChart::SELECTION_COLUMNS cc1fb1d Add vtkAbstractContextItem::StackAbove and StackUnder 695d3a6 Reorder the columns of vtkExtractFunctionBagPlot e539982 Apply selection pen opacity when drawing selected points 49683cc Fix crash when vtkPlotPoints has no Axis Julien Jomier (10): a2dea46 ENH: Fixes for ActiViz.Net e761536 BUG: Wrong transformation used to restore original parameters 98e7223 ENH: Added back support for TDx fa34ff6 COMP: GLEW_STATIC should be defined with MSVC2010 when building static e34f6f6 COMP: Missing type for vtkWindow GetScreenSize() b11d523 COMP: Q_OS_X11 doesn't exist with Qt4 replacing it back to Q_WS_X11 0b64c2e ENH: Added support for ClampToBorder (as it was in OpenGL) a42b786 ENH: Added function to initialize volume 507d690 BUG: AreaPicker doesn't consider position/orientation of assembly 9a968bc BUG: RenderedAreaPicker was not using the PickFromList KWSys Robot (7): 2eede99 KWSys 2014-03-12 (dd873734) 74e3192 KWSys 2014-08-11 (32023afd) 50e1f89 KWSys 2014-09-08 (80e852f6) 6bd7ebf KWSys 2014-09-19 (6aa1f800) 080409c KWSys 2014-09-25 (29ffaf43) d9b96c8 KWSys 2014-10-31 (88c8cc7f) 14f6f34 KWSys 2014-11-12 (5843f590) Ken Martin (310): 3c9a294 some rough changes to the VBO polydata mapper ece2ba8 some more cleanup fc6ca43 added light override b7e4976 compute cam matrix, add posiitonal light in progress 3c2af93 updates to support positional lights ab600cb change how object factory is done 479cc07 some fixes to normals etc 0400abf added ambient color in 52dc35a some module changes override actor change bunny color f4f93e7 changes in normal calcs f32f0de moved property over and started gutting it 1467ef3 fix normals on test 8111a7e minor changes e8e2ce2 some bug fixes and start on mapper2D a3efc60 allow testing using old mapper 6cc913c bug fix 9fe042e added cxx for Helper cf14de5 duh c1ba079 many updates to 2d mapper ab2a680 bug fix dd123f5 lots of rough changes 4165283 moved renderer over, moved init code 41f9ac4 in progress 16bbf3f in progress cell scalars fc0908f some cleanup and fixes cd4fa57 lots of changes in progress c0a1676 more fixes d9cc8a7 fix array bounds issue and memory leak 46e250d fix performance issue 2174bba add fast path for float points no col no norm and fix bug 057c4a6 started on texture mapping fe4eaee first cut a tmap support e1009d3 add textured backgrounds and fix issue with gradients 4a803b6 bug fixes 16cf6e9 clean up a bit a5e8a67 change opacity clean some texture stuff f2e6135 minor fixes 01327fb fix crash on test 6658a46 fix crash on test 7e65da3 add fragment shader lighting of lines 1e09fb1 support textured luts some cleanup 9a4d4ea some support for resolving coincident polys f53e785 ambient color fix df8d2df some minor fixes c768bc1 start working on image slice mapper 656a039 add baseine images 1f36e41 updated baseline images 0fe4c06 updated baseline image c605f6c minor backwards compatability change 7e90ebf basic ImageSliceMapper conversion 761e773 some more fixes 03ae0f7 moved render window over 800aff5 bug fix in old VTK af51a4f bunch of optimization more to come dd58c63 bad optimizations and missing classes' 952e427 doh forgot really key line 88d54a5 bug fix and minor cleanup 6583b32 fix a glyph bug and minor cleanup 86fd843 another bug fix e015655 better picking support some cleanup 337b7ec move interface closer to old Rendering API 4b3da32 convert ImageMapper 7b42481 some bug fixes 55429c5 another valid image, remove unused test 57de62b fix SetPixelData and fix picking issue 28e8166 add depth peeling f356ab1 make wider so we can see errors 48846df some win32 fixes a75a334 rename VBO mapper 8befe6c cleaned up the mapper a bit 3321751 minor cleanup 42ccec9 minor lighting fix for intel f97f9df handle wireframe tstrips 9af839a some bug fixes etc 4cec054 more fixes 35cd8ac more fixes 534e008 add support for edge visibility af9cc06 modify API to be a bit more future proof 817675c fix some picking issues aa13f3d some fixes for andriod 9b0f412 some fixes for andriod 7a78633 remove some old code e4a7943 some fixes for andriod 4450aed more andriod glew changes 0781dcf more andriod glew changes 3410034 many changes to support glew and android cb22be2 many changes to support glew and android e283572 many changes to support glew and android 403d1f5 first working in quotes android app 64b2dc9 first working in quotes android app 091d261 comment out more modukles by default 35d9c27 some warning fixes and minor cleanups 49afaa7 fix some more warnings 4b4c7cb fix some more warnings 672a797 make vtkOpenGLTexture use vtkTextureObject b1c9726 convert depth peeling to use more texture objects cae4a88 a tad more depth peeling cleanup 749dbe0 add android output window 521845f better debugging out for shader programs 1a131f3 clean up some shader code 5890fd2 new android interactor and cleanup 2c8e7a8 some shader cleanup 3d0c18c some android fixes in progress f65d8e4 improved release graphics resources b2f1073 improved release graphics resources cd2a628 minor change to be more compatible with some opengl hardware 410cbc5 fix android resize and lingering glew issue 412454e added multitouch framework and support on windows and android 6e873b5 fix java issue f0af35e in progress 5dfe80a in progress b1017ad more reasonable first cut at java android 7e75575 clean up some shader code and classes c0b5f66 removed unused includes e1ef59e fix some warnings 0713f8b dashboard fixes and debug leak af59eb1 some fixes for macs 411263d fix glyph memory leak and issue on intel b90516f cleanup reorg and fix some memory leaks b9f84d3 minor doc fix 67cd96b fix unit memory issue 618841c in progress ios a16c21e more iOS changes and depth peeling fix 38b02c3 some minor cleanups to wrapped classes fbc4da9 lighting fix for generated normals 0d11559 remove unimplemented methods 32f5c66 fix a number of dashbaord issues a900730 fix for lines that are exactly horizontal or vert plus cleanup 4b93362 fix for lines that are exactly horizontal or vert plus cleanup 51b0de4 add support for cell normals b53b163 add support for cell normals 793f23e fix a bad test 27f5b46 minor cleanup to a test c18c591 forgot to update the python version ebf6764 yank test for a feature we do not plan to support 64e5d7d fix an initialization issue with image reslice 882fd40 fix incorrect filename 5212468 added valid image for line lighting in opengl2 95054f7 removed broken test form opengl corrected for opengl2 3047038 more ios changes df57c93 some good cleanup 4912a3c ** working ** app and some cleanup 92b6907 fix for iphone test 48824d2 minor fix to cover vtkcompiletools f2b0d87 remove some extra files that we do not need 9d29733 make sure modules are really turned off 738b812 in progress need rebase 2bd9918 turn off more modules by default ca07346 in progress b7a0eef working clean prepping for opengl instancing 47ac0d5 some minor cleanups 42d799d really turn shared libs off 1246308 Fix compile warning in TextureObject 4f5f916 update toolchains to ios8 765646b Fix scalar colors using textures 25f401d Fix image mapper positions 4dc092c Fix the tcl and python cells test f5a7a1a Fix otherPrint and TestEmptyInput tests 08d7b9f fix for failing mac dashbaords a1dad76 Remove setting of ambient to 1.0 e7b395e Add support for backface properties ed1381e use GL_EXT_gpu_shader4 when picking 0140876 Rename TextureUnitManager to not have the OpenGL b286b89 Rename texture unit manager to not have OpenGL in it b1f0f0c Forgot to uncomment line on prior commit 4dea04e Add support for OpenGL32 instancing in GlyphMapper 4b18a9b Had to rebase as master had comflicts 4e9baa2 fix opengl es issues with glyphing code 23ceef0 Try adding support for ARB_instanced_arrays 27f77f8 Handle case with no lights on 4233190 Remove extra call to set the divisor b26e4d5 Forgot to add the image hash 8cb239b Replace some valid images lost with the big merge and a pick bug a9827d1 Fix error in glyphing and extend to mac cbe3f4b Fix fast path on apple 7129b4f Fix cleanup issue af77d96 Fix two glyph issues 3968464 trivial compiler warning fix 6a39514 Forgot a file dangit 4096ed8 Exclude freetype form iOS and andriod 901dde5 Remove EdgeFlags test from OpenGL2 6915708 Support edge flags. f702951 Fix for the 1 0 1 edge flag case. d239412 Minor cleanup 6921409 Another attempt. I think this one should work. 8f27431 Update the ios example to use GLKit View and put most logic in controller c09b0cf temporarily turn of mesa test until Joachim ets a chance to look at it 295ebc1 Add in support for clipping planes b6087b7 Add back in the edge test 42d91b1 Some suggested changes form Casey and remove user files c75f3f6 A first cut at a CompositePolyDataMapper2 f704378 Fix compiler warning and increase test threshold 69d845e Cache camera and actor matrices for performance cf1516a Remove the unused old code 4b6c88a Fix compiler error 221ba52 Fix issue with mesa and gl_FrontFacing 7ac000f make it so that this test works on the old OpenGL backend 7a7004c Fix a MTime check in the matrix cache b6d4561 Fix header test warning e134604 Minor fix for glyphing using CurrentInput 3eecb38 Fix float to integer comparison in shader code 3b363d2 Cleanup some indentation c7fa3a6 Convert Projected Tetrahedra class to OpenGL2 backend 66f9ae9 Fix up compiler warning of shadowed variables 6c598f1 Fixing ray cast image display helper 66bc416 Fix a few compiler warnings b5f0ab3 Cleanup a C style cast to keep it real plus a bug fix ecbf46f Fix a compile warning 6128ad4 Remove bad transpose of normal matrix 58034c4 Remove some unused headers and code 7bd4653 Updated API to force use of vtkShaderCache 66b74c9 Remove some extra code that isnt required f15f4bf Get render passes working in OpenGL2 4362136 Restore file that was accidentally changed 4dd3ac0 Fix some compiler errors that show up on other compilers 925f506 Add in depth peeling pass and a couple other passes 022ae36 A number of Parallel and MPI fixes for OpenGL2 2fc1358 Fix use of undefined vector behavior. fe14d90 Fix for out of range memcpy 0e68c3f Fix three dashbaord issues f7f98f7 Fix clearzpass on opengl ES 2 893c3c5 Fix edge color with composite polydata mapper 2 f497ed3 Added some ifdef needed for OpenGL ES 20 e1d90d0 Fix a bad merge 896b83f Fix RenderingParallel when wrapped and fix a compiler warning 3d57312 Make the old freetype code work with OpenGL2 d23ec3f Minor fix for clearing the zbuffer 6207dbb Add support for imposters for molecular rendering 5b62e02 Make it so that fragment shaders can modify vertexVC 22dd7ae Fix some OpenGLES compile issues 6b8ef81 Significantly better performance with EdgeVisibilityOn a7f4875 Add two more valid images ecd17aa Fix failing cursor2D test and some minor cleanup 4e92339 Fix bas valid image size and a couple NULL copies in SLACReader 1820290 Fix Context2D to clear the current shader before drawing. 029f8bf Fix lighting overdrive on ImagePlaneWidget 85d6b73 Camera was caching when shared between multiple renderers 34a8a2d Fix unnormalized interpolated normals 15753f9 Update the Composite Mapper to reflect changing in Edge Rendering 3c54b35 Fix for shadowed variable warning ddb8fab Fail gracefully if depth peeling is not supported 19de6f8 Fix 2d transparent annotation after depth peeling ed60226 Fix an coordinate issue with CopyToFrameBuffer 03efa72 Minor compiler cleanup bf48e6f make sure glsl extensions are requested at the start of a shader 2e1c54f Fixes for wrong case in include file name 5cc2de8 Fixes for composite poly data mapper2 54d1dc2 Make sure scale is included in the normal matrix 85666eb Make sure molecule mapper works with depth peeling c97d617 Fix lighting to use Blinn-Phong specular model 03efc59 Reduce the size of the test it was too big for my macbook 8cf3140 Add valid image for other systems (not AA etc) 8aef7c2 Add in support for OpenGL ES 3.0 0d5d049 trivial fix for es 2.0 6aa60b9 Fixes so the recent scalar changes compile on OpenGL2 c1eac93 Improve picking support in OpenGL2 aca55423 Minor compile fix for ES dd3801a Fix a few issues with parallel passes in VTK dda7a18 remove some leftover debugging code a7460ef A fix for rendering coincident polygons or lines. b98b7e9 Remove old references to vtkOpenGL.h and fix comment 93ba521 Enable IO/Export (minus gl2ps) for OPenGL2 6e98b4f Fix SynchronizedRenderers to work with use OpenGL2 3994715 Fix gcc warnings and build error with gl2ps 5116308 Fix a bad array reference 84ab1f8 More changes needed to get iceT working and cleanup 52b97a9 Fix compiler warning 094a728 Add valid image due to different z buffer 5c1c4b1 Fix some release graphics resource issues 81666b5 Ifdef out some code for OpenGLES systems 085a036 Add a point gaussian mapper for cosmology and cleanup bf8670a Remove test I added from old OpenGL backend 8f0ef47 Fix up some dashboard issues 598a834 Minor fix to the picking code 180ebd0 Fix floating point issue with chart test 2072f3b Add a timing framework in for testing rendering performance 7d6c491 Filename case issue 3458b18 Add another valid image as this test is sensitive to zbuffer d31ba5b Fix a simple compiler warning. f5e3a9b Break the UpdateVBO method into smaller pieces. 3e09873 Fix missing virtual destructors 0204d0e Improve the performance of the parametric function source fba6708 Add a molecule test ef8e3d4 Uh maybe fixing a cmake issue 940dc7f Cleanup the CMake build a bit 88d4238 Add aother valid image fbad49a Added another valid image 0de7f74 Fix a couple long lines 4a94679 Add virtual destructors again b6e796d Fix dashbaord compile error and some long lines b6e2cf3 Add valid image for OpenGL2 de8deb6 Use MCDCMatrix in shaders 2577188 Use MCDCMatrix in shaders 427694b Fix a compiler warning 38ca2cb Add two valid images 1862e2d Add a subclass for faster composite dataset mapping ea26fe1 Fix compile issues for es2 f91f8ef Expose more methods in opengles3 e25f524 Fix GLES3 9dd7bdb Add support for vtkTextures Transform ivar 342cb10 Fix some dashboard warnings e893f80 Fix for systems with spaces in the path ab843d0 Fix memory leak in helper class holding input data 51a0e97 Fix two compiler warnings 41ca652 Some updates to the timing test cfb3fbf Fix molecular rendering in parallel projection f77c1ff Fix an issue with mapper requiring a polydata input 3943313 Update to a cleaner way of solving the issue 4f3354b Fix a couple issues 409b4c5 A fix for shader link error reporting an molecules with lightkit Kenneth Moreland (6): c29aa73 Dax marching cubes now uses input array not active scalars. c5333aa Allow Dax marching cubes and threshold to work with doubles. 93a1db3 Change vtkDaxMarchingCubes to vtkDaxContour 423e248 Add compute scalars to Dax contour filter. 95a86c5 Support Dax marching tetrahedra 93c30ce Support passing point field data in Dax threshold filter. Lisandro Dalcin (1): aa8f6a0 import mpi4py 1.3 Marco Cecchetti (5): 126ce11 vtkColorString - Helper class for defining a color through a string. 04c2b8c Merged vtkColorString into vtkNamedColors. 1f2cdbf I added a RGBAToHTMLColor and made some minor changes. 848d2f4 Tentative fix for Windows build issue. e0cd5c2 Tentative fix for big-endian machine issue. Marcus D. Hanwell (123): 0b0b7b9 Added a test for biquadratic quad interpolation 8b53468 Exclude the vtkgl.* files (generated code) from coverage e768cfb Make consistent with vtkBiQuadraticQuad cb8e7d1 Added back the QtSQL test for the database class 6698c96 Removed misleading comment - test is built b0e6492 Added back various rendering tests d9bb602 Added back the named components test in FiltersCore 47bcdf2 Removed a few remaining Cg related files 1fd42d6 Refactored the TIFF reader, add support for floats fd35d0a Added progress updates when reading a volume c2a7f9f Remove redundant checks for old JPEG compression 4e060c2 Copy simple TIFF images into buffers more directly 3c6d297 First pass at a new render widget a9c4a04 Implement a basic VBO based poly data mapper a57dea4 Basic support for color from property b7754d7 Add the find module for Eigen 3 45e8939 Added a hack to override OpenGL overrides with GL2 f545b66 Roughly mapping the colors/scalars, updates to shaders e3ce385 Normalize the colors, and put the light the other side... 8d047ac Added the dragon model (already in external data store) 5d973c6 Moved the VBO and IBO creation to helper functions 1534202 Use the vtkPolyDataNormals filter to calculate normals 90d920d Added a points/lines test, added point/line rendering 3cc9225 Added in a program for lines, change a3f0010 Moved the replace function into the helper header 0fbdfdc Refactoring a little, movig IBO stuff into structs 4609c3f Added a polyline, and basic support for rendering it 15b0c1b Refactor uniforms a little, enable point rendering again e017b8e Small changes for point size and line width 4468526 Minor clean up for includes in the mappers 4ee2024 Ensure we set the active shaders 2feb10f Removed commented code/classes from the test ebb8c7b Added in the case for multiple renders/VBO updates d0ade44 Refactor the shader API to comply with VTK style 8163809 Refactor API, comply with VTK style 6c0a1fb Refactor the shader program API to comply with VTK style 865ce36 Added a Vertex Attribute Object (VAO) class f12857d Enable textures now that the vtkTexture class doesn't do it cebeddb Set the z-spacing in a TIFF to match x-spacing 910652d Early attempt at getting the 3D glyph mapper working 38b15eb Hackish, map the colors for the glyphs 4caaa29 Keep the color mapper around, shallow copy for settings 20bd289 Fixed the normal matrix, now molecules look much better bfada62 Make it compile on Linux/X again 0231688 Bring over the Cocoa classes for Mac 6fc649b Intel GLSL compiler is much fussier about type... 6f1f959 Removed the vtkFiltersCore dep ed6aa5a Removed vtkRenderingOpenGL as a dep now too! 8bc98a0 Made vtkRenderingOpenGL2 independent of vtkRenderingOpenGL c2a4792 The PainterDeviceAdaptor is abstract, can be NULL b40b181 Rename vtkOpenGL2* -> vtkOpenGL* a6a584b Very judicious use of sed, vtkOpenGL2* -> vtkOpenGL* cf406e9 Added a concept of backends, added OpenGL and OpenGL2 c512187 File moves necessary to create a context backend 389c88e Context OpenGL and OpenGL2 backends a1a6db6 Some minor tweaks to get the tests passing again a4bd9ca Some modules only in groups if correct backend selected ee5e9a2 Missed these OpenGL2 variants with the mass rename e58ca40 Brought more of the OpenGL module logic over 20b1618 OpenGL and OpenGL2 are mutually exclusive 0652978 If enabled, always override in OpenGL 2 01bc9b5 Unused include for a file that was deleted de0d411 Disable multitexturing in Geovis class 7da0bc3 Moving rendering tests to more appropriate places 312b3ff More test moves into more appropriate locations 00e0fe3 Removed the TDx classes from OpenGL 2 a8b9683 Only enable backends for interface modules being built 8f5d490 Disable test for render widget 703b6d9 Changed the default CDash URL for VTK e96a36c Move several TEST_DEPENDS to switch on backend 7def3bb Create object factory CMake file, move vtk_add_override cc8d147 Now generate the object factory files in a function 5766bc8 Revert "updated baseline images" 66f4884 Revert "updated baseline image" e7f0140 Some dependency updates now vtkRenderingContext2D is abstract 3d17f6c Don't exclude the module from wrapping - initialization c3ea64b Made the label tests pass again! a550da3 Make TCL wrapping happy - no numbers in module names ce2fbc5 Added include for std::string 0e8c8e1 Save the rendering backend used to the config file fdddd74 Avoid early termination when collecting actors 8b695d8 vtkOpenGLContextActor should subclass vtkContextActor 92b2485 One of the tests needs a context device to render 94e1f9e Removed unused variable - used in subclasses 7ded8b1 These classes are abstract, fix smoke tests c3ffed0 Fix for Windows mangling issue 70e078b Must be marked WRAP_EXCLUDE too for Tcl smoke tests 2a67262 Reduce the number of renders (avoid time outs) 5328c48 Move device adapter initialization to the OpenGL module 4518572 BUG: Make selections more permanent, linked to object 3c35743 STYLE: Some basic style fixes 4666a70 Removed sorts as the inputs were already sorted 4940fde Added a test to exercise bar graph selection 94288ee Remove the wrap exclusion at the module level e5f4217 More exclusions, avoid setting ABSTRACT twice 82e6876 TCL doesn't like numbers in module names 1303f08 Comment out the animated PDB renders d350387 CMake's exec_program is deprecated, revert back 2cfa25b Added some code to fix Tcl and its use of OpenGL backends f1d3e72 Added excludes for OpenGL2 headers b1ec605 Enable the Java rendering test for OpenGL2 too 800282f Actually define GLX_GLXEXT_LEGACY to prevent the include e124dd9 Update to the upstream GLEW 1.11.0 release 1b2d22f Added logic for OSMesa contexts c0dee40 Add support for OSMesa builds of OpenGL2 b2e4fb3 Added colored bar charts, along with a test 666ade8 Expand support for the OpenGL2 backend 3ae161f Restore test deps for matplotlib tests 9b17ebd Disable some widget tests building for OpenGL2 914c682 BUG: Fix bug #14378, ensure observer is removed in dtor 1cecc79 Added a non-const form of vtkTesting::AddArguments b566db3 Trivial fixes for API change in OpenGL2 shaders 9a91830 BUG: Fixed error in passing position of key press 88f5a5b Fix compile failures seen with latest FreeType b6173fb Make the VBO update more selective for picking 318ae30 Convert the file name to a const char* c048d00 Minor fixes for code style, indentation, use vtkNew fd6312e Benchmarking triangles, chart that updates 4e7c9fc Made a benchmark module, moved the benchmark tools 9081c12 Added a --timeout option, default to 1 second bfc6688 Call Write on the delimited text writer 77a2e48 Just make the benchmark module depend on volume rendering 8f183b5 Use the resolution variable to set the cube size Matt McCormick (1): 44aa48f Reset VTK_MODULES_REQUESTED to all modules with multiple calls. Matthew Woehlke (2): 980d648 Fix rotation handling in vtkTransformInterpolator. 192ddaa Fix operation order in vtkTransformInterpolator. MetaIO developers (1): e00f346 MetaIO 2014-07-09 (53aa417f) Nicolas Gallego (1): a32b29b IntersectWithLine method documentation update Orion Poplawski (1): c7f91af thirdparty: support defaulting all third party library sources Patric Schmitz (1): 58373b1 Include vtkPythonPackages in Web/JavaScript/CMakeLists.txt Patrick O'Leary (1): bd6960e added paraviewweb widget for catalyst workbench Paul Edwards (3): ac52a40 Fix for polyhedron cells. 4af6a72 Bug fix for dataset surface filter. 3cf2f88 Fixing how polydata cells are deleted. Robert Maynard (17): 90308be Update Dax Accelerator to use the new tll signature. e4aac22 Update the Dax Accelerator to use the new dispatcher classes. d353840 Correct warnings about negative unsigned constant values. 6803ffd Properly implement the factory for the dax filters. 278b3c6 EnSight Binary uses 64bit longs so explicitly use those instead of long. b7cb56b Netcdf now handles different directories for c and cxx bindings. 83b4764 Improve the performance of vtkDataArray::ComputeScalarRange. 9f1773e Improve the performance of vtkDataArray::ComputeVectorRange. 90289d7 Move all free functions in vtkDataArray into an anonymous namespace. a84e734 Update ComputeVectorRange based on gerrit feedback. 074e1fe Update DataArray and DataArrayTemplate to use vtkTypeTraits. 219b75b Correct ComputeScalarRange when dealing with multiple components. 87291c6 Improve ComputeScalarRange when we have a single component. dedc2ea Correct an issue with converting dax data to vtk polydata. 196bbe8 Refactor GetRange to compute all ranges at the same time. 880b695 Correctly detect that we are compiling with MSVC. 2dfb683 Enable the output of the number of triangles in the benchmark. Roger Bramon (1): 7b31f50 Fix QVTKWidget problem on Windows with Aero off and Qt5 Ronald R?mer (1): 44131c6 bugfix 14459: Iterating through polydata cells incorrectly. Sandeep Menon (1): b11deb8 vtkOBJReader: accept relative indices in OBJ files Sankhesh Jhaveri (119): 251f319 BUG: Fix failing EnSightBlow5ASCII tests b6a12db BUG: Turned multisampling OFF for certain tests failing on linux with ATI 82fca2d Fixed multisampling issues for some tests on ATI bfed0a0 ENH: Script to generate API differences between two git revisions d90b36a ENH: Added test for vtkImageCroppingRegionsWidget to improve coverage 4724a47 ENH: Enable selection of translucent geometry 596243f BUG: VTK_JAVA_SOURCE_VERSION to accomodate different java versions 942444b Re-enabling tests disabled during modularization for Interaction/Widgets 7d5b248 BUG: Duplicate class definition in TestSeedWidget2 c458abe BUG: Duplicate class definition of vtkSeedCallback2 0d98066 Additional baseline for TestAreaSelections 20d5df7 BUG: Border visibility from underlying vtkScalarBar actor f4ab3e8 ENH: New RenderingExternal module 4a3db5a ENH: Added custom renderer and camera classes for external support e6e4706 Variable renamed to maintain consistent syntax c8e1074 ENH: Cleaned up the ExternalRenderWindow efe5e07 Set light transform matrix irrespective of light type d921a8e ENH: Added test for vtkRenderingExternal bb9d2f0 Replace baseline with MD5 sum 754b0cd Fix lighting for the external rendering module be2a1a7 ENH: Fetch viewport size for the existing OpenGL context 3f2c51b Cleaned debugging code 9bf9827 Updated baseline for TestGLUTRenderWindow 70dd180 FIX: vtkRenderingExternal module is OFF by default 902183a ENH: Synchronize camera focalpoint 59a836f ENH: External renderer preserves buffers by default 0d4f055 Using the external renderwindow always uses current context f9f4ec9 ENH: Add ExternalVTKWidget 30de05b STYLE: Fixed indentation as per VTK style guidelines 0948eb1 ENH: Added interactor to ExternalVTKWidget 9914a84 ENH: Compute the window size when initializing from context a507a23 Moved the eye determination code to Start 913b13e ENH: Make sure VTK does stereo rendering faa1f77 Use vtkGenericOpenGLRenderWindow 05ba491 Attempt at fixing light issues across multiple screens 04ed903 Renamed module to vtkRenderingVolumeOpenGLNew 1013183 ENH: Changed dependency from glew to vtkglew defd350 FIX: Build error due to misplaced colon and style fixes 7d2e673 ENH: Implement PrintSelf a312624 STYLE: Fix lines larger than 80 chars 9594388 FIX: Failing HeaderTest and rename vtkGLSLShader 840dd5f Bring back deleted files abb5c30 FIX: VertexArray issue on APPLE machines 52f78f2 ENH: Additional tests for new volume mapper 7e69bad ENH: Added baselines based generated using old volume mapper 4f78b2a FIX: Exclude the vtkRenderingOpenGLNew module from BUILD_ALL_MODULES 9d74a3e FIX: Use RegressionTestImage instead of InteractorEventLoop d2cd5d7 FIX: Disable new volume rendering tests for old mapper d44d3e8 FIX: Exclude vtkRenderingVolumeOpenGLNew from vtkOpenGL kit 723ef37 FIX: Reset clipping planes 9e57bef FIX: Remove all vtkgl dependencies for vtkRenderingVolumeOpenGLNew 174238e Fix unused variable warning 09ae2a3 ENH: Added new vtkOpenGLGPUVolumeRayCastMapper to VolumeOpenGL2 bcc1626 ENH: Add all GPURayCast tests for OpenGL2 backend 92413fb Remove unused shader files 3647b66 Fix cmake string issue f6993a1 STYLE: Rename shader variables to maintain consistency cf497e9 ENH: Initial take at SmartVolumeMapper support 93af2c1 ENH: Removed all vtkVolumeTextureMapper3D refs from OpenGL2 module 857241a Port warning and style fixes from VolumeOpenGL2 a8c1117 ENH: Sorted out python and tcl tests for new volume rendering 374acf5 Make SmartVolumeMapper available for VolumeAMR 933c76a ENH: Volume Mapper benchmark test b3abe90 FIX: Make sure context is present 3f78716 FIX: Bypass testing if OpenGL extensions not supported 9a9917f STYLE: Ensure change follows VTK style 877eda9 FIX: Python testing was saving foo_1.valid.png style files 7c3fc18 Removed use of unrequired variable 9a35ca2 FIX: Disable antialiasing in new gpu volume tests 07b79de FIX: Nice axis bounds calculation when flipped 3fe8c43 FIX: Tooltips not showing up when axis inverted. 6dec986 ENH: Tests for inverted axis functionality 2c613d9 Test new volume mapper against positional lights 498c252 BUG: Representation not updating when volume input changed 740f018 Fix crash when running VolumeUpdate test 703ff1e Test for large sample distance in volume mapper c6a871a Test against geometry rendering d45993b Changed the noise generator amplitude to 0.1 c2e7405 Add baseline for new sample distance test 36e2614 Convert RGB Table to use vtkTextureObject ddf052c ENH: Ability to load create alpha textures from raw data 13abfb7 Minor semantic changes 65ff2f8 ENH: Use texture object for opacity tables 8a8b190 ENH: Use vtkTextureObject for gradient opacity table a4e8dc6 ENH: Make sure the new API for opacity tables is supported by mapper 275d348 Initial null value for pointer be72f94 ENH: Convert noise and depth textures to use texture object b65dde2 Initial work to reformat the window level test dde316b Started working on gradient opacity test for new mapper 6b29023 Added new gradient opacity test f85cec9 Test the new mapper for gradient opacity support a930c1c BUG: Fix an issue in the shader code that supports gradient opacity 53bb2e0 Pre-compute gradient function to reduce computation overhead c21a5ee Replaced old window level test for a better one 48d23e2 Check if extensions are supported for the new window level test ce47e09 Turn off auto adjust sample distances 95d92fd Set parameters before activating texture b7c399b Free the texture object memory at destruction time 2865feb Safety checks before deleting objects c5fd3c1 Safeguard against bad memory access b74405e Bring back the smart volume mapper window level test 0319b49 ENH: Use generic render window to support multiple platforms 400109c Fix GLUT API include header for Mac OSX and Windows bd9f401 Maintain consistent style across classes 9479946 Baseline for SmartVolumeMapper window level test 910f422 Additional baseline for failing test c4ac1b5 Prevent releasing graphics resources on the same memory twice dcadf4a Removed unwanted commented out code 1098a12 If check against bad memory access e140114 Support multiple renderers in the ExternalVTKWidget 9c9b0fc Fix segfault due to invalid pointer address 88c3da4 Fix viewport size change when renderwindow resizes 2c24e37 Removed redundant commented out code 3e5a471 Exclude vtkRenderingExternal from BUILD_ALL_MODULES 8fc37ab Improved style and documentation 015df9c Deleted unrequired commented debug code b1d35a1 GLUT test as an example for ExternalVTKWidget use dd4e27d Disable vtkRenderingExternal module for OpenGL2 backend 57f295d Remove debugging code Scott Wittenburg (20): 0d8d993 Added code to draw current selection rectangle in viewport. 847d750 Added code to support a cache option for filebrowser widget. ab674b2 Added canvas based image zooming and panning capabilities. 119cc10 Fixed a null reference by surrounding the call with a check. 3650e06 Support faster configuration times by checking dependencies at runtime. 7f92da1 Changed to make tests run serially, async nature was causing collisions. 2d1df14 Replace an import which disappeared and broke all dashboard web tests. 38ee579 Updating to Autobahn python version 0.8.13 to get http long poll endpoints. b576693 Added latest Autobahn JS (0.9.4) to support pvweb authentication. 12f6589 Properly override ApplicationSession c-tor, supports Crossbar.io. 2ac0cc8 This should fix problems with paraviewweb and python 2.6. 2f1e740 Added alternate jQuery catalyst view constructor. a65cdaa Added an rpc method to exit after a delay instead of immediately. 77d60b4 Update vtkweb loader to support addition of scalar opacity widget. b9cde71 Use "-dr" in lauch examples to encourage disabling registry for pvweb. 9ea8020 In the vtkweb loader, add css specific to the proxy editor widget. 5337c31 Changes to viewports supporting capturing screenshots for pvweb. f90491f Support vtkweb and pvweb servers using http only (no websockets). 2c4fb18 Added missing import which broke http-only servers not serving content. c2be1bc Updating launcher to include a complete set of example profiles. Sean McBride (142): 9fd9602 bug #14418: Remove addition of "-Wno-deprecated" compiler flag 3bbabb7 Fix clang analyzer warning about passing null to strcmp a6b3be7 Fixed clang analyzer warning about passing null to memcpy 3905cf7 Fixed clang analyzer warning about reading uninitialized memory fe1c6e0 Fixed clang analyzer waring about a dead store. a2fa76f Fixed clang analyzer warning about dead store 2bc660b Fixed clang analyzer warning about dead store. e4220a1 Fixed clang analyzer warning about dead store. 3b76550 Fixed clang analyzer warning about dead store. bdba2ea Fixed clang analyzer warning about dead store. cbf8c3a Fixed clang analyzer warning about 2 dead stores. d567715 Fixed clang analyzer warning about dead store. 23eba09 Fixed clang analyzer warning about reading past an array. 0bc6639 Fixed several clang analyzer warnings. d6a4175 Fixed clang analyzer warning about reading uninitialized memory. 480a8f9 Fixed clang analyzer warning about dead store to 'pd'. 27fa387 Fixed clang analyzer warning about passing null to memcpy. 6296aa1 Fixed clang analyzer warning about dead store to 'index'. c8389e9 Fixed clang analyzer warning about dead store to 'bestTime'. 8983273 Workaround clang analyzer warning by creating temp variable. 67ed07b Fixed clang analyzer warnings about dead stores. 5ff4c6b Misc cleanup of code nearby clang analyzer warnings. baea339 Fixed clang analyzer warnings about dead stores. d192654 Fixed clang analyzer warning about dead store at very end of method. 9c29087 Fixed clang analyzer warning about dead store to 'itr'. 5470f39 Fixed clang analyzer warning about dead store to 'cptr'. e319716 Fixed null deref found by clang analyzer 4cc7d0f Fixed clang analyzer warnings about dereferences 5c91a74 Suppress clang analyzer warning d0f7675 Fixed clang analyzer warning about null deref c85fdec Fixed clang analyzer warning about reading uninitialized data. 6195d1c Fixed infinite recursion in vtkBitArray::RemoveFirstTuple() f26450e Improved code coverage of vtkScalarsToColors by adding more tests fe50cbc Added tests for a few uncovered vtkMatrix3x3 methods bf70da0 Fixed error in vtkFiltersCoreCxx-TestClipPolyData test 107df71 Added comments about the danger of not clamping. 74f4888 Removed -fobjc-gc from VTK_REQUIRED_OBJCXX_FLAGS a3e9fc9 Various Cocoa improvements and fixes f062ed5 Fixed a bunch of clang -Wabsolute-value warnings 468f25d Removed all uses of deprecated NSOpenGLPFACompliant 5a568d2 Assume UTF8 for vtkCarbonRenderWindow::SetWindowName ad14e44 Remove unnessary 'if' before 'delete[]' bcb3344 Add #error when trying to build as Cocoa ARC 3d1f2d7 Fixed confusing indentation, no behaviour change a46f611 Fixed unused variable warning in release 2eb00f9 Rewrote vtkCoreGraphicsGPUInfoList to not use deprecated API 116f93f Removed checks for antique Borland versions 7399f6d Changed public API of vtkGPUInfo to return vtkTypeUInt64 for memory sizes. 985aab4 Fix clang warning about comparision that's always true. 486dc55 Added TODOs to indicate source of TestQuadricLODActor failure 13354f6 Change #include style from <> to "" for some vtk files 6ba34d7 Changed #include to a71e3d4 replaced #include with 0a8ca52 replaced most with includes dfc4019 changed some to 5370312 changed some to 8446c7b Fix gcc warning about possible use of uninitialized variable 64e66d7 Added check for null before dereference, for bug #14671 e579693 cleanup all uses of fclose() in vtkSTLReader, for bug #14515 af89456 Removed dead code in test by using #if 0 273205d Moved unused var suppression to suppressed dead code warning 87526dc Removed unneeded break statements in switches 77e6fb2 Fixed inconsistent #include style, from <> to "" 6e73ac3 Fixed inconsistent #include style, changed <> to "" 553c12e Fixed SimpleCocoaVTK Xcode project to build properly. b6a4db1 Fixed bug #14266: fix observation of NSView size change 40b1c95 Fixed unused const var warning fe69c24 Fixed a backwards ?if? test, and memory leak de54031 Eliminated unneeded null checks before using delete/free a3a2ed9 Fixed indentation level b417e82 Fixed ?null deref? warning 775ea71 Simplified memory deallocation 6ddb0bb Removed useless assignment 83a5945 Fixed warning about using null with memcpy ddccb71 Removed useless assignments 5372604 Misc cleanup and refactoring ca32186 Bail early on null parameter ba2bbac Sync up Cocoa code between OpenGL and OpenGL2 dd3f20d Added partial/initial support for Cocoa ARC memory management a0c7098 Remove dead store to fix warning. ab36a82 Added some consts in a few places 93b12c9 Put initial assignment at declaration 70d8784 Fixed analyzer warning by removing null check b8af0b7 Fixed analyzer warning about possible null deref 832f091 Fixed a few dead store warnings 8f0a469 Fixed dead store warning by removing redundant 'break' c591782 Fixed dead store warning by reformulating loop e2dad20 Fixed null dereference 1fa832c Fixed false positive warning about null deref ce0618c Fixed null dereference 57d3811 Fixed obvious null dereferences fd385ce Hopefully supress dashboard compiler warning in QT header 4dc4b4f Fixed use of memory after its deallocation c5bacd4 Fixed incorrect indentation 0885215 Prevent null deref of ?null? 53c18de Prevent null deref of ?composite? fn pointer d00f600 Init memory to prevent it being used uninitialized 2bacee0 Removed dead store to ?j? 6fd5a5d Removed dead stores 9d6d565 Suppress numerous warnings about using uninitialized memory 845c249 Remove a likely dead store ba93153 Prevent null dereferences 33dde16 Fixed null deref and whitespace/indentation e333730 Fixed obvious dead stores 14c4790 Fixed null deref by returning upon error a5c4a9a Fixed memory leaks and malloc(0) 68294b7 Removed minor dead stores, to fix warnings 6e773e1 Refactor to make intent clear to clang analyzer 92f6a35 Fixed warning about possible null deref 3099508 Fix clang analyzer warning by adding temp variable af2526d Fixed warning about using ?volBounds? uninitialized fca2fd5 Only react to NSView frame changes if VTK itself created the NSView fc6dc08 Suppress clang analyzer warning 496f9fb Suppress warning about dead store e2bf9bd Suppress warning about ?x? used uninitialized bb7623d Move warning check to prevent ?fd? null deref dd0dacc Return after warning to prevent ?dsa? null deref 9369028 Simplify and exit quickly if input point ids empty e8ef3e5 Another try to suppress warnings from Qt headers 666d78c Advance null check to before cast d5feacb Fix possible null deref of ?dsa? 42815af Added vtkErrorMacro to code paths that give null ptrs ea3f62e Removed harmless-looking dead code 91dcdaa Another attempt to silence warning from Qt header 52b233a Fixed -Wstring-conversion warnings c02f83d Whitespace/spelling 53c1f9f Fix warning about use-after-free efc3a4e Fix possible null deref warnings 2b14f1f Made some copy-pasted code more self-similar 4a53917 Fixed types of some copy-pasted code 337fa28 Move some declarations closer to use. abdb84d Removed useless null check 083a4c5 Return early to avoid null to strcmp() bdfb1cd Removed dubious #undef of keywords 141198e Refactoring and cleanup of Cocoa NSWindow and NSView observations 6dce510 Remove double underscore in header guards (.txx & __vtk*_txx form) 7cef24e Remove double underscore in header guards (.in & __vtk*_h form) 152e7f4 Remove double underscore in header guards (__vtk*_cxx form) 5a668f9 Manual tweak of .hxx include guard naming e89fdcf Remove double underscore in header guards (.h & __vtk*_h form) 9686d25 Manual search and cleanup of "__vtk" 5a31997 Remove the addition of a few inappropriate vtkErrorMacro Sebastien Jourdain (60): 9285aef Add catalyst web widget into VTK 42746d0 Add NaN support in web chart rendering c4821d4 Add a resampling filter ca29c4e Add JSON writer for ImageData ce554a5 Extend vtkImageMapToColors to support Mask color and Non Active Scalar input e6bcb7f Use / for path separator to prevent Windows related issue with escape char 697d178 Improve implementation of Catalyst viewer 6b1789a Add image resampler catalyst web widget 7d7fcfa Remove test dependency to data when not needed 3e71420 Remove usage of the keyword with to allow old python 59b5c51 Add new set of catalyst web widgets 8c7aca7 Attempt to handle some system raise condition a00f98f Add catalyst web composite widget b6700df Better composite catalyst web widget 3bb60f2 better UI for catalyst re-sampler web widget c395736 Various VTK-web improvement a8f8905 Fix vtkweb catalyst css e64f69d Add cost information in workbench analysis b4f486f Improve web compositing for dynamic interaction 4b450f4 Properly handle background selector visibility 1228f92 Fix composite rendering widget for search 4ef8264 Add sorting capabilities eaf3730 Refresh workbench UI and workflow 8f3a357 Fix Composite Javascript for WebKit 3ce7a4f Improve ParaView cinema UI 6d42e91 Improve basic search in web-catalyst dfcf9c7 Fix catalyst web - cost time computation 8ef209e Improve catalyst web UI c9161c1 Catalyst web: Minor Web UI change b19eaa4 Catalyst-web: Improve composite search experience cfcebd1 Add image width column 794807f Add cost estimate for Catalyst Web 0607cc5 Catalyst-Web estimate UI fix 5a83360 Change catalyst-web analysis API to expect full URL 8241ef5 Fix center of rotation for WebGL renderer 6ec408f Fix WebGL background orientation 87af8da Fix basic catalyst viewer with theta cc6002e Add runtime libraries on Windows for Java binary package 09f9d20 Fix several catalyst web UI issue 30e74c1 Add configuration pass to Catalyst PVW workflow 53d52a8 Add support for mobile device interaction 86cfbf4 Catalyst Web - Composite improvement 5139f27 Catalyst web 14b1a6e Add new rendering class API based on vtkPanel class 6b7102f Remove @Override annotation to prevent compilation issue on old Java compiler b7d419b Upgrade autobahn version to 0.8.9 85d3beb Upgrade Twisted version to 14.0.0 e5c6e09 Upgrade ZopeInterface version to 4.1.1 d7a0e9d Add SixPython module for Autobahn dependency 06aaa80 Update Autobahn/JS library version 9793f84 Update VTK Web Python code to handle WAMP v2 82a4d41 Update Web applications to support new protocol API 4c98d89 Fix python for vtkweb 4937ef8 Allow arbitrary WebSocket endpoint c9f5efb Add bottstrap3 + pv lib in loader ff5ffe4 Fix import with latest Autobahn update ad50df2 Add missing call to properly handle webgl rendering 93bcb11 Remove loading of native lib from vtk classes 43de2bf Add Get/SetTuple6 methods 1f59e83 Add additional information for Java package build Shawn Waldon (20): f9a208d Add a smartpointer for PyObjects befcfd1 Format comments according to VTK stlye guide ced0756 Fix the vtkPolyPlane implicit function ad5d35c Change vtkProbeFilter to expose the 'in' threshold 011ce9b Move static data in vtkVRMLImporter to local struct e23a5b2 Assume block request produced what was requested 25fd4c5 Add a documentation module that contains information keys 2f43b03 Add block amount of detail information key b2bd40a Block opacity and color are now more independent 8b650ea Add a baseline for block opacity with no depth peeling da65eea Adding a key to indicate the current process has the block 0caa936 Legacy reader/writers for composite data now save field data a8d2788 Added comment on required invocation order 9dac67f Prefer vtkDoubleArray::GetValue to GetTuple for single component arrays 1289500 Made vtkGaussianSplatter handle composite data input dc6386a Made sure composite data iterators were deleted properly f69efc8 Made vtkPointGaussianMapper handle NULL arrays 25e578b Add an option to set default radius of point gaussian 9d090aa Fix triangle size for sprites with radius > 1 96c61c1 Made Point Gaussian mapper handle scale arrays not in dataset Shinya Onogi (1): 313b647 fix_GPU_resource_handling Sujin Philip (9): b505112 Fix for buffer overflow in vtkCubeAxesActor class 71bd130 Toolchain files for MICs on stampede 55da875 Fix compile warnings in SMP under Windows 17a6674 Additions to SMP API a0d1391 Fix SMP examples warnings 44c9610 VTK SMP implementation of SynchronizedTemplates3D 42f31c8 Fix SMP compile warning in VC++ 0dceda0 Use the correct TBB lib based on the build config 485d174 Fix for SMP examples compile issues Thomas Vaughan (1): e6f7476 Set origin and spacing in vtkSurfaceReconstructionFilter. Ref: Mantis 0002826. Tim Thirion (14): 232657e Prefer xcrun when querying for iOS-related SDK elements 72dfcc3 Add CMake option to select OpenGL ES 2.0 or 3.0 7eaad01 Add x86_64 to list of archs for iOS simulator 27fb188 Surfaces example ported to iOS 7465b7b Add CMake script to allow user to `make framework` for iOS 48752ae Remove shell script for creating VTK framework; update iOS readme 628febb Update CMakeLists for iOS examples d9d3fc3 Create iOS framework in one pass through CMake config 27b58f1 Clean up iOS build script 86dbd0f Make vtkVersion available sooner in CMakeLists.txt b11f61c iOS build: check install directories before any compilation 092e7fb iOS build: pass OpenGL ES version string to child builds 39229f7 Update Android toolchain file (now support NDKs r5 through r10d) 425fc48 Add one-pass Android build Tristan Coulange (5): 0679bf4 BUG: fix some xdmf writer crashes d4fc9b3 BUG: Add a missing include for VS 2013 3c7c082 Add support for original ids for generic dataset a5e6d3d BUG: fix xdmf test failure b6235a7 BUG: Fix the quads evaluate location Utkarsh Ayachit (56): 3e5e0e1 Adding a new test for TestSocketCommunicator. 8489299 Added test to test vtkSynchronizedRenderers. 2bc3308 Deprecate vtkOpenGLPolyDataMapper. b80e196 Fix segfault with TestSetGet. 2be768b Fix build issues with deprecated vtkOpenGLPolyDataMapper. 4c3786b Add a delay between process launches. d616545 Fixed mismatches cell arrays in vtkPStreamTracer. 5a8a092 Added ability to probe filter to allow disabling of passing field data. c4c8ce8 Add support for empty strinngs in SetInputArrayToProcess. 59b7ad1 Make it possible to override ClampPos. c19112e Remove OpenGL error checks that were causing errors. 169f015 BUG #14244: Fix stereo image captures. e3229b0 Add helper method to convert from SelectionField to AttributeType. 59360cd Fix appending of scalar arrays. 4e338f3 Fix DataSet reference in when input array is passed to output. abf3539 Avoid exceptions on StringArrays. b345cec Fixed exceptions with older numpy version. 5c735a6 Cleanup MPI controller properly. 235ceec vtkExtractSelectedRows only works with IdTypeArray. daf8c6e BUG #14828: Keep surface color from interacting with scalar color. de46ebb Handle append scalar in CompositeDataSetAttributes. a5daf04 BUG: Fixed opacity mapping when scalar array is vtkUnsignedChar. 2327e0a BUG #14813: Fix range reported for mode shapes. 9085e57 BUG #14599: Handle double values properly. 4f3ffec Fix issue with empty arrays with numpy 1.2.1. 82a0c47 Don't glyph masked points in vtkUniformGrid. 73739ae BUG: Fix invalid return value check in vtkClientSocket. 535d6c6 vtkScalarBarRepresentation doesn't call Superclass. ac920d1 Fixed logic to work when an empty vtkSelection is passed. d7aca98 Fix handling of empty selection on ParallelCoordinates. 45efae2 Fixed issue with selection frame line style. dc8280b Refactoring CMake code for Python modules. 126135c BUG #14971. Fix invalid sprintf() in vtkPNGWriter. 4228c2d Add missing include. Needed for std::max/min. 6828506 Handle case when make_vector is called with NumPy arrays. f21207c Make vtkScalarsToColorsPainter respect ScalarMaterialMode. a765c1a Update TestScalarMaterialMode test image size. 92be9c2 BUG #14779. Fixes for vtkDistancePolyDataFilter. 49e0b6a BUG 14693: Fixed vtkAssignAttribute for unnamed arrays. 4087b62 BUG #12753: Fixed support for large images. 51996a6 BUG #11607: Fixed support for large images. 1c9adc2 Add support for vtkTable to vtkExtractSelectedThresholds. ef663ee Fixed warnings with shadowed variables. 031f7f6 BUG #15046, BUG #15020: Fix issues with OpenGL 1.2. 25e3938 BUG #15058: Fixes unclipped grid. 9ffb979 BUG #14809: Use title size when placing title in vtkChartXY. 015c6cf vtkPlotGrid draws grid even when axis is invisible. bf73ac0 BUG #15132: Fix incorrect flag check. f1a90fd Disable OpenGL error checks in release builds. 8bc9a3e Adding alternate baseline for TestLinePlotAxisFonts. a4069c6 Change invalid extent error to a debug message. 5fa4f8c Fixed typo in commit 031f7f6371. 6b86fb0 Fix inverted ifdef NDEBUG in commit f1a90fd2. 74a35b4 Forward InteractionEvent to Interactor. 5e791b5 Miscellaneous vtkContextInteractorStyle fixes. c22030c Fix missing headers. Will Schroeder (13): 399f778 Disabling translation and scaling now works. b04dd36 Added the ability to specify a clip tolerance. 9104559 Fixed bug causing plane to disappear on boundary. 0b42c0e InsertNextCell and related method now return the proper vtkIdType. c1d3768 Create vtkPolyData instead of vtkUnstructuredGrid when passing points. 0567a19 Extended filter to support culling unused points. eb41a25 Added ability to control alpha shape output bdd6fef Added hints for vtkBox.GetBounds() 5481868 Updated documentation 5111dc4 Select internal tetra tessellation based on scalar change 5eec2e2 New data file for QuadraticTetra e042195 Alternative test image ce22619 Progress reporting was broken XDMF Developers (3): 3fa4d33 export xdmf for import into vtk fe051e5 export xdmf for import into vtk 9195a1f export xdmf for import into vtk Xabi Riobe (1): 1c05c1f BUG: The method vtkClipPlanesPainter::UpdateBounds must not be implemented. Zack Galbreath (25): 83a2ffd fix lingering off-by-one error c0ff488 new writer: vtkPhyloXMLTreeWriter 2841e3d attempt to silence "possible loss of data" warning bba7656 improve the thoroughness of TestPhyloXMLTreeWriter 8153428 add baseline directory c71d9c2 get the baseline file's path from the command line 52d6255 add option to write XML to string instead of file e90c46a fix failing tests revealed by gerrit 183bb5d fix the format of PhyloXML references 2f042ba fix blank newline in XML output e99683a vtkXMLReader can now read from an input string 0471167 new class: vtkPhyloXMLTreeReader 8bc3c4d consolidate tests for PhyloXML 1b01fb8 silence unused parameter warning 6d50103 change signatures for wrapping 48341cd copy row names from R to vtkTable 729fe63 do not assume 1st column holds row names bba6de8 fix failing SetGet test forvtkHeatmapItem c06dd72 preserve R data.frame row names ea356a1 break vtkRCalculatorFilter's input/output symmetry 4cfbdfd style cleanup 1407114 add SSL support to VTKWeb server b77eff3 fix potential segmentation fault 21d92cf change the way we shut down the R interface 4ffb1c5 fix failing R tests reported by CDash acbauer (1): 8b5feb1 Fixing issue of wrong celldata output order from vtkGeometryFilter. xabi riobe (4): adf24a5 Fix memory leak in vtkPNGWriter when OutOfDiskSpaceError d5e1240 Initialize row_pointers e7438f2 Fix numerical precision problem in vtkCellLocator::IntersectWithLine 949ffbf Add default value for argument From dave.demarle at kitware.com Thu Mar 5 11:23:28 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 5 Mar 2015 11:23:28 -0500 Subject: [vtk-developers] announce: vtk 6.2.0 release candidate 1 is ready In-Reply-To: References: <20150219200444.933334771@mail.rogue-research.com> <20150219212511.1505792326@mail.rogue-research.com> <20150219214749.727843881@mail.rogue-research.com> Message-ID: Never tell me the odds Goldenrod! David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Sat, Feb 21, 2015 at 8:19 PM, David Cole via vtk-developers < vtk-developers at vtk.org> wrote: > Just some real-world data to consider: > > For the past three VTK releases (5.10, 6.0 and 6.1), here are the > stats, based on the tags in the git repo. > > average number of release candidates before a release's "final" > (x.x.0) release: 3 > average number of days between consecutive release candidates: 16 > average number of days from rc1 to final release: 40 > average number of days between x-rc1 and (x+1)-rc1: 357 > > I would think such readily available data ought to be considered when > determining the schedule for a set of release candidates. Even by > those whose hair is geometrically challenged. ;-) > > Based on historical data, I would expect the final release of VTK > 6.2.0 to land around Feb. 16th + 40, or approximately March 28th. > > > Thanks for the efforts. I am particularly looking forward to the > OpenGL2 backend becoming a reality, even if it is still experimental > for this release. > > Thx, > David C. > > > > > > > On Sat, Feb 21, 2015 at 7:45 AM, Will Schroeder > wrote: > > There is also the pointy-haired management concern. That is, we are > coming > > up to the end of Year 2 NIH funding for VTK Maintenance. We have a report > > due in mid-March and I want to make it as strong as possible so we can > > continue doing other great work along the lines of OpenGL2, interaction, > > community, and medical data integration. Being able to talk about a > release > > makes me very happy, and it will honor the investment that NIH is making > > into VTK. > > > > W > > > > On Fri, Feb 20, 2015 at 9:09 AM, Marcus D. Hanwell > > wrote: > >> > >> On Thu, Feb 19, 2015 at 4:47 PM, Sean McBride > >> wrote: > >> > On Thu, 19 Feb 2015 16:36:12 -0500, Marcus D. Hanwell said: > >> > > >> >>Why make more than one RC if there are no > >> >>critical flaws discovered? > >> > > >> > No disagreement there. But if the 1 rc period lasts only 4 business > >> > days (it was announced late Monday), there's *insufficient time* to > look for > >> > flaws. > >> > >> Agreed, I have been really busy with other things and didn't > >> appreciate this. Hopefully we can extend it out a day or two - would > >> that offer enough time? > >> > > >> > VTK 6.1 was released 13 months ago. Why the rush to declare 6.2 > final? > >> > > >> These things are always a balancing act, and we would like to increase > >> the release frequency so that we avoid this 13 month cycles. Thanks > >> for your feedback, and all of your contributions to VTK. > >> > >> Marcus > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the list archives at: > http://markmail.org/search/?q=vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > > > > > > > > -- > > William J. Schroeder, PhD > > Kitware, Inc. > > 28 Corporate Drive > > Clifton Park, NY 12065 > > will.schroeder at kitware.com > > http://www.kitware.com > > (518) 881-4902 > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Fri Mar 6 08:33:58 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 6 Mar 2015 08:33:58 -0500 Subject: [vtk-developers] SMP algorithm errors on Mac Message-ID: Will, In each of the SMP implementations (FlyEdges, Splatters, SampleFunction), if I remove the class name qualifier from each use of a member function, they compile for example: vtkFlyingEdges3DAlgorithm::Pass1 pass1(&algo,value); change to Pass1 pass1(&algo,value); and likewise through all of the other similar declarations. Bill -- Unpaid intern in BillsBasement at noware dot com From will.schroeder at kitware.com Fri Mar 6 08:46:59 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Fri, 6 Mar 2015 08:46:59 -0500 Subject: [vtk-developers] SMP algorithm errors on Mac In-Reply-To: References: Message-ID: Okay how about I make another round of edits to SampleFunction and push it in through gerrit (assuming it compiles on my windows box -- I'm worried that it won't compile on other systems). And if this doesn't work I'll ask Brad K. for help. It'll be later this morning when I can back to it; I've got some writing assignments and tcons to contend with this morning. W On Fri, Mar 6, 2015 at 8:33 AM, Bill Lorensen wrote: > Will, > > In each of the SMP implementations (FlyEdges, Splatters, SampleFunction), > if I remove the class name qualifier from each use of a member > function, they compile > > for example: > vtkFlyingEdges3DAlgorithm::Pass1 pass1(&algo,value); > change to > Pass1 pass1(&algo,value); > > and likewise through all of the other similar declarations. > > Bill > > -- > Unpaid intern in BillsBasement at noware dot com > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Fri Mar 6 09:09:44 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 6 Mar 2015 09:09:44 -0500 Subject: [vtk-developers] SMP algorithm errors on Mac In-Reply-To: References: Message-ID: I just submitted a gerrit topic. On Mar 6, 2015 8:47 AM, "Will Schroeder" wrote: > Okay how about I make another round of edits to SampleFunction and push it > in through gerrit (assuming it compiles on my windows box -- I'm worried > that it won't compile on other systems). And if this doesn't work I'll ask > Brad K. for help. It'll be later this morning when I can back to it; I've > got some writing assignments and tcons to contend with this morning. > > W > > On Fri, Mar 6, 2015 at 8:33 AM, Bill Lorensen > wrote: > >> Will, >> >> In each of the SMP implementations (FlyEdges, Splatters, SampleFunction), >> if I remove the class name qualifier from each use of a member >> function, they compile >> >> for example: >> vtkFlyingEdges3DAlgorithm::Pass1 pass1(&algo,value); >> change to >> Pass1 pass1(&algo,value); >> >> and likewise through all of the other similar declarations. >> >> Bill >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> > > > > -- > William J. Schroeder, PhD > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Fri Mar 6 09:18:16 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Fri, 6 Mar 2015 09:18:16 -0500 Subject: [vtk-developers] SMP algorithm errors on Mac In-Reply-To: References: Message-ID: Cool thanks! On Fri, Mar 6, 2015 at 9:09 AM, Bill Lorensen wrote: > I just submitted a gerrit topic. > On Mar 6, 2015 8:47 AM, "Will Schroeder" > wrote: > >> Okay how about I make another round of edits to SampleFunction and push >> it in through gerrit (assuming it compiles on my windows box -- I'm worried >> that it won't compile on other systems). And if this doesn't work I'll ask >> Brad K. for help. It'll be later this morning when I can back to it; I've >> got some writing assignments and tcons to contend with this morning. >> >> W >> >> On Fri, Mar 6, 2015 at 8:33 AM, Bill Lorensen >> wrote: >> >>> Will, >>> >>> In each of the SMP implementations (FlyEdges, Splatters, SampleFunction), >>> if I remove the class name qualifier from each use of a member >>> function, they compile >>> >>> for example: >>> vtkFlyingEdges3DAlgorithm::Pass1 pass1(&algo,value); >>> change to >>> Pass1 pass1(&algo,value); >>> >>> and likewise through all of the other similar declarations. >>> >>> Bill >>> >>> -- >>> Unpaid intern in BillsBasement at noware dot com >>> >> >> >> >> -- >> William J. Schroeder, PhD >> Kitware, Inc. >> 28 Corporate Drive >> Clifton Park, NY 12065 >> will.schroeder at kitware.com >> http://www.kitware.com >> (518) 881-4902 >> > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Fri Mar 6 10:12:22 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 6 Mar 2015 10:12:22 -0500 Subject: [vtk-developers] SMP algorithm errors on Mac In-Reply-To: References: Message-ID: All platforms compiled and ran tests. I merged my sample function topic. Will, If you make similar changes to the splatter and fly edge topics, I'll try them on my Mac. Bill On Fri, Mar 6, 2015 at 9:18 AM, Will Schroeder wrote: > Cool thanks! > > On Fri, Mar 6, 2015 at 9:09 AM, Bill Lorensen > wrote: >> >> I just submitted a gerrit topic. >> >> On Mar 6, 2015 8:47 AM, "Will Schroeder" >> wrote: >>> >>> Okay how about I make another round of edits to SampleFunction and push >>> it in through gerrit (assuming it compiles on my windows box -- I'm worried >>> that it won't compile on other systems). And if this doesn't work I'll ask >>> Brad K. for help. It'll be later this morning when I can back to it; I've >>> got some writing assignments and tcons to contend with this morning. >>> >>> W >>> >>> On Fri, Mar 6, 2015 at 8:33 AM, Bill Lorensen >>> wrote: >>>> >>>> Will, >>>> >>>> In each of the SMP implementations (FlyEdges, Splatters, >>>> SampleFunction), >>>> if I remove the class name qualifier from each use of a member >>>> function, they compile >>>> >>>> for example: >>>> vtkFlyingEdges3DAlgorithm::Pass1 pass1(&algo,value); >>>> change to >>>> Pass1 pass1(&algo,value); >>>> >>>> and likewise through all of the other similar declarations. >>>> >>>> Bill >>>> >>>> -- >>>> Unpaid intern in BillsBasement at noware dot com >>> >>> >>> >>> >>> -- >>> William J. Schroeder, PhD >>> Kitware, Inc. >>> 28 Corporate Drive >>> Clifton Park, NY 12065 >>> will.schroeder at kitware.com >>> http://www.kitware.com >>> (518) 881-4902 > > > > > -- > William J. Schroeder, PhD > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 -- Unpaid intern in BillsBasement at noware dot com From will.schroeder at kitware.com Fri Mar 6 10:13:54 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Fri, 6 Mar 2015 10:13:54 -0500 Subject: [vtk-developers] SMP algorithm errors on Mac In-Reply-To: References: Message-ID: Cool and thanks for your help. I'll get to this ASAP. Lot's going on but I should have it done by the end of the weekend. W On Fri, Mar 6, 2015 at 10:12 AM, Bill Lorensen wrote: > All platforms compiled and ran tests. I merged my sample function topic. > > Will, > > If you make similar changes to the splatter and fly edge topics, I'll > try them on my Mac. > > Bill > > > On Fri, Mar 6, 2015 at 9:18 AM, Will Schroeder > wrote: > > Cool thanks! > > > > On Fri, Mar 6, 2015 at 9:09 AM, Bill Lorensen > > wrote: > >> > >> I just submitted a gerrit topic. > >> > >> On Mar 6, 2015 8:47 AM, "Will Schroeder" > >> wrote: > >>> > >>> Okay how about I make another round of edits to SampleFunction and push > >>> it in through gerrit (assuming it compiles on my windows box -- I'm > worried > >>> that it won't compile on other systems). And if this doesn't work I'll > ask > >>> Brad K. for help. It'll be later this morning when I can back to it; > I've > >>> got some writing assignments and tcons to contend with this morning. > >>> > >>> W > >>> > >>> On Fri, Mar 6, 2015 at 8:33 AM, Bill Lorensen > > >>> wrote: > >>>> > >>>> Will, > >>>> > >>>> In each of the SMP implementations (FlyEdges, Splatters, > >>>> SampleFunction), > >>>> if I remove the class name qualifier from each use of a member > >>>> function, they compile > >>>> > >>>> for example: > >>>> vtkFlyingEdges3DAlgorithm::Pass1 pass1(&algo,value); > >>>> change to > >>>> Pass1 pass1(&algo,value); > >>>> > >>>> and likewise through all of the other similar declarations. > >>>> > >>>> Bill > >>>> > >>>> -- > >>>> Unpaid intern in BillsBasement at noware dot com > >>> > >>> > >>> > >>> > >>> -- > >>> William J. Schroeder, PhD > >>> Kitware, Inc. > >>> 28 Corporate Drive > >>> Clifton Park, NY 12065 > >>> will.schroeder at kitware.com > >>> http://www.kitware.com > >>> (518) 881-4902 > > > > > > > > > > -- > > William J. Schroeder, PhD > > Kitware, Inc. > > 28 Corporate Drive > > Clifton Park, NY 12065 > > will.schroeder at kitware.com > > http://www.kitware.com > > (518) 881-4902 > > > > -- > Unpaid intern in BillsBasement at noware dot com > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Fri Mar 6 10:33:46 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 6 Mar 2015 10:33:46 -0500 Subject: [vtk-developers] SMP algorithm errors on Mac In-Reply-To: References: Message-ID: Will, I have a topic ready to push that fixes the vtkCheckerboardSplatter compile issue for the Mac. If it's OK with you, I'll push it to gerrit as a mod to your topic. Bill On Fri, Mar 6, 2015 at 10:13 AM, Will Schroeder wrote: > Cool and thanks for your help. I'll get to this ASAP. Lot's going on but I > should have it done by the end of the weekend. > W > > On Fri, Mar 6, 2015 at 10:12 AM, Bill Lorensen > wrote: >> >> All platforms compiled and ran tests. I merged my sample function topic. >> >> Will, >> >> If you make similar changes to the splatter and fly edge topics, I'll >> try them on my Mac. >> >> Bill >> >> >> On Fri, Mar 6, 2015 at 9:18 AM, Will Schroeder >> wrote: >> > Cool thanks! >> > >> > On Fri, Mar 6, 2015 at 9:09 AM, Bill Lorensen >> > wrote: >> >> >> >> I just submitted a gerrit topic. >> >> >> >> On Mar 6, 2015 8:47 AM, "Will Schroeder" >> >> wrote: >> >>> >> >>> Okay how about I make another round of edits to SampleFunction and >> >>> push >> >>> it in through gerrit (assuming it compiles on my windows box -- I'm >> >>> worried >> >>> that it won't compile on other systems). And if this doesn't work I'll >> >>> ask >> >>> Brad K. for help. It'll be later this morning when I can back to it; >> >>> I've >> >>> got some writing assignments and tcons to contend with this morning. >> >>> >> >>> W >> >>> >> >>> On Fri, Mar 6, 2015 at 8:33 AM, Bill Lorensen >> >>> >> >>> wrote: >> >>>> >> >>>> Will, >> >>>> >> >>>> In each of the SMP implementations (FlyEdges, Splatters, >> >>>> SampleFunction), >> >>>> if I remove the class name qualifier from each use of a member >> >>>> function, they compile >> >>>> >> >>>> for example: >> >>>> vtkFlyingEdges3DAlgorithm::Pass1 pass1(&algo,value); >> >>>> change to >> >>>> Pass1 pass1(&algo,value); >> >>>> >> >>>> and likewise through all of the other similar declarations. >> >>>> >> >>>> Bill >> >>>> >> >>>> -- >> >>>> Unpaid intern in BillsBasement at noware dot com >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> William J. Schroeder, PhD >> >>> Kitware, Inc. >> >>> 28 Corporate Drive >> >>> Clifton Park, NY 12065 >> >>> will.schroeder at kitware.com >> >>> http://www.kitware.com >> >>> (518) 881-4902 >> > >> > >> > >> > >> > -- >> > William J. Schroeder, PhD >> > Kitware, Inc. >> > 28 Corporate Drive >> > Clifton Park, NY 12065 >> > will.schroeder at kitware.com >> > http://www.kitware.com >> > (518) 881-4902 >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com > > > > > -- > William J. Schroeder, PhD > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 -- Unpaid intern in BillsBasement at noware dot com From will.schroeder at kitware.com Fri Mar 6 10:35:47 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Fri, 6 Mar 2015 10:35:47 -0500 Subject: [vtk-developers] SMP algorithm errors on Mac In-Reply-To: References: Message-ID: Man you are on a roll. Please push this in and thanks again. When the heck are you going to Santa Cruz so I can get a rest? ;-) W On Fri, Mar 6, 2015 at 10:33 AM, Bill Lorensen wrote: > Will, > > I have a topic ready to push that fixes the vtkCheckerboardSplatter > compile issue for the Mac. If it's OK with you, I'll push it to gerrit > as a mod to your topic. > > Bill > > > On Fri, Mar 6, 2015 at 10:13 AM, Will Schroeder > wrote: > > Cool and thanks for your help. I'll get to this ASAP. Lot's going on but > I > > should have it done by the end of the weekend. > > W > > > > On Fri, Mar 6, 2015 at 10:12 AM, Bill Lorensen > > wrote: > >> > >> All platforms compiled and ran tests. I merged my sample function topic. > >> > >> Will, > >> > >> If you make similar changes to the splatter and fly edge topics, I'll > >> try them on my Mac. > >> > >> Bill > >> > >> > >> On Fri, Mar 6, 2015 at 9:18 AM, Will Schroeder > >> wrote: > >> > Cool thanks! > >> > > >> > On Fri, Mar 6, 2015 at 9:09 AM, Bill Lorensen < > bill.lorensen at gmail.com> > >> > wrote: > >> >> > >> >> I just submitted a gerrit topic. > >> >> > >> >> On Mar 6, 2015 8:47 AM, "Will Schroeder" > > >> >> wrote: > >> >>> > >> >>> Okay how about I make another round of edits to SampleFunction and > >> >>> push > >> >>> it in through gerrit (assuming it compiles on my windows box -- I'm > >> >>> worried > >> >>> that it won't compile on other systems). And if this doesn't work > I'll > >> >>> ask > >> >>> Brad K. for help. It'll be later this morning when I can back to it; > >> >>> I've > >> >>> got some writing assignments and tcons to contend with this morning. > >> >>> > >> >>> W > >> >>> > >> >>> On Fri, Mar 6, 2015 at 8:33 AM, Bill Lorensen > >> >>> > >> >>> wrote: > >> >>>> > >> >>>> Will, > >> >>>> > >> >>>> In each of the SMP implementations (FlyEdges, Splatters, > >> >>>> SampleFunction), > >> >>>> if I remove the class name qualifier from each use of a member > >> >>>> function, they compile > >> >>>> > >> >>>> for example: > >> >>>> vtkFlyingEdges3DAlgorithm::Pass1 pass1(&algo,value); > >> >>>> change to > >> >>>> Pass1 pass1(&algo,value); > >> >>>> > >> >>>> and likewise through all of the other similar declarations. > >> >>>> > >> >>>> Bill > >> >>>> > >> >>>> -- > >> >>>> Unpaid intern in BillsBasement at noware dot com > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> William J. Schroeder, PhD > >> >>> Kitware, Inc. > >> >>> 28 Corporate Drive > >> >>> Clifton Park, NY 12065 > >> >>> will.schroeder at kitware.com > >> >>> http://www.kitware.com > >> >>> (518) 881-4902 > >> > > >> > > >> > > >> > > >> > -- > >> > William J. Schroeder, PhD > >> > Kitware, Inc. > >> > 28 Corporate Drive > >> > Clifton Park, NY 12065 > >> > will.schroeder at kitware.com > >> > http://www.kitware.com > >> > (518) 881-4902 > >> > >> > >> > >> -- > >> Unpaid intern in BillsBasement at noware dot com > > > > > > > > > > -- > > William J. Schroeder, PhD > > Kitware, Inc. > > 28 Corporate Drive > > Clifton Park, NY 12065 > > will.schroeder at kitware.com > > http://www.kitware.com > > (518) 881-4902 > > > > -- > Unpaid intern in BillsBasement at noware dot com > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Fri Mar 6 10:46:30 2015 From: sean at rogue-research.com (Sean McBride) Date: Fri, 6 Mar 2015 10:46:30 -0500 Subject: [vtk-developers] cppcheck of VTK Message-ID: <20150306154631.1531522798@mail.rogue-research.com> Hi all, After hacking at cppcheck warnings on and off for a long time, I now have a suppression file that I'd like to commit so that dashboards can use it to run cppcheck nightly. Is putting it adjacent to the valgrind suppression file reasonable? ie in VTK/CMake. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From sean at rogue-research.com Fri Mar 6 10:50:31 2015 From: sean at rogue-research.com (Sean McBride) Date: Fri, 6 Mar 2015 10:50:31 -0500 Subject: [vtk-developers] [PATCH] MetaIO cppcheck fixes Message-ID: <20150306155031.1774182264@mail.rogue-research.com> Hi all, I know gerrit won't accept MetaIO changes, and I forget the procedure for it, so I'm attaching two trivial patches. Can someone review & merge please? BTW: might be good to mention the MetaIO special case here: (It does mention KWSys already.) Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fixed-memory-leak-in-error-paths.patch Type: application/octet-stream Size: 1913 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fixed-minor-printf-format-specifier-mismatch.patch Type: application/octet-stream Size: 1602 bytes Desc: not available URL: From bill.lorensen at gmail.com Fri Mar 6 11:47:13 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 6 Mar 2015 11:47:13 -0500 Subject: [vtk-developers] SMP algorithm errors on Mac In-Reply-To: References: Message-ID: Will, One final topic. I'll push fixes to the flying edge code as soon as my local build completes. Bill On Fri, Mar 6, 2015 at 10:35 AM, Will Schroeder wrote: > Man you are on a roll. Please push this in and thanks again. When the heck > are you going to Santa Cruz so I can get a rest? ;-) > W > > On Fri, Mar 6, 2015 at 10:33 AM, Bill Lorensen > wrote: >> >> Will, >> >> I have a topic ready to push that fixes the vtkCheckerboardSplatter >> compile issue for the Mac. If it's OK with you, I'll push it to gerrit >> as a mod to your topic. >> >> Bill >> >> >> On Fri, Mar 6, 2015 at 10:13 AM, Will Schroeder >> wrote: >> > Cool and thanks for your help. I'll get to this ASAP. Lot's going on but >> > I >> > should have it done by the end of the weekend. >> > W >> > >> > On Fri, Mar 6, 2015 at 10:12 AM, Bill Lorensen >> > wrote: >> >> >> >> All platforms compiled and ran tests. I merged my sample function >> >> topic. >> >> >> >> Will, >> >> >> >> If you make similar changes to the splatter and fly edge topics, I'll >> >> try them on my Mac. >> >> >> >> Bill >> >> >> >> >> >> On Fri, Mar 6, 2015 at 9:18 AM, Will Schroeder >> >> wrote: >> >> > Cool thanks! >> >> > >> >> > On Fri, Mar 6, 2015 at 9:09 AM, Bill Lorensen >> >> > >> >> > wrote: >> >> >> >> >> >> I just submitted a gerrit topic. >> >> >> >> >> >> On Mar 6, 2015 8:47 AM, "Will Schroeder" >> >> >> >> >> >> wrote: >> >> >>> >> >> >>> Okay how about I make another round of edits to SampleFunction and >> >> >>> push >> >> >>> it in through gerrit (assuming it compiles on my windows box -- I'm >> >> >>> worried >> >> >>> that it won't compile on other systems). And if this doesn't work >> >> >>> I'll >> >> >>> ask >> >> >>> Brad K. for help. It'll be later this morning when I can back to >> >> >>> it; >> >> >>> I've >> >> >>> got some writing assignments and tcons to contend with this >> >> >>> morning. >> >> >>> >> >> >>> W >> >> >>> >> >> >>> On Fri, Mar 6, 2015 at 8:33 AM, Bill Lorensen >> >> >>> >> >> >>> wrote: >> >> >>>> >> >> >>>> Will, >> >> >>>> >> >> >>>> In each of the SMP implementations (FlyEdges, Splatters, >> >> >>>> SampleFunction), >> >> >>>> if I remove the class name qualifier from each use of a member >> >> >>>> function, they compile >> >> >>>> >> >> >>>> for example: >> >> >>>> vtkFlyingEdges3DAlgorithm::Pass1 pass1(&algo,value); >> >> >>>> change to >> >> >>>> Pass1 pass1(&algo,value); >> >> >>>> >> >> >>>> and likewise through all of the other similar declarations. >> >> >>>> >> >> >>>> Bill >> >> >>>> >> >> >>>> -- >> >> >>>> Unpaid intern in BillsBasement at noware dot com >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> William J. Schroeder, PhD >> >> >>> Kitware, Inc. >> >> >>> 28 Corporate Drive >> >> >>> Clifton Park, NY 12065 >> >> >>> will.schroeder at kitware.com >> >> >>> http://www.kitware.com >> >> >>> (518) 881-4902 >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > William J. Schroeder, PhD >> >> > Kitware, Inc. >> >> > 28 Corporate Drive >> >> > Clifton Park, NY 12065 >> >> > will.schroeder at kitware.com >> >> > http://www.kitware.com >> >> > (518) 881-4902 >> >> >> >> >> >> >> >> -- >> >> Unpaid intern in BillsBasement at noware dot com >> > >> > >> > >> > >> > -- >> > William J. Schroeder, PhD >> > Kitware, Inc. >> > 28 Corporate Drive >> > Clifton Park, NY 12065 >> > will.schroeder at kitware.com >> > http://www.kitware.com >> > (518) 881-4902 >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com > > > > > -- > William J. Schroeder, PhD > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 -- Unpaid intern in BillsBasement at noware dot com From ben.boeckel at kitware.com Fri Mar 6 12:40:11 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 6 Mar 2015 12:40:11 -0500 Subject: [vtk-developers] [PATCH] MetaIO cppcheck fixes In-Reply-To: <20150306155031.1774182264@mail.rogue-research.com> References: <20150306155031.1774182264@mail.rogue-research.com> Message-ID: <20150306174011.GA30554@megas.kitwarein.com> On Fri, Mar 06, 2015 at 10:50:31 -0500, Sean McBride wrote: > I know gerrit won't accept MetaIO changes, and I forget the procedure > for it, so I'm attaching two trivial patches. Can someone review & > merge please? Pull requests accepted here: https://github.com/Kitware/metaio > BTW: might be good to mention the MetaIO special case here: > > (It does mention KWSys already.) Done. --Ben From sean at rogue-research.com Fri Mar 6 13:08:12 2015 From: sean at rogue-research.com (Sean McBride) Date: Fri, 6 Mar 2015 13:08:12 -0500 Subject: [vtk-developers] [PATCH] MetaIO cppcheck fixes In-Reply-To: <20150306174011.GA30554@megas.kitwarein.com> References: <20150306155031.1774182264@mail.rogue-research.com> <20150306174011.GA30554@megas.kitwarein.com> Message-ID: <20150306180812.1514469156@mail.rogue-research.com> On Fri, 6 Mar 2015 12:40:11 -0500, Ben Boeckel said: >On Fri, Mar 06, 2015 at 10:50:31 -0500, Sean McBride wrote: >> I know gerrit won't accept MetaIO changes, and I forget the procedure >> for it, so I'm attaching two trivial patches. Can someone review & >> merge please? > >Pull requests accepted here: > > https://github.com/Kitware/metaio > >> BTW: might be good to mention the MetaIO special case here: >> >> (It does mention KWSys already.) > >Done. Thanks. I'll certainly use that in the future. Given that I've already made .patch files, is there a way you could just merge them in? Or is there a simple way I can convert my patch files to a github pull request? Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From dave.demarle at kitware.com Fri Mar 6 13:12:48 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Fri, 6 Mar 2015 13:12:48 -0500 Subject: [vtk-developers] [PATCH] MetaIO cppcheck fixes In-Reply-To: <20150306180812.1514469156@mail.rogue-research.com> References: <20150306155031.1774182264@mail.rogue-research.com> <20150306174011.GA30554@megas.kitwarein.com> <20150306180812.1514469156@mail.rogue-research.com> Message-ID: Ben, Do we have a semi-automated procedure to do the submodule import dance yet for updating VTK's copy of MetaIO? Bonus points if it works with the other ThirdPartyLibraries like hdf5, netcdf, xdmf etc. cheers David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Fri, Mar 6, 2015 at 1:08 PM, Sean McBride wrote: > On Fri, 6 Mar 2015 12:40:11 -0500, Ben Boeckel said: > > >On Fri, Mar 06, 2015 at 10:50:31 -0500, Sean McBride wrote: > >> I know gerrit won't accept MetaIO changes, and I forget the procedure > >> for it, so I'm attaching two trivial patches. Can someone review & > >> merge please? > > > >Pull requests accepted here: > > > > https://github.com/Kitware/metaio > > > >> BTW: might be good to mention the MetaIO special case here: > >> > >> (It does mention KWSys already.) > > > >Done. > > Thanks. I'll certainly use that in the future. Given that I've already > made .patch files, is there a way you could just merge them in? Or is > there a simple way I can convert my patch files to a github pull request? > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Fri Mar 6 13:40:04 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 6 Mar 2015 13:40:04 -0500 Subject: [vtk-developers] [PATCH] MetaIO cppcheck fixes In-Reply-To: References: <20150306155031.1774182264@mail.rogue-research.com> <20150306174011.GA30554@megas.kitwarein.com> <20150306180812.1514469156@mail.rogue-research.com> Message-ID: <20150306184004.GB906@megas.kitwarein.com> On Fri, Mar 06, 2015 at 13:12:48 -0500, David E DeMarle wrote: > Do we have a semi-automated procedure to do the submodule import dance yet > for updating VTK's copy of MetaIO? Bonus points if it works with the other > ThirdPartyLibraries like hdf5, netcdf, xdmf etc. The commands usually appear in the merge commit, but I think the answer is "kwrobot magic" for kwsys and metaio. We will need to figure out something with the new gitlab workflow. --Ben From sean at rogue-research.com Tue Mar 10 16:22:11 2015 From: sean at rogue-research.com (Sean McBride) Date: Tue, 10 Mar 2015 16:22:11 -0400 Subject: [vtk-developers] ANNOUNCE: vtk 6.2.0 is ready! In-Reply-To: References: Message-ID: <20150310202211.1877875843@mail.rogue-research.com> On Thu, 5 Mar 2015 11:09:04 -0500, David E DeMarle said: >http://www.vtk.org/VTK/resources/software.html It still shows "git tag: "v6.2.0.rc1"" in the "Latest Release" section... Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From dave.demarle at kitware.com Tue Mar 10 16:28:54 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 10 Mar 2015 16:28:54 -0400 Subject: [vtk-developers] ANNOUNCE: vtk 6.2.0 is ready! In-Reply-To: <20150310202211.1877875843@mail.rogue-research.com> References: <20150310202211.1877875843@mail.rogue-research.com> Message-ID: No it doesn't. //anymore thanks David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Mar 10, 2015 at 4:22 PM, Sean McBride wrote: > On Thu, 5 Mar 2015 11:09:04 -0500, David E DeMarle said: > > >http://www.vtk.org/VTK/resources/software.html > > It still shows "git tag: "v6.2.0.rc1"" in the "Latest Release" section... > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Wed Mar 11 14:27:43 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 11 Mar 2015 14:27:43 -0400 Subject: [vtk-developers] Adding support for a macro in wrapper Message-ID: Hi folks, How difficult is it to add support for a macro, similar to vtkTypeMacro, to the wrappers? Is this documented somewhere, or can someone give me a quick rundown? Some background: I'm in the process of deprecating virtual double* vtkProp::GetBounds(); to favor a new signature virtual bool vtkProp::GetBounds(vtkViewport *, double[6]); This is a major change that touches a lot of classes, plus it introduces an overloaded signature to a virtual. This means that every subclass of vtkProp that implements GetBounds will need to define the deprecated signature so that it won't be hidden in legacy applications. Since this change affects a *lot* of code, I want to add a default implementation to a macro that forwards the call, sets up the deprecation flags, and implements the runtime warning. This approach is working so far, except that the wrappers don't know how to handle my macro. Thanks! Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Mar 11 14:49:27 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 11 Mar 2015 14:49:27 -0400 Subject: [vtk-developers] Adding support for a macro in wrapper In-Reply-To: References: Message-ID: <20150311184927.GB11496@megas.kitwarein.com> On Wed, Mar 11, 2015 at 14:27:43 -0400, David Lonie wrote: > I'm in the process of deprecating > > virtual double* vtkProp::GetBounds(); > > to favor a new signature > > virtual bool vtkProp::GetBounds(vtkViewport *, double[6]); > > This is a major change that touches a lot of classes, plus it introduces an > overloaded signature to a virtual. This means that every subclass of > vtkProp that implements GetBounds will need to define the deprecated > signature so that it won't be hidden in legacy applications. The solution is to do: using SuperClass::GetBounds; where GetBounds is reimplemented to "import" the subclass' overloads not reimplemented here. --Ben From david.lonie at kitware.com Wed Mar 11 14:51:51 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 11 Mar 2015 14:51:51 -0400 Subject: [vtk-developers] Adding support for a macro in wrapper In-Reply-To: <20150311184927.GB11496@megas.kitwarein.com> References: <20150311184927.GB11496@megas.kitwarein.com> Message-ID: On Wed, Mar 11, 2015 at 2:49 PM, Ben Boeckel wrote: > On Wed, Mar 11, 2015 at 14:27:43 -0400, David Lonie wrote: > > I'm in the process of deprecating > > > > virtual double* vtkProp::GetBounds(); > > > > to favor a new signature > > > > virtual bool vtkProp::GetBounds(vtkViewport *, double[6]); > > > > This is a major change that touches a lot of classes, plus it introduces > an > > overloaded signature to a virtual. This means that every subclass of > > vtkProp that implements GetBounds will need to define the deprecated > > signature so that it won't be hidden in legacy applications. > > The solution is to do: > > using SuperClass::GetBounds; > > where GetBounds is reimplemented to "import" the subclass' overloads not > reimplemented here. > D'oh! Forgot about that. Now let's see if the wrappers understand such things... ;) Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Wed Mar 11 15:09:57 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Wed, 11 Mar 2015 15:09:57 -0400 Subject: [vtk-developers] Migrating Git repository to Gitlab In-Reply-To: References: Message-ID: Folks, We are getting ever closer to making this move to Gitlab. If all goes well, the move will happen on Monday, March 16th. More details on what the development workflow looks like after this migration will be coming out soon. Behind the scenes, Brad and Ben have been working tirelessly to update the SetupForDevelopment scripts and documentation among other things, like uploads for testing data/baselines etc. As a consequence, all that this boils down to is to checkout VTK from the new Git URL, and run SetupForDevelopment script. In the mean time, there's not much to do. You may want to consider cleaning up any old gerrit topics, either getting them review/merged or abandoning them. The Gerrit instance will remain accessible for a while so you can still get to the changes you made to be able to move them manually to Gitlab for review in the new workflow. Dashboard maintainers, be prepared to change the Git URL for your dashboards on Monday. Last, but not the least, thanks for your patience so far and following the migration as we iron out any remaining kinks! Utkarsh On Mon, Mar 2, 2015 at 10:03 AM, Utkarsh Ayachit wrote: > Folks, > > In August 2014, there was a discussion on the mailing list [1] about development > workflows. A conclusion of that conversation was that we will look at a > Github-like approach to make contributing easier. The time has come to act on > those discussions, and we will outline plans to do that below. > > Since those initial discussions developers at Kitware have been evaluating > Github and Github clones to see what would work for our projects, including the > large ones like ParaView and VTK. Here is a summary of that evaluation and the > proposed plan. > > * We have settled on using Gitlab (an open source Github clone) as the platform > for hosting the official repositories. There are several advantages to using a > self-hosted Gitlab instance, including support for customized server-side > hooks. > * Gitlab is very Github-like. Thus we can use Gitlab for code-review instead of > Gerrit. For simplicity, let?s call this Kitware hosted instance of Gitlab, > KWGitlab. > * For VTK, we can use what is commonly called a *Forking Workflow* [2,3]. > Essentially, developers can create a fork of the VTK repository on KWGitlab. > They can then create branches on their fork to develop new features or bug > fixes. They can publish their branches to the world on their personal forks. > Once developers are ready to merge that change into VTK, they go to the > KWGitlab web application and create a *Merge Request*. Once a merge request is > made, we can use testing infrastructure to run dashboards on the merge request > (similar to what we currently do for Gerrit). We can decide on a convention as > to what constitutes an approval of the merge request. Once approved, the merge > request can be ?accepted? and merged into the master repo. > * Gitlab provides a nicer UI for inspecting changes and posting comments etc, as > compared with Gerrit, and one that would be familiar to many Github users. > Reviewing code will be easier, especially for topic branches with a number of > commits. Attached are a few miscellaneous screenshots from the Gitlab instance > we're testing out internally. > * For testing we have been experimenting with Buildbot to act as the scheduler > that triggers a dashboard run when an ?authenticated? merge-request is > received and ready for testing. Authenticated could mean something like the > following: > - The merge request has a specific label e.g. ?do-tests? AND > - The merge request was created by a user registered as a VTK developer OR > - A VTK developer has made a specific comment to trigger the builds. > We can set up a few buildbot-slaves to test merge requests in addition to the > traditional continuous and nightly testing. > > We will endeavor to make these changes as painless as possible, but ask that you > bear with us as we make the transition. We will flesh out low-level details for > contributing changes, dealing with conflicts, and so forth. > > Q&A > === > > 1. What is the timeline? > We are testing this out internally right now. There are a few things that > need to be ironed out like managing ExternalData, updating > SetupforDevelopment.sh, updating documentation etc. Once VTK 6.2 is out the > door, we plan to go live with this initiative. This needs to happen by April > 20th, since Google stops supporting OpenID 2.0 [4] then and our current > instance of Gerrit (with patches to support topic branches) uses OpenID 2.0. > Thus VTK gerrit users will not be able to sign in to Gerrit after April 20th. > > 2. Does the git url for checking out VTK change? > Yes. The git url will indeed change. The current plan is to abandon the old > URL to avoid confusion. > > 3. What happens to the Github clone of VTK? > That will continue as before. We will keep the Github clone updated as > earlier. Eventually, we can start accepting pull requests on Github that can > then be migrated to KWGitlab for testing/merging. > > 4. Are we also moving the bug tracker? > The general consensus is that it will indeed be nice to start using the > integrated issue tracker in Gitlab instead of the separate Mantis bug tracker. > As a first pass however, let?s keep the changes limited. Once we have all > settled in to using Gitlab we can start a separate thread to discuss how the > bug tracker evolves. > > 5. Do I have to update all my dashboards? > For most part, the only thing that needs to change on the dashboards is where > the checkout VTK from. We are currently testing a Buildbot+CDash-based > exhaustive testing model for ParaView to test individual merge requests. > We?ll post details on how that experiment goes and then we can decide how VTK > testing infrastructure can be expanded in time. We will certainly migrate the > current Gerrit topic testing machines to test merge requests either using > CDash at Home or Buildbot when all this goes live. > > [1] http://public.kitware.com/pipermail/vtk-developers/2014-August/030755.html > [2] https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow > [3] https://guides.github.com/introduction/flow/ > [4] https://developers.google.com/accounts/docs/OpenID From sean at rogue-research.com Wed Mar 11 15:19:48 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 11 Mar 2015 15:19:48 -0400 Subject: [vtk-developers] Migrating Git repository to Gitlab In-Reply-To: References: Message-ID: <20150311191948.1430865736@mail.rogue-research.com> On Wed, 11 Mar 2015 15:09:57 -0400, Utkarsh Ayachit said: >In the mean time, there's not much to do. You may want to consider >cleaning up any old gerrit topics, either getting them review/merged >or abandoning them. What's the magic to see all my unmerged gerrit thingies? Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From david.gobbi at gmail.com Wed Mar 11 15:21:04 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 11 Mar 2015 13:21:04 -0600 Subject: [vtk-developers] Adding support for a macro in wrapper In-Reply-To: References: <20150311184927.GB11496@megas.kitwarein.com> Message-ID: Hi David, The wrappers understand but ignore the "using" directive. So, yeah, wrapper changes would be needed to support it. For example, I have wrapper code on github that pulls in the header files for all the superclasses so that it can link used methods from the superclass namespace. What was your original macro? In general, the wrappers should be able to handle most macros without any problems. - David On Wed, Mar 11, 2015 at 12:51 PM, David Lonie wrote: > On Wed, Mar 11, 2015 at 2:49 PM, Ben Boeckel > wrote: > >> On Wed, Mar 11, 2015 at 14:27:43 -0400, David Lonie wrote: >> > I'm in the process of deprecating >> > >> > virtual double* vtkProp::GetBounds(); >> > >> > to favor a new signature >> > >> > virtual bool vtkProp::GetBounds(vtkViewport *, double[6]); >> > >> > This is a major change that touches a lot of classes, plus it >> introduces an >> > overloaded signature to a virtual. This means that every subclass of >> > vtkProp that implements GetBounds will need to define the deprecated >> > signature so that it won't be hidden in legacy applications. >> >> The solution is to do: >> >> using SuperClass::GetBounds; >> >> where GetBounds is reimplemented to "import" the subclass' overloads not >> reimplemented here. >> > > D'oh! Forgot about that. Now let's see if the wrappers understand such > things... ;) > > Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Wed Mar 11 15:23:52 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 11 Mar 2015 15:23:52 -0400 Subject: [vtk-developers] Migrating Git repository to Gitlab In-Reply-To: <20150311191948.1430865736@mail.rogue-research.com> References: <20150311191948.1430865736@mail.rogue-research.com> Message-ID: entity:change owner:"YOUR NAME HERE" status:open entity:topic owner:"YOUR NAME HERE" status:open entity:change reviewer:"YOUR NAME HERE" status:open entity:topic reviewer:"YOUR NAME HERE" status:open David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Mar 11, 2015 at 3:19 PM, Sean McBride wrote: > On Wed, 11 Mar 2015 15:09:57 -0400, Utkarsh Ayachit said: > > >In the mean time, there's not much to do. You may want to consider > >cleaning up any old gerrit topics, either getting them review/merged > >or abandoning them. > > What's the magic to see all my unmerged gerrit thingies? > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Wed Mar 11 15:25:40 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 11 Mar 2015 15:25:40 -0400 Subject: [vtk-developers] Adding support for a macro in wrapper In-Reply-To: References: <20150311184927.GB11496@megas.kitwarein.com> Message-ID: On Wed, Mar 11, 2015 at 3:21 PM, David Gobbi wrote: > Hi David, > > The wrappers understand but ignore the "using" directive. So, yeah, > wrapper > changes would be needed to support it. For example, I have wrapper code on > github that pulls in the header files for all the superclasses so that it > can link > used methods from the superclass namespace. > > What was your original macro? In general, the wrappers should be able to > handle most macros without any problems. > I've actually already stripped it out in favor of the much simpler "using" method. Good to know that simple macros should work -- it's entirely possible there was some little bug hidden in my macro that was throwing off the wrappers ;) Perhaps it was the pattern: VTK_LEGACY(virtual double* GetBounds()) \ { \ ... \ } that was causing confusion? I'm not sure if the VTK_LEGACY macro should be used with an inline definition... Anyway, it looks like this is all working now :) Thanks for the replies! Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Mar 11 15:46:00 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 11 Mar 2015 13:46:00 -0600 Subject: [vtk-developers] Adding support for a macro in wrapper In-Reply-To: References: <20150311184927.GB11496@megas.kitwarein.com> Message-ID: On Wed, Mar 11, 2015 at 1:25 PM, David Lonie wrote: > > > I've actually already stripped it out in favor of the much simpler "using" > method. Good to know that simple macros should work -- it's entirely > possible there was some little bug hidden in my macro that was throwing off > the wrappers ;) > > Perhaps it was the pattern: > > VTK_LEGACY(virtual double* GetBounds()) \ > { \ > ... \ > } > It's possible... VTK_LEGACY undergoes special handling by the wrappers, it isn't simply expanded. I'd still like to see the full macro plus its usage so that I can find out why the wrappers had trouble with it. > Anyway, it looks like this is all working now :) Thanks for the replies! > The old GetBounds() method might be hidden in the wrapped classes due to "using" being ignored. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Wed Mar 11 15:47:34 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 11 Mar 2015 15:47:34 -0400 Subject: [vtk-developers] Adding support for a macro in wrapper In-Reply-To: References: <20150311184927.GB11496@megas.kitwarein.com> Message-ID: On Wed, Mar 11, 2015 at 3:46 PM, David Gobbi wrote: > On Wed, Mar 11, 2015 at 1:25 PM, David Lonie > wrote: >> >> >> I've actually already stripped it out in favor of the much simpler >> "using" method. Good to know that simple macros should work -- it's >> entirely possible there was some little bug hidden in my macro that was >> throwing off the wrappers ;) >> >> Perhaps it was the pattern: >> >> VTK_LEGACY(virtual double* GetBounds()) \ >> { \ >> ... \ >> } >> > > It's possible... VTK_LEGACY undergoes special handling by the wrappers, it > isn't simply expanded. I'd still like to see the full macro plus its usage > so that I can find out why the wrappers had trouble with it. > > >> Anyway, it looks like this is all working now :) Thanks for the replies! >> > > The old GetBounds() method might be hidden in the wrapped classes due to > "using" being ignored. > I'll be sure to test this before I merge -- thanks for the heads up. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Wed Mar 11 16:12:47 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 11 Mar 2015 16:12:47 -0400 Subject: [vtk-developers] Pitch for Google Summer of Code topics Message-ID: Hi folks, I wanted to make a pitch for the Google Summer of Code topics listed below. Better support for shared-memory parallelism is essential for a healthy VTK for many years to come. If you are a student, please consider writing a proposal for one of these topics. If you are a professor/mentor, please encourage strong developers in your institution to apply. Best, -berk *Shared Memory Parallelism in VTK* Brief explanation: Development of multi-threaded algorithms in VTK. Multiple R&D efforts are leading the creation of an infrastructure to support next generation multi-threaded parallel algorithm development in VTK. These efforts are based on modern parallel libraries such as Intel TBB and Inria KAAPI. The main goal of this project will be the development of algorithms that leverage this infrastructure. The focus will be on upgrading existing core algorithms such as iso-surfacing, clipping, cutting, warping etc. to be parallel. Ideally, this will include modernization of the old multi-threading code in the imaging pipeline. Expected results: A number of algorithms that execute in parallel using shared memory. Scalability of new algorithms will have to be measured and documented. Development of regression tests and examples will be also expected. Prerequisites: Experience in C++ and multi-threaded code development. Understanding of core visualization algorithms and data structures. Some experience in VTK ideally but not necessary. Mentor: Berk Geveci (berk dot geveci at kitware dot com) and David Gobbi (david dot gobbi at gmail dot com) *Fine-Grained Parallelism in VTK-m* Brief explanation: VTK-m is a toolkit of scientific visualization algorithms for emerging processor architectures ( GPU's and Coprocessors's ). VTK-m is designed for fine-grained concurrency and provides abstract data and execution models that can be applied to a variety of algorithms. The goal of the project will be on developing algorithms such as Slice by implicit surface, Gradient, Streamlines, External Faces, Resample, etc. using VTKM-m data and execution model. Expected results: A collection of algorithms that are processor architecture agnostic and execute on GPU's and Coprocessor's using VTK-m's data and execution model. Performance of new algorithms will have to be measured and documented. Development of regression tests and examples will be also expected. Prerequisites: Experience in templated C++ development, visualization algorithms, data structures and highly parallel architectures such as GPU's. Some experience in VTK or CUDA or OpenCL would be ideal but not necessary. Mentor: Robert Maynard (robert dot maynard at kitware dot com) and Kenneth Moreland (kmorel at sandia dot gov) -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Mar 11 16:48:29 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 11 Mar 2015 16:48:29 -0400 Subject: [vtk-developers] [PATCH] MetaIO cppcheck fixes In-Reply-To: <20150306174011.GA30554@megas.kitwarein.com> References: <20150306155031.1774182264@mail.rogue-research.com> <20150306174011.GA30554@megas.kitwarein.com> Message-ID: <20150311204829.354536948@mail.rogue-research.com> On Fri, 6 Mar 2015 12:40:11 -0500, Ben Boeckel said: >> I know gerrit won't accept MetaIO changes, and I forget the procedure >> for it, so I'm attaching two trivial patches. Can someone review & >> merge please? > >Pull requests accepted here: > > https://github.com/Kitware/metaio OK, it's in: Can someone merge it into VTK please? Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From dcardwe07 at gmail.com Wed Mar 11 17:53:19 2015 From: dcardwe07 at gmail.com (David Cardwell) Date: Wed, 11 Mar 2015 17:53:19 -0400 Subject: [vtk-developers] GSOC Project Questions Message-ID: Hi, I'm a student interested in participating in Google Summer of Code this year, and I noticed two projects that I think I could work on for VTK. "Lua wrapping, Lua programmable filters" under Half-Baked Ideas and "Templated Input Generator for VTK" would be the projects I think I'm the most qualified for. I have experience doing Lua wrapping for other open source projects, so I'm especially confident I could do the former project. If someone could clarify what people would like to be able do with Lua and which parts of the project would need to be wrapped, that would be great. Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From ee130002001 at iiti.ac.in Thu Mar 12 15:47:25 2015 From: ee130002001 at iiti.ac.in (Abhinav Tripathi) Date: Fri, 13 Mar 2015 01:17:25 +0530 Subject: [vtk-developers] [GSoC '15] Eulerian Magnification for Revealing Subtle Changes Message-ID: Hi, I am B.Tech 2nd year student at IIT Indore, India. I have 7 years of experience programming in C++ and many of its libraries. , I am interested in contributing to the VTK project in the development of filter to analyze and produce results using the Euler magnification. I am new to this method of 'Euler Magnification' but it really caught my interest from the first look itself. I was just looking for some guidance to help me get started. . Regards, Abhinav -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Mar 12 16:13:55 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 12 Mar 2015 16:13:55 -0400 Subject: [vtk-developers] GSOC Project Questions In-Reply-To: References: Message-ID: <20150312201355.GA8481@megas.kitwarein.com> On Wed, Mar 11, 2015 at 17:53:19 -0400, David Cardwell wrote: > I'm a student interested in participating in Google Summer of Code this > year, and I noticed two projects that I think I could work on for VTK. "Lua > wrapping, Lua programmable filters" under Half-Baked Ideas and "Templated > Input Generator for VTK" would be the projects I think I'm the most > qualified for. Great! > I have experience doing Lua wrapping for other open source projects, so I'm > especially confident I could do the former project. There is wrapping infrastructure in Wrapping/Tools which does all the parsing and data extraction already. What would need to be done is to take those structures and turn them into Lua code to call the right functions, do type conversions, etc. Extending the wrapping infrastructure to expose any information Lua needs would be in scope as well. > If someone could clarify what people would like to be able do with Lua Similar things as Python: take VTK objects, put them into a pipeline, load data, do computations, etc. > and which parts of the project would need to be wrapped, that would be > great. If the wrapping infrastructure is used, "all" of VTK shouldn't be too much past the initial push. There are bound to be corner cases that will need to be handled though. David Gobbi is the main developer behind the wrapping infrastructure, but I've done some work in it as well. --Ben From david.gobbi at gmail.com Thu Mar 12 17:04:45 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 12 Mar 2015 15:04:45 -0600 Subject: [vtk-developers] GSOC Project Questions In-Reply-To: <20150312201355.GA8481@megas.kitwarein.com> References: <20150312201355.GA8481@megas.kitwarein.com> Message-ID: On Thu, Mar 12, 2015 at 2:13 PM, Ben Boeckel wrote: > > > > I have experience doing Lua wrapping for other open source projects, so > I'm > > especially confident I could do the former project. > > There is wrapping infrastructure in Wrapping/Tools which does all the > parsing and data extraction already. What would need to be done is to > take those structures and turn them into Lua code to call the right > functions, do type conversions, etc. Extending the wrapping > infrastructure to expose any information Lua needs would be in scope as > well. > > > If someone could clarify what people would like to be able do with Lua > > Similar things as Python: take VTK objects, put them into a pipeline, > load data, do computations, etc. > > > and which parts of the project would need to be wrapped, that would be > > great. > > If the wrapping infrastructure is used, "all" of VTK shouldn't be too > much past the initial push. There are bound to be corner cases that will > need to be handled though. > > David Gobbi is the main developer behind the wrapping infrastructure, > but I've done some work in it as well. > I can add a bit more info about how the VTK python wrappers work. Basically, the wrappers use a custom C++ parser (specifically tuned to VTK) that reads all the VTK header files and create a C data structure that describes the VTK API in all of its gory detail. That information is then used to generate the python wrapper code for each of the VTK classes. The entire python wrapper generator is actually written in C. If there is a desire to add other wrapper languages, there are options: 1) I have a modification to the VTK wrappers that generates a full xml description of the VTK API at https://github.com/dgobbi/WrapVTK , and this xml could be fed into a customized wrapper-code generator. 2) A person could write a back-end for our custom C++ parser that generates swig .i files, and then swig can be used to generate the language wrappers. Or, the aforementioned xml could be converted into a set of .i files for swig. 3) The same approach could be taken as for the existing wrappers, i.e. write the wrapper-generator in C (or C++). :) Due to its complexity, VTK is probably not amenable to off-the-shelf wrapping tools. So just as Qt chose to write their own PySide wrapper tools (and Riverbank wrote sip before that), and just as ITK chose to use a hybrid gccxml/swig approach, VTK is well served by a customized wrapping solution. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Thu Mar 12 17:25:01 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 12 Mar 2015 17:25:01 -0400 Subject: [vtk-developers] GSOC Project Questions In-Reply-To: References: <20150312201355.GA8481@megas.kitwarein.com> Message-ID: Adding to the stream of good advice: 1) I put that one up just because I thought a lua wrapper would be COOL. I have a hunch it will turn out to be really useful too at some point, but I don't really know what for just yet. 2) As for the input generator: The scope of that particular project idea is deceivingly big and a perfect solution within a summer will take a skilled, motivated and experienced developer. That said, small steps along the path are worthwhile too. The root problem is that there is a lot of tribal knowledge that goes into making a good reader. The closest thing I know of to a complete solution for it is the VisIt visualization tools database reader plugin architecture. See: Chapter 3 of https://wci.llnl.gov/content/assets/docs/simulation/computer-codes/visit/GettingDataIntoVisIt2.0.0.pdf for details. Combine its concepts with the ease of customization that a scripting tool (like the python programmable filter) would probably get you most of the way. Either that or gut and templatize one of the truly generic readers like xdmf and you might get there too. More background on readers can be found at: http://www.paraview.org/Wiki/Writing_ParaView_Readers thanks for considering VTK under GSoC and good luck with your proposal! David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Mar 12, 2015 at 5:04 PM, David Gobbi wrote: > On Thu, Mar 12, 2015 at 2:13 PM, Ben Boeckel > wrote: >> >> >> > I have experience doing Lua wrapping for other open source projects, so >> I'm >> > especially confident I could do the former project. >> >> There is wrapping infrastructure in Wrapping/Tools which does all the >> parsing and data extraction already. What would need to be done is to >> take those structures and turn them into Lua code to call the right >> functions, do type conversions, etc. Extending the wrapping >> infrastructure to expose any information Lua needs would be in scope as >> well. >> >> > If someone could clarify what people would like to be able do with Lua >> >> Similar things as Python: take VTK objects, put them into a pipeline, >> load data, do computations, etc. >> >> > and which parts of the project would need to be wrapped, that would be >> > great. >> >> If the wrapping infrastructure is used, "all" of VTK shouldn't be too >> much past the initial push. There are bound to be corner cases that will >> need to be handled though. >> >> David Gobbi is the main developer behind the wrapping infrastructure, >> but I've done some work in it as well. >> > > I can add a bit more info about how the VTK python wrappers work. > Basically, the wrappers use a custom C++ parser (specifically tuned > to VTK) that reads all the VTK header files and create a C data structure > that describes the VTK API in all of its gory detail. That information is > then > used to generate the python wrapper code for each of the VTK classes. > The entire python wrapper generator is actually written in C. > > If there is a desire to add other wrapper languages, there are options: > > 1) I have a modification to the VTK wrappers that generates a full xml > description of the VTK API at https://github.com/dgobbi/WrapVTK , > and this xml could be fed into a customized wrapper-code generator. > > 2) A person could write a back-end for our custom C++ parser that > generates swig .i files, and then swig can be used to generate the > language wrappers. Or, the aforementioned xml could be converted > into a set of .i files for swig. > > 3) The same approach could be taken as for the existing wrappers, > i.e. write the wrapper-generator in C (or C++). :) > > Due to its complexity, VTK is probably not amenable to off-the-shelf > wrapping tools. So just as Qt chose to write their own PySide wrapper > tools (and Riverbank wrote sip before that), and just as ITK chose to > use a hybrid gccxml/swig approach, VTK is well served by a customized > wrapping solution. > > - David > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Thu Mar 12 17:27:58 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 12 Mar 2015 17:27:58 -0400 Subject: [vtk-developers] [GSoC '15] Eulerian Magnification for Revealing Subtle Changes In-Reply-To: References: Message-ID: Here are some ideas to get you warmed up: I think I would go about it by first trying to implement pretty much exactly what the paper says: grab an image stream, apply the described operations in one or more vtk image filters, display the output. You could start by teaching yourself how to use the window to image filter to capture a render window's buffer back into an vtkImageData, and then apply some simple vtk's Image processing filters to it to modify it, then show that in a second window. Put that into a loop where you play through a time varying data set and you are well on your way. You would then just have to find or implement the filters that the paper describes. After learning the algorithm and VTK you could expand from there. Ideally the filter would work directly on VTK's time varying data instead of relying on some external loop. Andy (cc'd) was thinking that it would be interesting to apply the technique on general time varying data sets instead of the contents of the window. We were both thinking that it would be neat to expose the filter and the result window in ParaView. I hope that helps. Don't hesitate to ask us or better yet the vtk mailing list with more questions. thanks for considering VTK in GSoC and good luck with your application! David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Mar 12, 2015 at 3:47 PM, Abhinav Tripathi wrote: > Hi, > I am B.Tech 2nd year student at IIT Indore, India. I have 7 years of > experience programming in C++ and many of its libraries. > , > I am interested in contributing to the VTK project in the development of > filter to analyze and produce results using the Euler magnification. > I am new to this method of 'Euler Magnification' but it really caught my > interest from the first look itself. > I was just looking for some guidance to help me get started. > . > Regards, > Abhinav > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dani.torramilans at gmail.com Thu Mar 12 17:31:20 2015 From: dani.torramilans at gmail.com (Daniel Torramilans) Date: Thu, 12 Mar 2015 14:31:20 -0700 (MST) Subject: [vtk-developers] GSOC 2015 Templated Input Generator for VTK Message-ID: <1426195880458-5730785.post@n5.nabble.com> Hi! I'm a junior student (third year) in Barcelona, doing a Bachelor's Degree in CS. I have a strong background on C++, OpenGL, SDL and graphics frameworks ('ve been building my very own C++ graphics framework for a while now). I've been reading up on VTK for a Google Summer of Code 2015 Application lately, and the Templated Input Generator idea caught my eye. I've been looking at the current VTK/ParaView data formats lately in order to get a grasp of the work to be done as well as playing around with VTK and ParaView themselves, and think I am suitable for the job. I also happen to be very used to Python as I've been using that extensively for scripting/web dev projects, which would come in very handy for this task. I'd like to know your opinions on whether I am suitable for this issue given my background or there is other work that would suit me better. I'd could also use some pointers as to what the actual GSOC Proposal should include (it's my first time on GSOC). If there is any other reference material that I could use, pleas mention it. Thank you! -- View this message in context: http://vtk.1045678.n5.nabble.com/GSOC-2015-Templated-Input-Generator-for-VTK-tp5730785.html Sent from the VTK - Dev mailing list archive at Nabble.com. From ben.boeckel at kitware.com Thu Mar 12 23:13:43 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 12 Mar 2015 23:13:43 -0400 Subject: [vtk-developers] GSOC Project Questions In-Reply-To: References: <20150312201355.GA8481@megas.kitwarein.com> Message-ID: <20150313031343.GD15361@bronto-burt.dev.benboeckel.net> On Thu, Mar 12, 2015 at 17:25:01 -0400, David E DeMarle wrote: > I put that one up just because I thought a lua wrapper would be COOL. I > have a hunch it will turn out to be really useful too at some point, but I > don't really know what for just yet. Well, from the ParaView side, bundling up Lua is *way* easier than bundling up Python for super computers to use. It also looks like luajit has[1] with a way to do an equivalent of Python's "frozen" logic. No idea about "standard" Lua. Which raises a good question: Lua 5.0, 5.1, 5.2, 5.3, or LuaJIT? I'd say at least 5.3 (due to the improved numeric type support) while keeping LuaJIT as a possibility. --Ben [1]https://stackoverflow.com/questions/19606543/embedding-luajit-module-into-c-application From sean at rogue-research.com Fri Mar 13 10:17:00 2015 From: sean at rogue-research.com (Sean McBride) Date: Fri, 13 Mar 2015 10:17:00 -0400 Subject: [vtk-developers] VTK module system uplift to CMake 3.0 features In-Reply-To: References: <20150302195206.GA28834@megas.kitwarein.com> <348B29AC-1F8C-49FA-9CDD-2159340D164B@kitware.com> Message-ID: <20150313141700.591384356@mail.rogue-research.com> On Mon, 2 Mar 2015 18:05:59 -0500, Marcus D. Hanwell said: >Personally, I would love to see us move to C++11 sooner rather than >later, remove more workarounds for ancient compilers/OpenGL versions. Here's a patch to remove gcc 3.x hacks and MSVC++ 8.0 (aka Visual Studio 2005) hacks: With this, gcc 4.0 and MSVC++ 9.0 (aka Visual Studio 2008) become minimums. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From dave.demarle at kitware.com Fri Mar 13 10:24:50 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Fri, 13 Mar 2015 10:24:50 -0400 Subject: [vtk-developers] GSOC 2015 Templated Input Generator for VTK In-Reply-To: <1426195880458-5730785.post@n5.nabble.com> References: <1426195880458-5730785.post@n5.nabble.com> Message-ID: Greetings Daniel, Your background looks great. As for the application, see http://www.vtk.org/Wiki/GSoC_proposal_guidelines . I think the summary of technical work to be done is the most important. The details there are what we use to rank the applications that we get. Like any technical proposal, your job is to convince the reviewers that, the project idea is worthwhile (a given for the projects we proposed), that you have given serious thought to the project, and that your plan has a good chance to succeed. Thanks for considering VTK for google of summer of code and best of luck with your application! Welcome to VTK. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Mar 12, 2015 at 5:31 PM, Daniel Torramilans < dani.torramilans at gmail.com> wrote: > Hi! > > I'm a junior student (third year) in Barcelona, doing a Bachelor's Degree > in > CS. I have a strong background on C++, OpenGL, SDL and graphics frameworks > ('ve been building my very own C++ graphics framework for a while now). > > I've been reading up on VTK for a Google Summer of Code 2015 Application > lately, and the Templated Input Generator idea caught my eye. I've been > looking at the current VTK/ParaView data formats lately in order to get a > grasp of the work to be done as well as playing around with VTK and > ParaView > themselves, and think I am suitable for the job. I also happen to be very > used to Python as I've been using that extensively for scripting/web dev > projects, which would come in very handy for this task. > > I'd like to know your opinions on whether I am suitable for this issue > given > my background or there is other work that would suit me better. I'd could > also use some pointers as to what the actual GSOC Proposal should include > (it's my first time on GSOC). If there is any other reference material that > I could use, pleas mention it. > > Thank you! > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/GSOC-2015-Templated-Input-Generator-for-VTK-tp5730785.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Fri Mar 13 21:13:33 2015 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Fri, 13 Mar 2015 21:13:33 -0400 Subject: [vtk-developers] [PATCH] MetaIO cppcheck fixes In-Reply-To: <20150311204829.354536948@mail.rogue-research.com> References: <20150306155031.1774182264@mail.rogue-research.com> <20150306174011.GA30554@megas.kitwarein.com> <20150311204829.354536948@mail.rogue-research.com> Message-ID: As a side note, appending ".patch" to any github url will give you the patch. For example: https://github.com/Kitware/MetaIO/pull/4.patch Hth Jc On Wed, Mar 11, 2015 at 4:48 PM, Sean McBride wrote: > On Fri, 6 Mar 2015 12:40:11 -0500, Ben Boeckel said: > > >> I know gerrit won't accept MetaIO changes, and I forget the procedure > >> for it, so I'm attaching two trivial patches. Can someone review & > >> merge please? > > > >Pull requests accepted here: > > > > https://github.com/Kitware/metaio > > OK, it's in: > > > Can someone merge it into VTK please? > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabh.iitd02 at gmail.com Sun Mar 15 02:42:38 2015 From: saurabh.iitd02 at gmail.com (saurabh bhadada) Date: Sun, 15 Mar 2015 12:12:38 +0530 Subject: [vtk-developers] Shared Memory Parallelism in VTK Message-ID: hi guys, I have introduced myself before and I have been researching vtk source code. I have started working on my proposal on "Shared Memory Parallelism in VTK*". * please inform me what to study. And is there any work you would like me to do. Also, kindly guide me so that I can complete and submit patch on vtk's gerrit. Thank you. Saurabh Bhadada 3rd Year Integrated Mathematics and Computing IIT Delhi -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Mar 16 11:02:27 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 16 Mar 2015 11:02:27 -0400 Subject: [vtk-developers] Migrating Git repository to Gitlab In-Reply-To: References: Message-ID: <5506F083.4040708@kitware.com> On 3/11/2015 3:09 PM, Utkarsh Ayachit wrote: > We are getting ever closer to making this move to Gitlab. If all goes > well, the move will happen on Monday, March 16th. We will be turning off permissions to access review.source.kitware.com for VTK shortly in preparation for the move to GitLab. -Brad From berk.geveci at kitware.com Mon Mar 16 11:41:37 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 16 Mar 2015 11:41:37 -0400 Subject: [vtk-developers] Shared Memory Parallelism in VTK In-Reply-To: References: Message-ID: Dear Saurabh, At this point, the only thing that is important is to put together a good proposal for the VTK team to review. I recommend taking a look at the VTK code as well as the Wiki (including examples) to have a decent understanding of the algorithm and data APIs as well as various documents on the SMP work: * http://www.vtk.org/Wiki/VTK/VTK_SMP * https://hal.inria.fr/hal-00789814/document * http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.396.4673&rep=rep1&type=pdf These should help with your proposal. It is not expected that you submit a patch before being accepted into GSoC. In fact, it is unlikely that a patch will be accepted unless someone spends a decent amount of time gaining experience with VTK. Best, -berk On Sun, Mar 15, 2015 at 2:42 AM, saurabh bhadada wrote: > hi guys, > > I have introduced myself before and I have been researching vtk source > code. I have started working on my proposal on "Shared Memory Parallelism > in VTK*". * > > please inform me what to study. And is there any work you would like me to > do. Also, kindly guide me so that I can complete and submit patch on vtk's > gerrit. > > Thank you. > > Saurabh Bhadada > 3rd Year Integrated Mathematics and Computing > IIT Delhi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ljianweiyx at gmail.com Mon Mar 16 13:33:31 2015 From: ljianweiyx at gmail.com (jianwei li) Date: Tue, 17 Mar 2015 01:33:31 +0800 Subject: [vtk-developers] Shared Memory Parallelism in VTK Message-ID: Hi I'm a graduate student in NorthWestern Polytenical University.I have been study Parelism promraming,especially GPU programming for two year.So I want to accept task Shared Memory Paralism in VTK. But now,I don't know if you want implement the parallelism on GPU or CPU,and do you hace some other demand,such as efficiency,coefficeent of utilization of processor. Watting for your answer! Than you! Best Regard -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Mon Mar 16 13:35:01 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 16 Mar 2015 13:35:01 -0400 Subject: [vtk-developers] VTK module system uplift to CMake 3.0 features In-Reply-To: <20150313141700.591384356@mail.rogue-research.com> References: <20150302195206.GA28834@megas.kitwarein.com> <348B29AC-1F8C-49FA-9CDD-2159340D164B@kitware.com> <20150313141700.591384356@mail.rogue-research.com> Message-ID: Hi Sean, I just noticed this. I personally don't have any objections to removing support for these older compilers but I recommend starting a thread on the VTK and VTK developers list if you are interested in moving this forward. This shouldn't be decided without community support. Best, -berk On Fri, Mar 13, 2015 at 10:17 AM, Sean McBride wrote: > On Mon, 2 Mar 2015 18:05:59 -0500, Marcus D. Hanwell said: > > >Personally, I would love to see us move to C++11 sooner rather than > >later, remove more workarounds for ancient compilers/OpenGL versions. > > Here's a patch to remove gcc 3.x hacks and MSVC++ 8.0 (aka Visual Studio > 2005) hacks: > > > With this, gcc 4.0 and MSVC++ 9.0 (aka Visual Studio 2008) become minimums. > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Mar 16 13:47:46 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 16 Mar 2015 11:47:46 -0600 Subject: [vtk-developers] Shared Memory Parallelism in VTK In-Reply-To: References: Message-ID: Hi Jianwei, Thank you for your interest. This particular project is for CPU parallelism. As part of the project, the algorithms are to be evaluated to see how well they scale as more CPU cores are utilized, and evaluated vs. the equivalent serial algorithms. - David On Mon, Mar 16, 2015 at 11:33 AM, jianwei li wrote: > Hi > I'm a graduate student in NorthWestern Polytenical University.I have > been study Parelism promraming,especially GPU programming for two year.So I > want to accept task Shared Memory Paralism in VTK. > But now,I don't know if you want implement the parallelism on GPU or > CPU,and do you hace some other demand,such as efficiency,coefficeent of > utilization of processor. > Watting for your answer! > Than you! > Best Regard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Mon Mar 16 13:48:59 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 16 Mar 2015 13:48:59 -0400 Subject: [vtk-developers] Shared Memory Parallelism in VTK In-Reply-To: References: Message-ID: Dear Jianwei, Please take a look at these references: * http://www.vtk.org/Wiki/VTK/VTK_SMP * https://hal.inria.fr/hal-00789814/document * http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.396.4673&rep=rep1&type=pdf This particular project refer to the CPU based SMP parallelism currently in VTK as explained in the references above. For reference, I included these in the topic page as well. Best, -berk On Mon, Mar 16, 2015 at 1:33 PM, jianwei li wrote: > Hi > I'm a graduate student in NorthWestern Polytenical University.I have > been study Parelism promraming,especially GPU programming for two year.So I > want to accept task Shared Memory Paralism in VTK. > But now,I don't know if you want implement the parallelism on GPU or > CPU,and do you hace some other demand,such as efficiency,coefficeent of > utilization of processor. > Watting for your answer! > Than you! > Best Regard > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Mon Mar 16 14:09:26 2015 From: sean at rogue-research.com (Sean McBride) Date: Mon, 16 Mar 2015 14:09:26 -0400 Subject: [vtk-developers] RFC: Compiler support, removing hacks for old compilers Message-ID: <20150316180926.1146005295@mail.rogue-research.com> Hi all, VTK currently contains hacks for various old compilers. I'd like to prune some of this and increase the minimum compiler requirements. I'd be interested to know from the community what are the oldest compilers you care about? Anyone out there using a compiler older than 5 years or so? Concretely, I thought I'd start by removing support for: - gcc 3.x - MSVC++ 8.0 (aka Visual Studio 2005) The minimums would therefore become: - gcc 4.0 - Released: 2005-04-20 - MSVC++ 9.0 (aka Visual Studio 2008) - Released: 2007-11-19 The motivation being: - reduce cruft in the codebase - allow use of newer language features (C++11 eventually) Thoughts? Thanks, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From ljianweiyx at gmail.com Mon Mar 16 14:25:44 2015 From: ljianweiyx at gmail.com (jianwei li) Date: Tue, 17 Mar 2015 02:25:44 +0800 Subject: [vtk-developers] Shared Memory Parallelism in VTK In-Reply-To: References: Message-ID: Hi I have read the paper 'VtkSMP: Task-based Parallel Operators for VTK Filters'.Based on the paper,kaapi is better than other two methods.So,do you want to use kaapi to implement some VTK filters.And,which processor want to be,such as the number of core.And do you only want to implement the filter listed in the paper. Best regard Jianwei 2015-03-17 1:48 GMT+08:00 Berk Geveci : > Dear Jianwei, > > Please take a look at these references: > > * http://www.vtk.org/Wiki/VTK/VTK_SMP > * https://hal.inria.fr/hal-00789814/document > * > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.396.4673&rep=rep1&type=pdf > > This particular project refer to the CPU based SMP parallelism currently > in VTK as explained in the references above. For reference, I included > these in the topic page as well. > > Best, > -berk > > On Mon, Mar 16, 2015 at 1:33 PM, jianwei li wrote: > >> Hi >> I'm a graduate student in NorthWestern Polytenical University.I have >> been study Parelism promraming,especially GPU programming for two year.So I >> want to accept task Shared Memory Paralism in VTK. >> But now,I don't know if you want implement the parallelism on GPU or >> CPU,and do you hace some other demand,such as efficiency,coefficeent of >> utilization of processor. >> Watting for your answer! >> Than you! >> Best Regard >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Mon Mar 16 14:52:14 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 16 Mar 2015 14:52:14 -0400 Subject: [vtk-developers] Shared Memory Parallelism in VTK In-Reply-To: References: Message-ID: Dear Jianwei, The VTK SMP infrastructure abstracts the backend so you don't have to worry about which backend to write for. See the PDF document reference in http://www.vtk.org/Wiki/VTK/VTK_SMP It is up to the students to make a decision on which filters they want to implement using this infrastructure. Once the proposals are in, we may come back and make some suggestions for other algorithms. Also, note that the project may include the VTK imaging pipeline as stating in "this will include modernization of the old multi-threading code in the imaging pipeline". David: Is there a reference describing the VTK threaded image algorithm infrastructure or do we just point to the code? Best, -berk On Mon, Mar 16, 2015 at 2:25 PM, jianwei li wrote: > Hi > I have read the paper 'VtkSMP: Task-based Parallel Operators for VTK > Filters'.Based on the paper,kaapi is better than other two methods.So,do > you want to use kaapi to implement some VTK filters.And,which processor > want to be,such as the number of core.And do you only want to implement the > filter listed in the paper. > Best regard > Jianwei > > 2015-03-17 1:48 GMT+08:00 Berk Geveci : > >> Dear Jianwei, >> >> Please take a look at these references: >> >> * http://www.vtk.org/Wiki/VTK/VTK_SMP >> * https://hal.inria.fr/hal-00789814/document >> * >> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.396.4673&rep=rep1&type=pdf >> >> This particular project refer to the CPU based SMP parallelism currently >> in VTK as explained in the references above. For reference, I included >> these in the topic page as well. >> >> Best, >> -berk >> >> On Mon, Mar 16, 2015 at 1:33 PM, jianwei li wrote: >> >>> Hi >>> I'm a graduate student in NorthWestern Polytenical University.I have >>> been study Parelism promraming,especially GPU programming for two year.So I >>> want to accept task Shared Memory Paralism in VTK. >>> But now,I don't know if you want implement the parallelism on GPU or >>> CPU,and do you hace some other demand,such as efficiency,coefficeent of >>> utilization of processor. >>> Watting for your answer! >>> Than you! >>> Best Regard >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >>> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Mar 16 15:17:37 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 16 Mar 2015 13:17:37 -0600 Subject: [vtk-developers] Shared Memory Parallelism in VTK In-Reply-To: References: Message-ID: On Mon, Mar 16, 2015 at 12:52 PM, Berk Geveci wrote: > > > David: Is there a reference describing the VTK threaded image algorithm > infrastructure or do we just point to the code? > There's no reference for vtkThreadedImageAlgorithm that I'm aware of, though I can write something up on the wiki. Even though the code itself isn't very complicated, it would be hard to follow for anyone who isn't familiar with a) the streaming pipeline and b) the vtkMultiThreader. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Mar 16 15:27:15 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 16 Mar 2015 15:27:15 -0400 Subject: [vtk-developers] RFC: Compiler support, removing hacks for old compilers In-Reply-To: <20150316180926.1146005295@mail.rogue-research.com> References: <20150316180926.1146005295@mail.rogue-research.com> Message-ID: <20150316192715.GA23180@megas.kitwarein.com> On Mon, Mar 16, 2015 at 14:09:26 -0400, Sean McBride wrote: > The motivation being: > - reduce cruft in the codebase > - allow use of newer language features (C++11 eventually) FWIW, using C++11 support would bump to gcc 4.8 and VS2013 for (practical) purposes (gcc 4.4 and VS2010 have rudimentary support for it, but nothing I would rely on). > Thoughts? +1. --Ben From berk.geveci at kitware.com Mon Mar 16 15:59:14 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 16 Mar 2015 15:59:14 -0400 Subject: [vtk-developers] Shared Memory Parallelism in VTK In-Reply-To: References: Message-ID: Maybe a brief Wiki page describing the overall volume splitting and static thread assignment would be good. We can put a link from the project page. Beyond that, when/if we pick a student for the project and Google funds it, we can elaborate. -berk On Mon, Mar 16, 2015 at 3:17 PM, David Gobbi wrote: > On Mon, Mar 16, 2015 at 12:52 PM, Berk Geveci > wrote: >> >> >> David: Is there a reference describing the VTK threaded image algorithm >> infrastructure or do we just point to the code? >> > > There's no reference for vtkThreadedImageAlgorithm that I'm aware of, > though I can write something up on the wiki. Even though the code itself > isn't very complicated, it would be hard to follow for anyone who isn't > familiar with a) the streaming pipeline and b) the vtkMultiThreader. > > - David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Mar 16 17:12:59 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 16 Mar 2015 17:12:59 -0400 Subject: [vtk-developers] Migrating Git repository to Gitlab In-Reply-To: <5506F083.4040708@kitware.com> References: <5506F083.4040708@kitware.com> Message-ID: <5507475B.7010803@kitware.com> On 03/16/2015 11:02 AM, Brad King wrote: > We will be turning off permissions to access review.source.kitware.com > for VTK shortly in preparation for the move to GitLab. VTK development is now hosted by GitLab here: https://gitlab.kitware.com/vtk/vtk The top of that page shows the new preferred clone URL: https://gitlab.kitware.com/vtk/vtk.git It also links to the README.md file which links to CONTRIBUTING.md which links to the new entry point for Git and developer instructions: https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/README.md In order to update your existing work tree: $ git checkout master $ git pull $ Utilities/SetupForDevelopment.sh Please rebase any open topics on 'master' and revise the commit messages to drop any existing 'Change-Id' lines (these are not needed by GitLab). Then proceed according to the above-linked instructions. ----------------------------------------------------------------------- The old "git://vtk.org/VTK.git" repository is now a robot-maintained mirror of the GitLab VTK repository. The review.source.kitware.com Gerrit VTK repository is now a read-only archive and not maintained. Updates of web pages and links on vtk.org are still on-going. If after 2015-03-18 you come across an out-dated link, please report it here. We are also in the process of updating the test infrastructure to support the GitLab workflow. As of this writing Merge Requests will not yet be tested automatically prior to merging, but the necessary infrastructure is close to ready. -Brad From ben.boeckel at kitware.com Mon Mar 16 17:21:19 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 16 Mar 2015 17:21:19 -0400 Subject: [vtk-developers] Migrating Git repository to Gitlab In-Reply-To: <5507475B.7010803@kitware.com> References: <5506F083.4040708@kitware.com> <5507475B.7010803@kitware.com> Message-ID: <20150316212119.GA24569@megas.kitwarein.com> On Mon, Mar 16, 2015 at 17:12:59 -0400, Brad King wrote: > Please rebase any open topics on 'master' and revise the commit > messages to drop any existing 'Change-Id' lines (these are not > needed by GitLab). Then proceed according to the above-linked > instructions. Once you have rebased your changes onto master, the simplest way to remove the Change-Id markers is: GIT_EDITOR="sed -i -e 's/^pick/reword/;/^Change-Id:/d'" git rebase -i origin/master Basically, it interactively (-i) rebases the branch, changes 'pick' to 'reword' to edit the comment message and then removes any Change-Id lines from the commit message. One thing to watch for is that if you have "pick" in your commit message, it will be replaced, so I'd recommend doublechecking that "reword" doesn't show up in your commit messages: git log master.. after rebasing. --Ben From sean at rogue-research.com Mon Mar 16 17:27:53 2015 From: sean at rogue-research.com (Sean McBride) Date: Mon, 16 Mar 2015 17:27:53 -0400 Subject: [vtk-developers] Migrating Git repository to Gitlab In-Reply-To: <5507475B.7010803@kitware.com> References: <5506F083.4040708@kitware.com> <5507475B.7010803@kitware.com> Message-ID: <20150316212753.267553617@mail.rogue-research.com> On Mon, 16 Mar 2015 17:12:59 -0400, Brad King said: >VTK development is now hosted by GitLab here: Congrats on what was no doubt an arduous task! >It also links to the README.md file which links to CONTRIBUTING.md >which links to the new entry point for Git and developer instructions: > > https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/ >README.md Is there a convention for GitLab usernames? "Human Reviews" talks about 'referencing @username', so it might make it easier on us humans if a common scheme was used. Should I be "seanmcbride", "seanm", "SeanMcBride", or what? Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From david.gobbi at gmail.com Mon Mar 16 17:57:36 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 16 Mar 2015 15:57:36 -0600 Subject: [vtk-developers] Migrating Git repository to Gitlab In-Reply-To: <20150316212753.267553617@mail.rogue-research.com> References: <5506F083.4040708@kitware.com> <5507475B.7010803@kitware.com> <20150316212753.267553617@mail.rogue-research.com> Message-ID: On Mon, Mar 16, 2015 at 3:27 PM, Sean McBride wrote: > > Is there a convention for GitLab usernames? "Human Reviews" talks about > 'referencing @username', so it might make it easier on us humans if a > common scheme was used. Should I be "seanmcbride", "seanm", "SeanMcBride", > or what? > I used my github username, and I vote that people can do whatever they choose. If there is to be a convention, the "firstname.lastname" system that Brad used is a decent one. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From ljianweiyx at gmail.com Mon Mar 16 21:56:23 2015 From: ljianweiyx at gmail.com (jianwei li) Date: Tue, 17 Mar 2015 09:56:23 +0800 Subject: [vtk-developers] Shared Memory Parallelism in VTK In-Reply-To: References: Message-ID: So,do I need to write a proposal to implement anyone algorithm using TBB or XKaapi 2015-03-17 3:59 GMT+08:00 Berk Geveci : > Maybe a brief Wiki page describing the overall volume splitting and static > thread assignment would be good. We can put a link from the project page. > Beyond that, when/if we pick a student for the project and Google funds it, > we can elaborate. > > -berk > > On Mon, Mar 16, 2015 at 3:17 PM, David Gobbi > wrote: > >> On Mon, Mar 16, 2015 at 12:52 PM, Berk Geveci >> wrote: >>> >>> >>> David: Is there a reference describing the VTK threaded image algorithm >>> infrastructure or do we just point to the code? >>> >> >> There's no reference for vtkThreadedImageAlgorithm that I'm aware of, >> though I can write something up on the wiki. Even though the code itself >> isn't very complicated, it would be hard to follow for anyone who isn't >> familiar with a) the streaming pipeline and b) the vtkMultiThreader. >> >> - David >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Mar 16 22:54:37 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 16 Mar 2015 19:54:37 -0700 Subject: [vtk-developers] Trouble setting up gitlab Message-ID: When I run the setup script I get this error: Test access to GitLab (SSH)? [y/N]: y Testing GitLab access by SSH...fatal: protocol error: bad line length character: No s failed. I'm using the same public key I used on gerrit. From bill.lorensen at gmail.com Mon Mar 16 23:01:27 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 16 Mar 2015 20:01:27 -0700 Subject: [vtk-developers] Trouble setting up gitlab In-Reply-To: References: Message-ID: OK, I forgot to click my name to fork the repository. Now I'm OK. On Mon, Mar 16, 2015 at 7:54 PM, Bill Lorensen wrote: > When I run the setup script I get this error: > Test access to GitLab (SSH)? [y/N]: y > Testing GitLab access by SSH...fatal: protocol error: bad line length > character: No s > failed. > > I'm using the same public key I used on gerrit. -- Unpaid intern in BillsBasement at noware dot com From david.gobbi at gmail.com Mon Mar 16 23:17:56 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 16 Mar 2015 21:17:56 -0600 Subject: [vtk-developers] Shared Memory Parallelism in VTK In-Reply-To: References: Message-ID: Hi Jianwei, You wouldn't directly use TBB or Kaapi, because VTK provides an abstract SMP interface. This doxygen page provides a brief synopsis. The "Functor" described on the page is a function-like object with the signature "void func(vtkIdType first, vtkIdType last)" where vtkIdType is an integer type. Basically, the SMP For() function is given a (first,last) range that covers the entire data set, and divides it into smaller (first,last) sub-ranges that the Functor operates on from within the worker threads. http://www.vtk.org/doc/nightly/html/classvtkSMPTools.html To complete the picture, you can take a look at the Kaapi back end and the TBB back end: https://gitlab.kitware.com/vtk/vtk/blob/master/Common/Core/SMP/Kaapi/vtkSMPToolsInternal.h.in https://gitlab.kitware.com/vtk/vtk/blob/master/Common/Core/SMP/TBB/vtkSMPToolsInternal.h.in So to answer your question, the proposal would be to write (and then evaluate) an efficient parallel VTK algorithm that uses the abstract interface described on the first web page. Cheers, - David On Mon, Mar 16, 2015 at 7:56 PM, jianwei li wrote: > So,do I need to write a proposal to implement anyone algorithm using TBB > or XKaapi > > 2015-03-17 3:59 GMT+08:00 Berk Geveci : > >> Maybe a brief Wiki page describing the overall volume splitting and >> static thread assignment would be good. We can put a link from the project >> page. Beyond that, when/if we pick a student for the project and Google >> funds it, we can elaborate. >> >> -berk >> >> On Mon, Mar 16, 2015 at 3:17 PM, David Gobbi >> wrote: >> >>> On Mon, Mar 16, 2015 at 12:52 PM, Berk Geveci >>> wrote: >>>> >>>> >>>> David: Is there a reference describing the VTK threaded image algorithm >>>> infrastructure or do we just point to the code? >>>> >>> >>> There's no reference for vtkThreadedImageAlgorithm that I'm aware of, >>> though I can write something up on the wiki. Even though the code itself >>> isn't very complicated, it would be hard to follow for anyone who isn't >>> familiar with a) the streaming pipeline and b) the vtkMultiThreader. >>> >>> - David >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Mar 16 23:29:05 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 16 Mar 2015 20:29:05 -0700 Subject: [vtk-developers] How to request reviewer of a topic Message-ID: I have a topic I would like others to review. What is the equivalent of gerrit's "add reviewer". From david.gobbi at gmail.com Tue Mar 17 08:25:41 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 17 Mar 2015 06:25:41 -0600 Subject: [vtk-developers] Shared Memory Parallelism in VTK In-Reply-To: References: Message-ID: I've created a wiki page that describes the vtkThreadedImageAlgorithm. It's linked from the GSoC page and from the Advanced Tutorials wiki page. http://www.vtk.org/Wiki/VTK/Threaded_Image_Algorithms On Mon, Mar 16, 2015 at 1:59 PM, Berk Geveci wrote: > Maybe a brief Wiki page describing the overall volume splitting and static > thread assignment would be good. We can put a link from the project page. > Beyond that, when/if we pick a student for the project and Google funds it, > we can elaborate. > > -berk > > On Mon, Mar 16, 2015 at 3:17 PM, David Gobbi > wrote: > >> On Mon, Mar 16, 2015 at 12:52 PM, Berk Geveci >> wrote: >>> >>> >>> David: Is there a reference describing the VTK threaded image algorithm >>> infrastructure or do we just point to the code? >>> >> >> There's no reference for vtkThreadedImageAlgorithm that I'm aware of, >> though I can write something up on the wiki. Even though the code itself >> isn't very complicated, it would be hard to follow for anyone who isn't >> familiar with a) the streaming pipeline and b) the vtkMultiThreader. >> >> - David >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Mar 17 08:35:58 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 08:35:58 -0400 Subject: [vtk-developers] Migrating Git repository to Gitlab In-Reply-To: References: <5506F083.4040708@kitware.com> <5507475B.7010803@kitware.com> <20150316212753.267553617@mail.rogue-research.com> Message-ID: <55081FAE.3020704@kitware.com> On 03/16/2015 05:57 PM, David Gobbi wrote: > On Mon, Mar 16, 2015 at 3:27 PM, Sean McBride wrote: >> Is there a convention for GitLab usernames? "Human Reviews" talks about >> 'referencing @username', so it might make it easier on us humans if a >> common scheme was used. Should I be "seanmcbride", "seanm", "SeanMcBride", >> or what? > > I used my github username, and I vote that people can do whatever they > choose. If there is to be a convention, the "firstname.lastname" system > that Brad used is a decent one. In the GitLab text boxes when one types '@...' the completion logic allows you to type the person's Real Name and then select from a popup/drop-down list of matches. It will then insert the corresponding user name. Therefore we don't need to require any convention for user names for that reason. -Brad From brad.king at kitware.com Tue Mar 17 08:40:06 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 08:40:06 -0400 Subject: [vtk-developers] How to request reviewer of a topic In-Reply-To: References: Message-ID: <550820A6.3020207@kitware.com> On 03/16/2015 11:29 PM, Bill Lorensen wrote: > I have a topic I would like others to review. What is the equivalent > of gerrit's "add reviewer". As mentioned in each of these two sections: https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/develop.md#create-a-merge-request https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/develop.md#review-a-merge-request one can mention `@username` in a comment. That will notify the named user(s). GitLab has no notion of a list of reviewers, just participants in the discussion. There is an "Assignee" field in Merge Requests too, but we're not sure whether we need to use it for our workflow. -Brad From ben.boeckel at kitware.com Tue Mar 17 09:19:44 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 17 Mar 2015 09:19:44 -0400 Subject: [vtk-developers] Migrating Git repository to Gitlab In-Reply-To: References: <5506F083.4040708@kitware.com> <5507475B.7010803@kitware.com> <20150316212753.267553617@mail.rogue-research.com> Message-ID: <20150317131944.GB8660@megas.kitwarein.com> On Mon, Mar 16, 2015 at 15:57:36 -0600, David Gobbi wrote: > I used my github username, and I vote that people can do whatever they > choose. If there is to be a convention, the "firstname.lastname" system > that Brad used is a decent one. +1 to first.last. You can change it after you login, but do it before creating forks please :) . --Ben From ben.boeckel at kitware.com Tue Mar 17 09:21:13 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 17 Mar 2015 09:21:13 -0400 Subject: [vtk-developers] How to request reviewer of a topic In-Reply-To: References: Message-ID: <20150317132113.GC8660@megas.kitwarein.com> On Mon, Mar 16, 2015 at 20:29:05 -0700, Bill Lorensen wrote: > I have a topic I would like others to review. What is the equivalent > of gerrit's "add reviewer". You can assign it to someone or you can @mention folks. I like doing "Cc: @username" so the reason they're mentioned is more explicit. --Ben From ben.boeckel at kitware.com Tue Mar 17 09:30:05 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 17 Mar 2015 09:30:05 -0400 Subject: [vtk-developers] Migrating Git repository to Gitlab In-Reply-To: <55081FAE.3020704@kitware.com> References: <5506F083.4040708@kitware.com> <5507475B.7010803@kitware.com> <20150316212753.267553617@mail.rogue-research.com> <55081FAE.3020704@kitware.com> Message-ID: <20150317133005.GA12028@megas.kitwarein.com> On Tue, Mar 17, 2015 at 08:35:58 -0400, Brad King wrote: > In the GitLab text boxes when one types '@...' the completion logic allows > you to type the person's Real Name and then select from a popup/drop-down > list of matches. It will then insert the corresponding user name. > Therefore we don't need to require any convention for user names for > that reason. FWIW, this will only complete usernames of those "associated" with the project (members of the group or project). --Ben From ken.martin at kitware.com Tue Mar 17 09:48:02 2015 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 17 Mar 2015 09:48:02 -0400 Subject: [vtk-developers] Migrating Git repository to Gitlab In-Reply-To: <20150317133005.GA12028@megas.kitwarein.com> References: <5506F083.4040708@kitware.com> <5507475B.7010803@kitware.com> <20150316212753.267553617@mail.rogue-research.com> <55081FAE.3020704@kitware.com> <20150317133005.GA12028@megas.kitwarein.com> Message-ID: <5f3434d2a1b14ec07e18de347a34904b@mail.gmail.com> Hmm for me I only see three options on the pulldown all vtk ken-martin Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee.? Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message.? Thank you. -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Ben Boeckel Sent: Tuesday, March 17, 2015 9:30 AM To: Brad King Cc: VTK Developers; David Gobbi Subject: Re: [vtk-developers] Migrating Git repository to Gitlab On Tue, Mar 17, 2015 at 08:35:58 -0400, Brad King wrote: > In the GitLab text boxes when one types '@...' the completion logic > allows you to type the person's Real Name and then select from a > popup/drop-down list of matches. It will then insert the corresponding user name. > Therefore we don't need to require any convention for user names for > that reason. FWIW, this will only complete usernames of those "associated" with the project (members of the group or project). --Ben _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers From ken.martin at kitware.com Tue Mar 17 09:49:30 2015 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 17 Mar 2015 09:49:30 -0400 Subject: [vtk-developers] Migrating Git repository to Gitlab In-Reply-To: <20150317133005.GA12028@megas.kitwarein.com> References: <5506F083.4040708@kitware.com> <5507475B.7010803@kitware.com> <20150316212753.267553617@mail.rogue-research.com> <55081FAE.3020704@kitware.com> <20150317133005.GA12028@megas.kitwarein.com> Message-ID: Who should we assign merge requests to? I see an Assign to pulldown with an option to assign to me. Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee.? Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message.? Thank you. -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Ben Boeckel Sent: Tuesday, March 17, 2015 9:30 AM To: Brad King Cc: VTK Developers; David Gobbi Subject: Re: [vtk-developers] Migrating Git repository to Gitlab On Tue, Mar 17, 2015 at 08:35:58 -0400, Brad King wrote: > In the GitLab text boxes when one types '@...' the completion logic > allows you to type the person's Real Name and then select from a > popup/drop-down list of matches. It will then insert the corresponding user name. > Therefore we don't need to require any convention for user names for > that reason. FWIW, this will only complete usernames of those "associated" with the project (members of the group or project). --Ben _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers From ljianweiyx at gmail.com Tue Mar 17 09:54:54 2015 From: ljianweiyx at gmail.com (jianwei li) Date: Tue, 17 Mar 2015 21:54:54 +0800 Subject: [vtk-developers] Shared Memory Parallelism in VTK In-Reply-To: References: Message-ID: Hi Now,in my proposal,I want use the implemented paralle methods to implemente the cutting algorithm.But,do you have a guide line for the implemented paralle methods. Thank you Cheers Jianwei 2015-03-17 11:17 GMT+08:00 David Gobbi : > Hi Jianwei, > > You wouldn't directly use TBB or Kaapi, because VTK provides an abstract > SMP interface. This doxygen page provides a brief synopsis. The "Functor" > described on the page is a function-like object with the signature "void > func(vtkIdType first, vtkIdType last)" where vtkIdType is an integer type. > Basically, the SMP For() function is given a (first,last) range that covers > the entire data set, and divides it into smaller (first,last) sub-ranges > that the Functor operates on from within the worker threads. > http://www.vtk.org/doc/nightly/html/classvtkSMPTools.html > > To complete the picture, you can take a look at the Kaapi back end and the > TBB back end: > > https://gitlab.kitware.com/vtk/vtk/blob/master/Common/Core/SMP/Kaapi/vtkSMPToolsInternal.h.in > > https://gitlab.kitware.com/vtk/vtk/blob/master/Common/Core/SMP/TBB/vtkSMPToolsInternal.h.in > > So to answer your question, the proposal would be to write (and then > evaluate) an efficient parallel VTK algorithm that uses the abstract > interface described on the first web page. > > Cheers, > - David > > > On Mon, Mar 16, 2015 at 7:56 PM, jianwei li wrote: > >> So,do I need to write a proposal to implement anyone algorithm using TBB >> or XKaapi >> >> 2015-03-17 3:59 GMT+08:00 Berk Geveci : >> >>> Maybe a brief Wiki page describing the overall volume splitting and >>> static thread assignment would be good. We can put a link from the project >>> page. Beyond that, when/if we pick a student for the project and Google >>> funds it, we can elaborate. >>> >>> -berk >>> >>> On Mon, Mar 16, 2015 at 3:17 PM, David Gobbi >>> wrote: >>> >>>> On Mon, Mar 16, 2015 at 12:52 PM, Berk Geveci >>>> wrote: >>>>> >>>>> >>>>> David: Is there a reference describing the VTK threaded image >>>>> algorithm infrastructure or do we just point to the code? >>>>> >>>> >>>> There's no reference for vtkThreadedImageAlgorithm that I'm aware of, >>>> though I can write something up on the wiki. Even though the code itself >>>> isn't very complicated, it would be hard to follow for anyone who isn't >>>> familiar with a) the streaming pipeline and b) the vtkMultiThreader. >>>> >>>> - David >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Mar 17 10:18:29 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 17 Mar 2015 07:18:29 -0700 Subject: [vtk-developers] How to request reviewer of a topic In-Reply-To: <550820A6.3020207@kitware.com> References: <550820A6.3020207@kitware.com> Message-ID: How do I know the usernames? For example, I see Ken Martin's name is ken-martin. My name is lorensen. On Tue, Mar 17, 2015 at 5:40 AM, Brad King wrote: > On 03/16/2015 11:29 PM, Bill Lorensen wrote: >> I have a topic I would like others to review. What is the equivalent >> of gerrit's "add reviewer". > > As mentioned in each of these two sections: > > https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/develop.md#create-a-merge-request > https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/develop.md#review-a-merge-request > > one can mention `@username` in a comment. That will notify the > named user(s). GitLab has no notion of a list of reviewers, just > participants in the discussion. There is an "Assignee" field in > Merge Requests too, but we're not sure whether we need to use it > for our workflow. > > -Brad > -- Unpaid intern in BillsBasement at noware dot com From ljianweiyx at gmail.com Tue Mar 17 10:19:46 2015 From: ljianweiyx at gmail.com (jianwei li) Date: Tue, 17 Mar 2015 22:19:46 +0800 Subject: [vtk-developers] Shared Memory Parallelism in VTK In-Reply-To: References: Message-ID: Hi There is no the in the VTK source file.Is this a unused class,and we have to complete it in the future. Best Regard Jianwei Li 2015-03-17 21:54 GMT+08:00 jianwei li : > Hi > Now,in my proposal,I want use the implemented paralle methods to > implemente the cutting algorithm.But,do you have a guide line for the > implemented paralle methods. > Thank you > Cheers > Jianwei > > 2015-03-17 11:17 GMT+08:00 David Gobbi : > >> Hi Jianwei, >> >> You wouldn't directly use TBB or Kaapi, because VTK provides an abstract >> SMP interface. This doxygen page provides a brief synopsis. The "Functor" >> described on the page is a function-like object with the signature "void >> func(vtkIdType first, vtkIdType last)" where vtkIdType is an integer type. >> Basically, the SMP For() function is given a (first,last) range that covers >> the entire data set, and divides it into smaller (first,last) sub-ranges >> that the Functor operates on from within the worker threads. >> http://www.vtk.org/doc/nightly/html/classvtkSMPTools.html >> >> To complete the picture, you can take a look at the Kaapi back end and >> the TBB back end: >> >> https://gitlab.kitware.com/vtk/vtk/blob/master/Common/Core/SMP/Kaapi/vtkSMPToolsInternal.h.in >> >> https://gitlab.kitware.com/vtk/vtk/blob/master/Common/Core/SMP/TBB/vtkSMPToolsInternal.h.in >> >> So to answer your question, the proposal would be to write (and then >> evaluate) an efficient parallel VTK algorithm that uses the abstract >> interface described on the first web page. >> >> Cheers, >> - David >> >> >> On Mon, Mar 16, 2015 at 7:56 PM, jianwei li wrote: >> >>> So,do I need to write a proposal to implement anyone algorithm using TBB >>> or XKaapi >>> >>> 2015-03-17 3:59 GMT+08:00 Berk Geveci : >>> >>>> Maybe a brief Wiki page describing the overall volume splitting and >>>> static thread assignment would be good. We can put a link from the project >>>> page. Beyond that, when/if we pick a student for the project and Google >>>> funds it, we can elaborate. >>>> >>>> -berk >>>> >>>> On Mon, Mar 16, 2015 at 3:17 PM, David Gobbi >>>> wrote: >>>> >>>>> On Mon, Mar 16, 2015 at 12:52 PM, Berk Geveci >>>> > wrote: >>>>>> >>>>>> >>>>>> David: Is there a reference describing the VTK threaded image >>>>>> algorithm infrastructure or do we just point to the code? >>>>>> >>>>> >>>>> There's no reference for vtkThreadedImageAlgorithm that I'm aware of, >>>>> though I can write something up on the wiki. Even though the code itself >>>>> isn't very complicated, it would be hard to follow for anyone who isn't >>>>> familiar with a) the streaming pipeline and b) the vtkMultiThreader. >>>>> >>>>> - David >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Mar 17 10:20:17 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 10:20:17 -0400 Subject: [vtk-developers] Migrating Git repository to Gitlab In-Reply-To: References: <5506F083.4040708@kitware.com> <5507475B.7010803@kitware.com> <20150316212753.267553617@mail.rogue-research.com> <55081FAE.3020704@kitware.com> <20150317133005.GA12028@megas.kitwarein.com> Message-ID: <55083821.2030804@kitware.com> On 03/17/2015 09:49 AM, Ken Martin wrote: > Who should we assign merge requests to? I see an Assign to pulldown with > an option to assign to me. Currently we're not using the assignment field in our workflow. If you have someone specific in mind to review the merge request then you can use it, but it is not an official part of our documented workflow. -Brad From brad.king at kitware.com Tue Mar 17 10:21:21 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 10:21:21 -0400 Subject: [vtk-developers] How to request reviewer of a topic In-Reply-To: References: <550820A6.3020207@kitware.com> Message-ID: <55083861.5040104@kitware.com> On 03/17/2015 10:18 AM, Bill Lorensen wrote: > How do I know the usernames? For example, I see Ken Martin's name is > ken-martin. My name is lorensen. You should just be able to start typing @RealName and it will come up with completions for available developers whose real name or user name matches what you typed. -Brad From berk.geveci at kitware.com Tue Mar 17 10:34:15 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 17 Mar 2015 10:34:15 -0400 Subject: [vtk-developers] Shared Memory Parallelism in VTK In-Reply-To: References: Message-ID: It is there in VTK Git master. It is also in the last version I am pretty sure. Best, -berk On Tue, Mar 17, 2015 at 10:19 AM, jianwei li wrote: > Hi > There is no the in the VTK source file.Is this a > unused class,and we have to complete it in the future. > Best Regard > Jianwei Li > > 2015-03-17 21:54 GMT+08:00 jianwei li : > >> Hi >> Now,in my proposal,I want use the implemented paralle methods to >> implemente the cutting algorithm.But,do you have a guide line for the >> implemented paralle methods. >> Thank you >> Cheers >> Jianwei >> >> 2015-03-17 11:17 GMT+08:00 David Gobbi : >> >>> Hi Jianwei, >>> >>> You wouldn't directly use TBB or Kaapi, because VTK provides an abstract >>> SMP interface. This doxygen page provides a brief synopsis. The "Functor" >>> described on the page is a function-like object with the signature "void >>> func(vtkIdType first, vtkIdType last)" where vtkIdType is an integer type. >>> Basically, the SMP For() function is given a (first,last) range that covers >>> the entire data set, and divides it into smaller (first,last) sub-ranges >>> that the Functor operates on from within the worker threads. >>> http://www.vtk.org/doc/nightly/html/classvtkSMPTools.html >>> >>> To complete the picture, you can take a look at the Kaapi back end and >>> the TBB back end: >>> >>> https://gitlab.kitware.com/vtk/vtk/blob/master/Common/Core/SMP/Kaapi/vtkSMPToolsInternal.h.in >>> >>> https://gitlab.kitware.com/vtk/vtk/blob/master/Common/Core/SMP/TBB/vtkSMPToolsInternal.h.in >>> >>> So to answer your question, the proposal would be to write (and then >>> evaluate) an efficient parallel VTK algorithm that uses the abstract >>> interface described on the first web page. >>> >>> Cheers, >>> - David >>> >>> >>> On Mon, Mar 16, 2015 at 7:56 PM, jianwei li >>> wrote: >>> >>>> So,do I need to write a proposal to implement anyone algorithm using >>>> TBB or XKaapi >>>> >>>> 2015-03-17 3:59 GMT+08:00 Berk Geveci : >>>> >>>>> Maybe a brief Wiki page describing the overall volume splitting and >>>>> static thread assignment would be good. We can put a link from the project >>>>> page. Beyond that, when/if we pick a student for the project and Google >>>>> funds it, we can elaborate. >>>>> >>>>> -berk >>>>> >>>>> On Mon, Mar 16, 2015 at 3:17 PM, David Gobbi >>>>> wrote: >>>>> >>>>>> On Mon, Mar 16, 2015 at 12:52 PM, Berk Geveci < >>>>>> berk.geveci at kitware.com> wrote: >>>>>>> >>>>>>> >>>>>>> David: Is there a reference describing the VTK threaded image >>>>>>> algorithm infrastructure or do we just point to the code? >>>>>>> >>>>>> >>>>>> There's no reference for vtkThreadedImageAlgorithm that I'm aware of, >>>>>> though I can write something up on the wiki. Even though the code itself >>>>>> isn't very complicated, it would be hard to follow for anyone who isn't >>>>>> familiar with a) the streaming pipeline and b) the vtkMultiThreader. >>>>>> >>>>>> - David >>>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Mar 17 13:31:33 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 17 Mar 2015 10:31:33 -0700 Subject: [vtk-developers] Keeping in fork in sync Message-ID: How do I keep my fork in sync with the vtk repo? -- Unpaid intern in BillsBasement at noware dot com From brad.king at kitware.com Tue Mar 17 13:46:13 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 13:46:13 -0400 Subject: [vtk-developers] Keeping in fork in sync In-Reply-To: References: Message-ID: <55086865.70409@kitware.com> On 03/17/2015 01:31 PM, Bill Lorensen wrote: > How do I keep my fork in sync with the vtk repo? Whenever you do 'git gitlab-push' to push one of your topics it will also fetch 'master' from the main repo and push that to your fork along with your topic. In general you don't need to ever reference 'master' in your fork so it doesn't matter whether it stays updated. If you do want to update it manually you can do $ git checkout master $ git pull $ git push gitlab master -Brad From ken.martin at kitware.com Tue Mar 17 14:16:46 2015 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 17 Mar 2015 14:16:46 -0400 Subject: [vtk-developers] How to update someone else's topic (or create a new topic off of theirs) Message-ID: So I was doing a review of someone's merge request and I realized it needs some extra changes. Is there a way for me to download their topic (cherry pick?), make some more changes and then resubmit it? I saw lots of options to download a patch or diff for a topic but I do not want to lose their node/hash/whatever it is called. Is there a right way to do this. I did check the wiki but did not see a "revise someone else's topic". Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee.? Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message.? Thank you. -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Brad King Sent: Tuesday, March 17, 2015 1:46 PM To: Bill Lorensen Cc: VTK Developers Subject: Re: [vtk-developers] Keeping in fork in sync On 03/17/2015 01:31 PM, Bill Lorensen wrote: > How do I keep my fork in sync with the vtk repo? Whenever you do 'git gitlab-push' to push one of your topics it will also fetch 'master' from the main repo and push that to your fork along with your topic. In general you don't need to ever reference 'master' in your fork so it doesn't matter whether it stays updated. If you do want to update it manually you can do $ git checkout master $ git pull $ git push gitlab master -Brad _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers From brad.king at kitware.com Tue Mar 17 14:24:27 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 14:24:27 -0400 Subject: [vtk-developers] How to update someone else's topic (or create a new topic off of theirs) In-Reply-To: References: Message-ID: <5508715B.3030609@kitware.com> On 03/17/2015 02:16 PM, Ken Martin wrote: > So I was doing a review of someone's merge request and I realized it needs > some extra changes. Is there a way for me to download their topic (cherry > pick?), make some more changes and then resubmit it? I saw lots of options > to download a patch or diff for a topic but I do not want to lose their > node/hash/whatever it is called. Is there a right way to do this. I did > check the wiki but did not see a "revise someone else's topic". This is an area where GitLab's merge request workflow differs from Gerrit's. In GitLab the original submitter of the merge request is responsible for pushing all updates to the branch. There are a few options here: 1. You could checkout the branch locally, make the changes, and then ask the original submitter to fetch your version of the topic and 'git gitlab-push' it again to update the MR. 2. You could do the same but instead open your own MR and close the original. 3. You could work with the submitter directly in their repository. They can use the Setting tab in their GitLab fork to make you a developer that can push directly to their repository. In that case though the 'git gitlab-push' alias won't help you because it won't be configured to push to the right place. You'd have to push by hand. -Brad From bill.lorensen at gmail.com Tue Mar 17 14:25:51 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 17 Mar 2015 11:25:51 -0700 Subject: [vtk-developers] How to update someone else's topic (or create a new topic off of theirs) In-Reply-To: <5508715B.3030609@kitware.com> References: <5508715B.3030609@kitware.com> Message-ID: -1 On Tue, Mar 17, 2015 at 11:24 AM, Brad King wrote: > On 03/17/2015 02:16 PM, Ken Martin wrote: >> So I was doing a review of someone's merge request and I realized it needs >> some extra changes. Is there a way for me to download their topic (cherry >> pick?), make some more changes and then resubmit it? I saw lots of options >> to download a patch or diff for a topic but I do not want to lose their >> node/hash/whatever it is called. Is there a right way to do this. I did >> check the wiki but did not see a "revise someone else's topic". > > This is an area where GitLab's merge request workflow differs from Gerrit's. > In GitLab the original submitter of the merge request is responsible for > pushing all updates to the branch. There are a few options here: > > 1. You could checkout the branch locally, make the changes, and then ask > the original submitter to fetch your version of the topic and > 'git gitlab-push' it again to update the MR. > > 2. You could do the same but instead open your own MR and close the > original. > > 3. You could work with the submitter directly in their repository. They > can use the Setting tab in their GitLab fork to make you a developer > that can push directly to their repository. In that case though > the 'git gitlab-push' alias won't help you because it won't be > configured to push to the right place. You'd have to push by hand. > > -Brad > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- Unpaid intern in BillsBasement at noware dot com From kmorel at sandia.gov Tue Mar 17 14:46:14 2015 From: kmorel at sandia.gov (Moreland, Kenneth) Date: Tue, 17 Mar 2015 18:46:14 +0000 Subject: [vtk-developers] How to update someone else's topic (or create a new topic off of theirs) Message-ID: For solution number 2 below, is it really necessary to close the original merge request? Git is pretty good about managing the history DAG. If the original gets merged first and then the new, the second merge should include only those commits since the fork. If the the second gets merged before the original, I would expect git to do a no-op if you tried to merge the original. -Ken On 3/17/15, 12:24 PM, "Brad King" wrote: >On 03/17/2015 02:16 PM, Ken Martin wrote: >> So I was doing a review of someone's merge request and I realized it >>needs >> some extra changes. Is there a way for me to download their topic >>(cherry >> pick?), make some more changes and then resubmit it? I saw lots of >>options >> to download a patch or diff for a topic but I do not want to lose their >> node/hash/whatever it is called. Is there a right way to do this. I did >> check the wiki but did not see a "revise someone else's topic". > >This is an area where GitLab's merge request workflow differs from >Gerrit's. >In GitLab the original submitter of the merge request is responsible for >pushing all updates to the branch. There are a few options here: > >1. You could checkout the branch locally, make the changes, and then ask > the original submitter to fetch your version of the topic and > 'git gitlab-push' it again to update the MR. > >2. You could do the same but instead open your own MR and close the > original. > >3. You could work with the submitter directly in their repository. They > can use the Setting tab in their GitLab fork to make you a developer > that can push directly to their repository. In that case though > the 'git gitlab-push' alias won't help you because it won't be > configured to push to the right place. You'd have to push by hand. > >-Brad > >_______________________________________________ >Powered by www.kitware.com > >Visit other Kitware open-source projects at >http://www.kitware.com/opensource/opensource.html > >Search the list archives at: http://markmail.org/search/?q=vtk-developers > >Follow this link to subscribe/unsubscribe: >http://public.kitware.com/mailman/listinfo/vtk-developers > From bill.lorensen at gmail.com Tue Mar 17 14:47:14 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 17 Mar 2015 11:47:14 -0700 Subject: [vtk-developers] Cherry picking Message-ID: How do I cherry pick a topic from another users fork? With gerrit, I did almost all of my reviews using cherry-pick. This was very efficient and rarely required recompiling lots of files. -- Unpaid intern in BillsBasement at noware dot com From ken.martin at kitware.com Tue Mar 17 14:48:20 2015 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 17 Mar 2015 14:48:20 -0400 Subject: [vtk-developers] How to update someone else's topic (or create a new topic off of theirs) In-Reply-To: <5508715B.3030609@kitware.com> References: <5508715B.3030609@kitware.com> Message-ID: I apologize if these are stupid questions but I'm exploring this a tad further as it hits on the basic way we will collaborate on a topic and I want to make sure I do it the right way. So basically 1) Checkout their topic from their fork of VTK (the topic does not exist yet on other forks right?) 2) Do some work Then... I can push it to their fork if they add me as a developer on their fork. Can I push it to my fork even though my fork lacks their topic? Should I? They cannot fetch it from me unless I push it someplace public that they can see right? Where would that be? Github? Thanks! Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, March 17, 2015 2:24 PM To: Ken Martin Cc: VTK Developers Subject: Re: How to update someone else's topic (or create a new topic off of theirs) On 03/17/2015 02:16 PM, Ken Martin wrote: > So I was doing a review of someone's merge request and I realized it > needs some extra changes. Is there a way for me to download their > topic (cherry pick?), make some more changes and then resubmit it? I > saw lots of options to download a patch or diff for a topic but I do > not want to lose their node/hash/whatever it is called. Is there a > right way to do this. I did check the wiki but did not see a "revise > someone else's topic". This is an area where GitLab's merge request workflow differs from Gerrit's. In GitLab the original submitter of the merge request is responsible for pushing all updates to the branch. There are a few options here: 1. You could checkout the branch locally, make the changes, and then ask the original submitter to fetch your version of the topic and 'git gitlab-push' it again to update the MR. 2. You could do the same but instead open your own MR and close the original. 3. You could work with the submitter directly in their repository. They can use the Setting tab in their GitLab fork to make you a developer that can push directly to their repository. In that case though the 'git gitlab-push' alias won't help you because it won't be configured to push to the right place. You'd have to push by hand. -Brad From shawn.waldon at kitware.com Tue Mar 17 14:56:54 2015 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Tue, 17 Mar 2015 14:56:54 -0400 Subject: [vtk-developers] How to update someone else's topic (or create a new topic off of theirs) In-Reply-To: References: <5508715B.3030609@kitware.com> Message-ID: On Tue, Mar 17, 2015 at 2:48 PM, Ken Martin wrote: > I apologize if these are stupid questions but I'm exploring this a tad > further as it hits on the basic way we will collaborate on a topic and I > want to make sure I do it the right way. > > So basically > > 1) Checkout their topic from their fork of VTK (the topic does not exist > yet > on other forks right?) > Correct, the topic branch only exists on their fork. > > 2) Do some work > > Then... > > I can push it to their fork if they add me as a developer on their fork. > Yes. > > Can I push it to my fork even though my fork lacks their topic? Should I? > > Yes, it will create a branch on your fork with that name. The merge request will not be updated though. > They cannot fetch it from me unless I push it someplace public that they > can > see right? Where would that be? Github? > > In the Settings section of your fork you can make your fork public. Forks of public projects on Gitlab are public by default so unless you changed it your fork of VTK should be publicly visible. Then if they fetch that branch from your fork they will get your changes. HTH, Shawn > Thanks! > Ken > > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > ken.martin at kitware.com > 518 881-4901 (w) > 518 371-4573 (f) > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > > > -----Original Message----- > From: Brad King [mailto:brad.king at kitware.com] > Sent: Tuesday, March 17, 2015 2:24 PM > To: Ken Martin > Cc: VTK Developers > Subject: Re: How to update someone else's topic (or create a new topic off > of theirs) > > On 03/17/2015 02:16 PM, Ken Martin wrote: > > So I was doing a review of someone's merge request and I realized it > > needs some extra changes. Is there a way for me to download their > > topic (cherry pick?), make some more changes and then resubmit it? I > > saw lots of options to download a patch or diff for a topic but I do > > not want to lose their node/hash/whatever it is called. Is there a > > right way to do this. I did check the wiki but did not see a "revise > > someone else's topic". > > This is an area where GitLab's merge request workflow differs from > Gerrit's. > In GitLab the original submitter of the merge request is responsible for > pushing all updates to the branch. There are a few options here: > > 1. You could checkout the branch locally, make the changes, and then ask > the original submitter to fetch your version of the topic and > 'git gitlab-push' it again to update the MR. > > 2. You could do the same but instead open your own MR and close the > original. > > 3. You could work with the submitter directly in their repository. They > can use the Setting tab in their GitLab fork to make you a developer > that can push directly to their repository. In that case though > the 'git gitlab-push' alias won't help you because it won't be > configured to push to the right place. You'd have to push by hand. > > -Brad > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Tue Mar 17 14:57:31 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 17 Mar 2015 14:57:31 -0400 Subject: [vtk-developers] How to update someone else's topic (or create a new topic off of theirs) In-Reply-To: References: Message-ID: > For solution number 2 below, is it really necessary to close the original > merge request? Git is pretty good about managing the history DAG. If the > original gets merged first and then the new, the second merge should > include only those commits since the fork. If the the second gets merged > before the original, I would expect git to do a no-op if you tried to > merge the original. That's correct. The original merge request need not be closed, but better if it is since if the topic is amended (or rebased) then the two merge-requests would diverge. Utkarsh From david.gobbi at gmail.com Tue Mar 17 14:57:55 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 17 Mar 2015 12:57:55 -0600 Subject: [vtk-developers] How to update someone else's topic (or create a new topic off of theirs) In-Reply-To: References: <5508715B.3030609@kitware.com> Message-ID: It certainly was convenient that the Gerrit pages showed git commands that you could cut-and-paste to the terminal in order to checkout or cherry-pick whatever you were looking at. The ".zip", ".tar.gz", and "Download as" links that GitLab provides are kinda useless to developers. Ken, your fork is public and everyone can see it. You can fetch a branch from someone else's fork and push it, with modifications, to your own fork and ask them to take a look. The "origin" remote is vtk/vtk, the "gitlab" remote is ken-martin/vtk, and you could add a remote called "dgobbi" which would be my fork. So during collaborations, it will often be necessary to explicitly provide the remote and the branch name (or HEAD, which means "current branch"). - David On Tue, Mar 17, 2015 at 12:48 PM, Ken Martin wrote: > I apologize if these are stupid questions but I'm exploring this a tad > further as it hits on the basic way we will collaborate on a topic and I > want to make sure I do it the right way. > > So basically > > 1) Checkout their topic from their fork of VTK (the topic does not exist > yet > on other forks right?) > > 2) Do some work > > Then... > > I can push it to their fork if they add me as a developer on their fork. > > Can I push it to my fork even though my fork lacks their topic? Should I? > > They cannot fetch it from me unless I push it someplace public that they > can > see right? Where would that be? Github? > > Thanks! > Ken > > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > ken.martin at kitware.com > 518 881-4901 (w) > 518 371-4573 (f) > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > > > -----Original Message----- > From: Brad King [mailto:brad.king at kitware.com] > Sent: Tuesday, March 17, 2015 2:24 PM > To: Ken Martin > Cc: VTK Developers > Subject: Re: How to update someone else's topic (or create a new topic off > of theirs) > > On 03/17/2015 02:16 PM, Ken Martin wrote: > > So I was doing a review of someone's merge request and I realized it > > needs some extra changes. Is there a way for me to download their > > topic (cherry pick?), make some more changes and then resubmit it? I > > saw lots of options to download a patch or diff for a topic but I do > > not want to lose their node/hash/whatever it is called. Is there a > > right way to do this. I did check the wiki but did not see a "revise > > someone else's topic". > > This is an area where GitLab's merge request workflow differs from > Gerrit's. > In GitLab the original submitter of the merge request is responsible for > pushing all updates to the branch. There are a few options here: > > 1. You could checkout the branch locally, make the changes, and then ask > the original submitter to fetch your version of the topic and > 'git gitlab-push' it again to update the MR. > > 2. You could do the same but instead open your own MR and close the > original. > > 3. You could work with the submitter directly in their repository. They > can use the Setting tab in their GitLab fork to make you a developer > that can push directly to their repository. In that case though > the 'git gitlab-push' alias won't help you because it won't be > configured to push to the right place. You'd have to push by hand. > > -Brad > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue Mar 17 15:05:10 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 17 Mar 2015 15:05:10 -0400 Subject: [vtk-developers] Cherry picking In-Reply-To: References: Message-ID: <20150317190510.GA10675@megas.kitwarein.com> On Tue, Mar 17, 2015 at 11:47:14 -0700, Bill Lorensen wrote: > How do I cherry pick a topic from another users fork? > > With gerrit, I did almost all of my reviews using cherry-pick. This > was very efficient and rarely required recompiling lots of files. For the pull-request-style workflow, I usually add other developers' forks as a remote and then fetch it: $ git remote add gl/$username https://gitlab.kitware.com/$username/$project.git $ git fetch gl/$username $ git log -p master..gl/$username/$branch # view changes $ git cherry-pick master..gl/$username/$branch # apply changes --Ben From brad.king at kitware.com Tue Mar 17 15:08:23 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 17 Mar 2015 15:08:23 -0400 Subject: [vtk-developers] Cherry picking In-Reply-To: <20150317190510.GA10675@megas.kitwarein.com> References: <20150317190510.GA10675@megas.kitwarein.com> Message-ID: <55087BA7.8020001@kitware.com> On 03/17/2015 03:05 PM, Ben Boeckel wrote: > For the pull-request-style workflow, I usually add other developers' > forks as a remote and then fetch it: > > $ git remote add gl/$username https://gitlab.kitware.com/$username/$project.git > $ git fetch gl/$username > $ git log -p master..gl/$username/$branch # view changes Good. > $ git cherry-pick master..gl/$username/$branch # apply changes You could also just create a temporary branch to merge the topic you're reviewing: $ git checkout -b try-theirs $ git merge gl/$username/$branch (test it) $ git checkout - (should switch back to where you were) $ git branch -D try-theirs -Brad From ben.boeckel at kitware.com Tue Mar 17 16:01:44 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 17 Mar 2015 16:01:44 -0400 Subject: [vtk-developers] Cherry picking In-Reply-To: <55087BA7.8020001@kitware.com> References: <20150317190510.GA10675@megas.kitwarein.com> <55087BA7.8020001@kitware.com> Message-ID: <20150317200144.GA6047@megas.kitwarein.com> On Tue, Mar 17, 2015 at 15:08:23 -0400, Brad King wrote: > You could also just create a temporary branch to merge the topic > you're reviewing: > > $ git checkout -b try-theirs > $ git merge gl/$username/$branch > (test it) > $ git checkout - > (should switch back to where you were) > $ git branch -D try-theirs I think the point was to get *just* their changes on top of what has already been built so as to not have to rebuild everything. Fine for review, not for actual testing. --Ben From bill.lorensen at gmail.com Tue Mar 17 17:05:39 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 17 Mar 2015 14:05:39 -0700 Subject: [vtk-developers] Cherry picking In-Reply-To: <20150317200144.GA6047@megas.kitwarein.com> References: <20150317190510.GA10675@megas.kitwarein.com> <55087BA7.8020001@kitware.com> <20150317200144.GA6047@megas.kitwarein.com> Message-ID: Yes, the point is to not have to rebuild everything. I have slow computers. I guess I have an unusual workflow. 1) I keep my local copy up-to-date with master. 2) I almost always cherry pick and rebase on master. 3) Testing is better since I always test against master. This points out errors and conflicts against master. And, If I see need for many changes, I used to summit a new patch to the originator's patch. For me, the new workflow is less productive. I will give it a try. But I suspect my contributions will drop off. Bill On Tue, Mar 17, 2015 at 1:01 PM, Ben Boeckel wrote: > On Tue, Mar 17, 2015 at 15:08:23 -0400, Brad King wrote: >> You could also just create a temporary branch to merge the topic >> you're reviewing: >> >> $ git checkout -b try-theirs >> $ git merge gl/$username/$branch >> (test it) >> $ git checkout - >> (should switch back to where you were) >> $ git branch -D try-theirs > > I think the point was to get *just* their changes on top of what has > already been built so as to not have to rebuild everything. Fine for > review, not for actual testing. > > --Ben -- Unpaid intern in BillsBasement at noware dot com From utkarsh.ayachit at kitware.com Tue Mar 17 17:10:38 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 17 Mar 2015 17:10:38 -0400 Subject: [vtk-developers] Cherry picking In-Reply-To: References: <20150317190510.GA10675@megas.kitwarein.com> <55087BA7.8020001@kitware.com> <20150317200144.GA6047@megas.kitwarein.com> Message-ID: > I will give it a try. But I suspect my contributions will drop off. That'd be a shame! I am sure we can come up with an alias or something that'd make this easier -- let's give it a little time to settle. There's work happening behind the screens for moving ParaView to gitlab. Once that's live and well, we can focus on ironing out these kinks. Utkarsh From will.schroeder at kitware.com Tue Mar 17 17:18:10 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Tue, 17 Mar 2015 17:18:10 -0400 Subject: [vtk-developers] Cherry picking In-Reply-To: References: <20150317190510.GA10675@megas.kitwarein.com> <55087BA7.8020001@kitware.com> <20150317200144.GA6047@megas.kitwarein.com> Message-ID: I agree with Utkarsh. My old brain cells are definitely grumbling at the moment since all I want to do is write algorithms and not jump through hoops ;-) but with enough feedback and the smarts of this community I believe that we will make this work. After all we eventually made gerrit work .... W On Tue, Mar 17, 2015 at 5:10 PM, Utkarsh Ayachit < utkarsh.ayachit at kitware.com> wrote: > > I will give it a try. But I suspect my contributions will drop off. > > That'd be a shame! I am sure we can come up with an alias or something > that'd make this easier -- let's give it a little time to settle. > There's work happening behind the screens for moving ParaView to > gitlab. Once that's live and well, we can focus on ironing out these > kinks. > > Utkarsh > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Mar 17 17:27:35 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 17 Mar 2015 14:27:35 -0700 Subject: [vtk-developers] Cherry picking In-Reply-To: References: <20150317190510.GA10675@megas.kitwarein.com> <55087BA7.8020001@kitware.com> <20150317200144.GA6047@megas.kitwarein.com> Message-ID: I think I can download patches and use them in a new branch. On Tue, Mar 17, 2015 at 2:18 PM, Will Schroeder wrote: > I agree with Utkarsh. My old brain cells are definitely grumbling at the > moment since all I want to do is write algorithms and not jump through hoops > ;-) but with enough feedback and the smarts of this community I believe that > we will make this work. After all we eventually made gerrit work .... > > W > > On Tue, Mar 17, 2015 at 5:10 PM, Utkarsh Ayachit > wrote: >> >> > I will give it a try. But I suspect my contributions will drop off. >> >> That'd be a shame! I am sure we can come up with an alias or something >> that'd make this easier -- let's give it a little time to settle. >> There's work happening behind the screens for moving ParaView to >> gitlab. Once that's live and well, we can focus on ironing out these >> kinks. >> >> Utkarsh >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > > > > -- > William J. Schroeder, PhD > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 -- Unpaid intern in BillsBasement at noware dot com From deevankshu096 at gmail.com Wed Mar 18 08:18:06 2015 From: deevankshu096 at gmail.com (DEEVANKSHU GARG) Date: Wed, 18 Mar 2015 17:48:06 +0530 Subject: [vtk-developers] GSoC 2015-CAD Model and Simulation Spline Visualization Message-ID: Hello all ! My name is Deevankshu Garg. I'm in my second year , studying Computer Science at the Birla Institute of Technology and Science , Pilani , India. I've taken a keen interest in Computer Graphics/OpenGL for the last 2 semesters and am very excited to apply for GSOC under VTK. The project "CAD Model and Simulation Spline Visualization" is of particular interest to me.Curves and NURBS Modelling has been a project of mine at a personal level(https://github.com/gargd/Here-I-come-NURBS & https://github.com/gargd/Bezier-curves-and-surfaces).Also,I have been into modelling all kinds of stuff in Autodesk Maya from the past 1 year which has made clear in my mind the concept of curves and splines and their proper implementation requirements for the accurate visualization.I have also done a bit of Python scripting in Maya.I am also experienced with using CAD at an academic level as part of our Engineering Graphics course in my first year at college. About the project,there are some points I want to discuss and some questions I want to ask.First of all,implementation of IGA techniques for mesh rendering would be great addition for something as powerful as VTK.I have been reading a lot about IsoGeometric Analysis these days.Besides its obvious advantages of being easily integrated with CAD and the high level of solution accuracy,we also have the advantage of not having to write the whole code from scratch and reusing the earlier present FEM code.I have thought of a rough idea about implementing the project- 1.A new mesh representation class- This would include- a. h-refinement(knot insertion) for one and two dimensional meshes. b. p-refinement(order elevation) and k-refinement using Geopdes library. c.Extended IGA for hole,inclusion and crack modelling using variational formulas. d.Bezier extraction-to integrate isogeometric analysis with existing FEM codes. e.Visualization of displacements and stresses. 2.Contouring- This would basically include creating new classes like the following ones- a.crackedMesh: visualize cracked mesh as truly cracked domain. b.crackedMeshNURBS: the same but for higher order NURBS. c.plotStress: compute displacements and stresses at nodes of a visualization mesh. 3.Cutting- a.elements cut by cracks:sub-triangulation b.elements cut by circular holes/inclusions:adaptive sub-cells. Things I want to ask- a.You mentioned about conversion to handle the variety of spline formats (T-Splines, NURBS, Catmull-Clark surfaces, etc.).Would an object oriented design be more beneficial with the B-splines sitting at the top of the heirarchy? b.IGA techniques are mainly for analysis and meshing,what does it have to do with rendering.Shouldn't the rendering techniques remain the same?We can obviously optimise rendering,but it wouldn't be a part of IGA,right? Please tell me what you all think about it!All the feedback is valuable! Thanks a lot for reading! Regards, Deevankshu Garg (https://github.com/gargd) -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Wed Mar 18 08:57:33 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 18 Mar 2015 08:57:33 -0400 Subject: [vtk-developers] Cherry picking In-Reply-To: References: <20150317190510.GA10675@megas.kitwarein.com> <55087BA7.8020001@kitware.com> <20150317200144.GA6047@megas.kitwarein.com> Message-ID: I am sorry because I am probably about to ask something stupid. Isn't this what you want Bill? $ git remote add gl/$username https://gitlab.kitware.com/$username/$project.git $ git fetch gl/$username $ git log -p master..gl/$username/$branch # view changes $ git cherry-pick master..gl/$username/$branch # apply changes This looks identical to the Gerrit workflow where you fetch and cherry-pick or rebase. Once you fetch from a particular branch, you should be able to do anything with it without fully updating to that branch? -berk On Tue, Mar 17, 2015 at 5:27 PM, Bill Lorensen wrote: > I think I can download patches and use them in a new branch. > > > On Tue, Mar 17, 2015 at 2:18 PM, Will Schroeder > wrote: > > I agree with Utkarsh. My old brain cells are definitely grumbling at the > > moment since all I want to do is write algorithms and not jump through > hoops > > ;-) but with enough feedback and the smarts of this community I believe > that > > we will make this work. After all we eventually made gerrit work .... > > > > W > > > > On Tue, Mar 17, 2015 at 5:10 PM, Utkarsh Ayachit > > wrote: > >> > >> > I will give it a try. But I suspect my contributions will drop off. > >> > >> That'd be a shame! I am sure we can come up with an alias or something > >> that'd make this easier -- let's give it a little time to settle. > >> There's work happening behind the screens for moving ParaView to > >> gitlab. Once that's live and well, we can focus on ironing out these > >> kinks. > >> > >> Utkarsh > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the list archives at: > http://markmail.org/search/?q=vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > > > > > > > > -- > > William J. Schroeder, PhD > > Kitware, Inc. > > 28 Corporate Drive > > Clifton Park, NY 12065 > > will.schroeder at kitware.com > > http://www.kitware.com > > (518) 881-4902 > > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Wed Mar 18 09:59:34 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 18 Mar 2015 09:59:34 -0400 Subject: [vtk-developers] How to update someone else's topic (or create a new topic off of theirs) In-Reply-To: References: <5508715B.3030609@kitware.com> Message-ID: On Tue, Mar 17, 2015 at 2:57 PM, David Gobbi wrote: > It certainly was convenient that the Gerrit pages showed git commands that > you could cut-and-paste to the terminal in order to checkout or cherry-pick > whatever you were looking at. > +1. How much control do we have over the gitlab UI? Could we show a one-liner to pull a topic from a fork? Creating the remotes manually, updating them, and pulling isn't a ton of work, but the gerrit one-liner made everything a lot easier. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Mar 18 10:37:38 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 18 Mar 2015 10:37:38 -0400 Subject: [vtk-developers] How to update someone else's topic (or create a new topic off of theirs) In-Reply-To: References: <5508715B.3030609@kitware.com> Message-ID: <20150318143738.GA21235@megas.kitwarein.com> On Wed, Mar 18, 2015 at 09:59:34 -0400, David Lonie wrote: > +1. How much control do we have over the gitlab UI? Could we show a > one-liner to pull a topic from a fork? How much code do you want to write? ;) More seriously though, that is probably simpler. > Creating the remotes manually, updating them, and pulling isn't a ton of > work, but the gerrit one-liner made everything a lot easier. Until then, the robot could add a command line to use in its review comment. --Ben From david.lonie at kitware.com Wed Mar 18 10:40:07 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 18 Mar 2015 10:40:07 -0400 Subject: [vtk-developers] How to update someone else's topic (or create a new topic off of theirs) In-Reply-To: <20150318143738.GA21235@megas.kitwarein.com> References: <5508715B.3030609@kitware.com> <20150318143738.GA21235@megas.kitwarein.com> Message-ID: On Wed, Mar 18, 2015 at 10:37 AM, Ben Boeckel wrote: > On Wed, Mar 18, 2015 at 09:59:34 -0400, David Lonie wrote: > > +1. How much control do we have over the gitlab UI? Could we show a > > one-liner to pull a topic from a fork? > > How much code do you want to write? ;) More seriously though, that is > probably simpler. > Me? None! :D > Creating the remotes manually, updating them, and pulling isn't a ton of > > work, but the gerrit one-liner made everything a lot easier. > > Until then, the robot could add a command line to use in its review > comment. > This would be a very useful addition. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Wed Mar 18 10:41:25 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 18 Mar 2015 07:41:25 -0700 Subject: [vtk-developers] Cherry picking In-Reply-To: References: <20150317190510.GA10675@megas.kitwarein.com> <55087BA7.8020001@kitware.com> <20150317200144.GA6047@megas.kitwarein.com> Message-ID: I'll have to try it. For now, downloading the patch seems to work. On Wed, Mar 18, 2015 at 5:57 AM, Berk Geveci wrote: > I am sorry because I am probably about to ask something stupid. Isn't this > what you want Bill? > > $ git remote add gl/$username > https://gitlab.kitware.com/$username/$project.git > $ git fetch gl/$username > $ git log -p master..gl/$username/$branch # view changes > $ git cherry-pick master..gl/$username/$branch # apply changes > > This looks identical to the Gerrit workflow where you fetch and cherry-pick > or rebase. Once you fetch from a particular branch, you should be able to do > anything with it without fully updating to that branch? > > -berk > > > On Tue, Mar 17, 2015 at 5:27 PM, Bill Lorensen > wrote: >> >> I think I can download patches and use them in a new branch. >> >> >> On Tue, Mar 17, 2015 at 2:18 PM, Will Schroeder >> wrote: >> > I agree with Utkarsh. My old brain cells are definitely grumbling at the >> > moment since all I want to do is write algorithms and not jump through >> > hoops >> > ;-) but with enough feedback and the smarts of this community I believe >> > that >> > we will make this work. After all we eventually made gerrit work .... >> > >> > W >> > >> > On Tue, Mar 17, 2015 at 5:10 PM, Utkarsh Ayachit >> > wrote: >> >> >> >> > I will give it a try. But I suspect my contributions will drop off. >> >> >> >> That'd be a shame! I am sure we can come up with an alias or something >> >> that'd make this easier -- let's give it a little time to settle. >> >> There's work happening behind the screens for moving ParaView to >> >> gitlab. Once that's live and well, we can focus on ironing out these >> >> kinks. >> >> >> >> Utkarsh >> >> _______________________________________________ >> >> Powered by www.kitware.com >> >> >> >> Visit other Kitware open-source projects at >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> Search the list archives at: >> >> http://markmail.org/search/?q=vtk-developers >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > >> > >> > >> > -- >> > William J. Schroeder, PhD >> > Kitware, Inc. >> > 28 Corporate Drive >> > Clifton Park, NY 12065 >> > will.schroeder at kitware.com >> > http://www.kitware.com >> > (518) 881-4902 >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > -- Unpaid intern in BillsBasement at noware dot com From bill.lorensen at gmail.com Wed Mar 18 10:46:56 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 18 Mar 2015 07:46:56 -0700 Subject: [vtk-developers] How to update someone else's topic (or create a new topic off of theirs) In-Reply-To: References: <5508715B.3030609@kitware.com> <20150318143738.GA21235@megas.kitwarein.com> Message-ID: I assume we DO NOT want to make any changes to the gitlab code. Recall what happened when we changed gerrit. Mucking with the robot sounds like the way to go. On Wed, Mar 18, 2015 at 7:40 AM, David Lonie wrote: > On Wed, Mar 18, 2015 at 10:37 AM, Ben Boeckel > wrote: >> >> On Wed, Mar 18, 2015 at 09:59:34 -0400, David Lonie wrote: >> > +1. How much control do we have over the gitlab UI? Could we show a >> > one-liner to pull a topic from a fork? >> >> How much code do you want to write? ;) More seriously though, that is >> probably simpler. > > > Me? None! :D > >> > Creating the remotes manually, updating them, and pulling isn't a ton of >> > work, but the gerrit one-liner made everything a lot easier. >> >> Until then, the robot could add a command line to use in its review >> comment. > > > This would be a very useful addition. > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From utkarsh.ayachit at kitware.com Wed Mar 18 10:49:50 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Wed, 18 Mar 2015 10:49:50 -0400 Subject: [vtk-developers] Git FAQ in progress Message-ID: Folks, I've created a new merge-request collecting all the questions about the new Gitlab/Git workflow in an FAQ. We'll keep updating this in the next week or so to make the transition easier. Keep asking questions and let's figure out the workflow that works best for all of us! https://gitlab.kitware.com/vtk/vtk/merge_requests/15 Utkarsh From berk.geveci at kitware.com Wed Mar 18 11:02:00 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 18 Mar 2015 11:02:00 -0400 Subject: [vtk-developers] How to update someone else's topic (or create a new topic off of theirs) In-Reply-To: References: <5508715B.3030609@kitware.com> <20150318143738.GA21235@megas.kitwarein.com> Message-ID: We should consider making changes to the Gitlab code to make our lives easier. Before doing anything that would be hard to move forward on our own, we would have an open conversation with the Gitlab folks about getting contributions upstream. I'd rather we started our relationship with Gitlab fresh and not have it be tainted by our Gerrit experience. -berk On Wed, Mar 18, 2015 at 10:46 AM, Bill Lorensen wrote: > I assume we DO NOT want to make any changes to the gitlab code. Recall > what happened when we changed gerrit. > > Mucking with the robot sounds like the way to go. > > > On Wed, Mar 18, 2015 at 7:40 AM, David Lonie > wrote: > > On Wed, Mar 18, 2015 at 10:37 AM, Ben Boeckel > > wrote: > >> > >> On Wed, Mar 18, 2015 at 09:59:34 -0400, David Lonie wrote: > >> > +1. How much control do we have over the gitlab UI? Could we show a > >> > one-liner to pull a topic from a fork? > >> > >> How much code do you want to write? ;) More seriously though, that is > >> probably simpler. > > > > > > Me? None! :D > > > >> > Creating the remotes manually, updating them, and pulling isn't a ton > of > >> > work, but the gerrit one-liner made everything a lot easier. > >> > >> Until then, the robot could add a command line to use in its review > >> comment. > > > > > > This would be a very useful addition. > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Mar 18 11:29:42 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 18 Mar 2015 11:29:42 -0400 Subject: [vtk-developers] How to update someone else's topic (or create a new topic off of theirs) In-Reply-To: References: <5508715B.3030609@kitware.com> <20150318143738.GA21235@megas.kitwarein.com> Message-ID: <20150318152942.GA24019@megas.kitwarein.com> On Wed, Mar 18, 2015 at 11:02:00 -0400, Berk Geveci wrote: > We should consider making changes to the Gitlab code to make our lives > easier. Before doing anything that would be hard to move forward on our > own, we would have an open conversation with the Gitlab folks about getting > contributions upstream. I'd rather we started our relationship with Gitlab > fresh and not have it be tainted by our Gerrit experience. FWIW, there are a (few) changes to our GitLab install already (changes are here[1]) which have been required for the kwrobot to actually get notified of everything it needs to be able to do its tasks effectively. GitLab's merge window is the 1st to the 7th of every month; I need to make a MR for each of these features individually and then we can get feedback from upstream about it early next month. Once these "need to have" things go in, we can look at more cosmetic changes such as adding a "fetch" command. For now, the robot can make a command line which doesn't require any gitlab changes. (Working on that now.) --Ben [1]https://github.com/mathstuf/gitlabhq/tree/additional-hook-triggers From robert.maynard at kitware.com Wed Mar 18 11:44:28 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 18 Mar 2015 11:44:28 -0400 Subject: [vtk-developers] How to update someone else's topic (or create a new topic off of theirs) In-Reply-To: <20150318152942.GA24019@megas.kitwarein.com> References: <5508715B.3030609@kitware.com> <20150318143738.GA21235@megas.kitwarein.com> <20150318152942.GA24019@megas.kitwarein.com> Message-ID: It is unfortunate that gitlab doesn't use the github model of having pull requests placed in refs/pull/ or this could be easier too. On Wed, Mar 18, 2015 at 11:29 AM, Ben Boeckel wrote: > On Wed, Mar 18, 2015 at 11:02:00 -0400, Berk Geveci wrote: > > We should consider making changes to the Gitlab code to make our lives > > easier. Before doing anything that would be hard to move forward on our > > own, we would have an open conversation with the Gitlab folks about > getting > > contributions upstream. I'd rather we started our relationship with > Gitlab > > fresh and not have it be tainted by our Gerrit experience. > > FWIW, there are a (few) changes to our GitLab install already (changes > are here[1]) which have been required for the kwrobot to actually get > notified of everything it needs to be able to do its tasks effectively. > > GitLab's merge window is the 1st to the 7th of every month; I need to > make a MR for each of these features individually and then we can get > feedback from upstream about it early next month. > > Once these "need to have" things go in, we can look at more cosmetic > changes such as adding a "fetch" command. > > For now, the robot can make a command line which doesn't require any > gitlab changes. (Working on that now.) > > --Ben > > [1]https://github.com/mathstuf/gitlabhq/tree/additional-hook-triggers > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Mar 18 12:02:11 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 18 Mar 2015 12:02:11 -0400 Subject: [vtk-developers] How to update someone else's topic (or create a new topic off of theirs) In-Reply-To: References: <5508715B.3030609@kitware.com> <20150318143738.GA21235@megas.kitwarein.com> <20150318152942.GA24019@megas.kitwarein.com> Message-ID: <20150318160211.GA32242@megas.kitwarein.com> On Wed, Mar 18, 2015 at 11:44:28 -0400, Robert Maynard wrote: > It is unfortunate that gitlab doesn't use the github model of having pull > requests placed in refs/pull/ or this could be easier too. Vote here[1]. --Ben [1]http://feedback.gitlab.com/forums/176466-general/suggestions/6581273-create-merge-result-refs-for-merge-requests From david.thompson at kitware.com Wed Mar 18 12:09:17 2015 From: david.thompson at kitware.com (David Thompson) Date: Wed, 18 Mar 2015 12:09:17 -0400 Subject: [vtk-developers] GSoC 2015-CAD Model and Simulation Spline Visualization In-Reply-To: References: Message-ID: <6BD334A2-5477-42A1-B500-6F2B4827A511@kitware.com> Hi Deevankshu, > The project "CAD Model and Simulation Spline Visualization" is of particular interest to me.Curves and NURBS Modelling has been a project of mine at a personal level(https://github.com/gargd/Here-I-come-NURBS & https://github.com/gargd/Bezier-curves-and-surfaces). Those are nice examples, but they use the OpenGL GLU toolkit to evaluate the spline. Just to be clear, we are interested in adding implementations of evaluation and inversion to VTK, not using GLU to perform those operations. > ... About the project,there are some points I want to discuss and some questions I want to ask. ... Besides its obvious advantages of being easily integrated with CAD and the high level of solution accuracy, we also have the advantage of not having to write the whole code from scratch and reusing the earlier present FEM code. Using a FEM solver's evaluation and interpolation methods is one way to go, but the issues involved are 1. Many isogeometric analysis (IGA) codes use slightly different spline or patch formulations. We want to accommodate them all, not just a few. 2. I do not know of open source IGA implementations which cover the gamut of interpolation techniques whose source we could borrow. That is why we are aiming to provide operations on basic rational B?zier patches. The B?zier patch operations would not access control point arrays directly but use iterators so that different IGA formulations could provide B?zier patch iterators to access their underlying meshes. > I have thought of a rough idea about implementing the project- > > 1.A new mesh representation class- > This would include- > a. h-refinement(knot insertion) for one and two dimensional meshes. > b. p-refinement(order elevation) and k-refinement using Geopdes library. Unfortunately, the GeoPDEs library is licensed under the GPL. VTK cannot include GPL code without changing its license. > c.Extended IGA for hole,inclusion and crack modelling using variational formulas. This is interesting, but the first job is to implement basic evaluation and inversion methods along with cutting and clipping. > d.Bezier extraction-to integrate isogeometric analysis with existing FEM codes. This is the route we are hoping to take. > e.Visualization of displacements and stresses. > > 2.Contouring- > This would basically include creating new classes like the following ones- > a.crackedMesh: visualize cracked mesh as truly cracked domain. > b.crackedMeshNURBS: the same but for higher order NURBS. > c.plotStress: compute displacements and stresses at nodes of a visualization mesh. The way the VTK framework is written, these would not be individual classes but different combinations of classes into pipelines. > 3.Cutting- > a.elements cut by cracks:sub-triangulation > b.elements cut by circular holes/inclusions:adaptive sub-cells. We do not care so much about what shape the cut is, but rather how the cut is computationally represented; is it an implicit function? a spline in world coordinates or parameter space? a simple plane? By providing some basic functionality, the cases above (plus others) can be handled with a small effort. > Things I want to ask- > a.You mentioned about conversion to handle the variety of spline formats (T-Splines, NURBS, Catmull-Clark surfaces, etc.).Would an object oriented design be more beneficial ... Yes. I think the first step would be to provide a base class that allows iteration over a set of B?zier patches that, taken together, represent the spline curve, surface, or volume. > ... with the B-splines sitting at the top of the heirarchy? A B-spline formulation could be at the top of *one* hierarchy, but it would have siblings for other formats like T-splines. > b.IGA techniques are mainly for analysis and meshing,what does it have to do with rendering. Rendering is only part of visualization. It is important to provide analysis tools for post-processing to - find the range of values taken on over a mesh and the location of the extremal values. - compute derivative values and inspect them - divide the mesh into regions based on scalar values or spatial cuts to make inspection of the quantities defined on the mesh (e.g., stress, strain, temperature) possible. > Shouldn't the rendering techniques remain the same? I am unsure what you mean by this? The same as what? > We can obviously optimise rendering,but it wouldn't be a part of IGA,right? Rendering would involve evaluating patches provided by an IGA mesh at regular locations and connecting the evaluated points into a simplicial mesh (line segments in 1-D, triangles in 2-D, tetrahedra in 3-D) for either rendering or further post-processing. One example of post-processing is deflecting the evaluated points using the strain field computed by IGA. > ... > Thanks a lot for reading! I look forward to reading your proposal when you submit it to GSoC. David From chuck.atkins at kitware.com Wed Mar 18 14:12:32 2015 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 18 Mar 2015 14:12:32 -0400 Subject: [vtk-developers] RFC: Compiler support, removing hacks for old compilers In-Reply-To: <20150316180926.1146005295@mail.rogue-research.com> References: <20150316180926.1146005295@mail.rogue-research.com> Message-ID: > > I'd be interested to know from the community what are the oldest compilers > you care about? Anyone out there using a compiler older than 5 years or so? > I'd say for gcc, 4.1.x is likely the oldest you'd need to bother with. That's the system compiler for RHEL5 and SLES10, both of which are EOL'd but still actively deployed. That being said, chances are pretty high that even on those systems, you'd have a newer compiler available via system packages. RHEL5.5 and up has /usr/bin/gcc44 and SLES 10 has /usr/bin/gcc-4.3, both available as system packages and an alternative to the older /usr/bin/gcc used to compiler their respective kernels. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wascott at sandia.gov Wed Mar 18 14:46:04 2015 From: wascott at sandia.gov (Scott, W Alan) Date: Wed, 18 Mar 2015 18:46:04 +0000 Subject: [vtk-developers] [EXTERNAL] Re: RFC: Compiler support, removing hacks for old compilers In-Reply-To: References: <20150316180926.1146005295@mail.rogue-research.com> Message-ID: <89947a5813a84dc5842498245df50dd6@ES05AMSNLNT.srn.sandia.gov> Ditto for us. 4.1.2 is the oldest we seem to have. Alan From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Chuck Atkins Sent: Wednesday, March 18, 2015 12:13 PM To: Sean McBride Cc: VTK Developers; vtkusers at vtk.org Subject: [EXTERNAL] Re: [vtk-developers] RFC: Compiler support, removing hacks for old compilers I'd be interested to know from the community what are the oldest compilers you care about? Anyone out there using a compiler older than 5 years or so? I'd say for gcc, 4.1.x is likely the oldest you'd need to bother with. That's the system compiler for RHEL5 and SLES10, both of which are EOL'd but still actively deployed. That being said, chances are pretty high that even on those systems, you'd have a newer compiler available via system packages. RHEL5.5 and up has /usr/bin/gcc44 and SLES 10 has /usr/bin/gcc-4.3, both available as system packages and an alternative to the older /usr/bin/gcc used to compiler their respective kernels. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Wed Mar 18 16:57:38 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 18 Mar 2015 16:57:38 -0400 Subject: [vtk-developers] How to request reviewer of a topic In-Reply-To: <55083861.5040104@kitware.com> References: <550820A6.3020207@kitware.com> <55083861.5040104@kitware.com> Message-ID: In merge request Write field, @ only seems to give me a menu with vtk or demarle on it. The assign to menu doesn't seem to have a Brad King in it, until I start typing there. This is under Safari. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Mar 17, 2015 at 10:21 AM, Brad King wrote: > On 03/17/2015 10:18 AM, Bill Lorensen wrote: > > How do I know the usernames? For example, I see Ken Martin's name is > > ken-martin. My name is lorensen. > > You should just be able to start typing > > @RealName > > and it will come up with completions for available developers whose > real name or user name matches what you typed. > > -Brad > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Wed Mar 18 17:16:11 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 18 Mar 2015 17:16:11 -0400 Subject: [vtk-developers] cdash@home, er buildbots and cdash? Message-ID: Buildbot builds show up in experimental track right now correct? The files changed column for these submission are empty. Perhaps because of that I don't have the these are your changes indicators either. (I assume they are my changes, but I don't know for sure since I haven't read enough to see where I get to that via gitlab). David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Wed Mar 18 17:45:11 2015 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Wed, 18 Mar 2015 17:45:11 -0400 Subject: [vtk-developers] cdash@home, er buildbots and cdash? In-Reply-To: References: Message-ID: On Wed, Mar 18, 2015 at 5:16 PM, David E DeMarle wrote: > Buildbot builds show up in experimental track right now correct? > > Correct > The files changed column for these submission are empty. Perhaps because > of that I don't have the these are your changes indicators either. (I > assume they are my changes, but I don't know for sure since I haven't read > enough to see where I get to that via gitlab). > > That is a limitation of the current buildbot setup: ctest no longer knows what files changed. So you no longer the the indicators for your changes. We may fix this later, but when buildbot starts its builds it will post a link on the merge request to cdash with filters set up so that only the builds for the current branch tests are visible. This is the best way to find builds of your changes for now. David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Mar 18 18:22:09 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 18 Mar 2015 18:22:09 -0400 Subject: [vtk-developers] cdash@home, er buildbots and cdash? In-Reply-To: References: Message-ID: <20150318222209.GB11391@megas.kitwarein.com> On Wed, Mar 18, 2015 at 17:16:11 -0400, David E DeMarle wrote: > Buildbot builds show up in experimental track right now correct? Actually, forgot to tell you; if you add "master" and "buildbot" tracks to CDash, they should show up there (I don't have CDash super powers for VTK). > The files changed column for these submission are empty. Perhaps because of > that I don't have the these are your changes indicators either. (I assume > they are my changes, but I don't know for sure since I haven't read enough > to see where I get to that via gitlab). There is a TODO to have buildbot comment back on the MR once the build is done (and another TODO for kwrobot to gate[1] "Do: merge" based on buildbot's results if they exist). It will likely add the following information (and probably some more prose-like description of failures): On success: Tested-by: @buildbot Acked-by: @buildbot Branch-at: ... On failure: Rejected-by: @buildbot Branch-at: ... --Ben [1]"Masters" might be given a "Do: merge force" option to ignore buildbot; what VTK, ParaView, etc. want should be discussed. From ben.boeckel at kitware.com Wed Mar 18 18:24:16 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 18 Mar 2015 18:24:16 -0400 Subject: [vtk-developers] How to request reviewer of a topic In-Reply-To: References: <550820A6.3020207@kitware.com> <55083861.5040104@kitware.com> Message-ID: <20150318222416.GC11391@megas.kitwarein.com> On Wed, Mar 18, 2015 at 16:57:38 -0400, David E DeMarle wrote: > In merge request Write field, @ only seems to give me a menu with vtk or > demarle on it. The assign to menu doesn't seem to have a Brad King in it, > until I start typing there. > > This is under Safari. You're in your fork's scope for the initial comment and the completion isn't smart enough to also grab based on the target project; I've added an issue to look into this. The dropdown for "Assign" might be taking a bit of time to get the list of available users (there are quite a few now :) ). --Ben From 1275963 at gmail.com Wed Mar 18 18:27:30 2015 From: 1275963 at gmail.com (Yingjie) Date: Wed, 18 Mar 2015 22:27:30 +0000 Subject: [vtk-developers] GSOC "VTK Implementation of Eulerian Magnification for Revealing Subtle Changes" Proposal Message-ID: <49DE4F47-AC58-49F2-AEC4-A7717BAE9F76@gmail.com> Hi, My name is Yingjie Luan (https://github.com/y1275963) and I am current a transfer student from University of Leeds in UK and back at home in China my home university is Lanzhou university. I am currently a year 3 undergraduate student studying electronic engineering. Since I was enrolled in the university I have been keen on programming and back at my home I was the elect member of open source society in Lanzhou University(https://oss.lzu.edu.cn/). I am currently targeting at the project called ?Eulerian Magnification for revealing subtle changes?. The reasons why I love this project are the the following: 1. I am really interested in implementing all sorts of artificial algorithms. Just one year ago, I was luckily allowed to work at the mathematical laboratory at my home university during the winter holiday. And at that time I spent a great deal of time studying implementing artificial algorithms like BP Neural network, Generic Algorithm and simulating annealing. I love to read papers and documentations and write code. 2. I have C++ background. Just one year ago, I implemented a laboratory management system using C++ and Qt.(https://github.com/y1275963/FinalTerm) So I think I am comfortable with C++. 3. I have VTK background. Just at this semester, I was luckily enrolled in Pro. David Duck(https://www.engineering.leeds.ac.uk/people/computing/staff/d.j.duke)?s module called ?Scientific Visualization? within which we are discussing a way to visualize data from early universe using VTK. And Pro. David Duke is the developer of the VTK class called ?vtkSpanTreeLayoutStrategy?. 4. The most significant reason why I think I am suitable for this position is that I think I am a dedicated person and I am self-motivated. I asked Pro Wang to allow me to work at his mathematical laboratory. Although I am not allowed to be enrolled in the C++ module back at my home university, I managed spent my spare time to attend all my professor?s classes and finish his final project just as same as his enrolled student( Or even better because I leant Qt at the same time). The module called ?Scientific Visualization? is for master student but after consulting Pro. David I was allowed to be enrolled and I think my performance is not worse than those master students. I think as long as I am willing to devote all my time onto this project I will be fine. The rough idea about the implementation: After read though the paper and its related resources, I have got the idea about this algorithm. It goes like this: 1. First, I need to develop a way to construct spatial filter like Gaussian pyramid or Laplace pyramid. 2. Second, after I have decomposed the video in spatial domain I then apply temporal filter onto it. (like ideal filter, Butterworth filter or second-order IIR filter) 3. Third, I then amplify the filtered signal according to the description in the document. Basically what I need to do is to avoid huge magnification errors by setting approximation limit. 4. After adding the original signal and the amplified signal back together and collapsing the the image pyramid we should get the desired video. The technical difficulties: 1. We only have a Gaussian low pass filter and we don?t have filter to construct Gaussian pyramid or Laplace pyramid.( We have one in ITK) 2. The paper suggested us to use YIQ as color space, we need a filter to transfer the image into YIQ space. 3. This filter is the combination of temporal and spatial decomposition and I need to find a way to link them. 4. For visualizing motion the writer suggested a method called "phase based video motion processing? which is another topic. 5. Provide users some guide lines in determining filter parameters. 6. VTK requires threading process over images and hopefully I can do some things with parallelize. 7. To be honest, my biggest concern is how to build VTK filter and that is area I am going to work really hard onto(Like how to implement Requestdata function, how to work with images or even time varying images, where should my filter inherent from) My rough time table goes like this, 1. I decide to go before the start of the project and I hope by the 25th May I can get a functioning model using scripting language like MATLAB and I can get myself familiar with the VTK environment(Especially, writing VTK filter for time-varying processing) 2. I will do my best during the first term of the GSOC. And within that period I first will do as best as I can to implement the Gaussian pyramid, Laplace pyramid and YIQ converter. After that, I will combine the designed spatial filter with the pre-existing temporal filter and FFT in VTK to build a functioning model in VTK. And I guarantee I can finish this before 3rd July. 3. After I have got the functioning model, I then can do some advanced topics in the second part of my term, like supporting parallelize, implementing phase-based pipeline or write a example about this filter( This is important because we need to give user guide line in terms of how to select the filter parameters, like amplify ratio and what kind of schema). My questions in terms of this paper: 1. I dug into the MATLAB code provided and I am right now trying to implement the simplest one which is gaussian pyramid along with ideal filter, and I saw it goes like this: % Temporal filtering disp('Temporal filtering...') filtered_stack = ideal_bandpassing(Gdown_stack, 1, fl, fh, samplingRate); disp('Finished') %% amplify filtered_stack(:,:,:,1) = filtered_stack(:,:,:,1) .* alpha; filtered_stack(:,:,:,2) = filtered_stack(:,:,:,2) .* alpha .* chromAttenuation; filtered_stack(:,:,:,3) = filtered_stack(:,:,:,3) .* alpha .* chromAttenuation; That is, the writer just filter it out and directly amplified them, but in the paper we should do . Is this true we just assume motion signal is within the passband of the temporal bandpass filter that after applying the filter what we get is ? So we don?t need to explicitly calculate the spatial difference and to find the motion function. 2. The color magnification is fairly easy, I still need some work to understand the maximum application ratio theory for movement magnification.( Like applying different ratio for each spectral components of the movement signal) 3. There is no ideal bandpass filter in VTK should I use vtkWindowedSincPolyDataFilter or vtkSmoothPolyDataFilter or implementing my own?( I think those two filter are all for smoothing and is not for frequency filtering) 4. Am I on the right track? In summery, I hope I can be enrolled in this project and I will do my best not to let my mentor down. I have set up my blog at http://y1275963.github.io/ and my current progress is that I have finished the paper and I am digging into how to implement the pyramids. And I will write a post on my blog as soon as I got the result. I appreciate your valuable time in reading my proposal and I am looking for your feedback. Yingjie -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2015-03-18_22-00-52.png Type: image/png Size: 7578 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2015-03-18_22-02-24.png Type: image/png Size: 6710 bytes Desc: not available URL: From dave.demarle at kitware.com Wed Mar 18 18:27:26 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 18 Mar 2015 18:27:26 -0400 Subject: [vtk-developers] cdash@home, er buildbots and cdash? In-Reply-To: <20150318222209.GB11391@megas.kitwarein.com> References: <20150318222209.GB11391@megas.kitwarein.com> Message-ID: On Wed, Mar 18, 2015 at 6:22 PM, Ben Boeckel wrote: > Actually, forgot to tell you; if you add "master" and "buildbot" tracks > to CDash, they should show up there (I don't have CDash super powers for > VTK). > done buildbot is where gerrit track was master is just below continuous It should replace continuous eventually correct? David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Mar 18 18:40:27 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 18 Mar 2015 18:40:27 -0400 Subject: [vtk-developers] cdash@home, er buildbots and cdash? In-Reply-To: References: <20150318222209.GB11391@megas.kitwarein.com> Message-ID: <20150318224027.GB11867@megas.kitwarein.com> On Wed, Mar 18, 2015 at 18:27:26 -0400, David E DeMarle wrote: > buildbot is where gerrit track was > master is just below continuous > It should replace continuous eventually correct? Yes. --Ben From dave.demarle at kitware.com Wed Mar 18 20:22:35 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 18 Mar 2015 20:22:35 -0400 Subject: [vtk-developers] cdash@home, er buildbots and cdash? In-Reply-To: <20150318224027.GB11867@megas.kitwarein.com> References: <20150318222209.GB11391@megas.kitwarein.com> <20150318224027.GB11867@megas.kitwarein.com> Message-ID: Good. The continuous testers can be moved over to robot servants at any point now. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Mar 18, 2015 at 6:40 PM, Ben Boeckel wrote: > On Wed, Mar 18, 2015 at 18:27:26 -0400, David E DeMarle wrote: > > buildbot is where gerrit track was > > master is just below continuous > > It should replace continuous eventually correct? > > Yes. > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Wed Mar 18 21:27:38 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 18 Mar 2015 18:27:38 -0700 Subject: [vtk-developers] Keeping in fork in sync In-Reply-To: <55086865.70409@kitware.com> References: <55086865.70409@kitware.com> Message-ID: Your suggested method to sync my repo with the vtk repo did not work for me. This is what I needed to do: Do this once: git remote add upstream https://gitlab.kitware.com/vtk/vtk.git To sync: git fetch upstream git checkout master git merge upstream/master git push On Tue, Mar 17, 2015 at 10:46 AM, Brad King wrote: > On 03/17/2015 01:31 PM, Bill Lorensen wrote: >> How do I keep my fork in sync with the vtk repo? > > Whenever you do 'git gitlab-push' to push one of your topics > it will also fetch 'master' from the main repo and push that > to your fork along with your topic. > > In general you don't need to ever reference 'master' in your > fork so it doesn't matter whether it stays updated. If you > do want to update it manually you can do > > $ git checkout master > $ git pull > $ git push gitlab master > > -Brad > -- Unpaid intern in BillsBasement at noware dot com From david.gobbi at gmail.com Wed Mar 18 22:00:07 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 18 Mar 2015 20:00:07 -0600 Subject: [vtk-developers] Keeping in fork in sync In-Reply-To: References: <55086865.70409@kitware.com> Message-ID: Hi Bill, There must be something very strange about your setup. Can you post your .git/config? You shouldn't have to add "upstream" as a new remote, because "origin" should already point to https://gitlab.kitware.com/vtk/vtk.git Also, after running SetupForDevelopment.sh, "gitlab" should be set as a remote for your fork https://gitlab.kitware.com/lorensen/vtk.git I can sync my fork with the vtk master without even doing a local checkout of master: git fetch origin git push gitlab origin/master:master Of course, if I wanted to checkout master, I'd use Brad's example. - David On Wed, Mar 18, 2015 at 7:27 PM, Bill Lorensen wrote: > Your suggested method to sync my repo with the vtk repo did not work for > me. > > This is what I needed to do: > > Do this once: > git remote add upstream https://gitlab.kitware.com/vtk/vtk.git > > To sync: > git fetch upstream > git checkout master > git merge upstream/master > git push > > > > On Tue, Mar 17, 2015 at 10:46 AM, Brad King wrote: > > On 03/17/2015 01:31 PM, Bill Lorensen wrote: > >> How do I keep my fork in sync with the vtk repo? > > > > Whenever you do 'git gitlab-push' to push one of your topics > > it will also fetch 'master' from the main repo and push that > > to your fork along with your topic. > > > > In general you don't need to ever reference 'master' in your > > fork so it doesn't matter whether it stays updated. If you > > do want to update it manually you can do > > > > $ git checkout master > > $ git pull > > $ git push gitlab master > > > > -Brad > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Wed Mar 18 22:25:30 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 18 Mar 2015 19:25:30 -0700 Subject: [vtk-developers] Keeping in fork in sync In-Reply-To: References: <55086865.70409@kitware.com> Message-ID: Brad's instructions were: $ git checkout master $ git pull $ git push gitlab master which did not sync. Before I added upstream, this is the result of git remote -v gerrit lorensen at review.source.kitware.com:VTK (fetch) gerrit lorensen at review.source.kitware.com:VTK (push) gitlab git at gitlab.kitware.com:lorensen/vtk.git (push) gitlab https://gitlab.kitware.com/lorensen/vtk.git (fetch) origin git at gitlab.kitware.com:lorensen/vtk.git (fetch) origin git at gitlab.kitware.com:lorensen/vtk.git (push) stage git at vtk.org:stage/VTK.git (push) stage git://vtk.org/stage/VTK.git (fetch) After adding upstream git remote -v gerrit lorensen at review.source.kitware.com:VTK (fetch) gerrit lorensen at review.source.kitware.com:VTK (push) gitlab git at gitlab.kitware.com:lorensen/vtk.git (push) gitlab https://gitlab.kitware.com/lorensen/vtk.git (fetch) origin git at gitlab.kitware.com:lorensen/vtk.git (fetch) origin git at gitlab.kitware.com:lorensen/vtk.git (push) stage git at vtk.org:stage/VTK.git (push) stage git://vtk.org/stage/VTK.git (fetch) upstream https://gitlab.kitware.com/vtk/vtk.git (fetch) upstream https://gitlab.kitware.com/vtk/vtk.git (push) On Wed, Mar 18, 2015 at 7:00 PM, David Gobbi wrote: > Hi Bill, > > There must be something very strange about your setup. Can you > post your .git/config? > > You shouldn't have to add "upstream" as a new remote, because > "origin" should already point to https://gitlab.kitware.com/vtk/vtk.git > > Also, after running SetupForDevelopment.sh, "gitlab" should be set > as a remote for your fork https://gitlab.kitware.com/lorensen/vtk.git > > I can sync my fork with the vtk master without even doing a local > checkout of master: > > git fetch origin > git push gitlab origin/master:master > > Of course, if I wanted to checkout master, I'd use Brad's example. > > - David > > > > On Wed, Mar 18, 2015 at 7:27 PM, Bill Lorensen > wrote: >> >> Your suggested method to sync my repo with the vtk repo did not work for >> me. >> >> This is what I needed to do: >> >> Do this once: >> git remote add upstream https://gitlab.kitware.com/vtk/vtk.git >> >> To sync: >> git fetch upstream >> git checkout master >> git merge upstream/master >> git push >> >> >> >> On Tue, Mar 17, 2015 at 10:46 AM, Brad King wrote: >> > On 03/17/2015 01:31 PM, Bill Lorensen wrote: >> >> How do I keep my fork in sync with the vtk repo? >> > >> > Whenever you do 'git gitlab-push' to push one of your topics >> > it will also fetch 'master' from the main repo and push that >> > to your fork along with your topic. >> > >> > In general you don't need to ever reference 'master' in your >> > fork so it doesn't matter whether it stays updated. If you >> > do want to update it manually you can do >> > >> > $ git checkout master >> > $ git pull >> > $ git push gitlab master >> > >> > -Brad >> > >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > -- Unpaid intern in BillsBasement at noware dot com From david.gobbi at gmail.com Wed Mar 18 22:33:05 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 18 Mar 2015 20:33:05 -0600 Subject: [vtk-developers] Keeping in fork in sync In-Reply-To: References: <55086865.70409@kitware.com> Message-ID: So the issue is that your "origin" is set to your fork, rather than to the main repository. Unless origin is the main repo, the recipes we're posing will not work. On Wed, Mar 18, 2015 at 8:25 PM, Bill Lorensen wrote: > Brad's instructions were: > $ git checkout master > $ git pull > $ git push gitlab master > > which did not sync. > > Before I added upstream, this is the result of > git remote -v > gerrit lorensen at review.source.kitware.com:VTK (fetch) > gerrit lorensen at review.source.kitware.com:VTK (push) > gitlab git at gitlab.kitware.com:lorensen/vtk.git (push) > gitlab https://gitlab.kitware.com/lorensen/vtk.git (fetch) > origin git at gitlab.kitware.com:lorensen/vtk.git (fetch) > origin git at gitlab.kitware.com:lorensen/vtk.git (push) > stage git at vtk.org:stage/VTK.git (push) > stage git://vtk.org/stage/VTK.git (fetch) > > After adding upstream > git remote -v > gerrit lorensen at review.source.kitware.com:VTK (fetch) > gerrit lorensen at review.source.kitware.com:VTK (push) > gitlab git at gitlab.kitware.com:lorensen/vtk.git (push) > gitlab https://gitlab.kitware.com/lorensen/vtk.git (fetch) > origin git at gitlab.kitware.com:lorensen/vtk.git (fetch) > origin git at gitlab.kitware.com:lorensen/vtk.git (push) > stage git at vtk.org:stage/VTK.git (push) > stage git://vtk.org/stage/VTK.git (fetch) > upstream https://gitlab.kitware.com/vtk/vtk.git (fetch) > upstream https://gitlab.kitware.com/vtk/vtk.git (push) > > On Wed, Mar 18, 2015 at 7:00 PM, David Gobbi > wrote: > > Hi Bill, > > > > There must be something very strange about your setup. Can you > > post your .git/config? > > > > You shouldn't have to add "upstream" as a new remote, because > > "origin" should already point to https://gitlab.kitware.com/vtk/vtk.git > > > > Also, after running SetupForDevelopment.sh, "gitlab" should be set > > as a remote for your fork https://gitlab.kitware.com/lorensen/vtk.git > > > > I can sync my fork with the vtk master without even doing a local > > checkout of master: > > > > git fetch origin > > git push gitlab origin/master:master > > > > Of course, if I wanted to checkout master, I'd use Brad's example. > > > > - David > > > > > > > > On Wed, Mar 18, 2015 at 7:27 PM, Bill Lorensen > > wrote: > >> > >> Your suggested method to sync my repo with the vtk repo did not work for > >> me. > >> > >> This is what I needed to do: > >> > >> Do this once: > >> git remote add upstream https://gitlab.kitware.com/vtk/vtk.git > >> > >> To sync: > >> git fetch upstream > >> git checkout master > >> git merge upstream/master > >> git push > >> > >> > >> > >> On Tue, Mar 17, 2015 at 10:46 AM, Brad King > wrote: > >> > On 03/17/2015 01:31 PM, Bill Lorensen wrote: > >> >> How do I keep my fork in sync with the vtk repo? > >> > > >> > Whenever you do 'git gitlab-push' to push one of your topics > >> > it will also fetch 'master' from the main repo and push that > >> > to your fork along with your topic. > >> > > >> > In general you don't need to ever reference 'master' in your > >> > fork so it doesn't matter whether it stays updated. If you > >> > do want to update it manually you can do > >> > > >> > $ git checkout master > >> > $ git pull > >> > $ git push gitlab master > >> > > >> > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Wed Mar 18 23:01:10 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 18 Mar 2015 20:01:10 -0700 Subject: [vtk-developers] Cherry picking In-Reply-To: References: <20150317190510.GA10675@megas.kitwarein.com> <55087BA7.8020001@kitware.com> <20150317200144.GA6047@megas.kitwarein.com> Message-ID: Actually, I prefer downloading email patches and then git am "the-patch" Then I won't clutter up my machines with all of those fetched repos. On Wed, Mar 18, 2015 at 7:41 AM, Bill Lorensen wrote: > I'll have to try it. For now, downloading the patch seems to work. > > On Wed, Mar 18, 2015 at 5:57 AM, Berk Geveci wrote: >> I am sorry because I am probably about to ask something stupid. Isn't this >> what you want Bill? >> >> $ git remote add gl/$username >> https://gitlab.kitware.com/$username/$project.git >> $ git fetch gl/$username >> $ git log -p master..gl/$username/$branch # view changes >> $ git cherry-pick master..gl/$username/$branch # apply changes >> >> This looks identical to the Gerrit workflow where you fetch and cherry-pick >> or rebase. Once you fetch from a particular branch, you should be able to do >> anything with it without fully updating to that branch? >> >> -berk >> >> >> On Tue, Mar 17, 2015 at 5:27 PM, Bill Lorensen >> wrote: >>> >>> I think I can download patches and use them in a new branch. >>> >>> >>> On Tue, Mar 17, 2015 at 2:18 PM, Will Schroeder >>> wrote: >>> > I agree with Utkarsh. My old brain cells are definitely grumbling at the >>> > moment since all I want to do is write algorithms and not jump through >>> > hoops >>> > ;-) but with enough feedback and the smarts of this community I believe >>> > that >>> > we will make this work. After all we eventually made gerrit work .... >>> > >>> > W >>> > >>> > On Tue, Mar 17, 2015 at 5:10 PM, Utkarsh Ayachit >>> > wrote: >>> >> >>> >> > I will give it a try. But I suspect my contributions will drop off. >>> >> >>> >> That'd be a shame! I am sure we can come up with an alias or something >>> >> that'd make this easier -- let's give it a little time to settle. >>> >> There's work happening behind the screens for moving ParaView to >>> >> gitlab. Once that's live and well, we can focus on ironing out these >>> >> kinks. >>> >> >>> >> Utkarsh >>> >> _______________________________________________ >>> >> Powered by www.kitware.com >>> >> >>> >> Visit other Kitware open-source projects at >>> >> http://www.kitware.com/opensource/opensource.html >>> >> >>> >> Search the list archives at: >>> >> http://markmail.org/search/?q=vtk-developers >>> >> >>> >> Follow this link to subscribe/unsubscribe: >>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >> >>> > >>> > >>> > >>> > -- >>> > William J. Schroeder, PhD >>> > Kitware, Inc. >>> > 28 Corporate Drive >>> > Clifton Park, NY 12065 >>> > will.schroeder at kitware.com >>> > http://www.kitware.com >>> > (518) 881-4902 >>> >>> >>> >>> -- >>> Unpaid intern in BillsBasement at noware dot com >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >> > > > > -- > Unpaid intern in BillsBasement at noware dot com -- Unpaid intern in BillsBasement at noware dot com From andrew.amaclean at gmail.com Thu Mar 19 00:30:09 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 19 Mar 2015 15:30:09 +1100 Subject: [vtk-developers] Do we really need the VTK version of FindPythonLibs.cmake? Message-ID: Hi Folks, I would really like some input from those familiar with how Python is found and wrapped on VTK. I came across a problem where FindPythonLibs.cmake [the VTK version] cannot find the python include directory or the python lib. However the CMake version seems to work OK. This happens if Python is installed in a users directory and not a system directory. My thinking is that instead of just modifying the VTK version it would be better to just use the CMake version. What I think happens is that during the configuration process: 1) In the top-level CMakeLists.txt - PythonInterp is found. 2) ... groups and dependencies set up and defined ... 3) Utilities/Python/CMakeLists.txt - including vtkWrapPython vtkWrapPython.cmake FindPythonLibs Found PythonInterp: C:/Users/amaclean/Anaconda/python.exe (found version "2.7.8") Found PythonInterp: C:/Users/amaclean/Anaconda/python.exe (found suitable version "2.7.8", minimum required is "2") 4) ... HDF5 stuff ... 5) vtkPythonWrapping.cmake FindPythonLibs Not building mpi4py on Windows (not supported currently). vtkPythonWrapping.cmake FindPythonLibs vtkWrapPython.cmake FindPythonLibs Can someone explain why there has to be so many calls to FindPythonLibs? One oddity that you can see above is that ./Utilities/Python/CMakeLists.txt calls vtkWrapPython only to call FindPythonLibs. Which makes me think that: Is it safe, in the top-level CMakeLists.txt to do the FindPythonLibs just the once? It is clear that ./CMake/vtkPythonWrapping.cmake ./CMake/vtkWrapPython.cmake both call FindPythonLibs which may also be redundant. I am working on a branch to do this so any input from the original writers would be appreciated. It would also be really appreciated if they would act as reviewers. Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Mar 19 01:10:21 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 18 Mar 2015 23:10:21 -0600 Subject: [vtk-developers] Do we really need the VTK version of FindPythonLibs.cmake? In-Reply-To: References: Message-ID: Hi Andrew, You ask questions that are difficult to answer. I'll spend some time going over the code and reminding myself of why things are the way they are, but I won't have a full reply for you before the weekend. Off the top of my head: the fact that vtkWrapPython.cmake is used in odd places to indirectly call FindPythonLibs is bad. Someone got lazy and put put some code they shouldn't have into vtkWrapPython.cmake, and that required vtkWrapPython.cmake to be used in odd places or else debug builds would break. I disagree that using the CMake version of FindPythonLibs.cmake is better: 1) The very fact that FindPythonLibs.cmake and FindPythonInterp.cmake are two independent scripts has been a source of trouble (it make synchronization between the library and the interpreter difficult). So if there are going to be substantial changes, I'd rather make a new script "FindPython.cmake" and see if the cmake folks are willing to adopt it. 2) We've often been saved by the fact that we have our own script, because in the past we've run into situations where we've needed to patch the script. (Also, in the past we did a better job of synchronizing such changes with the cmake repository.) 3) I don't think there's a way to block cmake's FindPythonLibs.cmake from finding python3, and that's a real problem for us until VTK supports python3. So my preference would be to change FindPythonLibs.cmake so that it solves your specific issue (so that it finds your python). Eventually, when we make the move to python3, we can consider either making a new "FindPython.cmake" script, or syncing with the CMake script. - David On Wed, Mar 18, 2015 at 10:30 PM, Andrew Maclean wrote: > Hi Folks, > > I would really like some input from those familiar with how Python is > found and wrapped on VTK. > > I came across a problem where FindPythonLibs.cmake [the VTK version] > cannot find the python include directory or the python lib. However the > CMake version seems to work OK. This happens if Python is installed in a > users directory and not a system directory. > > My thinking is that instead of just modifying the VTK version it would be > better to just use the CMake version. > > What I think happens is that during the configuration process: > 1) In the top-level CMakeLists.txt - PythonInterp is found. > 2) ... groups and dependencies set up and defined ... > 3) Utilities/Python/CMakeLists.txt - including vtkWrapPython > vtkWrapPython.cmake > FindPythonLibs > Found PythonInterp: C:/Users/amaclean/Anaconda/python.exe (found version > "2.7.8") > Found PythonInterp: C:/Users/amaclean/Anaconda/python.exe (found suitable > version "2.7.8", minimum required is "2") > 4) ... HDF5 stuff ... > 5) vtkPythonWrapping.cmake > FindPythonLibs > Not building mpi4py on Windows (not supported currently). > vtkPythonWrapping.cmake > FindPythonLibs > vtkWrapPython.cmake > FindPythonLibs > > Can someone explain why there has to be so many calls to FindPythonLibs? > One oddity that you can see above is that > ./Utilities/Python/CMakeLists.txt calls vtkWrapPython only to call > FindPythonLibs. Which makes me think that: Is it safe, in the top-level > CMakeLists.txt to do the FindPythonLibs just the once? > > It is clear that > ./CMake/vtkPythonWrapping.cmake > ./CMake/vtkWrapPython.cmake > both call FindPythonLibs which may also be redundant. > > I am working on a branch to do this so any input from the original writers > would be appreciated. > It would also be really appreciated if they would act as reviewers. > > Regards > Andrew > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Thu Mar 19 03:21:19 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 19 Mar 2015 18:21:19 +1100 Subject: [vtk-developers] Do we really need the VTK version of FindPythonLibs.cmake? In-Reply-To: References: Message-ID: Hi David, Thanks for getting back so fast ... what time was it where you are? I am in no hurry, so take your time and have a good look at the code! All these questions arose because I did a gerrit submission, (now abandoned because I thought it would be a good idea to wait for GitLab to be up and running): http://review.source.kitware.com/#/c/19474/ These changes worked but on thinking about it they raised a lot of questions, hence the email. I did consider just a change to the VTK version of FindPythonLibs.cmake but then I found the CMake version worked quite well. The abandoned topic built Ok on the test machines and Windows. In response to your points: 2) I agree that the synchronization with CMake should be better! 1) It is strange that there exist FindPythonLibs.cmake and FindPythonInterp.cmake but I guess it may be historical. A FindPython.cmake would be more intuitive. You can emulate this by doing a: find_package(PythonInterp ${VTK_PYTHON_VERSION}) find_package(PythonLibs ${VTK_PYTHON_VERSION}) Which leads to point 3: 3) I think the problem here is that in the VTK stuff, all the finding of the Python Libs are done by: find_package(PythonLibs) note that Python_ADDITIONAL_VERSIONS is not being used. I think these calls should be: find_package(PythonLibs ${VTK_PYTHON_VERSION}) this should fix the issue that python3 libs are being found when python (2) is needed. It is interesting that the third party stuff all does this: FIND_PACKAGE(PythonInterp ${VTK_PYTHON_VERSION}) FIND_PACKAGE(PythonLibs ${VTK_PYTHON_VERSION}) Which raises the possibility that the third party lib versions could be different from the VTK versions! Anyway I think that if the python stuff can be streamlined an simplified that will be the best approach. So take your time and have a good look at the code! I can do a quick fix to FindPythonLibs.cmake but there are deeper issues here. I am in no hurry! Regards Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Thu Mar 19 08:35:29 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 19 Mar 2015 08:35:29 -0400 Subject: [vtk-developers] Cherry picking In-Reply-To: References: <20150317190510.GA10675@megas.kitwarein.com> <55087BA7.8020001@kitware.com> <20150317200144.GA6047@megas.kitwarein.com> Message-ID: Bill, If adding several remotes is what's keeping you from Berk's suggestion, here another alternative: $ git fetch https://gitlab.kitware.com/$username/$project.git $branch #To view the changes $ git log -p master..FETCH_HEAD # To cherry-pick the changes. $ git cherry-pick master..FETCH_HEAD This can be done on a single line too, similar to what Gerrit used to do: $ git fetch https://gitlab.kitware.com/$username/$project.git $branch && git cherry-pick master..FETCH_HEAD Utkarsh On Wed, Mar 18, 2015 at 11:01 PM, Bill Lorensen wrote: > Actually, I prefer downloading email patches and then > > git am "the-patch" > > Then I won't clutter up my machines with all of those fetched repos. > > > On Wed, Mar 18, 2015 at 7:41 AM, Bill Lorensen wrote: >> I'll have to try it. For now, downloading the patch seems to work. >> >> On Wed, Mar 18, 2015 at 5:57 AM, Berk Geveci wrote: >>> I am sorry because I am probably about to ask something stupid. Isn't this >>> what you want Bill? >>> >>> $ git remote add gl/$username >>> https://gitlab.kitware.com/$username/$project.git >>> $ git fetch gl/$username >>> $ git log -p master..gl/$username/$branch # view changes >>> $ git cherry-pick master..gl/$username/$branch # apply changes >>> >>> This looks identical to the Gerrit workflow where you fetch and cherry-pick >>> or rebase. Once you fetch from a particular branch, you should be able to do >>> anything with it without fully updating to that branch? >>> >>> -berk >>> >>> >>> On Tue, Mar 17, 2015 at 5:27 PM, Bill Lorensen >>> wrote: >>>> >>>> I think I can download patches and use them in a new branch. >>>> >>>> >>>> On Tue, Mar 17, 2015 at 2:18 PM, Will Schroeder >>>> wrote: >>>> > I agree with Utkarsh. My old brain cells are definitely grumbling at the >>>> > moment since all I want to do is write algorithms and not jump through >>>> > hoops >>>> > ;-) but with enough feedback and the smarts of this community I believe >>>> > that >>>> > we will make this work. After all we eventually made gerrit work .... >>>> > >>>> > W >>>> > >>>> > On Tue, Mar 17, 2015 at 5:10 PM, Utkarsh Ayachit >>>> > wrote: >>>> >> >>>> >> > I will give it a try. But I suspect my contributions will drop off. >>>> >> >>>> >> That'd be a shame! I am sure we can come up with an alias or something >>>> >> that'd make this easier -- let's give it a little time to settle. >>>> >> There's work happening behind the screens for moving ParaView to >>>> >> gitlab. Once that's live and well, we can focus on ironing out these >>>> >> kinks. >>>> >> >>>> >> Utkarsh >>>> >> _______________________________________________ >>>> >> Powered by www.kitware.com >>>> >> >>>> >> Visit other Kitware open-source projects at >>>> >> http://www.kitware.com/opensource/opensource.html >>>> >> >>>> >> Search the list archives at: >>>> >> http://markmail.org/search/?q=vtk-developers >>>> >> >>>> >> Follow this link to subscribe/unsubscribe: >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >> >>>> > >>>> > >>>> > >>>> > -- >>>> > William J. Schroeder, PhD >>>> > Kitware, Inc. >>>> > 28 Corporate Drive >>>> > Clifton Park, NY 12065 >>>> > will.schroeder at kitware.com >>>> > http://www.kitware.com >>>> > (518) 881-4902 >>>> >>>> >>>> >>>> -- >>>> Unpaid intern in BillsBasement at noware dot com >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the list archives at: http://markmail.org/search/?q=vtk-developers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>> >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com > > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From brad.king at kitware.com Thu Mar 19 08:47:15 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 19 Mar 2015 08:47:15 -0400 Subject: [vtk-developers] Keeping in fork in sync In-Reply-To: References: <55086865.70409@kitware.com> Message-ID: <550AC553.8050108@kitware.com> On 03/18/2015 10:33 PM, David Gobbi wrote: > So the issue is that your "origin" is set to your fork, rather > than to the main repository. Unless origin is the main repo, > the recipes we're posing will not work. Running the Utilities/SetupForDevelopment.sh script as was described in the initial transition instructions should have prompted you to change origin to the main repo on gitlab.kitware.com, not your fork. Some documentation in the wild (for Github IIRC) suggests cloning from your fork and adding the upstream repository as a remote called "upstream". Our documented workflow does *not* do this. We prefer to keep "origin" meaning the same thing for everyone. -Brad From ben.boeckel at kitware.com Thu Mar 19 08:58:39 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 19 Mar 2015 08:58:39 -0400 Subject: [vtk-developers] Do we really need the VTK version of FindPythonLibs.cmake? In-Reply-To: References: Message-ID: <20150319125839.GA12678@megas.kitwarein.com> On Wed, Mar 18, 2015 at 23:10:21 -0600, David Gobbi wrote: > You ask questions that are difficult to answer. I'll spend some time going > over the code and reminding myself of why things are the way they are, > but I won't have a full reply for you before the weekend. VTK's FindPythonLibs *removes* variables which are merely deprecated upstream. That will need to be re-added when pushing upstream for backwards-compat. > 1) The very fact that FindPythonLibs.cmake and FindPythonInterp.cmake are > two independent scripts has been a source of trouble (it make > synchronization > between the library and the interpreter difficult). So if there are going > to be > substantial changes, I'd rather make a new script "FindPython.cmake" and see > if the cmake folks are willing to adopt it. Please make this a "FindPython2.cmake". Wanting Python2 and finding Python3 is never acceptable (and vice versa). There are also reasonable cases where finding both is wanted and having a single Find module really gets in the way of that. --Ben From david.gobbi at gmail.com Thu Mar 19 09:11:00 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 19 Mar 2015 07:11:00 -0600 Subject: [vtk-developers] Do we really need the VTK version of FindPythonLibs.cmake? In-Reply-To: <20150319125839.GA12678@megas.kitwarein.com> References: <20150319125839.GA12678@megas.kitwarein.com> Message-ID: On Thu, Mar 19, 2015 at 6:58 AM, Ben Boeckel wrote: > On Wed, Mar 18, 2015 at 23:10:21 -0600, David Gobbi wrote: > > Please make this a "FindPython2.cmake". Wanting Python2 and finding > Python3 is never acceptable (and vice versa). There are also reasonable > cases where finding both is wanted and having a single Find module > really gets in the way of that. That's a good point, but having separate cmake variables for each (e.g. PYTHON2_INCLUDE_DIRS for 2 vs. PYTHON_INCLUDE_DIRS for 3) is going to complicate the rest of our cmake scripts. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Mar 19 09:15:33 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 19 Mar 2015 09:15:33 -0400 Subject: [vtk-developers] Do we really need the VTK version of FindPythonLibs.cmake? In-Reply-To: References: <20150319125839.GA12678@megas.kitwarein.com> Message-ID: <20150319131533.GA14200@megas.kitwarein.com> On Thu, Mar 19, 2015 at 07:11:00 -0600, David Gobbi wrote: > That's a good point, but having separate cmake variables for each (e.g. > PYTHON2_INCLUDE_DIRS for 2 vs. PYTHON_INCLUDE_DIRS for 3) > is going to complicate the rest of our cmake scripts. Well, with a 3.0-ized module system, we can just have a vtkpython target with target_include_directories() set to the right one and then everything else just links to that and gets all the right bits automatically :) . --Ben From utkarsh.ayachit at kitware.com Thu Mar 19 09:48:08 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 19 Mar 2015 09:48:08 -0400 Subject: [vtk-developers] Do we really need the VTK version of FindPythonLibs.cmake? In-Reply-To: <20150319131533.GA14200@megas.kitwarein.com> References: <20150319125839.GA12678@megas.kitwarein.com> <20150319131533.GA14200@megas.kitwarein.com> Message-ID: > Well, with a 3.0-ized module system, we can just have a vtkpython target > with target_include_directories() set to the right one and then > everything else just links to that and gets all the right bits > automatically :) . +1. At this point, 3.0-ized module system seems like cure-all which worries me as we all know there's no such thing! (just kidding). From bill.lorensen at gmail.com Thu Mar 19 10:29:40 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 19 Mar 2015 07:29:40 -0700 Subject: [vtk-developers] Keeping in fork in sync In-Reply-To: <550AC553.8050108@kitware.com> References: <55086865.70409@kitware.com> <550AC553.8050108@kitware.com> Message-ID: I'm not sure what happened when I did the initial setup. To fix it, I removed the upstream and origin from my config file and reran the setup script. I am OK now. Here is the result: master)] git remote -v gerrit lorensen at review.source.kitware.com:VTK (fetch) gerrit lorensen at review.source.kitware.com:VTK (push) gitlab https://gitlab.kitware.com/lorensen/vtk.git (fetch) gitlab git at gitlab.kitware.com:lorensen/vtk.git (push) origin https://gitlab.kitware.com/vtk/vtk.git (push) origin https://gitlab.kitware.com/vtk/vtk.git (fetch) stage git://vtk.org/stage/VTK.git (fetch) stage git at vtk.org:stage/VTK.git On Thu, Mar 19, 2015 at 5:47 AM, Brad King wrote: > On 03/18/2015 10:33 PM, David Gobbi wrote: >> So the issue is that your "origin" is set to your fork, rather >> than to the main repository. Unless origin is the main repo, >> the recipes we're posing will not work. > > Running the Utilities/SetupForDevelopment.sh script as was described > in the initial transition instructions should have prompted you to > change origin to the main repo on gitlab.kitware.com, not your fork. > > Some documentation in the wild (for Github IIRC) suggests cloning > from your fork and adding the upstream repository as a remote > called "upstream". Our documented workflow does *not* do this. > We prefer to keep "origin" meaning the same thing for everyone. > > -Brad > -- Unpaid intern in BillsBasement at noware dot com From bill.lorensen at gmail.com Thu Mar 19 10:31:03 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 19 Mar 2015 07:31:03 -0700 Subject: [vtk-developers] Cherry picking In-Reply-To: References: <20150317190510.GA10675@megas.kitwarein.com> <55087BA7.8020001@kitware.com> <20150317200144.GA6047@megas.kitwarein.com> Message-ID: Utkarsh, That looks good. Thanks. Bill On Thu, Mar 19, 2015 at 5:35 AM, Utkarsh Ayachit wrote: > Bill, > > If adding several remotes is what's keeping you from Berk's > suggestion, here another alternative: > > $ git fetch https://gitlab.kitware.com/$username/$project.git $branch > > #To view the changes > $ git log -p master..FETCH_HEAD > > # To cherry-pick the changes. > $ git cherry-pick master..FETCH_HEAD > > > This can be done on a single line too, similar to what Gerrit used to do: > > $ git fetch https://gitlab.kitware.com/$username/$project.git $branch > && git cherry-pick master..FETCH_HEAD > > Utkarsh > > On Wed, Mar 18, 2015 at 11:01 PM, Bill Lorensen wrote: >> Actually, I prefer downloading email patches and then >> >> git am "the-patch" >> >> Then I won't clutter up my machines with all of those fetched repos. >> >> >> On Wed, Mar 18, 2015 at 7:41 AM, Bill Lorensen wrote: >>> I'll have to try it. For now, downloading the patch seems to work. >>> >>> On Wed, Mar 18, 2015 at 5:57 AM, Berk Geveci wrote: >>>> I am sorry because I am probably about to ask something stupid. Isn't this >>>> what you want Bill? >>>> >>>> $ git remote add gl/$username >>>> https://gitlab.kitware.com/$username/$project.git >>>> $ git fetch gl/$username >>>> $ git log -p master..gl/$username/$branch # view changes >>>> $ git cherry-pick master..gl/$username/$branch # apply changes >>>> >>>> This looks identical to the Gerrit workflow where you fetch and cherry-pick >>>> or rebase. Once you fetch from a particular branch, you should be able to do >>>> anything with it without fully updating to that branch? >>>> >>>> -berk >>>> >>>> >>>> On Tue, Mar 17, 2015 at 5:27 PM, Bill Lorensen >>>> wrote: >>>>> >>>>> I think I can download patches and use them in a new branch. >>>>> >>>>> >>>>> On Tue, Mar 17, 2015 at 2:18 PM, Will Schroeder >>>>> wrote: >>>>> > I agree with Utkarsh. My old brain cells are definitely grumbling at the >>>>> > moment since all I want to do is write algorithms and not jump through >>>>> > hoops >>>>> > ;-) but with enough feedback and the smarts of this community I believe >>>>> > that >>>>> > we will make this work. After all we eventually made gerrit work .... >>>>> > >>>>> > W >>>>> > >>>>> > On Tue, Mar 17, 2015 at 5:10 PM, Utkarsh Ayachit >>>>> > wrote: >>>>> >> >>>>> >> > I will give it a try. But I suspect my contributions will drop off. >>>>> >> >>>>> >> That'd be a shame! I am sure we can come up with an alias or something >>>>> >> that'd make this easier -- let's give it a little time to settle. >>>>> >> There's work happening behind the screens for moving ParaView to >>>>> >> gitlab. Once that's live and well, we can focus on ironing out these >>>>> >> kinks. >>>>> >> >>>>> >> Utkarsh >>>>> >> _______________________________________________ >>>>> >> Powered by www.kitware.com >>>>> >> >>>>> >> Visit other Kitware open-source projects at >>>>> >> http://www.kitware.com/opensource/opensource.html >>>>> >> >>>>> >> Search the list archives at: >>>>> >> http://markmail.org/search/?q=vtk-developers >>>>> >> >>>>> >> Follow this link to subscribe/unsubscribe: >>>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >> >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > William J. Schroeder, PhD >>>>> > Kitware, Inc. >>>>> > 28 Corporate Drive >>>>> > Clifton Park, NY 12065 >>>>> > will.schroeder at kitware.com >>>>> > http://www.kitware.com >>>>> > (518) 881-4902 >>>>> >>>>> >>>>> >>>>> -- >>>>> Unpaid intern in BillsBasement at noware dot com >>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Search the list archives at: http://markmail.org/search/?q=vtk-developers >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>> >>> >>> >>> >>> -- >>> Unpaid intern in BillsBasement at noware dot com >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> -- Unpaid intern in BillsBasement at noware dot com From david.gobbi at gmail.com Thu Mar 19 10:49:40 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 19 Mar 2015 08:49:40 -0600 Subject: [vtk-developers] Do we really need the VTK version of FindPythonLibs.cmake? In-Reply-To: References: <20150319125839.GA12678@megas.kitwarein.com> <20150319131533.GA14200@megas.kitwarein.com> Message-ID: On Thu, Mar 19, 2015 at 7:48 AM, Utkarsh Ayachit < utkarsh.ayachit at kitware.com> wrote: > > +1. At this point, 3.0-ized module system seems like cure-all which > worries me as we all know there's no such thing! (just kidding). > It sounds like it could simplify things immensely for wrapping external projects. Importing targets is much easier than exporting/importing a whole mess of cmake variables. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Thu Mar 19 14:56:39 2015 From: david.lonie at kitware.com (David Lonie) Date: Thu, 19 Mar 2015 14:56:39 -0400 Subject: [vtk-developers] Adding support for a macro in wrapper In-Reply-To: References: <20150311184927.GB11496@megas.kitwarein.com> Message-ID: On Wed, Mar 11, 2015 at 3:47 PM, David Lonie wrote: > On Wed, Mar 11, 2015 at 3:46 PM, David Gobbi > wrote: >> >> The old GetBounds() method might be hidden in the wrapped classes due to >> "using" being ignored. >> > > I'll be sure to test this before I merge -- thanks for the heads up. > Just FYI, the wrappers seem to handle the 'using Superclass::method;' statement as expected :D Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Mar 19 15:39:09 2015 From: sean at rogue-research.com (Sean McBride) Date: Thu, 19 Mar 2015 15:39:09 -0400 Subject: [vtk-developers] RFC: Compiler support, removing hacks for old compilers In-Reply-To: <89947a5813a84dc5842498245df50dd6@ES05AMSNLNT.srn.sandia.gov> References: <20150316180926.1146005295@mail.rogue-research.com> <89947a5813a84dc5842498245df50dd6@ES05AMSNLNT.srn.sandia.gov> Message-ID: <20150319193909.1656031800@mail.rogue-research.com> Thanks for these comments. There is only one hack for gcc 4.0, I'll go ahead and yank it too. Anyone know if there is a dashboard running gcc 4.1? (My oldest buildbot, Rogue3, is running gcc 4.2, specifically Apple's fork.) Sean On Wed, 18 Mar 2015 18:46:04 +0000, Scott, W Alan said: >Ditto for us. 4.1.2 is the oldest we seem to have. > >Alan > >From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf >Of Chuck Atkins >Sent: Wednesday, March 18, 2015 12:13 PM >To: Sean McBride >Cc: VTK Developers; vtkusers at vtk.org >Subject: [EXTERNAL] Re: [vtk-developers] RFC: Compiler support, removing >hacks for old compilers > >I'd be interested to know from the community what are the oldest >compilers you care about? Anyone out there using a compiler older than >5 years or so? > > I'd say for gcc, 4.1.x is likely the oldest you'd need to bother with. >That's the system compiler for RHEL5 and SLES10, both of which are EOL'd >but still actively deployed. That being said, chances are pretty high >that even on those systems, you'd have a newer compiler available via >system packages. RHEL5.5 and up has /usr/bin/gcc44 and SLES 10 has /usr/ >bin/gcc-4.3, both available as system packages and an alternative to the >older /usr/bin/gcc used to compiler their respective kernels. From dave.demarle at kitware.com Thu Mar 19 15:47:46 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 19 Mar 2015 15:47:46 -0400 Subject: [vtk-developers] RFC: Compiler support, removing hacks for old compilers In-Reply-To: <20150319193909.1656031800@mail.rogue-research.com> References: <20150316180926.1146005295@mail.rogue-research.com> <89947a5813a84dc5842498245df50dd6@ES05AMSNLNT.srn.sandia.gov> <20150319193909.1656031800@mail.rogue-research.com> Message-ID: This from $VTKSRC/Utilities/Maintainance/vtk_submitter_summary.py run a while back. These are maybe. CMAKE_CXX_COMPILER;/usr/bin/c++;1.71428571429;['karego-at.kitware Ubuntu-NoRender', 'londinium.kitware Arch-GCC-4.8-x86_64-debug', 'kamino.kitware Mac10.7.5-gcc-release-x86_64-nightly_master', 'kargad.kitware MacLion-Continuous', 'karego-at.kitware Ubuntu-Continuous', 'sonne.domibel.de Debian_Testing_gcc-4.8.2_c++11', 'dejagore.kitware Ubuntu-13.10-x86_64-Ninja-Clang3.4-Accel', 'kargad.kitware MacLion-VTKAcceleratorsOMP', 'karego-at.kitware Ubuntu-Valgrind', 'dashlin1.kitware Ubuntu-Release', 'kargad.kitware MacLion-VTKRelease', 'dashlin1.kitware Ubuntu-master', 'karego-at.kitware Ubuntu-Coverage', 'kamino.kitware Mac10.7.5-gcc-release-x86_64-nightly_release', 'karego-at.kitware Ubuntu-NoData', 'kargad.kitware MacLion-VTKAccelerators'] CMAKE_CXX_COMPILER;/usr/bin/c++.exe;10.0;['dash14.kitware Win32-cygwin344'] CMAKE_CXX_COMPILER;/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++;1.0;['RogueResearch6 Mac10.9-clang-rel-x86_64', 'RogueResearch11 Mac10.7-clang-dbg-x86_64', 'RogueResearch11 Mac10.7-clang-rel-x86_64', 'RogueResearch6 Mac10.9-clang-dbg-x86_64'] CMAKE_CXX_COMPILER;/Developer/usr/bin/c++;1.0;['RogueResearch9 Mac10.6-gcc-dbg-i386', 'RogueResearch9 Mac10.6-gcc-rel-x86_64'] CMAKE_CXX_COMPILER;/Developer/usr/bin/c++;1.0;['RogueResearch9 Mac10.6-gcc-dbg-i386', 'RogueResearch9 Mac10.6-gcc-rel-x86_64'] CMAKE_CXX_COMPILER;/bin/g++;14.0;['rocky.lbl.gov Fedora19-gcc4.8.2-ATI-RadeonHD-7870'] CMAKE_CXX_COMPILER;/usr/bin/g++;1.0;['hythloth.kitware Linux-gcc'] CMAKE_CXX_COMPILER;/usr/lib/ccache/bin/c++;2.0;['londinium.kitware Arch-GCC-4.8-x86_64-release-branch-debug', 'londinium.kitware Arch-GCC-4.8-x86_64-release'] CMAKE_CXX_COMPILER;/usr/lib64/ccache/c++;10.75;['bubbles.hooperlab Fedora-19_OSMesaDevel-x86_64', 'bubbles.hooperlab Fedora-19-MesaDevel_DRI-x86_64', 'bubbles.hooperlab Fedora-19-Mesa-10.0.1_DRI-x86_64', 'bubbles.hooperlab Fedora-19_OSMesa-10.0.1-x86_64'] CMAKE_CXX_COMPILER;C:/MinGW/bin/g++.exe;1.0;['amber12.kitware Win32-mingw-gcc-4.5'] These are no. CMAKE_CXX_COMPILER;/Users/builder/llvm/llvm-rel-install/bin/clang++;4.66666666667;['RogueResearch7 Mac10.8-torture-clang-dbg-x86_64', 'RogueResearch7 Mac10.8-clang-rel-x86_64', 'RogueResearch7 Mac10.8-clang-dbg-x86_64'] CMAKE_CXX_COMPILER;/usr/bin/clang++;1.5;['kamino.kitware Mac10.7.5-clang-release-x86_64-nightly_master', 'londinium.kitware Arch-Clang-3.2-x86_64-debug'] CMAKE_CXX_COMPILER;/usr/bin/g++-4.2;0.5;['RogueResearch3 Mac10.5-gcc-dbg-ppc-shared', 'RogueResearch3 Mac10.5-gcc-dbg-ppc64-static'] CMAKE_CXX_COMPILER;/usr/vacpp/bin/xlC;2.0;['p90n03.pbm.ihost.com AIX00F614-xlC'] CMAKE_CXX_COMPILER;C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/x86_amd64/cl.exe;2.5;['amber10.kitware Win64-VS10', 'amber10.kitware VTK-REL-Win64-VS10'] CMAKE_CXX_COMPILER;C:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin/cl.exe;12.1666666667;['mug.neocisinc Win32-ninja-cl11-Release', 'dash1win7.kitware Win32-release-vs11-Shared', 'dash1win7.kitware Win32-vs11-Static', 'mug.neocisinc Win32-ninja-cl11-Debug', 'dash1win7.kitware Win32-vs11-Cont', 'dash1win7.kitware Win32-vs11-Shared'] CMAKE_CXX_COMPILER;C:/Program Files/Microsoft Visual Studio .NET 2003/Vc7/bin/cl.exe;0.0;['DASH11.kitware Win32-vs71-static'] CMAKE_CXX_COMPILER;c:/Program Files/Microsoft Visual Studio/VC98/Bin/CL.EXE;0.0;['DASH3.kitware Win32-vs9-Static', 'DASH3.kitware Win32-vs9-Shared', 'DASH3.kitware Win32-vs9'] David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Mar 19, 2015 at 3:39 PM, Sean McBride wrote: > Thanks for these comments. > > There is only one hack for gcc 4.0, I'll go ahead and yank it too. > > Anyone know if there is a dashboard running gcc 4.1? (My oldest buildbot, > Rogue3, is running gcc 4.2, specifically Apple's fork.) > > Sean > > > > On Wed, 18 Mar 2015 18:46:04 +0000, Scott, W Alan said: > > >Ditto for us. 4.1.2 is the oldest we seem to have. > > > >Alan > > > >From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf > >Of Chuck Atkins > >Sent: Wednesday, March 18, 2015 12:13 PM > >To: Sean McBride > >Cc: VTK Developers; vtkusers at vtk.org > >Subject: [EXTERNAL] Re: [vtk-developers] RFC: Compiler support, removing > >hacks for old compilers > > > >I'd be interested to know from the community what are the oldest > >compilers you care about? Anyone out there using a compiler older than > >5 years or so? > > > > I'd say for gcc, 4.1.x is likely the oldest you'd need to bother with. > >That's the system compiler for RHEL5 and SLES10, both of which are EOL'd > >but still actively deployed. That being said, chances are pretty high > >that even on those systems, you'd have a newer compiler available via > >system packages. RHEL5.5 and up has /usr/bin/gcc44 and SLES 10 has /usr/ > >bin/gcc-4.3, both available as system packages and an alternative to the > >older /usr/bin/gcc used to compiler their respective kernels. > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Thu Mar 19 16:01:05 2015 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Thu, 19 Mar 2015 16:01:05 -0400 Subject: [vtk-developers] [vtkusers] RFC: Compiler support, removing hacks for old compilers In-Reply-To: References: <20150316180926.1146005295@mail.rogue-research.com> <89947a5813a84dc5842498245df50dd6@ES05AMSNLNT.srn.sandia.gov> <20150319193909.1656031800@mail.rogue-research.com> Message-ID: FWIW, ParaView has a superbuild nightly binaries machine that runs debian 4 (gcc 4.1.2). We may be updating to a more recent debian soon though. Shawn On Thu, Mar 19, 2015 at 3:47 PM, David E DeMarle wrote: > This from $VTKSRC/Utilities/Maintainance/vtk_submitter_summary.py run a > while back. > > These are maybe. > CMAKE_CXX_COMPILER;/usr/bin/c++;1.71428571429;['karego-at.kitware > Ubuntu-NoRender', 'londinium.kitware Arch-GCC-4.8-x86_64-debug', > 'kamino.kitware Mac10.7.5-gcc-release-x86_64-nightly_master', > 'kargad.kitware MacLion-Continuous', 'karego-at.kitware Ubuntu-Continuous', > 'sonne.domibel.de Debian_Testing_gcc-4.8.2_c++11', 'dejagore.kitware > Ubuntu-13.10-x86_64-Ninja-Clang3.4-Accel', 'kargad.kitware > MacLion-VTKAcceleratorsOMP', 'karego-at.kitware Ubuntu-Valgrind', > 'dashlin1.kitware Ubuntu-Release', 'kargad.kitware MacLion-VTKRelease', > 'dashlin1.kitware Ubuntu-master', 'karego-at.kitware Ubuntu-Coverage', > 'kamino.kitware Mac10.7.5-gcc-release-x86_64-nightly_release', > 'karego-at.kitware Ubuntu-NoData', 'kargad.kitware MacLion-VTKAccelerators'] > CMAKE_CXX_COMPILER;/usr/bin/c++.exe;10.0;['dash14.kitware Win32-cygwin344'] > CMAKE_CXX_COMPILER;/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++;1.0;['RogueResearch6 > Mac10.9-clang-rel-x86_64', 'RogueResearch11 Mac10.7-clang-dbg-x86_64', > 'RogueResearch11 Mac10.7-clang-rel-x86_64', 'RogueResearch6 > Mac10.9-clang-dbg-x86_64'] > CMAKE_CXX_COMPILER;/Developer/usr/bin/c++;1.0;['RogueResearch9 > Mac10.6-gcc-dbg-i386', 'RogueResearch9 Mac10.6-gcc-rel-x86_64'] > CMAKE_CXX_COMPILER;/Developer/usr/bin/c++;1.0;['RogueResearch9 > Mac10.6-gcc-dbg-i386', 'RogueResearch9 Mac10.6-gcc-rel-x86_64'] > CMAKE_CXX_COMPILER;/bin/g++;14.0;['rocky.lbl.gov > Fedora19-gcc4.8.2-ATI-RadeonHD-7870'] > CMAKE_CXX_COMPILER;/usr/bin/g++;1.0;['hythloth.kitware Linux-gcc'] > CMAKE_CXX_COMPILER;/usr/lib/ccache/bin/c++;2.0;['londinium.kitware > Arch-GCC-4.8-x86_64-release-branch-debug', 'londinium.kitware > Arch-GCC-4.8-x86_64-release'] > CMAKE_CXX_COMPILER;/usr/lib64/ccache/c++;10.75;['bubbles.hooperlab > Fedora-19_OSMesaDevel-x86_64', 'bubbles.hooperlab > Fedora-19-MesaDevel_DRI-x86_64', 'bubbles.hooperlab > Fedora-19-Mesa-10.0.1_DRI-x86_64', 'bubbles.hooperlab > Fedora-19_OSMesa-10.0.1-x86_64'] > CMAKE_CXX_COMPILER;C:/MinGW/bin/g++.exe;1.0;['amber12.kitware > Win32-mingw-gcc-4.5'] > > These are no. > CMAKE_CXX_COMPILER;/Users/builder/llvm/llvm-rel-install/bin/clang++;4.66666666667;['RogueResearch7 > Mac10.8-torture-clang-dbg-x86_64', 'RogueResearch7 > Mac10.8-clang-rel-x86_64', 'RogueResearch7 Mac10.8-clang-dbg-x86_64'] > CMAKE_CXX_COMPILER;/usr/bin/clang++;1.5;['kamino.kitware > Mac10.7.5-clang-release-x86_64-nightly_master', 'londinium.kitware > Arch-Clang-3.2-x86_64-debug'] > CMAKE_CXX_COMPILER;/usr/bin/g++-4.2;0.5;['RogueResearch3 > Mac10.5-gcc-dbg-ppc-shared', 'RogueResearch3 Mac10.5-gcc-dbg-ppc64-static'] > CMAKE_CXX_COMPILER;/usr/vacpp/bin/xlC;2.0;['p90n03.pbm.ihost.com > AIX00F614-xlC'] > CMAKE_CXX_COMPILER;C:/Program Files (x86)/Microsoft Visual Studio > 10.0/VC/bin/x86_amd64/cl.exe;2.5;['amber10.kitware Win64-VS10', > 'amber10.kitware VTK-REL-Win64-VS10'] > CMAKE_CXX_COMPILER;C:/Program Files (x86)/Microsoft Visual Studio > 11.0/VC/bin/cl.exe;12.1666666667;['mug.neocisinc Win32-ninja-cl11-Release', > 'dash1win7.kitware Win32-release-vs11-Shared', 'dash1win7.kitware > Win32-vs11-Static', 'mug.neocisinc Win32-ninja-cl11-Debug', > 'dash1win7.kitware Win32-vs11-Cont', 'dash1win7.kitware Win32-vs11-Shared'] > CMAKE_CXX_COMPILER;C:/Program Files/Microsoft Visual Studio .NET > 2003/Vc7/bin/cl.exe;0.0;['DASH11.kitware Win32-vs71-static'] > CMAKE_CXX_COMPILER;c:/Program Files/Microsoft Visual > Studio/VC98/Bin/CL.EXE;0.0;['DASH3.kitware Win32-vs9-Static', > 'DASH3.kitware Win32-vs9-Shared', 'DASH3.kitware Win32-vs9'] > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Thu, Mar 19, 2015 at 3:39 PM, Sean McBride > wrote: > >> Thanks for these comments. >> >> There is only one hack for gcc 4.0, I'll go ahead and yank it too. >> >> Anyone know if there is a dashboard running gcc 4.1? (My oldest >> buildbot, Rogue3, is running gcc 4.2, specifically Apple's fork.) >> >> Sean >> >> >> >> On Wed, 18 Mar 2015 18:46:04 +0000, Scott, W Alan said: >> >> >Ditto for us. 4.1.2 is the oldest we seem to have. >> > >> >Alan >> > >> >From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf >> >Of Chuck Atkins >> >Sent: Wednesday, March 18, 2015 12:13 PM >> >To: Sean McBride >> >Cc: VTK Developers; vtkusers at vtk.org >> >Subject: [EXTERNAL] Re: [vtk-developers] RFC: Compiler support, removing >> >hacks for old compilers >> > >> >I'd be interested to know from the community what are the oldest >> >compilers you care about? Anyone out there using a compiler older than >> >5 years or so? >> > >> > I'd say for gcc, 4.1.x is likely the oldest you'd need to bother with. >> >That's the system compiler for RHEL5 and SLES10, both of which are EOL'd >> >but still actively deployed. That being said, chances are pretty high >> >that even on those systems, you'd have a newer compiler available via >> >system packages. RHEL5.5 and up has /usr/bin/gcc44 and SLES 10 has /usr/ >> >bin/gcc-4.3, both available as system packages and an alternative to the >> >older /usr/bin/gcc used to compiler their respective kernels. >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Mar 19 16:10:55 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 19 Mar 2015 16:10:55 -0400 Subject: [vtk-developers] [vtkusers] RFC: Compiler support, removing hacks for old compilers In-Reply-To: References: <20150316180926.1146005295@mail.rogue-research.com> <89947a5813a84dc5842498245df50dd6@ES05AMSNLNT.srn.sandia.gov> <20150319193909.1656031800@mail.rogue-research.com> Message-ID: <20150319201055.GC529@megas.kitwarein.com> On Thu, Mar 19, 2015 at 16:01:05 -0400, Shawn Waldon wrote: > FWIW, ParaView has a superbuild nightly binaries machine that runs debian 4 > (gcc 4.1.2). We may be updating to a more recent debian soon though. That's a pretty loose "soon". We need to see if Debian 5 (Lenny) can build Qt5. If so, that will be the new binary builder. Installing a Debian image once its packages have migrated to archive.debian.org is not trivial though. Tips welcome :) . --Ben From david.gobbi at gmail.com Thu Mar 19 16:25:41 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 19 Mar 2015 14:25:41 -0600 Subject: [vtk-developers] Adding support for a macro in wrapper In-Reply-To: References: <20150311184927.GB11496@megas.kitwarein.com> Message-ID: On Thu, Mar 19, 2015 at 12:56 PM, David Lonie wrote: > On Wed, Mar 11, 2015 at 3:47 PM, David Lonie > wrote: > >> On Wed, Mar 11, 2015 at 3:46 PM, David Gobbi >> wrote: >>> >>> The old GetBounds() method might be hidden in the wrapped classes due to >>> "using" being ignored. >>> >> >> I'll be sure to test this before I merge -- thanks for the heads up. >> > > Just FYI, the wrappers seem to handle the 'using Superclass::method;' > statement as expected :D > Let me know when this change is ready for review, and I'll see if I can find a way to break the new GetBounds from the wrappers ;) - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Thu Mar 19 16:26:39 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 19 Mar 2015 16:26:39 -0400 Subject: [vtk-developers] GSOC "VTK Implementation of Eulerian Magnification for Revealing Subtle Changes" Proposal In-Reply-To: <49DE4F47-AC58-49F2-AEC4-A7717BAE9F76@gmail.com> References: <49DE4F47-AC58-49F2-AEC4-A7717BAE9F76@gmail.com> Message-ID: Very nice to meet you Yingjie and thank you for considering working with VTK. Your proposal looks great so far. To the best of my knowledge right now, your plan looks like a good one. When the time comes for picking from and implementing new things in VTK (threading and all) we'll be able to get you up to speed. Falling back to ITK is also perfectly acceptable and we can help with that too if that turns out to be most effective. best of luck with your application! David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Mar 18, 2015 at 6:27 PM, Yingjie <1275963 at gmail.com> wrote: > Hi, > > My name is Yingjie Luan (https://github.com/y1275963) and I am current a > transfer student from University of Leeds in UK and back at home in China > my home university is Lanzhou university. I am currently a year 3 > undergraduate student studying electronic engineering. Since I was enrolled > in the university I have been keen on programming and back at my home I was > the elect member of open source society in Lanzhou University( > https://oss.lzu.edu.cn/). > > I am currently targeting at the project called ?Eulerian Magnification for > revealing subtle changes?. The reasons why I love this project are the the > following: > > 1. I am really interested in implementing all sorts of artificial > algorithms. Just one year ago, I was luckily allowed to work at the > mathematical laboratory at my home university during the winter holiday. > And at that time I spent a great deal of time studying implementing > artificial algorithms like BP Neural network, Generic Algorithm and > simulating annealing. I love to read papers and documentations and write > code. > 2. I have C++ background. Just one year ago, I implemented a laboratory > management system using C++ and Qt.(https://github.com/y1275963/FinalTerm) > So I think I am comfortable with C++. > 3. I have VTK background. Just at this semester, I was luckily enrolled in > Pro. David Duck( > https://www.engineering.leeds.ac.uk/people/computing/staff/d.j.duke)?s > module called ?Scientific Visualization? within which we are discussing a > way to visualize data from early universe using VTK. And Pro. David Duke is > the developer of the VTK class called ?vtkSpanTreeLayoutStrategy?. > 4. The most significant reason why I think I am suitable for this position > is that I think I am a dedicated person and I am self-motivated. I asked > Pro Wang to allow me to work at his mathematical laboratory. Although I am > not allowed to be enrolled in the C++ module back at my home university, I > managed spent my spare time to attend all my professor?s classes and finish > his final project just as same as his enrolled student( Or even better > because I leant Qt at the same time). The module called ?Scientific > Visualization? is for master student but after consulting Pro. David I was > allowed to be enrolled and I think my performance is not worse than those > master students. I think as long as I am willing to devote all my time onto > this project I will be fine. > > The rough idea about the implementation: > > After read though the paper and its related resources, I have got the idea > about this algorithm. It goes like this: > > 1. First, I need to develop a way to construct spatial filter like > Gaussian pyramid or Laplace pyramid. > 2. Second, after I have decomposed the video in spatial domain I then > apply temporal filter onto it. (like ideal filter, Butterworth filter or > second-order IIR filter) > 3. Third, I then amplify the filtered signal according to the description > in the document. Basically what I need to do is to avoid huge magnification > errors by setting approximation limit. > 4. After adding the original signal and the amplified signal back together > and collapsing the the image pyramid we should get the desired video. > > The technical difficulties: > > 1. We only have a Gaussian low pass filter and we don?t have filter to > construct Gaussian pyramid or Laplace pyramid.( We have one in ITK) > 2. The paper suggested us to use YIQ as color space, we need a filter to > transfer the image into YIQ space. > 3. This filter is the combination of temporal and spatial decomposition > and I need to find a way to link them. > 4. For visualizing motion the writer suggested a method called "phase > based video motion processing? which is another topic. > 5. Provide users some guide lines in determining filter parameters. > 6. VTK requires threading process over images and hopefully I can do some > things with parallelize. > 7. To be honest, my biggest concern is how to build VTK filter and that is > area I am going to work really hard onto(Like how to implement Requestdata > function, how to work with images or even time varying images, where should > my filter inherent from) > > > My rough time table goes like this, > 1. I decide to go before the start of the project and I hope by the 25th > May I can get a functioning model using scripting language like MATLAB and > I can get myself familiar with the VTK environment(Especially, writing VTK > filter for time-varying processing) > > 2. I will do my best during the first term of the GSOC. And within that > period I first will do as best as I can to implement the Gaussian pyramid, > Laplace pyramid and YIQ converter. After that, I will combine the designed > spatial filter with the pre-existing temporal filter and FFT in VTK to > build a functioning model in VTK. And I guarantee I can finish this before > 3rd July. > > 3. After I have got the functioning model, I then can do some advanced > topics in the second part of my term, like supporting parallelize, > implementing phase-based pipeline or write a example about this filter( > This is important because we need to give user guide line in terms of how > to select the filter parameters, like amplify ratio and what kind of > schema). > > My questions in terms of this paper: > > 1. I dug into the MATLAB code provided and I am right now trying to > implement the simplest one which is gaussian pyramid along with ideal > filter, and I saw it goes like this: > > % Temporal filtering > disp('Temporal filtering...') > filtered_stack = ideal_bandpassing(Gdown_stack, 1, fl, fh, > samplingRate); > disp('Finished') > > %% amplify > filtered_stack(:,:,:,1) = filtered_stack(:,:,:,1) .* alpha; > filtered_stack(:,:,:,2) = filtered_stack(:,:,:,2) .* alpha .* > chromAttenuation; > filtered_stack(:,:,:,3) = filtered_stack(:,:,:,3) .* alpha .* > chromAttenuation; > > That is, the writer just filter it out and directly amplified them, but in > the paper we should do . Is this true we just assume motion signal is > within the passband of the temporal bandpass filter that after applying the > filter what we get is ? So we don?t need to explicitly calculate the > spatial difference and to find the motion function. > > 2. The color magnification is fairly easy, I still need some work to > understand the maximum application ratio theory for movement > magnification.( Like applying different ratio for each spectral components > of the movement signal) > > 3. There is no ideal bandpass filter in VTK should I use > vtkWindowedSincPolyDataFilter or vtkSmoothPolyDataFilter or implementing my > own?( I think those two filter are all for smoothing and is not for > frequency filtering) > > 4. Am I on the right track? > > In summery, I hope I can be enrolled in this project and I will do my best > not to let my mentor down. I have set up my blog at > http://y1275963.github.io/ and my current progress is that I have > finished the paper and I am digging into how to implement the pyramids. And > I will write a post on my blog as soon as I got the result. I appreciate > your valuable time in reading my proposal and I am looking for your > feedback. > > Yingjie > > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2015-03-18_22-02-24.png Type: image/png Size: 6710 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2015-03-18_22-00-52.png Type: image/png Size: 7578 bytes Desc: not available URL: From ben.boeckel at kitware.com Thu Mar 19 16:27:31 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 19 Mar 2015 16:27:31 -0400 Subject: [vtk-developers] [vtkusers] RFC: Compiler support, removing hacks for old compilers In-Reply-To: References: <20150316180926.1146005295@mail.rogue-research.com> <89947a5813a84dc5842498245df50dd6@ES05AMSNLNT.srn.sandia.gov> <20150319193909.1656031800@mail.rogue-research.com> Message-ID: <20150319202731.GA26366@megas.kitwarein.com> On Thu, Mar 19, 2015 at 16:01:05 -0400, Shawn Waldon wrote: > FWIW, ParaView has a superbuild nightly binaries machine that runs debian 4 > (gcc 4.1.2). We may be updating to a more recent debian soon though. That's a pretty loose "soon". We need to see if Debian 5 (Lenny) can build Qt5. If so, that will be the new binary builder. Installing a Debian image once its packages have migrated to archive.debian.org is not trivial though. Tips welcome :) . --Ben From david.lonie at kitware.com Thu Mar 19 16:28:27 2015 From: david.lonie at kitware.com (David Lonie) Date: Thu, 19 Mar 2015 16:28:27 -0400 Subject: [vtk-developers] Adding support for a macro in wrapper In-Reply-To: References: <20150311184927.GB11496@megas.kitwarein.com> Message-ID: On Thu, Mar 19, 2015 at 4:25 PM, David Gobbi wrote: > On Thu, Mar 19, 2015 at 12:56 PM, David Lonie > wrote: > >> On Wed, Mar 11, 2015 at 3:47 PM, David Lonie >> wrote: >> >>> On Wed, Mar 11, 2015 at 3:46 PM, David Gobbi >>> wrote: >>>> >>>> The old GetBounds() method might be hidden in the wrapped classes due >>>> to "using" being ignored. >>>> >>> >>> I'll be sure to test this before I merge -- thanks for the heads up. >>> >> >> Just FYI, the wrappers seem to handle the 'using Superclass::method;' >> statement as expected :D >> > > Let me know when this change is ready for review, and I'll see if I can > find a way to break the new GetBounds from the wrappers ;) > The work-in-progress is here: https://gitlab.kitware.com/vtk/vtk/merge_requests/24 Feel free to hammer on it! BTW, I've already found an issue with the tcl wrappers, but I've got another thread about that on the way.... -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Thu Mar 19 16:28:56 2015 From: david.lonie at kitware.com (David Lonie) Date: Thu, 19 Mar 2015 16:28:56 -0400 Subject: [vtk-developers] Tcl wrapping and output array arguments Message-ID: I'm working on a branch that will deprecate the: double* GetBounds(); and void GetBounds(double[6]) signatures in vtkAbstractMapper3d and vtkProp to favor a new bool GetBounds(vtkRenderer *, double[6]) signature, as we're looking to add DPI dependence to some mappers/actors. However, some of the old Tcl tests relied on the 'double* GetBounds()' signature, and the new one isn't getting wrapped. My questions: 1) Is the concept of an "output array argument" even supported by Tcl? 2) If so, how can I teach the wrappers about it? 3) If not, is there some way to add a suitable implementation to Tcl, but not C++? And perhaps the most curious question from my point of view, 4) Why do we still provide Tcl bindings in 2015? *ducks* But seriously, can we deprecate them for 6.3? Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Mar 19 17:54:22 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 19 Mar 2015 15:54:22 -0600 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: On Thu, Mar 19, 2015 at 2:28 PM, David Lonie wrote: > > My questions: > > 1) Is the concept of an "output array argument" even supported by Tcl? > Yes. I imagine something like this could create a new array called "bounds": % mapper GetBounds renderer bounds > 2) If so, how can I teach the wrappers about it? > Adding things like this to Tcl is easier than for Java or Python, but it's more than an afternoon's work. I believe that Tcl will already wrap this method, but the wrapped method will expect 6 values as input, instead of expecting one name for an output array that it should create. Because the wrappers can't really tell whether "double[6]" is meant to be used for input or output, the method will actually have to be wrapped twice, once for input, and once for output. There are undoubtedly some tricky complications that I haven't though of, however. > 3) If not, is there some way to add a suitable implementation to Tcl, but > not C++? > > And perhaps the most curious question from my point of view, > > 4) Why do we still provide Tcl bindings in 2015? > Because they're cool! Actually, at this point I'm fine with them going away, but I'd still like to keep Tkinter (which works just fine without the Tcl wrappers). > But seriously, can we deprecate them for 6.3? > Any volunteers to convert TestSetGet and TestEmptyInput to python? - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Thu Mar 19 21:17:47 2015 From: david.thompson at kitware.com (David Thompson) Date: Thu, 19 Mar 2015 21:17:47 -0400 Subject: [vtk-developers] GSoC 2015-CAD Model and Simulation Spline Visualization In-Reply-To: References: <6BD334A2-5477-42A1-B500-6F2B4827A511@kitware.com> Message-ID: <6D747987-ACE4-448E-A9FB-23931788D594@kitware.com> Hi Deevankshu, > ...Since the basis functions of isogeometric analysis are related to control points, and not nodes as shape functions of FEA, the input of node coordinates is replaced by coordinates of control points. Correct. > The element topology is therefore related to the numbering of control points rather than the numbering of element nodes.The isogeometric analysis program based on B?zier extraction will require an extra input, namely the B?zier extraction operators. ... Just to be clear: we are not looking for an implementation of an IGA FEM solver. Instead, we want postprocessing techniques so that people with IGA solvers can use VTK to do post-processing. > A question -> are the "readers" mentioned in the project statement related to this part?About reading the data from CAD files?Can you throw some more light on readers? To simplify things for the project, we would create a few test inputs to verify things work rather than try adapting to a particular solver's file format. There are many solvers out there -- even many open source solvers http://geopdes.sourceforge.net/ http://sourceforge.net/projects/cmcodes/ http://sourceforge.net/projects/igabem/ https://bitbucket.org/dalcinl/petiga and they are all slightly different. If I were doing this project, I would not get fixed to any one solver because I am not using one for any projects. However, if you are using one or know someone who is developing a solver, then it might be a good idea to make use of that in your proposal. > ... > Post-processing part- > As you replied to the rendering question in the previous mail,I re-thought about it and did some further research.... It will write displacements and reactions at the control points,in contrast to FEA which writes these quantities at the nodes. Yes, although another option is to tessellate the splines into simplices (lines, triangles, tetrahedra) and write interpolated values out at the nodes of the simplices. That step will have to be done at some point in order to render the mesh. > ... The displacement ?eld is evaluated at the parametric coordinates which equal the nodes of FEA (for the same polynomial order), and plotted in the physical space. You are correct that we would evaluate the splines at many different parametric coordinates, but I do not understand what you mean by "which equal the nodes of the FEA". > A modi?cation is made to the storing of stress values to be able to plot contour plots of the stresses.The stresses are stored re?ecting the Gauss points? alignment relative to each other in the parameter space. That is not something VTK would like to deal with. Instead, it would be up for the IGA solver to provide B?zier patches to VTK for post-processing; those patches would have values specified at the control points. There are many different schemes for handling numerical integration; it would be wrong to assume that everyone uses Gauss points. For the GSoC project, it is safe to assume that we will come up with tests that provide your code with a sequence of B?zier patches. If we get past the simple tasks like interpolation, inversion, and tessellation then we can worry about BSpline or TSpline conversion. > Also,I have been able to set-up VTK on my system.Can you please tell me which part of the code base I should mainly focus on. It would be useful to understand 1. How arrays are stored (Common/Core/{vtkAbstractArray,vtkDataArray,vtkDoubleArray}). 2. How arrays are composed into datasets (Common/DataModel/{vtkDataObject,vtkDataSet,vtkUnstructuredGrid,vtkMultiBlockDataSet}). 3. How datasets are processed by filters (Common/ExecutionModel/{vtkAlgorithm,vtkUnstructuredGridAlgorithm} and Filters/Core/vtkContourFilter). > One more thing,I haven't been able to completely get through the cutting part.A piece of advice on this would be really very helpful. Here is an example of cutting a dataset using an implicit plane: http://www.vtk.org/Wiki/VTK/Examples/Cxx/VisualizationAlgorithms/CutWithCutFunction Cutting typically produces an output dataset with cells one dimension less than the input dataset's cells. E.g., Cutting a triangle mesh produces line segments. This is because the cut operation intersects the dataset with a cutting tool and generates cells that lie on the intersection. If both the input and cutting tool could be written as implicit functions F(x,y,z) = 0 and G(x,y,z) = 0, the output dataset is the set of points that satisfy both equations. A similar operation is clipping, except that the the cutting tool is not represented with an equation G(x,y,z) = 0 but rather an inequation G(x,y,z) <= 0. Thus clipping generally returns a dataset whose cells have the same dimensions as its input. > Also , what kind of details are you expecting in the proposal ? Do you want it to be mildly broad , or do you want it to be targeted as a needle ? Could you shed some light on it ? I have not participated in GSoC before, so I am not the best person to answer this question. However, others at Kitware who have been mentors before wrote this guide: http://vtk.org/Wiki/GSoC_proposal_guidelines As far as technical details, the guide says you should discuss "What do you intend to do in your proposed project?" You have asked me about the "CAD Model and Simulation Spline Visualization" idea and I have done my best to answer but really, you are proposing something that you are interested in doing; it does not have to be exactly the idea I outlined. My writeup is there to let you know what I am interested in (and what I think Kitware is likely to accept into VTK), not what you must do. David From andrew.amaclean at gmail.com Fri Mar 20 00:28:29 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Fri, 20 Mar 2015 15:28:29 +1100 Subject: [vtk-developers] Tcl wrapping and output array arguments Message-ID: Hi David & David, I'm happy to volunteer to convert TestSetGet and TestEmptyInput to python. The code looks pretty arcane! Looks like Ken Martin originally wrote it in 2001! Regards Andrew ---------- Forwarded message ---------- > From: David Gobbi > To: David Lonie > Cc: VTK Developers > Date: Thu, 19 Mar 2015 15:54:22 -0600 > Subject: Re: [vtk-developers] Tcl wrapping and output array arguments > On Thu, Mar 19, 2015 at 2:28 PM, David Lonie > wrote: > >> >> My questions: >> >> 1) Is the concept of an "output array argument" even supported by Tcl? >> > > Yes. I imagine something like this could create a new array called > "bounds": > > % mapper GetBounds renderer bounds > > >> 2) If so, how can I teach the wrappers about it? >> > > Adding things like this to Tcl is easier than for Java or Python, but it's > more than an afternoon's work. I believe that Tcl will already wrap this > method, but the wrapped method will expect 6 values as input, instead of > expecting one name for an output array that it should create. Because the > wrappers can't really tell whether "double[6]" is meant to be used for > input or output, the method will actually have to be wrapped twice, once > for input, and once for output. There are undoubtedly some tricky > complications that I haven't though of, however. > > >> 3) If not, is there some way to add a suitable implementation to Tcl, but >> not C++? >> >> And perhaps the most curious question from my point of view, >> >> 4) Why do we still provide Tcl bindings in 2015? >> > > Because they're cool! Actually, at this point I'm fine with them going > away, but I'd still like to keep Tkinter (which works just fine without the > Tcl wrappers). > > >> But seriously, can we deprecate them for 6.3? >> > > Any volunteers to convert TestSetGet and TestEmptyInput to python? > > - David > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ljianweiyx at gmail.com Fri Mar 20 01:47:38 2015 From: ljianweiyx at gmail.com (jianwei li) Date: Fri, 20 Mar 2015 13:47:38 +0800 Subject: [vtk-developers] (no subject) Message-ID: Hi I have compile VTK6.2 with Cmake and build it with VS2010,The following,do I need to add the DLL path into system environment or I can install it automaticly with other tools. thank you. Jianwei Li -------------- next part -------------- An HTML attachment was scrubbed... URL: From toku.yuuto at gmail.com Fri Mar 20 07:29:53 2015 From: toku.yuuto at gmail.com (Yuuto Tokunaga) Date: Fri, 20 Mar 2015 11:29:53 +0000 Subject: [vtk-developers] GSoC 2015 Message-ID: Hello. I'm Yuto Tokunaga. I'm a 2nd student of Osaka Univ in Japan, majoring in Physics. I'm interested in some project ideas for GSoC 2015 show below. *KiwiViewer on VTK* I'm interested in mobile development and have some experience of Android Development. I also have experience of GUI application (part time job and my hobby project). *OpenFOAM Catalyst adaptor* I'm interested in this project because I'd used OpenFOAM to visualize result of simulation of thermal convection. When I visited a laboratory studying thermal fluid dynamics, I used OpenFOAM and ParaView (ParaFOAM) to simulate Benard cells. I'm wavering to submit proposal for which project. I don't have so much experience with CFD, so I think I'm unsuitable for the latter project. Please give me some advice. -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Fri Mar 20 08:42:02 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Fri, 20 Mar 2015 08:42:02 -0400 Subject: [vtk-developers] (no subject) In-Reply-To: References: Message-ID: Dear Jianwei, Please direct these questions to the users list. This list is for VTK development discussion not for the use of VTK for other development. The answer to your question depends on what you are going to do with the final libraries and binaries generated. To run any of the binaries created by VTK, you shouldn't have to do anything. You can simply run them from the build tree. Best, -berk On Fri, Mar 20, 2015 at 1:47 AM, jianwei li wrote: > Hi > I have compile VTK6.2 with Cmake and build it with VS2010,The > following,do I need to add the DLL path into system environment or I can > install it automaticly with other tools. > thank you. > Jianwei Li > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Fri Mar 20 09:00:01 2015 From: david.lonie at kitware.com (David Lonie) Date: Fri, 20 Mar 2015 09:00:01 -0400 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi wrote: > On Thu, Mar 19, 2015 at 2:28 PM, David Lonie > wrote: > >> >> My questions: >> >> 1) Is the concept of an "output array argument" even supported by Tcl? >> > > Yes. I imagine something like this could create a new array called > "bounds": > > % mapper GetBounds renderer bounds > > >> 2) If so, how can I teach the wrappers about it? >> > > Adding things like this to Tcl is easier than for Java or Python, but it's > more than an afternoon's work. I believe that Tcl will already wrap this > method, but the wrapped method will expect 6 values as input, instead of > expecting one name for an output array that it should create. Because the > wrappers can't really tell whether "double[6]" is meant to be used for > input or output, the method will actually have to be wrapped twice, once > for input, and once for output. There are undoubtedly some tricky > complications that I haven't though of, however. > Unfortunately, the method is not wrapped currently (according to the generated vtkPropTcl.cxx file, anyway). And perhaps the most curious question from my point of view, >> >> 4) Why do we still provide Tcl bindings in 2015? >> > > Because they're cool! Actually, at this point I'm fine with them going > away, but I'd still like to keep Tkinter (which works just fine without the > Tcl wrappers). > The general consensus from the developers I've talked to out here is the same -- we'd love to see Tcl go. I had a heck of a time trying to even find a developer who remembered enough about Tcl to begin tracking down this issue before I posted on the mailing list...and this includes the people who wrote the original Tcl wrappers ;) > But seriously, can we deprecate them for 6.3? >> > > Any volunteers to convert TestSetGet and TestEmptyInput to python? > Looks like Andrew has volunteered :D I found this discussion from around v6.0's release: http://vtk.1045678.n5.nabble.com/Modularization-Context2D-and-Tcl-td5594211.html Looks like there was a fair bit of resistance against dropping Tcl 2-3 years ago, so I'm not sure how worthwhile it would be to push for this now. But if supporting such a simple method like this requires "more than an afternoon's work" to teach Tcl to understand it, it sounds like more of a burden than a benefit. From what I'm seeing, it's a non-trivial amount of work to keep Tcl working with new APIs and few active developers actually remember Tcl well enough to work on it. Not to mention that in my few years here at Kitware, I've never actually come across an active project that uses Tcl -- not to say they don't exist, but they seem quite rare these days. In any case, decisions like these are beyond me. I'm just a C++ guy trying to add a simple new method to the library :-) Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Fri Mar 20 09:17:32 2015 From: david.lonie at kitware.com (David Lonie) Date: Fri, 20 Mar 2015 09:17:32 -0400 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi wrote: > On Thu, Mar 19, 2015 at 2:28 PM, David Lonie > wrote: > >> 2) If so, how can I teach the wrappers about it? >> > > Adding things like this to Tcl is easier than for Java or Python, but it's > more than an afternoon's work. > One more thing: If you know offhand, can you briefly outline the steps that are needed to do this? That might help clarify whether the maintenance burden is excessive or not. Would it be a one-time deal that would teach Tcl how to wrap all similar methods, or would it need to be repeated for every similar method that gets added? Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Mar 20 09:42:39 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 20 Mar 2015 07:42:39 -0600 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: On Fri, Mar 20, 2015 at 7:17 AM, David Lonie wrote: > On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi > wrote: > >> On Thu, Mar 19, 2015 at 2:28 PM, David Lonie >> wrote: >> >>> 2) If so, how can I teach the wrappers about it? >>> >> >> Adding things like this to Tcl is easier than for Java or Python, but >> it's more than an afternoon's work. >> > > One more thing: > > If you know offhand, can you briefly outline the steps that are needed to > do this? That might help clarify whether the maintenance burden is > excessive or not. Would it be a one-time deal that would teach Tcl how to > wrap all similar methods, or would it need to be repeated for every similar > method that gets added? > My brief outline is this: find the code in vtkWrapTcl.c that builds arrays to be used as return values, and then do something similar for this new kind of method signature, except have it assign a global name (whatever name was passed as a parameter) to the new array instead of returning it. If it is done for this method, it should work for all similar methods. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Fri Mar 20 09:43:42 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Fri, 20 Mar 2015 09:43:42 -0400 Subject: [vtk-developers] GSoC 2015 In-Reply-To: References: Message-ID: Yuuoto, It is a pleasure to make your acquaintance and thanks for considering developing VTK. Students can submit up to five proposals to GSoC (to the same or different mentoring organizations), but they can choose only one if accepted. So I recommend you do this to increase your likelihood of success - pick the one you think you will enjoy the most, submit that first, if you've got the time submit others. As for the proposal: See http://www.vtk.org/Wiki/GSoC_proposal_guidelines for what we are looking for. As I've said before on the list already the more detailed your plan the better since it will show us that you've given it careful thought and have the skill to carry it through. About kiwi viewer: see: - http://www.vtk.org/Wiki/VES/Developers_Guide - http://www.kitware.com/blog/home/post/860 About open foam: - It won't hurt to know CFD, but it isn't really a requirement for the catalyst project. This is more of a data structure conversion exercise initially, once you get it running it gets more fun as you put it through its paces. - http://www.paraview.org/files/catalyst/docs/ParaViewCatalystUsersGuide_v2.pdf especially section 3.3 - https://github.com/OpenFOAM/OpenFOAM-2.2.x/tree/master/applications/utilities/postProcessing/dataConversion/foamToVTK - it might help to look at the vtkOpenFoam reader (either the one in paraview or the one in parafoam as they share a common ancestor at some point), but foamToVTK is probably easier to get your head around good luck with your proposal(s) David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Fri, Mar 20, 2015 at 7:29 AM, Yuuto Tokunaga wrote: > Hello. > > I'm Yuto Tokunaga. I'm a 2nd student of Osaka Univ in Japan, majoring in > Physics. I'm interested in some project ideas for GSoC 2015 show below. > > *KiwiViewer on VTK* > I'm interested in mobile development and have some experience of Android > Development. I also have experience of GUI application (part time job and > my hobby project). > > *OpenFOAM Catalyst adaptor* > I'm interested in this project because I'd used OpenFOAM to visualize > result of simulation of thermal convection. When I visited a laboratory > studying thermal fluid dynamics, I used OpenFOAM and ParaView (ParaFOAM) to > simulate Benard cells. > > I'm wavering to submit proposal for which project. I don't have so much > experience with CFD, so I think I'm unsuitable for the latter project. > Please give me some advice. > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Fri Mar 20 13:47:23 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 20 Mar 2015 10:47:23 -0700 Subject: [vtk-developers] buildbot build names Message-ID: Can the buildbot build name contain the topic. This was very convenient in the gerrit workflow. Bill -- Unpaid intern in BillsBasement at noware dot com From bill.lorensen at gmail.com Fri Mar 20 13:49:09 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 20 Mar 2015 10:49:09 -0700 Subject: [vtk-developers] buildbot message contents Message-ID: The buildbot message contents include this line: Kitware developers may monitor the status of testing here. The link is only available to kitware users. Can this be removed? Bill -- Unpaid intern in BillsBasement at noware dot com From utkarsh.ayachit at kitware.com Fri Mar 20 13:57:23 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Fri, 20 Mar 2015 13:57:23 -0400 Subject: [vtk-developers] buildbot build names In-Reply-To: References: Message-ID: I believe that's doable. On Fri, Mar 20, 2015 at 1:47 PM, Bill Lorensen wrote: > Can the buildbot build name contain the topic. This was very > convenient in the gerrit workflow. > > Bill > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From utkarsh.ayachit at kitware.com Fri Mar 20 14:18:16 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Fri, 20 Mar 2015 14:18:16 -0400 Subject: [vtk-developers] buildbot message contents In-Reply-To: References: Message-ID: > The link is only available to kitware users. Can this be removed? I'd vote against it. Kitware developers are a large part of the development team :). We do plan to make it publicly accessible in time. That way, other users can see what's happening with their builds too. Utkarsh From bill.lorensen at gmail.com Fri Mar 20 14:22:33 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 20 Mar 2015 11:22:33 -0700 Subject: [vtk-developers] buildbot message contents In-Reply-To: References: Message-ID: If we outsiders can eventually see it, I agree to leave it. On Fri, Mar 20, 2015 at 11:18 AM, Utkarsh Ayachit wrote: >> The link is only available to kitware users. Can this be removed? > > I'd vote against it. Kitware developers are a large part of the > development team :). We do plan to make it publicly accessible in > time. That way, other users can see what's happening with their builds > too. > > Utkarsh -- Unpaid intern in BillsBasement at noware dot com From bill.lorensen at gmail.com Fri Mar 20 14:39:47 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 20 Mar 2015 11:39:47 -0700 Subject: [vtk-developers] buildbot email recipients Message-ID: If I do a @buildbot test on another users topic, do they get the email? I do not see them lists in the cc'ed. Bill -- Unpaid intern in BillsBasement at noware dot com From bill.lorensen at gmail.com Fri Mar 20 14:45:56 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 20 Mar 2015 11:45:56 -0700 Subject: [vtk-developers] gitlab-push woes Message-ID: I tried to git gitlab-push a topic that already exist. Here is what I get: git gitlab-push Fetching gitlab master Fetching origin master Pushing to gitlab error: failed to push some refs to 'git at gitlab.kitware.com:lorensen/vtk.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. To git at gitlab.kitware.com:lorensen/vtk.git = 2dfab6b65cd007c67932f6923c4e3cdeb3484b3b:refs/heads/master [up to date] ! HEAD:refs/heads/UpdateRIB [rejected] (non-fast-forward) Done Add "-f" or "--force" to push a rewritten topic. -- Unpaid intern in BillsBasement at noware dot com From brad.king at kitware.com Fri Mar 20 15:31:27 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 20 Mar 2015 15:31:27 -0400 Subject: [vtk-developers] gitlab.kitware.com maintenance Message-ID: <550C758F.7050504@kitware.com> Hi Folks, We will be shutting down gitlab.kitware.com for a little while in order to upgrade the GitLab version to address a couple of issues reported with it. I will post again when normal service is restored. -Brad From utkarsh.ayachit at kitware.com Fri Mar 20 15:34:09 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Fri, 20 Mar 2015 15:34:09 -0400 Subject: [vtk-developers] gitlab-push woes In-Reply-To: References: Message-ID: Bill, Check the end of the message, it says the following: Add "-f" or "--force" to push a rewritten topic. Hence, the following will do the trick: > git gitlab-push -f Utkarsh On Fri, Mar 20, 2015 at 2:45 PM, Bill Lorensen wrote: > I tried to git gitlab-push a topic that already exist. Here is what I get: > git gitlab-push > Fetching gitlab master > Fetching origin master > Pushing to gitlab > error: failed to push some refs to 'git at gitlab.kitware.com:lorensen/vtk.git' > To prevent you from losing history, non-fast-forward updates were rejected > Merge the remote changes (e.g. 'git pull') before pushing again. See the > 'Note about fast-forwards' section of 'git push --help' for details. > To git at gitlab.kitware.com:lorensen/vtk.git > = 2dfab6b65cd007c67932f6923c4e3cdeb3484b3b:refs/heads/master [up to date] > ! HEAD:refs/heads/UpdateRIB [rejected] (non-fast-forward) > Done > > Add "-f" or "--force" to push a rewritten topic. > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From bill.lorensen at gmail.com Fri Mar 20 15:45:04 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 20 Mar 2015 12:45:04 -0700 Subject: [vtk-developers] gitlab-push woes In-Reply-To: References: Message-ID: Did I do something wrong that caused that? On Fri, Mar 20, 2015 at 12:34 PM, Utkarsh Ayachit wrote: > Bill, > > Check the end of the message, it says the following: > > Add "-f" or "--force" to push a rewritten topic. > > Hence, the following will do the trick: > > > git gitlab-push -f > > Utkarsh > > > On Fri, Mar 20, 2015 at 2:45 PM, Bill Lorensen wrote: >> I tried to git gitlab-push a topic that already exist. Here is what I get: >> git gitlab-push >> Fetching gitlab master >> Fetching origin master >> Pushing to gitlab >> error: failed to push some refs to 'git at gitlab.kitware.com:lorensen/vtk.git' >> To prevent you from losing history, non-fast-forward updates were rejected >> Merge the remote changes (e.g. 'git pull') before pushing again. See the >> 'Note about fast-forwards' section of 'git push --help' for details. >> To git at gitlab.kitware.com:lorensen/vtk.git >> = 2dfab6b65cd007c67932f6923c4e3cdeb3484b3b:refs/heads/master [up to date] >> ! HEAD:refs/heads/UpdateRIB [rejected] (non-fast-forward) >> Done >> >> Add "-f" or "--force" to push a rewritten topic. >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> -- Unpaid intern in BillsBasement at noware dot com From brad.king at kitware.com Fri Mar 20 15:51:15 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 20 Mar 2015 15:51:15 -0400 Subject: [vtk-developers] gitlab.kitware.com maintenance In-Reply-To: <550C758F.7050504@kitware.com> References: <550C758F.7050504@kitware.com> Message-ID: <550C7A33.5060808@kitware.com> On 03/20/2015 03:31 PM, Brad King wrote: > We will be shutting down gitlab.kitware.com for a little while in order > to upgrade the GitLab version to address a couple of issues reported > with it. I will post again when normal service is restored. Done. -Brad From utkarsh.ayachit at kitware.com Fri Mar 20 15:57:06 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Fri, 20 Mar 2015 15:57:06 -0400 Subject: [vtk-developers] gitlab-push woes In-Reply-To: References: Message-ID: Not really. Whenever you amend a topic, or rebase a topic, or rewrite the history of a topic in any way, by default, git doesn't let you push that topic to a remote to avoid accidentally overwriting some other changes that have been published previously. Gerrit simply ignored that and let you overwrite things on the remote. We opted to leave the default Git behavior and let the user explicitly state his/her intention by using "-f" when rewriting history on a remote. On Fri, Mar 20, 2015 at 3:45 PM, Bill Lorensen wrote: > Did I do something wrong that caused that? > > > On Fri, Mar 20, 2015 at 12:34 PM, Utkarsh Ayachit > wrote: >> Bill, >> >> Check the end of the message, it says the following: >> >> Add "-f" or "--force" to push a rewritten topic. >> >> Hence, the following will do the trick: >> >> > git gitlab-push -f >> >> Utkarsh >> >> >> On Fri, Mar 20, 2015 at 2:45 PM, Bill Lorensen wrote: >>> I tried to git gitlab-push a topic that already exist. Here is what I get: >>> git gitlab-push >>> Fetching gitlab master >>> Fetching origin master >>> Pushing to gitlab >>> error: failed to push some refs to 'git at gitlab.kitware.com:lorensen/vtk.git' >>> To prevent you from losing history, non-fast-forward updates were rejected >>> Merge the remote changes (e.g. 'git pull') before pushing again. See the >>> 'Note about fast-forwards' section of 'git push --help' for details. >>> To git at gitlab.kitware.com:lorensen/vtk.git >>> = 2dfab6b65cd007c67932f6923c4e3cdeb3484b3b:refs/heads/master [up to date] >>> ! HEAD:refs/heads/UpdateRIB [rejected] (non-fast-forward) >>> Done >>> >>> Add "-f" or "--force" to push a rewritten topic. >>> >>> >>> -- >>> Unpaid intern in BillsBasement at noware dot com >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> > > > > -- > Unpaid intern in BillsBasement at noware dot com From bill.lorensen at gmail.com Fri Mar 20 15:59:19 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 20 Mar 2015 12:59:19 -0700 Subject: [vtk-developers] gitlab-push woes In-Reply-To: References: Message-ID: Sounds good, thanks. Perhaps this should be added to the FAQ. On Fri, Mar 20, 2015 at 12:57 PM, Utkarsh Ayachit wrote: > Not really. Whenever you amend a topic, or rebase a topic, or rewrite > the history of a topic in any way, by default, git doesn't let you > push that topic to a remote to avoid accidentally overwriting some > other changes that have been published previously. Gerrit simply > ignored that and let you overwrite things on the remote. We opted to > leave the default Git behavior and let the user explicitly state > his/her intention by using "-f" when rewriting history on a remote. > > > > On Fri, Mar 20, 2015 at 3:45 PM, Bill Lorensen wrote: >> Did I do something wrong that caused that? >> >> >> On Fri, Mar 20, 2015 at 12:34 PM, Utkarsh Ayachit >> wrote: >>> Bill, >>> >>> Check the end of the message, it says the following: >>> >>> Add "-f" or "--force" to push a rewritten topic. >>> >>> Hence, the following will do the trick: >>> >>> > git gitlab-push -f >>> >>> Utkarsh >>> >>> >>> On Fri, Mar 20, 2015 at 2:45 PM, Bill Lorensen wrote: >>>> I tried to git gitlab-push a topic that already exist. Here is what I get: >>>> git gitlab-push >>>> Fetching gitlab master >>>> Fetching origin master >>>> Pushing to gitlab >>>> error: failed to push some refs to 'git at gitlab.kitware.com:lorensen/vtk.git' >>>> To prevent you from losing history, non-fast-forward updates were rejected >>>> Merge the remote changes (e.g. 'git pull') before pushing again. See the >>>> 'Note about fast-forwards' section of 'git push --help' for details. >>>> To git at gitlab.kitware.com:lorensen/vtk.git >>>> = 2dfab6b65cd007c67932f6923c4e3cdeb3484b3b:refs/heads/master [up to date] >>>> ! HEAD:refs/heads/UpdateRIB [rejected] (non-fast-forward) >>>> Done >>>> >>>> Add "-f" or "--force" to push a rewritten topic. >>>> >>>> >>>> -- >>>> Unpaid intern in BillsBasement at noware dot com >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the list archives at: http://markmail.org/search/?q=vtk-developers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com -- Unpaid intern in BillsBasement at noware dot com From utkarsh.ayachit at kitware.com Fri Mar 20 16:32:07 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Fri, 20 Mar 2015 16:32:07 -0400 Subject: [vtk-developers] buildbot email recipients In-Reply-To: References: Message-ID: Bill, The emails are sent out by GitLab as a consequence of the comment being posted to the merge-request. A merge-request has "participants", which includes the person who created the merge-request and anyone who commented on it or was "included" by using @$username in comments or merge-request message or was assigned to the merge-request. Each of the participants will receive email notifications based on their personal "Profile Settings". By default, all participants get emailed when a comment, including the buildbot notification, is posted on the merge-request. Utkarsh On Fri, Mar 20, 2015 at 2:39 PM, Bill Lorensen wrote: > If I do a > @buildbot test > on another users topic, do they get the email? I do not see them lists > in the cc'ed. > > Bill > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From andrew.amaclean at gmail.com Fri Mar 20 19:38:57 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Sat, 21 Mar 2015 10:38:57 +1100 Subject: [vtk-developers] Tcl wrapping and output array arguments Message-ID: David, David, Will, John I remember the TCL discussion, maybe the time has come to raise dropping it again. I would certainly support that. It was useful before Python was widely used but nowadays I think C++/Python/Java programmers would rarely (if ever) need to use it. Personally I find it difficult to understand and use.It is not a modern language, One of the reasons TCL was useful in the "old days" was that a lot of the testing code was written in it but that is hardly relevant now since we converted almost all of it into Python. Will, I did translate most of the VTK Textbook exercises into Python soon after that discussion (way back in 2012). There were a couple that I couldn't convert, see the attached document for a summary of what I have done. I'll look at converting TestSetGet and TestEmptyInput to python. Regards Andrew > > ---------- Forwarded message ---------- > From: David Lonie > To: David Gobbi > Cc: VTK Developers > Date: Fri, 20 Mar 2015 09:00:01 -0400 > Subject: Re: [vtk-developers] Tcl wrapping and output array arguments > On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi > wrote: > >> On Thu, Mar 19, 2015 at 2:28 PM, David Lonie >> wrote: >> >>> >>> My questions: >>> >>> 1) Is the concept of an "output array argument" even supported by Tcl? >>> >> >> Yes. I imagine something like this could create a new array called >> "bounds": >> >> % mapper GetBounds renderer bounds >> >> >>> 2) If so, how can I teach the wrappers about it? >>> >> >> Adding things like this to Tcl is easier than for Java or Python, but >> it's more than an afternoon's work. I believe that Tcl will already wrap >> this method, but the wrapped method will expect 6 values as input, instead >> of expecting one name for an output array that it should create. Because >> the wrappers can't really tell whether "double[6]" is meant to be used for >> input or output, the method will actually have to be wrapped twice, once >> for input, and once for output. There are undoubtedly some tricky >> complications that I haven't though of, however. >> > > Unfortunately, the method is not wrapped currently (according to the > generated vtkPropTcl.cxx file, anyway). > > And perhaps the most curious question from my point of view, >>> >>> 4) Why do we still provide Tcl bindings in 2015? >>> >> >> Because they're cool! Actually, at this point I'm fine with them going >> away, but I'd still like to keep Tkinter (which works just fine without the >> Tcl wrappers). >> > > The general consensus from the developers I've talked to out here is the > same -- we'd love to see Tcl go. I had a heck of a time trying to even find > a developer who remembered enough about Tcl to begin tracking down this > issue before I posted on the mailing list...and this includes the people > who wrote the original Tcl wrappers ;) > > >> But seriously, can we deprecate them for 6.3? >>> >> >> Any volunteers to convert TestSetGet and TestEmptyInput to python? >> > > Looks like Andrew has volunteered :D > > I found this discussion from around v6.0's release: > > > http://vtk.1045678.n5.nabble.com/Modularization-Context2D-and-Tcl-td5594211.html > > Looks like there was a fair bit of resistance against dropping Tcl 2-3 > years ago, so I'm not sure how worthwhile it would be to push for this now. > > But if supporting such a simple method like this requires "more than an > afternoon's work" to teach Tcl to understand it, it sounds like more of a > burden than a benefit. From what I'm seeing, it's a non-trivial amount of > work to keep Tcl working with new APIs and few active developers actually > remember Tcl well enough to work on it. Not to mention that in my few years > here at Kitware, I've never actually come across an active project that > uses Tcl -- not to say they don't exist, but they seem quite rare these > days. > > In any case, decisions like these are beyond me. I'm just a C++ guy trying > to add a simple new method to the library :-) > > Dave > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- VTK 6.0 All the cxx examples converted Ok. For the python conversions: 1) Added a new file colors.py from VTK\Wrapping\Python\vtk\util\colors.py 2) Added a file called: WindowLevelInterface.py to provide sliders. T: Converted to Tcl for Vtk 6.0 P: Converted to Python for VTK 6.0 T P 3dsToRIB T P animVectors T P *Attenuation: Converted Ok, however for the Python version, an extra file WindowLevelInterface.py provides sliders to manipulate the image. T P blow ############# Frog ################ T P segmented8, SliceOrder blood, brain, brainbin, frog, duodenum, eye_retna.ttcl, eye_white heart, ileum, kidney, l_intestine, liver, lung, nerve, skeleton, spleen, stomach For Python: blood, brain, brainbin, frog, duodenum, eye_retna.ttcl, eye_white heart, ileum, kidney, l_intestine, liver, lung, nerve, skeleton, spleen, stomach were converted to text files. The parameters were rationalised, eliminating duplicate parameters. segmented8.py has been rewritten to so that the *.txt files are read in as parameter files, blood.txt and frog.txt are used if no parameter files are specified. In segmented8.py vtkDecimatePro is used instead of vtkDecimate which gives different results. Default values are provided for the parameters and checks are made for required parameters. T P marching8, SliceOrder, skin For Python: skin has been converted to a test file. T P- renactors - renders all the vtk files created by segmented8 and marching8 - P BuildFrog.py - builds and renders all the tissues of the frog. T P FrogSlice Not working yet for Python. ################################### T P bluntStr - Converted vtkPlot3DReader to vtkMultiBlockPLOT3DReader. T P bottle T P CamBlur - Converted Ok, the writer now uses vtkPNGWriter T P camera T P camera2 T P clipPlane T P clipSphCyl T P ColorSph T P combIso T P complexV T P Cone T P Cone2 T P connPineRoot T P createBFont T P cut Converted vtkPlot3DReader to vtkMultiBlockPLOT3DReader. T P cutModel T P cutPlane T - dcubes: Used the patented vtkDividingCubes replaced with vtkRecursiveDividingCubes. T P deciFran T P deciHawa T - **Decimate T P deciPineRoot T P DelMesh - - *EnhanceEdges: Not converted T P expCos T P extractD T P flamingo T - frogLut T - frogSlice - - *GaussianSmooth T P hawaii T P headBone T P headSlic T P hello T - *HybridMedianComparison, ShotNoiseInclude T P Hyper T P IdealHighPass T P imageWarp T P ironPIso T P IsoSubsample T P LineWidget Converted vtkPlot3DReader to vtkMultiBlockPLOT3DReader. T P LOx T P LOxGrid T P Mace T - *MedianComparison, ShotNoiseInclude T P MotBlur T P motor T P Normals T P office T P officeTube - - opacity - sets opacity for the frog T - *Pad T P pickCells T P probe T P probeComb T P quadricCut T P rainbow Converted vtkPlot3DReader to vtkMultiBlockPLOT3DReader. Added in an example of using a colour transfer function. T P smoothCyl T P sphere T P splatFace T P spring T P stocks T P streamV T P stripF - - sweptVtk vtkSweptSurface is patented. It has been converted but not tested. I don't know of a relacement for vtkSweptSurface. T P tcutSph T P TenEllip T P thrshldV T P TPlane T P uStripeF T - WindowLevel * vtkTkImageViewerWidget not there ** vtkTkRenderWidget not there From will.schroeder at kitware.com Fri Mar 20 20:21:41 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Fri, 20 Mar 2015 20:21:41 -0400 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: Personally I have no real attachment to Tcl and can see queuing it up for deprecation at some point. I'd like to get the community more widely involved in this decision in terms of when, etc. since there may be some significant applications out there still using it and we want to minimize community disruption. There's a lot going on now anyway with the gitlab and OpenGL2 changes so this is not likely to happen anytime soon. W W On Fri, Mar 20, 2015 at 7:38 PM, Andrew Maclean wrote: > David, David, Will, John > > I remember the TCL discussion, maybe the time has come to raise dropping > it again. I would certainly support that. It was useful before Python was > widely used but nowadays I think C++/Python/Java programmers would rarely > (if ever) need to use it. Personally I find it difficult to understand and > use.It is not a modern language, > > One of the reasons TCL was useful in the "old days" was that a lot of the > testing code was written in it but that is hardly relevant now since we > converted almost all of it into Python. > > Will, I did translate most of the VTK Textbook exercises into Python soon > after that discussion (way back in 2012). There were a couple that I > couldn't convert, see the attached document for a summary of what I have > done. > > I'll look at converting TestSetGet and TestEmptyInput to python. > > Regards > Andrew > > >> >> ---------- Forwarded message ---------- >> From: David Lonie >> To: David Gobbi >> Cc: VTK Developers >> Date: Fri, 20 Mar 2015 09:00:01 -0400 >> Subject: Re: [vtk-developers] Tcl wrapping and output array arguments >> On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi >> wrote: >> >>> On Thu, Mar 19, 2015 at 2:28 PM, David Lonie >>> wrote: >>> >>>> >>>> My questions: >>>> >>>> 1) Is the concept of an "output array argument" even supported by Tcl? >>>> >>> >>> Yes. I imagine something like this could create a new array called >>> "bounds": >>> >>> % mapper GetBounds renderer bounds >>> >>> >>>> 2) If so, how can I teach the wrappers about it? >>>> >>> >>> Adding things like this to Tcl is easier than for Java or Python, but >>> it's more than an afternoon's work. I believe that Tcl will already wrap >>> this method, but the wrapped method will expect 6 values as input, instead >>> of expecting one name for an output array that it should create. Because >>> the wrappers can't really tell whether "double[6]" is meant to be used for >>> input or output, the method will actually have to be wrapped twice, once >>> for input, and once for output. There are undoubtedly some tricky >>> complications that I haven't though of, however. >>> >> >> Unfortunately, the method is not wrapped currently (according to the >> generated vtkPropTcl.cxx file, anyway). >> >> And perhaps the most curious question from my point of view, >>>> >>>> 4) Why do we still provide Tcl bindings in 2015? >>>> >>> >>> Because they're cool! Actually, at this point I'm fine with them going >>> away, but I'd still like to keep Tkinter (which works just fine without the >>> Tcl wrappers). >>> >> >> The general consensus from the developers I've talked to out here is the >> same -- we'd love to see Tcl go. I had a heck of a time trying to even find >> a developer who remembered enough about Tcl to begin tracking down this >> issue before I posted on the mailing list...and this includes the people >> who wrote the original Tcl wrappers ;) >> >> >>> But seriously, can we deprecate them for 6.3? >>>> >>> >>> Any volunteers to convert TestSetGet and TestEmptyInput to python? >>> >> >> Looks like Andrew has volunteered :D >> >> I found this discussion from around v6.0's release: >> >> >> http://vtk.1045678.n5.nabble.com/Modularization-Context2D-and-Tcl-td5594211.html >> >> Looks like there was a fair bit of resistance against dropping Tcl 2-3 >> years ago, so I'm not sure how worthwhile it would be to push for this now. >> >> But if supporting such a simple method like this requires "more than an >> afternoon's work" to teach Tcl to understand it, it sounds like more of a >> burden than a benefit. From what I'm seeing, it's a non-trivial amount of >> work to keep Tcl working with new APIs and few active developers actually >> remember Tcl well enough to work on it. Not to mention that in my few years >> here at Kitware, I've never actually come across an active project that >> uses Tcl -- not to say they don't exist, but they seem quite rare these >> days. >> >> In any case, decisions like these are beyond me. I'm just a C++ guy >> trying to add a simple new method to the library :-) >> >> Dave >> >> > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Fri Mar 20 20:23:29 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 20 Mar 2015 17:23:29 -0700 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: Andrew, There are also other tests that use tcl that have not been converted: ./Common/Core/Testing/Tcl/otherPrint.tcl ./Common/DataModel/Testing/Tcl/otherDataSetAttributes.tcl there may be more? like MassProperties TestAmoebaMinimizer TestArrays TestEmptyInput TestPolygonWriters TestSetGet TestString VolumeOutlineSource deciPlane financialField financialField2 financialField3 otherInterp otherPrint probe skinOrder squadViewer On Fri, Mar 20, 2015 at 4:38 PM, Andrew Maclean wrote: > David, David, Will, John > > I remember the TCL discussion, maybe the time has come to raise dropping it > again. I would certainly support that. It was useful before Python was > widely used but nowadays I think C++/Python/Java programmers would rarely > (if ever) need to use it. Personally I find it difficult to understand and > use.It is not a modern language, > > One of the reasons TCL was useful in the "old days" was that a lot of the > testing code was written in it but that is hardly relevant now since we > converted almost all of it into Python. > > Will, I did translate most of the VTK Textbook exercises into Python soon > after that discussion (way back in 2012). There were a couple that I > couldn't convert, see the attached document for a summary of what I have > done. > > I'll look at converting TestSetGet and TestEmptyInput to python. > > Regards > Andrew > >> >> >> ---------- Forwarded message ---------- >> From: David Lonie >> To: David Gobbi >> Cc: VTK Developers >> Date: Fri, 20 Mar 2015 09:00:01 -0400 >> Subject: Re: [vtk-developers] Tcl wrapping and output array arguments >> On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi >> wrote: >>> >>> On Thu, Mar 19, 2015 at 2:28 PM, David Lonie >>> wrote: >>>> >>>> >>>> My questions: >>>> >>>> 1) Is the concept of an "output array argument" even supported by Tcl? >>> >>> >>> Yes. I imagine something like this could create a new array called >>> "bounds": >>> >>> % mapper GetBounds renderer bounds >>> >>>> >>>> 2) If so, how can I teach the wrappers about it? >>> >>> >>> Adding things like this to Tcl is easier than for Java or Python, but >>> it's more than an afternoon's work. I believe that Tcl will already wrap >>> this method, but the wrapped method will expect 6 values as input, instead >>> of expecting one name for an output array that it should create. Because >>> the wrappers can't really tell whether "double[6]" is meant to be used for >>> input or output, the method will actually have to be wrapped twice, once for >>> input, and once for output. There are undoubtedly some tricky complications >>> that I haven't though of, however. >> >> >> Unfortunately, the method is not wrapped currently (according to the >> generated vtkPropTcl.cxx file, anyway). >> >>>> And perhaps the most curious question from my point of view, >>>> >>>> 4) Why do we still provide Tcl bindings in 2015? >>> >>> >>> Because they're cool! Actually, at this point I'm fine with them going >>> away, but I'd still like to keep Tkinter (which works just fine without the >>> Tcl wrappers). >> >> >> The general consensus from the developers I've talked to out here is the >> same -- we'd love to see Tcl go. I had a heck of a time trying to even find >> a developer who remembered enough about Tcl to begin tracking down this >> issue before I posted on the mailing list...and this includes the people who >> wrote the original Tcl wrappers ;) >> >>>> >>>> But seriously, can we deprecate them for 6.3? >>> >>> >>> Any volunteers to convert TestSetGet and TestEmptyInput to python? >> >> >> Looks like Andrew has volunteered :D >> >> I found this discussion from around v6.0's release: >> >> >> http://vtk.1045678.n5.nabble.com/Modularization-Context2D-and-Tcl-td5594211.html >> >> Looks like there was a fair bit of resistance against dropping Tcl 2-3 >> years ago, so I'm not sure how worthwhile it would be to push for this now. >> >> But if supporting such a simple method like this requires "more than an >> afternoon's work" to teach Tcl to understand it, it sounds like more of a >> burden than a benefit. From what I'm seeing, it's a non-trivial amount of >> work to keep Tcl working with new APIs and few active developers actually >> remember Tcl well enough to work on it. Not to mention that in my few years >> here at Kitware, I've never actually come across an active project that uses >> Tcl -- not to say they don't exist, but they seem quite rare these days. >> >> In any case, decisions like these are beyond me. I'm just a C++ guy trying >> to add a simple new method to the library :-) >> >> Dave >> > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From berk.geveci at kitware.com Fri Mar 20 20:24:12 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Fri, 20 Mar 2015 20:24:12 -0400 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: I am not against this either but I'd like to remind people that there are 2 VTK books that still use Tcl for their examples. We probably need to figure out how to transition those before discontinuing Tcl support. -berk On Fri, Mar 20, 2015 at 8:21 PM, Will Schroeder wrote: > Personally I have no real attachment to Tcl and can see queuing it up for > deprecation at some point. I'd like to get the community more widely > involved in this decision in terms of when, etc. since there may be some > significant applications out there still using it and we want to minimize > community disruption. There's a lot going on now anyway with the gitlab and > OpenGL2 changes so this is not likely to happen anytime soon. > > W > > W > > On Fri, Mar 20, 2015 at 7:38 PM, Andrew Maclean > wrote: > >> David, David, Will, John >> >> I remember the TCL discussion, maybe the time has come to raise dropping >> it again. I would certainly support that. It was useful before Python was >> widely used but nowadays I think C++/Python/Java programmers would rarely >> (if ever) need to use it. Personally I find it difficult to understand and >> use.It is not a modern language, >> >> One of the reasons TCL was useful in the "old days" was that a lot of the >> testing code was written in it but that is hardly relevant now since we >> converted almost all of it into Python. >> >> Will, I did translate most of the VTK Textbook exercises into Python soon >> after that discussion (way back in 2012). There were a couple that I >> couldn't convert, see the attached document for a summary of what I have >> done. >> >> I'll look at converting TestSetGet and TestEmptyInput to python. >> >> Regards >> Andrew >> >> >>> >>> ---------- Forwarded message ---------- >>> From: David Lonie >>> To: David Gobbi >>> Cc: VTK Developers >>> Date: Fri, 20 Mar 2015 09:00:01 -0400 >>> Subject: Re: [vtk-developers] Tcl wrapping and output array arguments >>> On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi >>> wrote: >>> >>>> On Thu, Mar 19, 2015 at 2:28 PM, David Lonie >>>> wrote: >>>> >>>>> >>>>> My questions: >>>>> >>>>> 1) Is the concept of an "output array argument" even supported by Tcl? >>>>> >>>> >>>> Yes. I imagine something like this could create a new array called >>>> "bounds": >>>> >>>> % mapper GetBounds renderer bounds >>>> >>>> >>>>> 2) If so, how can I teach the wrappers about it? >>>>> >>>> >>>> Adding things like this to Tcl is easier than for Java or Python, but >>>> it's more than an afternoon's work. I believe that Tcl will already wrap >>>> this method, but the wrapped method will expect 6 values as input, instead >>>> of expecting one name for an output array that it should create. Because >>>> the wrappers can't really tell whether "double[6]" is meant to be used for >>>> input or output, the method will actually have to be wrapped twice, once >>>> for input, and once for output. There are undoubtedly some tricky >>>> complications that I haven't though of, however. >>>> >>> >>> Unfortunately, the method is not wrapped currently (according to the >>> generated vtkPropTcl.cxx file, anyway). >>> >>> And perhaps the most curious question from my point of view, >>>>> >>>>> 4) Why do we still provide Tcl bindings in 2015? >>>>> >>>> >>>> Because they're cool! Actually, at this point I'm fine with them going >>>> away, but I'd still like to keep Tkinter (which works just fine without the >>>> Tcl wrappers). >>>> >>> >>> The general consensus from the developers I've talked to out here is the >>> same -- we'd love to see Tcl go. I had a heck of a time trying to even find >>> a developer who remembered enough about Tcl to begin tracking down this >>> issue before I posted on the mailing list...and this includes the people >>> who wrote the original Tcl wrappers ;) >>> >>> >>>> But seriously, can we deprecate them for 6.3? >>>>> >>>> >>>> Any volunteers to convert TestSetGet and TestEmptyInput to python? >>>> >>> >>> Looks like Andrew has volunteered :D >>> >>> I found this discussion from around v6.0's release: >>> >>> >>> http://vtk.1045678.n5.nabble.com/Modularization-Context2D-and-Tcl-td5594211.html >>> >>> Looks like there was a fair bit of resistance against dropping Tcl 2-3 >>> years ago, so I'm not sure how worthwhile it would be to push for this now. >>> >>> But if supporting such a simple method like this requires "more than an >>> afternoon's work" to teach Tcl to understand it, it sounds like more of a >>> burden than a benefit. From what I'm seeing, it's a non-trivial amount of >>> work to keep Tcl working with new APIs and few active developers actually >>> remember Tcl well enough to work on it. Not to mention that in my few years >>> here at Kitware, I've never actually come across an active project that >>> uses Tcl -- not to say they don't exist, but they seem quite rare these >>> days. >>> >>> In any case, decisions like these are beyond me. I'm just a C++ guy >>> trying to add a simple new method to the library :-) >>> >>> Dave >>> >>> >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ >> > > > > -- > William J. Schroeder, PhD > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Fri Mar 20 20:34:03 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 20 Mar 2015 17:34:03 -0700 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: I checked with Steve Pieper (Slicer guru). He does not care if tcl goes away? Personally, I don't care. In fact I wouldn't care if we dropped java and python. Code coverage is a concern, but that can be fixed if the tcl tests are all converted. On Fri, Mar 20, 2015 at 5:24 PM, Berk Geveci wrote: > I am not against this either but I'd like to remind people that there are 2 > VTK books that still use Tcl for their examples. We probably need to figure > out how to transition those before discontinuing Tcl support. > > -berk > > > On Fri, Mar 20, 2015 at 8:21 PM, Will Schroeder > wrote: >> >> Personally I have no real attachment to Tcl and can see queuing it up for >> deprecation at some point. I'd like to get the community more widely >> involved in this decision in terms of when, etc. since there may be some >> significant applications out there still using it and we want to minimize >> community disruption. There's a lot going on now anyway with the gitlab and >> OpenGL2 changes so this is not likely to happen anytime soon. >> >> W >> >> W >> >> On Fri, Mar 20, 2015 at 7:38 PM, Andrew Maclean >> wrote: >>> >>> David, David, Will, John >>> >>> I remember the TCL discussion, maybe the time has come to raise dropping >>> it again. I would certainly support that. It was useful before Python was >>> widely used but nowadays I think C++/Python/Java programmers would rarely >>> (if ever) need to use it. Personally I find it difficult to understand and >>> use.It is not a modern language, >>> >>> One of the reasons TCL was useful in the "old days" was that a lot of the >>> testing code was written in it but that is hardly relevant now since we >>> converted almost all of it into Python. >>> >>> Will, I did translate most of the VTK Textbook exercises into Python soon >>> after that discussion (way back in 2012). There were a couple that I >>> couldn't convert, see the attached document for a summary of what I have >>> done. >>> >>> I'll look at converting TestSetGet and TestEmptyInput to python. >>> >>> Regards >>> Andrew >>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: David Lonie >>>> To: David Gobbi >>>> Cc: VTK Developers >>>> Date: Fri, 20 Mar 2015 09:00:01 -0400 >>>> Subject: Re: [vtk-developers] Tcl wrapping and output array arguments >>>> On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi >>>> wrote: >>>>> >>>>> On Thu, Mar 19, 2015 at 2:28 PM, David Lonie >>>>> wrote: >>>>>> >>>>>> >>>>>> My questions: >>>>>> >>>>>> 1) Is the concept of an "output array argument" even supported by Tcl? >>>>> >>>>> >>>>> Yes. I imagine something like this could create a new array called >>>>> "bounds": >>>>> >>>>> % mapper GetBounds renderer bounds >>>>> >>>>>> >>>>>> 2) If so, how can I teach the wrappers about it? >>>>> >>>>> >>>>> Adding things like this to Tcl is easier than for Java or Python, but >>>>> it's more than an afternoon's work. I believe that Tcl will already wrap >>>>> this method, but the wrapped method will expect 6 values as input, instead >>>>> of expecting one name for an output array that it should create. Because >>>>> the wrappers can't really tell whether "double[6]" is meant to be used for >>>>> input or output, the method will actually have to be wrapped twice, once for >>>>> input, and once for output. There are undoubtedly some tricky complications >>>>> that I haven't though of, however. >>>> >>>> >>>> Unfortunately, the method is not wrapped currently (according to the >>>> generated vtkPropTcl.cxx file, anyway). >>>> >>>>>> And perhaps the most curious question from my point of view, >>>>>> >>>>>> 4) Why do we still provide Tcl bindings in 2015? >>>>> >>>>> >>>>> Because they're cool! Actually, at this point I'm fine with them going >>>>> away, but I'd still like to keep Tkinter (which works just fine without the >>>>> Tcl wrappers). >>>> >>>> >>>> The general consensus from the developers I've talked to out here is the >>>> same -- we'd love to see Tcl go. I had a heck of a time trying to even find >>>> a developer who remembered enough about Tcl to begin tracking down this >>>> issue before I posted on the mailing list...and this includes the people who >>>> wrote the original Tcl wrappers ;) >>>> >>>>>> >>>>>> But seriously, can we deprecate them for 6.3? >>>>> >>>>> >>>>> Any volunteers to convert TestSetGet and TestEmptyInput to python? >>>> >>>> >>>> Looks like Andrew has volunteered :D >>>> >>>> I found this discussion from around v6.0's release: >>>> >>>> >>>> http://vtk.1045678.n5.nabble.com/Modularization-Context2D-and-Tcl-td5594211.html >>>> >>>> Looks like there was a fair bit of resistance against dropping Tcl 2-3 >>>> years ago, so I'm not sure how worthwhile it would be to push for this now. >>>> >>>> But if supporting such a simple method like this requires "more than an >>>> afternoon's work" to teach Tcl to understand it, it sounds like more of a >>>> burden than a benefit. From what I'm seeing, it's a non-trivial amount of >>>> work to keep Tcl working with new APIs and few active developers actually >>>> remember Tcl well enough to work on it. Not to mention that in my few years >>>> here at Kitware, I've never actually come across an active project that uses >>>> Tcl -- not to say they don't exist, but they seem quite rare these days. >>>> >>>> In any case, decisions like these are beyond me. I'm just a C++ guy >>>> trying to add a simple new method to the library :-) >>>> >>>> Dave >>>> >>> >>> -- >>> ___________________________________________ >>> Andrew J. P. Maclean >>> >>> ___________________________________________ >> >> >> >> >> -- >> William J. Schroeder, PhD >> Kitware, Inc. >> 28 Corporate Drive >> Clifton Park, NY 12065 >> will.schroeder at kitware.com >> http://www.kitware.com >> (518) 881-4902 >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From pieper at isomics.com Fri Mar 20 20:45:05 2015 From: pieper at isomics.com (Steve Pieper) Date: Fri, 20 Mar 2015 20:45:05 -0400 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: When the topic came up on the ARB (back in 2011!) I sent the note quoted below about how we handle this in Slcer4. There is one project (EMSegmenter) that still uses 'tpycl' method discussed below. Everything else has been ported. While it's unconventional, it does work fine and allows people to write good old tcl code even though their vtk is only wrapped for python. It's kinda magical really, and could be used to solve Berk's book concerns -Steve p.s. over beer sometime, just to prove I'm really a crazy old coot, I'll be happy to take the position that python for all it's admitted utility, is still missing many cool features that made tcl especially productive. Hi Guys - As one of the olde timey tcl guys, I'd agree with Andrew's assessment that supporting tcl in the future is not required and should be considered for the chopping block for VTK 6. FWIW, the current development version of slicer (version 4, to be released this year) relies only on the vtk python wrappings. For most purposes, the differences between python and tcl are pretty minimal - but the big thing python has is numpy and the ability to get at image/poly data as numpy arrays. Now with SimplyITK's python bindings it is becoming possible to move bulk data around between packages in very nice ways. For those who are interested, the last vestiges of tcl in slicer are supported by an adapter layer which uses tkinter and a custom package called tpycl (python inside tcl - meant to be pronounced, with a sigh and a roll of the eyes as "typical!"). With typcl, big chunks of slicer code written for tcl wrapped vtk can be run unchanged against a python wrapped vtk. This is used to delay the task of porting/debugging legacy the Editor and the EMSegmenter. http://viewvc.slicer.org/viewvc.cgi/Slicer4/trunk/Base/Python/tpycl/ This layer is for backwards compatibility only - nobody is using it for new development. -Steve On Fri, Mar 20, 2015 at 8:34 PM, Bill Lorensen wrote: > I checked with Steve Pieper (Slicer guru). He does not care if tcl goes > away? > > Personally, I don't care. In fact I wouldn't care if we dropped java and > python. > > Code coverage is a concern, but that can be fixed if the tcl tests are > all converted. > > > On Fri, Mar 20, 2015 at 5:24 PM, Berk Geveci > wrote: > > I am not against this either but I'd like to remind people that there > are 2 > > VTK books that still use Tcl for their examples. We probably need to > figure > > out how to transition those before discontinuing Tcl support. > > > > -berk > > > > > > On Fri, Mar 20, 2015 at 8:21 PM, Will Schroeder < > will.schroeder at kitware.com> > > wrote: > >> > >> Personally I have no real attachment to Tcl and can see queuing it up > for > >> deprecation at some point. I'd like to get the community more widely > >> involved in this decision in terms of when, etc. since there may be some > >> significant applications out there still using it and we want to > minimize > >> community disruption. There's a lot going on now anyway with the gitlab > and > >> OpenGL2 changes so this is not likely to happen anytime soon. > >> > >> W > >> > >> W > >> > >> On Fri, Mar 20, 2015 at 7:38 PM, Andrew Maclean > >> wrote: > >>> > >>> David, David, Will, John > >>> > >>> I remember the TCL discussion, maybe the time has come to raise > dropping > >>> it again. I would certainly support that. It was useful before Python > was > >>> widely used but nowadays I think C++/Python/Java programmers would > rarely > >>> (if ever) need to use it. Personally I find it difficult to understand > and > >>> use.It is not a modern language, > >>> > >>> One of the reasons TCL was useful in the "old days" was that a lot of > the > >>> testing code was written in it but that is hardly relevant now since we > >>> converted almost all of it into Python. > >>> > >>> Will, I did translate most of the VTK Textbook exercises into Python > soon > >>> after that discussion (way back in 2012). There were a couple that I > >>> couldn't convert, see the attached document for a summary of what I > have > >>> done. > >>> > >>> I'll look at converting TestSetGet and TestEmptyInput to python. > >>> > >>> Regards > >>> Andrew > >>> > >>>> > >>>> > >>>> ---------- Forwarded message ---------- > >>>> From: David Lonie > >>>> To: David Gobbi > >>>> Cc: VTK Developers > >>>> Date: Fri, 20 Mar 2015 09:00:01 -0400 > >>>> Subject: Re: [vtk-developers] Tcl wrapping and output array arguments > >>>> On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi > >>>> wrote: > >>>>> > >>>>> On Thu, Mar 19, 2015 at 2:28 PM, David Lonie < > david.lonie at kitware.com> > >>>>> wrote: > >>>>>> > >>>>>> > >>>>>> My questions: > >>>>>> > >>>>>> 1) Is the concept of an "output array argument" even supported by > Tcl? > >>>>> > >>>>> > >>>>> Yes. I imagine something like this could create a new array called > >>>>> "bounds": > >>>>> > >>>>> % mapper GetBounds renderer bounds > >>>>> > >>>>>> > >>>>>> 2) If so, how can I teach the wrappers about it? > >>>>> > >>>>> > >>>>> Adding things like this to Tcl is easier than for Java or Python, but > >>>>> it's more than an afternoon's work. I believe that Tcl will already > wrap > >>>>> this method, but the wrapped method will expect 6 values as input, > instead > >>>>> of expecting one name for an output array that it should create. > Because > >>>>> the wrappers can't really tell whether "double[6]" is meant to be > used for > >>>>> input or output, the method will actually have to be wrapped twice, > once for > >>>>> input, and once for output. There are undoubtedly some tricky > complications > >>>>> that I haven't though of, however. > >>>> > >>>> > >>>> Unfortunately, the method is not wrapped currently (according to the > >>>> generated vtkPropTcl.cxx file, anyway). > >>>> > >>>>>> And perhaps the most curious question from my point of view, > >>>>>> > >>>>>> 4) Why do we still provide Tcl bindings in 2015? > >>>>> > >>>>> > >>>>> Because they're cool! Actually, at this point I'm fine with them > going > >>>>> away, but I'd still like to keep Tkinter (which works just fine > without the > >>>>> Tcl wrappers). > >>>> > >>>> > >>>> The general consensus from the developers I've talked to out here is > the > >>>> same -- we'd love to see Tcl go. I had a heck of a time trying to > even find > >>>> a developer who remembered enough about Tcl to begin tracking down > this > >>>> issue before I posted on the mailing list...and this includes the > people who > >>>> wrote the original Tcl wrappers ;) > >>>> > >>>>>> > >>>>>> But seriously, can we deprecate them for 6.3? > >>>>> > >>>>> > >>>>> Any volunteers to convert TestSetGet and TestEmptyInput to python? > >>>> > >>>> > >>>> Looks like Andrew has volunteered :D > >>>> > >>>> I found this discussion from around v6.0's release: > >>>> > >>>> > >>>> > http://vtk.1045678.n5.nabble.com/Modularization-Context2D-and-Tcl-td5594211.html > >>>> > >>>> Looks like there was a fair bit of resistance against dropping Tcl 2-3 > >>>> years ago, so I'm not sure how worthwhile it would be to push for > this now. > >>>> > >>>> But if supporting such a simple method like this requires "more than > an > >>>> afternoon's work" to teach Tcl to understand it, it sounds like more > of a > >>>> burden than a benefit. From what I'm seeing, it's a non-trivial > amount of > >>>> work to keep Tcl working with new APIs and few active developers > actually > >>>> remember Tcl well enough to work on it. Not to mention that in my few > years > >>>> here at Kitware, I've never actually come across an active project > that uses > >>>> Tcl -- not to say they don't exist, but they seem quite rare these > days. > >>>> > >>>> In any case, decisions like these are beyond me. I'm just a C++ guy > >>>> trying to add a simple new method to the library :-) > >>>> > >>>> Dave > >>>> > >>> > >>> -- > >>> ___________________________________________ > >>> Andrew J. P. Maclean > >>> > >>> ___________________________________________ > >> > >> > >> > >> > >> -- > >> William J. Schroeder, PhD > >> Kitware, Inc. > >> 28 Corporate Drive > >> Clifton Park, NY 12065 > >> will.schroeder at kitware.com > >> http://www.kitware.com > >> (518) 881-4902 > >> > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the list archives at: > http://markmail.org/search/?q=vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > >> > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Fri Mar 20 23:31:39 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Fri, 20 Mar 2015 23:31:39 -0400 Subject: [vtk-developers] buildbot build names In-Reply-To: References: Message-ID: Bill, A fix for this is now live. All CDash buildname are suffixed by the topic name for builds based on merge requests. e.g. https://open.cdash.org/index.php?project=VTK&filtercount=1&showfilters=1&field1=buildname/string&compare1=63&value1=actor-bounds-viewport On Fri, Mar 20, 2015 at 1:57 PM, Utkarsh Ayachit wrote: > I believe that's doable. > > On Fri, Mar 20, 2015 at 1:47 PM, Bill Lorensen wrote: >> Can the buildbot build name contain the topic. This was very >> convenient in the gerrit workflow. >> >> Bill >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> From bill.lorensen at gmail.com Sat Mar 21 00:12:24 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 20 Mar 2015 21:12:24 -0700 Subject: [vtk-developers] buildbot build names In-Reply-To: References: Message-ID: Great. Thanks On Mar 20, 2015 8:31 PM, "Utkarsh Ayachit" wrote: > Bill, > > A fix for this is now live. All CDash buildname are suffixed by the > topic name for builds based on merge requests. > > e.g. > https://open.cdash.org/index.php?project=VTK&filtercount=1&showfilters=1&field1=buildname/string&compare1=63&value1=actor-bounds-viewport > > > > On Fri, Mar 20, 2015 at 1:57 PM, Utkarsh Ayachit > wrote: > > I believe that's doable. > > > > On Fri, Mar 20, 2015 at 1:47 PM, Bill Lorensen > wrote: > >> Can the buildbot build name contain the topic. This was very > >> convenient in the gerrit workflow. > >> > >> Bill > >> > >> -- > >> Unpaid intern in BillsBasement at noware dot com > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > >> > >> Search the list archives at: > http://markmail.org/search/?q=vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Sat Mar 21 11:03:41 2015 From: ken.martin at kitware.com (Ken Martin) Date: Sat, 21 Mar 2015 11:03:41 -0400 Subject: [vtk-developers] gitlab-push woes In-Reply-To: References: Message-ID: Two minor suggestions 1) Make @buildbot and Do: consistent. It seems odd to do "Do: check" or "Do: merge" and then "@buildbot test". I would expect "Do: test" 2) Recognition is better than remembering. It is easier for infrequent developers to **recognize** what they want to do rather than **remembering** what to do. A good example of this is if you add "Do: oops" to a merge request it will respond with a list of valid options so that you can **recognize** what you really wanted, as opposed to just responding with an error and forcing the user to again try to **remember** the correct option. In that vein it might be nice to have the frequently used commands shown. Ideally the GUI has them as options and the user just picks (recognition), but that means messing with the GUI. A not quite as good alternative would be to maybe have a small part of the GUI on the merge request page show the basic commands Do: *** @buildbot *** Add reviewer with @... Or maybe have the "Do: check" output include that help sort of a "Hey passed basic content checks, the next steps are often... Do: ****, @buildbot **** etc" I'm sure those of us using this every day will learn the commands and remember them, but less frequent contributors might get lost. Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee.? Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message.? Thank you. From will.schroeder at kitware.com Sat Mar 21 11:08:55 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Sat, 21 Mar 2015 11:08:55 -0400 Subject: [vtk-developers] gitlab-push woes In-Reply-To: References: Message-ID: +1 On Sat, Mar 21, 2015 at 11:03 AM, Ken Martin wrote: > Two minor suggestions > > 1) Make @buildbot and Do: consistent. It seems odd to do "Do: check" or > "Do: merge" and then "@buildbot test". I would expect "Do: test" > > 2) Recognition is better than remembering. It is easier for infrequent > developers to **recognize** what they want to do rather than > **remembering** what to do. A good example of this is if you add "Do: > oops" to a merge request it will respond with a list of valid options so > that you can **recognize** what you really wanted, as opposed to just > responding with an error and forcing the user to again try to **remember** > the correct option. In that vein it might be nice to have the frequently > used commands shown. Ideally the GUI has them as options and the user > just picks (recognition), but that means messing with the GUI. A not quite > as good alternative would be to maybe have a small part of the GUI on the > merge request page show the basic commands > > Do: *** > @buildbot *** > Add reviewer with @... > > Or maybe have the "Do: check" output include that help sort of a > > "Hey passed basic content checks, the next steps are often... Do: ****, > @buildbot **** etc" > > I'm sure those of us using this every day will learn the commands and > remember them, but less frequent contributors might get lost. > > Thanks > Ken > > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > ken.martin at kitware.com > 518 881-4901 (w) > 518 371-4573 (f) > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you > are not the intended recipient, any disclosure, copying, distribution or > any action taken in reliance on it is prohibited and may be unlawful. If > you received this communication in error please notify us immediately and > destroy the original message. Thank you. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Sat Mar 21 11:10:04 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sat, 21 Mar 2015 08:10:04 -0700 Subject: [vtk-developers] gitlab-push woes In-Reply-To: References: Message-ID: +1 On Mar 21, 2015 8:03 AM, "Ken Martin" wrote: > Two minor suggestions > > 1) Make @buildbot and Do: consistent. It seems odd to do "Do: check" or > "Do: merge" and then "@buildbot test". I would expect "Do: test" > > 2) Recognition is better than remembering. It is easier for infrequent > developers to **recognize** what they want to do rather than > **remembering** what to do. A good example of this is if you add "Do: > oops" to a merge request it will respond with a list of valid options so > that you can **recognize** what you really wanted, as opposed to just > responding with an error and forcing the user to again try to **remember** > the correct option. In that vein it might be nice to have the frequently > used commands shown. Ideally the GUI has them as options and the user > just picks (recognition), but that means messing with the GUI. A not quite > as good alternative would be to maybe have a small part of the GUI on the > merge request page show the basic commands > > Do: *** > @buildbot *** > Add reviewer with @... > > Or maybe have the "Do: check" output include that help sort of a > > "Hey passed basic content checks, the next steps are often... Do: ****, > @buildbot **** etc" > > I'm sure those of us using this every day will learn the commands and > remember them, but less frequent contributors might get lost. > > Thanks > Ken > > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > ken.martin at kitware.com > 518 881-4901 (w) > 518 371-4573 (f) > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you > are not the intended recipient, any disclosure, copying, distribution or > any action taken in reliance on it is prohibited and may be unlawful. If > you received this communication in error please notify us immediately and > destroy the original message. Thank you. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Sat Mar 21 12:24:14 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Sat, 21 Mar 2015 12:24:14 -0400 Subject: [vtk-developers] gitlab-push woes In-Reply-To: References: Message-ID: <20150321162413.GA12388@bronto-burt.dev.benboeckel.net> On Sat, Mar 21, 2015 at 11:03:41 -0400, Ken Martin wrote: > 1) Make @buildbot and Do: consistent. It seems odd to do "Do: check" or > "Do: merge" and then "@buildbot test". I would expect "Do: test" I agree, but currently these are managed by completely different tools. Currently, they have no knowledge of each other and keeping kwrobot configuration kept up-to-date in tandem with buildbot changes is not something I want to maintain long-term. The best solution would be to have kwrobot tell buildbot to do things rather than having buildbot do its own scraping[1], but this is not even started (and I don't have a timeline for it right now since I have other projects that need attention now that the infrastructure is in a workable state). Once kwrobot is doing the buildbot orchestration, I would support adding a "Do: build" command since it would go through the same code as the existing "Do:" commands. > 2) Recognition is better than remembering. It is easier for infrequent > developers to **recognize** what they want to do rather than > **remembering** what to do. A good example of this is if you add "Do: > oops" to a merge request it will respond with a list of valid options so Kwrobot will respond to unknown commands with what it is configured to understand (for that project; some are set up to just have checks done and not merging). Currently, buildbot is silent except for the "your builds have been scheduled", but similar error messages can be added until the "Do: build" logic is implemented. > that you can **recognize** what you really wanted, as opposed to just > responding with an error and forcing the user to again try to **remember** > the correct option. In that vein it might be nice to have the frequently > used commands shown. Ideally the GUI has them as options and the user > just picks (recognition), but that means messing with the GUI. A not quite > as good alternative would be to maybe have a small part of the GUI on the > merge request page show the basic commands > > Do: *** > @buildbot *** > Add reviewer with @... > > Or maybe have the "Do: check" output include that help sort of a > > "Hey passed basic content checks, the next steps are often... Do: ****, > @buildbot **** etc" Changing the UI to have the instructions verbatim is not trivial maintenance-wise (it's not something we can upstream and we would have to patch on every upgrade). Instead, having the MR submission and view have links to guidelines and workflows would be upstreamable, but these should be placed in the repository so we can link to them and don't need to patch our GitLab instance for workflow changes. I can add this to the TODO list, but since this likely would require a database change (for the file to link to), is something that may take longer to figure out how to do properly. In the meantime, I can have kwrobot add a link to the "help" documentation on a per-project basis (again, I don't want it to be static so it isn't spammy and I don't want to have to make kwrobot updates for workflow documentation changes). --Ben [1]This would also keep the logic in one place for not scheduling builds for MRs with Rejected-by comments, requiring at least an Acked-by on external contributions before they are scheduled, etc. From csharpdotcom at gmail.com Sat Mar 21 12:33:40 2015 From: csharpdotcom at gmail.com (CSharpdotcom .) Date: Sat, 21 Mar 2015 09:33:40 -0700 Subject: [vtk-developers] Problems installing VTK Message-ID: Hello, I'm new to VTK and this is my first posting here or on any other forum related to VTK. I've been trying for about a week to get VTK installed and running on my computer. The project I'm working on is to use Java with VTK to represent 3D graphics, which I hope to use with NetBeans 8.0.2. I also have Visual Studio Pro 2010. After failed attempts in installing VTK 6.2.0 and the latest version of CMake, from the link http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk I downloaded and unzipped VTK 6.1.0 and CMake 3.0.0, then installed them. I then ran CMake according to the instructions on that link and installed the generated code in the folder C:\VTK. I then clicked on the file VTK.sin in that folder, which opened up Visual Studio and started compiling the code with a large number of modules in the project. This took about an hour, and on completion, generated the line at the end: Build: 387 succeeded, 1 failed, 0 up-to-date, 0 skipped I saved this in a file, which is very long, and after some effort found the error message: 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: 1 unresolved externals In the mean time I attempted to recompile the project, which was much quicker, and got the same message. In recompiled I checked the "INSTALL" option, which had not previously been checked, although I don't know if that is significant. Located in the folder \VTK\java\sample\rendering is the source file AwTConeRendering.java, which apparently has not been compiled. I created a NetBeans project and copied that file into it, then linked vtk.jar in the folder \VTK\bin to the project, and all imports were satisfied. In setting the Windows path to point to the dll files in \VTK\bin\Release, the application appears to pick up the dll files correctly, however, I get the following error message: java.lang.UnsatisfiedLinkError: C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent libraries repeated for many dll files. Incidentally, as Visual Studio dlls are all 32 bits, as far as I know, I set up NetBeans to use a 32 bit JVM. This had previously been tested successfully with a test dll I created with Visual Studio and could execute with NetBeans. This problem is presumably related to the first error mentioned above, and would be most grateful in getting this issue resolved. As I said, I'm new to VTK, and in fact only in the last couple of weeks have tried for the first time to call a dll file from a Java application on a Windows computer. In the Java code I added the statement: System.out.println(System.getProperty("java.library.path")); to check that the path was correct, which is the case. From sebastien.jourdain at kitware.com Sat Mar 21 13:26:07 2015 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Sat, 21 Mar 2015 11:26:07 -0600 Subject: [vtk-developers] Problems installing VTK In-Reply-To: References: Message-ID: Te java.library.path is not enough and you need to add into your environment PATH the following directory, C:\VTK\bin\Release. set PATH=C:\VTK\bin\Release;%PATH% Seb On Sat, Mar 21, 2015 at 10:33 AM, CSharpdotcom . wrote: > Hello, > > I'm new to VTK and this is my first posting here or on any other forum > related to VTK. > > I've been trying for about a week to get VTK installed and running on > my computer. The project I'm working on is to use Java with VTK to > represent 3D graphics, which I hope to use with NetBeans 8.0.2. I > also have Visual Studio Pro 2010. > > After failed attempts in installing VTK 6.2.0 and the latest version > of CMake, from the link > http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk > I downloaded and unzipped VTK 6.1.0 and CMake 3.0.0, then installed > them. > > I then ran CMake according to the instructions on that link and > installed the generated code in the folder C:\VTK. I then clicked on > the file VTK.sin in that folder, which opened up Visual Studio and > started compiling the code with a large number of modules in the > project. This took about an hour, and on completion, generated the > line at the end: > > Build: 387 succeeded, 1 failed, 0 up-to-date, 0 skipped > > I saved this in a file, which is very long, and after some effort > found the error message: > > 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: > 1 unresolved externals > > In the mean time I attempted to recompile the project, which was much > quicker, and got the same message. In recompiled I checked the > "INSTALL" option, which had not previously been checked, although I > don't know if that is significant. > > Located in the folder \VTK\java\sample\rendering is the source file > AwTConeRendering.java, which apparently has not been compiled. I > created a NetBeans project and copied that file into it, then linked > vtk.jar in the folder \VTK\bin to the project, and all imports were > satisfied. In setting the Windows path to point to the dll files in > \VTK\bin\Release, the application appears to pick up the dll files > correctly, however, I get the following error message: > > java.lang.UnsatisfiedLinkError: > C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent > libraries > > repeated for many dll files. Incidentally, as Visual Studio dlls are > all 32 bits, as far as I know, I set up NetBeans to use a 32 bit JVM. > This had previously been tested successfully with a test dll I created > with Visual Studio and could execute with NetBeans. > > This problem is presumably related to the first error mentioned above, > and would be most grateful in getting this issue resolved. As I said, > I'm new to VTK, and in fact only in the last couple of weeks have > tried for the first time to call a dll file from a Java application on > a Windows computer. > > In the Java code I added the statement: > > System.out.println(System.getProperty("java.library.path")); > > to check that the path was correct, which is the case. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From csharpdotcom at gmail.com Sat Mar 21 16:58:35 2015 From: csharpdotcom at gmail.com (CSharpdotcom .) Date: Sat, 21 Mar 2015 13:58:35 -0700 Subject: [vtk-developers] Problems installing VTK In-Reply-To: References: Message-ID: I already had PATH=C:\VTK\bin\Release, and added ;%PATH% at the end, but it still doesn't work, and get the following output: java.lang.UnsatisfiedLinkError: C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent libraries at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1119) at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) at vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) at vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) java.lang.UnsatisfiedLinkError: C:\VTK\bin\Release\vtkDomainsChemistryJava.dll: Can't find dependent libraries at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1119) at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) at vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) at vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) ................... These error messages continue, then a list of files not loaded are printed out, as given in the source code. Based on these error messages it's picking up the dll files in the \Release folder, but it's unable to find other files that these dll files depend on. Do you want a full listing of the Java source file? The AwtConeRendering class starts off with: static { System.out.println(System.getProperty("java.library.path")); if (!vtkNativeLibrary.LoadAllNativeLibraries()) { for (vtkNativeLibrary lib : vtkNativeLibrary.values()) { if (!lib.IsLoaded()) { System.out.println(lib.GetLibraryName() + " not loaded"); } } } vtkNativeLibrary.DisableOutputWindow(null); } which is followed by the main() method, which contains statements such as: vtkConeSource cone = new vtkConeSource(); csharp On Sat, Mar 21, 2015 at 10:26 AM, Sebastien Jourdain wrote: > Te java.library.path is not enough and you need to add into your environment > PATH the following directory, C:\VTK\bin\Release. > > set PATH=C:\VTK\bin\Release;%PATH% > > Seb > > On Sat, Mar 21, 2015 at 10:33 AM, CSharpdotcom . > wrote: >> >> Hello, >> >> I'm new to VTK and this is my first posting here or on any other forum >> related to VTK. >> >> I've been trying for about a week to get VTK installed and running on >> my computer. The project I'm working on is to use Java with VTK to >> represent 3D graphics, which I hope to use with NetBeans 8.0.2. I >> also have Visual Studio Pro 2010. >> >> After failed attempts in installing VTK 6.2.0 and the latest version >> of CMake, from the link >> http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk >> I downloaded and unzipped VTK 6.1.0 and CMake 3.0.0, then installed >> them. >> >> I then ran CMake according to the instructions on that link and >> installed the generated code in the folder C:\VTK. I then clicked on >> the file VTK.sin in that folder, which opened up Visual Studio and >> started compiling the code with a large number of modules in the >> project. This took about an hour, and on completion, generated the >> line at the end: >> >> Build: 387 succeeded, 1 failed, 0 up-to-date, 0 skipped >> >> I saved this in a file, which is very long, and after some effort >> found the error message: >> >> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: >> 1 unresolved externals >> >> In the mean time I attempted to recompile the project, which was much >> quicker, and got the same message. In recompiled I checked the >> "INSTALL" option, which had not previously been checked, although I >> don't know if that is significant. >> >> Located in the folder \VTK\java\sample\rendering is the source file >> AwTConeRendering.java, which apparently has not been compiled. I >> created a NetBeans project and copied that file into it, then linked >> vtk.jar in the folder \VTK\bin to the project, and all imports were >> satisfied. In setting the Windows path to point to the dll files in >> \VTK\bin\Release, the application appears to pick up the dll files >> correctly, however, I get the following error message: >> >> java.lang.UnsatisfiedLinkError: >> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >> libraries >> >> repeated for many dll files. Incidentally, as Visual Studio dlls are >> all 32 bits, as far as I know, I set up NetBeans to use a 32 bit JVM. >> This had previously been tested successfully with a test dll I created >> with Visual Studio and could execute with NetBeans. >> >> This problem is presumably related to the first error mentioned above, >> and would be most grateful in getting this issue resolved. As I said, >> I'm new to VTK, and in fact only in the last couple of weeks have >> tried for the first time to call a dll file from a Java application on >> a Windows computer. >> >> In the Java code I added the statement: >> >> System.out.println(System.getProperty("java.library.path")); >> >> to check that the path was correct, which is the case. >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > From sebastien.jourdain at kitware.com Sat Mar 21 18:04:23 2015 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Sat, 21 Mar 2015 16:04:23 -0600 Subject: [vtk-developers] Problems installing VTK In-Reply-To: References: Message-ID: Try to load the libraries that you need to load instead of all of them. It seems that you didn't build everything (which is probably fine). Seb On Sat, Mar 21, 2015 at 2:58 PM, CSharpdotcom . wrote: > I already had PATH=C:\VTK\bin\Release, and added ;%PATH% at the end, > but it still doesn't work, and get the following output: > > java.lang.UnsatisfiedLinkError: > C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent > libraries > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) at > java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) > at java.lang.Runtime.loadLibrary0(Runtime.java:870) > at java.lang.System.loadLibrary(System.java:1119) > at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) > at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) > at > vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) > at > vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) > java.lang.UnsatisfiedLinkError: > C:\VTK\bin\Release\vtkDomainsChemistryJava.dll: Can't find dependent > libraries > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) > at java.lang.Runtime.loadLibrary0(Runtime.java:870) > at java.lang.System.loadLibrary(System.java:1119) > at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) > at > vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) > at > vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) > ................... > > These error messages continue, then a list of files not loaded are > printed out, as given in the source code. > > Based on these error messages it's picking up the dll files in the > \Release folder, but it's unable to find other files that these dll > files depend on. > > Do you want a full listing of the Java source file? The > AwtConeRendering class starts off with: > > static { > System.out.println(System.getProperty("java.library.path")); > if (!vtkNativeLibrary.LoadAllNativeLibraries()) { > for (vtkNativeLibrary lib : vtkNativeLibrary.values()) { > if (!lib.IsLoaded()) { > System.out.println(lib.GetLibraryName() + " not loaded"); > } > } > } > vtkNativeLibrary.DisableOutputWindow(null); > } > > which is followed by the main() method, which contains statements such as: > > vtkConeSource cone = new vtkConeSource(); > > csharp > > On Sat, Mar 21, 2015 at 10:26 AM, Sebastien Jourdain > wrote: > > Te java.library.path is not enough and you need to add into your > environment > > PATH the following directory, C:\VTK\bin\Release. > > > > set PATH=C:\VTK\bin\Release;%PATH% > > > > Seb > > > > On Sat, Mar 21, 2015 at 10:33 AM, CSharpdotcom . > > > wrote: > >> > >> Hello, > >> > >> I'm new to VTK and this is my first posting here or on any other forum > >> related to VTK. > >> > >> I've been trying for about a week to get VTK installed and running on > >> my computer. The project I'm working on is to use Java with VTK to > >> represent 3D graphics, which I hope to use with NetBeans 8.0.2. I > >> also have Visual Studio Pro 2010. > >> > >> After failed attempts in installing VTK 6.2.0 and the latest version > >> of CMake, from the link > >> http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk > >> I downloaded and unzipped VTK 6.1.0 and CMake 3.0.0, then installed > >> them. > >> > >> I then ran CMake according to the instructions on that link and > >> installed the generated code in the folder C:\VTK. I then clicked on > >> the file VTK.sin in that folder, which opened up Visual Studio and > >> started compiling the code with a large number of modules in the > >> project. This took about an hour, and on completion, generated the > >> line at the end: > >> > >> Build: 387 succeeded, 1 failed, 0 up-to-date, 0 skipped > >> > >> I saved this in a file, which is very long, and after some effort > >> found the error message: > >> > >> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: > >> 1 unresolved externals > >> > >> In the mean time I attempted to recompile the project, which was much > >> quicker, and got the same message. In recompiled I checked the > >> "INSTALL" option, which had not previously been checked, although I > >> don't know if that is significant. > >> > >> Located in the folder \VTK\java\sample\rendering is the source file > >> AwTConeRendering.java, which apparently has not been compiled. I > >> created a NetBeans project and copied that file into it, then linked > >> vtk.jar in the folder \VTK\bin to the project, and all imports were > >> satisfied. In setting the Windows path to point to the dll files in > >> \VTK\bin\Release, the application appears to pick up the dll files > >> correctly, however, I get the following error message: > >> > >> java.lang.UnsatisfiedLinkError: > >> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent > >> libraries > >> > >> repeated for many dll files. Incidentally, as Visual Studio dlls are > >> all 32 bits, as far as I know, I set up NetBeans to use a 32 bit JVM. > >> This had previously been tested successfully with a test dll I created > >> with Visual Studio and could execute with NetBeans. > >> > >> This problem is presumably related to the first error mentioned above, > >> and would be most grateful in getting this issue resolved. As I said, > >> I'm new to VTK, and in fact only in the last couple of weeks have > >> tried for the first time to call a dll file from a Java application on > >> a Windows computer. > >> > >> In the Java code I added the statement: > >> > >> System.out.println(System.getProperty("java.library.path")); > >> > >> to check that the path was correct, which is the case. > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the list archives at: > http://markmail.org/search/?q=vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From csharpdotcom at gmail.com Sat Mar 21 20:05:05 2015 From: csharpdotcom at gmail.com (CSharpdotcom .) Date: Sat, 21 Mar 2015 17:05:05 -0700 Subject: [vtk-developers] Problems installing VTK In-Reply-To: References: Message-ID: Hello, Many thanks, but as I'm new ti VTK I don't know which libraries to load. However, in looking at: http://www.vtk.org/Wiki/VTK/Examples/Java/Miscellaneous/Cone6 which has similar code. The statement: System.loadLibrary("vtkCommonJava"); doesn't load as there is no dll with that name in the folder C:\VTK\bin\Release, but: System.loadLibrary("vtkCommonCoreJava"); does load correctly as there is a dll with that name. This applies to a few other files, but not all of them. Without the required dlls loaded, even if no errors are produced, the code will not execute. If I go back to the original code when I try and load everything, then I get the error message: java.lang.UnsatisfiedLinkError: C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent libraries The file vtkChartsCoreJava.dll is present in that folder, so it is loaded, but its dependencies cannot be found. This applies to quite a few other dll files with dependencies, and I also get a list of a large number files that were not loaded from the statement: if (!lib.IsLoaded()) System.out.println(lib.GetLibraryName() + " not loaded"); inside the for-loop in an earlier message. It looks that without these large number of files, possibly all of them, that have not been loaded the code will not work, even if I skip over the bad loads or put the loop in a try-catch loop. This must have something to do with the error message in the log during the build process with Visual Studio Pro 2010 I did a few days ago. I don't fully understand the log, but the section where it failed is here: 112>Link: 112> Creating library C:/VTK/lib/Release/vtkRenderingCoreJava.lib and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp 114> vtkDepthPeeling_fs.cxx 114> vtkGaussianBlurPassShader_fs.cxx 114> vtkLighting_s.cxx 114> vtkLightingHelper_s.cxx 114> vtkOpenGLRenderer_PeelingFS.cxx 114> vtkOpenGLPropertyDefaultPropFunc_fs.cxx 114> vtkOpenGLPropertyDefaultPropFunc_vs.cxx 112>vtkRenderWindowJava.obj : error LNK2019: unresolved external symbol __imp__JAWT_GetAWT at 8 referenced in function _Java_vtk_vtkPanel_RenderCreate at 12 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: 1 unresolved externals 114> vtkOpenGLPropertyDefaultMain_fs.cxx 112> 112>Build FAILED. 112> 112>Time Elapsed 00:01:32.30 Obviously vtkRenderingCoreJava.dll failed to link, which must be the cause of the problems I'm having. This was the only failure, with the other 387 compilations and linking successful. If this problem can be fixed, I hope I will be home and dry. I would most appreciate you or someone else kindly getting this resolved. csharp On Sat, Mar 21, 2015 at 3:04 PM, Sebastien Jourdain wrote: > Try to load the libraries that you need to load instead of all of them. It > seems that you didn't build everything (which is probably fine). > > Seb > > On Sat, Mar 21, 2015 at 2:58 PM, CSharpdotcom . > wrote: >> >> I already had PATH=C:\VTK\bin\Release, and added ;%PATH% at the end, >> but it still doesn't work, and get the following output: >> >> java.lang.UnsatisfiedLinkError: >> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >> libraries >> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) at >> java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >> at java.lang.System.loadLibrary(System.java:1119) >> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >> at >> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >> at >> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >> java.lang.UnsatisfiedLinkError: >> C:\VTK\bin\Release\vtkDomainsChemistryJava.dll: Can't find dependent >> libraries >> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >> at java.lang.System.loadLibrary(System.java:1119) >> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >> at >> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >> at >> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >> ................... >> >> These error messages continue, then a list of files not loaded are >> printed out, as given in the source code. >> >> Based on these error messages it's picking up the dll files in the >> \Release folder, but it's unable to find other files that these dll >> files depend on. >> >> Do you want a full listing of the Java source file? The >> AwtConeRendering class starts off with: >> >> static { >> System.out.println(System.getProperty("java.library.path")); >> if (!vtkNativeLibrary.LoadAllNativeLibraries()) { >> for (vtkNativeLibrary lib : vtkNativeLibrary.values()) { >> if (!lib.IsLoaded()) { >> System.out.println(lib.GetLibraryName() + " not loaded"); >> } >> } >> } >> vtkNativeLibrary.DisableOutputWindow(null); >> } >> >> which is followed by the main() method, which contains statements such as: >> >> vtkConeSource cone = new vtkConeSource(); >> >> csharp >> >> On Sat, Mar 21, 2015 at 10:26 AM, Sebastien Jourdain >> wrote: >> > Te java.library.path is not enough and you need to add into your >> > environment >> > PATH the following directory, C:\VTK\bin\Release. >> > >> > set PATH=C:\VTK\bin\Release;%PATH% >> > >> > Seb >> > >> > On Sat, Mar 21, 2015 at 10:33 AM, CSharpdotcom . >> > >> > wrote: >> >> >> >> Hello, >> >> >> >> I'm new to VTK and this is my first posting here or on any other forum >> >> related to VTK. >> >> >> >> I've been trying for about a week to get VTK installed and running on >> >> my computer. The project I'm working on is to use Java with VTK to >> >> represent 3D graphics, which I hope to use with NetBeans 8.0.2. I >> >> also have Visual Studio Pro 2010. >> >> >> >> After failed attempts in installing VTK 6.2.0 and the latest version >> >> of CMake, from the link >> >> http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk >> >> I downloaded and unzipped VTK 6.1.0 and CMake 3.0.0, then installed >> >> them. >> >> >> >> I then ran CMake according to the instructions on that link and >> >> installed the generated code in the folder C:\VTK. I then clicked on >> >> the file VTK.sin in that folder, which opened up Visual Studio and >> >> started compiling the code with a large number of modules in the >> >> project. This took about an hour, and on completion, generated the >> >> line at the end: >> >> >> >> Build: 387 succeeded, 1 failed, 0 up-to-date, 0 skipped >> >> >> >> I saved this in a file, which is very long, and after some effort >> >> found the error message: >> >> >> >> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: >> >> 1 unresolved externals >> >> >> >> In the mean time I attempted to recompile the project, which was much >> >> quicker, and got the same message. In recompiled I checked the >> >> "INSTALL" option, which had not previously been checked, although I >> >> don't know if that is significant. >> >> >> >> Located in the folder \VTK\java\sample\rendering is the source file >> >> AwTConeRendering.java, which apparently has not been compiled. I >> >> created a NetBeans project and copied that file into it, then linked >> >> vtk.jar in the folder \VTK\bin to the project, and all imports were >> >> satisfied. In setting the Windows path to point to the dll files in >> >> \VTK\bin\Release, the application appears to pick up the dll files >> >> correctly, however, I get the following error message: >> >> >> >> java.lang.UnsatisfiedLinkError: >> >> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >> >> libraries >> >> >> >> repeated for many dll files. Incidentally, as Visual Studio dlls are >> >> all 32 bits, as far as I know, I set up NetBeans to use a 32 bit JVM. >> >> This had previously been tested successfully with a test dll I created >> >> with Visual Studio and could execute with NetBeans. >> >> >> >> This problem is presumably related to the first error mentioned above, >> >> and would be most grateful in getting this issue resolved. As I said, >> >> I'm new to VTK, and in fact only in the last couple of weeks have >> >> tried for the first time to call a dll file from a Java application on >> >> a Windows computer. >> >> >> >> In the Java code I added the statement: >> >> >> >> System.out.println(System.getProperty("java.library.path")); >> >> >> >> to check that the path was correct, which is the case. >> >> _______________________________________________ >> >> Powered by www.kitware.com >> >> >> >> Visit other Kitware open-source projects at >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> Search the list archives at: >> >> http://markmail.org/search/?q=vtk-developers >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > > > From sebastien.jourdain at kitware.com Sat Mar 21 23:59:30 2015 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Sat, 21 Mar 2015 21:59:30 -0600 Subject: [vtk-developers] Problems installing VTK In-Reply-To: References: Message-ID: I didn't know you had a partial build of VTK. Can you share you CMakeCache.txt. You must have wrongly setup your build. Seb On Sat, Mar 21, 2015 at 6:05 PM, CSharpdotcom . wrote: > Hello, > > Many thanks, but as I'm new ti VTK I don't know which libraries to > load. However, in looking at: > > http://www.vtk.org/Wiki/VTK/Examples/Java/Miscellaneous/Cone6 > > which has similar code. The statement: > > System.loadLibrary("vtkCommonJava"); > > doesn't load as there is no dll with that name in the folder > C:\VTK\bin\Release, but: > > System.loadLibrary("vtkCommonCoreJava"); > > does load correctly as there is a dll with that name. This applies to > a few other files, but not all of them. Without the required dlls > loaded, even if no errors are produced, the code will not execute. > > If I go back to the original code when I try and load everything, then > I get the error message: > > java.lang.UnsatisfiedLinkError: > C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent > libraries > > The file vtkChartsCoreJava.dll is present in that folder, so it is > loaded, but its dependencies cannot be found. This applies to quite a > few other dll files with dependencies, and I also get a list of a > large number files that were not loaded from the statement: > > if (!lib.IsLoaded()) System.out.println(lib.GetLibraryName() + " not > loaded"); > > inside the for-loop in an earlier message. > > It looks that without these large number of files, possibly all of > them, that have not been loaded the code will not work, even if I skip > over the bad loads or put the loop in a try-catch loop. This must > have something to do with the error message in the log during the > build process with Visual Studio Pro 2010 I did a few days ago. > > I don't fully understand the log, but the section where it failed is here: > > 112>Link: > 112> Creating library C:/VTK/lib/Release/vtkRenderingCoreJava.lib > and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp > 114> vtkDepthPeeling_fs.cxx > 114> vtkGaussianBlurPassShader_fs.cxx > 114> vtkLighting_s.cxx > 114> vtkLightingHelper_s.cxx > 114> vtkOpenGLRenderer_PeelingFS.cxx > 114> vtkOpenGLPropertyDefaultPropFunc_fs.cxx > 114> vtkOpenGLPropertyDefaultPropFunc_vs.cxx > 112>vtkRenderWindowJava.obj : error LNK2019: unresolved external > symbol __imp__JAWT_GetAWT at 8 referenced in function > _Java_vtk_vtkPanel_RenderCreate at 12 > 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: > 1 unresolved externals > 114> vtkOpenGLPropertyDefaultMain_fs.cxx > 112> > 112>Build FAILED. > 112> > 112>Time Elapsed 00:01:32.30 > > Obviously vtkRenderingCoreJava.dll failed to link, which must be the > cause of the problems I'm having. This was the only failure, with the > other 387 compilations and linking successful. If this problem can be > fixed, I hope I will be home and dry. > > I would most appreciate you or someone else kindly getting this resolved. > > csharp > > On Sat, Mar 21, 2015 at 3:04 PM, Sebastien Jourdain > wrote: > > Try to load the libraries that you need to load instead of all of them. > It > > seems that you didn't build everything (which is probably fine). > > > > Seb > > > > On Sat, Mar 21, 2015 at 2:58 PM, CSharpdotcom . > > wrote: > >> > >> I already had PATH=C:\VTK\bin\Release, and added ;%PATH% at the end, > >> but it still doesn't work, and get the following output: > >> > >> java.lang.UnsatisfiedLinkError: > >> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent > >> libraries > >> at java.lang.ClassLoader$NativeLibrary.load(Native Method) > >> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) at > >> java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) > >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) > >> at java.lang.Runtime.loadLibrary0(Runtime.java:870) > >> at java.lang.System.loadLibrary(System.java:1119) > >> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) > >> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) > >> at > >> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) > >> at > >> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) > >> java.lang.UnsatisfiedLinkError: > >> C:\VTK\bin\Release\vtkDomainsChemistryJava.dll: Can't find dependent > >> libraries > >> at java.lang.ClassLoader$NativeLibrary.load(Native Method) > >> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) > >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) > >> at java.lang.Runtime.loadLibrary0(Runtime.java:870) > >> at java.lang.System.loadLibrary(System.java:1119) > >> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) > >> at > >> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) > >> at > >> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) > >> ................... > >> > >> These error messages continue, then a list of files not loaded are > >> printed out, as given in the source code. > >> > >> Based on these error messages it's picking up the dll files in the > >> \Release folder, but it's unable to find other files that these dll > >> files depend on. > >> > >> Do you want a full listing of the Java source file? The > >> AwtConeRendering class starts off with: > >> > >> static { > >> System.out.println(System.getProperty("java.library.path")); > >> if (!vtkNativeLibrary.LoadAllNativeLibraries()) { > >> for (vtkNativeLibrary lib : vtkNativeLibrary.values()) { > >> if (!lib.IsLoaded()) { > >> System.out.println(lib.GetLibraryName() + " not loaded"); > >> } > >> } > >> } > >> vtkNativeLibrary.DisableOutputWindow(null); > >> } > >> > >> which is followed by the main() method, which contains statements such > as: > >> > >> vtkConeSource cone = new vtkConeSource(); > >> > >> csharp > >> > >> On Sat, Mar 21, 2015 at 10:26 AM, Sebastien Jourdain > >> wrote: > >> > Te java.library.path is not enough and you need to add into your > >> > environment > >> > PATH the following directory, C:\VTK\bin\Release. > >> > > >> > set PATH=C:\VTK\bin\Release;%PATH% > >> > > >> > Seb > >> > > >> > On Sat, Mar 21, 2015 at 10:33 AM, CSharpdotcom . > >> > > >> > wrote: > >> >> > >> >> Hello, > >> >> > >> >> I'm new to VTK and this is my first posting here or on any other > forum > >> >> related to VTK. > >> >> > >> >> I've been trying for about a week to get VTK installed and running on > >> >> my computer. The project I'm working on is to use Java with VTK to > >> >> represent 3D graphics, which I hope to use with NetBeans 8.0.2. I > >> >> also have Visual Studio Pro 2010. > >> >> > >> >> After failed attempts in installing VTK 6.2.0 and the latest version > >> >> of CMake, from the link > >> >> > http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk > >> >> I downloaded and unzipped VTK 6.1.0 and CMake 3.0.0, then installed > >> >> them. > >> >> > >> >> I then ran CMake according to the instructions on that link and > >> >> installed the generated code in the folder C:\VTK. I then clicked on > >> >> the file VTK.sin in that folder, which opened up Visual Studio and > >> >> started compiling the code with a large number of modules in the > >> >> project. This took about an hour, and on completion, generated the > >> >> line at the end: > >> >> > >> >> Build: 387 succeeded, 1 failed, 0 up-to-date, 0 skipped > >> >> > >> >> I saved this in a file, which is very long, and after some effort > >> >> found the error message: > >> >> > >> >> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error > LNK1120: > >> >> 1 unresolved externals > >> >> > >> >> In the mean time I attempted to recompile the project, which was much > >> >> quicker, and got the same message. In recompiled I checked the > >> >> "INSTALL" option, which had not previously been checked, although I > >> >> don't know if that is significant. > >> >> > >> >> Located in the folder \VTK\java\sample\rendering is the source file > >> >> AwTConeRendering.java, which apparently has not been compiled. I > >> >> created a NetBeans project and copied that file into it, then linked > >> >> vtk.jar in the folder \VTK\bin to the project, and all imports were > >> >> satisfied. In setting the Windows path to point to the dll files in > >> >> \VTK\bin\Release, the application appears to pick up the dll files > >> >> correctly, however, I get the following error message: > >> >> > >> >> java.lang.UnsatisfiedLinkError: > >> >> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent > >> >> libraries > >> >> > >> >> repeated for many dll files. Incidentally, as Visual Studio dlls are > >> >> all 32 bits, as far as I know, I set up NetBeans to use a 32 bit JVM. > >> >> This had previously been tested successfully with a test dll I > created > >> >> with Visual Studio and could execute with NetBeans. > >> >> > >> >> This problem is presumably related to the first error mentioned > above, > >> >> and would be most grateful in getting this issue resolved. As I > said, > >> >> I'm new to VTK, and in fact only in the last couple of weeks have > >> >> tried for the first time to call a dll file from a Java application > on > >> >> a Windows computer. > >> >> > >> >> In the Java code I added the statement: > >> >> > >> >> System.out.println(System.getProperty("java.library.path")); > >> >> > >> >> to check that the path was correct, which is the case. > >> >> _______________________________________________ > >> >> Powered by www.kitware.com > >> >> > >> >> Visit other Kitware open-source projects at > >> >> http://www.kitware.com/opensource/opensource.html > >> >> > >> >> Search the list archives at: > >> >> http://markmail.org/search/?q=vtk-developers > >> >> > >> >> Follow this link to subscribe/unsubscribe: > >> >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> >> > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From csharpdotcom at gmail.com Sun Mar 22 02:11:28 2015 From: csharpdotcom at gmail.com (CSharpdotcom .) Date: Sat, 21 Mar 2015 23:11:28 -0700 Subject: [vtk-developers] Problems installing VTK In-Reply-To: References: Message-ID: OK, many thanks, I didn't know that there was such a file, this is because I'm so new to VTK and CMake. The file is in the root folder and is attached here. I look forward finally to getting this sorted out, as it has now tied me up for about a week. Christopher Sharp On Sat, Mar 21, 2015 at 8:59 PM, Sebastien Jourdain wrote: > I didn't know you had a partial build of VTK. Can you share you > CMakeCache.txt. > > You must have wrongly setup your build. > > Seb > > On Sat, Mar 21, 2015 at 6:05 PM, CSharpdotcom . > wrote: >> >> Hello, >> >> Many thanks, but as I'm new ti VTK I don't know which libraries to >> load. However, in looking at: >> >> http://www.vtk.org/Wiki/VTK/Examples/Java/Miscellaneous/Cone6 >> >> which has similar code. The statement: >> >> System.loadLibrary("vtkCommonJava"); >> >> doesn't load as there is no dll with that name in the folder >> C:\VTK\bin\Release, but: >> >> System.loadLibrary("vtkCommonCoreJava"); >> >> does load correctly as there is a dll with that name. This applies to >> a few other files, but not all of them. Without the required dlls >> loaded, even if no errors are produced, the code will not execute. >> >> If I go back to the original code when I try and load everything, then >> I get the error message: >> >> java.lang.UnsatisfiedLinkError: >> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >> libraries >> >> The file vtkChartsCoreJava.dll is present in that folder, so it is >> loaded, but its dependencies cannot be found. This applies to quite a >> few other dll files with dependencies, and I also get a list of a >> large number files that were not loaded from the statement: >> >> if (!lib.IsLoaded()) System.out.println(lib.GetLibraryName() + " not >> loaded"); >> >> inside the for-loop in an earlier message. >> >> It looks that without these large number of files, possibly all of >> them, that have not been loaded the code will not work, even if I skip >> over the bad loads or put the loop in a try-catch loop. This must >> have something to do with the error message in the log during the >> build process with Visual Studio Pro 2010 I did a few days ago. >> >> I don't fully understand the log, but the section where it failed is here: >> >> 112>Link: >> 112> Creating library C:/VTK/lib/Release/vtkRenderingCoreJava.lib >> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp >> 114> vtkDepthPeeling_fs.cxx >> 114> vtkGaussianBlurPassShader_fs.cxx >> 114> vtkLighting_s.cxx >> 114> vtkLightingHelper_s.cxx >> 114> vtkOpenGLRenderer_PeelingFS.cxx >> 114> vtkOpenGLPropertyDefaultPropFunc_fs.cxx >> 114> vtkOpenGLPropertyDefaultPropFunc_vs.cxx >> 112>vtkRenderWindowJava.obj : error LNK2019: unresolved external >> symbol __imp__JAWT_GetAWT at 8 referenced in function >> _Java_vtk_vtkPanel_RenderCreate at 12 >> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: >> 1 unresolved externals >> 114> vtkOpenGLPropertyDefaultMain_fs.cxx >> 112> >> 112>Build FAILED. >> 112> >> 112>Time Elapsed 00:01:32.30 >> >> Obviously vtkRenderingCoreJava.dll failed to link, which must be the >> cause of the problems I'm having. This was the only failure, with the >> other 387 compilations and linking successful. If this problem can be >> fixed, I hope I will be home and dry. >> >> I would most appreciate you or someone else kindly getting this resolved. >> >> csharp >> >> On Sat, Mar 21, 2015 at 3:04 PM, Sebastien Jourdain >> wrote: >> > Try to load the libraries that you need to load instead of all of them. >> > It >> > seems that you didn't build everything (which is probably fine). >> > >> > Seb >> > >> > On Sat, Mar 21, 2015 at 2:58 PM, CSharpdotcom . >> > wrote: >> >> >> >> I already had PATH=C:\VTK\bin\Release, and added ;%PATH% at the end, >> >> but it still doesn't work, and get the following output: >> >> >> >> java.lang.UnsatisfiedLinkError: >> >> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >> >> libraries >> >> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >> >> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) at >> >> java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >> >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >> >> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >> >> at java.lang.System.loadLibrary(System.java:1119) >> >> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >> >> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >> >> at >> >> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >> >> at >> >> >> >> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >> >> java.lang.UnsatisfiedLinkError: >> >> C:\VTK\bin\Release\vtkDomainsChemistryJava.dll: Can't find dependent >> >> libraries >> >> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >> >> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >> >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >> >> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >> >> at java.lang.System.loadLibrary(System.java:1119) >> >> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >> >> at >> >> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >> >> at >> >> >> >> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >> >> ................... >> >> >> >> These error messages continue, then a list of files not loaded are >> >> printed out, as given in the source code. >> >> >> >> Based on these error messages it's picking up the dll files in the >> >> \Release folder, but it's unable to find other files that these dll >> >> files depend on. >> >> >> >> Do you want a full listing of the Java source file? The >> >> AwtConeRendering class starts off with: >> >> >> >> static { >> >> System.out.println(System.getProperty("java.library.path")); >> >> if (!vtkNativeLibrary.LoadAllNativeLibraries()) { >> >> for (vtkNativeLibrary lib : vtkNativeLibrary.values()) { >> >> if (!lib.IsLoaded()) { >> >> System.out.println(lib.GetLibraryName() + " not loaded"); >> >> } >> >> } >> >> } >> >> vtkNativeLibrary.DisableOutputWindow(null); >> >> } >> >> >> >> which is followed by the main() method, which contains statements such >> >> as: >> >> >> >> vtkConeSource cone = new vtkConeSource(); >> >> >> >> csharp >> >> >> >> On Sat, Mar 21, 2015 at 10:26 AM, Sebastien Jourdain >> >> wrote: >> >> > Te java.library.path is not enough and you need to add into your >> >> > environment >> >> > PATH the following directory, C:\VTK\bin\Release. >> >> > >> >> > set PATH=C:\VTK\bin\Release;%PATH% >> >> > >> >> > Seb >> >> > >> >> > On Sat, Mar 21, 2015 at 10:33 AM, CSharpdotcom . >> >> > >> >> > wrote: >> >> >> >> >> >> Hello, >> >> >> >> >> >> I'm new to VTK and this is my first posting here or on any other >> >> >> forum >> >> >> related to VTK. >> >> >> >> >> >> I've been trying for about a week to get VTK installed and running >> >> >> on >> >> >> my computer. The project I'm working on is to use Java with VTK to >> >> >> represent 3D graphics, which I hope to use with NetBeans 8.0.2. I >> >> >> also have Visual Studio Pro 2010. >> >> >> >> >> >> After failed attempts in installing VTK 6.2.0 and the latest >> >> >> version >> >> >> of CMake, from the link >> >> >> >> >> >> http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk >> >> >> I downloaded and unzipped VTK 6.1.0 and CMake 3.0.0, then installed >> >> >> them. >> >> >> >> >> >> I then ran CMake according to the instructions on that link and >> >> >> installed the generated code in the folder C:\VTK. I then clicked >> >> >> on >> >> >> the file VTK.sin in that folder, which opened up Visual Studio and >> >> >> started compiling the code with a large number of modules in the >> >> >> project. This took about an hour, and on completion, generated the >> >> >> line at the end: >> >> >> >> >> >> Build: 387 succeeded, 1 failed, 0 up-to-date, 0 skipped >> >> >> >> >> >> I saved this in a file, which is very long, and after some effort >> >> >> found the error message: >> >> >> >> >> >> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error >> >> >> LNK1120: >> >> >> 1 unresolved externals >> >> >> >> >> >> In the mean time I attempted to recompile the project, which was >> >> >> much >> >> >> quicker, and got the same message. In recompiled I checked the >> >> >> "INSTALL" option, which had not previously been checked, although I >> >> >> don't know if that is significant. >> >> >> >> >> >> Located in the folder \VTK\java\sample\rendering is the source file >> >> >> AwTConeRendering.java, which apparently has not been compiled. I >> >> >> created a NetBeans project and copied that file into it, then linked >> >> >> vtk.jar in the folder \VTK\bin to the project, and all imports were >> >> >> satisfied. In setting the Windows path to point to the dll files in >> >> >> \VTK\bin\Release, the application appears to pick up the dll files >> >> >> correctly, however, I get the following error message: >> >> >> >> >> >> java.lang.UnsatisfiedLinkError: >> >> >> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >> >> >> libraries >> >> >> >> >> >> repeated for many dll files. Incidentally, as Visual Studio dlls >> >> >> are >> >> >> all 32 bits, as far as I know, I set up NetBeans to use a 32 bit >> >> >> JVM. >> >> >> This had previously been tested successfully with a test dll I >> >> >> created >> >> >> with Visual Studio and could execute with NetBeans. >> >> >> >> >> >> This problem is presumably related to the first error mentioned >> >> >> above, >> >> >> and would be most grateful in getting this issue resolved. As I >> >> >> said, >> >> >> I'm new to VTK, and in fact only in the last couple of weeks have >> >> >> tried for the first time to call a dll file from a Java application >> >> >> on >> >> >> a Windows computer. >> >> >> >> >> >> In the Java code I added the statement: >> >> >> >> >> >> System.out.println(System.getProperty("java.library.path")); >> >> >> >> >> >> to check that the path was correct, which is the case. >> >> >> _______________________________________________ >> >> >> Powered by www.kitware.com >> >> >> >> >> >> Visit other Kitware open-source projects at >> >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> >> >> Search the list archives at: >> >> >> http://markmail.org/search/?q=vtk-developers >> >> >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> >> > >> > >> > > > -------------- next part -------------- # This is the CMakeCache file. # For build in directory: c:/VTK # It was generated by CMake: C:/Program Files (x86)/CMake/bin/cmake.exe # You can edit this file to change values found and used by cmake. # If you do not want to change any of the values, simply exit the editor. # If you do want to change a value, simply edit, save, and exit the editor. # The syntax for the file is as follows: # KEY:TYPE=VALUE # KEY is the name of a variable in the cache. # TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!. # VALUE is the current value for the KEY. ######################## # EXTERNAL cache entries ######################## //Build the VTK documentation BUILD_DOCUMENTATION:BOOL=OFF //Build VTK examples. BUILD_EXAMPLES:BOOL=OFF //Build Shared Libraries BUILD_SHARED_LIBS:BOOL=ON //Build the testing tree. BUILD_TESTING:BOOL=OFF //Semicolon separated list of supported configuration types, only // supports Debug, Release, MinSizeRel, and RelWithDebInfo, anything // else will be ignored. CMAKE_CONFIGURATION_TYPES:STRING=Debug;Release;MinSizeRel;RelWithDebInfo //Flags used by the compiler during all build types. CMAKE_CXX_FLAGS:STRING= /DWIN32 /D_WINDOWS /W3 /GR /EHsc //Flags used by the compiler during debug builds. CMAKE_CXX_FLAGS_DEBUG:STRING=/D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 //Flags used by the compiler during release builds for minimum // size. CMAKE_CXX_FLAGS_MINSIZEREL:STRING=/MD /O1 /Ob1 /D NDEBUG //Flags used by the compiler during release builds. CMAKE_CXX_FLAGS_RELEASE:STRING=/MD /O2 /Ob2 /D NDEBUG //Flags used by the compiler during release builds with debug info. CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=/MD /Zi /O2 /Ob1 /D NDEBUG //Build with /MP flag enabled CMAKE_CXX_MP_FLAG:BOOL=OFF //The maximum number of processes for the /MP flag CMAKE_CXX_MP_NUM_PROCESSORS:STRING= //Libraries linked by default with all C++ applications. CMAKE_CXX_STANDARD_LIBRARIES:STRING=kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib //Flags used by the compiler during all build types. CMAKE_C_FLAGS:STRING= /DWIN32 /D_WINDOWS /W3 //Flags used by the compiler during debug builds. CMAKE_C_FLAGS_DEBUG:STRING=/D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 //Flags used by the compiler during release builds for minimum // size. CMAKE_C_FLAGS_MINSIZEREL:STRING=/MD /O1 /Ob1 /D NDEBUG //Flags used by the compiler during release builds. CMAKE_C_FLAGS_RELEASE:STRING=/MD /O2 /Ob2 /D NDEBUG //Flags used by the compiler during release builds with debug info. CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=/MD /Zi /O2 /Ob1 /D NDEBUG //Libraries linked by default with all C applications. CMAKE_C_STANDARD_LIBRARIES:STRING=kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib //Flags used by the linker. CMAKE_EXE_LINKER_FLAGS:STRING=' /machine:X86 ' //Flags used by the linker during debug builds. CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING=/debug /INCREMENTAL //Flags used by the linker during release minsize builds. CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING=/INCREMENTAL:NO //Flags used by the linker during release builds. CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING=/INCREMENTAL:NO //Flags used by the linker during Release with Debug Info builds. CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING=/debug /INCREMENTAL //Install path prefix, prepended onto install directories. CMAKE_INSTALL_PREFIX:PATH=C:/Program Files (x86)/VTK //Path to a program. CMAKE_LINKER:FILEPATH=c:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/link.exe //Flags used by the linker during the creation of modules. CMAKE_MODULE_LINKER_FLAGS:STRING=' /machine:X86 ' //Flags used by the linker during debug builds. CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING=/debug /INCREMENTAL //Flags used by the linker during release minsize builds. CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING=/INCREMENTAL:NO //Flags used by the linker during release builds. CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING=/INCREMENTAL:NO //Flags used by the linker during Release with Debug Info builds. CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING=/debug /INCREMENTAL //Value Computed by CMake CMAKE_PROJECT_NAME:STATIC=VTK //RC compiler CMAKE_RC_COMPILER:FILEPATH=rc //Flags for Windows Resource Compiler. CMAKE_RC_FLAGS:STRING=' ' //Flags used by the linker during the creation of dll's. CMAKE_SHARED_LINKER_FLAGS:STRING=' /machine:X86 ' //Flags used by the linker during debug builds. CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING=/debug /INCREMENTAL //Flags used by the linker during release minsize builds. CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL:STRING=/INCREMENTAL:NO //Flags used by the linker during release builds. CMAKE_SHARED_LINKER_FLAGS_RELEASE:STRING=/INCREMENTAL:NO //Flags used by the linker during Release with Debug Info builds. CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING=/debug /INCREMENTAL //If set, runtime paths are not added when installing shared libraries, // but are added when building. CMAKE_SKIP_INSTALL_RPATH:BOOL=OFF //If set, runtime paths are not added when using shared libraries. CMAKE_SKIP_RPATH:BOOL=OFF //Flags used by the linker during the creation of static libraries. CMAKE_STATIC_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_STATIC_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_STATIC_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Thread library used. CMAKE_THREAD_LIBS:STRING= //If true, cmake will use relative paths in makefiles and projects. CMAKE_USE_RELATIVE_PATHS:BOOL=OFF //If this value is on, makefiles will be generated without the // .SILENT directive, and all commands will be echoed to the console // during the make. This is useful for debugging only. With Visual // Studio IDE projects all commands are done without /nologo. CMAKE_VERBOSE_MAKEFILE:BOOL=OFF //Value Computed by CMake DICOMParser_BINARY_DIR:STATIC=C:/VTK/Utilities/DICOMParser //Value Computed by CMake DICOMParser_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/Utilities/DICOMParser //Path to a file. DirectX_INCLUDE_DIR:PATH=DirectX_INCLUDE_DIR-NOTFOUND //Path to a library. DirectX_LIBRARY:FILEPATH=DirectX_LIBRARY-NOTFOUND //Disable compiler warnings EXODUSII_DISABLE_COMPILER_WARNINGS:BOOL=ON //Additional URL templates for the ExternalData CMake script to // look for testing data. E.g. //\nfile:///var/bigharddrive/%(algo)/%(hash) ExternalData_URL_TEMPLATES:STRING= //Value Computed by CMake HDF5_BINARY_DIR:STATIC=C:/VTK/ThirdParty/hdf5/vtkhdf5 //Value Computed by CMake HDF5_HL_BINARY_DIR:STATIC=C:/VTK/ThirdParty/hdf5/vtkhdf5/hl //Value Computed by CMake HDF5_HL_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/hdf5/vtkhdf5/hl //Value Computed by CMake HDF5_HL_SRC_BINARY_DIR:STATIC=C:/VTK/ThirdParty/hdf5/vtkhdf5/hl/src //Value Computed by CMake HDF5_HL_SRC_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/hdf5/vtkhdf5/hl/src //Value Computed by CMake HDF5_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/hdf5/vtkhdf5 //Value Computed by CMake HDF5_SRC_BINARY_DIR:STATIC=C:/VTK/ThirdParty/hdf5/vtkhdf5/src //Value Computed by CMake HDF5_SRC_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/hdf5/vtkhdf5/src //Path to a file. JAVA_AWT_INCLUDE_PATH:PATH=C:/Program Files/Java/jdk1.8.0_31/include //Path to a library. JAVA_AWT_LIBRARY:FILEPATH=C:/Program Files/Java/jdk1.8.0_31/lib/jawt.lib //Path to a file. JAVA_INCLUDE_PATH:PATH=C:/Program Files/Java/jdk1.8.0_31/include //Path to a file. JAVA_INCLUDE_PATH2:PATH=C:/Program Files/Java/jdk1.8.0_31/include/win32 //Path to a library. JAVA_JVM_LIBRARY:FILEPATH=C:/Program Files/Java/jdk1.8.0_31/lib/jvm.lib //Path to a program. Java_JAR_EXECUTABLE:FILEPATH=C:/Program Files/Java/jdk1.8.0_31/bin/jar.exe //Path to a program. Java_JAVAC_EXECUTABLE:FILEPATH=C:/Program Files/Java/jdk1.8.0_31/bin/javac.exe //Path to a program. Java_JAVADOC_EXECUTABLE:FILEPATH=C:/Program Files/Java/jdk1.8.0_31/bin/javadoc.exe //Path to a program. Java_JAVAH_EXECUTABLE:FILEPATH=C:/Program Files/Java/jdk1.8.0_31/bin/javah.exe //Path to a program. Java_JAVA_EXECUTABLE:FILEPATH=C:/Program Files/Java/jdk1.8.0_31/bin/java.exe //Value Computed by CMake JsonCpp_BINARY_DIR:STATIC=C:/VTK/ThirdParty/jsoncpp/vtkjsoncpp //Value Computed by CMake JsonCpp_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/jsoncpp/vtkjsoncpp //Request building AutobahnPython Module_AutobahnPython:BOOL=OFF //Request building Twisted Module_Twisted:BOOL=OFF //Request building ZopeInterface Module_ZopeInterface:BOOL=OFF //Request building vtkAcceleratorsDax Module_vtkAcceleratorsDax:BOOL=OFF //Request building vtkAcceleratorsPiston Module_vtkAcceleratorsPiston:BOOL=OFF //Request building vtkFiltersParallelFlowPaths Module_vtkFiltersParallelFlowPaths:BOOL=OFF //Request building vtkFiltersParallelGeometry Module_vtkFiltersParallelGeometry:BOOL=OFF //Request building vtkFiltersParallelMPI Module_vtkFiltersParallelMPI:BOOL=OFF //Request building vtkFiltersParallelStatistics Module_vtkFiltersParallelStatistics:BOOL=OFF //Request building vtkFiltersReebGraph Module_vtkFiltersReebGraph:BOOL=OFF //Request building vtkFiltersStatisticsGnuR Module_vtkFiltersStatisticsGnuR:BOOL=OFF //Request building vtkGUISupportMFC Module_vtkGUISupportMFC:BOOL=OFF //Request building vtkGUISupportQt Module_vtkGUISupportQt:BOOL=OFF //Request building vtkGUISupportQtOpenGL Module_vtkGUISupportQtOpenGL:BOOL=OFF //Request building vtkGUISupportQtSQL Module_vtkGUISupportQtSQL:BOOL=OFF //Request building vtkGUISupportQtWebkit Module_vtkGUISupportQtWebkit:BOOL=OFF //Request building vtkIOFFMPEG Module_vtkIOFFMPEG:BOOL=OFF //Request building vtkIOGDAL Module_vtkIOGDAL:BOOL=OFF //Request building vtkIOGeoJSON Module_vtkIOGeoJSON:BOOL=OFF //Request building vtkIOMPIImage Module_vtkIOMPIImage:BOOL=OFF //Request building vtkIOMPIParallel Module_vtkIOMPIParallel:BOOL=OFF //Request building vtkIOMySQL Module_vtkIOMySQL:BOOL=OFF //Request building vtkIOODBC Module_vtkIOODBC:BOOL=OFF //Request building vtkIOParallelExodus Module_vtkIOParallelExodus:BOOL=OFF //Request building vtkIOParallelLSDyna Module_vtkIOParallelLSDyna:BOOL=OFF //Request building vtkIOParallelNetCDF Module_vtkIOParallelNetCDF:BOOL=OFF //Request building vtkIOPostgreSQL Module_vtkIOPostgreSQL:BOOL=OFF //Request building vtkIOVPIC Module_vtkIOVPIC:BOOL=OFF //Request building vtkIOXdmf2 Module_vtkIOXdmf2:BOOL=OFF //Request building vtkInfovisBoost Module_vtkInfovisBoost:BOOL=OFF //Request building vtkInfovisBoostGraphAlgorithms Module_vtkInfovisBoostGraphAlgorithms:BOOL=OFF //Request building vtkInfovisParallel Module_vtkInfovisParallel:BOOL=OFF //Request building vtkParallelMPI Module_vtkParallelMPI:BOOL=OFF //Request building vtkPython Module_vtkPython:BOOL=OFF //Request building vtkPythonInterpreter Module_vtkPythonInterpreter:BOOL=OFF //Request building vtkRenderingFreeTypeFontConfig Module_vtkRenderingFreeTypeFontConfig:BOOL=OFF //Request building vtkRenderingMatplotlib Module_vtkRenderingMatplotlib:BOOL=OFF //Request building vtkRenderingParallel Module_vtkRenderingParallel:BOOL=OFF //Request building vtkRenderingParallelLIC Module_vtkRenderingParallelLIC:BOOL=OFF //Request building vtkRenderingQt Module_vtkRenderingQt:BOOL=OFF //Request building vtkRenderingTk Module_vtkRenderingTk:BOOL=OFF //Request building vtkTclTk Module_vtkTclTk:BOOL=OFF //Request building vtkTestingCore Module_vtkTestingCore:BOOL=OFF //Request building vtkTestingGenericBridge Module_vtkTestingGenericBridge:BOOL=OFF //Request building vtkTestingIOSQL Module_vtkTestingIOSQL:BOOL=OFF //Request building vtkTestingRendering Module_vtkTestingRendering:BOOL=OFF //Request building vtkVPIC Module_vtkVPIC:BOOL=OFF //Request building vtkViewsQt Module_vtkViewsQt:BOOL=OFF //Request building vtkWebApplications Module_vtkWebApplications:BOOL=OFF //Request building vtkWebCore Module_vtkWebCore:BOOL=OFF //Request building vtkWebGLExporter Module_vtkWebGLExporter:BOOL=OFF //Request building vtkWebInstall Module_vtkWebInstall:BOOL=OFF //Request building vtkWebJavaScript Module_vtkWebJavaScript:BOOL=OFF //Request building vtkWebPython Module_vtkWebPython:BOOL=OFF //Request building vtkWrappingJava Module_vtkWrappingJava:BOOL=ON //Request building vtkWrappingPythonCore Module_vtkWrappingPythonCore:BOOL=OFF //Request building vtkWrappingTcl Module_vtkWrappingTcl:BOOL=OFF //Request building vtkmrmpi Module_vtkmrmpi:BOOL=OFF //Request building vtkxdmf2 Module_vtkxdmf2:BOOL=OFF //Specify default maximum number of elements in the file chunk // cache chunk for HDF5 files (should be prime number). NETCDF4_CHUNK_CACHE_NELEMS:STRING=1009 //Specify default file chunk cache preemption policy for HDF5 files // (a number between 0 and 1, inclusive). NETCDF4_CHUNK_CACHE_PREEMPTION:STRING=0.75 //Specify default file cache chunk size for HDF5 files in bytes. NETCDF4_CHUNK_CACHE_SIZE:STRING=4194304 //Specify the number of chunks to store in default per-variable // cache. NETCDF4_DEFAULT_CHUNKS_IN_CACHE:STRING=10 //Specify default size of chunks in bytes. NETCDF4_DEFAULT_CHUNK_SIZE:STRING=4194304 //Specify maximum size (in bytes) for the default per-var chunk // cache. NETCDF4_MAX_DEFAULT_CACHE_SIZE:STRING=67108864 //Disable compiler warnings NETCDF_DISABLE_COMPILER_WARNINGS:BOOL=ON //Build netcdf C++ API NETCDF_ENABLE_CXX:BOOL=ON //OpenGL library for win32 OPENGL_gl_LIBRARY:STRING=opengl32 //GLU library for win32 OPENGL_glu_LIBRARY:STRING=glu32 //Does an external project define proj_list or should libproj4 // define it? PROJ_LIST_EXTERNAL:BOOL=OFF //Should libproj4 include projection code that relies on GSL? PROJ_USE_GSL:BOOL=OFF //Should libproj4 be built as a thread-friendly library? PROJ_USE_PTHREADS:BOOL=OFF //Value Computed by CMake VTKEXPAT_BINARY_DIR:STATIC=C:/VTK/ThirdParty/expat/vtkexpat //Value Computed by CMake VTKEXPAT_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/expat/vtkexpat //Value Computed by CMake VTKFREETYPE_BINARY_DIR:STATIC=C:/VTK/ThirdParty/freetype/vtkfreetype //Value Computed by CMake VTKFREETYPE_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/freetype/vtkfreetype //Value Computed by CMake VTKFTGL_BINARY_DIR:STATIC=C:/VTK/ThirdParty/ftgl //Value Computed by CMake VTKFTGL_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/ftgl //Value Computed by CMake VTKGL2PS_BINARY_DIR:STATIC=C:/VTK/ThirdParty/gl2ps/vtkgl2ps //Value Computed by CMake VTKGL2PS_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/gl2ps/vtkgl2ps //Value Computed by CMake VTKJPEG_BINARY_DIR:STATIC=C:/VTK/ThirdParty/jpeg/vtkjpeg //Value Computed by CMake VTKJPEG_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/jpeg/vtkjpeg //Value Computed by CMake VTKNETCDF_BINARY_DIR:STATIC=C:/VTK/ThirdParty/netcdf/vtknetcdf //Value Computed by CMake VTKNETCDF_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf //Value Computed by CMake VTKOGGTHEORA_BINARY_DIR:STATIC=C:/VTK/ThirdParty/oggtheora/vtkoggtheora //Disable assemby optimizations VTKOGGTHEORA_DISABLE_ASM:BOOL=OFF //Disable the use of floating point code in theora VTKOGGTHEORA_DISABLE_FLOAT:BOOL=OFF //Additional linker flags for vtkoggtheora when building as a shared // library VTKOGGTHEORA_SHARED_LINKER_FLAGS:STRING= //Value Computed by CMake VTKOGGTHEORA_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/oggtheora/vtkoggtheora //Value Computed by CMake VTKPNG_BINARY_DIR:STATIC=C:/VTK/ThirdParty/png/vtkpng //Value Computed by CMake VTKPNG_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/png/vtkpng //Value Computed by CMake VTKSQLite_BINARY_DIR:STATIC=C:/VTK/ThirdParty/sqlite/vtksqlite //Value Computed by CMake VTKSQLite_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/sqlite/vtksqlite //Value Computed by CMake VTKTIFF_BINARY_DIR:STATIC=C:/VTK/ThirdParty/tiff/vtktiff //Value Computed by CMake VTKTIFF_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/tiff/vtktiff //Value Computed by CMake VTKZLIB_BINARY_DIR:STATIC=C:/VTK/ThirdParty/zlib/vtkzlib //Value Computed by CMake VTKZLIB_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/zlib/vtkzlib //Build all vtkObject derived classes with object factory new methods. VTK_ALL_NEW_OBJECT_FACTORY:BOOL=OFF //Value Computed by CMake VTK_BINARY_DIR:STATIC=C:/VTK //Request to build all modules VTK_BUILD_ALL_MODULES:BOOL=OFF //Directory where python modules will be put inside the build tree VTK_BUILD_PYTHON_MODULE_DIR:PATH=-NOTFOUND //Local directory holding ExternalData objects in the layout %(algo)/%(hash). VTK_DATA_STORE:PATH= //Build leak checking support into VTK. VTK_DEBUG_LEAKS:BOOL=OFF //Location of the OpenGL extensions header file (glext.h). VTK_GLEXT_FILE:FILEPATH=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/Utilities/ParseOGLExt/headers/glext.h //Location of the GLX extensions header file (glxext.h). VTK_GLXEXT_FILE:FILEPATH=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/Utilities/ParseOGLExt/headers/glxext.h //Request building Imaging modules VTK_Group_Imaging:BOOL=OFF //Request building MPI modules VTK_Group_MPI:BOOL=OFF //Request building Qt modules VTK_Group_Qt:BOOL=OFF //Request building Rendering modules VTK_Group_Rendering:BOOL=ON //Request building of all stand alone modules (no external dependencies // required) VTK_Group_StandAlone:BOOL=ON //Request building Tk modules VTK_Group_Tk:BOOL=OFF //Request building Views modules VTK_Group_Views:BOOL=OFF //Request building Web modules VTK_Group_Web:BOOL=OFF //Enable buggy OpenGL drivers for testing. VTK_IGNORE_GLDRIVER_BUGS:BOOL=OFF //Directory where python modules will be installed VTK_INSTALL_PYTHON_MODULE_DIR:PATH=-NOTFOUND //Use the Java rules to build the native libraries. VTK_JAVA_INSTALL:BOOL=OFF //Need JOGL jar files VTK_JAVA_JOGL_COMPONENT:BOOL=OFF //Should SWT component for Java be built (it requires Eclipse)? VTK_JAVA_SWT_COMPONENT:BOOL=OFF //Remove all legacy code completely. VTK_LEGACY_REMOVE:BOOL=OFF //Silence all legacy code messages. VTK_LEGACY_SILENT:BOOL=OFF //Should all modules build instantiators VTK_MAKE_INSTANTIATORS:BOOL=OFF //Max number of threads vktMultiThreader will allocate. VTK_MAX_THREADS:STRING=64 //The OpenGL library being used supports off screen Mesa calls VTK_OPENGL_HAS_OSMESA:BOOL=OFF //Enable OpenGL error check and report VTK_REPORT_OPENGL_ERRORS:BOOL=ON //Which multi-threaded parallelism implementation to use. Options // are Sequential, Simple, Kaapi or TBB VTK_SMP_IMPLEMENTATION_TYPE:STRING=Sequential //Value Computed by CMake VTK_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0 //Build VTK with 64 bit ids VTK_USE_64BIT_IDS:BOOL=OFF //Enable tests requiring "large" data VTK_USE_LARGE_DATA:BOOL=OFF //Use off screen calls by default VTK_USE_OFFSCREEN:BOOL=OFF //Use system-installed EXPAT VTK_USE_SYSTEM_EXPAT:BOOL=OFF //Use system-installed Freetype VTK_USE_SYSTEM_FREETYPE:BOOL=OFF //Use system-installed GL2PS VTK_USE_SYSTEM_GL2PS:BOOL=OFF //Use system-installed HDF5 VTK_USE_SYSTEM_HDF5:BOOL=OFF //Use system-installed JPEG VTK_USE_SYSTEM_JPEG:BOOL=OFF //Use system-installed JsonCpp VTK_USE_SYSTEM_JSONCPP:BOOL=OFF //Use system-installed LIBPROJ4 VTK_USE_SYSTEM_LIBPROJ4:BOOL=OFF //Use system-installed LibXml2 VTK_USE_SYSTEM_LIBXML2:BOOL=OFF //Use system-installed NetCDF VTK_USE_SYSTEM_NETCDF:BOOL=OFF //Use system-installed OGGTHEORA VTK_USE_SYSTEM_OGGTHEORA:BOOL=OFF //Use system-installed PNG VTK_USE_SYSTEM_PNG:BOOL=OFF //Use system-installed TIFF VTK_USE_SYSTEM_TIFF:BOOL=OFF //Use system-installed ZLIB VTK_USE_SYSTEM_ZLIB:BOOL=OFF //Use TDx interaction devices VTK_USE_TDX:BOOL=OFF //Enable using Video for Windows (vfw32) for video input and output. VTK_USE_VIDEO_FOR_WINDOWS:BOOL=ON //Use X for VTK render windows VTK_USE_X:BOOL=OFF //Location of the WGL extensions header file (wglext.h). VTK_WGLEXT_FILE:FILEPATH=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/Utilities/ParseOGLExt/headers/wglext.h //Path to a file. VTK_WRAP_HINTS:FILEPATH=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/Wrapping/Tools/hints //Should VTK Java wrapping be built? VTK_WRAP_JAVA:BOOL=ON //Should VTK Python wrapping be built? VTK_WRAP_PYTHON:BOOL=OFF //Should VTK Tcl wrapping be built? VTK_WRAP_TCL:BOOL=OFF //Value Computed by CMake alglib_BINARY_DIR:STATIC=C:/VTK/ThirdParty/alglib //Value Computed by CMake alglib_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/alglib //Value Computed by CMake libproj4_BINARY_DIR:STATIC=C:/VTK/ThirdParty/libproj4/vtklibproj4 //Value Computed by CMake libproj4_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/libproj4/vtklibproj4 //Value Computed by CMake netcdf_cxx_BINARY_DIR:STATIC=C:/VTK/ThirdParty/netcdf/vtknetcdf/cxx //Value Computed by CMake netcdf_cxx_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/cxx //Value Computed by CMake netcdf_libdispatch_BINARY_DIR:STATIC=C:/VTK/ThirdParty/netcdf/vtknetcdf/libdispatch //Value Computed by CMake netcdf_libdispatch_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch //Value Computed by CMake netcdf_liblib_BINARY_DIR:STATIC=C:/VTK/ThirdParty/netcdf/vtknetcdf/liblib //Value Computed by CMake netcdf_liblib_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/liblib //Value Computed by CMake netcdf_libsrc4_BINARY_DIR:STATIC=C:/VTK/ThirdParty/netcdf/vtknetcdf/libsrc4 //Value Computed by CMake netcdf_libsrc4_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4 //Value Computed by CMake netcdf_libsrc_BINARY_DIR:STATIC=C:/VTK/ThirdParty/netcdf/vtknetcdf/libsrc //Value Computed by CMake netcdf_libsrc_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc //Value Computed by CMake verdict_BINARY_DIR:STATIC=C:/VTK/ThirdParty/verdict/vtkverdict //Dependencies for target verdict_LIB_DEPENDS:STATIC= //Value Computed by CMake verdict_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/verdict/vtkverdict //Dependencies for the target vtkChartsCoreJava_LIB_DEPENDS:STATIC=general;vtkChartsCore;general;vtkWrappingJava;general;vtkRenderingContext2DJava; //Dependencies for the target vtkChartsCore_LIB_DEPENDS:STATIC=general;vtkRenderingContext2D;general;vtkCommonColor;general;vtkInfovisCore; //Dependencies for the target vtkCommonColorJava_LIB_DEPENDS:STATIC=general;vtkCommonColor;general;vtkWrappingJava;general;vtkCommonDataModelJava; //Dependencies for the target vtkCommonColor_LIB_DEPENDS:STATIC=general;vtkCommonDataModel; //Dependencies for the target vtkCommonComputationalGeometryJava_LIB_DEPENDS:STATIC=general;vtkCommonComputationalGeometry;general;vtkWrappingJava;general;vtkCommonDataModelJava;general;vtkCommonMathJava;general;vtkCommonSystemJava; //Dependencies for the target vtkCommonComputationalGeometry_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonMath;general;vtkCommonSystem; //Dependencies for the target vtkCommonCoreJava_LIB_DEPENDS:STATIC=general;vtkCommonCore;general;vtkWrappingJava; //Dependencies for the target vtkCommonCore_LIB_DEPENDS:STATIC=general;vtksys; //Dependencies for the target vtkCommonDataModelJava_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkWrappingJava;general;vtkCommonMathJava;general;vtkCommonMiscJava;general;vtkCommonSystemJava;general;vtkCommonTransformsJava; //Dependencies for the target vtkCommonDataModel_LIB_DEPENDS:STATIC=general;vtkCommonMath;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkCommonTransforms;general;vtksys; //Dependencies for the target vtkCommonExecutionModelJava_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkWrappingJava;general;vtkCommonDataModelJava; //Dependencies for the target vtkCommonExecutionModel_LIB_DEPENDS:STATIC=general;vtkCommonDataModel; //Dependencies for the target vtkCommonMathJava_LIB_DEPENDS:STATIC=general;vtkCommonMath;general;vtkWrappingJava;general;vtkCommonCoreJava; //Dependencies for the target vtkCommonMath_LIB_DEPENDS:STATIC=general;vtkCommonCore; //Dependencies for the target vtkCommonMiscJava_LIB_DEPENDS:STATIC=general;vtkCommonMisc;general;vtkWrappingJava;general;vtkCommonMathJava; //Dependencies for the target vtkCommonMisc_LIB_DEPENDS:STATIC=general;vtkCommonMath; //Dependencies for the target vtkCommonSystemJava_LIB_DEPENDS:STATIC=general;vtkCommonSystem;general;vtkWrappingJava;general;vtkCommonCoreJava; //Dependencies for the target vtkCommonSystem_LIB_DEPENDS:STATIC=general;vtkCommonCore;general;vtksys; //Dependencies for the target vtkCommonTransformsJava_LIB_DEPENDS:STATIC=general;vtkCommonTransforms;general;vtkWrappingJava;general;vtkCommonCoreJava;general;vtkCommonMathJava; //Dependencies for the target vtkCommonTransforms_LIB_DEPENDS:STATIC=general;vtkCommonCore;general;vtkCommonMath; //Dependencies for target vtkDICOMParser_LIB_DEPENDS:STATIC= //Dependencies for the target vtkDomainsChemistryJava_LIB_DEPENDS:STATIC=general;vtkDomainsChemistry;general;vtkWrappingJava;general;vtkCommonDataModelJava;general;vtkRenderingCoreJava; //Dependencies for the target vtkDomainsChemistry_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkRenderingCore;general;vtkIOXML;general;vtkFiltersSources; //Value Computed by CMake vtkExodus2_BINARY_DIR:STATIC=C:/VTK/ThirdParty/exodusII/vtkexodusII //Value Computed by CMake vtkExodus2_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/exodusII/vtkexodusII //Dependencies for the target vtkFiltersAMRJava_LIB_DEPENDS:STATIC=general;vtkFiltersAMR;general;vtkWrappingJava;general;vtkFiltersGeneralJava;general;vtkParallelCoreJava; //Dependencies for the target vtkFiltersAMR_LIB_DEPENDS:STATIC=general;vtkFiltersGeneral;general;vtkParallelCore; //Dependencies for the target vtkFiltersCoreJava_LIB_DEPENDS:STATIC=general;vtkFiltersCore;general;vtkWrappingJava;general;vtkCommonExecutionModelJava;general;vtkCommonMathJava;general;vtkCommonMiscJava;general;vtkCommonSystemJava;general;vtkCommonTransformsJava; //Dependencies for the target vtkFiltersCore_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkCommonMath;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkCommonTransforms; //Dependencies for the target vtkFiltersExtractionJava_LIB_DEPENDS:STATIC=general;vtkFiltersExtraction;general;vtkWrappingJava;general;vtkCommonExecutionModelJava;general;vtkFiltersCoreJava;general;vtkFiltersGeneralJava;general;vtkFiltersStatisticsJava; //Dependencies for the target vtkFiltersExtraction_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkFiltersCore;general;vtkFiltersGeneral;general;vtkFiltersStatistics; //Dependencies for the target vtkFiltersFlowPathsJava_LIB_DEPENDS:STATIC=general;vtkFiltersFlowPaths;general;vtkWrappingJava;general;vtkCommonExecutionModelJava;general;vtkFiltersGeneralJava;general;vtkFiltersSourcesJava;general;vtkIOCoreJava; //Dependencies for the target vtkFiltersFlowPaths_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkFiltersGeneral;general;vtkFiltersSources;general;vtkIOCore; //Dependencies for the target vtkFiltersGeneralJava_LIB_DEPENDS:STATIC=general;vtkFiltersGeneral;general;vtkWrappingJava;general;vtkCommonComputationalGeometryJava;general;vtkFiltersCoreJava; //Dependencies for the target vtkFiltersGeneral_LIB_DEPENDS:STATIC=general;vtkCommonComputationalGeometry;general;vtkFiltersCore; //Dependencies for the target vtkFiltersGenericJava_LIB_DEPENDS:STATIC=general;vtkFiltersGeneric;general;vtkWrappingJava;general;vtkFiltersCoreJava;general;vtkFiltersSourcesJava; //Dependencies for the target vtkFiltersGeneric_LIB_DEPENDS:STATIC=general;vtkFiltersCore;general;vtkFiltersSources; //Dependencies for the target vtkFiltersGeometryJava_LIB_DEPENDS:STATIC=general;vtkFiltersGeometry;general;vtkWrappingJava;general;vtkFiltersCoreJava; //Dependencies for the target vtkFiltersGeometry_LIB_DEPENDS:STATIC=general;vtkFiltersCore; //Dependencies for the target vtkFiltersHybridJava_LIB_DEPENDS:STATIC=general;vtkFiltersHybrid;general;vtkWrappingJava;general;vtkFiltersGeneralJava;general;vtkImagingSourcesJava;general;vtkRenderingCoreJava; //Dependencies for the target vtkFiltersHybrid_LIB_DEPENDS:STATIC=general;vtkFiltersGeneral;general;vtkImagingSources;general;vtkRenderingCore; //Dependencies for the target vtkFiltersHyperTreeJava_LIB_DEPENDS:STATIC=general;vtkFiltersHyperTree;general;vtkWrappingJava;general;vtkFiltersGeneralJava; //Dependencies for the target vtkFiltersHyperTree_LIB_DEPENDS:STATIC=general;vtkFiltersGeneral; //Dependencies for the target vtkFiltersImagingJava_LIB_DEPENDS:STATIC=general;vtkFiltersImaging;general;vtkWrappingJava;general;vtkFiltersStatisticsJava;general;vtkImagingGeneralJava;general;vtkImagingSourcesJava; //Dependencies for the target vtkFiltersImaging_LIB_DEPENDS:STATIC=general;vtkFiltersStatistics;general;vtkImagingGeneral;general;vtkImagingSources; //Dependencies for the target vtkFiltersModelingJava_LIB_DEPENDS:STATIC=general;vtkFiltersModeling;general;vtkWrappingJava;general;vtkFiltersGeneralJava;general;vtkFiltersSourcesJava; //Dependencies for the target vtkFiltersModeling_LIB_DEPENDS:STATIC=general;vtkFiltersGeneral;general;vtkFiltersSources; //Dependencies for the target vtkFiltersParallelImagingJava_LIB_DEPENDS:STATIC=general;vtkFiltersParallelImaging;general;vtkWrappingJava;general;vtkFiltersImagingJava;general;vtkFiltersParallelJava;general;vtkIOLegacyJava;general;vtkImagingCoreJava;general;vtkParallelCoreJava; //Dependencies for the target vtkFiltersParallelImaging_LIB_DEPENDS:STATIC=general;vtkFiltersImaging;general;vtkFiltersParallel;general;vtkIOLegacy;general;vtkImagingCore;general;vtkParallelCore; //Dependencies for the target vtkFiltersParallelJava_LIB_DEPENDS:STATIC=general;vtkFiltersParallel;general;vtkWrappingJava;general;vtkFiltersExtractionJava;general;vtkFiltersGeometryJava;general;vtkFiltersModelingJava;general;vtkParallelCoreJava;general;vtkRenderingCoreJava; //Dependencies for the target vtkFiltersParallel_LIB_DEPENDS:STATIC=general;vtkFiltersExtraction;general;vtkFiltersGeometry;general;vtkFiltersModeling;general;vtkParallelCore;general;vtkRenderingCore; //Dependencies for the target vtkFiltersProgrammableJava_LIB_DEPENDS:STATIC=general;vtkFiltersProgrammable;general;vtkWrappingJava;general;vtkCommonExecutionModelJava; //Dependencies for the target vtkFiltersProgrammable_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel; //Dependencies for the target vtkFiltersSMPJava_LIB_DEPENDS:STATIC=general;vtkFiltersSMP;general;vtkWrappingJava;general;vtkFiltersCoreJava;general;vtkFiltersGeneralJava; //Dependencies for the target vtkFiltersSMP_LIB_DEPENDS:STATIC=general;vtkFiltersCore;general;vtkFiltersGeneral; //Dependencies for the target vtkFiltersSelectionJava_LIB_DEPENDS:STATIC=general;vtkFiltersSelection;general;vtkWrappingJava;general;vtkCommonComputationalGeometryJava;general;vtkFiltersCoreJava; //Dependencies for the target vtkFiltersSelection_LIB_DEPENDS:STATIC=general;vtkCommonComputationalGeometry;general;vtkFiltersCore; //Dependencies for the target vtkFiltersSourcesJava_LIB_DEPENDS:STATIC=general;vtkFiltersSources;general;vtkWrappingJava;general;vtkCommonComputationalGeometryJava;general;vtkFiltersGeneralJava; //Dependencies for the target vtkFiltersSources_LIB_DEPENDS:STATIC=general;vtkCommonComputationalGeometry;general;vtkFiltersGeneral; //Dependencies for the target vtkFiltersStatisticsJava_LIB_DEPENDS:STATIC=general;vtkFiltersStatistics;general;vtkWrappingJava;general;vtkCommonExecutionModelJava;general;vtkCommonMathJava;general;vtkCommonMiscJava;general;vtkCommonTransformsJava;general;vtkImagingFourierJava; //Dependencies for the target vtkFiltersStatistics_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkCommonMath;general;vtkCommonMisc;general;vtkCommonTransforms;general;vtkImagingFourier;general;vtkalglib; //Dependencies for the target vtkFiltersTextureJava_LIB_DEPENDS:STATIC=general;vtkFiltersTexture;general;vtkWrappingJava;general;vtkFiltersGeneralJava; //Dependencies for the target vtkFiltersTexture_LIB_DEPENDS:STATIC=general;vtkFiltersGeneral; //Dependencies for the target vtkFiltersVerdictJava_LIB_DEPENDS:STATIC=general;vtkFiltersVerdict;general;vtkWrappingJava;general;vtkCommonExecutionModelJava; //Dependencies for the target vtkFiltersVerdict_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;verdict; //Dependencies for the target vtkGeovisCoreJava_LIB_DEPENDS:STATIC=general;vtkGeovisCore;general;vtkWrappingJava;general;vtkIOXMLJava;general;vtkInfovisLayoutJava;general;vtkInteractionStyleJava;general;vtkInteractionWidgetsJava;general;vtkRenderingOpenGLJava;general;vtkViewsCoreJava; //Dependencies for the target vtkGeovisCore_LIB_DEPENDS:STATIC=general;vtkIOXML;general;vtkInfovisLayout;general;vtkInteractionStyle;general;vtkInteractionWidgets;general;vtkRenderingOpenGL;general;vtkViewsCore;general;vtkproj4; //Dependencies for the target vtkIOAMRJava_LIB_DEPENDS:STATIC=general;vtkIOAMR;general;vtkWrappingJava;general;vtkFiltersAMRJava;general;vtkParallelCoreJava; //Dependencies for the target vtkIOAMR_LIB_DEPENDS:STATIC=general;vtkFiltersAMR;general;vtkParallelCore;general;vtkhdf5_hl;general;vtkhdf5;general;vtksys; //Dependencies for the target vtkIOCoreJava_LIB_DEPENDS:STATIC=general;vtkIOCore;general;vtkWrappingJava;general;vtkCommonDataModelJava;general;vtkCommonExecutionModelJava;general;vtkCommonMiscJava; //Dependencies for the target vtkIOCore_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonExecutionModel;general;vtkCommonMisc;general;vtkzlib;general;vtksys; //Dependencies for the target vtkIOEnSightJava_LIB_DEPENDS:STATIC=general;vtkIOEnSight;general;vtkWrappingJava;general;vtkCommonExecutionModelJava; //Dependencies for the target vtkIOEnSight_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel; //Dependencies for the target vtkIOExodusJava_LIB_DEPENDS:STATIC=general;vtkIOExodus;general;vtkWrappingJava;general;vtkFiltersGeneralJava;general;vtkIOXMLJava; //Dependencies for the target vtkIOExodus_LIB_DEPENDS:STATIC=general;vtkFiltersGeneral;general;vtkIOXML;general;vtkexoIIc;general;vtksys; //Dependencies for the target vtkIOExportJava_LIB_DEPENDS:STATIC=general;vtkIOExport;general;vtkWrappingJava;general;vtkCommonCoreJava;general;vtkImagingCoreJava;general;vtkRenderingAnnotationJava;general;vtkRenderingContext2DJava;general;vtkRenderingCoreJava;general;vtkRenderingFreeTypeJava;general;vtkRenderingGL2PSJava;general;vtkRenderingLabelJava;general;vtkRenderingOpenGLJava; //Dependencies for the target vtkIOExport_LIB_DEPENDS:STATIC=general;vtkCommonCore;general;vtkImagingCore;general;vtkRenderingAnnotation;general;vtkRenderingContext2D;general;vtkRenderingCore;general;vtkRenderingFreeType;general;vtkRenderingGL2PS;general;vtkRenderingLabel;general;vtkRenderingOpenGL;general;vtkIOImage;general;vtkFiltersGeometry;general;vtkgl2ps; //Dependencies for the target vtkIOGeometryJava_LIB_DEPENDS:STATIC=general;vtkIOGeometry;general;vtkWrappingJava;general;vtkCommonDataModelJava;general;vtkCommonMiscJava;general;vtkCommonSystemJava;general;vtkIOCoreJava; //Dependencies for the target vtkIOGeometry_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkIOCore;general;vtkzlib;general;vtkjsoncpp;general;vtksys; //Dependencies for the target vtkIOImageJava_LIB_DEPENDS:STATIC=general;vtkIOImage;general;vtkWrappingJava;general;vtkCommonDataModelJava;general;vtkCommonExecutionModelJava;general;vtkCommonMathJava;general;vtkCommonMiscJava;general;vtkCommonSystemJava;general;vtkCommonTransformsJava;general;vtkIOCoreJava; //Dependencies for the target vtkIOImage_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonExecutionModel;general;vtkCommonMath;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkCommonTransforms;general;vtkIOCore;general;vtkjpeg;general;vtkpng;general;vtktiff;general;vtkmetaio;general;vtkDICOMParser;general;vtksys; //Dependencies for the target vtkIOImportJava_LIB_DEPENDS:STATIC=general;vtkIOImport;general;vtkWrappingJava;general;vtkCommonCoreJava;general;vtkRenderingCoreJava; //Dependencies for the target vtkIOImport_LIB_DEPENDS:STATIC=general;vtkCommonCore;general;vtkRenderingCore;general;vtkFiltersSources; //Dependencies for the target vtkIOInfovisJava_LIB_DEPENDS:STATIC=general;vtkIOInfovis;general;vtkWrappingJava;general;vtkCommonDataModelJava;general;vtkCommonMiscJava;general;vtkCommonSystemJava;general;vtkIOCoreJava;general;vtkIOLegacyJava;general;vtkInfovisCoreJava; //Dependencies for the target vtkIOInfovis_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkIOCore;general;vtkIOLegacy;general;vtkInfovisCore;general;vtklibxml2;general;vtksys; //Dependencies for the target vtkIOLSDynaJava_LIB_DEPENDS:STATIC=general;vtkIOLSDyna;general;vtkWrappingJava;general;vtkCommonExecutionModelJava;general;vtkIOXMLJava; //Dependencies for the target vtkIOLSDyna_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkIOXML;general;vtksys; //Dependencies for the target vtkIOLegacyJava_LIB_DEPENDS:STATIC=general;vtkIOLegacy;general;vtkWrappingJava;general;vtkCommonDataModelJava;general;vtkCommonMiscJava;general;vtkCommonSystemJava;general;vtkIOCoreJava; //Dependencies for the target vtkIOLegacy_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkIOCore;general;vtksys; //Dependencies for the target vtkIOMINCJava_LIB_DEPENDS:STATIC=general;vtkIOMINC;general;vtkWrappingJava;general;vtkCommonExecutionModelJava;general;vtkFiltersHybridJava;general;vtkIOGeometryJava;general;vtkIOImageJava;general;vtkRenderingCoreJava; //Dependencies for the target vtkIOMINC_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkFiltersHybrid;general;vtkIOGeometry;general;vtkIOImage;general;vtkRenderingCore;general;vtksys;general;vtkNetCDF;general;vtkNetCDF_cxx; //Dependencies for the target vtkIOMovieJava_LIB_DEPENDS:STATIC=general;vtkIOMovie;general;vtkWrappingJava;general;vtkCommonDataModelJava;general;vtkCommonExecutionModelJava;general;vtkCommonSystemJava;general;vtkIOCoreJava; //Dependencies for the target vtkIOMovie_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonExecutionModel;general;vtkCommonSystem;general;vtkIOCore;general;vtkoggtheora;general;vfw32; //Dependencies for the target vtkIONetCDFJava_LIB_DEPENDS:STATIC=general;vtkIONetCDF;general;vtkWrappingJava;general;vtkCommonDataModelJava;general;vtkCommonSystemJava;general;vtkIOCoreJava; //Dependencies for the target vtkIONetCDF_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonSystem;general;vtkIOCore;general;vtksys;general;vtkNetCDF;general;vtkNetCDF_cxx; //Dependencies for the target vtkIOPLYJava_LIB_DEPENDS:STATIC=general;vtkIOPLY;general;vtkWrappingJava;general;vtkCommonExecutionModelJava;general;vtkCommonMiscJava;general;vtkIOGeometryJava; //Dependencies for the target vtkIOPLY_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkCommonMisc;general;vtkIOGeometry; //Dependencies for the target vtkIOParallelJava_LIB_DEPENDS:STATIC=general;vtkIOParallel;general;vtkWrappingJava;general;vtkFiltersParallelJava;general;vtkIOImageJava;general;vtkIONetCDFJava;general;vtkIOXMLJava;general;vtkParallelCoreJava; //Dependencies for the target vtkIOParallel_LIB_DEPENDS:STATIC=general;vtkFiltersParallel;general;vtkIOImage;general;vtkIONetCDF;general;vtkIOXML;general;vtkParallelCore;general;vtkexoIIc;general;vtkNetCDF;general;vtkNetCDF_cxx; //Dependencies for the target vtkIOSQLJava_LIB_DEPENDS:STATIC=general;vtkIOSQL;general;vtkWrappingJava;general;vtkIOCoreJava; //Dependencies for the target vtkIOSQL_LIB_DEPENDS:STATIC=general;vtkIOCore;general;vtksys;general;vtksqlite; //Dependencies for the target vtkIOVideoJava_LIB_DEPENDS:STATIC=general;vtkIOVideo;general;vtkWrappingJava;general;vtkCommonExecutionModelJava; //Dependencies for the target vtkIOVideo_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtksys;general;vfw32; //Dependencies for the target vtkIOXMLJava_LIB_DEPENDS:STATIC=general;vtkIOXML;general;vtkWrappingJava;general;vtkIOGeometryJava;general;vtkIOXMLParserJava; //Dependencies for the target vtkIOXMLParserJava_LIB_DEPENDS:STATIC=general;vtkIOXMLParser;general;vtkWrappingJava;general;vtkCommonDataModelJava;general;vtkCommonMiscJava;general;vtkCommonSystemJava;general;vtkIOCoreJava; //Dependencies for the target vtkIOXMLParser_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkIOCore;general;vtkexpat; //Dependencies for the target vtkIOXML_LIB_DEPENDS:STATIC=general;vtkIOGeometry;general;vtkIOXMLParser;general;vtksys; //Dependencies for the target vtkImagingColorJava_LIB_DEPENDS:STATIC=general;vtkImagingColor;general;vtkWrappingJava;general;vtkImagingCoreJava; //Dependencies for the target vtkImagingColor_LIB_DEPENDS:STATIC=general;vtkImagingCore; //Dependencies for the target vtkImagingCoreJava_LIB_DEPENDS:STATIC=general;vtkImagingCore;general;vtkWrappingJava;general;vtkCommonExecutionModelJava;general;vtkCommonMathJava;general;vtkCommonSystemJava;general;vtkCommonTransformsJava; //Dependencies for the target vtkImagingCore_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkCommonMath;general;vtkCommonSystem;general;vtkCommonTransforms; //Dependencies for the target vtkImagingFourierJava_LIB_DEPENDS:STATIC=general;vtkImagingFourier;general;vtkWrappingJava;general;vtkImagingCoreJava; //Dependencies for the target vtkImagingFourier_LIB_DEPENDS:STATIC=general;vtkImagingCore;general;vtksys; //Dependencies for the target vtkImagingGeneralJava_LIB_DEPENDS:STATIC=general;vtkImagingGeneral;general;vtkWrappingJava;general;vtkImagingSourcesJava; //Dependencies for the target vtkImagingGeneral_LIB_DEPENDS:STATIC=general;vtkImagingSources; //Dependencies for the target vtkImagingHybridJava_LIB_DEPENDS:STATIC=general;vtkImagingHybrid;general;vtkWrappingJava;general;vtkIOImageJava;general;vtkImagingCoreJava; //Dependencies for the target vtkImagingHybrid_LIB_DEPENDS:STATIC=general;vtkIOImage;general;vtkImagingCore; //Dependencies for the target vtkImagingMathJava_LIB_DEPENDS:STATIC=general;vtkImagingMath;general;vtkWrappingJava;general;vtkCommonDataModelJava;general;vtkCommonExecutionModelJava; //Dependencies for the target vtkImagingMath_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonExecutionModel; //Dependencies for the target vtkImagingMorphologicalJava_LIB_DEPENDS:STATIC=general;vtkImagingMorphological;general;vtkWrappingJava;general;vtkImagingCoreJava;general;vtkImagingGeneralJava; //Dependencies for the target vtkImagingMorphological_LIB_DEPENDS:STATIC=general;vtkImagingCore;general;vtkImagingGeneral; //Dependencies for the target vtkImagingSourcesJava_LIB_DEPENDS:STATIC=general;vtkImagingSources;general;vtkWrappingJava;general;vtkImagingCoreJava; //Dependencies for the target vtkImagingSources_LIB_DEPENDS:STATIC=general;vtkImagingCore; //Dependencies for the target vtkImagingStatisticsJava_LIB_DEPENDS:STATIC=general;vtkImagingStatistics;general;vtkWrappingJava;general;vtkImagingCoreJava; //Dependencies for the target vtkImagingStatistics_LIB_DEPENDS:STATIC=general;vtkImagingCore; //Dependencies for the target vtkImagingStencilJava_LIB_DEPENDS:STATIC=general;vtkImagingStencil;general;vtkWrappingJava;general;vtkCommonComputationalGeometryJava;general;vtkImagingCoreJava; //Dependencies for the target vtkImagingStencil_LIB_DEPENDS:STATIC=general;vtkCommonComputationalGeometry;general;vtkImagingCore; //Dependencies for the target vtkInfovisCoreJava_LIB_DEPENDS:STATIC=general;vtkInfovisCore;general;vtkWrappingJava;general;vtkCommonDataModelJava;general;vtkCommonSystemJava;general;vtkFiltersExtractionJava;general;vtkFiltersGeneralJava; //Dependencies for the target vtkInfovisCore_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonSystem;general;vtkFiltersExtraction;general;vtkFiltersGeneral; //Dependencies for the target vtkInfovisLayoutJava_LIB_DEPENDS:STATIC=general;vtkInfovisLayout;general;vtkWrappingJava;general;vtkCommonExecutionModelJava;general;vtkFiltersModelingJava;general;vtkImagingHybridJava;general;vtkInfovisCoreJava; //Dependencies for the target vtkInfovisLayout_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkFiltersModeling;general;vtkImagingHybrid;general;vtkInfovisCore; //Dependencies for the target vtkInteractionImageJava_LIB_DEPENDS:STATIC=general;vtkInteractionImage;general;vtkWrappingJava;general;vtkImagingColorJava;general;vtkInteractionStyleJava;general;vtkInteractionWidgetsJava;general;vtkRenderingCoreJava;general;vtkRenderingFreeTypeJava; //Dependencies for the target vtkInteractionImage_LIB_DEPENDS:STATIC=general;vtkImagingColor;general;vtkInteractionStyle;general;vtkInteractionWidgets;general;vtkRenderingCore;general;vtkRenderingFreeType; //Dependencies for the target vtkInteractionStyleJava_LIB_DEPENDS:STATIC=general;vtkInteractionStyle;general;vtkWrappingJava;general;vtkRenderingCoreJava; //Dependencies for the target vtkInteractionStyle_LIB_DEPENDS:STATIC=general;vtkRenderingCore;general;vtkFiltersSources;general;vtkFiltersExtraction; //Dependencies for the target vtkInteractionWidgetsJava_LIB_DEPENDS:STATIC=general;vtkInteractionWidgets;general;vtkWrappingJava;general;vtkFiltersHybridJava;general;vtkFiltersModelingJava;general;vtkImagingGeneralJava;general;vtkImagingHybridJava;general;vtkInteractionStyleJava;general;vtkRenderingAnnotationJava;general;vtkRenderingFreeTypeJava;general;vtkRenderingVolumeJava; //Dependencies for the target vtkInteractionWidgets_LIB_DEPENDS:STATIC=general;vtkFiltersHybrid;general;vtkFiltersModeling;general;vtkImagingGeneral;general;vtkImagingHybrid;general;vtkInteractionStyle;general;vtkRenderingAnnotation;general;vtkRenderingFreeType;general;vtkRenderingVolume; //Dependencies for the target vtkNetCDF_LIB_DEPENDS:STATIC=general;vtkhdf5_hl;general;vtkhdf5; //Dependencies for the target vtkNetCDF_cxx_LIB_DEPENDS:STATIC=general;vtkNetCDF; //Dependencies for the target vtkParallelCoreJava_LIB_DEPENDS:STATIC=general;vtkParallelCore;general;vtkWrappingJava;general;vtkCommonCoreJava;general;vtkIOLegacyJava; //Dependencies for the target vtkParallelCore_LIB_DEPENDS:STATIC=general;vtkCommonCore;general;vtkIOLegacy;general;vtksys; //Dependencies for the target vtkRenderingAnnotationJava_LIB_DEPENDS:STATIC=general;vtkRenderingAnnotation;general;vtkWrappingJava;general;vtkImagingColorJava;general;vtkRenderingFreeTypeJava; //Dependencies for the target vtkRenderingAnnotation_LIB_DEPENDS:STATIC=general;vtkImagingColor;general;vtkRenderingFreeType;general;vtkFiltersSources; //Dependencies for the target vtkRenderingContext2DJava_LIB_DEPENDS:STATIC=general;vtkRenderingContext2D;general;vtkWrappingJava;general;vtkRenderingCoreJava; //Dependencies for the target vtkRenderingContext2D_LIB_DEPENDS:STATIC=general;vtkRenderingCore;general;vtkCommonDataModel;general;vtkCommonMath;general;vtkCommonTransforms;general;vtkRenderingOpenGL;general;vtkRenderingFreeType; //Dependencies for the target vtkRenderingCoreJava_LIB_DEPENDS:STATIC=general;vtkRenderingCore;general;vtkWrappingJava;general;C:/Program Files/Java/jdk1.8.0_31/lib/jawt.lib;general;vtkCommonExecutionModelJava;general;vtkCommonTransformsJava; //Dependencies for the target vtkRenderingCore_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkCommonTransforms;general;vtkFiltersSources;general;vtkFiltersGeometry;general;vtkFiltersExtraction;general;vtksys; //Dependencies for the target vtkRenderingFreeTypeJava_LIB_DEPENDS:STATIC=general;vtkRenderingFreeType;general;vtkWrappingJava;general;vtkRenderingCoreJava;general;vtkRenderingCoreJava; //Dependencies for the target vtkRenderingFreeTypeOpenGLJava_LIB_DEPENDS:STATIC=general;vtkRenderingFreeTypeOpenGL;general;vtkWrappingJava;general;vtkRenderingCoreJava;general;vtkRenderingFreeTypeJava;general;vtkRenderingOpenGLJava; //Dependencies for the target vtkRenderingFreeTypeOpenGL_LIB_DEPENDS:STATIC=general;vtkRenderingCore;general;vtkRenderingFreeType;general;vtkRenderingOpenGL; //Dependencies for the target vtkRenderingFreeType_LIB_DEPENDS:STATIC=general;vtkRenderingCore;general;vtkRenderingCore;general;vtkfreetype;general;vtkftgl; //Dependencies for the target vtkRenderingGL2PSJava_LIB_DEPENDS:STATIC=general;vtkRenderingGL2PS;general;vtkWrappingJava;general;vtkRenderingContext2DJava; //Dependencies for the target vtkRenderingGL2PS_LIB_DEPENDS:STATIC=general;vtkRenderingContext2D;general;vtkRenderingOpenGL;general;vtkRenderingFreeType;general;vtkgl2ps; //Dependencies for the target vtkRenderingImageJava_LIB_DEPENDS:STATIC=general;vtkRenderingImage;general;vtkWrappingJava;general;vtkImagingCoreJava;general;vtkRenderingCoreJava; //Dependencies for the target vtkRenderingImage_LIB_DEPENDS:STATIC=general;vtkImagingCore;general;vtkRenderingCore; //Dependencies for the target vtkRenderingLICJava_LIB_DEPENDS:STATIC=general;vtkRenderingLIC;general;vtkWrappingJava;general;vtkIOLegacyJava;general;vtkIOXMLJava;general;vtkImagingSourcesJava;general;vtkRenderingOpenGLJava; //Dependencies for the target vtkRenderingLIC_LIB_DEPENDS:STATIC=general;vtkIOLegacy;general;vtkIOXML;general;vtkImagingSources;general;vtkRenderingOpenGL;general;vtksys; //Dependencies for the target vtkRenderingLODJava_LIB_DEPENDS:STATIC=general;vtkRenderingLOD;general;vtkWrappingJava;general;vtkFiltersModelingJava;general;vtkRenderingCoreJava; //Dependencies for the target vtkRenderingLOD_LIB_DEPENDS:STATIC=general;vtkFiltersModeling;general;vtkRenderingCore; //Dependencies for the target vtkRenderingLabelJava_LIB_DEPENDS:STATIC=general;vtkRenderingLabel;general;vtkWrappingJava;general;vtkRenderingFreeTypeJava; //Dependencies for the target vtkRenderingLabel_LIB_DEPENDS:STATIC=general;vtkRenderingFreeType;general;vtkFiltersExtraction; //Dependencies for the target vtkRenderingOpenGLJava_LIB_DEPENDS:STATIC=general;vtkRenderingOpenGL;general;vtkWrappingJava;general;vtkRenderingCoreJava; //Dependencies for the target vtkRenderingOpenGL_LIB_DEPENDS:STATIC=general;vtkRenderingCore;general;vtkImagingHybrid;general;vtksys;general;glu32;general;opengl32; //Dependencies for the target vtkRenderingVolumeAMRJava_LIB_DEPENDS:STATIC=general;vtkRenderingVolumeAMR;general;vtkWrappingJava;general;vtkFiltersAMRJava;general;vtkParallelCoreJava;general;vtkRenderingVolumeJava; //Dependencies for the target vtkRenderingVolumeAMR_LIB_DEPENDS:STATIC=general;vtkFiltersAMR;general;vtkParallelCore;general;vtkRenderingVolume; //Dependencies for the target vtkRenderingVolumeJava_LIB_DEPENDS:STATIC=general;vtkRenderingVolume;general;vtkWrappingJava;general;vtkImagingCoreJava;general;vtkRenderingCoreJava; //Dependencies for the target vtkRenderingVolumeOpenGLJava_LIB_DEPENDS:STATIC=general;vtkRenderingVolumeOpenGL;general;vtkWrappingJava;general;vtkRenderingOpenGLJava;general;vtkRenderingVolumeJava; //Dependencies for the target vtkRenderingVolumeOpenGL_LIB_DEPENDS:STATIC=general;vtkRenderingOpenGL;general;vtkRenderingVolume;general;vtksys;general;vtkFiltersGeneral;general;vtkFiltersSources; //Dependencies for the target vtkRenderingVolume_LIB_DEPENDS:STATIC=general;vtkImagingCore;general;vtkRenderingCore; //Dependencies for the target vtkViewsContext2DJava_LIB_DEPENDS:STATIC=general;vtkViewsContext2D;general;vtkWrappingJava;general;vtkRenderingContext2DJava;general;vtkViewsCoreJava; //Dependencies for the target vtkViewsContext2D_LIB_DEPENDS:STATIC=general;vtkRenderingContext2D;general;vtkViewsCore; //Dependencies for the target vtkViewsCoreJava_LIB_DEPENDS:STATIC=general;vtkViewsCore;general;vtkWrappingJava;general;vtkInteractionWidgetsJava;general;vtkRenderingCoreJava; //Dependencies for the target vtkViewsCore_LIB_DEPENDS:STATIC=general;vtkInteractionWidgets;general;vtkRenderingCore; //Dependencies for the target vtkViewsGeovisJava_LIB_DEPENDS:STATIC=general;vtkViewsGeovis;general;vtkWrappingJava;general;vtkGeovisCoreJava;general;vtkViewsInfovisJava; //Dependencies for the target vtkViewsGeovis_LIB_DEPENDS:STATIC=general;vtkGeovisCore;general;vtkViewsInfovis; //Dependencies for the target vtkViewsInfovisJava_LIB_DEPENDS:STATIC=general;vtkViewsInfovis;general;vtkWrappingJava;general;vtkChartsCoreJava;general;vtkCommonColorJava;general;vtkFiltersImagingJava;general;vtkFiltersModelingJava;general;vtkInfovisLayoutJava;general;vtkInteractionStyleJava;general;vtkRenderingContext2DJava;general;vtkRenderingLabelJava;general;vtkViewsCoreJava; //Dependencies for the target vtkViewsInfovis_LIB_DEPENDS:STATIC=general;vtkChartsCore;general;vtkCommonColor;general;vtkFiltersImaging;general;vtkFiltersModeling;general;vtkInfovisLayout;general;vtkInteractionStyle;general;vtkRenderingContext2D;general;vtkRenderingLabel;general;vtkViewsCore;general;vtkFiltersGeometry; //Dependencies for the target vtkWrappingJava_LIB_DEPENDS:STATIC=general;vtkCommonCore; //Dependencies for target vtkWrappingTools_LIB_DEPENDS:STATIC= //Dependencies for target vtkalglib_LIB_DEPENDS:STATIC= //Dependencies for the target vtkexoIIc_LIB_DEPENDS:STATIC=general;vtkNetCDF;general;vtkNetCDF_cxx; //Dependencies for target vtkexpat_LIB_DEPENDS:STATIC= //Dependencies for the target vtkfreetype_LIB_DEPENDS:STATIC=general;vtkzlib; //Dependencies for the target vtkftgl_LIB_DEPENDS:STATIC=general;opengl32;general;vtkfreetype; //Dependencies for the target vtkgl2ps_LIB_DEPENDS:STATIC=general;glu32;general;opengl32;general;vtkzlib;general;vtkpng; //Dependencies for the target vtkhdf5_LIB_DEPENDS:STATIC=general;ws2_32;general;wsock32;general;vtkzlib; //Dependencies for the target vtkhdf5_hl_LIB_DEPENDS:STATIC=general;vtkhdf5; //Dependencies for target vtkjpeg_LIB_DEPENDS:STATIC= //Dependencies for target vtkjsoncpp_LIB_DEPENDS:STATIC= //Value Computed by CMake vtklibxml2_BINARY_DIR:STATIC=C:/VTK/ThirdParty/libxml2/vtklibxml2 //Dependencies for the target vtklibxml2_LIB_DEPENDS:STATIC=general;vtkzlib; //Value Computed by CMake vtklibxml2_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/libxml2/vtklibxml2 //Value Computed by CMake vtkmetaio_BINARY_DIR:STATIC=C:/VTK/Utilities/MetaIO/vtkmetaio //Dependencies for the target vtkmetaio_LIB_DEPENDS:STATIC=general;vtkzlib;general;comctl32;general;wsock32; //Value Computed by CMake vtkmetaio_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/Utilities/MetaIO/vtkmetaio //Dependencies for target vtkoggtheora_LIB_DEPENDS:STATIC= //Dependencies for the target vtkpng_LIB_DEPENDS:STATIC=general;vtkzlib; //Dependencies for target vtkproj4_LIB_DEPENDS:STATIC= //Dependencies for target vtksqlite_LIB_DEPENDS:STATIC= //Value Computed by CMake vtksys_BINARY_DIR:STATIC=C:/VTK/Utilities/KWSys/vtksys //Dependencies for the target vtksys_LIB_DEPENDS:STATIC=general;ws2_32;general;Psapi; //Value Computed by CMake vtksys_SOURCE_DIR:STATIC=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/Utilities/KWSys/vtksys //Dependencies for the target vtktiff_LIB_DEPENDS:STATIC=general;vtkzlib;general;vtkjpeg; //Dependencies for target vtkzlib_LIB_DEPENDS:STATIC= ######################## # INTERNAL cache entries ######################## ALGLIB_SHARED_LIB:INTERNAL=ON //Stored GUID ALL_BUILD_GUID_CMAKE:INTERNAL=15B133D4-9549-4679-B6B5-B48375A68EBC //Result of TRY_COMPILE CMAKE_ANSI_FOR_SCOPE:INTERNAL=TRUE //Have include iostream CMAKE_ANSI_STREAM_HEADERS:INTERNAL=1 //This is the directory where this CMakeCache.txt was created CMAKE_CACHEFILE_DIR:INTERNAL=c:/VTK //Major version of cmake used to create the current loaded cache CMAKE_CACHE_MAJOR_VERSION:INTERNAL=3 //Minor version of cmake used to create the current loaded cache CMAKE_CACHE_MINOR_VERSION:INTERNAL=0 //Patch version of cmake used to create the current loaded cache CMAKE_CACHE_PATCH_VERSION:INTERNAL=0 //Path to CMake executable. CMAKE_COMMAND:INTERNAL=C:/Program Files (x86)/CMake/bin/cmake.exe //Path to cpack program executable. CMAKE_CPACK_COMMAND:INTERNAL=C:/Program Files (x86)/CMake/bin/cpack.exe //Path to ctest program executable. CMAKE_CTEST_COMMAND:INTERNAL=C:/Program Files (x86)/CMake/bin/ctest.exe //ADVANCED property for variable: CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_FLAGS_RELEASE CMAKE_CXX_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_FLAGS_RELWITHDEBINFO CMAKE_CXX_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_STANDARD_LIBRARIES CMAKE_CXX_STANDARD_LIBRARIES-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS CMAKE_C_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_MINSIZEREL CMAKE_C_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_RELWITHDEBINFO CMAKE_C_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_STANDARD_LIBRARIES CMAKE_C_STANDARD_LIBRARIES-ADVANCED:INTERNAL=1 //Executable file format CMAKE_EXECUTABLE_FORMAT:INTERNAL=Unknown //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS CMAKE_EXE_LINKER_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_DEBUG CMAKE_EXE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_MINSIZEREL CMAKE_EXE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_RELEASE CMAKE_EXE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Name of generator. CMAKE_GENERATOR:INTERNAL=Visual Studio 10 2010 //Name of generator toolset. CMAKE_GENERATOR_TOOLSET:INTERNAL= //Result of TRY_COMPILE CMAKE_HAS_ANSI_STRING_STREAM:INTERNAL=TRUE //Have includes pthread.h CMAKE_HAVE_PTHREAD_H:INTERNAL= //Start directory with the top level CMakeLists.txt file for this // project CMAKE_HOME_DIRECTORY:INTERNAL=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0 //ADVANCED property for variable: CMAKE_LINKER CMAKE_LINKER-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_DEBUG CMAKE_MODULE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_RELEASE CMAKE_MODULE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Does the compiler support ansi for scope. CMAKE_NO_ANSI_FOR_SCOPE:INTERNAL=0 //ADVANCED property for variable: CMAKE_NO_ANSI_STREAM_HEADERS CMAKE_NO_ANSI_STREAM_HEADERS-ADVANCED:INTERNAL=1 //Does the compiler support headers like iostream. CMAKE_NO_ANSI_STREAM_HEADERS:INTERNAL=0 //Does the compiler support sstream CMAKE_NO_ANSI_STRING_STREAM:INTERNAL=0 //Does the compiler support std::. CMAKE_NO_STD_NAMESPACE:INTERNAL=0 //number of local generators CMAKE_NUMBER_OF_LOCAL_GENERATORS:INTERNAL=139 //ADVANCED property for variable: CMAKE_RC_COMPILER CMAKE_RC_COMPILER-ADVANCED:INTERNAL=1 CMAKE_RC_COMPILER_WORKS:INTERNAL=1 //ADVANCED property for variable: CMAKE_RC_FLAGS CMAKE_RC_FLAGS-ADVANCED:INTERNAL=1 //Test Support for 64 bit file systems CMAKE_REQUIRE_LARGE_FILE_SUPPORT:INTERNAL= //Path to CMake installation. CMAKE_ROOT:INTERNAL=C:/Program Files (x86)/CMake/share/cmake-3.0 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_DEBUG CMAKE_SHARED_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_RELEASE CMAKE_SHARED_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(unsigned short) CMAKE_SIZEOF_UNSIGNED_SHORT:INTERNAL=2 //ADVANCED property for variable: CMAKE_SKIP_INSTALL_RPATH CMAKE_SKIP_INSTALL_RPATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SKIP_RPATH CMAKE_SKIP_RPATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS CMAKE_STATIC_LINKER_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_DEBUG CMAKE_STATIC_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELEASE CMAKE_STATIC_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Result of TRY_COMPILE CMAKE_STD_NAMESPACE:INTERNAL=TRUE //Suppress Warnings that are meant for the author of the CMakeLists.txt // files. CMAKE_SUPPRESS_DEVELOPER_WARNINGS:INTERNAL=FALSE //ADVANCED property for variable: CMAKE_THREAD_LIBS CMAKE_THREAD_LIBS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_USE_RELATIVE_PATHS CMAKE_USE_RELATIVE_PATHS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_VERBOSE_MAKEFILE CMAKE_VERBOSE_MAKEFILE-ADVANCED:INTERNAL=1 //Result of TEST_BIG_ENDIAN CMAKE_WORDS_BIGENDIAN:INTERNAL=0 //Test COMPILER_HAS_DEPRECATED COMPILER_HAS_DEPRECATED:INTERNAL=1 //Test COMPILER_HAS_DEPRECATED_ATTR COMPILER_HAS_DEPRECATED_ATTR:INTERNAL= //ADVANCED property for variable: DirectX_INCLUDE_DIR DirectX_INCLUDE_DIR-ADVANCED:INTERNAL=1 //ADVANCED property for variable: DirectX_LIBRARY DirectX_LIBRARY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: EXODUSII_DISABLE_COMPILER_WARNINGS EXODUSII_DISABLE_COMPILER_WARNINGS-ADVANCED:INTERNAL=1 //Have include malloc.h EX_HAVE_MALLOC_H:INTERNAL=1 //ADVANCED property for variable: ExternalData_URL_TEMPLATES ExternalData_URL_TEMPLATES-ADVANCED:INTERNAL=1 //Details about finding JNI FIND_PACKAGE_MESSAGE_DETAILS_JNI:INTERNAL=[C:/Program Files/Java/jdk1.8.0_31/lib/jawt.lib][C:/Program Files/Java/jdk1.8.0_31/lib/jvm.lib][C:/Program Files/Java/jdk1.8.0_31/include][C:/Program Files/Java/jdk1.8.0_31/include/win32][C:/Program Files/Java/jdk1.8.0_31/include][v()] //Details about finding Java FIND_PACKAGE_MESSAGE_DETAILS_Java:INTERNAL=[C:/Program Files/Java/jdk1.8.0_31/bin/java.exe][C:/Program Files/Java/jdk1.8.0_31/bin/jar.exe][C:/Program Files/Java/jdk1.8.0_31/bin/javac.exe][C:/Program Files/Java/jdk1.8.0_31/bin/javah.exe][C:/Program Files/Java/jdk1.8.0_31/bin/javadoc.exe][v1.8.0.31()] //Details about finding OpenGL FIND_PACKAGE_MESSAGE_DETAILS_OpenGL:INTERNAL=[opengl32][v()] //Details about finding Threads FIND_PACKAGE_MESSAGE_DETAILS_Threads:INTERNAL=[TRUE][v()] //Checking IF overflows normally converting floating-point to integer // values H5_FP_TO_INTEGER_OVERFLOW_WORKS:INTERNAL=1 //Result of TRY_COMPILE H5_FP_TO_INTEGER_OVERFLOW_WORKS_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_FP_TO_INTEGER_OVERFLOW_WORKS_RUN:INTERNAL=0 //Checking IF accurately roundup converting floating-point to unsigned // long long values H5_FP_TO_ULLONG_ACCURATE:INTERNAL=1 //Result of TRY_COMPILE H5_FP_TO_ULLONG_ACCURATE_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_FP_TO_ULLONG_ACCURATE_RUN:INTERNAL=0 H5_FP_TO_ULLONG_RIGHT_MAXIMUM:INTERNAL= //Result of TRY_COMPILE H5_FP_TO_ULLONG_RIGHT_MAXIMUM_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_FP_TO_ULLONG_RIGHT_MAXIMUM_RUN:INTERNAL=0 //Have function alarm H5_HAVE_ALARM:INTERNAL= //Have symbol tzname H5_HAVE_DECL_TZNAME:INTERNAL=1 //Have includes io.h;setjmp.h;stddef.h;stdint.h;string.h;sys/stat.h;time.h;sys/timeb.h;sys/types.h;stdlib.h;memory.h;dlfcn.h H5_HAVE_DLFCN_H:INTERNAL= //Have includes io.h;setjmp.h;stddef.h;stdint.h;string.h;sys/stat.h;time.h;sys/timeb.h;sys/types.h;stdlib.h;memory.h;features.h H5_HAVE_FEATURES_H:INTERNAL= //Have function fork H5_HAVE_FORK:INTERNAL= //Have function frexpf H5_HAVE_FREXPF:INTERNAL= //Have function frexpl H5_HAVE_FREXPL:INTERNAL= //Have function fseeko H5_HAVE_FSEEKO:INTERNAL= //Have function fstat64 H5_HAVE_FSTAT64:INTERNAL= //Have function ftello H5_HAVE_FTELLO:INTERNAL= //Have function getpwuid H5_HAVE_GETPWUID:INTERNAL= //Have function getrusage H5_HAVE_GETRUSAGE:INTERNAL= //Have includes ;globus/common.h H5_HAVE_GLOBUS_COMMON_H:INTERNAL= //Have includes io.h;setjmp.h;stddef.h;stdint.h;string.h;sys/stat.h;time.h;sys/timeb.h;sys/types.h;stdlib.h;memory.h;inttypes.h H5_HAVE_INTTYPES_H:INTERNAL= //Have function ioctl H5_HAVE_IOCTL:INTERNAL= //Have library nsl;ws2_32;wsock32 H5_HAVE_LIBNSL:INTERNAL= //Have library socket;ws2_32;wsock32 H5_HAVE_LIBSOCKET:INTERNAL= //Have library ucb;ws2_32;wsock32 H5_HAVE_LIBUCB:INTERNAL= //Have library ws2_32; H5_HAVE_LIBWS2_32:INTERNAL=1 //Have library wsock32;ws2_32 H5_HAVE_LIBWSOCK32:INTERNAL=1 //Have function lstat H5_HAVE_LSTAT:INTERNAL= //Have include io.h;setjmp.h;stddef.h;stdint.h;string.h;sys/stat.h;time.h;sys/timeb.h;sys/types.h;stdlib.h;memory.h H5_HAVE_MEMORY_H:INTERNAL=1 //Have includes io.h;mfhdf.h H5_HAVE_MFHDF_H:INTERNAL= //Have includes io.h;setjmp.h;stddef.h;stdint.h;string.h;sys/stat.h;time.h;sys/timeb.h;sys/types.h;stdlib.h;memory.h;winsock.h;netinet/in.h H5_HAVE_NETINET_IN_H:INTERNAL= //Have includes io.h;pdb.h H5_HAVE_PDB_H:INTERNAL= //Have includes io.h;pthread.h H5_HAVE_PTHREAD_H:INTERNAL= //Have function random H5_HAVE_RANDOM:INTERNAL= //Have function rand_r H5_HAVE_RAND_R:INTERNAL= //Have function setjmp H5_HAVE_SETJMP:INTERNAL= //Have function setsysinfo H5_HAVE_SETSYSINFO:INTERNAL= //Have function sigaction H5_HAVE_SIGACTION:INTERNAL= //Have function siglongjmp H5_HAVE_SIGLONGJMP:INTERNAL= //Have function signal H5_HAVE_SIGNAL:INTERNAL=1 //Have function sigprocmask H5_HAVE_SIGPROCMASK:INTERNAL= //Have function sigsetjmp H5_HAVE_SIGSETJMP:INTERNAL= //Have function snprintf H5_HAVE_SNPRINTF:INTERNAL= //Have function srandom H5_HAVE_SRANDOM:INTERNAL= //Have includes io.h;setjmp.h;srbclient.h H5_HAVE_SRBCLIENT_H:INTERNAL= //Have function stat64 H5_HAVE_STAT64:INTERNAL= //Have include io.h;setjmp.h;stddef.h;stdint.h H5_HAVE_STDINT_H:INTERNAL=1 //Have include stdint.h H5_HAVE_STDINT_H_CXX:INTERNAL=1 //Have include io.h;setjmp.h;stddef.h;stdint.h;string.h;sys/stat.h;time.h;sys/timeb.h;sys/types.h;stdlib.h H5_HAVE_STDLIB_H:INTERNAL=1 //Have includes io.h;setjmp.h;stddef.h;stdint.h;string.h;strings.h H5_HAVE_STRINGS_H:INTERNAL= //Have include io.h;setjmp.h;stddef.h;stdint.h;string.h H5_HAVE_STRING_H:INTERNAL=1 //Have function symlink H5_HAVE_SYMLINK:INTERNAL= //Have includes io.h;setjmp.h;stddef.h;stdint.h;string.h;sys/ioctl.h H5_HAVE_SYS_IOCTL_H:INTERNAL= //Have includes io.h;setjmp.h;stddef.h;stdint.h;string.h;sys/proc.h H5_HAVE_SYS_PROC_H:INTERNAL= //Have includes io.h;setjmp.h;stddef.h;stdint.h;string.h;sys/resource.h H5_HAVE_SYS_RESOURCE_H:INTERNAL= //Have includes io.h;setjmp.h;stddef.h;stdint.h;string.h;sys/socket.h H5_HAVE_SYS_SOCKET_H:INTERNAL= H5_HAVE_SYS_SYSINFO_H:INTERNAL= //Have includes io.h;setjmp.h;stddef.h;stdint.h;string.h;sys/stat.h;sys/time.h H5_HAVE_SYS_TIME_H:INTERNAL= //Have include io.h;setjmp.h;stddef.h;stdint.h;string.h;sys/stat.h;time.h H5_HAVE_TIME_H:INTERNAL=1 //Have includes io.h;setjmp.h;stddef.h;stdint.h;string.h;sys/stat.h;time.h;sys/timeb.h;sys/types.h;unistd.h H5_HAVE_UNISTD_H:INTERNAL= //Have function vasprintf H5_HAVE_VASPRINTF:INTERNAL= //Have function vsnprintf H5_HAVE_VSNPRINTF:INTERNAL=1 //Have function waitpid H5_HAVE_WAITPID:INTERNAL= //Other test H5_INLINE_TEST___inline:INTERNAL=1 //Other test H5_INLINE_TEST___inline__:INTERNAL= //Other test H5_INLINE_TEST_inline:INTERNAL= //checking IF accurately converting from integers to long double H5_INTEGER_TO_LDOUBLE_ACCURATE:INTERNAL=1 //checking IF converting from long double to integers is accurate H5_LDOUBLE_TO_INTEGER_ACCURATE:INTERNAL=1 //Checking IF converting from long double to integers works H5_LDOUBLE_TO_INTEGER_WORKS:INTERNAL=1 //Result of TRY_COMPILE H5_LDOUBLE_TO_INTEGER_WORKS_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_LDOUBLE_TO_INTEGER_WORKS_RUN:INTERNAL=0 //Checking IF correctly converting long double to (unsigned) long // long values H5_LDOUBLE_TO_LLONG_ACCURATE:INTERNAL=1 //Result of TRY_COMPILE H5_LDOUBLE_TO_LLONG_ACCURATE_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_LDOUBLE_TO_LLONG_ACCURATE_RUN:INTERNAL=0 //Checking IF correctly converting long double to unsigned int // values H5_LDOUBLE_TO_UINT_ACCURATE:INTERNAL=1 //Result of TRY_COMPILE H5_LDOUBLE_TO_UINT_ACCURATE_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_LDOUBLE_TO_UINT_ACCURATE_RUN:INTERNAL=0 //Use Legacy Names for Libraries and Programs H5_LEGACY_NAMING:INTERNAL=ON //Checking IF compiling long long to floating-point typecasts work H5_LLONG_TO_FP_CAST_WORKS:INTERNAL=1 //Checking IF correctly converting (unsigned) long long to long // double values H5_LLONG_TO_LDOUBLE_CORRECT:INTERNAL=1 //Result of TRY_COMPILE H5_LLONG_TO_LDOUBLE_CORRECT_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_LLONG_TO_LDOUBLE_CORRECT_RUN:INTERNAL=0 //Checking IF alignment restrictions are strictly enforced H5_NO_ALIGNMENT_RESTRICTIONS:INTERNAL=1 //Result of TRY_COMPILE H5_NO_ALIGNMENT_RESTRICTIONS_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_NO_ALIGNMENT_RESTRICTIONS_RUN:INTERNAL=0 //Width for printf for type `long long' or `__int64', us. `ll H5_PRINTF_LL_WIDTH:INTERNAL="ll" //CHECK_TYPE_SIZE: sizeof(char) H5_SIZEOF_CHAR:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(double) H5_SIZEOF_DOUBLE:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(float) H5_SIZEOF_FLOAT:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(int) H5_SIZEOF_INT:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(int16_t) H5_SIZEOF_INT16_T:INTERNAL=2 //CHECK_TYPE_SIZE: sizeof(int32_t) H5_SIZEOF_INT32_T:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(int64_t) H5_SIZEOF_INT64_T:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(int8_t) H5_SIZEOF_INT8_T:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(int_fast16_t) H5_SIZEOF_INT_FAST16_T:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(int_fast32_t) H5_SIZEOF_INT_FAST32_T:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(int_fast64_t) H5_SIZEOF_INT_FAST64_T:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(int_fast8_t) H5_SIZEOF_INT_FAST8_T:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(int_least16_t) H5_SIZEOF_INT_LEAST16_T:INTERNAL=2 //CHECK_TYPE_SIZE: sizeof(int_least32_t) H5_SIZEOF_INT_LEAST32_T:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(int_least64_t) H5_SIZEOF_INT_LEAST64_T:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(int_least8_t) H5_SIZEOF_INT_LEAST8_T:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(long) H5_SIZEOF_LONG:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(long double) H5_SIZEOF_LONG_DOUBLE:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(long long) H5_SIZEOF_LONG_LONG:INTERNAL=8 //SizeOf for off64_t H5_SIZEOF_OFF64_T:INTERNAL=0 //CHECK_TYPE_SIZE: sizeof(off_t) H5_SIZEOF_OFF_T:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(short) H5_SIZEOF_SHORT:INTERNAL=2 //CHECK_TYPE_SIZE: sizeof(size_t) H5_SIZEOF_SIZE_T:INTERNAL=4 //SizeOf for ssize_t H5_SIZEOF_SSIZE_T:INTERNAL=0 //CHECK_TYPE_SIZE: sizeof(uint16_t) H5_SIZEOF_UINT16_T:INTERNAL=2 //CHECK_TYPE_SIZE: sizeof(uint32_t) H5_SIZEOF_UINT32_T:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(uint64_t) H5_SIZEOF_UINT64_T:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(uint8_t) H5_SIZEOF_UINT8_T:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(uint_fast16_t) H5_SIZEOF_UINT_FAST16_T:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(uint_fast32_t) H5_SIZEOF_UINT_FAST32_T:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(uint_fast64_t) H5_SIZEOF_UINT_FAST64_T:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(uint_fast8_t) H5_SIZEOF_UINT_FAST8_T:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(uint_least16_t) H5_SIZEOF_UINT_LEAST16_T:INTERNAL=2 //CHECK_TYPE_SIZE: sizeof(uint_least32_t) H5_SIZEOF_UINT_LEAST32_T:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(uint_least64_t) H5_SIZEOF_UINT_LEAST64_T:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(uint_least8_t) H5_SIZEOF_UINT_LEAST8_T:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(unsigned) H5_SIZEOF_UNSIGNED:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(__int64) H5_SIZEOF___INT64:INTERNAL=8 //Checking IF compiling unsigned long long to floating-point typecasts // work H5_ULLONG_TO_FP_CAST_WORKS:INTERNAL=1 //Checking IF converting unsigned long long to long double with // precision H5_ULLONG_TO_LDOUBLE_PRECISION:INTERNAL= //Result of TRY_COMPILE H5_ULLONG_TO_LDOUBLE_PRECISION_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_ULLONG_TO_LDOUBLE_PRECISION_RUN:INTERNAL=1 //Checking IF accurately converting unsigned long to float values H5_ULONG_TO_FLOAT_ACCURATE:INTERNAL=1 //Result of TRY_COMPILE H5_ULONG_TO_FLOAT_ACCURATE_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_ULONG_TO_FLOAT_ACCURATE_RUN:INTERNAL=0 //Checking IF accurately converting unsigned long long to floating-point // values H5_ULONG_TO_FP_BOTTOM_BIT_ACCURATE:INTERNAL= //Result of TRY_COMPILE H5_ULONG_TO_FP_BOTTOM_BIT_ACCURATE_COMPILE:INTERNAL=TRUE //Result of TRY_RUN H5_ULONG_TO_FP_BOTTOM_BIT_ACCURATE_RUN:INTERNAL=1 //Stored GUID H5detect_GUID_CMAKE:INTERNAL=0141859B-4654-437B-B823-61877F6A38C0 //Stored GUID H5make_libsettings_GUID_CMAKE:INTERNAL=3754CD1F-110D-4D1B-B988-0F747471FCC8 //Have symbol alloca HAVE_ALLOCA:INTERNAL= //Have includes ;alloca.h HAVE_ALLOCA_H:INTERNAL= //Have includes stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ansidecl.h HAVE_ANSIDECL_H:INTERNAL= //Have includes stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;arpa/inet.h HAVE_ARPA_INET_H:INTERNAL= //Have includes stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;arpa/nameser.h HAVE_ARPA_NAMESER_H:INTERNAL= //Have include assert.h HAVE_ASSERT_H:INTERNAL=1 //Result of TRY_COMPILE HAVE_CMAKE_REQUIRE_LARGE_FILE_SUPPORT:INTERNAL=FALSE //Result of TRY_COMPILE HAVE_CMAKE_SIZEOF_UNSIGNED_SHORT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_CMAKE_WORDS_BIGENDIAN:INTERNAL=TRUE //Have include stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ctype.h HAVE_CTYPE_H:INTERNAL=1 //Have includes stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ctype.h;dirent.h HAVE_DIRENT_H:INTERNAL= //Have includes dlfcn.h HAVE_DLFCN_H:INTERNAL= //Have library HAVE_DLOPEN:INTERNAL= //Have includes stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ctype.h;dl.h HAVE_DL_H:INTERNAL= //Have include stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h HAVE_ERRNO_H:INTERNAL=1 //Have include fcntl.h HAVE_FCNTL_H:INTERNAL=1 //Have include fenv.h HAVE_FENV_H:INTERNAL= //Have symbol finite HAVE_FINITE:INTERNAL= //Have include stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ctype.h;float.h HAVE_FLOAT_H:INTERNAL=1 //Have function floor HAVE_FLOOR:INTERNAL=1 //Have symbol fpclass HAVE_FPCLASS:INTERNAL= //Have symbol fprintf HAVE_FPRINTF:INTERNAL=1 //Have symbol fp_class HAVE_FP_CLASS:INTERNAL= //Have includes stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ctype.h;float.h;fp_class.h HAVE_FP_CLASS_H:INTERNAL= //Have symbol ftime HAVE_FTIME:INTERNAL=1 //NetCDF test HAVE_FTRUNCATE:INTERNAL= //Result of TRY_COMPILE HAVE_GETADDRINFO_COMPILED:INTERNAL=FALSE //Have function getopt HAVE_GETOPT:INTERNAL= //Have symbol gettimeofday HAVE_GETTIMEOFDAY:INTERNAL= //Result of TRY_COMPILE HAVE_H5_SIZEOF_CHAR:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_DOUBLE:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_FLOAT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_INT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_INT16_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_INT32_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_INT64_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_INT8_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_INT_FAST16_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_INT_FAST32_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_INT_FAST64_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_INT_FAST8_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_INT_LEAST16_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_INT_LEAST32_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_INT_LEAST64_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_INT_LEAST8_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_LONG:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_LONG_DOUBLE:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_LONG_LONG:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_OFF64_T:INTERNAL=FALSE //Result of TRY_COMPILE HAVE_H5_SIZEOF_OFF_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_SHORT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_SIZE_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_SSIZE_T:INTERNAL=FALSE //Result of TRY_COMPILE HAVE_H5_SIZEOF_UINT16_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_UINT32_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_UINT64_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_UINT8_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_UINT_FAST16_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_UINT_FAST32_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_UINT_FAST64_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_UINT_FAST8_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_UINT_LEAST16_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_UINT_LEAST32_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_UINT_LEAST64_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_UINT_LEAST8_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF_UNSIGNED:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_H5_SIZEOF___INT64:INTERNAL=TRUE //Have includes ieeefp.h HAVE_IEEEFP_H:INTERNAL= //Have includes inttypes.h HAVE_INTTYPES_H:INTERNAL= //Have function isascii HAVE_ISASCII:INTERNAL= //Result of TRY_COMPILE HAVE_KWSYS_SIZEOF_CHAR:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_KWSYS_SIZEOF_INT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_KWSYS_SIZEOF_LONG:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_KWSYS_SIZEOF_LONG_LONG:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_KWSYS_SIZEOF_SHORT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_KWSYS_SIZEOF___INT64:INTERNAL=TRUE //Have library dl; HAVE_LIBDL:INTERNAL= //Have include limits.h HAVE_LIMITS_H:INTERNAL=1 //Have symbol localtime HAVE_LOCALTIME:INTERNAL=1 //Have include malloc.h HAVE_MALLOC_H:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ctype.h;float.h;math.h HAVE_MATH_H:INTERNAL=1 //Have function memmove HAVE_MEMMOVE:INTERNAL=1 //Have include memory.h HAVE_MEMORY_H:INTERNAL=1 //Have function memset HAVE_MEMSET:INTERNAL=1 //Have function mmap HAVE_MMAP:INTERNAL= //Have includes stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ctype.h;float.h;math.h;nan.h HAVE_NAN_H:INTERNAL= //Have includes stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ctype.h;float.h;math.h;ndir.h HAVE_NDIR_H:INTERNAL= //Have includes stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;netdb.h HAVE_NETDB_H:INTERNAL= //Have includes stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;netinet/in.h HAVE_NETINET_IN_H:INTERNAL= //Have function pow HAVE_POW:INTERNAL=1 //Have symbol printf HAVE_PRINTF:INTERNAL=1 //Have includes stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ctype.h;float.h;math.h;pthread.h HAVE_PTHREAD_H:INTERNAL= //Have includes stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ctype.h;float.h;math.h;resolv.h HAVE_RESOLV_H:INTERNAL= //Have library dld; HAVE_SHLLOAD:INTERNAL= //Have symbol signal HAVE_SIGNAL:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h HAVE_SIGNAL_H:INTERNAL=1 //Result of TRY_COMPILE HAVE_SIZEOF_DOUBLE:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_SIZEOF_FLOAT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_SIZEOF_INT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_SIZEOF_LONG:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_SIZEOF_OFF_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_SIZEOF_PTRDIFF_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_SIZEOF_SHORT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_SIZEOF_SIZE_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_SIZEOF_SSIZE_T:INTERNAL=FALSE //Result of TRY_COMPILE HAVE_SIZEOF_UCHAR:INTERNAL=FALSE //Result of TRY_COMPILE HAVE_SIZEOF__BOOL:INTERNAL=FALSE //Have symbol snprintf HAVE_SNPRINTF:INTERNAL= //Result of TRY_COMPILE HAVE_SOCKLEN_T_COMPILED:INTERNAL=FALSE //Have symbol sprintf HAVE_SPRINTF:INTERNAL=1 //Have function sqrt HAVE_SQRT:INTERNAL=1 //Have symbol sscanf HAVE_SSCANF:INTERNAL=1 //Have symbol stat HAVE_STAT:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ctype.h;float.h;math.h;stdarg.h HAVE_STDARG_H:INTERNAL=1 //Have includes stdlib.h;sys/types.h;sys/stat.h;fcntl.h;stdio.h;string.h;stddef.h;stdint.h;stdbool.h HAVE_STDBOOL_H:INTERNAL= //Have include stddef.h HAVE_STDDEF_H:INTERNAL=1 //Have include stdint.h HAVE_STDINT_H:INTERNAL=1 //Have include stdlib.h;sys/types.h;sys/stat.h;fcntl.h;stdio.h HAVE_STDIO_H:INTERNAL=1 //Have include stdlib.h HAVE_STDLIB_H:INTERNAL=1 //Have function strcasecmp HAVE_STRCASECMP:INTERNAL= //Have function strchr HAVE_STRCHR:INTERNAL=1 //Have symbol strdup HAVE_STRDUP:INTERNAL=1 //Have symbol strerror HAVE_STRERROR:INTERNAL=1 //Have symbol strftime HAVE_STRFTIME:INTERNAL=1 //Have includes strings.h HAVE_STRINGS_H:INTERNAL= //Have include string.h HAVE_STRING_H:INTERNAL=1 //Have symbol strndup HAVE_STRNDUP:INTERNAL= //Have function strrchr HAVE_STRRCHR:INTERNAL=1 //Have function strstr HAVE_STRSTR:INTERNAL=1 //Have function strtol HAVE_STRTOL:INTERNAL=1 //Have function strtoul HAVE_STRTOUL:INTERNAL=1 //NetCDF test HAVE_ST_BLKSIZE:INTERNAL= //Result of TRY_COMPILE HAVE_SYS_DIR_H_COMPILED:INTERNAL=FALSE //Have includes stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ctype.h;float.h;math.h;stdarg.h;sys/mman.h HAVE_SYS_MMAN_H:INTERNAL= //Result of TRY_COMPILE HAVE_SYS_NDIR_H_COMPILED:INTERNAL=FALSE //Have includes stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;sys/select.h HAVE_SYS_SELECT_H:INTERNAL= //Have includes stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;sys/socket.h HAVE_SYS_SOCKET_H:INTERNAL= //Have include sys/stat.h HAVE_SYS_STAT_H:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h;signal.h;errno.h;ctype.h;float.h;math.h;stdarg.h;sys/timeb.h HAVE_SYS_TIMEB_H:INTERNAL=1 //Have includes sys/time.h HAVE_SYS_TIME_H:INTERNAL= //Have include sys/types.h HAVE_SYS_TYPES_H:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;fcntl.h;malloc.h;memory.h;limits.h;stdint.h;stdlib.h;string.h;sys/stat.h;time.h HAVE_TIME_H:INTERNAL=1 //Have includes unistd.h HAVE_UNISTD_H:INTERNAL= //Result of TRY_COMPILE HAVE_VA_COPY_COMPILED:INTERNAL=FALSE //Have symbol vfprintf HAVE_VFPRINTF:INTERNAL=1 //Have symbol vsnprintf HAVE_VSNPRINTF:INTERNAL=1 //Have symbol vsprintf HAVE_VSPRINTF:INTERNAL=1 //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_INT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_INT16_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_INT32_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_INT64_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_LONG:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_LONG_LONG:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_SHORT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_UINT16_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_UINT32_T:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_U_INT16_T:INTERNAL=FALSE //Result of TRY_COMPILE HAVE_VTKOGGTHEORA_U_INT32_T:INTERNAL=FALSE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_CHAR:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_DOUBLE:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_FLOAT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_INT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_LONG:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_LONG_LONG:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_SHORT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF___INT64:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_UINTPTR_T:INTERNAL=TRUE //Have include windows.h HAVE_WINDOWS_H:INTERNAL=1 //Have symbol _stat HAVE__STAT:INTERNAL=1 //Result of TRY_COMPILE HAVE___VA_COPY_COMPILED:INTERNAL=FALSE //Allow External Library Building HDF5_ALLOW_EXTERNAL_SUPPORT:INTERNAL=OFF //Build HDF5 C++ Library HDF5_BUILD_CPP_LIB:INTERNAL=OFF //Build HIGH Level HDF5 Library HDF5_BUILD_HL_LIB:INTERNAL=ON //Disable compiler warnings HDF5_DISABLE_COMPILER_WARNINGS:INTERNAL=ON //Enable the function stack tracing (for developer debugging). HDF5_ENABLE_CODESTACK:INTERNAL=OFF //Enable code coverage for Libraries and Programs HDF5_ENABLE_COVERAGE:INTERNAL=OFF //Enable deprecated public API symbols HDF5_ENABLE_DEPRECATED_SYMBOLS:INTERNAL=ON //Enable GPFS hints for the MPI/POSIX file driver HDF5_ENABLE_GPFS:INTERNAL=OFF //Enable datasets larger than memory HDF5_ENABLE_HSIZET:INTERNAL=ON //Enable support for large (64-bit) files on Linux. HDF5_ENABLE_LARGE_FILE:INTERNAL=ON //Enable parallel build (requires MPI) HDF5_ENABLE_PARALLEL:INTERNAL=OFF //Use SZip Filter HDF5_ENABLE_SZIP_SUPPORT:INTERNAL=OFF //Enable Threadsafety HDF5_ENABLE_THREADSAFE:INTERNAL=OFF //Enable API tracing capability HDF5_ENABLE_TRACE:INTERNAL=OFF //Indicate that a memory checker is used HDF5_ENABLE_USING_MEMCHECKER:INTERNAL=OFF //Enable Zlib Filters HDF5_ENABLE_Z_LIB_SUPPORT:INTERNAL=ON //Securely clear file buffers before writing to file HDF5_Enable_Clear_File_Buffers:INTERNAL=ON //Instrument The library HDF5_Enable_Instrument:INTERNAL=OFF //Used to pass variables between directories HDF5_LIBRARIES_TO_EXPORT:INTERNAL=vtkhdf5;vtkhdf5_hl //Enable metadata trace file collection HDF5_METADATA_TRACE_FILE:INTERNAL=OFF //CPACK - include external libraries HDF5_PACKAGE_EXTLIBS:INTERNAL=OFF //Result of TRY_COMPILE HDF5_PRINTF_LL_TEST_COMPILE:INTERNAL=TRUE //Result of TRY_RUN HDF5_PRINTF_LL_TEST_RUN:INTERNAL=0 //Whether to perform strict file format checks HDF5_STRICT_FORMAT_CHECKS:INTERNAL=OFF //Use the HDF5 1.6.x API by default HDF5_USE_16_API_DEFAULT:INTERNAL=OFF //Use the FLETCHER32 Filter HDF5_USE_FILTER_FLETCHER32:INTERNAL=ON //Use the NBIT Filter HDF5_USE_FILTER_NBIT:INTERNAL=ON //Use the SCALEOFFSET Filter HDF5_USE_FILTER_SCALEOFFSET:INTERNAL=ON //Use the SHUFFLE Filter HDF5_USE_FILTER_SHUFFLE:INTERNAL=ON //Use the PACKED BITS feature in h5dump HDF5_USE_H5DUMP_PACKED_BITS:INTERNAL=ON //IF data accuracy is guaranteed during data conversions HDF5_WANT_DATA_ACCURACY:INTERNAL=ON //exception handling functions is checked during data conversions HDF5_WANT_DCONV_EXCEPTION:INTERNAL=ON //Result of TRY_COMPILE INLINE_TEST___inline:INTERNAL=TRUE //Result of TRY_COMPILE INLINE_TEST___inline__:INTERNAL=FALSE //Result of TRY_COMPILE INLINE_TEST_inline:INTERNAL=FALSE //Stored GUID INSTALL_GUID_CMAKE:INTERNAL=2A9DD151-452E-47E5-B5B5-B80DDA77552B //ADVANCED property for variable: JAVA_AWT_INCLUDE_PATH JAVA_AWT_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: JAVA_AWT_LIBRARY JAVA_AWT_LIBRARY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: JAVA_INCLUDE_PATH JAVA_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: JAVA_INCLUDE_PATH2 JAVA_INCLUDE_PATH2-ADVANCED:INTERNAL=1 //ADVANCED property for variable: JAVA_JVM_LIBRARY JAVA_JVM_LIBRARY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Java_JAR_EXECUTABLE Java_JAR_EXECUTABLE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Java_JAVAC_EXECUTABLE Java_JAVAC_EXECUTABLE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Java_JAVADOC_EXECUTABLE Java_JAVADOC_EXECUTABLE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Java_JAVAH_EXECUTABLE Java_JAVAH_EXECUTABLE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Java_JAVA_EXECUTABLE Java_JAVA_EXECUTABLE-ADVANCED:INTERNAL=1 //Result of TRY_RUN KWSYS_CHAR_IS_SIGNED:INTERNAL=0 //Result of TRY_COMPILE KWSYS_CHAR_IS_SIGNED_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_ARGUMENT_DEPENDENT_LOOKUP_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_ATOLL_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_CXX_HAS_ATOL_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_CSTDDEF_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_CSTDIO_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_ENVIRON_IN_STDLIB_H_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_FULL_SPECIALIZATION_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_LONG_LONG_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_MEMBER_TEMPLATES_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_NULL_TEMPLATE_ARGS_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_CXX_HAS_RLIMIT64_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_CXX_HAS_SETENV_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_CXX_HAS_UNSETENV_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_CXX_HAS_UTIMENSAT_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_CXX_HAS_UTIMES_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_CXX_HAS__ATOI64_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS___INT64_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_SAME_LONG_AND___INT64_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_CXX_SAME_LONG_LONG_AND___INT64_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_C_HAS_PTRDIFF_T_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_C_HAS_SSIZE_T_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_C_TYPE_MACROS_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_IOS_HAVE_BINARY_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_IOS_HAVE_STD_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_IOS_USE_ANSI_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_IOS_USE_SSTREAM_COMPILED:INTERNAL=TRUE //Checking for Large File Support failed to compile. KWSYS_LFS_WORKS:INTERNAL=-1 //Result of TRY_COMPILE KWSYS_LFS_WORKS_COMPILED:INTERNAL=FALSE //CHECK_TYPE_SIZE: sizeof(char) KWSYS_SIZEOF_CHAR:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(int) KWSYS_SIZEOF_INT:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(long) KWSYS_SIZEOF_LONG:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(long long) KWSYS_SIZEOF_LONG_LONG:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(short) KWSYS_SIZEOF_SHORT:INTERNAL=2 //CHECK_TYPE_SIZE: sizeof(__int64) KWSYS_SIZEOF___INT64:INTERNAL=8 //Result of TRY_COMPILE KWSYS_STL_HAS_ALLOCATOR_MAX_SIZE_ARGUMENT_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_STL_HAS_ALLOCATOR_OBJECTS_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_HAS_ALLOCATOR_REBIND_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_HAS_ALLOCATOR_TEMPLATE_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_HAS_ITERATOR_TRAITS_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_HAS_WSTRING_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_HAVE_STD_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_STRING_HAVE_NEQ_CHAR_COMPILED:INTERNAL=TRUE //Have includes sys/types.h;ifaddrs.h KWSYS_SYS_HAS_IFADDRS_H:INTERNAL= //Have symbol GetProcessMemoryInfo KWSYS_SYS_HAS_PSAPI:INTERNAL=1 //ADVANCED property for variable: Module_AutobahnPython Module_AutobahnPython-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_Twisted Module_Twisted-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_ZopeInterface Module_ZopeInterface-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkAcceleratorsDax Module_vtkAcceleratorsDax-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkAcceleratorsPiston Module_vtkAcceleratorsPiston-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkChartsCore Module_vtkChartsCore-ADVANCED:INTERNAL=1 //Request building vtkChartsCore Module_vtkChartsCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonColor Module_vtkCommonColor-ADVANCED:INTERNAL=1 //Request building vtkCommonColor Module_vtkCommonColor:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonComputationalGeometry Module_vtkCommonComputationalGeometry-ADVANCED:INTERNAL=1 //Request building vtkCommonComputationalGeometry Module_vtkCommonComputationalGeometry:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonCore Module_vtkCommonCore-ADVANCED:INTERNAL=1 //Request building vtkCommonCore Module_vtkCommonCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonDataModel Module_vtkCommonDataModel-ADVANCED:INTERNAL=1 //Request building vtkCommonDataModel Module_vtkCommonDataModel:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonExecutionModel Module_vtkCommonExecutionModel-ADVANCED:INTERNAL=1 //Request building vtkCommonExecutionModel Module_vtkCommonExecutionModel:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonMath Module_vtkCommonMath-ADVANCED:INTERNAL=1 //Request building vtkCommonMath Module_vtkCommonMath:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonMisc Module_vtkCommonMisc-ADVANCED:INTERNAL=1 //Request building vtkCommonMisc Module_vtkCommonMisc:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonSystem Module_vtkCommonSystem-ADVANCED:INTERNAL=1 //Request building vtkCommonSystem Module_vtkCommonSystem:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonTransforms Module_vtkCommonTransforms-ADVANCED:INTERNAL=1 //Request building vtkCommonTransforms Module_vtkCommonTransforms:INTERNAL=OFF //ADVANCED property for variable: Module_vtkDICOMParser Module_vtkDICOMParser-ADVANCED:INTERNAL=1 //Request building vtkDICOMParser Module_vtkDICOMParser:INTERNAL=OFF //ADVANCED property for variable: Module_vtkDomainsChemistry Module_vtkDomainsChemistry-ADVANCED:INTERNAL=1 //Request building vtkDomainsChemistry Module_vtkDomainsChemistry:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersAMR Module_vtkFiltersAMR-ADVANCED:INTERNAL=1 //Request building vtkFiltersAMR Module_vtkFiltersAMR:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersCore Module_vtkFiltersCore-ADVANCED:INTERNAL=1 //Request building vtkFiltersCore Module_vtkFiltersCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersExtraction Module_vtkFiltersExtraction-ADVANCED:INTERNAL=1 //Request building vtkFiltersExtraction Module_vtkFiltersExtraction:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersFlowPaths Module_vtkFiltersFlowPaths-ADVANCED:INTERNAL=1 //Request building vtkFiltersFlowPaths Module_vtkFiltersFlowPaths:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersGeneral Module_vtkFiltersGeneral-ADVANCED:INTERNAL=1 //Request building vtkFiltersGeneral Module_vtkFiltersGeneral:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersGeneric Module_vtkFiltersGeneric-ADVANCED:INTERNAL=1 //Request building vtkFiltersGeneric Module_vtkFiltersGeneric:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersGeometry Module_vtkFiltersGeometry-ADVANCED:INTERNAL=1 //Request building vtkFiltersGeometry Module_vtkFiltersGeometry:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersHybrid Module_vtkFiltersHybrid-ADVANCED:INTERNAL=1 //Request building vtkFiltersHybrid Module_vtkFiltersHybrid:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersHyperTree Module_vtkFiltersHyperTree-ADVANCED:INTERNAL=1 //Request building vtkFiltersHyperTree Module_vtkFiltersHyperTree:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersImaging Module_vtkFiltersImaging-ADVANCED:INTERNAL=1 //Request building vtkFiltersImaging Module_vtkFiltersImaging:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersModeling Module_vtkFiltersModeling-ADVANCED:INTERNAL=1 //Request building vtkFiltersModeling Module_vtkFiltersModeling:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersParallel Module_vtkFiltersParallel-ADVANCED:INTERNAL=1 //Request building vtkFiltersParallel Module_vtkFiltersParallel:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersParallelFlowPaths Module_vtkFiltersParallelFlowPaths-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersParallelGeometry Module_vtkFiltersParallelGeometry-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersParallelImaging Module_vtkFiltersParallelImaging-ADVANCED:INTERNAL=1 //Request building vtkFiltersParallelImaging Module_vtkFiltersParallelImaging:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersParallelMPI Module_vtkFiltersParallelMPI-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersParallelStatistics Module_vtkFiltersParallelStatistics-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersProgrammable Module_vtkFiltersProgrammable-ADVANCED:INTERNAL=1 //Request building vtkFiltersProgrammable Module_vtkFiltersProgrammable:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersReebGraph Module_vtkFiltersReebGraph-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersSMP Module_vtkFiltersSMP-ADVANCED:INTERNAL=1 //Request building vtkFiltersSMP Module_vtkFiltersSMP:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersSelection Module_vtkFiltersSelection-ADVANCED:INTERNAL=1 //Request building vtkFiltersSelection Module_vtkFiltersSelection:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersSources Module_vtkFiltersSources-ADVANCED:INTERNAL=1 //Request building vtkFiltersSources Module_vtkFiltersSources:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersStatistics Module_vtkFiltersStatistics-ADVANCED:INTERNAL=1 //Request building vtkFiltersStatistics Module_vtkFiltersStatistics:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersStatisticsGnuR Module_vtkFiltersStatisticsGnuR-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersTexture Module_vtkFiltersTexture-ADVANCED:INTERNAL=1 //Request building vtkFiltersTexture Module_vtkFiltersTexture:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersVerdict Module_vtkFiltersVerdict-ADVANCED:INTERNAL=1 //Request building vtkFiltersVerdict Module_vtkFiltersVerdict:INTERNAL=OFF //ADVANCED property for variable: Module_vtkGUISupportMFC Module_vtkGUISupportMFC-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkGUISupportQt Module_vtkGUISupportQt-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkGUISupportQtOpenGL Module_vtkGUISupportQtOpenGL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkGUISupportQtSQL Module_vtkGUISupportQtSQL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkGUISupportQtWebkit Module_vtkGUISupportQtWebkit-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkGeovisCore Module_vtkGeovisCore-ADVANCED:INTERNAL=1 //Request building vtkGeovisCore Module_vtkGeovisCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOAMR Module_vtkIOAMR-ADVANCED:INTERNAL=1 //Request building vtkIOAMR Module_vtkIOAMR:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOCore Module_vtkIOCore-ADVANCED:INTERNAL=1 //Request building vtkIOCore Module_vtkIOCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOEnSight Module_vtkIOEnSight-ADVANCED:INTERNAL=1 //Request building vtkIOEnSight Module_vtkIOEnSight:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOExodus Module_vtkIOExodus-ADVANCED:INTERNAL=1 //Request building vtkIOExodus Module_vtkIOExodus:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOExport Module_vtkIOExport-ADVANCED:INTERNAL=1 //Request building vtkIOExport Module_vtkIOExport:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOFFMPEG Module_vtkIOFFMPEG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOGDAL Module_vtkIOGDAL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOGeoJSON Module_vtkIOGeoJSON-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOGeometry Module_vtkIOGeometry-ADVANCED:INTERNAL=1 //Request building vtkIOGeometry Module_vtkIOGeometry:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOImage Module_vtkIOImage-ADVANCED:INTERNAL=1 //Request building vtkIOImage Module_vtkIOImage:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOImport Module_vtkIOImport-ADVANCED:INTERNAL=1 //Request building vtkIOImport Module_vtkIOImport:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOInfovis Module_vtkIOInfovis-ADVANCED:INTERNAL=1 //Request building vtkIOInfovis Module_vtkIOInfovis:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOLSDyna Module_vtkIOLSDyna-ADVANCED:INTERNAL=1 //Request building vtkIOLSDyna Module_vtkIOLSDyna:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOLegacy Module_vtkIOLegacy-ADVANCED:INTERNAL=1 //Request building vtkIOLegacy Module_vtkIOLegacy:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOMINC Module_vtkIOMINC-ADVANCED:INTERNAL=1 //Request building vtkIOMINC Module_vtkIOMINC:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOMPIImage Module_vtkIOMPIImage-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOMPIParallel Module_vtkIOMPIParallel-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOMovie Module_vtkIOMovie-ADVANCED:INTERNAL=1 //Request building vtkIOMovie Module_vtkIOMovie:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOMySQL Module_vtkIOMySQL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIONetCDF Module_vtkIONetCDF-ADVANCED:INTERNAL=1 //Request building vtkIONetCDF Module_vtkIONetCDF:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOODBC Module_vtkIOODBC-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOPLY Module_vtkIOPLY-ADVANCED:INTERNAL=1 //Request building vtkIOPLY Module_vtkIOPLY:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOParallel Module_vtkIOParallel-ADVANCED:INTERNAL=1 //Request building vtkIOParallel Module_vtkIOParallel:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOParallelExodus Module_vtkIOParallelExodus-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOParallelLSDyna Module_vtkIOParallelLSDyna-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOParallelNetCDF Module_vtkIOParallelNetCDF-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOPostgreSQL Module_vtkIOPostgreSQL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOSQL Module_vtkIOSQL-ADVANCED:INTERNAL=1 //Request building vtkIOSQL Module_vtkIOSQL:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOVPIC Module_vtkIOVPIC-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOVideo Module_vtkIOVideo-ADVANCED:INTERNAL=1 //Request building vtkIOVideo Module_vtkIOVideo:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOXML Module_vtkIOXML-ADVANCED:INTERNAL=1 //Request building vtkIOXML Module_vtkIOXML:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOXMLParser Module_vtkIOXMLParser-ADVANCED:INTERNAL=1 //Request building vtkIOXMLParser Module_vtkIOXMLParser:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOXdmf2 Module_vtkIOXdmf2-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkImagingColor Module_vtkImagingColor-ADVANCED:INTERNAL=1 //Request building vtkImagingColor Module_vtkImagingColor:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingCore Module_vtkImagingCore-ADVANCED:INTERNAL=1 //Request building vtkImagingCore Module_vtkImagingCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingFourier Module_vtkImagingFourier-ADVANCED:INTERNAL=1 //Request building vtkImagingFourier Module_vtkImagingFourier:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingGeneral Module_vtkImagingGeneral-ADVANCED:INTERNAL=1 //Request building vtkImagingGeneral Module_vtkImagingGeneral:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingHybrid Module_vtkImagingHybrid-ADVANCED:INTERNAL=1 //Request building vtkImagingHybrid Module_vtkImagingHybrid:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingMath Module_vtkImagingMath-ADVANCED:INTERNAL=1 //Request building vtkImagingMath Module_vtkImagingMath:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingMorphological Module_vtkImagingMorphological-ADVANCED:INTERNAL=1 //Request building vtkImagingMorphological Module_vtkImagingMorphological:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingSources Module_vtkImagingSources-ADVANCED:INTERNAL=1 //Request building vtkImagingSources Module_vtkImagingSources:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingStatistics Module_vtkImagingStatistics-ADVANCED:INTERNAL=1 //Request building vtkImagingStatistics Module_vtkImagingStatistics:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingStencil Module_vtkImagingStencil-ADVANCED:INTERNAL=1 //Request building vtkImagingStencil Module_vtkImagingStencil:INTERNAL=OFF //ADVANCED property for variable: Module_vtkInfovisBoost Module_vtkInfovisBoost-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkInfovisBoostGraphAlgorithms Module_vtkInfovisBoostGraphAlgorithms-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkInfovisCore Module_vtkInfovisCore-ADVANCED:INTERNAL=1 //Request building vtkInfovisCore Module_vtkInfovisCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkInfovisLayout Module_vtkInfovisLayout-ADVANCED:INTERNAL=1 //Request building vtkInfovisLayout Module_vtkInfovisLayout:INTERNAL=OFF //ADVANCED property for variable: Module_vtkInfovisParallel Module_vtkInfovisParallel-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkInteractionImage Module_vtkInteractionImage-ADVANCED:INTERNAL=1 //Request building vtkInteractionImage Module_vtkInteractionImage:INTERNAL=OFF //ADVANCED property for variable: Module_vtkInteractionStyle Module_vtkInteractionStyle-ADVANCED:INTERNAL=1 //Request building vtkInteractionStyle Module_vtkInteractionStyle:INTERNAL=OFF //ADVANCED property for variable: Module_vtkInteractionWidgets Module_vtkInteractionWidgets-ADVANCED:INTERNAL=1 //Request building vtkInteractionWidgets Module_vtkInteractionWidgets:INTERNAL=OFF //ADVANCED property for variable: Module_vtkMetaIO Module_vtkMetaIO-ADVANCED:INTERNAL=1 //Request building vtkMetaIO Module_vtkMetaIO:INTERNAL=OFF //ADVANCED property for variable: Module_vtkParallelCore Module_vtkParallelCore-ADVANCED:INTERNAL=1 //Request building vtkParallelCore Module_vtkParallelCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkParallelMPI Module_vtkParallelMPI-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkParseOGLExt Module_vtkParseOGLExt-ADVANCED:INTERNAL=1 //Request building vtkParseOGLExt Module_vtkParseOGLExt:INTERNAL=OFF //ADVANCED property for variable: Module_vtkPython Module_vtkPython-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkPythonInterpreter Module_vtkPythonInterpreter-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingAnnotation Module_vtkRenderingAnnotation-ADVANCED:INTERNAL=1 //Request building vtkRenderingAnnotation Module_vtkRenderingAnnotation:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingContext2D Module_vtkRenderingContext2D-ADVANCED:INTERNAL=1 //Request building vtkRenderingContext2D Module_vtkRenderingContext2D:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingCore Module_vtkRenderingCore-ADVANCED:INTERNAL=1 //Request building vtkRenderingCore Module_vtkRenderingCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingFreeType Module_vtkRenderingFreeType-ADVANCED:INTERNAL=1 //Request building vtkRenderingFreeType Module_vtkRenderingFreeType:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingFreeTypeFontConfig Module_vtkRenderingFreeTypeFontConfig-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingFreeTypeOpenGL Module_vtkRenderingFreeTypeOpenGL-ADVANCED:INTERNAL=1 //Request building vtkRenderingFreeTypeOpenGL Module_vtkRenderingFreeTypeOpenGL:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingGL2PS Module_vtkRenderingGL2PS-ADVANCED:INTERNAL=1 //Request building vtkRenderingGL2PS Module_vtkRenderingGL2PS:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingImage Module_vtkRenderingImage-ADVANCED:INTERNAL=1 //Request building vtkRenderingImage Module_vtkRenderingImage:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingLIC Module_vtkRenderingLIC-ADVANCED:INTERNAL=1 //Request building vtkRenderingLIC Module_vtkRenderingLIC:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingLOD Module_vtkRenderingLOD-ADVANCED:INTERNAL=1 //Request building vtkRenderingLOD Module_vtkRenderingLOD:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingLabel Module_vtkRenderingLabel-ADVANCED:INTERNAL=1 //Request building vtkRenderingLabel Module_vtkRenderingLabel:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingMatplotlib Module_vtkRenderingMatplotlib-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingOpenGL Module_vtkRenderingOpenGL-ADVANCED:INTERNAL=1 //Request building vtkRenderingOpenGL Module_vtkRenderingOpenGL:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingParallel Module_vtkRenderingParallel-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingParallelLIC Module_vtkRenderingParallelLIC-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingQt Module_vtkRenderingQt-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingTk Module_vtkRenderingTk-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingVolume Module_vtkRenderingVolume-ADVANCED:INTERNAL=1 //Request building vtkRenderingVolume Module_vtkRenderingVolume:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingVolumeAMR Module_vtkRenderingVolumeAMR-ADVANCED:INTERNAL=1 //Request building vtkRenderingVolumeAMR Module_vtkRenderingVolumeAMR:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingVolumeOpenGL Module_vtkRenderingVolumeOpenGL-ADVANCED:INTERNAL=1 //Request building vtkRenderingVolumeOpenGL Module_vtkRenderingVolumeOpenGL:INTERNAL=OFF //ADVANCED property for variable: Module_vtkTclTk Module_vtkTclTk-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkTestingCore Module_vtkTestingCore-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkTestingGenericBridge Module_vtkTestingGenericBridge-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkTestingIOSQL Module_vtkTestingIOSQL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkTestingRendering Module_vtkTestingRendering-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkUtilitiesEncodeString Module_vtkUtilitiesEncodeString-ADVANCED:INTERNAL=1 //Request building vtkUtilitiesEncodeString Module_vtkUtilitiesEncodeString:INTERNAL=OFF //ADVANCED property for variable: Module_vtkUtilitiesHashSource Module_vtkUtilitiesHashSource-ADVANCED:INTERNAL=1 //Request building vtkUtilitiesHashSource Module_vtkUtilitiesHashSource:INTERNAL=OFF //ADVANCED property for variable: Module_vtkVPIC Module_vtkVPIC-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkViewsContext2D Module_vtkViewsContext2D-ADVANCED:INTERNAL=1 //Request building vtkViewsContext2D Module_vtkViewsContext2D:INTERNAL=OFF //ADVANCED property for variable: Module_vtkViewsCore Module_vtkViewsCore-ADVANCED:INTERNAL=1 //Request building vtkViewsCore Module_vtkViewsCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkViewsGeovis Module_vtkViewsGeovis-ADVANCED:INTERNAL=1 //Request building vtkViewsGeovis Module_vtkViewsGeovis:INTERNAL=OFF //ADVANCED property for variable: Module_vtkViewsInfovis Module_vtkViewsInfovis-ADVANCED:INTERNAL=1 //Request building vtkViewsInfovis Module_vtkViewsInfovis:INTERNAL=OFF //ADVANCED property for variable: Module_vtkViewsQt Module_vtkViewsQt-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWebApplications Module_vtkWebApplications-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWebCore Module_vtkWebCore-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWebGLExporter Module_vtkWebGLExporter-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWebInstall Module_vtkWebInstall-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWebJavaScript Module_vtkWebJavaScript-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWebPython Module_vtkWebPython-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWrappingJava Module_vtkWrappingJava-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWrappingPythonCore Module_vtkWrappingPythonCore-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWrappingTcl Module_vtkWrappingTcl-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWrappingTools Module_vtkWrappingTools-ADVANCED:INTERNAL=1 //Request building vtkWrappingTools Module_vtkWrappingTools:INTERNAL=OFF //ADVANCED property for variable: Module_vtkalglib Module_vtkalglib-ADVANCED:INTERNAL=1 //Request building vtkalglib Module_vtkalglib:INTERNAL=OFF //ADVANCED property for variable: Module_vtkexodusII Module_vtkexodusII-ADVANCED:INTERNAL=1 //Request building vtkexodusII Module_vtkexodusII:INTERNAL=OFF //ADVANCED property for variable: Module_vtkexpat Module_vtkexpat-ADVANCED:INTERNAL=1 //Request building vtkexpat Module_vtkexpat:INTERNAL=OFF //ADVANCED property for variable: Module_vtkfreetype Module_vtkfreetype-ADVANCED:INTERNAL=1 //Request building vtkfreetype Module_vtkfreetype:INTERNAL=OFF //ADVANCED property for variable: Module_vtkftgl Module_vtkftgl-ADVANCED:INTERNAL=1 //Request building vtkftgl Module_vtkftgl:INTERNAL=OFF //ADVANCED property for variable: Module_vtkgl2ps Module_vtkgl2ps-ADVANCED:INTERNAL=1 //Request building vtkgl2ps Module_vtkgl2ps:INTERNAL=OFF //ADVANCED property for variable: Module_vtkhdf5 Module_vtkhdf5-ADVANCED:INTERNAL=1 //Request building vtkhdf5 Module_vtkhdf5:INTERNAL=OFF //ADVANCED property for variable: Module_vtkjpeg Module_vtkjpeg-ADVANCED:INTERNAL=1 //Request building vtkjpeg Module_vtkjpeg:INTERNAL=OFF //ADVANCED property for variable: Module_vtkjsoncpp Module_vtkjsoncpp-ADVANCED:INTERNAL=1 //Request building vtkjsoncpp Module_vtkjsoncpp:INTERNAL=OFF //ADVANCED property for variable: Module_vtklibproj4 Module_vtklibproj4-ADVANCED:INTERNAL=1 //Request building vtklibproj4 Module_vtklibproj4:INTERNAL=OFF //ADVANCED property for variable: Module_vtklibxml2 Module_vtklibxml2-ADVANCED:INTERNAL=1 //Request building vtklibxml2 Module_vtklibxml2:INTERNAL=OFF //ADVANCED property for variable: Module_vtkmrmpi Module_vtkmrmpi-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtknetcdf Module_vtknetcdf-ADVANCED:INTERNAL=1 //Request building vtknetcdf Module_vtknetcdf:INTERNAL=OFF //ADVANCED property for variable: Module_vtkoggtheora Module_vtkoggtheora-ADVANCED:INTERNAL=1 //Request building vtkoggtheora Module_vtkoggtheora:INTERNAL=OFF //ADVANCED property for variable: Module_vtkpng Module_vtkpng-ADVANCED:INTERNAL=1 //Request building vtkpng Module_vtkpng:INTERNAL=OFF //ADVANCED property for variable: Module_vtksqlite Module_vtksqlite-ADVANCED:INTERNAL=1 //Request building vtksqlite Module_vtksqlite:INTERNAL=OFF //ADVANCED property for variable: Module_vtksys Module_vtksys-ADVANCED:INTERNAL=1 //Request building vtksys Module_vtksys:INTERNAL=OFF //ADVANCED property for variable: Module_vtktiff Module_vtktiff-ADVANCED:INTERNAL=1 //Request building vtktiff Module_vtktiff:INTERNAL=OFF //ADVANCED property for variable: Module_vtkverdict Module_vtkverdict-ADVANCED:INTERNAL=1 //Request building vtkverdict Module_vtkverdict:INTERNAL=OFF //ADVANCED property for variable: Module_vtkxdmf2 Module_vtkxdmf2-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkzlib Module_vtkzlib-ADVANCED:INTERNAL=1 //Request building vtkzlib Module_vtkzlib:INTERNAL=OFF //ADVANCED property for variable: NETCDF4_CHUNK_CACHE_NELEMS NETCDF4_CHUNK_CACHE_NELEMS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: NETCDF4_CHUNK_CACHE_PREEMPTION NETCDF4_CHUNK_CACHE_PREEMPTION-ADVANCED:INTERNAL=1 //ADVANCED property for variable: NETCDF4_CHUNK_CACHE_SIZE NETCDF4_CHUNK_CACHE_SIZE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: NETCDF4_DEFAULT_CHUNKS_IN_CACHE NETCDF4_DEFAULT_CHUNKS_IN_CACHE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: NETCDF4_DEFAULT_CHUNK_SIZE NETCDF4_DEFAULT_CHUNK_SIZE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: NETCDF4_MAX_DEFAULT_CACHE_SIZE NETCDF4_MAX_DEFAULT_CACHE_SIZE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: NETCDF_DISABLE_COMPILER_WARNINGS NETCDF_DISABLE_COMPILER_WARNINGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: NETCDF_ENABLE_CXX NETCDF_ENABLE_CXX-ADVANCED:INTERNAL=1 //Have library c NOT_NEED_LIBNSL:INTERNAL= //ADVANCED property for variable: OPENGL_gl_LIBRARY OPENGL_gl_LIBRARY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: OPENGL_glu_LIBRARY OPENGL_glu_LIBRARY-ADVANCED:INTERNAL=1 //Have symbol atanh PROJ_HAVE_ATANH:INTERNAL= //Have symbol csin PROJ_HAVE_COMPLEX:INTERNAL= //ADVANCED property for variable: PROJ_LIST_EXTERNAL PROJ_LIST_EXTERNAL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: PROJ_USE_GSL PROJ_USE_GSL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: PROJ_USE_PTHREADS PROJ_USE_PTHREADS-ADVANCED:INTERNAL=1 //Stored GUID SG_Filter_CMake Rules_GUID_CMAKE:INTERNAL=AD700102-73A2-44F7-8577-5B6B26DA7F29 //Stored GUID SG_Filter_H5AC_GUID_CMAKE:INTERNAL=D6E13389-0414-4370-BF06-33EF0B7527D2 //Stored GUID SG_Filter_H5A_GUID_CMAKE:INTERNAL=5CC846FD-15A3-4408-B3D5-1EA433A0DFE9 //Stored GUID SG_Filter_H5B_GUID_CMAKE:INTERNAL=8FADB5B8-ABA0-4471-A385-D8EFD5C14145 //Stored GUID SG_Filter_H5D_GUID_CMAKE:INTERNAL=96B97820-CABB-416D-83D5-8B9246CA9BC2 //Stored GUID SG_Filter_H5E_GUID_CMAKE:INTERNAL=4D2F7914-1B86-4299-AF7B-94DA6E3F9ED5 //Stored GUID SG_Filter_H5FD_GUID_CMAKE:INTERNAL=EB94408A-F41C-4B89-B53C-4E88D4AD6983 //Stored GUID SG_Filter_H5FS_GUID_CMAKE:INTERNAL=5EE6BE09-2AB1-4DB3-BE73-E25E8B0A4DCC //Stored GUID SG_Filter_H5F_GUID_CMAKE:INTERNAL=9DB38E0F-1F5C-4D99-8452-6CCEDBE8212B //Stored GUID SG_Filter_H5G_GUID_CMAKE:INTERNAL=64281485-9348-4EFE-9FD4-BBFE8916AB2D //Stored GUID SG_Filter_H5HF_GUID_CMAKE:INTERNAL=208E269B-BE41-4C70-BF8A-797CA2A57798 //Stored GUID SG_Filter_H5HG_GUID_CMAKE:INTERNAL=605000CC-5D72-4E52-B807-8FABDCE7680C //Stored GUID SG_Filter_H5HL_GUID_CMAKE:INTERNAL=8255880D-68C1-4B76-9F01-89A36EA0F134 //Stored GUID SG_Filter_H5MF_GUID_CMAKE:INTERNAL=E72BF655-BF34-4891-9478-CAA019006FDE //Stored GUID SG_Filter_H5MP_GUID_CMAKE:INTERNAL=899C9F9C-B772-41E1-856E-570BF469C6EC //Stored GUID SG_Filter_H5O_GUID_CMAKE:INTERNAL=E4754D08-DF3F-422B-82AB-D8E2A09CD5D6 //Stored GUID SG_Filter_H5P_GUID_CMAKE:INTERNAL=2F3181E6-CE53-4178-B017-F03F61F95251 //Stored GUID SG_Filter_H5SM_GUID_CMAKE:INTERNAL=79447828-615B-4D92-80A3-721EB98B3A5C //Stored GUID SG_Filter_H5S_GUID_CMAKE:INTERNAL=D5CC2FEE-7D9C-4889-9934-F05FE086BA36 //Stored GUID SG_Filter_H5T_GUID_CMAKE:INTERNAL=14A1EAC9-AF30-4019-AEF2-9BECFFC0986D //Stored GUID SG_Filter_H5Z_GUID_CMAKE:INTERNAL=BCAECDFD-8380-494C-8052-19CD386A8397 //Stored GUID SG_Filter_H5_GUID_CMAKE:INTERNAL=63874D4F-C6AC-45CA-8D8A-21048B90B64C //Stored GUID SG_Filter_Header Files_GUID_CMAKE:INTERNAL=B249F2FC-25C6-4A9E-B22F-902D7873671B //Stored GUID SG_Filter_Object Files_GUID_CMAKE:INTERNAL=9885C4FA-C07A-497C-9AB4-3AFAAE98F1C1 //Stored GUID SG_Filter_Resources_GUID_CMAKE:INTERNAL=7EFF998C-A3D0-4D54-AE11-531C92D17D97 //Stored GUID SG_Filter_Source Files_GUID_CMAKE:INTERNAL=2D782436-ACF3-4EEA-A601-D459B6AC5A7A //CHECK_TYPE_SIZE: sizeof(double) SIZEOF_DOUBLE:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(float) SIZEOF_FLOAT:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(int) SIZEOF_INT:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(long) SIZEOF_LONG:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(off_t) SIZEOF_OFF_T:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(ptrdiff_t) SIZEOF_PTRDIFF_T:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(short) SIZEOF_SHORT:INTERNAL=2 //CHECK_TYPE_SIZE: sizeof(size_t) SIZEOF_SIZE_T:INTERNAL=4 //CHECK_TYPE_SIZE: ssize_t unknown SIZEOF_SSIZE_T:INTERNAL= //CHECK_TYPE_SIZE: uchar unknown SIZEOF_UCHAR:INTERNAL= //CHECK_TYPE_SIZE: _Bool unknown SIZEOF__BOOL:INTERNAL= //Have include stdlib.h;stdarg.h;string.h;float.h STDC_HEADERS:INTERNAL=1 //Result of TRY_COMPILE SUPPORT_IP6_COMPILED:INTERNAL=FALSE //ADVANCED property for variable: VERDICT_BUILD_DOC VERDICT_BUILD_DOC-ADVANCED:INTERNAL=1 //Build the 2007 Verdict User Manual VERDICT_BUILD_DOC:INTERNAL=OFF //ADVANCED property for variable: VERDICT_ENABLE_TESTING VERDICT_ENABLE_TESTING-ADVANCED:INTERNAL=1 //Should tests of the VERDICT library be built? VERDICT_ENABLE_TESTING:INTERNAL=OFF //ADVANCED property for variable: VERDICT_MANGLE VERDICT_MANGLE-ADVANCED:INTERNAL=1 //Mangle verdict names for inclusion in a larger library? VERDICT_MANGLE:INTERNAL=OFF //A string to prepend to all verdict function names and classes. VERDICT_MANGLE_PREFIX:INTERNAL= //Stored GUID VTKData_GUID_CMAKE:INTERNAL=F7985622-0FD0-4676-8A1D-32321FF822DC //Stored GUID VTKJavaChartsCore_GUID_CMAKE:INTERNAL=544D7B44-DE01-4459-8271-47C9B4EA66C2 //Stored GUID VTKJavaClasses_GUID_CMAKE:INTERNAL=F365A3C4-97E2-421F-87D1-9B93A63BAB66 //Stored GUID VTKJavaCommonColor_GUID_CMAKE:INTERNAL=87FEEB64-97EB-4FC1-A27F-F1FEC1307791 //Stored GUID VTKJavaCommonComputationalGeometry_GUID_CMAKE:INTERNAL=27E2A225-E111-4F3A-9DB2-B1B6A344D07B //Stored GUID VTKJavaCommonCore_GUID_CMAKE:INTERNAL=BE4E3943-78BB-49C7-9465-43C8C2B81C27 //Stored GUID VTKJavaCommonDataModel_GUID_CMAKE:INTERNAL=395E4B83-3DCB-43A1-A886-A4AD5EF9CEBA //Stored GUID VTKJavaCommonExecutionModel_GUID_CMAKE:INTERNAL=F1681645-E69E-4239-A6A6-984D6FFE8148 //Stored GUID VTKJavaCommonMath_GUID_CMAKE:INTERNAL=ADEE3CD4-A143-4AE1-B99F-F613F964C675 //Stored GUID VTKJavaCommonMisc_GUID_CMAKE:INTERNAL=3DBF020B-92C4-4412-9DCF-07EF999152CA //Stored GUID VTKJavaCommonSystem_GUID_CMAKE:INTERNAL=B894F253-E14D-4C77-8B4E-724F305AE126 //Stored GUID VTKJavaCommonTransforms_GUID_CMAKE:INTERNAL=F9727FDB-C770-4733-BF4D-BFA350E1E713 //Stored GUID VTKJavaDomainsChemistry_GUID_CMAKE:INTERNAL=E6A99F4E-C4CB-473F-81B2-5E9AEE5840C5 //Stored GUID VTKJavaExecutable_GUID_CMAKE:INTERNAL=217A7DFE-B90D-4436-BF77-2DEE78976D8E //Stored GUID VTKJavaFiltersAMR_GUID_CMAKE:INTERNAL=49BA6304-E6F0-4A51-AB4F-149D1114969A //Stored GUID VTKJavaFiltersCore_GUID_CMAKE:INTERNAL=7594D28E-F405-4B44-A2DE-9615EFF863FB //Stored GUID VTKJavaFiltersExtraction_GUID_CMAKE:INTERNAL=159D2416-9676-40CB-AE72-3C9750BD03BB //Stored GUID VTKJavaFiltersFlowPaths_GUID_CMAKE:INTERNAL=51F775DB-A712-47A0-948E-9D68EAE769B9 //Stored GUID VTKJavaFiltersGeneral_GUID_CMAKE:INTERNAL=90260F34-CC5B-4DB4-9B89-DC7EC3D2E9EF //Stored GUID VTKJavaFiltersGeneric_GUID_CMAKE:INTERNAL=BCA1A89C-A52A-4696-B04F-F5AB8CC0C0B6 //Stored GUID VTKJavaFiltersGeometry_GUID_CMAKE:INTERNAL=30823FFD-B1DE-4F8F-B345-4522C7D2F9B7 //Stored GUID VTKJavaFiltersHybrid_GUID_CMAKE:INTERNAL=855EFB06-DAD0-4328-97F0-80B9AFF74F94 //Stored GUID VTKJavaFiltersHyperTree_GUID_CMAKE:INTERNAL=AD47BCFE-B9EE-4BC0-8A1F-D5794967537B //Stored GUID VTKJavaFiltersImaging_GUID_CMAKE:INTERNAL=8AD4FA1A-FFA8-4883-99E5-6022260ADC6F //Stored GUID VTKJavaFiltersModeling_GUID_CMAKE:INTERNAL=27AE5CFB-65BC-4EE8-9EE5-724F96C24451 //Stored GUID VTKJavaFiltersParallelImaging_GUID_CMAKE:INTERNAL=687757E6-3218-47F2-806A-CC3A82B56B36 //Stored GUID VTKJavaFiltersParallel_GUID_CMAKE:INTERNAL=3E53BC4B-98B0-4098-90FA-FE1FEDA42C13 //Stored GUID VTKJavaFiltersProgrammable_GUID_CMAKE:INTERNAL=7BD67C54-7AF2-49AA-BBFE-CD128A72A73E //Stored GUID VTKJavaFiltersSMP_GUID_CMAKE:INTERNAL=8D207716-E908-4458-8E10-CFFE83BD697C //Stored GUID VTKJavaFiltersSelection_GUID_CMAKE:INTERNAL=33F7B1E7-0CFD-4F07-8769-53F0587D95CC //Stored GUID VTKJavaFiltersSources_GUID_CMAKE:INTERNAL=4E0041CC-AEC4-452D-9C73-F62F97857A83 //Stored GUID VTKJavaFiltersStatistics_GUID_CMAKE:INTERNAL=F0B8EFD5-FFC4-4A5E-AFE0-D6D63D6C1EEC //Stored GUID VTKJavaFiltersTexture_GUID_CMAKE:INTERNAL=A428F5E6-687C-47B6-8C8E-05DF7387BA26 //Stored GUID VTKJavaFiltersVerdict_GUID_CMAKE:INTERNAL=6F70886F-D986-49D7-B7F2-0A5221044CD0 //Stored GUID VTKJavaGeovisCore_GUID_CMAKE:INTERNAL=7EFE9658-22CD-476C-BAFB-B0DE306DF327 //Stored GUID VTKJavaIOAMR_GUID_CMAKE:INTERNAL=C329EFAA-7C7F-4804-B654-833E23B8C49E //Stored GUID VTKJavaIOCore_GUID_CMAKE:INTERNAL=284CF221-F155-4F1C-AC8D-1EF6054B4E90 //Stored GUID VTKJavaIOEnSight_GUID_CMAKE:INTERNAL=F2B925D7-0737-4B4A-9E3A-E5B3850E2F92 //Stored GUID VTKJavaIOExodus_GUID_CMAKE:INTERNAL=C9D65BDC-B86D-4934-965F-AF9164B4A4F5 //Stored GUID VTKJavaIOExport_GUID_CMAKE:INTERNAL=47CCDFF9-9EFF-48A3-8F73-1F7E285F176E //Stored GUID VTKJavaIOGeometry_GUID_CMAKE:INTERNAL=94699B1C-DEF8-436A-8E4E-0EF7CABE6AC0 //Stored GUID VTKJavaIOImage_GUID_CMAKE:INTERNAL=F4A957D6-2912-4243-B443-94EA9CA3915E //Stored GUID VTKJavaIOImport_GUID_CMAKE:INTERNAL=497EDABF-1C27-4FE7-A03E-6F067D959B1F //Stored GUID VTKJavaIOInfovis_GUID_CMAKE:INTERNAL=362ED125-1624-47D0-9C72-15F279349B79 //Stored GUID VTKJavaIOLSDyna_GUID_CMAKE:INTERNAL=2AFD0BD3-2C83-44EB-A786-3C30FC151FAD //Stored GUID VTKJavaIOLegacy_GUID_CMAKE:INTERNAL=9DBEFAEC-6250-414D-973E-3EEB23FB2B0E //Stored GUID VTKJavaIOMINC_GUID_CMAKE:INTERNAL=17592375-B397-4055-B713-57B57757C623 //Stored GUID VTKJavaIOMovie_GUID_CMAKE:INTERNAL=C81760BE-D43A-48AF-A1AA-76DC6B194E91 //Stored GUID VTKJavaIONetCDF_GUID_CMAKE:INTERNAL=5C30EB99-CBBD-4860-8EC8-2DA6EB2FFA8D //Stored GUID VTKJavaIOPLY_GUID_CMAKE:INTERNAL=28591C90-8E1E-4E6D-AA09-BC64E8148E30 //Stored GUID VTKJavaIOParallel_GUID_CMAKE:INTERNAL=777B9AAD-B2CE-48E9-8BC2-A5A494EE83F6 //Stored GUID VTKJavaIOSQL_GUID_CMAKE:INTERNAL=A5415DF9-DB5E-41CF-9CFF-BA10A6717AA0 //Stored GUID VTKJavaIOVideo_GUID_CMAKE:INTERNAL=080489FC-F9B1-463B-BAAB-B3877FEF804E //Stored GUID VTKJavaIOXMLParser_GUID_CMAKE:INTERNAL=58D94A0B-C96C-48A3-AD41-902156C50362 //Stored GUID VTKJavaIOXML_GUID_CMAKE:INTERNAL=C901F2F9-0760-44F6-A351-3187C26AC0F4 //Stored GUID VTKJavaImagingColor_GUID_CMAKE:INTERNAL=83674874-0DA1-4727-86D5-AEDEB6152890 //Stored GUID VTKJavaImagingCore_GUID_CMAKE:INTERNAL=D4667E7F-6B4C-4BD1-9C4D-D6A28813BD51 //Stored GUID VTKJavaImagingFourier_GUID_CMAKE:INTERNAL=6B3D9CF7-0381-4ECF-A64C-305CC045B1DF //Stored GUID VTKJavaImagingGeneral_GUID_CMAKE:INTERNAL=151EB4D2-0F24-40DD-A5DB-9FD22C876770 //Stored GUID VTKJavaImagingHybrid_GUID_CMAKE:INTERNAL=CF5123F1-7B13-4DD8-A901-AA58C7F3C4A0 //Stored GUID VTKJavaImagingMath_GUID_CMAKE:INTERNAL=DAAF274D-3041-44A2-BDB1-C2A118E87993 //Stored GUID VTKJavaImagingMorphological_GUID_CMAKE:INTERNAL=1DE7F029-1D84-42F8-85A7-EF1AC2B92A7F //Stored GUID VTKJavaImagingSources_GUID_CMAKE:INTERNAL=EDE8220C-15C5-4DE5-AEEC-C70BDD0F2E0F //Stored GUID VTKJavaImagingStatistics_GUID_CMAKE:INTERNAL=37D46D28-0CC7-4792-A7F6-369F56175E4E //Stored GUID VTKJavaImagingStencil_GUID_CMAKE:INTERNAL=D6A1D9B8-5598-448D-BDB8-B7266AAF1E90 //Stored GUID VTKJavaInfovisCore_GUID_CMAKE:INTERNAL=61D91EC8-7406-4E00-90F9-3A553F8C8EA4 //Stored GUID VTKJavaInfovisLayout_GUID_CMAKE:INTERNAL=40BE991F-8F56-4A4D-9414-54BA966BB7E0 //Stored GUID VTKJavaInteractionImage_GUID_CMAKE:INTERNAL=5812358A-BB08-4EA8-9A8C-74AD3BEE8374 //Stored GUID VTKJavaInteractionStyle_GUID_CMAKE:INTERNAL=1283B6B2-919A-4072-935C-EDBC3ADF62FC //Stored GUID VTKJavaInteractionWidgets_GUID_CMAKE:INTERNAL=2A31BA17-7C63-4A80-B834-B8EF52B35FF4 //Stored GUID VTKJavaJar_GUID_CMAKE:INTERNAL=AFEA5C12-74F4-4750-BDBA-BF6A2122B10B //Stored GUID VTKJavaParallelCore_GUID_CMAKE:INTERNAL=D3C58E24-1DA9-46E9-9617-9C2AACFCCAAB //Stored GUID VTKJavaRenderingAnnotation_GUID_CMAKE:INTERNAL=776034B6-3713-4CCC-A1ED-742D6DB7601A //Stored GUID VTKJavaRenderingContext2D_GUID_CMAKE:INTERNAL=34BC7348-2EF9-41FA-8902-52EF3E522D42 //Stored GUID VTKJavaRenderingCore_GUID_CMAKE:INTERNAL=440B52C8-28FC-449C-9DCB-B46F9D7D5EBF //Stored GUID VTKJavaRenderingFreeTypeOpenGL_GUID_CMAKE:INTERNAL=6CF562FA-6726-45BB-AA5A-46C674953CF2 //Stored GUID VTKJavaRenderingFreeType_GUID_CMAKE:INTERNAL=17B631FC-4B82-4B60-B86A-DD4101FDCC86 //Stored GUID VTKJavaRenderingGL2PS_GUID_CMAKE:INTERNAL=BE8EF2D9-9C9E-48E3-B2A6-8E99CCDC2992 //Stored GUID VTKJavaRenderingImage_GUID_CMAKE:INTERNAL=FA2FB2BC-C546-43D5-805B-09A3DA5A9C03 //Stored GUID VTKJavaRenderingLIC_GUID_CMAKE:INTERNAL=44573B72-6ABA-49A6-A2F7-9230547F005B //Stored GUID VTKJavaRenderingLOD_GUID_CMAKE:INTERNAL=43855335-9162-4AED-BE01-A325E3959E3F //Stored GUID VTKJavaRenderingLabel_GUID_CMAKE:INTERNAL=05857D72-A1CD-4D9E-8D62-95278D2DAFA4 //Stored GUID VTKJavaRenderingOpenGL_GUID_CMAKE:INTERNAL=1928CEEC-1F0C-4758-AA80-D31FC8D1EEAD //Stored GUID VTKJavaRenderingVolumeAMR_GUID_CMAKE:INTERNAL=4FF80D16-D65D-474D-895F-6FEEEEED3736 //Stored GUID VTKJavaRenderingVolumeOpenGL_GUID_CMAKE:INTERNAL=1D62CB2A-9052-4099-9D97-4C047806DE6C //Stored GUID VTKJavaRenderingVolume_GUID_CMAKE:INTERNAL=C09D5903-1C1E-450D-9E61-B82B94ED6653 //Stored GUID VTKJavaViewsContext2D_GUID_CMAKE:INTERNAL=A876004F-592C-4BD6-B2DF-C54A194B358A //Stored GUID VTKJavaViewsCore_GUID_CMAKE:INTERNAL=F2281C32-4033-44F1-89E8-60C021C55FEE //Stored GUID VTKJavaViewsGeovis_GUID_CMAKE:INTERNAL=02B15DB6-2772-4E56-8C27-B1AC9ADF1869 //Stored GUID VTKJavaViewsInfovis_GUID_CMAKE:INTERNAL=84B679A3-1613-4C47-90A7-F46AC4826483 //ADVANCED property for variable: VTKOGGTHEORA_DISABLE_ASM VTKOGGTHEORA_DISABLE_ASM-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTKOGGTHEORA_DISABLE_FLOAT VTKOGGTHEORA_DISABLE_FLOAT-ADVANCED:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(int) VTKOGGTHEORA_INT:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(int16_t) VTKOGGTHEORA_INT16_T:INTERNAL=2 //CHECK_TYPE_SIZE: sizeof(int32_t) VTKOGGTHEORA_INT32_T:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(int64_t) VTKOGGTHEORA_INT64_T:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(long) VTKOGGTHEORA_LONG:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(long long) VTKOGGTHEORA_LONG_LONG:INTERNAL=8 //ADVANCED property for variable: VTKOGGTHEORA_SHARED_LINKER_FLAGS VTKOGGTHEORA_SHARED_LINKER_FLAGS-ADVANCED:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(short) VTKOGGTHEORA_SHORT:INTERNAL=2 //CHECK_TYPE_SIZE: sizeof(uint16_t) VTKOGGTHEORA_UINT16_T:INTERNAL=2 //CHECK_TYPE_SIZE: sizeof(uint32_t) VTKOGGTHEORA_UINT32_T:INTERNAL=4 //CHECK_TYPE_SIZE: u_int16_t unknown VTKOGGTHEORA_U_INT16_T:INTERNAL= //CHECK_TYPE_SIZE: u_int32_t unknown VTKOGGTHEORA_U_INT32_T:INTERNAL= //ADVANCED property for variable: VTK_ALL_NEW_OBJECT_FACTORY VTK_ALL_NEW_OBJECT_FACTORY-ADVANCED:INTERNAL=1 //Result of TRY_COMPILE VTK_ANSI_STREAM_EOF_COMPILED:INTERNAL=TRUE //Result of TRY_RUN VTK_ANSI_STREAM_EOF_RESULT:INTERNAL=0 //ADVANCED property for variable: VTK_BUILD_ALL_MODULES VTK_BUILD_ALL_MODULES-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_BUILD_PYTHON_MODULE_DIR VTK_BUILD_PYTHON_MODULE_DIR-ADVANCED:INTERNAL=1 //Support for full template specialization syntax VTK_COMPILER_HAS_FULL_SPECIALIZATION:INTERNAL=1 //Test VTK_CONST_REVERSE_ITERATOR_COMPARISON VTK_CONST_REVERSE_ITERATOR_COMPARISON:INTERNAL=1 //ADVANCED property for variable: VTK_DATA_STORE VTK_DATA_STORE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_DEBUG_LEAKS VTK_DEBUG_LEAKS-ADVANCED:INTERNAL=1 //Support for C++ explict templates VTK_EXPLICIT_TEMPLATES:INTERNAL=1 //ADVANCED property for variable: VTK_GLEXT_FILE VTK_GLEXT_FILE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_GLXEXT_FILE VTK_GLXEXT_FILE-ADVANCED:INTERNAL=1 //Have symbol finite VTK_HAS_FINITE:INTERNAL= //Have symbol InterlockedAdd VTK_HAS_INTERLOCKEDADD:INTERNAL= //Have symbol isfinite VTK_HAS_ISFINITE:INTERNAL= //Have symbol isinf VTK_HAS_ISINF:INTERNAL= //Have symbol isnan VTK_HAS_ISNAN:INTERNAL= //Test VTK_HAS_STD_ISFINITE VTK_HAS_STD_ISFINITE:INTERNAL= //Test VTK_HAS_STD_ISINF VTK_HAS_STD_ISINF:INTERNAL= //Test VTK_HAS_STD_ISNAN VTK_HAS_STD_ISNAN:INTERNAL= //Have symbol _finite VTK_HAS__FINITE:INTERNAL=1 //Have symbol _isnan VTK_HAS__ISNAN:INTERNAL=1 //Support for getsockname with socklen_t VTK_HAVE_GETSOCKNAME_WITH_SOCKLEN_T:INTERNAL=0 //Have library socket VTK_HAVE_LIBSOCKET:INTERNAL= //Have symbol SO_REUSEADDR VTK_HAVE_SO_REUSEADDR:INTERNAL= //VTK modular always ignores BTX VTK_IGNORE_BTX:INTERNAL=ON //ADVANCED property for variable: VTK_IGNORE_GLDRIVER_BUGS VTK_IGNORE_GLDRIVER_BUGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_INSTALL_PYTHON_MODULE_DIR VTK_INSTALL_PYTHON_MODULE_DIR-ADVANCED:INTERNAL=1 //Whether istream supports long long VTK_ISTREAM_SUPPORTS_LONG_LONG:INTERNAL=1 //ADVANCED property for variable: VTK_LEGACY_REMOVE VTK_LEGACY_REMOVE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_LEGACY_SILENT VTK_LEGACY_SILENT-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_MAKE_INSTANTIATORS VTK_MAKE_INSTANTIATORS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_MAX_THREADS VTK_MAX_THREADS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_OPENGL_HAS_OSMESA VTK_OPENGL_HAS_OSMESA-ADVANCED:INTERNAL=1 //Whether ostream supports long long VTK_OSTREAM_SUPPORTS_LONG_LONG:INTERNAL=1 //ADVANCED property for variable: VTK_REPORT_OPENGL_ERRORS VTK_REPORT_OPENGL_ERRORS-ADVANCED:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(char) VTK_SIZEOF_CHAR:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(double) VTK_SIZEOF_DOUBLE:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(float) VTK_SIZEOF_FLOAT:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(int) VTK_SIZEOF_INT:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(long) VTK_SIZEOF_LONG:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(long long) VTK_SIZEOF_LONG_LONG:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(short) VTK_SIZEOF_SHORT:INTERNAL=2 //CHECK_TYPE_SIZE: sizeof(__int64) VTK_SIZEOF___INT64:INTERNAL=8 //STRINGS property for variable: VTK_SMP_IMPLEMENTATION_TYPE VTK_SMP_IMPLEMENTATION_TYPE-STRINGS:INTERNAL=Sequential;Simple;Kaapi;TBB //Whether char is signed. VTK_TYPE_CHAR_IS_SIGNED:INTERNAL=1 //Result of TRY_COMPILE VTK_TYPE_CHAR_IS_SIGNED_COMPILED:INTERNAL=TRUE //Whether long and __int64 are the same type VTK_TYPE_SAME_LONG_AND___INT64:INTERNAL=0 //Whether long long and __int64 are the same type VTK_TYPE_SAME_LONG_LONG_AND___INT64:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(uintptr_t) VTK_UINTPTR_T:INTERNAL=4 //ADVANCED property for variable: VTK_USE_64BIT_IDS VTK_USE_64BIT_IDS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_OFFSCREEN VTK_USE_OFFSCREEN-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_EXPAT VTK_USE_SYSTEM_EXPAT-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_FREETYPE VTK_USE_SYSTEM_FREETYPE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_GL2PS VTK_USE_SYSTEM_GL2PS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_HDF5 VTK_USE_SYSTEM_HDF5-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_JPEG VTK_USE_SYSTEM_JPEG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_JSONCPP VTK_USE_SYSTEM_JSONCPP-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_LIBPROJ4 VTK_USE_SYSTEM_LIBPROJ4-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_LIBXML2 VTK_USE_SYSTEM_LIBXML2-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_NETCDF VTK_USE_SYSTEM_NETCDF-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_OGGTHEORA VTK_USE_SYSTEM_OGGTHEORA-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_PNG VTK_USE_SYSTEM_PNG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_TIFF VTK_USE_SYSTEM_TIFF-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_ZLIB VTK_USE_SYSTEM_ZLIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_TDX VTK_USE_TDX-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_VIDEO_FOR_WINDOWS VTK_USE_VIDEO_FOR_WINDOWS-ADVANCED:INTERNAL=1 //Result of TRY_COMPILE VTK_USE_VIDEO_FOR_WINDOWS_DEFAULT:INTERNAL=TRUE //ADVANCED property for variable: VTK_USE_X VTK_USE_X-ADVANCED:INTERNAL=1 //Enable using Video for Windows (vfw32) for video capture. VTK_VFW_SUPPORTS_CAPTURE:INTERNAL=1 //ADVANCED property for variable: VTK_WGLEXT_FILE VTK_WGLEXT_FILE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_WRAP_HINTS VTK_WRAP_HINTS-ADVANCED:INTERNAL=1 //Stored GUID ZERO_CHECK_GUID_CMAKE:INTERNAL=68AA9EB8-2FC9-4CA4-B4E5-857AFCAEBBBF //Stored GUID lproj_GUID_CMAKE:INTERNAL=CD27887B-F1D2-4943-89A7-EE5D66755A91 netcdf_cxx_SOURCES:INTERNAL=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/cxx/netcdf.cpp;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/cxx/ncvalues.cpp netcdf_dispatch_SOURCES:INTERNAL=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/parallel.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/copy.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/file.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/dim.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/att.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/error.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/var.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/dispatch.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/nc_url.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/nclist.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/ncbytes.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/ncbytes.h;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libdispatch/nc4.c netcdf_liblib_SOURCES:INTERNAL=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/liblib/stub.c netcdf_src4_SOURCES:INTERNAL=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4internal.h;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/error4.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4dispatch.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4dispatch.h;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4attr.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4dim.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4file.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4grp.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4type.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4var.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/ncfunc.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4internal.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc4/nc4hdf.c netcdf_src_SOURCES:INTERNAL=C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/string.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/v1hpg.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/onstack.h;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/rnd.h;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/utf8proc.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/utf8proc_data.h;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/nclistmgr.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/putget.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/attr.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/nc3dispatch.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/nc.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/var.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/dim.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/ncx.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/ncx.h;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/lookup3.c;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/pstdint.h;C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0/ThirdParty/netcdf/vtknetcdf/libsrc/posixio.c //Stored GUID verdict_GUID_CMAKE:INTERNAL=5EA32627-9C3A-482B-8D15-0853DCFE0703 //Stored GUID vtkChartsCoreJavaJavaClasses_GUID_CMAKE:INTERNAL=EF426196-3BBB-4626-95B7-F8766D9636C7 //Stored GUID vtkChartsCoreJava_GUID_CMAKE:INTERNAL=CB3C8D8E-7535-4760-AF9D-BAE1881CB346 //Stored GUID vtkChartsCore_GUID_CMAKE:INTERNAL=8433A8E5-3E9F-431E-97A4-5F80B637DB1A //Stored GUID vtkCommonColorJavaJavaClasses_GUID_CMAKE:INTERNAL=A992B910-5665-41CE-A266-99762F303FFC //Stored GUID vtkCommonColorJava_GUID_CMAKE:INTERNAL=73BEDD87-0D42-4415-B327-16C3AD910B0F //Stored GUID vtkCommonColor_GUID_CMAKE:INTERNAL=6EB4F8EB-393E-4A1E-B7DF-1CA90100EBB8 //Stored GUID vtkCommonComputationalGeometryJavaJavaClasses_GUID_CMAKE:INTERNAL=15EC28AC-8164-4942-9A98-494227039EF6 //Stored GUID vtkCommonComputationalGeometryJava_GUID_CMAKE:INTERNAL=3028C81E-1895-418A-8AF1-DB1CFBFD76D6 //Stored GUID vtkCommonComputationalGeometry_GUID_CMAKE:INTERNAL=94232971-24AC-4F2C-8C49-4CAD6CE87F9A //Stored GUID vtkCommonCoreJavaJavaClasses_GUID_CMAKE:INTERNAL=315C4FAE-E7EB-40B7-B53B-FBB2F662701C //Stored GUID vtkCommonCoreJava_GUID_CMAKE:INTERNAL=86010C21-66F4-44B5-BDB1-57367E17C5CE //Stored GUID vtkCommonCore_GUID_CMAKE:INTERNAL=56453ABF-FEEA-4074-A8D4-5E0FD2B4D3CF //Stored GUID vtkCommonDataModelJavaJavaClasses_GUID_CMAKE:INTERNAL=20127DE1-B1E1-4835-8689-B6CD10D0FD8F //Stored GUID vtkCommonDataModelJava_GUID_CMAKE:INTERNAL=EAA84FEC-8A2C-4F89-A763-E7BD271BB1AB //Stored GUID vtkCommonDataModel_GUID_CMAKE:INTERNAL=C6F5FCD5-34A6-4A58-8998-26A2AEFA816C //Stored GUID vtkCommonExecutionModelJavaJavaClasses_GUID_CMAKE:INTERNAL=38E7A9CF-AA26-45F6-B250-F92A552A4324 //Stored GUID vtkCommonExecutionModelJava_GUID_CMAKE:INTERNAL=CE33BC51-1DE7-41E4-B4F4-2B077A090E4C //Stored GUID vtkCommonExecutionModel_GUID_CMAKE:INTERNAL=62831627-9B62-487D-A88C-72E1E5EC5BCE //Stored GUID vtkCommonMathJavaJavaClasses_GUID_CMAKE:INTERNAL=A1792CC7-F4AD-41ED-923A-B0F37B53A94B //Stored GUID vtkCommonMathJava_GUID_CMAKE:INTERNAL=79AACC68-61BD-4B6C-AB3E-306277708FDD //Stored GUID vtkCommonMath_GUID_CMAKE:INTERNAL=CA922E4F-10DE-4E35-B3F9-F0FBEB7F0D4B //Stored GUID vtkCommonMiscJavaJavaClasses_GUID_CMAKE:INTERNAL=4774196A-D77A-4E4E-8C08-8B6DB322D152 //Stored GUID vtkCommonMiscJava_GUID_CMAKE:INTERNAL=E8BA9E77-A134-41E1-8430-BE555C6DD6F2 //Stored GUID vtkCommonMisc_GUID_CMAKE:INTERNAL=B2CB29FF-BC9E-4DAD-B8E6-277C45E91DB2 //Stored GUID vtkCommonSystemJavaJavaClasses_GUID_CMAKE:INTERNAL=60564978-6978-4ABB-85F8-3AAB69304F0C //Stored GUID vtkCommonSystemJava_GUID_CMAKE:INTERNAL=2B122AB1-B9D9-48FF-9A80-806D4CA957CA //Stored GUID vtkCommonSystem_GUID_CMAKE:INTERNAL=40682EBC-796D-4807-9EF4-2FC973EBD78F //Stored GUID vtkCommonTransformsJavaJavaClasses_GUID_CMAKE:INTERNAL=D8E21295-79D5-41B3-8BFB-A57C5C386F3F //Stored GUID vtkCommonTransformsJava_GUID_CMAKE:INTERNAL=266551D6-0FF2-406F-BAD8-F439163F8374 //Stored GUID vtkCommonTransforms_GUID_CMAKE:INTERNAL=AFDD9266-700D-493B-9878-C69F3723EF8D //Stored GUID vtkCompileTools_GUID_CMAKE:INTERNAL=F242FE55-AAB4-40AC-A217-6E834B6B79B8 //Stored GUID vtkDICOMParser_GUID_CMAKE:INTERNAL=867503E6-23DC-4DEA-8FA1-90511591FE89 //Stored GUID vtkDomainsChemistryJavaJavaClasses_GUID_CMAKE:INTERNAL=0C61B468-F9E5-4567-8F71-7D7DF047C7C4 //Stored GUID vtkDomainsChemistryJava_GUID_CMAKE:INTERNAL=E20D16A4-505B-4199-BB42-657B5EDCB4D6 //Stored GUID vtkDomainsChemistry_GUID_CMAKE:INTERNAL=8F760800-DC39-4A46-BA34-3E2F49318BCD //Stored GUID vtkEncodeString_GUID_CMAKE:INTERNAL=72DE72CF-DA52-46D2-AD29-B7A77D75DDC0 //Stored GUID vtkFiltersAMRJavaJavaClasses_GUID_CMAKE:INTERNAL=C8C6A96B-9130-424F-AE21-ABDF557F472F //Stored GUID vtkFiltersAMRJava_GUID_CMAKE:INTERNAL=06F21E77-B954-4FF3-9212-31944D9AC576 //Stored GUID vtkFiltersAMR_GUID_CMAKE:INTERNAL=FE034487-3998-4C4F-B1C6-B9D038016962 //Stored GUID vtkFiltersCoreJavaJavaClasses_GUID_CMAKE:INTERNAL=179728C2-50B6-4B74-AE4B-E1E125F043A3 //Stored GUID vtkFiltersCoreJava_GUID_CMAKE:INTERNAL=88BCFA26-6820-4683-83E2-85664412BB0B //Stored GUID vtkFiltersCore_GUID_CMAKE:INTERNAL=D0029B70-A94F-4E69-8305-18380ED38E03 //Stored GUID vtkFiltersExtractionJavaJavaClasses_GUID_CMAKE:INTERNAL=60722772-38BF-4E6D-AC42-A4FCEABEC23B //Stored GUID vtkFiltersExtractionJava_GUID_CMAKE:INTERNAL=66813351-7938-42C8-A401-1176CBC0B6FF //Stored GUID vtkFiltersExtraction_GUID_CMAKE:INTERNAL=4BED5DD4-F400-4FE1-BA1D-B90EC596679A //Stored GUID vtkFiltersFlowPathsJavaJavaClasses_GUID_CMAKE:INTERNAL=BF7B2481-1E91-4AAC-9E6E-9205D1D89B79 //Stored GUID vtkFiltersFlowPathsJava_GUID_CMAKE:INTERNAL=B30C92D8-2438-4B75-BDCA-473630DD078B //Stored GUID vtkFiltersFlowPaths_GUID_CMAKE:INTERNAL=74D752B9-2454-4946-9D59-7574573015B6 //Stored GUID vtkFiltersGeneralJavaJavaClasses_GUID_CMAKE:INTERNAL=20522A3E-1B44-4035-B73A-5E78361E4729 //Stored GUID vtkFiltersGeneralJava_GUID_CMAKE:INTERNAL=FD3DF419-603D-4FAD-B764-F02D75DFC2C5 //Stored GUID vtkFiltersGeneral_GUID_CMAKE:INTERNAL=30470F77-2751-4772-B992-88E33DF0D761 //Stored GUID vtkFiltersGenericJavaJavaClasses_GUID_CMAKE:INTERNAL=EAEEC45B-D1C1-4455-AC1F-6CBED776DA91 //Stored GUID vtkFiltersGenericJava_GUID_CMAKE:INTERNAL=0F285DFD-BD0E-485A-8885-E790D9B66092 //Stored GUID vtkFiltersGeneric_GUID_CMAKE:INTERNAL=F2CEE9C8-EFED-4943-B218-8F50C27E4463 //Stored GUID vtkFiltersGeometryJavaJavaClasses_GUID_CMAKE:INTERNAL=8334A8DB-9850-4882-A845-410E1C7C785E //Stored GUID vtkFiltersGeometryJava_GUID_CMAKE:INTERNAL=46D7F468-5010-44C7-BF55-27C7082E8380 //Stored GUID vtkFiltersGeometry_GUID_CMAKE:INTERNAL=42E8AA03-73C0-416B-9A76-8F4B07E970D9 //Stored GUID vtkFiltersHybridJavaJavaClasses_GUID_CMAKE:INTERNAL=F5864EEC-6F4B-4ADA-82F5-534E80E4EBB8 //Stored GUID vtkFiltersHybridJava_GUID_CMAKE:INTERNAL=D7BBAB71-CEB6-435D-9B73-ED09E7BA9F94 //Stored GUID vtkFiltersHybrid_GUID_CMAKE:INTERNAL=EE309E02-29FF-4FBA-B63E-DC5FFA952E69 //Stored GUID vtkFiltersHyperTreeJavaJavaClasses_GUID_CMAKE:INTERNAL=A02E3318-5F2F-4EE6-96F5-D4EF70AE4706 //Stored GUID vtkFiltersHyperTreeJava_GUID_CMAKE:INTERNAL=B153CE97-BA38-40D9-893D-215A38B8DF5B //Stored GUID vtkFiltersHyperTree_GUID_CMAKE:INTERNAL=B007C95D-4C63-4A49-B890-19CF65CFA245 //Stored GUID vtkFiltersImagingJavaJavaClasses_GUID_CMAKE:INTERNAL=00C1954C-CB24-44A2-B570-72D0D3613823 //Stored GUID vtkFiltersImagingJava_GUID_CMAKE:INTERNAL=2F5211A7-8A3A-4A9B-82BE-76D845342131 //Stored GUID vtkFiltersImaging_GUID_CMAKE:INTERNAL=64F5D23B-8A17-4ECA-B71B-FE0D82DD0A5E //Stored GUID vtkFiltersModelingJavaJavaClasses_GUID_CMAKE:INTERNAL=E6E9C8B5-C645-4161-A032-C3399A865705 //Stored GUID vtkFiltersModelingJava_GUID_CMAKE:INTERNAL=7C516CAF-FEAB-4DD0-B574-8B6311D3F4D3 //Stored GUID vtkFiltersModeling_GUID_CMAKE:INTERNAL=7A4BD696-D7A3-438E-B326-D4185E0F8C28 //Stored GUID vtkFiltersParallelImagingJavaJavaClasses_GUID_CMAKE:INTERNAL=CDC5292B-9FF5-4946-BEE9-89B57F848AA0 //Stored GUID vtkFiltersParallelImagingJava_GUID_CMAKE:INTERNAL=AE2F64DB-4613-4EF7-AB08-45B4D08A034F //Stored GUID vtkFiltersParallelImaging_GUID_CMAKE:INTERNAL=AC9F3A5B-5C1E-4D8C-B3EB-31F1F9209EE9 //Stored GUID vtkFiltersParallelJavaJavaClasses_GUID_CMAKE:INTERNAL=D1F7095D-FD8C-4730-B4FD-D9D560739146 //Stored GUID vtkFiltersParallelJava_GUID_CMAKE:INTERNAL=D666E287-4C0A-49A1-B930-D6E0D3B04E60 //Stored GUID vtkFiltersParallel_GUID_CMAKE:INTERNAL=2F581653-D8E6-4888-8C49-41F31A9D1DC6 //Stored GUID vtkFiltersProgrammableJavaJavaClasses_GUID_CMAKE:INTERNAL=55B76A4B-B1EF-4AE8-AC89-4F7EB498A7D5 //Stored GUID vtkFiltersProgrammableJava_GUID_CMAKE:INTERNAL=C8ABE2BC-D406-430D-96AC-D622ED213BA5 //Stored GUID vtkFiltersProgrammable_GUID_CMAKE:INTERNAL=A4347585-C4D7-4B35-8DE6-2B39B15A7430 //Stored GUID vtkFiltersSMPJavaJavaClasses_GUID_CMAKE:INTERNAL=0BE6C5F5-73A9-4518-93C1-25CB9800389F //Stored GUID vtkFiltersSMPJava_GUID_CMAKE:INTERNAL=E7EAD390-65B1-4455-83E5-4666EA8B3FDB //Stored GUID vtkFiltersSMP_GUID_CMAKE:INTERNAL=90EE8579-ECAB-4B39-B23D-859FE0BFE619 //Stored GUID vtkFiltersSelectionJavaJavaClasses_GUID_CMAKE:INTERNAL=D270C68C-F220-44FB-9602-B1F786BC0E2C //Stored GUID vtkFiltersSelectionJava_GUID_CMAKE:INTERNAL=8F79A003-CEA7-4D50-966B-A99D6E348325 //Stored GUID vtkFiltersSelection_GUID_CMAKE:INTERNAL=E3FD4893-BE00-4334-B6CF-D16E36FBEF2B //Stored GUID vtkFiltersSourcesJavaJavaClasses_GUID_CMAKE:INTERNAL=B01C26EA-29BC-40E1-9A75-4D3DA43128AB //Stored GUID vtkFiltersSourcesJava_GUID_CMAKE:INTERNAL=1AAE66A4-E7C6-4E9C-BF8B-9155D4DCA39E //Stored GUID vtkFiltersSources_GUID_CMAKE:INTERNAL=B490D15E-47E1-43C2-A834-F33C9BA8A073 //Stored GUID vtkFiltersStatisticsJavaJavaClasses_GUID_CMAKE:INTERNAL=24122E81-0D81-458F-80C9-E8EAA7DE0526 //Stored GUID vtkFiltersStatisticsJava_GUID_CMAKE:INTERNAL=AEB54E45-9D83-425F-8EA8-0E59287549CB //Stored GUID vtkFiltersStatistics_GUID_CMAKE:INTERNAL=51075E43-F188-4B8E-B27C-B7283F3C1671 //Stored GUID vtkFiltersTextureJavaJavaClasses_GUID_CMAKE:INTERNAL=D0787063-CB63-4465-A024-0F41AEA2257D //Stored GUID vtkFiltersTextureJava_GUID_CMAKE:INTERNAL=2393E5A7-CA9A-4B66-A879-A8C70E69E82F //Stored GUID vtkFiltersTexture_GUID_CMAKE:INTERNAL=996717ED-3631-41ED-8B9F-17910478824D //Stored GUID vtkFiltersVerdictJavaJavaClasses_GUID_CMAKE:INTERNAL=3723D98E-8154-4450-8A93-7B093D1021A7 //Stored GUID vtkFiltersVerdictJava_GUID_CMAKE:INTERNAL=429CF17A-8A15-41B4-AF4B-9C4649BCFC8E //Stored GUID vtkFiltersVerdict_GUID_CMAKE:INTERNAL=5CCE50BA-0F28-46DA-B278-AC8A2F7EC486 //Stored GUID vtkGeovisCoreJavaJavaClasses_GUID_CMAKE:INTERNAL=0714B9A1-7320-4EFE-9C87-E5A7000A5BB2 //Stored GUID vtkGeovisCoreJava_GUID_CMAKE:INTERNAL=0D2102F9-E017-41E5-B168-FD88BEA30405 //Stored GUID vtkGeovisCore_GUID_CMAKE:INTERNAL=15BCF71F-8616-451F-A921-5928CEEAEF7D //Stored GUID vtkHashSource_GUID_CMAKE:INTERNAL=ECB58E06-B171-47B3-BB4B-642FDC7691C1 //Stored GUID vtkIOAMRJavaJavaClasses_GUID_CMAKE:INTERNAL=91CF2D99-00D7-4608-AE14-B8141B2CF0D3 //Stored GUID vtkIOAMRJava_GUID_CMAKE:INTERNAL=8FC29764-9E15-42F7-BB4E-966DC7FABC54 //Stored GUID vtkIOAMR_GUID_CMAKE:INTERNAL=11DDCCDC-97F9-4FD8-90B0-634AACD2F91F //Stored GUID vtkIOCoreJavaJavaClasses_GUID_CMAKE:INTERNAL=4359C454-06C5-49E9-AB48-5E790B772269 //Stored GUID vtkIOCoreJava_GUID_CMAKE:INTERNAL=568A5E7F-29A9-4BAB-AAEE-669E71905026 //Stored GUID vtkIOCore_GUID_CMAKE:INTERNAL=86EA5E30-201E-44B0-8D5C-43F70F97E2BB //Stored GUID vtkIOEnSightJavaJavaClasses_GUID_CMAKE:INTERNAL=14E4B81A-F350-4A32-88A5-868A2EC264B3 //Stored GUID vtkIOEnSightJava_GUID_CMAKE:INTERNAL=665388B4-CE8C-484D-8F5F-73B8C39E00AC //Stored GUID vtkIOEnSight_GUID_CMAKE:INTERNAL=9CC4D247-9D8D-49FC-AB66-08C1417EAC64 //Stored GUID vtkIOExodusJavaJavaClasses_GUID_CMAKE:INTERNAL=B48D22DD-A414-41F8-84E3-C9B23BD418FC //Stored GUID vtkIOExodusJava_GUID_CMAKE:INTERNAL=8420A239-31B5-42C0-BF7C-6A1FD6A1E72A //Stored GUID vtkIOExodus_GUID_CMAKE:INTERNAL=D475F4D5-AA12-478E-9FDA-8BBE47981435 //Stored GUID vtkIOExportJavaJavaClasses_GUID_CMAKE:INTERNAL=F94944D8-6D8E-456E-8AE8-F474B62D16C4 //Stored GUID vtkIOExportJava_GUID_CMAKE:INTERNAL=93973E46-DB20-49B0-AE3A-C4BE485562E3 //Stored GUID vtkIOExport_GUID_CMAKE:INTERNAL=C36607F9-3DFB-4201-9120-44066A22966B //Stored GUID vtkIOGeometryJavaJavaClasses_GUID_CMAKE:INTERNAL=F4DDB3F7-588A-4700-951B-90DBDE8280C2 //Stored GUID vtkIOGeometryJava_GUID_CMAKE:INTERNAL=B7D2CE2B-F67E-48FD-8BC1-002587241485 //Stored GUID vtkIOGeometry_GUID_CMAKE:INTERNAL=45A07F8A-E830-4D2E-A1D6-D4F925A31E46 //Stored GUID vtkIOImageJavaJavaClasses_GUID_CMAKE:INTERNAL=58691A57-535A-4214-B242-3F8170B7D63F //Stored GUID vtkIOImageJava_GUID_CMAKE:INTERNAL=34509BB6-42C2-482C-ACA4-14E6168A225C //Stored GUID vtkIOImage_GUID_CMAKE:INTERNAL=2E8D2D99-D584-4D4F-A3E9-CCFDF0CE14FB //Stored GUID vtkIOImportJavaJavaClasses_GUID_CMAKE:INTERNAL=6EB167CE-717D-499C-8357-9C1555BD2D29 //Stored GUID vtkIOImportJava_GUID_CMAKE:INTERNAL=1E49E170-796E-4708-8A7C-ED7C5CA8679A //Stored GUID vtkIOImport_GUID_CMAKE:INTERNAL=64638726-94E8-4D00-BFA7-851E9EEA39E4 //Stored GUID vtkIOInfovisJavaJavaClasses_GUID_CMAKE:INTERNAL=145E3286-9ECD-433C-B864-687218248E0E //Stored GUID vtkIOInfovisJava_GUID_CMAKE:INTERNAL=65049DA0-6205-4CAB-BAF5-19F572DC8790 //Stored GUID vtkIOInfovis_GUID_CMAKE:INTERNAL=1EF935F2-1AA0-4F3D-989D-2D1D35154B96 //Stored GUID vtkIOLSDynaJavaJavaClasses_GUID_CMAKE:INTERNAL=AA8B616B-1F5C-4DA9-B033-E33B4F2A0BF0 //Stored GUID vtkIOLSDynaJava_GUID_CMAKE:INTERNAL=73F00FC4-B991-4429-A6A7-1F9607BD9F56 //Stored GUID vtkIOLSDyna_GUID_CMAKE:INTERNAL=34430F0C-334B-4BB7-9249-A75AE80ACF26 //Stored GUID vtkIOLegacyJavaJavaClasses_GUID_CMAKE:INTERNAL=7F7D36CE-9C73-4DE0-9EF4-47F0AC2027F7 //Stored GUID vtkIOLegacyJava_GUID_CMAKE:INTERNAL=0EA9B3C9-0E30-42AE-AF79-93BEE1DDA708 //Stored GUID vtkIOLegacy_GUID_CMAKE:INTERNAL=ABEC7968-D2E6-41A7-8D9D-E121CE44FA22 //Stored GUID vtkIOMINCJavaJavaClasses_GUID_CMAKE:INTERNAL=7525EE41-4115-4AE0-BD84-AACCE6FC4F1F //Stored GUID vtkIOMINCJava_GUID_CMAKE:INTERNAL=28F58B5A-11C1-48EC-8FDF-93D2FA565A12 //Stored GUID vtkIOMINC_GUID_CMAKE:INTERNAL=6BD65495-1696-4C9E-95B2-72C748DDC9C1 //Stored GUID vtkIOMovieJavaJavaClasses_GUID_CMAKE:INTERNAL=6EDCC24A-224D-413E-BC63-CE7DB88CA0A1 //Stored GUID vtkIOMovieJava_GUID_CMAKE:INTERNAL=F7E7FEDF-36CF-4077-B2E2-8B2543AB41F4 //Stored GUID vtkIOMovie_GUID_CMAKE:INTERNAL=B5980760-FF6E-4FB5-8352-0E8C73EFE290 //Stored GUID vtkIONetCDFJavaJavaClasses_GUID_CMAKE:INTERNAL=258D69E0-CFC9-4BB2-8215-DF7663BDF7D1 //Stored GUID vtkIONetCDFJava_GUID_CMAKE:INTERNAL=8672D224-678D-4BD0-BC5D-CBDF60384CC2 //Stored GUID vtkIONetCDF_GUID_CMAKE:INTERNAL=F697FA12-9E32-4C44-90F9-1256ED9888CF //Stored GUID vtkIOPLYJavaJavaClasses_GUID_CMAKE:INTERNAL=31261E98-A0BD-4A5E-BEF9-2C0797EAE24B //Stored GUID vtkIOPLYJava_GUID_CMAKE:INTERNAL=80194B73-C6C3-45C4-A40B-78B3783D081A //Stored GUID vtkIOPLY_GUID_CMAKE:INTERNAL=1324403F-AA2E-48C2-B83C-09B3E1D23B4B //Stored GUID vtkIOParallelJavaJavaClasses_GUID_CMAKE:INTERNAL=7559A08F-6AD7-4530-99D4-BEE3430166B9 //Stored GUID vtkIOParallelJava_GUID_CMAKE:INTERNAL=CE8793D0-6822-4F76-9016-7FE739FC1495 //Stored GUID vtkIOParallel_GUID_CMAKE:INTERNAL=0A2A4B5B-517C-4E99-8899-75F0155B5593 //Stored GUID vtkIOSQLJavaJavaClasses_GUID_CMAKE:INTERNAL=C8FD6848-E35A-4341-8C3A-CDC57F628F8C //Stored GUID vtkIOSQLJava_GUID_CMAKE:INTERNAL=9BA384EC-39D7-42C4-9657-CFE26DEC4A08 //Stored GUID vtkIOSQL_GUID_CMAKE:INTERNAL=F1F61CC3-267E-4C26-812D-BA5F55286CF6 //Stored GUID vtkIOVideoJavaJavaClasses_GUID_CMAKE:INTERNAL=B8CBE330-8CD8-4217-BDF1-93FBE60D0E83 //Stored GUID vtkIOVideoJava_GUID_CMAKE:INTERNAL=A5DEBEFE-D70C-4F70-BB3E-49FE0A5BFF0D //Stored GUID vtkIOVideo_GUID_CMAKE:INTERNAL=D898A4F5-1576-4466-9C79-3FF41BCFE94A //Stored GUID vtkIOXMLJavaJavaClasses_GUID_CMAKE:INTERNAL=F6D41E34-2D98-4B15-A051-D892A155C0E9 //Stored GUID vtkIOXMLJava_GUID_CMAKE:INTERNAL=57AB2885-540B-40B1-8ACB-6F814B6B4BA9 //Stored GUID vtkIOXMLParserJavaJavaClasses_GUID_CMAKE:INTERNAL=1878FFF1-4795-4D1E-B80E-4492E555874C //Stored GUID vtkIOXMLParserJava_GUID_CMAKE:INTERNAL=CAB22900-82A0-472C-B97C-D1D1FFFE9388 //Stored GUID vtkIOXMLParser_GUID_CMAKE:INTERNAL=1B00B7FC-3D97-4821-99F0-36EF472B0FA8 //Stored GUID vtkIOXML_GUID_CMAKE:INTERNAL=744E09D0-59CB-42B9-80A7-BAF301C73798 //Stored GUID vtkImagingColorJavaJavaClasses_GUID_CMAKE:INTERNAL=F1A76FE0-472A-40EE-9D9C-93E1990FC0AC //Stored GUID vtkImagingColorJava_GUID_CMAKE:INTERNAL=E532F233-45C1-4D94-93A4-9D45FCC36F05 //Stored GUID vtkImagingColor_GUID_CMAKE:INTERNAL=5044C1BC-50A3-4977-8623-F3AD4C608055 //Stored GUID vtkImagingCoreJavaJavaClasses_GUID_CMAKE:INTERNAL=43417F9B-6EC4-414B-9A70-57B343EBF216 //Stored GUID vtkImagingCoreJava_GUID_CMAKE:INTERNAL=3DF381D0-1116-4677-BD51-93BA3F312ED4 //Stored GUID vtkImagingCore_GUID_CMAKE:INTERNAL=8C5ED0D4-442A-4827-B2CF-A08AA61AA15E //Stored GUID vtkImagingFourierJavaJavaClasses_GUID_CMAKE:INTERNAL=8FBA43C6-E314-4AD1-A037-A6C45914F94E //Stored GUID vtkImagingFourierJava_GUID_CMAKE:INTERNAL=0FDF3D41-B211-4F73-9FDA-E44EF38A6C10 //Stored GUID vtkImagingFourier_GUID_CMAKE:INTERNAL=2CBB824E-F2DD-413D-94B6-9102CDD70BE4 //Stored GUID vtkImagingGeneralJavaJavaClasses_GUID_CMAKE:INTERNAL=9C6934E7-F0E6-458B-A7A0-2841AFD27FEB //Stored GUID vtkImagingGeneralJava_GUID_CMAKE:INTERNAL=2BC4639C-4E57-4634-B6B8-5725F222D95B //Stored GUID vtkImagingGeneral_GUID_CMAKE:INTERNAL=7662F9C3-0D74-433F-8969-C2DD0620FA53 //Stored GUID vtkImagingHybridJavaJavaClasses_GUID_CMAKE:INTERNAL=A2393659-A93A-44B1-A010-368CCF4BA88A //Stored GUID vtkImagingHybridJava_GUID_CMAKE:INTERNAL=E1C698B6-62B3-4C24-84AC-160E8468AF87 //Stored GUID vtkImagingHybrid_GUID_CMAKE:INTERNAL=23AEE45F-DFA4-408C-9EED-B2E61A246D3C //Stored GUID vtkImagingMathJavaJavaClasses_GUID_CMAKE:INTERNAL=6CDBE6B5-36DB-4ED2-8AA9-3BE860EB3116 //Stored GUID vtkImagingMathJava_GUID_CMAKE:INTERNAL=4DD217DD-4C61-459E-AF44-F0D9173F0DA9 //Stored GUID vtkImagingMath_GUID_CMAKE:INTERNAL=9B2B57C6-774E-4BFC-B3E9-171A4D0557EE //Stored GUID vtkImagingMorphologicalJavaJavaClasses_GUID_CMAKE:INTERNAL=FF0EC6F9-1D99-4FF9-9D83-CD58997F8B4B //Stored GUID vtkImagingMorphologicalJava_GUID_CMAKE:INTERNAL=B5CC3245-8F27-4C2E-9E9B-E778B4084A41 //Stored GUID vtkImagingMorphological_GUID_CMAKE:INTERNAL=BF357176-2A2E-47C5-A3D0-0E973568C2A1 //Stored GUID vtkImagingSourcesJavaJavaClasses_GUID_CMAKE:INTERNAL=A914D934-AB04-4970-877F-CA2591653F69 //Stored GUID vtkImagingSourcesJava_GUID_CMAKE:INTERNAL=86CB888A-1729-4E4F-9757-C84B66AA655F //Stored GUID vtkImagingSources_GUID_CMAKE:INTERNAL=20C8DDB8-7162-49DC-A138-22F2685528FF //Stored GUID vtkImagingStatisticsJavaJavaClasses_GUID_CMAKE:INTERNAL=CC64C026-68E0-4018-A49D-C8D7B682958F //Stored GUID vtkImagingStatisticsJava_GUID_CMAKE:INTERNAL=D20BFFE9-21FA-4459-9E2D-454A2EAB3B00 //Stored GUID vtkImagingStatistics_GUID_CMAKE:INTERNAL=794DACE6-90C9-43E7-A2FC-CE37DF4F7F9D //Stored GUID vtkImagingStencilJavaJavaClasses_GUID_CMAKE:INTERNAL=C81104B4-C233-478A-A80D-39BDDE1AAA56 //Stored GUID vtkImagingStencilJava_GUID_CMAKE:INTERNAL=E08D8643-53B4-48E4-865E-79B3BDD550C4 //Stored GUID vtkImagingStencil_GUID_CMAKE:INTERNAL=4896705A-61A0-405E-A721-4927DEDCA765 //Stored GUID vtkInfovisCoreJavaJavaClasses_GUID_CMAKE:INTERNAL=FB3E6EEC-DC61-41ED-B96A-1A0A1873AE0E //Stored GUID vtkInfovisCoreJava_GUID_CMAKE:INTERNAL=6F110DCE-271F-47B8-B498-64CE2D07C253 //Stored GUID vtkInfovisCore_GUID_CMAKE:INTERNAL=DF1F0959-2D18-46EF-A3E2-B5136D583EAF //Stored GUID vtkInfovisLayoutJavaJavaClasses_GUID_CMAKE:INTERNAL=D1B279E0-10A7-4194-9D95-7B9DDB031155 //Stored GUID vtkInfovisLayoutJava_GUID_CMAKE:INTERNAL=F5884F39-62BF-43E3-8C3A-E48FCC00C707 //Stored GUID vtkInfovisLayout_GUID_CMAKE:INTERNAL=F2209870-1755-49BB-BFC0-2B5E099E1AD1 //Stored GUID vtkInteractionImageJavaJavaClasses_GUID_CMAKE:INTERNAL=55EF565C-7742-45F0-8DEF-FD29F4DCBCE2 //Stored GUID vtkInteractionImageJava_GUID_CMAKE:INTERNAL=785BA513-2C50-4487-AB64-EAE828957DEC //Stored GUID vtkInteractionImage_GUID_CMAKE:INTERNAL=0B7B57D0-5F6C-4028-9735-F3DC508F694D //Stored GUID vtkInteractionStyleJavaJavaClasses_GUID_CMAKE:INTERNAL=1BC35BCB-2E22-4186-A664-87FD27928632 //Stored GUID vtkInteractionStyleJava_GUID_CMAKE:INTERNAL=91F88AB2-9DAE-4916-A90C-D2EC5C35F428 //Stored GUID vtkInteractionStyle_GUID_CMAKE:INTERNAL=C88737FB-EDD4-4CE1-A710-1B71C0B7744F //Stored GUID vtkInteractionWidgetsJavaJavaClasses_GUID_CMAKE:INTERNAL=38FE2A76-8C81-40FA-B9ED-D20084783F2A //Stored GUID vtkInteractionWidgetsJava_GUID_CMAKE:INTERNAL=F12BB95B-8FB5-4C00-9DCA-883F19E54299 //Stored GUID vtkInteractionWidgets_GUID_CMAKE:INTERNAL=FD80E35F-B4DA-4D42-918E-D1BDB7ADF438 //Stored GUID vtkNetCDF_GUID_CMAKE:INTERNAL=C7F279E5-E646-419D-A624-21AED6D02816 //Stored GUID vtkNetCDF_cxx_GUID_CMAKE:INTERNAL=2ACB5A43-EEE1-4DB9-BE04-F66D47C0580E //Stored GUID vtkParallelCoreJavaJavaClasses_GUID_CMAKE:INTERNAL=2CF9C57A-8E3D-4FA1-9E38-3189C6F3F16E //Stored GUID vtkParallelCoreJava_GUID_CMAKE:INTERNAL=B7013AC1-A03D-4FB2-A01B-6A7303C1EB71 //Stored GUID vtkParallelCore_GUID_CMAKE:INTERNAL=A71FDC07-69BA-4E7F-BD2D-041D9AEFA8E8 //Stored GUID vtkParseJava_GUID_CMAKE:INTERNAL=EBBB27D2-EF67-42AA-BEF5-33F4F130B517 //Stored GUID vtkParseOGLExt_GUID_CMAKE:INTERNAL=AEB467E6-816B-456F-83A3-E349056156EF //Stored GUID vtkRenderingAnnotationJavaJavaClasses_GUID_CMAKE:INTERNAL=289A6F1C-45CE-489E-99DC-44C0544E21FC //Stored GUID vtkRenderingAnnotationJava_GUID_CMAKE:INTERNAL=870F8D12-2602-4EDE-9B79-90C5C3731107 //Stored GUID vtkRenderingAnnotation_GUID_CMAKE:INTERNAL=66CD352A-D6C2-4802-8F1D-ADFD1DF80F05 //Stored GUID vtkRenderingContext2DJavaJavaClasses_GUID_CMAKE:INTERNAL=EF4A9F01-990F-4892-AABC-0AA0D1E56020 //Stored GUID vtkRenderingContext2DJava_GUID_CMAKE:INTERNAL=023103D8-E4E9-4C32-A115-832AF2B3EA1A //Stored GUID vtkRenderingContext2D_GUID_CMAKE:INTERNAL=828302E5-B969-4B50-A602-96AB06F2BE89 //Stored GUID vtkRenderingCoreJavaJavaClasses_GUID_CMAKE:INTERNAL=4B0C785F-CC1A-457E-BF9F-5D23F184D67A //Stored GUID vtkRenderingCoreJava_GUID_CMAKE:INTERNAL=E89493C3-A62E-463A-B4C6-6972ADFCE2FB //Stored GUID vtkRenderingCore_GUID_CMAKE:INTERNAL=DB935AC8-15DF-4ECA-9726-39C1CCB6082F //Stored GUID vtkRenderingFreeTypeJavaJavaClasses_GUID_CMAKE:INTERNAL=0370B54B-9E47-453C-A659-C7D6232E4990 //Stored GUID vtkRenderingFreeTypeJava_GUID_CMAKE:INTERNAL=BC98A8B8-6E81-4484-A934-E599E9EC9F56 //Stored GUID vtkRenderingFreeTypeOpenGLJavaJavaClasses_GUID_CMAKE:INTERNAL=F2E2740D-CBC8-4A77-A3B7-D8F2B6E78834 //Stored GUID vtkRenderingFreeTypeOpenGLJava_GUID_CMAKE:INTERNAL=E1BA0E39-E9D2-471D-9184-86F02685E248 //Stored GUID vtkRenderingFreeTypeOpenGL_GUID_CMAKE:INTERNAL=F027AB0E-7E68-4F9C-BA61-7C5BA847EF12 //Stored GUID vtkRenderingFreeType_GUID_CMAKE:INTERNAL=68C0B97A-7DE7-491E-B468-210155302630 //Stored GUID vtkRenderingGL2PSJavaJavaClasses_GUID_CMAKE:INTERNAL=5FF4268B-4D19-440B-A92B-4EAA68527BE6 //Stored GUID vtkRenderingGL2PSJava_GUID_CMAKE:INTERNAL=B00DF63C-141D-44A3-AD71-DE6896F54E57 //Stored GUID vtkRenderingGL2PS_GUID_CMAKE:INTERNAL=9CE584B5-4433-4D8D-923C-EBE62D08E0C0 //Stored GUID vtkRenderingImageJavaJavaClasses_GUID_CMAKE:INTERNAL=4B8CECB4-9CAE-4143-97A9-3E0D1014B441 //Stored GUID vtkRenderingImageJava_GUID_CMAKE:INTERNAL=F14460DC-CDE2-4D2A-851C-143174E68D2A //Stored GUID vtkRenderingImage_GUID_CMAKE:INTERNAL=F063A0B6-F50E-42FF-A768-9F99BE3DBA35 //Stored GUID vtkRenderingLICJavaJavaClasses_GUID_CMAKE:INTERNAL=785E8F50-5D16-4FA4-BB58-CF38CA433974 //Stored GUID vtkRenderingLICJava_GUID_CMAKE:INTERNAL=D11446B2-AF71-4073-92AA-7362830F3E83 //Stored GUID vtkRenderingLIC_GUID_CMAKE:INTERNAL=528EC1C4-FD37-4247-8CC5-1EAA67BA7373 //Stored GUID vtkRenderingLODJavaJavaClasses_GUID_CMAKE:INTERNAL=656ED27B-39F8-4008-A592-CCE653109986 //Stored GUID vtkRenderingLODJava_GUID_CMAKE:INTERNAL=417B11BA-1789-45D1-8AE8-8EBDB8CE31FC //Stored GUID vtkRenderingLOD_GUID_CMAKE:INTERNAL=85429BB0-ABCE-4BC9-B065-204D306CE317 //Stored GUID vtkRenderingLabelJavaJavaClasses_GUID_CMAKE:INTERNAL=B2B95D67-3282-4154-A116-98BCE521AAD3 //Stored GUID vtkRenderingLabelJava_GUID_CMAKE:INTERNAL=2A006ADE-C310-478D-A4C6-E3107C23D6A3 //Stored GUID vtkRenderingLabel_GUID_CMAKE:INTERNAL=CE70ED41-D3B5-4D39-AB74-723B7527D779 //Stored GUID vtkRenderingOpenGLJavaJavaClasses_GUID_CMAKE:INTERNAL=574A2359-846B-4D73-9779-F969CE0B5CDE //Stored GUID vtkRenderingOpenGLJava_GUID_CMAKE:INTERNAL=8CA84807-9CEE-429A-AEBC-95DB923359A9 //Stored GUID vtkRenderingOpenGL_GUID_CMAKE:INTERNAL=59313646-0C4B-4C2F-9122-CF44090C8591 //Stored GUID vtkRenderingVolumeAMRJavaJavaClasses_GUID_CMAKE:INTERNAL=061C7692-A83D-4405-87AF-938EF85182AB //Stored GUID vtkRenderingVolumeAMRJava_GUID_CMAKE:INTERNAL=449DA65D-B001-4C08-BB1C-D52D71CF8BA7 //Stored GUID vtkRenderingVolumeAMR_GUID_CMAKE:INTERNAL=E8BFB258-0E02-4032-AAB7-0A7DC42F6A14 //Stored GUID vtkRenderingVolumeJavaJavaClasses_GUID_CMAKE:INTERNAL=7400A2FD-4184-4971-A870-A6082DA2BCDE //Stored GUID vtkRenderingVolumeJava_GUID_CMAKE:INTERNAL=BE731CFF-0039-4D60-A0FB-613F122443CF //Stored GUID vtkRenderingVolumeOpenGLJavaJavaClasses_GUID_CMAKE:INTERNAL=6AA240F5-171F-41BF-BE2E-E7E6DE8ACDE3 //Stored GUID vtkRenderingVolumeOpenGLJava_GUID_CMAKE:INTERNAL=A38DA4EF-5815-4DF2-BE12-5AC6E651047C //Stored GUID vtkRenderingVolumeOpenGL_GUID_CMAKE:INTERNAL=5FFD5981-2DEE-409C-9172-54D5C8D80FC2 //Stored GUID vtkRenderingVolume_GUID_CMAKE:INTERNAL=4752C172-01B7-4D47-8AD2-E025C92AA980 //Stored GUID vtkViewsContext2DJavaJavaClasses_GUID_CMAKE:INTERNAL=74D68C07-7567-4EDF-AC7C-0644034BB616 //Stored GUID vtkViewsContext2DJava_GUID_CMAKE:INTERNAL=47C8958B-25B8-4B9A-8A5C-B32AD3F16287 //Stored GUID vtkViewsContext2D_GUID_CMAKE:INTERNAL=4BA5E343-5939-4963-BB4A-97CB22892CBA //Stored GUID vtkViewsCoreJavaJavaClasses_GUID_CMAKE:INTERNAL=DFBDAC8E-D24F-41B3-B43E-DE1D7F794C55 //Stored GUID vtkViewsCoreJava_GUID_CMAKE:INTERNAL=017B6F92-1286-43CD-B23E-AA208F5A1248 //Stored GUID vtkViewsCore_GUID_CMAKE:INTERNAL=F63C3427-7D38-4E39-B70A-5479F79A3434 //Stored GUID vtkViewsGeovisJavaJavaClasses_GUID_CMAKE:INTERNAL=F08CD2C9-53CB-424B-A999-BB9FB6A9E5D0 //Stored GUID vtkViewsGeovisJava_GUID_CMAKE:INTERNAL=5C020961-D319-491D-9C77-3074E1DD0246 //Stored GUID vtkViewsGeovis_GUID_CMAKE:INTERNAL=A7800EE4-5D9D-4F77-B2D5-5A40C7683707 //Stored GUID vtkViewsInfovisJavaJavaClasses_GUID_CMAKE:INTERNAL=7D8E5582-5154-42DB-BB0E-9DD99F4B7709 //Stored GUID vtkViewsInfovisJava_GUID_CMAKE:INTERNAL=6F4B621A-3C7E-444F-B140-211D7C71F6D4 //Stored GUID vtkViewsInfovis_GUID_CMAKE:INTERNAL=BE196AB9-CA23-45DB-84A6-7D2C432D3CCB //Stored GUID vtkWrapHierarchy_GUID_CMAKE:INTERNAL=4423C9BD-12C8-4724-AEC1-E1F7D422CB1F //Stored GUID vtkWrapJava_GUID_CMAKE:INTERNAL=3EEB90FA-7BAC-481F-99F1-A953F2BEF64A //Stored GUID vtkWrapPythonInit_GUID_CMAKE:INTERNAL=BEF32204-44F6-465B-B5D6-6EB5C0971122 //Stored GUID vtkWrapPython_GUID_CMAKE:INTERNAL=3EEF6CEC-BEF9-4315-80BA-78DF6138041A //Stored GUID vtkWrapTclInit_GUID_CMAKE:INTERNAL=D2BB4676-0853-4710-A663-3F9CC3803BD8 //Stored GUID vtkWrapTcl_GUID_CMAKE:INTERNAL=08A05887-BF38-4EC7-8103-9E3BC14F4EEB //Stored GUID vtkWrappingJava_GUID_CMAKE:INTERNAL=FF71D313-BA62-4868-B996-E12A903B5F10 //Stored GUID vtkWrappingTools_GUID_CMAKE:INTERNAL=FCA672E3-D202-4C7F-A779-E0184F287615 //Stored GUID vtkalglib_GUID_CMAKE:INTERNAL=C1B7D21B-CA5C-44C2-A981-E3C7720D263B //Stored GUID vtkexoIIc_GUID_CMAKE:INTERNAL=2D638E13-8228-4A64-ABA0-91C59847CB02 //Stored GUID vtkexpat_GUID_CMAKE:INTERNAL=462D938C-1350-4AC1-8816-4DE2D27AA1D5 //Stored GUID vtkfreetype_GUID_CMAKE:INTERNAL=190DCBCD-4E86-4862-9358-208BCBF4FCFB //Stored GUID vtkftgl_GUID_CMAKE:INTERNAL=66D0AEDB-EBFE-4BFE-8A62-489D25C039A2 //Stored GUID vtkgl2ps_GUID_CMAKE:INTERNAL=0F966CFA-935C-4C56-B7F0-7328EFBB4ABF //Stored GUID vtkhdf5_GUID_CMAKE:INTERNAL=E289093C-4C6A-41FC-9B9B-FD5EAC0B90DE //Stored GUID vtkhdf5_hl_GUID_CMAKE:INTERNAL=3A95D620-8A7E-4B55-9A6E-8F3033CD86B5 //Stored GUID vtkjpeg_GUID_CMAKE:INTERNAL=0EE25FC4-25F0-48F4-A32F-49284801B265 //Stored GUID vtkjsoncpp_GUID_CMAKE:INTERNAL=7DE977E1-EC9B-4666-A483-EA618D5C996F //Stored GUID vtklibxml2_GUID_CMAKE:INTERNAL=5400A767-E0B8-40FE-B1BE-FEF071ABF953 //Stored GUID vtkmetaio_GUID_CMAKE:INTERNAL=D95DE1B3-71B3-4FD1-A8DB-B67E2BF08391 //Stored GUID vtkoggtheora_GUID_CMAKE:INTERNAL=3319C537-6846-4AFE-A938-F2406B5F40B3 //Stored GUID vtkpng_GUID_CMAKE:INTERNAL=29D8C931-BC5A-46BC-ADFC-D6D2E9F3ED31 //Stored GUID vtkproj4_GUID_CMAKE:INTERNAL=A1CB1A0F-2E3E-4BE9-ABC2-61CF51B941E3 //Stored GUID vtksqlite_GUID_CMAKE:INTERNAL=3E841608-9319-447A-BD8D-D768B2F28786 //Stored GUID vtksys_GUID_CMAKE:INTERNAL=E9F51C7A-5A6C-479A-BBE1-0631E8F4DB27 //Stored GUID vtktiff_GUID_CMAKE:INTERNAL=698AECB2-5CD5-4194-985B-4326DEF97C5D //Stored GUID vtkzlib_GUID_CMAKE:INTERNAL=C595AF0D-D452-44B3-B9D2-81546F3B174D From ee130002001 at iiti.ac.in Sun Mar 22 06:50:02 2015 From: ee130002001 at iiti.ac.in (Abhinav Tripathi) Date: Sun, 22 Mar 2015 16:20:02 +0530 Subject: [vtk-developers] [GSoc '15] Eulerian Magnification for Revealing Subtle Changes -- Proposal review request Message-ID: Hi, I am willing to work on the Eulerian Magnification project. I got to know much about how to approach the problem with the help of the mentors. I have submitted a proposal for the project on GSoC website. I hope that all the developers and mentors will review my proposal and help me improve my approach futher by providing feedback. . Abhinav -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Sun Mar 22 09:51:43 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Sun, 22 Mar 2015 09:51:43 -0400 Subject: [vtk-developers] gitlab-push woes In-Reply-To: <20150321162413.GA12388@bronto-burt.dev.benboeckel.net> References: <20150321162413.GA12388@bronto-burt.dev.benboeckel.net> Message-ID: >> 1) Make @buildbot and Do: consistent. It seems odd to do "Do: check" or >> "Do: merge" and then "@buildbot test". I would expect "Do: test" > > I agree, but currently these are managed by completely different tools. How about using @robot instead of Do:? That way, we are consistent: @robot merge @robot check @buildbot test >> 2) Recognition is better than remembering. How about adding support for 'help' e.g. @buildbot help @robot help And both will come back with a message describing the available actions and what they do. The first KWrobot check (which gets triggered automatically) can put a comment saying you can use "@buildbot help and @robot help for available actions". That way kwrobot doesn't need to be kept up-to-date with buildbot support commands (which will evolve -- just this weekend, I added a new command 'superbuild' to trigger a superbuild from a ParaView merge request). Utkarsh From sebastien.jourdain at kitware.com Sun Mar 22 10:18:35 2015 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Sun, 22 Mar 2015 08:18:35 -0600 Subject: [vtk-developers] Problems installing VTK In-Reply-To: References: Message-ID: <37F0F4BE-C015-452A-A752-B07317B5B42A@kitware.com> I didn't see anything strange but can you explain your build process? Which property you changed in cmake and how/what did you build in visual studio? Seb > On Mar 22, 2015, at 00:11, CSharpdotcom . wrote: > > OK, many thanks, I didn't know that there was such a file, this is > because I'm so new to VTK and CMake. The file is in the root folder > and is attached here. > > I look forward finally to getting this sorted out, as it has now tied > me up for about a week. > > Christopher Sharp > > On Sat, Mar 21, 2015 at 8:59 PM, Sebastien Jourdain > wrote: >> I didn't know you had a partial build of VTK. Can you share you >> CMakeCache.txt. >> >> You must have wrongly setup your build. >> >> Seb >> >> On Sat, Mar 21, 2015 at 6:05 PM, CSharpdotcom . >> wrote: >>> >>> Hello, >>> >>> Many thanks, but as I'm new ti VTK I don't know which libraries to >>> load. However, in looking at: >>> >>> http://www.vtk.org/Wiki/VTK/Examples/Java/Miscellaneous/Cone6 >>> >>> which has similar code. The statement: >>> >>> System.loadLibrary("vtkCommonJava"); >>> >>> doesn't load as there is no dll with that name in the folder >>> C:\VTK\bin\Release, but: >>> >>> System.loadLibrary("vtkCommonCoreJava"); >>> >>> does load correctly as there is a dll with that name. This applies to >>> a few other files, but not all of them. Without the required dlls >>> loaded, even if no errors are produced, the code will not execute. >>> >>> If I go back to the original code when I try and load everything, then >>> I get the error message: >>> >>> java.lang.UnsatisfiedLinkError: >>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>> libraries >>> >>> The file vtkChartsCoreJava.dll is present in that folder, so it is >>> loaded, but its dependencies cannot be found. This applies to quite a >>> few other dll files with dependencies, and I also get a list of a >>> large number files that were not loaded from the statement: >>> >>> if (!lib.IsLoaded()) System.out.println(lib.GetLibraryName() + " not >>> loaded"); >>> >>> inside the for-loop in an earlier message. >>> >>> It looks that without these large number of files, possibly all of >>> them, that have not been loaded the code will not work, even if I skip >>> over the bad loads or put the loop in a try-catch loop. This must >>> have something to do with the error message in the log during the >>> build process with Visual Studio Pro 2010 I did a few days ago. >>> >>> I don't fully understand the log, but the section where it failed is here: >>> >>> 112>Link: >>> 112> Creating library C:/VTK/lib/Release/vtkRenderingCoreJava.lib >>> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp >>> 114> vtkDepthPeeling_fs.cxx >>> 114> vtkGaussianBlurPassShader_fs.cxx >>> 114> vtkLighting_s.cxx >>> 114> vtkLightingHelper_s.cxx >>> 114> vtkOpenGLRenderer_PeelingFS.cxx >>> 114> vtkOpenGLPropertyDefaultPropFunc_fs.cxx >>> 114> vtkOpenGLPropertyDefaultPropFunc_vs.cxx >>> 112>vtkRenderWindowJava.obj : error LNK2019: unresolved external >>> symbol __imp__JAWT_GetAWT at 8 referenced in function >>> _Java_vtk_vtkPanel_RenderCreate at 12 >>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: >>> 1 unresolved externals >>> 114> vtkOpenGLPropertyDefaultMain_fs.cxx >>> 112> >>> 112>Build FAILED. >>> 112> >>> 112>Time Elapsed 00:01:32.30 >>> >>> Obviously vtkRenderingCoreJava.dll failed to link, which must be the >>> cause of the problems I'm having. This was the only failure, with the >>> other 387 compilations and linking successful. If this problem can be >>> fixed, I hope I will be home and dry. >>> >>> I would most appreciate you or someone else kindly getting this resolved. >>> >>> csharp >>> >>> On Sat, Mar 21, 2015 at 3:04 PM, Sebastien Jourdain >>> wrote: >>>> Try to load the libraries that you need to load instead of all of them. >>>> It >>>> seems that you didn't build everything (which is probably fine). >>>> >>>> Seb >>>> >>>> On Sat, Mar 21, 2015 at 2:58 PM, CSharpdotcom . >>>> wrote: >>>>> >>>>> I already had PATH=C:\VTK\bin\Release, and added ;%PATH% at the end, >>>>> but it still doesn't work, and get the following output: >>>>> >>>>> java.lang.UnsatisfiedLinkError: >>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>> libraries >>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) at >>>>> java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>> at java.lang.System.loadLibrary(System.java:1119) >>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>> at >>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >>>>> at >>>>> >>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >>>>> java.lang.UnsatisfiedLinkError: >>>>> C:\VTK\bin\Release\vtkDomainsChemistryJava.dll: Can't find dependent >>>>> libraries >>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>> at java.lang.System.loadLibrary(System.java:1119) >>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>> at >>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >>>>> at >>>>> >>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >>>>> ................... >>>>> >>>>> These error messages continue, then a list of files not loaded are >>>>> printed out, as given in the source code. >>>>> >>>>> Based on these error messages it's picking up the dll files in the >>>>> \Release folder, but it's unable to find other files that these dll >>>>> files depend on. >>>>> >>>>> Do you want a full listing of the Java source file? The >>>>> AwtConeRendering class starts off with: >>>>> >>>>> static { >>>>> System.out.println(System.getProperty("java.library.path")); >>>>> if (!vtkNativeLibrary.LoadAllNativeLibraries()) { >>>>> for (vtkNativeLibrary lib : vtkNativeLibrary.values()) { >>>>> if (!lib.IsLoaded()) { >>>>> System.out.println(lib.GetLibraryName() + " not loaded"); >>>>> } >>>>> } >>>>> } >>>>> vtkNativeLibrary.DisableOutputWindow(null); >>>>> } >>>>> >>>>> which is followed by the main() method, which contains statements such >>>>> as: >>>>> >>>>> vtkConeSource cone = new vtkConeSource(); >>>>> >>>>> csharp >>>>> >>>>> On Sat, Mar 21, 2015 at 10:26 AM, Sebastien Jourdain >>>>> wrote: >>>>>> Te java.library.path is not enough and you need to add into your >>>>>> environment >>>>>> PATH the following directory, C:\VTK\bin\Release. >>>>>> >>>>>> set PATH=C:\VTK\bin\Release;%PATH% >>>>>> >>>>>> Seb >>>>>> >>>>>> On Sat, Mar 21, 2015 at 10:33 AM, CSharpdotcom . >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I'm new to VTK and this is my first posting here or on any other >>>>>>> forum >>>>>>> related to VTK. >>>>>>> >>>>>>> I've been trying for about a week to get VTK installed and running >>>>>>> on >>>>>>> my computer. The project I'm working on is to use Java with VTK to >>>>>>> represent 3D graphics, which I hope to use with NetBeans 8.0.2. I >>>>>>> also have Visual Studio Pro 2010. >>>>>>> >>>>>>> After failed attempts in installing VTK 6.2.0 and the latest >>>>>>> version >>>>>>> of CMake, from the link >>>>>>> >>>>>>> http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk >>>>>>> I downloaded and unzipped VTK 6.1.0 and CMake 3.0.0, then installed >>>>>>> them. >>>>>>> >>>>>>> I then ran CMake according to the instructions on that link and >>>>>>> installed the generated code in the folder C:\VTK. I then clicked >>>>>>> on >>>>>>> the file VTK.sin in that folder, which opened up Visual Studio and >>>>>>> started compiling the code with a large number of modules in the >>>>>>> project. This took about an hour, and on completion, generated the >>>>>>> line at the end: >>>>>>> >>>>>>> Build: 387 succeeded, 1 failed, 0 up-to-date, 0 skipped >>>>>>> >>>>>>> I saved this in a file, which is very long, and after some effort >>>>>>> found the error message: >>>>>>> >>>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error >>>>>>> LNK1120: >>>>>>> 1 unresolved externals >>>>>>> >>>>>>> In the mean time I attempted to recompile the project, which was >>>>>>> much >>>>>>> quicker, and got the same message. In recompiled I checked the >>>>>>> "INSTALL" option, which had not previously been checked, although I >>>>>>> don't know if that is significant. >>>>>>> >>>>>>> Located in the folder \VTK\java\sample\rendering is the source file >>>>>>> AwTConeRendering.java, which apparently has not been compiled. I >>>>>>> created a NetBeans project and copied that file into it, then linked >>>>>>> vtk.jar in the folder \VTK\bin to the project, and all imports were >>>>>>> satisfied. In setting the Windows path to point to the dll files in >>>>>>> \VTK\bin\Release, the application appears to pick up the dll files >>>>>>> correctly, however, I get the following error message: >>>>>>> >>>>>>> java.lang.UnsatisfiedLinkError: >>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>>>> libraries >>>>>>> >>>>>>> repeated for many dll files. Incidentally, as Visual Studio dlls >>>>>>> are >>>>>>> all 32 bits, as far as I know, I set up NetBeans to use a 32 bit >>>>>>> JVM. >>>>>>> This had previously been tested successfully with a test dll I >>>>>>> created >>>>>>> with Visual Studio and could execute with NetBeans. >>>>>>> >>>>>>> This problem is presumably related to the first error mentioned >>>>>>> above, >>>>>>> and would be most grateful in getting this issue resolved. As I >>>>>>> said, >>>>>>> I'm new to VTK, and in fact only in the last couple of weeks have >>>>>>> tried for the first time to call a dll file from a Java application >>>>>>> on >>>>>>> a Windows computer. >>>>>>> >>>>>>> In the Java code I added the statement: >>>>>>> >>>>>>> System.out.println(System.getProperty("java.library.path")); >>>>>>> >>>>>>> to check that the path was correct, which is the case. >>>>>>> _______________________________________________ >>>>>>> Powered by www.kitware.com >>>>>>> >>>>>>> Visit other Kitware open-source projects at >>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>> >>>>>>> Search the list archives at: >>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>> >>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers > From ben.boeckel at kitware.com Sun Mar 22 11:18:37 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Sun, 22 Mar 2015 11:18:37 -0400 Subject: [vtk-developers] gitlab-push woes In-Reply-To: References: <20150321162413.GA12388@bronto-burt.dev.benboeckel.net> Message-ID: <20150322151836.GA21424@bronto-burt.dev.benboeckel.net> On Sun, Mar 22, 2015 at 09:51:43 -0400, Utkarsh Ayachit wrote: > How about using @robot instead of Do:? That way, we are consistent: > > @robot merge > @robot check > @buildbot test It would be @kwrobot first of all, but "Do:" parsing is done at the same time as all the other trailers (and is currently the *only* part of comments kwrobot looks at). Since "Do:" is, IMO, the longer-term solution, I'd like to work towards it being the consistent one. > >> 2) Recognition is better than remembering. > > How about adding support for 'help' e.g. > > @buildbot help > @robot help > > And both will come back with a message describing the available > actions and what they do. The first KWrobot check (which gets > triggered automatically) can put a comment saying you can use > "@buildbot help and @robot help for available actions". That way > kwrobot doesn't need to be kept up-to-date with buildbot support > commands (which will evolve -- just this weekend, I added a new > command 'superbuild' to trigger a superbuild from a ParaView merge > request). Well, commands can have arguments, but they aren't supported yet (as there haven't been any). That sounds like a better use of an argument rather than a separate command to me. The kwrobot help would likely just be a pointer back into the repo's documentation anyways, so adding a link on a successful check just removes the "help" noise altogether. --Ben From csharpdotcom at gmail.com Sun Mar 22 14:04:58 2015 From: csharpdotcom at gmail.com (CSharpdotcom .) Date: Sun, 22 Mar 2015 11:04:58 -0700 Subject: [vtk-developers] Problems installing VTK In-Reply-To: <37F0F4BE-C015-452A-A752-B07317B5B42A@kitware.com> References: <37F0F4BE-C015-452A-A752-B07317B5B42A@kitware.com> Message-ID: Many thanks for your message; what I will do now is backup my VTK folder, then instead of using Visual Studio 2010 Pro, I will download the latest version of Visual Studio C++ Express, which is 2013 I think, and try using DMake again form scratch. In the process I will note exactly what I did, so if these problems persist, I will have a record. csharp On Sun, Mar 22, 2015 at 7:18 AM, Sebastien Jourdain wrote: > I didn't see anything strange but can you explain your build process? Which property you changed in cmake and how/what did you build in visual studio? > > Seb > > > >> On Mar 22, 2015, at 00:11, CSharpdotcom . wrote: >> >> OK, many thanks, I didn't know that there was such a file, this is >> because I'm so new to VTK and CMake. The file is in the root folder >> and is attached here. >> >> I look forward finally to getting this sorted out, as it has now tied >> me up for about a week. >> >> Christopher Sharp >> >> On Sat, Mar 21, 2015 at 8:59 PM, Sebastien Jourdain >> wrote: >>> I didn't know you had a partial build of VTK. Can you share you >>> CMakeCache.txt. >>> >>> You must have wrongly setup your build. >>> >>> Seb >>> >>> On Sat, Mar 21, 2015 at 6:05 PM, CSharpdotcom . >>> wrote: >>>> >>>> Hello, >>>> >>>> Many thanks, but as I'm new ti VTK I don't know which libraries to >>>> load. However, in looking at: >>>> >>>> http://www.vtk.org/Wiki/VTK/Examples/Java/Miscellaneous/Cone6 >>>> >>>> which has similar code. The statement: >>>> >>>> System.loadLibrary("vtkCommonJava"); >>>> >>>> doesn't load as there is no dll with that name in the folder >>>> C:\VTK\bin\Release, but: >>>> >>>> System.loadLibrary("vtkCommonCoreJava"); >>>> >>>> does load correctly as there is a dll with that name. This applies to >>>> a few other files, but not all of them. Without the required dlls >>>> loaded, even if no errors are produced, the code will not execute. >>>> >>>> If I go back to the original code when I try and load everything, then >>>> I get the error message: >>>> >>>> java.lang.UnsatisfiedLinkError: >>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>> libraries >>>> >>>> The file vtkChartsCoreJava.dll is present in that folder, so it is >>>> loaded, but its dependencies cannot be found. This applies to quite a >>>> few other dll files with dependencies, and I also get a list of a >>>> large number files that were not loaded from the statement: >>>> >>>> if (!lib.IsLoaded()) System.out.println(lib.GetLibraryName() + " not >>>> loaded"); >>>> >>>> inside the for-loop in an earlier message. >>>> >>>> It looks that without these large number of files, possibly all of >>>> them, that have not been loaded the code will not work, even if I skip >>>> over the bad loads or put the loop in a try-catch loop. This must >>>> have something to do with the error message in the log during the >>>> build process with Visual Studio Pro 2010 I did a few days ago. >>>> >>>> I don't fully understand the log, but the section where it failed is here: >>>> >>>> 112>Link: >>>> 112> Creating library C:/VTK/lib/Release/vtkRenderingCoreJava.lib >>>> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp >>>> 114> vtkDepthPeeling_fs.cxx >>>> 114> vtkGaussianBlurPassShader_fs.cxx >>>> 114> vtkLighting_s.cxx >>>> 114> vtkLightingHelper_s.cxx >>>> 114> vtkOpenGLRenderer_PeelingFS.cxx >>>> 114> vtkOpenGLPropertyDefaultPropFunc_fs.cxx >>>> 114> vtkOpenGLPropertyDefaultPropFunc_vs.cxx >>>> 112>vtkRenderWindowJava.obj : error LNK2019: unresolved external >>>> symbol __imp__JAWT_GetAWT at 8 referenced in function >>>> _Java_vtk_vtkPanel_RenderCreate at 12 >>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: >>>> 1 unresolved externals >>>> 114> vtkOpenGLPropertyDefaultMain_fs.cxx >>>> 112> >>>> 112>Build FAILED. >>>> 112> >>>> 112>Time Elapsed 00:01:32.30 >>>> >>>> Obviously vtkRenderingCoreJava.dll failed to link, which must be the >>>> cause of the problems I'm having. This was the only failure, with the >>>> other 387 compilations and linking successful. If this problem can be >>>> fixed, I hope I will be home and dry. >>>> >>>> I would most appreciate you or someone else kindly getting this resolved. >>>> >>>> csharp >>>> >>>> On Sat, Mar 21, 2015 at 3:04 PM, Sebastien Jourdain >>>> wrote: >>>>> Try to load the libraries that you need to load instead of all of them. >>>>> It >>>>> seems that you didn't build everything (which is probably fine). >>>>> >>>>> Seb >>>>> >>>>> On Sat, Mar 21, 2015 at 2:58 PM, CSharpdotcom . >>>>> wrote: >>>>>> >>>>>> I already had PATH=C:\VTK\bin\Release, and added ;%PATH% at the end, >>>>>> but it still doesn't work, and get the following output: >>>>>> >>>>>> java.lang.UnsatisfiedLinkError: >>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>>> libraries >>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) at >>>>>> java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>>> at java.lang.System.loadLibrary(System.java:1119) >>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>>> at >>>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >>>>>> at >>>>>> >>>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >>>>>> java.lang.UnsatisfiedLinkError: >>>>>> C:\VTK\bin\Release\vtkDomainsChemistryJava.dll: Can't find dependent >>>>>> libraries >>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>>> at java.lang.System.loadLibrary(System.java:1119) >>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>>> at >>>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >>>>>> at >>>>>> >>>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >>>>>> ................... >>>>>> >>>>>> These error messages continue, then a list of files not loaded are >>>>>> printed out, as given in the source code. >>>>>> >>>>>> Based on these error messages it's picking up the dll files in the >>>>>> \Release folder, but it's unable to find other files that these dll >>>>>> files depend on. >>>>>> >>>>>> Do you want a full listing of the Java source file? The >>>>>> AwtConeRendering class starts off with: >>>>>> >>>>>> static { >>>>>> System.out.println(System.getProperty("java.library.path")); >>>>>> if (!vtkNativeLibrary.LoadAllNativeLibraries()) { >>>>>> for (vtkNativeLibrary lib : vtkNativeLibrary.values()) { >>>>>> if (!lib.IsLoaded()) { >>>>>> System.out.println(lib.GetLibraryName() + " not loaded"); >>>>>> } >>>>>> } >>>>>> } >>>>>> vtkNativeLibrary.DisableOutputWindow(null); >>>>>> } >>>>>> >>>>>> which is followed by the main() method, which contains statements such >>>>>> as: >>>>>> >>>>>> vtkConeSource cone = new vtkConeSource(); >>>>>> >>>>>> csharp >>>>>> >>>>>> On Sat, Mar 21, 2015 at 10:26 AM, Sebastien Jourdain >>>>>> wrote: >>>>>>> Te java.library.path is not enough and you need to add into your >>>>>>> environment >>>>>>> PATH the following directory, C:\VTK\bin\Release. >>>>>>> >>>>>>> set PATH=C:\VTK\bin\Release;%PATH% >>>>>>> >>>>>>> Seb >>>>>>> >>>>>>> On Sat, Mar 21, 2015 at 10:33 AM, CSharpdotcom . >>>>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I'm new to VTK and this is my first posting here or on any other >>>>>>>> forum >>>>>>>> related to VTK. >>>>>>>> >>>>>>>> I've been trying for about a week to get VTK installed and running >>>>>>>> on >>>>>>>> my computer. The project I'm working on is to use Java with VTK to >>>>>>>> represent 3D graphics, which I hope to use with NetBeans 8.0.2. I >>>>>>>> also have Visual Studio Pro 2010. >>>>>>>> >>>>>>>> After failed attempts in installing VTK 6.2.0 and the latest >>>>>>>> version >>>>>>>> of CMake, from the link >>>>>>>> >>>>>>>> http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk >>>>>>>> I downloaded and unzipped VTK 6.1.0 and CMake 3.0.0, then installed >>>>>>>> them. >>>>>>>> >>>>>>>> I then ran CMake according to the instructions on that link and >>>>>>>> installed the generated code in the folder C:\VTK. I then clicked >>>>>>>> on >>>>>>>> the file VTK.sin in that folder, which opened up Visual Studio and >>>>>>>> started compiling the code with a large number of modules in the >>>>>>>> project. This took about an hour, and on completion, generated the >>>>>>>> line at the end: >>>>>>>> >>>>>>>> Build: 387 succeeded, 1 failed, 0 up-to-date, 0 skipped >>>>>>>> >>>>>>>> I saved this in a file, which is very long, and after some effort >>>>>>>> found the error message: >>>>>>>> >>>>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error >>>>>>>> LNK1120: >>>>>>>> 1 unresolved externals >>>>>>>> >>>>>>>> In the mean time I attempted to recompile the project, which was >>>>>>>> much >>>>>>>> quicker, and got the same message. In recompiled I checked the >>>>>>>> "INSTALL" option, which had not previously been checked, although I >>>>>>>> don't know if that is significant. >>>>>>>> >>>>>>>> Located in the folder \VTK\java\sample\rendering is the source file >>>>>>>> AwTConeRendering.java, which apparently has not been compiled. I >>>>>>>> created a NetBeans project and copied that file into it, then linked >>>>>>>> vtk.jar in the folder \VTK\bin to the project, and all imports were >>>>>>>> satisfied. In setting the Windows path to point to the dll files in >>>>>>>> \VTK\bin\Release, the application appears to pick up the dll files >>>>>>>> correctly, however, I get the following error message: >>>>>>>> >>>>>>>> java.lang.UnsatisfiedLinkError: >>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>>>>> libraries >>>>>>>> >>>>>>>> repeated for many dll files. Incidentally, as Visual Studio dlls >>>>>>>> are >>>>>>>> all 32 bits, as far as I know, I set up NetBeans to use a 32 bit >>>>>>>> JVM. >>>>>>>> This had previously been tested successfully with a test dll I >>>>>>>> created >>>>>>>> with Visual Studio and could execute with NetBeans. >>>>>>>> >>>>>>>> This problem is presumably related to the first error mentioned >>>>>>>> above, >>>>>>>> and would be most grateful in getting this issue resolved. As I >>>>>>>> said, >>>>>>>> I'm new to VTK, and in fact only in the last couple of weeks have >>>>>>>> tried for the first time to call a dll file from a Java application >>>>>>>> on >>>>>>>> a Windows computer. >>>>>>>> >>>>>>>> In the Java code I added the statement: >>>>>>>> >>>>>>>> System.out.println(System.getProperty("java.library.path")); >>>>>>>> >>>>>>>> to check that the path was correct, which is the case. >>>>>>>> _______________________________________________ >>>>>>>> Powered by www.kitware.com >>>>>>>> >>>>>>>> Visit other Kitware open-source projects at >>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>> >>>>>>>> Search the list archives at: >>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>> >>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >> From csharpdotcom at gmail.com Sun Mar 22 17:05:28 2015 From: csharpdotcom at gmail.com (CSharpdotcom .) Date: Sun, 22 Mar 2015 14:05:28 -0700 Subject: [vtk-developers] Problems installing VTK In-Reply-To: References: <37F0F4BE-C015-452A-A752-B07317B5B42A@kitware.com> Message-ID: Hello, I decided not to install Visual Studio Express, as according to the website Visual Studio Pro was used, which is exactly what I've been using. Anyway, I created a new build folder and repeated the whole process from scratch. The error I'm still getting is: 117>Link: 117> Creating library C:/VTK/lib/Release/vtkRenderingCoreJava.lib and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp 117>vtkRenderWindowJava.obj : error LNK2019: unresolved external symbol __imp__JAWT_GetAWT at 8 referenced in function _Java_vtk_vtkPanel_RenderCreate at 12 117>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: 1 unresolved externals 124> Generating Code... 117> 117>Build FAILED. which is almost certainly due to Visual Studio trying to use 64 bit Java, which is incompatible with the 32 bit code it generates. I was unaware that Visual Studio has to use Java. This should be easy to fix by setting the path it uses to a 32 JVM. In addition, there are two other errors which appear to be related to the components VTK_JAVA_SWT_COMPONENT and VTK_JAVA_SWT_COMPONENT checked in the DMake window, which seem not to be installed in my system. What do they do, and are they needed for what I want to do? If so, I need to find out how to install them, otherwise they can presumably be ignored. Christopher Sharp On Sun, Mar 22, 2015 at 11:04 AM, CSharpdotcom . wrote: > Many thanks for your message; what I will do now is backup my VTK > folder, then instead of using Visual Studio 2010 Pro, I will download > the latest version of Visual Studio C++ Express, which is 2013 I > think, and try using DMake again form scratch. In the process I will > note exactly what I did, so if these problems persist, I will have a > record. > > csharp > > On Sun, Mar 22, 2015 at 7:18 AM, Sebastien Jourdain > wrote: >> I didn't see anything strange but can you explain your build process? Which property you changed in cmake and how/what did you build in visual studio? >> >> Seb >> >> >> >>> On Mar 22, 2015, at 00:11, CSharpdotcom . wrote: >>> >>> OK, many thanks, I didn't know that there was such a file, this is >>> because I'm so new to VTK and CMake. The file is in the root folder >>> and is attached here. >>> >>> I look forward finally to getting this sorted out, as it has now tied >>> me up for about a week. >>> >>> Christopher Sharp >>> >>> On Sat, Mar 21, 2015 at 8:59 PM, Sebastien Jourdain >>> wrote: >>>> I didn't know you had a partial build of VTK. Can you share you >>>> CMakeCache.txt. >>>> >>>> You must have wrongly setup your build. >>>> >>>> Seb >>>> >>>> On Sat, Mar 21, 2015 at 6:05 PM, CSharpdotcom . >>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> Many thanks, but as I'm new ti VTK I don't know which libraries to >>>>> load. However, in looking at: >>>>> >>>>> http://www.vtk.org/Wiki/VTK/Examples/Java/Miscellaneous/Cone6 >>>>> >>>>> which has similar code. The statement: >>>>> >>>>> System.loadLibrary("vtkCommonJava"); >>>>> >>>>> doesn't load as there is no dll with that name in the folder >>>>> C:\VTK\bin\Release, but: >>>>> >>>>> System.loadLibrary("vtkCommonCoreJava"); >>>>> >>>>> does load correctly as there is a dll with that name. This applies to >>>>> a few other files, but not all of them. Without the required dlls >>>>> loaded, even if no errors are produced, the code will not execute. >>>>> >>>>> If I go back to the original code when I try and load everything, then >>>>> I get the error message: >>>>> >>>>> java.lang.UnsatisfiedLinkError: >>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>> libraries >>>>> >>>>> The file vtkChartsCoreJava.dll is present in that folder, so it is >>>>> loaded, but its dependencies cannot be found. This applies to quite a >>>>> few other dll files with dependencies, and I also get a list of a >>>>> large number files that were not loaded from the statement: >>>>> >>>>> if (!lib.IsLoaded()) System.out.println(lib.GetLibraryName() + " not >>>>> loaded"); >>>>> >>>>> inside the for-loop in an earlier message. >>>>> >>>>> It looks that without these large number of files, possibly all of >>>>> them, that have not been loaded the code will not work, even if I skip >>>>> over the bad loads or put the loop in a try-catch loop. This must >>>>> have something to do with the error message in the log during the >>>>> build process with Visual Studio Pro 2010 I did a few days ago. >>>>> >>>>> I don't fully understand the log, but the section where it failed is here: >>>>> >>>>> 112>Link: >>>>> 112> Creating library C:/VTK/lib/Release/vtkRenderingCoreJava.lib >>>>> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp >>>>> 114> vtkDepthPeeling_fs.cxx >>>>> 114> vtkGaussianBlurPassShader_fs.cxx >>>>> 114> vtkLighting_s.cxx >>>>> 114> vtkLightingHelper_s.cxx >>>>> 114> vtkOpenGLRenderer_PeelingFS.cxx >>>>> 114> vtkOpenGLPropertyDefaultPropFunc_fs.cxx >>>>> 114> vtkOpenGLPropertyDefaultPropFunc_vs.cxx >>>>> 112>vtkRenderWindowJava.obj : error LNK2019: unresolved external >>>>> symbol __imp__JAWT_GetAWT at 8 referenced in function >>>>> _Java_vtk_vtkPanel_RenderCreate at 12 >>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: >>>>> 1 unresolved externals >>>>> 114> vtkOpenGLPropertyDefaultMain_fs.cxx >>>>> 112> >>>>> 112>Build FAILED. >>>>> 112> >>>>> 112>Time Elapsed 00:01:32.30 >>>>> >>>>> Obviously vtkRenderingCoreJava.dll failed to link, which must be the >>>>> cause of the problems I'm having. This was the only failure, with the >>>>> other 387 compilations and linking successful. If this problem can be >>>>> fixed, I hope I will be home and dry. >>>>> >>>>> I would most appreciate you or someone else kindly getting this resolved. >>>>> >>>>> csharp >>>>> >>>>> On Sat, Mar 21, 2015 at 3:04 PM, Sebastien Jourdain >>>>> wrote: >>>>>> Try to load the libraries that you need to load instead of all of them. >>>>>> It >>>>>> seems that you didn't build everything (which is probably fine). >>>>>> >>>>>> Seb >>>>>> >>>>>> On Sat, Mar 21, 2015 at 2:58 PM, CSharpdotcom . >>>>>> wrote: >>>>>>> >>>>>>> I already had PATH=C:\VTK\bin\Release, and added ;%PATH% at the end, >>>>>>> but it still doesn't work, and get the following output: >>>>>>> >>>>>>> java.lang.UnsatisfiedLinkError: >>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>>>> libraries >>>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) at >>>>>>> java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>>>> at java.lang.System.loadLibrary(System.java:1119) >>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>>>> at >>>>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >>>>>>> at >>>>>>> >>>>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >>>>>>> java.lang.UnsatisfiedLinkError: >>>>>>> C:\VTK\bin\Release\vtkDomainsChemistryJava.dll: Can't find dependent >>>>>>> libraries >>>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>>>> at java.lang.System.loadLibrary(System.java:1119) >>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>>>> at >>>>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >>>>>>> at >>>>>>> >>>>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >>>>>>> ................... >>>>>>> >>>>>>> These error messages continue, then a list of files not loaded are >>>>>>> printed out, as given in the source code. >>>>>>> >>>>>>> Based on these error messages it's picking up the dll files in the >>>>>>> \Release folder, but it's unable to find other files that these dll >>>>>>> files depend on. >>>>>>> >>>>>>> Do you want a full listing of the Java source file? The >>>>>>> AwtConeRendering class starts off with: >>>>>>> >>>>>>> static { >>>>>>> System.out.println(System.getProperty("java.library.path")); >>>>>>> if (!vtkNativeLibrary.LoadAllNativeLibraries()) { >>>>>>> for (vtkNativeLibrary lib : vtkNativeLibrary.values()) { >>>>>>> if (!lib.IsLoaded()) { >>>>>>> System.out.println(lib.GetLibraryName() + " not loaded"); >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> vtkNativeLibrary.DisableOutputWindow(null); >>>>>>> } >>>>>>> >>>>>>> which is followed by the main() method, which contains statements such >>>>>>> as: >>>>>>> >>>>>>> vtkConeSource cone = new vtkConeSource(); >>>>>>> >>>>>>> csharp >>>>>>> >>>>>>> On Sat, Mar 21, 2015 at 10:26 AM, Sebastien Jourdain >>>>>>> wrote: >>>>>>>> Te java.library.path is not enough and you need to add into your >>>>>>>> environment >>>>>>>> PATH the following directory, C:\VTK\bin\Release. >>>>>>>> >>>>>>>> set PATH=C:\VTK\bin\Release;%PATH% >>>>>>>> >>>>>>>> Seb >>>>>>>> >>>>>>>> On Sat, Mar 21, 2015 at 10:33 AM, CSharpdotcom . >>>>>>>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I'm new to VTK and this is my first posting here or on any other >>>>>>>>> forum >>>>>>>>> related to VTK. >>>>>>>>> >>>>>>>>> I've been trying for about a week to get VTK installed and running >>>>>>>>> on >>>>>>>>> my computer. The project I'm working on is to use Java with VTK to >>>>>>>>> represent 3D graphics, which I hope to use with NetBeans 8.0.2. I >>>>>>>>> also have Visual Studio Pro 2010. >>>>>>>>> >>>>>>>>> After failed attempts in installing VTK 6.2.0 and the latest >>>>>>>>> version >>>>>>>>> of CMake, from the link >>>>>>>>> >>>>>>>>> http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk >>>>>>>>> I downloaded and unzipped VTK 6.1.0 and CMake 3.0.0, then installed >>>>>>>>> them. >>>>>>>>> >>>>>>>>> I then ran CMake according to the instructions on that link and >>>>>>>>> installed the generated code in the folder C:\VTK. I then clicked >>>>>>>>> on >>>>>>>>> the file VTK.sin in that folder, which opened up Visual Studio and >>>>>>>>> started compiling the code with a large number of modules in the >>>>>>>>> project. This took about an hour, and on completion, generated the >>>>>>>>> line at the end: >>>>>>>>> >>>>>>>>> Build: 387 succeeded, 1 failed, 0 up-to-date, 0 skipped >>>>>>>>> >>>>>>>>> I saved this in a file, which is very long, and after some effort >>>>>>>>> found the error message: >>>>>>>>> >>>>>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error >>>>>>>>> LNK1120: >>>>>>>>> 1 unresolved externals >>>>>>>>> >>>>>>>>> In the mean time I attempted to recompile the project, which was >>>>>>>>> much >>>>>>>>> quicker, and got the same message. In recompiled I checked the >>>>>>>>> "INSTALL" option, which had not previously been checked, although I >>>>>>>>> don't know if that is significant. >>>>>>>>> >>>>>>>>> Located in the folder \VTK\java\sample\rendering is the source file >>>>>>>>> AwTConeRendering.java, which apparently has not been compiled. I >>>>>>>>> created a NetBeans project and copied that file into it, then linked >>>>>>>>> vtk.jar in the folder \VTK\bin to the project, and all imports were >>>>>>>>> satisfied. In setting the Windows path to point to the dll files in >>>>>>>>> \VTK\bin\Release, the application appears to pick up the dll files >>>>>>>>> correctly, however, I get the following error message: >>>>>>>>> >>>>>>>>> java.lang.UnsatisfiedLinkError: >>>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>>>>>> libraries >>>>>>>>> >>>>>>>>> repeated for many dll files. Incidentally, as Visual Studio dlls >>>>>>>>> are >>>>>>>>> all 32 bits, as far as I know, I set up NetBeans to use a 32 bit >>>>>>>>> JVM. >>>>>>>>> This had previously been tested successfully with a test dll I >>>>>>>>> created >>>>>>>>> with Visual Studio and could execute with NetBeans. >>>>>>>>> >>>>>>>>> This problem is presumably related to the first error mentioned >>>>>>>>> above, >>>>>>>>> and would be most grateful in getting this issue resolved. As I >>>>>>>>> said, >>>>>>>>> I'm new to VTK, and in fact only in the last couple of weeks have >>>>>>>>> tried for the first time to call a dll file from a Java application >>>>>>>>> on >>>>>>>>> a Windows computer. >>>>>>>>> >>>>>>>>> In the Java code I added the statement: >>>>>>>>> >>>>>>>>> System.out.println(System.getProperty("java.library.path")); >>>>>>>>> >>>>>>>>> to check that the path was correct, which is the case. >>>>>>>>> _______________________________________________ >>>>>>>>> Powered by www.kitware.com >>>>>>>>> >>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>> >>>>>>>>> Search the list archives at: >>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>>> >>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> From sebastien.jourdain at kitware.com Sun Mar 22 23:58:15 2015 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Sun, 22 Mar 2015 22:58:15 -0500 Subject: [vtk-developers] Problems installing VTK In-Reply-To: References: <37F0F4BE-C015-452A-A752-B07317B5B42A@kitware.com> Message-ID: <8E906FE3-B09F-4915-BD96-49028C996A23@kitware.com> You need to properly set cmake so you don't build the swt nor the Jogl components for Java. (You don't need them as you don't know what they are.) Moreover the jvm 32b should also be set via cmake. Otherwise VTK won't build correctly. Seb > On Mar 22, 2015, at 16:05, CSharpdotcom . wrote: > > Hello, > > I decided not to install Visual Studio Express, as according to the > website Visual Studio Pro was used, which is exactly what I've been > using. > > Anyway, I created a new build folder and repeated the whole process > from scratch. The error I'm still getting is: > > 117>Link: > 117> Creating library C:/VTK/lib/Release/vtkRenderingCoreJava.lib > and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp > 117>vtkRenderWindowJava.obj : error LNK2019: unresolved external > symbol __imp__JAWT_GetAWT at 8 referenced in function > _Java_vtk_vtkPanel_RenderCreate at 12 > 117>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: > 1 unresolved externals > 124> Generating Code... > 117> > 117>Build FAILED. > > which is almost certainly due to Visual Studio trying to use 64 bit > Java, which is incompatible with the 32 bit code it generates. I was > unaware that Visual Studio has to use Java. This should be easy to > fix by setting the path it uses to a 32 JVM. > > In addition, there are two other errors which appear to be related to > the components VTK_JAVA_SWT_COMPONENT and VTK_JAVA_SWT_COMPONENT > checked in the DMake window, which seem not to be installed in my > system. What do they do, and are they needed for what I want to do? > If so, I need to find out how to install them, otherwise they can > presumably be ignored. > > Christopher Sharp > >> On Sun, Mar 22, 2015 at 11:04 AM, CSharpdotcom . wrote: >> Many thanks for your message; what I will do now is backup my VTK >> folder, then instead of using Visual Studio 2010 Pro, I will download >> the latest version of Visual Studio C++ Express, which is 2013 I >> think, and try using DMake again form scratch. In the process I will >> note exactly what I did, so if these problems persist, I will have a >> record. >> >> csharp >> >> On Sun, Mar 22, 2015 at 7:18 AM, Sebastien Jourdain >> wrote: >>> I didn't see anything strange but can you explain your build process? Which property you changed in cmake and how/what did you build in visual studio? >>> >>> Seb >>> >>> >>> >>>> On Mar 22, 2015, at 00:11, CSharpdotcom . wrote: >>>> >>>> OK, many thanks, I didn't know that there was such a file, this is >>>> because I'm so new to VTK and CMake. The file is in the root folder >>>> and is attached here. >>>> >>>> I look forward finally to getting this sorted out, as it has now tied >>>> me up for about a week. >>>> >>>> Christopher Sharp >>>> >>>> On Sat, Mar 21, 2015 at 8:59 PM, Sebastien Jourdain >>>> wrote: >>>>> I didn't know you had a partial build of VTK. Can you share you >>>>> CMakeCache.txt. >>>>> >>>>> You must have wrongly setup your build. >>>>> >>>>> Seb >>>>> >>>>> On Sat, Mar 21, 2015 at 6:05 PM, CSharpdotcom . >>>>> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Many thanks, but as I'm new ti VTK I don't know which libraries to >>>>>> load. However, in looking at: >>>>>> >>>>>> http://www.vtk.org/Wiki/VTK/Examples/Java/Miscellaneous/Cone6 >>>>>> >>>>>> which has similar code. The statement: >>>>>> >>>>>> System.loadLibrary("vtkCommonJava"); >>>>>> >>>>>> doesn't load as there is no dll with that name in the folder >>>>>> C:\VTK\bin\Release, but: >>>>>> >>>>>> System.loadLibrary("vtkCommonCoreJava"); >>>>>> >>>>>> does load correctly as there is a dll with that name. This applies to >>>>>> a few other files, but not all of them. Without the required dlls >>>>>> loaded, even if no errors are produced, the code will not execute. >>>>>> >>>>>> If I go back to the original code when I try and load everything, then >>>>>> I get the error message: >>>>>> >>>>>> java.lang.UnsatisfiedLinkError: >>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>>> libraries >>>>>> >>>>>> The file vtkChartsCoreJava.dll is present in that folder, so it is >>>>>> loaded, but its dependencies cannot be found. This applies to quite a >>>>>> few other dll files with dependencies, and I also get a list of a >>>>>> large number files that were not loaded from the statement: >>>>>> >>>>>> if (!lib.IsLoaded()) System.out.println(lib.GetLibraryName() + " not >>>>>> loaded"); >>>>>> >>>>>> inside the for-loop in an earlier message. >>>>>> >>>>>> It looks that without these large number of files, possibly all of >>>>>> them, that have not been loaded the code will not work, even if I skip >>>>>> over the bad loads or put the loop in a try-catch loop. This must >>>>>> have something to do with the error message in the log during the >>>>>> build process with Visual Studio Pro 2010 I did a few days ago. >>>>>> >>>>>> I don't fully understand the log, but the section where it failed is here: >>>>>> >>>>>> 112>Link: >>>>>> 112> Creating library C:/VTK/lib/Release/vtkRenderingCoreJava.lib >>>>>> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp >>>>>> 114> vtkDepthPeeling_fs.cxx >>>>>> 114> vtkGaussianBlurPassShader_fs.cxx >>>>>> 114> vtkLighting_s.cxx >>>>>> 114> vtkLightingHelper_s.cxx >>>>>> 114> vtkOpenGLRenderer_PeelingFS.cxx >>>>>> 114> vtkOpenGLPropertyDefaultPropFunc_fs.cxx >>>>>> 114> vtkOpenGLPropertyDefaultPropFunc_vs.cxx >>>>>> 112>vtkRenderWindowJava.obj : error LNK2019: unresolved external >>>>>> symbol __imp__JAWT_GetAWT at 8 referenced in function >>>>>> _Java_vtk_vtkPanel_RenderCreate at 12 >>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: >>>>>> 1 unresolved externals >>>>>> 114> vtkOpenGLPropertyDefaultMain_fs.cxx >>>>>> 112> >>>>>> 112>Build FAILED. >>>>>> 112> >>>>>> 112>Time Elapsed 00:01:32.30 >>>>>> >>>>>> Obviously vtkRenderingCoreJava.dll failed to link, which must be the >>>>>> cause of the problems I'm having. This was the only failure, with the >>>>>> other 387 compilations and linking successful. If this problem can be >>>>>> fixed, I hope I will be home and dry. >>>>>> >>>>>> I would most appreciate you or someone else kindly getting this resolved. >>>>>> >>>>>> csharp >>>>>> >>>>>> On Sat, Mar 21, 2015 at 3:04 PM, Sebastien Jourdain >>>>>> wrote: >>>>>>> Try to load the libraries that you need to load instead of all of them. >>>>>>> It >>>>>>> seems that you didn't build everything (which is probably fine). >>>>>>> >>>>>>> Seb >>>>>>> >>>>>>> On Sat, Mar 21, 2015 at 2:58 PM, CSharpdotcom . >>>>>>> wrote: >>>>>>>> >>>>>>>> I already had PATH=C:\VTK\bin\Release, and added ;%PATH% at the end, >>>>>>>> but it still doesn't work, and get the following output: >>>>>>>> >>>>>>>> java.lang.UnsatisfiedLinkError: >>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>>>>> libraries >>>>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) at >>>>>>>> java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>>>>> at java.lang.System.loadLibrary(System.java:1119) >>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>>>>> at >>>>>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >>>>>>>> at >>>>>>>> >>>>>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >>>>>>>> java.lang.UnsatisfiedLinkError: >>>>>>>> C:\VTK\bin\Release\vtkDomainsChemistryJava.dll: Can't find dependent >>>>>>>> libraries >>>>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>>>>> at java.lang.System.loadLibrary(System.java:1119) >>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>>>>> at >>>>>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >>>>>>>> at >>>>>>>> >>>>>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >>>>>>>> ................... >>>>>>>> >>>>>>>> These error messages continue, then a list of files not loaded are >>>>>>>> printed out, as given in the source code. >>>>>>>> >>>>>>>> Based on these error messages it's picking up the dll files in the >>>>>>>> \Release folder, but it's unable to find other files that these dll >>>>>>>> files depend on. >>>>>>>> >>>>>>>> Do you want a full listing of the Java source file? The >>>>>>>> AwtConeRendering class starts off with: >>>>>>>> >>>>>>>> static { >>>>>>>> System.out.println(System.getProperty("java.library.path")); >>>>>>>> if (!vtkNativeLibrary.LoadAllNativeLibraries()) { >>>>>>>> for (vtkNativeLibrary lib : vtkNativeLibrary.values()) { >>>>>>>> if (!lib.IsLoaded()) { >>>>>>>> System.out.println(lib.GetLibraryName() + " not loaded"); >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> vtkNativeLibrary.DisableOutputWindow(null); >>>>>>>> } >>>>>>>> >>>>>>>> which is followed by the main() method, which contains statements such >>>>>>>> as: >>>>>>>> >>>>>>>> vtkConeSource cone = new vtkConeSource(); >>>>>>>> >>>>>>>> csharp >>>>>>>> >>>>>>>> On Sat, Mar 21, 2015 at 10:26 AM, Sebastien Jourdain >>>>>>>> wrote: >>>>>>>>> Te java.library.path is not enough and you need to add into your >>>>>>>>> environment >>>>>>>>> PATH the following directory, C:\VTK\bin\Release. >>>>>>>>> >>>>>>>>> set PATH=C:\VTK\bin\Release;%PATH% >>>>>>>>> >>>>>>>>> Seb >>>>>>>>> >>>>>>>>> On Sat, Mar 21, 2015 at 10:33 AM, CSharpdotcom . >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I'm new to VTK and this is my first posting here or on any other >>>>>>>>>> forum >>>>>>>>>> related to VTK. >>>>>>>>>> >>>>>>>>>> I've been trying for about a week to get VTK installed and running >>>>>>>>>> on >>>>>>>>>> my computer. The project I'm working on is to use Java with VTK to >>>>>>>>>> represent 3D graphics, which I hope to use with NetBeans 8.0.2. I >>>>>>>>>> also have Visual Studio Pro 2010. >>>>>>>>>> >>>>>>>>>> After failed attempts in installing VTK 6.2.0 and the latest >>>>>>>>>> version >>>>>>>>>> of CMake, from the link >>>>>>>>>> >>>>>>>>>> http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk >>>>>>>>>> I downloaded and unzipped VTK 6.1.0 and CMake 3.0.0, then installed >>>>>>>>>> them. >>>>>>>>>> >>>>>>>>>> I then ran CMake according to the instructions on that link and >>>>>>>>>> installed the generated code in the folder C:\VTK. I then clicked >>>>>>>>>> on >>>>>>>>>> the file VTK.sin in that folder, which opened up Visual Studio and >>>>>>>>>> started compiling the code with a large number of modules in the >>>>>>>>>> project. This took about an hour, and on completion, generated the >>>>>>>>>> line at the end: >>>>>>>>>> >>>>>>>>>> Build: 387 succeeded, 1 failed, 0 up-to-date, 0 skipped >>>>>>>>>> >>>>>>>>>> I saved this in a file, which is very long, and after some effort >>>>>>>>>> found the error message: >>>>>>>>>> >>>>>>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error >>>>>>>>>> LNK1120: >>>>>>>>>> 1 unresolved externals >>>>>>>>>> >>>>>>>>>> In the mean time I attempted to recompile the project, which was >>>>>>>>>> much >>>>>>>>>> quicker, and got the same message. In recompiled I checked the >>>>>>>>>> "INSTALL" option, which had not previously been checked, although I >>>>>>>>>> don't know if that is significant. >>>>>>>>>> >>>>>>>>>> Located in the folder \VTK\java\sample\rendering is the source file >>>>>>>>>> AwTConeRendering.java, which apparently has not been compiled. I >>>>>>>>>> created a NetBeans project and copied that file into it, then linked >>>>>>>>>> vtk.jar in the folder \VTK\bin to the project, and all imports were >>>>>>>>>> satisfied. In setting the Windows path to point to the dll files in >>>>>>>>>> \VTK\bin\Release, the application appears to pick up the dll files >>>>>>>>>> correctly, however, I get the following error message: >>>>>>>>>> >>>>>>>>>> java.lang.UnsatisfiedLinkError: >>>>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>>>>>>> libraries >>>>>>>>>> >>>>>>>>>> repeated for many dll files. Incidentally, as Visual Studio dlls >>>>>>>>>> are >>>>>>>>>> all 32 bits, as far as I know, I set up NetBeans to use a 32 bit >>>>>>>>>> JVM. >>>>>>>>>> This had previously been tested successfully with a test dll I >>>>>>>>>> created >>>>>>>>>> with Visual Studio and could execute with NetBeans. >>>>>>>>>> >>>>>>>>>> This problem is presumably related to the first error mentioned >>>>>>>>>> above, >>>>>>>>>> and would be most grateful in getting this issue resolved. As I >>>>>>>>>> said, >>>>>>>>>> I'm new to VTK, and in fact only in the last couple of weeks have >>>>>>>>>> tried for the first time to call a dll file from a Java application >>>>>>>>>> on >>>>>>>>>> a Windows computer. >>>>>>>>>> >>>>>>>>>> In the Java code I added the statement: >>>>>>>>>> >>>>>>>>>> System.out.println(System.getProperty("java.library.path")); >>>>>>>>>> >>>>>>>>>> to check that the path was correct, which is the case. >>>>>>>>>> _______________________________________________ >>>>>>>>>> Powered by www.kitware.com >>>>>>>>>> >>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>> >>>>>>>>>> Search the list archives at: >>>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>>>> >>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> From csharpdotcom at gmail.com Mon Mar 23 00:46:29 2015 From: csharpdotcom at gmail.com (CSharpdotcom .) Date: Sun, 22 Mar 2015 21:46:29 -0700 Subject: [vtk-developers] Problems installing VTK In-Reply-To: <8E906FE3-B09F-4915-BD96-49028C996A23@kitware.com> References: <37F0F4BE-C015-452A-A752-B07317B5B42A@kitware.com> <8E906FE3-B09F-4915-BD96-49028C996A23@kitware.com> Message-ID: Before I saw your message I tried building from scratch again, but still have errors. I didn't see in the link: https://www.particleincell.com/2011/vtk-java-visualization/ anything about using 32 bit Java in CMake, but it does say it has to be used with Visual Studio. After Googling around, I saw that the path environmental variable has to be set to the 32 bit Java, so I used C:\Program Files (x86)\Java\jre1.0.0_31\bin\client, where the file jvm.dll is located. I will now try again from scratch, with CMake using 32 bit Java. I've just set on my Windows 8 computer the following paths: JAVA_HOME = C:\Progra~2\Java\jdg1.8.0_31 PATH = C:\Program Files (x86)\jre1.8.-_31\bin and will reboot and start again. Christopher Sharp On Sun, Mar 22, 2015 at 8:58 PM, Sebastien Jourdain wrote: > You need to properly set cmake so you don't build the swt nor the Jogl components for Java. (You don't need them as you don't know what they are.) Moreover the jvm 32b should also be set via cmake. Otherwise VTK won't build correctly. > > Seb > >> On Mar 22, 2015, at 16:05, CSharpdotcom . wrote: >> >> Hello, >> >> I decided not to install Visual Studio Express, as according to the >> website Visual Studio Pro was used, which is exactly what I've been >> using. >> >> Anyway, I created a new build folder and repeated the whole process >> from scratch. The error I'm still getting is: >> >> 117>Link: >> 117> Creating library C:/VTK/lib/Release/vtkRenderingCoreJava.lib >> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp >> 117>vtkRenderWindowJava.obj : error LNK2019: unresolved external >> symbol __imp__JAWT_GetAWT at 8 referenced in function >> _Java_vtk_vtkPanel_RenderCreate at 12 >> 117>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: >> 1 unresolved externals >> 124> Generating Code... >> 117> >> 117>Build FAILED. >> >> which is almost certainly due to Visual Studio trying to use 64 bit >> Java, which is incompatible with the 32 bit code it generates. I was >> unaware that Visual Studio has to use Java. This should be easy to >> fix by setting the path it uses to a 32 JVM. >> >> In addition, there are two other errors which appear to be related to >> the components VTK_JAVA_SWT_COMPONENT and VTK_JAVA_SWT_COMPONENT >> checked in the DMake window, which seem not to be installed in my >> system. What do they do, and are they needed for what I want to do? >> If so, I need to find out how to install them, otherwise they can >> presumably be ignored. >> >> Christopher Sharp >> >>> On Sun, Mar 22, 2015 at 11:04 AM, CSharpdotcom . wrote: >>> Many thanks for your message; what I will do now is backup my VTK >>> folder, then instead of using Visual Studio 2010 Pro, I will download >>> the latest version of Visual Studio C++ Express, which is 2013 I >>> think, and try using DMake again form scratch. In the process I will >>> note exactly what I did, so if these problems persist, I will have a >>> record. >>> >>> csharp >>> >>> On Sun, Mar 22, 2015 at 7:18 AM, Sebastien Jourdain >>> wrote: >>>> I didn't see anything strange but can you explain your build process? Which property you changed in cmake and how/what did you build in visual studio? >>>> >>>> Seb >>>> >>>> >>>> >>>>> On Mar 22, 2015, at 00:11, CSharpdotcom . wrote: >>>>> >>>>> OK, many thanks, I didn't know that there was such a file, this is >>>>> because I'm so new to VTK and CMake. The file is in the root folder >>>>> and is attached here. >>>>> >>>>> I look forward finally to getting this sorted out, as it has now tied >>>>> me up for about a week. >>>>> >>>>> Christopher Sharp >>>>> >>>>> On Sat, Mar 21, 2015 at 8:59 PM, Sebastien Jourdain >>>>> wrote: >>>>>> I didn't know you had a partial build of VTK. Can you share you >>>>>> CMakeCache.txt. >>>>>> >>>>>> You must have wrongly setup your build. >>>>>> >>>>>> Seb >>>>>> >>>>>> On Sat, Mar 21, 2015 at 6:05 PM, CSharpdotcom . >>>>>> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Many thanks, but as I'm new ti VTK I don't know which libraries to >>>>>>> load. However, in looking at: >>>>>>> >>>>>>> http://www.vtk.org/Wiki/VTK/Examples/Java/Miscellaneous/Cone6 >>>>>>> >>>>>>> which has similar code. The statement: >>>>>>> >>>>>>> System.loadLibrary("vtkCommonJava"); >>>>>>> >>>>>>> doesn't load as there is no dll with that name in the folder >>>>>>> C:\VTK\bin\Release, but: >>>>>>> >>>>>>> System.loadLibrary("vtkCommonCoreJava"); >>>>>>> >>>>>>> does load correctly as there is a dll with that name. This applies to >>>>>>> a few other files, but not all of them. Without the required dlls >>>>>>> loaded, even if no errors are produced, the code will not execute. >>>>>>> >>>>>>> If I go back to the original code when I try and load everything, then >>>>>>> I get the error message: >>>>>>> >>>>>>> java.lang.UnsatisfiedLinkError: >>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>>>> libraries >>>>>>> >>>>>>> The file vtkChartsCoreJava.dll is present in that folder, so it is >>>>>>> loaded, but its dependencies cannot be found. This applies to quite a >>>>>>> few other dll files with dependencies, and I also get a list of a >>>>>>> large number files that were not loaded from the statement: >>>>>>> >>>>>>> if (!lib.IsLoaded()) System.out.println(lib.GetLibraryName() + " not >>>>>>> loaded"); >>>>>>> >>>>>>> inside the for-loop in an earlier message. >>>>>>> >>>>>>> It looks that without these large number of files, possibly all of >>>>>>> them, that have not been loaded the code will not work, even if I skip >>>>>>> over the bad loads or put the loop in a try-catch loop. This must >>>>>>> have something to do with the error message in the log during the >>>>>>> build process with Visual Studio Pro 2010 I did a few days ago. >>>>>>> >>>>>>> I don't fully understand the log, but the section where it failed is here: >>>>>>> >>>>>>> 112>Link: >>>>>>> 112> Creating library C:/VTK/lib/Release/vtkRenderingCoreJava.lib >>>>>>> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp >>>>>>> 114> vtkDepthPeeling_fs.cxx >>>>>>> 114> vtkGaussianBlurPassShader_fs.cxx >>>>>>> 114> vtkLighting_s.cxx >>>>>>> 114> vtkLightingHelper_s.cxx >>>>>>> 114> vtkOpenGLRenderer_PeelingFS.cxx >>>>>>> 114> vtkOpenGLPropertyDefaultPropFunc_fs.cxx >>>>>>> 114> vtkOpenGLPropertyDefaultPropFunc_vs.cxx >>>>>>> 112>vtkRenderWindowJava.obj : error LNK2019: unresolved external >>>>>>> symbol __imp__JAWT_GetAWT at 8 referenced in function >>>>>>> _Java_vtk_vtkPanel_RenderCreate at 12 >>>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: >>>>>>> 1 unresolved externals >>>>>>> 114> vtkOpenGLPropertyDefaultMain_fs.cxx >>>>>>> 112> >>>>>>> 112>Build FAILED. >>>>>>> 112> >>>>>>> 112>Time Elapsed 00:01:32.30 >>>>>>> >>>>>>> Obviously vtkRenderingCoreJava.dll failed to link, which must be the >>>>>>> cause of the problems I'm having. This was the only failure, with the >>>>>>> other 387 compilations and linking successful. If this problem can be >>>>>>> fixed, I hope I will be home and dry. >>>>>>> >>>>>>> I would most appreciate you or someone else kindly getting this resolved. >>>>>>> >>>>>>> csharp >>>>>>> >>>>>>> On Sat, Mar 21, 2015 at 3:04 PM, Sebastien Jourdain >>>>>>> wrote: >>>>>>>> Try to load the libraries that you need to load instead of all of them. >>>>>>>> It >>>>>>>> seems that you didn't build everything (which is probably fine). >>>>>>>> >>>>>>>> Seb >>>>>>>> >>>>>>>> On Sat, Mar 21, 2015 at 2:58 PM, CSharpdotcom . >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I already had PATH=C:\VTK\bin\Release, and added ;%PATH% at the end, >>>>>>>>> but it still doesn't work, and get the following output: >>>>>>>>> >>>>>>>>> java.lang.UnsatisfiedLinkError: >>>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>>>>>> libraries >>>>>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) at >>>>>>>>> java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >>>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>>>>>> at java.lang.System.loadLibrary(System.java:1119) >>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>>>>>> at >>>>>>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >>>>>>>>> at >>>>>>>>> >>>>>>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >>>>>>>>> java.lang.UnsatisfiedLinkError: >>>>>>>>> C:\VTK\bin\Release\vtkDomainsChemistryJava.dll: Can't find dependent >>>>>>>>> libraries >>>>>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >>>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>>>>>> at java.lang.System.loadLibrary(System.java:1119) >>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>>>>>> at >>>>>>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >>>>>>>>> at >>>>>>>>> >>>>>>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >>>>>>>>> ................... >>>>>>>>> >>>>>>>>> These error messages continue, then a list of files not loaded are >>>>>>>>> printed out, as given in the source code. >>>>>>>>> >>>>>>>>> Based on these error messages it's picking up the dll files in the >>>>>>>>> \Release folder, but it's unable to find other files that these dll >>>>>>>>> files depend on. >>>>>>>>> >>>>>>>>> Do you want a full listing of the Java source file? The >>>>>>>>> AwtConeRendering class starts off with: >>>>>>>>> >>>>>>>>> static { >>>>>>>>> System.out.println(System.getProperty("java.library.path")); >>>>>>>>> if (!vtkNativeLibrary.LoadAllNativeLibraries()) { >>>>>>>>> for (vtkNativeLibrary lib : vtkNativeLibrary.values()) { >>>>>>>>> if (!lib.IsLoaded()) { >>>>>>>>> System.out.println(lib.GetLibraryName() + " not loaded"); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> vtkNativeLibrary.DisableOutputWindow(null); >>>>>>>>> } >>>>>>>>> >>>>>>>>> which is followed by the main() method, which contains statements such >>>>>>>>> as: >>>>>>>>> >>>>>>>>> vtkConeSource cone = new vtkConeSource(); >>>>>>>>> >>>>>>>>> csharp >>>>>>>>> >>>>>>>>> On Sat, Mar 21, 2015 at 10:26 AM, Sebastien Jourdain >>>>>>>>> wrote: >>>>>>>>>> Te java.library.path is not enough and you need to add into your >>>>>>>>>> environment >>>>>>>>>> PATH the following directory, C:\VTK\bin\Release. >>>>>>>>>> >>>>>>>>>> set PATH=C:\VTK\bin\Release;%PATH% >>>>>>>>>> >>>>>>>>>> Seb >>>>>>>>>> >>>>>>>>>> On Sat, Mar 21, 2015 at 10:33 AM, CSharpdotcom . >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> I'm new to VTK and this is my first posting here or on any other >>>>>>>>>>> forum >>>>>>>>>>> related to VTK. >>>>>>>>>>> >>>>>>>>>>> I've been trying for about a week to get VTK installed and running >>>>>>>>>>> on >>>>>>>>>>> my computer. The project I'm working on is to use Java with VTK to >>>>>>>>>>> represent 3D graphics, which I hope to use with NetBeans 8.0.2. I >>>>>>>>>>> also have Visual Studio Pro 2010. >>>>>>>>>>> >>>>>>>>>>> After failed attempts in installing VTK 6.2.0 and the latest >>>>>>>>>>> version >>>>>>>>>>> of CMake, from the link >>>>>>>>>>> >>>>>>>>>>> http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk >>>>>>>>>>> I downloaded and unzipped VTK 6.1.0 and CMake 3.0.0, then installed >>>>>>>>>>> them. >>>>>>>>>>> >>>>>>>>>>> I then ran CMake according to the instructions on that link and >>>>>>>>>>> installed the generated code in the folder C:\VTK. I then clicked >>>>>>>>>>> on >>>>>>>>>>> the file VTK.sin in that folder, which opened up Visual Studio and >>>>>>>>>>> started compiling the code with a large number of modules in the >>>>>>>>>>> project. This took about an hour, and on completion, generated the >>>>>>>>>>> line at the end: >>>>>>>>>>> >>>>>>>>>>> Build: 387 succeeded, 1 failed, 0 up-to-date, 0 skipped >>>>>>>>>>> >>>>>>>>>>> I saved this in a file, which is very long, and after some effort >>>>>>>>>>> found the error message: >>>>>>>>>>> >>>>>>>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error >>>>>>>>>>> LNK1120: >>>>>>>>>>> 1 unresolved externals >>>>>>>>>>> >>>>>>>>>>> In the mean time I attempted to recompile the project, which was >>>>>>>>>>> much >>>>>>>>>>> quicker, and got the same message. In recompiled I checked the >>>>>>>>>>> "INSTALL" option, which had not previously been checked, although I >>>>>>>>>>> don't know if that is significant. >>>>>>>>>>> >>>>>>>>>>> Located in the folder \VTK\java\sample\rendering is the source file >>>>>>>>>>> AwTConeRendering.java, which apparently has not been compiled. I >>>>>>>>>>> created a NetBeans project and copied that file into it, then linked >>>>>>>>>>> vtk.jar in the folder \VTK\bin to the project, and all imports were >>>>>>>>>>> satisfied. In setting the Windows path to point to the dll files in >>>>>>>>>>> \VTK\bin\Release, the application appears to pick up the dll files >>>>>>>>>>> correctly, however, I get the following error message: >>>>>>>>>>> >>>>>>>>>>> java.lang.UnsatisfiedLinkError: >>>>>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>>>>>>>> libraries >>>>>>>>>>> >>>>>>>>>>> repeated for many dll files. Incidentally, as Visual Studio dlls >>>>>>>>>>> are >>>>>>>>>>> all 32 bits, as far as I know, I set up NetBeans to use a 32 bit >>>>>>>>>>> JVM. >>>>>>>>>>> This had previously been tested successfully with a test dll I >>>>>>>>>>> created >>>>>>>>>>> with Visual Studio and could execute with NetBeans. >>>>>>>>>>> >>>>>>>>>>> This problem is presumably related to the first error mentioned >>>>>>>>>>> above, >>>>>>>>>>> and would be most grateful in getting this issue resolved. As I >>>>>>>>>>> said, >>>>>>>>>>> I'm new to VTK, and in fact only in the last couple of weeks have >>>>>>>>>>> tried for the first time to call a dll file from a Java application >>>>>>>>>>> on >>>>>>>>>>> a Windows computer. >>>>>>>>>>> >>>>>>>>>>> In the Java code I added the statement: >>>>>>>>>>> >>>>>>>>>>> System.out.println(System.getProperty("java.library.path")); >>>>>>>>>>> >>>>>>>>>>> to check that the path was correct, which is the case. >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Powered by www.kitware.com >>>>>>>>>>> >>>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>>> >>>>>>>>>>> Search the list archives at: >>>>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>>>>> >>>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> From sebastien.jourdain at kitware.com Mon Mar 23 00:54:41 2015 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Sun, 22 Mar 2015 22:54:41 -0600 Subject: [vtk-developers] Problems installing VTK In-Reply-To: References: <37F0F4BE-C015-452A-A752-B07317B5B42A@kitware.com> <8E906FE3-B09F-4915-BD96-49028C996A23@kitware.com> Message-ID: Toggle the advance mode in cmake and search for java, just to make sure cmake find the right version of the lib. Seb On Sun, Mar 22, 2015 at 10:46 PM, CSharpdotcom . wrote: > Before I saw your message I tried building from scratch again, but > still have errors. > > I didn't see in the link: > > https://www.particleincell.com/2011/vtk-java-visualization/ > > anything about using 32 bit Java in CMake, but it does say it has to > be used with Visual Studio. After Googling around, I saw that the > path environmental variable has to be set to the 32 bit Java, so I > used C:\Program Files (x86)\Java\jre1.0.0_31\bin\client, where the > file jvm.dll is located. > > I will now try again from scratch, with CMake using 32 bit Java. I've > just set on my Windows 8 computer the following paths: > > JAVA_HOME = C:\Progra~2\Java\jdg1.8.0_31 > PATH = C:\Program Files (x86)\jre1.8.-_31\bin > > and will reboot and start again. > > Christopher Sharp > > On Sun, Mar 22, 2015 at 8:58 PM, Sebastien Jourdain > wrote: > > You need to properly set cmake so you don't build the swt nor the Jogl > components for Java. (You don't need them as you don't know what they are.) > Moreover the jvm 32b should also be set via cmake. Otherwise VTK won't > build correctly. > > > > Seb > > > >> On Mar 22, 2015, at 16:05, CSharpdotcom . > wrote: > >> > >> Hello, > >> > >> I decided not to install Visual Studio Express, as according to the > >> website Visual Studio Pro was used, which is exactly what I've been > >> using. > >> > >> Anyway, I created a new build folder and repeated the whole process > >> from scratch. The error I'm still getting is: > >> > >> 117>Link: > >> 117> Creating library C:/VTK/lib/Release/vtkRenderingCoreJava.lib > >> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp > >> 117>vtkRenderWindowJava.obj : error LNK2019: unresolved external > >> symbol __imp__JAWT_GetAWT at 8 referenced in function > >> _Java_vtk_vtkPanel_RenderCreate at 12 > >> 117>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: > >> 1 unresolved externals > >> 124> Generating Code... > >> 117> > >> 117>Build FAILED. > >> > >> which is almost certainly due to Visual Studio trying to use 64 bit > >> Java, which is incompatible with the 32 bit code it generates. I was > >> unaware that Visual Studio has to use Java. This should be easy to > >> fix by setting the path it uses to a 32 JVM. > >> > >> In addition, there are two other errors which appear to be related to > >> the components VTK_JAVA_SWT_COMPONENT and VTK_JAVA_SWT_COMPONENT > >> checked in the DMake window, which seem not to be installed in my > >> system. What do they do, and are they needed for what I want to do? > >> If so, I need to find out how to install them, otherwise they can > >> presumably be ignored. > >> > >> Christopher Sharp > >> > >>> On Sun, Mar 22, 2015 at 11:04 AM, CSharpdotcom . < > csharpdotcom at gmail.com> wrote: > >>> Many thanks for your message; what I will do now is backup my VTK > >>> folder, then instead of using Visual Studio 2010 Pro, I will download > >>> the latest version of Visual Studio C++ Express, which is 2013 I > >>> think, and try using DMake again form scratch. In the process I will > >>> note exactly what I did, so if these problems persist, I will have a > >>> record. > >>> > >>> csharp > >>> > >>> On Sun, Mar 22, 2015 at 7:18 AM, Sebastien Jourdain > >>> wrote: > >>>> I didn't see anything strange but can you explain your build process? > Which property you changed in cmake and how/what did you build in visual > studio? > >>>> > >>>> Seb > >>>> > >>>> > >>>> > >>>>> On Mar 22, 2015, at 00:11, CSharpdotcom . > wrote: > >>>>> > >>>>> OK, many thanks, I didn't know that there was such a file, this is > >>>>> because I'm so new to VTK and CMake. The file is in the root folder > >>>>> and is attached here. > >>>>> > >>>>> I look forward finally to getting this sorted out, as it has now tied > >>>>> me up for about a week. > >>>>> > >>>>> Christopher Sharp > >>>>> > >>>>> On Sat, Mar 21, 2015 at 8:59 PM, Sebastien Jourdain > >>>>> wrote: > >>>>>> I didn't know you had a partial build of VTK. Can you share you > >>>>>> CMakeCache.txt. > >>>>>> > >>>>>> You must have wrongly setup your build. > >>>>>> > >>>>>> Seb > >>>>>> > >>>>>> On Sat, Mar 21, 2015 at 6:05 PM, CSharpdotcom . < > csharpdotcom at gmail.com> > >>>>>> wrote: > >>>>>>> > >>>>>>> Hello, > >>>>>>> > >>>>>>> Many thanks, but as I'm new ti VTK I don't know which libraries to > >>>>>>> load. However, in looking at: > >>>>>>> > >>>>>>> http://www.vtk.org/Wiki/VTK/Examples/Java/Miscellaneous/Cone6 > >>>>>>> > >>>>>>> which has similar code. The statement: > >>>>>>> > >>>>>>> System.loadLibrary("vtkCommonJava"); > >>>>>>> > >>>>>>> doesn't load as there is no dll with that name in the folder > >>>>>>> C:\VTK\bin\Release, but: > >>>>>>> > >>>>>>> System.loadLibrary("vtkCommonCoreJava"); > >>>>>>> > >>>>>>> does load correctly as there is a dll with that name. This > applies to > >>>>>>> a few other files, but not all of them. Without the required dlls > >>>>>>> loaded, even if no errors are produced, the code will not execute. > >>>>>>> > >>>>>>> If I go back to the original code when I try and load everything, > then > >>>>>>> I get the error message: > >>>>>>> > >>>>>>> java.lang.UnsatisfiedLinkError: > >>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent > >>>>>>> libraries > >>>>>>> > >>>>>>> The file vtkChartsCoreJava.dll is present in that folder, so it is > >>>>>>> loaded, but its dependencies cannot be found. This applies to > quite a > >>>>>>> few other dll files with dependencies, and I also get a list of a > >>>>>>> large number files that were not loaded from the statement: > >>>>>>> > >>>>>>> if (!lib.IsLoaded()) System.out.println(lib.GetLibraryName() + " > not > >>>>>>> loaded"); > >>>>>>> > >>>>>>> inside the for-loop in an earlier message. > >>>>>>> > >>>>>>> It looks that without these large number of files, possibly all of > >>>>>>> them, that have not been loaded the code will not work, even if I > skip > >>>>>>> over the bad loads or put the loop in a try-catch loop. This must > >>>>>>> have something to do with the error message in the log during the > >>>>>>> build process with Visual Studio Pro 2010 I did a few days ago. > >>>>>>> > >>>>>>> I don't fully understand the log, but the section where it failed > is here: > >>>>>>> > >>>>>>> 112>Link: > >>>>>>> 112> Creating library > C:/VTK/lib/Release/vtkRenderingCoreJava.lib > >>>>>>> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp > >>>>>>> 114> vtkDepthPeeling_fs.cxx > >>>>>>> 114> vtkGaussianBlurPassShader_fs.cxx > >>>>>>> 114> vtkLighting_s.cxx > >>>>>>> 114> vtkLightingHelper_s.cxx > >>>>>>> 114> vtkOpenGLRenderer_PeelingFS.cxx > >>>>>>> 114> vtkOpenGLPropertyDefaultPropFunc_fs.cxx > >>>>>>> 114> vtkOpenGLPropertyDefaultPropFunc_vs.cxx > >>>>>>> 112>vtkRenderWindowJava.obj : error LNK2019: unresolved external > >>>>>>> symbol __imp__JAWT_GetAWT at 8 referenced in function > >>>>>>> _Java_vtk_vtkPanel_RenderCreate at 12 > >>>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error > LNK1120: > >>>>>>> 1 unresolved externals > >>>>>>> 114> vtkOpenGLPropertyDefaultMain_fs.cxx > >>>>>>> 112> > >>>>>>> 112>Build FAILED. > >>>>>>> 112> > >>>>>>> 112>Time Elapsed 00:01:32.30 > >>>>>>> > >>>>>>> Obviously vtkRenderingCoreJava.dll failed to link, which must be > the > >>>>>>> cause of the problems I'm having. This was the only failure, with > the > >>>>>>> other 387 compilations and linking successful. If this problem > can be > >>>>>>> fixed, I hope I will be home and dry. > >>>>>>> > >>>>>>> I would most appreciate you or someone else kindly getting this > resolved. > >>>>>>> > >>>>>>> csharp > >>>>>>> > >>>>>>> On Sat, Mar 21, 2015 at 3:04 PM, Sebastien Jourdain > >>>>>>> wrote: > >>>>>>>> Try to load the libraries that you need to load instead of all of > them. > >>>>>>>> It > >>>>>>>> seems that you didn't build everything (which is probably fine). > >>>>>>>> > >>>>>>>> Seb > >>>>>>>> > >>>>>>>> On Sat, Mar 21, 2015 at 2:58 PM, CSharpdotcom . < > csharpdotcom at gmail.com> > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> I already had PATH=C:\VTK\bin\Release, and added ;%PATH% at the > end, > >>>>>>>>> but it still doesn't work, and get the following output: > >>>>>>>>> > >>>>>>>>> java.lang.UnsatisfiedLinkError: > >>>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent > >>>>>>>>> libraries > >>>>>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) > >>>>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) > at > >>>>>>>>> java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) > >>>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) > >>>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) > >>>>>>>>> at java.lang.System.loadLibrary(System.java:1119) > >>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) > >>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) > >>>>>>>>> at > >>>>>>>>> > vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) > >>>>>>>>> at > >>>>>>>>> > >>>>>>>>> > vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) > >>>>>>>>> java.lang.UnsatisfiedLinkError: > >>>>>>>>> C:\VTK\bin\Release\vtkDomainsChemistryJava.dll: Can't find > dependent > >>>>>>>>> libraries > >>>>>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) > >>>>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) > >>>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) > >>>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) > >>>>>>>>> at java.lang.System.loadLibrary(System.java:1119) > >>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) > >>>>>>>>> at > >>>>>>>>> > vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) > >>>>>>>>> at > >>>>>>>>> > >>>>>>>>> > vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) > >>>>>>>>> ................... > >>>>>>>>> > >>>>>>>>> These error messages continue, then a list of files not loaded > are > >>>>>>>>> printed out, as given in the source code. > >>>>>>>>> > >>>>>>>>> Based on these error messages it's picking up the dll files in > the > >>>>>>>>> \Release folder, but it's unable to find other files that these > dll > >>>>>>>>> files depend on. > >>>>>>>>> > >>>>>>>>> Do you want a full listing of the Java source file? The > >>>>>>>>> AwtConeRendering class starts off with: > >>>>>>>>> > >>>>>>>>> static { > >>>>>>>>> System.out.println(System.getProperty("java.library.path")); > >>>>>>>>> if (!vtkNativeLibrary.LoadAllNativeLibraries()) { > >>>>>>>>> for (vtkNativeLibrary lib : vtkNativeLibrary.values()) { > >>>>>>>>> if (!lib.IsLoaded()) { > >>>>>>>>> System.out.println(lib.GetLibraryName() + " not loaded"); > >>>>>>>>> } > >>>>>>>>> } > >>>>>>>>> } > >>>>>>>>> vtkNativeLibrary.DisableOutputWindow(null); > >>>>>>>>> } > >>>>>>>>> > >>>>>>>>> which is followed by the main() method, which contains > statements such > >>>>>>>>> as: > >>>>>>>>> > >>>>>>>>> vtkConeSource cone = new vtkConeSource(); > >>>>>>>>> > >>>>>>>>> csharp > >>>>>>>>> > >>>>>>>>> On Sat, Mar 21, 2015 at 10:26 AM, Sebastien Jourdain > >>>>>>>>> wrote: > >>>>>>>>>> Te java.library.path is not enough and you need to add into your > >>>>>>>>>> environment > >>>>>>>>>> PATH the following directory, C:\VTK\bin\Release. > >>>>>>>>>> > >>>>>>>>>> set PATH=C:\VTK\bin\Release;%PATH% > >>>>>>>>>> > >>>>>>>>>> Seb > >>>>>>>>>> > >>>>>>>>>> On Sat, Mar 21, 2015 at 10:33 AM, CSharpdotcom . > >>>>>>>>>> > >>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Hello, > >>>>>>>>>>> > >>>>>>>>>>> I'm new to VTK and this is my first posting here or on any > other > >>>>>>>>>>> forum > >>>>>>>>>>> related to VTK. > >>>>>>>>>>> > >>>>>>>>>>> I've been trying for about a week to get VTK installed and > running > >>>>>>>>>>> on > >>>>>>>>>>> my computer. The project I'm working on is to use Java with > VTK to > >>>>>>>>>>> represent 3D graphics, which I hope to use with NetBeans > 8.0.2. I > >>>>>>>>>>> also have Visual Studio Pro 2010. > >>>>>>>>>>> > >>>>>>>>>>> After failed attempts in installing VTK 6.2.0 and the latest > >>>>>>>>>>> version > >>>>>>>>>>> of CMake, from the link > >>>>>>>>>>> > >>>>>>>>>>> > http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk > >>>>>>>>>>> I downloaded and unzipped VTK 6.1.0 and CMake 3.0.0, then > installed > >>>>>>>>>>> them. > >>>>>>>>>>> > >>>>>>>>>>> I then ran CMake according to the instructions on that link and > >>>>>>>>>>> installed the generated code in the folder C:\VTK. I then > clicked > >>>>>>>>>>> on > >>>>>>>>>>> the file VTK.sin in that folder, which opened up Visual Studio > and > >>>>>>>>>>> started compiling the code with a large number of modules in > the > >>>>>>>>>>> project. This took about an hour, and on completion, > generated the > >>>>>>>>>>> line at the end: > >>>>>>>>>>> > >>>>>>>>>>> Build: 387 succeeded, 1 failed, 0 up-to-date, 0 skipped > >>>>>>>>>>> > >>>>>>>>>>> I saved this in a file, which is very long, and after some > effort > >>>>>>>>>>> found the error message: > >>>>>>>>>>> > >>>>>>>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error > >>>>>>>>>>> LNK1120: > >>>>>>>>>>> 1 unresolved externals > >>>>>>>>>>> > >>>>>>>>>>> In the mean time I attempted to recompile the project, which > was > >>>>>>>>>>> much > >>>>>>>>>>> quicker, and got the same message. In recompiled I checked > the > >>>>>>>>>>> "INSTALL" option, which had not previously been checked, > although I > >>>>>>>>>>> don't know if that is significant. > >>>>>>>>>>> > >>>>>>>>>>> Located in the folder \VTK\java\sample\rendering is the source > file > >>>>>>>>>>> AwTConeRendering.java, which apparently has not been > compiled. I > >>>>>>>>>>> created a NetBeans project and copied that file into it, then > linked > >>>>>>>>>>> vtk.jar in the folder \VTK\bin to the project, and all imports > were > >>>>>>>>>>> satisfied. In setting the Windows path to point to the dll > files in > >>>>>>>>>>> \VTK\bin\Release, the application appears to pick up the dll > files > >>>>>>>>>>> correctly, however, I get the following error message: > >>>>>>>>>>> > >>>>>>>>>>> java.lang.UnsatisfiedLinkError: > >>>>>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent > >>>>>>>>>>> libraries > >>>>>>>>>>> > >>>>>>>>>>> repeated for many dll files. Incidentally, as Visual Studio > dlls > >>>>>>>>>>> are > >>>>>>>>>>> all 32 bits, as far as I know, I set up NetBeans to use a 32 > bit > >>>>>>>>>>> JVM. > >>>>>>>>>>> This had previously been tested successfully with a test dll I > >>>>>>>>>>> created > >>>>>>>>>>> with Visual Studio and could execute with NetBeans. > >>>>>>>>>>> > >>>>>>>>>>> This problem is presumably related to the first error mentioned > >>>>>>>>>>> above, > >>>>>>>>>>> and would be most grateful in getting this issue resolved. As > I > >>>>>>>>>>> said, > >>>>>>>>>>> I'm new to VTK, and in fact only in the last couple of weeks > have > >>>>>>>>>>> tried for the first time to call a dll file from a Java > application > >>>>>>>>>>> on > >>>>>>>>>>> a Windows computer. > >>>>>>>>>>> > >>>>>>>>>>> In the Java code I added the statement: > >>>>>>>>>>> > >>>>>>>>>>> System.out.println(System.getProperty("java.library.path")); > >>>>>>>>>>> > >>>>>>>>>>> to check that the path was correct, which is the case. > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> Powered by www.kitware.com > >>>>>>>>>>> > >>>>>>>>>>> Visit other Kitware open-source projects at > >>>>>>>>>>> http://www.kitware.com/opensource/opensource.html > >>>>>>>>>>> > >>>>>>>>>>> Search the list archives at: > >>>>>>>>>>> http://markmail.org/search/?q=vtk-developers > >>>>>>>>>>> > >>>>>>>>>>> Follow this link to subscribe/unsubscribe: > >>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers > >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Mon Mar 23 11:18:25 2015 From: david.lonie at kitware.com (David Lonie) Date: Mon, 23 Mar 2015 11:18:25 -0400 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: On Fri, Mar 20, 2015 at 9:42 AM, David Gobbi wrote: > On Fri, Mar 20, 2015 at 7:17 AM, David Lonie > wrote: > >> On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi >> wrote: >> >>> On Thu, Mar 19, 2015 at 2:28 PM, David Lonie >>> wrote: >>> >>>> 2) If so, how can I teach the wrappers about it? >>>> >>> >>> Adding things like this to Tcl is easier than for Java or Python, but >>> it's more than an afternoon's work. >>> >> >> One more thing: >> >> If you know offhand, can you briefly outline the steps that are needed to >> do this? That might help clarify whether the maintenance burden is >> excessive or not. Would it be a one-time deal that would teach Tcl how to >> wrap all similar methods, or would it need to be repeated for every similar >> method that gets added? >> > > My brief outline is this: find the code in vtkWrapTcl.c that builds arrays > to be used as return values, and then do something similar for this new > kind of method signature, except have it assign a global name (whatever > name was passed as a parameter) to the new array instead of returning it. > If it is done for this method, it should work for all similar methods. > This seems more doable than I'd feared, since it'd be a generic approach that should "just work" for similar cases. It sounds like there's a lot of support for removing Tcl, but it's unlikely that we'll see it go away completely anytime soon for a multitude of reasons. So back to the immediate issue of how the GetBounds change can be made to work with the wrappers, I see three options: 1) Train the wrappers to understand it. Might not be worth the effort if we're planning to pull support soon. 2) Add an additional non-deprecated GetBounds signature double* GetBounds(vtkViewport*) I don't like this approach as it has issues thread safety, and requires each object to carry around an array just to pass results back to a caller -- a pattern we should be moving away from. I'd be more supportive of this approach if we decided to use vtkTuple instead of double*, but this would also be likely to require some significant wrapper training and/or concrete vtkTuple subclasses. 3) Begin a long-term deprecation of Tcl. We'll not plan on removing it completely anytime soon, but enabling Tcl wrapping will also require enabling legacy code in VTK. This way the old legacy GetBounds, etc signatures will still be available to Tcl, and feedback from the deprecation would help us understand the full impact of completely removing Tcl, as we'll grab the attention of users that might not follow the mailing lists. My vote is for 3 -- it's an easy change that gives people a heads-up about then inevitable future removal of Tcl support, and ensures that everything will "just work" for legacy code until we decide to completely pull the plug. Thoughts? Votes? Alternatives? Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Mon Mar 23 12:54:46 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 23 Mar 2015 12:54:46 -0400 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: +1 to (3). -berk On Mon, Mar 23, 2015 at 11:18 AM, David Lonie wrote: > On Fri, Mar 20, 2015 at 9:42 AM, David Gobbi > wrote: > >> On Fri, Mar 20, 2015 at 7:17 AM, David Lonie >> wrote: >> >>> On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi >>> wrote: >>> >>>> On Thu, Mar 19, 2015 at 2:28 PM, David Lonie >>>> wrote: >>>> >>>>> 2) If so, how can I teach the wrappers about it? >>>>> >>>> >>>> Adding things like this to Tcl is easier than for Java or Python, but >>>> it's more than an afternoon's work. >>>> >>> >>> One more thing: >>> >>> If you know offhand, can you briefly outline the steps that are needed >>> to do this? That might help clarify whether the maintenance burden is >>> excessive or not. Would it be a one-time deal that would teach Tcl how to >>> wrap all similar methods, or would it need to be repeated for every similar >>> method that gets added? >>> >> >> My brief outline is this: find the code in vtkWrapTcl.c that builds >> arrays to be used as return values, and then do something similar for this >> new kind of method signature, except have it assign a global name (whatever >> name was passed as a parameter) to the new array instead of returning it. >> If it is done for this method, it should work for all similar methods. >> > > This seems more doable than I'd feared, since it'd be a generic approach > that should "just work" for similar cases. > > It sounds like there's a lot of support for removing Tcl, but it's > unlikely that we'll see it go away completely anytime soon for a multitude > of reasons. So back to the immediate issue of how the GetBounds change can > be made to work with the wrappers, I see three options: > > 1) Train the wrappers to understand it. Might not be worth the effort if > we're planning to pull support soon. > > 2) Add an additional non-deprecated GetBounds signature > > double* GetBounds(vtkViewport*) > > I don't like this approach as it has issues thread safety, and requires > each object to carry around an array just to pass results back to a caller > -- a pattern we should be moving away from. I'd be more supportive of this > approach if we decided to use vtkTuple instead of double*, but > this would also be likely to require some significant wrapper training > and/or concrete vtkTuple subclasses. > > 3) Begin a long-term deprecation of Tcl. We'll not plan on removing it > completely anytime soon, but enabling Tcl wrapping will also require > enabling legacy code in VTK. This way the old legacy GetBounds, etc > signatures will still be available to Tcl, and feedback from the > deprecation would help us understand the full impact of completely removing > Tcl, as we'll grab the attention of users that might not follow the mailing > lists. > > My vote is for 3 -- it's an easy change that gives people a heads-up about > then inevitable future removal of Tcl support, and ensures that everything > will "just work" for legacy code until we decide to completely pull the > plug. > > Thoughts? Votes? Alternatives? > > Dave > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From csharpdotcom at gmail.com Mon Mar 23 13:09:28 2015 From: csharpdotcom at gmail.com (CSharpdotcom .) Date: Mon, 23 Mar 2015 10:09:28 -0700 Subject: [vtk-developers] Problems installing VTK In-Reply-To: References: <37F0F4BE-C015-452A-A752-B07317B5B42A@kitware.com> <8E906FE3-B09F-4915-BD96-49028C996A23@kitware.com> Message-ID: OK, many thanks, I havn't done that before. This is what I just did with CMake, I checked the Advanced box, entered "Java" in the search window on the left, then clicked " +Add Entry". Below the word "Java" appeared under "Name", then searched for the 32 bit Java compiler on the right, which is at C:/Program Files (x86)/Java/jdk1.8.0_31/bin. So far so good, I will now start up CMake 3.3.0 again from scratch, having deleted all the old files. After all this I will let you know what happens. Christopher Sharp On Sun, Mar 22, 2015 at 9:54 PM, Sebastien Jourdain wrote: > Toggle the advance mode in cmake and search for java, just to make sure > cmake find the right version of the lib. > > Seb > > On Sun, Mar 22, 2015 at 10:46 PM, CSharpdotcom . > wrote: >> >> Before I saw your message I tried building from scratch again, but >> still have errors. >> >> I didn't see in the link: >> >> https://www.particleincell.com/2011/vtk-java-visualization/ >> >> anything about using 32 bit Java in CMake, but it does say it has to >> be used with Visual Studio. After Googling around, I saw that the >> path environmental variable has to be set to the 32 bit Java, so I >> used C:\Program Files (x86)\Java\jre1.0.0_31\bin\client, where the >> file jvm.dll is located. >> >> I will now try again from scratch, with CMake using 32 bit Java. I've >> just set on my Windows 8 computer the following paths: >> >> JAVA_HOME = C:\Progra~2\Java\jdg1.8.0_31 >> PATH = C:\Program Files (x86)\jre1.8.-_31\bin >> >> and will reboot and start again. >> >> Christopher Sharp >> >> On Sun, Mar 22, 2015 at 8:58 PM, Sebastien Jourdain >> wrote: >> > You need to properly set cmake so you don't build the swt nor the Jogl >> > components for Java. (You don't need them as you don't know what they are.) >> > Moreover the jvm 32b should also be set via cmake. Otherwise VTK won't build >> > correctly. >> > >> > Seb >> > >> >> On Mar 22, 2015, at 16:05, CSharpdotcom . >> >> wrote: >> >> >> >> Hello, >> >> >> >> I decided not to install Visual Studio Express, as according to the >> >> website Visual Studio Pro was used, which is exactly what I've been >> >> using. >> >> >> >> Anyway, I created a new build folder and repeated the whole process >> >> from scratch. The error I'm still getting is: >> >> >> >> 117>Link: >> >> 117> Creating library C:/VTK/lib/Release/vtkRenderingCoreJava.lib >> >> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp >> >> 117>vtkRenderWindowJava.obj : error LNK2019: unresolved external >> >> symbol __imp__JAWT_GetAWT at 8 referenced in function >> >> _Java_vtk_vtkPanel_RenderCreate at 12 >> >> 117>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: >> >> 1 unresolved externals >> >> 124> Generating Code... >> >> 117> >> >> 117>Build FAILED. >> >> >> >> which is almost certainly due to Visual Studio trying to use 64 bit >> >> Java, which is incompatible with the 32 bit code it generates. I was >> >> unaware that Visual Studio has to use Java. This should be easy to >> >> fix by setting the path it uses to a 32 JVM. >> >> >> >> In addition, there are two other errors which appear to be related to >> >> the components VTK_JAVA_SWT_COMPONENT and VTK_JAVA_SWT_COMPONENT >> >> checked in the DMake window, which seem not to be installed in my >> >> system. What do they do, and are they needed for what I want to do? >> >> If so, I need to find out how to install them, otherwise they can >> >> presumably be ignored. >> >> >> >> Christopher Sharp >> >> >> >>> On Sun, Mar 22, 2015 at 11:04 AM, CSharpdotcom . >> >>> wrote: >> >>> Many thanks for your message; what I will do now is backup my VTK >> >>> folder, then instead of using Visual Studio 2010 Pro, I will download >> >>> the latest version of Visual Studio C++ Express, which is 2013 I >> >>> think, and try using DMake again form scratch. In the process I will >> >>> note exactly what I did, so if these problems persist, I will have a >> >>> record. >> >>> >> >>> csharp >> >>> >> >>> On Sun, Mar 22, 2015 at 7:18 AM, Sebastien Jourdain >> >>> wrote: >> >>>> I didn't see anything strange but can you explain your build process? >> >>>> Which property you changed in cmake and how/what did you build in visual >> >>>> studio? >> >>>> >> >>>> Seb >> >>>> >> >>>> >> >>>> >> >>>>> On Mar 22, 2015, at 00:11, CSharpdotcom . >> >>>>> wrote: >> >>>>> >> >>>>> OK, many thanks, I didn't know that there was such a file, this is >> >>>>> because I'm so new to VTK and CMake. The file is in the root folder >> >>>>> and is attached here. >> >>>>> >> >>>>> I look forward finally to getting this sorted out, as it has now >> >>>>> tied >> >>>>> me up for about a week. >> >>>>> >> >>>>> Christopher Sharp >> >>>>> >> >>>>> On Sat, Mar 21, 2015 at 8:59 PM, Sebastien Jourdain >> >>>>> wrote: >> >>>>>> I didn't know you had a partial build of VTK. Can you share you >> >>>>>> CMakeCache.txt. >> >>>>>> >> >>>>>> You must have wrongly setup your build. >> >>>>>> >> >>>>>> Seb >> >>>>>> >> >>>>>> On Sat, Mar 21, 2015 at 6:05 PM, CSharpdotcom . >> >>>>>> >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> Hello, >> >>>>>>> >> >>>>>>> Many thanks, but as I'm new ti VTK I don't know which libraries to >> >>>>>>> load. However, in looking at: >> >>>>>>> >> >>>>>>> http://www.vtk.org/Wiki/VTK/Examples/Java/Miscellaneous/Cone6 >> >>>>>>> >> >>>>>>> which has similar code. The statement: >> >>>>>>> >> >>>>>>> System.loadLibrary("vtkCommonJava"); >> >>>>>>> >> >>>>>>> doesn't load as there is no dll with that name in the folder >> >>>>>>> C:\VTK\bin\Release, but: >> >>>>>>> >> >>>>>>> System.loadLibrary("vtkCommonCoreJava"); >> >>>>>>> >> >>>>>>> does load correctly as there is a dll with that name. This >> >>>>>>> applies to >> >>>>>>> a few other files, but not all of them. Without the required dlls >> >>>>>>> loaded, even if no errors are produced, the code will not execute. >> >>>>>>> >> >>>>>>> If I go back to the original code when I try and load everything, >> >>>>>>> then >> >>>>>>> I get the error message: >> >>>>>>> >> >>>>>>> java.lang.UnsatisfiedLinkError: >> >>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >> >>>>>>> libraries >> >>>>>>> >> >>>>>>> The file vtkChartsCoreJava.dll is present in that folder, so it is >> >>>>>>> loaded, but its dependencies cannot be found. This applies to >> >>>>>>> quite a >> >>>>>>> few other dll files with dependencies, and I also get a list of a >> >>>>>>> large number files that were not loaded from the statement: >> >>>>>>> >> >>>>>>> if (!lib.IsLoaded()) System.out.println(lib.GetLibraryName() + " >> >>>>>>> not >> >>>>>>> loaded"); >> >>>>>>> >> >>>>>>> inside the for-loop in an earlier message. >> >>>>>>> >> >>>>>>> It looks that without these large number of files, possibly all of >> >>>>>>> them, that have not been loaded the code will not work, even if I >> >>>>>>> skip >> >>>>>>> over the bad loads or put the loop in a try-catch loop. This must >> >>>>>>> have something to do with the error message in the log during the >> >>>>>>> build process with Visual Studio Pro 2010 I did a few days ago. >> >>>>>>> >> >>>>>>> I don't fully understand the log, but the section where it failed >> >>>>>>> is here: >> >>>>>>> >> >>>>>>> 112>Link: >> >>>>>>> 112> Creating library >> >>>>>>> C:/VTK/lib/Release/vtkRenderingCoreJava.lib >> >>>>>>> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp >> >>>>>>> 114> vtkDepthPeeling_fs.cxx >> >>>>>>> 114> vtkGaussianBlurPassShader_fs.cxx >> >>>>>>> 114> vtkLighting_s.cxx >> >>>>>>> 114> vtkLightingHelper_s.cxx >> >>>>>>> 114> vtkOpenGLRenderer_PeelingFS.cxx >> >>>>>>> 114> vtkOpenGLPropertyDefaultPropFunc_fs.cxx >> >>>>>>> 114> vtkOpenGLPropertyDefaultPropFunc_vs.cxx >> >>>>>>> 112>vtkRenderWindowJava.obj : error LNK2019: unresolved external >> >>>>>>> symbol __imp__JAWT_GetAWT at 8 referenced in function >> >>>>>>> _Java_vtk_vtkPanel_RenderCreate at 12 >> >>>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error >> >>>>>>> LNK1120: >> >>>>>>> 1 unresolved externals >> >>>>>>> 114> vtkOpenGLPropertyDefaultMain_fs.cxx >> >>>>>>> 112> >> >>>>>>> 112>Build FAILED. >> >>>>>>> 112> >> >>>>>>> 112>Time Elapsed 00:01:32.30 >> >>>>>>> >> >>>>>>> Obviously vtkRenderingCoreJava.dll failed to link, which must be >> >>>>>>> the >> >>>>>>> cause of the problems I'm having. This was the only failure, with >> >>>>>>> the >> >>>>>>> other 387 compilations and linking successful. If this problem >> >>>>>>> can be >> >>>>>>> fixed, I hope I will be home and dry. >> >>>>>>> >> >>>>>>> I would most appreciate you or someone else kindly getting this >> >>>>>>> resolved. >> >>>>>>> >> >>>>>>> csharp >> >>>>>>> >> >>>>>>> On Sat, Mar 21, 2015 at 3:04 PM, Sebastien Jourdain >> >>>>>>> wrote: >> >>>>>>>> Try to load the libraries that you need to load instead of all of >> >>>>>>>> them. >> >>>>>>>> It >> >>>>>>>> seems that you didn't build everything (which is probably fine). >> >>>>>>>> >> >>>>>>>> Seb >> >>>>>>>> >> >>>>>>>> On Sat, Mar 21, 2015 at 2:58 PM, CSharpdotcom . >> >>>>>>>> >> >>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>> I already had PATH=C:\VTK\bin\Release, and added ;%PATH% at the >> >>>>>>>>> end, >> >>>>>>>>> but it still doesn't work, and get the following output: >> >>>>>>>>> >> >>>>>>>>> java.lang.UnsatisfiedLinkError: >> >>>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >> >>>>>>>>> libraries >> >>>>>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >> >>>>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >> >>>>>>>>> at >> >>>>>>>>> java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >> >>>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >> >>>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >> >>>>>>>>> at java.lang.System.loadLibrary(System.java:1119) >> >>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >> >>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >> >>>>>>>>> at >> >>>>>>>>> >> >>>>>>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >> >>>>>>>>> at >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >> >>>>>>>>> java.lang.UnsatisfiedLinkError: >> >>>>>>>>> C:\VTK\bin\Release\vtkDomainsChemistryJava.dll: Can't find >> >>>>>>>>> dependent >> >>>>>>>>> libraries >> >>>>>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >> >>>>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >> >>>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >> >>>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >> >>>>>>>>> at java.lang.System.loadLibrary(System.java:1119) >> >>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >> >>>>>>>>> at >> >>>>>>>>> >> >>>>>>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >> >>>>>>>>> at >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >> >>>>>>>>> ................... >> >>>>>>>>> >> >>>>>>>>> These error messages continue, then a list of files not loaded >> >>>>>>>>> are >> >>>>>>>>> printed out, as given in the source code. >> >>>>>>>>> >> >>>>>>>>> Based on these error messages it's picking up the dll files in >> >>>>>>>>> the >> >>>>>>>>> \Release folder, but it's unable to find other files that these >> >>>>>>>>> dll >> >>>>>>>>> files depend on. >> >>>>>>>>> >> >>>>>>>>> Do you want a full listing of the Java source file? The >> >>>>>>>>> AwtConeRendering class starts off with: >> >>>>>>>>> >> >>>>>>>>> static { >> >>>>>>>>> System.out.println(System.getProperty("java.library.path")); >> >>>>>>>>> if (!vtkNativeLibrary.LoadAllNativeLibraries()) { >> >>>>>>>>> for (vtkNativeLibrary lib : vtkNativeLibrary.values()) { >> >>>>>>>>> if (!lib.IsLoaded()) { >> >>>>>>>>> System.out.println(lib.GetLibraryName() + " not >> >>>>>>>>> loaded"); >> >>>>>>>>> } >> >>>>>>>>> } >> >>>>>>>>> } >> >>>>>>>>> vtkNativeLibrary.DisableOutputWindow(null); >> >>>>>>>>> } >> >>>>>>>>> >> >>>>>>>>> which is followed by the main() method, which contains >> >>>>>>>>> statements such >> >>>>>>>>> as: >> >>>>>>>>> >> >>>>>>>>> vtkConeSource cone = new vtkConeSource(); >> >>>>>>>>> >> >>>>>>>>> csharp >> >>>>>>>>> >> >>>>>>>>> On Sat, Mar 21, 2015 at 10:26 AM, Sebastien Jourdain >> >>>>>>>>> wrote: >> >>>>>>>>>> Te java.library.path is not enough and you need to add into >> >>>>>>>>>> your >> >>>>>>>>>> environment >> >>>>>>>>>> PATH the following directory, C:\VTK\bin\Release. >> >>>>>>>>>> >> >>>>>>>>>> set PATH=C:\VTK\bin\Release;%PATH% >> >>>>>>>>>> >> >>>>>>>>>> Seb >> >>>>>>>>>> >> >>>>>>>>>> On Sat, Mar 21, 2015 at 10:33 AM, CSharpdotcom . >> >>>>>>>>>> >> >>>>>>>>>> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>> Hello, >> >>>>>>>>>>> >> >>>>>>>>>>> I'm new to VTK and this is my first posting here or on any >> >>>>>>>>>>> other >> >>>>>>>>>>> forum >> >>>>>>>>>>> related to VTK. >> >>>>>>>>>>> >> >>>>>>>>>>> I've been trying for about a week to get VTK installed and >> >>>>>>>>>>> running >> >>>>>>>>>>> on >> >>>>>>>>>>> my computer. The project I'm working on is to use Java with >> >>>>>>>>>>> VTK to >> >>>>>>>>>>> represent 3D graphics, which I hope to use with NetBeans >> >>>>>>>>>>> 8.0.2. I >> >>>>>>>>>>> also have Visual Studio Pro 2010. >> >>>>>>>>>>> >> >>>>>>>>>>> After failed attempts in installing VTK 6.2.0 and the latest >> >>>>>>>>>>> version >> >>>>>>>>>>> of CMake, from the link >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk >> >>>>>>>>>>> I downloaded and unzipped VTK 6.1.0 and CMake 3.0.0, then >> >>>>>>>>>>> installed >> >>>>>>>>>>> them. >> >>>>>>>>>>> >> >>>>>>>>>>> I then ran CMake according to the instructions on that link >> >>>>>>>>>>> and >> >>>>>>>>>>> installed the generated code in the folder C:\VTK. I then >> >>>>>>>>>>> clicked >> >>>>>>>>>>> on >> >>>>>>>>>>> the file VTK.sin in that folder, which opened up Visual Studio >> >>>>>>>>>>> and >> >>>>>>>>>>> started compiling the code with a large number of modules in >> >>>>>>>>>>> the >> >>>>>>>>>>> project. This took about an hour, and on completion, >> >>>>>>>>>>> generated the >> >>>>>>>>>>> line at the end: >> >>>>>>>>>>> >> >>>>>>>>>>> Build: 387 succeeded, 1 failed, 0 up-to-date, 0 skipped >> >>>>>>>>>>> >> >>>>>>>>>>> I saved this in a file, which is very long, and after some >> >>>>>>>>>>> effort >> >>>>>>>>>>> found the error message: >> >>>>>>>>>>> >> >>>>>>>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error >> >>>>>>>>>>> LNK1120: >> >>>>>>>>>>> 1 unresolved externals >> >>>>>>>>>>> >> >>>>>>>>>>> In the mean time I attempted to recompile the project, which >> >>>>>>>>>>> was >> >>>>>>>>>>> much >> >>>>>>>>>>> quicker, and got the same message. In recompiled I checked >> >>>>>>>>>>> the >> >>>>>>>>>>> "INSTALL" option, which had not previously been checked, >> >>>>>>>>>>> although I >> >>>>>>>>>>> don't know if that is significant. >> >>>>>>>>>>> >> >>>>>>>>>>> Located in the folder \VTK\java\sample\rendering is the source >> >>>>>>>>>>> file >> >>>>>>>>>>> AwTConeRendering.java, which apparently has not been compiled. >> >>>>>>>>>>> I >> >>>>>>>>>>> created a NetBeans project and copied that file into it, then >> >>>>>>>>>>> linked >> >>>>>>>>>>> vtk.jar in the folder \VTK\bin to the project, and all imports >> >>>>>>>>>>> were >> >>>>>>>>>>> satisfied. In setting the Windows path to point to the dll >> >>>>>>>>>>> files in >> >>>>>>>>>>> \VTK\bin\Release, the application appears to pick up the dll >> >>>>>>>>>>> files >> >>>>>>>>>>> correctly, however, I get the following error message: >> >>>>>>>>>>> >> >>>>>>>>>>> java.lang.UnsatisfiedLinkError: >> >>>>>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >> >>>>>>>>>>> libraries >> >>>>>>>>>>> >> >>>>>>>>>>> repeated for many dll files. Incidentally, as Visual Studio >> >>>>>>>>>>> dlls >> >>>>>>>>>>> are >> >>>>>>>>>>> all 32 bits, as far as I know, I set up NetBeans to use a 32 >> >>>>>>>>>>> bit >> >>>>>>>>>>> JVM. >> >>>>>>>>>>> This had previously been tested successfully with a test dll I >> >>>>>>>>>>> created >> >>>>>>>>>>> with Visual Studio and could execute with NetBeans. >> >>>>>>>>>>> >> >>>>>>>>>>> This problem is presumably related to the first error >> >>>>>>>>>>> mentioned >> >>>>>>>>>>> above, >> >>>>>>>>>>> and would be most grateful in getting this issue resolved. As >> >>>>>>>>>>> I >> >>>>>>>>>>> said, >> >>>>>>>>>>> I'm new to VTK, and in fact only in the last couple of weeks >> >>>>>>>>>>> have >> >>>>>>>>>>> tried for the first time to call a dll file from a Java >> >>>>>>>>>>> application >> >>>>>>>>>>> on >> >>>>>>>>>>> a Windows computer. >> >>>>>>>>>>> >> >>>>>>>>>>> In the Java code I added the statement: >> >>>>>>>>>>> >> >>>>>>>>>>> System.out.println(System.getProperty("java.library.path")); >> >>>>>>>>>>> >> >>>>>>>>>>> to check that the path was correct, which is the case. >> >>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>> Powered by www.kitware.com >> >>>>>>>>>>> >> >>>>>>>>>>> Visit other Kitware open-source projects at >> >>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >> >>>>>>>>>>> >> >>>>>>>>>>> Search the list archives at: >> >>>>>>>>>>> http://markmail.org/search/?q=vtk-developers >> >>>>>>>>>>> >> >>>>>>>>>>> Follow this link to subscribe/unsubscribe: >> >>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >> >>>>> > > From csharpdotcom at gmail.com Mon Mar 23 13:37:07 2015 From: csharpdotcom at gmail.com (CSharpdotcom .) Date: Mon, 23 Mar 2015 10:37:07 -0700 Subject: [vtk-developers] Problems installing VTK In-Reply-To: References: <37F0F4BE-C015-452A-A752-B07317B5B42A@kitware.com> <8E906FE3-B09F-4915-BD96-49028C996A23@kitware.com> Message-ID: OK, now CMake displays a screen with only 3 entries in red: Module_vtkWebJavaScript Module_vtkWrappingJava VTK_WRAP_JAVA I certainly need the last, and possibly Module_vtkWrappingJava, so I will check those and click Configure again. The BUILD_SHARED_LIBS option and the other do not appear, and I don't know why. On Mon, Mar 23, 2015 at 10:09 AM, CSharpdotcom . wrote: > OK, many thanks, I havn't done that before. This is what I just did > with CMake, I checked the Advanced box, entered "Java" in the search > window on the left, then clicked " +Add Entry". Below the word "Java" > appeared under "Name", then searched for the 32 bit Java compiler on > the right, which is at C:/Program Files (x86)/Java/jdk1.8.0_31/bin. > > So far so good, I will now start up CMake 3.3.0 again from scratch, > having deleted all the old files. After all this I will let you know > what happens. > > Christopher Sharp > > On Sun, Mar 22, 2015 at 9:54 PM, Sebastien Jourdain > wrote: >> Toggle the advance mode in cmake and search for java, just to make sure >> cmake find the right version of the lib. >> >> Seb >> >> On Sun, Mar 22, 2015 at 10:46 PM, CSharpdotcom . >> wrote: >>> >>> Before I saw your message I tried building from scratch again, but >>> still have errors. >>> >>> I didn't see in the link: >>> >>> https://www.particleincell.com/2011/vtk-java-visualization/ >>> >>> anything about using 32 bit Java in CMake, but it does say it has to >>> be used with Visual Studio. After Googling around, I saw that the >>> path environmental variable has to be set to the 32 bit Java, so I >>> used C:\Program Files (x86)\Java\jre1.0.0_31\bin\client, where the >>> file jvm.dll is located. >>> >>> I will now try again from scratch, with CMake using 32 bit Java. I've >>> just set on my Windows 8 computer the following paths: >>> >>> JAVA_HOME = C:\Progra~2\Java\jdg1.8.0_31 >>> PATH = C:\Program Files (x86)\jre1.8.-_31\bin >>> >>> and will reboot and start again. >>> >>> Christopher Sharp >>> >>> On Sun, Mar 22, 2015 at 8:58 PM, Sebastien Jourdain >>> wrote: >>> > You need to properly set cmake so you don't build the swt nor the Jogl >>> > components for Java. (You don't need them as you don't know what they are.) >>> > Moreover the jvm 32b should also be set via cmake. Otherwise VTK won't build >>> > correctly. >>> > >>> > Seb >>> > >>> >> On Mar 22, 2015, at 16:05, CSharpdotcom . >>> >> wrote: >>> >> >>> >> Hello, >>> >> >>> >> I decided not to install Visual Studio Express, as according to the >>> >> website Visual Studio Pro was used, which is exactly what I've been >>> >> using. >>> >> >>> >> Anyway, I created a new build folder and repeated the whole process >>> >> from scratch. The error I'm still getting is: >>> >> >>> >> 117>Link: >>> >> 117> Creating library C:/VTK/lib/Release/vtkRenderingCoreJava.lib >>> >> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp >>> >> 117>vtkRenderWindowJava.obj : error LNK2019: unresolved external >>> >> symbol __imp__JAWT_GetAWT at 8 referenced in function >>> >> _Java_vtk_vtkPanel_RenderCreate at 12 >>> >> 117>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: >>> >> 1 unresolved externals >>> >> 124> Generating Code... >>> >> 117> >>> >> 117>Build FAILED. >>> >> >>> >> which is almost certainly due to Visual Studio trying to use 64 bit >>> >> Java, which is incompatible with the 32 bit code it generates. I was >>> >> unaware that Visual Studio has to use Java. This should be easy to >>> >> fix by setting the path it uses to a 32 JVM. >>> >> >>> >> In addition, there are two other errors which appear to be related to >>> >> the components VTK_JAVA_SWT_COMPONENT and VTK_JAVA_SWT_COMPONENT >>> >> checked in the DMake window, which seem not to be installed in my >>> >> system. What do they do, and are they needed for what I want to do? >>> >> If so, I need to find out how to install them, otherwise they can >>> >> presumably be ignored. >>> >> >>> >> Christopher Sharp >>> >> >>> >>> On Sun, Mar 22, 2015 at 11:04 AM, CSharpdotcom . >>> >>> wrote: >>> >>> Many thanks for your message; what I will do now is backup my VTK >>> >>> folder, then instead of using Visual Studio 2010 Pro, I will download >>> >>> the latest version of Visual Studio C++ Express, which is 2013 I >>> >>> think, and try using DMake again form scratch. In the process I will >>> >>> note exactly what I did, so if these problems persist, I will have a >>> >>> record. >>> >>> >>> >>> csharp >>> >>> >>> >>> On Sun, Mar 22, 2015 at 7:18 AM, Sebastien Jourdain >>> >>> wrote: >>> >>>> I didn't see anything strange but can you explain your build process? >>> >>>> Which property you changed in cmake and how/what did you build in visual >>> >>>> studio? >>> >>>> >>> >>>> Seb >>> >>>> >>> >>>> >>> >>>> >>> >>>>> On Mar 22, 2015, at 00:11, CSharpdotcom . >>> >>>>> wrote: >>> >>>>> >>> >>>>> OK, many thanks, I didn't know that there was such a file, this is >>> >>>>> because I'm so new to VTK and CMake. The file is in the root folder >>> >>>>> and is attached here. >>> >>>>> >>> >>>>> I look forward finally to getting this sorted out, as it has now >>> >>>>> tied >>> >>>>> me up for about a week. >>> >>>>> >>> >>>>> Christopher Sharp >>> >>>>> >>> >>>>> On Sat, Mar 21, 2015 at 8:59 PM, Sebastien Jourdain >>> >>>>> wrote: >>> >>>>>> I didn't know you had a partial build of VTK. Can you share you >>> >>>>>> CMakeCache.txt. >>> >>>>>> >>> >>>>>> You must have wrongly setup your build. >>> >>>>>> >>> >>>>>> Seb >>> >>>>>> >>> >>>>>> On Sat, Mar 21, 2015 at 6:05 PM, CSharpdotcom . >>> >>>>>> >>> >>>>>> wrote: >>> >>>>>>> >>> >>>>>>> Hello, >>> >>>>>>> >>> >>>>>>> Many thanks, but as I'm new ti VTK I don't know which libraries to >>> >>>>>>> load. However, in looking at: >>> >>>>>>> >>> >>>>>>> http://www.vtk.org/Wiki/VTK/Examples/Java/Miscellaneous/Cone6 >>> >>>>>>> >>> >>>>>>> which has similar code. The statement: >>> >>>>>>> >>> >>>>>>> System.loadLibrary("vtkCommonJava"); >>> >>>>>>> >>> >>>>>>> doesn't load as there is no dll with that name in the folder >>> >>>>>>> C:\VTK\bin\Release, but: >>> >>>>>>> >>> >>>>>>> System.loadLibrary("vtkCommonCoreJava"); >>> >>>>>>> >>> >>>>>>> does load correctly as there is a dll with that name. This >>> >>>>>>> applies to >>> >>>>>>> a few other files, but not all of them. Without the required dlls >>> >>>>>>> loaded, even if no errors are produced, the code will not execute. >>> >>>>>>> >>> >>>>>>> If I go back to the original code when I try and load everything, >>> >>>>>>> then >>> >>>>>>> I get the error message: >>> >>>>>>> >>> >>>>>>> java.lang.UnsatisfiedLinkError: >>> >>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>> >>>>>>> libraries >>> >>>>>>> >>> >>>>>>> The file vtkChartsCoreJava.dll is present in that folder, so it is >>> >>>>>>> loaded, but its dependencies cannot be found. This applies to >>> >>>>>>> quite a >>> >>>>>>> few other dll files with dependencies, and I also get a list of a >>> >>>>>>> large number files that were not loaded from the statement: >>> >>>>>>> >>> >>>>>>> if (!lib.IsLoaded()) System.out.println(lib.GetLibraryName() + " >>> >>>>>>> not >>> >>>>>>> loaded"); >>> >>>>>>> >>> >>>>>>> inside the for-loop in an earlier message. >>> >>>>>>> >>> >>>>>>> It looks that without these large number of files, possibly all of >>> >>>>>>> them, that have not been loaded the code will not work, even if I >>> >>>>>>> skip >>> >>>>>>> over the bad loads or put the loop in a try-catch loop. This must >>> >>>>>>> have something to do with the error message in the log during the >>> >>>>>>> build process with Visual Studio Pro 2010 I did a few days ago. >>> >>>>>>> >>> >>>>>>> I don't fully understand the log, but the section where it failed >>> >>>>>>> is here: >>> >>>>>>> >>> >>>>>>> 112>Link: >>> >>>>>>> 112> Creating library >>> >>>>>>> C:/VTK/lib/Release/vtkRenderingCoreJava.lib >>> >>>>>>> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp >>> >>>>>>> 114> vtkDepthPeeling_fs.cxx >>> >>>>>>> 114> vtkGaussianBlurPassShader_fs.cxx >>> >>>>>>> 114> vtkLighting_s.cxx >>> >>>>>>> 114> vtkLightingHelper_s.cxx >>> >>>>>>> 114> vtkOpenGLRenderer_PeelingFS.cxx >>> >>>>>>> 114> vtkOpenGLPropertyDefaultPropFunc_fs.cxx >>> >>>>>>> 114> vtkOpenGLPropertyDefaultPropFunc_vs.cxx >>> >>>>>>> 112>vtkRenderWindowJava.obj : error LNK2019: unresolved external >>> >>>>>>> symbol __imp__JAWT_GetAWT at 8 referenced in function >>> >>>>>>> _Java_vtk_vtkPanel_RenderCreate at 12 >>> >>>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error >>> >>>>>>> LNK1120: >>> >>>>>>> 1 unresolved externals >>> >>>>>>> 114> vtkOpenGLPropertyDefaultMain_fs.cxx >>> >>>>>>> 112> >>> >>>>>>> 112>Build FAILED. >>> >>>>>>> 112> >>> >>>>>>> 112>Time Elapsed 00:01:32.30 >>> >>>>>>> >>> >>>>>>> Obviously vtkRenderingCoreJava.dll failed to link, which must be >>> >>>>>>> the >>> >>>>>>> cause of the problems I'm having. This was the only failure, with >>> >>>>>>> the >>> >>>>>>> other 387 compilations and linking successful. If this problem >>> >>>>>>> can be >>> >>>>>>> fixed, I hope I will be home and dry. >>> >>>>>>> >>> >>>>>>> I would most appreciate you or someone else kindly getting this >>> >>>>>>> resolved. >>> >>>>>>> >>> >>>>>>> csharp >>> >>>>>>> >>> >>>>>>> On Sat, Mar 21, 2015 at 3:04 PM, Sebastien Jourdain >>> >>>>>>> wrote: >>> >>>>>>>> Try to load the libraries that you need to load instead of all of >>> >>>>>>>> them. >>> >>>>>>>> It >>> >>>>>>>> seems that you didn't build everything (which is probably fine). >>> >>>>>>>> >>> >>>>>>>> Seb >>> >>>>>>>> >>> >>>>>>>> On Sat, Mar 21, 2015 at 2:58 PM, CSharpdotcom . >>> >>>>>>>> >>> >>>>>>>> wrote: >>> >>>>>>>>> >>> >>>>>>>>> I already had PATH=C:\VTK\bin\Release, and added ;%PATH% at the >>> >>>>>>>>> end, >>> >>>>>>>>> but it still doesn't work, and get the following output: >>> >>>>>>>>> >>> >>>>>>>>> java.lang.UnsatisfiedLinkError: >>> >>>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>> >>>>>>>>> libraries >>> >>>>>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>> >>>>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>> >>>>>>>>> at >>> >>>>>>>>> java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>> >>>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >>> >>>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>> >>>>>>>>> at java.lang.System.loadLibrary(System.java:1119) >>> >>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>> >>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>> >>>>>>>>> at >>> >>>>>>>>> >>> >>>>>>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >>> >>>>>>>>> at >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >>> >>>>>>>>> java.lang.UnsatisfiedLinkError: >>> >>>>>>>>> C:\VTK\bin\Release\vtkDomainsChemistryJava.dll: Can't find >>> >>>>>>>>> dependent >>> >>>>>>>>> libraries >>> >>>>>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>> >>>>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>> >>>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >>> >>>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>> >>>>>>>>> at java.lang.System.loadLibrary(System.java:1119) >>> >>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>> >>>>>>>>> at >>> >>>>>>>>> >>> >>>>>>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >>> >>>>>>>>> at >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >>> >>>>>>>>> ................... >>> >>>>>>>>> >>> >>>>>>>>> These error messages continue, then a list of files not loaded >>> >>>>>>>>> are >>> >>>>>>>>> printed out, as given in the source code. >>> >>>>>>>>> >>> >>>>>>>>> Based on these error messages it's picking up the dll files in >>> >>>>>>>>> the >>> >>>>>>>>> \Release folder, but it's unable to find other files that these >>> >>>>>>>>> dll >>> >>>>>>>>> files depend on. >>> >>>>>>>>> >>> >>>>>>>>> Do you want a full listing of the Java source file? The >>> >>>>>>>>> AwtConeRendering class starts off with: >>> >>>>>>>>> >>> >>>>>>>>> static { >>> >>>>>>>>> System.out.println(System.getProperty("java.library.path")); >>> >>>>>>>>> if (!vtkNativeLibrary.LoadAllNativeLibraries()) { >>> >>>>>>>>> for (vtkNativeLibrary lib : vtkNativeLibrary.values()) { >>> >>>>>>>>> if (!lib.IsLoaded()) { >>> >>>>>>>>> System.out.println(lib.GetLibraryName() + " not >>> >>>>>>>>> loaded"); >>> >>>>>>>>> } >>> >>>>>>>>> } >>> >>>>>>>>> } >>> >>>>>>>>> vtkNativeLibrary.DisableOutputWindow(null); >>> >>>>>>>>> } >>> >>>>>>>>> >>> >>>>>>>>> which is followed by the main() method, which contains >>> >>>>>>>>> statements such >>> >>>>>>>>> as: >>> >>>>>>>>> >>> >>>>>>>>> vtkConeSource cone = new vtkConeSource(); >>> >>>>>>>>> >>> >>>>>>>>> csharp >>> >>>>>>>>> >>> >>>>>>>>> On Sat, Mar 21, 2015 at 10:26 AM, Sebastien Jourdain >>> >>>>>>>>> wrote: >>> >>>>>>>>>> Te java.library.path is not enough and you need to add into >>> >>>>>>>>>> your >>> >>>>>>>>>> environment >>> >>>>>>>>>> PATH the following directory, C:\VTK\bin\Release. >>> >>>>>>>>>> >>> >>>>>>>>>> set PATH=C:\VTK\bin\Release;%PATH% >>> >>>>>>>>>> >>> >>>>>>>>>> Seb >>> >>>>>>>>>> >>> >>>>>>>>>> On Sat, Mar 21, 2015 at 10:33 AM, CSharpdotcom . >>> >>>>>>>>>> >>> >>>>>>>>>> wrote: >>> >>>>>>>>>>> >>> >>>>>>>>>>> Hello, >>> >>>>>>>>>>> >>> >>>>>>>>>>> I'm new to VTK and this is my first posting here or on any >>> >>>>>>>>>>> other >>> >>>>>>>>>>> forum >>> >>>>>>>>>>> related to VTK. >>> >>>>>>>>>>> >>> >>>>>>>>>>> I've been trying for about a week to get VTK installed and >>> >>>>>>>>>>> running >>> >>>>>>>>>>> on >>> >>>>>>>>>>> my computer. The project I'm working on is to use Java with >>> >>>>>>>>>>> VTK to >>> >>>>>>>>>>> represent 3D graphics, which I hope to use with NetBeans >>> >>>>>>>>>>> 8.0.2. I >>> >>>>>>>>>>> also have Visual Studio Pro 2010. >>> >>>>>>>>>>> >>> >>>>>>>>>>> After failed attempts in installing VTK 6.2.0 and the latest >>> >>>>>>>>>>> version >>> >>>>>>>>>>> of CMake, from the link >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk >>> >>>>>>>>>>> I downloaded and unzipped VTK 6.1.0 and CMake 3.0.0, then >>> >>>>>>>>>>> installed >>> >>>>>>>>>>> them. >>> >>>>>>>>>>> >>> >>>>>>>>>>> I then ran CMake according to the instructions on that link >>> >>>>>>>>>>> and >>> >>>>>>>>>>> installed the generated code in the folder C:\VTK. I then >>> >>>>>>>>>>> clicked >>> >>>>>>>>>>> on >>> >>>>>>>>>>> the file VTK.sin in that folder, which opened up Visual Studio >>> >>>>>>>>>>> and >>> >>>>>>>>>>> started compiling the code with a large number of modules in >>> >>>>>>>>>>> the >>> >>>>>>>>>>> project. This took about an hour, and on completion, >>> >>>>>>>>>>> generated the >>> >>>>>>>>>>> line at the end: >>> >>>>>>>>>>> >>> >>>>>>>>>>> Build: 387 succeeded, 1 failed, 0 up-to-date, 0 skipped >>> >>>>>>>>>>> >>> >>>>>>>>>>> I saved this in a file, which is very long, and after some >>> >>>>>>>>>>> effort >>> >>>>>>>>>>> found the error message: >>> >>>>>>>>>>> >>> >>>>>>>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error >>> >>>>>>>>>>> LNK1120: >>> >>>>>>>>>>> 1 unresolved externals >>> >>>>>>>>>>> >>> >>>>>>>>>>> In the mean time I attempted to recompile the project, which >>> >>>>>>>>>>> was >>> >>>>>>>>>>> much >>> >>>>>>>>>>> quicker, and got the same message. In recompiled I checked >>> >>>>>>>>>>> the >>> >>>>>>>>>>> "INSTALL" option, which had not previously been checked, >>> >>>>>>>>>>> although I >>> >>>>>>>>>>> don't know if that is significant. >>> >>>>>>>>>>> >>> >>>>>>>>>>> Located in the folder \VTK\java\sample\rendering is the source >>> >>>>>>>>>>> file >>> >>>>>>>>>>> AwTConeRendering.java, which apparently has not been compiled. >>> >>>>>>>>>>> I >>> >>>>>>>>>>> created a NetBeans project and copied that file into it, then >>> >>>>>>>>>>> linked >>> >>>>>>>>>>> vtk.jar in the folder \VTK\bin to the project, and all imports >>> >>>>>>>>>>> were >>> >>>>>>>>>>> satisfied. In setting the Windows path to point to the dll >>> >>>>>>>>>>> files in >>> >>>>>>>>>>> \VTK\bin\Release, the application appears to pick up the dll >>> >>>>>>>>>>> files >>> >>>>>>>>>>> correctly, however, I get the following error message: >>> >>>>>>>>>>> >>> >>>>>>>>>>> java.lang.UnsatisfiedLinkError: >>> >>>>>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>> >>>>>>>>>>> libraries >>> >>>>>>>>>>> >>> >>>>>>>>>>> repeated for many dll files. Incidentally, as Visual Studio >>> >>>>>>>>>>> dlls >>> >>>>>>>>>>> are >>> >>>>>>>>>>> all 32 bits, as far as I know, I set up NetBeans to use a 32 >>> >>>>>>>>>>> bit >>> >>>>>>>>>>> JVM. >>> >>>>>>>>>>> This had previously been tested successfully with a test dll I >>> >>>>>>>>>>> created >>> >>>>>>>>>>> with Visual Studio and could execute with NetBeans. >>> >>>>>>>>>>> >>> >>>>>>>>>>> This problem is presumably related to the first error >>> >>>>>>>>>>> mentioned >>> >>>>>>>>>>> above, >>> >>>>>>>>>>> and would be most grateful in getting this issue resolved. As >>> >>>>>>>>>>> I >>> >>>>>>>>>>> said, >>> >>>>>>>>>>> I'm new to VTK, and in fact only in the last couple of weeks >>> >>>>>>>>>>> have >>> >>>>>>>>>>> tried for the first time to call a dll file from a Java >>> >>>>>>>>>>> application >>> >>>>>>>>>>> on >>> >>>>>>>>>>> a Windows computer. >>> >>>>>>>>>>> >>> >>>>>>>>>>> In the Java code I added the statement: >>> >>>>>>>>>>> >>> >>>>>>>>>>> System.out.println(System.getProperty("java.library.path")); >>> >>>>>>>>>>> >>> >>>>>>>>>>> to check that the path was correct, which is the case. >>> >>>>>>>>>>> _______________________________________________ >>> >>>>>>>>>>> Powered by www.kitware.com >>> >>>>>>>>>>> >>> >>>>>>>>>>> Visit other Kitware open-source projects at >>> >>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>> >>>>>>>>>>> >>> >>>>>>>>>>> Search the list archives at: >>> >>>>>>>>>>> http://markmail.org/search/?q=vtk-developers >>> >>>>>>>>>>> >>> >>>>>>>>>>> Follow this link to subscribe/unsubscribe: >>> >>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>>>> >> >> From csharpdotcom at gmail.com Mon Mar 23 14:13:04 2015 From: csharpdotcom at gmail.com (CSharpdotcom .) Date: Mon, 23 Mar 2015 11:13:04 -0700 Subject: [vtk-developers] Problems installing VTK In-Reply-To: References: <37F0F4BE-C015-452A-A752-B07317B5B42A@kitware.com> <8E906FE3-B09F-4915-BD96-49028C996A23@kitware.com> Message-ID: OK, here is exactly what I have done so far, and have been making notes as follows: Instructions on using CMake 3.3.0 from: http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk https://www.particleincell.com/2011/vtk-java-visualization/ sebastien.jourdain at kitware.com with CC to vtk-developers at vtk.org 1) Start CMake 3.3.0 2) Click "Advanced", enter "Java" in search window, then click "+ Add Entry". "Java" will appear under "Name" in the window below in red. On the right click "..." and a browse folder window opens. Select "C:/Program Files (x86)/Java/jdk1.8.0_31/bin" for the 32 bit Java comiler. 3) Select as source - C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0 4) Select as build binaries - C:/VTK 5) Create empty folder C:/VTK 6) Click "Configure" then select Visualt Studio 2010 - Use default native compilers - Click "Finish" CMakes write output: log1.txt 7) Red screen displayed with the following items: Module_vtkWebJavaScript Module_vtkWrappingJava VTK_WRAP_JAVA 8) Check Module_vtkWrappingJava and VTK_WRAP_JAVA then press "Configure" again. 9) Copy the output to log2.txt. The screem shows the following items in red: JAVA_AWT_INCLUDE_PATH C:/Program Files (x86)/Java/jdk1.8.0_31/include JAVA_AWT_LIBRARY C:/Program Files (x86)/Java/jdk1.8.0_31/lib/jawt.lib JAVA_INCLUDE_PATH C:/Program Files (x86)/Java/jdk1.8.0_31/include JAVA_INCLUDE_PATH2 C:/Program Files (x86)/Java/jdk1.8.0_31/include/win32 JAVA_JVM_LIBRARY C:/Program Files (x86)/Java/jdk1.8.0_31/lib/jvm.lib Java_JAR_EXECUTABLE C:/Program Files (x86)/Java/jdk1.8.0_31/bin/jar.exe Java_JAVAC_EXECUTABLE C:/Program Files (x86)/Java/jdk1.8.0_31/bin/javac.exe Java_JAVADOC_EXECUTABLE C:/Program Files (x86)/Java/jdk1.8.0_31/bin/javadoc.exe Java_JAVAH_EXECUTABLE C:/Program Files (x86)/Java/jdk1.8.0_31/bin/javah.exe Java_JAVA_EXECUTABLE C:/Program Files (x86)/Java/jdk1.8.0_31/lib/java.exe VTK_JAVA_INSTALL Unchecked VTK_JAVA_JOGL_COMPONENT Unchecked VTK_JAVA_SWP_COMPONENR Unchecked The previous items from (7) are shown below not in red with the last two checked. Check VTK_JAVA_INSTALL then press "Configure" again. 10) Copy the output to log3.txt. 11) Click "Generate" - output "Generating done" when completed. The following warnings were printed out at the last configuration: CMake Warning (dev) at ThirdParty/hdf5/vtkhdf5/src/CMakeLists.txt:607 (ADD_CUSTOM_COMMAND): Policy CMP0040 is not set: The target in the TARGET signature of add_custom_command() must exist. Run "cmake --help-policy CMP0040" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The target name "C:/VTK/ThirdParty/hdf5/vtkhdf5/H5Edefin.h" is unknown in this context. This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at ThirdParty/hdf5/vtkhdf5/src/CMakeLists.txt:614 (ADD_CUSTOM_COMMAND): Policy CMP0040 is not set: The target in the TARGET signature of add_custom_command() must exist. Run "cmake --help-policy CMP0040" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The target name "C:/VTK/ThirdParty/hdf5/vtkhdf5/H5version.h" is unknown in this context. This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at ThirdParty/hdf5/vtkhdf5/src/CMakeLists.txt:621 (ADD_CUSTOM_COMMAND): Policy CMP0040 is not set: The target in the TARGET signature of add_custom_command() must exist. Run "cmake --help-policy CMP0040" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The target name "C:/VTK/ThirdParty/hdf5/vtkhdf5/H5overflow.h" is unknown in this context. This warning is for project developers. Use -Wno-dev to suppress it. Please let me know if there are any problems. I'm having a break for Lunch and will be back online shortly after 13:00 (1:00 pm) Arizona time, then will run Visual Studio, which could take a while. Christopher Sharp On Mon, Mar 23, 2015 at 10:37 AM, CSharpdotcom . wrote: > OK, now CMake displays a screen with only 3 entries in red: > > Module_vtkWebJavaScript > Module_vtkWrappingJava > VTK_WRAP_JAVA > > I certainly need the last, and possibly Module_vtkWrappingJava, so I > will check those and click Configure again. The BUILD_SHARED_LIBS > option and the other do not appear, and I don't know why. > > On Mon, Mar 23, 2015 at 10:09 AM, CSharpdotcom . wrote: >> OK, many thanks, I havn't done that before. This is what I just did >> with CMake, I checked the Advanced box, entered "Java" in the search >> window on the left, then clicked " +Add Entry". Below the word "Java" >> appeared under "Name", then searched for the 32 bit Java compiler on >> the right, which is at C:/Program Files (x86)/Java/jdk1.8.0_31/bin. >> >> So far so good, I will now start up CMake 3.3.0 again from scratch, >> having deleted all the old files. After all this I will let you know >> what happens. >> >> Christopher Sharp >> >> On Sun, Mar 22, 2015 at 9:54 PM, Sebastien Jourdain >> wrote: >>> Toggle the advance mode in cmake and search for java, just to make sure >>> cmake find the right version of the lib. >>> >>> Seb >>> >>> On Sun, Mar 22, 2015 at 10:46 PM, CSharpdotcom . >>> wrote: >>>> >>>> Before I saw your message I tried building from scratch again, but >>>> still have errors. >>>> >>>> I didn't see in the link: >>>> >>>> https://www.particleincell.com/2011/vtk-java-visualization/ >>>> >>>> anything about using 32 bit Java in CMake, but it does say it has to >>>> be used with Visual Studio. After Googling around, I saw that the >>>> path environmental variable has to be set to the 32 bit Java, so I >>>> used C:\Program Files (x86)\Java\jre1.0.0_31\bin\client, where the >>>> file jvm.dll is located. >>>> >>>> I will now try again from scratch, with CMake using 32 bit Java. I've >>>> just set on my Windows 8 computer the following paths: >>>> >>>> JAVA_HOME = C:\Progra~2\Java\jdg1.8.0_31 >>>> PATH = C:\Program Files (x86)\jre1.8.-_31\bin >>>> >>>> and will reboot and start again. >>>> >>>> Christopher Sharp >>>> >>>> On Sun, Mar 22, 2015 at 8:58 PM, Sebastien Jourdain >>>> wrote: >>>> > You need to properly set cmake so you don't build the swt nor the Jogl >>>> > components for Java. (You don't need them as you don't know what they are.) >>>> > Moreover the jvm 32b should also be set via cmake. Otherwise VTK won't build >>>> > correctly. >>>> > >>>> > Seb >>>> > >>>> >> On Mar 22, 2015, at 16:05, CSharpdotcom . >>>> >> wrote: >>>> >> >>>> >> Hello, >>>> >> >>>> >> I decided not to install Visual Studio Express, as according to the >>>> >> website Visual Studio Pro was used, which is exactly what I've been >>>> >> using. >>>> >> >>>> >> Anyway, I created a new build folder and repeated the whole process >>>> >> from scratch. The error I'm still getting is: >>>> >> >>>> >> 117>Link: >>>> >> 117> Creating library C:/VTK/lib/Release/vtkRenderingCoreJava.lib >>>> >> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp >>>> >> 117>vtkRenderWindowJava.obj : error LNK2019: unresolved external >>>> >> symbol __imp__JAWT_GetAWT at 8 referenced in function >>>> >> _Java_vtk_vtkPanel_RenderCreate at 12 >>>> >> 117>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: >>>> >> 1 unresolved externals >>>> >> 124> Generating Code... >>>> >> 117> >>>> >> 117>Build FAILED. >>>> >> >>>> >> which is almost certainly due to Visual Studio trying to use 64 bit >>>> >> Java, which is incompatible with the 32 bit code it generates. I was >>>> >> unaware that Visual Studio has to use Java. This should be easy to >>>> >> fix by setting the path it uses to a 32 JVM. >>>> >> >>>> >> In addition, there are two other errors which appear to be related to >>>> >> the components VTK_JAVA_SWT_COMPONENT and VTK_JAVA_SWT_COMPONENT >>>> >> checked in the DMake window, which seem not to be installed in my >>>> >> system. What do they do, and are they needed for what I want to do? >>>> >> If so, I need to find out how to install them, otherwise they can >>>> >> presumably be ignored. >>>> >> >>>> >> Christopher Sharp >>>> >> >>>> >>> On Sun, Mar 22, 2015 at 11:04 AM, CSharpdotcom . >>>> >>> wrote: >>>> >>> Many thanks for your message; what I will do now is backup my VTK >>>> >>> folder, then instead of using Visual Studio 2010 Pro, I will download >>>> >>> the latest version of Visual Studio C++ Express, which is 2013 I >>>> >>> think, and try using DMake again form scratch. In the process I will >>>> >>> note exactly what I did, so if these problems persist, I will have a >>>> >>> record. >>>> >>> >>>> >>> csharp >>>> >>> >>>> >>> On Sun, Mar 22, 2015 at 7:18 AM, Sebastien Jourdain >>>> >>> wrote: >>>> >>>> I didn't see anything strange but can you explain your build process? >>>> >>>> Which property you changed in cmake and how/what did you build in visual >>>> >>>> studio? >>>> >>>> >>>> >>>> Seb >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> On Mar 22, 2015, at 00:11, CSharpdotcom . >>>> >>>>> wrote: >>>> >>>>> >>>> >>>>> OK, many thanks, I didn't know that there was such a file, this is >>>> >>>>> because I'm so new to VTK and CMake. The file is in the root folder >>>> >>>>> and is attached here. >>>> >>>>> >>>> >>>>> I look forward finally to getting this sorted out, as it has now >>>> >>>>> tied >>>> >>>>> me up for about a week. >>>> >>>>> >>>> >>>>> Christopher Sharp >>>> >>>>> >>>> >>>>> On Sat, Mar 21, 2015 at 8:59 PM, Sebastien Jourdain >>>> >>>>> wrote: >>>> >>>>>> I didn't know you had a partial build of VTK. Can you share you >>>> >>>>>> CMakeCache.txt. >>>> >>>>>> >>>> >>>>>> You must have wrongly setup your build. >>>> >>>>>> >>>> >>>>>> Seb >>>> >>>>>> >>>> >>>>>> On Sat, Mar 21, 2015 at 6:05 PM, CSharpdotcom . >>>> >>>>>> >>>> >>>>>> wrote: >>>> >>>>>>> >>>> >>>>>>> Hello, >>>> >>>>>>> >>>> >>>>>>> Many thanks, but as I'm new ti VTK I don't know which libraries to >>>> >>>>>>> load. However, in looking at: >>>> >>>>>>> >>>> >>>>>>> http://www.vtk.org/Wiki/VTK/Examples/Java/Miscellaneous/Cone6 >>>> >>>>>>> >>>> >>>>>>> which has similar code. The statement: >>>> >>>>>>> >>>> >>>>>>> System.loadLibrary("vtkCommonJava"); >>>> >>>>>>> >>>> >>>>>>> doesn't load as there is no dll with that name in the folder >>>> >>>>>>> C:\VTK\bin\Release, but: >>>> >>>>>>> >>>> >>>>>>> System.loadLibrary("vtkCommonCoreJava"); >>>> >>>>>>> >>>> >>>>>>> does load correctly as there is a dll with that name. This >>>> >>>>>>> applies to >>>> >>>>>>> a few other files, but not all of them. Without the required dlls >>>> >>>>>>> loaded, even if no errors are produced, the code will not execute. >>>> >>>>>>> >>>> >>>>>>> If I go back to the original code when I try and load everything, >>>> >>>>>>> then >>>> >>>>>>> I get the error message: >>>> >>>>>>> >>>> >>>>>>> java.lang.UnsatisfiedLinkError: >>>> >>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>> >>>>>>> libraries >>>> >>>>>>> >>>> >>>>>>> The file vtkChartsCoreJava.dll is present in that folder, so it is >>>> >>>>>>> loaded, but its dependencies cannot be found. This applies to >>>> >>>>>>> quite a >>>> >>>>>>> few other dll files with dependencies, and I also get a list of a >>>> >>>>>>> large number files that were not loaded from the statement: >>>> >>>>>>> >>>> >>>>>>> if (!lib.IsLoaded()) System.out.println(lib.GetLibraryName() + " >>>> >>>>>>> not >>>> >>>>>>> loaded"); >>>> >>>>>>> >>>> >>>>>>> inside the for-loop in an earlier message. >>>> >>>>>>> >>>> >>>>>>> It looks that without these large number of files, possibly all of >>>> >>>>>>> them, that have not been loaded the code will not work, even if I >>>> >>>>>>> skip >>>> >>>>>>> over the bad loads or put the loop in a try-catch loop. This must >>>> >>>>>>> have something to do with the error message in the log during the >>>> >>>>>>> build process with Visual Studio Pro 2010 I did a few days ago. >>>> >>>>>>> >>>> >>>>>>> I don't fully understand the log, but the section where it failed >>>> >>>>>>> is here: >>>> >>>>>>> >>>> >>>>>>> 112>Link: >>>> >>>>>>> 112> Creating library >>>> >>>>>>> C:/VTK/lib/Release/vtkRenderingCoreJava.lib >>>> >>>>>>> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp >>>> >>>>>>> 114> vtkDepthPeeling_fs.cxx >>>> >>>>>>> 114> vtkGaussianBlurPassShader_fs.cxx >>>> >>>>>>> 114> vtkLighting_s.cxx >>>> >>>>>>> 114> vtkLightingHelper_s.cxx >>>> >>>>>>> 114> vtkOpenGLRenderer_PeelingFS.cxx >>>> >>>>>>> 114> vtkOpenGLPropertyDefaultPropFunc_fs.cxx >>>> >>>>>>> 114> vtkOpenGLPropertyDefaultPropFunc_vs.cxx >>>> >>>>>>> 112>vtkRenderWindowJava.obj : error LNK2019: unresolved external >>>> >>>>>>> symbol __imp__JAWT_GetAWT at 8 referenced in function >>>> >>>>>>> _Java_vtk_vtkPanel_RenderCreate at 12 >>>> >>>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error >>>> >>>>>>> LNK1120: >>>> >>>>>>> 1 unresolved externals >>>> >>>>>>> 114> vtkOpenGLPropertyDefaultMain_fs.cxx >>>> >>>>>>> 112> >>>> >>>>>>> 112>Build FAILED. >>>> >>>>>>> 112> >>>> >>>>>>> 112>Time Elapsed 00:01:32.30 >>>> >>>>>>> >>>> >>>>>>> Obviously vtkRenderingCoreJava.dll failed to link, which must be >>>> >>>>>>> the >>>> >>>>>>> cause of the problems I'm having. This was the only failure, with >>>> >>>>>>> the >>>> >>>>>>> other 387 compilations and linking successful. If this problem >>>> >>>>>>> can be >>>> >>>>>>> fixed, I hope I will be home and dry. >>>> >>>>>>> >>>> >>>>>>> I would most appreciate you or someone else kindly getting this >>>> >>>>>>> resolved. >>>> >>>>>>> >>>> >>>>>>> csharp >>>> >>>>>>> >>>> >>>>>>> On Sat, Mar 21, 2015 at 3:04 PM, Sebastien Jourdain >>>> >>>>>>> wrote: >>>> >>>>>>>> Try to load the libraries that you need to load instead of all of >>>> >>>>>>>> them. >>>> >>>>>>>> It >>>> >>>>>>>> seems that you didn't build everything (which is probably fine). >>>> >>>>>>>> >>>> >>>>>>>> Seb >>>> >>>>>>>> >>>> >>>>>>>> On Sat, Mar 21, 2015 at 2:58 PM, CSharpdotcom . >>>> >>>>>>>> >>>> >>>>>>>> wrote: >>>> >>>>>>>>> >>>> >>>>>>>>> I already had PATH=C:\VTK\bin\Release, and added ;%PATH% at the >>>> >>>>>>>>> end, >>>> >>>>>>>>> but it still doesn't work, and get the following output: >>>> >>>>>>>>> >>>> >>>>>>>>> java.lang.UnsatisfiedLinkError: >>>> >>>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>> >>>>>>>>> libraries >>>> >>>>>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>> >>>>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>> >>>>>>>>> at >>>> >>>>>>>>> java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>> >>>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >>>> >>>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>> >>>>>>>>> at java.lang.System.loadLibrary(System.java:1119) >>>> >>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>> >>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>> >>>>>>>>> at >>>> >>>>>>>>> >>>> >>>>>>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >>>> >>>>>>>>> at >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >>>> >>>>>>>>> java.lang.UnsatisfiedLinkError: >>>> >>>>>>>>> C:\VTK\bin\Release\vtkDomainsChemistryJava.dll: Can't find >>>> >>>>>>>>> dependent >>>> >>>>>>>>> libraries >>>> >>>>>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>> >>>>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>> >>>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >>>> >>>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>> >>>>>>>>> at java.lang.System.loadLibrary(System.java:1119) >>>> >>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>> >>>>>>>>> at >>>> >>>>>>>>> >>>> >>>>>>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >>>> >>>>>>>>> at >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >>>> >>>>>>>>> ................... >>>> >>>>>>>>> >>>> >>>>>>>>> These error messages continue, then a list of files not loaded >>>> >>>>>>>>> are >>>> >>>>>>>>> printed out, as given in the source code. >>>> >>>>>>>>> >>>> >>>>>>>>> Based on these error messages it's picking up the dll files in >>>> >>>>>>>>> the >>>> >>>>>>>>> \Release folder, but it's unable to find other files that these >>>> >>>>>>>>> dll >>>> >>>>>>>>> files depend on. >>>> >>>>>>>>> >>>> >>>>>>>>> Do you want a full listing of the Java source file? The >>>> >>>>>>>>> AwtConeRendering class starts off with: >>>> >>>>>>>>> >>>> >>>>>>>>> static { >>>> >>>>>>>>> System.out.println(System.getProperty("java.library.path")); >>>> >>>>>>>>> if (!vtkNativeLibrary.LoadAllNativeLibraries()) { >>>> >>>>>>>>> for (vtkNativeLibrary lib : vtkNativeLibrary.values()) { >>>> >>>>>>>>> if (!lib.IsLoaded()) { >>>> >>>>>>>>> System.out.println(lib.GetLibraryName() + " not >>>> >>>>>>>>> loaded"); >>>> >>>>>>>>> } >>>> >>>>>>>>> } >>>> >>>>>>>>> } >>>> >>>>>>>>> vtkNativeLibrary.DisableOutputWindow(null); >>>> >>>>>>>>> } >>>> >>>>>>>>> >>>> >>>>>>>>> which is followed by the main() method, which contains >>>> >>>>>>>>> statements such >>>> >>>>>>>>> as: >>>> >>>>>>>>> >>>> >>>>>>>>> vtkConeSource cone = new vtkConeSource(); >>>> >>>>>>>>> >>>> >>>>>>>>> csharp >>>> >>>>>>>>> >>>> >>>>>>>>> On Sat, Mar 21, 2015 at 10:26 AM, Sebastien Jourdain >>>> >>>>>>>>> wrote: >>>> >>>>>>>>>> Te java.library.path is not enough and you need to add into >>>> >>>>>>>>>> your >>>> >>>>>>>>>> environment >>>> >>>>>>>>>> PATH the following directory, C:\VTK\bin\Release. >>>> >>>>>>>>>> >>>> >>>>>>>>>> set PATH=C:\VTK\bin\Release;%PATH% >>>> >>>>>>>>>> >>>> >>>>>>>>>> Seb >>>> >>>>>>>>>> >>>> >>>>>>>>>> On Sat, Mar 21, 2015 at 10:33 AM, CSharpdotcom . >>>> >>>>>>>>>> >>>> >>>>>>>>>> wrote: >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> Hello, >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> I'm new to VTK and this is my first posting here or on any >>>> >>>>>>>>>>> other >>>> >>>>>>>>>>> forum >>>> >>>>>>>>>>> related to VTK. >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> I've been trying for about a week to get VTK installed and >>>> >>>>>>>>>>> running >>>> >>>>>>>>>>> on >>>> >>>>>>>>>>> my computer. The project I'm working on is to use Java with >>>> >>>>>>>>>>> VTK to >>>> >>>>>>>>>>> represent 3D graphics, which I hope to use with NetBeans >>>> >>>>>>>>>>> 8.0.2. I >>>> >>>>>>>>>>> also have Visual Studio Pro 2010. >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> After failed attempts in installing VTK 6.2.0 and the latest >>>> >>>>>>>>>>> version >>>> >>>>>>>>>>> of CMake, from the link >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk >>>> >>>>>>>>>>> I downloaded and unzipped VTK 6.1.0 and CMake 3.0.0, then >>>> >>>>>>>>>>> installed >>>> >>>>>>>>>>> them. >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> I then ran CMake according to the instructions on that link >>>> >>>>>>>>>>> and >>>> >>>>>>>>>>> installed the generated code in the folder C:\VTK. I then >>>> >>>>>>>>>>> clicked >>>> >>>>>>>>>>> on >>>> >>>>>>>>>>> the file VTK.sin in that folder, which opened up Visual Studio >>>> >>>>>>>>>>> and >>>> >>>>>>>>>>> started compiling the code with a large number of modules in >>>> >>>>>>>>>>> the >>>> >>>>>>>>>>> project. This took about an hour, and on completion, >>>> >>>>>>>>>>> generated the >>>> >>>>>>>>>>> line at the end: >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> Build: 387 succeeded, 1 failed, 0 up-to-date, 0 skipped >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> I saved this in a file, which is very long, and after some >>>> >>>>>>>>>>> effort >>>> >>>>>>>>>>> found the error message: >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error >>>> >>>>>>>>>>> LNK1120: >>>> >>>>>>>>>>> 1 unresolved externals >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> In the mean time I attempted to recompile the project, which >>>> >>>>>>>>>>> was >>>> >>>>>>>>>>> much >>>> >>>>>>>>>>> quicker, and got the same message. In recompiled I checked >>>> >>>>>>>>>>> the >>>> >>>>>>>>>>> "INSTALL" option, which had not previously been checked, >>>> >>>>>>>>>>> although I >>>> >>>>>>>>>>> don't know if that is significant. >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> Located in the folder \VTK\java\sample\rendering is the source >>>> >>>>>>>>>>> file >>>> >>>>>>>>>>> AwTConeRendering.java, which apparently has not been compiled. >>>> >>>>>>>>>>> I >>>> >>>>>>>>>>> created a NetBeans project and copied that file into it, then >>>> >>>>>>>>>>> linked >>>> >>>>>>>>>>> vtk.jar in the folder \VTK\bin to the project, and all imports >>>> >>>>>>>>>>> were >>>> >>>>>>>>>>> satisfied. In setting the Windows path to point to the dll >>>> >>>>>>>>>>> files in >>>> >>>>>>>>>>> \VTK\bin\Release, the application appears to pick up the dll >>>> >>>>>>>>>>> files >>>> >>>>>>>>>>> correctly, however, I get the following error message: >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> java.lang.UnsatisfiedLinkError: >>>> >>>>>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>> >>>>>>>>>>> libraries >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> repeated for many dll files. Incidentally, as Visual Studio >>>> >>>>>>>>>>> dlls >>>> >>>>>>>>>>> are >>>> >>>>>>>>>>> all 32 bits, as far as I know, I set up NetBeans to use a 32 >>>> >>>>>>>>>>> bit >>>> >>>>>>>>>>> JVM. >>>> >>>>>>>>>>> This had previously been tested successfully with a test dll I >>>> >>>>>>>>>>> created >>>> >>>>>>>>>>> with Visual Studio and could execute with NetBeans. >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> This problem is presumably related to the first error >>>> >>>>>>>>>>> mentioned >>>> >>>>>>>>>>> above, >>>> >>>>>>>>>>> and would be most grateful in getting this issue resolved. As >>>> >>>>>>>>>>> I >>>> >>>>>>>>>>> said, >>>> >>>>>>>>>>> I'm new to VTK, and in fact only in the last couple of weeks >>>> >>>>>>>>>>> have >>>> >>>>>>>>>>> tried for the first time to call a dll file from a Java >>>> >>>>>>>>>>> application >>>> >>>>>>>>>>> on >>>> >>>>>>>>>>> a Windows computer. >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> In the Java code I added the statement: >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> System.out.println(System.getProperty("java.library.path")); >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> to check that the path was correct, which is the case. >>>> >>>>>>>>>>> _______________________________________________ >>>> >>>>>>>>>>> Powered by www.kitware.com >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> Visit other Kitware open-source projects at >>>> >>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> Search the list archives at: >>>> >>>>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>> >>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>>> >>> >>> From david.gobbi at gmail.com Mon Mar 23 16:38:06 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 23 Mar 2015 14:38:06 -0600 Subject: [vtk-developers] Adding support for a macro in wrapper In-Reply-To: References: <20150311184927.GB11496@megas.kitwarein.com> Message-ID: On Thu, Mar 19, 2015 at 12:56 PM, David Lonie wrote: > On Wed, Mar 11, 2015 at 3:47 PM, David Lonie > wrote: > >> On Wed, Mar 11, 2015 at 3:46 PM, David Gobbi >> wrote: >>> >>> The old GetBounds() method might be hidden in the wrapped classes due to >>> "using" being ignored. >>> >> >> I'll be sure to test this before I merge -- thanks for the heads up. >> > > Just FYI, the wrappers seem to handle the 'using Superclass::method;' > statement as expected :D > I built your topic (with VTK_LEGACY_REMOVE:BOOL=OFF) and tested GetBounds() from the python wrappers to see if the 'using' statement was applied: from vtk import * v = vtkVolume() v.GetBounds() Traceback (most recent call last): File "", line 1, in TypeError: GetBounds() takes exactly 2 arguments (0 given) Conclusion: the wrappers do not handle the 'using' statement. This is something that I might be able to add later this week (it's been on my mind for a few years, I always knew that it would eventually have to be done). - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Mon Mar 23 16:44:23 2015 From: david.lonie at kitware.com (David Lonie) Date: Mon, 23 Mar 2015 16:44:23 -0400 Subject: [vtk-developers] Adding support for a macro in wrapper In-Reply-To: References: <20150311184927.GB11496@megas.kitwarein.com> Message-ID: On Mon, Mar 23, 2015 at 4:38 PM, David Gobbi wrote: > On Thu, Mar 19, 2015 at 12:56 PM, David Lonie > wrote: > >> On Wed, Mar 11, 2015 at 3:47 PM, David Lonie >> wrote: >> >>> On Wed, Mar 11, 2015 at 3:46 PM, David Gobbi >>> wrote: >>>> >>>> The old GetBounds() method might be hidden in the wrapped classes due >>>> to "using" being ignored. >>>> >>> >>> I'll be sure to test this before I merge -- thanks for the heads up. >>> >> >> Just FYI, the wrappers seem to handle the 'using Superclass::method;' >> statement as expected :D >> > > I built your topic (with VTK_LEGACY_REMOVE:BOOL=OFF) and tested GetBounds() > from the python wrappers to see if the 'using' statement was applied: > > from vtk import * > v = vtkVolume() > v.GetBounds() > Traceback (most recent call last): > File "", line 1, in > TypeError: GetBounds() takes exactly 2 arguments (0 given) > > Conclusion: the wrappers do not handle the 'using' statement. This is > something that > I might be able to add later this week (it's been on my mind for a few > years, I always > knew that it would eventually have to be done). > I was surprised to hear this, then I realized my mistake....the code that I was thinking of used GetCenter, not GetBounds, which was similarly deprecated but is not virtual, thus no overrides and no need for 'using' -- hence why the tests all still passed... >.< I'm glad you retested :) If you can add support for this soon, great! We'll have to wait for the dust to settle around the possible Tcl deprecation before this change can go it, so you should have plenty of time! Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From josp.jorge at gmail.com Mon Mar 23 16:46:16 2015 From: josp.jorge at gmail.com (Jorge Perez) Date: Mon, 23 Mar 2015 21:46:16 +0100 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: Hello, we are developing some applications based on VTK + Tcl. For our requirements, we think this a very productive multi-platform solution and we would like to provide support to solve the issue here raised with the aim to continue the development of the Tcl Wrapping capabilities in VTK. In order to help in this issue we appreciate any guide to understand the arguments that vtkWrapTcl is processing. best regards, Jorge 2015-03-23 16:18 GMT+01:00 David Lonie : > On Fri, Mar 20, 2015 at 9:42 AM, David Gobbi > wrote: > >> On Fri, Mar 20, 2015 at 7:17 AM, David Lonie >> wrote: >> >>> On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi >>> wrote: >>> >>>> On Thu, Mar 19, 2015 at 2:28 PM, David Lonie >>>> wrote: >>>> >>>>> 2) If so, how can I teach the wrappers about it? >>>>> >>>> >>>> Adding things like this to Tcl is easier than for Java or Python, but >>>> it's more than an afternoon's work. >>>> >>> >>> One more thing: >>> >>> If you know offhand, can you briefly outline the steps that are needed >>> to do this? That might help clarify whether the maintenance burden is >>> excessive or not. Would it be a one-time deal that would teach Tcl how to >>> wrap all similar methods, or would it need to be repeated for every similar >>> method that gets added? >>> >> >> My brief outline is this: find the code in vtkWrapTcl.c that builds >> arrays to be used as return values, and then do something similar for this >> new kind of method signature, except have it assign a global name (whatever >> name was passed as a parameter) to the new array instead of returning it. >> If it is done for this method, it should work for all similar methods. >> > > This seems more doable than I'd feared, since it'd be a generic approach > that should "just work" for similar cases. > > It sounds like there's a lot of support for removing Tcl, but it's > unlikely that we'll see it go away completely anytime soon for a multitude > of reasons. So back to the immediate issue of how the GetBounds change can > be made to work with the wrappers, I see three options: > > 1) Train the wrappers to understand it. Might not be worth the effort if > we're planning to pull support soon. > > 2) Add an additional non-deprecated GetBounds signature > > double* GetBounds(vtkViewport*) > > I don't like this approach as it has issues thread safety, and requires > each object to carry around an array just to pass results back to a caller > -- a pattern we should be moving away from. I'd be more supportive of this > approach if we decided to use vtkTuple instead of double*, but > this would also be likely to require some significant wrapper training > and/or concrete vtkTuple subclasses. > > 3) Begin a long-term deprecation of Tcl. We'll not plan on removing it > completely anytime soon, but enabling Tcl wrapping will also require > enabling legacy code in VTK. This way the old legacy GetBounds, etc > signatures will still be available to Tcl, and feedback from the > deprecation would help us understand the full impact of completely removing > Tcl, as we'll grab the attention of users that might not follow the mailing > lists. > > My vote is for 3 -- it's an easy change that gives people a heads-up about > then inevitable future removal of Tcl support, and ensures that everything > will "just work" for legacy code until we decide to completely pull the > plug. > > Thoughts? Votes? Alternatives? > > Dave > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Mar 23 17:13:35 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 23 Mar 2015 15:13:35 -0600 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: On Mon, Mar 23, 2015 at 2:46 PM, Jorge Perez wrote: > Hello, we are developing some applications based on VTK + Tcl. For our > requirements, we think this a very productive multi-platform solution and > we would like to provide support to solve the issue here raised with the > aim to continue the development of the Tcl Wrapping capabilities in VTK. In > order to help in this issue we appreciate any guide to understand the > arguments that vtkWrapTcl is processing. > Rough guide to understanding vtkWrapTcl.c: 1) Look for the main() function, which is at around line 1100. It uses a few important data structures: OptionInfo, FileInfo, ClassInfo. 2) Read vtkParseMain.h, vtkParseData.h, vtkParseType.h, vtkParseHierarchy.h to understand the data structures that are involved in VTK wrapping 3) Most of vtkWrapTcl.c is a bunch of fprintf() statements that produce C++ code for the wrappers. I don't have much advice here except to trace through the code, starting at the first "fprintf(fp, ..." at line 1132 in main(). This is the place where vtkWrapTcl starts writing the wrapper code. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From goodwin.lawlor.lists at gmail.com Mon Mar 23 17:34:08 2015 From: goodwin.lawlor.lists at gmail.com (Goodwin Lawlor) Date: Mon, 23 Mar 2015 21:34:08 +0000 Subject: [vtk-developers] Renderman Announces new pricing policy In-Reply-To: References: Message-ID: Renderman free non-commercial version is released! http://rendermansite.pixar.com/view/get-renderman -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Mar 23 17:40:19 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 23 Mar 2015 14:40:19 -0700 Subject: [vtk-developers] Renderman Announces new pricing policy In-Reply-To: References: Message-ID: I trying to download it now. Also, I'm working on updating the RIB exporter, property and light to work with modern render man. Keep you posted. On Mon, Mar 23, 2015 at 2:34 PM, Goodwin Lawlor wrote: > Renderman free non-commercial version is released! > > http://rendermansite.pixar.com/view/get-renderman > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From david.gobbi at gmail.com Mon Mar 23 17:51:43 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 23 Mar 2015 15:51:43 -0600 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: Hi David, It's apparent to me that part of the difficulty surrounding this change is due to the name of the method. Why not use a new name? bool ComputeBoundsForViewport(vtkViewport *, double bounds[6]); I confess that I have an ulterior motive. I like all Get() or Set() methods to get/set a property that depends only on the the object itself. Here, the Bounds depend on both the object and on a second object. So I don't consider this method to be a "getter" in the strict sense, hence "ComputeBounds" rather than "GetBounds". Basically, I like it when Get methods are associated with properties/traits of the object. Eventually, VTK's wrappers might associate Set/Get methods with Python properties. In fact, this idea can already be seen in action in tvtk, Enthought's Traited VTK. - David On Mon, Mar 23, 2015 at 9:18 AM, David Lonie wrote: > On Fri, Mar 20, 2015 at 9:42 AM, David Gobbi > wrote: > >> On Fri, Mar 20, 2015 at 7:17 AM, David Lonie >> wrote: >> >>> On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi >>> wrote: >>> >>>> On Thu, Mar 19, 2015 at 2:28 PM, David Lonie >>>> wrote: >>>> >>>>> 2) If so, how can I teach the wrappers about it? >>>>> >>>> >>>> Adding things like this to Tcl is easier than for Java or Python, but >>>> it's more than an afternoon's work. >>>> >>> >>> One more thing: >>> >>> If you know offhand, can you briefly outline the steps that are needed >>> to do this? That might help clarify whether the maintenance burden is >>> excessive or not. Would it be a one-time deal that would teach Tcl how to >>> wrap all similar methods, or would it need to be repeated for every similar >>> method that gets added? >>> >> >> My brief outline is this: find the code in vtkWrapTcl.c that builds >> arrays to be used as return values, and then do something similar for this >> new kind of method signature, except have it assign a global name (whatever >> name was passed as a parameter) to the new array instead of returning it. >> If it is done for this method, it should work for all similar methods. >> > > This seems more doable than I'd feared, since it'd be a generic approach > that should "just work" for similar cases. > > It sounds like there's a lot of support for removing Tcl, but it's > unlikely that we'll see it go away completely anytime soon for a multitude > of reasons. So back to the immediate issue of how the GetBounds change can > be made to work with the wrappers, I see three options: > > 1) Train the wrappers to understand it. Might not be worth the effort if > we're planning to pull support soon. > > 2) Add an additional non-deprecated GetBounds signature > > double* GetBounds(vtkViewport*) > > I don't like this approach as it has issues thread safety, and requires > each object to carry around an array just to pass results back to a caller > -- a pattern we should be moving away from. I'd be more supportive of this > approach if we decided to use vtkTuple instead of double*, but > this would also be likely to require some significant wrapper training > and/or concrete vtkTuple subclasses. > > 3) Begin a long-term deprecation of Tcl. We'll not plan on removing it > completely anytime soon, but enabling Tcl wrapping will also require > enabling legacy code in VTK. This way the old legacy GetBounds, etc > signatures will still be available to Tcl, and feedback from the > deprecation would help us understand the full impact of completely removing > Tcl, as we'll grab the attention of users that might not follow the mailing > lists. > > My vote is for 3 -- it's an easy change that gives people a heads-up about > then inevitable future removal of Tcl support, and ensures that everything > will "just work" for legacy code until we decide to completely pull the > plug. > > Thoughts? Votes? Alternatives? > > Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From csharpdotcom at gmail.com Mon Mar 23 18:11:00 2015 From: csharpdotcom at gmail.com (CSharpdotcom .) Date: Mon, 23 Mar 2015 15:11:00 -0700 Subject: [vtk-developers] Problems installing VTK In-Reply-To: References: <37F0F4BE-C015-452A-A752-B07317B5B42A@kitware.com> <8E906FE3-B09F-4915-BD96-49028C996A23@kitware.com> Message-ID: Great news, I finally got VTK to work, so thank you very much for all your help!!! I used the example at: https://www.particleincell.com/2011/vtk-java-visualization/ with NetBeans. Christopher Sharp On Mon, Mar 23, 2015 at 11:13 AM, CSharpdotcom . wrote: > OK, here is exactly what I have done so far, and have been making > notes as follows: > > Instructions on using CMake 3.3.0 from: > > http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk > https://www.particleincell.com/2011/vtk-java-visualization/ > sebastien.jourdain at kitware.com with CC to vtk-developers at vtk.org > > 1) Start CMake 3.3.0 > > 2) Click "Advanced", enter "Java" in search window, then click "+ Add Entry". > "Java" will appear under "Name" in the window below in red. On the > right click "..." and a browse > > folder > window opens. Select "C:/Program Files (x86)/Java/jdk1.8.0_31/bin" > for the 32 bit Java comiler. > > 3) Select as source - > C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0 > > 4) Select as build binaries - C:/VTK > > 5) Create empty folder C:/VTK > > 6) Click "Configure" then select Visualt Studio 2010 - Use default > native compilers - Click "Finish" > CMakes write output: log1.txt > > 7) Red screen displayed with the following items: > > Module_vtkWebJavaScript > Module_vtkWrappingJava > VTK_WRAP_JAVA > > 8) Check Module_vtkWrappingJava and VTK_WRAP_JAVA then press "Configure" again. > > 9) Copy the output to log2.txt. The screem shows the following items in red: > > JAVA_AWT_INCLUDE_PATH C:/Program Files (x86)/Java/jdk1.8.0_31/include > JAVA_AWT_LIBRARY C:/Program Files > (x86)/Java/jdk1.8.0_31/lib/jawt.lib > JAVA_INCLUDE_PATH C:/Program Files (x86)/Java/jdk1.8.0_31/include > JAVA_INCLUDE_PATH2 C:/Program Files > (x86)/Java/jdk1.8.0_31/include/win32 > JAVA_JVM_LIBRARY C:/Program Files > (x86)/Java/jdk1.8.0_31/lib/jvm.lib > Java_JAR_EXECUTABLE C:/Program Files > (x86)/Java/jdk1.8.0_31/bin/jar.exe > Java_JAVAC_EXECUTABLE C:/Program Files > (x86)/Java/jdk1.8.0_31/bin/javac.exe > Java_JAVADOC_EXECUTABLE C:/Program Files > (x86)/Java/jdk1.8.0_31/bin/javadoc.exe > Java_JAVAH_EXECUTABLE C:/Program Files > (x86)/Java/jdk1.8.0_31/bin/javah.exe > Java_JAVA_EXECUTABLE C:/Program Files > (x86)/Java/jdk1.8.0_31/lib/java.exe > VTK_JAVA_INSTALL Unchecked > VTK_JAVA_JOGL_COMPONENT Unchecked > VTK_JAVA_SWP_COMPONENR Unchecked > > The previous items from (7) are shown below not in red with the > last two checked. > Check VTK_JAVA_INSTALL then press "Configure" again. > > 10) Copy the output to log3.txt. > > 11) Click "Generate" - output "Generating done" when completed. > > The following warnings were printed out at the last configuration: > > CMake Warning (dev) at ThirdParty/hdf5/vtkhdf5/src/CMakeLists.txt:607 > (ADD_CUSTOM_COMMAND): > Policy CMP0040 is not set: The target in the TARGET signature of > add_custom_command() must exist. Run "cmake --help-policy CMP0040" for > policy details. Use the cmake_policy command to set the policy and > suppress this warning. > > The target name "C:/VTK/ThirdParty/hdf5/vtkhdf5/H5Edefin.h" is unknown in > this context. > This warning is for project developers. Use -Wno-dev to suppress it. > > CMake Warning (dev) at ThirdParty/hdf5/vtkhdf5/src/CMakeLists.txt:614 > (ADD_CUSTOM_COMMAND): > Policy CMP0040 is not set: The target in the TARGET signature of > add_custom_command() must exist. Run "cmake --help-policy CMP0040" for > policy details. Use the cmake_policy command to set the policy and > suppress this warning. > > The target name "C:/VTK/ThirdParty/hdf5/vtkhdf5/H5version.h" is unknown in > this context. > This warning is for project developers. Use -Wno-dev to suppress it. > > CMake Warning (dev) at ThirdParty/hdf5/vtkhdf5/src/CMakeLists.txt:621 > (ADD_CUSTOM_COMMAND): > Policy CMP0040 is not set: The target in the TARGET signature of > add_custom_command() must exist. Run "cmake --help-policy CMP0040" for > policy details. Use the cmake_policy command to set the policy and > suppress this warning. > > The target name "C:/VTK/ThirdParty/hdf5/vtkhdf5/H5overflow.h" is unknown in > this context. > This warning is for project developers. Use -Wno-dev to suppress it. > > Please let me know if there are any problems. > > I'm having a break for Lunch and will be back online shortly after > 13:00 (1:00 pm) Arizona time, then will run Visual Studio, which could > take a while. > > Christopher Sharp > > On Mon, Mar 23, 2015 at 10:37 AM, CSharpdotcom . wrote: >> OK, now CMake displays a screen with only 3 entries in red: >> >> Module_vtkWebJavaScript >> Module_vtkWrappingJava >> VTK_WRAP_JAVA >> >> I certainly need the last, and possibly Module_vtkWrappingJava, so I >> will check those and click Configure again. The BUILD_SHARED_LIBS >> option and the other do not appear, and I don't know why. >> >> On Mon, Mar 23, 2015 at 10:09 AM, CSharpdotcom . wrote: >>> OK, many thanks, I havn't done that before. This is what I just did >>> with CMake, I checked the Advanced box, entered "Java" in the search >>> window on the left, then clicked " +Add Entry". Below the word "Java" >>> appeared under "Name", then searched for the 32 bit Java compiler on >>> the right, which is at C:/Program Files (x86)/Java/jdk1.8.0_31/bin. >>> >>> So far so good, I will now start up CMake 3.3.0 again from scratch, >>> having deleted all the old files. After all this I will let you know >>> what happens. >>> >>> Christopher Sharp >>> >>> On Sun, Mar 22, 2015 at 9:54 PM, Sebastien Jourdain >>> wrote: >>>> Toggle the advance mode in cmake and search for java, just to make sure >>>> cmake find the right version of the lib. >>>> >>>> Seb >>>> >>>> On Sun, Mar 22, 2015 at 10:46 PM, CSharpdotcom . >>>> wrote: >>>>> >>>>> Before I saw your message I tried building from scratch again, but >>>>> still have errors. >>>>> >>>>> I didn't see in the link: >>>>> >>>>> https://www.particleincell.com/2011/vtk-java-visualization/ >>>>> >>>>> anything about using 32 bit Java in CMake, but it does say it has to >>>>> be used with Visual Studio. After Googling around, I saw that the >>>>> path environmental variable has to be set to the 32 bit Java, so I >>>>> used C:\Program Files (x86)\Java\jre1.0.0_31\bin\client, where the >>>>> file jvm.dll is located. >>>>> >>>>> I will now try again from scratch, with CMake using 32 bit Java. I've >>>>> just set on my Windows 8 computer the following paths: >>>>> >>>>> JAVA_HOME = C:\Progra~2\Java\jdg1.8.0_31 >>>>> PATH = C:\Program Files (x86)\jre1.8.-_31\bin >>>>> >>>>> and will reboot and start again. >>>>> >>>>> Christopher Sharp >>>>> >>>>> On Sun, Mar 22, 2015 at 8:58 PM, Sebastien Jourdain >>>>> wrote: >>>>> > You need to properly set cmake so you don't build the swt nor the Jogl >>>>> > components for Java. (You don't need them as you don't know what they are.) >>>>> > Moreover the jvm 32b should also be set via cmake. Otherwise VTK won't build >>>>> > correctly. >>>>> > >>>>> > Seb >>>>> > >>>>> >> On Mar 22, 2015, at 16:05, CSharpdotcom . >>>>> >> wrote: >>>>> >> >>>>> >> Hello, >>>>> >> >>>>> >> I decided not to install Visual Studio Express, as according to the >>>>> >> website Visual Studio Pro was used, which is exactly what I've been >>>>> >> using. >>>>> >> >>>>> >> Anyway, I created a new build folder and repeated the whole process >>>>> >> from scratch. The error I'm still getting is: >>>>> >> >>>>> >> 117>Link: >>>>> >> 117> Creating library C:/VTK/lib/Release/vtkRenderingCoreJava.lib >>>>> >> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp >>>>> >> 117>vtkRenderWindowJava.obj : error LNK2019: unresolved external >>>>> >> symbol __imp__JAWT_GetAWT at 8 referenced in function >>>>> >> _Java_vtk_vtkPanel_RenderCreate at 12 >>>>> >> 117>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: >>>>> >> 1 unresolved externals >>>>> >> 124> Generating Code... >>>>> >> 117> >>>>> >> 117>Build FAILED. >>>>> >> >>>>> >> which is almost certainly due to Visual Studio trying to use 64 bit >>>>> >> Java, which is incompatible with the 32 bit code it generates. I was >>>>> >> unaware that Visual Studio has to use Java. This should be easy to >>>>> >> fix by setting the path it uses to a 32 JVM. >>>>> >> >>>>> >> In addition, there are two other errors which appear to be related to >>>>> >> the components VTK_JAVA_SWT_COMPONENT and VTK_JAVA_SWT_COMPONENT >>>>> >> checked in the DMake window, which seem not to be installed in my >>>>> >> system. What do they do, and are they needed for what I want to do? >>>>> >> If so, I need to find out how to install them, otherwise they can >>>>> >> presumably be ignored. >>>>> >> >>>>> >> Christopher Sharp >>>>> >> >>>>> >>> On Sun, Mar 22, 2015 at 11:04 AM, CSharpdotcom . >>>>> >>> wrote: >>>>> >>> Many thanks for your message; what I will do now is backup my VTK >>>>> >>> folder, then instead of using Visual Studio 2010 Pro, I will download >>>>> >>> the latest version of Visual Studio C++ Express, which is 2013 I >>>>> >>> think, and try using DMake again form scratch. In the process I will >>>>> >>> note exactly what I did, so if these problems persist, I will have a >>>>> >>> record. >>>>> >>> >>>>> >>> csharp >>>>> >>> >>>>> >>> On Sun, Mar 22, 2015 at 7:18 AM, Sebastien Jourdain >>>>> >>> wrote: >>>>> >>>> I didn't see anything strange but can you explain your build process? >>>>> >>>> Which property you changed in cmake and how/what did you build in visual >>>>> >>>> studio? >>>>> >>>> >>>>> >>>> Seb >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>>> On Mar 22, 2015, at 00:11, CSharpdotcom . >>>>> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> OK, many thanks, I didn't know that there was such a file, this is >>>>> >>>>> because I'm so new to VTK and CMake. The file is in the root folder >>>>> >>>>> and is attached here. >>>>> >>>>> >>>>> >>>>> I look forward finally to getting this sorted out, as it has now >>>>> >>>>> tied >>>>> >>>>> me up for about a week. >>>>> >>>>> >>>>> >>>>> Christopher Sharp >>>>> >>>>> >>>>> >>>>> On Sat, Mar 21, 2015 at 8:59 PM, Sebastien Jourdain >>>>> >>>>> wrote: >>>>> >>>>>> I didn't know you had a partial build of VTK. Can you share you >>>>> >>>>>> CMakeCache.txt. >>>>> >>>>>> >>>>> >>>>>> You must have wrongly setup your build. >>>>> >>>>>> >>>>> >>>>>> Seb >>>>> >>>>>> >>>>> >>>>>> On Sat, Mar 21, 2015 at 6:05 PM, CSharpdotcom . >>>>> >>>>>> >>>>> >>>>>> wrote: >>>>> >>>>>>> >>>>> >>>>>>> Hello, >>>>> >>>>>>> >>>>> >>>>>>> Many thanks, but as I'm new ti VTK I don't know which libraries to >>>>> >>>>>>> load. However, in looking at: >>>>> >>>>>>> >>>>> >>>>>>> http://www.vtk.org/Wiki/VTK/Examples/Java/Miscellaneous/Cone6 >>>>> >>>>>>> >>>>> >>>>>>> which has similar code. The statement: >>>>> >>>>>>> >>>>> >>>>>>> System.loadLibrary("vtkCommonJava"); >>>>> >>>>>>> >>>>> >>>>>>> doesn't load as there is no dll with that name in the folder >>>>> >>>>>>> C:\VTK\bin\Release, but: >>>>> >>>>>>> >>>>> >>>>>>> System.loadLibrary("vtkCommonCoreJava"); >>>>> >>>>>>> >>>>> >>>>>>> does load correctly as there is a dll with that name. This >>>>> >>>>>>> applies to >>>>> >>>>>>> a few other files, but not all of them. Without the required dlls >>>>> >>>>>>> loaded, even if no errors are produced, the code will not execute. >>>>> >>>>>>> >>>>> >>>>>>> If I go back to the original code when I try and load everything, >>>>> >>>>>>> then >>>>> >>>>>>> I get the error message: >>>>> >>>>>>> >>>>> >>>>>>> java.lang.UnsatisfiedLinkError: >>>>> >>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>> >>>>>>> libraries >>>>> >>>>>>> >>>>> >>>>>>> The file vtkChartsCoreJava.dll is present in that folder, so it is >>>>> >>>>>>> loaded, but its dependencies cannot be found. This applies to >>>>> >>>>>>> quite a >>>>> >>>>>>> few other dll files with dependencies, and I also get a list of a >>>>> >>>>>>> large number files that were not loaded from the statement: >>>>> >>>>>>> >>>>> >>>>>>> if (!lib.IsLoaded()) System.out.println(lib.GetLibraryName() + " >>>>> >>>>>>> not >>>>> >>>>>>> loaded"); >>>>> >>>>>>> >>>>> >>>>>>> inside the for-loop in an earlier message. >>>>> >>>>>>> >>>>> >>>>>>> It looks that without these large number of files, possibly all of >>>>> >>>>>>> them, that have not been loaded the code will not work, even if I >>>>> >>>>>>> skip >>>>> >>>>>>> over the bad loads or put the loop in a try-catch loop. This must >>>>> >>>>>>> have something to do with the error message in the log during the >>>>> >>>>>>> build process with Visual Studio Pro 2010 I did a few days ago. >>>>> >>>>>>> >>>>> >>>>>>> I don't fully understand the log, but the section where it failed >>>>> >>>>>>> is here: >>>>> >>>>>>> >>>>> >>>>>>> 112>Link: >>>>> >>>>>>> 112> Creating library >>>>> >>>>>>> C:/VTK/lib/Release/vtkRenderingCoreJava.lib >>>>> >>>>>>> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp >>>>> >>>>>>> 114> vtkDepthPeeling_fs.cxx >>>>> >>>>>>> 114> vtkGaussianBlurPassShader_fs.cxx >>>>> >>>>>>> 114> vtkLighting_s.cxx >>>>> >>>>>>> 114> vtkLightingHelper_s.cxx >>>>> >>>>>>> 114> vtkOpenGLRenderer_PeelingFS.cxx >>>>> >>>>>>> 114> vtkOpenGLPropertyDefaultPropFunc_fs.cxx >>>>> >>>>>>> 114> vtkOpenGLPropertyDefaultPropFunc_vs.cxx >>>>> >>>>>>> 112>vtkRenderWindowJava.obj : error LNK2019: unresolved external >>>>> >>>>>>> symbol __imp__JAWT_GetAWT at 8 referenced in function >>>>> >>>>>>> _Java_vtk_vtkPanel_RenderCreate at 12 >>>>> >>>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error >>>>> >>>>>>> LNK1120: >>>>> >>>>>>> 1 unresolved externals >>>>> >>>>>>> 114> vtkOpenGLPropertyDefaultMain_fs.cxx >>>>> >>>>>>> 112> >>>>> >>>>>>> 112>Build FAILED. >>>>> >>>>>>> 112> >>>>> >>>>>>> 112>Time Elapsed 00:01:32.30 >>>>> >>>>>>> >>>>> >>>>>>> Obviously vtkRenderingCoreJava.dll failed to link, which must be >>>>> >>>>>>> the >>>>> >>>>>>> cause of the problems I'm having. This was the only failure, with >>>>> >>>>>>> the >>>>> >>>>>>> other 387 compilations and linking successful. If this problem >>>>> >>>>>>> can be >>>>> >>>>>>> fixed, I hope I will be home and dry. >>>>> >>>>>>> >>>>> >>>>>>> I would most appreciate you or someone else kindly getting this >>>>> >>>>>>> resolved. >>>>> >>>>>>> >>>>> >>>>>>> csharp >>>>> >>>>>>> >>>>> >>>>>>> On Sat, Mar 21, 2015 at 3:04 PM, Sebastien Jourdain >>>>> >>>>>>> wrote: >>>>> >>>>>>>> Try to load the libraries that you need to load instead of all of >>>>> >>>>>>>> them. >>>>> >>>>>>>> It >>>>> >>>>>>>> seems that you didn't build everything (which is probably fine). >>>>> >>>>>>>> >>>>> >>>>>>>> Seb >>>>> >>>>>>>> >>>>> >>>>>>>> On Sat, Mar 21, 2015 at 2:58 PM, CSharpdotcom . >>>>> >>>>>>>> >>>>> >>>>>>>> wrote: >>>>> >>>>>>>>> >>>>> >>>>>>>>> I already had PATH=C:\VTK\bin\Release, and added ;%PATH% at the >>>>> >>>>>>>>> end, >>>>> >>>>>>>>> but it still doesn't work, and get the following output: >>>>> >>>>>>>>> >>>>> >>>>>>>>> java.lang.UnsatisfiedLinkError: >>>>> >>>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>> >>>>>>>>> libraries >>>>> >>>>>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>>> >>>>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>>> >>>>>>>>> at >>>>> >>>>>>>>> java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>>> >>>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >>>>> >>>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>> >>>>>>>>> at java.lang.System.loadLibrary(System.java:1119) >>>>> >>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>> >>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>> >>>>>>>>> at >>>>> >>>>>>>>> >>>>> >>>>>>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >>>>> >>>>>>>>> at >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >>>>> >>>>>>>>> java.lang.UnsatisfiedLinkError: >>>>> >>>>>>>>> C:\VTK\bin\Release\vtkDomainsChemistryJava.dll: Can't find >>>>> >>>>>>>>> dependent >>>>> >>>>>>>>> libraries >>>>> >>>>>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>>> >>>>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>>> >>>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >>>>> >>>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>> >>>>>>>>> at java.lang.System.loadLibrary(System.java:1119) >>>>> >>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>> >>>>>>>>> at >>>>> >>>>>>>>> >>>>> >>>>>>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >>>>> >>>>>>>>> at >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >>>>> >>>>>>>>> ................... >>>>> >>>>>>>>> >>>>> >>>>>>>>> These error messages continue, then a list of files not loaded >>>>> >>>>>>>>> are >>>>> >>>>>>>>> printed out, as given in the source code. >>>>> >>>>>>>>> >>>>> >>>>>>>>> Based on these error messages it's picking up the dll files in >>>>> >>>>>>>>> the >>>>> >>>>>>>>> \Release folder, but it's unable to find other files that these >>>>> >>>>>>>>> dll >>>>> >>>>>>>>> files depend on. >>>>> >>>>>>>>> >>>>> >>>>>>>>> Do you want a full listing of the Java source file? The >>>>> >>>>>>>>> AwtConeRendering class starts off with: >>>>> >>>>>>>>> >>>>> >>>>>>>>> static { >>>>> >>>>>>>>> System.out.println(System.getProperty("java.library.path")); >>>>> >>>>>>>>> if (!vtkNativeLibrary.LoadAllNativeLibraries()) { >>>>> >>>>>>>>> for (vtkNativeLibrary lib : vtkNativeLibrary.values()) { >>>>> >>>>>>>>> if (!lib.IsLoaded()) { >>>>> >>>>>>>>> System.out.println(lib.GetLibraryName() + " not >>>>> >>>>>>>>> loaded"); >>>>> >>>>>>>>> } >>>>> >>>>>>>>> } >>>>> >>>>>>>>> } >>>>> >>>>>>>>> vtkNativeLibrary.DisableOutputWindow(null); >>>>> >>>>>>>>> } >>>>> >>>>>>>>> >>>>> >>>>>>>>> which is followed by the main() method, which contains >>>>> >>>>>>>>> statements such >>>>> >>>>>>>>> as: >>>>> >>>>>>>>> >>>>> >>>>>>>>> vtkConeSource cone = new vtkConeSource(); >>>>> >>>>>>>>> >>>>> >>>>>>>>> csharp >>>>> >>>>>>>>> >>>>> >>>>>>>>> On Sat, Mar 21, 2015 at 10:26 AM, Sebastien Jourdain >>>>> >>>>>>>>> wrote: >>>>> >>>>>>>>>> Te java.library.path is not enough and you need to add into >>>>> >>>>>>>>>> your >>>>> >>>>>>>>>> environment >>>>> >>>>>>>>>> PATH the following directory, C:\VTK\bin\Release. >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> set PATH=C:\VTK\bin\Release;%PATH% >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> Seb >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> On Sat, Mar 21, 2015 at 10:33 AM, CSharpdotcom . >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> wrote: >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> Hello, >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> I'm new to VTK and this is my first posting here or on any >>>>> >>>>>>>>>>> other >>>>> >>>>>>>>>>> forum >>>>> >>>>>>>>>>> related to VTK. >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> I've been trying for about a week to get VTK installed and >>>>> >>>>>>>>>>> running >>>>> >>>>>>>>>>> on >>>>> >>>>>>>>>>> my computer. The project I'm working on is to use Java with >>>>> >>>>>>>>>>> VTK to >>>>> >>>>>>>>>>> represent 3D graphics, which I hope to use with NetBeans >>>>> >>>>>>>>>>> 8.0.2. I >>>>> >>>>>>>>>>> also have Visual Studio Pro 2010. >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> After failed attempts in installing VTK 6.2.0 and the latest >>>>> >>>>>>>>>>> version >>>>> >>>>>>>>>>> of CMake, from the link >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk >>>>> >>>>>>>>>>> I downloaded and unzipped VTK 6.1.0 and CMake 3.0.0, then >>>>> >>>>>>>>>>> installed >>>>> >>>>>>>>>>> them. >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> I then ran CMake according to the instructions on that link >>>>> >>>>>>>>>>> and >>>>> >>>>>>>>>>> installed the generated code in the folder C:\VTK. I then >>>>> >>>>>>>>>>> clicked >>>>> >>>>>>>>>>> on >>>>> >>>>>>>>>>> the file VTK.sin in that folder, which opened up Visual Studio >>>>> >>>>>>>>>>> and >>>>> >>>>>>>>>>> started compiling the code with a large number of modules in >>>>> >>>>>>>>>>> the >>>>> >>>>>>>>>>> project. This took about an hour, and on completion, >>>>> >>>>>>>>>>> generated the >>>>> >>>>>>>>>>> line at the end: >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> Build: 387 succeeded, 1 failed, 0 up-to-date, 0 skipped >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> I saved this in a file, which is very long, and after some >>>>> >>>>>>>>>>> effort >>>>> >>>>>>>>>>> found the error message: >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error >>>>> >>>>>>>>>>> LNK1120: >>>>> >>>>>>>>>>> 1 unresolved externals >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> In the mean time I attempted to recompile the project, which >>>>> >>>>>>>>>>> was >>>>> >>>>>>>>>>> much >>>>> >>>>>>>>>>> quicker, and got the same message. In recompiled I checked >>>>> >>>>>>>>>>> the >>>>> >>>>>>>>>>> "INSTALL" option, which had not previously been checked, >>>>> >>>>>>>>>>> although I >>>>> >>>>>>>>>>> don't know if that is significant. >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> Located in the folder \VTK\java\sample\rendering is the source >>>>> >>>>>>>>>>> file >>>>> >>>>>>>>>>> AwTConeRendering.java, which apparently has not been compiled. >>>>> >>>>>>>>>>> I >>>>> >>>>>>>>>>> created a NetBeans project and copied that file into it, then >>>>> >>>>>>>>>>> linked >>>>> >>>>>>>>>>> vtk.jar in the folder \VTK\bin to the project, and all imports >>>>> >>>>>>>>>>> were >>>>> >>>>>>>>>>> satisfied. In setting the Windows path to point to the dll >>>>> >>>>>>>>>>> files in >>>>> >>>>>>>>>>> \VTK\bin\Release, the application appears to pick up the dll >>>>> >>>>>>>>>>> files >>>>> >>>>>>>>>>> correctly, however, I get the following error message: >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> java.lang.UnsatisfiedLinkError: >>>>> >>>>>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>> >>>>>>>>>>> libraries >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> repeated for many dll files. Incidentally, as Visual Studio >>>>> >>>>>>>>>>> dlls >>>>> >>>>>>>>>>> are >>>>> >>>>>>>>>>> all 32 bits, as far as I know, I set up NetBeans to use a 32 >>>>> >>>>>>>>>>> bit >>>>> >>>>>>>>>>> JVM. >>>>> >>>>>>>>>>> This had previously been tested successfully with a test dll I >>>>> >>>>>>>>>>> created >>>>> >>>>>>>>>>> with Visual Studio and could execute with NetBeans. >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> This problem is presumably related to the first error >>>>> >>>>>>>>>>> mentioned >>>>> >>>>>>>>>>> above, >>>>> >>>>>>>>>>> and would be most grateful in getting this issue resolved. As >>>>> >>>>>>>>>>> I >>>>> >>>>>>>>>>> said, >>>>> >>>>>>>>>>> I'm new to VTK, and in fact only in the last couple of weeks >>>>> >>>>>>>>>>> have >>>>> >>>>>>>>>>> tried for the first time to call a dll file from a Java >>>>> >>>>>>>>>>> application >>>>> >>>>>>>>>>> on >>>>> >>>>>>>>>>> a Windows computer. >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> In the Java code I added the statement: >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> System.out.println(System.getProperty("java.library.path")); >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> to check that the path was correct, which is the case. >>>>> >>>>>>>>>>> _______________________________________________ >>>>> >>>>>>>>>>> Powered by www.kitware.com >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> Visit other Kitware open-source projects at >>>>> >>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> Search the list archives at: >>>>> >>>>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>> >>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> >>>> >>>> From bill.lorensen at gmail.com Mon Mar 23 18:12:25 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 23 Mar 2015 15:12:25 -0700 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: +1 On Mon, Mar 23, 2015 at 2:51 PM, David Gobbi wrote: > Hi David, > > It's apparent to me that part of the difficulty surrounding this change is > due to the name of the method. Why not use a new name? > > bool ComputeBoundsForViewport(vtkViewport *, double bounds[6]); > > I confess that I have an ulterior motive. I like all Get() or Set() methods > to get/set a property that depends only on the the object itself. Here, > the Bounds depend on both the object and on a second object. So I > don't consider this method to be a "getter" in the strict sense, hence > "ComputeBounds" rather than "GetBounds". > > Basically, I like it when Get methods are associated with properties/traits > of the object. Eventually, VTK's wrappers might associate Set/Get > methods with Python properties. In fact, this idea can already be seen > in action in tvtk, Enthought's Traited VTK. > > - David > > > On Mon, Mar 23, 2015 at 9:18 AM, David Lonie > wrote: >> >> On Fri, Mar 20, 2015 at 9:42 AM, David Gobbi >> wrote: >>> >>> On Fri, Mar 20, 2015 at 7:17 AM, David Lonie >>> wrote: >>>> >>>> On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi >>>> wrote: >>>>> >>>>> On Thu, Mar 19, 2015 at 2:28 PM, David Lonie >>>>> wrote: >>>>>> >>>>>> 2) If so, how can I teach the wrappers about it? >>>>> >>>>> >>>>> Adding things like this to Tcl is easier than for Java or Python, but >>>>> it's more than an afternoon's work. >>>> >>>> >>>> One more thing: >>>> >>>> If you know offhand, can you briefly outline the steps that are needed >>>> to do this? That might help clarify whether the maintenance burden is >>>> excessive or not. Would it be a one-time deal that would teach Tcl how to >>>> wrap all similar methods, or would it need to be repeated for every similar >>>> method that gets added? >>> >>> >>> My brief outline is this: find the code in vtkWrapTcl.c that builds >>> arrays to be used as return values, and then do something similar for this >>> new kind of method signature, except have it assign a global name (whatever >>> name was passed as a parameter) to the new array instead of returning it. >>> If it is done for this method, it should work for all similar methods. >> >> >> This seems more doable than I'd feared, since it'd be a generic approach >> that should "just work" for similar cases. >> >> It sounds like there's a lot of support for removing Tcl, but it's >> unlikely that we'll see it go away completely anytime soon for a multitude >> of reasons. So back to the immediate issue of how the GetBounds change can >> be made to work with the wrappers, I see three options: >> >> 1) Train the wrappers to understand it. Might not be worth the effort if >> we're planning to pull support soon. >> >> 2) Add an additional non-deprecated GetBounds signature >> >> double* GetBounds(vtkViewport*) >> >> I don't like this approach as it has issues thread safety, and requires >> each object to carry around an array just to pass results back to a caller >> -- a pattern we should be moving away from. I'd be more supportive of this >> approach if we decided to use vtkTuple instead of double*, but >> this would also be likely to require some significant wrapper training >> and/or concrete vtkTuple subclasses. >> >> 3) Begin a long-term deprecation of Tcl. We'll not plan on removing it >> completely anytime soon, but enabling Tcl wrapping will also require >> enabling legacy code in VTK. This way the old legacy GetBounds, etc >> signatures will still be available to Tcl, and feedback from the deprecation >> would help us understand the full impact of completely removing Tcl, as >> we'll grab the attention of users that might not follow the mailing lists. >> >> My vote is for 3 -- it's an easy change that gives people a heads-up about >> then inevitable future removal of Tcl support, and ensures that everything >> will "just work" for legacy code until we decide to completely pull the >> plug. >> >> Thoughts? Votes? Alternatives? >> >> Dave > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From berk.geveci at kitware.com Mon Mar 23 20:13:06 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 23 Mar 2015 20:13:06 -0400 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: +1 On Mon, Mar 23, 2015 at 6:12 PM, Bill Lorensen wrote: > +1 > > > On Mon, Mar 23, 2015 at 2:51 PM, David Gobbi > wrote: > > Hi David, > > > > It's apparent to me that part of the difficulty surrounding this change > is > > due to the name of the method. Why not use a new name? > > > > bool ComputeBoundsForViewport(vtkViewport *, double bounds[6]); > > > > I confess that I have an ulterior motive. I like all Get() or Set() > methods > > to get/set a property that depends only on the the object itself. Here, > > the Bounds depend on both the object and on a second object. So I > > don't consider this method to be a "getter" in the strict sense, hence > > "ComputeBounds" rather than "GetBounds". > > > > Basically, I like it when Get methods are associated with > properties/traits > > of the object. Eventually, VTK's wrappers might associate Set/Get > > methods with Python properties. In fact, this idea can already be seen > > in action in tvtk, Enthought's Traited VTK. > > > > - David > > > > > > On Mon, Mar 23, 2015 at 9:18 AM, David Lonie > > wrote: > >> > >> On Fri, Mar 20, 2015 at 9:42 AM, David Gobbi > >> wrote: > >>> > >>> On Fri, Mar 20, 2015 at 7:17 AM, David Lonie > >>> wrote: > >>>> > >>>> On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi > >>>> wrote: > >>>>> > >>>>> On Thu, Mar 19, 2015 at 2:28 PM, David Lonie < > david.lonie at kitware.com> > >>>>> wrote: > >>>>>> > >>>>>> 2) If so, how can I teach the wrappers about it? > >>>>> > >>>>> > >>>>> Adding things like this to Tcl is easier than for Java or Python, but > >>>>> it's more than an afternoon's work. > >>>> > >>>> > >>>> One more thing: > >>>> > >>>> If you know offhand, can you briefly outline the steps that are needed > >>>> to do this? That might help clarify whether the maintenance burden is > >>>> excessive or not. Would it be a one-time deal that would teach Tcl > how to > >>>> wrap all similar methods, or would it need to be repeated for every > similar > >>>> method that gets added? > >>> > >>> > >>> My brief outline is this: find the code in vtkWrapTcl.c that builds > >>> arrays to be used as return values, and then do something similar for > this > >>> new kind of method signature, except have it assign a global name > (whatever > >>> name was passed as a parameter) to the new array instead of returning > it. > >>> If it is done for this method, it should work for all similar methods. > >> > >> > >> This seems more doable than I'd feared, since it'd be a generic approach > >> that should "just work" for similar cases. > >> > >> It sounds like there's a lot of support for removing Tcl, but it's > >> unlikely that we'll see it go away completely anytime soon for a > multitude > >> of reasons. So back to the immediate issue of how the GetBounds change > can > >> be made to work with the wrappers, I see three options: > >> > >> 1) Train the wrappers to understand it. Might not be worth the effort if > >> we're planning to pull support soon. > >> > >> 2) Add an additional non-deprecated GetBounds signature > >> > >> double* GetBounds(vtkViewport*) > >> > >> I don't like this approach as it has issues thread safety, and requires > >> each object to carry around an array just to pass results back to a > caller > >> -- a pattern we should be moving away from. I'd be more supportive of > this > >> approach if we decided to use vtkTuple instead of double*, > but > >> this would also be likely to require some significant wrapper training > >> and/or concrete vtkTuple subclasses. > >> > >> 3) Begin a long-term deprecation of Tcl. We'll not plan on removing it > >> completely anytime soon, but enabling Tcl wrapping will also require > >> enabling legacy code in VTK. This way the old legacy GetBounds, etc > >> signatures will still be available to Tcl, and feedback from the > deprecation > >> would help us understand the full impact of completely removing Tcl, as > >> we'll grab the attention of users that might not follow the mailing > lists. > >> > >> My vote is for 3 -- it's an easy change that gives people a heads-up > about > >> then inevitable future removal of Tcl support, and ensures that > everything > >> will "just work" for legacy code until we decide to completely pull the > >> plug. > >> > >> Thoughts? Votes? Alternatives? > >> > >> Dave > > > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien.jourdain at kitware.com Mon Mar 23 21:47:00 2015 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Mon, 23 Mar 2015 20:47:00 -0500 Subject: [vtk-developers] Problems installing VTK In-Reply-To: References: <37F0F4BE-C015-452A-A752-B07317B5B42A@kitware.com> <8E906FE3-B09F-4915-BD96-49028C996A23@kitware.com> Message-ID: Glad to ear you figured it out. Seb > On Mar 23, 2015, at 17:11, CSharpdotcom . wrote: > > Great news, I finally got VTK to work, so thank you very much for all > your help!!! > > I used the example at: > https://www.particleincell.com/2011/vtk-java-visualization/ with > NetBeans. > > Christopher Sharp > >> On Mon, Mar 23, 2015 at 11:13 AM, CSharpdotcom . wrote: >> OK, here is exactly what I have done so far, and have been making >> notes as follows: >> >> Instructions on using CMake 3.3.0 from: >> >> http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk >> https://www.particleincell.com/2011/vtk-java-visualization/ >> sebastien.jourdain at kitware.com with CC to vtk-developers at vtk.org >> >> 1) Start CMake 3.3.0 >> >> 2) Click "Advanced", enter "Java" in search window, then click "+ Add Entry". >> "Java" will appear under "Name" in the window below in red. On the >> right click "..." and a browse >> >> folder >> window opens. Select "C:/Program Files (x86)/Java/jdk1.8.0_31/bin" >> for the 32 bit Java comiler. >> >> 3) Select as source - >> C:/Users/Christopher/Documents/newb6sigma/VTK-6.1.0/src/VTK-6.1.0 >> >> 4) Select as build binaries - C:/VTK >> >> 5) Create empty folder C:/VTK >> >> 6) Click "Configure" then select Visualt Studio 2010 - Use default >> native compilers - Click "Finish" >> CMakes write output: log1.txt >> >> 7) Red screen displayed with the following items: >> >> Module_vtkWebJavaScript >> Module_vtkWrappingJava >> VTK_WRAP_JAVA >> >> 8) Check Module_vtkWrappingJava and VTK_WRAP_JAVA then press "Configure" again. >> >> 9) Copy the output to log2.txt. The screem shows the following items in red: >> >> JAVA_AWT_INCLUDE_PATH C:/Program Files (x86)/Java/jdk1.8.0_31/include >> JAVA_AWT_LIBRARY C:/Program Files >> (x86)/Java/jdk1.8.0_31/lib/jawt.lib >> JAVA_INCLUDE_PATH C:/Program Files (x86)/Java/jdk1.8.0_31/include >> JAVA_INCLUDE_PATH2 C:/Program Files >> (x86)/Java/jdk1.8.0_31/include/win32 >> JAVA_JVM_LIBRARY C:/Program Files >> (x86)/Java/jdk1.8.0_31/lib/jvm.lib >> Java_JAR_EXECUTABLE C:/Program Files >> (x86)/Java/jdk1.8.0_31/bin/jar.exe >> Java_JAVAC_EXECUTABLE C:/Program Files >> (x86)/Java/jdk1.8.0_31/bin/javac.exe >> Java_JAVADOC_EXECUTABLE C:/Program Files >> (x86)/Java/jdk1.8.0_31/bin/javadoc.exe >> Java_JAVAH_EXECUTABLE C:/Program Files >> (x86)/Java/jdk1.8.0_31/bin/javah.exe >> Java_JAVA_EXECUTABLE C:/Program Files >> (x86)/Java/jdk1.8.0_31/lib/java.exe >> VTK_JAVA_INSTALL Unchecked >> VTK_JAVA_JOGL_COMPONENT Unchecked >> VTK_JAVA_SWP_COMPONENR Unchecked >> >> The previous items from (7) are shown below not in red with the >> last two checked. >> Check VTK_JAVA_INSTALL then press "Configure" again. >> >> 10) Copy the output to log3.txt. >> >> 11) Click "Generate" - output "Generating done" when completed. >> >> The following warnings were printed out at the last configuration: >> >> CMake Warning (dev) at ThirdParty/hdf5/vtkhdf5/src/CMakeLists.txt:607 >> (ADD_CUSTOM_COMMAND): >> Policy CMP0040 is not set: The target in the TARGET signature of >> add_custom_command() must exist. Run "cmake --help-policy CMP0040" for >> policy details. Use the cmake_policy command to set the policy and >> suppress this warning. >> >> The target name "C:/VTK/ThirdParty/hdf5/vtkhdf5/H5Edefin.h" is unknown in >> this context. >> This warning is for project developers. Use -Wno-dev to suppress it. >> >> CMake Warning (dev) at ThirdParty/hdf5/vtkhdf5/src/CMakeLists.txt:614 >> (ADD_CUSTOM_COMMAND): >> Policy CMP0040 is not set: The target in the TARGET signature of >> add_custom_command() must exist. Run "cmake --help-policy CMP0040" for >> policy details. Use the cmake_policy command to set the policy and >> suppress this warning. >> >> The target name "C:/VTK/ThirdParty/hdf5/vtkhdf5/H5version.h" is unknown in >> this context. >> This warning is for project developers. Use -Wno-dev to suppress it. >> >> CMake Warning (dev) at ThirdParty/hdf5/vtkhdf5/src/CMakeLists.txt:621 >> (ADD_CUSTOM_COMMAND): >> Policy CMP0040 is not set: The target in the TARGET signature of >> add_custom_command() must exist. Run "cmake --help-policy CMP0040" for >> policy details. Use the cmake_policy command to set the policy and >> suppress this warning. >> >> The target name "C:/VTK/ThirdParty/hdf5/vtkhdf5/H5overflow.h" is unknown in >> this context. >> This warning is for project developers. Use -Wno-dev to suppress it. >> >> Please let me know if there are any problems. >> >> I'm having a break for Lunch and will be back online shortly after >> 13:00 (1:00 pm) Arizona time, then will run Visual Studio, which could >> take a while. >> >> Christopher Sharp >> >>> On Mon, Mar 23, 2015 at 10:37 AM, CSharpdotcom . wrote: >>> OK, now CMake displays a screen with only 3 entries in red: >>> >>> Module_vtkWebJavaScript >>> Module_vtkWrappingJava >>> VTK_WRAP_JAVA >>> >>> I certainly need the last, and possibly Module_vtkWrappingJava, so I >>> will check those and click Configure again. The BUILD_SHARED_LIBS >>> option and the other do not appear, and I don't know why. >>> >>>> On Mon, Mar 23, 2015 at 10:09 AM, CSharpdotcom . wrote: >>>> OK, many thanks, I havn't done that before. This is what I just did >>>> with CMake, I checked the Advanced box, entered "Java" in the search >>>> window on the left, then clicked " +Add Entry". Below the word "Java" >>>> appeared under "Name", then searched for the 32 bit Java compiler on >>>> the right, which is at C:/Program Files (x86)/Java/jdk1.8.0_31/bin. >>>> >>>> So far so good, I will now start up CMake 3.3.0 again from scratch, >>>> having deleted all the old files. After all this I will let you know >>>> what happens. >>>> >>>> Christopher Sharp >>>> >>>> On Sun, Mar 22, 2015 at 9:54 PM, Sebastien Jourdain >>>> wrote: >>>>> Toggle the advance mode in cmake and search for java, just to make sure >>>>> cmake find the right version of the lib. >>>>> >>>>> Seb >>>>> >>>>> On Sun, Mar 22, 2015 at 10:46 PM, CSharpdotcom . >>>>> wrote: >>>>>> >>>>>> Before I saw your message I tried building from scratch again, but >>>>>> still have errors. >>>>>> >>>>>> I didn't see in the link: >>>>>> >>>>>> https://www.particleincell.com/2011/vtk-java-visualization/ >>>>>> >>>>>> anything about using 32 bit Java in CMake, but it does say it has to >>>>>> be used with Visual Studio. After Googling around, I saw that the >>>>>> path environmental variable has to be set to the 32 bit Java, so I >>>>>> used C:\Program Files (x86)\Java\jre1.0.0_31\bin\client, where the >>>>>> file jvm.dll is located. >>>>>> >>>>>> I will now try again from scratch, with CMake using 32 bit Java. I've >>>>>> just set on my Windows 8 computer the following paths: >>>>>> >>>>>> JAVA_HOME = C:\Progra~2\Java\jdg1.8.0_31 >>>>>> PATH = C:\Program Files (x86)\jre1.8.-_31\bin >>>>>> >>>>>> and will reboot and start again. >>>>>> >>>>>> Christopher Sharp >>>>>> >>>>>> On Sun, Mar 22, 2015 at 8:58 PM, Sebastien Jourdain >>>>>> wrote: >>>>>>> You need to properly set cmake so you don't build the swt nor the Jogl >>>>>>> components for Java. (You don't need them as you don't know what they are.) >>>>>>> Moreover the jvm 32b should also be set via cmake. Otherwise VTK won't build >>>>>>> correctly. >>>>>>> >>>>>>> Seb >>>>>>> >>>>>>>> On Mar 22, 2015, at 16:05, CSharpdotcom . >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I decided not to install Visual Studio Express, as according to the >>>>>>>> website Visual Studio Pro was used, which is exactly what I've been >>>>>>>> using. >>>>>>>> >>>>>>>> Anyway, I created a new build folder and repeated the whole process >>>>>>>> from scratch. The error I'm still getting is: >>>>>>>> >>>>>>>> 117>Link: >>>>>>>> 117> Creating library C:/VTK/lib/Release/vtkRenderingCoreJava.lib >>>>>>>> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp >>>>>>>> 117>vtkRenderWindowJava.obj : error LNK2019: unresolved external >>>>>>>> symbol __imp__JAWT_GetAWT at 8 referenced in function >>>>>>>> _Java_vtk_vtkPanel_RenderCreate at 12 >>>>>>>> 117>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error LNK1120: >>>>>>>> 1 unresolved externals >>>>>>>> 124> Generating Code... >>>>>>>> 117> >>>>>>>> 117>Build FAILED. >>>>>>>> >>>>>>>> which is almost certainly due to Visual Studio trying to use 64 bit >>>>>>>> Java, which is incompatible with the 32 bit code it generates. I was >>>>>>>> unaware that Visual Studio has to use Java. This should be easy to >>>>>>>> fix by setting the path it uses to a 32 JVM. >>>>>>>> >>>>>>>> In addition, there are two other errors which appear to be related to >>>>>>>> the components VTK_JAVA_SWT_COMPONENT and VTK_JAVA_SWT_COMPONENT >>>>>>>> checked in the DMake window, which seem not to be installed in my >>>>>>>> system. What do they do, and are they needed for what I want to do? >>>>>>>> If so, I need to find out how to install them, otherwise they can >>>>>>>> presumably be ignored. >>>>>>>> >>>>>>>> Christopher Sharp >>>>>>>> >>>>>>>>> On Sun, Mar 22, 2015 at 11:04 AM, CSharpdotcom . >>>>>>>>> wrote: >>>>>>>>> Many thanks for your message; what I will do now is backup my VTK >>>>>>>>> folder, then instead of using Visual Studio 2010 Pro, I will download >>>>>>>>> the latest version of Visual Studio C++ Express, which is 2013 I >>>>>>>>> think, and try using DMake again form scratch. In the process I will >>>>>>>>> note exactly what I did, so if these problems persist, I will have a >>>>>>>>> record. >>>>>>>>> >>>>>>>>> csharp >>>>>>>>> >>>>>>>>> On Sun, Mar 22, 2015 at 7:18 AM, Sebastien Jourdain >>>>>>>>> wrote: >>>>>>>>>> I didn't see anything strange but can you explain your build process? >>>>>>>>>> Which property you changed in cmake and how/what did you build in visual >>>>>>>>>> studio? >>>>>>>>>> >>>>>>>>>> Seb >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Mar 22, 2015, at 00:11, CSharpdotcom . >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> OK, many thanks, I didn't know that there was such a file, this is >>>>>>>>>>> because I'm so new to VTK and CMake. The file is in the root folder >>>>>>>>>>> and is attached here. >>>>>>>>>>> >>>>>>>>>>> I look forward finally to getting this sorted out, as it has now >>>>>>>>>>> tied >>>>>>>>>>> me up for about a week. >>>>>>>>>>> >>>>>>>>>>> Christopher Sharp >>>>>>>>>>> >>>>>>>>>>> On Sat, Mar 21, 2015 at 8:59 PM, Sebastien Jourdain >>>>>>>>>>> wrote: >>>>>>>>>>>> I didn't know you had a partial build of VTK. Can you share you >>>>>>>>>>>> CMakeCache.txt. >>>>>>>>>>>> >>>>>>>>>>>> You must have wrongly setup your build. >>>>>>>>>>>> >>>>>>>>>>>> Seb >>>>>>>>>>>> >>>>>>>>>>>> On Sat, Mar 21, 2015 at 6:05 PM, CSharpdotcom . >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> Many thanks, but as I'm new ti VTK I don't know which libraries to >>>>>>>>>>>>> load. However, in looking at: >>>>>>>>>>>>> >>>>>>>>>>>>> http://www.vtk.org/Wiki/VTK/Examples/Java/Miscellaneous/Cone6 >>>>>>>>>>>>> >>>>>>>>>>>>> which has similar code. The statement: >>>>>>>>>>>>> >>>>>>>>>>>>> System.loadLibrary("vtkCommonJava"); >>>>>>>>>>>>> >>>>>>>>>>>>> doesn't load as there is no dll with that name in the folder >>>>>>>>>>>>> C:\VTK\bin\Release, but: >>>>>>>>>>>>> >>>>>>>>>>>>> System.loadLibrary("vtkCommonCoreJava"); >>>>>>>>>>>>> >>>>>>>>>>>>> does load correctly as there is a dll with that name. This >>>>>>>>>>>>> applies to >>>>>>>>>>>>> a few other files, but not all of them. Without the required dlls >>>>>>>>>>>>> loaded, even if no errors are produced, the code will not execute. >>>>>>>>>>>>> >>>>>>>>>>>>> If I go back to the original code when I try and load everything, >>>>>>>>>>>>> then >>>>>>>>>>>>> I get the error message: >>>>>>>>>>>>> >>>>>>>>>>>>> java.lang.UnsatisfiedLinkError: >>>>>>>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>>>>>>>>>> libraries >>>>>>>>>>>>> >>>>>>>>>>>>> The file vtkChartsCoreJava.dll is present in that folder, so it is >>>>>>>>>>>>> loaded, but its dependencies cannot be found. This applies to >>>>>>>>>>>>> quite a >>>>>>>>>>>>> few other dll files with dependencies, and I also get a list of a >>>>>>>>>>>>> large number files that were not loaded from the statement: >>>>>>>>>>>>> >>>>>>>>>>>>> if (!lib.IsLoaded()) System.out.println(lib.GetLibraryName() + " >>>>>>>>>>>>> not >>>>>>>>>>>>> loaded"); >>>>>>>>>>>>> >>>>>>>>>>>>> inside the for-loop in an earlier message. >>>>>>>>>>>>> >>>>>>>>>>>>> It looks that without these large number of files, possibly all of >>>>>>>>>>>>> them, that have not been loaded the code will not work, even if I >>>>>>>>>>>>> skip >>>>>>>>>>>>> over the bad loads or put the loop in a try-catch loop. This must >>>>>>>>>>>>> have something to do with the error message in the log during the >>>>>>>>>>>>> build process with Visual Studio Pro 2010 I did a few days ago. >>>>>>>>>>>>> >>>>>>>>>>>>> I don't fully understand the log, but the section where it failed >>>>>>>>>>>>> is here: >>>>>>>>>>>>> >>>>>>>>>>>>> 112>Link: >>>>>>>>>>>>> 112> Creating library >>>>>>>>>>>>> C:/VTK/lib/Release/vtkRenderingCoreJava.lib >>>>>>>>>>>>> and object C:/VTK/lib/Release/vtkRenderingCoreJava.exp >>>>>>>>>>>>> 114> vtkDepthPeeling_fs.cxx >>>>>>>>>>>>> 114> vtkGaussianBlurPassShader_fs.cxx >>>>>>>>>>>>> 114> vtkLighting_s.cxx >>>>>>>>>>>>> 114> vtkLightingHelper_s.cxx >>>>>>>>>>>>> 114> vtkOpenGLRenderer_PeelingFS.cxx >>>>>>>>>>>>> 114> vtkOpenGLPropertyDefaultPropFunc_fs.cxx >>>>>>>>>>>>> 114> vtkOpenGLPropertyDefaultPropFunc_vs.cxx >>>>>>>>>>>>> 112>vtkRenderWindowJava.obj : error LNK2019: unresolved external >>>>>>>>>>>>> symbol __imp__JAWT_GetAWT at 8 referenced in function >>>>>>>>>>>>> _Java_vtk_vtkPanel_RenderCreate at 12 >>>>>>>>>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error >>>>>>>>>>>>> LNK1120: >>>>>>>>>>>>> 1 unresolved externals >>>>>>>>>>>>> 114> vtkOpenGLPropertyDefaultMain_fs.cxx >>>>>>>>>>>>> 112> >>>>>>>>>>>>> 112>Build FAILED. >>>>>>>>>>>>> 112> >>>>>>>>>>>>> 112>Time Elapsed 00:01:32.30 >>>>>>>>>>>>> >>>>>>>>>>>>> Obviously vtkRenderingCoreJava.dll failed to link, which must be >>>>>>>>>>>>> the >>>>>>>>>>>>> cause of the problems I'm having. This was the only failure, with >>>>>>>>>>>>> the >>>>>>>>>>>>> other 387 compilations and linking successful. If this problem >>>>>>>>>>>>> can be >>>>>>>>>>>>> fixed, I hope I will be home and dry. >>>>>>>>>>>>> >>>>>>>>>>>>> I would most appreciate you or someone else kindly getting this >>>>>>>>>>>>> resolved. >>>>>>>>>>>>> >>>>>>>>>>>>> csharp >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, Mar 21, 2015 at 3:04 PM, Sebastien Jourdain >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> Try to load the libraries that you need to load instead of all of >>>>>>>>>>>>>> them. >>>>>>>>>>>>>> It >>>>>>>>>>>>>> seems that you didn't build everything (which is probably fine). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Seb >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sat, Mar 21, 2015 at 2:58 PM, CSharpdotcom . >>>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I already had PATH=C:\VTK\bin\Release, and added ;%PATH% at the >>>>>>>>>>>>>>> end, >>>>>>>>>>>>>>> but it still doesn't work, and get the following output: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> java.lang.UnsatisfiedLinkError: >>>>>>>>>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>>>>>>>>>>>> libraries >>>>>>>>>>>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>>>>>>>>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>>>>>>>>>>>>> at >>>>>>>>>>>>>>> java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>>>>>>>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >>>>>>>>>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>>>>>>>>>>>> at java.lang.System.loadLibrary(System.java:1119) >>>>>>>>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>>>>>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>>>>>>>>>>>> at >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >>>>>>>>>>>>>>> at >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >>>>>>>>>>>>>>> java.lang.UnsatisfiedLinkError: >>>>>>>>>>>>>>> C:\VTK\bin\Release\vtkDomainsChemistryJava.dll: Can't find >>>>>>>>>>>>>>> dependent >>>>>>>>>>>>>>> libraries >>>>>>>>>>>>>>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>>>>>>>>>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) >>>>>>>>>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855) >>>>>>>>>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>>>>>>>>>>>> at java.lang.System.loadLibrary(System.java:1119) >>>>>>>>>>>>>>> at vtk.vtkNativeLibrary.LoadLibrary(vtkNativeLibrary.java:214) >>>>>>>>>>>>>>> at >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> vtk.vtkNativeLibrary.LoadAllNativeLibraries(vtkNativeLibrary.java:149) >>>>>>>>>>>>>>> at >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> vtk.sample.rendering.AwtConeRendering.(AwtConeRendering.java:19) >>>>>>>>>>>>>>> ................... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> These error messages continue, then a list of files not loaded >>>>>>>>>>>>>>> are >>>>>>>>>>>>>>> printed out, as given in the source code. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Based on these error messages it's picking up the dll files in >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> \Release folder, but it's unable to find other files that these >>>>>>>>>>>>>>> dll >>>>>>>>>>>>>>> files depend on. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Do you want a full listing of the Java source file? The >>>>>>>>>>>>>>> AwtConeRendering class starts off with: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> static { >>>>>>>>>>>>>>> System.out.println(System.getProperty("java.library.path")); >>>>>>>>>>>>>>> if (!vtkNativeLibrary.LoadAllNativeLibraries()) { >>>>>>>>>>>>>>> for (vtkNativeLibrary lib : vtkNativeLibrary.values()) { >>>>>>>>>>>>>>> if (!lib.IsLoaded()) { >>>>>>>>>>>>>>> System.out.println(lib.GetLibraryName() + " not >>>>>>>>>>>>>>> loaded"); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> vtkNativeLibrary.DisableOutputWindow(null); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> which is followed by the main() method, which contains >>>>>>>>>>>>>>> statements such >>>>>>>>>>>>>>> as: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> vtkConeSource cone = new vtkConeSource(); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> csharp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sat, Mar 21, 2015 at 10:26 AM, Sebastien Jourdain >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> Te java.library.path is not enough and you need to add into >>>>>>>>>>>>>>>> your >>>>>>>>>>>>>>>> environment >>>>>>>>>>>>>>>> PATH the following directory, C:\VTK\bin\Release. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> set PATH=C:\VTK\bin\Release;%PATH% >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Seb >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Sat, Mar 21, 2015 at 10:33 AM, CSharpdotcom . >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm new to VTK and this is my first posting here or on any >>>>>>>>>>>>>>>>> other >>>>>>>>>>>>>>>>> forum >>>>>>>>>>>>>>>>> related to VTK. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I've been trying for about a week to get VTK installed and >>>>>>>>>>>>>>>>> running >>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>> my computer. The project I'm working on is to use Java with >>>>>>>>>>>>>>>>> VTK to >>>>>>>>>>>>>>>>> represent 3D graphics, which I hope to use with NetBeans >>>>>>>>>>>>>>>>> 8.0.2. I >>>>>>>>>>>>>>>>> also have Visual Studio Pro 2010. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> After failed attempts in installing VTK 6.2.0 and the latest >>>>>>>>>>>>>>>>> version >>>>>>>>>>>>>>>>> of CMake, from the link >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://www5.cs.fau.de/en/conrad/tutorials/itk-and-vtk-wrapping/wrap-vtk >>>>>>>>>>>>>>>>> I downloaded and unzipped VTK 6.1.0 and CMake 3.0.0, then >>>>>>>>>>>>>>>>> installed >>>>>>>>>>>>>>>>> them. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I then ran CMake according to the instructions on that link >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> installed the generated code in the folder C:\VTK. I then >>>>>>>>>>>>>>>>> clicked >>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>> the file VTK.sin in that folder, which opened up Visual Studio >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> started compiling the code with a large number of modules in >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> project. This took about an hour, and on completion, >>>>>>>>>>>>>>>>> generated the >>>>>>>>>>>>>>>>> line at the end: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Build: 387 succeeded, 1 failed, 0 up-to-date, 0 skipped >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I saved this in a file, which is very long, and after some >>>>>>>>>>>>>>>>> effort >>>>>>>>>>>>>>>>> found the error message: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 112>C:\VTK\bin\Release\vtkRenderingCoreJava.dll : fatal error >>>>>>>>>>>>>>>>> LNK1120: >>>>>>>>>>>>>>>>> 1 unresolved externals >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In the mean time I attempted to recompile the project, which >>>>>>>>>>>>>>>>> was >>>>>>>>>>>>>>>>> much >>>>>>>>>>>>>>>>> quicker, and got the same message. In recompiled I checked >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> "INSTALL" option, which had not previously been checked, >>>>>>>>>>>>>>>>> although I >>>>>>>>>>>>>>>>> don't know if that is significant. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Located in the folder \VTK\java\sample\rendering is the source >>>>>>>>>>>>>>>>> file >>>>>>>>>>>>>>>>> AwTConeRendering.java, which apparently has not been compiled. >>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>> created a NetBeans project and copied that file into it, then >>>>>>>>>>>>>>>>> linked >>>>>>>>>>>>>>>>> vtk.jar in the folder \VTK\bin to the project, and all imports >>>>>>>>>>>>>>>>> were >>>>>>>>>>>>>>>>> satisfied. In setting the Windows path to point to the dll >>>>>>>>>>>>>>>>> files in >>>>>>>>>>>>>>>>> \VTK\bin\Release, the application appears to pick up the dll >>>>>>>>>>>>>>>>> files >>>>>>>>>>>>>>>>> correctly, however, I get the following error message: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> java.lang.UnsatisfiedLinkError: >>>>>>>>>>>>>>>>> C:\VTK\bin\Release\vtkChartsCoreJava.dll: Can't find dependent >>>>>>>>>>>>>>>>> libraries >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> repeated for many dll files. Incidentally, as Visual Studio >>>>>>>>>>>>>>>>> dlls >>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>> all 32 bits, as far as I know, I set up NetBeans to use a 32 >>>>>>>>>>>>>>>>> bit >>>>>>>>>>>>>>>>> JVM. >>>>>>>>>>>>>>>>> This had previously been tested successfully with a test dll I >>>>>>>>>>>>>>>>> created >>>>>>>>>>>>>>>>> with Visual Studio and could execute with NetBeans. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This problem is presumably related to the first error >>>>>>>>>>>>>>>>> mentioned >>>>>>>>>>>>>>>>> above, >>>>>>>>>>>>>>>>> and would be most grateful in getting this issue resolved. As >>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>> said, >>>>>>>>>>>>>>>>> I'm new to VTK, and in fact only in the last couple of weeks >>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>> tried for the first time to call a dll file from a Java >>>>>>>>>>>>>>>>> application >>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>> a Windows computer. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In the Java code I added the statement: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> System.out.println(System.getProperty("java.library.path")); >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> to check that the path was correct, which is the case. >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> Powered by www.kitware.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Search the list archives at: >>>>>>>>>>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>>> >>>>> >>>>> From will.schroeder at kitware.com Tue Mar 24 06:49:36 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Tue, 24 Mar 2015 06:49:36 -0400 Subject: [vtk-developers] Renderman Announces new pricing policy In-Reply-To: References: Message-ID: Some interesting articles related to RenderMan: Pixar?s RenderMan Software To Be Free For Non-Commercial Users RenderMan Community Site (It looks like some useful resources, etc. although the site was really slow when I visited). W On Mon, Mar 23, 2015 at 5:40 PM, Bill Lorensen wrote: > I trying to download it now. Also, I'm working on updating the RIB > exporter, property and light to work with modern render man. > > Keep you posted. > > > On Mon, Mar 23, 2015 at 2:34 PM, Goodwin Lawlor > wrote: > > Renderman free non-commercial version is released! > > > > http://rendermansite.pixar.com/view/get-renderman > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From deevankshu096 at gmail.com Tue Mar 24 07:11:31 2015 From: deevankshu096 at gmail.com (DEEVANKSHU GARG) Date: Tue, 24 Mar 2015 16:41:31 +0530 Subject: [vtk-developers] GSoC 2015-CAD Model and Simulation Spline Visualization In-Reply-To: <6D747987-ACE4-448E-A9FB-23931788D594@kitware.com> References: <6BD334A2-5477-42A1-B500-6F2B4827A511@kitware.com> <6D747987-ACE4-448E-A9FB-23931788D594@kitware.com> Message-ID: Hello, Sorry for that little break in between but I was really stuck in my mid-semester exams. About the project,now I am concentrating more on the implementation of the IGA solver and post-processing techniques rather than understanding the IGA solver.Basically, it would be up to the IGA solver to provide us with Bezier patches.The data provided from the patches about the control points and vertices of the curve will be stored in arrays using the {vtkAbstractArray ,vtkDataArray,vtkDoubleArray} classes.And then composed into datasets using the classes {vtkDataObject, vtkDataSet, vtkUnstructuredGrid, vtkMultiBlockDataSet}.Then the main work starts.These datsets will be processed by further filters present in the new mesh rendering class.The main tasks in our hand are-interpolation,point inversion and finally,tesselation and rendering.Here's a rough implementation of the methods used to perform these tasks. Interpolation- -The algorithm here I am thinking of implementing here is DeBoor's algorithm which is , of course ,a generalization of de casteljau's algorithm for bezier curves. -The main thing to do here is to write the knot insertion as a matrix product operation done by DeBoor algorithm.We can then create these local matrices that allow us to go from a B-spline representation to a Bernstein definition (only a change of the polynomial basis). -We can also use Oslo algorithm-a more general and complex insertion algorithm permitting insertion of multiple knots into a B-spline knot vector. Point inversion- For point inversion, we extract candidate B?zier subcurves based on the strong convex hull property, and then find the approximate candidate points and their corresponding parameter values already present in our stored arrays. Finally, by comparing the distances between the test point and candidate points, we can find the closest point. We improve its accuracy by using the Newton-Raphson method. Tesselation and Rendering- I have always loathed the necessity of flow charts.I am attaching one here too explaining the implementation of the tesselation method.A brief explanation about this- -Tesselation Control Shader-Determines how much to tesselate,per-vertex attributes,new patch vertices in xyz. -Tesselation primitive generator-Tessellates the curve or surface into uvw coordinates. -Tesselation evaluation shader-Evaluate the curve or surface. Possibly apply a displacement map. After tesselation,finally rendering takes place which involves writing interpolated values out at the nodes of the simplices(lines,triangles,tetrahedra). For the cutting part,I still have to see what changes will have to be made to the already existing code.I will get to that soon. Please tell me what you think about it.Would it be a good idea to divide the whole timeline into these three parts or do you recommend something else? Bests, Deevankshu Garg. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tesselate.jpg Type: image/jpeg Size: 128573 bytes Desc: not available URL: From josp.jorge at gmail.com Tue Mar 24 08:48:38 2015 From: josp.jorge at gmail.com (Jorge Perez) Date: Tue, 24 Mar 2015 13:48:38 +0100 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: Thanks for the guide, the documentation from those files is useful. We are going to study that code and try to propose a change. We would like to implement support to vtkVariant in order to wrap methods expecting arguments of that type. 2015-03-23 22:13 GMT+01:00 David Gobbi : > On Mon, Mar 23, 2015 at 2:46 PM, Jorge Perez wrote: > >> Hello, we are developing some applications based on VTK + Tcl. For our >> requirements, we think this a very productive multi-platform solution and >> we would like to provide support to solve the issue here raised with the >> aim to continue the development of the Tcl Wrapping capabilities in VTK. In >> order to help in this issue we appreciate any guide to understand the >> arguments that vtkWrapTcl is processing. >> > > Rough guide to understanding vtkWrapTcl.c: > > 1) Look for the main() function, which is at around line 1100. It uses a > few > important data structures: OptionInfo, FileInfo, ClassInfo. > > 2) Read vtkParseMain.h, vtkParseData.h, vtkParseType.h, vtkParseHierarchy.h > to understand the data structures that are involved in VTK wrapping > > 3) Most of vtkWrapTcl.c is a bunch of fprintf() statements that produce > C++ code > for the wrappers. I don't have much advice here except to trace through > the > code, starting at the first "fprintf(fp, ..." at line 1132 in main(). > This is the place > where vtkWrapTcl starts writing the wrapper code. > > - David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Tue Mar 24 09:26:55 2015 From: david.lonie at kitware.com (David Lonie) Date: Tue, 24 Mar 2015 09:26:55 -0400 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: On Mon, Mar 23, 2015 at 5:51 PM, David Gobbi wrote: > Hi David, > > It's apparent to me that part of the difficulty surrounding this change is > due to the name of the method. Why not use a new name? > > bool ComputeBoundsForViewport(vtkViewport *, double bounds[6]); > > I confess that I have an ulterior motive. I like all Get() or Set() > methods > to get/set a property that depends only on the the object itself. Here, > the Bounds depend on both the object and on a second object. So I > don't consider this method to be a "getter" in the strict sense, hence > "ComputeBounds" rather than "GetBounds". > > Basically, I like it when Get methods are associated with properties/traits > of the object. Eventually, VTK's wrappers might associate Set/Get > methods with Python properties. In fact, this idea can already be seen > in action in tvtk, Enthought's Traited VTK. > Hmm, and this also wouldn't require the 'using' wrapper support right away...I like it! The distinction between Get/Compute makes sense. The name is a bit long, and "ForViewport" is implied by the arguments. I'd like ComputeBounds, but that's already a virtual on many of these classes. Now I'm leaning towards vtkBoundingBox ComputeBoundingBox(vtkViewport *) That would also: - eliminate the output-array-arg issues with the Tcl wrappers (Yay!) - encourage use of the vtkBoundingBox class, which is a really nice API for working with a bounding box that leads to much, much more consistent and readable usage (there are a few approaches used for, e.g. invalid bounds, that aren't always consistent). It needs a couple hints to be wrapped properly, but that's not nearly as much trouble :) Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gerrick.Bivins at halliburton.com Tue Mar 24 09:58:55 2015 From: Gerrick.Bivins at halliburton.com (Gerrick Bivins) Date: Tue, 24 Mar 2015 13:58:55 +0000 Subject: [vtk-developers] [EXTERNAL] Re: Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: +1 to the ?pure getter/setters? idea. This would also greatly benefit ?bean heads? like myself (Java devs). From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of David Lonie Sent: Tuesday, March 24, 2015 8:27 AM To: David Gobbi Cc: VTK Developers Subject: [EXTERNAL] Re: [vtk-developers] Tcl wrapping and output array arguments On Mon, Mar 23, 2015 at 5:51 PM, David Gobbi > wrote: Hi David, It's apparent to me that part of the difficulty surrounding this change is due to the name of the method. Why not use a new name? bool ComputeBoundsForViewport(vtkViewport *, double bounds[6]); I confess that I have an ulterior motive. I like all Get() or Set() methods to get/set a property that depends only on the the object itself. Here, the Bounds depend on both the object and on a second object. So I don't consider this method to be a "getter" in the strict sense, hence "ComputeBounds" rather than "GetBounds". Basically, I like it when Get methods are associated with properties/traits of the object. Eventually, VTK's wrappers might associate Set/Get methods with Python properties. In fact, this idea can already be seen in action in tvtk, Enthought's Traited VTK. Hmm, and this also wouldn't require the 'using' wrapper support right away...I like it! The distinction between Get/Compute makes sense. The name is a bit long, and "ForViewport" is implied by the arguments. I'd like ComputeBounds, but that's already a virtual on many of these classes. Now I'm leaning towards vtkBoundingBox ComputeBoundingBox(vtkViewport *) That would also: - eliminate the output-array-arg issues with the Tcl wrappers (Yay!) - encourage use of the vtkBoundingBox class, which is a really nice API for working with a bounding box that leads to much, much more consistent and readable usage (there are a few approaches used for, e.g. invalid bounds, that aren't always consistent). It needs a couple hints to be wrapped properly, but that's not nearly as much trouble :) Dave ---------------------------------------------------------------------- This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Tue Mar 24 10:29:47 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Tue, 24 Mar 2015 10:29:47 -0400 Subject: [vtk-developers] Renderman Announces new pricing policy In-Reply-To: References: Message-ID: Bill what are you drinking? that color scheme is way bad, but admittedly it looks very cool! It will be great to have this back in VTK again. On Tue, Mar 24, 2015 at 10:24 AM, Bill Lorensen wrote: > Generated my first exported RIB file with the free renderman. > Hopefully I have the updated RIBExporter ready soon. > > Bill > > > On Tue, Mar 24, 2015 at 3:49 AM, Will Schroeder > wrote: > > Some interesting articles related to RenderMan: > > > > Pixar?s RenderMan Software To Be Free For Non-Commercial Users > > > > RenderMan Community Site > > (It looks like some useful resources, etc. although the site was really > slow > > when I visited). > > > > W > > > > > > On Mon, Mar 23, 2015 at 5:40 PM, Bill Lorensen > > wrote: > >> > >> I trying to download it now. Also, I'm working on updating the RIB > >> exporter, property and light to work with modern render man. > >> > >> Keep you posted. > >> > >> > >> On Mon, Mar 23, 2015 at 2:34 PM, Goodwin Lawlor > >> wrote: > >> > Renderman free non-commercial version is released! > >> > > >> > http://rendermansite.pixar.com/view/get-renderman > >> > > >> > _______________________________________________ > >> > Powered by www.kitware.com > >> > > >> > Visit other Kitware open-source projects at > >> > http://www.kitware.com/opensource/opensource.html > >> > > >> > Search the list archives at: > >> > http://markmail.org/search/?q=vtk-developers > >> > > >> > Follow this link to subscribe/unsubscribe: > >> > http://public.kitware.com/mailman/listinfo/vtk-developers > >> > > >> > > >> > >> > >> > >> -- > >> Unpaid intern in BillsBasement at noware dot com > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the list archives at: > http://markmail.org/search/?q=vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > > > > > > > > -- > > William J. Schroeder, PhD > > Kitware, Inc. > > 28 Corporate Drive > > Clifton Park, NY 12065 > > will.schroeder at kitware.com > > http://www.kitware.com > > (518) 881-4902 > > > > -- > Unpaid intern in BillsBasement at noware dot com > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Wed Mar 25 00:28:37 2015 From: david.thompson at kitware.com (David Thompson) Date: Wed, 25 Mar 2015 00:28:37 -0400 Subject: [vtk-developers] GSoC 2015-CAD Model and Simulation Spline Visualization In-Reply-To: References: <6BD334A2-5477-42A1-B500-6F2B4827A511@kitware.com> <6D747987-ACE4-448E-A9FB-23931788D594@kitware.com> Message-ID: <2FC0093C-8EB6-486C-9EDB-4D1ED798E025@kitware.com> Hi Deevankshu, > Sorry for that little break in between but I was really stuck in my mid-semester exams. That's OK; I am also in a time crunch to finish a paper. > .... Basically, it would be up to the IGA solver to provide us with Bezier patches.The data provided from the patches about the control points and vertices of the curve will be stored in arrays using the {vtkAbstractArray ,vtkDataArray,vtkDoubleArray} classes. ... Correct, although if you are interested in storing BSplines (and then converting to B?zier patches on demand), it would be better to store the control points in a vtkStructuredGrid. > Then the main work starts.These datsets will be processed by further filters present in the new mesh rendering class. Yes. Filters would likely inherit vtkMultiBlockDataSetAlgorithm. > The main tasks in our hand are-interpolation,point inversion and finally,tesselation and rendering.Here's a rough implementation of the methods used to perform these tasks. ... > > Tesselation and Rendering- > I have always loathed the necessity of flow charts.I am attaching one here too explaining the implementation of the tesselation method.A brief explanation about this- > -Tesselation Control Shader-Determines how much to tesselate,per-vertex attributes,new patch vertices in xyz. > -Tesselation primitive generator-Tessellates the curve or surface into uvw coordinates. > -Tesselation evaluation shader-Evaluate the curve or surface. Possibly apply a displacement map. > After tesselation,finally rendering takes place which involves writing interpolated values out at the nodes of the simplices(lines,triangles,tetrahedra). While it would be nice to have direct OpenGL rendering of patches, I would prefer to implement tessellation on the CPU first so that the resulting tessellation can be represented as a VTK dataset and used in further operations before rendering. Also, since IGA frequently involves 3-dimensional volumetric elements, rendering using the flowchart you show would mean writing a volume renderer (which is an ambitious task and could be its own GSoC project). If we tessellate on the CPU then VTK already has volume rendering code that can be applied to the tetrahedra that approximate a volumetric patch. > For the cutting part,I still have to see what changes will have to be made to the already existing code.I will get to that soon. > > Please tell me what you think about it.Would it be a good idea to divide the whole timeline into these three parts or do you recommend something else? I think 3 sections would be fine for the timeline. I would prefer to work by (1) negotiating header files and unit tests, then (2) implementing the classes for each of the 3 sections. David From david.lonie at kitware.com Wed Mar 25 10:12:31 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 25 Mar 2015 10:12:31 -0400 Subject: [vtk-developers] vtkBoundingBoxJava build errors... Message-ID: ...are on me. I was naughty and merged a trivial-looking branch before all of the buildbots finished. We'll get the errors cleaned up or the change reverted soon. Ref: https://gitlab.kitware.com/vtk/vtk/merge_requests/34 Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Mar 25 13:07:52 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 25 Mar 2015 13:07:52 -0400 Subject: [vtk-developers] Help with vtkFreeTypeTools::MapTextPropertyToId error... Message-ID: <20150325170752.27808897@mail.rogue-research.com> Hi all, Anyone know vtkFreeTypeTools::MapTextPropertyToId? This test failure: vtkFreeTypeTools.cxx:634:71: runtime error: left shift of negative value -450 Is happening because the author is assuming vtkTextProperty's GetOrientation() returns an angle between 0 and 360: int angle = (vtkMath::Round(tprop->GetOrientation() * 10.0) % 3600) << bits; when in fact the returned angle can (apparently) be negative. Questions: 1) vtkTextProperty's GetOrientation() docs say only "Set/Get the text's orientation (in degrees)." I guess any range is correct? 2) is there a utility function somewhere to constrain an angle to 0->360? I could not find one... Thanks, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From sean at rogue-research.com Wed Mar 25 15:23:15 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 25 Mar 2015 15:23:15 -0400 Subject: [vtk-developers] What's the equivalent of +2 now? Message-ID: <20150325192315.1776904879@mail.rogue-research.com> Hi all, The "Develop VTK with Git" page does not make clear to me what the equivalent of +2 is now... - What's the difference between someone adding Acked-by vs Reviewed-by vs Signed-off-by vs Tested-by? - Which must be present for it to be considered agreed upon? - When do I know I can merge a change in? Thanks, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From david.gobbi at gmail.com Wed Mar 25 15:39:25 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 25 Mar 2015 13:39:25 -0600 Subject: [vtk-developers] vtkBoundingBoxJava build errors... In-Reply-To: References: Message-ID: The fix is merged, but we'll be checking the nightlies to be sure that there are no further issues. https://gitlab.kitware.com/vtk/vtk/merge_requests/42 On Wed, Mar 25, 2015 at 8:12 AM, David Lonie wrote: > ...are on me. I was naughty and merged a trivial-looking branch before all > of the buildbots finished. > > We'll get the errors cleaned up or the change reverted soon. > > Ref: https://gitlab.kitware.com/vtk/vtk/merge_requests/34 > > Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Wed Mar 25 15:44:28 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 25 Mar 2015 15:44:28 -0400 Subject: [vtk-developers] Help with vtkFreeTypeTools::MapTextPropertyToId error... In-Reply-To: <20150325170752.27808897@mail.rogue-research.com> References: <20150325170752.27808897@mail.rogue-research.com> Message-ID: On Wed, Mar 25, 2015 at 1:07 PM, Sean McBride wrote: > Hi all, > > Anyone know vtkFreeTypeTools::MapTextPropertyToId? > > This test failure: > > > vtkFreeTypeTools.cxx:634:71: runtime error: left shift of negative value > -450 > > Is happening because the author is assuming vtkTextProperty's > GetOrientation() returns an angle between 0 and 360: > > int angle = (vtkMath::Round(tprop->GetOrientation() * 10.0) % 3600) << > bits; > > when in fact the returned angle can (apparently) be negative. > Correct. > Questions: > > 1) vtkTextProperty's GetOrientation() docs say only "Set/Get the text's > orientation (in degrees)." I guess any range is correct? > Yes, values outside of that range should be handled properly. > 2) is there a utility function somewhere to constrain an angle to 0->360? > I could not find one... > Nor am I. This may need it's own code to handle that, and should fix the error. Something like: int angle = vtkMath::Round(tprop->GetOrientation() * 10. % 3600; if (angle < 0) { angle += 3600; } angle << bits; ought to do the trick without breaking the hash. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Wed Mar 25 15:46:06 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 25 Mar 2015 15:46:06 -0400 Subject: [vtk-developers] Help with vtkFreeTypeTools::MapTextPropertyToId error... In-Reply-To: References: <20150325170752.27808897@mail.rogue-research.com> Message-ID: Ugh, why doesn't gmail have a compiler-precheck? On Wed, Mar 25, 2015 at 3:44 PM, David Lonie wrote: > int angle = vtkMath::Round(tprop->GetOrientation() * 10. % 3600; > Of course, that should be: int angle = vtkMath::Round(tprop->GetOrientation() * 10.) % 3600; Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Mar 25 16:25:56 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 25 Mar 2015 16:25:56 -0400 Subject: [vtk-developers] [vtkusers] RFC: Compiler support, removing hacks for old compilers In-Reply-To: References: <20150316180926.1146005295@mail.rogue-research.com> <89947a5813a84dc5842498245df50dd6@ES05AMSNLNT.srn.sandia.gov> <20150319193909.1656031800@mail.rogue-research.com> Message-ID: <20150325202556.1274353100@mail.rogue-research.com> On Thu, 19 Mar 2015 16:01:05 -0400, Shawn Waldon said: >FWIW, ParaView has a superbuild nightly binaries machine that runs debian 4 >(gcc 4.1.2). We may be updating to a more recent debian soon though. Hi all, So here's my patch that removes support for gcc 4.0 and older and MSVC++ 8.0 / Visual Studio 2005 and older: Would be great if any of you with old compilers could try it... Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From ben.boeckel at kitware.com Wed Mar 25 16:41:18 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 25 Mar 2015 16:41:18 -0400 Subject: [vtk-developers] What's the equivalent of +2 now? In-Reply-To: <20150325192315.1776904879@mail.rogue-research.com> References: <20150325192315.1776904879@mail.rogue-research.com> Message-ID: <20150325204118.GB12506@megas.kitwarein.com> On Wed, Mar 25, 2015 at 15:23:15 -0400, Sean McBride wrote: > The "Develop VTK with Git" page does not make clear to me what the > equivalent of +2 is now... > > - What's the difference between someone adding Acked-by vs Reviewed-by > vs Signed-off-by vs Tested-by? My interpretations: Acked-by - "I see nothing wrong with the change" (which is all kwrobot's checks can do) Reviewed-by - "I reviewed the change and agree with it" (we should probably use this rather than Acked-by for humans) Tested-by - "I tested the change and approve that it works" (buildbot will be using this along with Rejected-by and Acked-by) Signed-off-by is typically used to signify "I understand that my contribution is made under the license of the project and my patches are licensed accordingly" and is for the submitter to add when making commits and sending them to a list via git's format-patch / send-email workflow. The act of submitting a merge request is taken as this permission here. The manpage for git's format.signoff configuration: format.signoff A boolean value which lets you enable the -s/--signoff option of format-patch by default. Note: Adding the Signed-off-by: line to a patch should be a conscious act and means that you certify you have the rights to submit this work under the same open source license. Please see the SubmittingPatches document for further discussion. > - Which must be present for it to be considered agreed upon? > - When do I know I can merge a change in? The only hard gate right now is that kwrobot has OK'd the change. There is a patch for kwrobot I need to finish to add in support for blocking based on a developer's "Rejected-by" trailer and requiring at least one Acked-by (or, better, Reviewed-by) from a developer that is not the submitter. --Ben From dave.demarle at kitware.com Wed Mar 25 20:34:22 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 25 Mar 2015 20:34:22 -0400 Subject: [vtk-developers] What's the equivalent of +2 now? In-Reply-To: <20150325204118.GB12506@megas.kitwarein.com> References: <20150325192315.1776904879@mail.rogue-research.com> <20150325204118.GB12506@megas.kitwarein.com> Message-ID: So my interpretation of Ben's response is: Acked-by a human ~= +1 Reviewed-by ~= +2 Tested-by ~= +3 And the convention is we wait for a +2 to merge. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Mar 25, 2015 at 4:41 PM, Ben Boeckel wrote: > On Wed, Mar 25, 2015 at 15:23:15 -0400, Sean McBride wrote: > > The "Develop VTK with Git" page does not make clear to me what the > > equivalent of +2 is now... > > > > - What's the difference between someone adding Acked-by vs Reviewed-by > > vs Signed-off-by vs Tested-by? > > My interpretations: > > Acked-by - "I see nothing wrong with the change" (which is all > kwrobot's checks can do) > Reviewed-by - "I reviewed the change and agree with it" (we should > probably use this rather than Acked-by for humans) > Tested-by - "I tested the change and approve that it works" (buildbot > will be using this along with Rejected-by and Acked-by) > > Signed-off-by is typically used to signify "I understand that my > contribution is made under the license of the project and my patches are > licensed accordingly" and is for the submitter to add when making > commits and sending them to a list via git's format-patch / send-email > workflow. The act of submitting a merge request is taken as this > permission here. The manpage for git's format.signoff configuration: > > format.signoff > A boolean value which lets you enable the -s/--signoff option of > format-patch by default. Note: Adding the Signed-off-by: line > to a patch should be a conscious act and means that you certify > you have the rights to submit this work under the same open > source license. Please see the SubmittingPatches document for > further discussion. > > > - Which must be present for it to be considered agreed upon? > > - When do I know I can merge a change in? > > The only hard gate right now is that kwrobot has OK'd the change. There > is a patch for kwrobot I need to finish to add in support for blocking > based on a developer's "Rejected-by" trailer and requiring at least one > Acked-by (or, better, Reviewed-by) from a developer that is not the > submitter. > > --Ben > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Wed Mar 25 21:09:48 2015 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 25 Mar 2015 21:09:48 -0400 Subject: [vtk-developers] What's the equivalent of +2 now? In-Reply-To: References: <20150325192315.1776904879@mail.rogue-research.com> <20150325204118.GB12506@megas.kitwarein.com> Message-ID: On Wed, Mar 25, 2015 at 8:34 PM, David E DeMarle wrote: > So my interpretation of Ben's response is: > > Acked-by a human ~= +1 > Reviewed-by ~= +2 > Tested-by ~= +3 > > And the convention is we wait for a +2 to merge. > That was my rough interpretation too, and sounds like a reasonable path forward. +2 Marcus From deevankshu096 at gmail.com Thu Mar 26 04:27:15 2015 From: deevankshu096 at gmail.com (DEEVANKSHU GARG) Date: Thu, 26 Mar 2015 13:57:15 +0530 Subject: [vtk-developers] GSoC 2015-CAD Model and Simulation Spline Visualization In-Reply-To: <2FC0093C-8EB6-486C-9EDB-4D1ED798E025@kitware.com> References: <6BD334A2-5477-42A1-B500-6F2B4827A511@kitware.com> <6D747987-ACE4-448E-A9FB-23931788D594@kitware.com> <2FC0093C-8EB6-486C-9EDB-4D1ED798E025@kitware.com> Message-ID: Hello all! I have drafted my proposal for the project- CAD Model and simulation spline visualization after discussions with Mr.David Thompson.Please review it and suggest any edits or additions/subtractions so I can polish it before finally submitting it. Here's the link- https://docs.google.com/document/d/1WvVhjcitFqeehpCBOHk_N71pPY2BV1UX9gbvhehL6pA/edit?usp=sharing On Wed, Mar 25, 2015 at 9:58 AM, David Thompson wrote: > Hi Deevankshu, > > > Sorry for that little break in between but I was really stuck in my > mid-semester exams. > > That's OK; I am also in a time crunch to finish a paper. > > > .... Basically, it would be up to the IGA solver to provide us with > Bezier patches.The data provided from the patches about the control points > and vertices of the curve will be stored in arrays using the > {vtkAbstractArray ,vtkDataArray,vtkDoubleArray} classes. ... > > Correct, although if you are interested in storing BSplines (and then > converting to B?zier patches on demand), it would be better to store the > control points in a vtkStructuredGrid. > > > Then the main work starts.These datsets will be processed by further > filters present in the new mesh rendering class. > > Yes. Filters would likely inherit vtkMultiBlockDataSetAlgorithm. > > > The main tasks in our hand are-interpolation,point inversion and > finally,tesselation and rendering.Here's a rough implementation of the > methods used to perform these tasks. ... > > > > Tesselation and Rendering- > > I have always loathed the necessity of flow charts.I am attaching one > here too explaining the implementation of the tesselation method.A brief > explanation about this- > > -Tesselation Control Shader-Determines how much to tesselate,per-vertex > attributes,new patch vertices in xyz. > > -Tesselation primitive generator-Tessellates the curve or surface into > uvw coordinates. > > -Tesselation evaluation shader-Evaluate the curve or surface. Possibly > apply a displacement map. > > After tesselation,finally rendering takes place which involves writing > interpolated values out at the nodes of the > simplices(lines,triangles,tetrahedra). > > While it would be nice to have direct OpenGL rendering of patches, I would > prefer to implement tessellation on the CPU first so that the resulting > tessellation can be represented as a VTK dataset and used in further > operations before rendering. Also, since IGA frequently involves > 3-dimensional volumetric elements, rendering using the flowchart you show > would mean writing a volume renderer (which is an ambitious task and could > be its own GSoC project). If we tessellate on the CPU then VTK already has > volume rendering code that can be applied to the tetrahedra that > approximate a volumetric patch. > > > For the cutting part,I still have to see what changes will have to be > made to the already existing code.I will get to that soon. > > > > Please tell me what you think about it.Would it be a good idea to divide > the whole timeline into these three parts or do you recommend something > else? > > > I think 3 sections would be fine for the timeline. I would prefer to work > by (1) negotiating header files and unit tests, then (2) implementing the > classes for each of the 3 sections. > > David > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yulj04 at gmail.com Thu Mar 26 14:40:08 2015 From: yulj04 at gmail.com (Lijun Yu) Date: Thu, 26 Mar 2015 14:40:08 -0400 Subject: [vtk-developers] GSoC 2015 Shared Memory Parallelism in VTK Message-ID: Hi Berk and David, I'm Lijun Yu, a PhD student in applied math in the US. I just know about the GSoC a few days ago. I'm intested in the project Shared Memory Parallelism in VTK. I did image processing project and course before but I just have some basic idea about the multi-threaded code development though I took a course on the theory for the parallel computation. I don't know if it is a core requirement for a person to have the milti-threaded code development experience to qualify for the project. Thanks for the suggestions. Best, Lijun Yu -------------- next part -------------- An HTML attachment was scrubbed... URL: From deevankshu096 at gmail.com Fri Mar 27 02:01:03 2015 From: deevankshu096 at gmail.com (DEEVANKSHU GARG) Date: Thu, 26 Mar 2015 23:01:03 -0700 Subject: [vtk-developers] GSoC 2015-CAD Model and Simulation Spline Visualization In-Reply-To: References: <6BD334A2-5477-42A1-B500-6F2B4827A511@kitware.com> <6D747987-ACE4-448E-A9FB-23931788D594@kitware.com> <2FC0093C-8EB6-486C-9EDB-4D1ED798E025@kitware.com> Message-ID: I have submitted the proposal on the GSoC profile also.Please review it.Thanks. On 26 Mar 2015 13:57, "DEEVANKSHU GARG" wrote: > Hello all! > I have drafted my proposal for the project- CAD Model and simulation > spline visualization after discussions with Mr.David Thompson.Please review > it and suggest any edits or additions/subtractions so I can polish it > before finally submitting it. > Here's the link- > > https://docs.google.com/document/d/1WvVhjcitFqeehpCBOHk_N71pPY2BV1UX9gbvhehL6pA/edit?usp=sharing > > > > On Wed, Mar 25, 2015 at 9:58 AM, David Thompson < > david.thompson at kitware.com> wrote: > >> Hi Deevankshu, >> >> > Sorry for that little break in between but I was really stuck in my >> mid-semester exams. >> >> That's OK; I am also in a time crunch to finish a paper. >> >> > .... Basically, it would be up to the IGA solver to provide us with >> Bezier patches.The data provided from the patches about the control points >> and vertices of the curve will be stored in arrays using the >> {vtkAbstractArray ,vtkDataArray,vtkDoubleArray} classes. ... >> >> Correct, although if you are interested in storing BSplines (and then >> converting to B?zier patches on demand), it would be better to store the >> control points in a vtkStructuredGrid. >> >> > Then the main work starts.These datsets will be processed by further >> filters present in the new mesh rendering class. >> >> Yes. Filters would likely inherit vtkMultiBlockDataSetAlgorithm. >> >> > The main tasks in our hand are-interpolation,point inversion and >> finally,tesselation and rendering.Here's a rough implementation of the >> methods used to perform these tasks. ... >> > >> > Tesselation and Rendering- >> > I have always loathed the necessity of flow charts.I am attaching one >> here too explaining the implementation of the tesselation method.A brief >> explanation about this- >> > -Tesselation Control Shader-Determines how much to tesselate,per-vertex >> attributes,new patch vertices in xyz. >> > -Tesselation primitive generator-Tessellates the curve or surface into >> uvw coordinates. >> > -Tesselation evaluation shader-Evaluate the curve or surface. Possibly >> apply a displacement map. >> > After tesselation,finally rendering takes place which involves writing >> interpolated values out at the nodes of the >> simplices(lines,triangles,tetrahedra). >> >> While it would be nice to have direct OpenGL rendering of patches, I >> would prefer to implement tessellation on the CPU first so that the >> resulting tessellation can be represented as a VTK dataset and used in >> further operations before rendering. Also, since IGA frequently involves >> 3-dimensional volumetric elements, rendering using the flowchart you show >> would mean writing a volume renderer (which is an ambitious task and could >> be its own GSoC project). If we tessellate on the CPU then VTK already has >> volume rendering code that can be applied to the tetrahedra that >> approximate a volumetric patch. >> >> > For the cutting part,I still have to see what changes will have to be >> made to the already existing code.I will get to that soon. >> > >> > Please tell me what you think about it.Would it be a good idea to >> divide the whole timeline into these three parts or do you recommend >> something else? >> >> >> I think 3 sections would be fine for the timeline. I would prefer to work >> by (1) negotiating header files and unit tests, then (2) implementing the >> classes for each of the 3 sections. >> >> David >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Fri Mar 27 07:32:53 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Fri, 27 Mar 2015 07:32:53 -0400 Subject: [vtk-developers] GSoC 2015 Shared Memory Parallelism in VTK In-Reply-To: References: Message-ID: Dear Lijun, It is not a core requirement to have experience in shared-memory parallelism. However, I should mention that I am aware of several applicants that understand the problem really well and will have strong proposals. At the end, it will come to the quality of the proposals we receive and all other things being equal, we will likely prefer candidates that have experience in the area. Best, -berk On Thu, Mar 26, 2015 at 2:40 PM, Lijun Yu wrote: > Hi Berk and David, > > I'm Lijun Yu, a PhD student in applied math in the US. I just know about > the GSoC a few days ago. I'm intested in the project Shared Memory > Parallelism in VTK. I did image processing project and course before but I > just have some basic idea about the multi-threaded code development > though I took a course on the theory for the parallel computation. I don't > know if it is a core requirement for a person to have the milti-threaded > code development experience to qualify for the project. Thanks for the > suggestions. > > Best, > Lijun Yu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Fri Mar 27 10:14:34 2015 From: david.lonie at kitware.com (David Lonie) Date: Fri, 27 Mar 2015 10:14:34 -0400 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: On Tue, Mar 24, 2015 at 9:26 AM, David Lonie wrote: > Now I'm leaning towards > > vtkBoundingBox ComputeBoundingBox(vtkViewport *) > [snip] > It needs a couple hints to be wrapped properly, but that's not nearly as > much trouble :) > Argh, it's not that easy. vtkBoundingBoxTcl.cxx is generated, but: vtkActor actor vtkRenderer renderer set bbox [actor ComputeBoundingBox renderer] fails, as vtkProp::ComputeBoundingBox isn't wrapped in Tcl or Python (didn't test java). vtkBoundingBox is wrapped, but even just vtkBoundingBox bbox fails in tcl ('unknown command vtkBoundingBox'). FWIW, bbox = vtk.vtkBoundingBox() works in python. Any ideas what's missing here? Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Fri Mar 27 10:25:00 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 27 Mar 2015 10:25:00 -0400 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: vtkBoundingBox does not derive from vtkObject. Are the tcl wrappers able to handle non-vtkObject (i.e. non-ref-counted) entities properly these days? On Fri, Mar 27, 2015 at 10:14 AM, David Lonie wrote: > On Tue, Mar 24, 2015 at 9:26 AM, David Lonie > wrote: >> >> Now I'm leaning towards >> >> vtkBoundingBox ComputeBoundingBox(vtkViewport *) >> [snip] >> It needs a couple hints to be wrapped properly, but that's not nearly as >> much trouble :) > > > Argh, it's not that easy. vtkBoundingBoxTcl.cxx is generated, but: > > vtkActor actor > vtkRenderer renderer > set bbox [actor ComputeBoundingBox renderer] > > fails, as vtkProp::ComputeBoundingBox isn't wrapped in Tcl or Python (didn't > test java). vtkBoundingBox is wrapped, but even just > > vtkBoundingBox bbox > > fails in tcl ('unknown command vtkBoundingBox'). FWIW, > > bbox = vtk.vtkBoundingBox() > > works in python. Any ideas what's missing here? > > Dave > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From david.gobbi at gmail.com Fri Mar 27 10:38:56 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 27 Mar 2015 08:38:56 -0600 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: No, neither the Tcl wrappers or the the Java wrappers can wrap vtkBoundingBox as an "object". But they could convert it into an array of six floats. For example, if a method takes an argument of type "vtkBoundingBox" in C++, it could be wrapped as a Tcl method that takes six floats. If a method returns a vtkBoundingBox in C++, it could be wrapped as a Tcl method that returns six floats. On Fri, Mar 27, 2015 at 8:25 AM, David Cole wrote: > vtkBoundingBox does not derive from vtkObject. Are the tcl wrappers > able to handle non-vtkObject (i.e. non-ref-counted) entities properly > these days? > > > On Fri, Mar 27, 2015 at 10:14 AM, David Lonie > wrote: > > On Tue, Mar 24, 2015 at 9:26 AM, David Lonie > > wrote: > >> > >> Now I'm leaning towards > >> > >> vtkBoundingBox ComputeBoundingBox(vtkViewport *) > >> [snip] > >> It needs a couple hints to be wrapped properly, but that's not nearly as > >> much trouble :) > > > > > > Argh, it's not that easy. vtkBoundingBoxTcl.cxx is generated, but: > > > > vtkActor actor > > vtkRenderer renderer > > set bbox [actor ComputeBoundingBox renderer] > > > > fails, as vtkProp::ComputeBoundingBox isn't wrapped in Tcl or Python > (didn't > > test java). vtkBoundingBox is wrapped, but even just > > > > vtkBoundingBox bbox > > > > fails in tcl ('unknown command vtkBoundingBox'). FWIW, > > > > bbox = vtk.vtkBoundingBox() > > > > works in python. Any ideas what's missing here? > > > > Dave > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Fri Mar 27 10:49:31 2015 From: david.lonie at kitware.com (David Lonie) Date: Fri, 27 Mar 2015 10:49:31 -0400 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: On Fri, Mar 27, 2015 at 10:38 AM, David Gobbi wrote: > No, neither the Tcl wrappers or the the Java wrappers can wrap > vtkBoundingBox as an "object". But they could convert it into an > array of six floats. For example, if a method takes an argument > of type "vtkBoundingBox" in C++, it could be wrapped as a Tcl > method that takes six floats. If a method returns a vtkBoundingBox > in C++, it could be wrapped as a Tcl method that returns six floats. > That'd be ok from a usability standpoint. Effort-wise, would this be a lot of work? I'm not introducing any API that takes vtkBoundingBox as input, so we'd just have to wrap the case where they're returned, if that makes it easier. As an aside, would it be difficult to have these handled as objects? If we could handle vtkBoundingBox, we could probably start using the wonderful vtkVector implementations, too. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Mar 27 11:21:31 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 27 Mar 2015 09:21:31 -0600 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: On Fri, Mar 27, 2015 at 8:49 AM, David Lonie wrote: > On Fri, Mar 27, 2015 at 10:38 AM, David Gobbi > wrote: > >> No, neither the Tcl wrappers or the the Java wrappers can wrap >> vtkBoundingBox as an "object". But they could convert it into an >> array of six floats. For example, if a method takes an argument >> of type "vtkBoundingBox" in C++, it could be wrapped as a Tcl >> method that takes six floats. If a method returns a vtkBoundingBox >> in C++, it could be wrapped as a Tcl method that returns six floats. >> > > That'd be ok from a usability standpoint. Effort-wise, would this be a lot > of work? > Same estimate that I gave before: it would take more than an afternoon. I'm not introducing any API that takes vtkBoundingBox as input, so we'd > just have to wrap the case where they're returned, if that makes it easier. > > As an aside, would it be difficult to have these handled as objects? If we > could handle vtkBoundingBox, we could probably start using the wonderful > vtkVector implementations, too. > It would be lots of work (I'm guessing two weeks minimum, probably much more). It would be very nice for Java, not sure if it would be worthwhile for Tcl. Wrapping vtkVector in python was especially tricky, because it was a templated class, and interpreted languages don't really support the concept of "templates". So the python wrappers automatically wrap a dozen or so instantiations of the vtkVector template and store them in a mapping so that you can do this: v = vtkVector[float,2]() print v [0.0, 0.0] So, in the python wrappers, vtkVector[float, 2] is equivalent to vtkVector in C++ (because python "float" is C++ "double"). - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Fri Mar 27 11:35:06 2015 From: david.lonie at kitware.com (David Lonie) Date: Fri, 27 Mar 2015 11:35:06 -0400 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: On Fri, Mar 27, 2015 at 11:21 AM, David Gobbi wrote: > On Fri, Mar 27, 2015 at 8:49 AM, David Lonie > wrote: > >> On Fri, Mar 27, 2015 at 10:38 AM, David Gobbi >> wrote: >> >>> No, neither the Tcl wrappers or the the Java wrappers can wrap >>> vtkBoundingBox as an "object". But they could convert it into an >>> array of six floats. For example, if a method takes an argument >>> of type "vtkBoundingBox" in C++, it could be wrapped as a Tcl >>> method that takes six floats. If a method returns a vtkBoundingBox >>> in C++, it could be wrapped as a Tcl method that returns six floats. >>> >> >> That'd be ok from a usability standpoint. Effort-wise, would this be a >> lot of work? >> > > Same estimate that I gave before: it would take more than an afternoon. > Would you have time to do this? It looks like we're going to need to bite the bullet and train the wrappers one way or another. No worries, If you're too busy, I can give it a shot, though I may need to bug you a bit while going through. But I really wouldn't mind taking some time to learn how the wrapping mechanisms work. > I'm not introducing any API that takes vtkBoundingBox as input, so we'd >> just have to wrap the case where they're returned, if that makes it easier. >> >> As an aside, would it be difficult to have these handled as objects? If >> we could handle vtkBoundingBox, we could probably start using the wonderful >> vtkVector implementations, too. >> > > It would be lots of work (I'm guessing two weeks minimum, probably much > more). It would be very nice for Java, not sure if it would be worthwhile > for Tcl. > > Wrapping vtkVector in python was especially tricky, because it was a > templated class, and interpreted languages don't really support the concept > of "templates". So the python wrappers automatically wrap a dozen or so > instantiations of the vtkVector template and store them in a mapping so > that you can do this: > > v = vtkVector[float,2]() > print v > [0.0, 0.0] > > So, in the python wrappers, vtkVector[float, 2] is equivalent to > vtkVector in C++ (because python "float" is C++ "double"). > I was thinking more along the lines of the concrete vtkVector3d, etc subclasses to avoid the templating issues. Is lifetime management the main problem with these classes? Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Mar 27 12:00:34 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 27 Mar 2015 10:00:34 -0600 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: On Fri, Mar 27, 2015 at 9:35 AM, David Lonie wrote: > On Fri, Mar 27, 2015 at 11:21 AM, David Gobbi > wrote: > >> On Fri, Mar 27, 2015 at 8:49 AM, David Lonie >> wrote: >> > Would you have time to do this? It looks like we're going to need to bite > the bullet and train the wrappers one way or another. No worries, If you're > too busy, I can give it a shot, though I may need to bug you a bit while > going through. But I really wouldn't mind taking some time to learn how the > wrapping mechanisms work. > No, I don't have time. Feel free to bug me with specific questions. I was thinking more along the lines of the concrete vtkVector3d, etc > subclasses to avoid the templating issues. Is lifetime management the main > problem with these classes? > Currently, the VTK wrappers need the superclasses of all wrapped classes to also be wrapped, that's how they handle method inheritance. Changes would be needed in order to wrap just the concrete subclasses classes. It's best not to touch this issue until the bounding box issue is fixed, suffice it to say that there are ways it can be done but it's not trivial. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From linyufly at gmail.com Sun Mar 29 12:00:14 2015 From: linyufly at gmail.com (Mingcheng Chen) Date: Sun, 29 Mar 2015 11:00:14 -0500 Subject: [vtk-developers] Do I need to delete an object when I create a smart pointer of it? Message-ID: Hello, I am always prudent when using VTK, i. e. I never mix the smart pointer and normal pointer of VTK objects. I have a concern. Suppose we have vtkPolyData *mesh = some_function_which_returns_vtkPolyData_star(...); vtkSmartPointer mesh_ptr = vtkSmartPointer(mesh); we should do mesh_ptr->Delete() after, right? However, can we do vtkSmartPointer mesh_ptr = vtkSmartPointer(some_function_which_returns_vtkPolyData_star(...)); ? If we do that, how can we delete the reference count to the object before passing it to vtkSmartPointer? Thanks! -Mingcheng -------------- next part -------------- An HTML attachment was scrubbed... URL: From josp.jorge at gmail.com Sun Mar 29 12:06:35 2015 From: josp.jorge at gmail.com (Jorge Perez) Date: Sun, 29 Mar 2015 18:06:35 +0200 Subject: [vtk-developers] Do I need to delete an object when I create a smart pointer of it? In-Reply-To: References: Message-ID: Hi, you can read here about that topic http://www.vtk.org/Wiki/VTK/Tutorials/SmartPointers HTH 2015-03-29 18:00 GMT+02:00 Mingcheng Chen : > Hello, > > I am always prudent when using VTK, i. e. I never mix the smart pointer > and normal pointer of VTK objects. > > I have a concern. Suppose we have > > vtkPolyData *mesh = some_function_which_returns_vtkPolyData_star(...); > vtkSmartPointer mesh_ptr = vtkSmartPointer(mesh); > > we should do mesh_ptr->Delete() after, right? > > However, can we do > > vtkSmartPointer mesh_ptr = > vtkSmartPointer(some_function_which_returns_vtkPolyData_star(...)); > > ? > > If we do that, how can we delete the reference count to the object before > passing it to vtkSmartPointer? > > Thanks! > > -Mingcheng > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From linyufly at gmail.com Sun Mar 29 12:11:50 2015 From: linyufly at gmail.com (Mingcheng Chen) Date: Sun, 29 Mar 2015 11:11:50 -0500 Subject: [vtk-developers] Do I need to delete an object when I create a smart pointer of it? In-Reply-To: References: Message-ID: Hi Jorge, Thank you very much! -Mingcheng On Sun, Mar 29, 2015 at 11:06 AM, Jorge Perez wrote: > Hi, you can read here about that topic > http://www.vtk.org/Wiki/VTK/Tutorials/SmartPointers > > HTH > > 2015-03-29 18:00 GMT+02:00 Mingcheng Chen : > >> Hello, >> >> I am always prudent when using VTK, i. e. I never mix the smart pointer >> and normal pointer of VTK objects. >> >> I have a concern. Suppose we have >> >> vtkPolyData *mesh = some_function_which_returns_vtkPolyData_star(...); >> vtkSmartPointer mesh_ptr = >> vtkSmartPointer(mesh); >> >> we should do mesh_ptr->Delete() after, right? >> >> However, can we do >> >> vtkSmartPointer mesh_ptr = >> vtkSmartPointer(some_function_which_returns_vtkPolyData_star(...)); >> >> ? >> >> If we do that, how can we delete the reference count to the object before >> passing it to vtkSmartPointer? >> >> Thanks! >> >> -Mingcheng >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -- Research Assistant in Graphics Group University of Illinois at Urbana-Champaign http://mingchengchen.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Mon Mar 30 09:26:32 2015 From: david.lonie at kitware.com (David Lonie) Date: Mon, 30 Mar 2015 09:26:32 -0400 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: On Fri, Mar 27, 2015 at 12:00 PM, David Gobbi wrote: > On Fri, Mar 27, 2015 at 9:35 AM, David Lonie > wrote: > >> On Fri, Mar 27, 2015 at 11:21 AM, David Gobbi >> wrote: >> >>> On Fri, Mar 27, 2015 at 8:49 AM, David Lonie >>> wrote: >>> >> Would you have time to do this? It looks like we're going to need to bite >> the bullet and train the wrappers one way or another. No worries, If you're >> too busy, I can give it a shot, though I may need to bug you a bit while >> going through. But I really wouldn't mind taking some time to learn how the >> wrapping mechanisms work. >> > > No, I don't have time. Feel free to bug me with specific questions. > I've started looking into the wrapping code to add support for methods returning vtkBoundingBox. I think I see what needs to happen, let me know if anything here sounds wrong: 1) Teach the parser about vtkBoundingBox: (basically duplicating what I see for vtkUnicodeString) 1a) Add #define VTK_BOUNDING_BOX to vtkType.h 1b) Add VTK_PARSE_BOUNDING_BOX to vtkParseTypeMap in vtkParse.y 1c) Add BoundingBox to the type_name definition in vtkParse.y 1d) Add BoundingBox detection to the guess_id_type method in vtkParse.y. 1e) Add vtkBoundingBox entry in vtkParse.l 2) Teach the wrapper about vtkBoundingBox (Tcl as an example, assuming others are similar...) 2a) Modify CheckFunctionSignature to allow vtkBoundingBox return types. 2b) Modify output_temp to declare the vtkBoundingBox temporary variable. 2c) Add a special case for vtkBoundingBox return types in outputFunction that converts to a bounds array. Sound good? Anything I'm missing? Thanks a ton! Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Mar 30 10:29:07 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 30 Mar 2015 08:29:07 -0600 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: On Mon, Mar 30, 2015 at 7:26 AM, David Lonie wrote: > On Fri, Mar 27, 2015 at 12:00 PM, David Gobbi > wrote: > >> On Fri, Mar 27, 2015 at 9:35 AM, David Lonie >> wrote: >> >>> On Fri, Mar 27, 2015 at 11:21 AM, David Gobbi >>> wrote: >>> >>>> On Fri, Mar 27, 2015 at 8:49 AM, David Lonie >>>> wrote: >>>> >>> Would you have time to do this? It looks like we're going to need to >>> bite the bullet and train the wrappers one way or another. No worries, If >>> you're too busy, I can give it a shot, though I may need to bug you a bit >>> while going through. But I really wouldn't mind taking some time to learn >>> how the wrapping mechanisms work. >>> >> >> No, I don't have time. Feel free to bug me with specific questions. >> > > I've started looking into the wrapping code to add support for methods > returning vtkBoundingBox. I think I see what needs to happen, let me know > if anything here sounds wrong: > > 1) Teach the parser about vtkBoundingBox: (basically duplicating what I > see for vtkUnicodeString) > 1a) Add #define VTK_BOUNDING_BOX to vtkType.h > 1b) Add VTK_PARSE_BOUNDING_BOX to vtkParseTypeMap in vtkParse.y > 1c) Add BoundingBox to the type_name definition in vtkParse.y > 1d) Add BoundingBox detection to the guess_id_type method in vtkParse.y. > 1e) Add vtkBoundingBox entry in vtkParse.l > The situation with vtkUnicodeString is very different from the situation with vtkBoundingBox. Most languages have the concept of a "unicode string", so we want vtkUnicodeString to be directly converted into e.g. a Python unicode string or a Java string. The type list in vtkType.h is for types that can be converted to native types in the wrapper language. Consider the python wrappers: they do not convert vtkBoundingBox into an existing python type, instead they wrap it as a new python type. If you add VTK_PARSE_BOUNDING_BOX, then you'd also have to check for it in vtkWrapPython.c, which is messier that the current situation where all we had to do was add it to the CMakeLists file. > 2) Teach the wrapper about vtkBoundingBox (Tcl as an example, assuming > others are similar...) > 2a) Modify CheckFunctionSignature to allow vtkBoundingBox return types. > 2b) Modify output_temp to declare the vtkBoundingBox temporary variable. > 2c) Add a special case for vtkBoundingBox return types in outputFunction > that converts to a bounds array. > CheckFunctionSignature() can recognize vtkBoundingBox by using strcmp to check whether the class name of the type is "vtkBoundingBox". In other words, modify the place where CheckFunctionSignature() looks at VTK_PARSE_OBJECT types (starting at line 888) and have it check for "vtkBoundingBox" there. This makes everything in (1) completely unnecessary. The list for (2) is good, though. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From josp.jorge at gmail.com Mon Mar 30 10:31:34 2015 From: josp.jorge at gmail.com (Jorge Perez) Date: Mon, 30 Mar 2015 16:31:34 +0200 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: I was also studying the vtkWrapTcl.c code, just the part related to the tasks described in 2). For instance, regarding to vtkVariant value, the function int checkFunctionSignature(ClassInfo *data) reject to wrap a method call if the return value is vtkVariant or expect an argument of type vtkVariant in one of this checks: if ((returnType & VTK_PARSE_INDIRECT) != VTK_PARSE_POINTER) // the return type is value not a pointer { args_ok = 0; } .... if ((argType & VTK_PARSE_INDIRECT) != VTK_PARSE_POINTER) // the argument is a value not a pointer { args_ok = 0; } I think that we can wrap (at least manually) some classes (vtkVariant, vtkBoundingBox, ...) not derived from vtkObject as new Tcl_ObjType and provide in vtkTclUtil some helper functions to convert from C++ instances to Tcl_Obj and the other way from Tcl_Obj to C++ instance. I'm experimenting with this idea: implement new Tcl_ObjType to wrap vtkVariant and vtkBoundingBox. By the way the generated C code could be based in Tcl_Obj *objv[] interface instead of char *argv[] best regards, Jorge 2015-03-30 15:26 GMT+02:00 David Lonie : > On Fri, Mar 27, 2015 at 12:00 PM, David Gobbi > wrote: > >> On Fri, Mar 27, 2015 at 9:35 AM, David Lonie >> wrote: >> >>> On Fri, Mar 27, 2015 at 11:21 AM, David Gobbi >>> wrote: >>> >>>> On Fri, Mar 27, 2015 at 8:49 AM, David Lonie >>>> wrote: >>>> >>> Would you have time to do this? It looks like we're going to need to >>> bite the bullet and train the wrappers one way or another. No worries, If >>> you're too busy, I can give it a shot, though I may need to bug you a bit >>> while going through. But I really wouldn't mind taking some time to learn >>> how the wrapping mechanisms work. >>> >> >> No, I don't have time. Feel free to bug me with specific questions. >> > > I've started looking into the wrapping code to add support for methods > returning vtkBoundingBox. I think I see what needs to happen, let me know > if anything here sounds wrong: > > 1) Teach the parser about vtkBoundingBox: (basically duplicating what I > see for vtkUnicodeString) > 1a) Add #define VTK_BOUNDING_BOX to vtkType.h > 1b) Add VTK_PARSE_BOUNDING_BOX to vtkParseTypeMap in vtkParse.y > 1c) Add BoundingBox to the type_name definition in vtkParse.y > 1d) Add BoundingBox detection to the guess_id_type method in vtkParse.y. > 1e) Add vtkBoundingBox entry in vtkParse.l > > 2) Teach the wrapper about vtkBoundingBox (Tcl as an example, assuming > others are similar...) > 2a) Modify CheckFunctionSignature to allow vtkBoundingBox return types. > 2b) Modify output_temp to declare the vtkBoundingBox temporary variable. > 2c) Add a special case for vtkBoundingBox return types in outputFunction > that converts to a bounds array. > > Sound good? Anything I'm missing? > > Thanks a ton! > Dave > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josp.jorge at gmail.com Mon Mar 30 10:39:31 2015 From: josp.jorge at gmail.com (Jorge Perez) Date: Mon, 30 Mar 2015 16:39:31 +0200 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: As for what I have seen in vtkWrapTcl we can deal with objects values excluded from wrapping (they appear in vtkXXXHierarchy.txt with the attribute WRAP_EXCLUDE) for instance: vtkVariant ; vtkVariant.h ; vtkCommonCore ; WRAP_EXCLUDE;WRAP_SPECIAL but it needs a specific check by name to finally accept a method signature to be wrapped without deal with step 1) best regards, Jorge 2015-03-30 16:29 GMT+02:00 David Gobbi : > On Mon, Mar 30, 2015 at 7:26 AM, David Lonie > wrote: > >> On Fri, Mar 27, 2015 at 12:00 PM, David Gobbi >> wrote: >> >>> On Fri, Mar 27, 2015 at 9:35 AM, David Lonie >>> wrote: >>> >>>> On Fri, Mar 27, 2015 at 11:21 AM, David Gobbi >>>> wrote: >>>> >>>>> On Fri, Mar 27, 2015 at 8:49 AM, David Lonie >>>>> wrote: >>>>> >>>> Would you have time to do this? It looks like we're going to need to >>>> bite the bullet and train the wrappers one way or another. No worries, If >>>> you're too busy, I can give it a shot, though I may need to bug you a bit >>>> while going through. But I really wouldn't mind taking some time to learn >>>> how the wrapping mechanisms work. >>>> >>> >>> No, I don't have time. Feel free to bug me with specific questions. >>> >> >> I've started looking into the wrapping code to add support for methods >> returning vtkBoundingBox. I think I see what needs to happen, let me know >> if anything here sounds wrong: >> >> 1) Teach the parser about vtkBoundingBox: (basically duplicating what I >> see for vtkUnicodeString) >> 1a) Add #define VTK_BOUNDING_BOX to vtkType.h >> 1b) Add VTK_PARSE_BOUNDING_BOX to vtkParseTypeMap in vtkParse.y >> 1c) Add BoundingBox to the type_name definition in vtkParse.y >> 1d) Add BoundingBox detection to the guess_id_type method in vtkParse.y. >> 1e) Add vtkBoundingBox entry in vtkParse.l >> > > The situation with vtkUnicodeString is very different from the situation > with vtkBoundingBox. Most languages have the concept of a "unicode > string", so we want vtkUnicodeString to be directly converted into e.g. a > Python unicode string or a Java string. > > The type list in vtkType.h is for types that can be converted to native > types in the wrapper language. Consider the python wrappers: they do not > convert vtkBoundingBox into an existing python type, instead they wrap it > as a new python type. If you add VTK_PARSE_BOUNDING_BOX, then you'd also > have to check for it in vtkWrapPython.c, which is messier that the current > situation where all we had to do was add it to the CMakeLists file. > > >> 2) Teach the wrapper about vtkBoundingBox (Tcl as an example, assuming >> others are similar...) >> 2a) Modify CheckFunctionSignature to allow vtkBoundingBox return types. >> 2b) Modify output_temp to declare the vtkBoundingBox temporary variable. >> 2c) Add a special case for vtkBoundingBox return types in outputFunction >> that converts to a bounds array. >> > > CheckFunctionSignature() can recognize vtkBoundingBox by using strcmp to > check whether the class name of the type is "vtkBoundingBox". In other > words, modify the place where CheckFunctionSignature() looks at > VTK_PARSE_OBJECT types (starting at line 888) and have it check for > "vtkBoundingBox" there. This makes everything in (1) completely > unnecessary. The list for (2) is good, though. > > - David > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Mar 30 10:58:20 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 30 Mar 2015 08:58:20 -0600 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: On Mon, Mar 30, 2015 at 8:31 AM, Jorge Perez wrote: > I was also studying the vtkWrapTcl.c code, just the part related to the > tasks described in 2). > > For instance, regarding to vtkVariant value, the function int > checkFunctionSignature(ClassInfo *data) reject to wrap a method call if the > return value is vtkVariant or expect an argument of type vtkVariant in one > of this checks: > > if ((returnType & VTK_PARSE_INDIRECT) != VTK_PARSE_POINTER) // the return > type is value not a pointer > > { > > args_ok = 0; > > } > > .... > > if ((argType & VTK_PARSE_INDIRECT) != VTK_PARSE_POINTER) // the argument > is a value not a pointer > > { > > args_ok = 0; > > } > Yes, exactly. You want to add "if" statements that allow "special" types like vtkVariant and vtkBoundingBox to get through. if ((argType & VTK_PARSE_INDIRECT) == VTK_PARSE_REF || /* pass by reference e.g. "¶m" */ (argType & VTK_PARSE_INDIRECT) == 0) /* pass-by-value */ { if (strcmp(currentFunction->ReturnClass, "vtkVariant") == 0 || strcmp(currentFunction->ReturnClass, "vtkBoundingox") == 0) { /* is a special object passed by reference or passed by value */ } else { /* is unrecognized */ args_ok = 0; } I think that we can wrap (at least manually) some classes (vtkVariant, > vtkBoundingBox, ...) not derived from vtkObject as new Tcl_ObjType and > provide in vtkTclUtil some helper functions to convert from C++ instances > to Tcl_Obj and the other way from Tcl_Obj to C++ instance. > > > I'm experimenting with this idea: implement new Tcl_ObjType to wrap > vtkVariant and vtkBoundingBox. > Sounds like it should work, but it has been so long since I've worked with Tcl that I don't remember anything about creating new tcl object types! By the way the generated C code could be based in Tcl_Obj *objv[] interface > instead of char *argv[] > If you think it would be a good change, put it on gitlab.kitware.com and I'll take a look. Cheers, - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Mar 30 11:04:32 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 30 Mar 2015 09:04:32 -0600 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: On Mon, Mar 30, 2015 at 8:39 AM, Jorge Perez wrote: > As for what I have seen in vtkWrapTcl we can deal with objects values > excluded from wrapping (they appear in vtkXXXHierarchy.txt with the > attribute WRAP_EXCLUDE) for instance: > > vtkVariant ; vtkVariant.h ; vtkCommonCore ; WRAP_EXCLUDE;WRAP_SPECIAL > If WRAP_EXCLUDE is set, then VTK will not automatically wrap the type, _unless_ the wrapping language is Python and WRAP_SPECIAL is set. But these flags are irrelevant for types that are "manually" wrapped. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From josp.jorge at gmail.com Mon Mar 30 12:41:11 2015 From: josp.jorge at gmail.com (Jorge Perez) Date: Mon, 30 Mar 2015 18:41:11 +0200 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: Understood, thank you!!! 2015-03-30 17:04 GMT+02:00 David Gobbi : > On Mon, Mar 30, 2015 at 8:39 AM, Jorge Perez wrote: > >> As for what I have seen in vtkWrapTcl we can deal with objects values >> excluded from wrapping (they appear in vtkXXXHierarchy.txt with the >> attribute WRAP_EXCLUDE) for instance: >> >> vtkVariant ; vtkVariant.h ; vtkCommonCore ; WRAP_EXCLUDE;WRAP_SPECIAL >> > > If WRAP_EXCLUDE is set, then VTK will not automatically wrap the type, > _unless_ the wrapping language is Python and WRAP_SPECIAL is set. > > But these flags are irrelevant for types that are "manually" wrapped. > > - David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josp.jorge at gmail.com Mon Mar 30 12:44:11 2015 From: josp.jorge at gmail.com (Jorge Perez) Date: Mon, 30 Mar 2015 18:44:11 +0200 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: I still do not have any useful implementation, just the design ideas based on Tcl_ObjType. Now that I know it could be useful I will continue with the implementation. 2015-03-30 16:58 GMT+02:00 David Gobbi : > On Mon, Mar 30, 2015 at 8:31 AM, Jorge Perez wrote: > >> I was also studying the vtkWrapTcl.c code, just the part related to the >> tasks described in 2). >> >> For instance, regarding to vtkVariant value, the function int >> checkFunctionSignature(ClassInfo *data) reject to wrap a method call if the >> return value is vtkVariant or expect an argument of type vtkVariant in one >> of this checks: >> >> if ((returnType & VTK_PARSE_INDIRECT) != VTK_PARSE_POINTER) // the return >> type is value not a pointer >> >> { >> >> args_ok = 0; >> >> } >> >> .... >> >> if ((argType & VTK_PARSE_INDIRECT) != VTK_PARSE_POINTER) // the argument >> is a value not a pointer >> >> { >> >> args_ok = 0; >> >> } >> > > Yes, exactly. You want to add "if" statements that allow "special" types > like vtkVariant and vtkBoundingBox to get through. > > if ((argType & VTK_PARSE_INDIRECT) == VTK_PARSE_REF || /* pass by > reference e.g. "¶m" */ > (argType & VTK_PARSE_INDIRECT) == 0) /* pass-by-value */ > { > if (strcmp(currentFunction->ReturnClass, "vtkVariant") == 0 || > strcmp(currentFunction->ReturnClass, "vtkBoundingox") == 0) > { > /* is a special object passed by reference or passed by value */ > } > else > { > /* is unrecognized */ > args_ok = 0; > } > > I think that we can wrap (at least manually) some classes (vtkVariant, >> vtkBoundingBox, ...) not derived from vtkObject as new Tcl_ObjType and >> provide in vtkTclUtil some helper functions to convert from C++ instances >> to Tcl_Obj and the other way from Tcl_Obj to C++ instance. >> >> >> I'm experimenting with this idea: implement new Tcl_ObjType to wrap >> vtkVariant and vtkBoundingBox. >> > > Sounds like it should work, but it has been so long since I've worked with > Tcl that I don't remember anything about creating new tcl object types! > > > By the way the generated C code could be based in Tcl_Obj *objv[] >> interface instead of char *argv[] >> > > If you think it would be a good change, put it on gitlab.kitware.com and > I'll take a look. > > Cheers, > - David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Mon Mar 30 17:32:09 2015 From: sean at rogue-research.com (Sean McBride) Date: Mon, 30 Mar 2015 17:32:09 -0400 Subject: [vtk-developers] "vtkCommonCoreTcl-TestEmptyInput" fails due to use-after-free in vtkDataEncoder Message-ID: <20150330213209.663391901@mail.rogue-research.com> Hi all, On my Rogue7 dashboard vtkCommonCoreTcl-TestEmptyInput fails intermittently. I debugged it a bit and, long story short, the evidence suggested a use-after-free so I enabled MallocScribble (on OS X it writes 0x55 to freed memory) and caught it in lldb: (lldb) bt * thread #7: tid = 0x64d84d, 0x00007fff8a7afbc9 libsystem_c.dylib`pthread_mutex_lock + 20, stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) frame #0: 0x00007fff8a7afbc9 libsystem_c.dylib`pthread_mutex_lock + 20 frame #1: 0x0000000100fd0e3e libvtkCommonCore-6.3.1.dylib`vtkSimpleMutexLock::Lock(this=0x555555555555561d) + 94 at vtkMutexLock.cxx:75 frame #2: 0x000000013886bd3e libvtkWebCore-6.3.1.dylib`(anonymous namespace)::vtkSharedData::BeginWorker(this=0x5555555555555555) + 158 at vtkDataEncoder.cxx:99 frame #3: 0x000000013886ad18 libvtkWebCore-6.3.1.dylib`(anonymous namespace)::Worker(calldata=0x000000010f046740) + 248 at vtkDataEncoder.cxx:304 frame #4: 0x00007fff8a7aa772 libsystem_c.dylib`_pthread_start + 327 frame #5: 0x00007fff8a7971a1 libsystem_c.dylib`thread_start + 13 Notice the this=0x5555555555555555. Definitely use-after-free. Hopefully this is enough for someone that knows this code to squash the bug...! Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From ben.boeckel at kitware.com Mon Mar 30 18:05:49 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 30 Mar 2015 18:05:49 -0400 Subject: [vtk-developers] "vtkCommonCoreTcl-TestEmptyInput" fails due to use-after-free in vtkDataEncoder In-Reply-To: <20150330213209.663391901@mail.rogue-research.com> References: <20150330213209.663391901@mail.rogue-research.com> Message-ID: <20150330220549.GA14903@megas.kitwarein.com> On Mon, Mar 30, 2015 at 17:32:09 -0400, Sean McBride wrote: > I debugged it a bit and, long story short, the evidence suggested a > use-after-free so I enabled MallocScribble (on OS X it writes 0x55 to > freed memory) and caught it in lldb: FWIW, same thing with glibc: export MALLOC_PERTURB_=100 Any value between 1 and 255 will memset() inside of free() (0 disables). Causes ~5% overhead or so. --Ben From sean at rogue-research.com Mon Mar 30 18:30:49 2015 From: sean at rogue-research.com (Sean McBride) Date: Mon, 30 Mar 2015 18:30:49 -0400 Subject: [vtk-developers] "vtkCommonCoreTcl-TestEmptyInput" fails due to use-after-free in vtkDataEncoder In-Reply-To: <20150330220549.GA14903@megas.kitwarein.com> References: <20150330213209.663391901@mail.rogue-research.com> <20150330220549.GA14903@megas.kitwarein.com> Message-ID: <20150330223049.2065395391@mail.rogue-research.com> On Mon, 30 Mar 2015 18:05:49 -0400, Ben Boeckel said: >> I debugged it a bit and, long story short, the evidence suggested a >> use-after-free so I enabled MallocScribble (on OS X it writes 0x55 to >> freed memory) and caught it in lldb: > >FWIW, same thing with glibc: > > export MALLOC_PERTURB_=100 > >Any value between 1 and 255 will memset() inside of free() (0 disables). >Causes ~5% overhead or so. The OS X one has similarly low overhead, and as such has been enabled on all my dashboards for ages. Getting off-topic I guess, but given the low overhead and great benefit, would be nice to have it enabled on the continuous and gitlab bots too... (maybe it is?) Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From ben.boeckel at kitware.com Mon Mar 30 22:34:52 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 30 Mar 2015 22:34:52 -0400 Subject: [vtk-developers] "vtkCommonCoreTcl-TestEmptyInput" fails due to use-after-free in vtkDataEncoder In-Reply-To: <20150330223049.2065395391@mail.rogue-research.com> References: <20150330213209.663391901@mail.rogue-research.com> <20150330220549.GA14903@megas.kitwarein.com> <20150330223049.2065395391@mail.rogue-research.com> Message-ID: <20150331023452.GA14294@bronto-burt.dev.benboeckel.net> On Mon, Mar 30, 2015 at 18:30:49 -0400, Sean McBride wrote: > The OS X one has similarly low overhead, and as such has been enabled > on all my dashboards for ages. How is it enabled? Environment? Or is it special tooling? > Getting off-topic I guess, but given the low overhead and great > benefit, would be nice to have it enabled on the continuous and gitlab > bots too... (maybe it is?) I'll start turning it on for them. Since we'd like to keep things green, we it won't be a one-shot deal. In front of that though is doing parallel testing (shaves ~hour off of some builds so our turn-around should be much better). --Ben From andrew.amaclean at gmail.com Tue Mar 31 00:59:10 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 31 Mar 2015 15:59:10 +1100 Subject: [vtk-developers] "vtkCommonCoreTcl-TestEmptyInput" fails due to use-after-free in vtkDataEncoder Message-ID: Sean, Thankyou for this information! I have been trying to convert TestEmptyInput.tcl to python and have been getting random hangs in windows, now I know the cause! Currently I can test 1708 classes out of 1981 classes. This is done by removing the testing for vtkDataEncoder, and filtering out classes that have 'Reader', 'Writer', 'Array_I', 'Qt' in their names. and trapping abstract classes and those such as vtkMathTextUtilities which have no concrete implementation. I am also skipping the classExcepions as detailed in the tcl code. I am not sure if this is a good approach, but I think I am getting there. I am also adding an observer for error events but it has only picked up a fail on: 144 Testing -- vtkObjectBase - vtkObjectBase AddObserver Also there is a message like: 221 Testing -- vtkStreamingStatistics - StatisticsAlgorithm not set! Punting! Not sure what to do with this one. Regards Andrew ---------- Forwarded message ---------- > From: Sean McBride > To: > Cc: > Date: Mon, 30 Mar 2015 17:32:09 -0400 > Subject: [vtk-developers] "vtkCommonCoreTcl-TestEmptyInput" fails due to > use-after-free in vtkDataEncoder > Hi all, > > On my Rogue7 dashboard vtkCommonCoreTcl-TestEmptyInput fails > intermittently. > > I debugged it a bit and, long story short, the evidence suggested a > use-after-free so I enabled MallocScribble (on OS X it writes 0x55 to freed > memory) and caught it in lldb: > > (lldb) bt > * thread #7: tid = 0x64d84d, 0x00007fff8a7afbc9 > libsystem_c.dylib`pthread_mutex_lock + 20, stop reason = EXC_BAD_ACCESS > (code=EXC_I386_GPFLT) > frame #0: 0x00007fff8a7afbc9 libsystem_c.dylib`pthread_mutex_lock + 20 > frame #1: 0x0000000100fd0e3e > libvtkCommonCore-6.3.1.dylib`vtkSimpleMutexLock::Lock(this=0x555555555555561d) > + 94 at vtkMutexLock.cxx:75 > frame #2: 0x000000013886bd3e libvtkWebCore-6.3.1.dylib`(anonymous > namespace)::vtkSharedData::BeginWorker(this=0x5555555555555555) + 158 at > vtkDataEncoder.cxx:99 > frame #3: 0x000000013886ad18 libvtkWebCore-6.3.1.dylib`(anonymous > namespace)::Worker(calldata=0x000000010f046740) + 248 at > vtkDataEncoder.cxx:304 > frame #4: 0x00007fff8a7aa772 libsystem_c.dylib`_pthread_start + 327 > frame #5: 0x00007fff8a7971a1 libsystem_c.dylib`thread_start + 13 > > Notice the this=0x5555555555555555. Definitely use-after-free. > > Hopefully this is enough for someone that knows this code to squash the > bug...! > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > > > > ---------- Forwarded message ---------- > From: Ben Boeckel > To: Sean McBride > Cc: vtk-developers at vtk.org > Date: Mon, 30 Mar 2015 18:05:49 -0400 > Subject: Re: [vtk-developers] "vtkCommonCoreTcl-TestEmptyInput" fails due > to use-after-free in vtkDataEncoder > On Mon, Mar 30, 2015 at 17:32:09 -0400, Sean McBride wrote: > > I debugged it a bit and, long story short, the evidence suggested a > > use-after-free so I enabled MallocScribble (on OS X it writes 0x55 to > > freed memory) and caught it in lldb: > > FWIW, same thing with glibc: > > export MALLOC_PERTURB_=100 > > Any value between 1 and 255 will memset() inside of free() (0 disables). > Causes ~5% overhead or so. > > --Ben > > > > ---------- Forwarded message ---------- > From: Sean McBride > To: > Cc: vtk-developers at vtk.org > Date: Mon, 30 Mar 2015 18:30:49 -0400 > Subject: Re: [vtk-developers] "vtkCommonCoreTcl-TestEmptyInput" fails due > to use-after-free in vtkDataEncoder > On Mon, 30 Mar 2015 18:05:49 -0400, Ben Boeckel said: > > >> I debugged it a bit and, long story short, the evidence suggested a > >> use-after-free so I enabled MallocScribble (on OS X it writes 0x55 to > >> freed memory) and caught it in lldb: > > > >FWIW, same thing with glibc: > > > > export MALLOC_PERTURB_=100 > > > >Any value between 1 and 255 will memset() inside of free() (0 disables). > >Causes ~5% overhead or so. > > The OS X one has similarly low overhead, and as such has been enabled on > all my dashboards for ages. > > Getting off-topic I guess, but given the low overhead and great benefit, > would be nice to have it enabled on the continuous and gitlab bots too... > (maybe it is?) > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > > > > ---------- Forwarded message ---------- > From: Ben Boeckel > To: Sean McBride > Cc: vtk-developers at vtk.org > Date: Mon, 30 Mar 2015 22:34:52 -0400 > Subject: Re: [vtk-developers] "vtkCommonCoreTcl-TestEmptyInput" fails due > to use-after-free in vtkDataEncoder > On Mon, Mar 30, 2015 at 18:30:49 -0400, Sean McBride wrote: > > The OS X one has similarly low overhead, and as such has been enabled > > on all my dashboards for ages. > > How is it enabled? Environment? Or is it special tooling? > > > Getting off-topic I guess, but given the low overhead and great > > benefit, would be nice to have it enabled on the continuous and gitlab > > bots too... (maybe it is?) > > I'll start turning it on for them. Since we'd like to keep things green, > we it won't be a one-shot deal. In front of that though is doing > parallel testing (shaves ~hour off of some builds so our turn-around > should be much better). > > --Ben > > -- > ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Tue Mar 31 07:54:50 2015 From: david.lonie at kitware.com (David Lonie) Date: Tue, 31 Mar 2015 07:54:50 -0400 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: On Mon, Mar 30, 2015 at 10:31 AM, Jorge Perez wrote: > I'm experimenting with this idea: implement new Tcl_ObjType to wrap > vtkVariant and vtkBoundingBox. > This would be great! I'll keep pushing forward on my vtkBoundingBox --> double[6] implementation since I need something very soon, but this solution sounds better. Looking forward to it. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue Mar 31 08:55:39 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 31 Mar 2015 08:55:39 -0400 Subject: [vtk-developers] "vtkCommonCoreTcl-TestEmptyInput" fails due to use-after-free in vtkDataEncoder In-Reply-To: <20150331023452.GA14294@bronto-burt.dev.benboeckel.net> References: <20150330213209.663391901@mail.rogue-research.com> <20150330220549.GA14903@megas.kitwarein.com> <20150330223049.2065395391@mail.rogue-research.com> <20150331023452.GA14294@bronto-burt.dev.benboeckel.net> Message-ID: <20150331125539.GA17723@megas.kitwarein.com> On Mon, Mar 30, 2015 at 22:34:52 -0400, Ben Boeckel wrote: > How is it enabled? Environment? Or is it special tooling? Found it. I'll enable it on megas and trey for now (since they're faster builds). --Ben From e.tadeu at gmail.com Tue Mar 31 09:51:35 2015 From: e.tadeu at gmail.com (E. Tadeu) Date: Tue, 31 Mar 2015 10:51:35 -0300 Subject: [vtk-developers] Static methods in vtkPythonArgs Message-ID: Hi! Why is there a static version for many methods in vtkPythonArgs (specially GetValue)? I see that they are being used only by Py*_SequenceSize. Is there a special reason? Could the static versions be removed, and Py*_SequenceSize generated code use an instance of vtkPythonArgs, just like all other generated functions? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Mar 31 10:39:04 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 31 Mar 2015 08:39:04 -0600 Subject: [vtk-developers] Static methods in vtkPythonArgs In-Reply-To: References: Message-ID: On Tue, Mar 31, 2015 at 7:51 AM, E. Tadeu wrote: > Hi! > > Why is there a static version for many methods in vtkPythonArgs > (specially GetValue)? > It allows those methods to be called without a vtkPythonArgs object ;) I see that they are being used only by Py*_SequenceSize. Is there a > special reason? Could the static versions be removed, and Py*_SequenceSize > generated code use an instance of vtkPythonArgs, just like all other > generated functions? > They're also called by the other methods that make up the python sequence protocol, i.e. SequenceSetItem and Sequence(Get)Item. As for why these protocol methods call the static version of GetValue(), it's because they have no need to create a vtkPythonArgs object. The main purpose of the vtkPythonArgs object is to check the argument list, i.e. to verify that the correct number of arguments has been passed, to keep track of the current position in the argument list, etc. None of that is necessary for python protocol methods like SequenceSize. All they need is a simple way to convert a python object to a C++ object or vice-versa. The static methods serve that purpose. If the python wrappers handled more python protocols, the static GetValue() methods would be more widely used. Cheers, - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Tue Mar 31 11:06:15 2015 From: sean at rogue-research.com (Sean McBride) Date: Tue, 31 Mar 2015 11:06:15 -0400 Subject: [vtk-developers] "vtkCommonCoreTcl-TestEmptyInput" fails due to use-after-free in vtkDataEncoder In-Reply-To: <20150331023452.GA14294@bronto-burt.dev.benboeckel.net> References: <20150330213209.663391901@mail.rogue-research.com> <20150330220549.GA14903@megas.kitwarein.com> <20150330223049.2065395391@mail.rogue-research.com> <20150331023452.GA14294@bronto-burt.dev.benboeckel.net> Message-ID: <20150331150615.13548201@mail.rogue-research.com> On Mon, 30 Mar 2015 22:34:52 -0400, Ben Boeckel said: >> The OS X one has similarly low overhead, and as such has been enabled >> on all my dashboards for ages. > >How is it enabled? Environment? Or is it special tooling? Seems you found it, but for completeness, here's how I enable them on my dashboards: (scroll down to "dashboard_hook_test".) I suggest also turning on MallocErrorAbort, which will cause certain memory errors to abort instead of just log. See 'man malloc' (on OS X). Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From sean at rogue-research.com Tue Mar 31 11:08:40 2015 From: sean at rogue-research.com (Sean McBride) Date: Tue, 31 Mar 2015 11:08:40 -0400 Subject: [vtk-developers] "vtkCommonCoreTcl-TestEmptyInput" fails due to use-after-free in vtkDataEncoder In-Reply-To: References: Message-ID: <20150331150840.160508609@mail.rogue-research.com> On Tue, 31 Mar 2015 15:59:10 +1100, Andrew Maclean said: > Thankyou for this information! I have been trying to >convert TestEmptyInput.tcl to python and have been getting random hangs in >windows, now I know the cause! Well, we sorta do. There's various threading stuff in vtkDataEncoder and being an intermittent failure, there must be some kind of race there. Something like Thread Sanitizer or hellgrind might catch it easily. Those tools don't work well on OS X IIRC, maybe someone with linux could try? Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From ben.boeckel at kitware.com Tue Mar 31 11:19:28 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 31 Mar 2015 11:19:28 -0400 Subject: [vtk-developers] "vtkCommonCoreTcl-TestEmptyInput" fails due to use-after-free in vtkDataEncoder In-Reply-To: <20150331150615.13548201@mail.rogue-research.com> References: <20150330213209.663391901@mail.rogue-research.com> <20150330220549.GA14903@megas.kitwarein.com> <20150330223049.2065395391@mail.rogue-research.com> <20150331023452.GA14294@bronto-burt.dev.benboeckel.net> <20150331150615.13548201@mail.rogue-research.com> Message-ID: <20150331151928.GA10273@megas.kitwarein.com> On Tue, Mar 31, 2015 at 11:06:15 -0400, Sean McBride wrote: > Seems you found it, but for completeness, here's how I enable them on my dashboards: > > > > (scroll down to "dashboard_hook_test".) > > I suggest also turning on MallocErrorAbort, which will cause certain > memory errors to abort instead of just log. See 'man malloc' (on OS > X). Ah, much more there (I only had Scribble, PreScribble, and GuardEdges) :) . I've added them all to the trey build which should show up under "experimental". One difference is that it will be during the entire build as well. Hopefully the toolchain is safe, but catching errors in the wrapping tools would be nice as well. Thanks, --Ben From csharpdotcom at gmail.com Tue Mar 31 13:47:09 2015 From: csharpdotcom at gmail.com (CSharpdotcom .) Date: Tue, 31 Mar 2015 10:47:09 -0700 Subject: [vtk-developers] Selecting libraries Message-ID: Hello, I've just been trying another Java example of VTK, as listed in http://www.vtk.org/Wiki/VTK/Examples/Java/Cylinder, which I put into NetBeans. When I use the code in the static block: static { System.loadLibrary("vtkCommonCoreJava"); System.loadLibrary("vtkFiltersSourcesJava"); System.loadLibrary("vtkInteractionStyleJava"); System.loadLibrary("vtkRenderingOpenGLJava"); } as given in the listing, the application fails with the error message: Exception in thread "main" java.lang.UnsatisfiedLinkError: vtk.vtkPolyDataMapper.VTKInit()J .......... and I found that VTKInit() is called right at the very end of the vtkPolyData class in vtk.jar. However, if I replace loading the specified libraries in the static block above by loading all the libraries using: static { if (!vtkNativeLibrary.LoadAllNativeLibraries()) { for (vtkNativeLibrary lib : vtkNativeLibrary.values()) { if (!lib.IsLoaded()) System.out.println(lib.GetLibraryName() + " not loaded"); } System.out.println("Make sure the search path is correct: "); System.out.println(System.getProperty("java.library.path")); } vtkNativeLibrary.DisableOutputWindow(null); } as copied from the code I got working last week, then the application works correctly. My questions are: 1) Is there a way of fixing the error without loading all the libraries? 2) Related to that, is there a way of determining which libraries to load, without having to load them all? 3) Is it better to load only the libraries you need rather than loading them all? This of course will depend on knowing which libraries to load from (2). At your convenience I would be grateful to have some help on this. Christopher Sharp From e.tadeu at gmail.com Tue Mar 31 14:22:39 2015 From: e.tadeu at gmail.com (E. Tadeu) Date: Tue, 31 Mar 2015 15:22:39 -0300 Subject: [vtk-developers] Static methods in vtkPythonArgs In-Reply-To: References: Message-ID: David, Perhaps you could help me with my first problem: I?m trying to patch vtkWrapPython in order to fully support unicode arguments. Currently, unicode python objects passed to VTK must be ascii-encodable (because of _PyUnicode_AsDefaultEncodedString(o, NULL) being used in vtkPythonGetStringValue in vtkPythonArgs.cxx). I?m trying to change it so that it will support any unicode string, encoding them in UTF-8. This must be done in two steps: first, using a PyObject *s = PyUnicode_AsUTF8String(o);, which will return a new reference to a temporary PyStringObject, and then using PyString_AS_STRING on this object, which will return a char * pointing to an internal buffer in s. The problem is that this temporary PyStringObject (s) must be deleted by calling Py_XDECREF only after the call to the wrapped function. I thought about adding an std::vector with these temporary python strings to the vtkPythonArgs class; each new temporary would be pushed to this vector, and, in the vtkPythonArgs destructor, they would all be released (at the very end of the wrapping function). The only problem now is that not all functions use an instance of vtkPythonArgs (such as the ones implementing the sequence protocol), and an instance would be always required in this case. Do you have a suggestion? Thanks! Best regards, Edson ? On Tue, Mar 31, 2015 at 11:39 AM, David Gobbi wrote: > On Tue, Mar 31, 2015 at 7:51 AM, E. Tadeu wrote: > >> Hi! >> >> Why is there a static version for many methods in vtkPythonArgs >> (specially GetValue)? >> > > It allows those methods to be called without a vtkPythonArgs object ;) > > I see that they are being used only by Py*_SequenceSize. Is there a >> special reason? Could the static versions be removed, and Py*_SequenceSize >> generated code use an instance of vtkPythonArgs, just like all other >> generated functions? >> > > They're also called by the other methods that make up the python sequence > protocol, i.e. SequenceSetItem and Sequence(Get)Item. > > As for why these protocol methods call the static version of GetValue(), > it's because they have no need to create a vtkPythonArgs object. The main > purpose of the vtkPythonArgs object is to check the argument list, i.e. to > verify that the correct number of arguments has been passed, to keep track > of the current position in the argument list, etc. None of that is > necessary for python protocol methods like SequenceSize. All they need is > a simple way to convert a python object to a C++ object or vice-versa. The > static methods serve that purpose. > > If the python wrappers handled more python protocols, the static > GetValue() methods would be more widely used. > > Cheers, > > - David > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Mar 31 14:27:16 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 31 Mar 2015 12:27:16 -0600 Subject: [vtk-developers] Static methods in vtkPythonArgs In-Reply-To: References: Message-ID: What's going on with the font in your email?? Maybe it's just my browser, but it's HUGE! On Tue, Mar 31, 2015 at 12:22 PM, E. Tadeu wrote: > David, > > Perhaps you could help me with my first problem: I'm trying to patch > vtkWrapPython in order to fully support unicode arguments. Currently, > unicode python objects passed to VTK must be ascii-encodable (because of _PyUnicode_AsDefaultEncodedString(o, > NULL) being used in vtkPythonGetStringValue in vtkPythonArgs.cxx). I'm > trying to change it so that it will support any unicode string, encoding > them in UTF-8. This must be done in two steps: first, using a PyObject *s > = PyUnicode_AsUTF8String(o);, which will return a new reference to a > temporary PyStringObject, and then using PyString_AS_STRING on this > object, which will return a char * pointing to an internal buffer in s. > > The problem is that this temporary PyStringObject (s) must be deleted > by calling Py_XDECREF only after the call to the wrapped function. I > thought about adding an std::vector with these temporary > python strings to the vtkPythonArgs class; each new temporary would be > pushed to this vector, and, in the vtkPythonArgs destructor, they would > all be released (at the very end of the wrapping function). The only > problem now is that not all functions use an instance of vtkPythonArgs > (such as the ones implementing the sequence protocol), and an instance > would be always required in this case. > > Do you have a suggestion? > > Thanks! Best regards, > > Edson > > > On Tue, Mar 31, 2015 at 11:39 AM, David Gobbi > wrote: > >> On Tue, Mar 31, 2015 at 7:51 AM, E. Tadeu wrote: >> >>> Hi! >>> >>> Why is there a static version for many methods in vtkPythonArgs >>> (specially GetValue)? >>> >> >> It allows those methods to be called without a vtkPythonArgs object ;) >> >> I see that they are being used only by Py*_SequenceSize. Is there a >>> special reason? Could the static versions be removed, and Py*_SequenceSize >>> generated code use an instance of vtkPythonArgs, just like all other >>> generated functions? >>> >> >> They're also called by the other methods that make up the python sequence >> protocol, i.e. SequenceSetItem and Sequence(Get)Item. >> >> As for why these protocol methods call the static version of GetValue(), >> it's because they have no need to create a vtkPythonArgs object. The main >> purpose of the vtkPythonArgs object is to check the argument list, i.e. to >> verify that the correct number of arguments has been passed, to keep track >> of the current position in the argument list, etc. None of that is >> necessary for python protocol methods like SequenceSize. All they need is >> a simple way to convert a python object to a C++ object or vice-versa. The >> static methods serve that purpose. >> >> If the python wrappers handled more python protocols, the static >> GetValue() methods would be more widely used. >> >> Cheers, >> >> - David >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.tadeu at gmail.com Tue Mar 31 14:40:09 2015 From: e.tadeu at gmail.com (E. Tadeu) Date: Tue, 31 Mar 2015 15:40:09 -0300 Subject: [vtk-developers] Static methods in vtkPythonArgs In-Reply-To: References: Message-ID: Sorry about that, it's a plugin that renders Markdown in e-mail, and I configured the style sheet to use a slightly larger font (but it should not be HUGE :P). Anyway, here it is in plain old ascii :) David, Perhaps you could help me with my first problem: I?m trying to patch vtkWrapPython in order to fully support unicode arguments. Currently, unicode python objects passed to VTK must be ascii-encodable (because of _PyUnicode_AsDefaultEncodedString(o, NULL) being used in vtkPythonGetStringValue in vtkPythonArgs.cxx). I?m trying to change it so that it will support any unicode string, encoding them in UTF-8. This must be done in two steps: first, using a PyObject *s = PyUnicode_AsUTF8String(o);, which will return a new reference to a temporary PyStringObject, and then using PyString_AS_STRING on this object, which will return a char * pointing to an internal buffer in s. The problem is that this temporary PyStringObject (s) must be deleted by calling Py_XDECREF only after the call to the wrapped function. I thought about adding an std::vector with these temporary python strings to the vtkPythonArgs class; each new temporary would be pushed to this vector, and, in the vtkPythonArgs destructor, they would all be released (at the very end of the wrapping function). The only problem now is that not all functions use an instance of vtkPythonArgs (such as the ones implementing the sequence protocol), and an instance would be always required in this case. Do you have a suggestion? Thanks! Best regards, Edson On Tue, Mar 31, 2015 at 3:27 PM, David Gobbi wrote: > What's going on with the font in your email?? Maybe it's just my browser, > but it's HUGE! > > On Tue, Mar 31, 2015 at 12:22 PM, E. Tadeu wrote: > >> David, >> >> Perhaps you could help me with my first problem: I?m trying to patch >> vtkWrapPython in order to fully support unicode arguments. Currently, >> unicode python objects passed to VTK must be ascii-encodable (because of _PyUnicode_AsDefaultEncodedString(o, >> NULL) being used in vtkPythonGetStringValue in vtkPythonArgs.cxx). I?m >> trying to change it so that it will support any unicode string, encoding >> them in UTF-8. This must be done in two steps: first, using a PyObject >> *s = PyUnicode_AsUTF8String(o);, which will return a new reference to a >> temporary PyStringObject, and then using PyString_AS_STRING on this >> object, which will return a char * pointing to an internal buffer in s. >> >> The problem is that this temporary PyStringObject (s) must be deleted >> by calling Py_XDECREF only after the call to the wrapped function. I >> thought about adding an std::vector with these temporary >> python strings to the vtkPythonArgs class; each new temporary would be >> pushed to this vector, and, in the vtkPythonArgs destructor, they would >> all be released (at the very end of the wrapping function). The only >> problem now is that not all functions use an instance of vtkPythonArgs >> (such as the ones implementing the sequence protocol), and an instance >> would be always required in this case. >> >> Do you have a suggestion? >> >> Thanks! Best regards, >> >> Edson >> >> >> On Tue, Mar 31, 2015 at 11:39 AM, David Gobbi >> wrote: >> >>> On Tue, Mar 31, 2015 at 7:51 AM, E. Tadeu wrote: >>> >>>> Hi! >>>> >>>> Why is there a static version for many methods in vtkPythonArgs >>>> (specially GetValue)? >>>> >>> >>> It allows those methods to be called without a vtkPythonArgs object ;) >>> >>> I see that they are being used only by Py*_SequenceSize. Is there a >>>> special reason? Could the static versions be removed, and Py*_SequenceSize >>>> generated code use an instance of vtkPythonArgs, just like all other >>>> generated functions? >>>> >>> >>> They're also called by the other methods that make up the python >>> sequence protocol, i.e. SequenceSetItem and Sequence(Get)Item. >>> >>> As for why these protocol methods call the static version of GetValue(), >>> it's because they have no need to create a vtkPythonArgs object. The main >>> purpose of the vtkPythonArgs object is to check the argument list, i.e. to >>> verify that the correct number of arguments has been passed, to keep track >>> of the current position in the argument list, etc. None of that is >>> necessary for python protocol methods like SequenceSize. All they need is >>> a simple way to convert a python object to a C++ object or vice-versa. The >>> static methods serve that purpose. >>> >>> If the python wrappers handled more python protocols, the static >>> GetValue() methods would be more widely used. >>> >>> Cheers, >>> >>> - David >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Mar 31 15:30:09 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 31 Mar 2015 12:30:09 -0700 Subject: [vtk-developers] Wiki scrapping regression after web page update Message-ID: Folks, I scrape the vtk.org wiki site each evening to maintain the vtk wiki examples. I have a python program that uses mwclient (https://github.com/mwclient/mwclient) that uses the MediaWiki API. Ever since the vtk.org page was updated, my nightly scripts have been failing. The error are occur on this line: site = mwclient.Site('vtk.org', '/Wiki/') If I change vtk.org to itk.org, my scripts work. I suspect some sort of web magic going on. I can workaround the problem but specifying itk.org, but I'd like to understand what happened just in case the itk.org site changes in the future. Thanks, Bill From david.gobbi at gmail.com Tue Mar 31 15:37:16 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 31 Mar 2015 13:37:16 -0600 Subject: [vtk-developers] Static methods in vtkPythonArgs In-Reply-To: References: Message-ID: On Tue, Mar 31, 2015 at 12:40 PM, E. Tadeu wrote: > Sorry about that, it's a plugin that renders Markdown in e-mail, and I > configured the style sheet to use a slightly larger font (but it should not > be HUGE :P). > Twice as large as the default font. You're writing an email, not a book. I don't think that there is a policy that states whether VTK is supposed to prefer utf-8 over the current system encoding (this is a big problem on Windows where the default code page is never utf-8). So it would be worth bringing that up as a separate topic before the python wrappers are modified. A possible solution would be to store the resulting string in a std::string instead of using a "char *". This would require changing vtkWrapPython.c so that it created it's local string variables as "std::string" instead of "char *", and then used c_str() to get a "char *" to pass to VTK. This would be a bit wasteful if the original string was not a PyUnicode object, but then again, for Python 3 _all_ strings will be unicode. Either that, or another method can be added to vtkPythonArgs that returns not only the "char *", but also returns a python object that the wrapper code (i.e. code generated by vtkWrapPython) can decref. This is more efficient than the std::string solution mentioned above. I'm sure there must be a precedent somewhere in the current python wrappers, because conversion via a temporary isn't uncommon. But, no, storing the temporary objects in the vtkPythonArgs won't work for static methods, and I'm a fan of the static methods. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.tadeu at gmail.com Tue Mar 31 16:42:21 2015 From: e.tadeu at gmail.com (E. Tadeu) Date: Tue, 31 Mar 2015 17:42:21 -0300 Subject: [vtk-developers] Static methods in vtkPythonArgs In-Reply-To: References: Message-ID: David, Using std::string in the code generated by vtkWrapPython.c would work, but it would be a more complicated solution and also a bit wasteful as you said (I think that in Python 3 the temporary object would not be necessary anymore, since it provides the beautiful PyUnicode_AsUTF8AndSize). I was hoping for the removal of the static methods, since they are sparsely used and since the vtkPythonArgs instance creation does not seem to be something that would impact on performance. I will try another solution (probably changing the Python default encoding), thanks! On Tue, Mar 31, 2015 at 4:37 PM, David Gobbi wrote: > On Tue, Mar 31, 2015 at 12:40 PM, E. Tadeu wrote: > >> Sorry about that, it's a plugin that renders Markdown in e-mail, and I >> configured the style sheet to use a slightly larger font (but it should not >> be HUGE :P). >> > > Twice as large as the default font. You're writing an email, not a book. > > I don't think that there is a policy that states whether VTK is supposed > to prefer utf-8 over the current system encoding (this is a big problem on > Windows where the default code page is never utf-8). So it would be worth > bringing that up as a separate topic before the python wrappers are > modified. > > A possible solution would be to store the resulting string in a > std::string instead of using a "char *". This would require changing > vtkWrapPython.c so that it created it's local string variables as > "std::string" instead of "char *", and then used c_str() to get a "char *" > to pass to VTK. This would be a bit wasteful if the original string was not > a PyUnicode object, but then again, for Python 3 _all_ strings will be > unicode. > > Either that, or another method can be added to vtkPythonArgs that returns > not only the "char *", but also returns a python object that the wrapper > code (i.e. code generated by vtkWrapPython) can decref. This is more > efficient than the std::string solution mentioned above. I'm sure there > must be a precedent somewhere in the current python wrappers, because > conversion via a temporary isn't uncommon. > > But, no, storing the temporary objects in the vtkPythonArgs won't work for > static methods, and I'm a fan of the static methods. > > - David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Mar 31 17:43:54 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 31 Mar 2015 14:43:54 -0700 Subject: [vtk-developers] Merging a topic Message-ID: Do I need special permissions top merge a topic? I just tried Do: merge and do not see any results. Bill -- Unpaid intern in BillsBasement at noware dot com From bill.lorensen at gmail.com Tue Mar 31 18:16:56 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 31 Mar 2015 15:16:56 -0700 Subject: [vtk-developers] Workflow suggestion #1 Message-ID: I suggest that the title and description for a topic be the commit message and the commit description respectively. Otherwise, the commit message is at least another click away. Bill -- Unpaid intern in BillsBasement at noware dot com From ben.boeckel at kitware.com Tue Mar 31 18:42:28 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 31 Mar 2015 18:42:28 -0400 Subject: [vtk-developers] Merging a topic In-Reply-To: References: Message-ID: <20150331224228.GA26695@megas.kitwarein.com> There has been further discussion on the MR[1] in question here, but for the list: On Tue, Mar 31, 2015 at 14:43:54 -0700, Bill Lorensen wrote: > Do I need special permissions top merge a topic? I just tried Do: > merge and do not see any results. Sorry for this, the GitLab docs[2] missed that 'reopened' is a valid state for merge requests, so it is ignored because it isn't 'opened'. The robot will be restarted in the morning when Brad gets in; a comment should get kwrobot to look at the MR and merge it. This should also land tomorrow with support for 'do: ' which will warn but act as if 'Do: ' had been used. As for why buildbot ignored that MR's last update...not sure off hand. Might be something that was wrong when buildbot looked at it and has since been fixed? The logs have no mention of the relevant commit, so it seems that it was missed somehow :/ . --Ben [1]https://gitlab.kitware.com/vtk/vtk/merge_requests/6 [2]http://doc.gitlab.com/ce/api/merge_requests.html From ben.boeckel at kitware.com Tue Mar 31 18:47:15 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 31 Mar 2015 18:47:15 -0400 Subject: [vtk-developers] Workflow suggestion #1 In-Reply-To: References: Message-ID: <20150331224715.GB26695@megas.kitwarein.com> On Tue, Mar 31, 2015 at 15:16:56 -0700, Bill Lorensen wrote: > I suggest that the title and description for a topic be the commit > message and the commit description respectively. > > Otherwise, the commit message is at least another click away. Reviewing commit messages is one thing that could definitely be nicer with GitLab (and you can't comment on them either). Getting GitLab to do it for us would mean patching GitLab, but I might be able to take a quick look at it for single-commit branches at least (this is what GitHub does). Multi-commit branches will be trickier. One problem I see right off the bat though would be that the description doesn't get edited if the commit message is revised. I doubt that would be trivial to get right though :/ . --Ben From bill.lorensen at gmail.com Tue Mar 31 18:58:53 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 31 Mar 2015 15:58:53 -0700 Subject: [vtk-developers] Workflow suggestion #1 In-Reply-To: <20150331224715.GB26695@megas.kitwarein.com> References: <20150331224715.GB26695@megas.kitwarein.com> Message-ID: I'm suggesting that we recommend this. Not automating it. On Mar 31, 2015 3:47 PM, "Ben Boeckel" wrote: > On Tue, Mar 31, 2015 at 15:16:56 -0700, Bill Lorensen wrote: > > I suggest that the title and description for a topic be the commit > > message and the commit description respectively. > > > > Otherwise, the commit message is at least another click away. > > Reviewing commit messages is one thing that could definitely be nicer > with GitLab (and you can't comment on them either). Getting GitLab to do > it for us would mean patching GitLab, but I might be able to take a > quick look at it for single-commit branches at least (this is what > GitHub does). Multi-commit branches will be trickier. > > One problem I see right off the bat though would be that the description > doesn't get edited if the commit message is revised. I doubt that would > be trivial to get right though :/ . > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deevankshu096 at gmail.com Thu Mar 19 19:33:03 2015 From: deevankshu096 at gmail.com (DEEVANKSHU GARG) Date: Thu, 19 Mar 2015 23:33:03 -0000 Subject: [vtk-developers] GSoC 2015-CAD Model and Simulation Spline Visualization In-Reply-To: <6BD334A2-5477-42A1-B500-6F2B4827A511@kitware.com> References: <6BD334A2-5477-42A1-B500-6F2B4827A511@kitware.com> Message-ID: Hello again! Thanks for your reply. It cleared in my mind the path to be followed for the isogeometric analysis i.e. through B?zier extraction.So I went through a lot of its theory part as well as the implementation part and scribbled down roughly everything required and the expected outputs and came up with a flow chart present in the attachment. Pre-processing part- Since the basis functions of isogeometric analysis are related to control points, and not nodes as shape functions of FEA, the input of node coordinates is replaced by coordinates of control points.The element topology is therefore related to the numbering of control points rather than the numbering of element nodes.The isogeometric analysis program based on B?zier extraction will require an extra input, namely the B?zier extraction operators.A question -> are the "readers" mentioned in the project statement related to this part?About reading the data from CAD files?Can you throw some more light on readers? Solving part- This will mainly contain a shape function routine which generates NURBS basis functions and derivatives in the isogeometric analysis program based on B?zier extraction.I am attaching a flow chart for this also.To form NURBS basis functions based on B?zier extraction using this shape function routine, ?rst the NURBS weights and the element extraction operators from the preprocessing step are called in.The B?zier basis functions and derivatives are calculated in a separate routine, and are also called into the shape function routine. Post-processing part- As you replied to the rendering question in the previous mail,I re-thought about it and did some further research.So,basically it would include- finding the range of values taken on over a mesh and the location of the extremal values,computing derivative values and inspecting them,dividing the mesh into regions based on scalar values or spatial cuts to make inspection of the quantities defined on the mesh (e.g., stress, strain, temperature) possible.It will write displacements and reactions at the control points,in contrast to FEA which writes these quantities at the nodes. In addition, the program plots NURBS control mesh, B?zier control mesh and B?zier physical mesh. The displacement ?eld is evaluated at the parametric coordinates which equal the nodes of FEA (for the same polynomial order), and plotted in the physical space.A modi?cation is made to the storing of stress values to be able to plot contour plots of the stresses.The stresses are stored re?ecting the Gauss points? alignment relative to each other in the parameter space. Also,I have been able to set-up VTK on my system.Can you please tell me which part of the code base I should mainly focus on.One more thing,I haven't been able to completely get through the cutting part.A piece of advice on this would be really very helpful. Also , what kind of details are you expecting in the proposal ? Do you want it to be mildly broad , or do you want it to be targeted as a needle ? Could you shed some light on it ? A quick response will be really helpful ! Regards, Deevankshu Garg (https://github.com/gargd) On Wed, Mar 18, 2015 at 9:39 PM, David Thompson wrote: > Hi Deevankshu, > > > The project "CAD Model and Simulation Spline Visualization" is of > particular interest to me.Curves and NURBS Modelling has been a project of > mine at a personal level(https://github.com/gargd/Here-I-come-NURBS & > https://github.com/gargd/Bezier-curves-and-surfaces). > > Those are nice examples, but they use the OpenGL GLU toolkit to evaluate > the spline. Just to be clear, we are interested in adding implementations > of evaluation and inversion to VTK, not using GLU to perform those > operations. > > > ... About the project,there are some points I want to discuss and some > questions I want to ask. ... Besides its obvious advantages of being easily > integrated with CAD and the high level of solution accuracy, we also have > the advantage of not having to write the whole code from scratch and > reusing the earlier present FEM code. > > Using a FEM solver's evaluation and interpolation methods is one way to > go, but the issues involved are > > 1. Many isogeometric analysis (IGA) codes use slightly different spline or > patch formulations. We want to accommodate them all, not just a few. > > 2. I do not know of open source IGA implementations which cover the gamut > of interpolation techniques whose source we could borrow. > > That is why we are aiming to provide operations on basic rational B?zier > patches. The B?zier patch operations would not access control point arrays > directly but use iterators so that different IGA formulations could provide > B?zier patch iterators to access their underlying meshes. > > > I have thought of a rough idea about implementing the project- > > > > 1.A new mesh representation class- > > This would include- > > a. h-refinement(knot insertion) for one and two dimensional meshes. > > b. p-refinement(order elevation) and k-refinement using Geopdes library. > > Unfortunately, the GeoPDEs library is licensed under the GPL. VTK cannot > include GPL code without changing its license. > > > c.Extended IGA for hole,inclusion and crack modelling using variational > formulas. > > This is interesting, but the first job is to implement basic evaluation > and inversion methods along with cutting and clipping. > > > d.Bezier extraction-to integrate isogeometric analysis with existing FEM > codes. > > This is the route we are hoping to take. > > > e.Visualization of displacements and stresses. > > > > 2.Contouring- > > This would basically include creating new classes like the following > ones- > > a.crackedMesh: visualize cracked mesh as truly cracked domain. > > b.crackedMeshNURBS: the same but for higher order NURBS. > > c.plotStress: compute displacements and stresses at nodes of a > visualization mesh. > > The way the VTK framework is written, these would not be individual > classes but different combinations of classes into pipelines. > > > 3.Cutting- > > a.elements cut by cracks:sub-triangulation > > b.elements cut by circular holes/inclusions:adaptive sub-cells. > > We do not care so much about what shape the cut is, but rather how the cut > is computationally represented; is it an implicit function? a spline in > world coordinates or parameter space? a simple plane? By providing some > basic functionality, the cases above (plus others) can be handled with a > small effort. > > > Things I want to ask- > > a.You mentioned about conversion to handle the variety of spline formats > (T-Splines, NURBS, Catmull-Clark surfaces, etc.).Would an object oriented > design be more beneficial ... > > Yes. I think the first step would be to provide a base class that allows > iteration over a set of B?zier patches that, taken together, represent the > spline curve, surface, or volume. > > > ... with the B-splines sitting at the top of the heirarchy? > > A B-spline formulation could be at the top of *one* hierarchy, but it > would have siblings for other formats like T-splines. > > > b.IGA techniques are mainly for analysis and meshing,what does it have > to do with rendering. > > Rendering is only part of visualization. It is important to provide > analysis tools for post-processing to > > - find the range of values taken on over a mesh and the location of the > extremal values. > - compute derivative values and inspect them > - divide the mesh into regions based on scalar values or spatial cuts to > make inspection of the quantities defined on the mesh (e.g., stress, > strain, temperature) possible. > > > Shouldn't the rendering techniques remain the same? > > I am unsure what you mean by this? The same as what? > > > We can obviously optimise rendering,but it wouldn't be a part of > IGA,right? > > Rendering would involve evaluating patches provided by an IGA mesh at > regular locations and connecting the evaluated points into a simplicial > mesh (line segments in 1-D, triangles in 2-D, tetrahedra in 3-D) for either > rendering or further post-processing. One example of post-processing is > deflecting the evaluated points using the strain field computed by IGA. > > > ... > > Thanks a lot for reading! > > I look forward to reading your proposal when you submit it to GSoC. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Flow Chart for IGA based on Bezier Extraction.jpg Type: image/jpeg Size: 218400 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Flow chart for Shape Function routine.jpg Type: image/jpeg Size: 200115 bytes Desc: not available URL: From bill.lorensen at gmail.com Mon Mar 2 15:36:00 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 02 Mar 2015 20:36:00 -0000 Subject: [vtk-developers] Renderman Announces new pricing policy In-Reply-To: References: Message-ID: Dave, I was able to create this image dented.tif which very similar to an image I created years ago: http://web.archive.org/web/19970630025047/http://www.crd.ge.com/~lorensen/vtkrib/ I had to hand edit the .rib file. I need to update the RIB exporter. Don't waste time on this until I fix the RIB exporter and property. It is encouraging since that example uses a shader that I wrote. I also attached the c++ code that almost produced a good rib file. Bill On Mon, Mar 2, 2015 at 11:40 AM, David E DeMarle wrote: > I'll let you know when I get past the black screen rendered with VTK > cells.py's cells.rib file. > > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Mon, Mar 2, 2015 at 11:34 AM, Bill Lorensen > wrote: >> >> I'll take a look. >> >> Thanks, >> >> Bill >> >> >> On Mon, Mar 2, 2015 at 11:30 AM, David E DeMarle >> wrote: >> > There is also the pixie project, a high quality rendering engine that >> > accepts RIB input. >> > http://www.renderpixie.com >> > seems to compile and run easily enough. >> > >> > >> > >> > >> > >> > David E DeMarle >> > Kitware, Inc. >> > R&D Engineer >> > 21 Corporate Drive >> > Clifton Park, NY 12065-8662 >> > Phone: 518-881-4909 >> > >> > On Fri, May 30, 2014 at 5:08 PM, Bill Lorensen >> > wrote: >> >> >> >> Folks, >> >> >> >> Mike Halle referred me to this article regarding RenderMan: >> >> http://renderman.pixar.com/view/non-commercial >> >> >> >> Many years ago, I wrote the vtkRIBExporter that produces RenderMan >> >> files. At that time, there was a free package BMRT that accepted >> >> RenderMan files and created high quality renderings from VTK models. >> >> In fact, almost all of the images in the VTK book centerfold plates >> >> were produced using vtkRIBExporter and BMRT. >> >> >> >> The new free license has commercial restrictions, but they seem >> >> lenient unless you want to sell your animations. >> >> >> >> I've requested a free license. I'll keep the group informed... >> >> >> >> Bill >> >> _______________________________________________ >> >> Powered by www.kitware.com >> >> >> >> Visit other Kitware open-source projects at >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> http://www.vtk.org/mailman/listinfo/vtk-developers >> >> >> > >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com > > -- Unpaid intern in BillsBasement at noware dot com -------------- next part -------------- A non-text attachment was scrubbed... Name: dented.tif Type: image/tiff Size: 228058 bytes Desc: not available URL: From luis.vieira at vektore.com Tue Mar 17 12:56:10 2015 From: luis.vieira at vektore.com (Luis Vieira) Date: Tue, 17 Mar 2015 16:56:10 -0000 Subject: [vtk-developers] Vtk Contouring Area In-Reply-To: <55070A0E.7000206@vektore.com> References: <55070A0E.7000206@vektore.com> Message-ID: <55085C99.1080705@vektore.com> Hello everyone, Actually, I have the following challenge as well as I am a beginner with Vtk. I need to develop a routine to do contouring of geology points on a stereo surface and I have been struggling to use the best component of VTK framework. I have been trying to create a map/area from the structure (clip of sphere and plane) and plot geology points and rendering. Then I have to recreate the map/area specifically by the set of geology points as you guys can see the options bellow: 1- vtkContourFilter , vtkStripper and vtkLookupTable (I got isolables and isosurface of the whole points of the structure not of the specifically set of geology points); or 2- vtkMarchingCubes with vtkCylinder ; or 3- vtkContourWidget with vtkOrientedGlyphContourRepresentation; I really appreciate if you guys could help me. My goals: Those are my unsuccessful results: Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 28609 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 64199 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 192267 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 296930 bytes Desc: not available URL: From bill.lorensen at gmail.com Tue Mar 24 10:24:32 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 24 Mar 2015 14:24:32 -0000 Subject: [vtk-developers] Renderman Announces new pricing policy In-Reply-To: References: Message-ID: Generated my first exported RIB file with the free renderman. Hopefully I have the updated RIBExporter ready soon. Bill On Tue, Mar 24, 2015 at 3:49 AM, Will Schroeder wrote: > Some interesting articles related to RenderMan: > > Pixar?s RenderMan Software To Be Free For Non-Commercial Users > > RenderMan Community Site > (It looks like some useful resources, etc. although the site was really slow > when I visited). > > W > > > On Mon, Mar 23, 2015 at 5:40 PM, Bill Lorensen > wrote: >> >> I trying to download it now. Also, I'm working on updating the RIB >> exporter, property and light to work with modern render man. >> >> Keep you posted. >> >> >> On Mon, Mar 23, 2015 at 2:34 PM, Goodwin Lawlor >> wrote: >> > Renderman free non-commercial version is released! >> > >> > http://rendermansite.pixar.com/view/get-renderman >> > >> > _______________________________________________ >> > Powered by www.kitware.com >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Search the list archives at: >> > http://markmail.org/search/?q=vtk-developers >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> > >> > >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > > > > -- > William J. Schroeder, PhD > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 -- Unpaid intern in BillsBasement at noware dot com -------------- next part -------------- A non-text attachment was scrubbed... Name: dented.tif Type: image/tiff Size: 330567 bytes Desc: not available URL: