Knitting Applications

Introducing new Developers to Your Project

You may want to introduce new developers into your project. This is either to get help or to allow the community to guide the project. In this blog post, I want to present how I believe an introduction can be designed.

(1) A Landing Page

For the knitting projects, I have designed a landing page, knitting.fossasia.org. It features all related projects with links to documentation and source code as well as a short summary what it is about. You can read more about the landing page in this blog post.

The idea is to to add short snippets of information that allow new developers to explore all available options to enter the projects. This may be contact information, documentation and videos.

(2) Setup Instructions

Especially for the projects I worked on, I created a introduction videos on how to set up your development environment. This could have been in text form, too.

The problem for new developers is often that the start takes a long time. Instead of focusing on the issue they would like to solve, it sometimes takes several hours to set up the environment with lots of possibilities to make mistakes.

In order to speed up the development environment setup, you can provide additional information. The CoderDojo Zen platform has its own landing page for new developers and a description of the steps to take to setup the development environment. In the case of the knitting projects, we have YouTube video tutorials which show the necessary steps.

(3) Introduction Events

You can participate in events to show your projects to other people.

With the knitting projects, we will participate at the Maker Faire Berlin 2016.There may be local user groups where you can present the work and the learnings from them.

Google Code-In is an excellent opportunity to allow new young developers to add code to your projects and document them. You can apply as a mentor and add tasks. A first task for beginners may be to get the project running on their computer. Another task could then be to either use it in a special way and document it or to solve an issue which is easy enough.

In the following Google Summer of Code your project can be used again. You can apply as a mentor for your project and help other students to work on what you left behind.

Summary

I listed some ways I will perform to get the projects I worked on into the community. I hope they may have been an inspiration for other people who read this. If you like to contribute new ways, you can comment šŸ™‚

Continue ReadingIntroducing new Developers to Your Project

Knit Editor Package Overview

In this years Google Summer of Code, we created several Python package. They are all available on the Python Package Index (PyPi) and installable via “pip install”. They are listed on knitting.fossasia.org but their interconnections are shown here.

In the following figure, you can see the different packages created during GSoC with a solid line. Other packages that are used by the “kniteditor” application are shown here with a dotted line.

 

Knit Editor Package Architecture
Knit Editor Package Architecture

Overall, five packages we created. The design is driven by responsibility. Thus the responsibilities of each packages should be clearly separated from the other packages. We describe the responsibilities of the packages as follows:

knittingpattern is the library for converting, loading, saving and manipulating knitting patterns. These patterns include in formation abour how to knit. Unlike a picture this includes more than a color: adding meshes, removing meshes, types of holes, the possibility of non-planar knit pieces ad more.

ObservableList is a list whose content can be observed. Whenever elements are added or removed, this list notifies the observers. This is used by the rows of instructions to provide a more convenient interface.

crc8 computes the crc8 hash from bytes. I did not find a Python library implementing ths functionality so I created it myself. The design follows the design of the hash functions in the Python standard library. This package is used by the AYABInterface package. Through creating a new package, this is also usable by other applications.

AYABInterface controls the knitting machines connected to the AYAB hack. Through the serial interface, it can send messages to the controllers and receive answers. It also provides hint for actions which the user should take in order to produce the desired outcome.

kniteditor contains the user interface to edit knitting patterns and control the knitting machines with the AYAB shield.

All these packages also include installation instructions.

Continue ReadingKnit Editor Package Overview

The new AYABInterface module

One create knit work with knitting machines and the AYAB shield. Therefore, the computer communicates with the machine. This communication shall be done, in the future, with this new library, the AYABInterface.

Here are some design decisions:

Complete vs. Incomplete

The idea is to have the AYAB seperated from the knittingpattern format. The knittingpattern format is an incomplete format that can be extended for any use case.Ā  In contrast, the AYAB machine has a complete instruction set. The knittingpattern format is a means to transform these formats into different complete instruction sets. They should be convertible but not mixed.

Desciptive vs. Imperative

The idea is to be able to pass the format to the AYABInterface as a description. As much knowledge about the behavior is capsuled in the AYABInterface module. With this striving, we are less prone to intermix concerns across the applications.

Responsibilty Driven Design

I see these separated responsibilities:

  • A communication part focusing on the protocol to talk and the messages sent across the wire. It is an interpreter of the protocol, transforming it from bytes to objects.
  • A configuration that is passed to the interface
  • Different Machines types supported.
  • Actions the user shall perform.

Different Representations

I see these representations:

  • Commands are transferred across the wire. (PySerial)
  • For each movement of a carriage, the needles are used and put into a new position, B or D. (communication)
  • We would like to knit a list of rows with different colors. (interface)
    • Holes can be described by a list of orders in which meshes are moved to other locations, i.e. on needle 1 we can find mesh 1, on needle 2 we find mesh 2 first and then mesh 3, so mesh 2 and mesh 3 are knit together in the following step
  • The knitting pattern format.

