Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an arglists-str response attribute in info op. #32

Closed
gtrak opened this issue Apr 14, 2014 · 3 comments
Closed

Add an arglists-str response attribute in info op. #32

gtrak opened this issue Apr 14, 2014 · 3 comments

Comments

@gtrak
Copy link
Contributor

gtrak commented Apr 14, 2014

Skips the serialization hassle if it's only for display purposes.

@bbatsov
Copy link
Member

bbatsov commented Apr 14, 2014

Alternatively we can have a dedicated arglists op for efficiency. That would reduce the payload of the response significantly.

@gtrak
Copy link
Contributor Author

gtrak commented Apr 14, 2014

Is it that bad? Honestly have no idea about elisp's efficiency, but I wouldn't worry about clojure's at all here.

As an alternative, I was considering a general kind of 'select-keys' sort of thing for requests.

@bbatsov
Copy link
Member

bbatsov commented Apr 14, 2014

I'm mostly worried about connections to remote nREPL servers, since the entire var info could be pretty big, although I doubt this would impact performance noticeably. At any rate - I don't think this is something over which we should fret too much right now.

gtrak added a commit to gtrak/cider-nrepl that referenced this issue Apr 15, 2014
@gtrak gtrak closed this as completed Apr 15, 2014
dpsutton pushed a commit to dpsutton/cider-nrepl that referenced this issue Feb 14, 2019
dpsutton pushed a commit to dpsutton/cider-nrepl that referenced this issue Feb 14, 2019
…te library"

This reverts commit 8b79657.

After further deliberation I've decided that it's best for the project
to have no runtime dependencies.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants