Re: apply to quoted form

[Andy Smith]

Ah I think I get it. 'x is a symbol pointing to a var which is a box that 
contains some value (i.e. which could be a function)

i.e. the following def creates a var, puts 1 into it, then creates a symbol 
'x and finally adds it to the user namespace :

user=> (def x 1)
#'user/x

we can see it in the namespace :
user=> ((ns-map *ns*) 'x)
#'user/x
user=> ('x (ns-map *ns*))
#'user/x

we can resolve the symbol to a var and then get the value in the var :
user=> (-> 'x resolve var-get)
1

we can also do this :
user=> (-> x var var-get)
1

However, im a bit puzzled by the following code as var is meant to take a 
symbol and in '(var x)', x is not quoted so since clojure is strict then x 
it should be evaluated to a Long. Secondly why do I get an error involving 
Cons? :

user=> (type x)
java.lang.Long
user=> (type (var x))
clojure.lang.Var
user=> (var x)
#'user/x
user=> (type 'x)
clojure.lang.Symbol
user=> (var 'x)
CompilerException java.lang.ClassCastException: clojure.lang.Cons cannot be 
cast to clojure.lang.Symbol, 
compiling:(/tmp/form-init8428687381658026649.clj:1:1)


Andy

On Friday, 21 March 2014 23:46:33 UTC, John Mastro wrote:
>
> On Fri, Mar 21, 2014 at 4:44 PM, John Mastro 
> > wrote:
>>
>> (let [f '(+ 1 1)]
>>   (apply (resolve (first f) (rest f
>> ;=> 2
>>
>
> Sorry, I have a typo in there. It should be:
>
> (let [f '(+ 1 1)]
>   (apply (resolve (first f)) (rest f)))
>
> --
> John Mastro
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: rant / cljs in cljs ? :-)

[t x]

I stopped using cljx, and "lein cljsbuild auto" is amazingly fast.

It does look like timing issues / how cljx/cljsbuild auto triggers
work is the issue.

Someone (that happens to be suffering more from this issue) please fix it. :-)

On Fri, Mar 21, 2014 at 4:31 PM, Moritz Ulrich  wrote:
>
> I really hope that a small plugin to coordinate cljx/cljsbuild will show
> up in the near future. I found cljsbuild's crossovers much better
> integrated and easier to use (but still far inferior to cljx).
>
> I agree that a REPL based workflow is much superior, especially with
> tools like Om which remove the need to coordinate DOM updates.
>
> Chas Emerick writes:
>
>> This particular trick is a clever one (that I'm afraid I've had some
>> hand in propagating, for the benefit of those that like an  "auto" +
>> browser refresh workflow), but it's never going to be particularly
>> efficient.  By its very nature, pdo sets up cljx and cljsbuild off and
>> running without any coordination; it's equivalent to running the two
>> tasks in separate processes.
>>
>> It's possible that some hooks may become available in cljsbuild so that
>> things like cljx can do what they like prior to each compile, but that's
>> speculative.
>>
>> IMO, a REPL-based workflow is far superior to anything involving
>> reloading your app's page, insofar as you can (nearly always) apply the
>> changes you're working on without blowing away the state of the app.  In
>> this context, cljx's nREPL middleware excels (but unfortunately cannot
>> be used with the stock ClojureScript browser-REPL; check out Austin).
>>
>> Note that cljx has not been optimized _at all_.  It's "fast enough" for
>> my purposes (i.e. reasonable when doing a clean rebuild, and snappy when
>> doing the small changes typical in a REPL). I'd be happy to merge
>> reasonable patches that make the actual cljx transformation faster.
>>
>> - Chas
>>
>> On 03/21/2014 01:23 PM, t x wrote:
>>> I'm using:
>>>
>>> "lein pdo cljx auto,cljsbuild auto dev'
>>>
>>> However, maybe perhaps it's weird timing interaction between cljx and
>>> cljsbuild that's making the lag appear more than it actually is.
>>>
>>> On Fri, Mar 21, 2014 at 8:27 AM, David Nolen  wrote:
 Unless you're compiling a very large file - with auto :optimizations :none
 you should always get sub-second compile times under auto.

 David


 On Fri, Mar 21, 2014 at 10:55 AM, Timothy Baldridge 
 wrote:
> are you using "lein cljsbuild auto" ? That's what I use, and I get about
> 1-3 sec recompile times for stuff that uses core.async.
>
> Timothy
>
>
> On Fri, Mar 21, 2014 at 12:48 AM, t x  wrote:
>> Hi,
>>
>> *  I'm already using:
>>
>>:incremental true
>>:compiler { :optimizations :none }
>>
>> * I'm also aware of cljs brepl
>>
>>
>> However:
>>
>> 1) the cljs compiler is still too slow for my liking (even though it's
>> not calling closure)
>>
>> 2) I don't like the cljs repl nearly as much as I like the clj repl
>>
>>
>> Now, my dumb/stupid question:
>>
>>Is there any cljs in cljs _slow_ interpreter? I'm perfectly happy
>> with an interpreter that runs 10x slower, if, in exchange, I get to
>> hit "refresh" and my new code starts running.
>>
>>Furthermore, I'm _okay_ with their being a big delay every time I
>> introduce a new macro from clj land.
>>
>>
>>I realize this sounds spoiled -- but -- the cljs compiler delays are
>> really really breaking my flow.
>>
>>
>> Thanks!
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> "One of the main causes of the fall of the Roman Empire was that-lacking
> zero-they had no way to indicate successful termination of their C
> programs."
> (Robert Firth)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> cloj

Re: ANN simple-time

[dm3]

Hey, this looks really simple and nice. 

So, to map Joda concepts to simple-time -  a *timespan* is a standard 
Period (1 day is always 24 hours) and a *datetime* doesn't have a timezone, 
so more akin to LocalDateTime, right?

There's also https://github.com/dm3/clojure.joda-time, in case you haven't 
seen it - more of a complete Joda API wrapper.

On Thursday, 20 March 2014 20:15:55 UTC+2, Matt Bossenbroek wrote:
>
> It is my pleasure to announce simple-time to the world: 
> https://github.com/mbossenbroek/simple-time
>
> simple-time is a dead simple datetime & timespan library for Clojure. It's 
> an opinionated alternative for clj-time that takes a more functional twist 
> on the object-heavy Joda time library.
>
> Full API is here: 
> http://mbossenbroek.github.io/simple-time/simple-time.core.html
>
> Read more about the motivation for simple-time here: 
> https://github.com/mbossenbroek/simple-time#motivations
>
> Enjoy!
>
> -Matt
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: apply to quoted form

[Andy Smith]

Secondly, 4clojure tells me use of resolve is bad as well :

i.e. the following is my latest code

(fn evaluate [c m]
  (let [ [f & as]
 (map
  #(if (sequential? %)
 (evaluate % m)
 (let [x (m %)] (if x x %))) c)]
(apply (resolve f) as)))

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: apply to quoted form

[Andy Smith]

my bad, the above example is wrong it is meant to return a function of the 
environment mappings :

(fn !! [c]
  (fn [m] (let [ [f & as]
 (map
  #(if (sequential? %)
 ((!! %) m)
 (let [x (m %)] (if x x %))) c)]
(apply ({'/ / '+ + '- - '* *} f) as

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

cljsbuild hooks + rsync/ssh

[t x]

Hi,

  This sounds sorta silly:

  I'm already running "lein cljsbuild auto"

  Now, whenver the build completes (definitely when it succeeds; I
don't care what happens when it fails), I would like to trigger an
rsync or ssh to copy the resources/release/*.js files to a remote
machine.

  Is there a standard way to setup these hooks?

Thanks!

My situation is as follows:

  *.cljs files are on my laptop
  lein is on my laptop

  actual webserver is a weak digital ocean droplet

  whenever my (relatively powerful) laptop finishes compiling, I want
my *.js files sent over to the droplet

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN simple-time

[Andrey Antukh]

Very nice! Thanks!


2014-03-22 10:35 GMT+01:00 dm3 :

> Hey, this looks really simple and nice.
>
> So, to map Joda concepts to simple-time -  a *timespan* is a standard
> Period (1 day is always 24 hours) and a *datetime* doesn't have a
> timezone, so more akin to LocalDateTime, right?
>
> There's also https://github.com/dm3/clojure.joda-time, in case you
> haven't seen it - more of a complete Joda API wrapper.
>
>
> On Thursday, 20 March 2014 20:15:55 UTC+2, Matt Bossenbroek wrote:
>>
>> It is my pleasure to announce simple-time to the world:
>> https://github.com/mbossenbroek/simple-time
>>
>> simple-time is a dead simple datetime & timespan library for Clojure.
>> It's an opinionated alternative for clj-time that takes a more functional
>> twist on the object-heavy Joda time library.
>>
>> Full API is here: http://mbossenbroek.github.io/simple-time/simple-
>> time.core.html
>>
>> Read more about the motivation for simple-time here: https://github.com/
>> mbossenbroek/simple-time#motivations
>>
>> Enjoy!
>>
>> -Matt
>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Andrey Antukh - Андрей Антух -  / 
http://www.niwi.be 
https://github.com/niwibe

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Stefan Kamphausen]

Hi,

On Saturday, March 22, 2014 3:52:00 AM UTC+1, Alex Miller wrote:
>
> That's pretty weird. 
>
>
that's pretty true. 
 

> 1.6.0-RC2 is out now - I would really appreciate it if you could give it a 
> shot.
>

Sure.  Tried with Oracle JDK 7 and 8, each run two times and took the 
average.  Each run was done using 

lein clean && lein uberjar && run.sh

where run.sh starts the uberjar and measures the times with /usr/bin/time 
-v.

These are the results:

   *Version* *Java Version* *User time(s)* *Sys time(s)* *Wall clock(s)* *% 
CPU*  1.6.0-RC2 Oracle 1.7.0_11 2087,5 104,5 326,5 671  1.5.1 Oracle 
1.7.0_11 1957 104,5 311,5 661  1.6.0-RC2 Oracle 1.8.0 2022,5 110 318,5 669,5  
1.5.1 Oracle 1.8.0 2087 105 323 675,5  
The results for Java7 are in-line with the results of my previous 
experiments, I tried Java8 just out of curiosity.

Cheers,
stefan

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: om component state

[Adrian Miron]

Yes, a shared channel looks nice :-) 
https://github.com/amiron/tryouts/blob/master/src/cljs/tryouts/notifications.cljs#L11-L25


On Friday, March 21, 2014 6:09:57 PM UTC+2, David Nolen wrote:
>
> On Fri, Mar 21, 2014 at 11:45 AM, Adrian Miron 
> 
> > wrote:
>
>>
>>
>> On Thursday, March 20, 2014 10:58:08 PM UTC+2, David Nolen wrote:
>>>
>>>
>>> If you don't pass app state data to this component then you don't need 
>>> to bother with build at all. If you need a component that doesn't need app 
>>> state but does need component local state you need to use om.core/graft. 
>>> Refer to the documentation on om.core/graft and look at the examples in the 
>>> repo.
>>>
>>> Channels could work. However :shared was also designed with this 
>>> scenario in mind, you could use an atom with the message in it and placed 
>>> it in :shared if the message is not an important piece of state for the 
>>> rest of your application. There are also examples of :shared in the repo as 
>>> well.
>>>
>>> HTH,
>>> David 
>>>
>>
>> Thank you for your reply. I've used graft and it works fine with 
>> channels. I will also try :shared, but I guess I will have to call refresh! 
>> after I swap the shared atom?
>>
>
> No the simplest thing would be to call om.core/root again, however if this 
> is not really a global change (i.e. switching logged in user) then you have 
> to pay for re-rendering your entire UI and throwing away all component 
> local state.
>
> Sounds like the simplest solution for you is a :shared message channel. 
> Components that care about the message need to set up go loops and update 
> their state when they receive a new message.
>
> HTH,
> David
>

On Friday, March 21, 2014 6:09:57 PM UTC+2, David Nolen wrote:
>
> On Fri, Mar 21, 2014 at 11:45 AM, Adrian Miron 
> 
> > wrote:
>
>>
>>
>> On Thursday, March 20, 2014 10:58:08 PM UTC+2, David Nolen wrote:
>>>
>>>
>>> If you don't pass app state data to this component then you don't need 
>>> to bother with build at all. If you need a component that doesn't need app 
>>> state but does need component local state you need to use om.core/graft. 
>>> Refer to the documentation on om.core/graft and look at the examples in the 
>>> repo.
>>>
>>> Channels could work. However :shared was also designed with this 
>>> scenario in mind, you could use an atom with the message in it and placed 
>>> it in :shared if the message is not an important piece of state for the 
>>> rest of your application. There are also examples of :shared in the repo as 
>>> well.
>>>
>>> HTH,
>>> David 
>>>
>>
>> Thank you for your reply. I've used graft and it works fine with 
>> channels. I will also try :shared, but I guess I will have to call refresh! 
>> after I swap the shared atom?
>>
>
> No the simplest thing would be to call om.core/root again, however if this 
> is not really a global change (i.e. switching logged in user) then you have 
> to pay for re-rendering your entire UI and throwing away all component 
> local state.
>
> Sounds like the simplest solution for you is a :shared message channel. 
> Components that care about the message need to set up go loops and update 
> their state when they receive a new message.
>
> HTH,
> David
>

On Friday, March 21, 2014 6:09:57 PM UTC+2, David Nolen wrote:
>
> On Fri, Mar 21, 2014 at 11:45 AM, Adrian Miron 
> 
> > wrote:
>
>>
>>
>> On Thursday, March 20, 2014 10:58:08 PM UTC+2, David Nolen wrote:
>>>
>>>
>>> If you don't pass app state data to this component then you don't need 
>>> to bother with build at all. If you need a component that doesn't need app 
>>> state but does need component local state you need to use om.core/graft. 
>>> Refer to the documentation on om.core/graft and look at the examples in the 
>>> repo.
>>>
>>> Channels could work. However :shared was also designed with this 
>>> scenario in mind, you could use an atom with the message in it and placed 
>>> it in :shared if the message is not an important piece of state for the 
>>> rest of your application. There are also examples of :shared in the repo as 
>>> well.
>>>
>>> HTH,
>>> David 
>>>
>>
>> Thank you for your reply. I've used graft and it works fine with 
>> channels. I will also try :shared, but I guess I will have to call refresh! 
>> after I swap the shared atom?
>>
>
> No the simplest thing would be to call om.core/root again, however if this 
> is not really a global change (i.e. switching logged in user) then you have 
> to pay for re-rendering your entire UI and throwing away all component 
> local state.
>
> Sounds like the simplest solution for you is a :shared message channel. 
> Components that care about the message need to set up go loops and update 
> their state when they receive a new message.
>
> HTH,
> David
>

On Friday, March 21, 2014 6:09:57 PM UTC+2, David Nolen wrote:
>
> On Fri, Mar 21, 2014 at 11:45 AM, Adrian Miron 
> 
> > wrote:
>
>>
>>
>> On Thursday, March 20, 2014 10:58:08 PM UTC+2, David Nolen wrote:
>>>
>>>
>>> If you don't pas

Re: om component state

[Adrian Miron]

Yes, a shared channel looks nice :-) 
https://github.com/amiron/tryouts/blob/master/src/cljs/tryouts/notifications.cljs#L11-L25

On Friday, March 21, 2014 6:09:57 PM UTC+2, David Nolen wrote:
>
> On Fri, Mar 21, 2014 at 11:45 AM, Adrian Miron 
> 
> > wrote:
>
>>
>>
>> On Thursday, March 20, 2014 10:58:08 PM UTC+2, David Nolen wrote:
>>>
>>>
>>> If you don't pass app state data to this component then you don't need 
>>> to bother with build at all. If you need a component that doesn't need app 
>>> state but does need component local state you need to use om.core/graft. 
>>> Refer to the documentation on om.core/graft and look at the examples in the 
>>> repo.
>>>
>>> Channels could work. However :shared was also designed with this 
>>> scenario in mind, you could use an atom with the message in it and placed 
>>> it in :shared if the message is not an important piece of state for the 
>>> rest of your application. There are also examples of :shared in the repo as 
>>> well.
>>>
>>> HTH,
>>> David 
>>>
>>
>> Thank you for your reply. I've used graft and it works fine with 
>> channels. I will also try :shared, but I guess I will have to call refresh! 
>> after I swap the shared atom?
>>
>
> No the simplest thing would be to call om.core/root again, however if this 
> is not really a global change (i.e. switching logged in user) then you have 
> to pay for re-rendering your entire UI and throwing away all component 
> local state.
>
> Sounds like the simplest solution for you is a :shared message channel. 
> Components that care about the message need to set up go loops and update 
> their state when they receive a new message.
>
> HTH,
> David
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

ANN: lein-servlet 0.4.0

[Shantanu Kumar]

Hi,

lein-servlet helps you to work with servlet based apps. I pushed out 
version 0.4.0 of lein-servlet to Clojars -- the changes are listed at the 
URL below:

https://github.com/kumarshantanu/lein-servlet/blob/master/CHANGES.md#2014-march-22--040

Shantanu

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Michał Marczyk]

On 22 March 2014 00:47, Stefan Kamphausen  wrote:
> On Saturday, March 22, 2014 12:41:55 AM UTC+1, Andy Fingerhut wrote:
>> That is odd.  This is a shot in the dark, and probably unhelpful because I
>> do not know a good way to verify whether my guess is true, but perhaps the
>> seqFrom method went from being small enough to be inlined by your JIT before
>> that change, to being too large to consider for inlining after the change?
>> It isn't a big change in the code, so it would have to have been close to
>> the threshold if this is true.
>
> if there is anything I can do to test this, just let me know.

You could experiment with different values of -XX:MaxInlineSize and
-XX:FreqInlineSize, see

http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

You can use -XX:+PrintFlagsFinal to discover what values it's currently using.

Additionally differences in -XX:+PrintCompilation ouput might be interesting.

Cheers,
Michał

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: cljsbuild hooks + rsync/ssh

[Chas Emerick]

That does sound very questionable, but you should be able to wire this 
up using :notify-command:


https://github.com/emezeske/lein-cljsbuild/blob/master/sample.project.clj#L73

- Chas

On 03/22/2014 07:06 AM, t x wrote:

Hi,

   This sounds sorta silly:

   I'm already running "lein cljsbuild auto"

   Now, whenver the build completes (definitely when it succeeds; I
don't care what happens when it fails), I would like to trigger an
rsync or ssh to copy the resources/release/*.js files to a remote
machine.

   Is there a standard way to setup these hooks?

Thanks!

My situation is as follows:

   *.cljs files are on my laptop
   lein is on my laptop

   actual webserver is a weak digital ocean droplet

   whenever my (relatively powerful) laptop finishes compiling, I want
my *.js files sent over to the droplet



--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: rant / cljs in cljs ? :-)

[Chas Emerick]

Despite numerous requests, I have so far resisted integrating cljsbuild, 
cljx, and clojurescript.test.  I noted my sentiments on this topic in a 
comment here some time ago:


https://github.com/lynaghk/cljx/issues/25

I haven't thought about it much since then, but I suspect I will relent 
at some point.  That said, any "integration" amongst these various tools 
will need to be open enough that alternatives can be used as desired 
(e.g. surely clojurescript.test is not the last word in ClojureScript 
testing??).


- Chas

On 03/22/2014 05:26 AM, t x wrote:

I stopped using cljx, and "lein cljsbuild auto" is amazingly fast.

It does look like timing issues / how cljx/cljsbuild auto triggers
work is the issue.

Someone (that happens to be suffering more from this issue) please fix it. :-)

On Fri, Mar 21, 2014 at 4:31 PM, Moritz Ulrich  wrote:

I really hope that a small plugin to coordinate cljx/cljsbuild will show
up in the near future. I found cljsbuild's crossovers much better
integrated and easier to use (but still far inferior to cljx).

I agree that a REPL based workflow is much superior, especially with
tools like Om which remove the need to coordinate DOM updates.

Chas Emerick writes:


This particular trick is a clever one (that I'm afraid I've had some
hand in propagating, for the benefit of those that like an  "auto" +
browser refresh workflow), but it's never going to be particularly
efficient.  By its very nature, pdo sets up cljx and cljsbuild off and
running without any coordination; it's equivalent to running the two
tasks in separate processes.

It's possible that some hooks may become available in cljsbuild so that
things like cljx can do what they like prior to each compile, but that's
speculative.

IMO, a REPL-based workflow is far superior to anything involving
reloading your app's page, insofar as you can (nearly always) apply the
changes you're working on without blowing away the state of the app.  In
this context, cljx's nREPL middleware excels (but unfortunately cannot
be used with the stock ClojureScript browser-REPL; check out Austin).

Note that cljx has not been optimized _at all_.  It's "fast enough" for
my purposes (i.e. reasonable when doing a clean rebuild, and snappy when
doing the small changes typical in a REPL). I'd be happy to merge
reasonable patches that make the actual cljx transformation faster.

- Chas

On 03/21/2014 01:23 PM, t x wrote:

I'm using:

"lein pdo cljx auto,cljsbuild auto dev'

However, maybe perhaps it's weird timing interaction between cljx and
cljsbuild that's making the lag appear more than it actually is.

On Fri, Mar 21, 2014 at 8:27 AM, David Nolen  wrote:

Unless you're compiling a very large file - with auto :optimizations :none
you should always get sub-second compile times under auto.

David


On Fri, Mar 21, 2014 at 10:55 AM, Timothy Baldridge 
wrote:

are you using "lein cljsbuild auto" ? That's what I use, and I get about
1-3 sec recompile times for stuff that uses core.async.

Timothy


On Fri, Mar 21, 2014 at 12:48 AM, t x  wrote:

Hi,

*  I'm already using:

:incremental true
:compiler { :optimizations :none }

* I'm also aware of cljs brepl


However:

1) the cljs compiler is still too slow for my liking (even though it's
not calling closure)

2) I don't like the cljs repl nearly as much as I like the clj repl


Now, my dumb/stupid question:

Is there any cljs in cljs _slow_ interpreter? I'm perfectly happy
with an interpreter that runs 10x slower, if, in exchange, I get to
hit "refresh" and my new code starts running.

Furthermore, I'm _okay_ with their being a big delay every time I
introduce a new macro from clj land.


I realize this sounds spoiled -- but -- the cljs compiler delays are
really really breaking my flow.


Thanks!

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
"One of the main causes of the fall of the Roman Empire was that-lacking
zero-they had no way to indicate successful termination of their C
programs."
(Robert Firth)

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more optio

Re: [ANN] thi.ng/morphogen - Declarative 3D form evolution through tree-based transformations

[kovas boguta]

This is great. Keep up the good work!

On Fri, Mar 21, 2014 at 5:16 PM, Karsten Schmidt  wrote:
> Hi all, I've just pushed the first (promising) beginnings of a new
> project to GH and would like to share with you:
>
> https://github.com/thi-ng/morphogen/
>
> Building on top of its companions, the recently announced thi.ng/geom
> & thi.ng/luxor libraries, morphogen provides a set of extensible
> building blocks to generate complex 3d structures in a completely data
> driven, declarative style.
>
> As usual for this project series, this too is developed in a literate
> format and even though it's still early days, there's quite a bit of
> background info, result renders and detailed descriptions available
> already.
>
> Since the weekend is upon us and maybe one or two of you are
> interested too in these things, I'd highly appreciate if some critical
> and/or creative eyeballs could go over this. Please take a peek, if
> you can!
>
> Some small examples (and their renders) I've been using for testing
> various bits are here:
> https://github.com/thi-ng/morphogen/blob/master/src/examples.org
>
> Things I'm actively working on over the next weeks:
>
> - new deform operators
> - export operator tree as graphviz file
> - develop HTML5 GUI for operator tree editing
>
> Thank you for your consideration! :) K.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How did you learn Clojure?

[Marcus Blankenship]

Thanks, Jerrod, this is great advice.  Thanks so much!


On Mar 21, 2014, at 6:53 PM, Jarrod Swart  wrote:

> A tip if you are completely stuck on 4clojure:
> 
> Often the 4clojure problem will say you can't use a particular function.  The 
> first thing I would do is go look at the source code for that function, then 
> I would try to find other functions with similar functionality.
> 
> Much like learning to paint or write, you have to copy first.  Eventually 
> looking through all that source code you will start to develop a sense of how 
> a problem can be solved, and in giving any solution 4clojure lets you look at 
> the solutions of others.  Look at the most prolific 4clojure users, their 
> solutions will teach you a lot.  Look up the functions they used.  In order 
> to learn to "Think in Clojure" you need to understand how someone who already 
> can\does did what they did. 
> 
> Another general tip is to harness momentum, when I started learning I picked 
> one thing that I could completely finish in a day.  And the trick is to dream 
> small, some things I did:
> List the files in a directory and sort them by type.
> A crypto-quote assist\solver.
> A small text based adventure game.
> 
> The goal is to get a WHOLE thing done, even if it is a small thing.  I did 
> this 2-3 times a week.  Porting old code you have done before in another 
> language is great too because the big issue here will be learning to turn 
> OO\Imperative code into functional code.
> 
> I also wrote a blog post listing the resources I used when just getting 
> started: http://jarrodswart.com/beginner-resources-clojure/, and a super 
> friendly 10k foot view of the reduce function: 
> http://jarrodswart.com/clojure-like-im-five-reduce-functions/.
> 
> Hope this helps,
> Jarrod
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Best,
Marcus

Marcus Blankenship
\\\ Problem Solver, Linear Thinker
\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: apply to quoted form

[Andy Smith]

After the above discussion, I suspect that the point of this 4clojure 
question is that using eval or resolve opens up the possibility for a user 
of the function to inject arbitrary code into the 'Universal Computation 
Engine', whereas using a map necessarily restricts the operations to the 
'allowed' set of arithmetic functions. So eval/resolve are evil because of 
this security concern.

I still dont quite understand the 'Cons' error message in my above post 
though... :o/ 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: rant / cljs in cljs ? :-)

[t x]

Unlike you (involved in all three), I'm involved in 0 of the tools.

>From a very short-sighted view, it seems the problem is that "lein
configuration" is "not clojure code."

It seems what I want is to setup core.async channels:

  * a channel that gets an item whenever my foo/cljx directory changes
  * a channel for cljx to notify cljsbuild that foo/out-cljs has new
data and should be recompiled



On Sat, Mar 22, 2014 at 8:19 AM, Chas Emerick  wrote:
> Despite numerous requests, I have so far resisted integrating cljsbuild,
> cljx, and clojurescript.test.  I noted my sentiments on this topic in a
> comment here some time ago:
>
> https://github.com/lynaghk/cljx/issues/25
>
> I haven't thought about it much since then, but I suspect I will relent at
> some point.  That said, any "integration" amongst these various tools will
> need to be open enough that alternatives can be used as desired (e.g. surely
> clojurescript.test is not the last word in ClojureScript testing??).
>
> - Chas
>
>
> On 03/22/2014 05:26 AM, t x wrote:
>>
>> I stopped using cljx, and "lein cljsbuild auto" is amazingly fast.
>>
>> It does look like timing issues / how cljx/cljsbuild auto triggers
>> work is the issue.
>>
>> Someone (that happens to be suffering more from this issue) please fix it.
>> :-)
>>
>> On Fri, Mar 21, 2014 at 4:31 PM, Moritz Ulrich 
>> wrote:
>>>
>>> I really hope that a small plugin to coordinate cljx/cljsbuild will show
>>> up in the near future. I found cljsbuild's crossovers much better
>>> integrated and easier to use (but still far inferior to cljx).
>>>
>>> I agree that a REPL based workflow is much superior, especially with
>>> tools like Om which remove the need to coordinate DOM updates.
>>>
>>> Chas Emerick writes:
>>>
 This particular trick is a clever one (that I'm afraid I've had some
 hand in propagating, for the benefit of those that like an  "auto" +
 browser refresh workflow), but it's never going to be particularly
 efficient.  By its very nature, pdo sets up cljx and cljsbuild off and
 running without any coordination; it's equivalent to running the two
 tasks in separate processes.

 It's possible that some hooks may become available in cljsbuild so that
 things like cljx can do what they like prior to each compile, but that's
 speculative.

 IMO, a REPL-based workflow is far superior to anything involving
 reloading your app's page, insofar as you can (nearly always) apply the
 changes you're working on without blowing away the state of the app.  In
 this context, cljx's nREPL middleware excels (but unfortunately cannot
 be used with the stock ClojureScript browser-REPL; check out Austin).

 Note that cljx has not been optimized _at all_.  It's "fast enough" for
 my purposes (i.e. reasonable when doing a clean rebuild, and snappy when
 doing the small changes typical in a REPL). I'd be happy to merge
 reasonable patches that make the actual cljx transformation faster.

 - Chas

 On 03/21/2014 01:23 PM, t x wrote:
>
> I'm using:
>
> "lein pdo cljx auto,cljsbuild auto dev'
>
> However, maybe perhaps it's weird timing interaction between cljx and
> cljsbuild that's making the lag appear more than it actually is.
>
> On Fri, Mar 21, 2014 at 8:27 AM, David Nolen 
> wrote:
>>
>> Unless you're compiling a very large file - with auto :optimizations
>> :none
>> you should always get sub-second compile times under auto.
>>
>> David
>>
>>
>> On Fri, Mar 21, 2014 at 10:55 AM, Timothy Baldridge
>> 
>> wrote:
>>>
>>> are you using "lein cljsbuild auto" ? That's what I use, and I get
>>> about
>>> 1-3 sec recompile times for stuff that uses core.async.
>>>
>>> Timothy
>>>
>>>
>>> On Fri, Mar 21, 2014 at 12:48 AM, t x  wrote:

 Hi,

 *  I'm already using:

 :incremental true
 :compiler { :optimizations :none }

 * I'm also aware of cljs brepl


 However:

 1) the cljs compiler is still too slow for my liking (even though
 it's
 not calling closure)

 2) I don't like the cljs repl nearly as much as I like the clj repl


 Now, my dumb/stupid question:

 Is there any cljs in cljs _slow_ interpreter? I'm perfectly
 happy
 with an interpreter that runs 10x slower, if, in exchange, I get to
 hit "refresh" and my new code starts running.

 Furthermore, I'm _okay_ with their being a big delay every time
 I
 introduce a new macro from clj land.


 I realize this sounds spoiled -- but -- the cljs compiler delays
 are
 really really breaking my flow.


 Thanks!

 --

Re: [ANN] Eastwood 0.1.1 Clojure lint tool

[Jakub Holy]

For me, Eastwood fails mysteriously:

$ lein eastwood
Exception in thread "main" java.lang.RuntimeException: No such var: 
clojure.core.cache/through, compiling:(clojure/core/memoize.clj:52:3)
at clojure.lang.Compiler.analyze(Compiler.java:6380)
...
Caused by: java.lang.RuntimeException: No such var: 
clojure.core.cache/through

using :dependencies [[org.clojure/clojure "1.5.1"] ...]

I use couple of other dependencies and 
pluginsthat
 could theoretically somehow conflict with Eastwood.

Cheers, Jakub


On Thursday, March 20, 2014 4:02:36 PM UTC+1, Andy Fingerhut wrote:
>
> Eastwood is a Clojure lint tool.  It analyzes Clojure source code in 
> Leiningen projects, reporting things that may be errors.
>
> Installation instructions are in the documentation here:
>
> https://github.com/jonase/eastwood/#installation--quick-usage
>
> The previous release was in January 2014.  Updates since then are 
> described in the change log here:
>
> 
> https://github.com/jonase/eastwood/blob/master/changes.md#changes-from-version-010-to-011
>
> Probably the most noticeable changes for Eastwood users will be the errors 
> if namespace/file name inconsistencies are found, and the reduction in bad 
> reflection warnings.
>
> Below is the description Eastwood from the January 2014 release:
>
> For example, did you know that if you use clojure.test to write tests, and 
> have multiple deftest definitions in the same namespace with the same name, 
> then the tests in all but the last deftest will never be run, whether those 
> tests would pass or fail?  Eastwood can find those duplicate names, as well 
> as other occurrences of the same Var name defined more than once.
>
> Eastwood can also warn about misplaced doc strings, calling deprecated 
> functions or Java methods, expressions that are suspicious because they 
> always return the same value (e.g. (= expr) is always true), expressions 
> whose return value is not used and appear to have no side effects, and a 
> few others.  See the documentation linked above for a complete list.
>
> Jonas Enlund wrote the original version of Eastwood with the help of 
> several other contributors.  Version 0.1.1 is an update by Jonas, Nicola 
> Mometto, and myself.  It uses the new Clojure contrib libraries 
> tools.reader for reading the code, and tools.analyzer and 
> tools.analyzer.jvm for parsing the source into abstract syntax trees, 
> making it straightforward to write many of the linters.  Thanks especially 
> to Nicola Mometto for tireless enhancements and bug fixes to those 
> libraries.
>
> You can file issues on the Github issue tracker if you encounter problems, 
> but please read the "Known Issues" section of the documentation before 
> filing problems.  Several issues have already been discovered, and their 
> causes documented, while testing Eastwood on most of the Clojure contrib 
> libraries, Clojure itself, and over 35 other open source libraries.
>
> Go squash some bugs!
>
> Andy Fingerhut
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Eastwood 0.1.1 Clojure lint tool

[Sean Corfield]

Use: lein deps :tree

That should show you where the conflict is coming from (you're picking up an 
old core.cache from somewhere).

Sean

On Mar 22, 2014, at 1:34 PM, Jakub Holy  wrote:
> For me, Eastwood fails mysteriously:
> 
> $ lein eastwood
> Exception in thread "main" java.lang.RuntimeException: No such var: 
> clojure.core.cache/through, compiling:(clojure/core/memoize.clj:52:3)
>   at clojure.lang.Compiler.analyze(Compiler.java:6380)
> ...
> Caused by: java.lang.RuntimeException: No such var: clojure.core.cache/through
> 
> using :dependencies [[org.clojure/clojure "1.5.1"] ...]
> 
> I use couple of other dependencies and plugins that could theoretically 
> somehow conflict with Eastwood.
> 
> Cheers, Jakub




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [ANN] Eastwood 0.1.1 Clojure lint tool

[Jakub Holy]

Thank you, I have tried that but haven't found out anything. There is only
one part of the tree that mentions core cache, no conflict (perhaps b/c
there is none until eastwood enters the scene):

[leiningen "2.3.4"]
   [stencil "0.3.2"]
 [org.clojure/core.cache "0.6.2"]

which is only 0.0.1 version behind the latest (and excluding it did not
help)


2014-03-22 22:25 GMT+01:00 Sean Corfield :

> Use: lein deps :tree
>
> That should show you where the conflict is coming from (you're picking up
> an old core.cache from somewhere).
>
> Sean
>
> On Mar 22, 2014, at 1:34 PM, Jakub Holy  wrote:
>
> For me, Eastwood fails mysteriously:
>
> $ lein eastwood
> Exception in thread "main" java.lang.RuntimeException: No such var:
> clojure.core.cache/through, compiling:(clojure/core/memoize.clj:52:3)
>  at clojure.lang.Compiler.analyze(Compiler.java:6380)
> ...
> Caused by: java.lang.RuntimeException: No such var:
> clojure.core.cache/through
>
> using :dependencies [[org.clojure/clojure "1.5.1"] ...]
>
> I use couple of other dependencies and 
> pluginsthat
>  could theoretically somehow conflict with Eastwood.
>
> Cheers, Jakub
>
>
>
>


-- 
*Forget software. Strive to make an impact, deliver a valuable change.*

*(**Vær så snill og hjelp meg med å forbedre norsken **min –** skriftlig og
muntlig. Takk!**)*

Jakub Holy
Solutions Engineer | +47 966 23 666
Iterate AS | www.iterate.no
The Lean Software Development Consultancy
- http://theholyjava.wordpress.com/ -

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Eastwood 0.1.1 Clojure lint tool

[Sean Corfield]

Ah, I ran into this as well recently with a plugin that was evaluating in 
Leiningen - and thus Leiningen's dependency on Stencil (and core.cache) 
overrode my own.

Are you using Vinyasa or something like that?

Sean

On Mar 22, 2014, at 2:55 PM, Jakub Holy  wrote:
> Thank you, I have tried that but haven't found out anything. There is only 
> one part of the tree that mentions core cache, no conflict (perhaps b/c there 
> is none until eastwood enters the scene):
> 
> [leiningen "2.3.4"]
>[stencil "0.3.2"]
>  [org.clojure/core.cache "0.6.2"]
> 
> which is only 0.0.1 version behind the latest (and excluding it did not help)
> 
> 
> 2014-03-22 22:25 GMT+01:00 Sean Corfield :
> Use: lein deps :tree
> 
> That should show you where the conflict is coming from (you're picking up an 
> old core.cache from somewhere).
> 
> Sean




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [ANN] Eastwood 0.1.1 Clojure lint tool

[Jakub Holy]

Yes, I am using vinyasa - see
https://github.com/jakubholynet/dotfiles/blob/master/.lein/profiles.clj

Still, Lein's core.cache is nearly the newest available...


2014-03-22 23:01 GMT+01:00 Sean Corfield :

> Ah, I ran into this as well recently with a plugin that was evaluating in
> Leiningen - and thus Leiningen's dependency on Stencil (and core.cache)
> overrode my own.
>
> Are you using Vinyasa or something like that?
>
> Sean
>
> On Mar 22, 2014, at 2:55 PM, Jakub Holy  wrote:
>
> Thank you, I have tried that but haven't found out anything. There is only
> one part of the tree that mentions core cache, no conflict (perhaps b/c
> there is none until eastwood enters the scene):
>
> [leiningen "2.3.4"]
>[stencil "0.3.2"]
>  [org.clojure/core.cache "0.6.2"]
>
> which is only 0.0.1 version behind the latest (and excluding it did not
> help)
>
>
> 2014-03-22 22:25 GMT+01:00 Sean Corfield :
>
>> Use: lein deps :tree
>>
>> That should show you where the conflict is coming from (you're picking up
>> an old core.cache from somewhere).
>>
>> Sean
>>
>
>
>


-- 
*Forget software. Strive to make an impact, deliver a valuable change.*

*(**Vær så snill og hjelp meg med å forbedre norsken **min –** skriftlig og
muntlig. Takk!**)*

Jakub Holy
Solutions Engineer | +47 966 23 666
Iterate AS | www.iterate.no
The Lean Software Development Consultancy
- http://theholyjava.wordpress.com/ -

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Eastwood 0.1.1 Clojure lint tool

[Sean Corfield]

On Mar 22, 2014, at 3:27 PM, Jakub Holy  wrote:
> Yes, I am using vinyasa - see 
> https://github.com/jakubholynet/dotfiles/blob/master/.lein/profiles.clj

See https://github.com/zcaudate/vinyasa/issues/3

> Still, Lein's core.cache is nearly the newest available...

My understanding is that 0.6.3 added core.cache/through, and core.memoize 
depends on that version.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [ANN] Eastwood 0.1.1 Clojure lint tool

[Jakub Holy]

I see. Thanks a lot!


2014-03-22 23:32 GMT+01:00 Sean Corfield :

> On Mar 22, 2014, at 3:27 PM, Jakub Holy  wrote:
>
> Yes, I am using vinyasa - see
> https://github.com/jakubholynet/dotfiles/blob/master/.lein/profiles.clj
>
>
> See https://github.com/zcaudate/vinyasa/issues/3
>
>  Still, Lein's core.cache is nearly the newest available...
>
>
> My understanding is that 0.6.3 added core.cache/through, and core.memoize
> depends on that version.
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
>


-- 
*Forget software. Strive to make an impact, deliver a valuable change.*

* (**Vær så snill og hjelp meg med å forbedre norsken **min –** skriftlig
og muntlig. Takk!**)*

Jakub Holy
Solutions Engineer | +47 966 23 666
Iterate AS | www.iterate.no
The Lean Software Development Consultancy
- http://theholyjava.wordpress.com/ -

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN+RFC] data.avl 0.0.12-alpha1 -- sliceable & splittable sorted collections

[Michał Marczyk]

Hi,

I am pleased to announce the 0.0.12-alpha1 release of data.avl, a
Clojure Contrib library providing drop-in replacements for
Clojure(Script)'s built-in sorted maps and sets with additional
functionality including support for real (non-view) logarithmic-time
slicing, splits, nearest neighbour lookups, rank queries and
transients. Performance in comparison to the built-ins is in
expectation better for lookups and worse for non-transient "updates";
memory use is higher by a reference and two ints per node.

This release includes an important fix to the rebalancing algorithm
and a much more extensive test suite. I would strongly advise all
users of 0.0.11 to upgrade as soon as possible. The "alpha"
designation is purely to do with the new additions to the API; see
below for details.

  [org.clojure/data.avl "0.0.12-alpha1"]

  
org.clojure
data.avl
0.0.12-alpha1
  

  org.clojure:data.avl:0.0.12-alpha1

As mentioned above, this is an alpha release because I would like to
solicit comments on several new additions to the API:

  (require '[clojure.data.avl :as avl])

  (avl/nearest (avl/sorted-set 0 1 2) < 2)
  ;= 1

  (avl/subrange (avl/sorted-set 0 1 2 3 4 5) >= 1 < 4)
  ;= #{1 2 3}

  (avl/split-at 2 (avl/sorted-set 0 1 2 3 4 5))
  ;= [#{0 1} #{2 3 4 5}]

  (avl/split-key 3 (avl/sorted-set 0 2 4 6))
  ;= [#{0 2} nil #{4 6}]

All of these functions operate in time logarithmic in the size of
their inputs. avl/subrange returns a data.avl collection of the same
type as its input and completely independent from it -- that is, it
shares structure with the input where possible, but does not hold on
to any parts of the tree containing keys that should not be present in
the output. avl/split-at and avl/split-key return similarly
independent data.avl collections; the middle element of the vector
returned by split-key is the element at the split key if present in
the input, nil otherwise.

"split" is the name usually applied in the literature to the operation
that splits a tree into a "left" tree, a middle element and a "right"
tree. "subrange" could also be called "slice". The split-* functions
take their collection argument last to be consistent with
clojure.core's split-at and split-with. Arguments accepted by subrange
are analogous to those taken by subseq/rsubseq.

I would appreciate any and all comments regarding this API.

Many thanks to the two new contributors to this release (listed here
in chronological order of ticket creation): Pepijn de Vos, who
prompted me to develop the above-mentioned new features by creating
the ticket asking for what is now avl/nearest and mentioning
java.util.Navigable{Map,Set}, and who provided new tests for
avl/nearest; and Andy Fingerhut, who kept on top of the hashing
changes and provided the initial implementation of new-style hasheq
for data.avl with further tests.

Cheers,
Michał

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How did you learn Clojure?

[Alan Moore]

Read lots and lots of code. I've poured over many many GH 
projects/libraries for clojure. Take a domain you are familiar with, 
preferably something you've written before in another language, find a 
library that does that thing and then read the code until you understand it 
clearly. Try to really understand what Persistent data structures are and 
how you use them.

When you don't understand some small thing don't just gloss over it. That 
works in most other languages but you really need to slow down and try to 
understand each thing before proceeding.

Some of the hardest parts of the language for me were the subtle, but very 
powerful, automatic destructuring, shorthand notations and in some cases 
the single character that can completely change the meaning or context of 
some code - like when it is evaluated. Keep asking yourself, is this code 
being executed at this point or is it going to be used later in some other 
context (usually w.r.t. lambdas...)

Next to that I had to re-learn my understanding of LISP and the idioms of 
Clojure. I had done LISP years before but all that knowledge of (car) (cdr) 
(cddr) etc was kinda useless in helping me understand the more powerful 
features of Clojure.

Also, make sure you really understand the code == data thing. That is 
really fundamental to understanding the power of LISP in general and 
Clojure in particular.

Hope this helps. Take care!

Alan



On Saturday, March 22, 2014 11:38:43 AM UTC-7, Marcus Blankenship wrote:
>
> Thanks, Jerrod, this is great advice.  Thanks so much!
>
>
> On Mar 21, 2014, at 6:53 PM, Jarrod Swart > 
> wrote:
>
> A tip if you are completely stuck on 4clojure:
>
> Often the 4clojure problem will say you can't use a particular function. 
>  The first thing I would do is go look at the source code for that 
> function, then I would try to find other functions with similar 
> functionality.
>
> Much like learning to paint or write, you have to copy first.  Eventually 
> looking through all that source code you will start to develop a sense of 
> how a problem can be solved, and in giving any solution 4clojure lets you 
> look at the solutions of others.  Look at the most prolific 4clojure users, 
> their solutions will teach you a lot.  Look up the functions they used.  In 
> order to learn to "Think in Clojure" you need to understand how someone who 
> already can\does did what they did. 
>
> Another general tip is to harness momentum, when I started learning I 
> picked one thing that I could completely finish in a day.  And the trick is 
> to dream small, some things I did:
>
>- List the files in a directory and sort them by type.
>- A crypto-quote assist\solver.
>- A small text based adventure game.
>
>
> The goal is to get a WHOLE thing done, even if it is a small thing.  I did 
> this 2-3 times a week.  Porting old code you have done before in another 
> language is great too because the big issue here will be learning to turn 
> OO\Imperative code into functional code.
>
> I also wrote a blog post listing the resources I used when just getting 
> started: http://jarrodswart.com/beginner-resources-clojure/, and a super 
> friendly 10k foot view of the reduce function: 
> http://jarrodswart.com/clojure-like-im-five-reduce-functions/.
>
> Hope this helps,
> Jarrod
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
> Best,
> Marcus
>
> Marcus Blankenship
> \\\ Problem Solver, Linear Thinker
> \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
>  
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Garden, Thorn - Looking for contributors

[Joel Holdbrooks]

Greetings everyone,

About a year ago I began working on Garden and in the short time the 
library has been around it's grown a bit. Although many folks seem to be 
interested in it, there's certainly not as much adoption of the library as 
I'd like to see. Sass, Less, and (god help us) pure CSS still appear to be 
the default choices for many people writing web applications in Clojure.

This is something I'd like to change... but I need *your* help!

No, no. Put down the phone. Don't look for a KickStarter URL. It's nothing 
like that.

How you can help Garden

I'm looking for individuals who are interested in the following:


   - improving the compiler code
   - improving/extending existing API's
   - building an interface to the CSSOM

I'm also open to good 'ol fashioned suggestions, pain points you've 
experienced using the library, or flat out letting me know what it would 
take to get you to choose Garden over the alternatives for your next 
project.

How you can help Thorn

Thorn is very young project and has no official release yet. So what is it? 
At the moment it's the beginnings of a Sass Parse Tree transformer; 
something that will take CSS/SCSS/Sass code and give you Garden code. 
There's a lot of fabulous libraries available in Sass and I'm sure it's a 
big factor when choosing how to go about CSS generation.

I'm looking for individuals who are interested in the following:


   - accurately transforming CSS/SCSS/Sass to real Clojure code targeting 
   Garden
   - accurately transforming Less to real Clojure code targeting Garden

Why?

I deeply believe that being able to author CSS in Clojure or ClojureScript 
is a key piece to having an extremely compelling story for web application 
development in Clojure. Being able to *program* CSS and not just 
*preprocess* is a big advantage over existing tools. Being able to use all 
of Clojure everywhere has astounding possibilities.


If any of this sounds interesting to you please get in contact with me or 
reply here. I will also be in San Francisco tomorrow until Tuesday for 
Clojure/West if you'd like to discuss these items in person.


Truly,

Joel

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

ANN: core.matrix "coding dojo" repo

[Mike Anderson]

Hi All,

I've made a repository for an upcoming core.matrix "coding dojo" that I'm 
organising. I think it might be a useful resource for others in the Clojure 
community, so I'm sharing the link here:
https://github.com/clojure-numerics/core.matrix.dojo

This is a basic project setup for a core.matrix project with some useful 
libraries and example code. I'll add some more examples over the next week 
or two. PRs also welcome, if anyone has other simple examples that are good 
for beginners to learn from.

  Mike.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: apply to quoted form

[Mars0i]

A remark from someone who's not a clojure expert, and isn't familiar with 
4clojure or its goals:
IMO eval isn't bad.  It's a tool, and it can be abused like any tool.  You 
have a choice.  Using eval with your original code would be a lot simpler, 
but there are tradeoffs.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.