Caching an anon function

[Phillip Lord]

I want to pass a java method call to a function. So instead of this:


(defn call-method []
  (.getCanonicalName Object))


I have something like this...

(defn indirect-call [f clazz]
  (f clazz))

(defn indirect-call-memfn []
  (indirect-call (memfn ^java.lang.Class getCanonicalName) Object))

(defn indirect-call-anon []
  (indirect-call #(.getCanonicalName ^java.lang.Class %) Object))

I am not sure which is faster yet, but either should work. But,
performance-wise I am creating a new function for every call (the
anonymous function) when I only ever need one. Which isn't idea.

One solution would be this:

(def indirect-call-memfn-cached
  (let [f (memfn ^java.lang.Class getCanonicalName)]
(fn []
  (indirect-call f Object

(def indirect-call-anon-cached
  (let [f #(.getCanonicalName ^java.lang.Class %)]
(fn []
  (indirect-call f Object


Or, if I want to stay using defn the slightly evil looking:

(let [f #(.getCanonicalName ^java.lang.Class %)]
  (defn indirect-call-defn-anon-cached[]
(indirect-call f Object)))


Which seems to work, but is fairly horrible syntactically.

I have thought about writing a macro which I might call "one-fn" which
looks like fn but caches. The best I have come up with is to turn the
contents of the &form variable into a hash, and store the functions in
global state. So something like this...

(one-fn [x] (.getCanonicalName x))


At run time we would have something like

(if-let [f (get &one-fn-state 423432423)]
  f
  (let [r (fn [x] (.getCanonicalName x))]
  (swap! one-fn-state assoc 423432423 r)
  r))
   

I can see some nasty edge cases where this will break, of course. But
most of all, I wonder whether I am missing something obvious that would
be far better. In the ideal world, I'd like one-fn to affect the
compiled code, so that a single instance is shared, but I can't see a
way to achieve this.

Thoughts? Has it already been done?

Phil

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

[Patch] Support for DOCTYPE when emitting XML (DXML-10)

[Christian Egli]

Hi 

Currently data.xml doesn't currently support the specification of
doctypes when emitting XML (see
http://dev.clojure.org/jira/browse/DXML-10). I created a patch to
support this. Now it appears that data.xml is in the midst of a big
refactoring so I'm wondering if and how I should attach the patch to the
jira bug.

The patch basically just adds another option to emit, emit-str, indent
and indent-str which allows to specify the doctype declaration. It then
simply delegates to the underlying XMLStreamWriter by invoking .writeDTD
if there is a doctype. 

The patch can be found at
https://github.com/egli/data.xml/compare/clojure:master...master?diff=unified.

Signing the CA will take a bit of time, so I thought I could get the
conversation already started while the legal process is under way.

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: CCW bug [SEVERE]

[Colin Yates]

+1. When I first read that post I thought he was joking!

On Tuesday, 28 October 2014 16:19:29 UTC, Marcus Blankenship wrote:
>
> Agreed.  I've been amazed at how kind this group has been, despite your 
> attitude of disrespect toward them.  
>
> On Tue, Oct 28, 2014 at 9:09 AM, Dylan Butman  > wrote:
>
>> From your attitude and lack of respect for the very knowledgeable, 
>> experienced, and respectful people here trying to help improve and 
>> understand the short comings in your current workflow, I'd say you might be 
>> walking to work in the near future. Parking's free that way.
>>
>> On Monday, October 27, 2014 3:15:38 PM UTC-4, Fluid Dynamics wrote:
>>>
>>> On Monday, October 27, 2014 11:45:47 AM UTC-4, tbc++ wrote:

 Whenever someone has suggested something (using git, submitting a bug 
 report), you've replied (paraphrase) "meh, I can't be bothered".

>>>
>>> The former suggestion, especially, seems excessively heavyweight for the 
>>> particular circumstances. Like suggesting I trade in my Miata for an 
>>> armored Brinks van for driving to work, because of the small chance of 
>>> crossing paths with terrorists along the way. While neglecting other 
>>> considerations, such as the vehicle's top speed and fuel economy among 
>>> other things ... not to mention whether it will still fit in my parking 
>>> space. :)
>>>
>>  -- 
>> 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.
>>
>
>
>
> -- 
>
> Marcus Blankenship
>
> CREO Agency: {Solutions Architect, Principal}
>
> mar...@creoagency.com 
>
> 541-805-2736
>
> @justzeros
>  

-- 
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: Caching an anon function

[Mars0i]

Phil, I think your post accidentally ended up in the wrong place.  I 
believe you intended to create a new thread.

On Friday, October 31, 2014 4:55:39 AM UTC-5, Phillip Lord wrote:
>
>
>
> I want to pass a java method call to a function. So instead of this: 
> ...
>

-- 
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: Caching an anon function

[Phillip Lord]

Oh, dear, did I leave a trailing reference in my headers?

Mars0i  writes:

> Phil, I think your post accidentally ended up in the wrong place.  I 
> believe you intended to create a new thread.
>
> On Friday, October 31, 2014 4:55:39 AM UTC-5, Phillip Lord wrote:
>>
>>
>>
>> I want to pass a java method call to a function. So instead of this: 
>> ...
>>

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

Software Engineer (Clojure) opportunity in Redwood City, CA

[Grant Du Plooy]

I don't know whether this group permits job posts, so this will be a 
one-time post.

Yummly, a growing startup in the food tech revolution, has an exciting 
opportunity for a Software Engineer (Clojure) to work on various components 
of Yummly's service-oriented system that powers our website and mobile 
apps. 

Yummly's iOS app is already the #1 recipe app, and our site receives 15M 
monthly unique visitors. Details here: http://jobsco.re/1uhrReN

Regards, Grant
gr...@yummly.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: [Patch] Support for DOCTYPE when emitting XML (DXML-10)

[Andy Fingerhut]

Christian, thanks for working on the enhancements.

It might be easiest to wait until the dust settles on the other big changes
in the works right now.  You could also contact Herwig Hochleitner (
hhochleit...@gmail.com), who is developing those other data.xml changes,
and ask him if perhaps the portions of code you are working on might be
independent.

Andy

On Fri, Oct 31, 2014 at 4:30 AM, Christian Egli 
wrote:

> Hi
>
> Currently data.xml doesn't currently support the specification of
> doctypes when emitting XML (see
> http://dev.clojure.org/jira/browse/DXML-10). I created a patch to
> support this. Now it appears that data.xml is in the midst of a big
> refactoring so I'm wondering if and how I should attach the patch to the
> jira bug.
>
> The patch basically just adds another option to emit, emit-str, indent
> and indent-str which allows to specify the doctype declaration. It then
> simply delegates to the underlying XMLStreamWriter by invoking .writeDTD
> if there is a doctype.
>
> The patch can be found at
>
> https://github.com/egli/data.xml/compare/clojure:master...master?diff=unified
> .
>
> Signing the CA will take a bit of time, so I thought I could get the
> conversation already started while the legal process is under way.
>
> 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: Software Engineer (Clojure) opportunity in Redwood City, CA

[Michael Klishin]

 On 31 October 2014 at 17:13:15, Grant Du Plooy (gr...@tolfrey.com) wrote:
> Yummly's iOS app is already the #1 recipe app, and our site receives  
> 15M monthly unique visitors. Details here:http://jobsco.re/1uhrReN  

Grant,

Many potential candidates would greatly appreciate if you clarify your policy
regarding remote work. Are remote candidates welcomed? If so, what time zones 
are OK?
--  
@michaelklishin, github.com/michaelklishin

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

On Testing

[Ashton Kemerling]

I tweeted recently that I thought that Clojure is super testable, and I was 
genuinely surprised about the number of people who disagreed with me. 

There's been a lively discussion about what the best testing frameworks in 
clojure currently are, and what the built in solutions (clojure.test and 
test.check) are lacking. While a lot of people recommend midje or expectations, 
I generally prefer the built in options (no offense to contributors of either 
of those libraries) and usually recommend people stick with clojure.test for 
its lack of magic. 


It's my opinion that these two libraries are largely complete aside from some 
human interface improvements (quality of output for example), but clearly not 
everyone agrees with me. 


So let's talk about what we could add to make the clojure testing experience 
superior compared to other languages.

-- 
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: [Patch] Support for DOCTYPE when emitting XML (DXML-10)

[Herwig Hochleitner]

Hi Christian,

your patch looks, like it should be straightforward to port to my work, but
it won't apply as is, since I moved the emitter into its own namespace.
I can take care of that, as soon as your CA goes through. Of course, I'd
also welcome a patch based on my branch ;-)

cheers

-- 
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: On Testing

[Ashton Kemerling]

I don't want to speak for others, I notified everyone involved on Twitter that 
I made this thread so they can voice their own complaints.

On Fri, Oct 31, 2014 at 9:02 AM, László Török  wrote:

> "I tweeted recently that I thought that Clojure is super testable, and I
> was genuinely surprised about the number of people who disagreed with me."
> My 2c.
> Without explicitly citing those complaints, it will be difficult to conduct
> a meaningful debate.
> 2014-10-31 14:52 GMT+00:00 Ashton Kemerling :
>>  I tweeted recently that I thought that Clojure is super testable, and I
>> was genuinely surprised about the number of people who disagreed with me.
>>
>> There's been a lively discussion about what the best testing frameworks in
>> clojure currently are, and what the built in solutions (clojure.test and
>> test.check) are lacking. While a lot of people recommend midje or
>> expectations, I generally prefer the built in options (no offense to
>> contributors of either of those libraries) and usually recommend people
>> stick with clojure.test for its lack of magic.
>>
>> It's my opinion that these two libraries are largely complete aside from
>> some human interface improvements (quality of output for example), but
>> clearly not everyone agrees with me.
>>
>> So let's talk about what we could add to make the clojure testing
>> experience superior compared to other languages.
>>
>>  --
>> 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.
>>
> -- 
> László Török
> Checkout justonemorepoint.com - Know your true value
> -- 
> 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: On Testing

[László Török]

"I tweeted recently that I thought that Clojure is super testable, and I
was genuinely surprised about the number of people who disagreed with me."

My 2c.

Without explicitly citing those complaints, it will be difficult to conduct
a meaningful debate.

2014-10-31 14:52 GMT+00:00 Ashton Kemerling :

>  I tweeted recently that I thought that Clojure is super testable, and I
> was genuinely surprised about the number of people who disagreed with me.
>
> There's been a lively discussion about what the best testing frameworks in
> clojure currently are, and what the built in solutions (clojure.test and
> test.check) are lacking. While a lot of people recommend midje or
> expectations, I generally prefer the built in options (no offense to
> contributors of either of those libraries) and usually recommend people
> stick with clojure.test for its lack of magic.
>
> It's my opinion that these two libraries are largely complete aside from
> some human interface improvements (quality of output for example), but
> clearly not everyone agrees with me.
>
> So let's talk about what we could add to make the clojure testing
> experience superior compared to other languages.
>
>  --
> 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.
>



-- 
László Török
Checkout justonemorepoint.com - Know your true value

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

Hi,


I too, am super interested in games in Clojure. My other background is 
cryptography, so I break out the crypto. I would say that you don’t really want 
a PRG, but you might want a PRF instead. (If that doesn’t mean anything to you, 
don’t worry, read on.)

My favorite cryptographic hash function, BLAKE2, has a number of cool features 
that might help. If you have some description of the thing that you want and a 
random seed, you can produce a number from which you can then go on and 
generate whatever you want. This answers your “sub-seed” question: 
blake2(master_seed, “room 1”) and blake2(master_seed, “room 2”) will be 
completely different values. However, you can compute blake2(master_seed, “room 
1”) at any later point, and it will still be the same value. This makes all of 
the problems of sharing, ordering… go away. No more state :)

This does mean passing a seed around in your game state, but it seems evident 
to me that your seed is indeed a fundamental property of your game state, so I 
don’t think that’s a bad thing.

While BLAKE2 is of course significantly stronger than what you need for a game, 
it is ridiculously fast [1]. In case you’re worried about speed (you most 
likely shouldn’t be), SipHash is still significantly stronger than what you 
need (nearly cryptographic strength), but is competitive in speed with 
non-cryptographic hash functions like CityHash, Murmur2/3

Neither BLAKE2 nor SipHash nor other PRFs typically come with the randomness 
utility features you would typically want, like random selection, weighted 
random selection, random variable according to a distribution… Hopefully those 
things are available in a way that lets you separate the concern of “generate n 
pseudorandom bits” and “use those bits to produce a value”. Of course, other 
PRNG algorithms like MT also don’t solve this problem: they just give you some 
random-looking bytes, just like BLAKE2/SipHash :)

BLAKE2 is exposed with a nice Clojure API through my caesium library. I don’t 
know of any easily available SipHash implementations, but I can’t imagine it’s 
very hard to get it running. There’s a Java implementation, and various Lisp 
implementations that shouldn’t be terribly hard to port to Clojure.

[1]: https://blake2.net/
[2]: https://131002.net/siphash/


hth
lvh


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: On Testing

[Eli Naeher]

On Fri, Oct 31, 2014 at 9:52 AM, Ashton Kemerling  wrote:


> It's my opinion that these two libraries are largely complete aside from
> some human interface improvements (quality of output for example), but
> clearly not everyone agrees with me.
>

Hi Ashton,

Check out https://github.com/pjstadig/humane-test-output if you haven't
already seen it, it's a nice improvement over the default output--in
particular seeing the specific diffs between expected and actual values is
really useful when you are dealing with collections.

-Eli

-- 
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: On Testing

[Jessica Kerr]

My top wish it more readable output from test.check when running within 
clojure.test

In particular, I want to know the value of each generated parameter at the 
first failure, and at the simplest failure. Currently that prints as part 
of a map, but if empty-string is generated, that does not show. (Forking 
and) printing with pr-str improves it, but I'd like to do a lot more with 
that.

-- 
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: On Testing

[Lucas Bradstreet]

I totally agree about pr-str in test.check. Quite often I want to copy and 
paste the failure into a repl and play around, but need to re-add missing 
quotation marks or quote lists. 

> On 31 Oct 2014, at 22:05, Jessica Kerr  wrote:
> 
> My top wish it more readable output from test.check when running within 
> clojure.test
> 
> In particular, I want to know the value of each generated parameter at the 
> first failure, and at the simplest failure. Currently that prints as part of 
> a map, but if empty-string is generated, that does not show. (Forking and) 
> printing with pr-str improves it, but I'd like to do a lot more with that.
> -- 
> 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: Software Engineer (Clojure) opportunity in Redwood City, CA

[Grant Du Plooy]

Hi Michael,

Good point, thank you for mentioning it. Unfortunately we are not hiring
remote workers at this time. This role is fulltime on site in Redwood City,
California.

Regards, Grant

On Fri, Oct 31, 2014 at 7:23 AM, Michael Klishin <
michael.s.klis...@gmail.com> wrote:

>  On 31 October 2014 at 17:13:15, Grant Du Plooy (gr...@tolfrey.com) wrote:
> > Yummly's iOS app is already the #1 recipe app, and our site receives
> > 15M monthly unique visitors. Details here:http://jobsco.re/1uhrReN
>
> Grant,
>
> Many potential candidates would greatly appreciate if you clarify your
> policy
> regarding remote work. Are remote candidates welcomed? If so, what time
> zones are OK?
> --
> @michaelklishin, github.com/michaelklishin
>
>


-- 


*Grant Du PlooyTolfrey Group510-315-0565*

-- 
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 Survey 2014 - Tag Clouds

[John Gabriele]

Neat!

I notice that in the results for "name one language feature you'd like to 
see added", the following items show up separately, though should probably 
be combined: StartupTime, FasterStartup, FastStartup, StartTime, 
CompileTime.

Similarly, in "most glaring weakness", lumped together are StartupTime, 
JvmStartup, LongStartupTime, LongStartup, StartupSpeed, StartTime, 
CompileTime, SlowStartup.

-- John


On Wednesday, October 29, 2014 10:00:22 AM UTC-4, juan.facorro wrote:
>
> Hi All,
>
> In case someone was interested in the results and how I got to them, I 
> wrote an article about my attempt to visualize the free-form text answers 
> from Clojure’s (and ClojureScript) Community Survey 2014.
>
> Any comments, suggestions or questions are welcome.
>
> Clojure Survey 2014 - Tag Clouds 
> 
>
> Cheers!
>
> Juan
>

-- 
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: extending custom data types to clojure core abstractions

[Daniel]

Brian, this may help: https://github.com/ztellman/collection-check

On Tuesday, October 28, 2014 2:24:48 PM UTC-5, Brian Craft wrote:
>
> Following up on the thread about the massive overhead of String, I tried 
> writing a string collection type that stores strings as bytes, converting 
> to String on-demand. It seems to work. Memory footprint and performance are 
> good for the application.
>
> The hard part was trying to track down the correct interfaces and 
> invocations. I note that "Clojure Programming" makes the same observation 
> in the section about clojure abstractions: "such things are largely 
> undocumented". I guess this situation hasn't improved? I had to proceed 
> mostly by experimentation, and am still unclear on, for example, why I 
> needed to use an interop call in some places (like cons), but should not in 
> others.
>
> Would be happy for any feedback on this attempt:
>
> (deftype StringVec [pv]
>   clojure.lang.IPersistentVector
>   (seq [self] (map #(String. ^bytes %) pv))
>   (nth [self i] (String. ^bytes (.nth ^clojure.lang.IPersistentVector pv 
> i)))
>   (nth [self i notfound] (String. ^bytes (.nth 
> ^clojure.lang.IPersistentVector pv i (.getBytes ^String notfound
>   clojure.lang.ILookup
>   (valAt [self i] (when-let [res (.valAt ^clojure.lang.IPersistentVector 
> pv i)]
> (String. ^bytes res)))
>   (valAt [self i notfound] (String. ^bytes (.valAt 
> ^clojure.lang.IPersistentVector pv i (.getBytes ^String notfound
>   clojure.lang.ISeq
>   (first [self] (String. ^bytes (first pv)))
>   (next [self] (->StringVec (next pv)))
>   (more [self] (->StringVec (rest pv)))
>   (cons [self s] (->StringVec (.cons ^clojure.lang.IPersistentVector pv 
> (.getBytes ^String s
>   (count [self] (count pv))
>   Object
>   (toString [self] (str (into [] self
>
> (defn stringvec [coll]
>   (into (->StringVec []) coll))
>
> (defmethod print-method StringVec [v, ^java.io.Writer w]
>   (.write w (.toString ^StringVec v)))
>
> Speak of cons, I gather ISeq cons is unrelated to cons, the function, but 
> rather is required for conj?
>
>

-- 
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: extending custom data types to clojure core abstractions

[Brian Craft]

Nice, thanks!

On Friday, October 31, 2014 9:59:26 AM UTC-7, Daniel wrote:
>
> Brian, this may help: https://github.com/ztellman/collection-check
>
> On Tuesday, October 28, 2014 2:24:48 PM UTC-5, Brian Craft wrote:
>>
>> Following up on the thread about the massive overhead of String, I tried 
>> writing a string collection type that stores strings as bytes, converting 
>> to String on-demand. It seems to work. Memory footprint and performance are 
>> good for the application.
>>
>> The hard part was trying to track down the correct interfaces and 
>> invocations. I note that "Clojure Programming" makes the same observation 
>> in the section about clojure abstractions: "such things are largely 
>> undocumented". I guess this situation hasn't improved? I had to proceed 
>> mostly by experimentation, and am still unclear on, for example, why I 
>> needed to use an interop call in some places (like cons), but should not in 
>> others.
>>
>> Would be happy for any feedback on this attempt:
>>
>> (deftype StringVec [pv]
>>   clojure.lang.IPersistentVector
>>   (seq [self] (map #(String. ^bytes %) pv))
>>   (nth [self i] (String. ^bytes (.nth ^clojure.lang.IPersistentVector pv 
>> i)))
>>   (nth [self i notfound] (String. ^bytes (.nth 
>> ^clojure.lang.IPersistentVector pv i (.getBytes ^String notfound
>>   clojure.lang.ILookup
>>   (valAt [self i] (when-let [res (.valAt ^clojure.lang.IPersistentVector 
>> pv i)]
>> (String. ^bytes res)))
>>   (valAt [self i notfound] (String. ^bytes (.valAt 
>> ^clojure.lang.IPersistentVector pv i (.getBytes ^String notfound
>>   clojure.lang.ISeq
>>   (first [self] (String. ^bytes (first pv)))
>>   (next [self] (->StringVec (next pv)))
>>   (more [self] (->StringVec (rest pv)))
>>   (cons [self s] (->StringVec (.cons ^clojure.lang.IPersistentVector pv 
>> (.getBytes ^String s
>>   (count [self] (count pv))
>>   Object
>>   (toString [self] (str (into [] self
>>
>> (defn stringvec [coll]
>>   (into (->StringVec []) coll))
>>
>> (defmethod print-method StringVec [v, ^java.io.Writer w]
>>   (.write w (.toString ^StringVec v)))
>>
>> Speak of cons, I gather ISeq cons is unrelated to cons, the function, but 
>> rather is required for conj?
>>
>>

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

CCW bug [SEVERE]

[Laurent PETIT]

Hello,

I'm the main CCW developer.
I have double checked the source code, and can confirm that the save
mechanism is handled by Eclipse. So one can expect it to be as stable as
every other save action performed in the Eclipse IDE.

There are a number of listeners that are triggered after the Save action
has completed.  It's most probably after the save, and presumably inside
one of those listeners, that the hang occured.

A central goal of CCW is to be as stable as possible. So if you are able to
describe how to deterministically reproduce the issue, then please create
an issue and put the description there. Also, if you can attach the
workspace's .metadata/.log file, I can take a look at it.

Link for creating a new issue :
https://code.google.com/p/counterclockwise/issues/entry

Please try to adopt a neutral language, leaving out the sarcasms and
implicit/explicit injonctions, etc. Those are totally inappropriate. Being
a "user" of a "service" does not give you the right to act like that. To
that matter, it is even irrelevant that the service is paid for, or free. I
know not everybody is equal with regards to how to best communicate, but it
can be learned. Listen to the advices given in this thread.

Cheers,

Laurent






2014-10-26 3:38 GMT+01:00 Fluid Dynamics >:

> Would somebody mind explaining to me why I just had CCW 0.28.1.STABLE001
> hang with 100% CPU usage when I edited this line:
>
>   :=  (= v cr
>
> to this:
>
>   =   (= v cr
>
> and then hit control-S?
>
> I do not ever want to see anything purportedly "STABLE" do something like
> that ever again, and that goes *one trillionfold* if it's IN THE MIDDLE OF
> A GODDAMN SAVE. What if my file had been corrupted, or truncated and only
> the first 42 bytes of the new version written thus far, or something like
> that at the moment when the hang started? Fortunately, in this instance
> that had not happened and the file seems to have been saved completely just
> *before* the hang. I might not be so lucky next time. That is why this
> cannot be permitted to happen again, and why therefore an explanation is
> required, and urgently, that I might be perfectly able to avoid triggering
> this severe, showstopping, and inexcusable bug again until such time as an
> 0.29.1 is published that has it permanently fixed.
>
>  --
> 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.
>



-- 
Laurent Petit


-- 
Laurent Petit

-- 
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 Survey 2014 - Tag Clouds

[juan.facorro]

*Plinio: *Thanks!

*John: *Hi!

I noticed that as well but I couldn't figure out an approach that would 
unify those terms, other than going through each of them and identifying 
the ones that are equivalent. Maybe grouping by the distance between any 
two terms? Or maybe if the ratio between the distance and the length of the 
terms is below a specific value? Do you have any suggestions?

I guess it's just a matter of trying out these ideas and checking if the 
results makes any sense :P

Thanks!

Juan

On Friday, October 31, 2014 1:26:31 PM UTC-3, John Gabriele wrote:
>
> Neat!
>
> I notice that in the results for "name one language feature you'd like to 
> see added", the following items show up separately, though should probably 
> be combined: StartupTime, FasterStartup, FastStartup, StartTime, 
> CompileTime.
>
> Similarly, in "most glaring weakness", lumped together are StartupTime, 
> JvmStartup, LongStartupTime, LongStartup, StartupSpeed, StartTime, 
> CompileTime, SlowStartup.
>
> -- John
>
>
> On Wednesday, October 29, 2014 10:00:22 AM UTC-4, juan.facorro wrote:
>>
>> Hi All,
>>
>> In case someone was interested in the results and how I got to them, I 
>> wrote an article about my attempt to visualize the free-form text answers 
>> from Clojure’s (and ClojureScript) Community Survey 2014.
>>
>> Any comments, suggestions or questions are welcome.
>>
>> Clojure Survey 2014 - Tag Clouds 
>> 
>>
>> Cheers!
>>
>> Juan
>>
>

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

io/writer + map/recur

[Sam Raker]

I'm writing some stuff to interact with the Twitter API. I want to be able 
to write tweets (as JSON) to a file, so I can, e.g., test things without 
connecting to the API. I've proxied the LinkedBlockingQueue that Twitter's 
HBC library uses to use an agent, so ideally I want to be able to write the 
contents of the agent AND the LBQ. Here's what I have right now:

(defmulti write-tweets (fn [q f] (class q)))
(defmethod write-tweets clojure.lang.Agent [a f]
  (with-open [w (clojure.java.io/writer f :append true)]
(.write w (apply str (interpose "\n" @a)
(defmethod write-tweets java.util.concurrent.LinkedBlockingQueue [lbq f]
(loop [res (.take lbq)]
  (if res
(recur 
  (with-open [w (clojure.java.io/writer f :append true)]
(.write w (str (generate-string res) "\n")))

My first implementation of this used `(map #(.write w %) @a)` and had the 
`recur` within the `with-open` block. Unfortunately, at least with the 
agent part, I ran into an error about the file being closed when I tried to 
write to it. I assumed `with-open` kept the file open within the block, but 
maybe I'm missing something? I'm worried about the performance of either 
creating a potentially super-huge string in memory for the agent method 
(twitter returns pretty sizable JSON blobs) or repeatedly opening/closing a 
file for the LBQ method (I realize I could collapse this into one problem 
by taking everything out of the LBQ and putting it into an agent, but 
that's not really a solution...)

Does `writer` auto-close the file after it's done? Is there some better way 
of handling this kind of situation? 

-- 
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.7.0-alpha3 now available

[Michael Blume]

Picking up the variadic arguments discussion, it seems that in a simple 
definition like

(fn [& args] (apply f arg1 args))

One could conceivably put some sort of preprocessing smarts into the fn 
macro that notices that

a) this is a variadic arglist
b) the variadic arg (args) is a symbol, not some complicated destructuring 
expression
c) args is only ever used as the last argument to apply (maybe check this 
after thoroughly macroexpanding the function body)

and then autogenerates the various unrolled cases.

Even if we did only the simplest version of this, the new definition of 
partial would be

(defn partial
  "Takes a function f and fewer than the normal arguments to f, and
  returns a fn that takes a variable number of additional args. When
  called, the returned function calls f with args + additional args."
  {:added "1.0"
   :static true}
  ([f] f)
  ([f arg1]
   (fn [& args]
 (apply f arg1 args)))
  ([f arg1 arg2]
   (fn [& args]
 (apply f arg1 arg2 args)))
  ([f arg1 arg2 arg3]
   (fn [& args]
 (apply f arg1 arg2 arg3 args)))
  ([f arg1 arg2 arg3 & more]
   (fn [& args] (apply f arg1 arg2 arg3 (concat more args)

which is shorter (and would be unrolled in more cases than it currently is)

The thing that concerns me is that such a preprocessing step would be 
treating 'clojure.core/apply as a magic token, when apply is supposed to be 
a function like any other. And sufficient smarts to make 'partial 
single-clause would probably require treating 'clojure.core/concat as a 
magic token as well.

On Sunday, October 26, 2014 8:43:23 PM UTC-7, Alex Miller wrote:
>
> Clojure 1.7.0-alpha3 is now available. 
>  
> Try it via 
> - Download: 
> http://central.maven.org/maven2/org/clojure/clojure/1.7.0-alpha3/
> - Download securely: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha3/
> - Leiningen: [org.clojure/clojure "1.7.0-alpha3"]
>
> For users of Clojure 1.7.0-alpha2, there have been a few important changes 
> in features under development:
>
> Transducers:
> - "iteration" function renamed to "eduction"
> - Fixed several issues related to reduced values
>
> *unchecked-math* boxed math warnings:
> - warnings are now only emitted when (set! *unchecked-math* 
> :warn-on-boxed). for old behavior (no warnings), use (set! *unchecked-math* 
> true).
>
> For other changes new in alpha3, see the issues marked "(alpha3)" in the 
> changes below.
>
> 
> Clojure 1.7.0-alpha3 has the changes below from 1.6.0:
>
> ## 1 New and Improved Features
>
> ### 1.1 Transducers
>
> Transducers is a new way to decouple algorithmic transformations from their
> application in different contexts. Transducers are functions that transform
> reducing functions to build up a "recipe" for transformation.
>
> Also see: http://clojure.org/transducers
>
> Many existing sequence functions now have a new arity (one fewer argument
> than before). This arity will return a transducer that represents the same
> logic but is independent of lazy sequence processing. Functions included 
> are:
>
> * conj (conjs to [])
> * map
> * mapcat
> * filter
> * remove
> * take
> * take-while
> * drop
> * drop-while
> * cycle
> * take-nth
> * replace
> * partition-by
> * partition-all
> * keep
> * keep-indexed
>
> Additionally some new transducer functions have been added:
>
> * cat - concatenates the contents of each input
> * de-dupe - removes consecutive duplicated values
> * random-sample - returns items from coll with random probability
>
> And this function can be used to make completing transforms:
>
> * completing
>
> There are also several new or modified functions that can be used to apply
> transducers in different ways:
>
> * sequence - takes a transformation and a coll and produces a lazy seq
> * transduce - reduce with a transformation (eager)
> * eduction - returns a reducible/seqable/iterable seq of applications of 
> the transducer to items in coll. Applications are re-performed with every 
> reduce/seq/iterator.
> * run! - run the transformation for side effects on the collection
>
> There have been a number of internal changes to support transducers:
>
> * volatiles - there are a new set of functions (volatile!, vswap!, 
> vreset!, volatile?) to create and use volatile "boxes" to hold state in 
> stateful transducers. Volatiles are faster than atoms but give up atomicity 
> guarantees so should only be used with thread isolation.
> * array iterators - added support for iterators over arrays
>
> Some related issues addressed during development:
> * [CLJ-1511](http://dev.clojure.org/jira/browse/CLJ-1511)
> * [CLJ-1497](http://dev.clojure.org/jira/browse/CLJ-1497)
> * [CLJ-1549](http://dev.clojure.org/jira/browse/CLJ-1549) (alpha3)
> * [CLJ-1537](http://dev.clojure.org/jira/browse/CLJ-1537) (alpha3)
>
> ### 1.2 Keyword and Symbol Construction
>
> In response to issues raised in [CLJ-1439](
> http://dev.clojure.org/jira/browse/CLJ-1439), several ch

Re: CCW bug [SEVERE]

[Fluid Dynamics]

On Friday, October 31, 2014 2:24:04 PM UTC-4, Laurent PETIT wrote:
>
> Also, if you can attach the workspace's .metadata/.log file, I can take a 
> look at it. 
>

I have no idea how to reproduce it, which is part of the problem: I don't 
know what to avoid doing, in order to ensure it doesn't happen again until 
an update to CCW fixes it for good.

As for that log file, I had a look and there's nothing that identifies the 
problem. The log entry immediately prior to the hang is a complaint that 
some map literal has an odd number of forms, which I must have left 
incomplete when I went to make that other edit. There are lots of other 
similar entries, probably from other times I saved while there was a 
half-written map literal on my to-do stack, and it didn't hang on any of 
those other saves. The log entry immediately following that one is a 
session start message. So whatever was different that one time does not 
show up in the log, unfortunately, rendering the log unhelpful in this 
instance.

-- 
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: io/writer + map/recur

[Brian Craft]

Your first implementation probably failed because map is lazy, so none of 
the '.write' calls happened during the with-open block. Try doseq.



On Friday, October 31, 2014 1:08:01 PM UTC-7, Sam Raker wrote:
>
> I'm writing some stuff to interact with the Twitter API. I want to be able 
> to write tweets (as JSON) to a file, so I can, e.g., test things without 
> connecting to the API. I've proxied the LinkedBlockingQueue that Twitter's 
> HBC library uses to use an agent, so ideally I want to be able to write the 
> contents of the agent AND the LBQ. Here's what I have right now:
>
> (defmulti write-tweets (fn [q f] (class q)))
> (defmethod write-tweets clojure.lang.Agent [a f]
>   (with-open [w (clojure.java.io/writer f :append true)]
> (.write w (apply str (interpose "\n" @a)
> (defmethod write-tweets java.util.concurrent.LinkedBlockingQueue [lbq f]
> (loop [res (.take lbq)]
>   (if res
> (recur 
>   (with-open [w (clojure.java.io/writer f :append true)]
> (.write w (str (generate-string res) "\n")))
>
> My first implementation of this used `(map #(.write w %) @a)` and had the 
> `recur` within the `with-open` block. Unfortunately, at least with the 
> agent part, I ran into an error about the file being closed when I tried to 
> write to it. I assumed `with-open` kept the file open within the block, but 
> maybe I'm missing something? I'm worried about the performance of either 
> creating a potentially super-huge string in memory for the agent method 
> (twitter returns pretty sizable JSON blobs) or repeatedly opening/closing a 
> file for the LBQ method (I realize I could collapse this into one problem 
> by taking everything out of the LBQ and putting it into an agent, but 
> that's not really a solution...)
>
> Does `writer` auto-close the file after it's done? Is there some better 
> way of handling this kind of situation? 
>

-- 
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: CCW bug [SEVERE]

[Luc Préfontaine]

Just curious, how can you expect a fix if you do not provide any information 
that
could support a serious investigation ?

I read the eclipse log file from time to time and guessing which error is
relevant or not is an educated guess at best except if you are deep in
Eclipse plugins coding.

Creating an issue in the ccw project page takes under a minute including 
attaching
the log file.

If you expect the developer to find the root cause from thin air, you will wait
for eternity. Laurent is very proactive in investigating problems but w/o any 
grounds,
he's better having a glass of wine than trying to guess what happened here.

I would do the same...

Luc P.


> On Friday, October 31, 2014 2:24:04 PM UTC-4, Laurent PETIT wrote:
> >
> > Also, if you can attach the workspace's .metadata/.log file, I can take a 
> > look at it. 
> >
> 
> I have no idea how to reproduce it, which is part of the problem: I don't 
> know what to avoid doing, in order to ensure it doesn't happen again until 
> an update to CCW fixes it for good.
> 
> As for that log file, I had a look and there's nothing that identifies the 
> problem. The log entry immediately prior to the hang is a complaint that 
> some map literal has an odd number of forms, which I must have left 
> incomplete when I went to make that other edit. There are lots of other 
> similar entries, probably from other times I saved while there was a 
> half-written map literal on my to-do stack, and it didn't hang on any of 
> those other saves. The log entry immediately following that one is a 
> session start message. So whatever was different that one time does not 
> show up in the log, unfortunately, rendering the log unhelpful in this 
> instance.
> 
> -- 
> 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.
> 
--
Luc Préfontaine sent by ibisMail!

-- 
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: On Testing

[John Louis Del Rosario]

Would be great if humane-test-output was part of clojure.test. Would make 
it easier for beginners to find it. 

On Friday, October 31, 2014 11:19:11 PM UTC+8, Eli Naeher wrote:
>
> On Fri, Oct 31, 2014 at 9:52 AM, Ashton Kemerling  > wrote:
>  
>
>> It's my opinion that these two libraries are largely complete aside from 
>> some human interface improvements (quality of output for example), but 
>> clearly not everyone agrees with me. 
>>
>
> Hi Ashton,
>
> Check out https://github.com/pjstadig/humane-test-output if you haven't 
> already seen it, it's a nice improvement over the default output--in 
> particular seeing the specific diffs between expected and actual values is 
> really useful when you are dealing with collections.
>
> -Eli
>

-- 
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: On Testing

[Andrew Rosa]

+1 to something like humane-test-output being part of core library.

There is value for the community to have some foundation library share 
across our test frameworks? Something like `test.runners`, to encapsulate 
error reporting and organization? Bit crazy, I know, but the idea come 
after seeing Haskell's https://github.com/feuerbach/tasty. OK, I don't do 
Haskell, but I kind of like the way of composing a single integrated suite 
of different flavors of test.

Andrew

On Friday, October 31, 2014 10:41:09 PM UTC-2, John Louis Del Rosario wrote:
>
> Would be great if humane-test-output was part of clojure.test. Would make 
> it easier for beginners to find it. 
>
> On Friday, October 31, 2014 11:19:11 PM UTC+8, Eli Naeher wrote:
>>
>> On Fri, Oct 31, 2014 at 9:52 AM, Ashton Kemerling  
>> wrote:
>>  
>>
>>> It's my opinion that these two libraries are largely complete aside from 
>>> some human interface improvements (quality of output for example), but 
>>> clearly not everyone agrees with me. 
>>>
>>
>> Hi Ashton,
>>
>> Check out https://github.com/pjstadig/humane-test-output if you haven't 
>> already seen it, it's a nice improvement over the default output--in 
>> particular seeing the specific diffs between expected and actual values is 
>> really useful when you are dealing with collections.
>>
>> -Eli
>>
>

-- 
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] outfn - A macro for clearer, more declarative functions (that are actually macros).

[Diogo Almeida]

Thanks for checking it out! (:

That is an unfortunately great point about implicits, I apologize! It's 
been in my head so long that I didn't realize that I never explained them. 
My concisest way of explaining implicits would be automatic glue code 
generation. You already have these functions annotated with their inputs 
and outputs, why would you have to write the code to stick them together? 
It solves the problem of which functions should you call in which order to 
get what you want. The long-term goal would be to write better code than a 
human could possibly write (I think that the problem of solving for a 
desired output from a set of inputs is not in P, not sure though) and being 
generally easy to maintain/change since it hopefully is a productivity 
multiplier. Perhaps "implicits" is the wrong word though, but I can't think 
of a better one at the moment (I would happily change it if someone else 
had a better idea though).

The outfn's are actually macros, which is how the verification can happen 
without them being called, thus the normal things that work only with 
functions such as map/apply, etc. won't work. This is a desired property 
though, because the moment you use map or apply, you're passing an opaque 
data structure into some function, thus not being clear to the reader. You 
could still do (map #(some-outfn :foo 42 :this-argument %) coll) to keep 
the higher order functions and call clarity.


On Thursday, October 30, 2014 7:02:39 PM UTC-7, Atamert Ölçgen wrote:
>
> I think this is pretty cool. Instead of thinking it as functions on 
> steroids, I'd prefer looking at it as a powerful callable abstraction.
>
> How does macroexpand-time validation play with apply (the function)? What 
> happens if I do (map some-outfn coll) ?
>
> Also implicits confused me a bit. At first I thought they were parameter 
> defaults. But it seems they're some sort of inheriance mechanism for 
> callables.
>
> BTW, thanks for taking the time to write a detailed readme. I know this is 
> a young project and it's probably in heavy development. It shows 
> professionalism (yes, professionalism in an open source context is a thing) 
> on your part.
>
>
> On Thu, Oct 30, 2014 at 3:08 AM, Diogo Almeida  > wrote:
>
>> Hi everyone,
>>
>> A couple of coworkers and I were chatting about what some of our biggest 
>> problems with (our) Clojure code was, and came up with this: 
>> https://github.com/diogo149/outfn ! We just finished making it, so we 
>> haven't really battle-tested it, but we would love to hear feedback and 
>> general thoughts about the approach, and possibly have it evolve with the 
>> community.
>>
>> The readme has a bunch examples, so I won't copy-paste it all here, but 
>> here is a list of things that we are hoping to acheive:
>> - bad/inconsistent variable naming
>> - function call clarity
>> - function dispatch based on inputs instead of arity and allowing the 
>> usage of a threading macro no matter the order of arguments with 0 overhead
>> - static DRY verification
>> - decomposing big let blocks easily
>> - dependency passing without coupling (and anything that makes us want to 
>> use a :dynamic var)
>> - automatic creation of glue code
>>
>> Some of our favorite examples:
>>
>>
>> - keyword arguments for function call clarity
>>   (do-something :user-map x :password-list y)
>>
>>
>> - decomplecting order from function arguments:
>> (defoutfn map-v2.0
>>   "Like map, but better"
>>   [f coll]
>>   (map f coll))
>> 
>> ;; threading in a collection
>> (->> 5
>>  range
>>  (map-v2.0 :f inc :coll)) ;; (1 2 3 4 5)
>> 
>> ;; threading in a function
>> (->> 5
>>  (partial +)
>>  (map-v2.0 :coll (range 5) :f)) ;; (5 6 7 8 9)
>>
>>
>> - macroexpand-time validation
>> (defoutfn outfn
>>   "what's up doc"
>>   [foo]
>>   :foo)
>> 
>> (when nil
>>   ;; this doesn't get run
>>   (outfn :fo 2))
>> ;; Error!  Invalid set of keys #{:fo} for #'outfn.core/outfn
>>
>>
>> - declarative function calls without glue code
>> (defoutfn foo-fn {:output :foo}
>>   "Docstring"
>>   ([a] 3)
>>   ([b] 4)
>>   ([c d] 5))
>>
>> (defoutfn bar-fn {:implicits #{#'foo-fn}}
>>   "what's up doc"
>>   [foo] foo)
>>
>> ;; Look ma, no glue code
>> (bar-fn :foo 2) ;; 2
>> (bar-fn :a nil) ;; 3
>> (bar-fn :b 42) ;; 4
>> (bar-fn :c 11 :d 22) ;; 5
>>
>> ;; I don't need to know what bar-fn needs - decoupling
>> (bar-fn :foo 2 :a 3 :b 4 :c 5 :d 6 :q 72) ;; 2
>>
>> ;; Laziness is a virtue
>> (bar-fn :foo 42 :a (throw Exception.)) ;; 42
>>
>>  -- 
>> 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 g

Re: CCW bug [SEVERE]

[Fluid Dynamics]

On Friday, October 31, 2014 6:23:42 PM UTC-4, Luc wrote:
>
> Just curious, how can you expect a fix if you do not provide any 
> information that 
> could support a serious investigation ? 
>
> I read the eclipse log file from time to time and guessing which error is 
> relevant or not is an educated guess at best except if you are deep in 
> Eclipse plugins coding. 
>
> Creating an issue in the ccw project page takes under a minute including 
> attaching 
> the log file. 
>
> If you expect the developer to find the root cause from thin air, you will 
> wait 
> for eternity. Laurent is very proactive in investigating problems but w/o 
> any grounds, 
> he's better having a glass of wine than trying to guess what happened 
> here. 
>
> I would do the same... 
>

It's not *my* fault the log file doesn't contain anything unusual between 
before the hang happened and after recovery. If CCW didn't log anything 
that helps indicate what was different or unusual on that occasion of 
saving, then there's simply not much I can do about it.

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

Re: CCW bug [SEVERE]

[Ben Wolfson]

On Fri, Oct 31, 2014 at 8:30 PM, Fluid Dynamics  wrote:

>
> It's not *my* fault the log file doesn't contain anything unusual between
> before the hang happened and after recovery. If CCW didn't log anything
> that helps indicate what was different or unusual on that occasion of
> saving, then there's simply not much I can do about it.
>

You could, theoretically, send it along anyway, per the developer's
request, and let him make the determination of whether or not there's
anything useful there.

-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure."
[Larousse, "Drink" entry]

-- 
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: CCW bug [SEVERE]

[Luc Prefontaine]

I'll repeat myself :

'...guessing which error is 
relevant or not is an educated guess at best except if you are deep in 
Eclipse plugins coding.'

Laurent stated clearly that saving
a file triggers a number of things
in several plugins.

There could be suspicious messages in the log
that have nothing to do with CCW 
and that could give an idea of the root of
the problem. 

I'll leave you to think about this
and figure out what should be your
next action.

Guess what ? It's not adding another 
email to this thread, I wrote 'action' above.

Luc P.

> On Friday, October 31, 2014 6:23:42 PM UTC-4, Luc wrote:
> >
> > Just curious, how can you expect a fix if you do not provide any 
> > information that 
> > could support a serious investigation ? 
> >
> > I read the eclipse log file from time to time and guessing which error is 
> > relevant or not is an educated guess at best except if you are deep in 
> > Eclipse plugins coding. 
> >
> > Creating an issue in the ccw project page takes under a minute including 
> > attaching 
> > the log file. 
> >
> > If you expect the developer to find the root cause from thin air, you will 
> > wait 
> > for eternity. Laurent is very proactive in investigating problems but w/o 
> > any grounds, 
> > he's better having a glass of wine than trying to guess what happened 
> > here. 
> >
> > I would do the same... 
> >
> 
> It's not *my* fault the log file doesn't contain anything unusual between 
> before the hang happened and after recovery. If CCW didn't log anything 
> that helps indicate what was different or unusual on that occasion of 
> saving, then there's simply not much I can do about it.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
--
Luc Prefontaine sent by ibisMail!

-- 
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: CCW bug [SEVERE]

[Fluid Dynamics]

On Friday, October 31, 2014 11:44:49 PM UTC-4, Luc wrote:
>
> I'll repeat myself : 
>
> '...guessing which error is 
> relevant or not is an educated guess at best except if you are deep in 
> Eclipse plugins coding.' 
>
> Laurent stated clearly that saving 
> a file triggers a number of things 
> in several plugins. 
>
> There could be suspicious messages in the log 
> that have nothing to do with CCW 
> and that could give an idea of the root of 
> the problem. 
>

And I'll repeat *my*self: each save I did in the ten minutes before the 
hang produced a particular message in the log. The save I did that 
triggered the hang produced the exact same message. The very next message 
was the first message generated by a fresh CCW instance starting up. There 
was nothing in between. There was nothing different, special, or unusual 
anywhere near (and prior to) the time of the hang, nor anything missing 
that was present for previous saves. Ergo there was nothing in the log that 
was any kind of clue to the reason for the hang.

-- 
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: CCW bug [SEVERE]

[Dylan Butman]

Is it hard to actually send the log? Are you purposefully uncooperative to 
people trying to help?



> On Oct 31, 2014, at 11:51 PM, Fluid Dynamics  wrote:
> 
>> On Friday, October 31, 2014 11:44:49 PM UTC-4, Luc wrote:
>> I'll repeat myself : 
>> 
>> '...guessing which error is 
>> relevant or not is an educated guess at best except if you are deep in 
>> Eclipse plugins coding.' 
>> 
>> Laurent stated clearly that saving 
>> a file triggers a number of things 
>> in several plugins. 
>> 
>> There could be suspicious messages in the log 
>> that have nothing to do with CCW 
>> and that could give an idea of the root of 
>> the problem. 
> 
> And I'll repeat *my*self: each save I did in the ten minutes before the hang 
> produced a particular message in the log. The save I did that triggered the 
> hang produced the exact same message. The very next message was the first 
> message generated by a fresh CCW instance starting up. There was nothing in 
> between. There was nothing different, special, or unusual anywhere near (and 
> prior to) the time of the hang, nor anything missing that was present for 
> previous saves. Ergo there was nothing in the log that was any kind of clue 
> to the reason for the hang.
> 
> -- 
> 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 a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/6Vw7wuVXz9E/unsubscribe.
> To unsubscribe from this group and all its topics, 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

[Isaac Karth]

Thanks for all of the feedback so far, it's been helpful. Mars0i, keeping 
an RNG for each thing that needs to have an independent random state seems 
like a good idea for a fallback, and the suggestion of using a different 
RNG is a good one. It's also helpful to know other people have dealt with 
similar problems.

Laurens, Using a PRF actually sounds very close to ideal for what I was 
looking for. If I can convert a map (or record) to a reproducible seed, and 
have that be independant from other random checks, that's pretty close to 
exactly what I wanted.

Looks like if I want to use libraries like clojure.data.generators or 
bigml.sampling I'd need to amend the random generators to replace calls to 
the Mersenne Twister function or (def ^:dynamic *rnd* (java.util.Random. 
42)). As long as I can figure out how to install caesium/libsodium on 
Windows, it should theoretically be possible to substitute the PRF there, 
though I'd have to rewrite some functions to replace the calls to 
.nextDouble, .nextFloat, et cetera. 

I'm assuming that just passing the hash as a seed to MT wouldn't work. If I 
can get away with something like (binding *rnd* (random-number-generator 
(blake2b [seed thing-to-hash]))) using it becomes trivial. But I'm just 
knowledgeable enough to know I don't know enough to be confident of that. 
Granted, the current application is an art project that will be just fine 
with some non-random randomness, so the tolerance for error is fairly high.

Speed isn't a major concern yet: implementation before optimization. I'm 
currently using a ridiculously naive rules system, which works just fine 
for my grand total of (so far) three rules. Filtering the rules is probably 
going to be the bottleneck long before the randomness in the conflict 
resolution.  

On Friday, October 31, 2014 11:15:44 AM UTC-4, Laurens Van Houtven wrote:
>
> Hi, 
>
>
> I too, am super interested in games in Clojure. My other background is 
> cryptography, so I break out the crypto. I would say that you don’t really 
> want a PRG, but you might want a PRF instead. (If that doesn’t mean 
> anything to you, don’t worry, read on.) 
>
> My favorite cryptographic hash function, BLAKE2, has a number of cool 
> features that might help. If you have some description of the thing that 
> you want and a random seed, you can produce a number from which you can 
> then go on and generate whatever you want. This answers your “sub-seed” 
> question: blake2(master_seed, “room 1”) and blake2(master_seed, “room 2”) 
> will be completely different values. However, you can compute 
> blake2(master_seed, “room 1”) at any later point, and it will still be the 
> same value. This makes all of the problems of sharing, ordering… go away. 
> No more state :) 
>
> This does mean passing a seed around in your game state, but it seems 
> evident to me that your seed is indeed a fundamental property of your game 
> state, so I don’t think that’s a bad thing. 
>
> While BLAKE2 is of course significantly stronger than what you need for a 
> game, it is ridiculously fast [1]. In case you’re worried about speed (you 
> most likely shouldn’t be), SipHash is still significantly stronger than 
> what you need (nearly cryptographic strength), but is competitive in speed 
> with non-cryptographic hash functions like CityHash, Murmur2/3 
>
> Neither BLAKE2 nor SipHash nor other PRFs typically come with the 
> randomness utility features you would typically want, like random 
> selection, weighted random selection, random variable according to a 
> distribution… Hopefully those things are available in a way that lets you 
> separate the concern of “generate n pseudorandom bits” and “use those bits 
> to produce a value”. Of course, other PRNG algorithms like MT also don’t 
> solve this problem: they just give you some random-looking bytes, just like 
> BLAKE2/SipHash :) 
>
> BLAKE2 is exposed with a nice Clojure API through my caesium library. I 
> don’t know of any easily available SipHash implementations, but I can’t 
> imagine it’s very hard to get it running. There’s a Java implementation, 
> and various Lisp implementations that shouldn’t be terribly hard to port to 
> Clojure. 
>
> [1]: https://blake2.net/ 
> [2]: https://131002.net/siphash/ 
>
>
> hth 
> lvh 
>

-- 
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: On Testing

[Ashton Kemerling]

That's an excellent idea, currently at least test.check hacks on top of 
clojure.test by using macros that emit clojure.test tests. 


Beyond that it seems that the #1 wish is better output. I don't think that 
ought to be very hard for us to pull off as a community.

On Fri, Oct 31, 2014 at 6:56 PM, Andrew Rosa  wrote:

> +1 to something like humane-test-output being part of core library.
> There is value for the community to have some foundation library share 
> across our test frameworks? Something like `test.runners`, to encapsulate 
> error reporting and organization? Bit crazy, I know, but the idea come 
> after seeing Haskell's https://github.com/feuerbach/tasty. OK, I don't do 
> Haskell, but I kind of like the way of composing a single integrated suite 
> of different flavors of test.
> Andrew
> On Friday, October 31, 2014 10:41:09 PM UTC-2, John Louis Del Rosario wrote:
>>
>> Would be great if humane-test-output was part of clojure.test. Would make 
>> it easier for beginners to find it. 
>>
>> On Friday, October 31, 2014 11:19:11 PM UTC+8, Eli Naeher wrote:
>>>
>>> On Fri, Oct 31, 2014 at 9:52 AM, Ashton Kemerling  
>>> wrote:
>>>  
>>>
 It's my opinion that these two libraries are largely complete aside from 
 some human interface improvements (quality of output for example), but 
 clearly not everyone agrees with me. 

>>>
>>> Hi Ashton,
>>>
>>> Check out https://github.com/pjstadig/humane-test-output if you haven't 
>>> already seen it, it's a nice improvement over the default output--in 
>>> particular seeing the specific diffs between expected and actual values is 
>>> really useful when you are dealing with collections.
>>>
>>> -Eli
>>>
>>
> -- 
> 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: CCW bug [SEVERE]

[Fluid Dynamics]

On Saturday, November 1, 2014 12:09:33 AM UTC-4, Dylan Butman wrote:
>
> Is it hard to actually send the log? Are you purposefully uncooperative to 
> people trying to help?
>

My inspection of the log indicates that the amount of information 
(namespace names, other things) about what I'm working on that it contains 
is non-zero. So, not only would there be some effort involved in signing up 
for wherever-it-was and uploading a copy there, but also some damage to my 
privacy, and all for zero gain, since it is already a mathematical 
certainty that the log contains nothing enlightening on this particular 
issue. Which can only mean one of two things: either you believe I'm lying 
when I describe the log entries immediately around the time of the hang, or 
you are so insistent on seeing the log anyway because you're after 
something else that it is in it, and are not being honest about what you're 
really looking for. So, either you're untrusting or untrustworthy, and in 
neither case am I especially inclined to trust you, Mr. Butman.

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