Closed m-g-r closed 7 years ago
Currently I'm going to reproduce my MarkLogic environment (I have to give my working laptop where it was installed previously). As soon as I will be able to run MarkLogic server on my personal laptop I will start to work on this issue.
Hi
In general, it would be nice to be able to just collect the result (usually as a list of strings I guess), and not have it inserted in a buffer.
That is also true for Clojure functions that I want to access from Emacs. Right now, I have written a simple function cider-eval-from that is based on cider-read-and-eval from cider-interaction.el; see attached file. cider-eval-form.el.txt
It just evaluates some Clojure code and prints the result in the echo area of Emacs. This is good enough if just want to execute something (like REST calls) and see the results. But also for this I know need to retrieve the result to do something with it in Emacs Lisp. (Here, I want to retrieve the connection config for cider-any-uruk from Cloure.)
Could this be a second backend for cider-any? Cider-any-clojure maybe? :) I got it right that cider-any is meant to make it easy to evaluate just anything via cider, right?
So this is something that is not only necessary for Uruk and MarkLogic, but in general. So it could also be tested without any MarkLogic installation. ;)
What do you think about all this?
Cheers, Max
Update: If I want the return value from clojure in emacs-list I now cider-eval-form/value that uses nrepl-sync-request:eval instead of cider-interactive-eval.
Something like that for cider-any would be nice. cider-eval-form.el.txt
Update: Improved version: cider-eval-form.el.txt
For now, I've put this into xdbc-selector. See file https://github.com/xquery-mode/xdbc-selector/blob/master/cider-eval-form.el
I'm done with first part of this issue. cider-any-string->list
is reimplemented as part of the #13 issue resolution. Currently it stays in its branch. You can look at it here
I think we will have this fix eventually in the master
branch, but if you want it immediately, I'll cherry-pick it.
I rewrite cider-eval-form.el
as we discussed earlier. Please see https://github.com/xquery-mode/xdbc-selector/pull/2
I keep this module with same name, since its used only in xdbc-selector
package. If you think there is a better place for this tiny utility module, say me and I'll move it there.
Hi,
cool. Please, keep also here in mind my recent bugfix in commit https://github.com/xquery-mode/xdbc-selector/commit/67a93889530eeb6283265e644bdbfbda2af6d704 Does your code still check that a cider connection exists? (cider-current-connection) might just return nil.
Cheers, Max
I can confirm that this doesn't check for the cider-connection but just files with a non-helpful error, caused by trying to use a connection that doesn't exist.
Fixed.
Cool, works nicely (with the added cider-ensure-connected that you've added in another commit).
Why is cider-any-eval-uruk-sync in cider-any-uruk? Does it actually have to be specific to uruk? In other functions I also just call cider-any-eval and not something specially using the uruk backend of cider any.
The reason why I put cider-any-eval-uruk-sync
into uruk module:
/Modules/security.xqy
cider-any-uruk-file-name-handler
functionsecurity.xqy
module content, so it calls cider-any-uruk-document-get
Answering your question, this function isn't specific to the cider-any-uruk
, but it specific to the uruk
clojure library.
I agree that code duplication and copy-pasted solutions are problems.
But in this branch there are problems with functionality implementation so for now I concentrate my attention on this rather code style.
Ok, I didn't think about your new error handling. Then it is ok, of course.
Doesn't the cider-any-eval then also to open /Modules/security.xqy in the error buffer compilation in the say way, so there should be something uruk specific to call instead of cider-any-eval?
Cheers, Max
Yes, compilation buffer must open /Modules/security.xqy
uri of
course. But I don't know how... What xquery I should run to see this
module content? I was able to do that with absolute file name on
remote MarkLogic server. But I can't tell if this is an appropriate
solution.
By intention cider-any-eval
is content agnostic function. It can
evaluate any form no matter if it is clojure or xquery or anithing
else. It delegates this job to the backend.
In the new-api
branch I move this line forward and remove nrepl from
cider-any-eval
. Also this function has new name eval-any
in the
new-api
branch. Its has only one purpose now - to be a generic
minor mode with common key bindings.
All xquery
specifics details must be implemented in the
eval-any-uruk.el
module. Also I make this decision more explicit by
moving this module into eval-any-xquery
.
Hope this make sense.
Compilation buffer: see the other reply in https://github.com/xquery-mode/cider-any/issues/13#issuecomment-255762837
Project structure:
Maybe we can just merge eval-any and eval-any-xquery into something like xquery-repl?
Remove whole backend thing and just write one minor mode on top of -eval and -eval-sync function?
I'm not insist on any name, you can suggest what ever you like.
I think cider is an implementation detail in the case of this module. This functionality can be done on top of any MarkLogic client library, so user interface and key bindings remains the same.
Maybe we can call it marklogic.el
, marklogic-mode
, marklogic-eval
and marklogic-eval-sync
?
Let's think about it for a night. It does sounds simpler!
Bye Max
Did you find sophisticated name for new module?
Well, marklogic.el
, marklogic-mode
, marklogic-eval
and marklogic-eval-sync
is a nice naming schema. What I don't like is that it all contains MarkLogic, as this is not official MarkLogic software, and also it talks xquery and REST, so it could actually also implemented for eXistDB, the same way it could use a different foundation than Cider and Uruk as you've said before.
So it is an XML database interface or helper. But xmldb-mode sounds as inelegant and ugly as xdbc-selector. Thus, maybe a completely different, more original name.
What about Ape? Referring to the librarian of the unseen university in the Discworld novels of Terry Pratchett? He is also a helper for a database (and also not a monkey). This would give: ape.el
, ape-mode
, ape-selector
, ape-eval
, ape-eval-sync
? What do you think about it? I like it because it is short.
Cheers, Max
Hi Artem,
OK, let's get rid of the backend system and just make the single cider-any-uruk backend standalone. And if you've nothing against it, I suggest that Ape naming schema. Also, I think, Ape Selector is mildly funny. :)
Cheers, Max
Hi Max,
I totally agree with Ape naming schema. But I think we need additional description in the README :) Like that one.
I'll start this refactoring today in the new-api branch. I leave other branches untouched for now. They will be moved to the new naming scheme before merge.
Regards, Artem.
Hi,
cool, yes. But of course we cannot directly quote. But we should write something. :) Hey, looking at the web for short descriptions of the Libarian I have an even better name: Oook. :) What about oook-eval, Oook selector, etc.? I llke it much better! Also, it might have less a negative connotation (as, for example, in "ape mode", http://www.urbandictionary.com/define.php?term=Ape%20Mode)
Ook or Oook is the sound that the Librarien makes, and a much more direct reference to Discworld than 'ape' as it is more specific to it. Just google 'ook' vs. 'ape'. See https://en.wikipedia.org/w/index.php?title=Ook_language_(Discworld) or http://www.lspace.org/books/toc/toc-orangutan.html
Oook -- is all the Librarian at the university of the Discworld ever utters. He is the sole staff member of the greatest database of knowledge, and as such offers a very versatile and helpful interface to it.
I'm looking forward for your work in the new-api branch!
Cheers, Max
I've done code transition to the oook name. Please see README describing installation instructions for pprint and associate to file plugins. I understand that asking for the filename each time isn't optimal work flow. But it will at least prove that new approach works.
Regards, Artem.
Hi Artem,
cool! Who do we proceed to do the change of the projects? Should we carve out the new-api branch and make this a new repository xquery-mode/Oook? I'd do the same to xdbc-selector (making a new branch that uses oook and make this a new repository oook-selector). Afterwards mark the old repositories as abondoned.
If we rename the project, the URLs of the repositories will also change. And also this would leave behind cider-any with the old backend system, should anyone want to base other work on it.
What do you think is the preferred way to make the change over of both projects?
Other things: What's asking for a filename each time?
Cheers Max
PS: This text was a suggestion for the readme if you like it:
Oook -- is all the Librarian at the university of the Discworld ever utters. He is the sole staff member of the greatest database of knowledge, and as such offers a very versatile and helpful interface to it.
Hi Max,
I move new-api
branch in to new Oook
repository. error-buffer
branch also was ported to new repository and adapt oook
naming scheme already. Future work on it will be done there.
I made some transition of xdbc-selector
to the oook-selector
under new repository. I tried my best, but I'm not completely sure that I've done all things right. Please check code base attentively, I'm afraid I may introduce bugs unintentionally.
Other things: What's asking for a filename each time?
For now when you enable oook-to-file-mode
it will ask for the result buffer-file-name each time you type C-c C-k. I leave a TODO note for you in the oook-selector repository. It point to the old style variable binding. Feel free to change oook-eval-buffer-to-file
function in any way to be compatible with oook-selector.
Also I've added Librarian description to the README :)
Are we done there? Or there are some points to do with code transition?
Regards, Artem.
Have a look at my latest commit. This has to be rewritten! I allowed myself to commit it nevertheless as it is an additional function that is only used by my newest xdbc-selector and nothing else.
The commit message is: add a function cider-any-string->list that is basically like cider-any-string but returns a list of values.
This is seriously hackish and should be replaced as soon as possible!
See source code comments, especially: +;; hackish without lexical let, should be improved!