[ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released
On Monday, April 13, 2015 at 4:48:28 PM UTC+3, Alex Miller wrote: I think what you're seeing here makes sense. On Sunday, April 12, 2015 at 3:39:15 PM UTC-5, whodidthis wrote: Are there any thoughts on code like this: #_ This says to ignore the next read form #?(:cljs (def unrelated-1 nil)) This evaluates to *nothing*, ie nothing is read, so it is not ignored by the #_. #?(:cljs (def unrelated-2 nil)) #?(:cljs (def unrelated-3 nil)) These also read as *nothing*. #?(:clj (def n 10)) This *is* read, but ignored per the prior #_ #?(:clj (defn num [] n)) ; compile on clj =RuntimeException: Unable to resolve symbol: n And then this makes sense. I guess it's fine if it continues to work that way but I can imagine it being a little surprising from time to time heh Conditional reading is definitely something to be careful about - I think in this case you are combining two types of conditional reading so be doubly careful. :) To get the effect you want in this, using #_ *inside* the reader conditional would work: #?(:cljs #_(def unrelated-1 nil)) Sorry, back to this stuff again. I tried using discard inside but #?(:clj #_'whatever) just throws CompilerException java.lang.RuntimeException: read-cond starting on line 32 requires an even number of forms when compiling on clojure. Would be nice to have a way to ignore reader conditional forms or the thingie things inside but there does not seem to be an easy way. -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released
Your particular example is equivalent to #?(:clj) which is illegal, for the reason given in the error message you saw. Normal Clojure comments are far less surprising in their behavior than #_ is I understand there can be convenience in using #_ when it works. Andy Sent from my iPhone On Apr 13, 2015, at 12:38 PM, whodidthis ton...@gmail.com wrote: On Monday, April 13, 2015 at 4:48:28 PM UTC+3, Alex Miller wrote: I think what you're seeing here makes sense. On Sunday, April 12, 2015 at 3:39:15 PM UTC-5, whodidthis wrote: Are there any thoughts on code like this: #_ This says to ignore the next read form #?(:cljs (def unrelated-1 nil)) This evaluates to *nothing*, ie nothing is read, so it is not ignored by the #_. #?(:cljs (def unrelated-2 nil)) #?(:cljs (def unrelated-3 nil)) These also read as *nothing*. #?(:clj (def n 10)) This *is* read, but ignored per the prior #_ #?(:clj (defn num [] n)) ; compile on clj =RuntimeException: Unable to resolve symbol: n And then this makes sense. I guess it's fine if it continues to work that way but I can imagine it being a little surprising from time to time heh Conditional reading is definitely something to be careful about - I think in this case you are combining two types of conditional reading so be doubly careful. :) To get the effect you want in this, using #_ *inside* the reader conditional would work: #?(:cljs #_(def unrelated-1 nil)) Sorry, back to this stuff again. I tried using discard inside but #?(:clj #_'whatever) just throws CompilerException java.lang.RuntimeException: read-cond starting on line 32 requires an even number of forms when compiling on clojure. Would be nice to have a way to ignore reader conditional forms or the thingie things inside but there does not seem to be an easy way. -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released
Why not just change the `?' to `_'? ? So: #?(:cljs (def unrelated-1 nil)) then #_(:cljs (def unrelated-1 nil)) Even saved a character :) On Monday, April 13, 2015 at 3:38:01 PM UTC-4, whodidthis wrote: On Monday, April 13, 2015 at 4:48:28 PM UTC+3, Alex Miller wrote: I think what you're seeing here makes sense. On Sunday, April 12, 2015 at 3:39:15 PM UTC-5, whodidthis wrote: Are there any thoughts on code like this: #_ This says to ignore the next read form #?(:cljs (def unrelated-1 nil)) This evaluates to *nothing*, ie nothing is read, so it is not ignored by the #_. #?(:cljs (def unrelated-2 nil)) #?(:cljs (def unrelated-3 nil)) These also read as *nothing*. #?(:clj (def n 10)) This *is* read, but ignored per the prior #_ #?(:clj (defn num [] n)) ; compile on clj =RuntimeException: Unable to resolve symbol: n And then this makes sense. I guess it's fine if it continues to work that way but I can imagine it being a little surprising from time to time heh Conditional reading is definitely something to be careful about - I think in this case you are combining two types of conditional reading so be doubly careful. :) To get the effect you want in this, using #_ *inside* the reader conditional would work: #?(:cljs #_(def unrelated-1 nil)) Sorry, back to this stuff again. I tried using discard inside but #?(:clj #_'whatever) just throws CompilerException java.lang.RuntimeException: read-cond starting on line 32 requires an even number of forms when compiling on clojure. Would be nice to have a way to ignore reader conditional forms or the thingie things inside but there does not seem to be an easy way. -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Very slow cljs compilation on Windows
Yeah, figwheel is pretty much instant to me on all my machines. If you're only using chestnut for what figwheel can do it's a pretty easy replacement - I think it should work without issues. I'm also not using Cygwin but I doubt that's the main issue. -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released
Just noticed that I sent my previous email to clojure-dev only – reposting
to all groups involved:
On 13 April 2015 at 16:25, Michał Marczyk michal.marc...@gmail.com wrote:
On 13 April 2015 at 15:48, Alex Miller a...@puredanger.com wrote:
To get the effect you want in this, using #_ *inside* the reader
conditional would work:
#?(:cljs #_(def unrelated-1 nil))
Actually this doesn't work because of the cond-like structure of #?
conditionals:
user= (read-string {:read-cond :allow} #?(:clj #_foo) bar)
RuntimeException read-cond requires an even number of forms.
clojure.lang.Util.runtimeException (Util.java:221)
To this I would add that it is possible to say
Clojure 1.7.0-beta1
user= (read-string {:read-cond :allow} #?(#_#_:clj foo) bar)
bar
taking advantage of the nice stacking property of #_ (which follows from
the recursive nature of the reader in the same way that the original
surprising case does).
Cheers,
Michał
On 13 April 2015 at 21:38, whodidthis ton...@gmail.com wrote:
On Monday, April 13, 2015 at 4:48:28 PM UTC+3, Alex Miller wrote:
I think what you're seeing here makes sense.
On Sunday, April 12, 2015 at 3:39:15 PM UTC-5, whodidthis wrote:
Are there any thoughts on code like this:
#_
This says to ignore the next read form
#?(:cljs (def unrelated-1 nil))
This evaluates to *nothing*, ie nothing is read, so it is not ignored by
the #_.
#?(:cljs (def unrelated-2 nil))
#?(:cljs (def unrelated-3 nil))
These also read as *nothing*.
#?(:clj (def n 10))
This *is* read, but ignored per the prior #_
#?(:clj (defn num [] n))
; compile on clj =RuntimeException: Unable to resolve symbol: n
And then this makes sense.
I guess it's fine if it continues to work that way but I can imagine it
being a little surprising from time to time heh
Conditional reading is definitely something to be careful about - I think
in this case you are combining two types of conditional reading so be
doubly careful. :)
To get the effect you want in this, using #_ *inside* the reader
conditional would work:
#?(:cljs #_(def unrelated-1 nil))
Sorry, back to this stuff again. I tried using discard inside but
#?(:clj #_'whatever)
just throws
CompilerException java.lang.RuntimeException: read-cond starting on line
32 requires an even number of forms
when compiling on clojure.
Would be nice to have a way to ignore reader conditional forms or the
thingie things inside but there does not seem to be an easy way.
--
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 clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
--
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 clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Very slow cljs compilation on Windows
On Friday, April 10, 2015 at 12:19:58 PM UTC+1, Conan Cook wrote: I've switched from OSX to Windows and a Ubuntu VM, and am experiencing extremely slow cljs compilation. I've got a few chestnut projects, and have tried the chestnut tutorial as well, all with the same results. I opened an issue over at Chestnut: https://github.com/plexus/chestnut/issues/114 The problem is that if I'm compiling files on a Windows filesystem, it's very slow, whether I'm running leiningen from inside Windows or inside Linux. If the files are on the Linux VM filesystem and I'm running leiningen in Linux, it's nice and snappy. Has anyone else had luck compiling cljs on Windows? aargh! i just installed windows 10 technical preview in a VM and got the same results. I literally installed java, cygwin and leiningen and tried a new chestnut project. cygwin is the only thing that stands out there - did you use cygwin Shaun? also, I just noticed you used lein figwheel instead of (run) from a repl. would you be able to test using (run)? i'd really appreciate it! -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Very slow cljs compilation on Windows
On Friday, April 10, 2015 at 6:08:55 PM UTC+1, Shaun Mahood wrote: Wow, that's crazy. On my main machine I get Successfully compiled resources/public/js/app.js in 5.545 seconds. on recompilation. Same project, making the same change to core.cljs, recompilation using lein figwheel I get Successfully compiled resources/public/js/app.js in 0.14 seconds. Running Windows 10 Preview, processor is i7-4790K @ 4.00GHz, 32.0 GB RAM and an SSD. I can try the same thing on a couple older machines as well if you want. On Friday, April 10, 2015 at 9:38:47 AM UTC-6, Conan Cook wrote: Just do: lein new chestnut speed-test cd speed-test lein repl (run) That's enough to show it up for me; a change in core.cljs should trigger a recompilation. For me on a windows filesystem I get: Successfully compiled resources/public/js/app.js in 23.226 seconds. On a linux filesystem I get: Successfully compiled resources/public/js/app.js in 0.174 seconds. That's a pretty hefty difference, whatever your machine it should be obvious. On Friday, 10 April 2015 15:27:13 UTC+1, Shaun Mahood wrote: Conan, if you have a repo I can try it on a few windows machines to compare. I did find that chestnut was really slow to refresh changes and ended up switching to use figwheel instead, it is essentially instant refresh now when I save a file. On Friday, April 10, 2015 at 5:19:58 AM UTC-6, Conan Cook wrote: I've switched from OSX to Windows and a Ubuntu VM, and am experiencing extremely slow cljs compilation. I've got a few chestnut projects, and have tried the chestnut tutorial as well, all with the same results. I opened an issue over at Chestnut: https://github.com/plexus/chestnut/issues/114 The problem is that if I'm compiling files on a Windows filesystem, it's very slow, whether I'm running leiningen from inside Windows or inside Linux. If the files are on the Linux VM filesystem and I'm running leiningen in Linux, it's nice and snappy. Has anyone else had luck compiling cljs on Windows? I just realised you're running lein figwheel and not chestnut's (run). i get good performance from that. thanks! i'll see whether i can get reloading working that way. -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Very slow cljs compilation on Windows
On Monday, April 13, 2015 at 11:00:31 PM UTC+1, Shaun Mahood wrote: Yeah, figwheel is pretty much instant to me on all my machines. If you're only using chestnut for what figwheel can do it's a pretty easy replacement - I think it should work without issues. I'm also not using Cygwin but I doubt that's the main issue. Thanks. I'll try to persuade my team to switch to figwheel on its own! Incidentally, chestnut uses enlive's reload namespace, which relies on java.nio.file.FileSystems.newWatchService(). I haven't looked into this yet, but the way it's used is possibly the cause of the trouble - enlive doesn't seem to be well tested on Windows. -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: clojurescript configuration variables
thank you, sir
it works
El miércoles, 8 de abril de 2015, 16:17:34 (UTC+2), Sebastian Bensusan
escribió:
Hi,
I use https://github.com/weavejester/environ for configuration. To call it
from ClojureScript I usually wrap it in a macro like this:
app/env.clj
(ns app.env
(:require [environ.core :refer [env]]))
(defmacro cljs-env [kw]
(env kw))
put it in on project.clj
:env {:rss-uri i-dont-know-how-rss-uri-look-like}
and then call it from ClojureScript like this:
app/view.cljs
(ns app.view
(:require-macros [app.env :as env :refer [cljs-env])
(cljs-env :rss-uri)
Note that the keyword :rss-uri needs to be available at compile time, since
that's when the code `(env kw)` will run.
Hope this helps
--
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 clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released
Hmm... In Clojurescript you can do the following (try ;; throw something (catch :default e e)) When I try the same thing in Clojure, it seems to not be supported. Is there any plans to support this syntax in Clojure 1.7? -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released
Why would that be fine? On Sunday, April 12, 2015 at 10:39:17 PM UTC+2, whodidthis wrote: Are there any thoughts on code like this: #_#?(:cljs (def unrelated-1 nil)) #?(:cljs (def unrelated-2 nil)) #?(:cljs (def unrelated-3 nil)) #?(:clj (def n 10)) #?(:clj (defn num [] n)) ; compile on clj =RuntimeException: Unable to resolve symbol: n I guess it's fine if it continues to work that way but I can imagine it being a little surprising from time to time heh -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Using Google Closure-compatible JS files in CLJS project
If you feel like trying a new build setup you could try shadow-build [1,2]. None of this should be an issue with it and :libs is not required, just make sure the .js files are in some listed source path and the rest should just work. Might have a whole lot of other issues though so YMMV. ;) Not a whole lot of documentation available though. /thomas [1] https://github.com/thheller/shadow-build [2] https://github.com/thheller/shadow-build-example -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released
The only reason :default exists is because *anything* in JavaScript can be thrown and there needs to be some way to catch non-Error derived values. This is not the case for Java of course. :default could probably be aliased to Throwable, but in the meantime differences like this are now handleable via conditional reading. David On Mon, Apr 13, 2015 at 6:37 AM, Robin Heggelund Hansen skinney...@gmail.com wrote: Hmm... In Clojurescript you can do the following (try ;; throw something (catch :default e e)) When I try the same thing in Clojure, it seems to not be supported. Is there any plans to support this syntax in Clojure 1.7? -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released
Ahh ok, makes sense. mandag 13. april 2015 12.45.35 UTC+2 skrev David Nolen følgende: The only reason :default exists is because *anything* in JavaScript can be thrown and there needs to be some way to catch non-Error derived values. This is not the case for Java of course. :default could probably be aliased to Throwable, but in the meantime differences like this are now handleable via conditional reading. David On Mon, Apr 13, 2015 at 6:37 AM, Robin Heggelund Hansen skinn...@gmail.com javascript: wrote: Hmm... In Clojurescript you can do the following (try ;; throw something (catch :default e e)) When I try the same thing in Clojure, it seems to not be supported. Is there any plans to support this syntax in Clojure 1.7? -- 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 javascript:. To post to this group, send email to clojur...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/clojurescript. -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released
There is a ticket to consider a portable solution to this issue: http://dev.clojure.org/jira/browse/CLJ-1293 On Monday, April 13, 2015 at 5:45:35 AM UTC-5, David Nolen wrote: The only reason :default exists is because *anything* in JavaScript can be thrown and there needs to be some way to catch non-Error derived values. This is not the case for Java of course. :default could probably be aliased to Throwable, but in the meantime differences like this are now handleable via conditional reading. David On Mon, Apr 13, 2015 at 6:37 AM, Robin Heggelund Hansen skinn...@gmail.com javascript: wrote: Hmm... In Clojurescript you can do the following (try ;; throw something (catch :default e e)) When I try the same thing in Clojure, it seems to not be supported. Is there any plans to support this syntax in Clojure 1.7? -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Using Google Closure-compatible JS files in CLJS project
cljsjs/openlayers is a Closure lib packaged for CLJS using the deps.cljs :libs feature. Maybe you can find some inspiration there: https://github.com/cljsjs/packages/tree/master/openlayers On Monday, April 13, 2015 at 12:58:58 PM UTC+2, Thomas Heller wrote: If you feel like trying a new build setup you could try shadow-build [1,2]. None of this should be an issue with it and :libs is not required, just make sure the .js files are in some listed source path and the rest should just work. Might have a whole lot of other issues though so YMMV. ;) Not a whole lot of documentation available though. /thomas [1] https://github.com/thheller/shadow-build [2] https://github.com/thheller/shadow-build-example -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: Very slow cljs compilation on Windows
On Sunday, 12 April 2015 17:50:46 UTC+1, Conan Cook wrote: On Sunday, 12 April 2015 16:48:52 UTC+1, Conan Cook wrote: On Saturday, 11 April 2015 18:46:31 UTC+1, Conan Cook wrote: On Saturday, 11 April 2015 18:37:51 UTC+1, Conan Cook wrote: On Saturday, 11 April 2015 18:35:37 UTC+1, Conan Cook wrote: On Friday, 10 April 2015 18:23:52 UTC+1, David Powell wrote: Wonder if something somewhere is calling java.io.FileDescriptor/sync - this i uber slow on Windows (and some Linux filesystems) because it causes the entire filesystem to sync, not just the selected file. On Fri, Apr 10, 2015 at 6:08 PM, Shaun Mahood s.ma...@gmail.com wrote: Wow, that's crazy. On my main machine I get Successfully compiled resources/public/js/app.js in 5.545 seconds. on recompilation. Same project, making the same change to core.cljs, recompilation using lein figwheel I get Successfully compiled resources/public/js/app.js in 0.14 seconds. Running Windows 10 Preview, processor is i7-4790K @ 4.00GHz, 32.0 GB RAM and an SSD. I can try the same thing on a couple older machines as well if you want. On Friday, April 10, 2015 at 9:38:47 AM UTC-6, Conan Cook wrote: Just do: lein new chestnut speed-test cd speed-test lein repl (run) That's enough to show it up for me; a change in core.cljs should trigger a recompilation. For me on a windows filesystem I get: Successfully compiled resources/public/js/app.js in 23.226 seconds. On a linux filesystem I get: Successfully compiled resources/public/js/app.js in 0.174 seconds. That's a pretty hefty difference, whatever your machine it should be obvious. On Friday, 10 April 2015 15:27:13 UTC+1, Shaun Mahood wrote: Conan, if you have a repo I can try it on a few windows machines to compare. I did find that chestnut was really slow to refresh changes and ended up switching to use figwheel instead, it is essentially instant refresh now when I save a file. On Friday, April 10, 2015 at 5:19:58 AM UTC-6, Conan Cook wrote: I've switched from OSX to Windows and a Ubuntu VM, and am experiencing extremely slow cljs compilation. I've got a few chestnut projects, and have tried the chestnut tutorial as well, all with the same results. I opened an issue over at Chestnut: https://github.com/plexus/chestnut/issues/114 The problem is that if I'm compiling files on a Windows filesystem, it's very slow, whether I'm running leiningen from inside Windows or inside Linux. If the files are on the Linux VM filesystem and I'm running leiningen in Linux, it's nice and snappy. Has anyone else had luck compiling cljs on Windows? -- 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. That certainly sounds plausible, as taking a look at files in use during the compilation shows that core.js gets written a lot even when I've only made a change in another namespace. Surely it should be an incremental compilation? That said, there doesn't seem to be any mention of Filedescriptor in the Figwheel codebase: https://github.com/bhauman/lein-figwheel/search?utf8=%E2%9C%93q=filedescriptor Figwheel uses a library called watchtower, which simply does a .lastModified call on a java.io.File, nothing fancy. https://github.com/ibdknox/watchtower/blob/master/src/watchtower/core.clj#L44 Having disabled all services I'm able to and killed all processes I can, I still see the same poor performance. Maybe it's something to do with the fact I'm running BitLocker on a MacBook Pro? I can't find any info about that being a problem, however. The problem is definitely that it's recompiling all the files. I've tried on another
[ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released
I think what you're seeing here makes sense. On Sunday, April 12, 2015 at 3:39:15 PM UTC-5, whodidthis wrote: Are there any thoughts on code like this: #_ This says to ignore the next read form #?(:cljs (def unrelated-1 nil)) This evaluates to *nothing*, ie nothing is read, so it is not ignored by the #_. #?(:cljs (def unrelated-2 nil)) #?(:cljs (def unrelated-3 nil)) These also read as *nothing*. #?(:clj (def n 10)) This *is* read, but ignored per the prior #_ #?(:clj (defn num [] n)) ; compile on clj =RuntimeException: Unable to resolve symbol: n And then this makes sense. I guess it's fine if it continues to work that way but I can imagine it being a little surprising from time to time heh Conditional reading is definitely something to be careful about - I think in this case you are combining two types of conditional reading so be doubly careful. :) To get the effect you want in this, using #_ *inside* the reader conditional would work: #?(:cljs #_(def unrelated-1 nil)) -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released
Sounds like you guys have it figured out; conditional reading forms cannot be ignored, only their results. Just wanted to make sure, had some bad times with it heh On Monday, April 13, 2015 at 4:48:28 PM UTC+3, Alex Miller wrote: I think what you're seeing here makes sense. On Sunday, April 12, 2015 at 3:39:15 PM UTC-5, whodidthis wrote: Are there any thoughts on code like this: #_ This says to ignore the next read form #?(:cljs (def unrelated-1 nil)) This evaluates to *nothing*, ie nothing is read, so it is not ignored by the #_. #?(:cljs (def unrelated-2 nil)) #?(:cljs (def unrelated-3 nil)) These also read as *nothing*. #?(:clj (def n 10)) This *is* read, but ignored per the prior #_ #?(:clj (defn num [] n)) ; compile on clj =RuntimeException: Unable to resolve symbol: n And then this makes sense. I guess it's fine if it continues to work that way but I can imagine it being a little surprising from time to time heh Conditional reading is definitely something to be careful about - I think in this case you are combining two types of conditional reading so be doubly careful. :) To get the effect you want in this, using #_ *inside* the reader conditional would work: #?(:cljs #_(def unrelated-1 nil)) -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released
Ouch! But that actually makes a lot of sense. On Mon, 13 Apr 2015 14:58 Alex Miller a...@puredanger.com wrote: There is a ticket to consider a portable solution to this issue: http://dev.clojure.org/jira/browse/CLJ-1293 On Monday, April 13, 2015 at 5:45:35 AM UTC-5, David Nolen wrote: The only reason :default exists is because *anything* in JavaScript can be thrown and there needs to be some way to catch non-Error derived values. This is not the case for Java of course. :default could probably be aliased to Throwable, but in the meantime differences like this are now handleable via conditional reading. David On Mon, Apr 13, 2015 at 6:37 AM, Robin Heggelund Hansen skinn...@gmail.com wrote: Hmm... In Clojurescript you can do the following (try ;; throw something (catch :default e e)) When I try the same thing in Clojure, it seems to not be supported. Is there any plans to support this syntax in Clojure 1.7? -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
