Clojurians Log v2

yes; I admit it's not optimal; but I figure if I get it working barely, someone more qualified will get annoyed enough to get it working flawlessly 🙂

https://github.com/binaryage/dirac/issues/56

Has anyone attempted to get goog.log to work with devtools custom formatters?

@martinklepsch just looked briefly and it looks like it won’t be easily possible - goog.log logging apis are string-based, they expect a msg parameter which is either a string or 0-arity function returning a string[1], so there is no easy way how to pass a message with additional objects to be printed via console.log using custom formatters [1] https://github.com/google/closure-library/blob/d54d6df5f9094dea2f3b570822103982c300029a/closure/goog/debug/logger.js#L42

I could imagine some hack of creating a format string (of type string) which would have additional “hidden” property gathering all formatted objects and custom handler which would pass those as additional parameters to console.log

something along these lines: https://gist.github.com/darwin/6b229ece516861ebfb97f4daa28b9869

@darwin looked a bit more into it as well. I think it could be achieved by creating a custom formatter the default console formatter is goog.debug.TextFormatter or something like that. You could probably create one that logs objects as is (which is whats required for custom formatters to work if I understand correctly)

I don’t see any implementation in closure-library which would provide an implementation for logging into js/console

goog.debug.TextFormatter does not exist

I’m not sure if I understand your sentence. By “creating a custom formatter” you mean creating a handler for goog.logger, not a custom formatter for Chrome DevTools, right?

anyways, if you look at logger apis defined in goog.debug.logger, you can see that the functions you would want to use for logging have string signatures: e.g. goog.debug.Logger.prototype.log expects msg as a string, so I don’t understand how you could do "You could probably create one that logs objects as is”, you have no good way how to pass multiple non-string parameters there without hacks

anyways, not my problem 🙂 I’m not going to use this personally

Latest ClojureScript commit broke devtools. Not quite sure whether hacking around private should be the answer.

ah, I see, they made cljs.core/fast-path-protocols private

@deas I will hack around that, private is just a flag, not a big deal

Sure, was just wondering whether the hack is what we want. :)

I don’t think we have a better option, the problem with this whole namespace is that the functionality is very fragile and can break anytime: https://github.com/binaryage/cljs-devtools/blob/master/src/lib/devtools/munging.cljs#L2-L18

didn’t find a better way, changing cljs internals to make this easier for cljs-devtools is not a viable option, that could break existing code and there are more important things for dnolen to spend his brain cycles on

@deas https://github.com/binaryage/cljs-devtools/commit/dff7ffefbc2562997386304f2bcb4c7f3a9c1494

@darwin Didn't see a cleaner alternative either. Thanks!

in dirac, when using "pause on exception", is it possible to have "reload the page when the page reloads" ?

so right now, when using dirac (1) I save file in emacs (2) boot recompiles (3) boot normally would ahve browser reload (4) but dirac pauses all this ==> I'd prefer to have dirac reload on these events

well, what about not pausing on exceptions?

or change your code to not throw during reload

dirac is not special in this, this is devtools behaviour, or maybe I’m missing your point?

I think you're understanding it correctly. This is probably devtools, not dirac behavior.

my "dev cycle" is (1) write some code, (2) get exception in dirac, (3) write some more code in emacs, (4) hit command-R in dirac because it's not auto reloading

I see, this can be annoying, but how should dirac/devtools possibly know that the exception you got is this kind of exception caused by your hot-reloading and not due to normal operation?

if you have enabled pausing on (unhandled) exceptions and something caused an (unhandled) exception, the code stops in debugger. period.

I see: (1) my desired behavior of "give me stack trace on exception" requires that dirac/devtools pauses execution of ALL code (2) my desire behavior of "save in emacs -> boot recompile -> reload" requires that the js is continuing to run (to reload) so I can't have both at the same time unless boot, outside of websockets, talks to dirac/devtools on some other port to specify "dude, we're going to do a reload, allow code execution again"

in theory I can imagine implementation of hot-reloader in dirac itself, that would enable hot-reloading even while paused on a breakpoint

but as long as "reload code" is being patched through websockets/http, dirac/devtools can't separate these two

thanks for walking me through this logic

you know what's the easiest/hackiest solution?

in emacs, add a on-save-hook which tells chrome canary to refresh 🙂

actually no, it'd have to be in boot as it needs to trigger after the recompilation

when stopped in the debugger, there is no chance hot-reloader could do any work - boot’s hot reloader is living in the app’s js context

right, but chrome canary and boot are running on the same computer

so boot can make some type of system call to tell another app to run f-5

