Clojurians Log v2

Just published a new version, fixing the "goto var definition" (hopefully! on my tests it works). Also, now this feature have tests too, so regressions are unlikely.

@mauricio.szabo after git pulling the master branch for atom-chlorine and doing a git submoule update, i built a new version, and it appears "Chlorine: Go To Var Defintion" works -- at least for jvm clojure 🙂

Great! Other targets are still not supported. I could probably make it work on Shadow-CLJS (but I would probably need help from the Clojure part) but I have no idea on how to make it work on Lumo

ok. neither do i 🙂

@mauricio.szabo btw, i have been encountering an issue like this: https://github.com/thheller/shadow-cljs/issues/304 -- when trying to work with two different plugins for atom that both use shadow-cljs. is there a way to build chlorine as a release? that seems to be a suggestion in the issue.

That's strange, I am releasing Chlorine as a release build

@sogaiu are you having this issue while trying to develop Chlorine, or while trying to use it (downloading from the Atom package manager) to develop the other?

You can build Chlorine as a release by using npx shadow-cljs release dev, or you can use one of the tags to get exactly the same version that's published on Atom's package registry. And also, if you want, there are tags suffixed with -source that's exactly the original source code made for that specific version 🙂

@mauricio.szabo thanks for the tip on how to build for release -- iiuc, i haven't built for release before. i typically use chlorine with yarn shadow-cljs watch dev or the result of having done that before. i will try with your release instructions to see if i get the same problem.

that seems sufficient -- i'm now able to use another atom plugin that is built with shadow-cljs (not with release, but watch) at the same time. do you think it's worth consulting with @thheller on this matter?

@sogaiu I don't think he can do much - it seems a limitation on the way ClojureScript, google closure compiler, and so on - it's not really a limitation of shadow-cljs. I had the exactly same problem with proto-repl and figwheel, in which I made a PR to make a "different release version" so it wouldn't conflict with other plug-ins: https://github.com/jasongilman/proto-repl/pull/232

(one of the most interesting PRs I ever made, 126k lines deleted :rolling_on_the_floor_laughing:)

@mauricio.szabo thanks for that. lol, deleting a lot sounds great! i got the sense that thheller was saying that there might be something that could be done, but for the case reported it might not be worth it: > Nothing we can do here really. :npm-module completely isolates everything but has considerably more overhead, not sure it is worth doing this for :node-library. without seeing the actual performance impact for atom plugins, i'm not sure it isn't worth doing...may be i will bug him about it.

Well, for once, Google Closure adds a global variable goog. Developing two packages in paralel will make goog variables interfere, and unless you use exactly the same version of shadow-cljs, ClojureScript and dependencies, you'll probably have trouble (even then, I'm not even sure that it would work...)

this is an issue that plagues more "interesting" setups: only a single CLJS application can be loaded in a given JS environment

hopefully it works better with node-library than with browser... ran into issues when running the release version of one app on the same page as a dev version of another

though that might be because I was using modules for both, which isn't present in node-library

@lilactown it does appear that all except one plugin being compiled for release resolves the issue here, so when using :node-library, there appears to be a "work-around". @mauricio.szabo may be if there is a sufficiently compelling use-case, thheller will come up with something 🙂