Re: Best practice for looping

[Cedric Greevey]

An algorithm like that generating StackOverflowErrors suggests it's
recursing deeply, which suggests you're not using recur *enough*. If the
function calls itself, try to see if you can get that call into tail
position and change it to "recur".


On Fri, Jun 21, 2013 at 4:06 PM, P Martin  wrote:

> Hi,
>
> I am new to clojure and I am trying to reimplement some optimization code
> that uses gradient descent. I have attached the source to this post. My
> experience with gradient descent is in Matlab, which is procedural.
>
> When I run my function gradient-descent I supply step sizes and error
> values of 0.01, it runs correctly and gives me good results. However, if I
> decrease the error value below 0.001 it produces a stack overflow error. I
> get the same error if my step value goes down to 0.001.
>
> Is my looping mechanism correct and I am just having numerical
> limitations? Am I abusing loop/recur? Any suggestions/critiques would be
> great!
>
> Thanks,
> Patrick
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: generating core.logic queries

[Cedric Greevey]

Please stop focusing on just the one instance -- it's the trend that
concerns me, not any individual data point on it. I don't want to see
Clojure become wed to something closed-source, yet it seems I'm seeing the
early stages of just such a courtship lately.


On Fri, Jun 21, 2013 at 8:53 PM, Brandon Bloom wrote:

> > Perhaps not, but apparently the developers of core.logic are.
>
> That's kinda a funny remark to make to David Nolen, who is *the* developer
> of core.logic.
>
> In this case, he's talking about this wiki page:
> https://github.com/clojure/core.logic/wiki/Extending-core.logic-(Datomic-example)
>
> That's not a recommendation to use Datomic, that's just one particularly
> interesting example of how to extend core.logic
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Web Framework update

[Kelker Ryan]

Some major changes have been made to the CHP framework. This library provides the following Clojure on the front end Run Clojure inside a HTML file with the  tagsStyle templates can be written in CHTML ex. chp.template/using-template Parameters Request params ex. ($p userid)Common web headers ex. ($ user-agent)Web Headers ex. ($$ cache-control)Environmental variables ex. (env java.vm.name) Path Routing Have multiple method handlers under a single route (get, post, put, delete, and head)Routes can be defined in seperate files and namespaces DB Create SQL database schemas ex. lein schemaPerform SQL database migrations ex. lein migratePerform migration rollbacks ex. lein rollbackManipulate SQL databases with KormaSQL Code Generation Generate _javascript_ / ECMAScriptGenerate HTMLGenerate CSS



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

Re: database wrapper lib

[Sean Corfield]

On Fri, Jun 21, 2013 at 8:56 AM, Michael Klishin
 wrote:
> Relational databases: https://github.com/clojure/java.jdbc (this one is not
> very extensively documented but is also small compared to Korma)

FYI, Korma is built on top of java.jdbc and if you want a different
DSL on top of java.jdbc, I highly recommend HoneySQL.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

Re: database wrapper lib

[Carlo Zancanaro]

Hey Justin,

I'm also working on a wrapper lib for SQL queries (which can optionally use
jdbc for performing the queries). At the moment it's pretty new, so it
might not actually work for you, but if you want to take a look the code's
at https://bitbucket.org/czan/clojure-sql. It's also been pushed to clojars
(https://clojars.org/clojure-sql) if you want to try it out.

The main idea is that all queries should be composable, so you can just
think of them in terms of the fields they expose and then you should be
able to join them together however you want.

I plan to do a bit more work before actually announcing a release, but
since it was so relevant to what you're asking about I just had to mention
it.

Carlo


On 22 June 2013 04:38, serialhex  wrote:

> Hey, thanks for the links!!  I searched around but never found those, this
> helps a lot!!!
>
> Justin
>
>
> On Fri, Jun 21, 2013 at 11:56 AM, Michael Klishin <
> michael.s.klis...@gmail.com> wrote:
>
>>
>> 2013/6/21 serialhex 
>>
>>> Hi all, I'm looking for a decent database wrapper library.
>>
>>
>> Relational databases: https://github.com/clojure/java.jdbc (this one is
>> not very extensively documented but is also small compared to Korma)
>>
>> MongoDB: http://clojuremongodb.info
>> Cassandra: http://clojurecassandra.info
>> Riak: http://clojureriak.info
>> Redis: https://github.com/ptaoussanis/carmine
>> Graph databases: http://titanium.clojurewerkz.org,
>> http://clojureneo4j.info
>> ElasticSearch: http://clojureelasticsearch.info
>>
>> For data validation, http://clojurevalidations.info is one of about a
>> dozen options
>> you can easily find with a quick search.
>> --
>> MK
>>
>> http://github.com/michaelklishin
>> http://twitter.com/michaelklishin
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
>
> --
> * I am rarely happier than when spending an entire day programming my
> computer to perform automatically a task that would otherwise take me a
> good ten seconds to do by hand.
>  - Douglas Adams
> ---
> CFO: “What happens if we train people and they leave?”
> CTO: “What if we don’t and they stay?”
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: representing clojure source code as data?

[Brandon Bloom]

> I think there are 2 representations that could be useful:

I think there are really two axis: 1) Shape of the data and 2) Language 
being described

You've outlined 2 out of the 3 interesting (to me) shapes: 1) raw data 
structures and 2) datoms. I think that the 3rd interesting one is a 
map/vector tree, like the CLJS analyzer output.

The two languages to describe are EDN and Clojure. You can further break 
Clojure down by host platform, and even potentially further (for example: 
pre and post macro expansion variants of the language).

> 1. as pure EDN data that encodes the various reader macros within the 
strict EDN subset, as a kind of minimal AST

I made a related design page here: 
http://dev.clojure.org/display/design/Representing+EDN

The contents of that design page right now are focused on the raw data 
structures shape of EDN, hence the proposal for a TaggedLiteral type.

Here's some code for parsing raw data with a TaggedLiteral record into a 
vector/map tree of sorts:
https://github.com/brandonbloom/ascribe/blob/04384d21bd9e74e29d84cf2ec1c55dd5034195e0/test/ascribe/cljs/parse.clj

As for the Code variant, the tools.analyzer library and CLJS compilers have 
an internal AST representation that should eventually be standardized. The 
important thing there for me is that we differentiate fundamental 
properties of AST nodes and synthesized/derived attributes that are 
attached to each node.

>

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

Re: generating core.logic queries

[Brandon Bloom]

> Perhaps not, but apparently the developers of core.logic are.

That's kinda a funny remark to make to David Nolen, who is *the* developer 
of core.logic.

In this case, he's talking about this wiki page: 
https://github.com/clojure/core.logic/wiki/Extending-core.logic-(Datomic-example)

That's not a recommendation to use Datomic, that's just one particularly 
interesting example of how to extend core.logic

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

Re: Problem filtering with definline'd function

[Colin Fleming]

Does anyone have an idea for what I might do to diagnose/fix this? Is this
just a misunderstanding on my part? If not I'll file a bug against
definline.


On 21 June 2013 18:04, Colin Fleming  wrote:

> So this has just happened to me again:
>
> Clojure 1.5.1
> (plugin.psi/symbol? 2)
> => false
> (filter plugin.psi/symbol? [1 2 3])
> => (1 2 3)
> ((var-get #'plugin.psi/symbol?) 2)
> => (clojure.core/instance?
> org.jetbrains.plugins.clojure.psi.api.symbols.ClSymbol 2)
>
> What that looks like to me is that the macro fn (i.e. the one that is
> usually in the :inline meta) is being stored in the var. So when it's used
> by filter, it always returns true. Does anyone have any idea what else I
> could try to debug this? I'll leave the REPL session open so I can try any
> suggestions.
>
> I just tried this, looks like the fns are not the same, at least, but they
> do have the same effect:
>
> (meta #'plugin.psi/symbol?)
> => {:inline plugin.psi$symbol_QMARK_@3781ff7f, :ns plugin.psi, :name
> symbol?, :arglists ([element]), :column 1, :line 35, :file "plugin/psi.clj"}
> (= plugin.psi/symbol?
>(:inline (meta #'plugin.psi/symbol?)))
> => false
> plugin.psi/symbol?
> => plugin.psi$symbol_QMARK_@4ccc75ae
> ((:inline (meta #'plugin.psi/symbol?)) 2)
> => (clojure.core/instance?
> org.jetbrains.plugins.clojure.psi.api.symbols.ClSymbol 2)
>
>
>
> On 20 June 2013 22:48, Colin Fleming  wrote:
>
>> ClSymbol is a Java class. I don't get the replacement warning because
>> I've excluded that symbol explicitly in my ns declaration using
>> :refer-clojure :exclude.
>>
>> I haven't done a 'lein clean' because I'm not using lein, but I have
>> rebuilt various times. However, sometimes it will work and sometimes it
>> won't. I just tried this now, and I've been unable to reproduce. I guess
>> I'll keep working tomorrow and see if it crops up again. If I see it again
>> I'm going to try ((var-get #'symbol?) 2) to see if the results from the
>> function differ from the macroexpanded version.
>>
>>
>>
>>
>> On 20 June 2013 22:21, Jim - FooBar();  wrote:
>>
>>> On 20/06/13 10:59, Colin Fleming wrote:
>>>
 Because this tests for something different - that the element is an
 instance of ClSymbol. It's not testing the same thing as the core version.
 I qualify it (psi/symbol? in the examples above) to distinguish it from the
 core one.

 Basically, I'm trying to use definline to allow me to have a more
 Clojure-y API without having the performance hit of tons of tiny function
 calls.

 I agree that this is unlikely to be a bug in Clojure and is probably
 something I'm missing, but I can't figure it out.

>>>
>>> right I see...so if ClSymbol is a defrecord/deftype I don't see anything
>>> wrong with your code...when you do (in-ns 'plugin.psi) do you get a warning
>>> that core/symbol? is being replaced by psi/symbol?  ?
>>>
>>> what you tried on your repl works fine on mine:
>>>
>>> user=> (defrecord FOO [a])
>>> user.FOO
>>>
>>> user=> (definline foo? [e]
>>>   #_=>   `(instance? FOO ~e))
>>> #'user/foo?
>>>
>>> user=> (foo? 2)
>>> false
>>>
>>> user=> (filter foo? [1 2 3])
>>> ()
>>>
>>> user=> (filter foo? [(FOO. 1) 2 3])
>>> (#user.FOO{:a 1})
>>>
>>> Did you try 'lein clean' to get rid of already compiled classes? I'm
>>> suspecting you have different versions of the same class lying around
>>> because of what you said about compiling and recompiling...
>>>
>>> Jim
>>>
>>>
>>>
>>>
>>>
>>> --
>>> --
>>> 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+unsubscribe@**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+unsubscribe@**googlegroups.com
>>> .
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out
>>> .
>>>
>>>
>>>
>>
>

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

Best practice for looping

[P Martin]

Hi,

I am new to clojure and I am trying to reimplement some optimization code 
that uses gradient descent. I have attached the source to this post. My 
experience with gradient descent is in Matlab, which is procedural.
 
When I run my function gradient-descent I supply step sizes and error 
values of 0.01, it runs correctly and gives me good results. However, if I 
decrease the error value below 0.001 it produces a stack overflow error. I 
get the same error if my step value goes down to 0.001.

Is my looping mechanism correct and I am just having numerical limitations? 
Am I abusing loop/recur? Any suggestions/critiques would be great!

Thanks,
Patrick

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




core.clj
Description: Binary data


vec.clj
Description: Binary data

Re: database wrapper lib

[serialhex]

Hey, thanks for the links!!  I searched around but never found those, this
helps a lot!!!

Justin


On Fri, Jun 21, 2013 at 11:56 AM, Michael Klishin <
michael.s.klis...@gmail.com> wrote:

>
> 2013/6/21 serialhex 
>
>> Hi all, I'm looking for a decent database wrapper library.
>
>
> Relational databases: https://github.com/clojure/java.jdbc (this one is
> not very extensively documented but is also small compared to Korma)
>
> MongoDB: http://clojuremongodb.info
> Cassandra: http://clojurecassandra.info
> Riak: http://clojureriak.info
> Redis: https://github.com/ptaoussanis/carmine
> Graph databases: http://titanium.clojurewerkz.org,
> http://clojureneo4j.info
> ElasticSearch: http://clojureelasticsearch.info
>
> For data validation, http://clojurevalidations.info is one of about a
> dozen options
> you can easily find with a quick search.
> --
> MK
>
> http://github.com/michaelklishin
> http://twitter.com/michaelklishin
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
* I am rarely happier than when spending an entire day programming my
computer to perform automatically a task that would otherwise take me a
good ten seconds to do by hand.
 - Douglas Adams
---
CFO: “What happens if we train people and they leave?”
CTO: “What if we don’t and they stay?”

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

Re: generating core.logic queries

[Timothy Baldridge]

One reason why Datomic works so well with core.logic is that it exposes raw
index data to the client. I am unaware of any other database that decouples
data storage from the query engine. If you can find one that does, I'm sure
someone could expose a core.logic interface to that DB as well.

But, if you really can't stand the idea of using Datomic, and would prefer
to see examples running against other DBs, I would recommend this tutorial
that shows how core.logic can be used to query a graph database:
http://tsdh.wordpress.com/2012/01/06/using-clojures-core-logic-with-custom-data-structures/

Timothy


On Fri, Jun 21, 2013 at 10:41 AM, Cedric Greevey  wrote:

> Perhaps not, but apparently the developers of core.logic are. And it's
> only one of several similar instances to come to my attention in recent
> weeks.
>
>
> On Fri, Jun 21, 2013 at 12:22 PM, David Nolen wrote:
>
>> I wasn't suggesting using Datomic.
>>
>>
>> On Fri, Jun 21, 2013 at 12:19 PM, Cedric Greevey wrote:
>>
>>> On Fri, Jun 21, 2013 at 11:56 AM, David Nolen wrote:
>>>
 Datomic integration notes on the core.logic wiki

>>>
>>> I'm concerned with this trend towards favoring Datomic over other
>>> solutions when adding database integration to libraries. If one DB is going
>>> to be singled out for preferred treatment by a lot of Clojure developers,
>>> I'd prefer it to be an open source one, and I doubt I am alone in this.
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



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

Re: generating core.logic queries

[Cedric Greevey]

Perhaps not, but apparently the developers of core.logic are. And it's only
one of several similar instances to come to my attention in recent weeks.


On Fri, Jun 21, 2013 at 12:22 PM, David Nolen wrote:

> I wasn't suggesting using Datomic.
>
>
> On Fri, Jun 21, 2013 at 12:19 PM, Cedric Greevey wrote:
>
>> On Fri, Jun 21, 2013 at 11:56 AM, David Nolen wrote:
>>
>>> Datomic integration notes on the core.logic wiki
>>>
>>
>> I'm concerned with this trend towards favoring Datomic over other
>> solutions when adding database integration to libraries. If one DB is going
>> to be singled out for preferred treatment by a lot of Clojure developers,
>> I'd prefer it to be an open source one, and I doubt I am alone in this.
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

[Colin Yates]

Ah OK, I didn't realise.  I thought the vars would be locally scoped, i.e. 
semantically equivalent to 'let'ed symbols.

Thanks everyone for contributing.

On Friday, 21 June 2013 14:49:52 UTC+1, Jim foo.bar wrote:
>
>  On 21/06/13 14:34, Colin Yates wrote:
>  
>  Is it correct but simply non-idiomatic?
>
>
> no no it's actually very *dangerous*...by doing this you're essentially 
> introducing mutable global state in your program and Clojure is a language 
> that strives hard to minimise mutable and especially global state! I 
> wouldn't say 'wrong' because the compiler lets you do it but it is 
> certainly nasty code!
>
> Also note that if I move the body out of the 'let' version of the array 
> into another function passing in the array then the performance is the same 
> as the 'def' version, so even if def is a problem it isn't the only cause.
>
>
> using 'let' or passing the array as parameter is the nice and safe 
> approach. The general performance of clojure when it comes to primitive 
> arrays was discussed very recently in this thread [1] and was concluded 
> that Clojure does indeed match java's performance. The specific use-case 
> actually was summing up primitive arrays. I encourage you read it...In a 
> nutshell, If you're using leiningen, add this entry to your project.clj and 
> rerun your benchmarks.
>
> :jvm-opts ^replace []
>
> Jim
>
> [1] https://groups.google.com/forum/#!topic/clojure/LTtxhPxH_ws
>
>  

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

Re: generating core.logic queries

[Karsten Schmidt]

Thanks, David! I wasn't aware the macros are just sugar. Time to study the
source more closely! The above code was very naive indeed, but for sake of
illustration only. These queries would only ever deal with a small subset
of facts, which have already been selected from a number of indexes. K.

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

Re: interval trees..

[David Williams]

Hi Sunil,

I created one here:

https://github.com/mobiusinversion/interval-trees

Here is the marginalia documentation

http://mobiusinversion.github.io/interval-trees/

and the Clojars page

https://clojars.org/interval-trees

Please let me know if you have a chance to try this out and I would greatly 
appreciate any feedback.


On Monday, June 6, 2011 4:35:01 AM UTC-7, Sunil Nandihalli wrote:
>
> Hello everybody,
>  Is there any implementation of Interval 
> Trees in 
> Clojure. I found this Java 
> implementation 
> but 
> it does not have remove operation. Even some other Java Implementation 
> would do.
> Thanks,
> Sunil.
>

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

Re: generating core.logic queries

[David Nolen]

I wasn't suggesting using Datomic.


On Fri, Jun 21, 2013 at 12:19 PM, Cedric Greevey  wrote:

> On Fri, Jun 21, 2013 at 11:56 AM, David Nolen wrote:
>
>> Datomic integration notes on the core.logic wiki
>>
>
> I'm concerned with this trend towards favoring Datomic over other
> solutions when adding database integration to libraries. If one DB is going
> to be singled out for preferred treatment by a lot of Clojure developers,
> I'd prefer it to be an open source one, and I doubt I am alone in this.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: generating core.logic queries

[Cedric Greevey]

On Fri, Jun 21, 2013 at 11:56 AM, David Nolen wrote:

> Datomic integration notes on the core.logic wiki
>

I'm concerned with this trend towards favoring Datomic over other solutions
when adding database integration to libraries. If one DB is going to be
singled out for preferred treatment by a lot of Clojure developers, I'd
prefer it to be an open source one, and I doubt I am alone in this.

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

Re: matching, assigning and branching in one form

[David Nolen]

Not a specific answer to your question, but it would be cool to see someone
make the core.match regex facilities handle this.

(match [msg]
  [(#"^:(.*?)!.*PRIVMSG (.*) :(.*)" :>> [from to message])] ... true form
...
  :else ... false form ..)

David


On Fri, Jun 21, 2013 at 11:43 AM, Steven D. Arnold <
thoth.amon.i...@gmail.com> wrote:

> Hi, I am writing a simple IRC bot, pretty much just for fun, starting with
> a simple implementation originally posted by Nurullah Akkaya on his blog.
>  It already does what it's supposed to, which is message a fortune from
> mod-fortune (shelling out) when someone asks it to.
>
> However, there's a bit of code I don't like.  It looks like this:
>
>  (cond
>(re-find #"^:(.*?)!.*PRIVMSG (.*) :(.*)" msg)
>  (let [[_ from to message] (re-find #"^:(.*?)!.*PRIVMSG (.*)
> :(.*)" msg)]
>[...logic omitted...]
>
> What's happening is we're looking for a PRIVMSG, and if we find one, we
> scan the message again and pull out the chunks we're interested in, and use
> them in the "logic" part below.
>
> The problem is I don't like maintaining two regular expressions.  I wish I
> could use it only once, and therefore change it only once if it needs to be
> modified.  I'd prefer to see an expression that looks like this (for
> example):
>
> (cond
>  (if-matched #"^:(.*?)!.*PRIVMSG (.*) :(.*)" msg
>[from to message]
>(true form)
>(optional false form)))
>
> The if-matched acts as a let block while pulling out groups and assigning
> to local variables at the same time.  Also, it ignores the first "match" of
> re-find, which is the entire expression -- not generally useful to me.
>  Maybe if-matched-groups would ignore the overall expression, and
> if-matched would include it.
>
> I suppose a macro might be the way to go to accomplish this, but I wonder
> if there are any Clojure tricks that could accomplish this short of a
> macro.  Also, do any fellow Clojurians think a macro like this is a bad
> idea in general?  Would you suggest taking a different tack to solve this
> problem?
>
> Thanks in advance!
> steven
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: database wrapper lib

[Michael Klishin]

2013/6/21 serialhex 

> Hi all, I'm looking for a decent database wrapper library.


Relational databases: https://github.com/clojure/java.jdbc (this one is not
very extensively documented but is also small compared to Korma)

MongoDB: http://clojuremongodb.info
Cassandra: http://clojurecassandra.info
Riak: http://clojureriak.info
Redis: https://github.com/ptaoussanis/carmine
Graph databases: http://titanium.clojurewerkz.org, http://clojureneo4j.info
ElasticSearch: http://clojureelasticsearch.info

For data validation, http://clojurevalidations.info is one of about a dozen
options
you can easily find with a quick search.
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

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

Re: generating core.logic queries

[David Nolen]

It's common misconception that core.logic is a bunch of macros. The macros
are just sugar, there are functions for *everything*.

You can load a stream of "facts" however you please, you should look at
`to-stream` which can take any Clojure sequence of data and make it useable
from core.logic as a list of facts. Note this is very naive - you'll have
to provide indexing yourself if you have a large data set. You might want
to take a look at the experimental Datomic integration notes on the
core.logic wiki for further guidance.

I would look into this approach first and see if this doesn't answer your
other questions as well.

David


On Fri, Jun 21, 2013 at 11:28 AM, Karsten Schmidt  wrote:

> Hi all, am toying around with the thought of generating core.logic
> queries dynamically. However, I'm stuck at square one since all
> the core.logic functions are macros and am not sure how to refer
> to logic vars within a query generator fn.
>
> E.g. given this list of facts...
>
> (def myfacts
>   [[:karsten :spouse :mia]
>[:fred :spouse :anna]
>[:mia :name "mia"]
>[:anna :name "anna"]])
>
> ...I'd like to find the person who's spouse's name is "mia".
>
> The SPARQL[1] equivalent for the above would be:
> SELECT ?p WHERE { ?p :spouse ?s . ?s :name "mia" }
>
> In core.logic I can do this equivalently, but have no idea how to
> generate the lists of `conso`s dynamically:
>
> (run* [p]
>  (fresh [s]
>   (conde
>[(conso p [:spouse s] (myfacts 0))]
>[(conso p [:spouse s] (myfacts 1))]
>[(conso p [:spouse s] (myfacts 2))]
>[(conso p [:spouse s] (myfacts 3))])
>   (conde
>[(conso s [:name "mia"] (myfacts 0))]
>[(conso s [:name "mia"] (myfacts 1))]
>[(conso s [:name "mia"] (myfacts 2))]
>[(conso s [:name "mia"] (myfacts 3))])))
>
> ; => (:karsten)
>
> a) How would I go about generating such a single `conso` only given a
> single logic var, var position in the triple and the fact triple
> itself?
>
> b) How can I refer to a logic var in a function outside the lexical
> scope of `fresh` or `run*`?
>
> c) What is the best way to produce and pass a seq of goals for `conde`?
> Since
> it is a macro I can't use `apply`...
>
> K.
>
> [1] http://www.w3.org/TR/sparql11-overview/
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

database wrapper lib

[serialhex]

Hi all, I'm looking for a decent database wrapper library.  I'm probably
going to end up using PostgrSQL & maybe SQLite for testing.  I've looked at
Korma & a few others, but I'm getting lost on how to *actually use* them.
 I'm new to Clojure, so something with a good tutorial would be best!

Thanks!

Justin

-- 
* I am rarely happier than when spending an entire day programming my
computer to perform automatically a task that would otherwise take me a
good ten seconds to do by hand.
 - Douglas Adams
---
CFO: “What happens if we train people and they leave?”
CTO: “What if we don’t and they stay?”

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

matching, assigning and branching in one form

[Steven D. Arnold]

Hi, I am writing a simple IRC bot, pretty much just for fun, starting with a 
simple implementation originally posted by Nurullah Akkaya on his blog.  It 
already does what it's supposed to, which is message a fortune from mod-fortune 
(shelling out) when someone asks it to.

However, there's a bit of code I don't like.  It looks like this:

 (cond
   (re-find #"^:(.*?)!.*PRIVMSG (.*) :(.*)" msg)
 (let [[_ from to message] (re-find #"^:(.*?)!.*PRIVMSG (.*) :(.*)" 
msg)]
   [...logic omitted...]

What's happening is we're looking for a PRIVMSG, and if we find one, we scan 
the message again and pull out the chunks we're interested in, and use them in 
the "logic" part below.

The problem is I don't like maintaining two regular expressions.  I wish I 
could use it only once, and therefore change it only once if it needs to be 
modified.  I'd prefer to see an expression that looks like this (for example):

(cond
 (if-matched #"^:(.*?)!.*PRIVMSG (.*) :(.*)" msg
   [from to message]
   (true form)
   (optional false form)))

The if-matched acts as a let block while pulling out groups and assigning to 
local variables at the same time.  Also, it ignores the first "match" of 
re-find, which is the entire expression -- not generally useful to me.  Maybe 
if-matched-groups would ignore the overall expression, and if-matched would 
include it.

I suppose a macro might be the way to go to accomplish this, but I wonder if 
there are any Clojure tricks that could accomplish this short of a macro.  
Also, do any fellow Clojurians think a macro like this is a bad idea in 
general?  Would you suggest taking a different tack to solve this problem?

Thanks in advance!
steven

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

generating core.logic queries

[Karsten Schmidt]

Hi all, am toying around with the thought of generating core.logic
queries dynamically. However, I'm stuck at square one since all
the core.logic functions are macros and am not sure how to refer
to logic vars within a query generator fn.

E.g. given this list of facts...

(def myfacts
  [[:karsten :spouse :mia]
   [:fred :spouse :anna]
   [:mia :name "mia"]
   [:anna :name "anna"]])

...I'd like to find the person who's spouse's name is "mia".

The SPARQL[1] equivalent for the above would be:
SELECT ?p WHERE { ?p :spouse ?s . ?s :name "mia" }

In core.logic I can do this equivalently, but have no idea how to
generate the lists of `conso`s dynamically:

(run* [p]
 (fresh [s]
  (conde
   [(conso p [:spouse s] (myfacts 0))]
   [(conso p [:spouse s] (myfacts 1))]
   [(conso p [:spouse s] (myfacts 2))]
   [(conso p [:spouse s] (myfacts 3))])
  (conde
   [(conso s [:name "mia"] (myfacts 0))]
   [(conso s [:name "mia"] (myfacts 1))]
   [(conso s [:name "mia"] (myfacts 2))]
   [(conso s [:name "mia"] (myfacts 3))])))

; => (:karsten)

a) How would I go about generating such a single `conso` only given a
single logic var, var position in the triple and the fact triple
itself?

b) How can I refer to a logic var in a function outside the lexical
scope of `fresh` or `run*`?

c) What is the best way to produce and pass a seq of goals for `conde`? Since
it is a macro I can't use `apply`...

K.

[1] http://www.w3.org/TR/sparql11-overview/

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

Re: Function returns nil

[Phillip Lord]

"Jim - FooBar();"  writes:

> On 21/06/13 14:01, Neale Swinnerton wrote:
>>
>>
>> I really wish there were support for this in clojure.core: both
>> "dofor"
>> and "domap" would be very useful.
>>
>>
>> mapv is non-lazy, which gives you the semantics of a domap as long as you
>> don't mind a vector over a sequence
>
> exactly! also, that's why macros are for...every time I think "I wish there
> was X in clojure.core...", the next thought is macros :)
> what you wish is rather trivial to implement and it doesn't even have to be a
> macro...

Well, indeed, yes, I have implemented it. But, then I have to do require
statements everywhere, or I redo the implementation in every package, or
add a dependency. Lots of functions in clojure.core are trivial to
implement after all. dofor really is different from doseq because it
doesn't drop the head.

Didn't know about mapv though. Will use that lots!

Phil


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

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

[Jim - FooBar();]

On 21/06/13 15:06, Andy Fingerhut wrote:
Colin showed pretty clearly in his email that he was using "lein 
uberjar" followed by running the JVM explicitly with his own command 
line, so Leiningen has no way to affect the JVM command line options 
in that case.


oops! I thought Michael meant the guys from Prismatic not the OP on this 
thread. Yes, this doesn't apply to Colin...

my bad...I'm really sorry...

Jim

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

[Michael Klishin]

2013/6/21 Jim - FooBar(); 

> Did you read the entire thread?
> both Jason and Leon (who originally posted) admit that this was the
> problem...Stuart even opened this issue:
> https://github.com/technomancy/leiningen/pull/1230
>

Leiningen's default only apply if you, hm, run Leiningen.

If you run java -jar …, you don't run Leiningen and the JVM flags used
are exactly what you provide.
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

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

Re: fastest way to produce a PersistentList

[Jim - FooBar();]

Hi David,


On 21/06/13 14:51, David Nolen wrote:
The problem is the reversing of the list if you want to convert back 
to a list. You can avoid this but you have to use a custom mapping 
operation, continuation passing style, and a trampoline - it won't be 
fast.


Another option is to realize that concrete types simply don't matter. 
What you're trying to avoid is getting stuck with a ISeq vs. a 
IPersistentList (note you shouldn't care about having a PersistentList 
as none of the Clojure fns target that).


Yes, but what about java interop? Why not being able to send data over 
from Java to that namespace? The protocol is also extended to Lists, 
Vectors, arrays etc. One is able to send his ArrayLists for 
normalisation to that namespace and get the same type back or a similar 
one (conforming to a common interface). I'll admit that sending 
PersistentLists from Java is extremely unlikely but it's been bugging me 
since this is the one extension-point where uniformity breaks. I will 
consider removing the extension-point to IPersistenList. If such a type 
is passed in, the extension-point for IPersistentCollection should catch 
it, which happens to return a vector.




One bit of cleverness you could do is to create a new type that 
satisfies all the interfaces of IPersistentList and return that 
instead (under the hood you can hide the lazy sequence or whatever you 
like generated by the mapping operation). A bit more work but probably 
accomplishes what you want.

 that does sound more work but I'll look into it anyway...:)



David


thanks a lot,
Jim



On Fri, Jun 21, 2013 at 9:32 AM, Jim - FooBar(); > wrote:


On 21/06/13 14:08, Philip Potter wrote:

Your logic here is incorrect. To say "transients == fast, persistents
== slow" is to grossly oversimplify things.


Yes, I am indeed oversimplifying things but that doesn't change
the fact that 'into' will be *slower* for collections that don't
have transient cousins than the ones that have. It will also be
slower if you don't use the 'transient-capabilities'  than when
you use them. I didn't mean to say that persistents==slow but
rather that filling up a transient will always be faster (for more
than 5-6 elements I') than filling up a persistent.


The default data structures are**fast**. Transients are offered, where
they make sense, as optimization to make things go**faster**. Note that
this does not change the big-O complexity.

I did not imply otherwise did I?


There is no analogous case in lists. Every conj operation necessarly
allocates a new cons cell; there is no scope for saving time by
bashing in place. Therefore, there is no transient for lists.

The fact that no transient optimization exists for lists does not mean
that lists are slow. This logic simply does not follow.


again, I never said that lists are slow but that with my current
implementation the extension-point for IPeristentList is
consistently slower than all the rest extensions. Even lazy-seqs
are faster (NOT the data-structure but the mapping operation).
Therefore I'd like to get it in-par with at least lazy-seqs.



If you're afraid of performing 2 passes, you could take advantage of 
laziness:

(->> (rseq v)
   (map f)
   (into '()))

Since map is lazy, this will only perform one pass (though it appears
on first glance that it performs two).


I already tried that but cannot call 'rseq' on a PersistenList and
reverse would do an entire pass.
ClassCastException clojure.lang.PersistentList cannot be cast to
clojure.lang.Reversible  clojure.core/rseq (core.clj:1497)




but I would be wary of your use of the word "fastest" at the top.
Normally on the JVM, the answer to a "what is the fastest way to..?"
question is "it depends". A much easier question to answer is "Is X
fast enough?"


I thought I was very careful to provide all the details for the
"what does it depend on?" question. Ok, the title just reads
"fastest way..." but in the message I explained all the
constraints of my problem. I carefully  said "the fastest way to
produce a list from mapping" and since I explained that these are
all protocol extensions you can infer that I am extending it to
PersistenLIsts and I want to produce PersistentLists. The question
is much narrower now isn't it? in any case I apologise for
potentially causing confusion... this wasn't even a question about
performance...I don't care if the fastest way is fast enough. All
I care is that I find the fastest way...if that's not fast-enough
then the consumer can choose not to use it...but I do want to
offer the fastest way to do it by default (should the user choose
it)...much like 'conj' works polymorphically

regards,

Jim





-- 
-- 
You received this message because you are sub

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

[Andy Fingerhut]

:jvm-opts and that ticket for Leiningen only affect the options passed to
the JVM if you let Leiningen invoke the JVM for you, e.g. via "lein run ..."

Colin showed pretty clearly in his email that he was using "lein uberjar"
followed by running the JVM explicitly with his own command line, so
Leiningen has no way to affect the JVM command line options in that case.

Andy


On Fri, Jun 21, 2013 at 6:59 AM, Jim - FooBar(); wrote:

>  Did you read the entire thread?
> both Jason and Leon (who originally posted) admit that this was the
> problem...Stuart even opened this issue:
> https://github.com/technomancy/leiningen/pull/1230
>
> the very last post reads:
>
> I should follow up on this and clarify that core.matrix's esum is in fact
> as fast as Java -- I apologize for the false statement (I was unaware that
> new versions of leiningen disable advanced JIT optimizations by default,
> which lead to the numbers I reported).
>
> Jim
>
>
>
>
> On 21/06/13 14:54, Michael Klishin wrote:
>
>  2013/6/21 Jim - FooBar(); 
>
>> If you're using leiningen, add this entry to your project.clj and rerun
>> your benchmarks.
>>
>> :jvm-opts ^replace []
>>
>
> Original post suggests the code is executed by building an uberjar running
> java -jar target/…
> so Leiningen default JVM options are not relevant.
> --
> MK
>
> http://github.com/michaelklishin
> http://twitter.com/michaelklishin
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: fastest way to produce a PersistentList

[David Nolen]

The problem is the reversing of the list if you want to convert back to a
list. You can avoid this but you have to use a custom mapping operation,
continuation passing style, and a trampoline - it won't be fast.

Another option is to realize that concrete types simply don't matter. What
you're trying to avoid is getting stuck with a ISeq vs. a IPersistentList
(note you shouldn't care about having a PersistentList as none of the
Clojure fns target that).

One bit of cleverness you could do is to create a new type that satisfies
all the interfaces of IPersistentList and return that instead (under the
hood you can hide the lazy sequence or whatever you like generated by the
mapping operation). A bit more work but probably accomplishes what you want.

David


On Fri, Jun 21, 2013 at 9:32 AM, Jim - FooBar(); wrote:

>  On 21/06/13 14:08, Philip Potter wrote:
>
> Your logic here is incorrect. To say "transients == fast, persistents
> == slow" is to grossly oversimplify things.
>
>
> Yes, I am indeed oversimplifying things but that doesn't change the fact
> that 'into' will be *slower* for collections that don't have transient
> cousins than the ones that have. It will also be slower if you don't use
> the 'transient-capabilities'  than when you use them. I didn't mean to say
> that persistents==slow but rather that filling up a transient will always
> be faster (for more than 5-6 elements I') than filling up a persistent.
>
>  The default data structures are **fast**. Transients are offered, where
> they make sense, as optimization to make things go **faster**. Note that
> this does not change the big-O complexity.
>
>  I did not imply otherwise did I?
>
>  There is no analogous case in lists. Every conj operation necessarly
> allocates a new cons cell; there is no scope for saving time by
> bashing in place. Therefore, there is no transient for lists.
>
> The fact that no transient optimization exists for lists does not mean
> that lists are slow. This logic simply does not follow.
>
>
> again, I never said that lists are slow but that with my current
> implementation the extension-point for IPeristentList is consistently
> slower than all the rest extensions. Even lazy-seqs are faster (NOT the
> data-structure but the mapping operation). Therefore I'd like to get it
> in-par with at least lazy-seqs.
>
>
>  If you're afraid of performing 2 passes, you could take advantage of 
> laziness:
>
> (->> (rseq v)
>   (map f)
>   (into '()))
>
> Since map is lazy, this will only perform one pass (though it appears
> on first glance that it performs two).
>
>
> I already tried that but cannot call 'rseq' on a PersistenList and reverse
> would do an entire pass.
> ClassCastException clojure.lang.PersistentList cannot be cast to
> clojure.lang.Reversible  clojure.core/rseq (core.clj:1497)
>
>
>
>  but I would be wary of your use of the word "fastest" at the top.
> Normally on the JVM, the answer to a "what is the fastest way to..?"
> question is "it depends". A much easier question to answer is "Is X
> fast enough?"
>
>
> I thought I was very careful to provide all the details for the "what does
> it depend on?" question. Ok, the title just reads "fastest way..." but in
> the message I explained all the constraints of my problem. I carefully
> said "the fastest way to produce a list from mapping" and since I explained
> that these are all protocol extensions you can infer that I am extending it
> to PersistenLIsts and I want to produce PersistentLists. The question is
> much narrower now isn't it? in any case I apologise for potentially causing
> confusion... this wasn't even a question about performance...I don't care
> if the fastest way is fast enough. All I care is that I find the fastest
> way...if that's not fast-enough then the consumer can choose not to use
> it...but I do want to offer the fastest way to do it by default (should the
> user choose it)...much like 'conj' works polymorphically
>
> regards,
>
> Jim
>
>
>
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe 

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

[Jim - FooBar();]

Did you read the entire thread?
both Jason and Leon (who originally posted) admit that this was the 
problem...Stuart even opened this issue:

https://github.com/technomancy/leiningen/pull/1230

the very last post reads:

I should follow up on this and clarify that core.matrix's esum is in 
fact as fast as Java -- I apologize for the false statement (I was 
unaware that new versions of leiningen disable advanced JIT 
optimizations by default, which lead to the numbers I reported).


Jim



On 21/06/13 14:54, Michael Klishin wrote:
2013/6/21 Jim - FooBar(); >


If you're using leiningen, add this entry to your project.clj and
rerun your benchmarks.

:jvm-opts ^replace []


Original post suggests the code is executed by building an uberjar 
running java -jar target/…

so Leiningen default JVM options are not relevant.
--
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com.

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




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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

[Michael Klishin]

2013/6/21 Jim - FooBar(); 

> If you're using leiningen, add this entry to your project.clj and rerun
> your benchmarks.
>
> :jvm-opts ^replace []
>

Original post suggests the code is executed by building an uberjar running
java -jar target/…
so Leiningen default JVM options are not relevant.
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

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

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

[Michael Klishin]

2013/6/21 Colin Yates 

> Is it correct but simply non-idiomatic?


It's not how defs are supposed to be used. It's like using fields for
everything in Java
even though you could use local variables for a lot of things, just because
you can.

def produces a shared (well, namespace-local) var. You probably
want a function-local one.

On top of that, since the thread is about performance, vars have features
that locals don't
and no feature comes without performance overhead.
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

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

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

[Jim - FooBar();]

On 21/06/13 14:34, Colin Yates wrote:

 Is it correct but simply non-idiomatic?


no no it's actually very *dangerous*...by doing this you're essentially 
introducing mutable global state in your program and Clojure is a 
language that strives hard to minimise mutable and especially global 
state! I wouldn't say 'wrong' because the compiler lets you do it but it 
is certainly nasty code!


Also note that if I move the body out of the 'let' version of the 
array into another function passing in the array then the performance 
is the same as the 'def' version, so even if def is a problem it isn't 
the only cause.


using 'let' or passing the array as parameter is the nice and safe 
approach. The general performance of clojure when it comes to primitive 
arrays was discussed very recently in this thread [1] and was concluded 
that Clojure does indeed match java's performance. The specific use-case 
actually was summing up primitive arrays. I encourage you read it...In a 
nutshell, If you're using leiningen, add this entry to your project.clj 
and rerun your benchmarks.


:jvm-opts ^replace []

Jim

[1] https://groups.google.com/forum/#!topic/clojure/LTtxhPxH_ws 



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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

[Colin Yates]

Thanks Jim and David.

David, can you expand on why it is incorrect?  That is such a strong word.
 Is it correct but simply non-idiomatic?

Also note that if I move the body out of the 'let' version of the array
into another function passing in the array then the performance is the same
as the 'def' version, so even if def is a problem it isn't the only cause.



On 21 June 2013 14:29, David Nolen  wrote:

> Using `def` like that is simply incorrect. `def` should always be at the
> top level unlike say Scheme.
>
> I would first remove all internal defs and then rerun your benchmarks.
>
>
> On Fri, Jun 21, 2013 at 8:36 AM, Colin Yates wrote:
>
>> Hi all,
>>
>> I am doing some (naive and trivial) performance tests before deciding
>> whether and how to use Clojure for some performance critical number
>> cruching and I wanted help understanding the behaviour.
>>
>> I am defining an array inside a function, setting the contents to be 1
>> and then summing them up (by areducing) them (I chose 1 instead of a random
>> number for consistency, obviously the contents will be different otherwise
>> it would all reduce to (n) :)).  If I 'let' the array then it is factors of
>> 10 faster than if I def the array.
>>
>> The relevant code (
>> https://github.com/yatesco/clojure-perf/blob/master/src/inc.clj):
>>
>> [code]
>> (ns inc
>>   (:gen-class))
>>
>> (defn- inc-atom [n]
>>   (def x (atom 0))
>>   (dotimes [n n] (swap! x inc))
>>   @x)
>>
>> (defn- array-let [n]
>>   (let [a (int-array n)]
>> (dotimes [n n] (aset-int a n 1))
>> (areduce a i ret 0
>>  (+ ret (aget a i)
>>
>> (defn- array-def [n]
>>   (def a (int-array n))
>>   (dotimes [n n] (aset-int a n 1))
>>   (areduce a i ret 0
>>(+ ret (aget a i
>>
>> (defn- run-test [subject n]
>>   (time (do (def x (subject n)) (println x
>>
>> (defn -main [& args]
>>   (let [n 100]
>> (println "inc atom")
>> (run-test inc-atom n)
>> (println "array with let")
>> (run-test array-let n)
>> (println "array with def")
>> (run-test array-def n))
>> )
>> [/code]
>>
>> Interestingly, if I refactored an 'execute-on-array' def which array-let
>> and array-def delegated to then they had the same performance which seems
>> to imply it is about scoping, but the array in both array-let and array-def
>> have exactly the same scope...  Setting the autoboxing warning to true
>> didn't point out anything either.
>>
>> The output (from my VM, so a bit slow):
>> [code]
>> inc atom
>> 100
>> "Elapsed time: 213.214118 msecs"
>> array with let
>> 100
>> "Elapsed time: 75.302602 msecs"
>> array with def
>> 100
>> "Elapsed time: 12868.970203 msecs"
>> [/code]
>>
>> For comparison, the following java code:
>>
>> [code]
>> package perf;
>>
>> public class Inc {
>> public static void main(String[] args) {
>> int n = 100;
>> int counter = 0;
>> long start = System.currentTimeMillis();
>> for (int i=0; i> long end  = System.currentTimeMillis();
>> System.out.println ("Naive " + (end - start) + " ms, counter is "
>> + counter);
>>
>> counter = 0;
>> int[] arr = new int[n];
>> start = System.currentTimeMillis();
>> for (int i=0; i> for (int i=0; i> end  = System.currentTimeMillis();
>> System.out.println ("Array " + (end - start) + " ms, counter is "
>> + counter);
>>}
>> }
>> [/code]
>>
>> produces the (as expected, much faster) results :
>>
>> [code]
>> Naive 3 ms, counter is 100
>> Array 6 ms, counter is 100
>> [/code]
>>
>> I am not surprised that the atom/inc takes much longer than 3 ms, but I
>> don't understand why the array solution is so much more expensive in
>> Clojure?
>>
>> On a related point - can anyone provide a faster implementation of
>> summing up the contents of an array?
>>
>> A lein project can be found https://github.com/yatesco/clojure-perf,
>> 'lein uberjar; java -jar target/*.jar should demonstrate the output.
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note tha

Re: fastest way to produce a PersistentList

[Jim - FooBar();]

On 21/06/13 14:08, Philip Potter wrote:

Your logic here is incorrect. To say "transients == fast, persistents
== slow" is to grossly oversimplify things.


Yes, I am indeed oversimplifying things but that doesn't change the fact 
that 'into' will be *slower* for collections that don't have transient 
cousins than the ones that have. It will also be slower if you don't use 
the 'transient-capabilities'  than when you use them. I didn't mean to 
say that persistents==slow but rather that filling up a transient will 
always be faster (for more than 5-6 elements I') than filling up a 
persistent.



The default data structures are*fast*. Transients are offered, where
they make sense, as optimization to make things go*faster*. Note that
this does not change the big-O complexity.

I did not imply otherwise did I?


There is no analogous case in lists. Every conj operation necessarly
allocates a new cons cell; there is no scope for saving time by
bashing in place. Therefore, there is no transient for lists.

The fact that no transient optimization exists for lists does not mean
that lists are slow. This logic simply does not follow.


again, I never said that lists are slow but that with my current 
implementation the extension-point for IPeristentList is consistently 
slower than all the rest extensions. Even lazy-seqs are faster (NOT the 
data-structure but the mapping operation). Therefore I'd like to get it 
in-par with at least lazy-seqs.



If you're afraid of performing 2 passes, you could take advantage of laziness:

(->> (rseq v)
   (map f)
   (into '()))

Since map is lazy, this will only perform one pass (though it appears
on first glance that it performs two).


I already tried that but cannot call 'rseq' on a PersistenList and 
reverse would do an entire pass.
ClassCastException clojure.lang.PersistentList cannot be cast to 
clojure.lang.Reversible  clojure.core/rseq (core.clj:1497)




but I would be wary of your use of the word "fastest" at the top.
Normally on the JVM, the answer to a "what is the fastest way to..?"
question is "it depends". A much easier question to answer is "Is X
fast enough?"


I thought I was very careful to provide all the details for the "what 
does it depend on?" question. Ok, the title just reads "fastest way..." 
but in the message I explained all the constraints of my problem. I 
carefully  said "the fastest way to produce a list from mapping" and 
since I explained that these are all protocol extensions you can infer 
that I am extending it to PersistenLIsts and I want to produce 
PersistentLists. The question is much narrower now isn't it? in any case 
I apologise for potentially causing confusion... this wasn't even a 
question about performance...I don't care if the fastest way is fast 
enough. All I care is that I find the fastest way...if that's not 
fast-enough then the consumer can choose not to use it...but I do want 
to offer the fastest way to do it by default (should the user choose 
it)...much like 'conj' works polymorphically


regards,

Jim





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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

[David Nolen]

Using `def` like that is simply incorrect. `def` should always be at the
top level unlike say Scheme.

I would first remove all internal defs and then rerun your benchmarks.


On Fri, Jun 21, 2013 at 8:36 AM, Colin Yates  wrote:

> Hi all,
>
> I am doing some (naive and trivial) performance tests before deciding
> whether and how to use Clojure for some performance critical number
> cruching and I wanted help understanding the behaviour.
>
> I am defining an array inside a function, setting the contents to be 1 and
> then summing them up (by areducing) them (I chose 1 instead of a random
> number for consistency, obviously the contents will be different otherwise
> it would all reduce to (n) :)).  If I 'let' the array then it is factors of
> 10 faster than if I def the array.
>
> The relevant code (
> https://github.com/yatesco/clojure-perf/blob/master/src/inc.clj):
>
> [code]
> (ns inc
>   (:gen-class))
>
> (defn- inc-atom [n]
>   (def x (atom 0))
>   (dotimes [n n] (swap! x inc))
>   @x)
>
> (defn- array-let [n]
>   (let [a (int-array n)]
> (dotimes [n n] (aset-int a n 1))
> (areduce a i ret 0
>  (+ ret (aget a i)
>
> (defn- array-def [n]
>   (def a (int-array n))
>   (dotimes [n n] (aset-int a n 1))
>   (areduce a i ret 0
>(+ ret (aget a i
>
> (defn- run-test [subject n]
>   (time (do (def x (subject n)) (println x
>
> (defn -main [& args]
>   (let [n 100]
> (println "inc atom")
> (run-test inc-atom n)
> (println "array with let")
> (run-test array-let n)
> (println "array with def")
> (run-test array-def n))
> )
> [/code]
>
> Interestingly, if I refactored an 'execute-on-array' def which array-let
> and array-def delegated to then they had the same performance which seems
> to imply it is about scoping, but the array in both array-let and array-def
> have exactly the same scope...  Setting the autoboxing warning to true
> didn't point out anything either.
>
> The output (from my VM, so a bit slow):
> [code]
> inc atom
> 100
> "Elapsed time: 213.214118 msecs"
> array with let
> 100
> "Elapsed time: 75.302602 msecs"
> array with def
> 100
> "Elapsed time: 12868.970203 msecs"
> [/code]
>
> For comparison, the following java code:
>
> [code]
> package perf;
>
> public class Inc {
> public static void main(String[] args) {
> int n = 100;
> int counter = 0;
> long start = System.currentTimeMillis();
> for (int i=0; i long end  = System.currentTimeMillis();
> System.out.println ("Naive " + (end - start) + " ms, counter is "
> + counter);
>
> counter = 0;
> int[] arr = new int[n];
> start = System.currentTimeMillis();
> for (int i=0; i for (int i=0; i end  = System.currentTimeMillis();
> System.out.println ("Array " + (end - start) + " ms, counter is "
> + counter);
>}
> }
> [/code]
>
> produces the (as expected, much faster) results :
>
> [code]
> Naive 3 ms, counter is 100
> Array 6 ms, counter is 100
> [/code]
>
> I am not surprised that the atom/inc takes much longer than 3 ms, but I
> don't understand why the array solution is so much more expensive in
> Clojure?
>
> On a related point - can anyone provide a faster implementation of summing
> up the contents of an array?
>
> A lein project can be found https://github.com/yatesco/clojure-perf,
> 'lein uberjar; java -jar target/*.jar should demonstrate the output.
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Function returns nil

[Jay C]

Cheers Jim, my problem is now solved using :when and then doing (apply str 
(fn)) to the return value.

On Friday, 21 June 2013 14:08:19 UTC+1, Jim foo.bar wrote:
>
> 'for' accepts a :when clause which will get you even further :) 
>
> Jim 
>
> ps: it also accepts a :let clause if you find it useful 
>
>
> On 21/06/13 14:06, Jay C wrote: 
> > Thanks for all the input. Using for as in Phillip's suggestion seems 
> > to have gotten me somewhere, but now the function returns during every 
> > iteration. What am I missing to have it only return when a conditional 
> > statement is satisfied? 
> > -- 
> > -- 
> > 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/groups/opt_out. 
> > 
> > 
>
>

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

Re: Function returns nil

[Jay C]

On Friday, 21 June 2013 11:17:44 UTC+1, Jay C wrote:
>
> Hi, I'm fairly new to Clojure and need help with a problem. The following 
> function always returns nil, whereas it should return the value of "line" 
> (which is not nil - I've tested).
>
> (defn find-line-in-output [regex]
>> (with-open [rdr (reader belarc-output-filepath)]
>> (doseq [line (line-seq rdr)]
>> (if (not (nil? (re-find (re-pattern regex) line)))
>> line
>> )
>> )
>> )
>> )
>>
>

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

Re: Function returns nil

[Jim - FooBar();]

'for' accepts a :when clause which will get you even further :)

Jim

ps: it also accepts a :let clause if you find it useful


On 21/06/13 14:06, Jay C wrote:
Thanks for all the input. Using for as in Phillip's suggestion seems 
to have gotten me somewhere, but now the function returns during every 
iteration. What am I missing to have it only return when a conditional 
statement is satisfied?

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com.

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




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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: fastest way to produce a PersistentList

[Philip Potter]

On 21 June 2013 13:37, Jim - FooBar();  wrote:
> Hi all,
>
> what do you guys do when you want to map a fn over a list but you want to
> produce a list as the result (not vector or lazy-seq). What is the fastest
> way of doing this?
>
> My first attempt was this:
>
> (->> (mapv f coll)
>   rseq ;;reverse fast
>  (into '()))
>
> but I quickly realised that lists do not have transient counterparts.
> Therefore, the call to 'into' will be slow...

Your logic here is incorrect. To say "transients == fast, persistents
== slow" is to grossly oversimplify things.

The default data structures are *fast*. Transients are offered, where
they make sense, as optimization to make things go *faster*. Note that
this does not change the big-O complexity.

Transients make sense for vectors and maps since they are 32-wide
tree-based data structures, and often a conj or assoc operation on a
persistent data structure will entirely replace a tree node with a
copy with one entry replaced. This operation can be optimized to a
mutable bash-the-node-in-place operation provided you know you won't
want the old value afterwards.

There is no analogous case in lists. Every conj operation necessarly
allocates a new cons cell; there is no scope for saving time by
bashing in place. Therefore, there is no transient for lists.

The fact that no transient optimization exists for lists does not mean
that lists are slow. This logic simply does not follow.

> in addition, I'm performing 2
> passes with this...
>
> any ideas?

If you're afraid of performing 2 passes, you could take advantage of laziness:

(->> (rseq v)
  (map f)
  (into '()))

Since map is lazy, this will only perform one pass (though it appears
on first glance that it performs two).

but I would be wary of your use of the word "fastest" at the top.
Normally on the JVM, the answer to a "what is the fastest way to..?"
question is "it depends". A much easier question to answer is "Is X
fast enough?"

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

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

Re: Function returns nil

[Jay C]

Thanks for all the input. Using for as in Phillip's suggestion seems to 
have gotten me somewhere, but now the function returns during every 
iteration. What am I missing to have it only return when a conditional 
statement is satisfied?

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

Re: Function returns nil

[Jim - FooBar();]

On 21/06/13 14:01, Neale Swinnerton wrote:



I really wish there were support for this in clojure.core: both
"dofor"
and "domap" would be very useful.


mapv is non-lazy, which gives you the semantics of a domap as long as 
you don't mind a vector over a sequence


exactly! also, that's why macros are for...every time I think "I wish 
there was X in clojure.core...", the next thought is macros :)
what you wish is rather trivial to implement and it doesn't even have to 
be a macro...


Jim




--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com.

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




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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Function returns nil

[Neale Swinnerton]

I really wish there were support for this in clojure.core: both "dofor"
> and "domap" would be very useful.
>

mapv is non-lazy, which gives you the semantics of a domap as long as you
don't mind a vector over a sequence

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

Re: Function returns nil

[Jim - FooBar();]

aaa yes, of course! :)

Jim



On 21/06/13 13:47, John D. Hume wrote:


If you use for, which is lazy, wrap it in a doall to force it to do 
its work before with-open closes your reader.


On Jun 21, 2013 6:52 AM, "Jim" > wrote:


Only use 'doseq' when you don't care about the reuturn value. In
other words only for side-effect-y code. Use 'for'  instead...

Jim



On 21/06/13 11:17, Jay C wrote:

Hi, I'm fairly new to Clojure and need help with a problem. The
following function always returns nil, whereas it should return
the value of "line" (which is not nil - I've tested).

(defn find-line-in-output [regex]
(with-open [rdr (reader belarc-output-filepath)]
(doseq [line (line-seq rdr)]
(if (not (nil? (re-find (re-pattern
regex) line)))
line
)
)
)
)

-- 
-- 
You received this message because you are subscribed to the Google

Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com

Note that posts from new members are moderated - please be
patient with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the
Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to clojure+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.




-- 
-- 
You received this message because you are subscribed to the Google

Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com

Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to clojure+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.


--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com.

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




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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: fastest way to produce a PersistentList

[Jim - FooBar();]

On 21/06/13 13:51, Cedric Greevey wrote:

(apply list the-seq) seems to work, but (list* the-seq), oddly, does not.


In most contexts, PersistentLists and seqs are interchangeable. Are 
you needing to use the seq as a stack after constructing it in some 
manner that produces a seq?


No, my requirement is this:

I'm extending a protocol to all major Clojure data-structures very much 
in the same way conj is implemented.  The protocol defines a single fn 
which simply maps a transformer on whatever collection was passed in. 
However, each polymorphic call should not mess with the types. It should 
always return the same type and do the mapping in the most efficient 
manner...


(apply list (map f the-seq)) does work but is not very efficient and I 
think you will get the results reversed...


Jim

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Function returns nil

[Phillip Lord]

I don't think that will work. for is lazy, so by the time it evals, the
code will have dropped out of the scope of with-open.

So:

(defn read-stuff-2 []
  (with-open [r (java.io.BufferedReader.
 (java.io.FileReader. "myfile.txt"))]
(for [line (line-seq r)]
  line)))


fails with an IOException.

So, I think the OP needs:

(defn read-stuff-3 []
  (with-open [r (java.io.BufferedReader.
 (java.io.FileReader. "myfile.txt"))]
(doall
 (for [line (line-seq r)]
   line

or alternatively:

(defn read-stuff-4 []
  (with-open [r (java.io.BufferedReader.
 (java.io.FileReader. "myfile.txt"))]
(for [line (doall (line-seq r))]
  line)))

I really wish there were support for this in clojure.core: both "dofor"
and "domap" would be very useful. Laziness is useful but when working
with Java objecs with state, or anything with dynamic scope liberal use
of doall is necessary which just adds extra brackets. 

Phil



Jim  writes:

> Only use 'doseq' when you don't care about the reuturn value. In other words
> only for side-effect-y code. Use 'for'  instead...
>
> Jim
>
>
>
> On 21/06/13 11:17, Jay C wrote:
>> Hi, I'm fairly new to Clojure and need help with a problem. The following
>> function always returns nil, whereas it should return the value of "line"
>> (which is not nil - I've tested).
>>
>> (defn find-line-in-output [regex]
>> (with-open [rdr (reader belarc-output-filepath)]
>> (doseq [line (line-seq rdr)]
>> (if (not (nil? (re-find (re-pattern regex)
>> line)))
>> line
>> )
>> )
>> )
>> )
>>
>> -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> -- 

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

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

Re: (clojure 1.5.1) Weird performance results when using let versus def for variable

[Jim - FooBar();]

a start would be to set *warn-on-reflection* & *unchecked-math* to 
true...I think you're not properly type-hinting your 'aget' calls. 
areduce is the fastest way to sum up an array of primitives given that 
there are no reflective calls. This takes just over 19 ms on my humble 
machine and don't forget that we 're counting the time it takes to 
populate the array as well...


(defn- array-sum-ints [n]
  (let [^ints a (int-array n)]
(dotimes [n n] (aset a n 1))
(areduce a i ret 0
 (+ ret (aget a i)

Jim


On 21/06/13 13:36, Colin Yates wrote:

Hi all,

I am doing some (naive and trivial) performance tests before deciding 
whether and how to use Clojure for some performance critical number 
cruching and I wanted help understanding the behaviour.


I am defining an array inside a function, setting the contents to be 1 
and then summing them up (by areducing) them (I chose 1 instead of a 
random number for consistency, obviously the contents will be 
different otherwise it would all reduce to (n) :)).  If I 'let' the 
array then it is factors of 10 faster than if I def the array.


The relevant code 
(https://github.com/yatesco/clojure-perf/blob/master/src/inc.clj):


[code]
(ns inc
  (:gen-class))

(defn- inc-atom [n]
  (def x (atom 0))
  (dotimes [n n] (swap! x inc))
  @x)

(defn- array-let [n]
  (let [a (int-array n)]
(dotimes [n n] (aset-int a n 1))
(areduce a i ret 0
 (+ ret (aget a i)

(defn- array-def [n]
  (def a (int-array n))
  (dotimes [n n] (aset-int a n 1))
  (areduce a i ret 0
   (+ ret (aget a i

(defn- run-test [subject n]
  (time (do (def x (subject n)) (println x

(defn -main [& args]
  (let [n 100]
(println "inc atom")
(run-test inc-atom n)
(println "array with let")
(run-test array-let n)
(println "array with def")
(run-test array-def n))
)
[/code]

Interestingly, if I refactored an 'execute-on-array' def which 
array-let and array-def delegated to then they had the same 
performance which seems to imply it is about scoping, but the array in 
both array-let and array-def have exactly the same scope...  Setting 
the autoboxing warning to true didn't point out anything either.


The output (from my VM, so a bit slow):
[code]
inc atom
100
"Elapsed time: 213.214118 msecs"
array with let
100
"Elapsed time: 75.302602 msecs"
array with def
100
"Elapsed time: 12868.970203 msecs"
[/code]

For comparison, the following java code:

[code]
package perf;

public class Inc {
public static void main(String[] args) {
int n = 100;
int counter = 0;
long start = System.currentTimeMillis();
for (int i=0; iSystem.out.println ("Naive " + (end - start) + " ms, counter 
is " + counter);


counter = 0;
int[] arr = new int[n];
start = System.currentTimeMillis();
for (int i=0; iSystem.out.println ("Array " + (end - start) + " ms, counter 
is " + counter);

   }
}
[/code]

produces the (as expected, much faster) results :

[code]
Naive 3 ms, counter is 100
Array 6 ms, counter is 100
[/code]

I am not surprised that the atom/inc takes much longer than 3 ms, but 
I don't understand why the array solution is so much more expensive in 
Clojure?


On a related point - can anyone provide a faster implementation of 
summing up the contents of an array?


A lein project can be found https://github.com/yatesco/clojure-perf, 
'lein uberjar; java -jar target/*.jar should demonstrate the output.


--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com.

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




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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: fastest way to produce a PersistentList

[Cedric Greevey]

(apply list the-seq) seems to work, but (list* the-seq), oddly, does not.


In most contexts, PersistentLists and seqs are interchangeable. Are you
needing to use the seq as a stack after constructing it in some manner that
produces a seq?



On Fri, Jun 21, 2013 at 8:37 AM, Jim - FooBar(); wrote:

> Hi all,
>
> what do you guys do when you want to map a fn over a list but you want to
> produce a list as the result (not vector or lazy-seq). What is the fastest
> way of doing this?
>
> My first attempt was this:
>
> (->> (mapv f coll)
>   rseq ;;reverse fast
>  (into '()))
>
> but I quickly realised that lists do not have transient counterparts.
> Therefore, the call to 'into' will be slow...in addition, I'm performing 2
> passes with this...
>
> any ideas?
>
> Jim
>
> --
> --
> 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+unsubscribe@**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+unsubscribe@**googlegroups.com
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>
>
>

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

Re: Function returns nil

[John D. Hume]

If you use for, which is lazy, wrap it in a doall to force it to do its
work before with-open closes your reader.
On Jun 21, 2013 6:52 AM, "Jim"  wrote:

>  Only use 'doseq' when you don't care about the reuturn value. In other
> words only for side-effect-y code. Use 'for'  instead...
>
> Jim
>
>
>
> On 21/06/13 11:17, Jay C wrote:
>
> Hi, I'm fairly new to Clojure and need help with a problem. The following
> function always returns nil, whereas it should return the value of "line"
> (which is not nil - I've tested).
>
> (defn find-line-in-output [regex]
>> (with-open [rdr (reader belarc-output-filepath)]
>> (doseq [line (line-seq rdr)]
>> (if (not (nil? (re-find (re-pattern regex) line)))
>> line
>> )
>> )
>> )
>> )
>>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

fastest way to produce a PersistentList

[Jim - FooBar();]

Hi all,

what do you guys do when you want to map a fn over a list but you want 
to produce a list as the result (not vector or lazy-seq). What is the 
fastest way of doing this?


My first attempt was this:

(->> (mapv f coll)
  rseq ;;reverse fast
 (into '()))

but I quickly realised that lists do not have transient counterparts. 
Therefore, the call to 'into' will be slow...in addition, I'm performing 
2 passes with this...


any ideas?

Jim

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

(clojure 1.5.1) Weird performance results when using let versus def for variable

[Colin Yates]

Hi all,

I am doing some (naive and trivial) performance tests before deciding 
whether and how to use Clojure for some performance critical number 
cruching and I wanted help understanding the behaviour.

I am defining an array inside a function, setting the contents to be 1 and 
then summing them up (by areducing) them (I chose 1 instead of a random 
number for consistency, obviously the contents will be different otherwise 
it would all reduce to (n) :)).  If I 'let' the array then it is factors of 
10 faster than if I def the array.

The relevant code 
(https://github.com/yatesco/clojure-perf/blob/master/src/inc.clj):

[code]
(ns inc
  (:gen-class))

(defn- inc-atom [n]
  (def x (atom 0))
  (dotimes [n n] (swap! x inc))
  @x)

(defn- array-let [n]
  (let [a (int-array n)]
(dotimes [n n] (aset-int a n 1))
(areduce a i ret 0
 (+ ret (aget a i)

(defn- array-def [n]
  (def a (int-array n))
  (dotimes [n n] (aset-int a n 1))
  (areduce a i ret 0
   (+ ret (aget a i

(defn- run-test [subject n]
  (time (do (def x (subject n)) (println x

(defn -main [& args]
  (let [n 100]
(println "inc atom")
(run-test inc-atom n)
(println "array with let")
(run-test array-let n)
(println "array with def")
(run-test array-def n))
)
[/code]

Interestingly, if I refactored an 'execute-on-array' def which array-let 
and array-def delegated to then they had the same performance which seems 
to imply it is about scoping, but the array in both array-let and array-def 
have exactly the same scope...  Setting the autoboxing warning to true 
didn't point out anything either.

The output (from my VM, so a bit slow):
[code]
inc atom
100
"Elapsed time: 213.214118 msecs"
array with let
100
"Elapsed time: 75.302602 msecs"
array with def
100
"Elapsed time: 12868.970203 msecs"
[/code]

For comparison, the following java code:

[code]
package perf;

public class Inc {
public static void main(String[] args) {
int n = 100;
int counter = 0;
long start = System.currentTimeMillis();
for (int i=0; ihttps://github.com/yatesco/clojure-perf, 'lein 
uberjar; java -jar target/*.jar should demonstrate the output.

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

Re: Function returns nil

[Alan Forrester]

On 21 June 2013 11:17, Jay C  wrote:
> Hi, I'm fairly new to Clojure and need help with a problem. The following
> function always returns nil, whereas it should return the value of "line"
> (which is not nil - I've tested).
>
>> (defn find-line-in-output [regex]
>> (with-open [rdr (reader belarc-output-filepath)]
>> (doseq [line (line-seq rdr)]
>> (if (not (nil? (re-find (re-pattern regex) line)))
>> line
>> )
>> )
>> )
>> )

doseq returns nil, it's for side effecting code. If you want a return
value you should use loop or something else that doesn't have side
effects.

Alan

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

Re: Function returns nil

[Jim]

Only use 'doseq' when you don't care about the reuturn value. In other 
words only for side-effect-y code. Use 'for'  instead...


Jim



On 21/06/13 11:17, Jay C wrote:
Hi, I'm fairly new to Clojure and need help with a problem. The 
following function always returns nil, whereas it should return the 
value of "line" (which is not nil - I've tested).


(defn find-line-in-output [regex]
(with-open [rdr (reader belarc-output-filepath)]
(doseq [line (line-seq rdr)]
(if (not (nil? (re-find (re-pattern regex)
line)))
line
)
)
)
)

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com.

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




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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Function returns nil

[Jay C]

Hi, I'm fairly new to Clojure and need help with a problem. The following 
function always returns nil, whereas it should return the value of "line" 
(which is not nil - I've tested).

(defn find-line-in-output [regex]
> (with-open [rdr (reader belarc-output-filepath)]
> (doseq [line (line-seq rdr)]
> (if (not (nil? (re-find (re-pattern regex) line)))
> line
> )
> )
> )
> )
>

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