Actions and Information for the User

The user should be informed about actions to take. These actions should not be in the form of text but rather in the form of an object that represents the action, i.e. [“move”, “this carriage”, “from right to left”]. This way, they can be adequately represented in the UI and translated somewhere central in the UI.

Summary

The new design separates concerns and allows testing. The bridge between the machine and the knittnigpattern format are primitive, descriptive objects such as lists and integers.

Continue ReadingThe new AYABInterface module

Transcript from the Python Toolbox 101

At the Python User Group Berlin, I lead a talk/discussion about free-of-charge tools for open-source development based on what we use GSoC. The whole content was in an Etherpad and people could add their ideas.

Because there are a lot of tools, I thought, I would share it with you. Maybe it is of use. Here is the talk:

Python Users Berlin 2016/07/14 Talk & Discussion

 

START: 19:15
Agenda 1min END: 19:15
======
– Example library
– What is code
– Version Control
Ā  – Python Package Index
– …, see headings
– discussion: write down, what does not fit into my structure
Example Library (2min)Ā  19:17
======================
What is Code (2min) 19:19
===================
.. note:: This frames our discussion
– Source files .py, .pyw
– tests
– documentation
– quality
– readability
– bugs and problems
– <3
Configurationsfiles plain Text for editing
Version Control (2min) 19:21
======================
.. note:: Sharing and Collaboration
– no Version Control:
Ā  – Dropbox
Ā  – Google drive
Ā  – Telekom cloud
Ā  – ftp, windows share
– Version Control Tools:
Ā  – git
Ā Ā Ā  – https://github.com
Ā Ā Ā  – https://gitlab.com
Ā Ā Ā  – gitweb own server
Ā Ā Ā  –Ā 
Ā  – mecurial
Ā Ā Ā  – https://bitbucket.org
Ā  – svn
Ā Ā Ā  – http://sourceforge.net/
Ā  – perforce (proprietary)
Ā Ā 
Ā Ā 
Ā Ā 
Ā Ā 
Ā Ā 
Ā Ā 
Python Package Index (3min) 19:24
—————————
.. note:: Shipping to the users
hosts python packages you develop.
Example: “knittingpattern” package
pip
Installation from Pypi:
Ā Ā Ā  $ python3 -m pip install knittingpattern # Linux
Ā Ā Ā  > py -3.4 -m pip install knittingpattern # Windows
Documentation upload included!
Documentation (3min) 19:27
====================
.. note:: Inform users
I came across a talk:
Documentation can be:
– tutorials
– how to
– introduction to the community/development process
– code documentation!!!
– chat
–Ā 
Building the documentation (3min)Ā  19:30
———————————
Formats:
– HTML
– PDF
– reRST
– EPUB
– doc strings in source code
– test?
Tools:
– Sphinx
– doxygen
– doc strings
Ā  – standard how to put in docstrings in Python
Ā Ā Ā  –Ā 
Example: SphinxĀ  3min 19:33
~~~~~~~~~~~~~~~
– Used for Python
– Used for knittingpattern
Python file:
Documentation file with sphinx.ext.autodoc:
Built documentation:
Ā Ā Ā  See the return type str, Intersphinx can reference across documentations.
Ā Ā Ā  Intersphinx uses objects inventory, hosted with the documentation:
Testing the documentation:
Ā Ā Ā  – TODO: link
Ā Ā Ā Ā Ā  – evertying is included in the docs
Ā Ā Ā Ā Ā  – everything that is public is documented
Ā Ā Ā Ā Ā Ā 
Ā Ā Ā Ā Ā  syntax
Ā Ā Ā Ā Ā  – numpyĀ 
Ā Ā Ā Ā Ā  – googleĀ 
Ā Ā Ā Ā Ā  – sphinx
Hosting the Documentation (3min) 19:36
——————————–
Tools:
– pythonhosted
Ā  only latest version
– readthedocs.io
Ā  several branches, versions, languages
– wiki pages
–Ā 
Code Testing 2min 19:38
============
.. note:: Tests show the presence of mistakes, not their absence.
What can be tested:
– features
– style: pep8, pylint,Ā 
– documentation
– complexity
–Ā 
Testing Features with unit tests 4min 19:42
——————————–
code:
Ā Ā Ā  def fib(i): …
Tools with different styles
– unittest
Ā Ā 
Ā Ā Ā  import unittest
Ā Ā Ā  from fibonacci import fib
Ā Ā Ā  class FibonacciTest(unittest.TestCase):
Ā Ā Ā Ā Ā Ā Ā  def testCalculation(self):
Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā  self.assertEqual(fib(0), 0)
Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā  self.assertEqual(fib(1), 1)
Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā  self.assertEqual(fib(5), 5)
Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā  self.assertEqual(fib(10), 55)
Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā  self.assertEqual(fib(20), 6765)
Ā Ā Ā  if __name__ == “__main__”:Ā 
Ā Ā Ā Ā Ā Ā Ā  unittest.main()
Ā 
– doctest
Ā Ā Ā  import doctest
Ā Ā Ā  def fib(n):
Ā Ā Ā Ā Ā Ā Ā  “””Ā 
Ā Ā Ā Ā Ā Ā Ā  Calculates the n-th Fibonacci number iterativelyĀ Ā 
Ā Ā Ā Ā Ā Ā Ā  >>> fib(0)
Ā Ā Ā Ā Ā Ā Ā  0
Ā Ā Ā Ā Ā Ā Ā  >>> fib(1)
Ā Ā Ā Ā Ā Ā Ā  1
Ā Ā Ā Ā Ā Ā Ā  >>> fib(10)Ā 
Ā Ā Ā Ā Ā Ā Ā  55
Ā Ā Ā Ā Ā Ā Ā  >>> fib(15)
Ā Ā Ā Ā Ā Ā Ā  610
Ā Ā Ā Ā Ā Ā Ā  >>>Ā 
Ā Ā Ā Ā Ā Ā Ā  “””
Ā Ā Ā Ā Ā Ā Ā  a, b = 0, 1
Ā Ā Ā Ā Ā Ā Ā  for i in range(n):
Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā  a, b = b, a + b
Ā Ā Ā Ā Ā Ā Ā  return a
Ā Ā Ā  if __name__ == “__main__”:Ā 
Ā Ā Ā Ā Ā Ā Ā  doctest.testmod()
– pytest (works with unittest)
Ā Ā Ā  import pytest
Ā Ā Ā  from fibonacci import fib
Ā Ā Ā Ā 
Ā Ā Ā  @pytest.mark.parametrize(“parameter,value”,[(0, 0), (1, 1), (10, 55), (15, 610)])
Ā Ā Ā  def test_fibonacci(parameter, value):
Ā Ā Ā Ā Ā Ā Ā  assert fib(parameter) == value
– nose tests?
– …
– pyhumber
– assert in code,Ā  PyHamcrest
– Behaviour driven development
Ā  – human test
Automated Test Run & Continuous Integration 2min 19:44
===========================================
.. note::Ā 
Several branches:
– production branch always works
– feature branches
– automated test before feature is put into production
Tools running tests 6min 19:50
——————-
– Travis CI for Mac, Ubuntu
– Appveyor for Windows
Host yourself:
– buildbot
– Hudson
– Jenkins
– Teamcity
– circle CI
Ā  + selenium for website test
–Ā 
– …?????!!!!!!
Tools for code quality 4min 19:54
———————-
– landscape
Ā  complexity, style, documentation
Ā  – libraries are available separately
Ā Ā Ā  – flake8
Ā Ā Ā  – destinate
Ā Ā Ā  – pep257
– codeclimate
Ā  code duplication, code coverage
Ā  – libraries are available separately
– PyCharm
Ā  – integrated what landscape hasĀ 
Ā  – + complexity
Bugs, Issues, Pull Requests, Milestones 4min 19:58
=======================================
.. note:: this is also a way to get people into the project
1. find bug
2. open issue if big bug, discuss
3. create pull request
4. merge
5. deploy
– github
Ā  issue tracker
Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā  http://www.appveyor.com/docs/branches#build-on-tags-github-and-gitlab-only
– waffle.io – scrumboard
Ā  merge several github issues tracker
– Redmine
– JIRA
– tracĀ 
– github issues + zenhub integrated in github
– gitlab
– gerrit framework that does alternative checking https://www.gerritcodereview.com/
Ā  1. propose change
Ā  2. test
Ā  3. someone reviews the code
Ā Ā Ā Ā Ā  – X people needed
Ā  QT company uses it
Localization 2min 20:00
============
crowdin.com
Ā Ā Ā  Crowdsourced translation tool:
Ā Ā Ā Ā 
Discussion
– spellchecker is integrated in PyCharm
Ā  – character set
Ā  – new vocabulary
Ā  – not for continuous integration (CI)
– Emacs
Ā  –Ā 
– pylint pluginĀ 
Ā Ā  – not all languages?
– readthedocs
Ā  – add github project,Ā 
Ā  – hosts docs
– sphinx-plugin?
– PyCon testing talk:
Ā Ā Ā  – Hypothesis package
Ā Ā Ā Ā Ā  – tries to break your code
Ā Ā Ā Ā Ā  – throws in a lot of edge cases (huge number, nothing, …)
Ā Ā Ā Ā Ā  -> find obscure edge cases
Ā Ā Ā Ā Ā Ā 
Did someone create a Pylint plugin
– question:
Ā Ā Ā  – cyclomatic code complexity
Ā Ā Ā  – which metrics tools do you know?
Ā Ā Ā  –
Virtual Environment:
Ā Ā Ā  nobody should install everything in the system
Ā Ā Ā  -> switch between different python versions
Ā Ā Ā  – python3-venv
Ā Ā Ā Ā Ā  – slightly different than virtual-env(more mature)
Beginners:
Ā Ā Ā  Windows:
Ā Ā Ā Ā Ā Ā Ā  install Anaconda
Continue ReadingTranscript from the Python Toolbox 101

