Thursday, May 16, 2019

ip-num version 1.2.0 has been released.

NOTE: A cyclic dependency issue was found in the 1.2.0 release and has been fixed with the 1.2.1 patch release. It is thus advised to use version 1.2.1. The content of this post still applies. 
ip-num version 1.2.0 has been released.













This release contains the following enhancements/additions:

Switched JavaScript target to es5 to ease usage in ie11.

Based on this issue, the generated JavaScript for ip-num is now es5. This is to make it easier to use in browsers that do not support es6: like internet explorer 11. Unfortunately things won’t still work right out of the box, and a polyfill for string.prototype.repeat needs to be included. Trying to get things to work in ie11 is already sucking out the fun on working on the library, so I would not be spending any more energy/time on this. Perhaps in the future I will look into getting things to work out of the box with ie11...or perhaps not.

Moved some operations to the IPRange interface.

The following methods were moved to the IPRange interface:
  • isConsecutive - Indicates whether the given IP range is an adjacent range
  • Contains - Indicates if the given IP range is contained within the range
  • Inside - inverse of Contains. It indicates if the range is contained inside the given range
  • isOverlapping - Checks if two IP ranges overlap (which will always be false with CIDR ranges)

Added method to IPRange to return the adjacent ranges.

This enables the ability to check if a range has next or previous range and the ability to return such a range. So for example:

IPv4CidrRange.fromCidr("255.255.254.0/24").hasNextRange() will return true and
IPv4CidrRange.fromCidr("255.255.254.0/24").nextRange().toCidrString() will return 255.255.255.0/24



Added ability to validate if a CIDR notation represents a valid range.

Added isValidIPv4CidrRange/isValidIPv6CidrRange validation methods that returns true or false depending on if the given ip number represents the start of the CIDR range.

For example, validating 10.0.0.0/8 should return true, since 10.0.0.0 is the start of the CIDR range depicted, but validating 10.0.4.23/8 should return false, since 10.0.4.23/8 is not the start of the range.

This new validation is a stricter form of already existing isValidIPv4CidrNotation/isValidIPv6CidrNotation which only validates that the given string is of the format [ip number]/[range].

That is basically the summary of the 1.2.0 release. Work would start soon on the 1.3.0 version, which would focus mainly on adding operations for working with sets of IP numbers to the library.

Saturday, January 05, 2019

Ristex 0.1.0 Released

At about 11:46 pm, I got version 0.1.0 of Ristex released to Maven central. This marks the first Scala library I would be releasing! Yay!! 🎉

It should now be available for inclusion with the following sbt configuration:

// ${version} = 0.1.0
libraryDependencies += "io.geekabyte.ristex" %% "ristex" % "${version}"


And by the way, the release process was not as painful as I envisaged. Read further, for my thought on this.

What is Ristex

Ristex is a parser combinator library for parsing the RIR Statistics Exchange files. In theory it should work with the files published by all regional internet registry, in practice, it has only been used with files published by RIPE NCC.

Ristex uses Atto, which is a compact, pure-functional, incremental text parsing library for Scala. Infact, Ristex essentially extends Atto to cater for parsing the RIR Statistics Exchange files, and it makes no attempt to abstract it away, hence all of Atto's API are directly available for use with Ristex.

The idea for Ristex came up when I started working on a fun project to create a JSON format for the CSV like format of the RIR Statistics Exchange files. While working on this, it became apparent that it would be good to have a nicer way to parse the exchange files instead of relying on regex. And since I have always wanted to explore the idea of Parser Combinators in general and the Atto library in particular, it took little persuasion to temporarily shelf the project to create a JSON format, and create a parser combinator library to parse them instead.

Releasing to Maven Central Via SBT

Releasing the library to maven with sbt was relatively painless. I was expecting it to be much of a frustrating experience but I was pleasantly surprised. I guess having previously documented How To Publish Software Artifacts To Central Repository, also helped.

I found this post: An in depth guide to deploying to Maven Central with sbt by Leonard Ehrenfried to be particularly helpful.

The only snag I encountered was related to getting the PGP key published to a public key server. For reasons I still do not know, running the command:

`pgp-cmd send-key ${keyname} hkp://pool.sks-keyservers.net` 

as specified in the post above was not working. This caused the release process to fail a couple of times since maven could not verify the integrity of what was being published.

I had to result to manually uploading the PGP key using the web interface provided by https://pgp.surfnet.nl/. Apart from this, everything went smoothly.

Anyways, the source of Ristex is available on Github, so do feel free to poke around!