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
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
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
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
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*
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
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
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
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
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
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 []
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. ;)
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
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
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
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
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,
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
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
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:
20 matches
Mail list logo
