Fork me on GitHub
#off-topic
<
2019-09-30
>
agigao11:09:52

OOP : ( self… :face_with_monocle:

lepistane12:09:06

should i take / or domain? first time buying domain so i have no experience with this can u guys share any thoughts on this to help me make decision?

henrik13:09:00

All of the above! I got .org and .net as well, to thwart spammers a little.

💯 4
henrik13:09:32

Eh, given that it’s an uncommon enough word, that is.

danielstockton12:09:43

@lepistane Have you had offers accepted? Namecheap lists http://theabc.com at $10k. None of them are already available.

danielstockton12:09:30

$10k is hard to justify

Conor12:09:09

I imagine that <abc> is just a placeholder and the end bit is the important one for the question

👍 4
Conor12:09:50

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

Conor12:09:55

But it's up to you, basically

markmarkmark12:09:42

my understanding is that you can never go wrong with .com

lepistane13:09:34

@danielstockton abc is just placeholder for what i need <x>.io or 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

danielstockton13:09:58

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 😛

manutter5113:09:33

I usually poke around with variations on abc until I find a combination that nobody’s using. It can take some creativity, of course.

Mattias14:09:18

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?

danielstockton14:09:59

More expensive than .com usually. I think it mostly became popular with techies/apis.

Alexander Heldt14:09:55

yeah, its short and rings I/O

lepistane14:09:26

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 but @mattias504

danielstockton14:09:31

I've seen a lot of companies start with .io and then buy the .com when they have some money

emccue16:09:23

Can someone explain JVM fibers to me?

emccue16:09:34

I really don't understand how they would function

emccue16:09:51

and how would they play with something like core.async?

emccue16:09:09

im used to the explanation of cooperative concurrency being cheap

hiredman16:09:18

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

hiredman16:09:48

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

hiredman16:09:28

jvm fibers turn that suspending and resuming into a vm level feature so all code can be suspended and resumed without being rewritten

hiredman16:09:58

which also makes the extent of the suspend/resume dynamic, not limited to the static(known at compile time) extent of the go macro

hiredman16:09:37

fibers give you a superset of what you get from the go macro

emccue17:09:56

so if fibers get released, what will that mean for core.async

🔥 4
lilactown17:09:45

maybe we don’t need it 🙂

lilactown17:09:44

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

lilactown17:09:14

using JVM fibers would be relegated to only JVM Clojure programs

Alex Miller (Clojure team)17:09:01

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

Alex Miller (Clojure team)17:09:31

ask me again in 2 years :)

dpsutton17:09:18

i wonder how it will progress if the cljs version cannot benefit from the updates on the jvm.

lilactown17:09:37

IME core.async use in CLJS is relatively niche

jsa-aerial18:09:47

IME, that would be quite the opposite

👍 8
lilactown18:09:36

hmm. I’ve only seen it used heavily when doing websocket or Chrome (using chromex) plugin programming

jsa-aerial19:09:23

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

danielneal11:10:28

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

Alex Miller (Clojure team)17:09:10

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.

jsa-aerial18:09:47

IME, that would be quite the opposite

👍 8
hiredman18:09:33

cljs core.async has some great bugs

👍 4
hiredman18:09:54

(clj does too, but the cljs ones are older)

👍 4
vemv19:09:23

> 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!

borkdude19:09:32

@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.

vemv20:09:56

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.

seancorfield20:09:00

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?

seancorfield20:09:34

To work on core.async requires a commitment of time/effort from someone who is authorized to work on a Contrib project.

vemv20:09:44

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

hiredman20:09:35

many of the bugs already have patches bit rotting away in jira

hiredman20:09:13

so it isn't like getting a posse together is going to do anything

vemv20:09:16

review time deserves as much time/appreciation as coding time

hiredman20:09:09

to put things in terms of a system of queues, increasing output upstream of the limiting constraint is not going to increase throughput

vemv20:09:25

but you are implying money can only be invested in output and not in input

hiredman20:09:45

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

vemv20:09:33

we also can get an individual to review the existing patches

hiredman20:09:40

reviewing and merging changes is the bottleneck, and as far as I have seen, there is little interest to spread that around

hiredman20:09:39

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"

vemv20:09:39

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

hiredman20:09:43

ASYNC-165 for example fixes a bug in the cljs go macro, and the patches are 3+ years old now

hiredman20:09:16

it doesn't matter why they are aren't getting to it if there is no interest in letting other people get to it

vemv20:09:44

> 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?

hiredman20:09:17

I happen to have a few patches for core.async sitting waiting(including the 3+ years old one)

hiredman20:09:20

I don't know

hiredman20:09:57

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

👍 4
hiredman21:09:57

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

hiredman21:09:44

I also fixed the exception handling machinery for cljs's go macro, but the first round of fixes for that never got merged

borkdude21:09:48

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.

vemv21:09:53

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?

seancorfield21:09:43

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.

👍 4
hiredman21:09:53

it is a shame that the irregular development of "Stable" means bugfixes don't land either

👍 4
vemv21:09:18

@U04V70XH6 Observation very much in point. At the same time, owners can change. It might boil down to a matter of incentives and rationale.

vemv21:09:09

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

seancorfield21:09:42

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?

seancorfield21:09:05

(In fact, perhaps those are the second and first Q respectively, not the other way round?)

borkdude21:09:46

Maybe someone inside Cognitect could own the project other than Rich?

👍 4
vemv21:09:29

Exactly, in fact I don't think CT projects have been carried out by non-owners of the respective funded projects

borkdude19:09:17

btw I haven't run into these bugs myself, probably not using core.async hard enough 😉

borkdude20:09:37

I know you shouldn't do this, but I just discovered you can do this:

user=> (def c @#'cond)
user=> (c nil nil 1 2 3 4)
(if 1 2 (clojure.core/cond 3 4))
Aha, so you can take the value of a macro 😉

🤯 20
vemv20:09:50

Nice one 🙂 guess nil nil are placeholders for something like &env?

borkdude20:09:50

yes, guess so

borkdude20:09:26

user=> (defmacro foo [] [&form &env])
#'user/foo
user=> (#'foo 'foo 'bar)
[foo bar]