Re: [ANN] test.check 0.10.0-RC1

[Gary Fredericks]

And now, due to lack of complaints, 0.10.0 proper has been released. No
differences from 0.10.0-RC1.

Gary Fredericks

On Mon, Jul 1, 2019 at 10:42 AM Gary Fredericks 
wrote:

> After Quite A Long Time, test.check (the property-based testing contrib
> library) is in a state that I think is good enough for a 0.10.0 release.
> There's an RC1 release out yesterday, with changes detailed here
> <https://github.com/clojure/test.check/blob/master/CHANGELOG.markdown>.
> Give it a try, if you like trying new things.
>
> Gary Fredericks
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAMMdeLiEyt-jFyzJW_rfZ6VbnjjXA2yhJk37%2BT_o01kOwE%2BHbg%40mail.gmail.com.

[ANN] test.check 0.10.0-RC1

[Gary Fredericks]

After Quite A Long Time, test.check (the property-based testing contrib
library) is in a state that I think is good enough for a 0.10.0 release.
There's an RC1 release out yesterday, with changes detailed here
<https://github.com/clojure/test.check/blob/master/CHANGELOG.markdown>.
Give it a try, if you like trying new things.

Gary Fredericks

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAMMdeLiHpa6tg70SoWfO9mh%3DyKMZa42p7J29MEw%2BhFuRxLcVOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Noob question on the --> macro implementation

[Gary Fredericks]

There's probably also a difference in what happens if the form is empty. 
The current impl results in a compile error about calling nil, whereas the 
suggested implementation would result in calling the current thread value 
as a function, I think.

On Saturday, January 26, 2019 at 5:13:23 PM UTC-6, Sean Corfield wrote:
>
> I suspect it’s done for consistency with the source of -> (which has to 
> use first/next because it threads the expression between them) – using 
> first/next/x in ->> is therefore a closer parallel to using first/x/next in 
> -> so it’s easier to see the similarity (and correctness) of the code.
>
>  
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
> --
> *From:* clo...@googlegroups.com   > on behalf of James Reeves  >
> *Sent:* Saturday, January 26, 2019 11:08:25 AM
> *To:* clo...@googlegroups.com 
> *Subject:* Re: Noob question on the --> macro implementation 
>  
> I believe he's just saying it's simpler and possibly more efficient.
>
> Unless I'm missing something subtle in the way this is resolved, I believe 
> Ujjwal is right that:
>
> `(~(first form) ~@(next form) ~x)
>
> Is equivalent to:
>
> `(~@form ~x)
>
> On Sat, 26 Jan 2019 at 19:04, Andy Fingerhut  > wrote:
>
>> When you ask "am I right?" about your proposed change, what is it that 
>> the current behavior does not do, that your change would do?  Do you have 
>> some use case in mind that works with your change, but doesn't with the 
>> current implementation? 
>>
>> Andy
>>
>> On Sat, Jan 26, 2019 at 10:50 AM Ujjwal Thaakar > > wrote:
>>
>>> Hi, 
>>> I'm trying to learn Clojure and I just curiously typed  
>>> (source ->>)
>>>  in the REPL and was wondering about this: 
>>> https://github.com/clojure/clojure/commit/749a0ad8b66c781d8176833f0ad26cfe6b9b24e3#r32075784
>>>
>>> Am I missing something?
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com 
>>> 
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com 
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to 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.
>>
>
>
> -- 
> James Reeves 
> booleanknot.com
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: (float 0.819869321599107) = 0.81986934 ?

[Gary Fredericks]

0.81986932 is not a valid float -- the next smallest one is 0.81986930, so 
the one you were given is the closest that can be rounded to.

Try (Math/nextUp x) and (Math/nextDown x) to see what floats are possible.

On Saturday, December 15, 2018 at 4:21:05 PM UTC-6, ru wrote:
>
> I have to use float in one application.
> I just thought that a reasonable implementation of the float function 
> could use the rounding we were used to, that is, (float 
> 0.819869321599107) = 0.81986932
>
> суббота, 15 декабря 2018 г., 21:10:54 UTC+3 пользователь ru написал:
>>
>> Dear Clojure users and team!
>>
>> Please explain me this result:
>>
>> Ruslans-iMac:clojure ru$ lein repl
>>
>> nREPL server started on port 54147 on host 127.0.0.1 - nrepl://
>> 127.0.0.1:54147
>>
>> REPL-y 0.3.7, nREPL 0.2.12
>>
>> Clojure 1.8.0
>>
>> Java HotSpot(TM) 64-Bit Server VM 11.0.1+13-LTS
>>
>> Docs: (doc function-name-here)
>>
>>   (find-doc "part-of-name-here")
>>
>>   Source: (source function-name-here)
>>
>>  Javadoc: (javadoc java-object-or-class-here)
>>
>> Exit: Control+D or (exit) or (quit)
>>
>>  Results: Stored in vars *1, *2, *3, an exception in *e
>>
>>
>> user=> (float 0.819869321599107)
>>
>> 0.81986934
>>
>> user=> 
>>
>>
>> Thanks in advance.
>>
>>
>> Sincerely,
>>
>>   Ru
>>
>

-- 
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: Why does interruptible-eval from tools.nrepl queue evaluations?

[Gary Fredericks]

I used the hacky tactic of just sending messages through the nrepl channels
(while the eval is blocked) to implement this:
https://github.com/gfredericks/debug-repl

Gary Fredericks
(803)-295-0195
fredericksg...@gmail.com
gfredericks.com

On Thu, May 3, 2018 at 4:31 PM, Carlo Zancanaro <carlozancan...@gmail.com>
wrote:

>
> On Thu, May 03 2018, Gary Fredericks wrote:
>
>> Separately, I use this macro <https://github.com/gfrederick
>> s/repl-utils#bg> for running background things in the repl. It probably
>> targets different concerns, but seems related at least.
>>
>
> My use case is quite different. Requiring someone to decide ahead of time
> to run code in the background (ie. by wrapping it in another form) won't
> work for me at all.
>
> I'm trying to write a Common Lisp interactive restart system, somewhat
> similar to what Slime gives you. It actually works pretty well, but it's
> often helpful to be able to redefine things, or to run some code to change
> a data structure, before selecting a restart. While waiting for a restart
> selection the eval thread is blocked, though, so other evaluations have to
> happen in another thread. The nrepl protocol seems like it was designed for
> this, given how asynchronous it is, so I was surprised that
> interruptible-eval explicitly queued up evaluations and ran them
> sequentially.
>
> I've ended up doing this as a solution: https://github.com/czan/dont-g
> ive-up.nrepl/blob/acc20e0c25aa90a5c991b9cd1f7cc4abe2f1cd6b/
> src/dont_give_up/nrepl.clj#L335. This isn't perfect. There are further
> modifications required to be able to interrupt evaluations other than the
> most recent one, but it works well enough to be useful. If anyone has a
> reason why this is a terrible idea, I'm all ears.
>
> Carlo
>

