@alandipert: isn't that what cycle + rest/ first does?

Yeah but the explicit rotate would make super clean I think

(defc things ["one" "two" "three"])
(defc= slides (cycle things))
(defc= slide (first slides))
(with-interval 1000 (swap! slides rest))

My rebuttal is quite elegant but can't fit in the margin of the iPad

I leave it as an exercise

haha

oh my, not enough room in this channel for my ego

All that is left now is to update the api doc and then do the releases.

[ANN] notify 0.1.1 uses a decay timer to reduce polling by inactive clients.

@alandipert: pardon my intrusion—while the rotate would make it super clean, afaik there’s no rotate function in clojure. Wouldn’t you have to code it in manually?

hey, if i'm not planning to use cell=, is there an advantage to cell over atom (or vice versa)?

oh also

is there a way to respond to a Hoplon element being rendered?

i got a 3rd party library sticking something in the DOM, which gets blown away by Hoplon

would be good to have it do it's thing after Hoplon builds the page

ah, so the actual issue is that anything i pull in as a dependency with cljsjs, that does something to the page as it is pulled in

will get blown away when Hoplon does its thing

quick question on Hoplon and Server Sent Events (SSE) … I know that the architecture supports one way data updates / CQRS and SSE is a very natural way to achieve this from a READ perspective … do you have any thoughts on how the RPC mechanism could be hooked into SSE data rather than a web socket?

perhaps I’m missing something on how state changes from client X are distributed to client Y and Z without Y and Z needing to poll for the state changes

The fact that hoplon/notify uses polling (and not even long poll) to receive notifications (events) from the server is an embarrassing testimony to my ignorance. But I'm a back-end java dev with minimal web-server experience and a clojure newbie. @raymcdermott: I'd love to move notify to more appropriate tech!

Now you may have noticed that in notify we use registered functions to process notifications. This is because notifications can be changes which require updates to client state rather than being updated client state. The problem with tying notifications directly to hoplon/javelin input cells is that multiple identical notifications (add 1 to the page counter) would be deduped, resulting in the loss of significant notifications. Fortunately it is very easy in hoplon to write a function which adds 1 to an input cell using swap!

Really, I am thinking that the ideal solution here would be to have alternatives to notify which use the same API but different transports.

I agree - let’s hear what the giants have to say when they awake from their slumber 😉

I added Hoplon here - would love to see a presentation at Clojure/west 2016 https://github.com/clojurewest/clojurewest2016/wiki/Suggested-Topics

As a non-web dev, I find hoplon very hot. But the biggest problem is being limited to just castra. Easy enough to integrate other transports into hoplon, except it hits on my personal weakness as a non-web dev. Clojurescript is a boon too, as I'm weakest when it comes to JS. But I especially love hoplon's lightweight approach to reactive web pages. (Though the demos seem especially weak in this regard!)

[ANN] notify 0.2.0-- Notify now includes the timestamp of when a notification was created on the server. Functions registered to process notifications on the client now take that timestamp as a second argument. The castra-notify-random and castra-notify-chat demos have both been updated. No further changes are planned for notify at this time.

@thedavidmeister: can you describe what you're wanting to do a little more?

hoplon can coexist very well with other js libraries, but there may be things you need to do, depending on the assumptions those libraries make

@micha What do you think of @raymcdermott 's idea of using SSE in a notify variant? https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events

I just know that @micha and @alandipert are brilliant developers

Fer sure!

@laforge49: to do full event-driven backend i think we'd need to go a completely different direction

i don't usually work on facebook type applications

i work more on AWS console type applications

or gmail type applications

you know, business frontends

that means you don't have billions of users all talking to each other

and expecting real-time updates from any random user to another

for business type applications castra works well for me

i would like to make some middleware that sits between the castra middleware and the castra client, that uses SSE or websockets

it would still be request-response, i.e. the client makes a request and gets a response

but the middleware would keep track of the client's state

then it could pass only patches across the wire

For now, I've got what I need to start working on some aatree demos. I really should let someone else run with the ball re transport.

yes i want to see some aatree demos!

will you add them to the hoplon demos?

Nothing fancy to start with, though I still very much want to work towards db change notification subscriptions for clients.

Gladly!

Another thing I keep thinking about is reworking aatree, immature as it is, to run in clojurescript as well. My todo list then is way too big, which is why I wanted to stabilize notify for now and start using it.

