CMake

CTest and CDash now support the new suite of "sanitizer" dynamic analysis tools that are available for gcc and clang!  Support for these tools will be included in the upcoming release of CMake 3.1.  They can be found in the first release ... [More] candidate CMake 3.1-rc1, or you can checkout CMake master from git and build it from source. These new features were added as part of the Google Project Tango effort to create mobile 3D scanning devices.  The sanitizer tools allow for low overhead run time error checking similar to what you can find in valgrind. However, instead of running a machine code level simulator to detect the errors, the compiler based sanitizers add extra error checks that are compiled into the code. This provides better performance. There is one price that is paid for that performance gain. Once the first error is detected, the program halts.  This blog will provide examples of how to use CTest and CDash to run sanitized test programs and collect and display the results. In order to make it easier for you to replicate the examples below, all of the sample code is available as an attachment to this blog post. Use of the sanitizer tools requires building your code with extra compile flags that inject the error checking into the final executable. There are several ways to do that. You can set CMAKE_C_FLAGS and CMAKE_CXX_FLAGS on the command line of cmake or by preloading the cache with values in a ctest script.   ThreadSanitizer ThreadSanitizer (TSan) allows us to detect data races in our programs.   Example code Here's a simple example of a program with a data race: #include <pthread.h> #include <stdio.h> int Global; void *Thread1(void *x) { Global++; return NULL; } void *Thread2(void *x) { Global--; return NULL; } int main() { pthread_t t[2]; pthread_create(&t[0], NULL, Thread1, NULL); pthread_create(&t[1], NULL, Thread2, NULL); pthread_join(t[0], NULL); pthread_join(t[1], NULL); }   Building with TSan All we need to do to test this program with ThreadSanitizer is add some flags to the C and CXX flags used to build the project. The flags required are: -g -O1 -fsanitize=thread -fno-omit-frame-pointer -fPIC   Example Output After we build this executable and run it, we see the following output from TSan: ================== WARNING: ThreadSanitizer: data race (pid=5618) Write of size 4 at 0x7f47f6025c3c by thread T2: #0 Thread2(void*) simple_race.cc:12 (simple_race+0x0000000a8883) Previous write of size 4 at 0x7f47f6025c3c by thread T1: #0 Thread1(void*) simple_race.cc:7 (simple_race+0x0000000a8843) Location is global 'Global' of size 4 at 0x7f47f6025c3c (simple_race+0x0000016f0c3c) Thread T2 (tid=5622, running) created by main thread at: #0 pthread_create <null>:0 (simple_race+0x00000004de4b) #1 main simple_race.cc:19 (simple_race+0x0000000a88e1) Thread T1 (tid=5621, finished) created by main thread at: #0 pthread_create <null>:0 (simple_race+0x00000004de4b) #1 main simple_race.cc:18 (simple_race+0x0000000a88ca) SUMMARY: ThreadSanitizer: data race simple_race.cc:12 Thread2(void*) ================== ThreadSanitizer: reported 1 warnings   Submitting to CDash Here's a CTest script that you can use to run this example and submit the results to CDash's public dashboard. set(CTEST_PROJECT_NAME "tsan_example") set(CTEST_SITE "localhost") set(CTEST_BUILD_NAME "ThreadSanitizer") set(CTEST_SOURCE_DIRECTORY "${CTEST_SCRIPT_DIRECTORY}") set(CTEST_BINARY_DIRECTORY "${CTEST_SCRIPT_DIRECTORY}/bin") set(CTEST_CMAKE_GENERATOR "Unix Makefiles") set(CTEST_MEMORYCHECK_TYPE "ThreadSanitizer") ctest_start(Experimental) file(WRITE "${CTEST_SCRIPT_DIRECTORY}/bin/CMakeCache.txt" " CMAKE_CXX_FLAGS=-g -O1 -fsanitize=thread -fno-omit-frame-pointer -fPIC ") ctest_configure() ctest_build() ctest_test() ctest_memcheck() set(CTEST_DROP_METHOD "http") set(CTEST_DROP_SITE "open.cdash.org") set(CTEST_DROP_LOCATION "/submit.php?project=PublicDashboard") ctest_submit() Other than the compile flags mentioned earlier, of particular note here is the line set(CTEST_MEMORYCHECK_TYPE "ThreadSanitizer") This is what tells CTest how to intrepret the output of the dynamic analysis (memcheck) step. After you've submitted your results to CDash, you should see a new row in the Dynamic Analysis section of the page.  Here's an example of what this will look like: When you click on the "1" (under Defect Count) you'll be taken to a page displaying the following information: From here, if you click on the name of the test (simple_race) you will see the output of the sanitizer tool.   AddressSanitizer AddressSanitizer (asan) allows us to detect buffer overflows and cases where memory is read after being freed.   Example code Here's an example C program that attempts to read some memory after freeing it: #include <stdlib.h> int main() { char *x = (char*)malloc(10 * sizeof(char*)); free(x); return x[5]; }   Building with ASan Similarly to the TSan example, we enable ASan dynamic analysis by modifying the flags that we use to compile our program: -DCMAKE_C_FLAGS="-g -O1 -fsanitize=address -fno-omit-frame-pointer"   Example output Here is an example of the output you should expect when ASan detects a defect in your program: ================================================================= ==6140==ERROR: AddressSanitizer: heap-use-after-free on address 0x60700000dfb5 at pc 0x4820cb bp 0x7fffa1ac1130 sp 0x7fffa1ac1128 READ of size 1 at 0x60700000dfb5 thread T0 #0 0x4820ca in main use-after-free.c:5 #1 0x7fb5d55b776c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226 #2 0x481f9c in _start (bin/use-after-free+0x481f9c) 0x60700000dfb5 is located 5 bytes inside of 80-byte region [0x60700000dfb0,0x60700000e000) freed by thread T0 here: #0 0x46bd39 in free (bin/use-after-free+0x46bd39) #1 0x48209a in main use-after-free.c:4 #2 0x7fb5d55b776c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226 previously allocated by thread T0 here: #0 0x46beb9 in __interceptor_malloc (bin/use-after-free+0x46beb9) #1 0x48208f in main use-after-free.c:3 #2 0x7fb5d55b776c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226 SUMMARY: AddressSanitizer: heap-use-after-free use-after-free.c:5 main   Submitting to CDash To submit these results to CDash, you can use a script very similar to the one above in the TSan example.  The only important difference is that instead of: set(CTEST_MEMORYCHECK_TYPE "ThreadSanitizer") you should specify: set(CTEST_MEMORYCHECK_TYPE "AddressSanitizer") and the cache should will be: file(WRITE "${CTEST_SCRIPT_DIRECTORY}/bin/CMakeCache.txt" " CMAKE_C_FLAGS=-g -O1 -fsanitize=address -fno-omit-frame-pointer ") Here are a couple views of these results from CDash:   MemorySanitizer MemorySanitizer (msan) allows us to detect reads of uninitialized memory.   Example code In this example, our program reads from memory before it has been initialized: #include <stdio.h> int main(int argc, char** argv) { int* a = new int[10]; a[5] = 0; if (a[argc]) printf("xx\n"); return 0; }   Building with ASan As before, we simply need to modify the compile flags for the executable that we wish to test.  In this case, we specify -fsanitize=memory instead of =thread or =address. -DCMAKE_CXX_FLAGS="-g -O1 -fsanitize=memory -fno-omit-frame-pointer"   Example output Here is the output you should expect if you run the example above through MSan: ==6805== WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x7ff16024fcb6 in main umr.cc:6 #1 0x7ff15edd276c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226 #2 0x7ff16024fadc in _start (bin/umr+0x7badc) SUMMARY: MemorySanitizer: use-of-uninitialized-value umr.cc:6 main   Submitting to CDash You can follow the pattern outlined above for TSan.  The important change is to specify set(CTEST_MEMORYCHECK_TYPE "MemorySanitizer") instead of: set(CTEST_MEMORYCHECK_TYPE "ThreadSanitizer") and the cache should have: file(WRITE "${CTEST_SCRIPT_DIRECTORY}/bin/CMakeCache.txt" " CMAKE_CXX_FLAGS=-g -O1 -fsanitize=memory -fno-omit-frame-pointer ")   Finally, here's what these results look like on CDash:   That's all there is to it!  I hope that you found these examples useful.  With the use of these new tools, you can be more confident that there aren't any nasty memory defects lurking in your codebase.  If you have any questions or comments about these new features of CTest & CDash, please contact us on the CMake users mailing list. [Less]

