@flyboarder yeah, it’s weird though because the div being added/removed is not a parent but a sibling of an ancestor

Do you have a link to the element?

not sure what you mean by that @flyboarder ?

@thedavidmeister: like a link to the github file

oh right, nah i don’t

it’s in a private repo and has a lot going on anyway

it looks something like this though

(div (if-tpl c (div “foo”)) (div (input)))

and c can change from true to false as the user types in input

(div (div (input)) (if-tpl c (div "foo")) ) does not lose focus

(div (div (if-tpl c (div "foo”))) (div (input))) also seems ok

@thedavidmeister could have something to do with the hanging alternative clause

does when-tpl have the same issue?

i have happened upon a braintickler re: settimeout ordering

maintaining your own queue only seems to work if you have a uniform timeout amount in ms

@micha ooh, worth trying out

ie 0

@alandipert yeah.. unless you had a master loop and something like a crontab?

@thedavidmeister i think so, yeah

it wasn't very hard to see it go out of order

i can't believe i never knew this

something like this? https://github.com/padolsey/cron.js

well, i dont personally want cron exactly

well no

but that kind of thing waves hands

but yeah, 'discrete event simulation' its called, i think

i need it to have a proper SLEEP function in my basic interpreter

wait so you're saying that if i do like

setTimeout(function() { console.log("one") }, 0)
setTimeout(function() { console.log("two") }, 0)

it could print

two
one

?

@micha yeah apparently

is there a demo of it?

@micha http://stackoverflow.com/a/28236904

i am skeptical

it’s like… a browser specific thing according to that post

it must put the things on a queue

like when you call setTimeout it needs to return and keep executing your code

so it has to put the callback somewhere

on a queue of course

and it has to finish putting the first callback somewhere before it can start evaluating the second setTimeout call

color me skeptical af

lol

if you do like

setTimeout(function() { console.log("one") }, 150)
// some other code
setTimeout(function() { console.log("two") }, 150)

then maybe

hm yeah, i can't get it to break in ff or chrome

i think i do need to make my own master loop for my sleep code tho

since i can't let other timers pre-empt my thing

https://jsfiddle.net/7oL84rao/

i don't think it's true

it's like the pool dye that turns blue with pee

i did a similar thing

(def n 1000000)
  (def xs (vec (range n)))
  (def ys (atom []))
  (dotimes [i n]
    (.setTimeout js/window #(swap! ys conj i) 0))
  (.setInterval js/window
                (fn [] (when (= (count @ys) n)
                         (println "equal?" (= xs @ys))))
                1000)

https://jsfiddle.net/7oL84rao/1/

there cleaned up and simplified

sure, i don’t have any ie boxes on this computer

so i can’t check that

(def queue (atom cljs.core/PersistentQueue.EMPTY))

(defn handle []
  (let [[not-before thunk] (peek @queue)
        now                (.getTime (js/Date.))]
    (if (<= not-before now)
      (do (thunk) (swap! queue pop))
      (.setTimeout js/window handle (- not-before now)))))

(defn enqueue
  [ms f & args]
  (let [not-before (+ (.getTime (js/Date.)) ms)]
    (swap! queue conj [not-before #(apply f args)])
    (.setTimeout js/window handle ms)))

this solves the non-0 timer delay problem, by giving you your own queue

i guess it depends on the idea that all calls to enqueue will result in different values of now, which i'm not sure is true

not-before is just setTimeout i believe

that's the guarantee of it

you mean the whole code is ident. to setTimeout?

i believe so

i don't think so, since i have my own queue there

it only compares the time for the thing at the head of the queue

ie the queue is not ordered by ms

how is that different?

it's different because if you have 2 sequential setTimeout calls, and the first waits longer than the 2nd, the 2nd could go off first

that couldn't happen in my thing

is the timeout for the same number of ms?

for the two calls?

let's say the first call timeout is 10x the 2nd one

or 100x, whatever

in my thing the waiting is sequential

probably only useful for sleep

(enqueue 3000 println "one")
  (enqueue 0 println "two")

it would only ever manifest when you block the event loop for 100x the first timeout

which is already fucked

https://dl.dropboxusercontent.com/u/12379861/Screenshots/045855fb-0622-4785-958f-a44c0592b0a3.png

yeah but this is exactly what i want for sleep in basic

this is the driver loop for instructions

you want to block the event loop?

not the browser's event loop

but hte program's

only blocking the browser event loop will manifest the issue you describe though

otherwise they will always fire in the correct order

at least this is my belief

eg timeout A set to 1500 ms

i'm solving a differnt problem

and B set to 15 ms

the only way A will fire before B is if you block the event loop for more than 1500 ms

(.setTimeout js/window println "one" 3000)
  (.setTimeout js/window println "two" 0)

and even then only if the event queue isn't sorted in the browser

that should print out two, one, right?

yes

yeah, not what i want

if i have two sequential sleep commands, i don't want the code after the shorter one to go first... it needs to wait for both in order

hence my own queue

oh ok

that makes sense

now my question is, in a JS program does new Date().getTime() ever return the same number twice

looks like... yes

you could just retry then

put a validator on the atom or whatever

if the date is the same it could reject it

yeah i did something like that

oh right, i could make my own function to get the ms

i kept track of a “highest seen"

and it always returns a unique one by running the thing long enough to get at least 2 diff ones

altho that slows my thing down

if now > highest seen return now else return highest + 1

but ideally though the second settimeout wouldn't be evaluated until the first one fired already

solving a different problem but maybe that helps?

like a settimeout loop that waits until the sleep is done before making another sleep

actually, i don't think the time problem affects me

since i'm already ordering the events in a queue, i don't have to worry about order

ie the enqueue call order governs what happens next. when exactly it happens might be a lil fuzzy but thats ok

i think if you implement settimeout atop settimeout tho, then you need it

madness

yeah, not a thing to do

starting on a blog post about ah btw

what’s ah?

it's this thing we use to deploy services on AWS

really more of a pattern plus this shell script

dude awesome

we need to polish off the s3 secret storage concept also

yeah definitely

i've been thinking about it lately

i guess we just need some conventions for ourselves

we need that thing

lol i made the repo

so that's one song in the bag

next song

oh ok, so examples for deploying hoplon, or more general than that?

@thedavidmeister it's more general

the cleaned-up thing, calling it after:

(def default-queue (atom cljs.core/PersistentQueue.EMPTY))

(defn- handle [q]
  (let [[not-before thunk] (peek @q)
        now                (.getTime (js/Date.))]
    (if (<= not-before now)
      (do (thunk) (swap! q pop))
      (.setTimeout js/window #(handle q) (- not-before now)))))

(defn after
  "Enqueues a function for invocation after some number of ms. The function is
  not invoked until after all previously enqueued functions have been invoked."
  ([ms f] (after default-queue ms f))
  ([q ms f]
   (let [not-before (+ (.getTime (js/Date.)) ms)]
     (swap! q conj [not-before f])
     (.setTimeout js/window #(handle q) ms))))

@micha when-tpl didn’t help with the focus thing, fyi

all good though, happy enough to just leave my errors sitting in a wrapper div for now

@micha: circling back to our previous conversation, are you on board for factoring out the cljs ns+ into ns for cljs.hl files (and a clojurescript pull request for :refer :all)?

ns+ is also broken on clojurescript 9.

i'm also thinking that, in the next version of castra, we should drop the jquery promise in exchange for an ecmascript 6 promise and a polyfill. something like https://github.com/taylorhakes/promise-polyfill.

the advantage of this is that it provides compatibility when chaining together calls with the browser's native apis like websockets, getUserMedia, and webrtc.

@jumblerg: We can implement castra via a multimethod so we can factor out the "how" portions to providers

I have being thinking about providers is general and I believe it's a bad idea. It's hard enough getting one provider to do what we want and having libraries that work in a sane way. IMO another provider should be a fork. Flexibility is not always good and may be pretty bad.

@mynomoto: But I think being able to move between different providers is essential for diverse applications, see feathersjs for example https://docs.feathersjs.com/clients/rest.html

Support all possible things is not essential. Not make those impossible I think it's fair. Make abstractions that allow everything is bad practice imo.

I have used hoplon with rest and castra, used websockets with it and never needed the provider concept. The cell abstraction was rich enough for all use cases I had.

I'm not saying I'm against replacing implementations, I'm against having multiple ones.

@mynomoto: https://instagram.com/p/BNCMJZoA0aE/

i think i agree with @mynomoto

the problem is with libraries really

it would be unfortunate if the libraries get fractured to the point where they only work with some permutation of providers

hoplon really should i think standardize that layer

so you can write libraries in a well-factored way

maybe that means that hoplon should have its own compatibility api

like its own Event type, and its own XmlHttpRequest type etc

Agreed doesn't hoplon do two things really, give you meaningful abstractions and a default implementation for it

it is "hosted" like clojure

like clojure doesn't box strings or primitives

this lets you do lots of stuff

but then it is tied to the platform

same with hoplon

it doesn't wrap the jquery Event object for example, or the dom element, etc

honestly it's hard to see the real benefit of un-jquerying

like with castra, i don't really understand what is holding back websockets or webrtc or whatever

I think it will be more productive to the Hoplon ecosystem to stick with jquery (not un-jquerying things), keep things simple, so hoplon should only be concerned with creating/updating the dom and adding event listeners. And have a sane release cycle following what Ember does, this would remove the problem of shipping compiled hoplon libraries and make boot-hoplon optional for users.