Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v0.1.52 Patch #193

Merged
merged 1 commit into from
Apr 3, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
56 changes: 39 additions & 17 deletions Axium.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,11 +7,20 @@ There is much to be expanded upon this as a potential platform of doing. Where t

## Working with the Axium
```typescript
export function createAxium(initialConcepts: Concept[], logging?: boolean, storeDialog?: boolean) : {
subscribe: () => {},
unsubscribe: () => {},
close: () => {},
dispatch: (action: Action) => {}
export function createAxium(
name: string,
initialConcepts: Concept[],
logging?: boolean,
storeDialog?: boolean,
logActionStream?: boolean
): Axium { }

export type Axium = {
subscribe: (observerOrNext?: Partial<Observer<Concepts>> | ((value: Concepts) => void) | undefined) => Subscription;
unsubscribe: () => void;
close: (exit?: boolean) => void;
dispatch: (action: Action) => void;
plan: (title: string, stages: Staging[]) => StagePlanner
}
```

Expand All @@ -20,51 +29,64 @@ Note here an additional departure of what would be supplied to the store is an a
The design decision here allows us to forgo the need for dependency injection. And later we will discuss axium qualities that would allow the change of concepts loaded or generated into the axium at run time. Which if one chooses to alter the composition of the Axium, the generation is iterated upon. This accomplishes one of the primary qualities that satisfies the specification laid out by the Unified Turing Machine. Where by the finite symbol reference table is of a logical selection and permitting some testable ability to halt. Is the logical deterministic means of solving the halting problem of the classical turing machine. But this is only if we accept that concepts and their qualities have an amount of completeness towards their ability to halt. That the inability to halt, is a specific design choice or consequence of the machine at some point of scale, not yet accounted for, or done so on purpose. For example: while(true). As the axium in reality is just a recursive self transforming function, that removes the need for a loop.

```typescript
export type AxiumState {
export type AxiumState = {
name: string;
open: boolean;
prepareClose: boolean;
exit: boolean;
conceptCounter: number;
logging: boolean;
logActionStream: boolean;
dialog: string;
storeDialog: boolean;
lastStrategy: string;
lastStrategyData: unknown;
lastStrategyDialog: string;
generation: number;
cachedSemaphores: Map<string,Map<string,[number,number,number, number]>>
modeIndex: number;
defaultModeIndex: number;
modeNames: string[]
methodSubscribers: NamedSubscribers[];
generalSubscribers: NamedSubscribers[];
methodSubscribers: NamedSubscription[];
principleSubscribers: NamedSubscription[];
generalSubscribers: NamedSubscription[];
stagePlanners: NamedStagePlanner[];
action$: Subject<Action>;
actionConcepts$: Subject<Concepts>;
concepts$: UnifiedSubject;
innerConcepts$: UnifiedSubject;
subConcepts$: UnifiedSubject;
addConceptQue: Concept[],
removeConceptQue: Concept[],
badPlans: Plan[];
badActions: Action[];
}
```
* name - This should be set to a unique network identifier, and/or the concept of your system.
* open - This is utilized by principles and external subscribers to denote when they should initialize their functionality.
* open - This is utilized by principles and external subscribers to denote when they should initialize their functionality.
* prepareClose - Flag to signal the axium's internal close principle to initialize shut down process.
* exit - Controls whether close will have the process exit.
* conceptCounter - Simple counter to keep track of what numbered identifiers are safe to assign to concepts.
* logging - controls whether the Stratimux dialog paragraphs are emitted upon strategy completion. In addition to other debugging procedures.
* logActionStream - Forces the axium to log each action incoming from the action$ stream.
* dialog - Is the internal representation of the strategies that the axium has ran.
* storeDialog - This is set to false by default to save on memory, but if true will store each dialog, and allows such to be subscribed to.
* lastStrategy - Informs specifically the of the last ActionStrategy topic to have ran through the system. This is used via testing or the deployment of addition strategies upon completion.
* lastStrategyData - Paired with lastStrategy. Use to access thee last data of the previous strategy.
* lastStrategyDialog - Will only store the lastStrategy actionList as a dialog if storeDialog is set to true for performance reasons. This allows access of your strategies final action list as a verbose dialog.
* generation - This iterates each time the Set of Concepts is transformed. And if an action is received of the wrong generation. Will be primed at run time, if not found this will emit a badAction that if logging is set to True. Will be emitted to the console alongside the invalidated action as payload.
* cachedSemaphores - For internal use, is recalculated each time a concept is loaded or removed.
* modeIndex - This determines which Mode is currently being ran from the lists of modes stored on the axium concept.
* defaultModeIndex - This determines what mode will be set by setDefaultMode. Of importance for adding and removing strategies.
* modeNames - Is the paring of a name that correspond to mode and their respective index that allow for the mode to altered at run time without string comparison.
* methodSubscribers - Accumulates all method subscriptions for their manipulation at run time.
* principleSubscribers - Aggregator that registers the subscription assigned to each loaded principle, this subscription passes actions directly to the action$ stream.
* generalSubscribers - Same as method subscribers, but a catch all including that of principles and their internal subscriptions that would ordinarily leave principles as hot and active in memory if not concluded upon removal or close.
* action$ - Is the internal action stream.
* concepts$ - Is the internal Concepts stream that methods and principles have access to, will not be notified in blocking mode.
* innerConcepts$ - Internal Concepts stream that only the Axium principles have access to.
* subConcepts$ - This is the outer subscription that other axiums or applications may have access to. While in blocking mode, these subscriptions are not updated.
* action$ - Is the internal action stream.
* actionConcepts$ - A simple subject that ensures that reducers, methods, and principles each have access to the most recent concepts.
* concepts$ - Is the internal concepts stream that informs plans and subscriptions to the axium of changes to the loaded concepts, will not be notified in blocking mode.
* addConceptQue - The current pattern to allow for principles to effect the concepts within the application. Rather than a direct subscription to the action$, they listen to state properties to control what actions they emit into the stream. In this case a set of concepts to be loaded into the axium.
* removeConceptQue - The inverse of the above to remove concepts.
* badPlans - Stores plans that have experienced action overflow.
* badActions - Keeps track of all actions that cannot be registered via the cachedSemaphores property.