Visual Analytics, or the use of informatics and graphical techniques to allow for guided exploration of complex data, is a powerful component of big data exploitation. In this vein, the Software Processes group is exploring the limits of Visual ... [More] Analytics in multiple domains including in categorizations of the VA VistA EHR and in the exploration of relationships between multiple sources of data -- patient demographics, symptoms, case histories and medical image derived features -- in predicting individual patient health trajectories.  There is no question that Jason Li's work on VIVIANTM (Visualizing VistA And Namespace) for the OSHERA project has been met with great excitement from the VistA development community.  The VIVIANTM tools provide insight into the structure and interactions of the 40 year old, >26,000 file VA legacy Electronic Health Record (EHR) code. Developed for internal use by OSEHRA in managing the VA open source repository, the VIVIANTM suite has proven even more popular with the development community providing them with resources that had been missing since the inception of VistA. Below are a few examples of the visualizations that Jason has been working on. The first is a hierarchical view of VistA packages organized by application area. Interactions allow the tree to be expanded or collapsed. Clicking on a file brings up additonal information derived directly from the source code or code repository and allowing for the self-documentation of an extremely complicated codebase. The second illustration is an interaction diagram showing the package to package relationships. As the user hovers over a specific package, calls into the package are highlighted by a red arc and calls out of the package are highlighted by green arcs. The pattern of interactions and the illustrated call graph provide insight into the interconnectivity patterns that cannot be obtained by simply looking a flat textual representations. Again, clicking on a package will bring you to more detailed information and specifications. Trying to understand the intricacies of a large legacy system is not an easy task. Wading through thousands (literally, in this case) of files to attempt to figure out if this code change will break something downstream is tedious and error-prone.  Using these tools, developers are able to quickly and easily understand the relationship between sections of the large and complicated code base. But VIVIANTM is only the beginning. When beginning to prepare for the NIH NCMS P41: National Center for Multi Systems demo, we faced the challenge of finding connections between large sets of patient and medical imaging derived data. In particular, we needed to demonstrate a unique way for researchers to look at the data and see possible connections with fresh eyes.  Knowing that Jason's work not only looked interesting but was proving to provide real insight, we asked the question "Would it be possible to re-use the powerful graphics he had already developed?" The answer, of course, is yes.  Working with our collaborators, such as noted researcher Hugo Aerts, PhD, Assistant Professor of Radiation Oncology Harvard Medical School and of Brigham and Women's Hospital Dana Farber Cancer Institute; we were able to generate some demo data representing imaging and nonimaging disease presentations. Not only was the edge bundling visualization adapted for the demonstration but it was also placed into the Tangelo-Hub (Arbor) framework for general use. Continuing to explore other Visual Analytics solutions, we next turned to a matrix of scatterplots.  At the start, viewers are presented with a high-level, birds-eye view.  Are there any patterns? Much like the edge bundling graph, positive and negative correlations can easily be seen. While selecting specific blocks make it possible to drill down and look at those graphs that might be interesting in more detail. Finally, we developed an interactive heatmap.  The interesting aspect of this visualization is the ability to sort data by rows and columns. By shuffling data, new patterns emerge.  We believe that we have only begun to explore the landscape of data representation. What other applications could these simple yet powerful visualizations be applied to?        [Less]

