Re: extend-type and extend-protocol: different syntax for multi-arity methods

[Alexey Cherkaev]

Hi Tassilo,

Thanks for the reply.

The thing is, although the implementations for extending protocols directly
in records and with extend-type might be different, there is no reason why
the syntax should be different: from Clojure-programmer perspective it’s
all the same. It is a leaked abstraction if we have to thing about those
details. The same applies for interface implementation: overloaded methods
there and multi-arity functions in Clojure shouldn’t look differently to a
Clojure programmer (unless there is some more profound difference).
​


Best regards,
Alexey

On 13 May 2015 at 14:46, Tassilo Horn  wrote:

> Alexey Cherkaev  writes:
>
> Hi Alexey,
>
> > If you have a protocol
> >
> > (defprotocol Foo (foo [x] [x y]))
> >
> > and implement it for the record
> >
> > (defrecord Bar [p q r]
> >   Foo
> >   (foo [x] x)
> >   (foo [x y] [x y]))
> >
> > you write each method separately.  The same is true for extend-type.
> > Yet, if you use extend-protocol syntax is more like usual Clojure
> > multi-arity function definition:
> >
> > (extend-protocol Foo
> >   Bar
> >   (foo
> >  ([x] x)
> >  ([x y] [x y])))
> >
> > The first question is why there is a difference?
>
> I think, the difference is that deftype/defrecord create an interface
> (and an implementation class) under the hoods, and there, the different
> arities of foo are actually different methods.
>
> extend/extend-type/extend-protocol dynamically extend a protocol to some
> type.  Basically, the protocol's underlying dynamic dispatch table gets
> a new [type impl-function] entry where impl-function is a real Clojure
> function, thus you must specify all arities you want to support the
> normal Clojure way.
>
> > Secondly, if you mess up which syntax is where, the error you will get
> > is quite obscure, nothing guards you against essentially a *wrong
> > syntax*: both extend-type and extend-protocol are macros, so it
> > shouldn’t be too difficult to add a quick check on correctness.
>
> Yeah, for extend-protocol/extend-type the standard multi-arity syntax is
> the only correct one.
>
> > But lastly, wouldn’t it be better to have a uniform syntax?
>
> The problem is that defrecord and deftype also allow for implementing
> interfaces.  If Foo above was an interface, foo with 1 argument and foo
> with 2 arguments are completely separate methods (ok, they overload),
> thus it makes sense to define them separately.  However, if Foo was a
> protocol, it would also make sense to notate it as multi-arity function.
> But then you have an inconsistent syntax inside defrecord/deftype.
> Well, although one could argue that this was a good thing because it
> would allow to see immediately if Foo was a protocol or an interface.
>
> Bye,
> Tassilo
>

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

Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Amith George]

I wrote the following code to solve this challenge - 
https://www.reddit.com/r/dailyprogrammer/comments/35s2ds/20150513_challenge_214_intermediate_pile_of_paper/.

Code - 
https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/56ce1dbb6a08e96150dc85934caecfeb68108a53/src/rdp/214_intermediate.clj

I executed the -main function using `lein run 1`. 

Output

;; lein run 1

0 12605919
1 3578145
2 15356894
3 19134293
4 2394558
5 15030409
6 6424953
7 14893444
8 1592254
9 1914025
10 7075106
"Elapsed time: 501168.972435 msecs"

The code originally used an immutable hashmap, but I lost patience waiting 
for the computation to end. With mutable hashmap, it still takes around 8 
mins.

I wrote a C# version of the above code - 
https://gist.github.com/amithgeorge/766b8220f39d48221e58. It finishes under 
40secs. The C# exe was built under Release mode and executed directly from 
the commandline. I expected the Clojure version to perform similarly.

Any tips on what I am doing wrong?

-
Explanation of the code - Create a vector of all paper sheets, such that 
the sheet placed last is the first element of the vector and the last 
element is the canvas. To compute the frequency of each visible color - for 
each point in the canvas find the first sheet in the vector that covers the 
point. Store/increment its count in the hashmap. I understand there might 
be better more efficient ways to solve this, but currently I am interested 
in why the Clojure versions is so slow vis-a-vis the C# 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.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 the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Amith George]

I forgot to link the input files 

https://raw.githubusercontent.com/fsufitch/dailyprogrammer/0e4bb5ba1e3bc6e749b9e9bb49387513d5a623b7/ideas/pile_of_paper/100rects100x100.in
https://raw.githubusercontent.com/fsufitch/dailyprogrammer/0e4bb5ba1e3bc6e749b9e9bb49387513d5a623b7/ideas/pile_of_paper/100rects100Kx100K.in

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

Managing database schema

[Colin Yates]

Is there a lib that will allow me to have my sql defined in a file which I 
can reference from Clojure? I cannot use one of the existing migration 
libraries as I need to do more than just manipulate SQL on a version 
upgrade.

I am aware of yesql which would be great but it didn't work out for DDL. 
Specifically yesql seems to associate one block of sql for each name. I 
want to have multiple blocks (e.g. a 'create table ...' as well as a number 
of 'alter table create index idx_').

I have tried embedding the sql as a string in the .clj file. This isn't as 
painful as it might sound but is still painful enough.

Any suggestions?

-- 
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: Managing database schema

[Gadzhi Musaev]

Have you looked at ragtime? Particularly it's sql.files library. As far as
I see, it will suit your needs.

https://github.com/weavejester/ragtime

On 14 May 2015 at 11:45, Colin Yates  wrote:

> Is there a lib that will allow me to have my sql defined in a file which I
> can reference from Clojure? I cannot use one of the existing migration
> libraries as I need to do more than just manipulate SQL on a version
> upgrade.
>
> I am aware of yesql which would be great but it didn't work out for DDL.
> Specifically yesql seems to associate one block of sql for each name. I
> want to have multiple blocks (e.g. a 'create table ...' as well as a number
> of 'alter table create index idx_').
>
> I have tried embedding the sql as a string in the .clj file. This isn't as
> painful as it might sound but is still painful enough.
>
> Any suggestions?
>
>  --
> 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: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Mikera]

My general rule of thumb is that "idiomatic" Clojure is about 10x slower 
than Java. So this result doesn't really surprise me.

If you want to get maximum performance, you will have to do some more 
advanced / non-idiomatic things like:
- Add type hints for classes and primitive values
- Use "deftype" for your data structures
- Use loop/recur rather than more functional looping constructs
- Avoid laziness
- Use Java arrays for accumulating / mutating values
- Use Java classes like java.util.HashMap, java.util.ArrayList as 
appropriate

On Thursday, 14 May 2015 16:02:42 UTC+8, Amith George wrote:
>
> I wrote the following code to solve this challenge - 
> https://www.reddit.com/r/dailyprogrammer/comments/35s2ds/20150513_challenge_214_intermediate_pile_of_paper/
> .
>
> Code - 
> https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/56ce1dbb6a08e96150dc85934caecfeb68108a53/src/rdp/214_intermediate.clj
>
> I executed the -main function using `lein run 1`. 
>
> Output
>
> ;; lein run 1
>
> 0 12605919
> 1 3578145
> 2 15356894
> 3 19134293
> 4 2394558
> 5 15030409
> 6 6424953
> 7 14893444
> 8 1592254
> 9 1914025
> 10 7075106
> "Elapsed time: 501168.972435 msecs"
>
> The code originally used an immutable hashmap, but I lost patience waiting 
> for the computation to end. With mutable hashmap, it still takes around 8 
> mins.
>
> I wrote a C# version of the above code - 
> https://gist.github.com/amithgeorge/766b8220f39d48221e58. It finishes 
> under 40secs. The C# exe was built under Release mode and executed directly 
> from the commandline. I expected the Clojure version to perform similarly.
>
> Any tips on what I am doing wrong?
>
> -
> Explanation of the code - Create a vector of all paper sheets, such that 
> the sheet placed last is the first element of the vector and the last 
> element is the canvas. To compute the frequency of each visible color - for 
> each point in the canvas find the first sheet in the vector that covers the 
> point. Store/increment its count in the hashmap. I understand there might 
> be better more efficient ways to solve this, but currently I am interested 
> in why the Clojure versions is so slow vis-a-vis the C# 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.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: Probabilistic programming anyone?

[Frank Wood]

A complete comparison would take quite a long time and probably warrants a 
journal paper-length effort.  In short:

Anglican: fast, composable queries, parallel, expressive - slower than Stan 
for models in which one can use HMC and less modular than Venture
Stan: no recursion, continuous valued parameters only; good mixing thanks 
to gradients and HMC
Venture: same expressivity; dependency tracking allowing slightly greater 
diversity of inference techniques albeit at (currently) high overhead, 
"programmable" inference, 


On Wednesday, May 13, 2015 at 7:14:38 AM UTC+1, Sunil Nandihalli wrote:
>
> Hi Frank,
>  I am looking forward to giving it a shot. I am familiar with and used 
> Stan. While I understand that stan may not as flexible. A comparison with 
> of Anglician with Venture and Stan would be very much appreciated. Thanks 
> for probabilistic-language embedded in clojure.
>
> Sunil.
>
> On Wed, May 13, 2015 at 1:16 AM, > wrote:
>
>> Another question: is there a particular reason why the code of Anglican 
>> is hosted on BitBucket with read only access for outsider, whereas the 
>> examples are on Github? Does that mean that you do not anticipate 
>> contributions to the language from the outside? I saw the license is GPL 
>> though.
>>
>> On Tuesday, May 12, 2015 at 3:05:50 AM UTC-7, Frank Wood wrote:
>>
>>> I'm a professor at Oxford and my group has been working on a new 
>>> embedded language called Anglican:
>>>
>>> http://www.robots.ox.ac.uk/~fwood/anglican/
>>>
>>> It can be used to do advanced machine learning in Clojure (Java, etc.) 
>>> applications without having to know anything about inference or math.  For 
>>> example see:
>>>
>>> http://www.robots.ox.ac.uk/~fwood/anglican/examples/index.html
>>>
>>> My group would be very interested to get feedback on the language design 
>>> and its usefulness to the community.  Also, frankly, we could use your help 
>>> in taking it forward, where "help" largely means writing queries and 
>>> telling us what doesn't work.
>>>
>>  -- 
>> 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: Probabilistic programming anyone?

[Frank Wood]

We'd love to have contributions!  It's read only for outsider for now -- 
we'd like you to "sign-up" if you're going to be making pull requests, etc.

The examples are on github only momentarily -- it's a mirror of a bitbucket 
repo.  The public release of the eaxmples was easier for silly technical 
reasons to do it that way.   Don't read anything into it! 

