This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-27
Channels
- # aleph (1)
- # aws (2)
- # beginners (69)
- # boot (79)
- # braid-chat (1)
- # cider (221)
- # clara (13)
- # cljs-dev (9)
- # cljs-edn (1)
- # cljsrn (7)
- # clojure (128)
- # clojure-chicago (1)
- # clojure-russia (196)
- # clojure-sanfrancisco (1)
- # clojure-uk (13)
- # clojurescript (166)
- # community-development (2)
- # css (2)
- # cursive (8)
- # datomic (4)
- # emacs (11)
- # hoplon (54)
- # instaparse (2)
- # jobs (16)
- # jobs-discuss (54)
- # jobs-rus (7)
- # luminus (4)
- # off-topic (33)
- # om (37)
- # onyx (8)
- # proton (10)
- # quil (8)
- # re-frame (29)
- # reagent (7)
- # remote-jobs (2)
- # untangled (140)
- # yada (1)
If I want to make a few remote reads in parallel, how would I accomplish that?
Hey, how do I use the lein template for untangled? When I do lein new untangled bazbaz
, it "fails to resolve the version"
https://github.com/untangled-web/untangled-template This is the template I'm talking about
@currentoor: what do you mean by in parallel?
@cjmurphy: 0.4.8 has been released, no snapshot version
is there something you’re looking for in a snapshot version that isn’t in 0.4.8?
@kauko: i’m having the same issue, not too sure. @adambros any thoughts?
@adambros: If you wanted to pull todomvc and turn it into a base template that does work (without any special features yet), that would probably be nice for satisfying the basic need.
How ready for use do you think untangled is? I know it's alpha since om next is alpha, but I'd still like to hear your thoughts.
There are definitely "missing" things, but most of them are small and well understood. Refinements, for example, are in progress on the unhappy path error handling
documentation is coming along, but we're kind of swamped, so that is kind of a hole...but the tutorial has most of what you'd need to know
@ethangracer: by in parallel I mean, if I have multiple calls to load-field
in the same UI transition but I don't want them to be batched together.
I have a dashboard with several widgets, and these widgets have very different data requirements (some external APIs and some internal).
I don't want the loading of a slow widget to block the others.
what do you mean?
It is a valid use-case, so we could add a little sugar so you could mark loads that you want to serialize
We also want to add support to "future-based" loads, where you spin something off on the server but get an immediate response, and then poll for the result.
It would be easy enough to add all of the bits of that so you could just specify a flag on a load, and it would switch to that behavior
so the post-mutation approach, it would load the widgets one by one correct?
i was hoping for something like make these four requests at once
the only complication is that writing that in post-mutation isn't ideal from a clarity standpoint
ah i see
I'm feeling like the future-based approach is something we're going to need soon, and would solve your case
what about a websocket based solution?
i see, so polling is just an implementation detail?
ah cool
basically: respond immediately...don't wait for response....but when the response arrives, normalize it into to app state and call the post mutation
makes sense
so, we could still batch the requests, but their responses would process in parallel and arrive when complete
yeah that would be cool
Our default sequential processing is needed for optimistic update reasoning, but this parallel processing is needed for reports/dashboards
also don't want to tie up network connection (and have timeouts) for long running things
yeah the sequential processing has worked pretty great for us so far
optimistically creating report and widgets is a breeze
Let's open an issue on untangled-client for this...we're going to need it within the next few weeks for our product, and I was already thinking about it, which is why I had so many ideas about it so quickly 😉
nice, you want me to do it?
@tony.kay: LOL i meant write the issue!
hahah
well i'd be happy to help in anyway i can
I'm going to coordinate with @mahinshaw since he's working on the network layer at the moment. I've got the arch in my head.
awesome
I could probably get something working pretty quickly...as a rough draft. Minimal configuration, etc. Wouldn't be ideal for production, but would be easy to refine from there
i'm looking forward to seeing what you come up with
I'm calling load-field
inside componentWillMount
. Is that frowned upon?
(componentWillMount [this]
(let [{:keys [widget/data-source]} (om/props this)]
(if (empty? data-source)
(df/load-field this :widget/data-source))))
so not frowned upon?
unless, of course, your transact could cause it to unmount and then something could cause it to re-mount...
@tony.kay: thanks, will do
@tony.kay … I’ve noticed that with-db-fixture somehow masks components started in let bindings within. For example this will start the scheduler:
(let [scheduler (component/start (scheduler/make-scheduler))]
(with-db-fixture db-comp
while this won’t:
(with-db-fixture db-comp
(let [scheduler (component/start (scheduler/make-scheduler))]
yeah, I poked around real quick. Nothing jumped out. Just pointing it out. We’re on a deadline coming Monday so I’m in hurry up mode ATM. Our thought is to either make an issue or just fix it but that will have to be later next week or the week thereafter.
Also, FYI (I’ll prb either submit a patch or issue for this)
clj
[varname form & {:keys [migrations seed-fn log-level db-key] :or {log-level :fatal db-key :mockdb}}]
`(t/with-level ~log-level
(let [~varname (db-fixture ~db-key :migration-ns ~migrations :seed-fn ~seed-fn)]
(try ~form (finally (component/stop ~varname))))))
If the migration fails it doesn’t report why (since there isn’t a catch)…instead the component/stop just says it can’t call stop on nil.I fat fingered a migration and got confused for a while wondering what the nil was from.
there are a number of things that do not give adequate error messages....at least we're in good company there, eh?
@brianosaurus: Did you get logs about your migrations failing, because you should have?
@mahinshaw: Sorry, I mispoke. The migration was good but the seed tried to shove an integer into an :instant during fixture setup. Once I fixed my mistake it all started to work very well (except timbre/info doesn’t output inside of (provides and also the schduler not starting).
Don’t get me wrong, THANK YOU THANK YOU for untangled. I’d like to help with PRs once my crunch is over.
@brianosaurus: No problem. I was interested in logs to see where the issue propagated from. In the case of seed errors, there is a catch around those, and the log uses a fatal level.
ahh, ok. thanks for clarifying
The DatabaseComponent in untangled.datomic.impl.components
is where the migration and seeding happens.
Wondering if someone has a cleaner way to do this with untangled.spec - what I want is something like this:
(assertions
channel-result => {:db/id _}
)
Confirming that the channel receives something with an id I don't care about. I end up using =fn=> and destructuring in the fn:
`
(assertions
channel-result =fn=> (fn [{:keys [db/id]}] id)
)
I feel like maybe we'd need some sort of matcher library for that? Realizing I could shorten a bit using the keyword as the fn: (`channel-result =fn=> :db/id`)
I'm trying to avoid too much syntactic sugar. The fn arrow gives you the power to make your own and typically the core library functions already give you nice expressiveness...as you just found
@therabidbanana: I usually prefer something more like (contains? channel-result :db/id) => true
for looking in at things...just access the data structure and say what you want to find there
That's fair, I'm just used to all of the weird things rspec matchers provide in Ruby, I guess.
yeah, it is very tempting...but then you have a whole new language to learn, when everyone already knows the core stuff
(contains? channel-result :db/id) => true
definitely has a better response than channel-result =fn=> :db/id
on fail, so I'll probably go with that.
that is the other thing about even supplying =fn=>
: hard to make a quickly comprehensible failure message
@ethangracer: @currentoor OK, a first draft of parallel loading is on the branch feature/untangled-7 of untangled-server untangled-client, and the cookbook (sample recipe). I'll push the server/client libs as SNAPSHOTs to clojars. Use the branch on cookbook to see how to use it.
DEFINITELY NOT ready for prime-time...it does some really nasty stuff...but the API looks right, requires no changes on the server, and requires almost nothing on the client....so the API is right
awesome!
also leaks memory on server like a seive and is more chatty than a housewife in a 50's sitcom
@currentoor: There are definitely things you could fix about it. If you want some suggestions.
Ideally, to support this feature, we'd change the networking layer to use long-polling or websockets full-time.
This is a really important feature for webapps. Comes up in every non-trivial one I've ever worked in: How to cope with users that can submit long-running tasks without killing your server or making the user unable to do anything else.
On the plus-side, the internals of Om make it trivial to deal with the fact that they might "navigate away"....once the result is in the db, it is in the db...doesn't matter what changes on the screen while the bg job runs
might be nice to integrate a caching story on the server...e.g. "keep the result of this query for x minutes, in case someone else asks for it"
On a related, but different note: We can do some nifty things to make HTTP caching work without much coding (based on the Om wiki tutorial on caching)
@brianosaurus: I’ve actually fixed the error being swallowed in the DatabaseComponent, I just haven’t commited it yet if I remove the try catch here: https://github.com/untangled-web/untangled-datomic/blob/master/src/untangled/datomic/impl/components.clj#L56 errors propagate properly and you will see what’s wrong with your seed function
@adambros: thanks!
@therabidbanana: https://github.com/untangled-web/untangled-spec/blob/master/src/untangled_spec/contains.cljc#L59 is my current attempt at having something similar to what midje provides, just as a function my current gripe that I haven’t had time to think about, is how I want =fn=> checkers to be able to report when something fails in a custom and more detailed way
@brianosaurus: did you try it yourself? an easy workaround is to wrap your seed-function in a try catch, but the error will still be swallowed, but you can at least print and find it in your terminal
so like (try (link-and-load-seed-data …) (catch Exception e (println e)))
@tony.kay: how do you feel about sente?
we were thinking about having a core.async/go loop monitor the datomic transaction log and push relevant stuff to the right users using sente
@currentoor: i think @mahinshaw is finishing up a cookbook on that
oh cool
@currentoor: There is a bit of setup for that, but it will work. I have hooked up traffic with a websocket, and am moving to server push in a minute. I will post here when I get the cookbook code pushed to github.
@mahinshaw: awesome!