require refer do not give errors

[Timothy Pratley]

Hi,

Why are these not errors?

(ns x
(:require [typomina :refer [listen!]]))

;; not an error, but typomina does not exist

(listen!)

;; not an error, but listen! does not exist and will result in a runtime error:
;; Cannot call method 'call' of undefined

(listen-up)

WARNING: Use of undeclared Var

;; Warning but not an error

Will bad things happen to me if I use obj/field instead of (.-field obj)? Both seem to work, I take it the latter is preferred.

For the compiled output, do you generally .gitignore those files or source control them (the diffs dominate changesets)?

Are there any good ways to know when a page can be refreshed other than watching a lein cljsbuild auto terminal?

Might it be useful for a cljsbuild failure to compile to remove the target file to avoid not realizing the compilation failed?

Regards,
Timothy

[David Nolen]

On Tue, Dec 31, 2013 at 1:31 AM, Timothy Pratley <timothy...@gmail.com> wrote:

Hi,


Why are these not errors?

(ns x
  (:require [typomina :refer [listen!]]))

;; not an error, but typomina does not exist

(listen!)

;; not an error, but listen! does not exist and will result in a runtime error:
;; Cannot call method 'call' of undefined

A ticket exists for this. Patch welcome :)

 

(listen-up)

WARNING: Use of undeclared Var

;; Warning but not an error

Not sure what difference it makes, warnings are errors but without blowing up the compilation process so you can get many warnings at once.

 

Will bad things happen to me if I use obj/field instead of (.-field obj)? Both seem to work, I take it the latter is preferred.

Bad form. / is only for namespaces. 

For the compiled output, do you generally .gitignore those files or source control them (the diffs dominate changesets)?

I would ignore.

 

Are there any good ways to know when a page can be refreshed other than watching a lein cljsbuild auto terminal?

Might it be useful for a cljsbuild failure to compile to remove the target file to avoid not realizing the compilation failed?

Tooling questions outside of CLJS itself.

David

[Jonas Enlund]

On Tuesday, December 31, 2013 8:31:40 AM UTC+2, Timothy Pratley wrote:
> Hi,
>
>
> Why are these not errors?
>
> (ns x
> (:require [typomina :refer [listen!]]))
>

I believe that the reason the above does not trigger an error is because 'typomina' might be in a Javascript file somewhere. In GClosure there is not an 1-to-1 correspondence between namespaces and files. There is no sane way to find a file given a namespace symbol and a file might even define several namespaces.

[Timothy Pratley]

Hi David

 

A ticket exists for this. Patch welcome :)

Is this the ticket?

http://dev.clojure.org/jira/browse/CLJS-615

It speaks of analyzer.clj, but I don't see such a file.

I do see analyze as a function in compiler.clj which sounds promising.

closure.clj:

(defn cljs-dependencies

;...

                   (map #(let [f (ns->cp %)] (hash-map :relative-path f :uri (io/resource f))))

                   (remove #(nil? (:uri %)))

Looks to be ignoring missing files. I suspect though that it merges with js dependencies later, and that the trick will be recognizing requires that are in neither...  I'll dig into it tomorrow and see what I can discover.

Not sure what difference it makes, warnings are errors but without blowing up the compilation process so you can get many warnings at once.

Some compilers report multiple errors, it may be reasonable to classify the output however you like.  My opinion is that an error is appropriate when you know 'it' just wont work, and refuse to produce an output... whereas a warning is appropriate as a hint that probably 'it' will do something you might not expect.  In the specific case of an undeclared var will it always be a runtime error?  I can see an argument to say some js output is better than none even if certain paths will fail.

 

And Jonas,

I believe that the reason the above does not trigger an error is because 'typomina' might be in a Javascript file somewhere. In GClosure there is not an 1-to-1 correspondence between namespaces and files. There is no sane way to find a file given a namespace symbol and a file might even define several namespaces.

Ah that makes sense and makes me think that the code I was looking at can't be patched so easily then.

It seems I need to read up on exactly what 'require' means in GClosure.  I was initially mistaken that JavaScript code would be imported to distinguish from ClojureScript being required, but that is not the case.

Thanks your replies.

Regards,

Timothy

[David Nolen]

On Tue, Dec 31, 2013 at 3:03 AM, Timothy Pratley <timothy...@gmail.com> wrote:

Hi David

 

A ticket exists for this. Patch welcome :)

Is this the ticket?

http://dev.clojure.org/jira/browse/CLJS-615

It speaks of analyzer.clj, but I don't see such a file.

I do see analyze as a function in compiler.clj which sounds promising.

analyzer.clj exists.

 

closure.clj:

(defn cljs-dependencies

;...

                   (map #(let [f (ns->cp %)] (hash-map :relative-path f :uri (io/resource f))))

                   (remove #(nil? (:uri %)))

Looks to be ignoring missing files. I suspect though that it merges with js dependencies later, and that the trick will be recognizing requires that are in neither...  I'll dig into it tomorrow and see what I can discover.

This is not the place to put this assertion check. The best location is ns form parsing in analyzer.clj. 

Not sure what difference it makes, warnings are errors but without blowing up the compilation process so you can get many warnings at once.

Some compilers report multiple errors, it may be reasonable to classify the output however you like.  My opinion is that an error is appropriate when you know 'it' just wont work, and refuse to produce an output... whereas a warning is appropriate as a hint that probably 'it' will do something you might not expect.  In the specific case of an undeclared var will it always be a runtime error?  I can see an argument to say some js output is better than none even if certain paths will fail.

This is already supported to some degree. Again look at analyzer.clj. Some errors will halt compilation - source reading errors, errors in the ns form, and those that would result in a mangled file. We haven't been super disciplined how we classify these. Yet another place for someone to contribute.

 

I believe that the reason the above does not trigger an error is because 'typomina' might be in a Javascript file somewhere. In GClosure there is not an 1-to-1 correspondence between namespaces and files. There is no sane way to find a file given a namespace symbol and a file might even define several namespaces.

Ah that makes sense and makes me think that the code I was looking at can't be patched so easily then.

It seems I need to read up on exactly what 'require' means in GClosure.  I was initially mistaken that JavaScript code would be imported to distinguish from ClojureScript being required, but that is not the case.

Verifying that random JS libs exist on disk will require more work, but there's a lot of value in starting with .cljs and .clj macro files first.

David 

[Timothy Pratley]

Patch is up for this:

http://dev.clojure.org/jira/browse/CLJS-615

Additional details in the ticket description.

Regards,

Timothy

[David Nolen]

Thanks!

--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to the Google Groups "ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.