Re: Get Lein to run 32-bit JVM on Windows

[Niels van Klaveren]

If system/getProperty "os.arch" says it's 64 bits, it means the processor 
is a 64 bits compatible processor, not that the Java process is 64 or 32 
bits.
If you want to see what the JVM data model is you need to use 
(System/getPropery  "sun.arch.data.model") and see what it returns (either 
"32" or "64").

On Tuesday, July 5, 2016 at 9:17:02 PM UTC+2, JvJ wrote:
>
> I think when I wrote LEIN_CMD, I meant LEIN_JAVA_CMD.  I've already set it 
> to the x86 JVM path, with no luck so far.
>
> (System/getProperty "os.arch") still returns "amd64", and overtone still 
> doesn't work right.
>
> On Tuesday, 5 July 2016 02:02:53 UTC-7, David Powell wrote:
>>
>> I think you need to set LEIN_JAVA_CMD to affect the jvm actually used to 
>> start leiningen itself.
>>
>> On Tue, Jul 5, 2016 at 9:35 AM, JvJ  wrote:
>>
>>> Is it possible to configure Leiningen to run a 32-bit JVM by default?  
>>> I've already tried changing the LEIN_CMD and JAVA_HOME to the x86 
>>> executable paths, but it still runs the amd64 JVM.
>>>
>>> Any tips?  I'm doing this for overtone, since it doesn't support amd64 
>>> on Windows.
>>>
>>> --
>>> 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.
>>>
>>
>>

-- 
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] Clojure 1.9.0-alpha9

[Leon Grapenthin]

Small bug report

Throwable->map in core_print.clj doesn't handle Throwable.getCause 
returning null in L463. This results in a NPE in StrackTraceElement->vec in 
the same file in some cases, so printing a stacktrace results in a new 
Exception which is a bit confusing.

On Tuesday, July 5, 2016 at 9:50:47 PM UTC+2, Alex Miller wrote:
>
> Clojure 1.9.0-alpha9 is now available.
>
> Try it via
>
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha9
> - Leiningen: [org.clojure/clojure "1.9.0-alpha9"]
>
> 1.9.0-alpha9 includes the following changes since 1.9.0-alpha8:
>
> - NEW clojure.spec/assert - a facility for adding spec assertions to your 
> code. See the docs for *compile-asserts* 
> 
>  
> and assert 
> 
>  
> for more details.
>
> - clojure.spec/merge - now merges rather than flows in conform/unform
>
> - clojure.spec.test/instrument now reports the caller that caused an :args 
> spec failure and ignores spec'ed macros
>
> - clojure.spec.test - `test`, `test-fn`, `testable-syms` renamed to 
> `check`, `check-fn`, and `checkable-syms` to better reflect their purpose. 
> Additionally, some of the return value structure of `check` has been 
> further improved.
>
> - clojure.core/Throwable->map formerly returned StackTraceElements which 
> were later handled by the printer. Now the StackTraceElements are converted 
> to data such that the return value is pure Clojure data, as intended.
>
>
>
>
>

-- 
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] Clojure 1.9.0-alpha9

[Leon Grapenthin]

Another small bug report:

(let [{:keys [a/b] :or {a/b 42}} {}]
  b)

Evaluates to nil, but should evaluate to 42

(let [{:keys [a/b] :or {b 42}} {}]
   b)

Evaluates to 42, but should evaluate to nil.



On Tuesday, July 5, 2016 at 9:50:47 PM UTC+2, Alex Miller wrote:
>
> Clojure 1.9.0-alpha9 is now available.
>
> Try it via
>
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha9
> - Leiningen: [org.clojure/clojure "1.9.0-alpha9"]
>
> 1.9.0-alpha9 includes the following changes since 1.9.0-alpha8:
>
> - NEW clojure.spec/assert - a facility for adding spec assertions to your 
> code. See the docs for *compile-asserts* 
> 
>  
> and assert 
> 
>  
> for more details.
>
> - clojure.spec/merge - now merges rather than flows in conform/unform
>
> - clojure.spec.test/instrument now reports the caller that caused an :args 
> spec failure and ignores spec'ed macros
>
> - clojure.spec.test - `test`, `test-fn`, `testable-syms` renamed to 
> `check`, `check-fn`, and `checkable-syms` to better reflect their purpose. 
> Additionally, some of the return value structure of `check` has been 
> further improved.
>
> - clojure.core/Throwable->map formerly returned StackTraceElements which 
> were later handled by the printer. Now the StackTraceElements are converted 
> to data such that the return value is pure Clojure data, as intended.
>
>
>
>
>

-- 
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] Clojure 1.9.0-alpha9

[Alex Miller]

This is the correct behavior. The :or map keys are always the local names being 
bound (not the keys being looked up in the map).

> On Jul 6, 2016, at 4:40 AM, Leon Grapenthin  wrote:
> 
> Another small bug report:
> 
> (let [{:keys [a/b] :or {a/b 42}} {}]
>   b)
> 
> Evaluates to nil, but should evaluate to 42
> 
> (let [{:keys [a/b] :or {b 42}} {}]
>b)
> 
> Evaluates to 42, but should evaluate to nil.

-- 
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] Clojure 1.9.0-alpha9

[Alex Miller]

Thanks! If I could trouble you to make a jira for that, would love to get it 
fixed.

> On Jul 6, 2016, at 4:09 AM, Leon Grapenthin  wrote:
> 
> Small bug report
> 
> Throwable->map in core_print.clj doesn't handle Throwable.getCause returning 
> null in L463. This results in a NPE in StrackTraceElement->vec in the same 
> file in some cases, so printing a stacktrace results in a new Exception which 
> is a bit confusing.
> 

-- 
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] Clojure 1.9.0-alpha9

[Leon Grapenthin]

@Alex Miller: Please reconsider. What you state does not apply to 1.8, i. 
e. the ns is required in :or and such code is broken in 1.9

1.8/1.9 differences:
(let [{:keys [a/b] :or {b 42}} {}] 
  b)
=>
1.8: nil
1.9: 42(let [{:keys [a/b] :or {a/b 42}} {}] 
  b)
=>
1.8: 42
1.9: nil




On Wednesday, July 6, 2016 at 1:43:46 PM UTC+2, Alex Miller wrote:
>
> This is the correct behavior. The :or map keys are always the local names 
> being bound (not the keys being looked up in the map). 
>
> > On Jul 6, 2016, at 4:40 AM, Leon Grapenthin  > wrote: 
> > 
> > Another small bug report: 
> > 
> > (let [{:keys [a/b] :or {a/b 42}} {}] 
> >   b) 
> > 
> > Evaluates to nil, but should evaluate to 42 
> > 
> > (let [{:keys [a/b] :or {b 42}} {}] 
> >b) 
> > 
> > Evaluates to 42, but should evaluate to nil. 
>

-- 
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] Clojure 1.9.0-alpha9

[Nicola Mometto]

I'd say that's a bug with 1.8 rather than 1.9

> On 6 Jul 2016, at 13:01, Leon Grapenthin  wrote:
> 
> @Alex Miller: Please reconsider. What you state does not apply to 1.8, i. e. 
> the ns is required in :or and such code is broken in 1.9
> 
> 1.8/1.9 differences:
> (let [{:keys [a/b] :or {b 42}} {}]
>   b)
> =>
> 1.8: nil
> 1.9: 42(let [{:keys [a/b] :or {a/b 42}} {}]
>   b)
> =>
> 1.8: 42
> 1.9: nil
> 
> 
> 
> 
> On Wednesday, July 6, 2016 at 1:43:46 PM UTC+2, Alex Miller wrote:
> This is the correct behavior. The :or map keys are always the local names 
> being bound (not the keys being looked up in the map).
> 
> > On Jul 6, 2016, at 4:40 AM, Leon Grapenthin  wrote:
> >
> > Another small bug report:
> >
> > (let [{:keys [a/b] :or {a/b 42}} {}]
> >   b)
> >
> > Evaluates to nil, but should evaluate to 42
> >
> > (let [{:keys [a/b] :or {b 42}} {}]
> >b)
> >
> > Evaluates to 42, but should evaluate to nil.
> 
> --
> 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.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [ANN] Clojure 1.9.0-alpha9

[Alex Miller]

This *is* different than 1.8 (and prior) because it has been buggy since 
namespaced keys were added (due to a lack of tests - entirely my fault). 
Nothing was ever documented about this behavior - it was purely accidental and 
I would consider it in the realm of "unspecified".

In 1.9 I added additional tests and tightened up this code in the process of 
adding the namespaced key support. 

-- 
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] Clojure 1.9.0-alpha9

[Leon Grapenthin]

1.9 could still support the behavior that worked in 1.8 and in CLJS, too, 
or throw a compile time Exception. 

If we had known this change in behavior, fixing it in the codebase wouldn't 
have been much trouble. But a missing default can lead to errors far away 
so it takes time to get to the ground of this.

If there was no (working) other way to provide a default for namespaced 
keys in 1.8 I believe that many people will have tried adding the ns and 
ran with it.


On Wednesday, July 6, 2016 at 2:17:14 PM UTC+2, Alex Miller wrote:
>
> This *is* different than 1.8 (and prior) because it has been buggy since 
> namespaced keys were added (due to a lack of tests - entirely my fault). 
> Nothing was ever documented about this behavior - it was purely accidental 
> and I would consider it in the realm of "unspecified".
>
> In 1.9 I added additional tests and tightened up this code in the process 
> of adding the namespaced key support. 
>

-- 
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] Clojure 1.9.0-alpha9

[Alex Miller]

There will soon be a spec for let that will fail in this circumstance, 
letting you know.

