swyddfa / arlunio Goto Github PK

1. I just want an excuse to play with click 😄
2. I think there could be real benefits from having a cli interface to some aspects of stylo.

stylo has been designed in theory to support multiple colorspaces. However I know for a fact that there are places in the code that are specific to a particular colorspace so we need to add another colorspace and work it through end-to-end to flush out these dependent parts of the code

• How to use existing parameter group implementations
• How to write your own parameter group implementations
• How to declare new parameter group implementations
• How the parameter group factory works

At its simplest arlunio is a three step process. Everything else is sugar to make it easier to push stuff through that process.

The images are a completely untested part of the codebase, it would be good to put some tests in there.

At the moment everything is timeless, while this is advertised as a library for making animations making an animation boils down to shoving everything in a for-loop. It would be good to introduce some notion of time to make it easier to introduce a time element into images

There is a lot of "magic" here, it really needs documenting and justifying

Image objects such as LayeredImage currently take an option scale that can control the range of values contained in the underlying domain.

They should also take parameters like the following

• origin: This should control the general position of the origin, taking values like c,ul,ur,lr,ll
• dx: This should shift everything in the image in the x direction
• dy: This should shift everything in the image in the y direction

• How to build it
• How the build works
• How the documentation is deployed

e.g.

• never work on master
• all PRs against develop

After moving the image related code into its own submodule, doctest builds on travis are completely broken with sphinx reporting that there is no module stylo.images

/home/travis/build/alcarney/stylo/docs/developing/reference/channel.rst:4: WARNING: autodoc: failed to import class 'Channel' from module 'stylo.interpolate'; the following exception was raised:
Traceback (most recent call last):
  File "/home/travis/virtualenv/python3.5.4/lib/python3.5/site-packages/sphinx/ext/autodoc.py", line 658, in import_object
    __import__(self.modname)
  File "/home/travis/virtualenv/python3.5.4/lib/python3.5/site-packages/stylo/__init__.py", line 10, in <module>
    from .images import Image
ImportError: No module named 'stylo.images'

But i have no such issue on my local machine

Currently if I have a shape A and I want to shift it around and make a composite from a few transformed copies of it.

B = A >> translate(1, 0)
C = A >> translate(0, 1)

shape = B | C

However transforms are currently applied to the instance A directly so the result is equivalent to the following

shape = A >> translate(1, 0) >> translate(0, 1)
``
I think this behavior should be changed to be more like the original example as it would be more intuitive and flexible

It appears that at this point in time having a pyproject.toml and using a tool like poetry is a good move to make.

Currently the BaseShapeTest class will only work with shapes that are defined on a RealDomain this is due to a number of the tests using UnitSquare() internally. The class should probably be changed to instead take a domain given in the setUp method along with the shape instance

There are a number of BaseClass BaseClassTest pairs in the library, these are meant to make it easy to extend stylo, document why this is

• Include rationale for using abstract classes
• How this system works
• How to use the system.

If I have two shapes A and B I can create a composite shape C by ORing them together

C = A | B

However if I wanted to say rotate one of these shapes before combining them like so

C = A | (B >> rotate(pi/4))

when I draw the shape C the result is as if I didn't apply the rotation at all.

Another situation is where we want to apply a transform to the result C like so

C = (A | B) >> rotate(pi/4)

the result appears to be one of the sub-shapes disappearing entirely

Let's define what I mean by rendering.

At the moment every image goes through the same basic steps.

1. Discretise a domain
2. Apply that domain to a shape to get the mask
3. Color the pixels in the mask according to the colormap.

But that might not always be the case, for example in the not too distant future there may be colormaps that take their own domain, or colormaps that make use of two or more masks. In these
situations the process for "rendering" will have to be modified - is that the job of images? I'm not convinced, an image such as LayeredImage should only care about combining multiple layers of image data into a final image - not how those layers are produced

stylo has been designed to work with multiple domain families, however I'm pretty sure there are places that are dependent on the RealDomain family. We should add a second family to work it through end to end and flush out these dependent parts

The README on our PyPi project page is not rendering properly I think this is due to a number of reasons

• We have recently added an image to the README and PyPi is not able to resolve URLs that are local to the repository. More info
• I'm trying to be too clever and have the code that is included in the README automatically tested by Sphinx when the documentation is built. However it appears that most rst renderers (such as GitHub's) doesn't recognise the .. testcode:: directive.

So I think it's time to simplfy the README and convert it to Markdown

http://boisgera.github.io/bitstream/

There should also be documentation on how to keep it in sync with the main repository

The stylo.domain._factory module has a lot of "magic", I'm fairly certain this can be rewritten to insted use a function that returns a class

def define_domain(...):
    
    class Domain:
        ....

    return Domain

If someone use the colormap property to change the colorspace in use on a ColorMap the representation of the color should be recomputed so that everything remain consistent

• Why would you want to?
• How to do it

While the code is currently easy to extend (or at least I think it is), that's only half the battle when it comes to potential third party packages.

Do we need some sort of plugin system where packages can register themselves as extensions? What would we gain from such as system?

Things to investigate more

• Entry Points

The tests are potentially an excellent source of reference documentation

• In theory every feature of the library is tested
• They show exactly how to use each feature
• If you include the docstring on the test method, then there is even room for some exposition.
• They are always up to date.

Explore ways in which this information can be exposed to people reading the documentation.

Not entirely sure of the right terminology for this, but the dependencies for stylo are quite heavy considering the only "real" dependencies are numpy and Pillow most of the others are... well extras.

It would be good to be able to have a "minimal" install option by default that installs just what is required to run stylo itself. With the following extras available

• pip install stylo[testing]: Installs the packages required to do imports from the stylo.testing package (currently hypothesis and pytest)
• pip install stylo[interactive]: Installs everything required to use stylo interactively (currently matplotlib and jupyter)

• What are domains?
• How do they relate to everything else?
• How to use them in depth

https://pypi.org/project/colour/

In a previous version of stylo you could take a number of image definitions (think sprite sheet) and then draw them in various positions in a grid (like how platformer game levels are constructed). I'm sure there are plenty of other examples where being able to control the position of sub-images would be useful.

The question though, is this a "core" feature or is this better suited to 3rd party package?

I like the idea of having stylo be a namespace package that way we can have:

• A standard library from stylo.core.xxx import yyy
• A number of "core?" extensions from stylo.ext.xxxx import yyy?
• Third party packages from stylo.ppp.xxx import yyy

However:

• I tried a similar approach with topos and topos-preview and had issues when pip installing them - one package would overwrite the contents of the other making half the code vanish.
• Would we get any tangible benefit from doing this?

Things to investigate more

• Namespace packages

e.g.

• What linting is and what it looks for
• How to run the linting tests.

• Using the @shape decorator
• Making composite shapes based on existing shapes

e.g.

• What needs to be done for a release
• How a release is triggered