This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-09-11
Channels
- # alda (9)
- # beginners (28)
- # boot (94)
- # cider (21)
- # clojure (179)
- # clojure-android (4)
- # clojure-boston (2)
- # clojure-brasil (1)
- # clojure-denmark (1)
- # clojure-dev (194)
- # clojure-italy (1)
- # clojure-russia (8)
- # clojure-uk (1)
- # clojurescript (269)
- # clojurex (22)
- # clojutre (2)
- # cursive (4)
- # datomic (3)
- # devops (1)
- # events (7)
- # jobs (6)
- # ldnclj (30)
- # luminus (3)
- # off-topic (8)
- # reagent (3)
@alexmiller: the API docs for core.async seem to correspond to an unreleased version of core.async?
Yes, they do. We have multi release set up for core but its rarely an issue on the contrib projects so we just have master there
Unfortunately async has gone way too long without a release which weighs on me heavily but I need some oks from rich to move it forward
@alexmiller: are contrib docs rebuilt from master on each commit?
Yeah, commit hook
should be a release today afaik
alpha release that is
Clojure 1.8.0-alpha5 is out https://groups.google.com/d/msg/clojure/xZ2YpiKg2FU/VvnojP7rCgAJ
andrewhr: I think you've got a patch in there!
hopefully more to come :)
talking about it... there is something specific that you need someone to work on? If you haven't, I will look for myself for some random thing
hard to say right now. I really need Rich to pull some things from the triaged list
new doc for socket repl added to http://clojure.org/repl_and_main
@alexmiller: Socket REPL looks very nice
@cfleming: would love your feedback in particular
not sure if you've been following the prior patches or the session stuff I had in the prior rev (-12)
no worries
As I understand it, there’s currently no support for publishing STAR__ns__STAR__ to other threads, is that correct?
not in this version
the -12 version had the ability to "attach" from one client session to another and eval in it's env
Rich asked to pull that part out until we had more time to talk about it
I'm not sure the "attach" metaphor is something Stu/Rich are comfortable with but that's really mechanism
the key thing is the ability to capture the environment in one client and to eval-in that environment in the other
Right, and of course I can wrap executed forms to pass more data back, too, as nREPL does.
and that's just a few lines of code in the -12 patch
so I guess that's the question - what level of support do you need for this stuff and what would be useful
in the comments for [[http://dev.clojure.org/jira/browse/CLJ-1671 near the end is a rescued bit of description from how the session attach thing worked
I haven’t looked at the details yet - I’ll need to open the user session (where the actual interaction goes) and a background session for tooling commands.
I’m not sure yet whether I would configure the JVM to have two different servers listening or if both sessions could be open to the same server.
same server
no reason for two
Well, depends if they need different behaviour for some reason, not sure yet. Does the current REPL implementation print prompts, for example?
it does, although could be configurable
per-client
I mean, in principle, it doesn't do this now
but there could easily be a repl command like :repl/noprompt
or it could be a server property and you'd run two servers, but that's twice as many threads and sockets so seems like that shouldn't be necessary
I actually have a use case for that right now, but can’t mandate the Clojure version unfortunately
in data only mode - what do you do with err ?
well that's been a long lingering question
well out is going onto the socket, but yeah that's the real issue
The problem is, as soon as out goes over the socket then you can’t have a data-only connection based on reading forms
so that's do-able though
Which is what I was arguing in the original ML thread but I think it got lost in the noise.
don't pipe out to the socket and only return eval results
other than drop it on the floor? :)
Unless you return an nREPL style {:out “output here” :err “errors here” :values [values, here]}
yeah, interesting
I think having a mechanism to do that would be very useful, it’s relatively simple to implement but I think that’s what a lot of people are going to want for RPC style systems.
for the tooling repl, what is the scope of things you want to be able to do?
Off the top of my head: completion, macroexpansion, things like core.typed type checking
eval in their env covers a lot
Yeah - in general, I need to be able to eval in their environment, ideally without disturbing it
I’m playing around with ShimDandy to do some of this stuff, which may mean that I actually don’t need tooling connections at all, or perhaps only for completion
I’m also interested in trying to move away from completion coming over the REPL connection, so that may go away at some point too.
so the way the session attachment stuff works is that every time the user session evals, I clone their env and save it off
the tooling session can then push that env on the binding stack and eval in their env
and I was also going to the trouble of capturing *1, *2, *3
their full dynamic binding set
That would work for most things I think - off the top of my head, I can’t think of anything I need except *ns*
and *e*
the nuts-and-bolts of this is in http://dev.clojure.org/jira/secure/attachment/15046/clj-1671-12.patch if you search for repl-eval
and nicely if you set! a dynvar, you're only in your copy of the bindings so there is some isolation
yeah, * e will work
Things like test running etc also happen in the REPL, but I’m unsure about whether I should open a hidden REPL session for that anyway.
this is all based on (get-thread-bindings) in the session thread and push-thread-bindings / pop-thread-bindings in the tooling thread
that's the core of it - the rest is all just a mechanism to allow that to happen
Stu thinks maybe just the ability to "eval-in" a remote session's env would be better than the "attachment" metaphor but either are really just trappings around the binding stuff
heck, maybe that even exists somewhere already in core :)
it's essentially what binding does
or with-bindings / with-bindings*
Well, you need a way to get a reference to the bindings of the other context, right?
the key is really just having the ability to look up another session's bindings
right now, every repl session has a server+client identifier
and there is a global map where you can look up data stashed per session
that's in clojure.core.server/servers
although it's access is intentionally somewhat protected
So in the user session/tooling session case, how would I get the ID of the user session from the tooling session?
that is the crux of it :)
I had in -12 a command :repl/sessions that gives you a vector of the ids for all sessions
and there is a dyn var clojure.core.server/session that is set in every client session
so the user session can say who it is - but I wasn't sure if you have some non-intrusive way to ask that
could also use the wrapping technique though
stepping way back for a second...
In general, anything I do to interrogate the user session will be visible to the user.
if you have the ability to run your own socket server with it's own client accept function
you can define your own custom repl protocol or have it do whatever you want
like you could insert code to always update a global var with the ns of the current repl
Yeah, I thought about that. I can also do that from the client. It feels very dirty, though
just like I'm inserting code to steal the thread bindings
but what if that was actually supported by the server socket repl as a function you'd set
I can wrap evaluations in a form like that from the client too, without needing to run a different server
yeah, although the set! location could be just a generic function call the repl client function invokes that's provided as an option to the socket repl accept fn
it's built-in that is
I do much more complicated things like that for macroexpansion right now. I prefer it to middleware like CIDER uses.
you could also call get-thread-bindings and save that off if you desired
then you could do anything you like
Right, that would probably be the best option, then create a var containing an atom named with a UUID representing the session to store it in.
I like this as a direction - I don't even need the session gunk at that point
ok, well I'm going to at least work up a patch over alpha5 along these lines
I thought about doing that for the clojure.main REPL in Cursive, but opted for prompt parsing for reasons which escape me right now.
well, you couldn't get back into the same server to get the data, right?
it's having multiple connections that helps here
and then the other useful thing we discussed is the data-only connection
which I'd like to think about a bit more
but could easily be repl config options or something
and then you would start a 2nd server
thanks for your time on this - this has been hugely helpful
how we deal with out/err is the hardest part of the data version
It might be interesting to think about a simple framing mechanism for that case, although I’m not sure if it’s required.
and something Rich may have thoughts about
If you just read repeatedly, you’ll get the symbols concatenated together as a single reply without framing of some kind.
Same for two numbers etc. Repeated reading only really works for delimited things (strings, collections)
yeah it seems to me like the stream-oriented cases are primarily human-oriented right?
I've only asked humans so far
I need to go back and read those messages from Rich on the ml thread
re-read that is
perhaps :)
again, with a custom client accept function though - it's up to you
we don't have to a priori make any decisions on the language side
so you could definitely provide a framing data repl server accept fn
which I am happy about
I’ll think about it. I like the flexibility of the minimal core, what I’m not sure of is how much it would be useful to provide to the user as example or built-in implementations.
this is the best discussion I've had all week :)
at a bare minimum I will build some examples to test it and maybe they become options that are available, or maybe libs, or maybe just documentation
well I won't decide that now :)
later! again, big thanks for your time.
No worries, I’ll try to do a client implementation for Cursive sometime soon, and let you know how it goes.
@alexmiller: by any chance, do you have a set of benchmarks for protocol method calls that you use?
nothing official. I've created various things at different times