This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-17
Channels
- # bangalore-clj (4)
- # beginners (60)
- # boot (63)
- # cider (2)
- # cljs-dev (22)
- # cljsrn (3)
- # clojars (32)
- # clojure (133)
- # clojure-gamedev (1)
- # clojure-germany (17)
- # clojure-italy (1)
- # clojure-russia (11)
- # clojure-serbia (16)
- # clojure-spec (35)
- # clojure-uk (75)
- # clojurebridge (1)
- # clojurescript (83)
- # community-development (25)
- # core-async (43)
- # cursive (15)
- # datomic (28)
- # emacs (2)
- # fulcro (108)
- # graphql (5)
- # hoplon (15)
- # lein-figwheel (6)
- # leiningen (39)
- # lumo (106)
- # new-channels (1)
- # off-topic (4)
- # om (26)
- # om-next (53)
- # onyx (46)
- # other-languages (2)
- # perun (1)
- # protorepl (5)
- # re-frame (13)
- # ring (18)
- # ring-swagger (1)
- # rum (6)
- # shadow-cljs (82)
- # spacemacs (19)
- # specter (5)
- # sql (3)
- # test-check (31)
- # unrepl (12)
- # untangled (2)
- # vim (109)
Morning
Mornin'
(fortunately i didn't bugger up the other two replicas and recovery was relatively straightforward)
@carr0t were i to build these AMIs again i would do exactly that
zk is for dc/os
although kafka and onyx are using it too
@mccraigmccraig what are you doing with zookeeper that filled up the disks ? I know what zookeepr is and what it’s used for, especially in DC/OS context. But I’ve never experienced this. What did you do to get into this state in the first place ? You gave your server instances very few GBs… ?
@dotemacs it was partly me being dumb - i uploaded a large CQL file to the root volume. there is plenty of space on the non-root volumes, but it seems that this dc/os deploy has put the ZK db on the root volume
most of the space is on /var/lib/docker, /var/lib/mesos and /dcos/volumeN volumes. ZK however is at /var/lib/dcos and whoever at mesosphere (who produced the base AMI scripts) didn't think that merited its own volume... it lives on the 8GB root volume
Bejeezuzz! Black Friday is making a black hole in my bank account 😞
It is at some places
Like Amazon if you're on Prime
Curries have black friday stuff going on too
Officially, but some places have already started
I thought a lot of places did stuff like ramp up prices for the month beforehand so the deal looked much better than it actually was
When the local radio station is blasting out “black friday deals” for a local shop, it’s all gone too far.
How do people feel about things being :require ...
but not used at all in the file later on? clean up? or leave as is (this code is already in production)
i always clean up. i keep all requires alphabetised to avoid duplication (which always happens), but if you're requiring something for side effects (something i find happens a lot with spec) then it doesn't have a :refer
or an :as
in it, in which case i know to be careful
For purely side-effecting requires, e.g. loading protocol extensions, I’ve adopted the convention of including them outside the ns definition as (require 'foo.bar) ;; side effect
, that way I can use cljr-clean-ns
without fear.
I would like to clean it up.... I guess if I get it wrong I would get a compile error 🙂
@thomas also double check they are not loading defprotocol extensions, a legitimate case of require that does not show up as usage in a namespace
clean up. easy to do with clojure (clj-refactor has a fn), harder with clojurescript. and what @reborg said. that gives you runtime errors
that said, if you find yourself in a positon where you need to load a namespace solely for side-effects, you might be either organizing your namespaces wrong (this with the recent exception of spec namespaces) and not keeping type/protocol definitions and declarations together, or you're having too much state in your programs :)
Is there an argument for using a top-level require
For such side-effecting namespace loading?
in some cases there is I'd say (`.spec` segments, very specific situations like e.g. in the cljs compiler)
not sure I follow @bronsa, we have dozens of suppliers and counting, each one of them extending a bunch of defmethods, I surely don't want all of those implementations to end up in a single namespace. Is that a code smell?
Well... I was thinking it might stand out as "here be side-effects"... I ran across it with tools.deps
because it has multi-methods across multiple namespaces.
I have heard someone called out the practice of using java.jdbc's protocols for extending joda dates & such going against "best practices", due to this reason.
You have to require all the namespaces to make the parsing work but you don't use those namespaces otherwise. You literally require them for the side-effect of defining the methods.
-1 you have namespaces whose only reason is to register defmethods for a specific supplier
i'd say 1 is a big code smell and should be in a single file, 2 is fine IME, as you keep functions that manipulate a certain object and the stateful defmethods/extends coupled
@seancorfield yeah and I don't like that about tools.deps TBH, I don't see why they have to be namespaces and not just either separate files that just get load
ed in (like what clojure.core does), or simply alll in a file
I have seen another option:
(defn activate-magic! []
(defmethod …))
Which was a compromise in order to satisfy refactor.el I think.Since it's Cognitect code I sort of assume it's how they think we should do it 😀
It's number -2 here (phew). It's much better to search for a supplier and have all the info you need in a single place (actually a folder with several ns). If the defmethod was elsewhere, it would make life more difficult. Having said so, there is one ns that collects all the side-effecting ones, so when that's required, everything is registered
tools.deps itself was broken for a few days initially precisely because it didn't require the file
ns for side effects
That's only in tools.deps.alpha.makecp
so if you happen not to :require
that -- I wasn't using it, only reader
at first -- then you run into that problem.
The code is strangely structured, IMO, since the alias handling is not public, and you need access to that in tooling if you want to wrap tools.deps
properly.
Ah, I missed the single all-loading ns.
Right, it's the weekend y'all, and thus for most of us non @ work Clojure types...... #ClojureTime! For me, it's all about reacquainting myself with SICP after a few failed attempts at going through it a few years back. Anyone else got any exciting plans?
That's only in tools.deps.alpha.makecp
so if you happen not to :require
that -- I wasn't using it, only reader
at first -- then you run into that problem.
@paulspencerwilliams #ClojureTime here, too. 🙂 I've found ways to use Clojure a little at work, but the vast majority of my constructive time with it is after my daughter's gone to bed.
Hopefully my weekend #ClojureTime will be continuing to work on the new documentation for Expectations and improving clojure.test
compatibility!