-- 
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: Why does interruptible-eval from tools.nrepl queue evaluations?

[Gary Fredericks]

Separately, I use this macro <https://github.com/gfredericks/repl-utils#bg>
for running background things in the repl. It probably targets different
concerns, but seems related at least.

Gary Fredericks
(803)-295-0195
fredericksg...@gmail.com
gfredericks.com

On Thu, May 3, 2018 at 8:01 AM, Carlo Zancanaro <carlozancan...@gmail.com>
wrote:

> Apologies, I forgot to cc the list.
>
> On Thu, May 03 2018, Gary Fredericks wrote:
>
>> You would also have race conditions on the meaning of *1, *2, *3, and *e.
>>
>> On Thu, May 3, 2018 at 5:43 AM, Carlo Zancanaro <carlozancan...@gmail.com
>> >
>> wrote:
>>
>>> >But what happens when a user set!s a var? is it effective for >all
>>> future evals but not the concurrent ones?
>>>
>>> I believe so, but I can't check right now. If I'm wrong I'll correct
>>> myself when I can check.
>>>
>>
> It turns out I was half-wrong. When you start an evaluation then the
> bindings will be set to the state that they were in at the end of the most
> recent evaluation. This can get a bit confusing when there are lots of
> overlapping evaluations, but when you're using the system interactively
> (eg. with CIDER) then you have a lot of control over the evaluation
> sequence.
>
> The meanings of *1, *2, *3, and *e follow the same rules as the above. I
> still find it a bit weird that evaluating a form with C-M-x (or other
> in-buffer evaluation commands) changes those variables, though. I would
> prefer it if those variables only got set by an evaluation from the REPL
> buffer (which CIDER ensures are sequential). That way I could eval stuff
> with C-M-x without affecting the state of my REPL history variables. But
> that's a separate issue in my mind.
>
> Carlo
>

-- 
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: Why does interruptible-eval from tools.nrepl queue evaluations?

[Gary Fredericks]

But what happens when a user set!s a var? is it effective for all future
evals but not the concurrent ones?

On Wed, May 2, 2018 at 8:35 PM, Carlo Zancanaro 
wrote:

>
>
> >I think dynamic vars in particular would be problematic. The repl is
> built around being able to set! certain vars, and you can't do that to the
> same binding from multiple threads.
>
> The dynamic thread bindings are established within the function passed to
> queue-eval, though, so it seems like it will be as close to sensible as
> possible. (That is: use the bindings that were current at the point when
> the evaluation was started.)
>
> I just looked into the interruption code, which is the only thing that
> looks like it actually depends on the serial nature of the evaluation. I
> think it would be possible to make it work with parallel evaluations,
> though, by storing a "message id to thread" map on the session instead of a
> single message id and thread. That would let you interrupt the thread for a
> given evaluation.
>
> Carlo
>

-- 
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: Why does interruptible-eval from tools.nrepl queue evaluations?

[Gary Fredericks]

I think dynamic vars in particular would be problematic. The repl is built 
around being able to set! certain vars, and you can't do that to the same 
binding from multiple threads.

On Wednesday, May 2, 2018 at 5:48:46 AM UTC-5, Carlo Zancanaro wrote:
>
> Hey there! 
>
> With tools.nrepl, if you eval two expressions they get queued up 
> and evaluated in sequence. This means that if I evaluate 
> (Thread/sleep 1), and then immediately evaluate (+ 1 2), then 
> I have to wait ten seconds for the result of 3 to come back. 
>
> Is there a particular reason for this? Given that it's quite easy 
> to make it evaluate them in parallel, I figure there's a reason 
> why it was decided to evaluate them in sequence. 
>
> I have a use-case where I would like to be able to run evaluations 
> in parallel without having to wrap everything in (future ...), so 
> I'm considering writing some middleware to redefine 
> clojure.tools.nrepl.middleware.interruptible-eval/queue-eval to 
> just put things straight on the executor. It seems to work from my 
> limited tests, but are there any reasons why this would break 
> horribly? 
>
> Carlo 
>

-- 
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: Nesting test.check's defspec tests like deftest/testing

[Gary Fredericks]

There's nothing like that in test.check proper, but you might find this 
 
useful.

On Thursday, March 29, 2018 at 7:36:15 AM UTC-5, Khalid Jebbari wrote:
>
> Hello everyone,
>
> Is there a way to nest defspec tests like we can with deftest and testing 
> ? I'm porting some tests from deftest to defspec but losing the ability to 
> nest them make them a bit less readable.
>
> Thanks in advance
>

-- 
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: [?] Adding my own function to clojure.core namespace

[Gary Fredericks]

For clojure (not cljs, yet) I proxy all the dev utilities I might want to 
use in a namespace called `.` so I can refer to it everywhere no matter 
what the local namespace setup is: 
https://github.com/gfredericks/dot-slash-2

On Sunday, February 25, 2018 at 11:45:41 AM UTC-6, Philos Kim wrote:
>
> I have another question. Debux library supports ClojureScript as well. 
> Similarly, I want to add my own function or macro to cljs.core as in 
> Clojure. Can I use the same strategy in ClojureScript as in Clojure if I 
> use it in the  ClojureScript source code, not in REPL?

-- 
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 to disable (or limit) test.check shrinking

[Gary Fredericks]

Wrapping the generator in `gen/no-shrink` will give you a generator that 
pretends it doesn't know how to shrink.

On Thursday, February 9, 2017 at 11:55:38 AM UTC-6, Matt Bossenbroek wrote:
>
> I considered that, but that only partially fixes the issue. If it does 
> actually find a real problem, it’ll never complete because the shrinking 
> takes too long.
>
> In the end I’d rather have something not fully shrunk than something that 
> runs forever.
>
> -Matt
>
>
> On February 8, 2017 at 1:19:24 PM, Daniel Compton (daniel.com...@gmail.com 
> ) wrote:
>
> If the 503 is only returned by failures not relating to what you are 
> testing (e.g. load), then one option might be to catch the exception and 
> retry that request?
>
> On Thu, Feb 9, 2017 at 6:48 AM 'Matt Bossenbroek' via Clojure <
> clo...@googlegroups.com > wrote:
>
>> I'm using test.check to test a live service. Occasionally it gets a 503 
>> from the service and spends hours trying to shrink the input & reproduce 
>> the error. 
>>
>> Is there a way to limit the shrinking process to n iterations? Or disable 
>> it entirely for some tests?
>>
>> Is there a better approach for using test.check against a live service 
>> where transient issues are expected? Should I just retry the actual service 
>> call many times before allowing test.check to see it?
>>
>> Thanks,
>> Matt
>>
>> --
>> 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.
>>
> --
>
> Daniel
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>

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

