github.com/wzzhu/tensor@v0.9.24/CONTRIBUTING.md (about)

     1  # Contributing #
     2  
     3  We want to make contributing as easy as possible. There are a number of [issues](https://github.com/chewxy/gorgonia/issues) that can be solved. Most of the issues are labelled.
     4  
     5  ## Labels ##
     6  
     7  Here's the current explanation of the labels:
     8  
     9  <table>
    10  <thead><th>Label</th><th>Expertise Required</th><th>Notes</th></thead>
    11  <tbody>
    12  <tr><td>easy</td><td>Familiar with Go</td><td>Usually there would be a link to an existing implementation that is similar</td></tr>
    13  <tr><td>requires Linear Algebra knowledge</td><td>Linear algebra knowledge required on top of being familiar with Go</td><td>Linear Algebra knowledge will go a long way in helping identify subtler bugs</td></tr>
    14  <tr><td>no label</td><td>Knowledge about Gorgonia</td><td></td></tr>
    15  <tr><td>help wanted</td><td>Various expertise</td><td>Typically it means the task requires extranormal speciality that the author doesn't possess</td></tr>
    16  <tr><td>complicated</td><td>-</td><td>The code change will affect, and involve many files</td></tr>
    17  </tbody>
    18  </table>
    19  
    20  ## Steps ##
    21  1. Fork this project on Github
    22  2. Clone to your local drive
    23  3. Check if there are any pending issues in the issues tracker
    24  4. Pick an unassigned issue that you can accomplish. Comment on the issue to pick it up.
    25  5. Work on it, using topic branches is highly recommended.
    26  
    27  ## Testing ##
    28  
    29  Testing is important
    30  
    31  
    32  ## How To Get Your Pull Request Accepted ##
    33  
    34  1. Test, test, test. Make sure your new code doesn't break the existing tests
    35  2. If you add new code, you must add tests.
    36  3. `gofmt` your code
    37  5. Atomic pull requests - solve one issue per pull request. Some issues may break down to atomic tasks. In those cases, it's OK to solve them partially.
    38  
    39  
    40  ## Git Workflow ##
    41  
    42  The master branch is considered to be the "canonical" branch. There is no develop branch. The author prefers use of topic branches. The workflow can best be described by the [Github Flow](https://guides.github.com/introduction/flow/). Please try to keep to this flow.
    43  
    44  # Development #
    45  
    46  ## How the `Tensor` Libs Are Developed ##
    47  
    48  
    49  ## Debugging ##
    50  
    51  Whilst the author encourages the use of [Delve](https://github.com/derekparker/delve), it may often be easier to log the trace using the debug loggers. Gorgonia comes with a debug build tag precisely to help with that. To build debug builds, simply do this:
    52  
    53  ```go
    54  go build -tags='debug' . 
    55  ```
    56  
    57  The debug tag enables various tracing options, available in `debug.go`. There are several debug constants that are used:
    58  
    59  * `compileDev`       
    60  * `shapeInferenceDev`
    61  * `typeSystemDev`    
    62  * `symdiffDev`       
    63  * `autodiffDev`      
    64  * `machineDev`       
    65  * `stabilizationDev` 
    66  * `solverDev`
    67  * `cudaDev`        
    68  
    69  These are the bools that you need to set in order to get a trace. If for example, you think there is something wrong with the type system, simply set `typeSystemDev` to `true` and then insert `typeSysLogf` into wherever you want to trace. 
    70