Skip to content

Releases: Phuire-Research/Stratimux

Minor QoL

23 Oct 23:33
c3cd0b4
Compare
Choose a tag to compare

Incremental Update

  • Properly allow for Decks to be passed now to all Method Creators
  • Cleaned up code base to ease with separation of concerns.
  • strategy export -> strata

What's Changed

Full Changelog: v0.2.0...v0.2.4

STEALTH 0.2.0 DECK INTERFACE UPDATE

03 Oct 17:14
Compare
Choose a tag to compare

Essentially a complete refactor of interfaces, but not core functionality.

More information to come.

Consistency Update

17 May 19:41
1c0666a
Compare
Choose a tag to compare

Consistency Update

Focused on improving the internal consistency of Stratimux with this release. Breaking only action creator functions to fold into the options design pattern that is used throughout. This is not only a quality of life update, but a strong fighting position for Stratimux. That will the reinforcement of axiumTimeOut, we can now see a Function as an Operating System (FaaOS) Paradigm truly take shape.

Updates moving forward will be focusing on expanding the capabilities of Stratimux, versus just ensuring a rock solid computation environment. These will focus on decomposing certain aspects of the Axium into their own concepts. So that those parts may have their own dedicated qualities that can be unified into your own concepts. The strongest contenders for this are the Strategy, Dialog, and Unified Subject(Stage Planner).

For example unifying some Strategy Concept into your working set. Would append the lastStrategy and lastStrategyData properties to your concepts properties. The only downside to this change is having to create specific steps in strategies to handle the setting of these values. Versus the Axium internally handling these properties themselves.

The downside of further decomposition, is increasing the total skill cap when utilizing Stratimux. What we have now is a very fine MVP, but beyond this point. Will require tutorials, developer tools, etc... To reduce the complexity of learning how to work in this new paradigm.

Cheers~
Have Fun~

v0.1.72

  • Added a new Axium Quality: axiumRegisterTimeOut, that accepts an action and specified timeout that will run the axiumTimeOut function then succeed an incoming strategy if present.
    • This likewise fulfills the original purpose of buffer, even in a complex scenario.

v0.1.71 5/16/2024

  • Finally removed the need to add "as Subject | UnifiedSubject" when creating methods that access state or concepts.
  • Added then removed a new Buffer Method Creator Series. See branch Stash-Buffer for details.

v0.1.69 5/15/2024

  • Added priority to axium strategies.
  • Improved consistency of logic due the above change.
  • Exported isAxiumOpen helper function.

Strategy Priority v0.1.68 5/15/2024

  • Added priority to strategies, this priority will be assigned to each step issued by such.
    • With this change you may now have strategies jump all lines upon creation, ensuring some change prior to other action's taking effect.
    • Unless a ActionNode or incoming Action created by createActionNode has its own priority, then that takes precedents. But does not effect the Strategy's overall priority.

BREAKING v0.1.67 5/13/2024

  • Revamped the Action Creator Functions to follow behind the current creator with an options parameter design choice.
    • Note pure action creators will not provide an option for payload
  • Cascaded priority to ActionStrategies to allow for planning priority ahead of time.
  • Updated the PrincipleFunction documentation to have the semaphore parameter to now be conceptSemaphore. This allows for an easy drop in into the options parameter.
  • Made createAxium utilize the same options design pattern.

v0.1.65 5/13/2024

  • Removed one more level of deepness from DotPath(6 levels now), projects should now compile without the excessively deep error.

v0.1.64 5/13/2024

  • Added Action Priority: This will allow action's assigned a priority of not 0 to be placed accordingly into the action ques.
  • Adjusted DotPath type to improve type checking performance. Massively degrades with an additional level.
  • Updated documentation to reflect recent changes

What's Changed

Full Changelog: v0.1.62...v0.1.72

Strong Fast v0.1.62

08 May 21:24
18ceff4
Compare
Choose a tag to compare

Strong Fast with Lock Step Timing

This release moves closer to towards being agnostic towards NodeJS, as the purpose of this project is to demonstrate a Strong Fast Computation Algorithm. That opens a path towards realizing a such all the way down to the hardware and beyond. Specifically we have reduced the total dependency on setTimeout() via axiumTimeOut and have created a new Action Que (axium.head,body,tail) handling system to ensure a lock step operation of outcomes.

The primary difference between this version of Stratimux and one that is completely responsible for its parts. Would be the utilization of a Timing Axium, that can go further by defining a new unit of Time allowing for greater granular control. Noting that during the development of the Stage Delimiter feature the original goal was to limit an action overflow over a period of time. With the current time provided in computing, we cannot accurately predict and control the flow of actions just by timing alone. Noting the dumb limiter via some 5 consecutive actions unless a throttle: 0 is provided in the dispatch options. This would be a prime example of Stratimux even in its earliest of stages of development hitting the limits of modern computing.