In a recent article, Ben Balter discusses "9 things to look for in an open-source project." According to the article, "If you're going to rely on a community-contributed open-source project, you'll want to ensure the code is up to your standards and ... [More] that the community will continue to support it throughout the project's life cycle." Below is a summary of the article's "9 things to look for" and an overview of some of Kitware's most popular open-source projects, including ParaView, CMake, VTK, and ITK. 1. Update frequency. "The most commonly cited metric is: When was it last updated?" For some of the projects to which Kitware contributes, the most recent releases are: ITK 4.6.1 was released on October 1, 2014. ITK began in 1999 with a three-year contract from the U.S. National Library of Medicine of the National Institutes of Health to develop an open-source registration and segmentation toolkit. CMake 3.0.2 was released on September 11, 2014. The initial CMake implementation was mid-2000. ParaView 4.2.0 was released on September 29, 2014. The ParaView project started in 2000 as a collaborative effort between Kitware and Los Alamos National Laboratory. VTK 4.6.1 was released in January. VTK was originally written as part of a textbook, The Visualization Toolkit An Object-Oriented Approach to 3D Graphics, by Will Schroeder, Ken Martin, and Bill Lorensen. The book was written beginning in December 1993. 2. Issues. "Issues and bug reports are good things -- really." Like all of the projects Kitware develops, ParaView, CMake, VTK, and ITK have bug trackers that are actively monitored. This helps the development team ensure that issues are addressed and fixed quickly. To address issues in VTK, for example, we hosted a hackathon earlier in October. For details on the hackathon, please read this previously posted blog entry. 3. Forks, stars and downloads. "Each distribution platform provides its own metrics to describe popularity...Those indicators show how much the project is used, but be careful not to confuse adoption with quality." So far in October, VTK has over 5,000 total downloads, ParaView has over 1,200 total downloads, and CMake has over total 76,900 downloads. 4. Documentation. "How is the project documented?" Kitware's open-source projects have many documentation resources available, including Mastering CMake and The ITK Software Guide. Documentation for the four open-source projects is updated often. For example, ParaView's documentation is automatically generated on a nightly basis. The documentation contains extensive descriptions regarding inheritance, methods, object collaboration, etc., that are particularly useful for developers working with the projects. VTK's Doxygen-generated manuals are also updated nightly. 5. Organization or user. "Who's behind the project?" Many of the open-source projects to which Kitware contributes are the result of extended collaboration. Kitware has collaborated with organizations including Los Alamos National Laboratory, National Library of Medicine, National Alliance for Medical Computing, Department of Energy, Sandia National Laboratories, and Army Research Laboratory, UNC Chapel Hill, University of Utah, University of Pennsylvania, GE Corporate R&D, and Insightful, among others, for open-source projects such as ITK, ParaView, VTK, and CMake. 6. Number of contributors "Is the project a solo act or a team effort?" Many of the open-source projects to which Kitware contributes are surrounded by active communities. For example, ParaView has had over 160 contributors, VTK has had over 250 contributors, CMake has had 330 contributors, and ITK has had over 260 contributors. 7. Who else uses it? "...if none of your peers is using the project (or worse, have not even heard of it), that could be a major red flag. Many companies proudly showcase their open-source projects." Many organizations are using the projects to which Kitware contributes. For example, Netflix, INRIA, Canonical, biicode, and the Wolfram Language use CMake. In addition, over the summer, Microsoft announced Windows support for CMake. Meanwhile, Sandia National Laboratories, Los Alamos National Laboratory, Army Research Laboratory, and CSimSoft are among ParaView's contributors. 8. License. "Does it contain a license file or just a reference to a license in the readme.txt file? Do files contain the proper headings where required? The strictness with which the software is licensed and the type of license used can indicate how familiar the publisher is with open source and how serious he or she is about providing you with unburdened intellectual property. Most important, make sure the license is compatible with your project and goals." Many of Kitware's open-source projects are distributed under a BSD or an Apache license. For example, ParaView uses a permissive BSD license that enables the broadest possible audience, including commercial organizations, to use the software, royalty free, for most purposes. CMake is also distributed under a BSD 3-clause License, and ITK is distributed as open source under an OSI-approved license. Starting with ITK 4.0, the Apache 2.0 license is used. In addition, VTK is distributed under a BSD license. 9. The code itself. "Did the developer follow the language's common conventions and design patterns? Did he or she use a framework or build everything from scratch? Did he or she use a package manager?" According to Open HUB, CMake, ParaView, VTK, and ITK have mature and well-established codebases. For descriptions of each codebase, please visit their respective websites. [Less]