On Tuesday, May 12, 2015 at 8:51:21 PM UTC+1, hy...@juji-inc.com wrote:
>
> Another question: is there a particular reason why the code of Anglican is 
> hosted on BitBucket with read only access for outsider, whereas the 
> examples are on Github? Does that mean that you do not anticipate 
> contributions to the language from the outside? I saw the license is GPL 
> though.
>
> On Tuesday, May 12, 2015 at 3:05:50 AM UTC-7, Frank Wood wrote:
>>
>> I'm a professor at Oxford and my group has been working on a new embedded 
>> language called Anglican:
>>
>> http://www.robots.ox.ac.uk/~fwood/anglican/
>>
>> It can be used to do advanced machine learning in Clojure (Java, etc.) 
>> applications without having to know anything about inference or math.  For 
>> example see:
>>
>> http://www.robots.ox.ac.uk/~fwood/anglican/examples/index.html
>>
>> My group would be very interested to get feedback on the language design 
>> and its usefulness to the community.  Also, frankly, we could use your help 
>> in taking it forward, where "help" largely means writing queries and 
>> telling us what doesn't work.
>>
>

-- 
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: Managing database schema

[Colin Yates]

Thanks, I'll take a look

Sent from my iPhone

> On 14 May 2015, at 10:18, Gadzhi Musaev  wrote:
> 
> Have you looked at ragtime? Particularly it's sql.files library. As far as I 
> see, it will suit your needs.
> 
> https://github.com/weavejester/ragtime
> 
>> On 14 May 2015 at 11:45, Colin Yates  wrote:
>> Is there a lib that will allow me to have my sql defined in a file which I 
>> can reference from Clojure? I cannot use one of the existing migration 
>> libraries as I need to do more than just manipulate SQL on a version upgrade.
>> 
>> I am aware of yesql which would be great but it didn't work out for DDL. 
>> Specifically yesql seems to associate one block of sql for each name. I want 
>> to have multiple blocks (e.g. a 'create table ...' as well as a number of 
>> 'alter table create index idx_').
>> 
>> I have tried embedding the sql as a string in the .clj file. This isn't as 
>> painful as it might sound but is still painful enough.
>> 
>> Any suggestions?
>> 
>> -- 
>> 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.

-- 
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: Managing database schema

[Stuart Sierra]

You can put a .sql file in /resources and read it with 
clojure.java.io/resource.
–S


On Thursday, May 14, 2015 at 9:45:31 AM UTC+1, Colin Yates wrote:
>
> Is there a lib that will allow me to have my sql defined in a file which I 
> can reference from Clojure? I cannot use one of the existing migration 
> libraries as I need to do more than just manipulate SQL on a version 
> upgrade.
>
> I am aware of yesql which would be great but it didn't work out for DDL. 
> Specifically yesql seems to associate one block of sql for each name. I 
> want to have multiple blocks (e.g. a 'create table ...' as well as a number 
> of 'alter table create index idx_').
>
> I have tried embedding the sql as a string in the .clj file. This isn't as 
> painful as it might sound but is still painful enough.
>
> Any suggestions?
>
>

-- 
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: separation of concerns w/o encapsulation

[Sean Corfield]

On May 13, 2015, at 11:07 PM, Brian Craft  wrote:
> http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)#As_information_hiding_mechanism
>  
> 

In an environment where you can’t trust your co-workers(!), you certainly want 
to hide *mutable* data so they can’t modify your objects’ state. When you 
remove mutability, there’s a lot less damage they can do and they it’s really 
more about which pieces of the system do you not want them to "use" (in terms 
of functional APIs).

The "Clojure Way" seems to be "just make all functions public — they might be 
useful to someone" although that then restricts what refactoring you can do in 
future compared to exposing a smaller surface area. Since you can always call 
private functions anyway (and access private data directly), you really need 
conventions — and code review — to prevent abuse, and at that point having 
foo.api and foo.impl namespaces — and a convention to not use foo.impl outside 
of foo.api — is very reasonable and even automatically enforceable through 
tooling.

When I first started doing Clojure (five years ago — yikes! feels like 
yesterday!) I still had an OOP mindset around data hiding and I used defn- and 
^:private a lot (well, ^{:private true} back then I guess). These days I tend 
to make all my functions public and use namespaces if necessary to clearly 
delineate APIs vs implementations. A def of immutable data tends to be public 
too. It’s rare that I feel the need to make things private since immutability 
means no one can "abuse" my data or my functions.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



-- 
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: separation of concerns w/o encapsulation

[Colin Yates]

I guess a related concern is abstraction. I notice I often have functions
which work at different levels of abstraction in the same ns which makes me
uncomfortable. In OO land they would be package level or even instance
classes. I haven't yet found a way to solve this in clojure land.

To be explicit, I have a defn which calls a defn which calls a defn which
calls , having all of those defns public doesn't capture the hierarchy
of abstraction.
On 14 May 2015 17:14, "Sean Corfield"  wrote:

> On May 13, 2015, at 11:07 PM, Brian Craft  wrote:
>
>
> http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)#As_information_hiding_mechanism
>
>
> In an environment where you can’t trust your co-workers(!), you certainly
> want to hide *mutable* data so they can’t modify your objects’ state. When
> you remove mutability, there’s a lot less damage they can do and they it’s
> really more about which pieces of the system do you not want them to "use"
> (in terms of functional APIs).
>
> The "Clojure Way" seems to be "just make all functions public — they might
> be useful to someone" although that then restricts what refactoring you can
> do in future compared to exposing a smaller surface area. Since you can
> always call private functions anyway (and access private data directly),
> you really need conventions — and code review — to prevent abuse, and at
> that point having foo.api and foo.impl namespaces — and a convention to not
> use foo.impl outside of foo.api — is very reasonable and even automatically
> enforceable through tooling.
>
> When I first started doing Clojure (five years ago — yikes! feels like
> yesterday!) I still had an OOP mindset around data hiding and I used
> *defn-* and *^:private* a lot (well, *^{:private true}* back then I
> guess). These days I tend to make all my functions public and use
> namespaces if necessary to clearly delineate APIs vs implementations. A
> *def* of immutable data tends to be public too. It’s rare that I feel the
> need to make things private since immutability means no one can "abuse" my
> data or my functions.
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
>  --
> 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: separation of concerns w/o encapsulation

[Sean Corfield]

On May 14, 2015, at 10:28 AM, Colin Yates  wrote:
> I guess a related concern is abstraction. I notice I often have functions 
> which work at different levels of abstraction in the same ns which makes me 
> uncomfortable. In OO land they would be package level or even instance 
> classes. I haven't yet found a way to solve this in clojure land.
> To be explicit, I have a defn which calls a defn which calls a defn which 
> calls , having all of those defns public doesn't capture the hierarchy of 
> abstraction.

…although it would allow other users of your code to build their own 
abstraction hierarchies. They can’t do that if you make things private 
"arbitrarily".

If you really want to separate them and provide strong guidance that there is 
an intended hierarchy of abstractions, put them in different namespaces — named 
to indicate the layers in your hierarchy — and leave them all public.

That creates a much more reusable, extensible code base. IMO (now — I didn’t 
think that way five years ago).

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



-- 
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 the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Raoul Duke]

Ditto F# vs. C#.

One has to wonder when / where / if functional-pure-immutable
approaches will ever under the covers get "fast enough"?

-- 
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 the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Timothy Baldridge]

I think it false view that immutable/functional constructs are slow by
default. Instead, a lot of it comes down to lack of support in the popular
VMs for these constructs. For example the following code:

(defn add-fn [& args]
  (reduce -add 0 args))

(loop [x 0]
  (if (eq x 1)
x
(recur (add-fn x 1

Is never going to be super fast in Clojure, but it compiles down to a loop
with 4 assembly operations in Pixie (https://github.com/pixie-lang/pixie)
all while remaining fully dynamic. But that's because the VM is tuned to
optimize things like varargs and reduce. You can't really tap into the VM
at that level on the CLR or the JVM.

That's not to say that Pixie is always faster than these platforms, on the
contrary, it's often much slower on GC heavy operations. But hopefully
someday we'll reach the holy grail of a VM that aggressively optimizes
dynamic languages without requiring hinting or rewriting into less
idiomatic forms.

Timothy

On Thu, May 14, 2015 at 12:36 PM, Raoul Duke  wrote:

> Ditto F# vs. C#.
>
> One has to wonder when / where / if functional-pure-immutable
> approaches will ever under the covers get "fast enough"?
>
> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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 the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Jorge Branco]

I could be a bit off here, but I'd say the speed differences between
Clojure and Java are actually due to immutability AND weak-typing, while in
C# vs F# the difference should be less pronounced and governed primarily by
the use of immutability (i.e., using mutable data-structures yield results
in the same order of magnitude)?

On Thu, May 14, 2015 at 7:36 PM, Raoul Duke  wrote:

> Ditto F# vs. C#.
>
> One has to wonder when / where / if functional-pure-immutable
> approaches will ever under the covers get "fast enough"?
>
> --
> 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.

a record that implements the iFn protocol can itself be called as a function?

[piastkrakow]

The docs offer this example: 

https://clojuredocs.org/clojure.core/defrecord

user=> (defrecord Someone [nick-name preffered-drink] Fun-Time (drinky-drinky 
[_] (str nick-name "(having " preffered-drink "): uuumm")))
user.Someone

user=> (def dude (->Someone "belun" "daiquiri"))
#'user/dude

user=> (drinky-drinky dude)
"belun(having daiquiri): uuumm"

But if a record implements clojure.lang.IFn it can be called directly? Do I 
understand this correctly? When I run macroexpand-all on defrecord-ifn, as 
defined here: 

https://github.com/overtone/overtone/blob/e200075da27375727db1f5ce342e2e1c22ea1dbd/src/overtone/helpers/lib.clj

I see that it extends clojure.lang.IFn as in: 

clojure.lang.IFn 
(invoke [this__1446__auto__] 
  ((fn [this & args] 
(apply synth-player sdef params this [:tail instance-group] args)) 
this__1446__auto__)) 
(invoke [this__1447__auto__ arg0] 
  ((fn [this & args] 
(apply synth-player sdef params this [:tail instance-group] args)) 
this__1447__auto__ arg0)) 
// etc, all 20 arities are defined

So, that means I could call the record as a function? 


-- 
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: separation of concerns w/o encapsulation

[Erik Price]

On Thu, May 14, 2015 at 12:14 PM, Sean Corfield  wrote:

>
> In an environment where you can’t trust your co-workers(!), you certainly
> want to hide *mutable* data so they can’t modify your objects’ state. When
> you remove mutability, there’s a lot less damage they can do and they it’s
> really more about which pieces of the system do you not want them to "use"
> (in terms of functional APIs).
>

The code itself is mutable. The nice thing about a private function is that
I have reserved the right to change how it works someday, without fear that
others have become dependent on the way it currently works.

e

-- 
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 the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Alex Miller]

The major problem here is that you are using boxed math for everything 
instead of primitives.

0) Switch to Clojure 1.7.0-beta3 - it's faster and some things below are 
dependent on it for best performance. And use Java 1.8.
1) Parse the lines you're reading directly into longs (Clojure focuses on 
64-bit primitives - longs and doubles)
2) Put the longs first into a data structure that preserves the primitive 
type. The two best options for that here are records (which can have 
primitive fields) and arrays. I would create a Canvas defrecord with ^long 
width and height and a Paper defrecord with all ^long fields for example. 
3) Store the papers in a vector (using transient to create it)
4) I suspect visible-color and covered? could probably be tightened up into 
a reduce over papers or a single loop-recur over papers - can't say I 
totally get what's happening there.
5) In visible-color-frequencies, you could use "update" instead of get + 
transient assoc! on the acc map, but this is never going to be terribly 
fast. Another option here would be to create an array with the max color 
(you could track that while reading if it's not a well-known answer) and 
bash the array. That can retain int or long counters and will be *way* 
faster.
6) You can use (set! *unchecked-math* :warn-on-boxed) to get faster math 
(no overflow checks) and also issue warnings (added in 1.7) if you happened 
to use boxed math by accident. 



On Thursday, May 14, 2015 at 3:02:42 AM UTC-5, Amith George wrote:
>
> I wrote the following code to solve this challenge - 
> https://www.reddit.com/r/dailyprogrammer/comments/35s2ds/20150513_challenge_214_intermediate_pile_of_paper/
> .
>
> Code - 
> https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/56ce1dbb6a08e96150dc85934caecfeb68108a53/src/rdp/214_intermediate.clj
>
> I executed the -main function using `lein run 1`. 
>
> Output
>
> ;; lein run 1
>
> 0 12605919
> 1 3578145
> 2 15356894
> 3 19134293
> 4 2394558
> 5 15030409
> 6 6424953
> 7 14893444
> 8 1592254
> 9 1914025
> 10 7075106
> "Elapsed time: 501168.972435 msecs"
>
> The code originally used an immutable hashmap, but I lost patience waiting 
> for the computation to end. With mutable hashmap, it still takes around 8 
> mins.
>
> I wrote a C# version of the above code - 
> https://gist.github.com/amithgeorge/766b8220f39d48221e58. It finishes 
> under 40secs. The C# exe was built under Release mode and executed directly 
> from the commandline. I expected the Clojure version to perform similarly.
>
> Any tips on what I am doing wrong?
>
> -
> Explanation of the code - Create a vector of all paper sheets, such that 
> the sheet placed last is the first element of the vector and the last 
> element is the canvas. To compute the frequency of each visible color - for 
> each point in the canvas find the first sheet in the vector that covers the 
> point. Store/increment its count in the hashmap. I understand there might 
> be better more efficient ways to solve this, but currently I am interested 
> in why the Clojure versions is so slow vis-a-vis the C# 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.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: separation of concerns w/o encapsulation

[Colin Yates]

That assumes the intermediate functions are reusable. I guess with all
these things asthetics come into play, and there is of course the option of
letfn as well.
On 14 May 2015 18:40, "Sean Corfield"  wrote:

> On May 14, 2015, at 10:28 AM, Colin Yates  wrote:
> > I guess a related concern is abstraction. I notice I often have
> functions which work at different levels of abstraction in the same ns
> which makes me uncomfortable. In OO land they would be package level or
> even instance classes. I haven't yet found a way to solve this in clojure
> land.
> > To be explicit, I have a defn which calls a defn which calls a defn
> which calls , having all of those defns public doesn't capture the
> hierarchy of abstraction.
>
> …although it would allow other users of your code to build their own
> abstraction hierarchies. They can’t do that if you make things private
> "arbitrarily".
>
> If you really want to separate them and provide strong guidance that there
> is an intended hierarchy of abstractions, put them in different namespaces
> — named to indicate the layers in your hierarchy — and leave them all
> public.
>
> That creates a much more reusable, extensible code base. IMO (now — I
> didn’t think that way five years ago).
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
> --
> 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: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Alex Miller]

Gah. Meant in project.clj:

:jvm-opts ^:replace ["-server"]  ;; maybe also set max heap with  "-Xmx1g" 
in there


On Thursday, May 14, 2015 at 2:46:59 PM UTC-5, Alex Miller wrote:
>
> Oh also, the default Leiningen settings are optimized for reducing 
> startup, not for speed. Use:
>
>   ^:jvm-opts ^:replace ["-server"]  ;; maybe also set max heap 
> with  "-Xmx1g" in there
>
> Or just don't use lein when perf testing. 
>
> On Thursday, May 14, 2015 at 2:44:38 PM UTC-5, Alex Miller wrote:
>>
>> The major problem here is that you are using boxed math for everything 
>> instead of primitives.
>>
>> 0) Switch to Clojure 1.7.0-beta3 - it's faster and some things below are 
>> dependent on it for best performance. And use Java 1.8.
>> 1) Parse the lines you're reading directly into longs (Clojure focuses on 
>> 64-bit primitives - longs and doubles)
>> 2) Put the longs first into a data structure that preserves the primitive 
>> type. The two best options for that here are records (which can have 
>> primitive fields) and arrays. I would create a Canvas defrecord with ^long 
>> width and height and a Paper defrecord with all ^long fields for example. 
>> 3) Store the papers in a vector (using transient to create it)
>> 4) I suspect visible-color and covered? could probably be tightened up 
>> into a reduce over papers or a single loop-recur over papers - can't say I 
>> totally get what's happening there.
>> 5) In visible-color-frequencies, you could use "update" instead of get + 
>> transient assoc! on the acc map, but this is never going to be terribly 
>> fast. Another option here would be to create an array with the max color 
>> (you could track that while reading if it's not a well-known answer) and 
>> bash the array. That can retain int or long counters and will be *way* 
>> faster.
>> 6) You can use (set! *unchecked-math* :warn-on-boxed) to get faster math 
>> (no overflow checks) and also issue warnings (added in 1.7) if you happened 
>> to use boxed math by accident. 
>>
>>
>>
>> On Thursday, May 14, 2015 at 3:02:42 AM UTC-5, Amith George wrote:
>>>
>>> I wrote the following code to solve this challenge - 
>>> https://www.reddit.com/r/dailyprogrammer/comments/35s2ds/20150513_challenge_214_intermediate_pile_of_paper/
>>> .
>>>
>>> Code - 
>>> https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/56ce1dbb6a08e96150dc85934caecfeb68108a53/src/rdp/214_intermediate.clj
>>>
>>> I executed the -main function using `lein run 1`. 
>>>
>>> Output
>>>
>>> ;; lein run 1
>>>
>>> 0 12605919
>>> 1 3578145
>>> 2 15356894
>>> 3 19134293
>>> 4 2394558
>>> 5 15030409
>>> 6 6424953
>>> 7 14893444
>>> 8 1592254
>>> 9 1914025
>>> 10 7075106
>>> "Elapsed time: 501168.972435 msecs"
>>>
>>> The code originally used an immutable hashmap, but I lost patience 
>>> waiting for the computation to end. With mutable hashmap, it still takes 
>>> around 8 mins.
>>>
>>> I wrote a C# version of the above code - 
>>> https://gist.github.com/amithgeorge/766b8220f39d48221e58. It finishes 
>>> under 40secs. The C# exe was built under Release mode and executed directly 
>>> from the commandline. I expected the Clojure version to perform similarly.
>>>
>>> Any tips on what I am doing wrong?
>>>
>>> -
>>> Explanation of the code - Create a vector of all paper sheets, such that 
>>> the sheet placed last is the first element of the vector and the last 
>>> element is the canvas. To compute the frequency of each visible color - for 
>>> each point in the canvas find the first sheet in the vector that covers the 
>>> point. Store/increment its count in the hashmap. I understand there might 
>>> be better more efficient ways to solve this, but currently I am interested 
>>> in why the Clojure versions is so slow vis-a-vis the C# 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.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 the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Alex Miller]

Oh also, the default Leiningen settings are optimized for reducing startup, 
not for speed. Use:

  ^:jvm-opts ^:replace ["-server"]  ;; maybe also set max heap 
with  "-Xmx1g" in there

Or just don't use lein when perf testing. 

On Thursday, May 14, 2015 at 2:44:38 PM UTC-5, Alex Miller wrote:
>
> The major problem here is that you are using boxed math for everything 
> instead of primitives.
>
> 0) Switch to Clojure 1.7.0-beta3 - it's faster and some things below are 
> dependent on it for best performance. And use Java 1.8.
> 1) Parse the lines you're reading directly into longs (Clojure focuses on 
> 64-bit primitives - longs and doubles)
> 2) Put the longs first into a data structure that preserves the primitive 
> type. The two best options for that here are records (which can have 
> primitive fields) and arrays. I would create a Canvas defrecord with ^long 
> width and height and a Paper defrecord with all ^long fields for example. 
> 3) Store the papers in a vector (using transient to create it)
> 4) I suspect visible-color and covered? could probably be tightened up 
> into a reduce over papers or a single loop-recur over papers - can't say I 
> totally get what's happening there.
> 5) In visible-color-frequencies, you could use "update" instead of get + 
> transient assoc! on the acc map, but this is never going to be terribly 
> fast. Another option here would be to create an array with the max color 
> (you could track that while reading if it's not a well-known answer) and 
> bash the array. That can retain int or long counters and will be *way* 
> faster.
> 6) You can use (set! *unchecked-math* :warn-on-boxed) to get faster math 
> (no overflow checks) and also issue warnings (added in 1.7) if you happened 
> to use boxed math by accident. 
>
>
>
> On Thursday, May 14, 2015 at 3:02:42 AM UTC-5, Amith George wrote:
>>
>> I wrote the following code to solve this challenge - 
>> https://www.reddit.com/r/dailyprogrammer/comments/35s2ds/20150513_challenge_214_intermediate_pile_of_paper/
>> .
>>
>> Code - 
>> https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/56ce1dbb6a08e96150dc85934caecfeb68108a53/src/rdp/214_intermediate.clj
>>
>> I executed the -main function using `lein run 1`. 
>>
>> Output
>>
>> ;; lein run 1
>>
>> 0 12605919
>> 1 3578145
>> 2 15356894
>> 3 19134293
>> 4 2394558
>> 5 15030409
>> 6 6424953
>> 7 14893444
>> 8 1592254
>> 9 1914025
>> 10 7075106
>> "Elapsed time: 501168.972435 msecs"
>>
>> The code originally used an immutable hashmap, but I lost patience 
>> waiting for the computation to end. With mutable hashmap, it still takes 
>> around 8 mins.
>>
>> I wrote a C# version of the above code - 
>> https://gist.github.com/amithgeorge/766b8220f39d48221e58. It finishes 
>> under 40secs. The C# exe was built under Release mode and executed directly 
>> from the commandline. I expected the Clojure version to perform similarly.
>>
>> Any tips on what I am doing wrong?
>>
>> -
>> Explanation of the code - Create a vector of all paper sheets, such that 
>> the sheet placed last is the first element of the vector and the last 
>> element is the canvas. To compute the frequency of each visible color - for 
>> each point in the canvas find the first sheet in the vector that covers the 
>> point. Store/increment its count in the hashmap. I understand there might 
>> be better more efficient ways to solve this, but currently I am interested 
>> in why the Clojure versions is so slow vis-a-vis the C# 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.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: separation of concerns w/o encapsulation

