Fork me on GitHub

does anyone know what could be happening here, in a directory with nothing but this deps.edn pointing at clojurescript at latest master

{:deps {org.clojure/clojurescript {:local/root "/path/to/clojurescript"}}}
I get
➜ clj -m cljs.main --repl-env node
WARNING: When invoking clojure.main, use -M
ClojureScript 0.0.2008668038
It seems to be picking up some ancient version of ClojureScript? clj -Stree looks fine.


I see this as well in the REPL, but in the actual dependencies it's the correct version.


ah seems to be better after a script/build

Alex Miller (Clojure team)14:03:18

you're probably just picking up a resource file that stores the ClojureScript version that is old would be my guess


I'm seeing this when using master as a git dep as well. Where would that resource file be?

Alex Miller (Clojure team)14:03:38

local/git deps are basically used the same way. don't know, just guessing

👌 3
Alex Miller (Clojure team)14:03:52

just in general, projects with build steps do not play well (yet!) as local/git deps, and cljs is certainly such a project

👌 3

Looking at the goog.log changes for Glögi (, seems several instance methods have become static methods/functions

(.setLevel logger level)  ->  (glog/setLevel logger level)
(.addHandler logger handler) -> (glog/addHandler logger level)
(.logRecord logger record)  ->  (glog/publishLogRecord logger record)


Yes, and also calling the log functions themselves has changed


@U45J3R52L didn’t you open a PR?


thanks, but I was nearly there. I'd like to retain backwards compatibility at least for a while.


(require '[goog.log :as glog])

👍 3

now the name of your library makes even more sense


If I want to support both I guess I can do a (exists? glog/publishLogRecord) etc. Unless someone has a better idea 🙂


dynamic check seems best


while I'm here let me also warmly encourage people to use Glögi (or goog.log) in their projects/libraries. It is really nice to get consistent logging and be able to control log levels all in one place

 '{:glogi/root :debug
   lambdaisland :all
   co.gaiwan.some.ns :warn
   some.library :info})

👍 3

So if you do a log/info in lambdaisland it will override to :all?


It's not clear in the README how that behavior is supposed to work. The example does a log in the root namespace. It would be helpful to have an example in one of the defined namespaces.


it follows the rules of goog.log or pretty much any logging library out there, if there's a log level defined for a given logger it uses that, otherwise it goes up the hierarchy.


{foo :info :warn :debug
 :glogi/root :error}
- -> debug - -> also debug (traverses to the parent logger, which has an explicit level) - -> :warn - some.other.logger -> :error (no level for some.other, no level for some, so it uses the root level)


So it would be good for someone that hasn't used that to be in the README. 🙂


doc PRs are always welcome!


Since the documentation for goog.log isn't very clear as you mentioned


Documentation provided by someone whom has never used the library doesn't make any sense to me.


So then according to that article the answer to my original question is no. It just sets the filter level. You still have to call the appropriate goog.log function. So I'm failing to see why this is any better than just calling the log function you want for the given thing you are logging.


I don't follow. You put logging in your code at the appropriate level for what you're logging, log/trace for highly detailed debug stuff, log/error for exceptional situations. Then you can use the hierarchies for fine grained control of how much detail you want to see for a given tree of namespaces/loggers at a given time.


Is there any coordination with the JVM team when adding things to cljs.core, e.g. about the function iter, etc? For context: