Re: Get the value of the persistentArrayMap from the exception which was thrown

[Atamert Ölçgen]

It wouldn't matter which map is throwing the exception in this case. It's
an arity issue and maps accept 1 or 2 parameters.

https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/APersistentMap.java

If this wasn't REPL, it would result in a larger stacktrace and sufficient
squinting would reveal the line of originating call.


On Thu, Nov 6, 2014 at 3:19 PM, Michael Blume  wrote:

> Well, from the print of the exception, it looks unlikely, but let's look
> at the code. This stacktrace says the exception was thrown in line 429 of
> clojure.lang.AFn, and I'm going to assume you're using Clojure 1.6.0, so we
> want
> https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/AFn.java#L429
>
> Looking at that line of code, it's creating the exception object using
> only the arity (a number) and the name of the class of the object, a
> string. So no, the map is not recoverable from the exception.
>
>
> On Wednesday, November 5, 2014 10:15:50 PM UTC-8, Sunil Nandihalli wrote:
>>
>> Hi Everybody,
>>
>> user=> ({:a 1})
>>
>> ArityException Wrong number of args (0) passed to: PersistentArrayMap
>>  clojure.lang.AFn.throwArity (AFn.java:429)
>> user=> *e
>> #> passed to: PersistentArrayMap>
>>
>> From *e is it possible to infer that the object which threw it was {:a 1}?
>>
>> Thanks,
>> Sunil.
>>
>  --
> 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.
>



-- 
Kind Regards,
Atamert Ölçgen

-+-
--+
+++

www.muhuk.com

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

Re: Get the value of the persistentArrayMap from the exception which was thrown

[Michael Blume]

Well, from the print of the exception, it looks unlikely, but let's look at 
the code. This stacktrace says the exception was thrown in line 429 of 
clojure.lang.AFn, and I'm going to assume you're using Clojure 1.6.0, so we 
want 
https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/AFn.java#L429

Looking at that line of code, it's creating the exception object using only 
the arity (a number) and the name of the class of the object, a string. So 
no, the map is not recoverable from the exception.

On Wednesday, November 5, 2014 10:15:50 PM UTC-8, Sunil Nandihalli wrote:
>
> Hi Everybody,
>
> user=> ({:a 1})
>
> ArityException Wrong number of args (0) passed to: PersistentArrayMap 
>  clojure.lang.AFn.throwArity (AFn.java:429)
> user=> *e
> # passed to: PersistentArrayMap>
>
> From *e is it possible to infer that the object which threw it was {:a 1}?
>
> Thanks,
> Sunil.
>

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

Get the value of the persistentArrayMap from the exception which was thrown

[Sunil S Nandihalli]

Hi Everybody,

user=> ({:a 1})

ArityException Wrong number of args (0) passed to: PersistentArrayMap
 clojure.lang.AFn.throwArity (AFn.java:429)
user=> *e
#

>From *e is it possible to infer that the object which threw it was {:a 1}?

Thanks,
Sunil.

-- 
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: Dependency problem between clj-http and com.cemerick/friend

[John Louis Del Rosario]

Not sure if it's the same issue, but there's an existing issue in Friend's 
repo about dependency conflicts 
(https://github.com/cemerick/friend/issues/116).

On Wednesday, November 5, 2014 7:21:06 PM UTC+8, Christian Egli wrote:
>
> Hi all 
>
> I have a strange interaction between clj-http and com.cemerick/friend. I 
> don't know if this is a problem in either of the two packages or maybe 
> even Leiningen. 
>
> The problem is very easy to reproduce. Create a project with `lein new`, 
> add dependencies to clj-http and com.cemerick/friend, start a repl and 
> simpy require clj-http.client as follows: 
>
> $ lein new app friend-and-clj-http 
> $ cd friend-and-clj-http 
> $ # add clj-http and friend as a dependency to project.clj 
> $ lein repl 
> friend-and-clj-http.core=> (require '[clj-http.client :as client]) 
>
> If the dependency to friend is before the dependency to clj-http you 
> will get the following exception: 
>
> CompilerException java.lang.ClassNotFoundException: 
> org.apache.http.conn.ssl.SSLContexts, compiling:(clj_http/conn_mgr.clj:1:1) 
>
> However if you change the order of the dependencies everything works as 
> expected. 
>
> $ # change the order of the dependencies 
> $ lein repl 
> friend-and-clj-http.core=> (require '[clj-http.client :as client]) 
> nil 
> friend-and-clj-http.core=> Bye for now! 
>
> I put both versions of project.clj, the shell session and the output of 
> `lein deps :tree` for both versions in public gists 
>
> - https://gist.github.com/egli/8e6086f4d35ff7c11f80 project.clj with 
>   friend and clj-http as dependencies 
> - https://gist.github.com/egli/ff26669047b9273741c6 project.clj with 
>   clj-http and friend as dependencies 
> - https://gist.github.com/egli/076b4f450cc237e2ac4a shell session 
> - https://gist.github.com/egli/b3e149aded64c7628f8e lein deps :tree with 
>   friend before clj-http 
> - https://gist.github.com/egli/4fa13bc791e52061f9e9 lein deps :tree with 
>   clj-http before friend 
>
> Where do I report this problem? 
>
> Thanks 
> Christian 
>
> -- 
> Christian Egli 
> Swiss Library for the Blind, Visually Impaired and Print Disabled 
> Grubenstrasse 12, CH-8045 Zürich, Switzerland 
>
>

-- 
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: multimethod, record, type, and protocol pitfalls?

[Adam Krieg]

You are right about the factory methods for Records.  My need to reference the 
records in another namespace was for type hinting.


> On Nov 5, 2014, at 6:12 PM, Gary Trakhman  wrote:
> 
> You don't need to import the record if you use the auto-gen'd factories, 
> ->RecordName and map->RecordName.  You can and also shouldn't import the java 
> interfaces created by protocols.  
> 
> It's possible to interactively develop this way, but you really have to know 
> what's being eval'd and what types are invalidated to do so, and is generally 
> not recommended.
> 
> Extend-type is easier to use interactively than inline protocol extensions 
> (which are faster) as it's modifying dynamic globals.
> 
> On Wed, Nov 5, 2014 at 6:03 PM, Adam Krieg  > wrote:
> My experience with protocols is that the implementations can't be redefined, 
> e.g changing an implementation.  So if you change one of the applied 
> protocols, you may need to restart your REPL. YMMV.
> 
> Using records outside of their declared namespace is also really weird.  You 
> need to both require the namespace and import the record IN THAT ORDER. If 
> you import the Record and then require the namespace, it doesn't work, which 
> is a nasty wart, IMO.
> 
> 
> On Sunday, October 26, 2014 11:48:29 AM UTC-4, Daniel Higginbotham wrote:
> What's difficult when it comes to understanding multimethods, records, types, 
> and protocols? I'm writing a chapter on multimethods, records, types, and 
> protocols for the book Clojure for the Brave and True, and I'd love to hear 
> about what kinds of pitfalls I should be sure to cover :)
> 
> Thanks!
> Daniel
> 

-- 
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: Introducing Boot v2 with a streamlined CLJS workflow

[Alan Dipert]

Hi Laurent,
The boot-cljs-example has started to move ahead of the blog post, and 
includes an optional 'serve' task.

There was a bug in the boot-cljs task that was deleting index.html 
erroneously; I pushed a new version and updated boot-cljs-example.

If you `boot -u` to update boot (which was also updated today) and fetch 
latest from boot-cljs-example, there's a decent chance it will actually 
work :-)
Alan

On Wednesday, November 5, 2014 5:07:04 PM UTC-5, Laurent PETIT wrote:
>
> Alternatively, if I follow instructions from 
> https://github.com/adzerk/boot-cljs-example ,
>
> then there's no mention of target/index.html, so I directly jump to 
> http://localhost:3000/ but I get an HTTP 404, so same problem there I 
> think.
>
> command is different than from the blog post:
>
> $ boot serve -d target/ watch speak cljs-repl cljs -usO none reload
> Retrieving ring-jetty-adapter-1.3.1.jar from http://clojars.org/repo/
> Retrieving ring-core-1.3.1.jar from http://clojars.org/repo/
> Retrieving clj-time-0.6.0.jar from http://clojars.org/repo/
> Retrieving crypto-random-1.2.0.jar from http://clojars.org/repo/
> Retrieving crypto-equality-1.0.0.jar from http://clojars.org/repo/
> Retrieving ring-servlet-1.3.1.jar from http://clojars.org/repo/
> Retrieving compojure-1.2.1.jar from http://clojars.org/repo/
> Retrieving clout-2.0.0.jar from http://clojars.org/repo/
> Retrieving instaparse-1.3.4.jar from http://clojars.org/repo/
> Retrieving medley-0.5.3.jar from http://clojars.org/repo/
> Retrieving ring-codec-1.0.0.jar from http://clojars.org/repo/
> Retrieving tools.reader-0.8.1.jar from http://repo1.maven.org/maven2/
> Retrieving commons-fileupload-1.3.jar from http://repo1.maven.org/maven2/
> Retrieving jetty-server-7.6.13.v20130916.jar from 
> http://repo1.maven.org/maven2/
> Retrieving javax.servlet-2.5.0.v201103041518.jar from 
> http://repo1.maven.org/maven2/
> Retrieving joda-time-2.2.jar from http://repo1.maven.org/maven2/
> Retrieving jetty-continuation-7.6.13.v20130916.jar from 
> http://repo1.maven.org/maven2/
> Retrieving jetty-http-7.6.13.v20130916.jar from 
> http://repo1.maven.org/maven2/
> Retrieving jetty-io-7.6.13.v20130916.jar from 
> http://repo1.maven.org/maven2/
> Retrieving jetty-util-7.6.13.v20130916.jar from 
> http://repo1.maven.org/maven2/
> Retrieving tools.macro-0.1.5.jar from http://repo1.maven.org/maven2/
> Retrieving commons-codec-1.6.jar from http://repo1.maven.org/maven2/
> << started reload server on ws://localhost:8090 >>
> 2014-11-05 22:59:51.865:INFO:oejs.Server:jetty-7.6.13.v20130916
> 2014-11-05 22:59:51.928:INFO:oejs.AbstractConnector:Started 
> SelectChannelConnector@0.0.0.0:3000
> << started web server on http://localhost:3000 (serving: target/) >>
> Starting file watcher (CTRL-C to quit)...
>
> nREPL server listening: 0.0.0.0:50475
> Compiling main.js...
> Adding 

Re: multimethod, record, type, and protocol pitfalls?

[Gary Trakhman]

You don't need to import the record if you use the auto-gen'd factories,
->RecordName and map->RecordName.  You can and also shouldn't import the
java interfaces created by protocols.

It's possible to interactively develop this way, but you really have to
know what's being eval'd and what types are invalidated to do so, and is
generally not recommended.

Extend-type is easier to use interactively than inline protocol extensions
(which are faster) as it's modifying dynamic globals.

On Wed, Nov 5, 2014 at 6:03 PM, Adam Krieg  wrote:

> My experience with protocols is that the implementations can't be
> redefined, e.g changing an implementation.  So if you change one of the
> applied protocols, you may need to restart your REPL. YMMV.
>
> Using records outside of their declared namespace is also really weird.
> You need to both require the namespace and import the record IN THAT ORDER.
> If you import the Record and then require the namespace, it doesn't work,
> which is a nasty wart, IMO.
>
>
> On Sunday, October 26, 2014 11:48:29 AM UTC-4, Daniel Higginbotham wrote:
>
>> What's difficult when it comes to understanding multimethods, records,
>> types, and protocols? I'm writing a chapter on multimethods, records,
>> types, and protocols for the book Clojure for the Brave and True, and I'd
>> love to hear about what kinds of pitfalls I should be sure to cover :)
>>
>> Thanks!
>> Daniel
>>
>  --
> 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: multimethod, record, type, and protocol pitfalls?