In a recent article, Ben Balter discusses "9 things to look for in an open-source project." According to the article, "If you're going to rely on a community-contributed open-source project, you'll want to ensure the code is up to your standards and ... [More] that the community will continue to support it throughout the project's life cycle." Below is a summary of the article's "9 things to look for" and an overview of some of Kitware's most popular open-source projects, including ParaView, CMake, VTK, and ITK. 1. Update frequency. "The most commonly cited metric is: When was it last updated?" For some of the projects to which Kitware contributes, the most recent releases are: ITK 4.6.1 was released on October 1, 2014. ITK began in 1999 with a three-year contract from the U.S. National Library of Medicine of the National Institutes of Health to develop an open-source registration and segmentation toolkit. CMake 3.0.2 was released on September 11, 2014. The initial CMake implementation was mid-2000. ParaView 4.2.0 was released on September 29, 2014. The ParaView project started in 2000 as a collaborative effort between Kitware and Los Alamos National Laboratory. VTK 6.1.0 was released in January. VTK was originally written as part of a textbook, The Visualization Toolkit An Object-Oriented Approach to 3D Graphics, by Will Schroeder, Ken Martin, and Bill Lorensen. The book was written beginning in December 1993. 2. Issues. "Issues and bug reports are good things -- really." Like all of the projects Kitware develops, ParaView, CMake, VTK, and ITK have bug trackers that are actively monitored. This helps the development team ensure that issues are addressed and fixed quickly. To address issues in VTK, for example, we hosted a hackathon earlier in October. For details on the hackathon, please read this previously posted blog entry. 3. Forks, stars and downloads. "Each distribution platform provides its own metrics to describe popularity...Those indicators show how much the project is used, but be careful not to confuse adoption with quality." So far in October, VTK has over 5,000 total downloads, ParaView has over 1,200 total downloads, and CMake has over total 76,900 downloads. 4. Documentation. "How is the project documented?" Kitware's open-source projects have many documentation resources available, including Mastering CMake and The ITK Software Guide. Documentation for the four open-source projects is updated often. For example, ParaView's documentation is automatically generated on a nightly basis. The documentation contains extensive descriptions regarding inheritance, methods, object collaboration, etc., that are particularly useful for developers working with the projects. VTK's Doxygen-generated manuals are also updated nightly. 5. Organization or user. "Who's behind the project?" Many of the open-source projects to which Kitware contributes are the result of extended collaboration. Kitware has collaborated with organizations including Los Alamos National Laboratory, National Library of Medicine, National Alliance for Medical Computing, Department of Energy, Sandia National Laboratories, and Army Research Laboratory, UNC Chapel Hill, University of Utah, University of Pennsylvania, GE Corporate R&D, and Insightful, among others, for open-source projects such as ITK, ParaView, VTK, and CMake. 6. Number of contributors "Is the project a solo act or a team effort?" Many of the open-source projects to which Kitware contributes are surrounded by active communities. For example, ParaView has had over 160 contributors, VTK has had over 250 contributors, CMake has had 330 contributors, and ITK has had over 260 contributors. 7. Who else uses it? "...if none of your peers is using the project (or worse, have not even heard of it), that could be a major red flag. Many companies proudly showcase their open-source projects." Many organizations are using the projects to which Kitware contributes. For example, Netflix, INRIA, Canonical, biicode, and the Wolfram Language use CMake. In addition, over the summer, Microsoft announced Windows support for CMake. Meanwhile, Sandia National Laboratories, Los Alamos National Laboratory, Army Research Laboratory, and CSimSoft are among ParaView's contributors. 8. License. "Does it contain a license file or just a reference to a license in the readme.txt file? Do files contain the proper headings where required? The strictness with which the software is licensed and the type of license used can indicate how familiar the publisher is with open source and how serious he or she is about providing you with unburdened intellectual property. Most important, make sure the license is compatible with your project and goals." Many of Kitware's open-source projects are distributed under a BSD or an Apache license. For example, ParaView uses a permissive BSD license that enables the broadest possible audience, including commercial organizations, to use the software, royalty free, for most purposes. CMake is also distributed under a BSD 3-clause License, and ITK is distributed as open source under an OSI-approved license. Starting with ITK 4.0, the Apache 2.0 license is used. In addition, VTK is distributed under a BSD license. 9. The code itself. "Did the developer follow the language's common conventions and design patterns? Did he or she use a framework or build everything from scratch? Did he or she use a package manager?" According to Open HUB, CMake, ParaView, VTK, and ITK have mature and well-established codebases. For descriptions of each codebase, please visit their respective websites. [Less]

