Cider: print-namespace-maps est toujours vrai

Créé le 2 mai 2018 · 8Commentaires · Source: clojure-emacs/cider

Comportement attendu, comportement réel et étapes pour reproduire le problème

Évaluer une carte avec des clés avec espace de noms comme
{:person/name "Fred" :person/age 50}
dans le cidre repl imprime la valeur de retour suivante
#:person{:name "Fred", :age 50}
Cela est dû au fait que *print-namespace-maps* défaut true .
Normalement, il devrait être possible de changer la valeur de cette var en permanence avec set! ainsi :

user> (set! *print-namespace-maps* false)
false
user> *print-namespace-maps*
false

Cependant, le comportement réel est donc :

user> (set! *print-namespace-maps* false)
false
user> *print-namespace-maps*
true

De même, il devrait être possible de changer temporairement la var avec binding :

user> (binding [*print-namespace-maps* false]
        [*print-namespace-maps* {:person/name "Fred" :person/age 50}])
[false {:person/name "Fred" :person/age 50}]

Mais, bien que la var semble changer, le comportement souhaité reste à voir ;

user> (binding [*print-namespace-maps* false]
        [*print-namespace-maps* {:person/name "Fred" :person/age 50}])
[false #:person{:name "Fred", :age 50}]

Informations sur la version du CIDRE

;; CIDER 0.15.0 (London), nREPL 0.2.13
;; Clojure 1.9.0, Java 1.8.0_92

Version Emacs

GNU Emacs 24.5.1 (x86_64-apple-darwin15.3.0, NS apple-appkit-1404.34) du 01/06/2016

Système opérateur

OSX El Capitan, version 10.11.6

Source

Reefersleep

Commentaire le plus utile

Je ne sais pas s'il s'agit d'un problème spécifique au CIDER, je peux reproduire ce problème dans un REPL de Leiningen.

danielcompton le 2 mai 2018

👍2

Tous les 8 commentaires

Je ne sais pas s'il s'agit d'un problème spécifique au CIDER, je peux reproduire ce problème dans un REPL de Leiningen.

danielcompton le 2 mai 2018

👍2

Cela suggère que c'est quelque chose à voir avec l'implémentation de nREPL ou REPLY.

https://github.com/cemerick/nREPL/blob/master/src/main/clojure/clojure/tools/nrepl/middleware/interruptible_eval.clj - il semble que l'implémentation d'eval fasse ce qu'il faut, en supposant que (get-thread-bindings) fait ce qu'il est censé faire. L'implémentation dans Clojure 1.9 a l'air bien et elle fait ce qu'il faut au REPL. Cela suggère que la gestion de session de nREPL ou quelque chose en amont de celle-ci ne capture pas et ne restaure pas correctement *print-namespace-maps* .

https://github.com/cemerick/nREPL/blob/master/src/main/clojure/clojure/tools/nrepl/middleware/session.clj#L108 - cela peut être un peu suspect, il ne sait pas *print-namespace-maps* mais cela ne doit pas être un problème.

clojure.main/with-bindings établit des liaisons racine pour tout ce qui passe par clojure.main/repl , ce qui inclut la poussée de la liaison par défaut *print-namespace-maps* de true . La définition racine de *print-namespace-maps* dans clojure/core_print.clj est false . Ce comportement peut être confirmé avec clj -e "(get-thread-bindings)" qui rapportera que {#'clojure.core/*print-namespace-maps* true ...} .

arrdem le 3 mai 2018

👍1

Cela suggère que c'est quelque chose à voir avec l'implémentation de nREPL ou REPLY.

Je doute que REPLy fasse quelque chose de spécial en plus de nREPL, donc probablement un problème nREPL.

bbatsov le 5 mai 2018

clojure.main lie print-namespace-maps , puis conserve sa valeur à travers les évaluations dans le fichier repl. Je ne sais pas comment faire l'équivalent dans nrepl, mais c'est ce qu'il faut.