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 with Nicco Kunzmann https://niccokunzmann.github.io 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 ====================== At https://pypi.python.org/pypi/knittingpattern 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     https://pypi.python.org/pypi/knittingpattern pip     http://pip.readthedocs.io/en/latest/ Installation from Pypi:     $ python3 -m pip install knittingpattern # Linux     > py -3.4 -m pip install knittingpattern # Windows Documentation upload included! http://pythonhosted.org/knittingpattern/ Documentation (3min) 19:27 ==================== .. note:: Inform users I came across a talk: - https://www.youtube.com/watch?v=x5rGUqRWlK8 - Thoughts of Nicco Kunzmann: http://niccokunzmann.github.io/blog/2016-06-10/Documentation-Driven-Development 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 - pep257: https://www.python.org/dev/peps/pep-0257/   - standard how to put in docstrings in Python     -  Example: Sphinx  3min 19:33 ~~~~~~~~~~~~~~~ - Used for Python - Used for knittingpattern - Several themes available http://www.writethedocs.org/guide/tools/sphinx-themes/ Python file:     https://github.com/AllYarnsAreBeautiful/knittingpattern/blob/master/knittingpattern/Mesh.py Documentation file with sphinx.ext.autodoc:     https://github.com/AllYarnsAreBeautiful/knittingpattern/blob/master/docs/reference/knittingpattern/Mesh.rst Built documentation:     http://knittingpattern.readthedocs.io/en/latest/reference/knittingpattern/Mesh.html#knittingpattern.Mesh.Mesh.__repr__     See the return type str, Intersphinx can reference across documentations.     Intersphinx uses objects inventory, hosted with the documentation:         http://knittingpattern.readthedocs.io/en/latest/objects.inv 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   example: http://pythonhosted.org/knittingpattern/ - readthedocs.io   several branches, versions, languages   Example: http://knittingpattern.readthedocs.io/en/latest/ - wiki pages -  Code Testing 2min 19:38 ============ .. note:: Tests show the presence of mistakes, not their absence. What can be tested:…

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: Installation. The app and dmg files are built. 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. 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). 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…

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

Knitting Pattern Conversion

We can convert knitting patterns to svg (middle) which proves the concept but is still a different from the original (right) Our goal is to create a knit-work exchange format. This includes the conversion to a scematic view of the knittting pattern as svg - to make it endlessly scalable and allow conversions to png, pdf and paper. This week we ended the prototype of the SVG conversion. The positions are a bit off and instructions are placed above eachother. Most of the work is done. We are also able to load and save knitting patterns a png files. (1) (2) (3) We loaded them (1), converted them to a knitting pattern and then saved them again as png (2). This way we path our way towards using the ayab software and actually knitting the pattern. Also we can convert the knitting pattern to an svg consisting all of knit instructions (3). Here is the code for it in version 0.0.8. >>> import knittingpattern >>> from knittingpattern.convert.image_to_knittingpattern import * >>> convert_image_to_knitting_pattern.path("head-band.png").temporary_path(".json") "head-band.json" >>> k = knittingpattern.load_from_path("head-band.json") >>> k.to_svg(10).temporary_path(".svg") "head-band.svg" Here you can see a proof of concept video:  

Continue ReadingKnitting Pattern Conversion

A look into the knitting pattern format

We are currently working on a format that allows to exchange instructions for knitting independent of how it is going to be knit: by a machine like Brother, Pfaff, or by hand. For this to be possible we need the format to be as general as possible and have no ties to a specific form of knitting. At some point the transition to a format specifically designed for a certain machine is necessary. However, we believe that it is possible to have a format so general that instructions for all types of machines and for hand knitting could be generated from it. We have decided to use JSON as the language to describe the format, because it is machine readable and human readable at the same time. The structure of our format follows the rows in knitting. Our first thought was about creating a format that would describe how meshes are connected and how the thread travels. This would allow for great flexibility and it should be possible to represent everything like this. However, we have decided against it, because we think this format would be quite complicated (different orientations and twists of meshes possible, different threads for multiple colors...) and would get quite big very quickly, because of all the different properties for each mesh and because of all the meshes. Furthermore, and this point is probably more important, knitters do not think this way. If we had a format like that, it would not be easy to understand what was happening for human beings. Whenever I knit by hand, I never think about how all the meshes are connected by this single thread I am using. I always think about which operations I am performing when knitting in each row. Instructions for creating patterns in knitting are also written this way. They give the knitter a set of knitting instructions to do and possibly repeat. We have concluded, that most knitters think in knitting operations performed rather than connections between meshes. Knitting instructions from Garnstudio's Café. Therefore we have decided to base our format on knitting instructions/operations. The most common instructions probably are: knit, purl, cast on, bind off, knit two together, yarn over. Of course for increases and decreases there are many different operations which work in a similar way but have slight differences (e.g. skp, k2tog). Since in knitting many things are possible and it is unlikely that we ever manage to create a complete list of all the possible operations you can perform in knitting we have decided to have a very open format, that allows the definition of new instructions. Instructions are also defined in JSON format. Here is an example, the "k2tog" instruction: [ { "type" : "k2tog", "title" : { "en-en" : "Knit 2 Together" }, "number of consumed meshes" : 2, "description" : { "wikipedia" : { "en-en" : "https://en.wikipedia.org/wiki/Knitting_abbreviations#Types_of_knitting_abbreviations" }, "text" : { "en-en" : "Knit two stitches together, as if they were one stitch." } } } ]  …