i wonder if it would make sense to implement it in clojurescript first, so you can make demos to see how it works in applications

and then when you have it all pretty much nailed down port to clj

I see aatree as having 3 layers. The first layer is done for clojure. Layer 2 is very much like datomic. Layers 2 and 3 are implemented in Java, where layer 3 contains things like access control.

is layer 1 there the "outermost" layer?

like the API?

like backwards compared to the OSI layer scheme?

no, the lowest layer. It gets hidden by the higher layers. But it is also usable independent of them, at least the clojure version is.

ah i see

ok

yes i'm tracking

With layer two I do time, entities and entity relationships. And time is complets, whereas datomic only covers the smallest part of time.

So you can see changes to an entity or relationship over time, and navigate freely between those views and datomic-style time-travel.

--Datomic only has 1 time index, whereas I use 3.

But I really want to get layer 1 finished. It has use cases which are not supported by the other layers.

What is currently lacking in layer 1 of aatree is journaling. Every update needs to first create a journal entry which can be archived and then processed. This facilitates fast recoveries, hot backups and data mining.

But before going any further, I want to add a back end to the chat demo .

sounds pretty awesome

Been working on this for over a decade.

But I'm pretty burnt on working alone. So whatever I do needs to be accessible.

Success only comes from the cross-pollination of different perspectives and different skill sets. 😄

I am also quite excited about a deep integration between a database and reactive web clients.

yeah cross-pollination is key

@micha: in my experience business front-ends can also benefit from shared real-time updates. Stock level or booking system are the pretty common examples. Dashboards and other visualisations greatly benefit from push style events.

sure, but that's very different from facebook say

where users are talking to each other in real time

it's a much simpler problem

polling works really well there, since the individual updates are essentially stateless

I was thinking of how to use http://docs.datomic.com/clojure/index.html#datomic.api/tx-report-queue

yeah i mean that's a brutal solution

because you then need to couple all of your code to the db schema

you lose all encapsulation and layered architecture stuff

with say a stock ticker, for example

that's very well suited to sse

and with castra for instance, you can wrap it in middleware that keeps track of the client's state, either by keeping a websocket reference or by request sequence numbers (related to tx ids in datomic)

the middleware is an optimization to reduce the traffic sent over the wire for updates

the middleware can compute the diff of new state / old state

and just send that

and middleware in the client can apply the patch

that still allows your business logic and your rpc endpoints to be stateless

the state is essentially boilerplate then, implemented in the middleware

so for a stock ticker the most naive thing would be to just poll the backend

that will provide real time updates

to optimize you can add middleware in the server that polls the castra endpoint, so the client doesn't need to send requests over the wire

with that optimization the client still polls, but the responses are not returned to the client until the state changes on the server

ok, so a little like conditional GET in HTTP?

so client calls endpoint the first time. the middleware calls the castra endpoint and collects the result. it then compares to the last result it has seen for that client/endpoint pair. since there are no previous requests that will be nil. it then computes the diff of previous and current, and if there is any difference sends the diff across the wire to the client

now the client is polling, so it makes a second request, with a sequence number that corresponds to its previous state

the middleware on the server does the same thing it did before, calling the castra endpoint

but suppose nothing changed on the backend, i.e. the castra rpc function returns the same thing it returned last time

in this case the middleware goes into a loop

periodically calling the castra endpoint and computing a diff of the result with the stored previous state of the client

it doesn't return any result yet

(this is the sse part)

long polling basically

it continues to loop, calling the castra rpc function until something changes

when that happens it sends the diff as a response

and middleware in the client applies the patch to its own state

this kind of serverside polling should be pretty scalable for databases like datomic where reads are cheap and local to the peer

and where state can be described by an immutable database value or tx id

basically the client can send a request to a castra endpoint with some immutable value that describes its current state

and the server delays responding until the endpoint returns something other than the client's current state

i dunno if that makes sense at all

we need a whiteboard 😉

haha yeah

i have one actually

so you’re saying do polling on the server-side

exactly yes

using the tx-report-queue might obviate that for Datomic

this allows you to preserve the vastly simpler stateless architecture for your backend application

yeah but the tx queue is too low level

true

it's a huge simplification to organize your backend as a namespace of functions that the client can call

it does indicate change but needs a lot of parsing