Deploying a Kivy Application with PyInstaller for Mac OSX with Travis CI to Github

In this sprint for the kniteditor library we focused on automatic deployment for Windows and Mac. The idea: whenever a tag is pushed to Github, a new travis build is triggered. The new built app is uploaded to Github as an “.dmg” file.

Travis

Travis is configured with the “.travis.yml” file which you can see here:

language: python

# see https://docs.travis-ci.com/user/multi-os/
matrix:
  include:
    - os: linux
      python: 3.4
    - os: osx
      language: generic
  allow_failures:
    - os: osx

install:
  - if [ "$TRAVIS_OS_NAME" == "osx"   ] ; then   mac-build/install.sh ; fi

script:
  - if [ "$TRAVIS_OS_NAME" == "osx"   ] ; then   mac-build/test.sh ; fi

before_deploy:
  - if [ "$TRAVIS_OS_NAME" == "osx"   ] ; then cp mac-build/dist/KnitEditor.dmg /Users/travis/KnitEditor.dmg ; fi

deploy:
  # see https://docs.travis-ci.com/user/deployment/releases/
  - provider: releases
    api_key:
      secure: v18ZcrXkIMgyb7mIrKWJYCXMpBmIGYWXhKul4/PL/TVpxtg2f/zfg08qHju7mWnAZYApjTV/EjOwWCtqn/hm2CfPFo=
    file: /Users/travis/KnitEditor.dmg
    on:
      tags: true
      condition:  "\"$TRAVIS_OS_NAME\" == \"osx\""
      repo: AllYarnsAreBeautiful/kniteditor