Last week, Luis Ibáñez from Google spoke to a group of Kitwareans and MBA students on the economic aspects of open source. According to Luis, software is an "incarnation of business logic and processes." In today's technological environment, software ... [More] is becoming increasingly important. As Luis pointed out, 20% of the cost of a car is software. So, why not take advantage of the benefits of open-source? Below are the main points from Luis' discussion. In regards to companies using open source Break away from proprietary constraints. One economic advantage of open-source software is that it provides flexibility and freedom that proprietary software does not. For example, with open source, downstream distribution of your software is free. Furthermore, making copies of your software is free. This is due, in part, to the notion that software is now being increasingly used as a platform to provide a service, rather than as an end in itself. Thus, open source enables you to better tailor your software to fit your company's needs and enables you to focus more on providing a service. In addition, using or reproducing open-source software does not lessen the value of the original project. Make open source an advantage for your business model. In order to make open source an advantage for your business model, it is important that you cultivate a team with software skills and knowledge of the open-source application you're using and its development process. Simply leveraging an open-source project without skilled team members leaves you vulnerable. On the other hand, if you have a team of peole involved in an open-source project, it means that you can share knowledge and will not find yourself in a situation where somenone leaving or changing roles creates a vacuum. Such situations occur when your team members do not know your organization's system. As a result, they have to spend time figuring it out, which is an added expense. Grow the contributing community. Open source projects rely on contributions from developers, who may or may not be sponsored (i.e., paid) for their work on a specific project. These contributions are critical to the success and longevity of an open-source project. For companies that are leveraging open-source projects, it's well worth the investment to contribute back to the community and project, whether that's through hiring developers to focus on that project as part of your team, sponsoring hackathons or other events, or contributing to recruiting new memebers to join the community. In any situation with experienced individuals (think of your own team and when new individuals join), there is always a balance between having the people who are already familiar with the work simply do the work and having those people spend their time on-boarding new community members and getting them to a place to be able to contribute. To build a thriving open source community, focusing resources on recruiting new members and making it clear and easy how people can get involved is important. In regards to open-source projects Maintenance is everything in the software environment, and maintenance is supported by the community. Developers know that it is important that you maintain software. For open-source projects, this requires a healthy community around the software. In order to increase the probability that people will return and contribute to the community, it helps to follow some basic principles. For example, you should thank community members for their contributions. It helps to remember that there is no requirement that people contribute to an open-source project; they are choosing to be part of the community and their contributions are a gift. Rudeness has a price in terms of member retention. Creating a space or environment that considers the human aspects of communities in open source, not simply the technical points, will help build a strong foundation for future success. Thank you Luis for sharing your insights with us!! [Less]

The landscape of open-source software within the federal government has always been a difficult back and forth, with some agencies and contractors embracing it, while others either avoid it like the plague or just simply do not care one way or the ... [More] other.  During the past few months, however, the White House has started to push several policies down from the very top, which is great news for open science. U.S. Digital Services Playbook The "U.S. Digital Services Playbook" is essentially a set of guidelines for software, services, and data funded by the U.S. government.  According to the document's github project, the U.S. Digital Services Playbook identifies a series of “plays” drawn from successful best practices from the private sector and government that, if followed together, will help the government build effective digital services. The plays outline an approach to delivering services that increases the ability of agencies to be flexible and iterative. Most importantly, the plays allow agencies to focus on the needs of the people that use their services. The real icing on the cake for open science is Play #13: Default to Open, which states: "If the code base has not been released under an open source license, explain why." In other words, it asks contractors to justify why they have not made their government-funded work open source.  While we've seen this initiative before with the Consumer Financial Protection Bureau, it is now becoming a government-wide initiative instead of one restricted to a single agency.  The TechFAR Handbook The TechFAR Handbook highlights flexibilities in the Federal Acquisition Regulation (FAR) that can help agencies implement “plays” from the Playbook using acquisition support. In particular, the handbook focuses on how to use contractors to support an iterative, customer-driven software development process. The TechFAR is a great accompaniment to Play #13, since much of the difficulty some groups face with providing open-source solutions is on the contractual side, given the myriad of government regulations for acquisitions. Second Open Government National Action Plan for the United States of America The Open Government Partnership, as part of the "Second Open Government National Action Plan for the United States of America," contains new initiatives that can benefit open science. While there are four main initiatives, the second, “Deliver Government Services More Effectively Through Information Technology,” is of particular interest.  Two points from the second initiative deserve a special highlight. 1.) Build digital services in the open. Much of the open source work we have seen from the government has been in the form of periodic "code drops." While code drops provide access to source code, they are a far cry from embracing open science, as they eliminate all of the added benefits gained through an open source community. For example, developer community engagement and bug fixes from places you never even imagined just cannot materialize under the "code drop" model. By developing services in the open, there is a chance to build open source communities around them and, in turn, reap the associated technical and financial benefits. 2.) Adopt an open source software policy. Using and contributing back to open source software can fuel innovation, lower costs, and benefit the public. No later than December 31, 2015, the Administration will work through the Federal agencies to develop an open-source software policy that, together with the Digital Services Playbook, will support improved access to custom software code developed for the Federal government. This is perhaps the most significant point, as it fosters the adoption of a government-wide open-source software policy. The intent seems to be quite clear, at least in regards to open source: Taxpayer funded software should be actively developed in the open.  However, the devil is always in the details of how these various policies and initiatives are put into action, which will be interesting to watch play out over the next year. [Less]