[Sean Corfield]

On May 14, 2015, at 12:37 PM, Erik Price  wrote:
> The code itself is mutable. The nice thing about a private function is that I 
> have reserved the right to change how it works someday, without fear that 
> others have become dependent on the way it currently works.

That’s why I suggested foo.api and foo.impl namespaces and requiring 
(convention, peer review) that nothing outside of foo.api uses the foo.impl 
namespace — any exceptions would need to be specifically discussed and 
sanctioned.

And remember there’s a difference between building a library for "the public" 
to use and building software for internal use by your own team or other peer 
teams in your division.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



-- 
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 the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[David Nolen]

Also using `lein run` without supplying correct JVM settings (like -server)
is going to lead to pretty misleading results.

On Thu, May 14, 2015 at 3:44 PM, Alex Miller  wrote:

> The major problem here is that you are using boxed math for everything
> instead of primitives.
>
> 0) Switch to Clojure 1.7.0-beta3 - it's faster and some things below are
> dependent on it for best performance. And use Java 1.8.
> 1) Parse the lines you're reading directly into longs (Clojure focuses on
> 64-bit primitives - longs and doubles)
> 2) Put the longs first into a data structure that preserves the primitive
> type. The two best options for that here are records (which can have
> primitive fields) and arrays. I would create a Canvas defrecord with ^long
> width and height and a Paper defrecord with all ^long fields for example.
> 3) Store the papers in a vector (using transient to create it)
> 4) I suspect visible-color and covered? could probably be tightened up
> into a reduce over papers or a single loop-recur over papers - can't say I
> totally get what's happening there.
> 5) In visible-color-frequencies, you could use "update" instead of get +
> transient assoc! on the acc map, but this is never going to be terribly
> fast. Another option here would be to create an array with the max color
> (you could track that while reading if it's not a well-known answer) and
> bash the array. That can retain int or long counters and will be *way*
> faster.
> 6) You can use (set! *unchecked-math* :warn-on-boxed) to get faster math
> (no overflow checks) and also issue warnings (added in 1.7) if you happened
> to use boxed math by accident.
>
>
>
> On Thursday, May 14, 2015 at 3:02:42 AM UTC-5, Amith George wrote:
>>
>> I wrote the following code to solve this challenge -
>> https://www.reddit.com/r/dailyprogrammer/comments/35s2ds/20150513_challenge_214_intermediate_pile_of_paper/
>> .
>>
>> Code -
>> https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/56ce1dbb6a08e96150dc85934caecfeb68108a53/src/rdp/214_intermediate.clj
>>
>> I executed the -main function using `lein run 1`.
>>
>> Output
>>
>> ;; lein run 1
>>
>> 0 12605919
>> 1 3578145
>> 2 15356894
>> 3 19134293
>> 4 2394558
>> 5 15030409
>> 6 6424953
>> 7 14893444
>> 8 1592254
>> 9 1914025
>> 10 7075106
>> "Elapsed time: 501168.972435 msecs"
>>
>> The code originally used an immutable hashmap, but I lost patience
>> waiting for the computation to end. With mutable hashmap, it still takes
>> around 8 mins.
>>
>> I wrote a C# version of the above code -
>> https://gist.github.com/amithgeorge/766b8220f39d48221e58. It finishes
>> under 40secs. The C# exe was built under Release mode and executed directly
>> from the commandline. I expected the Clojure version to perform similarly.
>>
>> Any tips on what I am doing wrong?
>>
>> -
>> Explanation of the code - Create a vector of all paper sheets, such that
>> the sheet placed last is the first element of the vector and the last
>> element is the canvas. To compute the frequency of each visible color - for
>> each point in the canvas find the first sheet in the vector that covers the
>> point. Store/increment its count in the hashmap. I understand there might
>> be better more efficient ways to solve this, but currently I am interested
>> in why the Clojure versions is so slow vis-a-vis the C# 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.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: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Lee Spector]

I'd like to get more guidance on how to specify :jvm-opts for maximum 
performance. I've received some help on this topic from people on this list in 
the past (thanks!), but I'm pretty sure that I'm still not doing things right.

I'm almost always interested in maximum performance for long-running, 
compute-intensive and memory-intensive processes, almost never caring much at 
all about startup time or anything else.

I also run my code on different machines, with different numbers of cores and 
amounts of memory, and would prefer to be able to put something in my 
project.clj that will do something reasonable regardless of what machine it's 
running on.

I run my code with "lein run", and I'd like whatever I need to "run fast" to be 
in project.clj.

I don't know a lot about JVM options, and I've tried to figure out what to 
specify for :jvm-opts by asking questions here and web searches, but I'm not at 
all confident that I'm doing it right yet. And because my systems are also 
stochastic, it's not easy for me to do timing tests on the options I've tried. 

I think there are options relevant to memory and also garbage collection and 
maybe also compilation... and what else? I wish there was a simple switch to 
get maximum performance of the sort I've outlined here (or at least a 
reasonable stab at it), but I gather that there isn't.

Anyway, here's what I've been using recently, which just deals with memory and 
GC (and maybe not in the best way):

  :jvm-opts ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
 
(java.lang.management.ManagementFactory/getOperatingSystemMXBean))
   0.8))]
   [(str "-Xmx" mem-to-use)
(str "-Xms" mem-to-use)
"-XX:+UseG1GC"])

After seeing Alex's post I thought that maybe I should add "-server", as 
follows:

  :jvm-opts ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
 
(java.lang.management.ManagementFactory/getOperatingSystemMXBean))
   0.8))]
   [(str "-Xmx" mem-to-use)
(str "-Xms" mem-to-use)
"-XX:+UseG1GC"
"-server"])

Is that right? Does it make sense? What does "-server" do? Also, should I also 
be using "^:replace"?

I've looked in 
https://github.com/technomancy/leiningen/blob/master/sample.project.clj in 
hopes that this would say more about this stuff, but it doesn't say anything 
about -server or ^:replace.

Looking into the compilation options, it looks from 
https://github.com/technomancy/leiningen/wiki/Faster that I should be 
specifying:

:jvm-opts ^:replace []

This is also familiar to me from some earlier discussions. But how would I 
combine this with the memory/GC/server(?) options above?

A guess would be that maybe I should do this:

  :jvm-opts ^:replace
  ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
 
(java.lang.management.ManagementFactory/getOperatingSystemMXBean))
   0.8))]
   [(str "-Xmx" mem-to-use)
(str "-Xms" mem-to-use)
"-XX:+UseG1GC"
"-server"
"-XX:-TieredCompilation"])

Note that this guess involves changing a + to a - in the last line, which was 
suggested for the opposite purpose at 
https://github.com/technomancy/leiningen/wiki/Faster -- but I don't know if 
it's legitimate.

Is this a reasonable thing to do to get maximum performance for long-running, 
compute-intensive and memory-intensive processes?

Is the tiered compilation thing maybe already done by including "-server"?

I'm probably at least somewhat confused about several different issues here...

Any help or pointers would be appreciated.

Thanks,

 -Lee




> On May 14, 2015, at 3:47 PM, Alex Miller  wrote:
> 
> Gah. Meant in project.clj:
> 
> :jvm-opts ^:replace ["-server"]  ;; maybe also set max heap with  "-Xmx1g" in 
> there
> 

-- 
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 the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Colin Yates]

Probably not helpful, but I tend to rely on the jvm optimisations and just
-server. I figured this is an area where a little knowledge is a dangerous
thing.

At the very least I would have a realistic benchmark suite to prove to
myself that these gains were worth it. In my experience the performance
bottleneck is always in design.

Just my 2p, although with my self-confessed ignoramus status it is more
like 0.5p :).
On 14 May 2015 21:46, "Lee Spector"  wrote:

> I'd like to get more guidance on how to specify :jvm-opts for maximum
> performance. I've received some help on this topic from people on this list
> in the past (thanks!), but I'm pretty sure that I'm still not doing things
> right.
>
> I'm almost always interested in maximum performance for long-running,
> compute-intensive and memory-intensive processes, almost never caring much
> at all about startup time or anything else.
>
> I also run my code on different machines, with different numbers of cores
> and amounts of memory, and would prefer to be able to put something in my
> project.clj that will do something reasonable regardless of what machine
> it's running on.
>
> I run my code with "lein run", and I'd like whatever I need to "run fast"
> to be in project.clj.
>
> I don't know a lot about JVM options, and I've tried to figure out what to
> specify for :jvm-opts by asking questions here and web searches, but I'm
> not at all confident that I'm doing it right yet. And because my systems
> are also stochastic, it's not easy for me to do timing tests on the options
> I've tried.
>
> I think there are options relevant to memory and also garbage collection
> and maybe also compilation... and what else? I wish there was a simple
> switch to get maximum performance of the sort I've outlined here (or at
> least a reasonable stab at it), but I gather that there isn't.
>
> Anyway, here's what I've been using recently, which just deals with memory
> and GC (and maybe not in the best way):
>
>   :jvm-opts ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
>
>  (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
>0.8))]
>[(str "-Xmx" mem-to-use)
> (str "-Xms" mem-to-use)
> "-XX:+UseG1GC"])
>
> After seeing Alex's post I thought that maybe I should add "-server", as
> follows:
>
>   :jvm-opts ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
>
>  (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
>0.8))]
>[(str "-Xmx" mem-to-use)
> (str "-Xms" mem-to-use)
> "-XX:+UseG1GC"
> "-server"])
>
> Is that right? Does it make sense? What does "-server" do? Also, should I
> also be using "^:replace"?
>
> I've looked in
> https://github.com/technomancy/leiningen/blob/master/sample.project.clj
> in hopes that this would say more about this stuff, but it doesn't say
> anything about -server or ^:replace.
>
> Looking into the compilation options, it looks from
> https://github.com/technomancy/leiningen/wiki/Faster that I should be
> specifying:
>
> :jvm-opts ^:replace []
>
> This is also familiar to me from some earlier discussions. But how would I
> combine this with the memory/GC/server(?) options above?
>
> A guess would be that maybe I should do this:
>
>   :jvm-opts ^:replace
>   ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
>
>  (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
>0.8))]
>[(str "-Xmx" mem-to-use)
> (str "-Xms" mem-to-use)
> "-XX:+UseG1GC"
> "-server"
> "-XX:-TieredCompilation"])
>
> Note that this guess involves changing a + to a - in the last line, which
> was suggested for the opposite purpose at
> https://github.com/technomancy/leiningen/wiki/Faster -- but I don't know
> if it's legitimate.
>
> Is this a reasonable thing to do to get maximum performance for
> long-running, compute-intensive and memory-intensive processes?
>
> Is the tiered compilation thing maybe already done by including "-server"?
>
> I'm probably at least somewhat confused about several different issues
> here...
>
> Any help or pointers would be appreciated.
>
> Thanks,
>
>  -Lee
>
>
>
>
> > On May 14, 2015, at 3:47 PM, Alex Miller  wrote:
> >
> > Gah. Meant in project.clj:
> >
> > :jvm-opts ^:replace ["-server"]  ;; maybe also set max heap with
> "-Xmx1g" in there
> >
>
> --
> 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

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Mark Engelberg]