Note that it builds both Linux and OSX. Thus, for each step one must distinguish. Here, only the OSX parts are shown. These steps are executed:

  1. Installation. The app and dmg files are built.
  2. Testing. The tests are shipped with the app in our case. This allows us to execute them at many more locations – where the user is.
  3. Before Deploy. Somehow Travis did not manage to upload from the original location. Maybe it was a bug. Thus, a absolute path was created for the use in (4).
  4. Deployment to github. In this case we use an API key. One could also use a password.

Installation:

#!/bin/bash
#
# execute with --user to pip install in the user home
#
set -e

HERE="`dirname \"$0\"`"
USER="$1"
cd "$HERE"

brew update

echo "# install python3"
brew install python3
echo -n "Python version: "
python3 --version
python3 -m pip install --upgrade pip

echo "# install pygame"
python3 -m pip uninstall -y pygame || true
# locally compiled pygame version
# see https://bitbucket.org/pygame/pygame/issues/82/homebrew-on-leopard-fails-to-install#comment-636765
brew install sdl sdl_image sdl_mixer sdl_ttf portmidi
brew install mercurial || true
python3 -m pip install $USER hg+http://bitbucket.org/pygame/pygame

echo "# install kivy dependencies"
brew install sdl2 sdl2_image sdl2_ttf sdl2_mixer gstreamer

echo "# install requirements"
python3 -m pip install $USER -I Cython==0.23 \
                       --install-option="--no-cython-compile"
USE_OSX_FRAMEWORKS=0 python3 -m pip install $USER kivy
python3 -m pip uninstall -y Cython==0.23
python3 -m pip install $USER -r ../requirements.txt
python3 -m pip install $USER -r ../test-requirements.txt
python3 -m pip install $USER PyInstaller

./build.sh $USER

The first step is to update brew. It cost me 4 hours to find this bug, 2 hours to work around it before. If brew is not updated, Python 3.4 is installed instead of Python 3.5.

Then, Python, Pygame as the window provider for Kivy is installed, and the other requirements. It goes on with the build step. While installation is executed once on a personal Mac, the build step is executed several times, when the source code is changed.

#!/bin/bash
#
# execute with --user to make pip install in the user home
#
set -e

HERE="`dirname \"$0\"`"
USER="$1"
cd "$HERE"

(
  cd ..

  echo "# removing old installation of kniteditor"
  python3 -m pip uninstall -y kniteditor || true

  echo "# build the distribution"
  python3 -m pip install $USER wheel
  python3 setup.py sdist --formats=zip
  python3 setup.py bdist_wheel
  python3 -m pip uninstall -y wheel

  echo "# install the current version from the build"
  python3 -m pip install $USER --upgrade dist/kniteditor-`linux-build/package_version`.zip

  echo "# install test requirements"
  python3 -m pip install $USER --upgrade -r test-requirements.txt
)

