Fork me on GitHub
#shadow-cljs
<
2018-03-26
>
hlolli13:03:22

do you remember if the google closure bug we found last month was fixed already, the one you opened the ticket for? @thheller

hlolli13:03:15

https://github.com/google/closure-compiler/issues/2822 ok found it, I’ll give the new clojurescript release a try without targeting older closure compiler…

hlolli13:03:29

nevermind what I said, the release from 6 days ago v20180319 with the fix for #2822 isn’t on maven https://mvnrepository.com/artifact/com.google.javascript/closure-compiler-unshaded yet

thheller14:03:29

yeah apparently its stuck internally or something

mhuebert15:03:27

great. re: how the server persists, would it quit when I hit ctrl-c in that terminal window?

mhuebert15:03:03

👍:skin-tone-2:

thheller15:03:21

added that to the docs as well

justinlee16:03:39

is there a way to make a namespace always available, e.g. a debugging library?

thosmos17:03:49

I'm attempting to include the "sql.js" NPM module. It works in dev mode, but not in release, unless I set the :optimizations :simple compiler flag. In release mode, some of its functions work, except for one. I'm wondering what's going on and how best to troubleshoot. I can live with :simple optimizations, but I'm curious what's causing the problem.

justinlee18:03:52

@thosmos what error message do you get?

thosmos18:03:00

@lee.justin.m Uncaught TypeError: b.wb is not a function

justinlee18:03:42

automatic type inferences arn’t working. is your :infer-extern :auto set? https://shadow-cljs.github.io/docs/UsersGuide.html#infer-externs

justinlee18:03:03

make sure those are on and then add type hints until the warnings go away

thosmos18:03:11

the actual call is (.prepare db "SELECT * FROM myTable WHERE MainID=? AND SubID=? AND ProtocolID=?;")

thosmos18:03:09

yes when I did that, the call works, but there's no result, whereas with :simple it actually works, which makes me think the library is getting optimized?

thosmos18:03:49

other functions like (.exec db) works, but not (.prepare db)

justinlee18:03:44

the actual javascript goes through normal minification only. the b.wb is not a function is because something you are calling in clojurescript is getting munged. try this : (.prepare ^js db "SELECT * FROM myTable WHERE MainID=? AND SubID=? AND ProtocolID=?;")

justinlee18:03:23

that will prevent the prepare symbol from being munged

justinlee18:03:29

if that doesn’t work, then something in the minification process is actually messing with the javascript source, though that really shouldn’t happen

justinlee18:03:22

actually, I don’t think changing compiler optimizations changes anything with regard to javascript, so that can’t be it.

justinlee18:03:34

it’s got to be a missing type hint

thosmos18:03:00

yeah when I add that I no longer get the error, but the call doesn't work.

thosmos18:03:26

I'll keep looking for other type hints

justinlee18:03:16

make sure you are positive that there is a different outcome on the prepare statement--maybe the prepare is working but something else is failing? if not, then there is a bug that @thheller will have to take a look at

thosmos18:03:03

(def sql (js/require "sql.js")) is also how I'm loading the library.

justinlee18:03:10

I assume you’re targeting node. I don’t know that there is any reason to do optimizations on node. Optimizations are about space efficiency, not time efficiency, as far as I know.

justinlee18:03:19

But it would still be good to understand the bug.

thosmos18:03:33

I'll rig up a minimal test

thosmos18:03:36

@lee.justin.m using the following minimal test, the row result is empty with optimizations and filled with :simple:

(def sql (js/require "sql.js"))
(def fs (js/require "fs"))
(defn testDB []
  (let [dbPath  "/my/db/path"
        fb     (.readFileSync ^js fs dbPath)
        db     (new (.-Database ^js sql) fb)
        stmt   (.prepare ^js db "SELECT * FROM tblTreatment WHERE MainID=? AND SubID=? AND ProtocolID=?;")
        _ (.bind ^js stmt (clj->js [1 1 1]))
        _ (.step ^js stmt)
        row (js->clj (.getAsObject ^js stmt))
        _ (println "ROW: " row)
        ]))

justinlee18:03:00

@thosmos awesome! thanks! hey could you do me a favor and open up a ticket in github? that way thomas will see it.

thosmos18:03:35

I'll make a minimal github project and then do that

thosmos18:03:16

oh, hmm, maybe this is relevant: I've been doing this in the renderer process. I just tested it in the main process and it works in release mode when it doesn't in the browser. in the main process, the target is :node-script, whereas in the renderer it's :browser

justinlee18:03:04

okay wait i’m confused about the “rendered process” and the “main process”

justinlee18:03:08

what is that?

thosmos18:03:54

this is for an electron app which has two processes, one is the node app and the other is the browser app. they both have access to npm modules

thosmos18:03:12

sql.js works in both because it is pure javascript

justinlee18:03:52

ruh roh you’ve run completely off the edge of my expertise 🙂

justinlee18:03:08

that definitely sounds like the problem but I can’t even guess what

thosmos18:03:15

but what this suggests is that in release mode, the :browser target seems to be doing something different than the :node-script target

justinlee18:03:25

yea it does. i’d add that information into the ticket

thosmos18:03:49

thanks for thinking it through with me

thosmos19:03:18

it's probably that npm modules are fully handled only in the :node-x targets

justinlee19:03:20

seems weird. handling npm modules on the browser is shadow’s raison d’etre. node is a later addition (as I understand it)

thheller19:03:17

@thosmos do not use (js/require ...) for anything or half the inference won't work

thheller19:03:10

just use (ns the.thing (:require ["fs" :as fs])) and treat it like any other namespace. eg. (fs/readFileSync ...) instead of (.readFileSync fs ...)

thheller19:03:34

as for the modules thing. for :browser things are handled entirely differently that is correct. you can however set :js-options {:js-provider :require} in your build. then they are handled exactly like :node-script