Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 28 14:27
    dependabot[bot] opened #54
  • May 28 14:27
    dependabot[bot] labeled #54
  • May 28 14:27

    dependabot[bot] on npm_and_yarn

    Bump dns-packet from 1.3.1 to 1… (compare)

  • May 26 07:01
    dependabot[bot] labeled #53
  • May 26 07:01
    dependabot[bot] opened #53
  • May 26 07:01

    dependabot[bot] on npm_and_yarn

    Bump browserslist from 4.5.4 to… (compare)

  • May 12 01:15
    dependabot[bot] labeled #52
  • May 12 01:15
    dependabot[bot] opened #52
  • May 12 01:15

    dependabot[bot] on npm_and_yarn

    Bump nodemailer from 1.8.0 to 6… (compare)

  • May 12 00:48
    dependabot[bot] labeled #51
  • May 12 00:48
    dependabot[bot] opened #51
  • May 12 00:48

    dependabot[bot] on npm_and_yarn

    Bump nodemailer from 2.7.2 to 6… (compare)

  • May 12 00:31
    dependabot[bot] labeled #50
  • May 12 00:31
    dependabot[bot] opened #50
  • May 12 00:31

    dependabot[bot] on npm_and_yarn

    Bump chart.js in /angular4-Boot… (compare)

  • May 11 14:41
    dependabot[bot] labeled #49
  • May 11 14:41
    dependabot[bot] opened #49
  • May 11 14:41

    dependabot[bot] on npm_and_yarn

    Bump hosted-git-info from 2.7.1… (compare)

  • May 11 08:04

    dependabot[bot] on npm_and_yarn

    (compare)

  • May 11 08:04
    dependabot[bot] closed #20
Jean-Jacques Dubray
@jdubray
There is also dotuml, I'll add an output tonight, there is a nice plugin for vscode: https://dotuml.com/documentation.html#secDiagramState
Jean-Jacques Dubray
@jdubray
I am working on adding composite states: https://www.uml-diagrams.org/state-machine-diagrams.html#composite-state
That sounds like a reasonable feature

Here is the specification:
Since a SAM instance can run multiple state machine, the sam-fsm library also supports the concept of composite state when a state machine can only accept actions when another state machine is in a particular state. The composite state fsm can also be programmed to execute automatic actions on the parent fsm on specific states (success, failure,...)

The composite descriptor specifies the composite state label of the parent fsm (COMPOSITE_STATE in the snippet below). That state value acts as a global guard of the composite fsm. The composite fsm will start in the pc0 state each time the parent transitions to the composite state.

Conversely, the composite fsm can specify automatic actions on the parent fsm as composite transitions. On a given state (for instance END, the composite fsm will automatically execute the specified parent action and pass the proposal parameters (in addition to its own state)).

When the parent and or composite fsm use their local states, the same logic applies.

const parentFSM = fsm({ 
  pc: 'parentStatus', 
  states: {
    COMPOSITE_STATE: { ... }
  },
  ... 
})

const compositeStateFSM = fsm({ 
        ...
        composite: {
          onState: { pc: 'parentStatus', label: 'COMPOSITE_STATE' },
          transitions: [
            { onState: 'END', action: 'PARENT_ACTION', proposal: ['counter'] }
          ]
        }
        ...
})
Edward Mulraney
@edmulraney
Looks cool - I haven't hit a use case where I'd need that yet since i'm only using FSM for high level / macro control state that is self isolated. One thing I've been thinking about is removing the responsibility of triggering events from the UI components themselves, and instead having the model responsible for sending them. Haven't thought it through too much yet but it would mean the FSM was responsible for the event triggers based off the model, instead of having it defined in UI components themselves. Then UI components are only responsible for triggering events that update state (not events that immediately go to the FSM, i'd rather the UI components didn't know about the FSM)
That way your FSM logic is all colocated also (inside the FSM itself, the transitions and the triggers)
Currently a developer can effectively write triggerTransitionEvent() when the model isn't necessarily in the right state to have sent that. The FSM protects against this by only allowing permitted events (actions), and by optionally having guards. With having the FSM responsible for triggering the event instead, the developer no longer has the responsibility of updating state (via a proposal or event), and, triggering the transition event, but instead only has to update state
That way they can't "get it wrong" when it comes to the triggering the transition event, they can only get the state update wrong (which is one less area for bugs to appear)
Edward Mulraney
@edmulraney
The FSM is then testable to a much more useful degree by ensuring the transitions are also triggered correctly. Previously testing that would have required every UI component that can trigger the event to also be part of the test
Jean-Jacques Dubray
@jdubray