echo "# build the app"
# see https://pythonhosted.org/PyInstaller/usage.html
python3 -m PyInstaller -d -y KnitEditor.spec

echo "# create the .dmg file"
# see http://stackoverflow.com/a/367826/1320237
KNITEDITOR_DMG="`pwd`/dist/KnitEditor.dmg"
rm -f "$KNITEDITOR_DMG"
hdiutil create -srcfolder dist/KnitEditor.app "$KNITEDITOR_DMG"

echo "The installer can be found in \"$KNITEDITOR_DMG\"."

In the first steps we install the kniteditor from the built “sdist”Ā  zip file. This way we can uninstall it with pip. Also, the dependencies are installed. Then, PyInstaller is invoked with a spec and then the .dmg file is created.

The spec looks like this:

# -*- mode: python -*-

import sys
site_packages = [path for path in sys.path if path.rstrip("/\\").endswith('site-packages')]
print("site_packages:", site_packages)

from kivy.tools.packaging.pyinstaller_hooks import get_deps_all, \
    hookspath, runtime_hooks

block_cipher = None

added_files = [(site_packages_, ".") for site_packages_ in site_packages]

kwargs = get_deps_all()
kwargs["datas"] = added_files
kwargs["hiddenimports"] += ['queue', 'unittest', 'unittest.mock']


a = Analysis(['_KnitEditor.py'],
             pathex=[],
             binaries=None,
             win_no_prefer_redirects=False,
             win_private_assemblies=False,
             cipher=block_cipher,
             hookspath=hookspath(),
             runtime_hooks=runtime_hooks(),
             **kwargs)
pyz = PYZ(a.pure, a.zipped_data,
             cipher=block_cipher)
exe = EXE(pyz,
          a.scripts,
          exclude_binaries=True,
          name='KnitEditorX',
          debug=False,
          strip=False,
          upx=True,
          console=True )
coll = COLLECT(exe,
               a.binaries,
               a.zipfiles,
               a.datas,
               strip=False,
               upx=True,
               name='KnitEditor')
app = BUNDLE(coll,
             name='KnitEditor.app',
             icon=None,
             bundle_identifier="com.ayab-knitting.KnitEditor")

Note, that all files in all site-packages are included. This way, we do not need to cope with missing modules. Also, there are three different names for

  • the entry script “_KnitEditor.py”
  • the executable “KnitEditorX”
  • the library “kniteditor”

While on the command line, OSX is case sensitive, it is not sensitive on the file system. Thus, if one of the names is the same, we can get errors durig the PyInstaller build.

Lessons learned

Do “brew update” on travis.

Use absolute paths for deployment on Mac OSX travis.

Never use the same names in PyInstaller for the main script, a library and the executable. Otherwise you get a “not a directory” or “not a file” error.

Travis OSX build max out from time to time. It is much faster to have a Mac computer there, to create the scripts.

Continue ReadingDeploying a Kivy Application with PyInstaller for Mac OSX with Travis CI to Github

DesignaKnit

I started a conversation on strickforum.de and was inspired to take a closer look at DesignaKnit 8.

A free Demo version of DesignaKnit is available which cannot save changes to patterns or shapes and cannot connect to a knitting machine. Otherwise all functionality is available.

DesignaKnit contains:

  • an editor for color patterns
  • an editor for shapes or sewing patterns
  • a shape library
  • a tool for converting images to patterns
  • interactive knitting

Patterns can be applied to shapes.

I did not look very closely at the editors because I do not know much about pattern generation, especially shape or sewing patterns. And the editor for the color patterns did not work for me.

Interactive Knitting:
I took a look at some of the features available in the interactive knitting. There are some interesting features we would also like to implement.

I was not able to take in all the functions available. I could not connect it to a machine and I am still a beginner with knitting machines, which is why I am probably missing some features which make life easier.

The interactive knitting support has several views:

  • overview of knit piece which also shows the position of the carriage
  • view for next row to be knit, some rows around for context
  • view for yarn colors in use and visualization that shows which yarn is currently in the carriage and being knit
  • view for instructions to the human, which also contains
    • row counter as it should be on the machine
    • counter for row in the piece being knit
    • counter for row in pattern
    • information on start and stop needle on machine

DesignaKnit

DesignaKnit can be configured to play sounds when an action, like decreasing the number of meshes, needs to be taken. Voice cuing is also possible. Furthermore, the view for the instructions for the human can flash yellow and displays what step needs to be completed by the human next. In the image above the number of meshes should be decreased by 6 on the right side.

Ideas for our interactive knitting support:
The idea of extra audio and visual cuing is very interesting and we are considering also having this option in our interface. We are not yet sure how we will organize all the information, but the information we will show to the user will be similar to what is shown in DesignaKnit.