"boot sending chorme canary rrefresh signal" <-- not via websocket, via applescript or something

yes, that could work

I was thinking about solutions through dirac, this image might help: https://github.com/binaryage/dirac/blob/master/docs/about-repls.md#dirac--figwheel your boot’s hot-reloader is the same box as “figwheel support”, you would have to move it into “javascript execution context of Dirac DevTools fork"

but that would be pretty difficult exercise

but proper solution IMO

for example if I did this with that figwheel support box, I would get Figwheel’s code patching and compilation feedback HUD even when stopped on a breakpoint

does dirac try to print metadata of objects?

I'm getting weird "maximum call stack size exceeded" on very small datastrcutures, but these data structures have an alter-meta! to point the meta data back at itself

dirac does not care, this is cljs-devtools’s job to present clojurescript datastructures in the console, do you have an example of the stack trace?

https://github.com/binaryage/cljs-devtools

I have objects that look like this: ` (def x {}) (alter-meta! x (fn [old] (assoc old :foo x)))

let me try to get a minimal failure care

oh sorry, the fault isn't even dirac's; the particular error is: "CLJS DevTools Error: Maximum call stack size exceeded"

and you should see some call stack, no?

yes let me copy/paste it (on separate machines)

this looks like a bug to me, but likely a bug in some printing code, not in cljs-devtools itself

cljs-devtools asks clojurescript to print the data structure, and clojurescript prints what it can or defer to IPrintWithWriter protocol if avail

so if there is a bug in some code there, cljs-devtools will report internal error

RangeError: Maximum call stack size exceeded
    at Object.cljs$core$array_index_of_keyword_QMARK_ [as array_index_of_keyword_QMARK_] (core.cljs:6044)
    at Object.cljs$core$array_index_of [as array_index_of] (core.cljs:6082)
    at Object.cljs$core$array_map_index_of [as array_map_index_of] (core.cljs:6095)
    at cljs.core.PersistentArrayMap.cljs$core$ILookup$_lookup$arity$3 (core.cljs:6275)
    at cljs.core.PersistentArrayMap.cljs$core$ILookup$_lookup$arity$2 (core.cljs:6272)
    at Function.cljs.core.get.cljs$core$IFn$_invoke$arity$2 (core.cljs:1832)
    at cljs.core.Keyword.cljs$core$IFn$_invoke$arity$1 (core.cljs:3162)
    at Object.cljs$core$pr_writer [as pr_writer] (core.cljs:9354)
    at cljs$core$pr_seq_writer (core.cljs:9359)
    at printing.cljs:141 

but not necessarily a bug in cljs-devtools itself

(still working on minimal eaxmple) did dirac just go from 1.1.4 to 1.1.5? I restarted chromecanary and repl complained to me to use 1.1.5 instead of 1.1.4

yes, chrome extension auto-updates

https://github.com/binaryage/dirac/blob/master/docs/faq.md#how-do-i-stick-to-a-particular-dirac-version

simply bump your dirac dependency to 1.1.5 and restart your repl and recompile project

yeah ,just didthat

okay, in the dirac repl, I now have created an object "foo" where:

> foo
CLJS DevTools Error: Maximum call stack size exceeded
> (str foo)
"[:tex-space 30 20 5]"

@darwin : I have a minimal failure case now:

(in the dirac repl)
> (def x [:foo 1])
> (alter-meta! x #(assoc % :ref x))
CLJS DevTools Error: maximum call stack size exceeded
> (str x)
"[:foo 1]"

@dawin: is there anything else I can do to help debug this?

I’m going to try it myself now

there used to be a guard against infinite recursion, data printing has max-level and max-length, those should stop recursion

unless you redefined them

I don't think I redefined any of them.

I'd prefer it just not even show meta data

btw. there are some tests for circular data structures in cljs-devtools: https://github.com/binaryage/cljs-devtools-sample/blob/master/src/tests/devtools_sample/tests/lab.cljs#L107 but not via circular metadata, I’m going to investigate it now

I suspect, with 0 evidence, is that cljs-devtools is trying to eagerly generate the DOM elements for the meta data, which is then causing the infinite loop // which I guess can only be fized by making the DOM visualization lazy

good news, I was able to reproduce your behaviour

yay 🙂 your problem now 🙂

not necessarily, until confirmed 🙂

will look at it later, subscribe to https://github.com/binaryage/cljs-devtools/issues/35

@darwin: please tell me this is new record for time from "dirac installs" to "dirac bug report" 🙂

no, this is not a dirac bug, you are being offtopic for the whole time 😉