I know that remembering to put "-server" used to be a huge issue, but I
thought that on all recent versions of Java on all modern 64-bit machines,
-server is now the default.  I thought it was a non-issue at this point.
Is that incorrect?

On Thu, May 14, 2015 at 1:54 PM, Colin Yates  wrote:

> Probably not helpful, but I tend to rely on the jvm optimisations and just
> -server. I figured this is an area where a little knowledge is a dangerous
> thing.
>
> At the very least I would have a realistic benchmark suite to prove to
> myself that these gains were worth it. In my experience the performance
> bottleneck is always in design.
>
> Just my 2p, although with my self-confessed ignoramus status it is more
> like 0.5p :).
> On 14 May 2015 21:46, "Lee Spector"  wrote:
>
>> I'd like to get more guidance on how to specify :jvm-opts for maximum
>> performance. I've received some help on this topic from people on this list
>> in the past (thanks!), but I'm pretty sure that I'm still not doing things
>> right.
>>
>> I'm almost always interested in maximum performance for long-running,
>> compute-intensive and memory-intensive processes, almost never caring much
>> at all about startup time or anything else.
>>
>> I also run my code on different machines, with different numbers of cores
>> and amounts of memory, and would prefer to be able to put something in my
>> project.clj that will do something reasonable regardless of what machine
>> it's running on.
>>
>> I run my code with "lein run", and I'd like whatever I need to "run fast"
>> to be in project.clj.
>>
>> I don't know a lot about JVM options, and I've tried to figure out what
>> to specify for :jvm-opts by asking questions here and web searches, but I'm
>> not at all confident that I'm doing it right yet. And because my systems
>> are also stochastic, it's not easy for me to do timing tests on the options
>> I've tried.
>>
>> I think there are options relevant to memory and also garbage collection
>> and maybe also compilation... and what else? I wish there was a simple
>> switch to get maximum performance of the sort I've outlined here (or at
>> least a reasonable stab at it), but I gather that there isn't.
>>
>> Anyway, here's what I've been using recently, which just deals with
>> memory and GC (and maybe not in the best way):
>>
>>   :jvm-opts ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
>>
>>  (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
>>0.8))]
>>[(str "-Xmx" mem-to-use)
>> (str "-Xms" mem-to-use)
>> "-XX:+UseG1GC"])
>>
>> After seeing Alex's post I thought that maybe I should add "-server", as
>> follows:
>>
>>   :jvm-opts ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
>>
>>  (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
>>0.8))]
>>[(str "-Xmx" mem-to-use)
>> (str "-Xms" mem-to-use)
>> "-XX:+UseG1GC"
>> "-server"])
>>
>> Is that right? Does it make sense? What does "-server" do? Also, should I
>> also be using "^:replace"?
>>
>> I've looked in
>> https://github.com/technomancy/leiningen/blob/master/sample.project.clj
>> in hopes that this would say more about this stuff, but it doesn't say
>> anything about -server or ^:replace.
>>
>> Looking into the compilation options, it looks from
>> https://github.com/technomancy/leiningen/wiki/Faster that I should be
>> specifying:
>>
>> :jvm-opts ^:replace []
>>
>> This is also familiar to me from some earlier discussions. But how would
>> I combine this with the memory/GC/server(?) options above?
>>
>> A guess would be that maybe I should do this:
>>
>>   :jvm-opts ^:replace
>>   ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
>>
>>  (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
>>0.8))]
>>[(str "-Xmx" mem-to-use)
>> (str "-Xms" mem-to-use)
>> "-XX:+UseG1GC"
>> "-server"
>> "-XX:-TieredCompilation"])
>>
>> Note that this guess involves changing a + to a - in the last line, which
>> was suggested for the opposite purpose at
>> https://github.com/technomancy/leiningen/wiki/Faster -- but I don't know
>> if it's legitimate.
>>
>> Is this a reasonable thing to do to get maximum performance for
>> long-running, compute-intensive and memory-intensive processes?
>>
>> Is the tiered compilation thing maybe already done by including "-server"?
>>
>> I'm probably at least somewhat confused about several different issues
>> here...
>>
>> Any help or pointers would be appreciated.
>>
>> Thanks,
>>
>>  -Lee
>>
>>
>>
>>
>> > On May 14, 2015, at 3:47 PM, Alex Miller  wrote:
>> >
>> > Gah. Meant in project.clj:
>> >
>> > :jvm-opts ^:replace ["-server"]  ;; maybe also set max heap with
>> "-Xmx1g" in there
>> >
>

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Colin Yates]

Now I feel even more of an ignoramus :)
On 14 May 2015 21:57, "Mark Engelberg"  wrote:

> I know that remembering to put "-server" used to be a huge issue, but I
> thought that on all recent versions of Java on all modern 64-bit machines,
> -server is now the default.  I thought it was a non-issue at this point.
> Is that incorrect?
>
> On Thu, May 14, 2015 at 1:54 PM, Colin Yates 
> wrote:
>
>> Probably not helpful, but I tend to rely on the jvm optimisations and
>> just -server. I figured this is an area where a little knowledge is a
>> dangerous thing.
>>
>> At the very least I would have a realistic benchmark suite to prove to
>> myself that these gains were worth it. In my experience the performance
>> bottleneck is always in design.
>>
>> Just my 2p, although with my self-confessed ignoramus status it is more
>> like 0.5p :).
>> On 14 May 2015 21:46, "Lee Spector"  wrote:
>>
>>> I'd like to get more guidance on how to specify :jvm-opts for maximum
>>> performance. I've received some help on this topic from people on this list
>>> in the past (thanks!), but I'm pretty sure that I'm still not doing things
>>> right.
>>>
>>> I'm almost always interested in maximum performance for long-running,
>>> compute-intensive and memory-intensive processes, almost never caring much
>>> at all about startup time or anything else.
>>>
>>> I also run my code on different machines, with different numbers of
>>> cores and amounts of memory, and would prefer to be able to put something
>>> in my project.clj that will do something reasonable regardless of what
>>> machine it's running on.
>>>
>>> I run my code with "lein run", and I'd like whatever I need to "run
>>> fast" to be in project.clj.
>>>
>>> I don't know a lot about JVM options, and I've tried to figure out what
>>> to specify for :jvm-opts by asking questions here and web searches, but I'm
>>> not at all confident that I'm doing it right yet. And because my systems
>>> are also stochastic, it's not easy for me to do timing tests on the options
>>> I've tried.
>>>
>>> I think there are options relevant to memory and also garbage collection
>>> and maybe also compilation... and what else? I wish there was a simple
>>> switch to get maximum performance of the sort I've outlined here (or at
>>> least a reasonable stab at it), but I gather that there isn't.
>>>
>>> Anyway, here's what I've been using recently, which just deals with
>>> memory and GC (and maybe not in the best way):
>>>
>>>   :jvm-opts ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
>>>
>>>  (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
>>>0.8))]
>>>[(str "-Xmx" mem-to-use)
>>> (str "-Xms" mem-to-use)
>>> "-XX:+UseG1GC"])
>>>
>>> After seeing Alex's post I thought that maybe I should add "-server", as
>>> follows:
>>>
>>>   :jvm-opts ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
>>>
>>>  (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
>>>0.8))]
>>>[(str "-Xmx" mem-to-use)
>>> (str "-Xms" mem-to-use)
>>> "-XX:+UseG1GC"
>>> "-server"])
>>>
>>> Is that right? Does it make sense? What does "-server" do? Also, should
>>> I also be using "^:replace"?
>>>
>>> I've looked in
>>> https://github.com/technomancy/leiningen/blob/master/sample.project.clj
>>> in hopes that this would say more about this stuff, but it doesn't say
>>> anything about -server or ^:replace.
>>>
>>> Looking into the compilation options, it looks from
>>> https://github.com/technomancy/leiningen/wiki/Faster that I should be
>>> specifying:
>>>
>>> :jvm-opts ^:replace []
>>>
>>> This is also familiar to me from some earlier discussions. But how would
>>> I combine this with the memory/GC/server(?) options above?
>>>
>>> A guess would be that maybe I should do this:
>>>
>>>   :jvm-opts ^:replace
>>>   ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
>>>
>>>  (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
>>>0.8))]
>>>[(str "-Xmx" mem-to-use)
>>> (str "-Xms" mem-to-use)
>>> "-XX:+UseG1GC"
>>> "-server"
>>> "-XX:-TieredCompilation"])
>>>
>>> Note that this guess involves changing a + to a - in the last line,
>>> which was suggested for the opposite purpose at
>>> https://github.com/technomancy/leiningen/wiki/Faster -- but I don't
>>> know if it's legitimate.
>>>
>>> Is this a reasonable thing to do to get maximum performance for
>>> long-running, compute-intensive and memory-intensive processes?
>>>
>>> Is the tiered compilation thing maybe already done by including
>>> "-server"?
>>>
>>> I'm probably at least somewhat confused about several different issues
>>> here...
>>>
>>> Any help or pointers would be appreciated.
>>>
>>> Thanks,
>>

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Lee Spector]

FWIW if I run with no :jvm-opts at all then I often crash with an out-of-memory 
error, so I do know that whatever happens by default doesn't do what I'm doing 
with respect to memory, at least.

I don't know what happens with respect to the other issues (tiered compilation 
and whatever else) by default, or with -server, etc.

 -Lee


> On May 14, 2015, at 4:59 PM, Colin Yates  wrote:
> 
> Now I feel even more of an ignoramus :)
> 
> On 14 May 2015 21:57, "Mark Engelberg"  > wrote:
> I know that remembering to put "-server" used to be a huge issue, but I 
> thought that on all recent versions of Java on all modern 64-bit machines, 
> -server is now the default.  I thought it was a non-issue at this point.  Is 
> that incorrect?
> 
> On Thu, May 14, 2015 at 1:54 PM, Colin Yates  > wrote:
> Probably not helpful, but I tend to rely on the jvm optimisations and just 
> -server. I figured this is an area where a little knowledge is a dangerous 
> thing.
> 
> At the very least I would have a realistic benchmark suite to prove to myself 
> that these gains were worth it. In my experience the performance bottleneck 
> is always in design.
> 
> Just my 2p, although with my self-confessed ignoramus status it is more like 
> 0.5p :).
> 
> On 14 May 2015 21:46, "Lee Spector"  > wrote:
> I'd like to get more guidance on how to specify :jvm-opts for maximum 
> performance. I've received some help on this topic from people on this list 
> in the past (thanks!), but I'm pretty sure that I'm still not doing things 
> right.
> 
> I'm almost always interested in maximum performance for long-running, 
> compute-intensive and memory-intensive processes, almost never caring much at 
> all about startup time or anything else.
> 
> I also run my code on different machines, with different numbers of cores and 
> amounts of memory, and would prefer to be able to put something in my 
> project.clj that will do something reasonable regardless of what machine it's 
> running on.
> 
> I run my code with "lein run", and I'd like whatever I need to "run fast" to 
> be in project.clj.
> 
> I don't know a lot about JVM options, and I've tried to figure out what to 
> specify for :jvm-opts by asking questions here and web searches, but I'm not 
> at all confident that I'm doing it right yet. And because my systems are also 
> stochastic, it's not easy for me to do timing tests on the options I've tried.
> 
> I think there are options relevant to memory and also garbage collection and 
> maybe also compilation... and what else? I wish there was a simple switch to 
> get maximum performance of the sort I've outlined here (or at least a 
> reasonable stab at it), but I gather that there isn't.
> 
> Anyway, here's what I've been using recently, which just deals with memory 
> and GC (and maybe not in the best way):
> 
>   :jvm-opts ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
>  
> (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
>0.8))]
>[(str "-Xmx" mem-to-use)
> (str "-Xms" mem-to-use)
> "-XX:+UseG1GC"])
> 
> After seeing Alex's post I thought that maybe I should add "-server", as 
> follows:
> 
>   :jvm-opts ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
>  
> (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
>0.8))]
>[(str "-Xmx" mem-to-use)
> (str "-Xms" mem-to-use)
> "-XX:+UseG1GC"
> "-server"])
> 
> Is that right? Does it make sense? What does "-server" do? Also, should I 
> also be using "^:replace"?
> 
> I've looked in 
> https://github.com/technomancy/leiningen/blob/master/sample.project.clj 
>  in 
> hopes that this would say more about this stuff, but it doesn't say anything 
> about -server or ^:replace.
> 
> Looking into the compilation options, it looks from 
> https://github.com/technomancy/leiningen/wiki/Faster 
>  that I should be 
> specifying:
> 
> :jvm-opts ^:replace []
> 
> This is also familiar to me from some earlier discussions. But how would I 
> combine this with the memory/GC/server(?) options above?
> 
> A guess would be that maybe I should do this:
> 
>   :jvm-opts ^:replace
>   ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
>  
> (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
>0.8))]
>[(str "-Xmx" mem-to-use)
> (str "-Xms" mem-to-use)
> "-XX:+UseG1GC"
> "-server"
> "-XX:-Tiered

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Mark Engelberg]

I always run my REPL inside of Counterclockwise, but as far as I know it
uses leiningen to launch the REPL.  In any case, when I attach a profiler
such as the built-in jvisualvm to the REPL process, it clearly says that
the REPL is running in 64-bit server mode.

On Thu, May 14, 2015 at 2:29 PM, Lee Spector  wrote:

> FWIW if I run with no :jvm-opts at all then I often crash with an
> out-of-memory error, so I do know that whatever happens by default doesn't
> do what I'm doing with respect to memory, at least.
>
> I don't know what happens with respect to the other issues (tiered
> compilation and whatever else) by default, or with -server, etc.
>
>  -Lee
>
>
> On May 14, 2015, at 4:59 PM, Colin Yates  wrote:
>
> Now I feel even more of an ignoramus :)
> On 14 May 2015 21:57, "Mark Engelberg"  wrote:
>
>> I know that remembering to put "-server" used to be a huge issue, but I
>> thought that on all recent versions of Java on all modern 64-bit machines,
>> -server is now the default.  I thought it was a non-issue at this point.
>> Is that incorrect?
>>
>> On Thu, May 14, 2015 at 1:54 PM, Colin Yates 
>> wrote:
>>
>>> Probably not helpful, but I tend to rely on the jvm optimisations and
>>> just -server. I figured this is an area where a little knowledge is a
>>> dangerous thing.
>>>
>>> At the very least I would have a realistic benchmark suite to prove to
>>> myself that these gains were worth it. In my experience the performance
>>> bottleneck is always in design.
>>>
>>> Just my 2p, although with my self-confessed ignoramus status it is more
>>> like 0.5p :).
>>> On 14 May 2015 21:46, "Lee Spector"  wrote:
>>>
 I'd like to get more guidance on how to specify :jvm-opts for maximum
 performance. I've received some help on this topic from people on this list
 in the past (thanks!), but I'm pretty sure that I'm still not doing things
 right.

 I'm almost always interested in maximum performance for long-running,
 compute-intensive and memory-intensive processes, almost never caring much
 at all about startup time or anything else.

 I also run my code on different machines, with different numbers of
 cores and amounts of memory, and would prefer to be able to put something
 in my project.clj that will do something reasonable regardless of what
 machine it's running on.

 I run my code with "lein run", and I'd like whatever I need to "run
 fast" to be in project.clj.

 I don't know a lot about JVM options, and I've tried to figure out what
 to specify for :jvm-opts by asking questions here and web searches, but I'm
 not at all confident that I'm doing it right yet. And because my systems
 are also stochastic, it's not easy for me to do timing tests on the options
 I've tried.

 I think there are options relevant to memory and also garbage
 collection and maybe also compilation... and what else? I wish there was a
 simple switch to get maximum performance of the sort I've outlined here (or
 at least a reasonable stab at it), but I gather that there isn't.

 Anyway, here's what I've been using recently, which just deals with
 memory and GC (and maybe not in the best way):

   :jvm-opts ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize

  (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
0.8))]
[(str "-Xmx" mem-to-use)
 (str "-Xms" mem-to-use)
 "-XX:+UseG1GC"])

 After seeing Alex's post I thought that maybe I should add "-server",
 as follows:

   :jvm-opts ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize

  (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
0.8))]
[(str "-Xmx" mem-to-use)
 (str "-Xms" mem-to-use)
 "-XX:+UseG1GC"
 "-server"])

 Is that right? Does it make sense? What does "-server" do? Also, should
 I also be using "^:replace"?

 I've looked in
 https://github.com/technomancy/leiningen/blob/master/sample.project.clj
 in hopes that this would say more about this stuff, but it doesn't say
 anything about -server or ^:replace.

 Looking into the compilation options, it looks from
 https://github.com/technomancy/leiningen/wiki/Faster that I should be
 specifying:

 :jvm-opts ^:replace []

 This is also familiar to me from some earlier discussions. But how
 would I combine this with the memory/GC/server(?) options above?

 A guess would be that maybe I should do this:

   :jvm-opts ^:replace
   ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize

  (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
0

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Alex Miller]

By default, I believe that lein will set:  -XX:+TieredCompilation 
-XX:TieredStopAtLevel=1 for the JVM opts.

If you supply :jvm-opts, they will be *added* to these. Using ^:replace 
will instead *replace* the defaults with what you supply. There are a bunch 
of rules in the JVM for whether -server is used by default but they have 
are different across versions so I just use -server so I don't have to 
wonder. I often also set a max memory with -Xmx512m so that's known too.

Using -XX:+AggressiveOpts will enable optimizations that are available but 
not the default (yet) in your current JDK. Sometimes that's helpful but 
what that actually does will depend on your version.

That's a good place to start. There are lots of other things that *might* 
help (like GC settings), but you should probably understand what it all 
means before applying it, esp GC settings.



On Thursday, May 14, 2015 at 4:29:50 PM UTC-5, Lee wrote:
>
> FWIW if I run with no :jvm-opts at all then I often crash with an 
> out-of-memory error, so I do know that whatever happens by default doesn't 
> do what I'm doing with respect to memory, at least.
>
> I don't know what happens with respect to the other issues (tiered 
> compilation and whatever else) by default, or with -server, etc.
>
>  -Lee
>
>
> On May 14, 2015, at 4:59 PM, Colin Yates > 
> wrote:
>
> Now I feel even more of an ignoramus :)
> On 14 May 2015 21:57, "Mark Engelberg" > 
> wrote:
>
>> I know that remembering to put "-server" used to be a huge issue, but I 
>> thought that on all recent versions of Java on all modern 64-bit machines, 
>> -server is now the default.  I thought it was a non-issue at this point.  
>> Is that incorrect?
>>
>> On Thu, May 14, 2015 at 1:54 PM, Colin Yates > > wrote:
>>
>>> Probably not helpful, but I tend to rely on the jvm optimisations and 
>>> just -server. I figured this is an area where a little knowledge is a 
>>> dangerous thing.
>>>
>>> At the very least I would have a realistic benchmark suite to prove to 
>>> myself that these gains were worth it. In my experience the performance 
>>> bottleneck is always in design.
>>>
>>> Just my 2p, although with my self-confessed ignoramus status it is more 
>>> like 0.5p :).
>>> On 14 May 2015 21:46, "Lee Spector" > 
>>> wrote:
>>>
 I'd like to get more guidance on how to specify :jvm-opts for maximum 
 performance. I've received some help on this topic from people on this 
 list 
 in the past (thanks!), but I'm pretty sure that I'm still not doing things 
 right.

 I'm almost always interested in maximum performance for long-running, 
 compute-intensive and memory-intensive processes, almost never caring much 
 at all about startup time or anything else.

 I also run my code on different machines, with different numbers of 
 cores and amounts of memory, and would prefer to be able to put something 
 in my project.clj that will do something reasonable regardless of what 
 machine it's running on.

 I run my code with "lein run", and I'd like whatever I need to "run 
 fast" to be in project.clj.

 I don't know a lot about JVM options, and I've tried to figure out what 
 to specify for :jvm-opts by asking questions here and web searches, but 
 I'm 
 not at all confident that I'm doing it right yet. And because my systems 
 are also stochastic, it's not easy for me to do timing tests on the 
 options 
 I've tried.

 I think there are options relevant to memory and also garbage 
 collection and maybe also compilation... and what else? I wish there was a 
 simple switch to get maximum performance of the sort I've outlined here 
 (or 
 at least a reasonable stab at it), but I gather that there isn't.

 Anyway, here's what I've been using recently, which just deals with 
 memory and GC (and maybe not in the best way):

   :jvm-opts ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
 
  (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
0.8))]
[(str "-Xmx" mem-to-use)
 (str "-Xms" mem-to-use)
 "-XX:+UseG1GC"])

 After seeing Alex's post I thought that maybe I should add "-server", 
 as follows:

   :jvm-opts ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
 
  (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
0.8))]
[(str "-Xmx" mem-to-use)
 (str "-Xms" mem-to-use)
 "-XX:+UseG1GC"
 "-server"])

 Is that right? Does it make sense? What does "-server" do? Also, should 
 I also be using "^:replace"?

 I've looked in 
 https://github.com/technomancy/leininge

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Andy Fingerhut]