BREAKING Strong Fast Lock Step v0.1.62

  • Devised a means to ensure a lock step execution of incoming actions
    • Due to each stage being ran once regardless of their selector being changed, some plans may receive the wrong value if not determining if that stage has been ran for the first time. See priority.test.ts for the example: if (changes.length > 0) {//}
    • This also impacted the axiumWaitForOpenThenIterate helper function, but now works as intended via no longer checking for the latest lastStrategy change.
    • Note Removed CI checks for 14.x and 16.x due to updating dependencies.

Strong Fast Time v0.1.61

  • Created the new axiumTimeOut helper function
    • This will add a specified action to the axium tail property after some specified time.
    • This is used internally to handle the majority of asynchronous interactions

Strong Fast BREAKING v0.1.59 5/06/24

  • Removed the setTimeout trick in favor of a new tail property added to the axium concept, this paves the way for this pattern to be completely responsible for its own implementation.
    • BREAKING Method Subjects are now a tuple of [action: Action, async: Boolean]. This allows for the old setTimeout trick to be used in case the action stream isn't kicked into gear.
      • This change is only breaking if you have implemented your own custom methods, please see src/model/method.ts for reference.
  • Ensured that plans that conclude with an active beat, will have their timers removed.

v0.1.58 Stage Flow

03 May 12:18
1fe891a
Compare
Choose a tag to compare

Stage Flow Release

Expanded and iron sided stage options to control when and how stages are informed of new observations of internal state changes.

v0.1.58 5/03/24

  • Ensured that changes that happen between a stage's beat interval are accumulated

v0.1.57 5/02/24

  • Added the ability to set specific stages of their selectors, priority, and beat values.
  • Note that by setting these values, this will not force the internal priority selector cache mechanism to trigger. Use set for stages your are iterating to or changing due to some circumstance. The new stage options will force the priority selector cache to trigger.
  • Quick pass updating the StagePlanner documentation in regards to stage selectors/priority/beat properties.

v0.1.56 5/01/24

  • May now properly update each plans intended KeyedSelectors to control when they are ran.

What's Changed

Full Changelog: v0.1.55...v0.1.58

Developer Experience v0.1.55

24 Apr 22:16
1524e38
Compare
Choose a tag to compare

v0.1.54 4/24/24

  • Changed ActionNodeOptions to allow for successNode and failureNode to be left absent. Continued effort towards decreasing boilerplate.
  • Refined original paper.
  • Properly exporting the new ActionCreator and ActionCreatorWithPayload for specific createQualitySetX creator functions

Full Changelog: v0.1.53...v0.1.55

Developer Experience v0.1.53

02 Apr 18:30
45318f3
Compare
Choose a tag to compare

v0.1.53 4/23/24

  • Added createQualitySet and createQualitySetWithPayload to reduce some boilerplate.

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
  • It is now a requirement you use the stageWaitForOpenThenIterate(() => action) helper function in your plans if you are depending on the last strategyTopic property on the axium concept.
  • Added an addition logging property to reveal the internal action stream that can be set when creating your axium. This is separate from the prior logging feature.
  • Method now utilize an internal actionConcept$ stream of type Subject. Method creators that utilize the UnifiedSubject will throw a type error and will need to be updated.
  • PATCH v0.1.51 Removed debugging console.logs

What's Changed

What's Changed

Full Changelog: v0.1.5...v0.1.53

Carousel v0.1.4

29 Mar 00:25
76b8083
Compare
Choose a tag to compare

NOTE: Hold off on updating to v0.1.4 and instead use v0.1.2

BREAKING Update v0.1.4 3/28/24

  • Removed the "on.expected" option from dispatch to reduce inner complexity of your stages
  • Renamed axium.stage to axium.plan to be in line with industry terminology
    • The new plan set up requires a staging entity or the return from the new createStage helper function
      • This new entity enables you to change the priority in which your stages are informed per state change
    • You may now assign each stage its own separate beat versus the entire plan
      • Removes beat from the overall plan and now needs to be performed atomically
    • This overall change trims the total plans that are checked per state, but may still supply plans that trigger on all changes via empty array in entity or outright ignoring the value field via the createStage function
  • Added nullReducer to disallow excessive observations from being triggered
  • First pass updating StagePlanner documentation

Initial release of hierarchical planning changes, will be creating tutorials after ensuring iron siding via logixUX.

What's Changed

Full Changelog: RELEASE...v0.1.4

v1

29 Nov 20:59
831d556
Compare
Choose a tag to compare
v1

Hello World!
Damn you branch prediction.
Cheers! Have fun!

Time to move onto the Cyberdeck.