well it's the meaning that's the problem

yes

like there is no a priori relationship between functions and datoms

agreed, it is too general

if you have to declare that relationship, which you would, then you've defeated most of the benefits of the lisp abstractions

like imagine if you make programs like that

like externally mapping vars to functions

I think I need some schooling there ...

i mean a normal clojure program has functions that compute things, referring to various vars and whatnot to perform their computations

i think the tx queue is similar to adding watches to vars

and trying to figure out which functions will need to be called when they change

your program would become spaghetti very fast

essentially GOTO all over the place

via core.async 😛 but yes, your point is well made

with the serverside polling you'd probably want to use core.async

or some kind of fibers

so you wouldn't need to have a dedicated thread for it

i mean for each client

sure I just meant that we could use flashy libs and end up with GOTO equivalents

haha yeah it's easy to end up there

ok I like the idea of Datomic clients sending the database value as that is trivial to compare with the current value so making queries against databases that are different will usually have the chance to obtain novelty

yeah the state of the client could be associated with a datomic tx id

would that just be some meta data on the state

and the client could send that with the request

the server then performs its query, and compares to a query against the client's tx id

and computes a diff

yes, it leaks out that we’re using Datomic but I don’t think that’s a huge issue … hiding this stuff has wasted 20 years of enterprise computing

the tx id is just a uuid

it doesn't need to be datomic specific

it could be anything

it could be a key corresponding to something in redis, who knows

like my current project is using sql server

we could maybe store client state in memcached

or something

well we know, but yes, just put a different generic label on it

and still be able to compare

datomic makes it all much cheaper

and easier

what would be a good entry point in the Castra middleware for that …. or it just another defrpc?

i would make middleware that wraps castra

i think they're separate concerns really

the middleware could do the polling by repeatedly calling the next handler

which would be castra, presumably

it would just keep track of the client's state

and transform the result in the :body to be a patch instead of the whole state

and in the client you'd need some middleware between the castra client and the ajax call

that would apply the patch on the client side

and pass the patched state up to the castra client code

the client middleware would handle the tx metadata, too

i don't think anything would need to change in your serverside or clientside code really

other than adding the middleware

I guess there isn’t anything like that on "the market” so let me have a think and a play … great ideas and as you say, solves for most of the problems without binding the client into the low level schema

BTW @micha: if you draw it up on the whiteboard, post a photo on the channel!

an interesting thing we have been thinking about is the "s3c", the ServerSide Stem Cell

like if you have a function that only makes a datomic query, there must be a way to make that like a formula cell

on the server

by watching the tx queue etc

that would still allow encapsulation etc, because it would be a general solution involving analysis of the datalog query perhaps

then you could create formula cells for the client in the server

and directly map them via websocket or sse

now that would be something

that really would be something

yeah that's like a pie in the sky dream that won't die

lol

the concepts are circling the same need

I have this view, tell me when in changes

(defquery [[?q ...]] conn state-cell)

perhaps?

I have this view, is it still OK?

that would hook up to the tx queue and reset! the state-cell whenever the result of that query changes

I was hearing about rethinkdb and they have something like this

some query that is automatically recalculated on the server and patches pushed out to clients

yeah this is what we want

we need more than that though

we need formula cells because it might not be as simple as just the query

like we want composable things

but the underlying primitive is the "reactive query" thing

yeah, so that changes in the reactive query can fire off other updates in the view

yeah

well you'd have a formula cell in the server that is synced with a cell in the client

when it changes on the sever the client is updated too

castra provides this, but you have to poll to get changes

the "formula cell" in the server is a function

yes, that’s our conversation 😛

i wonder if watching the tx queue is actually more expensive than polling

because you'd need to do more work, potentially

or you'd need to process the queue in batches

poll the queue essentially

the queue is a LinkedBlockingQueue

so it’s ‘cheap’ to poll

what i mean is in terms of waking up threads

and doing work

like with simple serverside polling you wake up every now and then and make a datomic query

is that more expensive than waking up to observe the tx queue?

and deciding whether to make the query or not?

i suppose if you did the query analysis the reactive query could register itself with a global tx queue processor

and then go to sleep until it's called

checking if the queue has anything new should be low cost

global tx queue processor … maybe that is starting to sound quite stateful?

you'd also need to know if any of the new things are interesting

