Developing a Nimble package

Software projects are typically given version numbers to identify their state. As soft-ware evolves, new developments are marked with increasing version numbers. Nimble packages are no different.

The NimbleExample package began its life as version 0.1.0, and if it continues to be developed, it may someday reach version 1.0 or even 10.3. Versions help the user distinguish and identify different states of your package.

Version information for your package is stored in your package’s .nimble file using the version key. The version must consist of at least one digit, and multiple digits must be separated by periods. A full line specifying the version could look something like version = "1.42.5".

5.8.1 Giving version numbers meaning

The way in which version numbers are assigned and incremented differs. In some cases, the version numbers have little meaning other than signifying that version 1.0 is newer than version 0.5. In others, such as with semantic versioning, the version numbers tell you more about the API compatibility of different versions of software.

Semantic versioning is a convention for specifying a three-part version number:

major version, minor version, and patch. The patch is incremented for minor bug fixes and changes that don’t affect the API of the software. The minor version is incremented when backward-compatible additions are made to the software. The major version is incremented when the API of the software changes to something that’s not backward compatible. The full semantic versioning specification is available at http://semver.org.

All Nimble packages should use this convention, so if you aren’t familiar with it, be sure to learn about it.

5.8.2 Storing different versions of a single package

There are some things you need to keep in mind with versioning and Nimble packages.

A local Nimble package that doesn’t have a Git or Mercurial repository associated with it has a specific version associated with it. This is the version in the .nimble file.

A local Nimble package that does have a Git or Mercurial repository associated with it is the same, but different versions of it can be retrieved because its repository contains a full history of the package. The retrieval must be done manually for local packages, whereas for remote packages, Nimble will automatically retrieve the speci-fied version. All remote Nimble packages are currently stored in such repositories, and they can be downloaded to create a local repository containing each version of the Nimble package. Figure 5.15 shows the difference between a Nimble package with and without a Git repository.

When developing Nimble packages, it’s important to remember one thing: Nimble uses the tags in the Nimble package’s repository to retrieve a certain version.

Whenever you want to release a new version of a package, you need to follow these steps:

1 Increment the version number in the .nimble file.

2 Commit these changes into your repository; for example, git commit -am

"Version 0.1.2".

3 Tag the commit you just made, using the new version number as the tag name;

for example, git tag v0.1.2.

4 Upload the changes to the remote repository, making sure you upload the tags as well; for example, git push origin master --tags.

Performing step 1 first is very important. If the name of the tag doesn’t match the ver-sion specified in the .nimble file at the point in history that the tag corresponds to, there will be an inconsistency, and Nimble will refuse to install the package.

The preceding steps for tagging versions are specific to Git. You’ll find that in order to develop Nimble packages, you’ll need at least a basic knowledge of Git or Mercurial.

5.9 Summary

 The Nim package manager is called Nimble.

 A Nimble package is any directory or repository, compressed or otherwise, con-taining a .nimble file and some Nim source code.

 A .nimble file contains information about a package, including its version, author, dependencies, and more.

 Nimble packages are installed using the nimble install command.

 Nimble packages can be installed from various sources, including the local filesystem, a Git or Mercurial URL, and a curated list of packages identified by name.

 Installing a package by name or from a URL will install the latest tagged version of it; the tip or the HEAD can be installed by appending @#head to the URL or package name.

NimbleExample.nimble NimbleExample package

.git

NimbleExample.nimble NimbleExample package Local package with no repository Local package with a Git repository

Version 1.0.0 ^{0.1.0 0.2.0 0.3.0} Version 1.0.0

Figure 5.15 Local Nimble package with no repository vs. one with a Git repository

 A Nimble package can be created using the nimble init command.

 A Nimble package can be published using the nimble publish command.

 New versions of packages are released by incrementing the version number in the .nimble file, creating a new commit, and then tagging it as the new version in Git or Mercurial.

150

Parallelism

Every computer program performs one or more computations, and these computa-tions are usually performed sequentially. That is, the current computation has to com-plete before the next one starts. For example, consider a simple calculation, (2 + 2) x 4, in which the addition must be computed first, to give 4, followed by the multiplication, to give 16. In that example, the calculation is performed sequentially.

Concurrency allows more than one computation to make progress without wait-ing for all other computations to complete. This form of computwait-ing is useful in many situations, such as in an I/O application like the chat application you devel-oped in chapter 3. If executed sequentially, such applications waste time waiting on input or output operations to complete. Concurrency allows this time to be used for another task, drastically reducing the execution time of the application. You

This chapter covers

 Exploring the importance of parallelism

 Examining concurrency versus parallelism

 Getting to know threads in Nim

 Advanced parsing of data using regular expressions and other means

 Parallelizing the parsing of large datasets

learned about concurrency in chapter 3; in this chapter, you’ll learn about a related concept called parallelism.

Nim offers many built-in facilities for concurrency and parallelism including asyn-chronous I/O features in the form of futures and await, spawn for creating new threads, and more. You’ve already seen some of these used in chapter 3.

Parallelism in Nim is still evolving, which means that the features described in this chapter may change or be replaced by more-robust features. But the core concepts of parallelism in Nim should remain the same, and what you’ll learn in this chapter will be applicable to other programming languages as well.

In addition to showing you Nim’s parallelism features, this chapter will lead you through the implementation of a simple parser, which will show you different meth-ods for creating parsers. Toward the end of the chapter, you’ll optimize the parser so it’s concurrent and can be run in parallel on multiple CPU cores.