The interface for DesignaKnit serves its purpose well. However, we think we can create something that is a little more appealing to the eye.
To keep our Design of the user interface clean and simple we are designing for mobile devices first.

 

Continue ReadingDesignaKnit

How to create a Windows Installer from tagged commits

I working on an open-source Python project, an editor for knit work called the “KnitEditor”. Development takes place at Github. Here, I would like to give some insight in how we automated deployment of the application to a Windows installer.

The process works like this:

  1. Create a tag with git and push it to Github.
  2. AppVeyor build the application.
  3. AppVeyor pushes the application to the Github release.

(1) Create a tag and push it

Tags should reflect the version of the software. Version “0.0.1” is in tag “v0.0.1”. We automated the tagging with the “setup.py” in the repository. Now, you can run

py -3.4 setup.py tag_and_deploy

Which checks that there is no such tag already. Several commits have the same version, so, we like to make sure that we do not have two versions with the same name. Also, this can only be executed on the master branch. This way, the software has gone through all the automated quality assurance. Here is the code from the setup.py:

from distutils.core import Command
# ...
class TagAndDeployCommand(Command):

    description = "Create a git tag for this version and push it to origin."\
                  "To trigger a travis-ci build and and deploy."
    user_options = []
    name = "tag_and_deploy"
    remote = "origin"
    branch = "master"

    def initialize_options(self):
        pass

    def finalize_options(self):
        pass

    def run(self):
        if subprocess.call(["git", "--version"]) != 0:
            print("ERROR:\n\tPlease install git.")
            exit(1)
        status_lines = subprocess.check_output(
            ["git", "status"]).splitlines()
        current_branch = status_lines[0].strip().split()[-1].decode()
        print("On branch {}.".format(current_branch))
        if current_branch != self.branch:
            print("ERROR:\n\tNew tags can only be made from branch"
                  " \"{}\".".format(self.branch))
            print("\tYou can use \"git checkout {}\" to switch"
                  " the branch.".format(self.branch))
            exit(1)
        tags_output = subprocess.check_output(["git", "tag"])
        tags = [tag.strip().decode() for tag in tags_output.splitlines()]
        tag = "v" + __version__
        if tag in tags:
            print("Warning: \n\tTag {} already exists.".format(tag))
            print("\tEdit the version information in {}".format(
                    os.path.join(HERE, PACKAGE_NAME, "__init__.py")
                ))
        else:
            print("Creating tag \"{}\".".format(tag))
            subprocess.check_call(["git", "tag", tag])
        print("Pushing tag \"{}\" to remote \"{}\"."
              "".format(tag, self.remote))
        subprocess.check_call(["git", "push", self.remote, tag])
# ...
SETUPTOOLS_METADATA = dict(
# ...
    cmdclass={
# ...
        TagAndDeployCommand.name: TagAndDeployCommad
    },
)
# ...
if __name__ == "__main__":
    import setuptools
    METADATA.update(SETUPTOOLS_METADATA)
    setuptools.setup(**METADATA) # METADATA can be found in several other

Above, you can see a “distutils” command that executed git through the command line interface.

(2) AppVeyor builds the application

As mentioned above, you can configure AppVeyor to build your application. Here are some parts of the “appveyor.yml” file, that I comment on inline:

# see https://packaging.python.org/appveyor/#adding-appveyor-support-to-your-project
environment:
  PYPI_USERNAME: niccokunzmann3
  PYPI_PASSWORD:
    secure: Gxrd9WI60wyczr9mHtiQHvJ45Oq0UyQZNrvUtKs2D5w=

  # For Python versions available on Appveyor, see
  # http://www.appveyor.com/docs/installed-software#python
  # The list here is complete (excluding Python 2.6, which
  # isn't covered by this document) at the time of writing.

  # we only need Python 3.4 for kivy
  PYTHON: "C:\\Python34"


install:
  - "%PYTHON%\\python.exe -m pip install docutils pygments pypiwin32 kivy.deps.sdl2 kivy.deps.glew"
  - "%PYTHON%\\python.exe -m pip install -r requirements.txt"
  - "%PYTHON%\\python.exe -m pip install -r test-requirements.txt"
  - "%PYTHON%\\python.exe setup.py install"
  
build_script:
- cmd: cmd /c windows-build\build.bat

test_script:
  # Put your test command here.
  # If you don't need to build C extensions on 64-bit Python 3.3 or 3.4,
  # you can remove "build.cmd" from the front of the command, as it's
  # only needed to support those cases.
  # Note that you must use the environment variable %PYTHON% to refer to
  # the interpreter you're using - Appveyor does not do anything special
  # to put the Python version you want to use on PATH.
  - windows-build\dist\KnitEditor\KnitEditor.exe /test
  - "%PYTHON%\\python.exe -m pytest --pep8 kniteditor"

artifacts:
  # bdist_wheel puts your built wheel in the dist directory