yes

which could be less low cost

yes, and as we agreed earlier, hard to generalise

just taking the query and running it is cheap on the Peer or at least its cost is understandable

yeah you can tune your memcached or whatever

to make repeated queries cheaper

the nice thing is that the performance cost is in the hands of the function composer

I see being able to qualify what constitutes an interesting change, and then filtering the transactions for changes of interest to all the clients. Only when there is an interesting change do you do the underlying query to see if it is really a change of interest and what the change is from the client's perspective.

there isn’t any hidden weirdness

yeah putting the tradeoffs in the function composer is very LCDI

which we like

@laforge49: I think we are struggling with working out how could that be achieved

And what I'm talking about is only a further optimization.

Also, I tend to look at things from the perspective of a db internals dev, which is not at all useful in many cases as the overall architecture should generally be db agnostic. 😄

But yeah, we all share the same excitement. A closer integration between reactive web apps and databases via a new framework.

the graphQL folks are also circling this problem of course

I just think there are advantages to using the db journal entry stream to trigger activities, like a kind of data mining.

the difference here is the cell model

yup!

yes, datomic tx-queue, mongo oplog, rethinkdb queries are all pushing on the same problem

And having things like distributed datomic peers helps keep you from dying of query poll overhead.

yes, the fact that txn infrastructure is first class matters

it's very hard to beat a stateless server in terms of spaghetti elimination

though when you say tx-queue, you really are talking about the same thing as I am.

😄

yes, I know - I used to be a DB engineer too so we probably share many of the same perspectives

lol

Ingres, back in my day 😉

gotta run an errand. You'all enjoy now.

the main assumption of the castra model is that interesting changes occur as a result of some action by the user, not spontaneously

which is mostly true for business applications

multi-user though

and it's flexible enough to be useful with whatever storage/database layer you have

i think AWS console is a good example of a scalable multi-user application

it's not a toy, like facebook. people do real work on there

but talking it through, I’m convinced that polling - at some layer - is going to get us out of jail

yeah you can see some interesting things in the way amazon does it in their console UI

they have a mix of polling, explicit "refresh" buttons, etc

i think at the end of the day that's what you end up having to do

the AWS console really sucks 455 though as a design

how so?

i mean it has really difficult scaling problems to solve

you can't have say a combobox with all your instances in it

cause maybe you have lots of them

I mean the way that you have so many different navigation choices and looks all mashed together

oh

yeah i'm talking about the engineering i guess

like imagine a world in which everything must be paginated

like even the list of pages in a pagination widget!

haha yes

you might have hundreds of pages of something, so you can't even do that the simple way

i think this is where the rubber meets the road for real

in this distributed system kind of world i think polling might actually be the best option

I suppose that’s why many bespoke clients exist for specific AWS use cases

once you have to visualise 1000s of things pagination makes no sense anymore. You hit a google search problem, nobody goes past the first page

exactly

typeahead etc so key

everything is tuned to getting the result in the first hit (hence query predictions)

we needed that just then

ok, so how does that all fit into s3c?

well i guess s3c isn't as awesome as it might seem, maybe

i go back and forth with it constantly

so it needs to be built, just to see

as long as you can pass it a query to resolve, it could be fine - like you say it has the job to calculate whether the client needs updating

might actually be quite easy

i'm pretty convinced though that we need to have a menagerie of state machines in the client

as least doing it that way

like a state machine zoo

we started developing some at adzerk for our application

like we have a general purpose form-machine

this is a stateful thing that implements a state machine

exposing the knobs as functions that operate on it and cells by which it exposes its current state

ok yes, so some all reacting inside the client cage and some being allowed to interact with external entities like the server

so you can call the state transition functions

yeah

the machine knows how to handle errors, for one thing

which is huge

because in a distributed system ther are many different ways you need to do this

like can you retry?

what about out of order results?

things like that

having a pre-made zoo is key

but like you say you are mainly just focussed on the thin pipe between the client server and not the general problem of scheduling distributed computing

right

so that zoo has a chance

the goal here is to make it comprehensible and simple to use

like a few key abstractions that can be composed

we didn't do any optimization of the deeper things, we just did the thin pipeline state machine stuff

and our app is super responsive and fast to use

that’s what we need - most of the deep optimisations are chimeras

this is a screen in our app

it has a datatable with pagination, search, etc

