Unzip the provided clj-paint.zip file to a location of your choice

Ensure you have Java available on your PATH to run the provided .jar file

Review the user guide stored at doc/user-guide.pdf to learn how to use clj-paint commands

To run clj-paint execute the following in your terminal

java -jar clj-paint.jar

If you would like to run the code from source code you can use:

clojure -X:run-x

A new jar file can be compiled using:

clojure -X:uberjar

clojure -X:test:runner

The project is comprised of four source files & supporting documents/tests

This file contains the project entry point for generating jars via :gen-class and does the stateful job of placing the user into a command loop, this is separated out so that the underlying machinery can be tested

This file contains the command routing and parsing required to turn string commands like I 2 3 into something our program understands

We are using cli-matic to help validate and parse those commands along with functions that are organising our data before forwarding each command on to our main file image.clj

Within our clj-matic "router" we are also adding our new canvas states to a history atom, while this is not required to reach our immediate goals it maybe helpful in the future to implement undo

This file is to support the history preservation operations to the canvas, at the moment the canvas states are just stored in memory but separating state operations out early makes it easier to keep the state at the edge of the system

The main logic for the application is found here, for most functions we're making use of clojure.core.matrix to create new canvas states and we're using the-flood version 1.1 to handle the flood filling behaviour

Example based tests are specified in resources/examples.txt tests are seperated by - - - -

lines that start with > are considered input commands, many can be executed in order as they would be written by the user inside the application

The lines below > are considered the expected outputs for printing the canvases

When tests are run the examples file is read and we dynamically run the user commands from the file and then compare our program's result with our expected result in the .txt file

Lots of little bugs were found as part of this process so confidence is quite high for time invested but we could always implement other kinds of testing

At the moment the canvas state is fully immutable which means after extended use of the application would theoretically exceed memory constraints, we could start removing history from the beginning of the atom after a certain amount of changes have been persisted to help prevent this

Flood fill is implemented from a library to help speed up development but on larger canvas sizes this can freeze the application, to make this apparent clj-paint now prints :OK when work has finished so the user can tell if a command is taking longer than expected

If slowness becomes a problem we could look at implementing a more efficient flood fill function something similar to https://silven.nu/posts/4-parallel-flood-fil.html to help improve performance

If we can improve this upstream we can potentially get away with making no change to our application beyond bumping the flood fill library version

Writing state out to disk would allow users to save and load previously made images from clj-paint

Copyright © 2021 Adriansmith

EPLv1.0 is just the default for projects generated by clj-new: you are not required to open source this project, nor are you required to use EPLv1.0! Feel free to remove or change the LICENSE file and remove or update this section of the README.md file!

Distributed under the Eclipse Public License version 1.0.