fossasia / knitlib Goto Github PK

View Code? Open in Web Editor NEW

1.5K 15.0 14.0 224 KB

Knitting backend library for knitting machines

License: GNU Lesser General Public License v3.0

PowerShell 2.45% Batchfile 1.22% Python 96.33%

knitlib's Introduction

knitlib

1. What is Knitlib

Knitlib is a library designed to support the operation of varied knitting machines, mechanisms, and hacks. Knitlib is based on projects like AYAB, PDD, and KnitterStream to control knitting machines. Knitlib features a plugin system for knitting machines and implements an API to control machines' operation, knitting jobs and knitting patterns. The software is based on Python. There also is a Web API. Among the primary tasks is to develop plugins based on this solution to add support for more machines.

1.1 Idea behind Knitlib

1.2 Technical Background of Knitlib

Knitlib is implemented as a Python Library and API. Each machine is supported via a Plugin, allowing for extensibility. Each of the plugins is based on a simple Finite State Machine, with states from machine initialization to operation and knitting process. Among the aplications using the Knitlib API is Knitlib-server, implementing a Webserver and REST / WebSocket endpoints. Clients can also implement message callbacks, errors, notifications and blocking messages in order to provide a good user experience.

2.Development Installation

pip install -r requirements.txt pip install knitlib

3. Usage

4. Development

To run the all tests run:

tox

5. References

6. Documentation

7. Contributing

7.1. Bug reports

Bugs can be reported via the Github issues tracker at https://github.com/fashiontec/knitlib/issues

7.2 Documentation improvements

7.3 Feature requests, Issues, and Feedback

Issues, feature requests and feedback can be reported via the Github issues tracker at https://github.com/fashiontec/knitlib/issues

7.4 Pull Request Guidelines

8. Applications using Knitlib

9. License

Free software: LGPLv3+ license

knitlib's People

Contributors

Stargazers

Watchers

Forkers

shiluka daminisatya souravsingh bakirk haripalbaluja undeadinu leoperon priti24 itsvinayak mobasherah12 12-malak standardgalactic iq-scm

knitlib's Issues

Documentation of the command line tool

Develop serial abstraction testing infrastructure.

A generic serial simulator that can allow for testing without physical hardware.

Adapting KnitterStream

http://borgstrom.ca/2012/05/06/hacking-the-passap-e6000-knitterstream.html

Tests on communication

Full testsuite for AYAB plugin

Will require mocking and emulation of Serial Port

Implement the structure of the library

Improving plugin-user communication API.

Defining a clear way for plugins to communicate errors or status to user facing UIs (load yarn, error has occurred, etc)

File I/O handling for Disk Image

write and read disk image

Implement dummy plugin without any external dependencies

Documentation of KnitLib

Design of the library (knitlib)

Define and implement basic knitting machine plugin functionality.

Knitlib API Version 1 beta release

A formal freeze release of API so we can start building the Web API.
Includes both Plugin API Transparent support, basic machine detection and listing. Includes Knitpat parsing library.

Abstract Machine class for various hacks

Abstract machine class for select various machines (communication, image and controller)

Tests on on Image functions

Development of Generic Demo CLI

Will use Click. http://click.pocoo.org/

Disk emulation (PDD) hack plugin

https://github.com/adafruit/knitting_machine

Implement the functions that are related to image based on ayab

Pattern file integration

Tracking issue for deeper integration of knitpat format to knitlib handlers.

Aiming for

plugin.configure(knitpat_object)

useage.

Implementation of Machine Selector improvements

Part of implementing the basic structure of the library, as mentioned on fossasia/2018.fossasia.org#16 (comment)

Exception handler for the knitlib

Should we use a Plugin framework?

Should we use a plugin frameworks such as Yapsy or others? We can build a modular interface that does not require a plugin manager, yet is still compatible with the aim of a plugin based architecture.

I think some important questions that we need to answer are:

Is hot plugging important for modules? (it might only add complexity)
Can/should we need to deploy library versions in which support for some machines is disabled?
Should we force plugins to be tested as extensibility as the library (I think it is good to do so, however, it means both more testing).

Implement abstract com module

Implement abstract com module to support various kind of plugins such as ayab_comunication plugin

Errors when calling socket callbacks functions on

Traceback (most recent call last):
  File "/usr/lib64/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/usr/lib64/python2.7/threading.py", line 763, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/home/tian/devel/knitlib-webserver/knitlib_webserver.py", line 139, in __emit_socket
    emit(ms["type"], ms["data"], namespace="/knit")
  File "/usr/lib/python2.7/site-packages/flask_socketio/__init__.py", line 444, in emit
    return request.namespace.emit(event, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/werkzeug/local.py", line 338, in __getattr__
    return getattr(self._get_current_object(), name)
  File "/usr/lib/python2.7/site-packages/werkzeug/local.py", line 297, in _get_current_object
    return self.__local()
  File "/usr/lib/python2.7/site-packages/flask/globals.py", line 20, in _lookup_req_object
    raise RuntimeError('working outside of request context')
RuntimeError: working outside of request context