That way they can't "get it wrong" when it comes to the triggering the transition event

that has always been my issue with the coupling action/event -> state, that's why I prefer Dr. Lamport's view of state machines and integrate the control state as another model property derived from the processing of the proposal. But happy to hear more about your thoughts and see if I can implement. I am already so pleased (but not surprised) that SAM can implement FSMs so easily. I have claimed that with empirical data points (and some reasonable theoretical background) but I have now proven that the two can coexist synergetically.

pechkin
@3dc1d3

@jdubray how very serendipitous you should be having this fsm discussion as I was deliberating on this very topic over the last few weeks!

I have 2 questions based on what you've said above and your articles:

1) why write sam-fsm if the semantics of fsms are "not very useful beyond light switches"? what need does it fulfill that isn't (it seems) better fulfilled by vanilla sam?

2) is there a good example that highlights practical advantages of computing state from the model vs the traditional fsm approach of S1 dictating to enter S2 given some condition?

I appreciate the elegance and decoupled nature of the sam approach, but in the end, it seems to me the difference is superfluous when viewed as sam: accept(...); compute_and_enter_state_from_model(); vs fsm: process_event(...); compute_and_enter_state_from_event_and_model(); - what am I missing?

one thing that may be hampered is time travel, but I think that as long as the control state is part of the model, and the fsm respects it, then you can time travel with traditional fsm design? (not sure, just speculating)

Jean-Jacques Dubray
@jdubray
@3dc1d3
1) When you look at the work of Dr. Lamport you will notice that TLA+ based state machines often us a pc variable that Dr. Lamport describes as control state, sam-fsm makes it easier to implement control state without compromising on the structure of the TLA+ state machine. In other words, the control state does not necessarily change for every action (unlike in a traditional FSM). Theoretically the state changes of course but it is often immaterial to the control state.
2) FSMs couple actions and state, one action leads to one state regardless of any computation you would need. TLA+ based state machine use the model to decouple action and state: action -> model -> state, action makes a proposal to the model, the model computes the resulting state (which includes the control state). The best examples are the code everyone writes day in and day out. The only reason we cannot use FSMs is exactly because that coupling is not practical for things other than light switches. We don't know the resulting state when we take an action. SAM is just a factoring of your code that helps you reason more effectively about the application state. In our code the application state is usually handled via if-then-else statements. Unfortunately developers tend to use them inconsistently. SAM provides a structure that makes it a lot clearer to reason about it because:
  • the mutations are first class citizens (two types of mutations: acceptors and reactors), in particular actions (event handlers) are no longer orchestrating mutations, mutations are reactive
  • the state representation(s) can be computed from the application state (again reactively) leading to cleaner rendering of that state representation, again, actions or mutations are not involved in orchestrating the rendering
    Overall, SAM (since it based on TLA+) introduces the concept of a step, a very natural step that allows you to deal with complex issues, including control state as it is demonstrated with sam-fsm. The only thing that sam-fsm does is adding general acceptors and reactors configured with the FSM definition. If you were to implement that by hand the code would look very ugly very fast (as shown by the old rocket launcher sample), add on top non-fsm code and you redefine spaghetti code.
Jean-Jacques Dubray
@jdubray
The example I take often is what does it mean to start an electric vehicle? Yes, I get it, you turn the light switch on, but even then it's no true, since a Tesla for instance is always on. To start an EV, really means to be in the position to start your trip. Going on the road without enough battery would get you into trouble, we don't need to have this kind of consideration for GPVs because we can refill easily. So an EV needs something like SAM where the action's proposal is a destination, and the model computes whether the car is effectively ready to start the trip or if you need to charge it. Most of our code looks like that, SAM provides the structure to write this code effectively and scale in scope effortlessly, otherwise the if-then-else turn quickly ugly.
pechkin
@3dc1d3

@jdubray thank you, I understand the high level rationale, my question was more specific. I'll try to rephrase it more clearly.

a standard sam process:

1. propose A
2. update M
3. compute S from M

step 3 is it's own pure fn based on M alone, where M has 'absorbed' the effects of A (or E (event) in fsm terms).

a general fsm:

1. observe E
2a. update M
2b. decide/compute S from M+E

I labelled them 2a and 2b as this is typically done in the same fn.

observations:

  1. computing S from M or M+E is really the same thing, the former just includes E's data as part of the model.
  2. one could argue that step 2b is an 'optimised' step 3 as you (often) don't need to check any values of the model, you can just change state based on the type of the event (and it's args) alone as is commonly done in traditional fsms designs.
  3. the structure and semantics are basically the same (within this limited scope)

question: under what conditions would the fsm design cause problems? specifically the difference between sam's computing S as a standalone fn based only on M vs fsm's essentially including that same computation as the final step in the update fn?

this question has come up while reviewing UML tools to help our team document and structure fsms - the sam approach makes it impossible to visualise the state transitions precisely because there's no hard link between state A and state B.

so if I were to draw a sam-based fsm in UML it would look something like (as I understand it):

            ┌─────────┐
    A ──────┤         ├──────  A
            │         │
            │         │
    B ──────┤ State   ├──────  B
            │         │
            │         │
    C ──────┤         ├──────  C
            └─────────┘

you could add transition labels to hint where you expect A to transition to but it's still just a hint - the state fn is what really determines the next state, which is buried in a bunch of condition checks.

Did that make sense?

Jean-Jacques Dubray
@jdubray
@3dc1d3 I would king of disagree from step 2b, the step 1 decides of the update (the expected control state value), the model has no flexibility as to decide how the application gets updated. The only computation that occurs is on the guarded transitions and automatic transitions. With that in mind, I am not sure how you could implement the Tesla example above? You'd have to create an automatic action that stops the Tesla when the battery charge is too low and displays an error message. There is not a lot of room to do complex updates to the application state, within the FSM. The design of the FSM would cause problem as soon as you start having an explosion of automatic actions and additional control states to implement the behavior when the action cannot control the true value of the control state, which is very common in complex software.
SAM + SAM-FSM would help because you can choose a non deterministic FSM (Start -> Started or NotCharged). You can create a representation of that state machine. Actually SAM-FSM does it for you with fsm.stateMachineDiagram
Yes, what you are saying makes sense, but my answer is that FSMs do not scale in scope, you could quickly lose track of what's going on when everything becomes a control state. SAM + SAM-FSM gives you the flexibility of using control state when it makes sense and simple actions when it doesn't.
Jean-Jacques Dubray
@jdubray
David (author of XState) claims that State charts are better, but I don't see it.
Jean-Jacques Dubray
@jdubray

Did that make sense?

yes, spot on, but real world state machines do not work like FSMs (not even talking about mixing API calls)

pechkin
@3dc1d3

yes statecharts is what I've been looking into, and I also do not really buy into them, but I'm struggling to justify why.

the EV implementation would not be very different from sam, as far as I can tell. i guess in my mind the fsm would be as close as possible to sam, with the biggest (and in my mind the only) difference being in the handling of state transitions.

fsm: in state ON, accept destination A if M.battery==100%, set state to DRIVE.
any naps could be queued just before setting the state to DRIVE.

the difference with sam would be that the ON state has no idea what state to go to next as it is computed from M.

in sam I don't see how you can draw a diagram of state transitions because each state is completely blind/oblivious to what the next state might be computed to.

in regard to fsm.stateMachineDiagram - I assume this would still be a diagram of "this is how we expect/assume the transitions should happen" but is not "this is actually how the code is written, state A leads to state B, no questions." the only way to know for sure what the next state will be in sam is by looking through all the state computations - it's a black box, like in my diagram above.

drawing a diagram which shows the intended specification is good, but it doesn't say what the implementation actually does - this is the main selling point (to me) of UML based tools (statecharts): what you see is literally the path taken by the machine.

specifying allowed state transitions helps but all it does is narrow down the possible next states, you still can't say whether A will go to B or C.

Jean-Jacques Dubray
@jdubray

if M.battery==100%

It's more complicated than that since you need to take into account the trip length, possibly the outside temperature, ... The main question though is "Is every state a control state?" and the answer is probably no. It is not practical to write code in a FSM way.

this is how we expect/assume the transitions should happen

Correct, this is a diagram of the FSM specification. It would actually be interesting to create a second one, of the actual path! great idea.

it's a black box, like in my diagram above.

That's why there is a model checker! I can't claim it's practical since the number of combinations would quickly explode, but you also have safety conditions to prevent the system to get to unexpected and unwanted states.

it doesn't say what the implementation actually does

