I haven't published the intellij plugin just yet as I would like some folks to try it out first before it's available in the plugin repository. If you are an intellij user, you can pull down the https://github.com/djblue/portal/releases/download/0.17.0/portal-extension-intellij-0.17.0.zip and install it manually from disk. Feedback welcome!

Another major highlight is multi-select which enables n-arity commands. To perform a multil-select, hold down cmd on osx and click multiple values (haven't tried this on windows yet). You can now select any two items and diff them directly via lambdaisland.deep-diff2/diff! This also works for any user supplied commands.

To launch the UI in intellij, do (def idea (p/open {:launcher :intellij})) . Documentation will be updated soon.

I have installed the intellij plugin from the zip and I have confirmed the plugin is active but I don't see any new viewer. How can I get to the portal viewer?

The tool window is guarded with https://github.com/djblue/portal/blob/master/extension-intellij/src/main/clojure/portal/extensions/intellij/factory.clj#L97-L105

That was it. My clojure project is a directory within a larger IntelliJ project.

When I create a new IntelliJ project pointing to the correct subdirectory, I have the Portal tool viewer.

Thanks!

I could remove this limitation, just thought most people would be annoyed to see the portal tool window if it wasn't a clojure project.

would be nice to have the option, in my case I also have a problem with multiple modules inside

altough I just tried in one that's a simple clojure project, I still can't see the portal tool window

Is the repl process running inside the project?

> I could remove this limitation, just thought most people would be annoyed to see the portal tool window if it wasn't a clojure project. My opinion: If you don't want to see the portal viewer, simply close it in IntelliJ. I suspect the isApplicable guard will be more annoying than useful

@U2845S9KL agreed 💯

https://github.com/djblue/portal/commit/3a4e835509028071741aba996c1b062ce81f4252 will be part of next release 👌

yes, REPL running inside the project

Are you running a version of intellij with https://plugins.jetbrains.com/docs/intellij/jcef.html?

is this something I have to do myself? Im on latest stable intellij, and didn't remember changing anything related to JCEF

I got some errors in the log

com.intellij.diagnostic.PluginException: Cannot create class portal.extensions.intellij.Factory (classloader=PluginClassLoader(plugin=PluginDescriptor(name=portal, id=djblue.portal-extension-intellij, descriptorPath=plugin.xml, path=~/Library/Application Support/JetBrains/IntelliJIdea2021.2/plugins/portal-extension-intellij-0.17.0.jar, version=0.17.0, package=null), packagePrefix=null, instanceId=5, state=active))
	at com.intellij.serviceContainer.ComponentManagerImpl.instantiateClass(ComponentManagerImpl.kt:870)
	at com.intellij.serviceContainer.ComponentManagerImpl.instantiateClass(ComponentManagerImpl.kt:887)
	at com.intellij.openapi.wm.ToolWindowEP.getToolWindowFactory(ToolWindowEP.java:129)
	at com.intellij.openapi.wm.impl.ToolWindowManagerImpl$$special$$inlined$processDescriptors$1.accept(ToolWindowManagerImpl.kt:2317)
	at com.intellij.openapi.wm.impl.ToolWindowManagerImpl$$special$$inlined$processDescriptors$1.accept(ToolWindowManagerImpl.kt:88)
	at com.intellij.openapi.extensions.impl.ExtensionPointImpl.processWithPluginDescriptor(ExtensionPointImpl.java:293)
	at com.intellij.openapi.extensions.ExtensionPointName.processWithPluginDescriptor(ExtensionPointName.java:156)
	at com.intellij.openapi.wm.impl.ToolWindowManagerImpl.<init>(ToolWindowManagerImpl.kt:2362)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
	at com.intellij.serviceContainer.ConstructorInjectionKt.instantiateUsingPicoContainer(constructorInjection.kt:52)
	at com.intellij.serviceContainer.ComponentManagerImpl.instantiateClassWithConstructorInjection(ComponentManagerImpl.kt:877)
	at com.intellij.serviceContainer.ServiceComponentAdapter.createAndInitialize(ServiceComponentAdapter.kt:48)
	at com.intellij.serviceContainer.ServiceComponentAdapter.doCreateInstance(ServiceComponentAdapter.kt:36)
	at com.intellij.serviceContainer.BaseComponentAdapter.getInstanceUncached(BaseComponentAdapter.kt:113)
	at com.intellij.serviceContainer.BaseComponentAdapter.getInstance(BaseComponentAdapter.kt:67)
	at com.intellij.serviceContainer.BaseComponentAdapter.getInstance$default(BaseComponentAdapter.kt:60)
	at com.intellij.serviceContainer.ComponentManagerImpl.instantiateService(ComponentManagerImpl.kt:1084)
	at com.intellij.serviceContainer.ComponentManagerImpl$preloadServices$1.invoke(ComponentManagerImpl.kt:1056)
	at com.intellij.serviceContainer.ComponentManagerImpl$preloadServices$1.run(ComponentManagerImpl.kt:58)
	at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1407)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
	at java.base/java.util.concurrent.ForkJoinTask.doInvoke(ForkJoinTask.java:408)
	at java.base/java.util.concurrent.ForkJoinTask.invokeAll(ForkJoinTask.java:845)
	at com.intellij.serviceContainer.ComponentManagerImpl$preloadServices$2.run(ComponentManagerImpl.kt:1071)
	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1728)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: java.lang.NoClassDefFoundError: clojure/lang/Var
	at portal.extensions.intellij.Factory.<clinit>(Unknown Source)
	at java.base/jdk.internal.misc.Unsafe.allocateInstance(Native Method)
	at java.base/java.lang.invoke.DirectMethodHandle.allocateInstance(DirectMethodHandle.java:482)
	at com.intellij.serviceContainer.ComponentManagerImpl.instantiateClass(ComponentManagerImpl.kt:830)
	... 33 more
