Fork me on GitHub
#dirac
<
2016-02-18
>
denisj03:02:18

@darwin: apologies for my tardy response: regarding devtools sources. I'm just confirming on latest Chrome unstable v50.0.2652.0 dev (64-bit) on Ubutnu 14.04 Dirac devtools does NOT show cljs, only js and normal devtools does. I have not tried release Chrome but will report when I get a chance.

bbss16:02:59

wow, dirac is really cool!

bbss16:02:21

I think I am running in to one or two bugs but I really love the tool simple_smile

darwin16:02:56

yeah, dirac has still some rough edges

darwin16:02:04

pretty young project

bbss16:02:27

as for the issue on go channel debugging, that would be really awesome. I had been thinking how cool it would be to have go consumers and producers as nodes and channels as edges in a graph

darwin16:02:31

I’m a bit worried to keep it up to date with devtools evolution, the official devtools moves quite fast

bbss16:02:28

yeah I bet that is hard to keep merged

bbss16:02:42

especially since you are adding to existing tabs

bbss16:02:28

I wondered if you need to fork the core-async though, couldn't a bootstrapped compiler work as well for this kind of tools?

darwin16:02:06

that debugging support for core.async would definitely need support from core async

darwin16:02:44

IMO bootstrapped is not applicable here

darwin16:02:27

core.async would need to keep track of all channels and go blocks, so I could expose it in the UI

bbss16:02:33

hmm yeah maybe since you can't touch the compiler

bbss16:02:47

I was thinking of making some stuff for devcards that do that graph thing

bbss16:02:58

but got a bit overwhelmed digging in to the compiler

darwin16:02:20

that graph thing is not doable, in general case IMO

darwin16:02:37

how do you know what code does in general cases?

darwin16:02:43

I can take from one channel and put into another

darwin16:02:53

use variety of functions for that

darwin16:02:59

dynamically

bbss16:02:59

well I thought you'd build an index of all occurences of puts takes and channels and then put them in a proxy channel to tunnel them so you can inpect the values

bbss16:02:25

mostly just a thought experiment so not sure how hard it would be

darwin16:02:52

I can imagine some library on top of core.async, which would track that information and then expose it in some form for debugging

bbss16:02:15

hmm yeah that would be easier I guess

darwin16:02:35

but it is hard to imagine some analyser for general clojure(script) code using core.async without changes

darwin16:02:25

in that library you would need primitives for connecting channels, basically building that graph via some kind of api

darwin16:02:14

in my issue, I had in mind more low level view of core.async. it would just list pending go blocks and state of all existing channels

bbss16:02:32

yeah, that would be great too

darwin16:02:36

no info about flow of values between channels and their relation

bbss17:02:22

any idea what could be wrong with "Use of undeclared Var projectname.core/variable at line 1 <dirac repl>" ?

bbss17:02:32

It does evaluate properly

bbss17:02:41

but just gives that warning

darwin17:02:13

I barely remember someone else had this question before

darwin17:02:26

it was expected REPL behaviour

darwin17:02:36

he didn’t do require or something like that

darwin17:02:11

can you test the same thing in normal repl?

bbss17:02:09

Hmm if I manually require the NS the warnings go away

darwin17:02:47

(require ‘productivity.core) ?

darwin17:02:33

this is standard REPL behaviour, it does not know about your vars until you require the namespace (aka eval it in the context of REPL)

darwin17:02:25

if you don’t have evaluated the code, it warns you, but it compiles down to correct matching js just by coincidence

bbss17:02:51

ah yes, makes sense

bbss17:02:59

if I do it in a figwheel repl I don't need to, but that might already have required it or so

darwin17:02:48

hm, maybe figwheel is smarter about it and evals your code in REPL context

darwin17:02:54

I should look into that

bbss17:02:33

the only other thing I've run in to so far is no having the same focus behaviour as regular dev tools. Sometimes input loses focus and I need to manually click the input line (which is really small for some reason in canary, might be my high dpi setting.)

darwin17:02:57

in next version I would like to describe how to bind a global system keyboard shortcut to focus dirac prompt

darwin17:02:14

so one can have system-wide quick access to it

bbss17:02:33

system wide? cool.

darwin17:02:53

yes, chrome allows that, but it is a bit secret setting

bbss17:02:49

I try to not use the mouse at all, and the devtools are pretty bad for that. It took me a long time to find out that if you detach the dock you can tab between the page and devtools.

bbss17:02:04

I use vimium besides that so hardly need to interact by mouse anymore simple_smile

bbss17:02:18

speaking of, what is the hotkey for dirac devtools?

bbss17:02:31

you mentioned in the read me but not which one it was 😄

darwin17:02:54

command keys can be also global, just need to look it up how to do that

darwin17:02:05

I will add a new one for dirac prompt focus

darwin17:02:21

so you one could bind it to some global shortcut

bbss17:02:26

thanks a bunch

bbss17:02:35

calling it a night, cheers