propensive/cellulose

A comprehensive Scala library for working with CoDL files

cellulose's Issues

Reimplement binary serialization(s)

Two variants of the binary serialization should be provided: one optimized for when the data is stored as a string, and offsets are character-based, and another for random-access from disk, where offsets are in bytes.

Use Wisteria for generic derivation

Implement vertical alignment checking

Using two or more spaces should force consistent vertical alignment all adjacent lines on parameters preceded by two or more spaces. This needs to be formalized, though.

`Codl.parse` should take a `LazyList[Bytes]`

Currently it's written in terms of a Reader.

Detection of duplicate IDs does not work

There is a failing test for this issue.

Logo looks a bit indistinct

The color of the "cell walls" looks a bit "washed-out".

Implement JavaScript reader for serialized CoDL

The implementation should be quite simple.

Multiline text is not serialized correctly

Simplify derived instances

The derived instances are unnecessarily cumbersome to define, and can be mostly simplified to one-liners.

Rendered logo contains artifacts

In the center of each "cell" there is a small "mess" of shapes.

Simplify serialization

Serialization to a string should be easier. Currently it uses an java.io.Writer, though we shouldn't be exposing Java APIs.

Distinguish between single- and double-space delimited parameters

The rule should be that if we encounter two consecutive spaces, for the remainder of the line, a single space should be considered an "ordinary" character.

Documentation is quite incomplete

Reimplement derivations using low-level `Mirror`s

Switch to using field name mapping instead of annotations

Investigate failing tests

Reading an empty file causes a `Nil.head` error

Work out exceptions to double-space rules

We have a general rule that on a line, after two or more spaces, a single space does not constitute a new parameter. That is, two or more spaces are required to separate subsequent parameters. For key/value-style data, this works well most of the time, but not always. In a hypothetical project definition we could have, for example,

id           my-project
name         My project
description  The project I'm developing
keywords     experimental data cli

and experimental data cli would be treated as a single parameter, which would lead to a validation failure if keywords are not allowed to contain spaces, while it should really be three separate parameters (which would be interpreted as a repeated parameter according to the schema). But we would not want the description to be split on spaces.

Offering a way to specify (in a schema) whether a field can include spaces (or not) might help here. Concretely, this would mean that the example above could be correctly interpreted without additional spaces being required between the keywords.

Separate binary CoDL format into a separate module

BCoDL should be an optional module.

Allow CODL body to be accessed as a character stream

`CodlDoc`'s `body` should be a `LazyList[Text]` not `LazyList[Char]`

Some serialization tests have started failing

Provide support in schemas for coproducts

There should be a standard way of serializing a coproduct. For example, given,

sealed trait Node
case class File(path: Text) extends Node
case class Directory(path: Text, empty: Boolean) extends Node

we should write these as,

node file
  path /path/to/file
node directory
  empty yes
  path /path/to/directory/

where the parameter, file or directory would have the name type. The children of each should be checked for the particular type.

In a schema, the definitions for node file and node directory should (on some level) be as different as any other two distinct keywords, but consideration needs to be paid to the multiplicity of node... This is currently unresolved.

Dynamic access should be enabled with an import

It's too easy to accidentally call a dynamic method when it's not intended.