Caused by: java.lang.ClassNotFoundException: clojure.lang.Var PluginClassLoader(plugin=PluginDescriptor(name=portal, id=djblue.portal-extension-intellij, descriptorPath=plugin.xml, path=~/Library/Application Support/JetBrains/IntelliJIdea2021.2/plugins/portal-extension-intellij-0.17.0.jar, version=0.17.0, package=null), packagePrefix=null, instanceId=5, state=active)
	at com.intellij.ide.plugins.cl.PluginClassLoader.loadClass(PluginClassLoader.java:235)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	... 37 more

That's an interesting stacktrace, not sure why Caused by: java.lang.NoClassDefFoundError: clojure/lang/Var would happen, especially since the clojure jar is part of the distribution zip :thinking_face:

@U066U8JQJ, I can reproduce if I crack open the zip and install lib/portal-extension-intellij-0.17.0.jar. Is that how you are installing the plugin? If so, try installing the .zip archive directly.

ah that is it

trying to reinstall now

working, its awesome, thank you very much!

You are correct, I forgot to update the readme after the switch. Although I don't know why I have json listed as an optional dependency since it's a direct dependency. I should delete that entirely. Sorry for the confusion.

I think that was when json was an optional dep and I was using transit as the serialization format. Now json is directly required for portal to function.

https://github.com/djblue/portal/commit/5e5661476956c149ae1599716c453e37d473deb9#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5L271-L272. Thanks for pointing it out @U04V70XH6!

The yaml stuff is still optional tho' right?

Yeah, I never added that as a dep to portal. Although it would work directly in bb since it's included by default.

I used to have it in my :rebl alias but I've a feeling it's in our dep tree at work due to something else...

Transitive deps are always fun 💯

...hmm, nope, apparently. clojure -Stree -A:dev:everything has nearly 1,000 lines though... 👀

😲

Also to be fair my work repo has 451 lines for our deps tree 😆

$ clojure -X:deps list :aliases '[:dev :everything]'|wc
    331     662   16314

What is that computing exactly? All the deps for all the aliases?

It's the unique, sorted list of final, selected dependencies.

But it also includes local deps which is a bit misleading in our case...

Is the output lines, words, chars?

Yes, from wc.

So we have 97 local deps. So that's 234 external deps.

When I do clj -Stree -A:dev:test:nrepl:cljs-deps | sort | uniq | wc , I get 382 1221 16027

So we might be "winning" 😏

Production deps:

$ clojure -Stree -A:dev:everything|sort|uniq|wc
    539    1675   29848

$ clojure -Stree -A:dev:everything:test:runner:build:poly|sort|uniq|wc
WARNING: Use of :main-opts with -A is deprecated. Use -M instead.
    783    2477   44747

(but that's a 120K line code base)

With Polylith, there's typically no "core" deps. Everything comes it with :dev for the "default" project. :everything is the core deps for our legacy code (that hasn't migrated to Polylith yet).

> NOTE: portal will keep objects from being garbage collected until they are cleared from the UI.

You are correct to be paranoid 😂

Have you considered adding a default configurable upper limit?

It's partly why I have a hot key bound to clearing the Portal UI 🙂

There's probably some human upper limit which can be reasonably set

The problem is that reasonable is a relative value (wide vs deep references for example). My expectation is that most people are using portal during development where hanging onto values a little longer isn't an issue, especially because clearing values is pretty easy.

I guess my question would be, what are some issues you have experienced with portal?

True. It's just a consideration I have because I want to contribute to cider tap support for the inspector

My REPLs run for weeks and weeks and I don't clear Portal's UI very often TBH. I don't think it's something to really worry about. My default eval hot keys all tap> values into Portal and that's how I work day-in, day-out...

Interesting. Currently with portal, as soon as you add-tap the p/submit function, portal begins collecting values. Portal could easily drop values if no UI is currently connected :thinking_face:

A configurable upper limit could still be useful, perhaps turned off by default

I think there are some native plugins but they aren't the default so not as easy of a target as the other portal extensions.

https://clojurians.slack.com/archives/C06MAR553/p1636346297288600?thread_ts=1636341839.285000&cid=C06MAR553