spacetimeengineer / mupy Goto Github PK

As a developer .... blah blah blah blah blah.

Follow the TODOs ; basically the variables need to be renamed and re established in their use-case.

This is partly designed to extend the scope of a system-code technology but mostly it would be cool. Since it can now reach across python3 and its capabilities there are no limits as long as system-code constraints aren't violated.

The family code libraries can be removed along with the jig scad (the one that is named by system-code).

1.) Hardware class may need to be called Ware class. More research is going into this. The reason is that Hardware may be too specific. A ware class is more general.

2.) Map Namespace, Workspace, Assembly, Ware -> Namespace-Code, Family-Code, Type Code, (Wares are not included in family unless there are made from direct scad or some similar situation in the script)

3.) mupy is more appropriate as an aspect of a larger Linux image since it is easier to leverage entire Linux system rather than upgrade python package to do everything. This way an ecosystem can be formed and preexisting lots leveraged.

4.) The Linux image will have an ip-address or some unique system for providing a namespace or a shop. A shop is a directory that lives at a namespace. A market is a server object which possesses a payment system and can allow shops to interact and it can sponsor discussions.

5.) When you execute a script it makes a whole family code system with instructions and parametrizations.

6.) Auto Certification

7.) Auto Manual : Derived from new Dimension object maybe and other things.

8.) Auto Encoder : This function is hard to build but is a collection of well designed smaller functions.

9.) Implement Market, Shop, Work objects This should be build as a new project altogether and then integrate mupy.

10.) Need new abstraction layer for discerning scad object and things that do not need to be scad objects.

Follow the BPAN type for each family made by me.

Even if it is rudimetry..