This post is the second part of our trip report on the SciPy 2014 conference. It covers the conference’s presentations and posters.  For an introduction and overview of tutorials, please see our previous blog post. Overview This year’s ... [More] conference expanded the number of talks by approximately 50%. While the talks spanned two days instead of three, the quality of the talks and posters was as stellar as ever. Although the IPython notebook was the hot topic of last year’s conference, it still held considerable mindshare, and most presentations were delivered with an IPython notebook. Similarly, while reproducibility was not an explicit theme for this year’s conference, it was still an issue addressed in many talks.        At the conference, there were different flavors of talks, which shared commonalities in that they were about science and computing with Python, were informative, and were interesting. The conference talks included inspirational keynotes on computational learning, adventures in CPython packaging, and software carpentry. There were also takes on fundamental concepts such as frequentism vs bayesianism and choosing the best colormap. In addition, solutions were proposed to interesting social problems, including enabling contributions with a dispatch architecture and improving computational literacy. Plus, exciting new projects were announced, such as airspeed velocity, zero dependency python, and jupyter. Presentations Aashish Chaudhary presented a talk on Climate & GIS: User friendly data access, workflows, manipulation, analysis, and visualization of climate and geospatial datasets. Bradley Lowekamp presented the SimpleITK talk, which was co-authored by Luis Ibáñez and Matt McCormick. The talk was well received, and we had a number of great conversations with attendees who were not very familiar with ITK/SimpleITK, as well as with many who were simply happy to see our presence and support. Posters This year, we had two posters accepted to the conference. Jean-Christophe Fillion-Robin presented his poster on “Python cross-compilation and platform builds for HPC and scientific computing,” which describes a CMake configuration for CPython. Source: https://github.com/jcfr/scipy_2014_python-cmake-buildsystem_poster Furthermore, Aashish presented Web visualization and analysis work under the title “Web-based analysis and visualization for large geospatial datasets for climate scientists.” Comparative visualization over the Web for climate datasets accessed from ESGF [Less]

