Fork me on GitHub
#dirac
<
2017-02-19
>
qqq00:02:22

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 🙂

martinklepsch05:02:41

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

darwin13:02:59

@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

darwin13:02:23

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

martinklepsch14:02:06

@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)

darwin14:02:37

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

darwin14:02:51

goog.debug.TextFormatter does not exist

darwin14:02:56

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?

darwin14:02:41

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

darwin14:02:03

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

deas16:02:55

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

darwin16:02:02

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

darwin16:02:40

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

deas16:02:06

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

darwin17:02:37

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

darwin17:02:01

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

deas18:02:03

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

qqq20:02:34

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

qqq20:02:12

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

darwin20:02:01

well, what about not pausing on exceptions?

darwin20:02:15

or change your code to not throw during reload

darwin20:02:51

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

qqq20:02:11

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

qqq20:02:43

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

darwin20:02:24

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?

darwin20:02:12

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

qqq20:02:13

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"

darwin20:02:27

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

qqq20:02:32

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

qqq20:02:51

thanks for walking me through this logic

qqq20:02:08

you know what's the easiest/hackiest solution?

qqq20:02:22

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

qqq20:02:42

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

darwin20:02:32

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

qqq20:02:51

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

qqq20:02:02

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

qqq20:02:20

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

darwin20:02:42

yes, that could work

darwin20:02:23

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"

darwin20:02:40

but that would be pretty difficult exercise

darwin20:02:50

but proper solution IMO

darwin20:02:38

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

qqq22:02:31

does dirac try to print metadata of objects?

qqq22:02:50

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

darwin22:02:36

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?

qqq22:02:59

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

qqq22:02:04

let me try to get a minimal failure care

qqq22:02:50

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

darwin22:02:11

and you should see some call stack, no?

qqq22:02:34

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

darwin22:02:02

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

darwin22:02:48

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

darwin22:02:15

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

qqq22:02:25

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 
^^ this is a diferent object, let me try to get a minimal object that riggers this

darwin22:02:27

but not necessarily a bug in cljs-devtools itself

qqq22:02:49

(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

darwin22:02:10

yes, chrome extension auto-updates

darwin22:02:15

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

qqq22:02:24

yeah ,just didthat

qqq22:02:25

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]"
if I can extract this object foo out, this would be a minimal failure case? (or a "small enough" failure case) ?

qqq22:02:32

@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]"

qqq22:02:30

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

darwin22:02:40

I’m going to try it myself now

darwin22:02:33

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

darwin22:02:38

unless you redefined them

qqq22:02:38

I don't think I redefined any of them.

qqq22:02:45

I'd prefer it just not even show meta data

darwin22:02:31

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

qqq22:02:41

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

darwin22:02:43

good news, I was able to reproduce your behaviour

qqq22:02:51

yay 🙂 your problem now 🙂

darwin22:02:02

not necessarily, until confirmed 🙂

qqq22:02:44

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

darwin23:02:25

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