I am not quite sure how UML solves this. UML produces design artefacts, not runtime.

Daniel Neveux
@dagatsoin

If I may, it seems that FSM can be done with SAM, but SAM can't be done with FSM. Mainly because, SAM state don't need to know where it comes from but can take hints to act like a FSM.
For exemple :

  • if you pass the delta to your SAM state computation function, you will know which control state was before.
  • if you map control state with allowed actions you can easily guess what control state will came after.

With those two points (totally legit in SAM thanks to the temporal concept), you can do a FSM.

Jean-Jacques Dubray
@jdubray
@dagatsoin exactly, with SAM you don't need static actions, the sam-pattern library does, only because it wraps it for some features of the library (such as allowedActions). A proposal does not have to have a specific structure either. It would be too impractical to define that kind of structure at the scale at of a real-world application. That's why I was really excited with the suggestion of @edmulraney because you can get the best of both world because control state makes a lot of sense.
I had often claimed that SAM was compatible with a FSM formalism, but the implementation was not pretty. sam-fsm or the like, makes it predictable and fairly easy to integrate.
pechkin
@3dc1d3

I am not quite sure how UML solves this. UML produces design artefacts, not runtime.

actually statecharts are used to generate the runtime. for example (QM)[https://www.state-machine.com/products/qm/] modelling tool, but there are many others. you draw the statechart and it outputs C code in fsm structure.

being able to see the paths and knowing that they exactly match the runtime implementation is (at least theoretically) a big help in digesting a complex system.

this is where I'm coming from, and why I'm so focused on how the state transitions are encoded - with sam I can't see the state architecture, i have to read it and compute it in my head. having a model checker is great of course but it doesn't give a junior dev, or even a new senior dev (or even a client) any insight into how the system actually operates (excluding bugs). the state fn acts as a spec enforcer, but the issue I'm facing is extracting the links/relationships out of that spec for easier understanding.

It would actually be interesting to create a second one, of the actual path! great idea.

how would you go about generating this diagram? if you can do that then you don't need the spec diagram as it's subsumed by the runtime diagram. I just don't see how you can extract it.

Edward Mulraney
@edmulraney

Still reading through the recent discussion but wanted to just say on this point:

and the answer is probably no. It is not practical to write code in a FSM way.

Totally agree. Where I'm going with my approach is that there is lots of auxiliary state that the FSM doesn't need to know about, and I think that's totally okay, you cannot factor in every true state of the world into your app, no matter how hard you try to. So it's about choosing what's essential to the control state. I think it would be valid to have some logic inside a component which is external to the FSM, but feeds its result to the FSM for the purpose of control state. It's a worthwhile tradeoff between practicality and usefulness.

pechkin
@3dc1d3
I agree with that as well, it is one of my biggest gripes with fsms and what I love most about sam - ability to cover a plethora of micro states but in a coherent and controlled (ha) way.
Jean-Jacques Dubray
@jdubray

how would you go about generating this diagram?

I had done it originally, back in 2015 (see at the bottom). We just need to collect the action/control state graph.
https://github.com/jdubray/sam-samples/tree/master/star-java

pechkin
@3dc1d3
stateA = ({x}) -> x < 0
stateB = ({x}) -> x >= 0 and x < 10
stateC = ({x}) -> x > 10
to generate the graph via simulation you'd have to propose all values of x in [-inf, +inf]- no?
Jean-Jacques Dubray
@jdubray
I was talking about the runtime graph, not the simulated one.
Jean-Jacques Dubray
@jdubray
Just to be clear, I am not claiming the simulation works for everything, this is just for very specific algorithms or parts of algorithms that are difficult to debug otherwise. Things like people do with TLA+, and of course you need to specify how the test values vary. The Die Hard sample provides a pretty good use case.
Jean-Jacques Dubray
@jdubray
I have completed the support composite state machines (v0.9.18) and the library also supports runtime state diagrams!! (v0.9.20). I'll call that RC1.
I am going to focus on using SAM in the back-end in the coming months. Really excited about that too. This ties back to an approach to design microservices. I came up with that approach over a decade ago: https://www.infoq.com/articles/seven-fallacies-of-bpm/
Nice way to connect all parts of my work.
Jean-Jacques Dubray
@metapgmr_twitter
Edward de Jong
@CodingFiend_twitter

I just discovered Mr. Dubray's excellent talk on YouTube from a few years back. It is very interesting that my work led me in exactly in the same direction. I now a very usable (very few errors extant) TypeScript competitor called Beads, that uses the SAM model exclusively. It is a tracked mutable language, that emits plain JS, no external frameworks needed whatsoever. I will do the "Gone Fishing" example, which i believe could be improved if it was a game, where you gradually caught the fish if you only select 1 fish during the click/drag operation.

Anyway I hope that JJ Dubray will at least take it for a spin. No question in my mind that the SAM model is much more reasonable as it isolates the business logic. In my system the layout phase is done usually in one pass with the drawing, and the draw code is automatically called again if any state variables that it reference change their value. So it is SAM with a runtime that supports intelligent repaint.

I know that Dubray in his talk stated a preference for people to not invent a new language, however there are many other features that i found lacking in the JS derivatives, such as closed arithmetic, Time Travel Debugging, and many others.

Anyway please let me know where to send the Fishing game.
Edward de Jong
@CodingFiend_twitter
![screenshot](http://beadslang.com/projects/fishing_game/screenshot.gif)
I can't seem to get an image to show up. Must be doing something wrong in the markup.
Jean-Jacques Dubray
@jdubray
I am very excited to hear about beads, I will certainly take a look as soon as I can. Competition is welcome, I encourage anyone to use SAM and create always better libraries. SAM comes from Dr. Lamport's work, I am merely a user of TLA+ and wish developer would take a look at his work.
Edward de Jong
@CodingFiend_twitter

Okay, i finished the fishing game. It works fine in a desktop browser, haven't yet updated it for touch devices. But that is a minor issue. It is i what i am guessing the fishing example in the sam.js.org website was supposed to do, but has a great deal more polish on it. One of the most interesting aspects is that the window can be resized without ruining the game, as the code places the fish in virtual area that can be stretched without a problem. Otherwise it would foul up the game.

It demonstrates that you have pure code in the drawing section that follows the state, and only the tracking code updates the state. the State-Action-Model method of programming is the only way you can program in Beads, as it purpose built with this pattern in mind.

I hope you will add this fishing game example to your website so that people can compare the Vanilla.JS version with the Beads.

fishing game

Jean-Jacques Dubray
@jdubray

This looks awesome!

the State-Action-Model method of programming is the only way you can program in Beads, as it purpose built with this pattern in mind

wow!

Jean-Jacques Dubray
@jdubray
The startup where I work has still some positions open (Front-End, Back-End, B2B). We filled 6 already. We are building an exciting Service-as-a-Software (the other SaaS) in FinTech with a modern stack (React/GraphQL/Microservices/AWS). Lots of ML and Data Analytics.
Positions are all remote (or onsite).
Edward de Jong
@CodingFiend_twitter

Sounds very interesting. I don't know anything about ML unfortunately. I thought maybe you would like an introduction to Beads, i can zip through the main design features via a screenshare if you are interested.

It is far simpler than React, and can generate Web, Desktop and Mobile apps, all from a single code base. I have a graph database inside the language, so i haven't used GraphQL. I did look at Neo4J when i was doing my project; not a big fan of Cypher, they didn't go far enough.

I have a finite state machine sub-language in Beads, it is very similar to your sam-js tool, but as it is built into the language it is probably more graceful to use. I haven't actually used it, because i haven't had a complicated enough state machine to work on in terms of my examples. Once you have multiple levels of state machines, then that kind of feature is very handy.

The syntax for regular expressions was redone, and i think its the best notation that has even been devised for that often opaque part of programming. One doesn't use them much, but they are sure hard to read in the classical Unix form.

Jean-Jacques Dubray
@jdubray
Yes I'd be very interested to have that intro, I strap for time right now to explore it on my own.
david kaye
@dfkaye_twitter
@jdubray - You may recall that about a year ago I was contorted over how to separate View concerns from the SAM state-transition logic loop. Today it finally came to me: Put the SAM methods in a Web Worker and let the View respond to 1) events and send proposals to the SAM worker, and to 2) messages from the worker to update the DOM in the main thread.
What's embarrassing here is that I forgot that I had already done something like that for a spreadsheet app in the browser using a Worker to run eval() or Function() (behind strict-dynamic content security policy - that was fun).
Anyway, what do you think?
Daniel Neveux
@dagatsoin
that is a very good exemple of the decoupling power of SAM. All the part of SAM can be distributed in any component of an infrastructure.We can even run the model in WASM, action in a server (action as a service ?)