[Adam Krieg]

My experience with protocols is that the implementations can't be 
redefined, e.g changing an implementation.  So if you change one of the 
applied protocols, you may need to restart your REPL. YMMV.

Using records outside of their declared namespace is also really weird. 
 You need to both require the namespace and import the record IN THAT 
ORDER. If you import the Record and then require the namespace, it doesn't 
work, which is a nasty wart, IMO.


On Sunday, October 26, 2014 11:48:29 AM UTC-4, Daniel Higginbotham wrote:
>
> What's difficult when it comes to understanding multimethods, records, 
> types, and protocols? I'm writing a chapter on multimethods, records, 
> types, and protocols for the book Clojure for the Brave and True, and I'd 
> love to hear about what kinds of pitfalls I should be sure to cover :)
>
> Thanks!
> Daniel
>

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

Re: clojure.test.check with fixtures

[Ashton Kemerling]

You can use fixtures from Clojure.test, but each spec from the perspective of 
clojure.test includes multiple runs. So I use fixtures :once to do any global 
setup, and then farm out to a setup function for anything that needs to be done 
before each test run. 

--Ashton

Sent from my iPhone

> On Nov 5, 2014, at 3:27 PM, Sven Richter  wrote:
> 
> Hi,
> 
> Is there a way to use clojure.test.check's defspec with fixtures?
> Like (use-fixtures :each (partial wrap-setup setup teardown)) in clojures 
> test library?
> 
> How do other people execute setup and teardowns with clojure.test.check?
> 
> Best Regards,
> Sven
> -- 
> 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.

clojure.test.check with fixtures

[Sven Richter]

Hi,

Is there a way to use clojure.test.check's defspec with fixtures?
Like (use-fixtures :each (partial wrap-setup setup teardown)) in clojures 
test library?

How do other people execute setup and teardowns with clojure.test.check?

Best Regards,
Sven

-- 
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: Dependency problem between clj-http and com.cemerick/friend

[Plínio Balduino]

Hi, Christian

Did you try the issue list on GitHub?

https://github.com/cemerick/friend/issues

Regards

Plínio Balduino

On Wed, Nov 5, 2014 at 8:20 AM, Christian Egli 
wrote:

> Hi all
>
> I have a strange interaction between clj-http and com.cemerick/friend. I
> don't know if this is a problem in either of the two packages or maybe
> even Leiningen.
>
> The problem is very easy to reproduce. Create a project with `lein new`,
> add dependencies to clj-http and com.cemerick/friend, start a repl and
> simpy require clj-http.client as follows:
>
> $ lein new app friend-and-clj-http
> $ cd friend-and-clj-http
> $ # add clj-http and friend as a dependency to project.clj
> $ lein repl
> friend-and-clj-http.core=> (require '[clj-http.client :as client])
>
> If the dependency to friend is before the dependency to clj-http you
> will get the following exception:
>
> CompilerException java.lang.ClassNotFoundException:
> org.apache.http.conn.ssl.SSLContexts, compiling:(clj_http/conn_mgr.clj:1:1)
>
> However if you change the order of the dependencies everything works as
> expected.
>
> $ # change the order of the dependencies
> $ lein repl
> friend-and-clj-http.core=> (require '[clj-http.client :as client])
> nil
> friend-and-clj-http.core=> Bye for now!
>
> I put both versions of project.clj, the shell session and the output of
> `lein deps :tree` for both versions in public gists
>
> - https://gist.github.com/egli/8e6086f4d35ff7c11f80 project.clj with
>   friend and clj-http as dependencies
> - https://gist.github.com/egli/ff26669047b9273741c6 project.clj with
>   clj-http and friend as dependencies
> - https://gist.github.com/egli/076b4f450cc237e2ac4a shell session
> - https://gist.github.com/egli/b3e149aded64c7628f8e lein deps :tree with
>   friend before clj-http
> - https://gist.github.com/egli/4fa13bc791e52061f9e9 lein deps :tree with
>   clj-http before friend
>
> Where do I report this problem?
>
> Thanks
> Christian
>
> --
> Christian Egli
> Swiss Library for the Blind, Visually Impaired and Print Disabled
> Grubenstrasse 12, CH-8045 Zürich, Switzerland
>
> --
> 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: Dependency problem between clj-http and com.cemerick/friend

[Andy Fingerhut]

Christian:

Try running 'lein deps :tree >& deps.txt' in each of those projects, and
diff them.  I can't explain why the differences are there that exist, but
there are significant differences, including in version numbers of some of
the dependencies brought in.

Asking on the Leiningen email list or #clojure IRC channel may be more
fruitful.

Andy


On Wed, Nov 5, 2014 at 3:20 AM, Christian Egli 
wrote:

> Hi all
>
> I have a strange interaction between clj-http and com.cemerick/friend. I
> don't know if this is a problem in either of the two packages or maybe
> even Leiningen.
>
> The problem is very easy to reproduce. Create a project with `lein new`,
> add dependencies to clj-http and com.cemerick/friend, start a repl and
> simpy require clj-http.client as follows:
>
> $ lein new app friend-and-clj-http
> $ cd friend-and-clj-http
> $ # add clj-http and friend as a dependency to project.clj
> $ lein repl
> friend-and-clj-http.core=> (require '[clj-http.client :as client])
>
> If the dependency to friend is before the dependency to clj-http you
> will get the following exception:
>
> CompilerException java.lang.ClassNotFoundException:
> org.apache.http.conn.ssl.SSLContexts, compiling:(clj_http/conn_mgr.clj:1:1)
>
> However if you change the order of the dependencies everything works as
> expected.
>
> $ # change the order of the dependencies
> $ lein repl
> friend-and-clj-http.core=> (require '[clj-http.client :as client])
> nil
> friend-and-clj-http.core=> Bye for now!
>
> I put both versions of project.clj, the shell session and the output of
> `lein deps :tree` for both versions in public gists
>
> - https://gist.github.com/egli/8e6086f4d35ff7c11f80 project.clj with
>   friend and clj-http as dependencies
> - https://gist.github.com/egli/ff26669047b9273741c6 project.clj with
>   clj-http and friend as dependencies
> - https://gist.github.com/egli/076b4f450cc237e2ac4a shell session
> - https://gist.github.com/egli/b3e149aded64c7628f8e lein deps :tree with
>   friend before clj-http
> - https://gist.github.com/egli/4fa13bc791e52061f9e9 lein deps :tree with
>   clj-http before friend
>
> Where do I report this problem?
>
> Thanks
> Christian
>
> --
> Christian Egli
> Swiss Library for the Blind, Visually Impaired and Print Disabled
> Grubenstrasse 12, CH-8045 Zürich, Switzerland
>
> --
> 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: Introducing Boot v2 with a streamlined CLJS workflow

[Laurent PETIT]

Alternatively, if I follow instructions from
https://github.com/adzerk/boot-cljs-example ,

then there's no mention of target/index.html, so I directly jump to
http://localhost:3000/ but I get an HTTP 404, so same problem there I think.

command is different than from the blog post:

$ boot serve -d target/ watch speak cljs-repl cljs -usO none reload
Retrieving ring-jetty-adapter-1.3.1.jar from http://clojars.org/repo/
Retrieving ring-core-1.3.1.jar from http://clojars.org/repo/
Retrieving clj-time-0.6.0.jar from http://clojars.org/repo/
Retrieving crypto-random-1.2.0.jar from http://clojars.org/repo/
Retrieving crypto-equality-1.0.0.jar from http://clojars.org/repo/
Retrieving ring-servlet-1.3.1.jar from http://clojars.org/repo/
Retrieving compojure-1.2.1.jar from http://clojars.org/repo/
Retrieving clout-2.0.0.jar from http://clojars.org/repo/
Retrieving instaparse-1.3.4.jar from http://clojars.org/repo/
Retrieving medley-0.5.3.jar from http://clojars.org/repo/
Retrieving ring-codec-1.0.0.jar from http://clojars.org/repo/
Retrieving tools.reader-0.8.1.jar from http://repo1.maven.org/maven2/
Retrieving commons-fileupload-1.3.jar from http://repo1.maven.org/maven2/
Retrieving jetty-server-7.6.13.v20130916.jar from
http://repo1.maven.org/maven2/
Retrieving javax.servlet-2.5.0.v201103041518.jar from
http://repo1.maven.org/maven2/
Retrieving joda-time-2.2.jar from http://repo1.maven.org/maven2/
Retrieving jetty-continuation-7.6.13.v20130916.jar from
http://repo1.maven.org/maven2/
Retrieving jetty-http-7.6.13.v20130916.jar from
http://repo1.maven.org/maven2/
Retrieving jetty-io-7.6.13.v20130916.jar from http://repo1.maven.org/maven2/
Retrieving jetty-util-7.6.13.v20130916.jar from
http://repo1.maven.org/maven2/
Retrieving tools.macro-0.1.5.jar from http://repo1.maven.org/maven2/
Retrieving commons-codec-1.6.jar from http://repo1.maven.org/maven2/
<< started reload server on ws://localhost:8090 >>
2014-11-05 22:59:51.865:INFO:oejs.Server:jetty-7.6.13.v20130916
2014-11-05 22:59:51.928:INFO:oejs.AbstractConnector:Started
SelectChannelConnector@0.0.0.0:3000
<< started web server on http://localhost:3000 (serving: target/) >>
Starting file watcher (CTRL-C to quit)...

nREPL server listening: 0.0.0.0:50475
Compiling main.js...
Adding 

Re: Introducing Boot v2 with a streamlined CLJS workflow

[Laurent PETIT]

Thanks Micha for the detailed explanation !

I started following the cljs example, but am stuck right after having
launched the first boot command: I don't see file target/index.html

The command and output look like this (launched from the boot-cljs-example
folder):

$ boot watch speak cljs-repl cljs -usO none reload
Retrieving tagsoup-1.2.1.jar from http://clojars.org/repo/
Retrieving enlive-1.1.5.jar from http://clojars.org/repo/
Retrieving jsoup-1.7.2.jar from http://repo1.maven.org/maven2/
Retrieving args4j-2.0.16.jar from http://repo1.maven.org/maven2/
Retrieving protobuf-java-2.4.1.jar from http://repo1.maven.org/maven2/
Retrieving clojurescript-0.0-2080.jar from http://repo1.maven.org/maven2/
Retrieving closure-compiler-v20130603.jar from
http://repo1.maven.org/maven2/
Retrieving google-closure-library-0.0-20130212-95c19e7f0f5f.jar from
http://repo1.maven.org/maven2/
Retrieving google-closure-library-third-party-0.0-20130212-95c19e7f0f5f.jar
from http://repo1.maven.org/maven2/
Retrieving tools.reader-0.8.0.jar from http://repo1.maven.org/maven2/
<< started reload server on ws://localhost:8090 >>
Starting file watcher (CTRL-C to quit)...

nREPL server listening: 0.0.0.0:50352
Compiling main.js...
Adding 

Re: Deterministic Randomness in Functional Clojure

[blake]

On Tue, Nov 4, 2014 at 7:22 PM, Fluid Dynamics  wrote:

> On Tuesday, November 4, 2014 9:54:39 PM UTC-5, Atamert Ölçgen wrote:
>>
>> clojure-lanterna is pretty cool.
>>
>> https://github.com/sjl/clojure-lanterna
>>
>> I'm interested in hearing about alternatives as well.
>>
>
> Terminal emulation? In this day and age?
>

To quote Steve Losh's blog "Being able to output to either a console or a
GUI means that I can develop through Swank really easily with the Swing
terminal, but [actually] play the finished product in a terminal
like God intended."

Modern roguelikes (like "Diablo", heh) can use the mouse, but traditionally
they are played fullscreen, in darkness, with hands never leaving the home
row.



>
> And a quick look around reveals no sign of mouse support. Even old MS-DOS
> applications often had some kind of mouse support (QBASIC for one). With so
> many people increasingly using tablets that lack keyboards, I'd think any
> game should try to be playable with little or no keyboard input required.
>
> --
> 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: Deterministic Randomness in Functional Clojure

[blake]

OK, I was using Lanterna as well, based on Steve Losh's "Caves of Clojure"
series.

On Tue, Nov 4, 2014 at 6:53 PM, Atamert Ölçgen  wrote:

> clojure-lanterna is pretty cool.
>
> https://github.com/sjl/clojure-lanterna
>
> I'm interested in hearing about alternatives as well.
>
>
> On Wed, Nov 5, 2014 at 4:09 AM, blake  wrote:
>
>> Pardon my interruption: What are you using for screen output for your
>> roguelike?
>>
>> On Tue, Oct 28, 2014 at 12:08 PM, Isaac Karth 
>> wrote:
>>
>>> I've been working on some projects (roguelikes, story-generators) that
>>> often have a reason to have a random outcome for things like procedurally
>>> generating a map. Ideally, they would be deterministically psuduorandom, so
>>> that I can generate the same results from the same seed. The part I'm
>>> having trouble with is figuring out what method to use to implement this in
>>> a functional way.
>>>
>>> The naive approach that first occurred to me was to pass a PRNG and seed
>>> value into each function. That would certainly keep the functions
>>> referentially transparent. But it would also require either rewriting a
>>> bunch of functions that don't directly use the randomness themselves or
>>> adding the RNG as part of the map that's already being passed.
>>>
>>> Plus, the seed should probably vary (deterministically) between calls to
>>> the subfunctions. It's not too useful if all the rooms on a map have the
>>> same type because they all pulled their die roll from the same-nth result
>>> of the exact same seed. Maybe the seed could be created from the contents
>>> of the vector or a UUID of a map object or something?
>>>
>>> The other suggestion I've run across is to rebind something like
>>> clojure.data.generators/*rnd* for each high-level procedural generation
>>> call. I think this requires the generation to be single threaded and
>>> otherwise deterministic. At the moment I don't feel like I know enough
>>> about how things work under the hood to say if this a good idea or not.
>>>
>>> I've poked around at the bigml.sampling and clojure.data.generators
>>> libraries, which look useful for dealing with some of this, but I haven't
>>> come across anything that directly addresses what kind of architecture to
>>> use for deterministic randomness. This may be my inexperience. I feel like
>>> I may be a bit too close to the problem, and I can't quite see what the
>>> idiomatic answer is. Re-read SICP? Implement some kind of monad? Just bite
>>> the bullet and pass the RNG+seed? Find the secret pure functional library
>>> everyone is using for repeatable stochastic simulations?
>>>
>>> Does anyone have any advice on this? Or prior experience with approaches
>>> that work? What are some best practices for approaching deterministic
>>> simulations in an idiomatic, functional way?
>>>
>>> --
>>> 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.
>>
>
>
>
> --
> Kind Regards,
> Atamert Ölçgen
>
> -+-
> --+
> +++
>
> www.muhuk.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 i

Re: Content-negotiation in compojure web libraries/frameworks the right way (tm)

[Nils Grunwald]

You can take a look at https://github.com/ngrunwald/ring-middleware-format 
which tries to handle content negociation only in a sane and flexible way 
for REST api.

On Wednesday, November 5, 2014 2:47:02 PM UTC+1, Miguel Ping wrote:
>
> Hi all,
>
> What's the best way to do content-negotiation on compojure-based web 
> frameworks? I know liberator deals with it in a special way, I was 
> wondering if is there anything out there to deal with it like rails does.
> Right now I have a big cond:
>
> (defn handle-home [req]
>   (let [content-type (-> (clojure.walk/keywordize-keys req) :headers 
> :content-type)]
> (cond  (empty? content-type)
>(home-page) ;renders selmer
>
>(= "application/json" content-type)
>(generate-string (db/get-messages)) ;cheshire json generation
>
>:else
>{:status 415 :body "unavailable-content-type"})))
>
> But I'm pretty sure there's a more idiomatic way of defining resources. 
> I'd like a way to just return a hash, and according to content-type either 
> render an html (through selmer, whatever) or a json from that map.
> I'm sure this is pretty easy with clojure but I'm still quite new to it. 
> I'd like to see how you guys are dealing with this.
> I'm trying luminus right now but I'm guessing this is the same for any 
> compojure-based routing.
>

-- 
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: Content-negotiation in compojure web libraries/frameworks the right way (tm)

[Herwig Hochleitner]

Liberator is very helpful for this:
http://clojure-liberator.github.io/liberator/

2014-11-05 14:47 GMT+01:00 Miguel Ping :

> Hi all,
>
> What's the best way to do content-negotiation on compojure-based web
> frameworks? I know liberator deals with it in a special way, I was
> wondering if is there anything out there to deal with it like rails does.
> Right now I have a big cond:
>
> (defn handle-home [req]
>   (let [content-type (-> (clojure.walk/keywordize-keys req) :headers
> :content-type)]
> (cond  (empty? content-type)
>(home-page) ;renders selmer
>
>(= "application/json" content-type)
>(generate-string (db/get-messages)) ;cheshire json generation
>
>:else
>{:status 415 :body "unavailable-content-type"})))
>
> But I'm pretty sure there's a more idiomatic way of defining resources.
> I'd like a way to just return a hash, and according to content-type either
> render an html (through selmer, whatever) or a json from that map.
> I'm sure this is pretty easy with clojure but I'm still quite new to it.
> I'd like to see how you guys are dealing with this.
> I'm trying luminus right now but I'm guessing this is the same for any
> compojure-based routing.
>
> --
> 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.

Content-negotiation in compojure web libraries/frameworks the right way (tm)

[Miguel Ping]

Hi all,

What's the best way to do content-negotiation on compojure-based web 
frameworks? I know liberator deals with it in a special way, I was 
wondering if is there anything out there to deal with it like rails does.
Right now I have a big cond:

(defn handle-home [req]
  (let [content-type (-> (clojure.walk/keywordize-keys req) :headers 
:content-type)]
(cond  (empty? content-type)
   (home-page) ;renders selmer

   (= "application/json" content-type)
   (generate-string (db/get-messages)) ;cheshire json generation

   :else
   {:status 415 :body "unavailable-content-type"})))

But I'm pretty sure there's a more idiomatic way of defining resources. I'd 
like a way to just return a hash, and according to content-type either 
render an html (through selmer, whatever) or a json from that map.
I'm sure this is pretty easy with clojure but I'm still quite new to it. 
I'd like to see how you guys are dealing with this.
I'm trying luminus right now but I'm guessing this is the same for any 
compojure-based routing.

-- 
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: Neighbors function from The Joy of Clojure

[Mark Nutter]

​Forgot to add that my usual recommendation is Clojure in Action followed
by The Joy of Clojure. Killer combo.​

On Wed, Nov 5, 2014 at 7:34 AM, Mark Nutter  wrote:

> A bit off the original topic, but this seemed like a good place to give a
> shout out to my favorite intro book: Clojure In Action (
> http://www.manning.com/rathore/). There are a lot of really excellent
> intro books out there, and I don't want to disparage any of them, but I
> found this one very readable. I think there's a 2nd edition in the works to
> bring it up to date too.
>
> On Tue, Nov 4, 2014 at 8:57 PM, Pierre Thibault <
> pierre.thibau...@gmail.com> wrote:
>
>> Ouch! I found this code hard to understand. I read to previous part of
>> the book. I guess it is normal when you are new to Clojure?
>>
>> --
>> 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: Neighbors function from The Joy of Clojure

[Mark Nutter]

A bit off the original topic, but this seemed like a good place to give a
shout out to my favorite intro book: Clojure In Action (
http://www.manning.com/rathore/). There are a lot of really excellent intro
books out there, and I don't want to disparage any of them, but I found
this one very readable. I think there's a 2nd edition in the works to bring
it up to date too.

On Tue, Nov 4, 2014 at 8:57 PM, Pierre Thibault 
wrote:

> Ouch! I found this code hard to understand. I read to previous part of the
> book. I guess it is normal when you are new to Clojure?
>
> --
> 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: Deterministic Randomness in Functional Clojure

[Mikera]

You may find that wrapping a random number generator as a lazy sequence is 
a useful approach - it is functional and works nicely in an idiomatic 
clojure style where you can "take" as many random numbers as you need while 
treating the whole sequence as an immutable value.

I have an (experimental) implementation of this approach in 
core.matrix.stats, see:

https://github.com/clojure-numerics/core.matrix.stats/blob/develop/src/main/clojure/clojure/core/matrix/random.clj

On Wednesday, 29 October 2014 03:08:55 UTC+8, Isaac Karth wrote:
>
> I've been working on some projects (roguelikes, story-generators) that 
> often have a reason to have a random outcome for things like procedurally 
> generating a map. Ideally, they would be deterministically psuduorandom, so 
> that I can generate the same results from the same seed. The part I'm 
> having trouble with is figuring out what method to use to implement this in 
> a functional way.
>
> The naive approach that first occurred to me was to pass a PRNG and seed 
> value into each function. That would certainly keep the functions 
> referentially transparent. But it would also require either rewriting a 
> bunch of functions that don't directly use the randomness themselves or 
> adding the RNG as part of the map that's already being passed. 
>
> Plus, the seed should probably vary (deterministically) between calls to 
> the subfunctions. It's not too useful if all the rooms on a map have the 
> same type because they all pulled their die roll from the same-nth result 
> of the exact same seed. Maybe the seed could be created from the contents 
> of the vector or a UUID of a map object or something?
>
> The other suggestion I've run across is to rebind something like 
> clojure.data.generators/*rnd* for each high-level procedural generation 
> call. I think this requires the generation to be single threaded and 
> otherwise deterministic. At the moment I don't feel like I know enough 
> about how things work under the hood to say if this a good idea or not.
>
> I've poked around at the bigml.sampling and clojure.data.generators 
> libraries, which look useful for dealing with some of this, but I haven't 
> come across anything that directly addresses what kind of architecture to 
> use for deterministic randomness. This may be my inexperience. I feel like 
> I may be a bit too close to the problem, and I can't quite see what the 
> idiomatic answer is. Re-read SICP? Implement some kind of monad? Just bite 
> the bullet and pass the RNG+seed? Find the secret pure functional library 
> everyone is using for repeatable stochastic simulations?
>
> Does anyone have any advice on this? Or prior experience with approaches 
> that work? What are some best practices for approaching deterministic 
> simulations in an idiomatic, functional way?
>

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

Dependency problem between clj-http and com.cemerick/friend

[Christian Egli]

Hi all

I have a strange interaction between clj-http and com.cemerick/friend. I
don't know if this is a problem in either of the two packages or maybe
even Leiningen.

The problem is very easy to reproduce. Create a project with `lein new`,
add dependencies to clj-http and com.cemerick/friend, start a repl and
simpy require clj-http.client as follows:

$ lein new app friend-and-clj-http
$ cd friend-and-clj-http
$ # add clj-http and friend as a dependency to project.clj
$ lein repl
friend-and-clj-http.core=> (require '[clj-http.client :as client])

If the dependency to friend is before the dependency to clj-http you
will get the following exception:

CompilerException java.lang.ClassNotFoundException: 
org.apache.http.conn.ssl.SSLContexts, compiling:(clj_http/conn_mgr.clj:1:1)

However if you change the order of the dependencies everything works as
expected.

$ # change the order of the dependencies
$ lein repl
friend-and-clj-http.core=> (require '[clj-http.client :as client])
nil
friend-and-clj-http.core=> Bye for now!

I put both versions of project.clj, the shell session and the output of
`lein deps :tree` for both versions in public gists

- https://gist.github.com/egli/8e6086f4d35ff7c11f80 project.clj with
  friend and clj-http as dependencies
- https://gist.github.com/egli/ff26669047b9273741c6 project.clj with
  clj-http and friend as dependencies 
- https://gist.github.com/egli/076b4f450cc237e2ac4a shell session
- https://gist.github.com/egli/b3e149aded64c7628f8e lein deps :tree with
  friend before clj-http
- https://gist.github.com/egli/4fa13bc791e52061f9e9 lein deps :tree with
  clj-http before friend

Where do I report this problem?

Thanks
Christian

-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

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

Re: how clojure infers types.

[Phillip Lord]

Ah, okay. I thought it might be this.

Not that I don't trust you, though, but how do you know this? Is there a
good way of finding out what clojure has infered or not? tools.analyzer?
I'm thinking from a point of view of the developer trying to get his
type hints sorted.

Phil

Nicola Mometto  writes:

> The reason why that call doesn't require reflection is that
> Collection.unmodifiableSet has no overloaded methods, it only takes a
> Set so the compiler doesn't have to disambiguate between different
> signatures.
>
> Phillip Lord writes:
>
>> Yes, I checked the code.
>>
>> (defn set
>>   "Returns a set of the distinct elements of coll."
>>   {:added "1.0"
>>:static true}
>>   [coll] (clojure.lang.PersistentHashSet/create (seq coll)))
>>
>> And that was my first assumption. But if clojure doesn't know the return
>> type, then why does this:
>>
>> (defn two []
>>   (java.util.Collections/unmodifiableSet
>>(set [])))
>>
>> Not require reflection? Clojure should not know which method to call.
>> Unless it is just because unmodifiableSet has an arity of one and it's
>> the only arity of one, so it doesn't try to disambiguate.
>>
>> I guess even if set was type hinted (to IPersistentSet) it would still
>> not work since, IPersistentSet is not assignable from java.util.Set.
>>
>> Phil
>>
>>
>>
>> Nicola Mometto  writes:
>>
>>> Actually `set` and a lot of other clojure.core functions are neither
>>> inlineable nor have type hints.
>>>
>>> Phillip Lord writes:
>>>
 I have a piece of code that looks like this

 (.getOWLEquivalentClassesAxiom
   (owl-data-factory)
   (set classlist)
   (union-annotations classlist))

 The method signature is

 getOWLEquivalentClassesAxiom(Set,Set)

 On runing lein check I get


 Reflection warning, tawny/owl.clj:2219:6 - call to method
 getOWLEquivalentClassesAxiom on
 org.semanticweb.owlapi.model.OWLDataFactory can't be resolved (argument
 types: unknown, java.util.Set).

 which makes no sense. Surely, the return type of clojure.core/set is
 known to be java.util.Set? I have quite a few calls like this in my
 code, which is why I don't want to type hint the return of set
 individually.

 If I add a function like so:

 (defn ^java.util.Set hset [coll]
   (set coll))

 and call like this:

 (.getOWLEquivalentClassesAxiom
   (owl-data-factory)
   (hset classlist)
   (union-annotations classlist))

 The reflection warning goes away.


 I've tried to reproduce this with simpler cases, like so:


 (defn one []
   (java.util.Collections/unmodifiableSet
(java.util.HashSet.)))


 (defn two []
   (java.util.Collections/unmodifiableSet
(set [])))

 But both of these pass lein check just fine. Which suggests that clojure
 knows set returns a java.util.Set object.

 Now, given that I can't give a simple test case, I realise that it's
 hard for anyone to work out what is happening. But, worse, I don't know
 how to debug this at all. So, how I find out what clojure things the
 return type of a function is? Or probe any further why this is failing?

 Phil
>>>
>>> --
>>
>> --
>> Phillip Lord,   Phone: +44 (0) 191 222 7827
>> Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
>> School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord
>> Room 914 Claremont Tower,   skype: russet_apples
>> Newcastle University,   twitter: phillord
>> NE1 7RU
>
> --

-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
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: Neighbors function from The Joy of Clojure

[Gary Verhaegen]

On Wednesday, 5 November 2014, Pierre Thibault 
wrote:

> Ouch! I found this code hard to understand. I read to previous part of the
> book. I guess it is normal when you are new to Clojure?
>

Yes. It will become easier with experience. That piece of code looks very
explicit and readable to me, although I remember that when I first read the
book, with no other Clojure experience, it was indeed a bit hard to decode.

-- 
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: About transients no longer being safe in 1.7-alpha2

[Daniel Marjenburgh]

Hi Atamert, yes, that is also wrong usage that is not caught. I do want to 
focus on the current change though.

So the thought behind this change is that the birth-thread check was 
unnecessary or too strict from the beginning and people should just use 
transients correctly, caveat implementor. No more kids gloves.

There is a paragraph  dedicated to 
enforcement of thread-isolation, which I think is great. I also understand 
we want to give programmers more flexibility in using transients in other 
(mutlithreaded) contexts where the user knows it will be safe. I just think 
throwing away the entire safeguard is overkill and it's making unsafe 
Clojure code not only really easy, but even the default in the case of 
transients. All programs not using core.async could benefit from the 
owner-check.

Again, like Alex suggested, a flag like (transient m {} :thread-isolated? 
false) or something (with the default to true) would at least ease my mind 
a bit. It would also alert programmers in core async when they see it, that 
they need to make sure only one logical thread should have access.


>> But they would run fine, if you used delay's instead of future's. Same 
> wrong usage, single threaded. So the issue is not really this new change.
>
> (See my code with delay's earlier) 
>
>  

-- 
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: Deterministic Randomness in Functional Clojure

[Laurens Van Houtven]

On 05 Nov 2014, at 04:22, Fluid Dynamics  wrote:

> Terminal emulation? In this day and age?

Yes. Many people write and play explicitly retro games :-)

hth
lvh


signature.asc
Description: Message signed with OpenPGP using GPGMail