This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (1)
- # announcements (7)
- # aws (4)
- # beginners (52)
- # calva (11)
- # cider (20)
- # clj-kondo (36)
- # clojure (53)
- # clojure-austin (1)
- # clojure-brasil (1)
- # clojure-conj (1)
- # clojure-europe (27)
- # clojure-italy (17)
- # clojure-nl (11)
- # clojure-norway (2)
- # clojure-spec (41)
- # clojure-uk (39)
- # clojuredesign-podcast (2)
- # clojurescript (22)
- # clojutre (14)
- # community-development (24)
- # cursive (6)
- # data-science (1)
- # datomic (38)
- # duct (3)
- # figwheel-main (8)
- # fulcro (34)
- # funcool (8)
- # jackdaw (3)
- # jobs (2)
- # off-topic (84)
- # pathom (3)
- # re-frame (4)
- # shadow-cljs (8)
- # tools-deps (5)
- # vim (7)
should i take
first time buying domain so i have no experience with this
can u guys share any thoughts on this to help me make decision?
I imagine that <abc> is just a placeholder and the end bit is the important one for the question
If you are a student of history you will probably know that the history of the British Indian Ocean Territory is not a particularly happy one, so personally I would avoid .io
abc is just placeholder for what i need
the<x>.com might've made more sense?
@conor.p.farrell is correct.
@markmarkmark that's what i gathered from researching online but that
the somehow doesn't sound right maybe because
abc is 2 words that
the adds extra
Oops, took it a bit too literally. I also wanted to suggest not announcing it, in case someone else liked the sound of one of them 😛
I usually poke around with variations on
abc until I find a combination that nobody’s using. It can take some creativity, of course.
In the never ending series of “things you always wanted to ask but...” - why are .io so common since a couple of years? I never got what happened. Are they cheap? Something else?
More expensive than .com usually. I think it mostly became popular with techies/apis.
as far as i know (few days of looking at this topic) it's mostly because domain is treated as global (like .net, .com...) and there are a lot of available options unlike in .com
I've seen a lot of companies start with
.io and then buy the
.com when they have some money
ClojuTRE talks are up https://www.youtube.com/watch?v=kPuGS4_9mRc&list=PLetHPRQvX4a-c3KDRTxxwGRmEMutL8Apf
core.async rewrites clojure code locally (with in the lexical scope) of the go macro, in to a format that makes it possible to suspend and resume the execution of that clojure code
code that hasn't been transformed by the go macro cannot suspend and resume, so if from go macro code you call some function that blocks the thread forever, then you have blocked one of core.async's limited threadpool threads forever
jvm fibers turn that suspending and resuming into a vm level feature so all code can be suspended and resumed without being rewritten
which also makes the extent of the suspend/resume dynamic, not limited to the static(known at compile time) extent of the go macro
but one thing to note is that because core.async acts at the syntax level, it is relatively cross-platform; e.g. it works in ClojureScript, and could possibly be adapted by ClojureCLR and other platforms
hard to say what it will mean for core.async until serious analysis is done on it. given that it's unlikely to be available till jdk 14 at the earliest, I think it's highly unlikely that core.async would be able to make use of it immediately
i wonder how it will progress if the cljs version cannot benefit from the updates on the jvm.
hmm. I’ve only seen it used heavily when doing websocket or Chrome (using chromex) plugin programming
any messaging. also it is nice (and very simple) at separating modal ui stuff. and anything like mathjax updates. I find it to be much simpler at this sort of thing than any explicit use of callbacks
I definitely tend to lean on built in promises in js. Can usually achieve most of the same stuff, and core async can expand to quite a lot of code, which can swell the js size
they are completely separate implementations anyways, so depends whether the apis would diverge in this case or not. if not, then it doesn't matter.
IME, that would be quite the opposite
> cljs core.async has some great bugs would love some Clojurists Together effort in that direction. Mailed Daniel some time ago and supporting certain kind of projects (currently very unlikely to be funded) doesn't seem off the radar!
@vemv Not sure if that would help anything, it's not just a matter of digging through some work. There are several tickets waiting for review/screening in JIRA if I'm not mistaking.
seems bit of a dense topic. Cognitect currently asks for some money from the community (https://www.patreon.com/cognitect ), so it's not impossible that they could give core.async a boost if some appreciation/interest was given.
That's licensing for REBL so I don't think you can just expect them to accept money from CT and divert it to core.async -- who is actually going to do the work?
To work on core.async requires a commitment of time/effort from someone who is authorized to work on a Contrib project.
As prefaced, I do think it's a dense topic 🙂 The suggestion I transmitted to Daniel @ CT was: 1.- Capture the interest in core.async et al first. Currently this capture has many flaws 2.- Armed with money and reified community interest, you can make specific offers that project owners (however busy) can consider more seriously
to put things in terms of a system of queues, increasing output upstream of the limiting constraint is not going to increase throughput
I am implying if you get a bunch of people together to write patches, those patches are going to make the backlog in jira worse
reviewing and merging changes is the bottleneck, and as far as I have seen, there is little interest to spread that around
e.g. when you ask alex about getting a patch merged the response is not "it would get merged faster if I could get help reviewing it" the response is "when I get to it, but I have a bunch of other stuff on my plate"
It seems plausible to me that that we could be mistaking lack of interest for lack of capacity
I can literally intepret that from
when I get to it and
bunch of other stuff
ASYNC-165 for example fixes a bug in the cljs go macro, and the patches are 3+ years old now
it doesn't matter why they are aren't getting to it if there is no interest in letting other people get to it
> ASYNC-165 for example fixes a bug in the cljs go macro, and the patches are 3+ years old now that's not something I didn't know > it doesn't matter why they are aren't getting to it if there is no interest in letting other people get to it you don't think that a company that literally does consulting for a living can be incentivized to work on an area of its expertise?
I happen to have a few patches for core.async sitting waiting(including the 3+ years old one)
I don't even use core.async for cljs, I use it for clojure and just happened to see that issue and write a patch for it. What I would really love is getting more exception handling patches merged
The way exceptions were handled before was super broken, after about a year I got some patches merged to fix it, and there have been some follow up bugs to fix there that have been sitting for years now
I also fixed the exception handling machinery for cljs's go macro, but the first round of fixes for that never got merged
You could also argue: if (fixing several things in) core.async was of that much business value, there would be incentive from within to fix it.
I think most people (project consumers) prefer applying workarounds to getting involved at all (which can be as easy as upvoting issues) clojure.coree rightly pointed out that some old issues/patches have practically no upvotes. So why would they prioritize those?
It's important to look at this page when you're talking about Contrib libraries: https://clojure.org/community/contrib_libs#_contrib_libraries -- core.async is "owned" by Rich himself and is marked "Stable". That means "working but development is irregular". So unless you can get agreement that someone else should take over as owner of core.async, any work you push for on that library will take Rich away from something else.
it is a shame that the irregular development of "Stable" means bugfixes don't land either
@U04V70XH6 Observation very much in point. At the same time, owners can change. It might boil down to a matter of incentives and rationale.
FWIW I've used core.async in cljs in 2-3 production projects (not solo). Old issues like lack of dynamic bindings can be quite a constraint As a practitioner I do have an incentive to make change happen
The first question is: would you (or some other user of core.async in cljs/clj) be willing to step up and own the project? The second question is: do Clojure/core think core.async could be maintained by a community member outside Cognitect?
(In fact, perhaps those are the second and first Q respectively, not the other way round?)
Exactly, in fact I don't think CT projects have been carried out by non-owners of the respective funded projects
btw I haven't run into these bugs myself, probably not using core.async hard enough 😉
I know you shouldn't do this, but I just discovered you can do this:
Aha, so you can take the value of a macro 😉
user=> (def c @#'cond) user=> (c nil nil 1 2 3 4) (if 1 2 (clojure.core/cond 3 4))