In general, running any kind of JVM via Leiningen, using the 'ps' command
with lots of '' on the end of the command line options should give full
command line options used to start the JVM, so you can see what is
happening.

Understanding exactly which options are good or bad for performance, I
don't have anything to add to the message I am replying to.

Andy

On Thu, May 14, 2015 at 2:42 PM, Alex Miller  wrote:

> By default, I believe that lein will set:  -XX:+TieredCompilation
> -XX:TieredStopAtLevel=1 for the JVM opts.
>
> If you supply :jvm-opts, they will be *added* to these. Using ^:replace
> will instead *replace* the defaults with what you supply. There are a bunch
> of rules in the JVM for whether -server is used by default but they have
> are different across versions so I just use -server so I don't have to
> wonder. I often also set a max memory with -Xmx512m so that's known too.
>
> Using -XX:+AggressiveOpts will enable optimizations that are available but
> not the default (yet) in your current JDK. Sometimes that's helpful but
> what that actually does will depend on your version.
>
> That's a good place to start. There are lots of other things that *might*
> help (like GC settings), but you should probably understand what it all
> means before applying it, esp GC settings.
>
>
>
> On Thursday, May 14, 2015 at 4:29:50 PM UTC-5, Lee wrote:
>>
>> FWIW if I run with no :jvm-opts at all then I often crash with an
>> out-of-memory error, so I do know that whatever happens by default doesn't
>> do what I'm doing with respect to memory, at least.
>>
>> I don't know what happens with respect to the other issues (tiered
>> compilation and whatever else) by default, or with -server, etc.
>>
>>  -Lee
>>
>>
>> On May 14, 2015, at 4:59 PM, Colin Yates  wrote:
>>
>> Now I feel even more of an ignoramus :)
>> On 14 May 2015 21:57, "Mark Engelberg"  wrote:
>>
>>> I know that remembering to put "-server" used to be a huge issue, but I
>>> thought that on all recent versions of Java on all modern 64-bit machines,
>>> -server is now the default.  I thought it was a non-issue at this point.
>>> Is that incorrect?
>>>
>>> On Thu, May 14, 2015 at 1:54 PM, Colin Yates  wrote:
>>>
 Probably not helpful, but I tend to rely on the jvm optimisations and
 just -server. I figured this is an area where a little knowledge is a
 dangerous thing.

 At the very least I would have a realistic benchmark suite to prove to
 myself that these gains were worth it. In my experience the performance
 bottleneck is always in design.

 Just my 2p, although with my self-confessed ignoramus status it is more
 like 0.5p :).
 On 14 May 2015 21:46, "Lee Spector"  wrote:

> I'd like to get more guidance on how to specify :jvm-opts for maximum
> performance. I've received some help on this topic from people on this 
> list
> in the past (thanks!), but I'm pretty sure that I'm still not doing things
> right.
>
> I'm almost always interested in maximum performance for long-running,
> compute-intensive and memory-intensive processes, almost never caring much
> at all about startup time or anything else.
>
> I also run my code on different machines, with different numbers of
> cores and amounts of memory, and would prefer to be able to put something
> in my project.clj that will do something reasonable regardless of what
> machine it's running on.
>
> I run my code with "lein run", and I'd like whatever I need to "run
> fast" to be in project.clj.
>
> I don't know a lot about JVM options, and I've tried to figure out
> what to specify for :jvm-opts by asking questions here and web searches,
> but I'm not at all confident that I'm doing it right yet. And because my
> systems are also stochastic, it's not easy for me to do timing tests on 
> the
> options I've tried.
>
> I think there are options relevant to memory and also garbage
> collection and maybe also compilation... and what else? I wish there was a
> simple switch to get maximum performance of the sort I've outlined here 
> (or
> at least a reasonable stab at it), but I gather that there isn't.
>
> Anyway, here's what I've been using recently, which just deals with
> memory and GC (and maybe not in the best way):
>
>   :jvm-opts ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
>
>  (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
>0.8))]
>[(str "-Xmx" mem-to-use)
> (str "-Xms" mem-to-use)
> "-XX:+UseG1GC"])
>
> After seeing Alex's post I thought that maybe I should add "-server",
> as follows:
>
>   :jvm-opts ~(let [mem-to-use (long (* (.getTotalPhysicalMemorySize
>
>  (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
>>>

Re: separation of concerns w/o encapsulation

[JUAN ANTONIO RUZ]

pasting here what I think could be a separation of concerns code pattern
proposal from "Graph: Abstractions for Structured Computation"


*... Object-oriented programming encourages the decomposition of large
systems into objects that encapsulate their state, making it easier to
build, test, and reason about these systems. OOP was a massive step forward
in software engineering, and today nearly all large-scale software
endeavors (video games, search engines, etc.) are built within this
paradigm.*

*The reason for this shift is that the older generation of procedural code
with no state boundaries came with a complexity overhead that made it
harder to understand the code than the actual concepts being represented.
No software abstraction can reduce the inherent complexity of a problem,
but it can reduce the complexity overhead, making it possible for engineers
to build complex systems faster and with fewer bugs.*
*...*
*Once an engineer comes to grok FP, they tend to organize code around how
data 'flows' between these pure functions to produce output data. The
structure of how functions connect to form the structure of a functional
computation has typically been informal. Until now*


2015-05-14 21:48 GMT+02:00 Sean Corfield :

> On May 14, 2015, at 12:37 PM, Erik Price  wrote:
> > The code itself is mutable. The nice thing about a private function is
> that I have reserved the right to change how it works someday, without fear
> that others have become dependent on the way it currently works.
>
> That’s why I suggested foo.api and foo.impl namespaces and requiring
> (convention, peer review) that nothing outside of foo.api uses the foo.impl
> namespace — any exceptions would need to be specifically discussed and
> sanctioned.
>
> And remember there’s a difference between building a library for "the
> public" to use and building software for internal use by your own team or
> other peer teams in your division.
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
> --
> 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/mJqQJn_oW4A/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: Probabilistic programming anyone?

[Sungjin Chun]

Anglican seems very interesting to me (I have no prior experience on the 
"probabilistic programming"); can I find more
newbie like me friendly document on this?

On Tuesday, May 12, 2015 at 7:05:50 PM UTC+9, Frank Wood wrote:
>
> I'm a professor at Oxford and my group has been working on a new embedded 
> language called Anglican:
>
> http://www.robots.ox.ac.uk/~fwood/anglican/
>
> It can be used to do advanced machine learning in Clojure (Java, etc.) 
> applications without having to know anything about inference or math.  For 
> example see:
>
> http://www.robots.ox.ac.uk/~fwood/anglican/examples/index.html
>
> My group would be very interested to get feedback on the language design 
> and its usefulness to the community.  Also, frankly, we could use your help 
> in taking it forward, where "help" largely means writing queries and 
> telling us what doesn't work.
>

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

Multimethod or protocol or...? Clojure design feedback

[Jason Marmon]

 

I'm working on a tool to orchestrate the migration from mongodb to datomic, 
and i'm looking for a bit of design feedback as i'm new to clojure. 


The user needs to provide functions that transform mongodb documents into 
datomic txes. Do y'all prefer the top or bottom style, or think there's a 
different way to implement this design that might be better?
12345678910111213141516171819

;; Multimethod for transforming data based on the name of the source mongodb 
collection 
(defmulti transform identity)
 
(defmethod transform "events" [data]
   ;; do something with data
 )
 
(defmethod transform "users" [data]
   ;; do something with data
 )
 
;;
 
(defprotocol Collection-Transformer
   (transform [mongo-db document]))
 
(def user-transformer
 (reify Collection-Transformer
  (transform [m d] "do stuff")))

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

Re: Multimethod or protocol or...? Clojure design feedback

[Max Countryman]

I personally prefer multimethods, generally speaking—I think they feel more 
idiomatic. Although it does depend on the context of what you’re doing. In some 
cases a protocol may be the correct choice. Here the multimethod seems fine.


> On May 14, 2015, at 16:34, Jason Marmon  wrote:
> 
> I'm working on a tool to orchestrate the migration from mongodb to datomic, 
> and i'm looking for a bit of design feedback as i'm new to clojure. 
> 
> 
> 
> The user needs to provide functions that transform mongodb documents into 
> datomic txes. Do y'all prefer the top or bottom style, or think there's a 
> different way to implement this design that might be better?
> 
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
> 10
> 11
> 12
> 13
> 14
> 15
> 16
> 17
> 18
> 19
> ;; Multimethod for transforming data based on the name of the source mongodb 
> collection 
> (defmulti transform identity)
>  
> (defmethod transform "events" [data]
>;; do something with data
>  )
>  
> (defmethod transform "users" [data]
>;; do something with data
>  )
>  
> ;;
>  
> (defprotocol Collection-Transformer
>(transform [mongo-db document]))
>  
> (def user-transformer
>  (reify Collection-Transformer
>   (transform [m d] "do stuff")))
> 
> -- 
> 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: separation of concerns w/o encapsulation

[Raoul Duke]

> Once an engineer comes to grok FP, they tend to organize code around how
> data 'flows' between these pure functions to produce output data. The
> structure of how functions connect to form the structure of a functional
> computation has typically been informal. Until now

see Flow Based Programming, Dataflow, LabView, etc.

-- 
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 the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Colin Jones]

I can heartily recommend Java Performance: The Definitive Guide to anyone 
interested in digging further into all the knobs you can set on the command 
line: http://www.amazon.com/Java-Performance-The-Definitive-Guide/dp/1449358454

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

Re: Multimethod or protocol or...? Clojure design feedback

[Daniel Compton]

Alex Miller's recent blog post on this is quite relevant
http://insideclojure.org/2015/04/27/poly-perf/
On Fri, 15 May 2015 at 12:00 pm Max Countryman  wrote:

> I personally prefer multimethods, generally speaking—I think they feel
> more idiomatic. Although it does depend on the context of what you’re
> doing. In some cases a protocol may be the correct choice. Here the
> multimethod seems fine.
>
>
> On May 14, 2015, at 16:34, Jason Marmon  wrote:
>
> I'm working on a tool to orchestrate the migration from mongodb to
> datomic, and i'm looking for a bit of design feedback as i'm new to
> clojure.
>
>
> The user needs to provide functions that transform mongodb documents into
> datomic txes. Do y'all prefer the top or bottom style, or think there's a
> different way to implement this design that might be better?
> 12345678910111213141516171819
>
> ;; Multimethod for transforming data based on the name of the source mongodb 
> collection
> (defmulti transform identity)
>
> (defmethod transform "events" [data]
>;; do something with data
>  )
>
> (defmethod transform "users" [data]
>;; do something with data
>  )
>
> ;;
>
> (defprotocol Collection-Transformer
>(transform [mongo-db document]))
>
> (def user-transformer
>  (reify Collection-Transformer
>   (transform [m d] "do stuff")))
>
>
> --
> 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.
>

-- 
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 the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Lee Spector]

Thanks Colin and also Alex and Andy.

I'm trying to determine a reasonable way to do this without reading a book 
about it.

It sounds like I should use ^:replace, -server, and also -XX:-TieredCompilation 
(is that right, the way I've changed + to -?), and also -XX:+AggressiveOpts. 
Does it make sense to use all of these together?

And maybe I should get rid of "-XX:+UseG1GC", since I'm not really sure if 
that's a good thing.

Assuming that none of those things use as big a chunk of RAM as is available, I 
guess I should keep my messy code for the memory options.

So that would mean that overall I'd do the following to maximize performance on 
long-running, compute-intensive, memory-intensive runs:

  :jvm-opts ^:replace ~(let [mem-to-use 
 (long (* (.getTotalPhysicalMemorySize

(java.lang.management.ManagementFactory/getOperatingSystemMXBean))
  0.8))]
 [(str "-Xmx" mem-to-use)
  (str "-Xms" mem-to-use)
  "-server"
  "-XX:-TieredCompilation"
  "-XX:+AggressiveOpts"])

Seem reasonable?

Thanks for all of the help!

 -Lee




> On May 14, 2015, at 8:19 PM, Colin Jones  wrote:
> 
> I can heartily recommend Java Performance: The Definitive Guide to anyone 
> interested in digging further into all the knobs you can set on the command 
> line: 
> http://www.amazon.com/Java-Performance-The-Definitive-Guide/dp/1449358454
> 

-- 
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 the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Fluid Dynamics]

On Thursday, May 14, 2015 at 8:45:09 PM UTC-4, Lee wrote:
>
> Thanks Colin and also Alex and Andy. 
>
> I'm trying to determine a reasonable way to do this without reading a book 
> about it. 
>
> It sounds like I should use ^:replace, -server, and also 
> -XX:-TieredCompilation (is that right, the way I've changed + to -?), and 
> also -XX:+AggressiveOpts. Does it make sense to use all of these together? 
>
> And maybe I should get rid of "-XX:+UseG1GC", since I'm not really sure if 
> that's a good thing. 
>
> Assuming that none of those things use as big a chunk of RAM as is 
> available, I guess I should keep my messy code for the memory options. 
>
> So that would mean that overall I'd do the following to maximize 
> performance on long-running, compute-intensive, memory-intensive runs: 
>
>   :jvm-opts ^:replace ~(let [mem-to-use 
>  (long (* (.getTotalPhysicalMemorySize 
> 
> (java.lang.management.ManagementFactory/getOperatingSystemMXBean)) 
>   0.8))] 
>  [(str "-Xmx" mem-to-use) 
>   (str "-Xms" mem-to-use) 
>   "-server" 
>   "-XX:-TieredCompilation" 
>   "-XX:+AggressiveOpts"]) 
>
> Seem reasonable? 
>
 
Umm, the :replace metadata needs to be on the vector. Attaching it to the 
let form won't do much of anything useful. So:

 :jvm-opts ~(let [mem-to-use
   (long (* (.getTotalPhysicalMemorySize
  
(java.lang.management.ManagementFactory/getOperatingSystemMXBean))
0.8))]
   ^:replace [(str "-Xmx" mem-to-use)
  (str "-Xms" mem-to-use)
  "-server"
  "-XX:-TieredCompilation"
  "-XX:+AggressiveOpts"])

-- 
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 the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Mikera]

I agree that the problem is immutable/functional constructs per se., but I 
don't think the problem is the lack of VM support either. It is possible to 
get *very* fast code on the JVM.

In Clojure the issue is more that the dynamic nature of many Clojure 
constructs and lack of static type inference make it impossible for some of 
the more advanced JVM optimisations to be applied. This isn't really a VM 
problem, it is more of a compiler problem.

When I optimise Clojure code, I always get the feeling that I am doing 
something that a "sufficiently smart compiler" should be able to do 
(forcing use of primitives rather than boxed numbers, adding type hints 
etc.)

On Friday, 15 May 2015 03:01:57 UTC+8, tbc++ wrote:
>
> I think it false view that immutable/functional constructs are slow by 
> default. Instead, a lot of it comes down to lack of support in the popular 
> VMs for these constructs. For example the following code: 
>
> (defn add-fn [& args]
>   (reduce -add 0 args))
>
> (loop [x 0]
>   (if (eq x 1)
> x
> (recur (add-fn x 1
>
> Is never going to be super fast in Clojure, but it compiles down to a loop 
> with 4 assembly operations in Pixie (https://github.com/pixie-lang/pixie) 
> all while remaining fully dynamic. But that's because the VM is tuned to 
> optimize things like varargs and reduce. You can't really tap into the VM 
> at that level on the CLR or the JVM.
>
> That's not to say that Pixie is always faster than these platforms, on the 
> contrary, it's often much slower on GC heavy operations. But hopefully 
> someday we'll reach the holy grail of a VM that aggressively optimizes 
> dynamic languages without requiring hinting or rewriting into less 
> idiomatic forms. 
>
> Timothy
>
> On Thu, May 14, 2015 at 12:36 PM, Raoul Duke  > wrote:
>
>> Ditto F# vs. C#.
>>
>> One has to wonder when / where / if functional-pure-immutable
>> approaches will ever under the covers get "fast enough"?
>>
>> --
>> 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.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>  

-- 
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 the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Lee Spector]

> On May 14, 2015, at 9:15 PM, Fluid Dynamics  wrote:
>  
> Umm, the :replace metadata needs to be on the vector. Attaching it to the let 
> form won't do much of anything useful. So:
> 
>  :jvm-opts ~(let [mem-to-use
>(long (* (.getTotalPhysicalMemorySize
>   
> (java.lang.management.ManagementFactory/getOperatingSystemMXBean))
> 0.8))]
>^:replace [(str "-Xmx" mem-to-use)
>   (str "-Xms" mem-to-use)
>   "-server"
>   "-XX:-TieredCompilation"
>   "-XX:+AggressiveOpts"])

Thanks Fluid!

 -Lee

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

Managing database schema

[Brett Morgan]

I use clj-liquibase, https://github.com/kumarshantanu/clj-liquibase. It's a 
clojure wrapper for Liquibase.  There is a function to load schema changes 
(changeset) from a file, along with many other functions to create changesets 
for your schema. 

-- 
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 the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Rangel Spasov]

All the advice here is valid; type hinting + eliminating boxed math will 
probably give you the biggest gains. By adding one type hint in the proper 
place sometimes I've been able to make my code go 5-10x faster.

I've used tools like YourKit to great advantage to be able to pinpoint 
exactly which parts of the code contribute most to the slowness.

I.e. your time is better spent optimizing a fn that's called 1k times per 
second and it's a little slow (for example, missing a type hint and has to 
do reflection or using boxed math) vs. a fn that's very slow but is only 
called once a minute.

@raspasov

On Thursday, May 14, 2015 at 1:02:42 AM UTC-7, Amith George wrote:
>
> I wrote the following code to solve this challenge - 
> https://www.reddit.com/r/dailyprogrammer/comments/35s2ds/20150513_challenge_214_intermediate_pile_of_paper/
> .
>
> Code - 
> https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/56ce1dbb6a08e96150dc85934caecfeb68108a53/src/rdp/214_intermediate.clj
>
> I executed the -main function using `lein run 1`. 
>
> Output
>
> ;; lein run 1
>
> 0 12605919
> 1 3578145
> 2 15356894
> 3 19134293
> 4 2394558
> 5 15030409
> 6 6424953
> 7 14893444
> 8 1592254
> 9 1914025
> 10 7075106
> "Elapsed time: 501168.972435 msecs"
>
> The code originally used an immutable hashmap, but I lost patience waiting 
> for the computation to end. With mutable hashmap, it still takes around 8 
> mins.
>
> I wrote a C# version of the above code - 
> https://gist.github.com/amithgeorge/766b8220f39d48221e58. It finishes 
> under 40secs. The C# exe was built under Release mode and executed directly 
> from the commandline. I expected the Clojure version to perform similarly.
>
> Any tips on what I am doing wrong?
>
> -
> Explanation of the code - Create a vector of all paper sheets, such that 
> the sheet placed last is the first element of the vector and the last 
> element is the canvas. To compute the frequency of each visible color - for 
> each point in the canvas find the first sheet in the vector that covers the 
> point. Store/increment its count in the hashmap. I understand there might 
> be better more efficient ways to solve this, but currently I am interested 
> in why the Clojure versions is so slow vis-a-vis the C# 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.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 the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Raoul Duke]

> I.e. your time is better spent optimizing a fn that's called 1k times per
> second and it's a little slow (for example, missing a type hint and has to
> do reflection or using boxed math) vs. a fn that's very slow but is only
> called once a minute.

not all apps, and not all developers, end up with code that has hot
spots (ha ha).

-- 
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 the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Rangel Spasov]

Ok, IF there's such a spot : ) .

On Thursday, May 14, 2015 at 9:57:53 PM UTC-7, raould wrote:
>
> > I.e. your time is better spent optimizing a fn that's called 1k times 
> per 
> > second and it's a little slow (for example, missing a type hint and has 
> to 
> > do reflection or using boxed math) vs. a fn that's very slow but is only 
> > called once a minute. 
>
> not all apps, and not all developers, end up with code that has hot 
> spots (ha ha). 
>

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

Controlling growth rates of generators with test.check

[Mikera]

Hi all,

I am doing some generative testing with test.check and need a way to 
control the growth rate of data structures (the regular linear growth 
quickly makes the computations too large for meaningful testing usage). I 
came up with the following solution to do this:

(defn gen-resize 
  "Creates a generator that pre-modifies the 'size' pramater with the 
function f. Use if you want to 
   have the size grow at a different rate from the normal linear scaling."
  ([f gen]
(let [gf (or (:gen gen) "gen paramter must be a test.check generator")
  new-gf (fn [rnd size]
   (gf rnd (f size)))]
  (clojure.test.check.generators.Generator. new-gf

Normal O(n) growth:

(gen/sample gen/s-pos-int 30)
=> (1 2 3 2 4 5 4 7 6 3 3 7 10 4 8 11 14 12 6 10 9 1 8 21 12 16 25 25 21 6)

Controlled O(sqrt(n)) growth:

(gen/sample (gen-resize sqrt gen/s-pos-int) 30)
=> (1 2 2 2 2 4 3 3 3 3 4 3 5 1 2 3 2 4 4 2 2 3 6 6 2 5 5 4 6 3)

So it seems to work, but is this a sane / recommended approach? Am I 
relying too much on test.check internals?

  mikera

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