Re: alternative to passing parameters to functions

[Gunnar Völkel]

You can checkout clojure.options (https://github.com/guv/clojure.options/).
One of its main features is documentation for options (even transitive ones 
in calls to other functions with options).

-- 
-- 
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/groups/opt_out.

Multiple subselects, korma

[Omer Iqbal]

Hey folks, I'm using korma 0.3.0 RC4 in a project, and wanted to
know what's the idiomatic way to perform a union of two subselects.
e.g. Something of this sort
(select foo
   (where  {:somefield
 [in
 (subselect ...)
 (subselect ...)]}))

Thanks!
Omer

-- 
-- 
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/groups/opt_out.

Re: STM in Clojure vs Haskell, why no retry or orElse?

[Tom Hall]

OK, I guess the essence is:
Why does Clojure not need retry or orElse when another implementer of
STM considers them essential?
I'm guessing it's because clojures in MVCC but would like confirmation
and perhaps links to comparisons between STMs and maybe a guide to
Clojures.

How would you solve the Santa Claus Problem in Clojure?
I suggested watchers might be a good idea but am curious what others would do.
The original paper has a 2 page description of the problem if the
version I linked to is too verbose for people,
http://www.crsr.net/files/ANewExerciseInConcurrency.pdf


Cheers,
Tom



On 16 February 2013 17:13, vemv  wrote:
> You can increase the chances of generating discussion by boiling down both
> the relevant content of paper and your program to a minimal, self-contained
> form.
>
> Cheers - Victor
>
>
> On Friday, February 15, 2013 4:05:09 PM UTC+1, thattommyhall wrote:
>>
>> A few months ago I reread Simon Peyton Joneses article on STM in the
>> Beautiful Code book and decided to try and translate it into clojures
>> STM
>>
>> See the paper here http://research.microsoft.com/pubs/74063/beautiful.pdf
>>
>> He says 'Atomic blocks as we have introduced them so far are utterly
>> inadequate to coordinate concurrent programs. They lack two key
>> facilities: blocking and choice' so I guess the implication is
>> Clojures STM is inferior, any thoughts?
>>
>> I had to use a constraint on a ref and try/catch to get the same
>> effect (though I hate using exceptions for control flow it does seem
>> to work)
>>
>>
>> https://github.com/thattommyhall/santa-claus/blob/master/src/santa/core.clj
>>
>> I think a better solution might be had using watchers, how would you do
>> it?
>> Any good links explaining differences in the STMs?
>>
>> Cheers,
>> Tom
>
> --
> --
> 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/groups/opt_out.
>
>

-- 
-- 
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/groups/opt_out.

Re: RC 16: Last chance to test against Clojure 1.5 before it ships

[Dave Sann]

I don't expect this to go into 1.5.

But the point raised by vemv is a good one.

Clojurescript makes ExceptionInfo available by default. If this were also 
the case in clojure - it would help with portable code. Specifically 
catching ExceptionInfo. (longer comments on the thread referenced 
previously).

Dave


On Monday, 18 February 2013 12:18:15 UTC+11, Dave Sann wrote:
>
> timely comment.
>
> you can create and throw it but catching it requires the imported type. 
> (not withstanding catching the generic Exception on the JVM).
>
> see the link for suggestion/discussion on making this more "uniform" for 
> clj and cljs:
>
> https://groups.google.com/d/topic/clojurescript/A3wH_Hm3OmQ/discussion
>
> Dave
>
> On Monday, 18 February 2013 03:54:00 UTC+11, Baishampayan Ghose wrote:
>>
>> You can create an ExceptionInfo instance easily by using the core fn 
>> `ex-info`. So something like ... (throw (ex-info {:foo "bar"})) works 
>> fine. ~BG 
>>
>> On Sun, Feb 17, 2013 at 10:05 PM, vemv  wrote: 
>> > Couldn't clojure.lang.ExceptionInfo be imported by default? That'd 
>> surely 
>> > help making ExceptionInfo the idiomatic exception to be thrown. 
>> > 
>> > 
>> > On Thursday, February 14, 2013 4:33:42 AM UTC+1, 
>> > stuart@gmail.comwrote: 
>> >> 
>> >> If you care about Clojure 1.5 compatibility for your codebase, please 
>> test 
>> >> it against RC 16 as soon as possible. 
>> >> 
>> >> You can get the source and build it yourself from [1], or wait for 
>> Maven 
>> >> Central [2] to pick up the CI build, which usually takes a few hours. 
>> >> 
>> >> Thanks! 
>> >> Stu 
>> >> 
>> >> [1] https://github.com/clojure/clojure 
>> >> [2] http://bit.ly/WEnjAi 
>> > 
>> > -- 
>> > -- 
>> > 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/groups/opt_out. 
>> > 
>> > 
>>
>>
>>
>> -- 
>> Baishampayan Ghose 
>> b.ghose at gmail.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/groups/opt_out.

Re: with-redefs for vars in a different namespace for tests (midje facts)

[Brian Marick]

On Feb 17, 2013, at 8:49 PM, Leonardo Borges  
wrote:

> My theory behind why this works is that when I reload the cache
> namespace it recompiles it - and at that point, the new var binding is
> available.
> 
> Is this the case? More importantly, is this how I should be doing this?

Yes. If you load a namespace that uses a macro, the macro is expanded at load 
time. 

Probably what you should do is redefine whatever function `with-redis` expands 
into. (If it's a private, use the var:

   (cache/set "key" "value" => "OK")
   (provided 
  (#'redis/private-redis-function …) => …
  (redis/set …) => …)



Looking for employment as a Clojure programmer
Latest book: /Functional Programming for the Object-Oriented Programmer/
https://leanpub.com/fp-oo

-- 
-- 
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/groups/opt_out.

Re: RC 16: Last chance to test against Clojure 1.5 before it ships

[vemv]

Your additional points make more evident the need to put some final effort 
on the design of ExceptionInfo - leaving it "alpha" would be pretty 
unfortunate.

On Monday, February 18, 2013 2:05:39 PM UTC+1, Dave Sann wrote:
>
> I don't expect this to go into 1.5.
>
> But the point raised by vemv is a good one.
>
> Clojurescript makes ExceptionInfo available by default. If this were also 
> the case in clojure - it would help with portable code. Specifically 
> catching ExceptionInfo. (longer comments on the thread referenced 
> previously).
>
> Dave
>
>
> On Monday, 18 February 2013 12:18:15 UTC+11, Dave Sann wrote:
>>
>> timely comment.
>>
>> you can create and throw it but catching it requires the imported type. 
>> (not withstanding catching the generic Exception on the JVM).
>>
>> see the link for suggestion/discussion on making this more "uniform" for 
>> clj and cljs:
>>
>> https://groups.google.com/d/topic/clojurescript/A3wH_Hm3OmQ/discussion
>>
>> Dave
>>
>> On Monday, 18 February 2013 03:54:00 UTC+11, Baishampayan Ghose wrote:
>>>
>>> You can create an ExceptionInfo instance easily by using the core fn 
>>> `ex-info`. So something like ... (throw (ex-info {:foo "bar"})) works 
>>> fine. ~BG 
>>>
>>> On Sun, Feb 17, 2013 at 10:05 PM, vemv  wrote: 
>>> > Couldn't clojure.lang.ExceptionInfo be imported by default? That'd 
>>> surely 
>>> > help making ExceptionInfo the idiomatic exception to be thrown. 
>>> > 
>>> > 
>>> > On Thursday, February 14, 2013 4:33:42 AM UTC+1, 
>>> > stuart@gmail.comwrote: 
>>> >> 
>>> >> If you care about Clojure 1.5 compatibility for your codebase, please 
>>> test 
>>> >> it against RC 16 as soon as possible. 
>>> >> 
>>> >> You can get the source and build it yourself from [1], or wait for 
>>> Maven 
>>> >> Central [2] to pick up the CI build, which usually takes a few hours. 
>>> >> 
>>> >> Thanks! 
>>> >> Stu 
>>> >> 
>>> >> [1] https://github.com/clojure/clojure 
>>> >> [2] http://bit.ly/WEnjAi 
>>> > 
>>> > -- 
>>> > -- 
>>> > 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/groups/opt_out. 
>>> > 
>>> > 
>>>
>>>
>>>
>>> -- 
>>> Baishampayan Ghose 
>>> b.ghose at gmail.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/groups/opt_out.

Re: STM in Clojure vs Haskell, why no retry or orElse?

[Philip Potter]

On 18 February 2013 12:30, Tom Hall  wrote:
> OK, I guess the essence is:
> Why does Clojure not need retry or orElse when another implementer of
> STM considers them essential?

What are retry and orElse? What do they do?

> I'm guessing it's because clojures in MVCC but would like confirmation
> and perhaps links to comparisons between STMs and maybe a guide to
> Clojures.
>
> How would you solve the Santa Claus Problem in Clojure?
> I suggested watchers might be a good idea but am curious what others would do.
> The original paper has a 2 page description of the problem if the
> version I linked to is too verbose for people,
> http://www.crsr.net/files/ANewExerciseInConcurrency.pdf

Following links creates inertia, particularly when the links are pdfs
and when people are reading the list on mobile devices. For reference,
here is a one-paragraph description I found on google:

"Santa repeatedly sleeps until wakened by either all of his nine
reindeer, back from their holidays, or by a group of three of his ten
elves. If awakened by the reindeer, he harnesses each of them to his
sleigh, delivers toys with them and finally unharnesses them (allowing
them to go off on holiday). If awakened by a group of elves, he shows
each of the group into his study, consults with them on toy R&D and
finally shows them each out (allowing them to go back to work). Santa
should give priority to the reindeer in the case that there is both a
group of elves and a group of reindeer waiting."

Phil
>
>
> Cheers,
> Tom
>
>
>
> On 16 February 2013 17:13, vemv  wrote:
>> You can increase the chances of generating discussion by boiling down both
>> the relevant content of paper and your program to a minimal, self-contained
>> form.
>>
>> Cheers - Victor
>>
>>
>> On Friday, February 15, 2013 4:05:09 PM UTC+1, thattommyhall wrote:
>>>
>>> A few months ago I reread Simon Peyton Joneses article on STM in the
>>> Beautiful Code book and decided to try and translate it into clojures
>>> STM
>>>
>>> See the paper here http://research.microsoft.com/pubs/74063/beautiful.pdf
>>>
>>> He says 'Atomic blocks as we have introduced them so far are utterly
>>> inadequate to coordinate concurrent programs. They lack two key
>>> facilities: blocking and choice' so I guess the implication is
>>> Clojures STM is inferior, any thoughts?
>>>
>>> I had to use a constraint on a ref and try/catch to get the same
>>> effect (though I hate using exceptions for control flow it does seem
>>> to work)
>>>
>>>
>>> https://github.com/thattommyhall/santa-claus/blob/master/src/santa/core.clj
>>>
>>> I think a better solution might be had using watchers, how would you do
>>> it?
>>> Any good links explaining differences in the STMs?
>>>
>>> Cheers,
>>> Tom
>>
>> --
>> --
>> 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/groups/opt_out.
>>
>>
>
> --
> --
> 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/groups/opt_out.
>
>

-- 
-- 
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/groups/opt_out.

The case for as->> ("as-last")

[vemv]

While there are other possible uses 
(example), 
I see myself mainly using as-> as a mechanism for resorting to thread-last 
within a thread-first expression.

For example, given

(-> [[1 1 1] 2 3] (nth 0))

I might want to add an operation that doesn't happen to have an adequate 
signature (sequence functions tend to not be thread-first friendly). You 
can't just add:

(-> [[1 1 1] 2 3] (nth 0) (map inc)) ;; fail

And neither can be solved by adding a lambda:

(-> [[1 1 1] 2 3] (nth 0) #(map inc %)) ;; fail

Clojure 1.5's as->, though, can come to the rescue.

(-> [[1 1 1] 2 3] (nth 0) (as-> x (map inc x))) ;; cool

Now, I only wish 1.5 came with as->> macro! Its implemetation is trivial 
anyway.

(defmacro as->> [name & body]
  (let [[b v] ((juxt butlast last) body)]
`(let [~name ~v]
   ~@b)))

(->> [1 2 3] (as->> _ (nth _ 0)))

Of course, for the given examples, using these "as" forms is overkill. But 
if you've ever ended up writing large expressions (especially when 
experimenting) which arbitrarily nest/interleave ->> and ->, using as-> and 
as->> can provide a more sequential, structured alternative.

Couldn't find any related discussion about the uses of as->, as its name is 
unfriendly to Google/JIRA searches. Thoughts?

-- 
-- 
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/groups/opt_out.

Re: How to bind an Aleph TCP server to a TCP v4 port?

[Jorge Luis Pérez]

Hi Peter,

You was right! I append the -Djava.net.preferIPv4Stack=true option in the 
project file:

(defproject clj-echo-server "0.1.0-SNAPSHOT"
  :description "Echo server with Aleph"
  :url "http://example.com/FIXME";
  :license {:name "Eclipse Public License"
  :url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [[org.clojure/clojure "1.4.0"]
 [aleph "0.3.0-beta12"]]
  :main clj-echo-server.core
  *:jvm-opts** ["**-Djava.net.preferIPv4Stack=tru**e**"]*)


And now works in the way I want.

Thanks!

Jorge


On Friday, 15 February 2013 06:16:21 UTC-3, peter.c...@googlemail.com wrote:
>
>
> Hi Jorge,
>
> I'm not sure if this is what you need but, you could try starting the jvm with
>
> |-Djava.net.preferIPv4Stack=true
>
> Regards,
>
> Peter
>
>
> On Thursday, 14 February 2013 23:06:24 UTC, Jorge Luis Pérez wrote:
>>
>> I started to learn Clojure a couple of days ago. I was trying with some 
>> Aleph TCP echo server examples but I can not get the server to bind to a 
>> tcp v4 port. The server only binds to a tcp v6 port by default. 
>>
>> Here my project file: 
>>
>> (defproject clj-echo-server "0.1.0-SNAPSHOT"
>>   :description "Echo server with Aleph"
>>   :url "http://example.com/FIXME";
>>   :license {:name "Eclipse Public License"
>>   :url "http://www.eclipse.org/legal/epl-v10.html"}
>>   :dependencies [[org.clojure/clojure "1.4.0"]
>>  [aleph "0.3.0-beta12"]]
>>   :main clj-echo-server.core)
>>
>> And the server code:
>>
>> (ns clj-echo-server.core)
>> (use 'lamina.core 'aleph.tcp 'gloss.core)
>> (defn handler [ch client-info]
>>   (receive-all ch
>> #(enqueue ch (str "You said " %
>> (start-tcp-server
>>   handler
>>   {:port 9000, :frame (string :utf-8 :delimiters ["\r\n"])})
>>
>>
>> I can't figure out if I'm doing something wrong or how to configure the 
>> binding port, the documentation wasn't very helpful about tcp ports.
>>
>> My OS is an Ubuntu 12.04.2 LTS, the Leiningen version is 2.0.0-preview10 
>> and all runs on Java 1.6.0_24 OpenJDK 64-Bit Server VM.
>>
>> Can anyone advise me on how to configure the port binding for the tcp 
>> server?
>>
>> Thanks for your time.
>>
>

-- 
-- 
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/groups/opt_out.

reflection used for (or ...) and (into-array ...)

[AtKaaZ]

For *or*
=> *(set! *warn-on-reflection* true)
   (def ^Integer a 1)
   (java.awt.Color. 0 0 ^Integer (or ^Integer a 0) 0)
   *clojure-version**
true
#'cgws.notcore/a
Reflection warning, NO_SOURCE_PATH:3:1 - call to java.awt.Color ctor can't
be resolved.
#
{:major 1, :minor 5, :incremental 0, :qualifier "*RC16*"}
=> *(java.awt.Color. 0 0 ^Integer (or 0 ^Integer a) 0)*
Reflection warning, NO_SOURCE_PATH:2:1 - call to java.awt.Color ctor can't
be resolved.
#
=>* (java.awt.Color. 0 0 a 0)*
#


For *into-array*  I don't yet have a sample but what is wanted is this:
*^{:tag "[Ljava.awt.Color;"} (into-array java.awt.Color (list
(java.awt.Color. 0 0 0 0)))*
but what we get is the returned value without the typehint when doing just
this:
*(into-array java.awt.Color (list (java.awt.Color. 0 0 0 0)))*


I'm not sure which jira issues apply for these, likely this is already
reported but more generically?

-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate it.

-- 
-- 
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/groups/opt_out.

Re: reflection used for (or ...) and (into-array ...)

[Andy Fingerhut]

Integer is a "boxed" integer in Java.  It is a full Java Object.  The 
java.awt.Color constructor you are calling takes 4 primitive int parameters, 
not Integer.  Try this:

(set! *warn-on-reflection* true)
(def a 1)
(java.awt.Color. (int 0) (int 0) (int (or a 0)) (int 0))


I'm not so sure what you are asking for with the into-array part of your 
questions.  The last into-array expression returns a Java array of 
java.awt.Color objects.  If you are trying to pass that to some other Java 
method and you are seeing reflection, and adding a type hint of 
^"[Ljava.awt.Color;" doesn't work somewhere near there to avoid the reflection, 
it would be good to show a code snippet of what you are trying and getting 
reflection with.

Andy


On Feb 18, 2013, at 10:29 AM, AtKaaZ wrote:

> For or
> => (set! *warn-on-reflection* true)
>(def ^Integer a 1)
>(java.awt.Color. 0 0 ^Integer (or ^Integer a 0) 0)
>*clojure-version*
> true
> #'cgws.notcore/a
> Reflection warning, NO_SOURCE_PATH:3:1 - call to java.awt.Color ctor can't be 
> resolved.
> #
> {:major 1, :minor 5, :incremental 0, :qualifier "RC16"}
> => (java.awt.Color. 0 0 ^Integer (or 0 ^Integer a) 0)
> Reflection warning, NO_SOURCE_PATH:2:1 - call to java.awt.Color ctor can't be 
> resolved.
> #
> => (java.awt.Color. 0 0 a 0)
> #
> 
> 
> For into-array  I don't yet have a sample but what is wanted is this:
> ^{:tag "[Ljava.awt.Color;"} (into-array java.awt.Color (list (java.awt.Color. 
> 0 0 0 0)))
> but what we get is the returned value without the typehint when doing just 
> this:
> (into-array java.awt.Color (list (java.awt.Color. 0 0 0 0)))
> 
> 
> I'm not sure which jira issues apply for these, likely this is already 
> reported but more generically? 

-- 
-- 
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/groups/opt_out.

Loading in jars with dependencies at runtime into separate classloaders with independent classpaths

[Adam Clements]

I'm working on a web api wrapper around a number of java/clojure libraries. 
One problem that I have run into is transitive dependency conflicts, 
especially when some of the projects are older than others. 

What I want to do is have each API endpoint's final handler function in its 
own classloader, with its own dependencies, ideally downloaded at runtime. 
That way none of them will interfere with one another and I can add new API 
endpoints without restarting the entire api server process.

Is this possible? I have come across pomegranate for dependency resolution 
and classlojure for evaling in other classloaders, but I can't find any 
examples of doing both at once, and my experiments have so far been 
unsuccessful. 

Any hints would be much appreciated,

Thanks,
Adam

-- 
-- 
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/groups/opt_out.

Re: Loading in jars with dependencies at runtime into separate classloaders with independent classpaths

[Toby Crawley]

Adam:

You can do this exact thing in Immutant[1]. It can handle multiple
applications at the same time, with each application getting an isolated
ClassLoader. Each application can optionally have its dependencies
resolved at deploy time via pomegranate, and can be (re)deployed
independently of other applications within the same container.

[1]:http://immutant.org

Adam Clements writes:

> I'm working on a web api wrapper around a number of java/clojure libraries. 
> One problem that I have run into is transitive dependency conflicts, 
> especially when some of the projects are older than others. 
>
> What I want to do is have each API endpoint's final handler function in its 
> own classloader, with its own dependencies, ideally downloaded at runtime. 
> That way none of them will interfere with one another and I can add new API 
> endpoints without restarting the entire api server process.
>
> Is this possible? I have come across pomegranate for dependency resolution 
> and classlojure for evaling in other classloaders, but I can't find any 
> examples of doing both at once, and my experiments have so far been 
> unsuccessful. 
>
> Any hints would be much appreciated,
>
> Thanks,
> Adam
>
> -- 


-- 
Toby Crawley
http://immutant.org | http://torquebox.org

-- 
-- 
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/groups/opt_out.

Re: reflection used for (or ...) and (into-array ...)

[AtKaaZ]

Thank you for the reply.

Does this *(int (or a 0)) *incur any runtime penalty when compared to ^int
(if that would be possible) ? (answer: insignificat)

Well I'll test:
=> *(def a 1)*
#'seesaw.layout/a
=> (time (dorun (doseq [x (take 1000 (range))]
 (java.awt.Color. 0 0 *(int a)* 0
"Elapsed time: 7352.883635 msecs"
nil
=> (time (dorun (doseq [x (take 1000 (range))]
 (java.awt.Color. 0 0 *(int a)* 0
"Elapsed time: 7374.908407 msecs"
nil
=> *(def ^Integer a 1)*
#'seesaw.layout/a
=> (time (dorun (doseq [x (take 1000 (range))]
 (java.awt.Color. 0 0* a* 0
"Elapsed time: 7361.800378 msecs"
nil
=> (time (dorun (doseq [x (take 1000 (range))]
 (java.awt.Color. 0 0 *a* 0
"Elapsed time: 7327.946211 msecs"
nil
=> (time (dorun (doseq [x (take 1000 (range))]
 (java.awt.Color. 0 0 *a* 0
"Elapsed time: 7346.675841 msecs"
nil

;ok again:)
=> *(def a 1)*
#'seesaw.layout/a
=> (time (dorun (doseq [x (take 1000 (range))]
 (java.awt.Color. 0 0* (int a)* 0
"Elapsed time: 7553.677781 msecs"
nil
=> (time (dorun (doseq [x (take 1000 (range))]
 (java.awt.Color. 0 0 *(int a)* 0
"Elapsed time: 7584.735069 msecs"
nil
=> (time (dorun (doseq [x (take 1000 (range))]
 (java.awt.Color. 0 0* (int a)* 0
"Elapsed time: 7500.791362 msecs"
nil
=>* (def ^Integer a 1)*
#'seesaw.layout/a
=> (time (dorun (doseq [x (take 1000 (range))]
 (java.awt.Color. 0 0* a* 0
"Elapsed time: 7483.519889 msecs"
nil
=> (time (dorun (doseq [x (take 1000 (range))]
 (java.awt.Color. 0 0* a* 0
"Elapsed time: 7514.795536 msecs"
nil
=> (time (dorun (doseq [x (take 1000 (range))]
 (java.awt.Color. 0 0 *a* 0
"Elapsed time: 7561.362051 msecs"
nil

So practically no difference, therefore the (int ...) thing is good, thank
you!

Let's see some reflection:

*(def a 1)*
=>* (time (dorun (doseq [x (take 100 (range))]
 (java.awt.Color. 0 0 (int (or a 0)) 0*
"Elapsed time: 783.968474 msecs"
nil
=> *(time (dorun (doseq [x (take 100 (range))]
 (java.awt.Color. 0 0 (int (or a 0)) 0*
"Elapsed time: 796.891853 msecs"
nil
=>* (time (dorun (doseq [x (take 100 (range))]
 (java.awt.Color. 0 0 (int (or a 0)) 0*
"Elapsed time: 778.344676 msecs"
nil
=> *(time (dorun (doseq [x (take 100 (range))]
 (java.awt.Color. 0 0 (or a 0) 0*
Reflection warning, NO_SOURCE_PATH:2 - call to java.awt.Color ctor can't be
resolved.
Reflection warning, NO_SOURCE_PATH:2 - call to java.awt.Color ctor can't be
resolved.
"Elapsed time: 8195.232631 msecs"
nil
=> *(time (dorun (doseq [x (take 100 (range))]
 (java.awt.Color. 0 0 (or a 0) 0*
Reflection warning, NO_SOURCE_PATH:2 - call to java.awt.Color ctor can't be
resolved.
Reflection warning, NO_SOURCE_PATH:2 - call to java.awt.Color ctor can't be
resolved.
"Elapsed time: 8557.929886 msecs"
nil

So like +-11 times faster.

the into-array part that you said works but that means I have to *add that
type hint on every call to into-array*, I was hoping maybe that could be
avoided by having into-array do that inside itself, something like
(float-array ...) does, but I guess calling *or *and *into-array *both are
doing the same thing in terms of what they can't do: have their return be
type hinted. I'm not sure if this could ever work since they don't always
return the same type, like *float-array* would do .


On Mon, Feb 18, 2013 at 7:42 PM, Andy Fingerhut wrote:

> Integer is a "boxed" integer in Java.  It is a full Java Object.  The
> java.awt.Color constructor you are calling takes 4 primitive int
> parameters, not Integer.  Try this:
>
> (set! *warn-on-reflection* true)
> (def a 1)
> (java.awt.Color. (int 0) (int 0) (int (or a 0)) (int 0))
>
>
> I'm not so sure what you are asking for with the into-array part of your
> questions.  The last into-array expression returns a Java array of
> java.awt.Color objects.  If you are trying to pass that to some other Java
> method and you are seeing reflection, and adding a type hint of
> ^"[Ljava.awt.Color;" doesn't work somewhere near there to avoid the
> reflection, it would be good to show a code snippet of what you are trying
> and getting reflection with.
>
> Andy
>
>
> On Feb 18, 2013, at 10:29 AM, AtKaaZ wrote:
>
> For *or*
> => *(set! *warn-on-reflection* true)
>(def ^Integer a 1)
>(java.awt.Color. 0 0 ^Integer (or ^Integer a 0) 0)
>*clojure-version**
> true
> #'cgws.notcore/a
> Reflection warning, NO_SOURCE_PATH:3:1 - call to java.awt.Color ctor can't
> be resolved.
> #
> {:major 1, :minor 5, :incremental 0, :qualifier "*RC16*"}
> => *(java.awt.Color. 0 0 ^Integer (or 0 ^Integer a) 0)*
> Reflection warning, NO_SOURCE_PATH:2:1 - call to java.awt.Color ctor can't
> be resolved.
> #
> =>* (java.awt.Color. 0 0 a 0)*
> #
>
>
> For *into-array*  I don't yet have a sample but what is wanted is this:
> *^{:tag "[Ljava.awt.Color;"} (into-array java.awt.Color (list
> (java.awt.Color. 0 0 0 0)))*
> but what we get is the returne

Re: reflection used for (or ...) and (into-array ...)

[Marko Topolnik]

A side note: dorun makes no sense around doseq since doseq returns nil and 
dorun operates on a lazy seq.

On Monday, February 18, 2013 8:16:16 PM UTC+1, AtKaaZ wrote:
>
> => (time (dorun (doseq [x (take 1000 (range))]
>  (java.awt.Color. 0 0 *(int a)* 0
> "Elapsed time: 7352.883635 msecs"
>

-- 
-- 
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/groups/opt_out.

Re: The case for as->> ("as-last")

[Marko Topolnik]

On Monday, February 18, 2013 5:40:51 PM UTC+1, vemv wrote:

>
> And neither can be solved by adding a lambda:
>
> (-> [[1 1 1] 2 3] (nth 0) #(map inc %)) ;; fail
>

Lambda does solve it, you are just missing the parens around the lambda:

(-> [[1 1 1] 2 3] (nth 0) (#(map inc %)))
 


> Clojure 1.5's as->, though, can come to the rescue.
>
> (-> [[1 1 1] 2 3] (nth 0) (as-> x (map inc x))) ;; cool
>
> Now, I only wish 1.5 came with as->> macro! Its implemetation is trivial 
> anyway.
>
> (->> [1 2 3] (as->> _ (nth _ 0)))
>
> Of course, for the given examples, using these "as" forms is overkill. But 
> if you've ever ended up writing large expressions (especially when 
> experimenting) which arbitrarily nest/interleave ->> and ->, using as-> and 
> as->> can provide a more sequential, structured alternative.
>
> Couldn't find any related discussion about the uses of as->, as its name 
> is unfriendly to Google/JIRA searches. Thoughts?
>

as-> is actually a generalization of both -> and ->>: you get to choose 
where to involve the previous result in each form. That is why as->> would 
be redundant.

-Marko

-- 
-- 
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/groups/opt_out.

Re: reflection used for (or ...) and (into-array ...)

[AtKaaZ]

awesome!  I wasn't thinking at all about that, I just remember something
returned lazyseq and I just had to make sure, but was too lazy to think
about it :)

Much appreciated! Thanks!


On Mon, Feb 18, 2013 at 8:36 PM, Marko Topolnik wrote:

> A side note: dorun makes no sense around doseq since doseq returns nil and
> dorun operates on a lazy seq.
>
>
> On Monday, February 18, 2013 8:16:16 PM UTC+1, AtKaaZ wrote:
>>
>> => (time (dorun (doseq [x (take 1000 (range))]
>>  (java.awt.Color. 0 0 *(int a)* 0
>> "Elapsed time: 7352.883635 msecs"
>>
>  --
> --
> 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/groups/opt_out.
>
>
>



-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate it.

-- 
-- 
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/groups/opt_out.

nrepl-ritz setup (missing dependency "dynapath")

[Dima B]

Hi,

I've been going through all the instruction on the nrepl-ritz page 
(https://github.com/pallet/ritz/tree/develop/nrepl) as well as nrepl-ritz 
threads and I can't seem to get it working due to a mysterious dependency 
problem on dynapath.

M-x nrepl-ritz-jack-in results in

Starting nREPL ritz server...
error in process sentinel: nrepl-server-sentinel: Could not start nREPL 
server: Exception in thread "main" java.io.FileNotFoundException: Could not 
locate dynapath/core__init.class or dynapath/core.clj on classpath: 
at clojure.lang.RT.load(RT.java:432)
at clojure.lang.RT.load(RT.java:400)
at clojure.core$load$fn__4890.invoke(core.clj:5415)
at clojure.core$load.doInvoke(core.clj:5414)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5227)
at clojure.core$load_lib.doInvoke(core.clj:5264)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:603)
at clojure.core$load_libs.doInvoke(core.clj:5298)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:603)
at clojure.core$require.doInvoke(core.clj:5381)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at 
ritz.repl_utils.class_browse$eval1633$loading__4784__auto1634.invoke(class_browse.clj:13)
at ritz.repl_utils.class_browse$eval1633.invoke(class_browse.clj:13)
...
at clojure.lang.Var.applyTo(Var.java:532)
at clojure.main.main(main.java:37)
Subprocess failed

Adding [org.tcrawley/dynapath "0.2.1"] explicitly into :dependencies list 
into ~/.lein/profiles.clj doesn't help.
nrepl-jack-in and "$ lein repl" works as expected.

Please help!

Thank you,
Dima

-- 
-- 
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/groups/opt_out.

Re: The case for as->> ("as-last")

[Víctor M . V .]

That extra parenses trick is neat, never thought of that!

As for as->> being redundant - it could be considered so indeed, given that
as-> can be lambified: (->> [] (#(as-> % x (map inc x - but that's
pretty damn ugly haha. If you were thinking something else, please let me
know.

Thanks - Victor

On Mon, Feb 18, 2013 at 8:44 PM, Marko Topolnik wrote:

> On Monday, February 18, 2013 5:40:51 PM UTC+1, vemv wrote:
>
>>
>> And neither can be solved by adding a lambda:
>>
>> (-> [[1 1 1] 2 3] (nth 0) #(map inc %)) ;; fail
>>
>
> Lambda does solve it, you are just missing the parens around the lambda:
>
> (-> [[1 1 1] 2 3] (nth 0) (#(map inc %)))
>
>
>
>> Clojure 1.5's as->, though, can come to the rescue.
>>
>> (-> [[1 1 1] 2 3] (nth 0) (as-> x (map inc x))) ;; cool
>>
>> Now, I only wish 1.5 came with as->> macro! Its implemetation is trivial
>> anyway.
>>
>> (->> [1 2 3] (as->> _ (nth _ 0)))
>>
>> Of course, for the given examples, using these "as" forms is overkill.
>> But if you've ever ended up writing large expressions (especially when
>> experimenting) which arbitrarily nest/interleave ->> and ->, using as-> and
>> as->> can provide a more sequential, structured alternative.
>>
>> Couldn't find any related discussion about the uses of as->, as its name
>> is unfriendly to Google/JIRA searches. Thoughts?
>>
>
> as-> is actually a generalization of both -> and ->>: you get to choose
> where to involve the previous result in each form. That is why as->> would
> be redundant.
>
> -Marko
>
>  --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: The case for as->> ("as-last")

[Marko Topolnik]

as-> is meant to be used as the only threading form. In your example you'd 
want to replace the initial ->> with as->.

On Monday, February 18, 2013 9:04:55 PM UTC+1, vemv wrote:
>
> That extra parenses trick is neat, never thought of that!
>
> As for as->> being redundant - it could be considered so indeed, given 
> that as-> can be lambified: (->> [] (#(as-> % x (map inc x - but 
> that's pretty damn ugly haha. If you were thinking something else, please 
> let me know.
>
> Thanks - Victor
>
> On Mon, Feb 18, 2013 at 8:44 PM, Marko Topolnik 
> 
> > wrote:
>
>> On Monday, February 18, 2013 5:40:51 PM UTC+1, vemv wrote:
>>
>>>
>>> And neither can be solved by adding a lambda:
>>>
>>> (-> [[1 1 1] 2 3] (nth 0) #(map inc %)) ;; fail
>>>
>>
>> Lambda does solve it, you are just missing the parens around the lambda:
>>
>> (-> [[1 1 1] 2 3] (nth 0) (#(map inc %)))
>>  
>>
>>
>>> Clojure 1.5's as->, though, can come to the rescue.
>>>
>>> (-> [[1 1 1] 2 3] (nth 0) (as-> x (map inc x))) ;; cool
>>>
>>> Now, I only wish 1.5 came with as->> macro! Its implemetation is 
>>> trivial anyway.
>>>
>>> (->> [1 2 3] (as->> _ (nth _ 0)))
>>>
>>> Of course, for the given examples, using these "as" forms is overkill. 
>>> But if you've ever ended up writing large expressions (especially when 
>>> experimenting) which arbitrarily nest/interleave ->> and ->, using as-> and 
>>> as->> can provide a more sequential, structured alternative.
>>>
>>> Couldn't find any related discussion about the uses of as->, as its name 
>>> is unfriendly to Google/JIRA searches. Thoughts?
>>>
>>
>> as-> is actually a generalization of both -> and ->>: you get to choose 
>> where to involve the previous result in each form. That is why as->> would 
>> be redundant.
>>
>> -Marko
>>
>>  -- 
>> -- 
>> 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/groups/opt_out.
>>  
>>  
>>
>
>

-- 
-- 
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/groups/opt_out.

Re: The case for as->> ("as-last")

[Víctor M . V .]

Fair enough. Now I'm beggining to truly appreciate as->, thank you. I still
believe as->> would be somewhat useful but I don't see it getting added to
clojure.core now.

On Mon, Feb 18, 2013 at 9:10 PM, Marko Topolnik wrote:

> as-> is meant to be used as the only threading form. In your example you'd
> want to replace the initial ->> with as->.
>
>
> On Monday, February 18, 2013 9:04:55 PM UTC+1, vemv wrote:
>
>> That extra parenses trick is neat, never thought of that!
>>
>> As for as->> being redundant - it could be considered so indeed, given
>> that as-> can be lambified: (->> [] (#(as-> % x (map inc x - but
>> that's pretty damn ugly haha. If you were thinking something else, please
>> let me know.
>>
>> Thanks - Victor
>>
>> On Mon, Feb 18, 2013 at 8:44 PM, Marko Topolnik wrote:
>>
>>> On Monday, February 18, 2013 5:40:51 PM UTC+1, vemv wrote:
>>>

 And neither can be solved by adding a lambda:

 (-> [[1 1 1] 2 3] (nth 0) #(map inc %)) ;; fail

>>>
>>> Lambda does solve it, you are just missing the parens around the lambda:
>>>
>>> (-> [[1 1 1] 2 3] (nth 0) (#(map inc %)))
>>>
>>>
>>>
 Clojure 1.5's as->, though, can come to the rescue.

 (-> [[1 1 1] 2 3] (nth 0) (as-> x (map inc x))) ;; cool

 Now, I only wish 1.5 came with as->> macro! Its implemetation is
 trivial anyway.

 (->> [1 2 3] (as->> _ (nth _ 0)))

 Of course, for the given examples, using these "as" forms is overkill.
 But if you've ever ended up writing large expressions (especially when
 experimenting) which arbitrarily nest/interleave ->> and ->, using as-> and
 as->> can provide a more sequential, structured alternative.

 Couldn't find any related discussion about the uses of as->, as its
 name is unfriendly to Google/JIRA searches. Thoughts?

>>>
>>> as-> is actually a generalization of both -> and ->>: you get to choose
>>> where to involve the previous result in each form. That is why as->> would
>>> be redundant.
>>>
>>> -Marko
>>>
>>>  --
>>> --
>>> 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/**groups/opt_out
>>> .
>>>
>>>
>>>
>>
>>  --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: nrepl-ritz setup (missing dependency "dynapath")

[Hugo Duncan]

Dima B  writes:

> I've been going through all the instruction on the nrepl-ritz page 
> (https://github.com/pallet/ritz/tree/develop/nrepl) as well as nrepl-ritz 
> threads and I can't seem to get it working due to a mysterious dependency 
> problem on dynapath.

Which version of ritz?

> Adding [org.tcrawley/dynapath "0.2.1"] explicitly into :dependencies list 
> into ~/.lein/profiles.clj doesn't help.

The dependency is [dynapath "0.1.0"], which is on clojars.

Hugo

-- 
-- 
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/groups/opt_out.

Re: STM in Clojure vs Haskell, why no retry or orElse?

[Tom Hall]

>> Why does Clojure not need retry or orElse when another implementer of
>> STM considers them essential?
> What are retry and orElse? What do they do?

I had hoped to get a reply from someone with experience of both, as
the quote suggests they are for blocking and choice (The article was
the first time I'd seen STM so am absolutely not an expert)

>From the Haskell docs:
retry :: STM a
Retry execution of the current memory transaction because it has seen
values in TVars which mean that it should not continue (e.g. the TVars
represent a shared buffer that is now empty). The implementation may
block the thread until one of the TVars that it has read from has been
udpated. (GHC only)
(this is what made me think of watchers in clojure,
http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/add-watch)

orElse :: STM a -> STM a -> STM a
Compose two alternative STM actions (GHC only). If the first action
completes without retrying then it forms the result of the orElse.
Otherwise, if the first action retries, then the second action is
tried in its place. If both actions retry then the orElse as a whole
retries.

> "Santa repeatedly sleeps until wakened by either all of his nine
> reindeer, back from their holidays, or by a group of three of his ten
> elves. If awakened by the reindeer, he harnesses each of them to his
> sleigh, delivers toys with them and finally unharnesses them (allowing
> them to go off on holiday). If awakened by a group of elves, he shows
> each of the group into his study, consults with them on toy R&D and
> finally shows them each out (allowing them to go back to work). Santa
> should give priority to the reindeer in the case that there is both a
> group of elves and a group of reindeer waiting."

I think it's a shame he wrote the article around Christmas and chose a
less well known problem, I have looked at several Clojure Barbershop
Problem solutions so have a better idea now what an idiomatic solution
to this sort of problem might be.

Cheers Phil,
Tom

-- 
-- 
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/groups/opt_out.

ANN Gavagai 0.3.1 released

[Nils Grunwald]

Gavagai is a library dedicated to facilitating the creation of Clojure 
wrapper around Java libraries. It enables a simple, declarative way to 
automatically convert recursive graphs of Java objects to Clojure immutable 
and lazy data structures.
You can find out more about this project motivations (and name!) in this 
blog post (http://theblankscreen.net/blog/2013/02/18/introducing-gavagai/) 
and more details on usage in the README of the project repo (
https://github.com/ngrunwald/gavagai). The tests are also a useful source 
of info.

Also, you can have a look at https://github.com/ngrunwald/clj-rome. It is 
an idiomatic Clojure wrapper for the Java RSS parser 
ROME and 
though ROME uses a very Java centric approach, clj-rome is only 60 lines 
long thanks to Gavagai. This code is a good exemple of real production 
usage of gavagai.

Patches and comments welcome

Nils Grunwald

-- 
-- 
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/groups/opt_out.

Re: nrepl-ritz setup (missing dependency "dynapath")

[Toby Crawley]

Dima B writes:

> Hi,
>
> I've been going through all the instruction on the nrepl-ritz page 
> (https://github.com/pallet/ritz/tree/develop/nrepl) as well as nrepl-ritz 
> threads and I can't seem to get it working due to a mysterious dependency 
> problem on dynapath.
...
> error in process sentinel: nrepl-server-sentinel: Could not start nREPL 
> server: Exception in thread "main" java.io.FileNotFoundException: Could not 
> locate dynapath/core__init.class or dynapath/core.clj on classpath: 

This is caused by something else bringing in dynapath 0.2.1, which is
overriding the 0.1.0 version that ritz expects. 0.2.1 no longer has a
core ns, which is causing the above error.

Unfortunately, I didn't consider this issue when I removed the core ns
between 0.1.0 and 0.2.0, which I now regret.

There are a couple of options here, both of which probably require
action by me: 

* I can release a new version that is compatible with 0.1.0 and 0.2.x,
  requiring you do depend on it (and possibly exclude other versions)
* I can update ritz to use 0.2.1, and Hugo can make a new release (if he
  is amenable to that). As far as I know, ritz is the only project that
  depends on 0.1.0.

I'd prefer to do the latter, because that would be the proper fix, but
don't want to burden Hugo.

-- 
Toby Crawley
http://immutant.org | http://torquebox.org

-- 
-- 
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/groups/opt_out.

Re: nrepl-ritz setup (missing dependency "dynapath")

[Hugo Duncan]

Toby Crawley  writes:

> * I can release a new version that is compatible with 0.1.0 and 0.2.x,
>   requiring you do depend on it (and possibly exclude other versions)
> * I can update ritz to use 0.2.1, and Hugo can make a new release (if he
>   is amenable to that). As far as I know, ritz is the only project that
>   depends on 0.1.0.
>
> I'd prefer to do the latter, because that would be the proper fix, but
> don't want to burden Hugo.

Thanks for finding the cause.

The latter is fine by me.  It is about time we had another ritz release for
nrepl.el 1.6 anyway.

Hugo

-- 
-- 
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/groups/opt_out.

Re: nrepl-ritz setup (missing dependency "dynapath")

[Toby Crawley]

Hugo Duncan writes:
>
> The latter is fine by me.  It is about time we had another ritz release for
> nrepl.el 1.6 anyway.

I'll send you a PR in a few minutes.

-- 
Toby Crawley
http://immutant.org | http://torquebox.org

-- 
-- 
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/groups/opt_out.

Re: nrepl-ritz setup (missing dependency "dynapath")

[Dima B]

> Which version of ritz?

Ritz is "0.6.0", emacs plug-in is also 0.6.0. Clojure 1.4.0. Lein 2.0.
I believe the midje plugin does have a dependency on dynapath 2.x that 
explains the mystery.

Thank you for looking into this!


On Monday, February 18, 2013 12:36:20 PM UTC-8, Hugo Duncan wrote:
>
> Dima B > writes: 
>
> > I've been going through all the instruction on the nrepl-ritz page 
> > (https://github.com/pallet/ritz/tree/develop/nrepl) as well as 
> nrepl-ritz 
> > threads and I can't seem to get it working due to a mysterious 
> dependency 
> > problem on dynapath. 
>
> Which version of ritz? 
>
> > Adding [org.tcrawley/dynapath "0.2.1"] explicitly into :dependencies 
> list 
> > into ~/.lein/profiles.clj doesn't help. 
>
> The dependency is [dynapath "0.1.0"], which is on clojars. 
>
> Hugo 
>

-- 
-- 
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/groups/opt_out.

Re: nrepl-ritz setup (missing dependency "dynapath")

[Hugo Duncan]

Toby Crawley  writes:

> Hugo Duncan writes:
>>
>> The latter is fine by me.  It is about time we had another ritz release for
>> nrepl.el 1.6 anyway.
>
> I'll send you a PR in a few minutes.

Thanks.

Released in ritz 0.7.0

-- 
-- 
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/groups/opt_out.

Re: nrepl-ritz setup (missing dependency "dynapath")

[Dima B]

I confirm that the issue is fixed. Thank you, guys!


On Monday, February 18, 2013 3:39:37 PM UTC-8, Hugo Duncan wrote:
>
> Toby Crawley > writes: 
>
> > Hugo Duncan writes: 
> >> 
> >> The latter is fine by me.  It is about time we had another ritz release 
> for 
> >> nrepl.el 1.6 anyway. 
> > 
> > I'll send you a PR in a few minutes. 
>
> Thanks. 
>
> Released in ritz 0.7.0 
>

-- 
-- 
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/groups/opt_out.

Re: alternative to passing parameters to functions

[AtKaaZ]

Thanks guys, I think I will go with this variant that vemv suggested and
upon further exploring I realized it can do much more (still exploring
currently):

*(defn somefn
  [req1 req2 **;required params *
   *& {:keys [a b c d e]** ;optional params*
  *:or {a 1** ;optional params with preset default values other than
the nil default*
*  ; b takes nil if not specified on call*
  *  c 3** ; c is 3 when not specified on call*
*d 0* *; d is 0 --//--*
  *; e takes nil if not specified on call*
  * }
  :as mapOfParamsSpecifiedOnCall }]
  (println req1 req2 mapOfParamsSpecifiedOnCall a b c d e)
  )*

*=>* *(somefn 9 10 :b 2 :d 4)*
9 10 {:b 2, :d 4} 1 2 3 4 nil
nil
*=>* *(somefn)*
ArityException Wrong number of args (0) passed to: funxions$somefn
clojure.lang.AFn.throwArity (AFn.java:437)
*=>* *(somefn 9 10)*
9 10 nil 1 nil 3 0 nil
nil
=>* (somefn 9 10 :x 123)*
9 10 {:x 123} 1 nil 3 0 nil
nil
=> *(somefn 9 10 123)*
IllegalArgumentException No value supplied for key: 123
clojure.lang.PersistentHashMap.create (PersistentHashMap.java:77)
=>* (somefn 9 10 123 45)*
9 10 {123 45} 1 nil 3 0 nil
nil



On Sun, Feb 17, 2013 at 10:12 PM, vemv  wrote:

> fn's "keyword arguments" feature provide unrolled, optional key-value args:
>
> (defn foo [& {:keys [a b c]}]
>   [a b c])
>
> (foo :c 4) ;; [nil nil 4]
>
>
> On Sunday, February 17, 2013 10:06:13 PM UTC+1, AtKaaZ wrote:
>>
>> Was there a library or some other way to pass ie. maps to functions
>> so that the order of the params isn't predefined, just in case I want to
>> skip some passing parameters without actually having to pass some value for
>> them, I could just refer to which params I'm passing by identifying them
>> with a :key  ?
>>
>> It's probably not hard at all to implement, but if there's a lib already,
>> it would do a better job that I could.
>>
>> --
>> Please correct me if I'm wrong or incomplete,
>> even if you think I'll subconsciously hate it.
>>
>>   --
> --
> 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/groups/opt_out.
>
>
>



-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate it.

-- 
-- 
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/groups/opt_out.

Clojure Performance For Expensive Algorithms

[Geo]

Hello,

I am cross-posting my Clojure question from StackOverflow.  I am trying to 
get an algorithm in Clojure to match Java speed and managed to get the 
performance to within one order of magnitude and wondering if more is 
possible. The full question is here:

http://stackoverflow.com/questions/14949705/clojure-performance-for-expensive-algorithms

Thank you.

-- 
-- 
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/groups/opt_out.

Re: RC 16: Last chance to test against Clojure 1.5 before it ships

[Tim McCormack]

On Wednesday, February 13, 2013 10:33:42 PM UTC-5, Stuart Halloway wrote:
>
> If you care about Clojure 1.5 compatibility for your codebase, please test 
> it against RC 16 as soon as possible.
>

(I mistakenly posted this already to the *read-eval* thread, but it really 
belongs here... apologies for the double-post.)

The command-line eval feature is broken under -Dclojure.read.eval=unknown 
in beta13 and RC16 (not sure which is newer):

$ java -Dclojure.read.eval=unknown -jar 
~/.m2/repository/org/clojure/clojure/1.5.0-RC16/clojure-1.5.0-RC16.jar -e 
"(+ 1 2)"
Exception in thread "main" java.lang.RuntimeException: Reading disallowed - 
*read-eval* bound to :unknown

 - timmc
 
 

-- 
-- 
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/groups/opt_out.

ANN LispCast Videos

[Eric Normand]

Hi,

I thought this might interest Clojure programmers. I have a Kickstarter 
project to create screencasts to introduce people to Clojure. The project 
so far is doing well, but there is still a ways to go. One hour of video is 
set at a very good price ($5). If it does well, I hope to create more.

If you think it could be useful to you or someone you know, please check it 
out.

http://www.kickstarter.com/projects/376627045/lispcast-introduction-to-clojure-videos

Thanks!
Eric

-- 
-- 
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/groups/opt_out.

Re: Clojure Performance For Expensive Algorithms

[Andy Fingerhut]

This won't get you all of the way to Java speeds, or at least it didn't for me, 
but try these things:

Use:

(set! *warn-on-reflection* true)
(set! *unchecked-math* true)

The first won't speed anything up, but it will warn you about some things that 
are slow.

The second will use unchecked match wherever it can, meaning primitive 
operations on arithmetic values like longs, that will silently wrap instead of 
checking for overflow.  Java doesn't check for overflow in primitive 
operations, either.

Also use aset instead of aset-int.  I don't know why, but the aset-* operations 
are typically slower than aset, as long as the type hints on the aset arguments 
are good enough.

I got within 4x Java speed with those changes.

Andy


On Feb 18, 2013, at 8:16 PM, Geo wrote:

> Hello,
> 
> I am cross-posting my Clojure question from StackOverflow.  I am trying to 
> get an algorithm in Clojure to match Java speed and managed to get the 
> performance to within one order of magnitude and wondering if more is 
> possible. The full question is here:
> 
> http://stackoverflow.com/questions/14949705/clojure-performance-for-expensive-algorithms
> 
> Thank you.

-- 
-- 
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/groups/opt_out.