Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 06 14:14

    dependabot[bot] on npm_and_yarn

    (compare)

  • Oct 06 14:14
    dependabot[bot] closed #47
  • Oct 06 14:14
    dependabot[bot] commented #47
  • Oct 06 14:14
    dependabot[bot] labeled #62
  • Oct 06 14:14
    dependabot[bot] opened #62
  • Oct 06 14:14

    dependabot[bot] on npm_and_yarn

    Bump url-parse from 1.4.4 to 1.… (compare)

  • Sep 29 17:45
    dependabot[bot] labeled #61
  • Sep 29 17:45
    dependabot[bot] opened #61
  • Sep 29 17:45

    dependabot[bot] on npm_and_yarn

    Bump i from 0.3.5 to 0.3.7 in /… (compare)

  • Sep 03 00:51

    dependabot[bot] on npm_and_yarn

    (compare)

  • Sep 03 00:51
    dependabot[bot] closed #36
  • Sep 03 00:51
    dependabot[bot] commented #36
  • Sep 03 00:51
    dependabot[bot] labeled #60
  • Sep 03 00:51
    dependabot[bot] opened #60
  • Sep 03 00:51

    dependabot[bot] on npm_and_yarn

    Bump immer from 2.1.5 to 9.0.6 … (compare)

  • Aug 12 04:31
    dependabot[bot] labeled #59
  • Aug 12 04:31
    dependabot[bot] opened #59
  • Aug 12 04:31

    dependabot[bot] on npm_and_yarn

    Bump path-parse from 1.0.6 to 1… (compare)

  • Aug 11 00:49
    dependabot[bot] labeled #58
  • Aug 11 00:49
    dependabot[bot] opened #58
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
@gvolk0

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
@gvolk0

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
@gvolk0
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
@gvolk0
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 ?)
Marcus Feitoza
@mfeitoza

@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.

That's a good solution, I think SAM pattern works well with actor model.

Jean-Jacques Dubray
@metapgmr_twitter
@dfkaye_twitter sorry, for the delay. Yes, as @dagatsoin mentioned, that's the power if SAM, the pattern can be deployed across tiers. This exactly how it should be done with a PWA.
JohnGurin
@JohnGurin

Good day, everyone. I cannot find the "old" rocket launcher example where I thought I would find an answer. Here is the question:
when a timer is counting we have to re-render the timer in a view, ​where should nap go in the example?

state.render = function(model) {
    state.representation(model)
    state.nextAction(model) ;
}

In the example above render is inside state.representation(model) and if place nap check there to, then
nap and nextAction could run "simultaneously".

Is this valid approach:

    const sr = stateRepresentation( model )
    if ( nap( sr ) ) return
    render( sr )
    nextAction( model )

So if nap is true, there is no render, if nextAction is needed, then it is done only after render

https://github.com/jdubray/sam-samples/blob/master/inferno-rocket/index.html#L251-L255

Pete Barnett
@petebarnett
Hi all - I'm wondering about a situation where multiple actors implement "Next Action Predicates" that would run given the current state... If an action starts a new cycle of the reactive loop, is it simply the case that the 2nd one can wait for that to happen until it's invoked?
Is there a scenario where that might not be suitable? like a state change consists of "a product was added to the cart", and there are 2 NAPs that want to respond to that specifically... by the time the second one is invoked again, that is no longer the latest action
it makes me think there is a class of responsive action, that needs to be queued. and when it's re-invoked, decides for itself whether it still wants to act
Pete Barnett
@petebarnett
(I guess otherwise they could be composed, but only if they knew the nature of the other, and knew they were composable, and that seems more complicated than giving them a chance to re-evaluate after being popped from the stack)
then my mention of a stack raises a new question - should it be resolved that way (depth first vs breadth first)
Pete Barnett
@petebarnett
I think I've answered my own question by rubber ducking it... If you consider the model to be closed, these actors are effectively external- in that they care to be notified about changes... But the natural reaction would be to raise a new action, and we know that actions must be queued due to the synchronised nature of the model.
So the queing becomes front-loaded, instead of implemented at the nap
Pete Barnett
@petebarnett

Revisiting the above with more clarity-

Of couse a SAM "machine" only has 1 NAP function, but my project is an "cart engine" (ecommerce) that supports modular extension. Modules have an interest in implementing their own NAPs against the cart state.
The top level NAP therefore delegates responsibility to registered modules, invoking each of their NAP implementations. In effect these modules are collaborating without knowing anything about each other, but you can't just compose their actions.

This would be no problem if they only need to respond to the current state- It is only when they start to care about the "event" that led to the state change, that things become problematic. The event can be captured by the SAM machine and rendered into the current state. e.g. "itemAdded".
Child NAPs can respond to that, but of course a new cycle begins with each action, meaning the next time round, it would not be "itemAdded" anymore, and the 2nd NAP missed its chance to act.
Rocket launcher is simple because when countdown gets to 0, you stop. It's a terminating condition. But think about counting upwards, and needing something to trigger only after, when "count > 20". You need to synthesise an event like "count exceeded 20", otherwise it'll trigger in an infinite loop.

So going back to my problem - to solve the "multiple proposed actions", actions can only be queued. But from my own reading (not sure if SAM or Lamport papers) it seems like a fundamental principle that intents are strongly associated with the state from which they are raised, to the point where it seems legitimate to require a "version/sequence number" on an intent, and to reject it if the model version has changed since then.

If I start queing actions however, I break that principle... actions become deferred to be applied against future unknown states and that doesn't feel right! But I did come up with a pattern which I think addresses the problem in my use case, and would be interested to hear thoughts.

I change the wiring so that a NAP returns model proposal(s) AND a "defferedApplication" callback.
The idea is that you can define a secondary predicate, evaluated against the new state when the action is about to be applied - to determine whether it is still valid or not. i.e. return true or false.

If the change (a.k.a. Event) that caused a NAP to propose an action was "Item added to shopping cart", the "deferredApplicatoin" callback would potentially evaluate that the product was still present in the cart.

Pete Barnett
@petebarnett
...and if the above sounds like it's bending the rules with magical machinery, I would argue that it's possible to implement as a pure SAM model, by providing an action called "setFutureActions". It accepts a list of action identifiers, and of course those can be output in state representation.
You then have one pure NAP (a single function) that happens to call out to its subscribers with the current State Representation, and collects a list of "future actions". It then looks at the current state representation for existing "futureActions", and returns a proposal equivalent to "setFutureActions" + "the action that was at the front of the queue".
In this way, you get a synchronised model with a single NAP and the queuing built into the model itself.
Pete Barnett
@petebarnett
(this is all probably equivalent to NAPs just returning callbacks which produce proposals at the time they're called)
Daniel Neveux
@dagatsoin
I ran into this problem to. I solved this by adding a new responsibility to the StateRepresentation function : define what actions could.be triggered at a specific ControlState.
It is barely equivalent of what exists on the Safe demo that JJ wrote a few years ago.
Daniel Neveux
@dagatsoin
Regarding the intent queue, you can have conflict when two actions in the queue are allowed in the same ControlState but those control states can be separated in time (e.g.: the cart can be empty, the filled, then empty...). In this case I solved the issue by tagging intent whith exact same mechanism than, one more time, the SAM Safe exemple.
Another situation is also on a project I am working on, a lag compensation engine for multiplayer game. In this case I have to deals with multiple users with different ping. And this is solved by using a Lemport Clock which fits perfectly with SAM, as the exemple above, due to the "timed" nature of the algorithm.