This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-20
Channels
- # aleph (12)
- # announcements (7)
- # aws (6)
- # babashka (36)
- # beginners (161)
- # boot (1)
- # calva (6)
- # cider (21)
- # clj-kondo (13)
- # cljs-dev (28)
- # cljsrn (1)
- # clojars (3)
- # clojure (13)
- # clojure-colombia (1)
- # clojure-europe (10)
- # clojure-spec (12)
- # clojure-uk (47)
- # clojuredesign-podcast (2)
- # clojurescript (67)
- # datascript (8)
- # datomic (21)
- # duct (3)
- # emacs (6)
- # events (1)
- # fulcro (6)
- # graalvm (98)
- # jobs (1)
- # kaocha (18)
- # luminus (1)
- # malli (7)
- # off-topic (56)
- # pathom (5)
- # re-frame (18)
- # reagent (3)
- # reitit (9)
- # remote-jobs (3)
- # rewrite-clj (10)
- # ring (1)
- # shadow-cljs (155)
- # spacemacs (2)
- # sql (5)
- # tools-deps (27)
- # vim (86)
- # xtdb (2)
Can I print the bytecode of a compiled function at the REPL? Just curious.
I know I can touch the three parts, the name, the var, and the function itself, but can I print the function's code?
@jaihindhreddy https://github.com/clojure/tools.emitter.jvm https://github.com/clojure-goes-fast/clj-java-decompiler
Thanks guys! 💯💯
fwiw, there was this nice article that touches on this topic too with some practical advice: http://clojure-goes-fast.com/blog/introspection-tools-java-decompilers/
Anyone good with statistics? I'm trying to answer a question. If I scratch 100 lottery tickets, what can I expect my winnings/losses to be within 66% of the time, 95% of the time, etc...? I'm not sure what words to use to describe this. I think it's something like "I want to see the graph of the cumulative distribution function for 100 scratches of a particular scratch off lottery game"?
I think that's more probability (specifically combinations) than statistics
although maybe when you include the distribution you get there
phrases like "within 1 standard deviation" and "within 2 standard deviations" seem possibly relevant
I think what I need are the formulas in this stackexchange post. But nothing is making sense. https://stats.stackexchange.com/questions/6534/how-do-i-calculate-a-weighted-standard-deviation-in-excel
# (prize_value, num_prizes_in_game)
# In statistics terms, I think this is: (observation, weight*)
# *Once we convert the scalar number of tickets to percentages
# by dividing the number of tickets at each prize level by the total
# number of tickets in the game.
tickets = [
(15e6, 4),
(1e6, 13),
(1e5, 4),
(2e4, 351),
(1e4, 358),
(5e3, 1066),
(1e3, 24488),
(500, 52608),
(200, 175536),
(100, 825885),
(50, 1409291),
(40, 2116878),
(30, 3534425),
(0, 13051157),
]
total_num_tickets = sum(t[1] for t in tickets)
scratch_tickets_percentages = [(t[0], t[1] / total_num_tickets) for t in tickets]
# Since we converted the weights to percentages, this is simply 1.0
# And since the sum of the weights is 1.0, we don't really need
# to divide by it in the following formula. But I'm leaving it there
# for reference because I'm not sure if I should have converted the number
# of tickets into percentages. Will that affect anything? Is it
# effectively the same going forward?
sum_weights = sum(t[1] for t in scratch_tickets_percentages)
weighted_mean = sum(
weight * val
for val, weight in scratch_tickets_percentages
) / sum_weights
sum_of_squares_of_weighted_means = sum(
weight * (val - weighted_mean) ** 2
for val, weight in scratch_tickets_percentages
) # AKA variance
Sorry for the Python, but off-topic eh? That gives me a variance of 43095998 (standard deviation of 6564), but what is that the answer to? $6,564 is obviously not the standard deviation of buying a single $30 lottery ticket. It's also obviously not the standard deviation of buying every ticket in the game. So while I think I followed the formula correctly, I'm not sure what question that formula is answering.
End goal of this is I want to plug numbers into a formula, like https://stackoverflow.com/questions/10138085/python-pylab-plot-normal-distribution, and get a visualization of where I can expect to be after 10 tickets, 100 tickets, etc...
What's a good way to keep up with version changes on a project? (Clojure, JavaScript, java etc...) To know what new features are in a version. For instance, if I have a clojure project It would be nifty if you could subscribe to get notified if any deps had new versions and see those changes in a uniform way. Or as a point on time manual tool. Such a view would depend on people writing a changelog in the same way. Tag on question, do changelogs have a specification?
This is as close to a spec for changelogs as you'll find I think https://keepachangelog.com/en/1.0.0/
This might be hard to give general advice on, and it also might be fairly arbitrary, but when it comes to the data structure of an event
type that components of a system communicate, do people prefer vectors ie [:new-message/dogs {:payload 123 :timestamp 12345 :id 11}
or maps like {:event/topic :new-message/dogs :event/data {:payload 123 :timestamp 12345 :id 11} :event/timestamp 12344}
? The vector style feels a bit nicer to type out when dispatch is usually based on topic, or when events are nested. however the map is easier to extend over time and more flexible, and I've found that it's pretty common in my usage to dispatch on something other than topic anyway. Anyone have any thoughts on this?
i perfer the hashmap, vectors are best for items where the order implies something. Here the order implies what the values are, which is better reflected by keys in a map.
I think the exception to this is if your very sure your api will be stable forever, then using values in a list might be ok bc it reduces the overhead. e.g anything in core, etc..
Yeah that's an interesting point too about the ordering. back to the nested/wrapped events, the ideal case for the vector events seems to be when dispatch is solely based on topic aka event-type aka first vector item. In that case it's a case of "first, what is the type of this thing, then based on that type hand the thing itself somewhere"
i'm not sure what context the question is asked in. But i would like to see more event dispatch systems do dispatch like clojure does multimethods where it can be done off arbitrary code. For one, i quickly found that event names overlaped :logout-x :logout-y , etc.. As opposed to at least having it be tagged based [logout][x] [logout][y]
there was a post on clojurverse that also talked about the pros and cons of using data for code in that context.
it was a heavy topic, so i can't really summarize it, but it was from a week or so back, might be worth digging up if your building such a system.
The way I often like to think of it in general is that data is the raw representation of an idea, the language for the idea, and is a mapping of keys to values. The vector is a shorthand, an implicit mapping of integers to values (by position) that themselves often are implicitly supposed to represent some other key. So the map is the explicit data, the vector is implicit shorthand
I'm a Clojure learner, coming from a distant procedural language history but I've been thinking about this a lot. A vector is values/facts, onto which our mind projects an idea. A mapping of keys with meaningful names makes the idea more explicit. It is human-readable meta-data about declared knowledge. The data that is code is how-to knowledge. Data, facts and knowledge may all be wrong and need to be corrected later. Immutability allows the changes to be audited.
@sogaiu I've been using the vector style for awhile and it does feel nicer to me to type out and destructive.
[:component/foo [:component.foo/bar {:args-for :bar}]]
can be nice when you multiple levels of routing, one to pass the message to the :component/foo
handler and then that handler knows how to deal with the :component.foo/bar
message. This is nicer to type and destrucure than the nested map alternative.
the places i've seen vectors that come to mind immediately are: unrepl, re-frame, and punk
aha well I'm carefully trying to call it a mapping in place of a map -- I feel like the words map and vector are themselves the perfect words to use when differentiating between these kinds of mappings
Yeah that's an interesting point too about the ordering. back to the nested/wrapped events, the ideal case for the vector events seems to be when dispatch is solely based on topic aka event-type aka first vector item. In that case it's a case of "first, what is the type of this thing, then based on that type hand the thing itself somewhere"
Examples btw where we use a similar sort of mapping with implicit meaning is lisp lists / function calls themselves! You could have written things like {:fn add :args [1 2 3]} and called the language MAPP but we stuck with the shorthand of (fn arg1 arg2 arg3) ahaha
vectors are inherently positional, and thus have implicit attributes
implicit usually means something is hidden/assumed - the tradeoff is typically that it's easier to type, more concise, but also less explicit about meaning
implicit also typically means it's more fragile (harder to extend without violating assumptions)
one common dodge here is to base your api on the explicit form, but support an implicit form for ease of use and a means of transforming from implicit to explicit
often the explicit form is more amenable to programmatic transformation and manipulation too
ah and here I almost wrote something like that; what I was going to say is 'if I was going to use a short form, I'd often still want an explicit form underneath it as the base'
the tradeoff for doing both is of course - more code, bigger api
but then I started getting into a conversation with myself over the trade offs and left it
you can look around and find lots of examples all across this set of dimensions
full let bindings = explicit, destructuring = implicit (there is an undocumented function destructure
that converts from destructuring forms into let bindings)
This is as close to a spec for changelogs as you'll find I think https://keepachangelog.com/en/1.0.0/