COMMANDS - LeFreq/Singularity GitHub Wiki

The system commands form an "assembly language" of an object ecosystem. They apply from very small objects to the whole object environment, which can be seen as the inside of your NODE, which is inside various levels of physical/geographic networks, which is inside the universal SYSTEM object.

System commands are simply sub-obects inside the highest-level system node.

Definitions STUB:

  • node: A hardware machine running Singularity software.
  • group: A group of nodes with a name.
  • user: A person interacting in coordinate space
  • friend: A person interacting in the Soup.
  • list: A comma-separated(or space?) sequence of [node,] names within a pair of ([] or {})?
  • administrator: the User who has access to a node`s SET list. Biologically, this would be the membrane of the cell.
There might be two different sets of commands, or two different contexts: inside a node and outside one. (Is anyone every really outside? NO, so maybe the context are looking inward/downward and looking outward/upwards, with side-notes of your present environment (if you're the owner of Node Ex and you want to look at it.)

Modes of command use:

  • writing/editing something internal to an object: CODE
  • CODE exists inside a simple container called a "string". That container is opened at a node and parsed or run... When the container is a string object, it is considered text or CODE.
  • writing/reading the surface data inside an object: DATA
  • DATA locked into the membrane: IDENTITY.
  • OBJECT seen in visual space should be unique. Running, it is an APP and has all the do-dads of any application.
  • Getstate on a running object is always "running".
  • sending or receiving data on a running objevt takes permission. ON non-running objects they could queue up until run, like messages on a user's node, waiting for the machine to turn on.
  • Cloning a running object is denied.
  • DATA and Objects can be sorted into other objects through the "or" | or "and" & or "not' ~ operators. These are sent to NODES or other Objects and Files. If sent to an object, the object checks the data first, otherwise if a file it appends the data without checking. Sent to NOT operators, will make the objects/data rejected (how to implement this?) -- they float into theSoup looking for a home. This could be a whole table of data, for example, looking for anyone who's interested in it. DATA > (NODE:Object | NODE2:Object243 | Object). Object with no Node designation is assumed to be on the home machine. The DATA, in this case...
  • navigation commands
  • commands that link nodes (MSG/LINK):
Two sets of commands 10 each. These are the commands for data curators.
  • *link(" !> or <>"): Link or subscribe to a node. Can be bi-directional (only ack messages) or one directional, with a + or - valence (giving exception handling or panics from the node, node1 > node2 subs node1 to node2's messages). Linking to a node will get you it`s messages which are not addressed or thrown exceptions.
  • want/GOAL (+): Declare a named desire or goal (described in a special language, like categories), put up a bounty, and wait. Objects, rather than wants, can set GOALS. These can create a gravitational fields in coordinate space for some view. (Ex: want LOVE, goal: to fix the world. much like a mission/vision statement)
  • publish(&): writes something visible to the outer world if they visit your node. (XXXupdate the welcome message to just use this. That is, ask them what their welcome message should be and this is their first PUBLISHation).
  • look(!): Look at a published item inside the node.
  • have: announce that you ahve a resource.
  • REQUIRES: the objects required for a node string to function. AT the command line, this is the implied environment (incoming/outgoing/workspace/prompt along with input/output/network/? devices).
