Fork me on GitHub
#shadow-cljs
<
2018-05-02
>
pez04:05:28

@thheller Right now the clojurescript porting comes at a heavy cost: most of the debugger help is lost, even for non-ported code. Very often the variables view is empty, and the debugger complaints about missing scopes. Is it something I have configured incorrectly, you think?

odie04:05:49

Hi all, I’m having trouble calling cljs’s “format” function.

(format "%d bottles of beers on the wall" 99)
=> TypeError: Cannot read property 'call' of undefined
    at eval (eval at <anonymous> (), <anonymous>:1:23)
I have no idea how to go about figure out what I’m doing wrong here. I’m using shadow-cljs version 2.3.16.

odie05:05:09

nevermind x_x It appears format never made it into any actual release of clojurescript.

tianshu05:05:28

does shadow-cljs support aot cache share?

thheller08:05:13

@mjmeintjes no idea. are you deleting the .shadow-cljs for any reason? or using :cache-root "target/shadow-cljs" and deleting the target dir (lein does this)? or any other classloader/classpath trickery?

thheller08:05:56

@doglooksgood no. cache is always per build. shared would be invalidated far too often to be useful.

thheller08:05:43

@odie yeah format doesn't exist. there is goog.string.format but it requires a weird require setup (:require [goog.string.format] [goog.string :refer (format)])

thheller08:05:13

@pez hmm does vscode not support source maps?

pez08:05:40

It does.

pez08:05:19

I can step the code and such, but there's an exception thrown complaining about scopes something.

thheller08:05:53

but it loads the map?

pez08:05:32

In that the code looks sane and I can step it, yes. At least the code that was .js. Stepping the cljs code does not work very well.

thheller08:05:41

so you are not stepping through the compiled JS but the actual source JS?

pez08:05:07

Exactly. I have to put the breakpoint in the compiled JS, but code picks up the source JS when the breakpoint fires.

thheller08:05:52

I don't follow

thheller08:05:13

how do you set a breakpoint in compiled JS but then see the source?

pez08:05:18

It gets a bit crazy since the compiled JS is quite heavily rewwritten, but I think I can live with that. The problem is this lack of context such as variables, which I think is due to that exception on lacking scopes.

pez08:05:05

It just happens. Code opens up the source when the code pointer enters the compiled code (not sure I am using the right terminology):

thheller08:05:34

sorry I have never used the vscode debugger and do not quite understand what you are doing

thheller08:05:57

does vscode even officially support debugging compiled code?

pez08:05:08

Not sure it does.

thheller08:05:10

ie. stuff written in coffeescript? JSX and so on?

pez08:05:24

It does support Typescript officially.

thheller08:05:35

well .. yeah because thats from MS

thheller08:05:49

others as well?

pez09:05:13

Haven't checked.

pez09:05:50

Here's part of that stack trace I mentioned:

Error processing "scopes": TypeError: Line must be greater than or equal to 1, got -1
    at BasicSourceMapConsumer.SourceMapConsumer_findMapping [as _findMapping] (/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.node-debug2/node_modules/vscode-chrome-debug-core/node_modules/source-map/lib/source-map-consumer.js:584:13)

pez09:05:36

What I do is that I place a breakpoint in the generated code. When that breakpoint hits, Code opens up the source and I can step the code without pretending to be a closure compiler. Sometimes I can see some variables , but most often not (and that exception is thrown).

thheller09:05:25

yeah sorry I won't be much help here. not enough time/brain capacity to look into how vscode works

thheller09:05:37

source maps in general seem to work ok and I never had an issue in the browser

thheller09:05:11

so no idea why vscode complains. might be something incorrect in the source map but I don't know

pez09:05:07

I'll investigate it further and see if I can understand if something can be fixed on our (as in shadow-cljs or Calva) end.

gnl11:05:48

@thheller Quick question before I open an issue with the Closure compiler, since you've worked a lot with externs - are you aware of any way to add Closure annotations to internal code with externs or something? I tried using externs directly, but as expected they get overridden by the annotation-less actual function definition:

variable cljs.core.inc redefined with type function(?): ?, original definition at EXTERNS:externs/clojure.core.js:12 with type function(number): number

thheller11:05:28

you can't add type annotations to existing code via externs.

thheller11:05:43

externs are only for external code.

gnl11:05:25

Yeah I get the idea, I'm just trying to make this work somehow. Will open an issue with Closure, then. Thank you

thheller11:05:03

no idea if its possible to attach type information after the fact

thheller11:05:06

I don't think so

thheller11:05:26

are you trying to type cljs.core?

gnl11:05:13

Among other things. Working on something and went off on a bit of a tangent to see how well this might work.

thheller11:05:45

probably not at all

thheller11:05:14

typing clojure maps and vectors is pretty hard and I think you'd need new stuff the GCC doesn't support for it

thheller11:05:08

ie. how do you type [:div {:foo "bar"} "hello world"] when it also may be [:div "hello world"] and so on

gnl11:05:14

Oh I'm not expecting any sort of deep structural typing from this, it's just some added value to a library that I'm trying to get over the finish line.

gnl11:05:29

There's lots of runtime exceptions that boil down to trying to pass a vector where you should have passed a map or something.

thheller11:05:41

you can add typehints in cljs directly

thheller11:05:07

(def ^{:jsdoc ["@type Foo"]} foo ...)

thheller11:05:32

:jsdoc meta is emitted as is into the code

gnl11:05:33

Yup, using that, but was hoping could do this for cljs code I import.

thheller11:05:49

I wouldn't put too much effort into this. CLJS doesn't typecheck at all anyways the check is sort of a failed experiment in that regard

thheller11:05:10

it is useful in certain situations but you'll never get it to actually fully typecheck a program

thheller11:05:32

not without significant work on CLJS and GCC that is

gnl11:05:27

Yup, you're right, I'm not. This is just a maybe/sorta cherry on top kind of thing.

gnl11:05:35

Will let you know when it's done, if you have any ideas how to improve on it.

thheller11:05:26

I could add something that lets you define extra metadata that gets merged in on compile

thheller11:05:45

ie. {cljs.core/inc {:jsdoc ["whatever"]}

thheller11:05:10

thats not too hard to do doubtful you'd gain anything by doing that

gnl11:05:00

That would, I believe, be pretty great. At the moment, based on my initial work, I'm actually quite optimistic that there is some value to be gained from this.