This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (113)
- # announcements (6)
- # beginners (18)
- # boot (294)
- # bristol-clojurians (3)
- # cider (90)
- # clojure (122)
- # clojure-berlin (42)
- # clojure-czech (1)
- # clojure-dev (19)
- # clojure-italy (4)
- # clojure-japan (5)
- # clojure-korea (10)
- # clojure-russia (1)
- # clojure-uk (5)
- # clojured (1)
- # clojurescript (179)
- # datomic (2)
- # editors (10)
- # indycljs (1)
- # jobs (1)
- # ldnclj (29)
- # off-topic (33)
- # onyx (11)
- # reagent (48)
- # yada (18)
markbillie: process management in the jvm is really sad, like there is no standard way to get the PID of a child process
markbillie: I think some of us might be relying on the unix policy of reaping children that haven't been orphaned, but under Windows you have no such convenience
Great work by @lazy-lambda — Replicator: A bootstrapped ClojureScript REPL for Android! http://tahmid.me/posts/2015-07-15-bootstrapped-cljs-repl-for-android.html
hello. i have a question about Hoplon. is there a good way to interpret html from text field inside a loop-tpl construction? thanks.
How is the best way a report an possible issue with the compiler api? (mainly related with cljs.build.api/watch and cljs.build.api/build)
Also, it is usually good to be able to repro a potential issue with a variation on Quick Start
and build is not aware of
Inputs, instead of it, it works in terms of
The watch will works properly but the compilation not! Because the Compilable protocol has implementation for Vector that does not interpret the fector of files. Instead of this, it interpret a vector as list of expressions.
I think stuff surrounding multiple directories isn't really a bug—it is just the way it works today.
(Referring to this JIRA in example above: http://dev.clojure.org/jira/browse/CLJS-1308 )
I Understand, but at this moment for the compilation and watching multiple directories I should use
(b/watch (b/inputs "test", "src") ... instead of the most obvious way
(b/watch ["test", "src"] ...
because the build function already has implementation for vector that does not expect paths
Perhaps the enhancement could be filed. I think I see what you are asking now: “Where are potential strategies for compiler changes discussed?”
One pattern I've seen: A ticket is written, and then discussion happens (in the past in IRC) or proposed patches are added to the ticket and commented upon in the ticket. I suppose this process isn't described in the ClojureScript wiki (where the process isn't yet as formal as Clojure's).
Or, even before a ticket is written, sometimes a light discussion occurs as to whether an enhancement is itself reasonable. Like “would it make sense to watch multiple directories?”
Ok, I'll try to write a enhancement proposal later. Thanks @mfikes for your suggestions!
FWIW, I think there are places that work in terms of a single directory, and that may be for no other reason than nobody's yet asked for multi-directory support.
I also may be missing what you are saying: “The watch support API appears to support multiple directories, but it doesn't work.”
It works, but not how I expert to be works. If I do (cljs.build.api/build "src") it interprests "src" as path, but if I do (cljs.build.api/build ["src", "test"]) it interprets that as a vector of expressions instead of vector of paths.
One thing: the
api namespace is supposed to act as a clean barrier so that things needn't be coupled to internal knowledge. It's docstring should clearly say how to watch multiple directories.
I just took a look at the API docstring for
watch. It isn’t obvious that there is an
inputs function defined earlier that pertains to
In other words, Replete isn’t yet properly dealing with the distinction between
println for example.
Is there a reason why it has to call an "update" function internally, rather than just returning the evaluated string (that then the client can format itself)
@frankie: It actually used to do that initially. But then there are things like
(do (print “hi”) (println “hello”))
@niwinz: if you want to pass multiple directories you must pass
(cljs.build.api/inputs “src” “foo” …)
@dnolen I'm aware of it. Thanks! But if you read the rest of the conversations. The final issue is ... (cljs.build.api/build "src") interprets "src" string as path but if you pass a vector of strings it interprets them as expressions or something similar. And the issue is about the not obvious behavior.
is it expected that
(.. element -dataset -fooId) does not preserve
@bostonaholic: it probably get’s minified by advanced compilation. You can do (aget (.-dataset element) “fooId”) instead
@dnolen: yeah, that's what's happening and using
aget works. I'm just wondering if it shouldn't get minified
@dnolen - forgive my ignorance but where is that page pinned? (newbie Slack user)
Here's an odd question. I have a function that returns an atom. Inside the function a timer regularly updates the value of this atom. Should the name of the function end with a bang, or not?
func-that-returns-atom! or just
you’ve got a function that returns an atom, presumably always the same atom, and every
:timer-step seconds a loop inside the function
swap!s the value in the atom?
@chris_johnson: well, a new atom each time, otherwise, yes - so you would just call it one time
so you’d expect caller A at time a to get an atom with value a’, and caller B at time b to get an atom with value b’, or would A’s atom also now hold b’?
I guess I’m struggling with the reason for returning an atom instead of just a calculated value based on the time
the original caller would hold onto the atom locally and just deref it to get the new value
I’m really new here and somewhat of a newbie in general, but I think I’d put at least one
! at the end of that method name tbh
you’ll want the antigrav lifters and a full-atmosphere hazmat suit to move that thing around
yeah, the weird thing is that the state I'm mutating is state that originates within the function, so kinda different
@meow: no grief , just curious why complect the change state with a container holding the current value.
(defn request-animation-frame "A delayed callback that pegs to the next animation frame." [callback] (.start (goog.async.AnimationDelay. callback))) (defn measure-fps "Returns an atom containing the frames-per-second measured at regular intervals." ( (measure-fps 500)) ; Measure every half-second ([interval] (let [fps (atom 0) frame-count (atom 0) starting-point (atom nil)] (letfn [(callback [timestamp] (request-animation-frame callback) (if-not @starting-point (reset! starting-point timestamp)) (let [elapsed (- timestamp @starting-point) f-count (swap! frame-count inc)] (if (>= elapsed interval) (do (reset! fps (->> (/ f-count elapsed) (* 1000) (.round js/Math))) (reset! frame-count 0) (reset! starting-point timestamp)))))] (request-animation-frame callback)) fps)))
@meow: I would use core.async go-loops instead of atoms for all of this, and like a sliding window over the last few intervals.
like keep a sum and a queue, subtract popped, add pushed, divide by a fixed number each time.
@gtrak: yeah, I guess I could write one that way - will probably do that just for the experience
on the consuming end of this all I want is a number that's magically updated in a way that doesn't have a negative impact on what it's measuring, of course, right!
Yea, i just don't use atoms that much, and i can see wanting to decouple the storage from the updates.
I sure don't want to take a callback as an argument as who knows what that function might do
So I was thinking about use cases, particularly in atom-shell/electron. If I am building something that takes Clojure code as input, like an IDE, I see how useful that would be. But I’m curious about other uses.
I know they’re not generally considered a good idea, but since you’re just evaluating a string, I’d think that it would be possible somehow.
@gtrak: you were right - taking a callback makes total sense and I like the code a lot better - thanks
(defn listen-fps! "Repeated callback containing the frames-per-second measured at regular intervals." ([callback] (listen-fps! callback 500)) ; Measure every half-second ([callback interval] (let [frame-count (atom 0) starting-point (atom nil)] (letfn [(measure-fps [timestamp] (request-animation-frame measure-fps) (if-not @starting-point (reset! starting-point timestamp)) (let [elapsed (- timestamp @starting-point) f-count (swap! frame-count inc)] (if (> elapsed interval) (let [fps (->> (/ f-count elapsed) (* 1000) (.round js/Math))] (callback fps) (reset! frame-count 0) (reset! starting-point timestamp)))))] (request-animation-frame measure-fps)))))
if you work on any large codebase, you'll be surprised how little you actually need atoms
this fps code started with code I found in-the-wild that I'm slowly moving into something more elegant
by the time its done it will seem so simple and make me wonder why the "in-the-wild" examples were so complex
I'm already shaking my head in amazement at the examples that got me to this point - boy were they complicated. Just shows that even with clojure one can make a mess.
i think it's probably easier to make a mess, but it makes the right things more easier than it makes the wrong ones.
@gtrak: "It makes the right things more easier than it makes the wrong ones." I totally propose that as the new Clojure motto. 😉
@dnolen: can you clarify and expand on what you mean when you recommend using
(goog.object/get …) over
aget? Is that in all cases?