Re: Obtaining the call graph of a clojure project

[Gary Fredericks]

I have a very hacky bunch of code here 

 
that uses tools.analyzer to try to do this. It works okay and I would love 
for somebody to make it better.

On Wednesday, July 27, 2016 at 5:51:03 PM UTC-5, Matan Safriel wrote:
>
> Hi,
>
> Is it possible to get information about the call graph of a project from 
> the clojure compiler?
> For example in Scala, one can use a compiler plugin, to tap into the AST. 
> This in turn permits deriving more or less the entire call graph of the 
> project, directly through the compiler, rather than by picking inside the 
> byte code produced by the compiler.
>
> What can be said about this aspect in Clojure?
>
> Thanks!
> Matan
>

-- 
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: Thoughts on clojure.spec

[Gary Fredericks]

Here's a library you could add that functionality to: 
https://github.com/gfredericks/schpec

Gary

On Tuesday, July 19, 2016 at 1:30:27 AM UTC-5, Beau Fabry wrote:
>
> Right, and I don't think the "this is closed we shouldn't discuss it 
> anymore" line is great when people are advocating for a piece of 
> functionality. I understand Alex doesn't want endless threads bikeshedding 
> basically arbitrary naming choices, but that's not the same as people 
> making simple points of "I think X would be a good addition because of Y" 
> with no back and forth.
>
> Maybe enough people saying "yes that sounds like a good idea because Y" in 
> this thread will convince someone else that they should create a lib that 
> mirrors the old functionality, this is the general Clojure group and not 
> clojure-dev after all.
>
> Sorry about the meta.
>
> On Tuesday, July 19, 2016 at 3:51:09 PM UTC+10, Sean Corfield wrote:
>>
>> Well, both Alex and Rich have said the change is deliberate and there are 
>> no plans to change that decision – and Rich talked about ways you can add 
>> return value testing manually based on specs (if you want, but he won’t 
>> help you) – so it seems like a “closed” topic to me? (and Alex has shut 
>> down a couple of other threads that have continued on past a clear line of 
>> decision)
>>
>>  
>>
>> I was sad to see :ret checking go away but I accept Rich’s line of 
>> thinking on this and I’ll adjust my workflow accordingly. I find Rich’s 
>> point that instrumentation is now about ensuring functions are _*called*_ 
>> correctly rather than trying to establish that they _*behave*_ correctly 
>> oddly compelling, now that I’ve had some time to think about it and play 
>> with it 
>>
>>  
>>
>> Sean Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org
>>
>>  
>>
>> *From: *Beau Fabry
>> *Sent: *Monday, July 18, 2016 8:50 PM
>> *To: *Clojure
>> *Subject: *Re: Thoughts on clojure.spec
>>
>>  
>>
>> I think that was an explanation of why it's not particularly valuable in 
>> unit tests, but not really an explanation of why it wouldn't be useful in 
>> lower environments or canary boxes in distributed deployments. This thread 
>> has also touched on how not everything is gen-testable because of 
>> complexity, and I'd add that side-effects are another reason for that. We 
>> also have "you can just use assert on the return value" which is true, but 
>> seeing as I already have a database of expected return values that I've 
>> defined then it seems natural to be able to use that database to gain some 
>> extra testing value rather than define it again.
>>
>>  
>>
>> I'm not trying to argue for inclusion, if clojure core doesn't want to 
>> implement the feature then those who see value in it can trivially 
>> implement it themselves, but I haven't read anything that's made me think 
>> it wouldn't be useful.
>>
>>
>> On Tuesday, July 19, 2016 at 12:53:49 PM UTC+10, Sean Corfield wrote:
>>
>> Rich has given a pretty good explanation of why this was removed 
>> elsewhere. And in this thread, a week ago, he explained again why 
>> gen-testing :ret and :fn specs was the better approach.
>>
>>  
>>
>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "If you're not annoying somebody, you're not really alive."
>> -- Margaret Atwood
>>
>>  
>>
>> On 7/18/16, 7:46 PM, "Oliver George" > of oli...@condense.com.au> wrote:
>>
>>  
>>
>> Here's the commit removing that aspect of instrument-all.  Not a big 
>> change.
>>
>>  
>>
>>
>> https://github.com/clojure/clojure/commit/30dd3d8554ff96f1acda7cbe31470d92df2f565a
>>
>>  
>>
>> As an aside, I also love the idea of the Clojure community fostering a 
>> culture of gen testing each chunk of well defined functionality.  If it's 
>> truly achievable the Clojure community could become known as an unstoppable 
>> force of robust code.
>>
>>  
>>
>> It would be something of a challenge for many of us... especially those 
>> wanting this particular feature!
>>
>>  
>>
>>  
>>
>> On 19 July 2016 at 10:36, Beau Fabry  wrote:
>>
>> > Do you find it frustrating that there's no way to turn on 
>> instrumentation of function outputs for manual testing?
>>
>>  
>>
>> Yes. I've mentioned this elsewhere but I think being able to turn on 
>> output checking in lower environments (dev, test, master, staging) is 
>> getting extra values from specs basically for free. Being able to do it 
>> seems pragmatic. I'm hoping it won't be too difficult to write an 
>> `overinstrument-all` that gives me that when I want it.
>>
>>
>> On Tuesday, July 12, 2016 at 5:36:39 PM UTC+10, Maarten Truyens wrote:
>>
>> I would also truly appreciate instrumentation of function outputs for 
>> manual outputs. I understand the rationale for not having it as the 
>> default, but could it perhaps be specified as an option s/instrument? 
>> (Considering that it was present in 

Re: lein repl and own functions

[Gary Fredericks]

I use lein-shorthand , which 
makes arbitrary functions available to me in any project (or no project) 
and namespace.

Gary

On Thursday, July 14, 2016 at 8:53:03 AM UTC-5, Cecil Westerhof wrote:
>
> When I first worked with Clojure I used a Bash script with had:
> rlwrap java -cp "${CP}" clojure.main --init "${CLOJURE_INIT}" --repl
>
> In this way I had several of my own functions in the REPL. Now I started 
> again with Clojure I understood I should use ‘lein repl’. Is there a method 
> to get my own functions also included when using ‘lein repl’?
>
> -- 
> Cecil Westerhof
>

-- 
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: test.check for-all reuses generated values?

[Gary Fredericks]

The generator should definitely always generate unique values (though only 
because gen/uuid does that), though as you say shrinking is different case 
that would be problematic for what you're doing. When you say "I don't see 
any other error" have you accounted for the fact that test.check normally 
returns *two* results after shrinking (the first failure, and the final 
failure)? This could be especially difficult to notice if the first failure 
was not an exception, and is being reported as merely false while the 
stacktrace of the final failure takes up your whole screen.

To be more precise, the original failure is under the :result key of the 
test.check result, while all the shrinking info is under :shrunk (including 
another :result key).

Other than that I don't have any ideas, but you should be able to check 
your theory about for-all reusing generated values by collecting them in an 
atom or something like that.

Gary

On Thursday, June 2, 2016 at 9:51:46 AM UTC-5, Tom wrote:
>
> Hi,
>
> I'm doing something like:
>
> (def valid-email (gen/fmap (fn [[name domain]] (str name "@" domain)) 
> (gen/tuple (gen/not-empty gen/string) gen/uuid)))
>
> (defspec test-email
>   100
>   (for-all [email valid-email]
>(tx-email! (get-in system [:database :conn]) email)
>
> The email has a unique-by-value constraint (in datomic) and this 
> transaction fails occasionally because the unique-by-value constraint 
> fails. However, this:
>
> (= 1000 (count (distinct (gen/sample valid-email 1000
>
> always succeeds. It seems like for-all reuses a generated value sometimes. 
> Could this be possible? Or maybe this happens when test.check tries to 
> shrink the test case? Except I don't see any other error, one that would 
> cause it to try to shrink.
>
> Thanks.
>
> -Tom
>
>

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

Re: clojure.spec generation question

[Gary Fredericks]

At a glance, this is probably the normal increasing-size behavior of 
test.check, and the bias should only be present for the first few samples. 
E.g., if you do a (take 1000 (gen/sample ...)), it should be more uniform.

Whether it's a real problem depends on how you're running your tests. I 
haven't yet looked into whether clojure.spec provides some default way of 
running test.check properties, so I'm not sure about that. But as long as 
you're running "enough" tests, e.g. >100, it should be fine.

On Monday, May 30, 2016 at 4:05:52 PM UTC-5, Jeroen van Dijk wrote:
>
> I'm trying to generate logical predicates in order to test a function that 
> should return the predicate in DNF. The generation seems to be biased 
> towards one of the predicates. What am I doing wrong?
>
> (require '[clojure.spec :as s])
> (require '[clojure.spec.gen :as gen])
>
> (s/def ::atom string?)
>
> (s/def ::predicate (s/or
> ::not-predicate
> ::and-predicate
> ::or-predicate
> ::atom))
>
> (s/def ::and-predicate (s/cat :pred #{:and} :args (s/+ ::predicate)))
> (s/def ::or-predicate  (s/cat :pred #{:or} :args (s/+ ::predicate)))
> (s/def ::not-predicate (s/tuple :pred #{:not} ::predicate))
>
> (prn (take 5 (gen/sample (s/gen ::predicate
> ;;=> 
> ((:and (:and "")) "" "X" "G" (:and "yd" (:and "c" "" (:and "F" (:and "" 
> "8" "Hb" "U0d")) "C") (:and (:and "1" "e" (:and "ME01" "w" "Y4" "" "P4") 
> "J4m4" "8") "Q7c" "") (:and (:and (:and "" "dG"))) "gw5"))
>
>
> No :or's or :not's here. If I change the order of s/or above the bias 
> changes. What's a better approach?
>
> Thanks,
> Jeroen
>
>

-- 
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: [Q] default decimal of Clojure is IEEE double, not BigDecimal

[Gary Fredericks]

Am I missing something? I realize doubles are generally faster because of 
hardware implementations , but that seems orthogonal from the question of 
syntax. I've several times thought idealistically that it could be better 
to have the syntaxes switched (to reduce the amount of accidental floating 
point use), and the only downsides I know of are A) surprising people 
(especially people who think they can divide 2 by 3 without thinking about 
it), and B) needing to be more careful when you're trying to use doubles 
for performance. Maybe you were referring to B?

Of course I do realize it's *way* too late to change it now ☺.

Gary

On Tuesday, December 22, 2015 at 9:23:43 AM UTC-6, Alex Miller wrote:
>
> It's done this way for performance.

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

[ANN] test.check 0.9.0

[Gary Fredericks]

 

I'm happy to announce the release today of version 0.9.0 of test.check, the 
QuickCheck-inspired property-based testing library. The changes in this 
release are a new minimum required version of Clojure (1.7) and a handful 
of new generators.


Clojure 1.7 is required now as the test.check codebase has been mostly 
ported to cljc files (thanks to Nicolás Berger for doing the tedious 
parts), which will make future development of test.check as a portable 
library much easier.


The biggest addition to the generators is a new macro called gen/let, which 
is an alternative to both gen/bind and gen/fmap, and will hopefully be more 
intuitive for many users. There is also now a uuid generator, a Double 
generator, a generator for large integers, and a handful of generators for 
collections of distinct elements.


I also added a cheatsheet 
 to 
the documentation, which will hopefully be a useful overview of the 
library's features (currently just the generators).

-- 
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: ArithmeticException while using unchecked-multiply

[Gary Fredericks]

Thanks andy!

On Monday, October 26, 2015 at 1:25:42 AM UTC-5, Andy Fingerhut wrote:
>
> While waiting to see what becomes of that ticket, if someone felt 
> energetic enough to document the gotchas with the unchecked functions, and 
> recommend how to get the desired results, e.g. either ^long type hints, or 
> if (long x) type conversions on the arguments work (I haven't checked), 
> Reid McKenzie's Grimoire updates can be made via pull request here:
>
> https://github.com/clojure-grimoire/datastore
>
> Or wiki edits can be made to ClojureDocs.org here:
>
> http://clojuredocs.org/clojure.core/unchecked-multiply
> http://clojuredocs.org/clojure.core/unchecked-add
> http://clojuredocs.org/clojure.core/unchecked-subtract
>
> Describing the odd behavior in only one of those entries, and then 
> cross-referencing it explicitly in the examples of the others to the 
> 'detailed one', can save redundancy in writing.
>
> Andy
>
>
> On Sun, Oct 25, 2015 at 11:17 PM, Andy Fingerhut <andy.fi...@gmail.com 
> > wrote:
>
>> I created this ticket: http://dev.clojure.org/jira/browse/CLJ-1832
>>
>> I don't know what will become of it, e.g. perhaps a change in behavior to 
>> the unchecked functions, perhaps a clarification to the documentation, 
>> perhaps nothing.  I wouldn't be surprised if the Clojure core team judged 
>> the existing documentation strings to be explicit enough because they use 
>> little-L 'long', and it doesn't promise any behavior of any kind for 
>> arguments that are not 'long'.
>>
>> Feel free to add comments or edit the description if I've left anything 
>> out, vote on it, etc.
>>
>> Andy
>>
>> On Sun, Oct 25, 2015 at 5:50 PM, Gary Fredericks <frederi...@gmail.com 
>> > wrote:
>>
>>> Half of the time that I use the unchecked functions it's for the math, 
>>> not the speed, so getting the wrong behavior when I don't care enough about 
>>> perf to do the work for primitives is pretty annoying.
>>>
>>>
>>> On Sunday, October 25, 2015 at 7:49:47 PM UTC-5, Gary Fredericks wrote:
>>>>
>>>> Maybe even not warn unless that one var where you can get 
>>>> boxed-math-warnings is set appropriately.
>>>>
>>>> On Sunday, October 25, 2015 at 2:04:36 PM UTC-5, Fluid Dynamics wrote:
>>>>>
>>>>> On Saturday, October 24, 2015 at 8:01:05 PM UTC-4, Gary Fredericks 
>>>>> wrote:
>>>>>>
>>>>>> I've always thought this is bad behavior, since it's blatantly doing 
>>>>>> the opposite of what the name advertises. I think either the boxed 
>>>>>> versions 
>>>>>> should return the same result as the unboxed version, or (if the whole 
>>>>>> point is to give good performance and so we don't want want users to be 
>>>>>> able to accidentally use the unboxed versions) it should throw at 
>>>>>> compile-time for boxed args.
>>>>>>
>>>>>
>>>>> Or it could emit just a warning at compile-time, and give the same 
>>>>> result at run-time as the unboxed version. Then you don't have to stop 
>>>>> everything else you're doing and fix the boxed math first, when you might 
>>>>> have higher priorities. The warnings will remind you to fix it 
>>>>> eventually. 
>>>>>
>>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com 
>>> 
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com 
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>

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

Re: ArithmeticException while using unchecked-multiply

[Gary Fredericks]

Maybe even not warn unless that one var where you can get 
boxed-math-warnings is set appropriately.

On Sunday, October 25, 2015 at 2:04:36 PM UTC-5, Fluid Dynamics wrote:
>
> On Saturday, October 24, 2015 at 8:01:05 PM UTC-4, Gary Fredericks wrote:
>>
>> I've always thought this is bad behavior, since it's blatantly doing the 
>> opposite of what the name advertises. I think either the boxed versions 
>> should return the same result as the unboxed version, or (if the whole 
>> point is to give good performance and so we don't want want users to be 
>> able to accidentally use the unboxed versions) it should throw at 
>> compile-time for boxed args.
>>
>
> Or it could emit just a warning at compile-time, and give the same result 
> at run-time as the unboxed version. Then you don't have to stop everything 
> else you're doing and fix the boxed math first, when you might have higher 
> priorities. The warnings will remind you to fix it eventually. 
>

-- 
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: ArithmeticException while using unchecked-multiply

[Gary Fredericks]

Half of the time that I use the unchecked functions it's for the math, not 
the speed, so getting the wrong behavior when I don't care enough about 
perf to do the work for primitives is pretty annoying.

On Sunday, October 25, 2015 at 7:49:47 PM UTC-5, Gary Fredericks wrote:
>
> Maybe even not warn unless that one var where you can get 
> boxed-math-warnings is set appropriately.
>
> On Sunday, October 25, 2015 at 2:04:36 PM UTC-5, Fluid Dynamics wrote:
>>
>> On Saturday, October 24, 2015 at 8:01:05 PM UTC-4, Gary Fredericks wrote:
>>>
>>> I've always thought this is bad behavior, since it's blatantly doing the 
>>> opposite of what the name advertises. I think either the boxed versions 
>>> should return the same result as the unboxed version, or (if the whole 
>>> point is to give good performance and so we don't want want users to be 
>>> able to accidentally use the unboxed versions) it should throw at 
>>> compile-time for boxed args.
>>>
>>
>> Or it could emit just a warning at compile-time, and give the same result 
>> at run-time as the unboxed version. Then you don't have to stop everything 
>> else you're doing and fix the boxed math first, when you might have higher 
>> priorities. The warnings will remind you to fix it eventually. 
>>
>

-- 
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: ArithmeticException while using unchecked-multiply

[Gary Fredericks]

I once set out to make a ticket for it, but ended up not probably because 
it was going to take too much effort to describe or something. I was 
probably busy.

On Saturday, October 24, 2015 at 7:01:05 PM UTC-5, Gary Fredericks wrote:
>
> I've always thought this is bad behavior, since it's blatantly doing the 
> opposite of what the name advertises. I think either the boxed versions 
> should return the same result as the unboxed version, or (if the whole 
> point is to give good performance and so we don't want want users to be 
> able to accidentally use the unboxed versions) it should throw at 
> compile-time for boxed args.
>
> On Saturday, October 24, 2015 at 9:35:46 AM UTC-5, Andy Fingerhut wrote:
>>
>> I can't answer whether Clojure should do that.
>>
>> It is doing it because unchecked-multiply falls back to normal multiply, 
>> i.e. *, unless both of its arguments are primitive long values.  Even boxed 
>> Long values cause it to fall back to the behavior of *.  The same goes for 
>> unchecked-add and unchecked-subtract.
>>
>>
>> user=> (unchecked-multiply 243290200817664 21)
>> -4249290049419214848
>> user=> (unchecked-multiply 243290200817664 (Long. 21))
>>
>> ArithmeticException integer overflow 
>>  clojure.lang.Numbers.throwIntOverflow (Numbers.java:1501)
>>
>> Andy
>>
>>
>> On Fri, Oct 23, 2015 at 1:54 PM, Garrett Rowe <gmrow...@gmail.com> wrote:
>>
>>> Should `unchecked-multiply` throw an exception in this case? (see also: 
>>> http://stackoverflow.com/questions/33306984/why-does-my-hash-function-fail-with-arithmeticexception-integer-overflow-even/33308956#33308956
>>> )
>>>
>>> user> (reduce unchecked-multiply (range 1 22))
>>> ArithmeticException integer overflow  clojure.lang.Numbers.throwIntOverflow 
>>> (Numbers.java:1388)
>>>
>>> The loop-recur version also fails, unless you use a type hint:
>>>
>>> user> (loop [n 1
>>>  r (range 1 22)]
>>> (if-let [a (first r)]
>>>   (recur (unchecked-multiply n a) (next r))
>>>   n))
>>> ArithmeticException integer overflow  clojure.lang.Numbers.throwIntOverflow 
>>> (Numbers.java:1388)
>>>
>>> user> (loop [n 1
>>>  r (range 1 22)]
>>> (if-let [^long a (first r)]
>>>   (recur (unchecked-multiply n a) (next r))
>>>   n))
>>> -4249290049419214848
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

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

Re: ArithmeticException while using unchecked-multiply

[Gary Fredericks]

I've always thought this is bad behavior, since it's blatantly doing the 
opposite of what the name advertises. I think either the boxed versions 
should return the same result as the unboxed version, or (if the whole 
point is to give good performance and so we don't want want users to be 
able to accidentally use the unboxed versions) it should throw at 
compile-time for boxed args.

On Saturday, October 24, 2015 at 9:35:46 AM UTC-5, Andy Fingerhut wrote:
>
> I can't answer whether Clojure should do that.
>
> It is doing it because unchecked-multiply falls back to normal multiply, 
> i.e. *, unless both of its arguments are primitive long values.  Even boxed 
> Long values cause it to fall back to the behavior of *.  The same goes for 
> unchecked-add and unchecked-subtract.
>
>
> user=> (unchecked-multiply 243290200817664 21)
> -4249290049419214848
> user=> (unchecked-multiply 243290200817664 (Long. 21))
>
> ArithmeticException integer overflow 
>  clojure.lang.Numbers.throwIntOverflow (Numbers.java:1501)
>
> Andy
>
>
> On Fri, Oct 23, 2015 at 1:54 PM, Garrett Rowe  > wrote:
>
>> Should `unchecked-multiply` throw an exception in this case? (see also: 
>> http://stackoverflow.com/questions/33306984/why-does-my-hash-function-fail-with-arithmeticexception-integer-overflow-even/33308956#33308956
>> )
>>
>> user> (reduce unchecked-multiply (range 1 22))
>> ArithmeticException integer overflow  clojure.lang.Numbers.throwIntOverflow 
>> (Numbers.java:1388)
>>
>> The loop-recur version also fails, unless you use a type hint:
>>
>> user> (loop [n 1
>>  r (range 1 22)]
>> (if-let [a (first r)]
>>   (recur (unchecked-multiply n a) (next r))
>>   n))
>> ArithmeticException integer overflow  clojure.lang.Numbers.throwIntOverflow 
>> (Numbers.java:1388)
>>
>> user> (loop [n 1
>>  r (range 1 22)]
>> (if-let [^long a (first r)]
>>   (recur (unchecked-multiply n a) (next r))
>>   n))
>> -4249290049419214848
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: Using type hints to optimize protocol invocation

[Gary Fredericks]

I'm not an expert on this subject, but two thoughts come to mind:


   1. the point of protocols is polymorphism, and if I understand you 
   correctly, the case you're describing is narrowed enough that it is *not* 
   polymorphic -- i.e., if the compiler can statically determine what code to 
   run, it's not polymorphic anymore, and you as the programmer could have 
   just called that code directly (though perhaps for some reason you might 
   not want to write it that way)
   2. the previous point notwithstanding, I don't think static type 
   information is enough to pick an implementation, because you could still 
   conceivably encounter (at runtime) subclasses of the annotated type with 
   their own implementations, and have to check for that
   

On Tuesday, September 8, 2015 at 3:59:41 PM UTC-5, Nathan Marz wrote:
>
> My understanding is that invocation of protocol methods incurs about 30% 
> overhead due to the need to look up the appropriate function for the type. 
> I also learned recently that Clojure does not use static type information 
> to do the lookup at compile-time and avoid the overhead. Given that Clojure 
> already does do some type analysis (to optimize Java method invocations), 
> why not do it for protocol invocation as well? Just trying to further my 
> understanding of the Clojure compiler. 
>
>
>

-- 
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] test.check 0.8.0

[Gary Fredericks]

oh yeah, my scale example did look a lot like fmap.

There is some context on the original jira ticket 
http://dev.clojure.org/jira/browse/TCHECK-68.

scale lets you modify the size of objects generated by a generator. So e.g. 
(gen/list 
gen/nat) will under normal settings generate lists of size 0-200 of numbers 
from 0-200. But if you scale it via (gen/scale #(* 1000 %) (gen/list 
gen/nat)) you will generate *much bigger* lists of larger numbers. Though 
probably more common uses for scale would be for limiting sizes (e.g., 
(gen/scale 
#(max % 20) gen/string)).

Gary

On Saturday, August 15, 2015 at 8:57:02 PM UTC-5, Laurens Van Houtven wrote:

 Hi Gary 


 Thanks a lot for your hard work; I'm a big fan of test.check and have been 
 tracking the RCs :)

 Could you help me understand  the difference between scale and fmap?


 thanks 
 lvh 

 Sent from my iPhone

 On Aug 15, 2015, at 13:08, Gary Fredericks frederi...@gmail.com 
 javascript: wrote:

 I'm happy to announce the release today of version 0.8.0 of test.check 
 https://github.com/clojure/test.check, the QuickCheck-inspired 
 property-based testing library. The release is light on new features, but 
 has a couple important changes: 

- The generators now use an immutable random number generator under 
the hood, which makes the determinism a lot less brittle and enables 
various extensions and new features 
- The ClojureScript namespaces have been renamed – all occurrences of 
`cljs` have been changed to `clojure` so that the clj and cljs namespaces 
are consistent. This is an internal improvement since it means we can 
upgrade the codebase to use .cljc files, but it also makes things easier 
for writing portable tools  tests for/with test.check. 

 Additionally there are two new generator functions: 

- scale: a function that lets you tweak the size of a given generator, 
e.g. (gen/scale #(* % 1000) gen/nat) 
- generate: an alternative to sample that returns a single generated 
object, defaulting to a larger size to give you an idea of what 
 non-trivial 
values look like for the generator 

 There are a handful of new features planned for upcoming releases: 

- running tests in parallel (on the jvm) 
- generating specifically-sized collections of distinct elements 
- better options for integration with other testing frameworks 

 As always I welcome any feedback, ideas, or experience reports. 


 Gary

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

[ANN] test.check 0.8.0

[Gary Fredericks]

 

I'm happy to announce the release today of version 0.8.0 of test.check 
https://github.com/clojure/test.check, the QuickCheck-inspired 
property-based testing library. The release is light on new features, but 
has a couple important changes: 

   - The generators now use an immutable random number generator under the 
   hood, which makes the determinism a lot less brittle and enables various 
   extensions and new features 
   - The ClojureScript namespaces have been renamed – all occurrences of 
   `cljs` have been changed to `clojure` so that the clj and cljs namespaces 
   are consistent. This is an internal improvement since it means we can 
   upgrade the codebase to use .cljc files, but it also makes things easier 
   for writing portable tools  tests for/with test.check. 

Additionally there are two new generator functions: 

   - scale: a function that lets you tweak the size of a given generator, 
   e.g. (gen/scale #(* % 1000) gen/nat) 
   - generate: an alternative to sample that returns a single generated 
   object, defaulting to a larger size to give you an idea of what non-trivial 
   values look like for the generator 

There are a handful of new features planned for upcoming releases: 

   - running tests in parallel (on the jvm) 
   - generating specifically-sized collections of distinct elements 
   - better options for integration with other testing frameworks 

As always I welcome any feedback, ideas, or experience reports. 


Gary

-- 
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: Need suggestions on how to write rand-interleave test.check generator.

[Gary Fredericks]

Another kind of approach that would be worth trying is adapting 
test.check's own shuffle generator 
https://github.com/clojure/test.check/blob/e3256cbaa3a98b1d688475fe190aa97ad255e08b/src/main/clojure/clojure/test/check/generators.clj#L447-465.
 
It generates a sequence of pairs of indexes and then swaps the elements at 
those indexes. The benefits are that you avoid the stack issues and also 
other disadvantages that come with using bind.

I tried one that only did adjacent swaps, and only when they didn't violate 
the constraint, but it took a lot of swaps for it to get really mixed up. I 
think something more clever could be better.

Gary

On Friday, August 14, 2015 at 9:43:52 AM UTC-5, Carlo wrote:

 Hey Mayank!

 Similarly to your attempt last time, you need to use gen/bind to get the 
 result of a generator which you can then use to make a new generator.

 (defn- rand-interleave* [coll acc]
   (if (seq coll)
 (gen/bind (gen/choose 0 (dec (count coll)))
   (fn [index]
 (let [value (first (get coll index))
   coll (- (update-in coll [index] next)
 (remove empty?)
 vec)]
   (rand-interleave* coll (conj acc value)
 (gen/return acc)))

 (defn rand-interleave [ colls]
   (rand-interleave* (vec colls) []))

 The (gen/choose 0 (dec (count coll))) is similar to your rand-count 
 function, then the generated number is passed to the function as result. 
 Writing it this way will shrink towards the (apply concat args) (ie. as 
 it shrinks it will move towards just concatenating the arguments).

 In terms of the recursion: this will eventually overflow the stack. I 
 don't know of a way to trampoline generators, so I don't know how to avoid 
 that. (This is a bit of a recurring problem with monadic code in Clojure, I 
 feel, as algo.monads had a similar problem last time I checked.) For the 
 moment I'm just ignoring this theoretical problem until it becomes a 
 practical problem.

 I hope that helps!

 Carlo

 On 14 August 2015 at 23:39, Mayank Jain fires...@gmail.com javascript: 
 wrote:

 Hi Everyone,

 Here's the problem I am facing,
 I need to write a generator which takes any number of sequences,
 interleaves them but maintains the order within each sequence.
 Assume each sequence has at least one element.

 For example:

 (rand-interleave [1 2 3 4] [:a :b] [:A :B :C :D :E])
 = [:a 1 2 :b :A :B :C 3 :D 4 :E]


 (rand-interleave [1 2 3 4])
 = [1 2 3 4]


 (rand-interleave [1])
 = [1]


 (rand-interleave [1] [:a] [:A])
 = [:a 1 :A]


 I have been able to write this down as clojure functions.
 But I am unable to convert this into a test.check generator.

 Specifically:

- How to pass random index count without using rand-int i.e. use 
gen/choose
- How do I write recursive functions which play well with test.check

 Here's my take on it (without the generators).

 (defn- first-nth
   (first-nth [[1 2 3 4] [:a :b :c :d]]
   1)
= :a
   [coll n]
   (first (nth coll n))) 

  

 (defn- next-nth
   (next-nth [[1 2 3 4] [:a :b :c :d]]
   1)
= [[1 2 3 4] (:b :c :d)]
   [coll n]
   (- n
(nth coll)
next
(assoc coll n)
(remove nil?)
vec)) 

  

 (defn- rand-count
   [coll]
   (rand-int (count coll))) 

  

 (defn- rand-interleave*
   [coll acc]
   (let [n (rand-count coll)]
 (if (not-empty coll)
   (rand-interleave* (next-nth coll n)
   (conj acc
   (first-nth coll n)))
   acc))) 

  

 (defn rand-interleave
   [ args]
   ;; Make args a vector as I would like to
   ;; look up elements by their index values.
   (rand-interleave* (vec args) []))


 Looking forward to any suggestions on how to solve it :)

 Thanks,
 Mayank.

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

[ANN] new library for portable exact arithmetic

[Gary Fredericks]

Hello,

I've just released a new library called exact 
https://github.com/gfredericks/exact for doing cross-platform arithmetic 
with [big]-integers and ratios.

I don't anticipate it getting a whole lot of use, but I thought I would 
point it out here in case I'm wrong about that. The library might not be 
Super Awesome but it should at least Work Pretty Good.

Gary

-- 
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: Generating varying sized map using test.check

[Gary Fredericks]

It also might be helpful to know that there is already a subset generator 
available in this library 
https://github.com/gfredericks/test.chuck#generators.

Gary

On Saturday, July 25, 2015 at 6:54:59 PM UTC-5, Carlo wrote:

 Hey Mayank!

 What you've done here might appear to work, but it will get you into 
 trouble when test.check starts to shrink your inputs. When test.check runs 
 your generators it relies you you using it as your only source of 
 randomness, and so your use of `rand-int` will cause some problems.

 The trick is to use the `bind` function to make a generator which depends 
 on the value of another generator (in this case, to capture the generated 
 map so you can call rand-subset with the correct set of keys):

 (defn rand-subset
   Given a collection coll
it'll generate a random subset.
   [coll]
   (gen/fmap (fn [i] (combo/nth-subset coll i))
 (gen/choose 0 (dec (combo/count-subsets coll)

 (defn gen-varying-map
   Given a generator which generates a map,
it'll randomly select keys from it thus making it
varying-sized map.
Note: It can return empty maps as well.
   [map-gen]
   (gen/bind map-gen
 (fn [map]
   (gen/fmap (fn [keyseq]
   (select-keys map keyseq))
 (rand-subset (keys map))

 (gen/sample (gen-varying-map (gen/hash-map
   user (gen/such-that not-empty 
 gen/string-alpha-numeric)
   level gen/nat
   timezone gen/pos-int)))
 =
 ({user e, level 0}
  {level 1}
  {user M1}
  {timezone 2}
  {user 2, level 2, timezone 0}
  {timezone 3}
  {user W, level 5, timezone 0}
  {timezone 5}
  {}
  {})

 This output appears the same as yours, but it will produce predictable 
 shrink trees, and thus will shrink more effectively.

 Carlo

 On 26 July 2015 at 07:10, Mayank Jain fires...@gmail.com javascript: 
 wrote:

 Hi,

 I would like to generate variable sized map using test.check i.e.
 given any generator which generates a map, it should randomly select-keys 
 from it.

 Here's what I've come up with so far:
  

 (ns proj.util
   (:require [clojure.test.check.generators :as gen]
 [clojure.math.combinatorics :as combo]))

 (defn rand-subset
   Given a collection coll,
it'll generate a random subset.
   [coll]
   (- coll
combo/count-subsets
rand-int
(combo/nth-subset coll)))

 (defn gen-varying-map
   Given a generator which generates a map,
it'll randomly select keys from it thus making it
varying-sized map.
Note: It can return empty maps as well.
   [map-gen]
   (gen/fmap (fn [m]
   (let [ks (rand-subset (keys m))]
 (select-keys m ks)))
 map-gen))

 Here's an example output,
 (gen/sample (gen-varying-map (gen/hash-map
   user (gen/such-that not-empty
 
 gen/string-alphanumeric)
   level gen/nat
   timezone gen/pos-int)))
 = 
 ({user 1}
  {user l8, level 0, timezone 1}
  {level 1}
  {user oA, timezone 0}
  {level 2, timezone 1}
  {level 5}
  {user 8aP, level 5, timezone 6}
  {user 035rqi, level 7}
  {timezone 4}
  {timezone 2})

 My question is, is this the right way? Or is there a better way to do it?

 Thanks :)

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

[ANN] test.check alpha release (with immutable random number generator)

[Gary Fredericks]

 

I'm excited to announce an important alpha release of test.check, the 
QuickCheck-inspired property-based testing library[1]. The 0.8.0 release 
will be the first release with the new immutable splittable random number 
generator[2], which is not really a user-facing change but is a serious 
implementation change with associated performance risk. 


So we're starting with an alpha release and would like to hear feedback 
from people trying it on real test suites. If you'd simply like to run your 
tests and let us know if they seemed any slower, that would certainly be 
helpful. If you'd like to put in slightly more effort to get more 
quantifiable results, I have some brief instructions for benchmarking your 
test suite runtimes[3]. 


The release otherwise will likely have just minor user-facing changes (the 
addition of a `scale` function for transforming a generator's size, and a 
`generate` function for getting a single large sample from a generator), 
but the immutable random number generator will enable implementing several 
other useful features robustly, such as parallel tests and a better API for 
re-running failing tests. 


 The alpha release is at [org.clojure/test.check 0.8.0-alpha3]. 


Thanks!


Gary Fredericks


[1] https://github.com/clojure/test.check
[2] https://www.youtube.com/watch?v=u0t-6lUvXHo
[3] https://gist.github.com/gfredericks/c9eb5563651626626155

-- 
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: eval/macros with functions with metadata

[Gary Fredericks]

what's the use case for evaling a function object?


On Tue, Aug 27, 2013 at 8:54 PM, Ben Wolfson wolf...@gmail.com wrote:

 or, the dreaded no matching ctor found exception.

 Is there a way to write the function

 (defn eval-at-one [f] (eval `(~f 1)))

 such that it works when invoked like this:

 (eval-at-one (fn [x] x))
  ;; -- 1

 and like this

 (eval-at-one (with-meta (fn [x] x) {}))
  ;; - IllegalArgumentException No matching ctor found for class
 clojure.lang.AFunction$1  clojure.lang.Reflector.invokeConstructor
 (Reflector.java:163)

 ?

 I thought that the object returned by with-meta might be hanging onto the
 original, metadata-less object, which could then be retrieved and used
 without difficulty, but this appears not to be the case.

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




-- 
Gary Fredericks
(803)-295-0195
fredericksg...@gmail.com
www.gfredericks.com

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

Re: Easiest way to map over leaf nodes of nested sequence

[Gary Fredericks]

the function cleans up slightly with cond-. I don't think you can get
around having to specify how to recognize a leaf, for any general solution.


On Tue, Aug 27, 2013 at 10:27 PM, JvJ kfjwhee...@gmail.com wrote:

 I suppose that works, but it seems a little inelegant to do this:
 (prewalk #(if (sequential? %) % (f %)) xs)
 instead of just
 (prewalk f xs)


 On Tuesday, 27 August 2013 20:06:38 UTC-7, gfredericks wrote:

 Clojure.walk
 On Aug 27, 2013 10:05 PM, JvJ kfjwh...@gmail.com wrote:

  I feel like this question has been asked about a trillion times, but I
 was having a hard time finding a straight answer.  Is there a really
 straightforward way in the standard library or in one of the contrib
 libraries to do something like this:
 (nested-map inc '(1 (2 3) (4 (5 (6) === '(2 (3 4) (5 (6 (7

 --
 --
 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=enhttp://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to clojure+u...@**googlegroups.com.

 For more options, visit 
 https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
 .

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




-- 
Gary Fredericks
(803)-295-0195
fredericksg...@gmail.com
www.gfredericks.com

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

Re: Easiest way to map over leaf nodes of nested sequence

[Gary Fredericks]

Clojure.walk
On Aug 27, 2013 10:05 PM, JvJ kfjwhee...@gmail.com wrote:

 I feel like this question has been asked about a trillion times, but I was
 having a hard time finding a straight answer.  Is there a really
 straightforward way in the standard library or in one of the contrib
 libraries to do something like this:
 (nested-map inc '(1 (2 3) (4 (5 (6) === '(2 (3 4) (5 (6 (7

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


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

Type hint puzzler

[Gary Fredericks]

Can anybody figure out how I can type hint this adequately? Not only does
it result in reflection, but because a Fn is both a Runnable and Callable,
it can result in runtime incorrectness:

https://gist.github.com/fredericksgary/6058783

-- 
Gary Fredericks
(803)-295-0195
fredericksg...@gmail.com
www.gfredericks.com

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

Re: Remove-first function

[Gary Fredericks]

Well obviously if you can get something to be tail-recursive you won't have
the stack overflows, and the thing in your code that prevents tail recursion
is having to cons the result of the recursive call. So let's try this:

(defn remove-first
  [syb lst]
  (let [[before after]
  (loop [b [] a lst]
(if (empty? lst)
  [b a]
  (if (= syb (first a))
[b (rest a)]
(recur (cons (first a) b) (rest a)]
   (concat (reverse before) after)))

user= (remove-first 4 '(1 5 3 4 2 6 674 4 2))
(1 5 3 2 6 674 4 2)

I'm interested if somebody comes up with something more efficient, i.e. that
doesn't require the reversal.

Gary

On Sat, Jul 24, 2010 at 11:41 AM, nickikt nick...@gmail.com wrote:

 Hallo all,

 I'm working trough Essentials of Programming Languages. I'm trying to
 right a function like this one:

 (defn scheme-remove-first [syb lst]
  (if (empty? lst)
'()
(if (= (first lst) syb)
  (rest lst)
  (cons (first lst) (scheme-remove-first syb (rest lst))

 in a idiomatic clojure way (this is just a scheme to clojure 1:1
 version). I don't like that this function produces stack overflows.

 I tried some stuff but I it (almost) semantically correct working but
 I didn't like my code. Can anyone come up with a good version?

 --
 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.comclojure%2bunsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en




-- 
Gary Fredericks
(660)-623-1095
fredericksg...@gmail.com
www.gfredericks.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