- path: dist/*
  name: distribution
- path: windows-build/dist/Installer/KnitEditorInstaller.exe
  name: installer
- path: windows-build/dist/KnitEditor
  name: standalone

deploy:
- provider: GitHub
  # http://www.appveyor.com/docs/deployment/github
  tag: $(APPVEYOR_REPO_TAG_NAME)
  description: "Release $(APPVEYOR_REPO_TAG_NAME)"
  auth_token:
    secure: j1EbCI55pgsetM/QyptIM/QDZC3SR1i4Xno6jjJt9MNQRHsBrFiod0dsuS9lpcC7
  artifact: installer
  force_update: true
  draft: false
  prerelease: false
  on:
    branch: master                 # release from master branch only
    appveyor_repo_tag: true        # deploy on tag push only

Note that the line

  - windows-build\dist\KnitEditor\KnitEditor.exe /test

executes the tests in the built application.

These commands are executed to build the application and are executed by this step:

build_script:
- cmd: cmd /c windows-build\build.bat

"%PYTHON%\python.exe" -m pip install pyinstaller

The line above installs pyinstaller

"%PYTHON%\python.exe" -m PyInstaller KnitEditor.spec

The line above uses pyinstaller to create an executable from the specification.

"Inno Setup 5\ISCC.exe" KnitEditor.iss

The line above uses Inno Setup to create the Installer for the built application.

(3) Deploy to Github

As you can see in the “appveyor.yml” file, the resulting executable is listed as an artifact. Artifacts can be downloaded directly from appveyor or used to deploy. In this case, we use the github deploy, which can be customized via the UI of appveyor.

- path: windows-build/dist/Installer/KnitEditorInstaller.exe
  name: installer
deploy:
- provider: GitHub
  # http://www.appveyor.com/docs/deployment/github
  tag: $(APPVEYOR_REPO_TAG_NAME)
  description: "Release $(APPVEYOR_REPO_TAG_NAME)"
  auth_token:
    secure: j1EbCI55pgsetM/QyptIM/QDZC3SR1i4Xno6jjJt9MNQRHsBrFiod0dsuS9lpcC7
  artifact: installer
  force_update: true
  draft: false
  prerelease: false
  on:
    branch: master                 # release from master branch only
    appveyor_repo_tag: true        # deploy on tag push only

Summary

Now, every time we push a tag to Github, AppVeyor build a new installer for our application.

Continue ReadingHow to create a Windows Installer from tagged commits

Towards a unified digital aproach to knitting

Our idea is to create a knitting library for a format that allows conversion of knitting projects, patterns and tutorials. Usually, communities will only focus on the knitting format for their machines. Our approach should be different and be able to support any knitting communities efforts.

Here is our strategy to achieve this:

  • We connect to different communities to get a broader view on what their needs are.
  • Our knitting format is based on knitting instructions like knit, purl, yarn over, skp. We found a comprehensive list on Wikipedia.

Other Communities

From time to time we meet with other people who also knit and could use our software.

First, we met with Viktoria from ETIB Berlin. She taught us a lot about knitting, how she does it, that almost everything could be created from one peace with the machine. Also, that AYAB is used for lace patterns. We saw examples where she let meshes fall so that larger holes were created. Our goal is to support laces in the file format.Ā  Color patterns should be possible across sewing edges.

We are also in touch with Valentina Project. With their software we would be able to connect to yet another community and use their sewing patterns for custom-fit clothes.

We got in touch with Kniterate. They and we share a lot of goals. Because they create a startup, they are very cautious what they release. They focus on their open-source knitting machine first and later on the software. They already created an editor much like we imagined ours to be, but as a web application. A way of collaboration could be that we understand their file format and see how we can support it.

Only talking about our GSoC project is worth it as other people may have seen alike at Maker Faires and other hacky places. We have the chance to bring communities and efforts together.

Knitting Format

A universal knitting format has many concerns:

  • Languages of users differ
  • It should be possible to knit by hand
  • Mesh sizes and wool differ
  • Different knitting machines with different abilities
  • A knitting format for exchange is never complete. A knitting format for machines must be complete.

In contrast to a knitting format for a automatic machine, it is possible, to have machines operate in semi-automatic modes or just to knit by hand. In both cases, meshes could be changed in a way that was never foreseen. This is why we did not base it on meshes and mesh types but rather on instructions – closer to the mental model of the knitters who perform instructions with their hand.

Some of the instructions are understood by the machines, some could be adapted a bit so the machine can do it automatically or faster and some are still necessary to be done by hand. We created a Python module for that, “knittingpattern“. We work on it in a test-driven way.

 

Continue ReadingTowards a unified digital aproach to knitting

Functionality of KnitWeb Application

Hi Everyone,

In this blog post I will show what are the functionalities implemented in KnitWeb application. First of all let us look into why there is a web application to get a knitting job done. It’s simple. Going for a web application is the best way to acheive platform independence among all the knit app firmware. So the if the hardware level functionality can be abstracted out to a separate library then the web application can use that and provide a common interface to all different knitting application platforms. This is what we have been doing in this GSoC, to provide a common platform and interface for all open source knit app solutions.

So let’s look at the KnitWeb Functionality. KnitWeb consists of two major components, KnitWeb front end and KnitWeb back end logic. KnitWeb front end consists of a pattern editor for edit loaded patterns to workspace, Simulator for show knitting progress and a drawing tool for draw a pattern from scratch. Therefore Pattern editor component is used for easily edit the pattern before send for knitting.

Knitting Simulator is used for render knitting progress to the user with a enhanced user experience. It also consists of main controls for knitting job which user can start/pause/stop a job while knitting.

KnitWeb Drawing tool is used to generate a pattern from a scratch. It provides basic drawing tools including pencil, line, basic shapes and color palette. It also used for replicate a pattern from a existing pattern or a image. Then user can export it to the workspace to continue knitting job.

Pattern Editor Usage

Pattern editor gives following functionality to the users

  • Loads the pattern according to number of rows and columns(stitches) to the editor. Pattern is pixelated as the defined number of rows and columns.

Screenshot from 2015-08-25 08:42:41

  • Select pattern area using square/free hand tools. Then edit colour values of selected area.

Screenshot from 2015-08-25 08:57:28Screenshot from 2015-08-25 08:59:53

  • Show colour regions of selected area/whole pattern and easily edit their colour values.

Screenshot from 2015-08-25 09:08:03

  • Configure machine type and Available ports before creating a knit job. In this step knit web client is communicating with the knit lib server to get those information. After that user can click proceed knitting button to create a knit job.

Knitting Simulator Usage

Screenshot from 2015-08-25 12:14:40

  • Knitting simulator provides knitting progress to the user with enhanced user experience. Current knitting progress is shown to the user as above and also with a progress bar.
  • Knitting simulator window consists of other meta data input needed for configure knitting pattern(knitpat) file such as Start Line, Start Needle, Stop Needle, Number of colours used etc.

Screenshot from 2015-08-25 12:19:33

Drawing Tool

Screenshot from 2015-08-25 12:25:19

  • Drawing tool is used to generate a pattern from scratch or design patterns by replicating image or a texture.
  • After editing finished pattern can be exported to the workspace.

Apart from the above mentioned components edited patterns at the pattern editor can be downloaded as a image file. Also multi-language translation is added by @shiluka to the knit web interface. following is the translation for german language

.Screenshot from 2015-08-25 09:36:08

This sums up the most critical functionalities of knitweb application. I would like to continuously contribute to FashionTec as this inspired me to research and do things that I have not done before. :).

Also here is a little demo on the functionality of knit web. demo link

Thank You šŸ™‚

Continue ReadingFunctionality of KnitWeb Application

Knitting machine abstractions for Knitlib

Hello, during the last weeks we have been working on Knitlib and Knitpat, a knitting machine control library and a standardized format that allows for exchange and storage of patterns.

In order to achieve a common platform for knitting machine development we have the need to abstract away implementation details that can difficult the generic usage of the lib, while keeping extensible and powerful control features.Ā Among the most important abstractions developed for Knitlib is the Knitting Machine Finite State Machine, an abstract representation of the procedures needed to operate a knitting machine.

BaseKnittingPlugin
BaseKnittingPlugin, the basis of knitlib’sĀ machine knitting controller plugins.

The architecture of Knitlib allows for easy integration of different knitting machine plugins for varied use cases, hardware, and software protocols. All functions of the plugin are non blocking except for .knit(), which is blocking due to the physical interaction needed in order to execute this command. To ease usage and to enable more versatile behaviour from theĀ .knit()Ā function, without limiting the interaction facilities needed for operation, the callback infrastructure allows for blocking and non-blocking callbacks from the Plugin to the machine operator (the Knitlib client), such as Information, Warnings, Error Notifications or Mechanical Required Actions (moving spools, switches, needles, etc). Callbacks abstract away the notification and interaction paradigms from the plugin, allowing for simpler behaviour, a more elegant design and ease of testing. Callbacks also allow for future plugins to not take care into implementing user interfaces, but to focus on functionality.

The pending remaining challenge is to standardize configuration options, flags and settings in order to allow forĀ UI that respond to each plugin requirements and options, and to specify which features are supported on each machine plugin. Insofar, most of the standardization has been done on Knitpat, but some specifications such as physical resource assignation (Serial Ports, input streams, etc) are still to be implemented soon.

Thank you, and I hope this article helps you to understand the software architecture and design patterns of the implementation of Knitlib.

Regards,

Sebastian

Continue ReadingKnitting machine abstractions for Knitlib