and you can update any of the things with a modal form

upsert-machine is a subspecies of the general form-machine

and all of our hoplon form components can work with any form machine

does validation, etc

shows errors in the right place

modal goes away when something succeeded

also fancy things like clicking outside the modal makes the modal go away, but only if you don't have unsaved changes in the form

this is all hooked into the form machine in a pretty straightforward way

we use an interesting pattern of macros + dynamic bindings

like screen/with-screen there, is a macro that sets dynamic bindings

same with form/with-form

various hoplon elements are implemented to get default attribute values from dynamic vars if they're not explicitly provided

that’s a bit of a blizzard to be honest!

so the (form/validation-message) thing in there doesn't have any configuration at all

because it gets its config from the dynamic vars bound by with-form

this means that you can put that guy anywhere, like nested inside 50 divs, whatever

and you don't need to pass through the varibales it needs, or explicitly set attributes

like the with-form macro binds the form machine

and various elements in the body (possibly deeply nested) will be able to access the form machine to do their work

this is why we don't need to explicitly configure the text inputs with where their values go

how do you link fields together (so for example password must be the same in both fields)?

that's a validation concern

the default behavior is to do validation on the backend

since you need that anyway

castra has a *validate-only* mode

the form machine handles the details of this

ah OK that’s maybe why FRP UI is not so visible in the demos?

the form machine will not enable as-you-type validation until you've submitted the form once

but if you submit and there is a problem

then every keypress triggers validation

