Home Explore Help
Sign In
3DFaces
/
libigl_Martin
3
0
Fork 0
Files Issues 0 Pull Requests 0 Wiki
Browse Source

added coding guidelines

Former-commit-id: 87b4732371394d5f70b951cab79b109502e02092
Daniele Panozzo 8 years ago
parent
176202c632
commit
6cc07ac576
7 changed files with 144 additions and 28 deletions
Split View Show Diff Stats
  1. 11 7
      README.md
  2. 62 0
      coding-guidelines.html
  3. 42 0
      coding-guidelines.md
  4. 15 10
      index.html
  5. 9 9
      optional/index.html
  6. 4 1
      scripts/update_gh-pages.sh
  7. 1 1
      tutorial/tutorial.html.REMOVED.git-id

+ 11 - 7
README.md
View File 

@@ -43,10 +43,14 @@ and Windows with Visual Studio 2015 Community Edition.
 
 As of version 1.0, libigl includes an introductory
 
 [tutorial](http://libigl.github.io/libigl/tutorial/tutorial.html) that covers many functionalities.
 
 
-## libigl example project
 
+## libigl Example Project
 
 
 We provide a [blank project example](https://github.com/libigl/libigl-example-project) showing how to use libigl and cmake. Feel free and encouraged to copy or fork this project as a way of starting a new personal project using libigl.
 
 
+## Coding Guidelines and Tips
 
+
 
+libigl follows strict coding guidelines, please take a look [here](style-guidelines.html) before submitting your pull requests. We also have a set of [general coding tips](coding-guidelines.html) on how to code a geometry processing research project.
 
+
 
 ## Installation
 
 
 Libigl is a **header-only** library. You do **not** need to build anything to
 
@@ -98,7 +102,7 @@ libigl depends only on the [Eigen](http://eigen.tuxfamily.org) library.
 
 
 For more information see our [tutorial](tutorial/tutorial.html).
 
 
-### Optional dependencies
 
+### Optional Dependencies
 
 
 Libigl compartmentalizes its **optional** dependences via its directory
 
 organization in the `include/` folder. All header files located _directly_ in
 
@@ -106,7 +110,7 @@ the `include/igl/` folder have only stl and Eigen as dependencies. For example,
 
 all of the headers that depend on CGAL are located in `include/igl/cgal`. For a
 
 full list of _optional_ dependencies check `optional/CMakeLists.txt`.
 
 
-### GCC and the optional CGAL dependency
 
+### GCC and the Optional CGAL Dependency
 
 The `include/igl/cgal/*.h` headers depend on CGAL. It has come to our attention
 
 that CGAL does not work properly with GCC 4.8. To the best of our knowledge,
 
 GCC 4.7 and clang will work correctly.
 
@@ -162,16 +166,16 @@ git pull
 
 git submodule update --recursive
 
 ```
 
 
-## Unit testing
 
+## Unit Testing
 
 
 Libigl maintains [separate
 
 repository](https://github.com/libigl/libigl-unit-tests) for unit testing.
 
 
-## How to contribute
 
+## How to Contribute
 
 
 If you are interested in joining development, please fork the repository and
 
 submit a [pull request](https://help.github.com/articles/using-pull-requests/)
 
-with your changes.
 
+with your changes. libigl follows strict coding guidelines, please take a look at our  [style guidelines](style-guidelines.html) before submitting your pull requests.
 
 
 ## License
 
 libigl is primarily [MPL2](http://www.mozilla.org/MPL/2.0/) licensed
 
@@ -255,7 +259,7 @@ If you find bugs or have problems please use our [github issue tracking
 
 page](https://github.com/libigl/libigl/issues).
 
 
 ## Copyright
 
-2016 Alec Jacobson, Daniele Panozzo, Christian Schüller, Olga Diamanti, Qingnan
 
+2017 Alec Jacobson, Daniele Panozzo, Christian Schüller, Olga Diamanti, Qingnan
 
 Zhou, Sebastian Koch, Amir Vaxman, Nico Pietroni, Stefan Brugger, Kenshi Takayama, Wenzel Jakob, Nikolas De
 
 Giorgis, Luigi Rocca, Leonardo Sacht, Kevin Walliman, Olga Sorkine-Hornung, and others.

+ 62 - 0
coding-guidelines.html
View File 

@@ -0,0 +1,62 @@
 
+<!DOCTYPE html>
 
+<html>
 
+<head>
 
+	<meta charset="utf-8"/>
 
+	<title>libigl</title>
 
+	<meta name="author" content="Alec Jacobson and Daniele Panozzo and others"/>
 
+	<link type="text/css" rel="stylesheet" href="../tutorial/style.css"/>
 
+<script type='text/javascript' src='http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML'></script>
 
+<link rel='stylesheet' href='http://yandex.st/highlightjs/7.3/styles/default.min.css'>
 
+<script src='http://yandex.st/highlightjs/7.3/highlight.min.js'></script>
 
+<script>hljs.initHighlightingOnLoad();</script>
 
+</head>
 
+<body>
 
+
 
+<h1 id="libiglcodingtipsakahowtocodeasiggraphproject">Libigl Coding Tips (aka &#8220;How to code a SIGGRAPH project&#8221;)</h1>
 
+
 
+<p>This is a short list of coding tips that will greatly reduce your pain and suffering before (and after) the SIGGRAPH deadline.</p>
 
+
 
+<h3 id="1.serializeitall">1. Serialize it all</h3>
 
+
 
+<p>The entire state of your application should be serializable, i.e. It should be possible to save it into a binary file and reload it at any point. This drastically simplifies debugging, since you can serialize just before a crash happens and debug from that point without running your complete algorithm again. Serializing all results shown in the paper&#8217;s figures enables quicker editing iterations before (and after) the deadline. It also allows you to share your results with others that wish to compare with your method. An additional tip is to serialize the state of the application on the window close event and automatically reload it when you launch it again.</p>
 
+
 
+<h3 id="2.alwaysassert">2. Always assert</h3>
 
+
 
+<p>Even if you know what you are doing, always assert, you will be surprised. Assertion is a powerful but underused feature available in all programming languages. It is essential for writing research code since often you will have to implement algorithms that turns out to not be doing what you expect: in these cases it is important to know if the algorithm is flawed or if there is a bug in your implementation. Discarding a good idea because of a coding bug is frustrating and unfortunately common. Assertion is an ideal way to reduce the chances of introducing bugs in your code and, differently from unit testing, requires a very minor programming effort. You should use them extensively.</p>
 
+
 
+<h3 id="3.ploteverything">3. Plot everything</h3>
 
+
 
+<p>If you can visually plot the results or some intermediate steps of your algorithm, do it, even if you think your implementation is correct! It is a lot easier to find bugs or to get an intuition on an algorithm by looking at a plot than by looking at the code.</p>
 
+
 
+<h3 id="4.ifthecompilationtimeafteracodechangeismorethanfivesecondsyouaredoingitwrong">4. If the compilation time after a code change is more than five seconds, you are doing it wrong</h3>
 
+
 
+<p>You will change your code hundreds of times every day for months. Let&#8217;s say that you will change it a hundred times a day (which is a very conservative estimate): if the compilation takes one minute, you will waste almost two hours every day, just waiting! What is even worse, is that since it is only 1&#8211;2 minutes at a time, it will not even be sufficient to prepare a coffee. Spend the hour or two that is needed to get your code to compile in a few seconds, you will benefit from it in the same day already, and the time saved over an entire project will be gigantic.</p>
 
+
 
+<h3 id="5.commitoftenandwithameaningfuldescription">5. Commit often (and with a meaningful description)</h3>
 
+
 
+<p>Use a distributed version control system (git,hg), and keep the repository on a remote host. Commit often and put meaningful comments. This will serve you as an emergency backup and it will always allow you to have a running version of your code whenever your advisor is passing by and asking to see some results. She will be impressed and you will not have to quickly fix your build with your boss breathing down your neck.</p>
 
+
 
+<h3 id="6.dependenciesareevilavoidthem">6. Dependencies are evil, avoid them</h3>
 
+
 
+<p>Keep your code simple and with minimal external dependencies. Spending a day or two to code something from scratch while avoiding to use third party code is usually an investment that pays off. The more code you have in your algorithm that is not written by you, the harder debugging becomes. In particular, refrain from building your entire project on code that you do not understand to avoid bad surprises just before the deadline. If you must use code written by others, spend the time that is needed to fully understand what it does, and link it statically so that it will be easy to place breakpoints inside it.</p>
 
+
 
+<h3 id="7.globalvariablesarenotevilusethem">7. Global variables are not evil, use them</h3>
 
+
 
+<p>Global variables are often extremely useful &#8212; if you think you need one, use it. They are indeed dangerous for large projects, but you are not coding one of those, you are coding a prototype to test a research idea. I suggest to keep one single copy of your entire application state in a global variable (or a singleton class) that can be serialized (see tip 1). This variable should include everything rendered on screen and all the temporary data produced by your algorithm. This will allow you to easily access all the data in your project for plotting or debugging purposes.</p>
 
+
 
+<h3 id="8.prototypefirst">8. Prototype first</h3>
 
+
 
+<p>Don’t preemptively optimize and try to quickly write code that is clean and correct. It is common to try multiple different approaches to solve a new problem before finding the right one. This means that the majority of the code that you will write will not be used at the end of the project. While you should still write high-quality and bug-free code to make sure that your results is correct, you definitely do not want to spend time optimizing it before you are sure that is the right approach. In particular, it is helpful to learn a good prototyping language (Python, matlab) and use it for the early stages of the project and switch to (or mix it with) c++ only after finding a promising direction.</p>
 
+
 
+<h3 id="9.avoidexplicitpointers">9. Avoid explicit pointers</h3>
 
+
 
+<p>Do yourself a favor, do not use explicit pointers. If you use a language that supports explicit pointers, use them only if you really have to. And even in that case, keep them isolated in a single file and be very careful with them. Writing data inside another variable by accident might not trigger a crash, and simply produce strange artifacts that might convince you that a promising research direction does not work, while the problem lies in a nasty bug in your code. There is no reason to take that risk during prototyping, just avoid them and leave them for the end of the project in case they become necessary to optimize your code.</p>
 
+
 
+<h3 id="10.ifyourprogramcrashesfixitnow">10. If your program crashes, fix it now!</h3>
 
+
 
+<p>If your program crashes, don&#8217;t close your eyes and move on. Try to make it happen again, debug it and fix it immediately. These bugs are a nightmare to find, and the more code you add on top of a bug will just make it harder to find. If you don&#8217;t fix it, due to Murphy&#8217;s law, it will start to be problematic only a few days before the deadline and you will have no time to fix it at that point.</p>
 
+
 
+<p><em>Daniele Panozzo</em></p>
 
+
 
+</body>
 
+</html>

+ 42 - 0
coding-guidelines.md
View File 

@@ -0,0 +1,42 @@
 
+# Libigl Coding Tips (aka "How to code a SIGGRAPH project")
 
+
 
+This is a short list of coding tips that will greatly reduce your pain and suffering before (and after) the SIGGRAPH deadline.
 
+
 
+
 
+### 1. Serialize it all
 
+The entire state of your application should be serializable, i.e. It should be possible to save it into a binary file and reload it at any point. This drastically simplifies debugging, since you can serialize just before a crash happens and debug from that point without running your complete algorithm again. Serializing all results shown in the paper's figures enables quicker editing iterations before (and after) the deadline. It also allows you to share your results with others that wish to compare with your method. An additional tip is to serialize the state of the application on the window close event and automatically reload it when you launch it again.
 
+
 
+### 2. Always assert
 
+Even if you know what you are doing, always assert, you will be surprised. Assertion is a powerful but underused feature available in all programming languages. It is essential for writing research code since often you will have to implement algorithms that turns out to not be doing what you expect: in these cases it is important to know if the algorithm is flawed or if there is a bug in your implementation. Discarding a good idea  because of a coding bug is frustrating and unfortunately common. Assertion is an ideal way to reduce the chances of introducing bugs in your code and, differently from unit testing, requires a very minor programming effort. You should use them extensively.
 
+
 
+### 3. Plot everything
 
+
 
+If you can visually plot the results or some intermediate steps of your algorithm, do it, even if you think your implementation is correct! It is a lot easier to find bugs or to get an intuition on an algorithm by looking at a plot than by looking at the code.
 
+
 
+### 4. If the compilation time after a code change is more than five seconds, you are doing it wrong
 
+
 
+You will change your code hundreds of times every day for months. Let's say that you will change it a hundred times a day (which is a  very conservative estimate): if the compilation takes one minute, you will waste almost two hours every day, just waiting! What is even worse, is that since it is only 1-2 minutes at a time, it will not even be sufficient to prepare a coffee. Spend the hour or two that is needed to get your code to compile in a few seconds, you will benefit from it in the same day already, and the time saved over an entire project will be gigantic.
 
+
 
+### 5. Commit often (and with a meaningful description)
 
+
 
+Use a distributed version control system (git,hg), and keep the repository on a remote host. Commit often and put meaningful comments. This will serve you as an emergency backup and it will always allow you to have a running version of your code whenever your advisor is passing by and asking to see some results. She will be impressed and you will not have to quickly fix your build with your boss breathing down your neck.
 
+
 
+### 6. Dependencies are evil, avoid them
 
+
 
+Keep your code simple and with minimal external dependencies. Spending a day or two to code something from scratch while avoiding to use third party code is usually an investment that pays off. The more code you have in your algorithm that is not written by you, the harder debugging becomes. In particular, refrain from building your entire project on code that you do not understand to avoid bad surprises just before the deadline. If you must use code written by others, spend the time that is needed to fully understand what it does, and link it statically so that it will be easy to place breakpoints inside it.
 
+
 
+### 7. Global variables are not evil, use them
 
+
 
+Global variables are often extremely useful --- if you think you need one, use it. They are indeed dangerous for large projects, but you are not coding one of those, you are coding a prototype to test a research idea. I suggest to keep one single copy of your entire application state in a global variable (or a singleton class) that can be serialized (see tip 1). This variable should include everything rendered on screen and all the temporary data produced by your algorithm. This will allow you to easily access all the data in your project for plotting or debugging purposes.
 
+
 
+### 8. Prototype first
 
+Don’t preemptively optimize and try to quickly write code that is clean and correct. It is common to try multiple different approaches to solve a new problem before finding the right one. This means that the majority of the code that you will write will not be used at the end of the project. While you should still write high-quality and bug-free code to make sure that your results is correct, you definitely do not want to spend time optimizing it before you are sure that is the right approach. In particular, it is helpful to learn a good prototyping language (Python, matlab) and use it for the early stages of the project and switch to (or mix it with) c++ only after finding a promising direction.
 
+
 
+### 9. Avoid explicit pointers
 
+Do yourself a favor, do not use explicit pointers. If you use a language that supports explicit pointers, use them only if you really have to. And even in that case, keep them isolated in a single file and be very careful with them. Writing data inside another variable by accident might not trigger a crash, and simply produce strange artifacts that might convince you that a promising research direction does not work, while the problem lies in a nasty bug in your code. There is no reason to take that risk during prototyping, just avoid them and leave them for the end of the project in case they become necessary to optimize your code.
 
+
 
+### 10. If your program crashes, fix it now!
 
+
 
+If your program crashes, don't close your eyes and move on. Try to make it happen again, debug it and fix it immediately. These bugs are a nightmare to find, and the more code you add on top of a bug will just make it harder to find. If you don't fix it, due to Murphy's law, it will start to be problematic only a few days before the deadline and you will have no time to fix it at that point.
 
+
 
+_Daniele Panozzo_

+ 15 - 10
index.html
View File 

@@ -15,7 +15,7 @@
 
 <h1 id="libigl-asimplecgeometryprocessinglibrary">libigl - A simple C++ geometry processing library</h1>
 
 
 <p><a href="https://travis-ci.org/libigl/libigl"><img src="https://travis-ci.org/libigl/libigl.svg?branch=master" alt="Build Status" /></a>
 
-<a href="https://ci.appveyor.com/project/danielepanozzo/libigl-6hjk1"><img src="https://ci.appveyor.com/api/projects/status/mf3t9rnhco0vhly8?svg=true" alt="Build status" /></a>
 
+<a href="https://ci.appveyor.com/project/danielepanozzo/libigl-6hjk1/branch/master"><img src="https://ci.appveyor.com/api/projects/status/mf3t9rnhco0vhly8/branch/master?svg=true" alt="Build status" /></a>
 
 <img src="libigl-teaser.png" alt="" /></p>
 
 
 <p><a href="https://github.com/libigl/libigl/">https://github.com/libigl/libigl/</a></p>
 
@@ -59,10 +59,14 @@ and Windows with Visual Studio 2015 Community Edition.</p>
 
 <p>As of version 1.0, libigl includes an introductory
 
 <a href="http://libigl.github.io/libigl/tutorial/tutorial.html">tutorial</a> that covers many functionalities.</p>
 
 
-<h2 id="libiglexampleproject">libigl example project</h2>
 
+<h2 id="libiglexampleproject">libigl Example Project</h2>
 
 
 <p>We provide a <a href="https://github.com/libigl/libigl-example-project">blank project example</a> showing how to use libigl and cmake. Feel free and encouraged to copy or fork this project as a way of starting a new personal project using libigl.</p>
 
 
+<h2 id="codingguidelinesandtips">Coding Guidelines and Tips</h2>
 
+
 
+<p>libigl follows strict coding guidelines, please take a look <a href="style-guidelines.html">here</a> before submitting your pull requests. We also have a set of <a href="coding-guidelines.html">general coding tips</a> on how to code a geometry processing research project.</p>
 
+
 
 <h2 id="installation">Installation</h2>
 
 
 <p>Libigl is a <strong>header-only</strong> library. You do <strong>not</strong> need to build anything to
 
@@ -112,7 +116,7 @@ libigl depends only on the <a href="http://eigen.tuxfamily.org">Eigen</a> librar
 
 
 <p>For more information see our <a href="tutorial/tutorial.html">tutorial</a>.</p>
 
 
-<h3 id="optionaldependencies">Optional dependencies</h3>
 
+<h3 id="optionaldependencies">Optional Dependencies</h3>
 
 
 <p>Libigl compartmentalizes its <strong>optional</strong> dependences via its directory
 
 organization in the <code>include/</code> folder. All header files located <em>directly</em> in
 
@@ -120,7 +124,7 @@ the <code>include/igl/</code> folder have only stl and Eigen as dependencies. Fo
 
 all of the headers that depend on CGAL are located in <code>include/igl/cgal</code>. For a
 
 full list of <em>optional</em> dependencies check <code>optional/CMakeLists.txt</code>.</p>
 
 
-<h3 id="gccandtheoptionalcgaldependency">GCC and the optional CGAL dependency</h3>
 
+<h3 id="gccandtheoptionalcgaldependency">GCC and the Optional CGAL Dependency</h3>
 
 
 <p>The <code>include/igl/cgal/*.h</code> headers depend on CGAL. It has come to our attention
 
 that CGAL does not work properly with GCC 4.8. To the best of our knowledge,
 
@@ -178,16 +182,16 @@ subrepos:</p>
 
 git submodule update --recursive
 
 </code></pre>
 
 
-<h2 id="unittesting">Unit testing</h2>
 
+<h2 id="unittesting">Unit Testing</h2>
 
 
 <p>Libigl maintains <a href="https://github.com/libigl/libigl-unit-tests">separate
 
 repository</a> for unit testing.</p>
 
 
-<h2 id="howtocontribute">How to contribute</h2>
 
+<h2 id="howtocontribute">How to Contribute</h2>
 
 
 <p>If you are interested in joining development, please fork the repository and
 
 submit a <a href="https://help.github.com/articles/using-pull-requests/">pull request</a>
 
-with your changes.</p>
 
+with your changes. libigl follows strict coding guidelines, please take a look at our <a href="style-guidelines.html">style guidelines</a> before submitting your pull requests.</p>
 
 
 <h2 id="license">License</h2>
 
 
@@ -232,7 +236,8 @@ few labs/companies/institutions using libigl:</p>
 
 <li>ETH Zurich, <a href="http://igl.ethz.ch/">Interactive Geometry Lab</a> and <a href="http://ait.inf.ethz.ch/">Advanced Technologies Lab</a>, Swizterland</li>
 
 <li>George Mason University, <a href="http://cs.gmu.edu/~ygingold/">CraGL</a>, USA</li>
 
 <li><a href="http://www.ust.hk/">Hong Kong University of Science and Technology</a>, Hong Kong</li>
 
-<li>[Inria](Université Grenoble Alpes), France</li>
 
+<li><a href="https://www.inria.fr/centre/grenoble/">Inria, Université Grenoble Alpes</a>, France</li>
 
+<li><a href="http://english.jiangnan.edu.cn">Jiangnan university</a>, China</li>
 
 <li><a href="http://www.nii.ac.jp/en/">National Institute of Informatics</a>, Japan</li>
 
 <li>New York University, <a href="http://mrl.nyu.edu/">Media Research Lab</a>, USA</li>
 
 <li>NYUPoly, <a href="http://game.engineering.nyu.edu/">Game Innovation Lab</a>, USA</li>
 
@@ -257,7 +262,7 @@ few labs/companies/institutions using libigl:</p>
 
 
 <h2 id="contact">Contact</h2>
 
 
-<p>Libigl is a group endeavor led by <a href="http://www.cs.columbia.edu/~jacobson/">Alec
 
+<p>Libigl is a group endeavor led by <a href="http://www.cs.toronto.edu/~jacobson/">Alec
 
 Jacobson</a> and <a href="http://cs.nyu.edu/~panozzo/">Daniele
 
 Panozzo</a>. Please <a href="&#109;&#97;&#105;&#108;&#x74;&#111;&#x3a;&#x61;&#x6c;&#101;&#x63;&#x6a;&#x61;&#x63;&#111;&#98;&#115;&#111;&#110;&#64;&#103;&#109;&#x61;&#105;&#108;&#x2e;&#x63;&#x6f;&#x6d;&#44;&#x64;&#x61;&#110;&#105;&#101;&#x6c;&#101;&#x2e;&#x70;&#x61;&#110;&#x6f;&#122;&#x7a;&#x6f;&#64;&#x67;&#x6d;&#x61;&#x69;&#x6c;&#x2e;&#99;&#x6f;&#x6d;">&#99;&#x6f;&#x6e;&#116;&#x61;&#99;&#x74;
 
 &#117;&#115;</a> if you have
 
@@ -274,7 +279,7 @@ page</a>.</p>
 
 
 <h2 id="copyright">Copyright</h2>
 
 
-<p>2016 Alec Jacobson, Daniele Panozzo, Christian Schüller, Olga Diamanti, Qingnan
 
+<p>2017 Alec Jacobson, Daniele Panozzo, Christian Schüller, Olga Diamanti, Qingnan
 
 Zhou, Sebastian Koch, Amir Vaxman, Nico Pietroni, Stefan Brugger, Kenshi Takayama, Wenzel Jakob, Nikolas De
 
 Giorgis, Luigi Rocca, Leonardo Sacht, Kevin Walliman, Olga Sorkine-Hornung, and others.</p>

+ 9 - 9
optional/index.html
View File 

@@ -146,12 +146,12 @@ containing Eigen matrices and other standard simple data-structures.</p>
 
 <pre><code>git archive -prefix=libigl/ -o libigl.zip master
 
 </code></pre>
 
 
-<h2 id="explicitspecializationoftemplatedfunctions">Explicit specialization of templated functions</h2>
 
+<h2 id="explicitinstantiationsoftemplatedfunctions">Explicit instantiations of templated functions</h2>
 
 
 <p>Special care must be taken by the developers of each function and
 
 class in the libigl library that uses C++ templates. If this function
 
 is intended to be compiled into the statically linked libigl library
 
-then function is only compiled for each <i>explicitly</i> specialized
 
+then function is only compiled for each <i>explicitly</i> instantiated
 
 declaration. These should be added at the bottom of the corresponding
 
 .cpp file surrounded by a</p>
 
 
@@ -159,8 +159,8 @@ declaration. These should be added at the bottom of the corresponding
 
 </code></pre>
 
 
 <p>Of course, a developer may not know ahead of time which
 
-specializations should be explicitly included in the igl static lib.
 
-One way to find out is to add one explicit specialization for each
 
+instantiations should be explicitly included in the igl static lib.
 
+One way to find out is to add one explicit instantiation for each
 
 call in one&#8217;s own project. This only ever needs to be done once for
 
 each template.</p>
 
 
@@ -168,7 +168,7 @@ each template.</p>
 
 output.</p>
 
 
 <p>Supposed for example we have compiled the igl static lib, including the
 
-cat.h and cat.cpp functions, without any explicit instanciation. Say
 
+cat.h and cat.cpp functions, without any explicit instantiation. Say
 
 using the makefile in the <code>libigl</code> directory:</p>
 
 
 <pre><code>cd $LIBIGL
 
@@ -193,13 +193,13 @@ all. Just copy the first part in quotes</p>
 
 </code></pre>
 
 
 <p>, then append it
 
-to the list of explicit template specializations at the end of
 
+to the list of explicit template instantiations at the end of
 
 <code>cat.cpp</code> after the word
 
 <strong>template</strong> and followed by a semi-colon.
 
 Like this:</p>
 
 
 <pre><code>#ifdef IGL_STATIC_LIBRARY
 
-// Explicit template specialization
 
+// Explicit template instantiation
 
 template Eigen::Matrix&lt;int, -1, -1, 0, -1, -1&gt; igl::cat&lt;Eigen::Matrix&lt;int, -1, -1, 0, -1, -1&gt; &gt;(int, Eigen::Matrix&lt;int, -1, -1, 0, -1, -1&gt; const&amp;, Eigen::Matrix&lt;int, -1, -1, 0, -1, -1&gt; const&amp;);
 
 #endif
 
 </code></pre>
 
@@ -215,7 +215,7 @@ process until no more symbols are undefined.</p>
 
 
 <p><code>It may be useful to check that you code compiles with
 
 no errors first using the headers-only version to be sure that all errors are from missing template
 
-specializations.</code></p>
 
+instantiations.</code></p>
 
 
 <p>If you&#8217;re using make then the following command will
 
 reveal each missing symbol on its own line:</p>
 
@@ -225,7 +225,7 @@ reveal each missing symbol on its own line:</p>
 
 
 <p>Alternatively you can use the <code>autoexplicit.sh</code> function
 
 which (for well organized .h/.cpp pairs in libigl) automatically
 
-create explicit instanciations from your compiler&#8217;s error messages.
 
+create explicit instantiations from your compiler&#8217;s error messages.
 
 Repeat this process until convergence:</p>
 
 
 <pre><code>cd /to/your/project

+ 4 - 1
scripts/update_gh-pages.sh
View File 

@@ -16,7 +16,7 @@ echo "$HEADER" \
 
   | cat - README.md | multimarkdown -o index.html
 
 
 echo "$HEADER" \
 
-  | cat - style-guidelines.md | multimarkdown -o style-guidelines.html 
+  | cat - style-guidelines.md | multimarkdown -o style-guidelines.html
 
 
 HEADER="title: libigl
 
 author: Alec Jacobson and Daniele Panozzo and others
 
@@ -32,3 +32,6 @@ echo "$HEADER" \
 
   | cat - optional/README.md | multimarkdown -o optional/index.html
 
 
 multimarkdown tutorial/tutorial.md -o tutorial/tutorial.html
 
+
 
+echo "$HEADER" \
 
+  | cat - coding-guidelines.md | multimarkdown -o coding-guidelines.html

+ 1 - 1
tutorial/tutorial.html.REMOVED.git-id
View File 

@@ -1 +1 @@
 
-e433fea7c89195d4086db16774eec2e6a7e8014f
 
+b216f50907a0c99d0cf2121123faff1aa75755bb