On Wednesday, July 6, 2016 at 7:42:22 AM UTC-5, Leon Grapenthin wrote:
>
> 1.9 could still support the behavior that worked in 1.8 and in CLJS, too, 
> or throw a compile time Exception. 
>
> If we had known this change in behavior, fixing it in the codebase 
> wouldn't have been much trouble. But a missing default can lead to errors 
> far away so it takes time to get to the ground of this.
>
> If there was no (working) other way to provide a default for namespaced 
> keys in 1.8 I believe that many people will have tried adding the ns and 
> ran with it.
>
>
> On Wednesday, July 6, 2016 at 2:17:14 PM UTC+2, Alex Miller wrote:
>>
>> This *is* different than 1.8 (and prior) because it has been buggy since 
>> namespaced keys were added (due to a lack of tests - entirely my fault). 
>> Nothing was ever documented about this behavior - it was purely accidental 
>> and I would consider it in the realm of "unspecified".
>>
>> In 1.9 I added additional tests and tightened up this code in the process 
>> of adding the namespaced key support. 
>>
>

-- 
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] akar 0.1.0

[Nahuel Greco]

Hi Rahul, Akar seems very nice! It works in Clojurescript?

Saludos,
Nahuel Greco.

On Tue, Jul 5, 2016 at 11:38 AM, Rahul Goma Phulore <
rahul.phulore@gmail.com> wrote:

> Hi, all.
>
> I am quite excited to announce my project Akar –
> https://github.com/missingfaktor/akar. It's a pattern matching library
> for Clojure, wherein the patterns are first class values (just functions,
> actually). Akar patterns can be manipulated, composed, abstracted over,
> like any other functions. In fact, this is exactly how various pattern
> operations, such as guards, alternation, and views are implemented in Akar.
> The library also features a syntactic layer that makes common use cases
> convenient, but at the same time stays true to the first-class spirit of
> the core model.
>
> The library comes with a full-blown *tutorial*
>  and also
> covers some FAQs
> .
>
> I made the first release - 0.1.0 - today.
>
> I hope you guys like it, and find it useful! Feedback, constructive
> criticism, PRs are most welcome.
>
> Best,
> Rahul
>
> --
> 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: Get Lein to run 32-bit JVM on Windows

[JvJ]

My solution was to dual-boot linux.  I think it's about time anyway.

On Tuesday, 5 July 2016 12:17:02 UTC-7, JvJ wrote:
>
> I think when I wrote LEIN_CMD, I meant LEIN_JAVA_CMD.  I've already set it 
> to the x86 JVM path, with no luck so far.
>
> (System/getProperty "os.arch") still returns "amd64", and overtone still 
> doesn't work right.
>
> On Tuesday, 5 July 2016 02:02:53 UTC-7, David Powell wrote:
>>
>> I think you need to set LEIN_JAVA_CMD to affect the jvm actually used to 
>> start leiningen itself.
>>
>> On Tue, Jul 5, 2016 at 9:35 AM, JvJ  wrote:
>>
>>> Is it possible to configure Leiningen to run a 32-bit JVM by default?  
>>> I've already tried changing the LEIN_CMD and JAVA_HOME to the x86 
>>> executable paths, but it still runs the amd64 JVM.
>>>
>>> Any tips?  I'm doing this for overtone, since it doesn't support amd64 
>>> on Windows.
>>>
>>> --
>>> 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.
>>>
>>
>>

-- 
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.

Can't extract multipart-params from POST request in compojure

[aaarturozhao]

When I try to extract the multipart-params from a POST request like this:

(defroutes upload-routes
  (POST "/upload" {params :params} (println params))


I got {}.

Then I tried like this:

(defroutes upload-routes
  (POST "/upload" {multipart-params :multipart-params} (println 
multipart-params))

I still got {}.

I guess there are something wrong about my middleware.

So I tried to change the handler, here are the handlers I had tried:

(ns cloudserver.handler
  (:require [compojure.core :refer [defroutes routes]]
[compojure.route :as route]
[compojure.handler :as handler]
[cloudserver.routes.home :refer [home-routes]]
[noir.util.middleware :as noir-middleware]
[cloudserver.routes.auth :refer [auth-routes]]
[cloudserver.routes.upload :refer [upload-routes]]
[cloudserver.routes.search :refer [search-routes]]
[cloudserver.routes.download :refer [download-routes]]
[ring.middleware.defaults :refer [api-defaults wrap-defaults 
site-defaults]]
[ring.middleware.multipart-params :refer [wrap-multipart-params]]
[ring.middleware.params :refer [wrap-params]]
[noir.session :as session]
[ring.middleware.session.memory :refer [memory-store]]))

(def app
  (->
   (routes auth-routes
   home-routes
   upload-routes
   search-routes
   download-routes
   app-routes)
   session/wrap-noir-session
   (wrap-defaults（assoc-in site-defaults [:security :anti-forgery] false)
   wrap-multipart-params
   wrap-params))
(def app
  (->
   (routes auth-routes
   home-routes
   upload-routes
   search-routes
   download-routes
   app-routes)
   session/wrap-noir-session
   (wrap-defaults（assoc-in site-defaults [:security :anti-forgery] false)
   wrap-multipart-params))
(def app
  (->
   (routes auth-routes
   home-routes
   upload-routes
   search-routes
   download-routes
   app-routes)
   session/wrap-noir-session
   (wrap-defaults (-> site-defaults
  (assoc-in [:security :anti-forgery] false)
  (assoc-in [:params :multipart] true)
  (assoc-in [:params :nested] true)))
   handler/site))
(def app
  (->
   (routes auth-routes
   home-routes
   upload-routes
   search-routes
   download-routes
   app-routes)
   wrap-multipart-params
   session/wrap-noir-session
   (wrap-defaults（assoc-in site-defaults [:security :anti-forgery] false)))
(def app
  (noir-middleware/app-handler
   [auth-routes
home-routes
upload-routes
search-routes
download-routes
app-routes]
   :ring-defaults (assoc site-defaults :security nil)))

But the only result I got is {}
--

My client code is:

public int upload (String filename, String[] tags, String time, String 
fingerprint) throws IOException {
String url = host + "/upload";
CloseableHttpClient httpClient = 
HttpClients.custom().setDefaultCookieStore(cookieStore).build(); 
HttpPost httpPost =  new HttpPost(url);

MultipartEntityBuilder mulentity = MultipartEntityBuilder.create();

mulentity.addBinaryBody("photo", new File(filename));

for (int i = 0; i < tags.length; i ++) {
mulentity.addTextBody("tag" + i, tags[i]);
}

mulentity.addTextBody("fingerprint", fingerprint);
mulentity.addTextBody("time", time);
mulentity.addTextBody("filename", 
filename.substring(filename.lastIndexOf(File.separatorChar) + 1, 
filename.length()));

HttpEntity entity = mulentity.build();
httpPost.setEntity(entity);
httpPost.setHeader("Content-Type", "multipart/form-data;boundary=" + 
BOUNDARY);

int status = 3;

try {
ResponseHandler responseHandler = new BasicResponseHandler();
String response = httpClient.execute(httpPost, responseHandler);
status = Integer.parseInt(response);
} catch (ClientProtocolException e) {
e.printStackTrace();
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
} finally {
httpClient.close();
}
return status;
}

--

I am really a green hand in clojure web programming. Thanks a lot!

-- 
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 opti

Re: Can't extract multipart-params from POST request in compojure

[aaarturozhao]

This is the link to the question in stackoverflow:
http://stackoverflow.com/questions/38226276/cant-extract-multipart-params-from-post-request-in-compojure

在 2016年7月7日星期四 UTC+8上午10:13:25，aaartu...@gmail.com写道：
>
> When I try to extract the multipart-params from a POST request like this:
>
> (defroutes upload-routes
>   (POST "/upload" {params :params} (println params))
>
>
> I got {}.
>
> Then I tried like this:
>
> (defroutes upload-routes
>   (POST "/upload" {multipart-params :multipart-params} (println 
> multipart-params))
>
> I still got {}.
>
> I guess there are something wrong about my middleware.
>
> So I tried to change the handler, here are the handlers I had tried:
>
> (ns cloudserver.handler
>   (:require [compojure.core :refer [defroutes routes]]
> [compojure.route :as route]
> [compojure.handler :as handler]
> [cloudserver.routes.home :refer [home-routes]]
> [noir.util.middleware :as noir-middleware]
> [cloudserver.routes.auth :refer [auth-routes]]
> [cloudserver.routes.upload :refer [upload-routes]]
> [cloudserver.routes.search :refer [search-routes]]
> [cloudserver.routes.download :refer [download-routes]]
> [ring.middleware.defaults :refer [api-defaults wrap-defaults 
> site-defaults]]
> [ring.middleware.multipart-params :refer [wrap-multipart-params]]
> [ring.middleware.params :refer [wrap-params]]
> [noir.session :as session]
> [ring.middleware.session.memory :refer [memory-store]]))
>
> (def app
>   (->
>(routes auth-routes
>home-routes
>upload-routes
>search-routes
>download-routes
>app-routes)
>session/wrap-noir-session
>(wrap-defaults（assoc-in site-defaults [:security :anti-forgery] false)
>wrap-multipart-params
>wrap-params))
> (def app
>   (->
>(routes auth-routes
>home-routes
>upload-routes
>search-routes
>download-routes
>app-routes)
>session/wrap-noir-session
>(wrap-defaults（assoc-in site-defaults [:security :anti-forgery] false)
>wrap-multipart-params))
> (def app
>   (->
>(routes auth-routes
>home-routes
>upload-routes
>search-routes
>download-routes
>app-routes)
>session/wrap-noir-session
>(wrap-defaults (-> site-defaults
>   (assoc-in [:security :anti-forgery] false)
>   (assoc-in [:params :multipart] true)
>   (assoc-in [:params :nested] true)))
>handler/site))
> (def app
>   (->
>(routes auth-routes
>home-routes
>upload-routes
>search-routes
>download-routes
>app-routes)
>wrap-multipart-params
>session/wrap-noir-session
>(wrap-defaults（assoc-in site-defaults [:security :anti-forgery] false)))
> (def app
>   (noir-middleware/app-handler
>[auth-routes
> home-routes
> upload-routes
> search-routes
> download-routes
> app-routes]
>:ring-defaults (assoc site-defaults :security nil)))
>
> But the only result I got is {}
> --
>
> My client code is:
>
> public int upload (String filename, String[] tags, String time, String 
> fingerprint) throws IOException {
> String url = host + "/upload";
> CloseableHttpClient httpClient = 
> HttpClients.custom().setDefaultCookieStore(cookieStore).build(); 
> HttpPost httpPost =  new HttpPost(url);
>
> MultipartEntityBuilder mulentity = MultipartEntityBuilder.create();
>
> mulentity.addBinaryBody("photo", new File(filename));
>
> for (int i = 0; i < tags.length; i ++) {
> mulentity.addTextBody("tag" + i, tags[i]);
> }
>
> mulentity.addTextBody("fingerprint", fingerprint);
> mulentity.addTextBody("time", time);
> mulentity.addTextBody("filename", 
> filename.substring(filename.lastIndexOf(File.separatorChar) + 1, 
> filename.length()));
>
> HttpEntity entity = mulentity.build();
> httpPost.setEntity(entity);
> httpPost.setHeader("Content-Type", "multipart/form-data;boundary=" + 
> BOUNDARY);
>
> int status = 3;
>
> try {
> ResponseHandler responseHandler = new BasicResponseHandler();
> String response = httpClient.execute(httpPost, responseHandler);
> status = Integer.parseInt(response);
> } catch (ClientProtocolException e) {
> e.printStackTrace();
> } catch (UnsupportedEncodingException e) {
> e.printStackTrace();
> } finally {
> httpClient.close();
> }
> return status;
> }
>
> --
>
> I am really a green hand in clojure web programming. Thanks a lot!
>

-- 
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 

Re: Can't extract multipart-params from POST request in compojure

[James Reeves]

In all your examples except for possibly the last, you have the multipart
middleware added twice over to your application.

Also, are you sure it's not a problem with your client code?

One thing to try is recording your HTTP request by pointing your client at
a netcat listener (e.g. "nc -l 3000"). Or writing a handler that dumps out
the headers and the contents of the request body.

- James

On 7 July 2016 at 03:18,  wrote:

> This is the link to the question in stackoverflow:
>
> http://stackoverflow.com/questions/38226276/cant-extract-multipart-params-from-post-request-in-compojure
>
> 在 2016年7月7日星期四 UTC+8上午10:13:25，aaartu...@gmail.com写道：
>
>> When I try to extract the multipart-params from a POST request like this:
>>
>> (defroutes upload-routes
>>   (POST "/upload" {params :params} (println params))
>>
>>
>> I got {}.
>>
>> Then I tried like this:
>>
>> (defroutes upload-routes
>>   (POST "/upload" {multipart-params :multipart-params} (println 
>> multipart-params))
>>
>> I still got {}.
>>
>> I guess there are something wrong about my middleware.
>>
>> So I tried to change the handler, here are the handlers I had tried:
>>
>> (ns cloudserver.handler
>>   (:require [compojure.core :refer [defroutes routes]]
>> [compojure.route :as route]
>> [compojure.handler :as handler]
>> [cloudserver.routes.home :refer [home-routes]]
>> [noir.util.middleware :as noir-middleware]
>> [cloudserver.routes.auth :refer [auth-routes]]
>> [cloudserver.routes.upload :refer [upload-routes]]
>> [cloudserver.routes.search :refer [search-routes]]
>> [cloudserver.routes.download :refer [download-routes]]
>> [ring.middleware.defaults :refer [api-defaults wrap-defaults 
>> site-defaults]]
>> [ring.middleware.multipart-params :refer [wrap-multipart-params]]
>> [ring.middleware.params :refer [wrap-params]]
>> [noir.session :as session]
>> [ring.middleware.session.memory :refer [memory-store]]))
>>
>> (def app
>>   (->
>>(routes auth-routes
>>home-routes
>>upload-routes
>>search-routes
>>download-routes
>>app-routes)
>>session/wrap-noir-session
>>(wrap-defaults（assoc-in site-defaults [:security :anti-forgery] false)
>>wrap-multipart-params
>>wrap-params))
>> (def app
>>   (->
>>(routes auth-routes
>>home-routes
>>upload-routes
>>search-routes
>>download-routes
>>app-routes)
>>session/wrap-noir-session
>>(wrap-defaults（assoc-in site-defaults [:security :anti-forgery] false)
>>wrap-multipart-params))
>> (def app
>>   (->
>>(routes auth-routes
>>home-routes
>>upload-routes
>>search-routes
>>download-routes
>>app-routes)
>>session/wrap-noir-session
>>(wrap-defaults (-> site-defaults
>>   (assoc-in [:security :anti-forgery] false)
>>   (assoc-in [:params :multipart] true)
>>   (assoc-in [:params :nested] true)))
>>handler/site))
>> (def app
>>   (->
>>(routes auth-routes
>>home-routes
>>upload-routes
>>search-routes
>>download-routes
>>app-routes)
>>wrap-multipart-params
>>session/wrap-noir-session
>>(wrap-defaults（assoc-in site-defaults [:security :anti-forgery] false)))
>> (def app
>>   (noir-middleware/app-handler
>>[auth-routes
>> home-routes
>> upload-routes
>> search-routes
>> download-routes
>> app-routes]
>>:ring-defaults (assoc site-defaults :security nil)))
>>
>> But the only result I got is {}
>> --
>>
>> My client code is:
>>
>> public int upload (String filename, String[] tags, String time, String 
>> fingerprint) throws IOException {
>> String url = host + "/upload";
>> CloseableHttpClient httpClient = 
>> HttpClients.custom().setDefaultCookieStore(cookieStore).build();
>> HttpPost httpPost =  new HttpPost(url);
>>
>> MultipartEntityBuilder mulentity = MultipartEntityBuilder.create();
>>
>> mulentity.addBinaryBody("photo", new File(filename));
>>
>> for (int i = 0; i < tags.length; i ++) {
>> mulentity.addTextBody("tag" + i, tags[i]);
>> }
>>
>> mulentity.addTextBody("fingerprint", fingerprint);
>> mulentity.addTextBody("time", time);
>> mulentity.addTextBody("filename", 
>> filename.substring(filename.lastIndexOf(File.separatorChar) + 1, 
>> filename.length()));
>>
>> HttpEntity entity = mulentity.build();
>> httpPost.setEntity(entity);
>> httpPost.setHeader("Content-Type", "multipart/form-data;boundary=" + 
>> BOUNDARY);
>>
>> int status = 3;
>>
>> try {
>> ResponseHandler responseHandler = new BasicResponseHandler();
>> String response = httpClient.execute(httpPost, res

Re: Can't extract multipart-params from POST request in compojure

[aaarturozhao]

The request  header:




The request body:



My test params are: 

String[] tags = {"", "", ""};
s = test.upload("/Users/apple/test.txt", tags, "19960808", 
"qwertyuiopasdfghjklzxcvbnm");


The content of test.txt is "This is a test...".


Is there anything wrong?


BTW, could you give me an example of the definition of app? I'm not sure 
which one is correct.


在 2016年7月7日星期四 UTC+8上午10:30:31，James Reeves写道：
>
> In all your examples except for possibly the last, you have the multipart 
> middleware added twice over to your application.
>
> Also, are you sure it's not a problem with your client code?
>
> One thing to try is recording your HTTP request by pointing your client at 
> a netcat listener (e.g. "nc -l 3000"). Or writing a handler that dumps out 
> the headers and the contents of the request body.
>
> - James
>
> On 7 July 2016 at 03:18, > wrote:
>
>> This is the link to the question in stackoverflow:
>>
>> http://stackoverflow.com/questions/38226276/cant-extract-multipart-params-from-post-request-in-compojure
>>
>> 在 2016年7月7日星期四 UTC+8上午10:13:25，aaartu...@gmail.com写道：
>>
>>> When I try to extract the multipart-params from a POST request like this:
>>>
>>> (defroutes upload-routes
>>>   (POST "/upload" {params :params} (println params))
>>>
>>>
>>> I got {}.
>>>
>>> Then I tried like this:
>>>
>>> (defroutes upload-routes
>>>   (POST "/upload" {multipart-params :multipart-params} (println 
>>> multipart-params))
>>>
>>> I still got {}.
>>>
>>> I guess there are something wrong about my middleware.
>>>
>>> So I tried to change the handler, here are the handlers I had tried:
>>>
>>> (ns cloudserver.handler
>>>   (:require [compojure.core :refer [defroutes routes]]
>>> [compojure.route :as route]
>>> [compojure.handler :as handler]
>>> [cloudserver.routes.home :refer [home-routes]]
>>> [noir.util.middleware :as noir-middleware]
>>> [cloudserver.routes.auth :refer [auth-routes]]
>>> [cloudserver.routes.upload :refer [upload-routes]]
>>> [cloudserver.routes.search :refer [search-routes]]
>>> [cloudserver.routes.download :refer [download-routes]]
>>> [ring.middleware.defaults :refer [api-defaults wrap-defaults 
>>> site-defaults]]
>>> [ring.middleware.multipart-params :refer 
>>> [wrap-multipart-params]]
>>> [ring.middleware.params :refer [wrap-params]]
>>> [noir.session :as session]
>>> [ring.middleware.session.memory :refer [memory-store]]))
>>>
>>> (def app
>>>   (->
>>>(routes auth-routes
>>>home-routes
>>>upload-routes
>>>search-routes
>>>download-routes
>>>app-routes)
>>>session/wrap-noir-session
>>>(wrap-defaults（assoc-in site-defaults [:security :anti-forgery] false)
>>>wrap-multipart-params
>>>wrap-params))
>>> (def app
>>>   (->
>>>(routes auth-routes
>>>home-routes
>>>upload-routes
>>>search-routes
>>>download-routes
>>>app-routes)
>>>session/wrap-noir-session
>>>(wrap-defaults（assoc-in site-defaults [:security :anti-forgery] false)
>>>wrap-multipart-params))
>>> (def app
>>>   (->
>>>(routes auth-routes
>>>home-routes
>>>upload-routes
>>>search-routes
>>>download-routes
>>>app-routes)
>>>session/wrap-noir-session
>>>(wrap-defaults (-> site-defaults
>>>   (assoc-in [:security :anti-forgery] false)
>>>   (assoc-in [:params :multipart] true)
>>>   (assoc-in [:params :nested] true)))
>>>handler/site))
>>> (def app
>>>   (->
>>>(routes auth-routes
>>>home-routes
>>>upload-routes
>>>search-routes
>>>download-routes
>>>app-routes)
>>>wrap-multipart-params
>>>session/wrap-noir-session
>>>(wrap-defaults（assoc-in site-defaults [:security :anti-forgery] false)))
>>> (def app
>>>   (noir-middleware/app-handler
>>>[auth-routes
>>> home-routes
>>> upload-routes
>>> search-routes
>>> download-routes
>>> app-routes]
>>>:ring-defaults (assoc site-defaults :security nil)))
>>>
>>> But the only result I got is {}
>>> --
>>>
>>> My client code is:
>>>
>>> public int upload (String filename, String[] tags, String time, String 
>>> fingerprint) throws IOException {
>>> String url = host + "/upload";
>>> CloseableHttpClie

Re: Can't extract multipart-params from POST request in compojure

[James Reeves]

By "application" I mean "Ring handler".

Your request looks wrong. The boundary you set in your header
(--BoUnDaRyFF) doesn't match the boundary I see in the body
(--2n639DJeu...).

- James

On 7 July 2016 at 05:29,  wrote:

> The request  header:
>
>
>
> 
>
> The request body:
>
>
> 
>
> My test params are:
>
> String[] tags = {"", "", ""};
> s = test.upload("/Users/apple/test.txt", tags, "19960808",
> "qwertyuiopasdfghjklzxcvbnm");
>
>
> The content of test.txt is "This is a test...".
>
>
> Is there anything wrong?
>
>
> BTW, could you give me an example of the definition of app? I'm not sure
> which one is correct.
>
>
> 在 2016年7月7日星期四 UTC+8上午10:30:31，James Reeves写道：
>>
>> In all your examples except for possibly the last, you have the multipart
>> middleware added twice over to your application.
>>
>> Also, are you sure it's not a problem with your client code?
>>
>> One thing to try is recording your HTTP request by pointing your client
>> at a netcat listener (e.g. "nc -l 3000"). Or writing a handler that dumps
>> out the headers and the contents of the request body.
>>
>> - James
>>
>> On 7 July 2016 at 03:18,  wrote:
>>
>>> This is the link to the question in stackoverflow:
>>>
>>> http://stackoverflow.com/questions/38226276/cant-extract-multipart-params-from-post-request-in-compojure
>>>
>>> 在 2016年7月7日星期四 UTC+8上午10:13:25，aaartu...@gmail.com写道：
>>>
 When I try to extract the multipart-params from a POST request like
 this:

 (defroutes upload-routes
   (POST "/upload" {params :params} (println params))


 I got {}.

 Then I tried like this:

 (defroutes upload-routes
   (POST "/upload" {multipart-params :multipart-params} (println 
 multipart-params))

 I still got {}.

 I guess there are something wrong about my middleware.

 So I tried to change the handler, here are the handlers I had tried:

 (ns cloudserver.handler
   (:require [compojure.core :refer [defroutes routes]]
 [compojure.route :as route]
 [compojure.handler :as handler]
 [cloudserver.routes.home :refer [home-routes]]
 [noir.util.middleware :as noir-middleware]
 [cloudserver.routes.auth :refer [auth-routes]]
 [cloudserver.routes.upload :refer [upload-routes]]
 [cloudserver.routes.search :refer [search-routes]]
 [cloudserver.routes.download :refer [download-routes]]
 [ring.middleware.defaults :refer [api-defaults wrap-defaults 
 site-defaults]]
 [ring.middleware.multipart-params :refer 
 [wrap-multipart-params]]
 [ring.middleware.params :refer [wrap-params]]
 [noir.session :as session]
 [ring.middleware.session.memory :refer [memory-store]]))

 (def app
   (->
(routes auth-routes
home-routes
upload-routes
search-routes
download-routes
app-routes)
session/wrap-noir-session
(wrap-defaults（assoc-in site-defaults [:security :anti-forgery] false)
wrap-multipart-params
wrap-params))
 (def app
   (->
(routes auth-routes
home-routes
upload-routes
search-routes
download-routes
app-routes)
session/wrap-noir-session
(wrap-defaults（assoc-in site-defaults [:security :anti-forgery] false)
wrap-multipart-params))
 (def app
   (->
(routes auth-routes
home-routes
upload-routes
search-routes
download-routes
app-routes)
session/wrap-noir-session
(wrap-defaults (-> site-defaults
   (assoc-in [:security :anti-forgery] false)
   (assoc-in [:params :multipart] true)
   (assoc-in [:params :nested] true)))
handler/site))
 (def app
   (->
(routes auth-routes
home-routes
upload-routes
search-routes
download-routes
app-routes)
wrap-multipart-params
session/wrap-noir-session
(wrap-defaults（assoc-in site-defaults [:security :anti-forgery] false)))
 (def app
   (noir-middleware/app-handler
[auth-routes
 home-routes
 upload-routes
 search-routes
>>>

Re: Can't extract multipart-params from POST request in compojure

[aaarturozhao]

You are right! I didn't set the boundary in my client code. Thanks a lot!

在 2016年7月7日星期四 UTC+8下午12:46:04，James Reeves写道：
>
> By "application" I mean "Ring handler".
>
> Your request looks wrong. The boundary you set in your header 
> (--BoUnDaRyFF) doesn't match the boundary I see in the body 
> (--2n639DJeu...).
>
> - James
>
> On 7 July 2016 at 05:29, > wrote:
>
>> The request  header:
>>
>>
>>
>> 
>>
>> The request body:
>>
>>
>> 
>>
>> My test params are: 
>>
>> String[] tags = {"", "", ""};
>> s = test.upload("/Users/apple/test.txt", tags, "19960808", 
>> "qwertyuiopasdfghjklzxcvbnm");
>>
>>
>> The content of test.txt is "This is a test...".
>>
>>
>> Is there anything wrong?
>>
>>
>> BTW, could you give me an example of the definition of app? I'm not sure 
>> which one is correct.
>>
>>
>> 在 2016年7月7日星期四 UTC+8上午10:30:31，James Reeves写道：
>>>
>>> In all your examples except for possibly the last, you have the 
>>> multipart middleware added twice over to your application.
>>>
>>> Also, are you sure it's not a problem with your client code?
>>>
>>> One thing to try is recording your HTTP request by pointing your client 
>>> at a netcat listener (e.g. "nc -l 3000"). Or writing a handler that dumps 
>>> out the headers and the contents of the request body.
>>>
>>> - James
>>>
>>> On 7 July 2016 at 03:18,  wrote:
>>>
 This is the link to the question in stackoverflow:

 http://stackoverflow.com/questions/38226276/cant-extract-multipart-params-from-post-request-in-compojure

 在 2016年7月7日星期四 UTC+8上午10:13:25，aaartu...@gmail.com写道：

> When I try to extract the multipart-params from a POST request like 
> this:
>
> (defroutes upload-routes
>   (POST "/upload" {params :params} (println params))
>
>
> I got {}.
>
> Then I tried like this:
>
> (defroutes upload-routes
>   (POST "/upload" {multipart-params :multipart-params} (println 
> multipart-params))
>
> I still got {}.
>
> I guess there are something wrong about my middleware.
>
> So I tried to change the handler, here are the handlers I had tried:
>
> (ns cloudserver.handler
>   (:require [compojure.core :refer [defroutes routes]]
> [compojure.route :as route]
> [compojure.handler :as handler]
> [cloudserver.routes.home :refer [home-routes]]
> [noir.util.middleware :as noir-middleware]
> [cloudserver.routes.auth :refer [auth-routes]]
> [cloudserver.routes.upload :refer [upload-routes]]
> [cloudserver.routes.search :refer [search-routes]]
> [cloudserver.routes.download :refer [download-routes]]
> [ring.middleware.defaults :refer [api-defaults wrap-defaults 
> site-defaults]]
> [ring.middleware.multipart-params :refer 
> [wrap-multipart-params]]
> [ring.middleware.params :refer [wrap-params]]
> [noir.session :as session]
> [ring.middleware.session.memory :refer [memory-store]]))
>
> (def app
>   (->
>(routes auth-routes
>home-routes
>upload-routes
>search-routes
>download-routes
>app-routes)
>session/wrap-noir-session
>(wrap-defaults（assoc-in site-defaults [:security :anti-forgery] false)
>wrap-multipart-params
>wrap-params))
> (def app
>   (->
>(routes auth-routes
>home-routes
>upload-routes
>search-routes
>download-routes
>app-routes)
>session/wrap-noir-session
>(wrap-defaults（assoc-in site-defaults [:security :anti-forgery] false)
>wrap-multipart-params))
> (def app
>   (->
>(routes auth-routes
>home-routes
>upload-routes
>search-routes
>download-routes
>app-routes)
>session/wrap-noir-session
>(wrap-defaults (-> site-defaults
>   (assoc-in [:security :anti-forgery] false)
>   (assoc-in [:params :multipart] true)
>   (assoc-in [:params :nested] true)))
>handler/site))
> (def app
>   (->
>(routes auth-routes
>home-routes
>upload-routes
>search-routes
>download-routes
>app-routes)
>>>

Re: [ANN] Neanderthal 0.6.0: new support for AMD, Nvidia, and Intel GPUs on Linux, Windows and OS X (fast matrix library)

[Dragan Djuric]

Neanderthal 0.7.0 released: Nvidia, AMD, and Intel GPU on LInux, Windows, 
and OS X  http://neanderthal.uncomplicate.org#matrix  #Clojure #GPU 
 #GPGPU

On Monday, May 23, 2016 at 9:57:00 PM UTC+2, Dragan Djuric wrote:
>
> This is a major release of Neanderthal, a fast native & GPU matrix library:
>
> In this release, spotlight is on the new GPU engine, that:
>
> * Works on all three major hardware platforms: AMD, Nvidia, and Intel
> * Works on all three major operating systems: Linux, Windows, and OS X
> * Is even faster, so it is now more than 1000x faster than the optimized 
> Java libraries for 8192x8192 matrix multiplication.
>
> Version 0.6.0 is in clojars
> Documentation and the tutorials can be found at the usual place: 
> http://neanderthal.uncomplicate.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/d/optout.