(there is some throttling, but it's transparent)

and the errors in the form update as you type

well in the example i pasted we've made some very high level abstractions

so you hardly see any of the plumbing at all

that page there is completely declarative, in that way

but it's not like a brittle template

maybe this is a philosophy thing but I think clients should be smart enough to help the user immediately rather than deferring to the server. It’s wise to distrust the client but that doesn’t mean that the code should mistreat them 😉

yes, that's also supported

the form machine can be configured with clientside validation fns too

those are only used to tell the user that something is not valid

which is a key aspect of a sane ui

only the server can tell the user that something is okay

is that work all proprietary to adzerk?

that way you don't have the ui telling the user that everything is fine, and the server rejecting the request

we're going to open source it

yes, the balance between the client smarts and the server truth is a balancing act

that’s great to here (re open sourcing)

but we've found that there isn't much to be gained from clientside validation in our app really

the server is plenty fast enough, the user can't tell

the diference

classic example I had (and is the canonical reactive form) is the user registration form

yeah that always needs serverside validation anyway

because you can't ship a list of all used email addresses to the client

is a username available … exactly

i mean every server endpoint needs to have solid validation on it

so i think it makes sense to start there

and add clientside validation if there is some need to do so

we just haven't found the need at all

definitely, especially with the security fears these days coming to the fore

if you do like

(binding [castra.core/*validate-only* true]
  (my-rpc-fn ...))

from the client

that will send the rpc request to the server with some metadata in the headers

the server will see that metadata and run the rpc endpoint in validation mode

that means all the preconditions like :rpc/pre will run

ok so a kind of rehearsal mode

but the body of the rpc function will not be evaluated

this way if validation fails (validation is implemented as :rpc/pre expressions) you get an exception in the client

the same as if you had submitted the form

is that possible now?

yes, it's in there

ok, great

serverside validation is pretty much free with this model

@micha: I could talk all night about this stuff but I have to go off and do a few family things

later dude!

I will look into this stuff and I have learned a lot through this conversation

🙇

later!

me too, thanks!

@raymcdermott: the form machine: https://gist.github.com/622a62d6a52ff419e5ac

:incomplete is the initial state

I did a desktop calculator in QML using a state machine: https://github.com/pkobrien/calculator-qml/blob/master/src/qml/StateMachine.qml

yeah this thing lacks any kind of real state machine abstraction

did you find the DSM abstraction you used there to be helpful?

i mean over the naive just code a thing that happens to be a DSM

yes, I think the DSM is one of the really good things in QML

learned a lot working it out using a canonical calculator example

can you compose them?

like my form machine thing seems like it could be factored into a few smaller machines that are composed to form the whole

hrm, well, they are hierarchical

the formalization lets you be confident that you've covered all the possible states, is one benefit?

well, it goes back to good design in the end - most of the examples online and/or in the HSM standards are awful

which I learned by making a calculator that actually works

Donald Knuth said something to the effect that it took him 6 tries to get the state machine for the elevator in his building defined correctly and even then he basically gave up for fear that he would never get it finished

yeah

the traffic light example is also a good one

a real mental rabbithole of uncertainty and doubt

I refactored that calculator many, many times

do you know of a good state machine library for cljs?

i looked around and didn't find anything that appealed to me

pretty happy with it, but then decided QML was a dead-end and switched to Clojure

nope, haven't seen anything compelling in Clojure

ztellman might have something

https://github.com/ztellman/automat

yeah i've tried to use that

but it's not clear to me how that relates to my thing there

like i can see how you'd make a parser or something with it

http://www.amazon.com/Modeling-Software-Finite-State-Machines/dp/0849380863

have you seen this?

read it - not crazy about it

what was not good?

read pretty much everything I could get my hands on about HFSMs

the theory is easy, putting it into practice less so

lisp though

the theory is the practice in lisp

yep - maybe I'll give it another shot some day

the DSM in QML is awesome

do you have a good intro to state machines reference you'd recommend?

like for a person who knows nothing about it

asking for a friend

hahahahahahaha

hang on, just peed in my pjs

lol

so what you should tell your "friend" is that there are no good references

bummer

they'll be disappointed

that book isn't too bad

friends are always disappointed

I find documentation in general is essential. And the more the better. Be it state machines or anything else. It lets you develop a different perspective on the code and that is when the bugs start popping out.

if you have the kind of problem that a state machine is good for then a state machine is awesome - better than all the unit tests in the world

But I find in general that it is difficult to abstract reasonably simple state machines. And trying to be complete is just too overwhelming!

yeah unit tests are especially useless for stateful things like that

tests have just as many bugs as the code!

always!

take a look at my calculator code example and you will see, imnsho, a good example of a fully functioning trivial/non-trivial system

yeah i'm trying to work through it

the gui is just a dumb layer on top

that enables/disables keys that are valid/invalid depending on the current state

all the logic is in the machine

a nice thing is that the machine is completely decoupled from actual calculating

like i don't see any + implementation there

its in there somewhere

What I dislike about statemachine ish software is that it generally composes badly--the whole becomes quite fragile. This is how I characterize actor systems. As soon as you use state to filter message processing, you've got intimately coupled state machines.

i mean in StateMachine.qml

@laforge49: I agree and felt like developing the state machine was a very fragile process

@laforge49: the form-machine thing has been a huge simplification in our application

it's like an order of magnitude difference

cool. Hey, use what works where it works.

in terms of being able to understand complex stateful stuff, like any real world application will have

like we code all the things that interact with the server to delegate to a state machine

that manages the state of the session, more or less

That's where I prefer synthesis to analysis--keep it simple so you can understand it

DSM.SignalTransition {
                signal: keyManager.addSubPressed
                targetState: operatorState
                onTriggered: processor.calculateAll(false);
            }

maybe the quest for a formal representation is flawed

maybe ad-hoc is actually better

A good semantic model wins hands down. This is why naming is key in software development.

https://github.com/pkobrien/calculator-qml/blob/master/src/qml/Processor.qml

I find I keep changing the meaning of things as the code matures.

--refining the semantic model

function calculateAll(updateExpression) {
        var num = operandBuffer.number;
        var operator;
        if (operators.length === 2) {
            operand = operands.pop();
            operator = operators.pop();
            switch (operator) {
                case "*":
                    operand *= num;
                    break;
                case "/":
                    operand /= num;
                    break;
            }
            num = operand;
            if (equalKeyRepeatsLastOperation) {
                operandBuffer.update(operand);
            }
        }
        if (operators.length === 1) {
            operand = operands.pop();
            operator = operators.pop();
            switch (operator) {
                case "+":
                    operand += num;
                    break;
                case "-":
                    operand -= num;
                    break;
                case "*":
                    operand *= num;
                    break;
                case "/":
                    operand /= num;
                    break;
            }
        } else {
            operands.pop();
            operand = operandBuffer.number;
        }
        operands.push(operand);
        calculationResult = operand;
        if (updateExpression) {
            expressionBuilder.push("=");
            expressionBuilder.push(calculationResult);
        }
        operators = operators;  // To trigger any bindings to this list.
    }

hm

so StateMachine are just the states and Processor has the logic

state machines do result in pretty clean code... when you only have one. But I think it is because the semantic model is so clear.

ok maybe you could tell me what you think of the form-machine i made, in relation to the formal DSM approach

?

i can describe the overall concept or organization

gopherit

ok cool, thanks

so the idea is there is a cljs record type, the FormMachine

it implements IFormMachine, which are methods that can be called on the form machine instance, these are the "signals"

need a cigarette break but I'll catch up so spill yer guts

the form machine's record fields are actually javelin cells

so the state of the machine is kept in these cells

in the specific case of the FormMachine there are three signals: reset, validate, and submit

and when you construct a new form machine with the form-machine function, you provide an action (a function to call that will do the ajax, following a certain convention for reporting error or success)

the convention there is that the action when called will return a js promise

you also provide a schema which is describing which things could have errors related to them (eg. form fields or whatever)

and a cell that represents the current value of the form and a callback to call when form has been successfully submitted

the machine has its own fields that are cells, as i said before

like (:error the-machine) returns a map of error cells

so for instance if my schema is like {:foo nil} then there will be a cell you can get via (get-in the-machine [:error :foo])

which will contain the error message for the :foo field

so from a very high level:

you create the form machine with some configuration that includes functions to call when different states are entered or exited

and with some configuration about what kind of state to keep track of internally

(this is the schema for instance)

then you can call the reset, submit, or validate methods on the machine, and things will happen

if things happen it will be reflected in cells that change their values

for example the (get-in my-machine [:error :foo])

the form machine also can trigger state changes when it's own internal formula cells change

derp line 100 and 101 there

the idea is that maybe i have a form with username and password fields

i can express the form data as {:username (cell ...) :password (cell ...)}

and my login! castra rpc function can take that map as its argument, say

and if there is an error it could attach {:username "must not be blank"} to the exception it throws

in the case that the username was submitted blank

so to express this relationship the form machine has the :data and :error fields

which are both maps

hm

i'm in the weeds, disregard all this

welcome to state machine hell - can I get you a latte or toasted bagel?

hahaha

one thing that became clear to me working on the calculator is that the import part is the behavior

something is going to happen, like the user hits the = key

what does that mean when the = key is pressed, what behavior intent does that represent?

depends on the state of the machine

focus on variations in expected behavior

create states and transitions to reflect that

look at my code

I will not be humble about it - the code might suck and it sure isn't clojure but I modeled a calculator better than any examples I found online and I think I saw them all

took a lot of work to get it

then you just group things together and put them in a hierarchy that works

easy peasy

yeah the heirarchical part is interesting

can also be a quagmire

I think I did that more than once

like class hierarchies

if you aren't careful, yes

much tuning, and then a new thing presents it self and whoa

wheels aren't part of a car now, they're a separate thing, uh oh

like I said, eventually it all comes back to good design

all the theory is here: https://www.w3.org/TR/scxml/

@meow: What you said is key, about focusing on the meaning and intent. It is like deriving proofs in physics rather than memorizing them. Always go back to first principles: What am I doing?

look in that doc for G.4 Calculator Example for an example of a really poorly thought out example - or a good example of how not to do a real state machine

such examples do a real injustice to a good idea like state machines, imo

@laforge49: yes, or like letting go of your OO instincts and adopting a functional approach

that was hard for me when I started doing Clojure 9 months ago

You've been doing it longer than me!

but from the look of your github you are smarter than me

so its a tie

But I learned oo in C++, where using functions instead of methods was encouraged--keep the objects simple and reusable!

I'm just persistent and stubborn and a pain in the ass

no, you've got that wrong. I'm just full time playing with clojure. I'm very very slow on the uptake--ask micha! I'm just tenacious.

cool

two of us can drive the geniuses crazy

@meow: sent you an invitation. I just created the aatree organization to replace the laforge49/aatree project. I want to include more clojurescript among other things.

@micha sent you an invite too.

Yeah, I tend to ask the dumb questions and then write up the answer I get. I figure there are a lot of other dumb people out there that will appreciate it.

Developers usually have a serious issue when it comes to targeting an audience!

sweet, thanks

I'm in process of linking aatree to the slack clojurians aatree channel.

So it had to be a community instead of the existing project.

this scxml doc is interesting

looking at the microwave example now

G.2