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

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)

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

does shadow-cljs support aot cache share?

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

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

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

@pez hmm does vscode not support source maps?

It does.

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

but it loads the map?

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.

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

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

I don't follow

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

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.

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

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

does vscode even officially support debugging compiled code?

Not sure it does.

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

It does support Typescript officially.

well .. yeah because thats from MS

others as well?

Haven't checked.

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)

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

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

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

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

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.

@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

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

externs are only for external code.

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

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

I don't think so

are you trying to type cljs.core?

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

probably not at all

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

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

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.

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

you can add typehints in cljs directly

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

:jsdoc meta is emitted as is into the code

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

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

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

not without significant work on CLJS and GCC that is

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

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

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

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

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

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.