Clojurians Log v2
portal
I have a bunch of portal code that I want to use across projects as a dev dependency (format-specifying taps, routing between portal instances, etc.). Is there a preferable way to do this? I was thinking creating a project and using it as a local dep, but I think that would require some overhead anytime I wanted to edit that code while working in another project. Lighter weight would be a symlink to a git ignored file in the "dev" dir, which would require one-time overhead when creating a new project. Git submodule, perhaps? Anyone else found a better solution?
I realize this might be a Clojure question, not a Portal question, but I'm guessing it's a fairly common consideration for Portal users.
Once my portal code was stable, I created project templates that would add it to new projects. The code is kept in the Dev directory and included on the path aica a Clojure CLI alias https://practical.li/clojure/clojure-cli/projects/templates/practicalli/ To add code to existing projects I would use a similar Clojure CLI alias with a local/root to include the Portal code from a local project. This approach would also be useful if the portal code was still evolving. If the Portal code was quite stable and unchanging, then I would use a git coord for the dependence, after sharing the portal code in a suitable project.
I use local dependencies plus a global dev profile in deps.edn - as long as that profile is used I have access to my portal extensions/helpers
Most of my Portal code is in Calva custom REPL snippets so it's available to all projects (and in my VS Code/Calva setup repo on GitHub).
@seancorfield Interesting! But I use Emacs (mostly), so while it that would be possible (what isn't in Emacs?), I think it would be awkward to put Clojure in my Elisp. Are you using cljc code and Joyride?
@jr0cket Ah, yes, I think that sounds like about what I was looking for, if I'm understanding. Using local:root to point to a non-project dir in an alias in the global Clojure config.
Then you just start the repl with that alias when you want the Portal code. Curious if you can then hop over to that dir and start editing code while connected to the project repl and it would "just work." Guess there's one way to find out!
@selahb https://github.com/seancorfield/vscode-calva-setup/blob/develop/calva/config.edn is my REPL snippets for starting Portal and for eval'ing various things into it. https://github.com/seancorfield/dot-clojure/blob/develop/src/org/corfield/dev/repl.clj is my code to start nREPL plus other stuff.
Portal and Joyride are a big part of why I switched to VS Code (from Emacs, with a couple of detours).
@selahb changes made to the code made in a project included via a :local/root would need to be evaluated in the REPL, but the repl itself shouldn't need to be restarted (as the project is already on the class path)
@seancorfield I love the idea of Joyride, but my Emacs muscle memory runs deep (not just the keybindings, but the idioms), so I have a hard time getting into VS Code. It's my secondary work environment and my first choice for Python dev, though, so I'll keep trying to dig deeper! Incidentally, I borrowed liberally from Joyride's code base to get my Obsidian.md REPL running.
I'm building a custom viewer for a parse tree, as a debugging aid for writing grammars. navigating the tree using clojure.zip would be handy, but I can't require clojure.zip in Portal CLJS. since that's a standard CLJS library, I am puzzled.
The cljs runtime in Portal is using sci which requires manual specification of which namespaces to include. https://github.com/djblue/portal/blob/master/src/portal/ui/sci/libs.cljs#L58 are those namespaces. It should be relatively easy to add more namespaces.
Did you want to try making the changes locally to see if they solve the issue?
I can give it a try, sure.
hm. perhaps I did it wrong? I added it like this
(def namespaces
(merge
(sci-import/import-ns
clojure.zip
goog.crypt.base64
#_...deps.edn to use :local/root. but I still can't p/eval-str my viewer ns.`clojure.zip` doesn't have any requires, so I suppose I could send that namespace to the running portal env and it would start working? but it has JVM-isms in it like Exception
I'm moving again by pasting clojure.zip's code into a CLJS namespace in my classpath and requiring that instead.
I’ve got a bit of a brain-teaser here. I am tapping a var that contains a lazy sequence of vectors. It gets displayed like this:
Ohh, this is likely due to the data matching the spec for stack traces. https://github.com/djblue/portal/blob/master/src/portal/ui/app.cljs#L451-L452. For now, you can add some metadata to use the inspector by default, (with-meta [...] {:portal.viewer/default :portal.viewer/inspector}) . I should update portal to always use the inspector by default and only opt-in to other viewers.
Great. Thanks for the tip. I'll give it a try tomorrow.
My thinking was that it would be a good way to discover new viewers. If data matched a spec, use that viewer instead of the inspector. However, I feel like it's not worth it given that it can cause confusion at times.
Right. An elegant idea that unfortunately leads to brittleness in some scenarios.
https://github.com/djblue/portal/commit/30a243854cf8606eb446d194a4023f327d4d18af will fix this in the next release 👍
Excellent. Many thanks. 😄
Otherwise, there are no error messages anywhere.
The REPL quite happily prints it like this:
I can’t seem to find out what is so exotic about this value that the portal does not want to render it.