We are pleased to announce that CMake 3.0.2 is now available for download.   Please use the latest release from our download page http://www.cmake.org/download/    Thanks for your support! ... [More] -------------------------------------------------------------------- Changes in 3.0.2 since 3.0.1:   Alan W. Irwin (1):   ExternalProject: Avoid infinite loop on file download hash mismatch Brad King (6):   CMP0047: Fix CMAKE_COMPILER_IS_GNU(CC|CXX) in OLD behavior   CMP0022: Fix version documented to support LINK_PUBLIC/LINK_PRIVATE   cmListFileLexer: Fix lexing of single '[' character (#15092)   Xcode: Generate per-target file references (#15111)   Fix finding binutils when cross-compiling with Clang Christian Svensson (2):   KWIML: Teach ABI.h about OpenRISC 1000   KWSys CPU: Add support for OpenRISC 1000 Stephen Kelly (2):   QtAutogen: Use the basename for resource files.   QtAutogen: Fix use of multiple ui files in a single target. Tim Blechmann (1):   BundleUtilities: Allow Info.plist files which use CR line endings -------------------------------------------------------------------- [Less]

Kitware is pleased to announce the development of an open-source website that depicts a network of participants in the popular Ice Bucket Challenge, which has raised funds for The ALS Association. We all have seen the unending stream of news reports ... [More] of celebrities performing the ALS Ice Bucket Challenge. However, no one report has captured the true scale and proliferation of the challenge or highlighted the interesting connections between the participants. Accordingly, some folks in our Scientific Computing team created a simple open-source website on the Ice Bucket Challenge to show the breadth of participation in the fundraiser. The information visualization on the website also addresses how and why particular people became involved in the challenge by linking participants to those who challenged them, as well as to those who they, in turn, challenged. For example, below you can see that at least four separate celebrities challenged Oprah, and that Oprah challenged Steven Spielberg. For the website, a simple data format was developed that is read by the site to list the participants in a grid, show details and related individuals, and link to posted videos of participants taking the challenge.  To further promote community involvement, we are encouraging additions and corrections to the website from anyone who would like to participate. Those who would like to add or propose corrections to the website can submit information through the issues page. For the developer-inclined, Kitware urges others to fork its repository on GitHub and submit pull requests with additions to its JSON data file and image thumbnails. [Less]

Kitware is pleased to announce the development of an open-source website that depicts a network of participants in the popular Ice Bucket Challenge, which has raised funds for The ALS Association. We all have seen the unending stream of news reports ... [More] of celebrities performing the ALS Ice Bucket Challenge. However, no one report has captured the true scale and proliferation of the challenge or highlighted the interesting connections between the participants. Accordingly, some folks in our Scientific Computing team created a simple open-source website on the Ice Bucket Challenge to show the breadth of participation in the fundraiser. The information visualization on the website also addresses how and why particular people became involved in the challenge by linking participants to those who challenged them, as well as to those who they, in turn, challenged. For example, below you can see that at least four separate celebrities challenged Oprah, and that Oprah challenged Steven Spielberg. For the website, a simple data format was developed that is read by the site to list the participants in a grid, show details and related individuals, and link to posted videos of participants taking the challenge.  To further promote community involvement, we are encouraging additions and corrections to the website from anyone who would like to participate. Those who would like to add or propose corrections to the website can submit information through the issues page. For the developer-inclined, Kitware urges others to fork its repository on GitHub and submit pull requests with additions to its JSON data file and image thumbnails. [Less]