Applications can be written with very high-level concepts. Since the >> prompt acts like an output query, one can simply say the name of a file, and it`s contents will be emitted to the screen, perhaps decoratored by a function.

Modes: user mode and programmer mode.

4 nav Commands:

  • (>)ENTER: Enter a node, perhaps to change on object's code.
  • (<) EXIT (or SHUTDOWN?): leave a node. Will shutdown present computer hardware if you leave your own node.
  • INVERT(1/): ?? cell/object death. Perhaps a higher-level user can do this to another node. Contents spill out for everyone to see, user has to collect them again to regain access to coordinate space.
There are only 10 (8?) commands to the OS (these mimic the "minimal set" of operations of a general-purpose computing organism/machine). These are the comands for program curators:
  • XXXCommands:RUN(type at commandline): Run an objectXXXcan just type object name at command-line.
  • XXXTEST(!): Test the doctests within an object (or move this function to an inspection object which reports the object that fails it's test. YES) REMOVE to inspection objectXXX
  • HELP(?): Print the help contents of an object
  • LIST/DIR($ or *): Show the objects within a (or the present) namespace/GROUP
  • CLONE(%): Clone an object, can be shallow or deep, COPY
  • PURGE (!): Move an errant node to Purgatory or DELETE.
  • MOVE: move an object to a different group.
  • MSG(@ or ' or "test" >> Node): Send a message to another node
  • GROUP("()"): Define a group. Similar to LINK but hierarchical/vertical rather than lateral/horizontal.
  • SET (# or << value): Set a meta_variable, related to above. Can be set for each node, but defaults to outer settings, if not specified. (?This should be done prior to entering the command prompt, and done at BOOT time. These then can't be changed by any node on the network and lies out side the Cloud--within the personal hardware.?)
    • NAME????: set node name
    • HELP ("I'm responsible for handling X"), queryable DATA (personal name, phone number, total bytes stored, total objects, highest level object, average level, etc.),
    • DIR (who can list the objects on your machine),
    • CLONE (what to do if someone wants to clone your objects, like add GROUP),
    • XXXTEST (who can test your objects)), XXX and
    • DEL (remove an object from the machine). Everything in the environment is already saved to your hardware with each change. Backups are handled with your hardware (like RAID5) and the natural ease and redudancy of the network covers you in other cases (cloning).
These commands might be better grouped in groups of 4, with 4+4 primary commands, from which 4+4 secondary commands are made (like BREAK to remove a membrane). XXXQ: How to express a vote for a node? This perhaps is all done inside the node by the meritocracy. Publishing things posts things inside the surface of the node.XXX
XXX RRETHINK into four quadrants: Scanning/search command (dir), edit/understand XXX, creating/setting (set), . I.e. an empty object gets created, THEN edit separate.... (too soon)?

So all commands can be reduced to GROUP (form a membrane), LINK (form a link/edge/connection between nodes), RUN (have data flow through the said graph, SHUTDOWN (shutdown a running neuron or the machine itself: a kill cell command). These can all be related to the four basic methods of hte standard objects. RUN would send DATAMSG would be DATA {RUNning} through the graph.

COMMANDS must work with DATA. So DATA becomes the first element, LINKING/GROUPing perhaps the next, XXX

Object commands (clone, test, get state, in <, and out >) that are run without arguments operate on the system as an object. So, "?" would return the state of the user's node (GPS coordinates, newscolor, nodecolor, name, ...?). "!" would test all objects running. < sends messages or objects into the Cloud and.

"> 'test'" returns string object cannot receive SYSTEM.

What should these commands return?

  • RUN: nothing but a write to a log with the success value (if debug is true).
  • EDIT: An object with the new code.
  • TEST: How many successes and failures.
  • GROUP: What nodes declines the group
  • MSG: nothing, unless network not available
  • SET: "Done." or ERROR result ("Name already on network").
  • HELP: Outputs the knowledge of the object.
a list of allows and declines? Friends, foes. But there are at least two dimensions of this. Even friends may not get access to everything. Everyone else: ask.

An Object combine command? That will take two objects and put them into named mashup, autoplacing code for programmer to decide?

RUN

EDIT

TEST [object] | [node]

Tests an object on your machine or the objects on another node.

GROUP name

Defines a group

MSG

Message a individual node or a group established by the GROUP command. Appears on node console as "Message Text".

MSG(EDIT(RUN(object)),TEST(object2))) Is this syntax revelatory or interesting?

Three? special devices are named STDOUT, STDLOG. XXXThis may not be wanted on a p2p os.xxx The latter simply receive all messages and appends them to the system logfile.

Singularity

⚠️ **GitHub.com Fallback** ⚠️