hey all. does anyone here have experience adding testing to a hoplon backend? or should it just be enough to have an additional task that includes src files for testing?

seems like that should work

i just always include the test namespaces anyway

so there isn't a special task or anything

alright, thanks!

i think i'll need to make a separate task though, just so a boot test can be done externally

yeah could be

Hi guys - sorry, some probably really obvious javelin questions that I'm struggling with: 1. How can I create a formula cell that depends on values of a set of anonymous cells passed in? Something like:

(defc a {})
(defn a-acc [t] (cell= (get a t)))
(defn grid [cs] (cell= (js/console.log (apply + cs))))
(grid cells (map a-acc [:a :b :c :d]))

^ this fails with Error: No protocol method IAttr.-dom-attribute defined for type javelin.core/Cell: [object Object](…)

Does the cell a ever get populated with data?

2. If I have a converging cell in the graph (like the cell= returned from grid; and I update a, does grid get executed n times for the number of cells defined by a-acc or just once?

@levitanong: yes subject to user input somewhere. I should probably make a-acc (cell= (get a t 0)) to stop a null pointer exception

Can you talk a little more about the background behind what you’re trying to do? I almost never have to make a function that returns a cell.

For example, what I would do is this:

(defc a {})
(defc= a-vals (map #(get a %) [:a :b :c :d]))
(cell= (println (apply + a-vals)))

@levitanong: so I'm trying to wire up a real spreadsheet (hoho). Basically I want to create n cells on the fly corresponding to the individual spreadsheet cells, so basically I have a function that creates a lens for each cell in the spreadsheet. Each spreadsheet cell would is built from 3 places; a javelin/cell containing a set of values, a javelin/cell containing a set of formats, and a javelin/cell containing a possible set of override values that should be displayed instead of the value in <values>.

I could combine this all into one map like a-vals, but then every cell would get recomputed whenever, say, one override cell changes, which is very wasteful.

So I would rather generate n cells corresponding to each spreadsheet cell

Ah

which minimizes ticks, at the expense of making the graph larger

I think in this case, you should wait for someone like @micha or @laforge49

@adamw: I think you need to use formula function in order to create cells dynamically

re q2; this talk by @micha answers it; rule 3 'Side effects occur at most once per event' https://www.youtube.com/watch?v=UoZyyo2Bwr8

the formula cells trigger when any of their dependencies values change, I believe

there's a special javelin.core/dosync that you can use to change multiple cells in one "transaction"

#dm3 I was thinking of one input cell which is referred to by n formula cells, and a final formula cell which uses those individual formula cells.

I was concerned that the final formula cell would be updated n times even though we only set one input cell

but it seems that it will only be executed once

it should be just once

IIRC it goes through all cells according to their rank

which is a good thing

when propagating updates

so updates to cells with lower ranks will be done when you get to the "deepest" formula cell

yep, it constructs a final ordering and then executes the propagation

javelin just gets better and better 🙂

that talk should be referred to from the Javelin readme.md 🙂

hehe, I love it

however, some people like a bit more sophistication: https://github.com/paf31/purescript-comonad-ui/blob/master/src/Main.purs

it's crazy

wow

i worked with a guy obsessed with comonads once

it was not fun

:)))

I guess if you have a PhD in type theory it's all intuitive

this guy wasn't a phd, just very enthusiastic

which is worse 😉

working with both monads and comonads i always get the feel that they are poor substitutes for a right data structure

at least when working with anything other than effects

> -- | This is a bit like taking the smash product of pointed topological spaces.

it's state of the art when you're looking at type theory research applications

just not compatible with how I want to do programming

were you working in a strongly typed language at that time?

err, I mean statically

no it was clj, which was part of the "problem"

oh, that's horrible