Skip to content

Latest commit

 

History

History
131 lines (90 loc) · 4.34 KB

getting-started.md

File metadata and controls

131 lines (90 loc) · 4.34 KB
Raw

Getting Started

The steps to install and run CL-NLP with quicklisp. You will also find information about the test, docs infrastructure with guidelines to contribute.

Recommended Reading

If you are new to NLP, here are a few documents to help you get started.

Dependencies

As of now cl-nlp has been tested only on SBCL.

Test Dependencies

Installation

Currently CL-NLP is not available from the quicklisp repository. You need to clone it to your quicklisp local projects directory. You are also advised to clone RUTILS and SHOULD-TEST to local projects.

cd path/to/quicklisp/local-projects (usually, ~/quicklisp/local-projects/)

git clone [email protected]:vseloved/cl-nlp.git

git clone [email protected]:vseloved/rutils.git

git clone [email protected]:vseloved/should-test.git

Test System

The tests are guarded by the #+dev feature. As such you need to push this symbol to *features* in order to run the tests before loading CL-NLP. The tests can be run with a single command using ASDF:TEST-SYSTEM as is shown in the next section.

If you do not wish to run tests, you can skip this step. We hope a developer who wants to contribute does not do this!

Travis CI

CL-NLP is automatically tested with Travis CI which runs the test suite using SBCL.

Using Quicklisp with Test System

Now you can load CL-NLP and run the tests.

* (pushnew :dev *features*) ;;; use only if you want to run tests

* (ql:quickload :cl-nlp)

* (asdf:test-system :cl-nlp)

Project Layout

  1. src - contains source code divided into modules by NLP tasks
  2. contrib - contains supplementary source code (usually, targeted at integration with external software)
  3. test - contains test code guarded by #+dev
  4. docs - contains documentation created with MKDocs

Contribution Guidelines

You are welcome to submit bug fixes and new features. The following is the process you need to follow:

Process Guidelines

  • Create your own fork.
  • Create a bug fix or feature branch.
  • Make your code changes on that branch.
  • Add tests for your bug fix/feature.
  • Run the test suite locally.
  • Add and test documentation as described next.
  • Submit PR.
  • Hopefully Travis will be happy.
  • Incorporate any review changes and rinse, lather, repeat till integrated :-).

Coding Style Guidelines

  • In general, follow the Google Common Lisp Style Guide.
  • CL-NLP uses heavily utilities and syntactic extensions from RUTILS. Using the "normal" CL things for the same stuff in new code is OK, although expect it to be eventually re-written in rutils' style. Using other utilities packages is not allowed.
  • The library is built around a generic OO-approach where each algorithm is specialized with a certain class or classes of entities it is bound to. For instance a tokenize function will have methods for sentence-splitter and word-tokenizer classes. For more details on it see Overview of CL-NLP architecture.
  • Tests for CL-NLP are written using SHOULD-TEST. The test module is only loaded when :dev is present in *features*

Documentation

The project is documented using MkDocs and hosted on readthedocs.org.

If you wish to contribute to the documentation, the following steps are recommended:

  • Install MkDocs as described here.
  • Create a new branch and make the changes.
  • Test locally as described here using the serve command.
  • Verify and submit a Github PR.