We want to make contributing as easy as possible. There are a number of issues that can be solved. Most of the issues are labelled.
Here's the current explanation of the labels:
Label | Expertise Required | Notes |
---|---|---|
easy | Familiar with Go | Usually there would be a link to an existing implementation that is similar |
requires Linear Algebra knowledge | Linear algebra knowledge required on top of being familiar with Go | Linear Algebra knowledge will go a long way in helping identify subtler bugs |
no label | Knowledge about Gorgonia | |
help wanted | Various expertise | Typically it means the task requires extranormal speciality that the author doesn't possess |
complicated | - | The code change will affect, and involve many files |
- Fork this project on Github
- Clone to your local drive
- Check if there are any pending issues in the issues tracker
- Pick an unassigned issue that you can accomplish. Comment on the issue to pick it up.
- Work on it, using topic branches is highly recommended.
Testing is important
- Test, test, test. Make sure your new code doesn't break the existing tests
- If you add new code, you must add tests.
gofmt
your code- 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.
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. Please try to keep to this flow.
Whilst the author encourages the use of 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:
go build -tags='debug' .
The debug tag enables various tracing options, available in debug.go
. There are several debug constants that are used:
compileDev
shapeInferenceDev
typeSystemDev
symdiffDev
autodiffDev
machineDev
stabilizationDev
solverDev
cudaDev
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.