Continue ReadingA look into the knitting pattern format

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. Select pattern area using square/free hand tools. Then edit colour values of selected area. Show colour regions of selected area/whole pattern and easily edit their colour values. 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 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. Drawing Tool 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 . This sums up the most…

Continue ReadingFunctionality of KnitWeb Application

KnitWeb Localization

  • Post author:
  • Post category:FOSSASIA

Why Localization important Localization is the process of adapting, translating and customizing a product for a specific locale or cultural conventions. Localization distinguishes a good web front end from a truly successful one. Today English is a priority language to be learning to use computers. Having Localization we can gain benefits such as, no need to local users to learn English first, Reduce amount of training and localization brings additional value.  To improve localization community of volunteers needs to get together and first establish a guiding set of terms to guarantee accurate and consistent translation. Community is the strongest part for an Open Source project. Translation process can be improved by making sure that efforts in translations are consistent and structured. So the lots of local users can enjoy KnitWeb and hopefully become a part of the community. How Localization work on KnitWeb KnitWeb construct elements of the interface using JavaScript dynamically. Retrieve the correct localized string in JavaScript is the most important part for localize an app like KnitWeb. For the Localization I used 3 types of files i.e. languge.properties, locles.ini and l10.js. .properties files (en.properties, ge.properties): These files contain the translations of strings used in the KnitWeb. Each line is the translation of a single string in “name=value” format; name is an identifier for this string, It is used to map the string; value is the translation of the string in particular language. Inside ge.properties #Inputs input_port=Port input_machine=Maschine: Inside si.properties #Inputs input_port=කවුළුව input_machine=යන්ත්‍රය: locales.ini : locales.ini includes which is the default language in case app does not support current language, what type of other locales KnitWeb supports and the location of the each translated file. l10n.js: JavaScript library. Automatic localization of strings appearing in your app's HTML. Provides a JavaScript API your app can use to retrieve localized strings( get, getLanguage, setLanguage, getDirection)

Continue ReadingKnitWeb Localization

Exception handler in KnitLib

  • Post author:
  • Post category:FOSSASIA

An exception is an error that happens during the execution of a program. It is important to have exception handler in KnitLib to handle and deal with errors automatically. Many standard libraries define their own exceptions to report errors that may occur in functions they define.  Depending on the kind of error in knitlib (“communication error”, “pattern not found error”, etc.. ). The exception handler module in the knitlib can handle the exception and the knitlib can be continued afterwards with the previously saved data. Define exceptions as classes Exception can be defined as classes which do any other class can do, but are usually kept simple, often only offering a number of attributes that allow information about the error to be extracted by handlers for the exception. When creating a library like KnitLib which can raise several distinct errors, a common practice is to create a base class for exceptions and subclass that to create specific exception classes for different error conditions.

Continue ReadingException handler in KnitLib

Importance of the test cases for the KnitLib

Having test cases is very important especially for a library like KnitLib because using test cases; we can clearly test particular fields.  In KnitLib, test cases show the information of how the KnitLib should be checked. Also test cases help for new contributors to understand about the KnitLib. There are several test cases for the current KnitLib implementation such as tests on ayab communication, tests on ayab image, tests on command line interface, tests on KnitPat module and tests on knitting plugin. For an example in ayab communication there are several important functions have been tested. Test on closing serial port communication, test on opening serial port with a baud rate of 115200 which ayab fits, tests on sending start message to the controller, tests on sending line of data via serial port and tests on reading line from serial communication.  Most of these tests have been done using mock tests. Mock is a python library to test in python.  Using mocks we can replace parts of our system with mock objects and have assertions about how they have been used. We can easily represent some complex objects without having to manually set up stubs as mock objects during a test. It is very important to improve further test cases on the KnitLib because with the help of good test cases we can guarantee that the KnitLib’s features and functionalities should be working great. Regards, Shiluka.

Continue ReadingImportance of the test cases for the KnitLib