## The Anatomy of an Axium
* Action - Is a dumb object that is supplied some data as payload or performs some transformation of state based on its semaphore which is inferred via its type. Is the messaging protocol of an axium.
Expand Down Expand Up @@ -115,5 +137,5 @@ Note these strategies can be broken into two parts responsibly, one to be ran vi
*Note* That the addition of the axium concept itself is an addition departure from the FLUX architecture. This will be refined over time as specifics needs grow and should be seen as a work in progress. But, this should also be limited in its functionality to allow for the addition of concepts to expand the total functionality of the Axium paradigm.

## Axium Modes
* Default Mode - This Mode uses the simple trick of setTimeout(() => {}, 0) to allow for the axium to have some non blocking behavior. As this functionality directly engages with the event loop. In addition this mode will emit the internal concepts to the outer subConcept$ stream.
* Blocking Mode - This would be the synchronous mode behavior of the axium in order to allow for internal modifications of the axium's set of concepts. While blocking the potential of outside subscriptions to be notified of additional state changes of the application. And thus potential conflicts of dispatched actions during these changes. Even if dispatched and the concepts are removed, these actions would be invalidated due to the internal semaphore behavior.
* Permissive Mode - This Mode uses the simple trick of setTimeout(() => {}, 0) to allow for the axium to have some non blocking behavior. As this functionality directly engages with the event loop. In addition this mode will emit the internal concepts to the base and outer plans.
* Blocking Mode - This would be the synchronous mode behavior of the axium in order to allow for internal modifications of the axium's set of concepts. While blocking the potential of outside subscriptions to be notified of additional state changes of the application. And thus potential conflicts of dispatched actions during these changes. Even if dispatched and the concepts are removed, these actions will added to the badActions list.
4 changes: 4 additions & 0 deletions Concept.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,7 @@ As in the scope of some rapid rise of generative information. This simplicity of
export type Quality = {
actionType: ActionType;
reducer: Reducer;
toString: () => string;
methodCreator?: MethodCreator;
method?: Method;
subject?: Subject<Action>;
Expand All @@ -34,6 +35,7 @@ export type Quality = {
```
* actionType - Is the type of action and logical explanation of functionality
* reducer - Alters the state of a concept
* toString - Qualities are each assigned their own toString method to enable advanced configurations.
* methodCreator - Creates a subject and method that utilizes the observer for additional control of flow. Including that of moving actions off premise, to be later remitted back into the action stream.
* method - Is the implementation of the strategy pattern via to facilitate higher order functionality to enable additional composability.
* subject - Used within the mode to inform the method of an action to be consumed.
Expand All @@ -46,6 +48,7 @@ export type Quality = {
export type Concept = {
name: string;
state: unknown;
unified: string[];
qualities: Quality[];
principles?: PrincipleFunction[];
mode?: Mode[];
Expand All @@ -54,6 +57,7 @@ export type Concept = {
```
* name - The identifier of the concept to be used in conjunction with selection.
* state - Is the state of the concept of properties identified by the programmer to achieve functionality.
* unified - A simple list keeping track of what concepts have been unified to formalize the concept. Assigned via the unifyConcepts function.
* qualities - Is a list of qualities that relay to the actions that mechanize the concept throughout your applications.
* principles - Are observers of state of your application or that of external mechanisms. That emit some action into the axium based upon that observation.
* mode - A mode is a function and point of recursion of the runtime that the concept may utilize to achieve a specific functionality necessary for that concept. This should rarely be expanded upon.
Expand Down
3 changes: 3 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -44,6 +44,9 @@ When in doubt simplify.
* [Unified Turing Machine](https://github.com/Phuire-Research/Stratimux/blob/main/The-Unified-Turing-Machine.md) - The governing concept for this entire framework.

## Change Log ![Tests](https://github.com/Phuire-Research/Stratimux/actions/workflows/node.js.yml/badge.svg)
### v0.1.52 Patch 4/03/24
* Quick pass updating documentation
* Synced up createAxium, etc... To properly allow for the axium to log actions incoming in the action stream if set.
### **BREAKING Update v0.1.5** 4/02/24
* Unified the internal concept streams and created a new dedicated stream to inform most recent concepts
* Note if you are assembling plans within a method, be sure to grab the **concepts$** from *getAxiumState*
Expand Down
2 changes: 1 addition & 1 deletion StagePlanner.md
Original file line number Diff line number Diff line change
Expand Up @@ -70,7 +70,7 @@ export const createStage = (stage: Stage, selector?: KeyedSelector[], priority?:
};

export class UnifiedSubject extends Subject<Concepts> {
plan(title: string, stages: PartialStaging[], beat?: number): StagePlanner {}
plan(title: string, stages: PartialStaging[]): StagePlanner {}
}
```
* Dispatcher - This is the supplied dispatch function that is made available each stage.
Expand Down
2 changes: 1 addition & 1 deletion package.json
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
{
"name": "stratimux",
"license": "GPL-3.0",
"version": "0.1.51",
"version": "0.1.52",
"description": "Unified Turing Machine",
"main": "dist/index.js",
"module": "dist/index.mjs",
Expand Down
4 changes: 2 additions & 2 deletions src/concepts/axium/axium.concept.ts
Original file line number Diff line number Diff line change
Expand Up @@ -109,10 +109,10 @@ const createAxiumState = (name: string, storeDialog?: boolean, logging?: boolean
};
};

export const createAxiumConcept = (name: string, storeDialog?: boolean, logging?: boolean): Concept => {
export const createAxiumConcept = (name: string, storeDialog?: boolean, logging?: boolean, logActionStream?: boolean): Concept => {
return createConcept(
axiumName,
createAxiumState(name, storeDialog, logging),
createAxiumState(name, storeDialog, logging, logActionStream),
[
axiumKickQuality,
axiumOpenQuality,
Expand Down
12 changes: 9 additions & 3 deletions src/model/axium.ts
Original file line number Diff line number Diff line change
Expand Up @@ -77,9 +77,15 @@ export const defaultMethodSubscription = (action$: Subject<Action>, action: Acti
}
};

export function createAxium(name: string, initialConcepts: Concept[], logging?: boolean, storeDialog?: boolean): Axium {
export function createAxium(
name: string,
initialConcepts: Concept[],
logging?: boolean,
storeDialog?: boolean,
logActionStream?: boolean
): Axium {
const concepts: Concepts = {};
const init = [createAxiumConcept(name, logging, storeDialog), ...initialConcepts];
const init = [createAxiumConcept(name, storeDialog, logging, logActionStream), ...initialConcepts];
init.forEach((concept, i) => {
concept.semaphore = i;
concepts[i] = concept;
Expand Down Expand Up @@ -171,7 +177,7 @@ export type Axium = {
unsubscribe: () => void;
close: (exit?: boolean) => void;
dispatch: (action: Action) => void;
plan: (title: string, stages: Staging[], beat?: number) => StagePlanner
plan: (title: string, stages: Staging[]) => StagePlanner
}

export const getAxiumState = (concepts: Concepts) => (concepts[0].state as AxiumState);
Expand Down
Loading