Re: [GSoC 2013] core.logic CLP(Prob)

[Maximilien Rzepka]

For the sake of completion  ;)

Nils Bertschinger's work 
https://github.com/bertschi/ProbClojureNice 
https://groups.google.com/forum/?fromgroups=#!topic/clojure/9NhsFga4D9s

Le mercredi 24 avril 2013 11:34:14 UTC+2, Zack Maril a écrit :
>
> Lately, I've been on a bit of a jag into probabilistic programming with 
> Clojure, specifically embedding Church inside of Clojure. The results so 
> far are promising from a syntactic level, but, like David said, getting it 
> to actually work is another matter entirely. I wanted to share what I've 
> been able to get working so far and some of the potential challenges of 
> embedding Church in Clojure. 
>
> https://gist.github.com/zmaril/5447488
>
> The above gist is a self contained Clojure program that implements, among 
> other things, `query-by-rejection` and `flip`. With these two functions, we 
> can already do most of what Church seems to do. What's missing from 
> a functionality standpoint is support for various distributions and some 
> useful functions related to tolerance (and, of course, a good MCMC/Gibbs 
> implementation). What's been gained is, via some careful macro writing, the 
> ability to reuse code, specifically to reuse memoized functions. 
>
> One of the key ideas behind Church is that memoization allows one to 
> express complicated scenarios very concisely. So, to code up a randomized 
> persistent trait (like a person's eye color), you simply define a memoized 
> function that takes in a person and returns their eye color. Every time a 
> new world is generated, the memoized function gets recreated. But within 
> the world (or current experiment), the trait persists and can be referenced 
> again in various places without too much hassle.  Note that a new memoized 
> function must be created for each experiment, i.e. you can't just memoize 
> the function outside the query and bring that back in. Within the gist 
> above, binding is used to carefully rebind any function provided in the 
> :memobound clause for each experiment. By declaring a var to be dynamic, we 
> can write queries that are pretty short but all rely on the same logic. 
> From a syntactic standpoint, it took about one evening of work to cut down 
> the length of most of the Church examples by at least half. 
>
> From a speed standpoint, Church is way, way ahead of the above. Sampling 
> via rejection is quite slow compared to modern methods like MCMC or Gibbs. 
> It might not even be possible to do the dynamic rebinding of memoized 
> functions mentioned above and get as fast as Church is. I really don't 
> know. Here's one of the first papers on Church:
> http://www.stanford.edu/~ngoodman/papers/churchUAI08_rev2.pdf
>
> The paper is about five years old now, but section 4.1 goes into how 
> Church was first implemented with a MCMC. The key idea they introduce here 
> is the computation trace. I won't try to summarize it here because I don't 
> fully understand it yet. If it means what I think it means though, then it 
> should be possible to build and keep track of the computation trace thanks 
> to the JVM and Clojure. My intuition says that a very dedicated student 
> could probably produce a Clojure library to catch Church in terms of speed 
> by the end of the summer, simply by emulating what they have done and 
> letting pmap take care of the rest.  
> -Zack
>
> On Wednesday, April 24, 2013 12:48:56 AM UTC+4, David Nolen wrote:
>>
>> On Tue, Apr 23, 2013 at 2:10 PM, Radosław Piliszek wrote:
>>
>>> 1) Is this place the best to discuss this?
>>>
>>
>> Yes.
>>  
>>
>>> 2) Are there some set goals that CLP(Prob) should achieve? (,,Basic 
>>> support of CLP(Prob).'' does not express it too well! :-P )
>>>
>>
>> This seems like a pretty challenging one as there are a variety of 
>> possible approaches. Basic support for CLP(Prob) could very well mean 
>> *several* prototypes. That said the probabilistic Prolog variants are 
>> probably worthy of the most study as core.logic is closest to that model.
>>  
>>
>>> 3) Is there any API sketch that should be followed? Is it still yet to 
>>> be discussed? And, most importantly, how would you see CLP(Prob) fit in 
>>> core.logic's ecosystem?
>>>
>>
>> There is no API sketch. It's extremely important to survey the links, try 
>> out existing implementations, assess their advantages / disadvantages and 
>> devise a syntax (or several) that works reasonably well with what we've 
>> already established in core.logic. 
>>
>> Of the projects listed this is probably the most experimental and 
>> research-y. I think if anyone seriously wants to take this on they have to 
>> be extremely focused / self-directed and be willing to put in a 
>> *considerable* amount of time. I'm of course willing to help in whatever 
>> way I can as far as implementation & integration approach - but it will be 
>> a big learning experience for me as well!
>>
>> David
>>
>

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

[ANN] A github issues app/bot to better serve users

[Gabriel Horner]

Hi,
I thought I'd share a github issues app/bot I wrote to make my life easier 
as an author and hopefully my users: 
https://github.com/cldwalker/gh-active-issues#readme

The app does two main things:

* It lists issues the maintainer considers active. See my list at 
https://gh-active-issues.herokuapp.com/
* It auto-comments soon after an issue/pull request is opened with a link 
to the issue on the maintainer's issues list.
   Feel free to open an issue to see it in action - 
https://github.com/cldwalker/gh-active-issues/issues

To try with your repositories, configure it, 
https://github.com/cldwalker/gh-active-issues#configuration, 
and push your fork to heroku.

Curious to hear what other issue workflows maintainers have for multiple 
repositories. Feedback appreciated from users and maintainers alike.

Thanks,
Gabriel

-- 
-- 
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: Do functions never get inlined by jvm?

[u1204]

...0? :-)

Tim Daly

-- 
-- 
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: New CSS library - Garden

[Joel Holdbrooks]

It's funny you should bring that up! I've actually been working on
extracting the grid system from Bootstrap and modular scale from
Foundation. But it's mostly been tinkering.

*  I am sorely tempted to give this a try.*

Please do! If I come up with something I'll be sure to share a Gist.


On Thu, Apr 25, 2013 at 3:27 PM, Clinton Dreisbach wrote:

> One interesting thing you could do, given both Garden and
> ClojureScript, is package CSS frameworks like Twitter Bootstrap or
> Zurb Foundation as a Clojure library. I am sorely tempted to give this
> a try.
>
> On Thu, Apr 25, 2013 at 6:12 PM, Joel Holdbrooks 
> wrote:
> > Murtaza,
> >
> > Thanks for having a look at the library. I'll try to answer you
> questions as
> > best as I can.
> >
> >
> > How does Garden compare to other pre processors such as sass and less?
> >
> > There are some similarities with Garden and other CSS preprocessors. I've
> > tried to bring over the ones I found most useful when using them. Nested
> > selectors and declarations, parent selector references, and unit
> arithmetic
> > are all currently available to stylesheet authors.
> >
> > The big difference and, in my opinion, the big win is you can build your
> > stylesheets with regular Clojure. This gives you a lot of power and
> freedom
> > you won't find anywhere else (AFAIK). To name just a few benefits:
> >
> > There's no file parsing or interpretation step. It's just data
> > transformation.
> > There's no need for any sort of special @mixin syntax or macros, you can
> use
> > Clojure function.
> > There's no need for an @include directive thanks to clojure namespaces.
> This
> > can help you organize your stylesheet in ways (I think) are much cleaner
> and
> > less surprising than SASS and other preprocessors.
> > Thanks to Clojure, Garden (potentially) has clearer syntax than CSS
> which,
> > if you look closely, can be pretty random in some places.
> >
> > WIth regard to the third point, if you've ever tried using the SMACSS
> > approach to stylesheet authoring with a preprocessor like SASS, you can
> end
> > up with an explosion of files and tons of @include directives. It's not
> fun,
> > it's hard to manage, and it's difficult to see where code is coming from
> -
> > especially when using 3rd-party libraries.
> >
> > Also can I use it in my clojurescript projects ? I mean does it have any
> > java lib dependencies that would prevent it?
> >
> > It does have one small dependency on java.net.URI but I need some time to
> > think about whether or not it would be worth dropping. As far as using it
> > from a ClojureScript project, what sort of use case are you considering?
> >
> > What is the workflow when using Garden?
> >
> > My experience using Garden is probably close to others at this point.
> It's
> > kind of funny in that regard. I'm building a tool and at the same time am
> > learning how to use it. Personally, I create a namespace for my "core"
> > stylesheets and separate namespaces for things like utilities and so
> forth
> > (ie. (ns me.css (:require [me.css.button :as button])) . Then I have a
> call
> > to function that compiles and saves the stylesheet at the bottom of the
> > "core" stylesheets. Since I develop with Emacs and nREPL this means all I
> > have to do is reload the file and the CSS is "refreshed".
> >
> > It isn't the best approach, but Garden is still very young and I haven't
> > thought about how a standardize the build process. But I would
> definitely be
> > open to any thoughts regarding that. A Leiningen plugin would be awesome!
> >
> >
> > I hope these answers are helpful. Please continue to experiment with the
> > library and express your thoughts!
> >
> > Thanks,
> >
> > Joel
> >
> >
> > On Wed, Apr 24, 2013 at 6:44 PM, Murtaza Husain
> >  wrote:
> >>
> >> Joel,
> >>
> >> Thanks for the lib. Its great and I plan to use it in my projects.
> >>
> >> How does Garden compare to other pre processors such as sass and less ?
> >>
> >> Also can I use it in my clojurescript projects ? I mean does it have any
> >> java lib dependencies that would prevent it?
> >>
> >> What is the workflow when using Garden ? If I am using Sass, I would
> >> create a .scss file, and the sass daemon would watch over any changes
> to the
> >> file and compile it to .css.
> >>
> >> As I understand garden is generating css when called with the fn/macro
> >> (css [...]). Would it make sense to have a similar workflow like above;
> >> where a leiningen plugin watches for any .garden files and compiles
> them to
> >> .css files ? Or is there a better workflow that I am missing?
> >>
> >> Thanks,
> >> Murtaza
> >>
> >>
> >> On Tuesday, April 23, 2013 2:42:55 AM UTC+5:30, Joel Holdbrooks wrote:
> >>>
> >>> As of today, Garden is officially out of alpha and in to beta!
> >>>
> >>> The library now sports media queries (via meta data) and parent
> selector
> >>> references (ie. "&hover"). With these new features it is now possible
> to
> >>> build more sophisticated stylesh

Re: New CSS library - Garden

[Clinton Dreisbach]

One interesting thing you could do, given both Garden and
ClojureScript, is package CSS frameworks like Twitter Bootstrap or
Zurb Foundation as a Clojure library. I am sorely tempted to give this
a try.

On Thu, Apr 25, 2013 at 6:12 PM, Joel Holdbrooks  wrote:
> Murtaza,
>
> Thanks for having a look at the library. I'll try to answer you questions as
> best as I can.
>
>
> How does Garden compare to other pre processors such as sass and less?
>
> There are some similarities with Garden and other CSS preprocessors. I've
> tried to bring over the ones I found most useful when using them. Nested
> selectors and declarations, parent selector references, and unit arithmetic
> are all currently available to stylesheet authors.
>
> The big difference and, in my opinion, the big win is you can build your
> stylesheets with regular Clojure. This gives you a lot of power and freedom
> you won't find anywhere else (AFAIK). To name just a few benefits:
>
> There's no file parsing or interpretation step. It's just data
> transformation.
> There's no need for any sort of special @mixin syntax or macros, you can use
> Clojure function.
> There's no need for an @include directive thanks to clojure namespaces. This
> can help you organize your stylesheet in ways (I think) are much cleaner and
> less surprising than SASS and other preprocessors.
> Thanks to Clojure, Garden (potentially) has clearer syntax than CSS which,
> if you look closely, can be pretty random in some places.
>
> WIth regard to the third point, if you've ever tried using the SMACSS
> approach to stylesheet authoring with a preprocessor like SASS, you can end
> up with an explosion of files and tons of @include directives. It's not fun,
> it's hard to manage, and it's difficult to see where code is coming from -
> especially when using 3rd-party libraries.
>
> Also can I use it in my clojurescript projects ? I mean does it have any
> java lib dependencies that would prevent it?
>
> It does have one small dependency on java.net.URI but I need some time to
> think about whether or not it would be worth dropping. As far as using it
> from a ClojureScript project, what sort of use case are you considering?
>
> What is the workflow when using Garden?
>
> My experience using Garden is probably close to others at this point. It's
> kind of funny in that regard. I'm building a tool and at the same time am
> learning how to use it. Personally, I create a namespace for my "core"
> stylesheets and separate namespaces for things like utilities and so forth
> (ie. (ns me.css (:require [me.css.button :as button])) . Then I have a call
> to function that compiles and saves the stylesheet at the bottom of the
> "core" stylesheets. Since I develop with Emacs and nREPL this means all I
> have to do is reload the file and the CSS is "refreshed".
>
> It isn't the best approach, but Garden is still very young and I haven't
> thought about how a standardize the build process. But I would definitely be
> open to any thoughts regarding that. A Leiningen plugin would be awesome!
>
>
> I hope these answers are helpful. Please continue to experiment with the
> library and express your thoughts!
>
> Thanks,
>
> Joel
>
>
> On Wed, Apr 24, 2013 at 6:44 PM, Murtaza Husain
>  wrote:
>>
>> Joel,
>>
>> Thanks for the lib. Its great and I plan to use it in my projects.
>>
>> How does Garden compare to other pre processors such as sass and less ?
>>
>> Also can I use it in my clojurescript projects ? I mean does it have any
>> java lib dependencies that would prevent it?
>>
>> What is the workflow when using Garden ? If I am using Sass, I would
>> create a .scss file, and the sass daemon would watch over any changes to the
>> file and compile it to .css.
>>
>> As I understand garden is generating css when called with the fn/macro
>> (css [...]). Would it make sense to have a similar workflow like above;
>> where a leiningen plugin watches for any .garden files and compiles them to
>> .css files ? Or is there a better workflow that I am missing?
>>
>> Thanks,
>> Murtaza
>>
>>
>> On Tuesday, April 23, 2013 2:42:55 AM UTC+5:30, Joel Holdbrooks wrote:
>>>
>>> As of today, Garden is officially out of alpha and in to beta!
>>>
>>> The library now sports media queries (via meta data) and parent selector
>>> references (ie. "&hover"). With these new features it is now possible to
>>> build more sophisticated stylesheets bringing us a step closer to having a
>>> viable CSS alternative in Clojure.
>>>
>>> Over the course of the next few weeks, I plan to continue improving the
>>> library by adding "missing" features and functions to make the library as
>>> powerful as possible when it's release as 0.1.0 stable.
>>>
>>> Now more than ever, I would like to encourage others in the community to
>>> reach out with suggestions and code review. This my first "real" Clojure
>>> library and after only six months with the language I'm sure it could
>>> benefit greatly from both of these things.
>>
>> --
>> --

Re: New CSS library - Garden

[Joel Holdbrooks]

Murtaza,

Thanks for having a look at the library. I'll try to answer you questions
as best as I can.


*How does Garden compare to other pre processors such as sass and less?*
*
*
There are some similarities with Garden and other CSS preprocessors. I've
tried to bring over the ones I found most useful when using them. Nested
selectors and declarations, parent selector references, and unit arithmetic
are all currently available to stylesheet authors.

The big difference and, in my opinion, the big win is you can build your
stylesheets with regular Clojure. This gives you a lot of power and freedom
you won't find anywhere else (AFAIK). To name just a few benefits:

   - There's no file parsing or interpretation step. It's just data
   transformation.
   - There's no need for any sort of special *@mixin* syntax or macros, you
   can use Clojure function.
   - There's no need for an *@include* directive thanks to clojure
   namespaces. This can help you organize your stylesheet in ways (I think)
   are much cleaner and less surprising than SASS and other preprocessors.
   - Thanks to Clojure, Garden (potentially) has clearer syntax than CSS
   which, if you look closely, can be pretty random in some places.

WIth regard to the third point, if you've ever tried using the SMACSS
approach to stylesheet authoring with a preprocessor like SASS, you can end
up with an explosion of files and tons of *@include* directives. It's not
fun, it's hard to manage, and it's difficult to see where code is coming
from - especially when using 3rd-party libraries.

*Also can I use it in my clojurescript projects ? I mean does it have any
java lib dependencies that would prevent it?*
*
*
It does have one small dependency on java.net.URI but I need some time to
think about whether or not it would be worth dropping. As far as using it
from a ClojureScript project, what sort of use case are you considering?

*What is the workflow when using Garden?*
*
*
My experience using Garden is probably close to others at this point. It's
kind of funny in that regard. I'm building a tool and at the same time am
learning how to use it. Personally, I create a namespace for my "core"
stylesheets and separate namespaces for things like utilities and so forth
(ie. *(ns me.css (:require [me.css.button :as button])*) . Then I have a
call to function that compiles and saves the stylesheet at the bottom of
the "core" stylesheets. Since I develop with Emacs and nREPL this means all
I have to do is reload the file and the CSS is "refreshed".

It isn't the best approach, but Garden is still very young and I haven't
thought about how a standardize the build process. But I would definitely
be open to any thoughts regarding that. A Leiningen plugin would be awesome!


I hope these answers are helpful. Please continue to experiment with the
library and express your thoughts!

Thanks,

Joel


On Wed, Apr 24, 2013 at 6:44 PM, Murtaza Husain <
murtaza.hus...@sevenolives.com> wrote:

> Joel,
>
> Thanks for the lib. Its great and I plan to use it in my projects.
>
> How does Garden compare to other pre processors such as sass and less ?
>
> Also can I use it in my clojurescript projects ? I mean does it have any
> java lib dependencies that would prevent it?
>
> What is the workflow when using Garden ? If I am using Sass, I would
> create a .scss file, and the sass daemon would watch over any changes to
> the file and compile it to .css.
>
> As I understand garden is generating css when called with the fn/macro
> (css [...]). Would it make sense to have a similar workflow like above;
> where a leiningen plugin watches for any .garden files and compiles them to
> .css files ? Or is there a better workflow that I am missing?
>
> Thanks,
> Murtaza
>
>
> On Tuesday, April 23, 2013 2:42:55 AM UTC+5:30, Joel Holdbrooks wrote:
>>
>> As of today, Garden is officially out of alpha and in to beta!
>>
>> The library now sports media 
>> queries (via
>> meta data) and parent selector 
>> references 
>> (ie.
>> "&hover"). With these new features it is now possible to build more
>> sophisticated stylesheets bringing us a step closer to having a viable CSS
>> alternative in Clojure.
>>
>> Over the course of the next few weeks, I plan to continue improving the
>> library by adding "missing" features and functions to make the library as
>> powerful as possible when it's release as 0.1.0 stable.
>>
>> Now more than ever, I would like to encourage others in the community to
>> reach out with suggestions and code review. This my first "real" Clojure
>> library and after only six months with the language I'm sure it could
>> benefit greatly from both of these things.
>>
>  --
> --
> 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

Re: core.logic: Strange behaviour when using featurec with nested feature map (bug?).

[David Nolen]

Looks like a featurec bug, please file a ticket
http://dev.clojure.org/jira/browse/LOGIC

Thanks!
David


On Thu, Apr 25, 2013 at 5:53 PM, Martin Forsgren
wrote:

> Hi!
>
> I noticed something strange when using featurec with a nested feature map(I'm 
> using core.logic 0.8.3).
> This works as expected:
> (run* [x y]
>   (featurec x {:a {:b 1}})
>   (== y {:b 1})
>   (== x {:a y}))
> and returns:
> ([{:a {:b 1}} {:b 1}])
>
> But with the last two goals swapped I get an exception:
> (run* [x y]
>   (featurec x {:a {:b 1}})
>   (== x {:a y})
>   (== y {:b 1}))
> Throws:
> Exception clojure.core.logic.PMap@3c6f0bed is non-storable
> clojure.core.logic.LVar (logic.clj:647)
> clojure.core.logic/unify (logic.clj:231)
> clojure.core.logic/unify-with-pmap* (logic.clj:2601)
> clojure.core.logic.PMap (logic.clj:2614)
> clojure.core.logic/unify (logic.clj:232)
> clojure.core.logic/==/fn--2819 (logic.clj:1135)
> clojure.core.logic/composeg/fn--2745 (logic.clj:1029)
> clojure.core.logic/-featurec/reify--3655 (logic.clj:2646)
> clojure.core.logic/composeg/fn--2745 (logic.clj:1029)
> clojure.core.logic/composeg/fn--2745 (logic.clj:1030)
> clojure.core.logic/run-constraint/fn--3431 (logic.clj:2184)
> clojure.core.logic/fix-constraints (logic.clj:2211)
>
> I get the same exception when (== y {:b 1}) is left out:
> (run* [x y]
>   (featurec x {:a {:b 1}})
>   (== x {:a y}))
>
> Any ideas why this is happening?
>
> - Martin
>
> --
> --
> 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: merge nested maps

[Stuart Sierra]

Here's a way to do it from the Pedestal demo source 
code
:

(defn deep-merge
  "Recursively merges maps. If keys are not maps, the last value wins."
  [& vals]
  (if (every? map? vals)
(apply merge-with deep-merge vals)
(last vals)))

-S



On Thursday, April 25, 2013 4:41:33 PM UTC-4, Joachim De Beule wrote:
>
> Hi list,
>
> I was searching for an "easy" way to combined nested maps, e.g. as in 
>
> (combine {:foo {:bar "baz"}} {:foo {:x "y"}})
> => {:foo {:bar "baz", :x "y"}}
>
> I would expect that there is some core map operation to do this, but 
> neither merge nor unify work as they simply return {:foo {:x "y"}}, and I 
> don't see anything else. Am I missing something?
>
> Joachim.
>

-- 
-- 
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: merge nested maps

[Jorge Urdaneta]

It was fun to try a naive implementation

(defn combine [m1 m2]
  (let [mm1 (transient m1)]
(do
  (doseq [k (keys m2)]
(if (contains? m1 k)
  (assoc! mm1 k (conj (mm1 k) (m2 k)))
  (assoc! mm1 k (m2 k
  (persistent! mm1



On 25/04/13 16:29, Cedric Greevey wrote:
Seems you want a cross between update-in and merge. Maybe something 
like this?


(defn combine
  "Merge maps, recursively merging nested maps whose keys collide."
  ([] {})
  ([m] m)
  ([m1 m2]
(reduce (fn [m1 [k2 v2]]
  (if-let [v1 (get m1 k2)]
(if (and (map? v1) (map? v2))
  (assoc m1 k2 (combine v1 v2))
  (assoc m1 k2 v2))
(assoc m1 k2 v2)))
m1 m2))
  ([m1 m2 & more]
(apply combine (combine m1 m2) more)))

(warning: scarcely tested much)



On Thu, Apr 25, 2013 at 4:41 PM, Joachim De Beule 
mailto:joachim.de.be...@gmail.com>> wrote:


Hi list,

I was searching for an "easy" way to combined nested maps, e.g. as in

(combine {:foo {:bar "baz"}} {:foo {:x "y"}})
=> {:foo {:bar "baz", :x "y"}}

I would expect that there is some core map operation to do this,
but neither merge nor unify work as they simply return {:foo {:x
"y"}}, and I don't see anything else. Am I missing something?

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





--
Jorge Urdaneta

--
--
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: merge nested maps

[Cedric Greevey]

Seems you want a cross between update-in and merge. Maybe something like
this?

(defn combine
  "Merge maps, recursively merging nested maps whose keys collide."
  ([] {})
  ([m] m)
  ([m1 m2]
(reduce (fn [m1 [k2 v2]]
  (if-let [v1 (get m1 k2)]
(if (and (map? v1) (map? v2))
  (assoc m1 k2 (combine v1 v2))
  (assoc m1 k2 v2))
(assoc m1 k2 v2)))
m1 m2))
  ([m1 m2 & more]
(apply combine (combine m1 m2) more)))

(warning: scarcely tested much)



On Thu, Apr 25, 2013 at 4:41 PM, Joachim De Beule <
joachim.de.be...@gmail.com> wrote:

> Hi list,
>
> I was searching for an "easy" way to combined nested maps, e.g. as in
>
> (combine {:foo {:bar "baz"}} {:foo {:x "y"}})
> => {:foo {:bar "baz", :x "y"}}
>
> I would expect that there is some core map operation to do this, but
> neither merge nor unify work as they simply return {:foo {:x "y"}}, and I
> don't see anything else. Am I missing something?
>
> Joachim.
>
> --
> --
> 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: merge nested maps

[Michael Gardner]

On Apr 25, 2013, at 15:41 , Joachim De Beule  wrote:

> I was searching for an "easy" way to combined nested maps, e.g. as in 
> 
> (combine {:foo {:bar "baz"}} {:foo {:x "y"}})
> => {:foo {:bar "baz", :x "y"}}

user=> (merge-with merge {:foo {:bar "baz"}} {:foo {:x "y"}})
{:foo {:x "y", :bar "baz"}}

If you need to support more than one level of nesting, you could try something 
like:

(defn combine [& maps]
(apply merge-with combine maps))

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

merge nested maps

[Joachim De Beule]

Hi list,

I was searching for an "easy" way to combined nested maps, e.g. as in 

(combine {:foo {:bar "baz"}} {:foo {:x "y"}})
=> {:foo {:bar "baz", :x "y"}}

I would expect that there is some core map operation to do this, but 
neither merge nor unify work as they simply return {:foo {:x "y"}}, and I 
don't see anything else. Am I missing something?

Joachim.

-- 
-- 
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: Do functions never get inlined by jvm?

[Softaddicts]

I am not defending it at all cost. Just tired of earing you whining the same
complaint in around 70% of your posts and in some cases, like this one,
unrelated with the original issue.

Like if "correct" documentation could replace self acquired knowledge about how 
things
work. This is why civilisations decline, more people use technology but less and
less understand it. It's not just in Star Wars movies that this happens.

Do not generalize, Gretzky is Mr. Canada Nice Guy... were are not all like him
over here:)

Post whatever you want, I will now be mute, this thread is going nowhere.
Go get your diaper changed, the air is getting thick :)

Luc P.

> 2013/4/25 Softaddicts 
> 
> > May I suggest you an upgrade  ?
> >
> > http://www.ehow.com/how_6949396_record-78-vinyl-records-cd.html
> >
> 
> Ah, a batch of fresh preaching from Mr. Defend Clojure/core At All Costs.
> 
> Best Canadian export since Wayne Gretzky!
> -- 
> 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.
> 
> 
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
-- 
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: Do functions never get inlined by jvm?

[gaz jones]

There seems to be some rule that given sufficient time and enough
participants, all threads deteriorate into an argument about the current
state of clojure documentation and a huge post from Tim Daly regarding
literate programming in 3...2...1...


On Thu, Apr 25, 2013 at 2:23 PM, Gary Trakhman wrote:

> Good vinyls are considered higher quality by audiophiles, because there
> are less stages in between the mastering and amplification.  There is more
> potential of better performance.
>
> It can be considered a real-world case of inlining.
>
>
> On Thu, Apr 25, 2013 at 3:16 PM, Softaddicts 
> wrote:
>
>> May I suggest you an upgrade  ?
>>
>> http://www.ehow.com/how_6949396_record-78-vinyl-records-cd.html
>>
>> > 2013/4/25 Softaddicts 
>> >
>> > > Of course my answer comes in total antagonism with your usual position
>> > > about the
>> > > bad state of the existing documentation which is incomplete, wrong,
>> ...
>> > > and so forth.
>> > >
>> > Your reaction does not suprise me, your behavior is quite predictable.
>> > > Like an old vinyl record with all these scratches being played over
>> and
>> > > over
>> > > again.
>> > >
>> > >
>> > Nothing has changed w.r.t. Clojure/core's attitude towards documentation
>> > and making it easy
>> > for other people to contribute documentation improvements that are
>> rapidly
>> > integrated instead of
>> > gathering dust in JIRA for many months.
>> >
>> > Why would I suddenly start singing praises to something that is broken
>> and
>> > does not change?
>> >
>> > Sorry pal, someone has to periodically remind those in control of
>> Clojure
>> > that we are exactly
>> > where we were years ago. And that the entire community has to put up
>> with
>> > this.
>> >
>> >
>> > > Definline may be tagged as experimental but defrecord, defprotocol,
>> ...
>> > > are marked
>> > > as being in alpha stage. Does this prevents you from using them ?
>> > >
>> >
>> > Those are mentioned in every book and are widely used. It would be
>> crazy to
>> > break
>> > those by now. Makes a bit of difference when it comes to recommending
>> > features to people, don't you
>> > think?
>> > --
>> > 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.
>> >
>> >
>> >
>> --
>> Softaddicts sent by ibisMail from my ipad!
>>
>> --
>> --
>> 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
---

Re: Do functions never get inlined by jvm?

[JeremyS]

Hi guys,

Maybe we'll see some change in the future, Atlas 
already 
seems to be interesting. I think there is also a huge potential with Codeq. 
>From what I gather Codeq only
parse thing looking like (defsomething ) for now. But we can imagine that 
if we augment the capability of it, we could extract docstrings, symbols 
utilisation to 
connect the different parts of a code base, etc... I think there might be a 
Google Summer of Code project like that.

The cool things about Codeq are:

   -  it doesn't need anybody "in control" of Clojure to work on such a 
   project
   - we can add to the Codeq schema other documentation attributes than 
   docstrings to replace broken or insufficient documentation (still on our 
   own)
   - it surely as great potential to explain the code base of a project 
   with the fact that it can highlight evolution of the code at a higher level 
   than just git diffs
   - and it could be run on the core clojure libraries of course

And I don't think that I thought of all the things we could do about it but 
I think it might be the new way to generate documentation for code, a 
highly queryable one at that. 
The only issue, it's not done yet... :-D 

Cheers

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

Re: Do functions never get inlined by jvm?

[Michael Klishin]

2013/4/25 Softaddicts 

> May I suggest you an upgrade  ?
>
> http://www.ehow.com/how_6949396_record-78-vinyl-records-cd.html
>

Ah, a batch of fresh preaching from Mr. Defend Clojure/core At All Costs.

Best Canadian export since Wayne Gretzky!
-- 
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: Do functions never get inlined by jvm?

[Gary Trakhman]

Good vinyls are considered higher quality by audiophiles, because there are
less stages in between the mastering and amplification.  There is more
potential of better performance.

It can be considered a real-world case of inlining.


On Thu, Apr 25, 2013 at 3:16 PM, Softaddicts wrote:

> May I suggest you an upgrade  ?
>
> http://www.ehow.com/how_6949396_record-78-vinyl-records-cd.html
>
> > 2013/4/25 Softaddicts 
> >
> > > Of course my answer comes in total antagonism with your usual position
> > > about the
> > > bad state of the existing documentation which is incomplete, wrong, ...
> > > and so forth.
> > >
> > Your reaction does not suprise me, your behavior is quite predictable.
> > > Like an old vinyl record with all these scratches being played over and
> > > over
> > > again.
> > >
> > >
> > Nothing has changed w.r.t. Clojure/core's attitude towards documentation
> > and making it easy
> > for other people to contribute documentation improvements that are
> rapidly
> > integrated instead of
> > gathering dust in JIRA for many months.
> >
> > Why would I suddenly start singing praises to something that is broken
> and
> > does not change?
> >
> > Sorry pal, someone has to periodically remind those in control of Clojure
> > that we are exactly
> > where we were years ago. And that the entire community has to put up with
> > this.
> >
> >
> > > Definline may be tagged as experimental but defrecord, defprotocol, ...
> > > are marked
> > > as being in alpha stage. Does this prevents you from using them ?
> > >
> >
> > Those are mentioned in every book and are widely used. It would be crazy
> to
> > break
> > those by now. Makes a bit of difference when it comes to recommending
> > features to people, don't you
> > think?
> > --
> > 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.
> >
> >
> >
> --
> Softaddicts sent by ibisMail from my ipad!
>
> --
> --
> 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: Do functions never get inlined by jvm?

[Softaddicts]

May I suggest you an upgrade  ?

http://www.ehow.com/how_6949396_record-78-vinyl-records-cd.html

> 2013/4/25 Softaddicts 
> 
> > Of course my answer comes in total antagonism with your usual position
> > about the
> > bad state of the existing documentation which is incomplete, wrong, ...
> > and so forth.
> >
> Your reaction does not suprise me, your behavior is quite predictable.
> > Like an old vinyl record with all these scratches being played over and
> > over
> > again.
> >
> >
> Nothing has changed w.r.t. Clojure/core's attitude towards documentation
> and making it easy
> for other people to contribute documentation improvements that are rapidly
> integrated instead of
> gathering dust in JIRA for many months.
> 
> Why would I suddenly start singing praises to something that is broken and
> does not change?
> 
> Sorry pal, someone has to periodically remind those in control of Clojure
> that we are exactly
> where we were years ago. And that the entire community has to put up with
> this.
> 
> 
> > Definline may be tagged as experimental but defrecord, defprotocol, ...
> > are marked
> > as being in alpha stage. Does this prevents you from using them ?
> >
> 
> Those are mentioned in every book and are widely used. It would be crazy to
> break
> those by now. Makes a bit of difference when it comes to recommending
> features to people, don't you
> think?
> -- 
> 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.
> 
> 
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
-- 
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: Do functions never get inlined by jvm?

[Michael Klishin]

2013/4/25 Softaddicts 

> Of course my answer comes in total antagonism with your usual position
> about the
> bad state of the existing documentation which is incomplete, wrong, ...
> and so forth.
>
Your reaction does not suprise me, your behavior is quite predictable.
> Like an old vinyl record with all these scratches being played over and
> over
> again.
>
>
Nothing has changed w.r.t. Clojure/core's attitude towards documentation
and making it easy
for other people to contribute documentation improvements that are rapidly
integrated instead of
gathering dust in JIRA for many months.

Why would I suddenly start singing praises to something that is broken and
does not change?

Sorry pal, someone has to periodically remind those in control of Clojure
that we are exactly
where we were years ago. And that the entire community has to put up with
this.


> Definline may be tagged as experimental but defrecord, defprotocol, ...
> are marked
> as being in alpha stage. Does this prevents you from using them ?
>

Those are mentioned in every book and are widely used. It would be crazy to
break
those by now. Makes a bit of difference when it comes to recommending
features to people, don't you
think?
-- 
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: Do functions never get inlined by jvm?

[Softaddicts]

Well you looked quite outraged that it could not be found easily. I 
demonstrated 
that doc strings can be easily searched.

Of course my answer comes in total antagonism with your usual position about 
the 
bad state of the existing documentation which is incomplete, wrong, ... and so 
forth.

Your reaction does not suprise me, your behavior is quite predictable.
Like an old vinyl record with all these scratches being played over and over
again.

Definline may be tagged as experimental but defrecord, defprotocol, ... are 
marked
as being in alpha stage. Does this prevents you from using them ?

I hope so, especially in production.

Luc P.


> 2013/4/25 Softaddicts 
> 
> > Inlining is a concept that existed for more than 40 years in many
> > programming
> > languages. It's not anything new.
> >
> 
> The OP probably know what inlining is because, hm, the subject has that
> word.
> Then she is recommended to use something that only technically has
> documentation (and is marked as experimental) and is not known or used by
> many.
> 
> I've pointed that out. Problem?
> -- 
> 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.
> 
> 
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
-- 
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: Do functions never get inlined by jvm?

[Gary Trakhman]

You could come up with definline yourself by thinking about what inlining
is and wrapping things in macros, it seems to me the real problem definline
solves is to also be able to use the output as a function, which is more
about keeping convenience than performance gains.

I think the people who want to know about this stuff will find it, it took
me a couple hours myself when I worked through this thought process a year
or so ago.




On Thu, Apr 25, 2013 at 2:05 PM, Softaddicts wrote:

> You asked a simple question, you got a plain answer.
> Now if you are still grunting there's not much I can do about that.
>
> I do agree that the doc string could be a bit more descriptive.
> But what does it mean to be understandable by "normal" users ?
> I am still trying to size what is a "normal" Lisp user these days.
> No single answer seems to fit so far.
>
> When I first used Lisp, inlining meant writing pseudo assembly code
> right through your Lisp code most of the time using a macro.
> Procedural languages had most of the time
> extension directives to allow you to force inlining at your will.
>
> Inlining is a concept that existed for more than 40 years in many
> programming
> languages. It's not anything new. Now if you want to use it but do not
> understand the implications, well it's not the doc string that will explain
> it to you.
>
> To me, definline looks simpler than any of the above.
>
> Luc
>
> > 2013/4/25 Softaddicts 
> >
> > > user=> (apropos "inline")
> > > (definline)
> > >
> >
> > Yeah, yeah. It all starts with (apropos "apropos"), right?
> >
> > I knew it.
> > --
> > 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.
> >
> >
> >
> --
> Softaddicts sent by ibisMail from my ipad!
>
> --
> --
> 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: Do functions never get inlined by jvm?

[Michael Klishin]

2013/4/25 Softaddicts 

> Inlining is a concept that existed for more than 40 years in many
> programming
> languages. It's not anything new.
>

The OP probably know what inlining is because, hm, the subject has that
word.
Then she is recommended to use something that only technically has
documentation (and is marked as experimental) and is not known or used by
many.

I've pointed that out. Problem?
-- 
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: Do functions never get inlined by jvm?

[Softaddicts]

You asked a simple question, you got a plain answer.
Now if you are still grunting there's not much I can do about that.

I do agree that the doc string could be a bit more descriptive.
But what does it mean to be understandable by "normal" users ?
I am still trying to size what is a "normal" Lisp user these days.
No single answer seems to fit so far.

When I first used Lisp, inlining meant writing pseudo assembly code
right through your Lisp code most of the time using a macro.
Procedural languages had most of the time
extension directives to allow you to force inlining at your will.

Inlining is a concept that existed for more than 40 years in many programming
languages. It's not anything new. Now if you want to use it but do not
understand the implications, well it's not the doc string that will explain
it to you.

To me, definline looks simpler than any of the above.

Luc

> 2013/4/25 Softaddicts 
> 
> > user=> (apropos "inline")
> > (definline)
> >
> 
> Yeah, yeah. It all starts with (apropos "apropos"), right?
> 
> I knew it.
> -- 
> 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.
> 
> 
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
-- 
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: Do functions never get inlined by jvm?

[Michael Klishin]

2013/4/25 Softaddicts 

> user=> (apropos "inline")
> (definline)
>

Yeah, yeah. It all starts with (apropos "apropos"), right?

I knew it.
-- 
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: Do functions never get inlined by jvm?

[Softaddicts]

user=> (apropos "inline")
(definline)
user=> (doc inline)
..




> 2013/4/25 David Nolen 
> 
> > (doc definline)
> 
> 
> Macro
>   Experimental - like defmacro, except defines a named function whose
>   body is the expansion, calls to which may be expanded inline as if
>   it were a macro. Cannot be used with variadic (&) args.
> 
> If you think this is useful to regular users (who have no idea about the
> compiler internals or JVM), you may want to reconsider.
> 
> Also, if I don't know definline exists, how do I find out? Books, docs
> don't mention it.
> 1 page on clojure.org that you have to find doesn't count.
> -- 
> 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.
> 
> 
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
-- 
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: Do functions never get inlined by jvm?

[Michael Klishin]

2013/4/25 David Nolen 

> (doc definline)


Macro
  Experimental - like defmacro, except defines a named function whose
  body is the expansion, calls to which may be expanded inline as if
  it were a macro. Cannot be used with variadic (&) args.

If you think this is useful to regular users (who have no idea about the
compiler internals or JVM), you may want to reconsider.

Also, if I don't know definline exists, how do I find out? Books, docs
don't mention it.
1 page on clojure.org that you have to find doesn't count.
-- 
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: Do functions never get inlined by jvm?

[David Nolen]

(doc definline)


On Thu, Apr 25, 2013 at 1:17 PM, Michael Klishin <
michael.s.klis...@gmail.com> wrote:

>
> 2013/4/25 David Nolen 
>
>> + :inline metadata
>
>
> Which is not documented anywhere and might as well not exist for regular
> Clojure users.
> --
> 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: Do functions never get inlined by jvm?

[Michael Klishin]

2013/4/25 David Nolen 

> + :inline metadata


Which is not documented anywhere and might as well not exist for regular
Clojure users.
-- 
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: Do functions never get inlined by jvm?

[David Nolen]

It just doesn't accurately describe how primitive fns work when used
non-higher order, nor is it correct for the tricks you can play with
non-higher order fn usage + :inline metadata. JVM will aggressively inline
these cases.


On Thu, Apr 25, 2013 at 1:03 PM, Alice  wrote:

> Care to elaborate which part is out of date?
>
> On Apr 26, 1:48 am, David Nolen  wrote:
> > Which is out of date.
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Apr 25, 2013 at 12:47 PM, Alice  wrote:
> > > Found this blog post written by fogus:
> >
> > > "To provide this level of flexibility Clojure establishes a level of
> > > indirection. Specifically, all function lookups through a Var occur,
> > > at the lowest level, through an atomic volatile. This happens every
> > > time that a function bound using the def/defn special forms is called.
> > > This indirection is not amenable to HotSpot optimizations."
> >
> > >http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic.
> ..
> >
> > > On Apr 25, 10:19 pm, Alice  wrote:
> > > > I create many small methods in java without worrying about the
> > > > performance since it's usually the target of inline optimization. For
> > > > example,
> >
> > > > public class Foo {
> > > >   public static long inc(long l) {
> > > > return ++l;
> > > >   }
> >
> > > >   public static long f1() {
> > > > long l = 0;
> > > > for (int i=0; i < 10; i++) {
> > > >   l++;
> > > > }
> > > > return l;
> > > >   }
> >
> > > >   public static long f2() {
> > > > long l = 0;
> > > > for (int i=0; i < 10; i++) {
> > > >   l = inc(l);
> > > > }
> > > > return l;
> > > >   }
> >
> > > > }
> >
> > > > (time (Foo/f1))
> > > > (time (Foo/f1))
> > > > (time (Foo/f1))
> > > > (time (Foo/f2))
> > > > (time (Foo/f2))
> > > > (time (Foo/f2))
> >
> > > > "Elapsed time: 23.309532 msecs"
> > > > "Elapsed time: 23.333039 msecs"
> > > > "Elapsed time: 21.714753 msecs"
> > > > "Elapsed time: 22.943366 msecs"
> > > > "Elapsed time: 21.612783 msecs"
> > > > "Elapsed time: 21.71376 msecs"
> >
> > > > But clojure funtions seem to be never get inlined.
> >
> > > > (def obj (Object.))
> >
> > > > (defn getObj [] obj)
> >
> > > > (defn f1 [] obj)
> > > > (defn f2 [] (getObj))
> >
> > > > (time (dotimes [n 1] (f1)))
> > > > (time (dotimes [n 1] (f1)))
> > > > (time (dotimes [n 1] (f1)))
> > > > (time (dotimes [n 1] (f2)))
> > > > (time (dotimes [n 1] (f2)))
> > > > (time (dotimes [n 1] (f2)))
> >
> > > > "Elapsed time: 67.758744 msecs"
> > > > "Elapsed time: 68.555306 msecs"
> > > > "Elapsed time: 68.725147 msecs"
> > > > "Elapsed time: 104.810459 msecs"
> > > > "Elapsed time: 103.273618 msecs"
> > > > "Elapsed time: 103.374595 msecs"
> >
> > > --
> > > --
> > > 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, visithttps://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/g

Re: Do functions never get inlined by jvm?

[Alice]

Care to elaborate which part is out of date?

On Apr 26, 1:48 am, David Nolen  wrote:
> Which is out of date.
>
>
>
>
>
>
>
> On Thu, Apr 25, 2013 at 12:47 PM, Alice  wrote:
> > Found this blog post written by fogus:
>
> > "To provide this level of flexibility Clojure establishes a level of
> > indirection. Specifically, all function lookups through a Var occur,
> > at the lowest level, through an atomic volatile. This happens every
> > time that a function bound using the def/defn special forms is called.
> > This indirection is not amenable to HotSpot optimizations."
>
> >http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic...
>
> > On Apr 25, 10:19 pm, Alice  wrote:
> > > I create many small methods in java without worrying about the
> > > performance since it's usually the target of inline optimization. For
> > > example,
>
> > > public class Foo {
> > >   public static long inc(long l) {
> > >     return ++l;
> > >   }
>
> > >   public static long f1() {
> > >     long l = 0;
> > >     for (int i=0; i < 10; i++) {
> > >       l++;
> > >     }
> > >     return l;
> > >   }
>
> > >   public static long f2() {
> > >     long l = 0;
> > >     for (int i=0; i < 10; i++) {
> > >       l = inc(l);
> > >     }
> > >     return l;
> > >   }
>
> > > }
>
> > > (time (Foo/f1))
> > > (time (Foo/f1))
> > > (time (Foo/f1))
> > > (time (Foo/f2))
> > > (time (Foo/f2))
> > > (time (Foo/f2))
>
> > > "Elapsed time: 23.309532 msecs"
> > > "Elapsed time: 23.333039 msecs"
> > > "Elapsed time: 21.714753 msecs"
> > > "Elapsed time: 22.943366 msecs"
> > > "Elapsed time: 21.612783 msecs"
> > > "Elapsed time: 21.71376 msecs"
>
> > > But clojure funtions seem to be never get inlined.
>
> > > (def obj (Object.))
>
> > > (defn getObj [] obj)
>
> > > (defn f1 [] obj)
> > > (defn f2 [] (getObj))
>
> > > (time (dotimes [n 1] (f1)))
> > > (time (dotimes [n 1] (f1)))
> > > (time (dotimes [n 1] (f1)))
> > > (time (dotimes [n 1] (f2)))
> > > (time (dotimes [n 1] (f2)))
> > > (time (dotimes [n 1] (f2)))
>
> > > "Elapsed time: 67.758744 msecs"
> > > "Elapsed time: 68.555306 msecs"
> > > "Elapsed time: 68.725147 msecs"
> > > "Elapsed time: 104.810459 msecs"
> > > "Elapsed time: 103.273618 msecs"
> > > "Elapsed time: 103.374595 msecs"
>
> > --
> > --
> > 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, visithttps://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: Do functions never get inlined by jvm?

[David Nolen]

Which is out of date.


On Thu, Apr 25, 2013 at 12:47 PM, Alice  wrote:

> Found this blog post written by fogus:
>
> "To provide this level of flexibility Clojure establishes a level of
> indirection. Specifically, all function lookups through a Var occur,
> at the lowest level, through an atomic volatile. This happens every
> time that a function bound using the def/defn special forms is called.
> This indirection is not amenable to HotSpot optimizations."
>
>
> http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic-but-it-might-be-nice/
>
> On Apr 25, 10:19 pm, Alice  wrote:
> > I create many small methods in java without worrying about the
> > performance since it's usually the target of inline optimization. For
> > example,
> >
> > public class Foo {
> >   public static long inc(long l) {
> > return ++l;
> >   }
> >
> >   public static long f1() {
> > long l = 0;
> > for (int i=0; i < 10; i++) {
> >   l++;
> > }
> > return l;
> >   }
> >
> >   public static long f2() {
> > long l = 0;
> > for (int i=0; i < 10; i++) {
> >   l = inc(l);
> > }
> > return l;
> >   }
> >
> > }
> >
> > (time (Foo/f1))
> > (time (Foo/f1))
> > (time (Foo/f1))
> > (time (Foo/f2))
> > (time (Foo/f2))
> > (time (Foo/f2))
> >
> > "Elapsed time: 23.309532 msecs"
> > "Elapsed time: 23.333039 msecs"
> > "Elapsed time: 21.714753 msecs"
> > "Elapsed time: 22.943366 msecs"
> > "Elapsed time: 21.612783 msecs"
> > "Elapsed time: 21.71376 msecs"
> >
> > But clojure funtions seem to be never get inlined.
> >
> > (def obj (Object.))
> >
> > (defn getObj [] obj)
> >
> > (defn f1 [] obj)
> > (defn f2 [] (getObj))
> >
> > (time (dotimes [n 1] (f1)))
> > (time (dotimes [n 1] (f1)))
> > (time (dotimes [n 1] (f1)))
> > (time (dotimes [n 1] (f2)))
> > (time (dotimes [n 1] (f2)))
> > (time (dotimes [n 1] (f2)))
> >
> > "Elapsed time: 67.758744 msecs"
> > "Elapsed time: 68.555306 msecs"
> > "Elapsed time: 68.725147 msecs"
> > "Elapsed time: 104.810459 msecs"
> > "Elapsed time: 103.273618 msecs"
> > "Elapsed time: 103.374595 msecs"
>
> --
> --
> 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: Do functions never get inlined by jvm?

[Alice]

Found this blog post written by fogus:

"To provide this level of flexibility Clojure establishes a level of
indirection. Specifically, all function lookups through a Var occur,
at the lowest level, through an atomic volatile. This happens every
time that a function bound using the def/defn special forms is called.
This indirection is not amenable to HotSpot optimizations."

http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic-but-it-might-be-nice/

On Apr 25, 10:19 pm, Alice  wrote:
> I create many small methods in java without worrying about the
> performance since it's usually the target of inline optimization. For
> example,
>
> public class Foo {
>   public static long inc(long l) {
>     return ++l;
>   }
>
>   public static long f1() {
>     long l = 0;
>     for (int i=0; i < 10; i++) {
>       l++;
>     }
>     return l;
>   }
>
>   public static long f2() {
>     long l = 0;
>     for (int i=0; i < 10; i++) {
>       l = inc(l);
>     }
>     return l;
>   }
>
> }
>
> (time (Foo/f1))
> (time (Foo/f1))
> (time (Foo/f1))
> (time (Foo/f2))
> (time (Foo/f2))
> (time (Foo/f2))
>
> "Elapsed time: 23.309532 msecs"
> "Elapsed time: 23.333039 msecs"
> "Elapsed time: 21.714753 msecs"
> "Elapsed time: 22.943366 msecs"
> "Elapsed time: 21.612783 msecs"
> "Elapsed time: 21.71376 msecs"
>
> But clojure funtions seem to be never get inlined.
>
> (def obj (Object.))
>
> (defn getObj [] obj)
>
> (defn f1 [] obj)
> (defn f2 [] (getObj))
>
> (time (dotimes [n 1] (f1)))
> (time (dotimes [n 1] (f1)))
> (time (dotimes [n 1] (f1)))
> (time (dotimes [n 1] (f2)))
> (time (dotimes [n 1] (f2)))
> (time (dotimes [n 1] (f2)))
>
> "Elapsed time: 67.758744 msecs"
> "Elapsed time: 68.555306 msecs"
> "Elapsed time: 68.725147 msecs"
> "Elapsed time: 104.810459 msecs"
> "Elapsed time: 103.273618 msecs"
> "Elapsed time: 103.374595 msecs"

-- 
-- 
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: Do functions never get inlined by jvm?

[David Nolen]

You have to be very careful with microbenchmarks like this. I recommend
writing less trivial benchmarks. For example
http://github.com/clojure/test.benchmark/blob/master/src/main/clojure/alioth/spectral_norm.clj

This code demonstrates performance on par with plain Java. There are many
other similar examples in the test.benchark project.

David


On Thu, Apr 25, 2013 at 9:44 AM, Alice  wrote:

> Primitive hinted funtions seem to be not an exception.
>
> (defn my-inc ^long [^long l] (inc l))
>
> (defn f1 [^long l] (inc l))
> (defn f2 [^long l] (my-inc l))
>
> (time (dotimes [n 1] (f1 1)))
> (time (dotimes [n 1] (f1 1)))
> (time (dotimes [n 1] (f1 1)))
> (time (dotimes [n 1] (f2 1)))
> (time (dotimes [n 1] (f2 1)))
> (time (dotimes [n 1] (f2 1)))
>
> "Elapsed time: 68.683431 msecs"
> "Elapsed time: 68.964182 msecs"
> "Elapsed time: 68.105047 msecs"
> "Elapsed time: 108.576746 msecs"
> "Elapsed time: 100.992193 msecs"
> "Elapsed time: 100.945511 msecs"
>
> On Apr 25, 10:32 pm, David Nolen  wrote:
> > primitive hinted fns will get inlined. You can also play the same kinds
> of
> > games that Clojure does with definterface+deftype and fns that declare
> > :inline metadata.
> >
> > If you don't want to learn the subtleties of Clojure performance tuning
> > then you can always write your performance critical bits in Java and call
> > into it. Some folks, like the people at Prismatic, seem to be doing
> pretty
> > well writing all their performance critical code in Clojure, but they've
> > built some tools to avoid the various potential pitfalls.
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Apr 25, 2013 at 9:19 AM, Alice  wrote:
> > > I create many small methods in java without worrying about the
> > > performance since it's usually the target of inline optimization. For
> > > example,
> >
> > > public class Foo {
> > >   public static long inc(long l) {
> > > return ++l;
> > >   }
> >
> > >   public static long f1() {
> > > long l = 0;
> > > for (int i=0; i < 10; i++) {
> > >   l++;
> > > }
> > > return l;
> > >   }
> >
> > >   public static long f2() {
> > > long l = 0;
> > > for (int i=0; i < 10; i++) {
> > >   l = inc(l);
> > > }
> > > return l;
> > >   }
> > > }
> >
> > > (time (Foo/f1))
> > > (time (Foo/f1))
> > > (time (Foo/f1))
> > > (time (Foo/f2))
> > > (time (Foo/f2))
> > > (time (Foo/f2))
> >
> > > "Elapsed time: 23.309532 msecs"
> > > "Elapsed time: 23.333039 msecs"
> > > "Elapsed time: 21.714753 msecs"
> > > "Elapsed time: 22.943366 msecs"
> > > "Elapsed time: 21.612783 msecs"
> > > "Elapsed time: 21.71376 msecs"
> >
> > > But clojure funtions seem to be never get inlined.
> >
> > > (def obj (Object.))
> >
> > > (defn getObj [] obj)
> >
> > > (defn f1 [] obj)
> > > (defn f2 [] (getObj))
> >
> > > (time (dotimes [n 1] (f1)))
> > > (time (dotimes [n 1] (f1)))
> > > (time (dotimes [n 1] (f1)))
> > > (time (dotimes [n 1] (f2)))
> > > (time (dotimes [n 1] (f2)))
> > > (time (dotimes [n 1] (f2)))
> >
> > > "Elapsed time: 67.758744 msecs"
> > > "Elapsed time: 68.555306 msecs"
> > > "Elapsed time: 68.725147 msecs"
> > > "Elapsed time: 104.810459 msecs"
> > > "Elapsed time: 103.273618 msecs"
> > > "Elapsed time: 103.374595 msecs"
> >
> > > --
> > > --
> > > 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, visithttps://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

Re: Do functions never get inlined by jvm?

[Jonathan Fischer Friberg]

If that's a problem, you could try https://github.com/hugoduncan/criterium


On Thu, Apr 25, 2013 at 5:38 PM, Phil Hagelberg  wrote:

> Three repetitions is not nearly enough to get a feel for how hotspot
> optimizes functions when it detects they're in a tight loop. I don't know
> how javac works, but Clojure doesn't optimize much for cases where hotspot
> can do a much better job over time.
>
> -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.
>
>
>

-- 
-- 
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: Do functions never get inlined by jvm?

[Phil Hagelberg]

Three repetitions is not nearly enough to get a feel for how hotspot
optimizes functions when it detects they're in a tight loop. I don't know
how javac works, but Clojure doesn't optimize much for cases where hotspot
can do a much better job over time.

-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: Do functions never get inlined by jvm?

[Ambrose Bonnaire-Sergeant]

jvm.tools.analyzer is a nice tool for exploration in this area.

I don't personally know all the subtleties here, but after some playing I
managed to emit an unboxing function.
I could tell from the AST.

https://gist.github.com/frenchy64/5459989

Thanks,
Ambrose


On Thu, Apr 25, 2013 at 9:44 PM, Alice  wrote:

> Primitive hinted funtions seem to be not an exception.
>
> (defn my-inc ^long [^long l] (inc l))
>
> (defn f1 [^long l] (inc l))
> (defn f2 [^long l] (my-inc l))
>
> (time (dotimes [n 1] (f1 1)))
> (time (dotimes [n 1] (f1 1)))
> (time (dotimes [n 1] (f1 1)))
> (time (dotimes [n 1] (f2 1)))
> (time (dotimes [n 1] (f2 1)))
> (time (dotimes [n 1] (f2 1)))
>
> "Elapsed time: 68.683431 msecs"
> "Elapsed time: 68.964182 msecs"
> "Elapsed time: 68.105047 msecs"
> "Elapsed time: 108.576746 msecs"
> "Elapsed time: 100.992193 msecs"
> "Elapsed time: 100.945511 msecs"
>
> On Apr 25, 10:32 pm, David Nolen  wrote:
> > primitive hinted fns will get inlined. You can also play the same kinds
> of
> > games that Clojure does with definterface+deftype and fns that declare
> > :inline metadata.
> >
> > If you don't want to learn the subtleties of Clojure performance tuning
> > then you can always write your performance critical bits in Java and call
> > into it. Some folks, like the people at Prismatic, seem to be doing
> pretty
> > well writing all their performance critical code in Clojure, but they've
> > built some tools to avoid the various potential pitfalls.
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Apr 25, 2013 at 9:19 AM, Alice  wrote:
> > > I create many small methods in java without worrying about the
> > > performance since it's usually the target of inline optimization. For
> > > example,
> >
> > > public class Foo {
> > >   public static long inc(long l) {
> > > return ++l;
> > >   }
> >
> > >   public static long f1() {
> > > long l = 0;
> > > for (int i=0; i < 10; i++) {
> > >   l++;
> > > }
> > > return l;
> > >   }
> >
> > >   public static long f2() {
> > > long l = 0;
> > > for (int i=0; i < 10; i++) {
> > >   l = inc(l);
> > > }
> > > return l;
> > >   }
> > > }
> >
> > > (time (Foo/f1))
> > > (time (Foo/f1))
> > > (time (Foo/f1))
> > > (time (Foo/f2))
> > > (time (Foo/f2))
> > > (time (Foo/f2))
> >
> > > "Elapsed time: 23.309532 msecs"
> > > "Elapsed time: 23.333039 msecs"
> > > "Elapsed time: 21.714753 msecs"
> > > "Elapsed time: 22.943366 msecs"
> > > "Elapsed time: 21.612783 msecs"
> > > "Elapsed time: 21.71376 msecs"
> >
> > > But clojure funtions seem to be never get inlined.
> >
> > > (def obj (Object.))
> >
> > > (defn getObj [] obj)
> >
> > > (defn f1 [] obj)
> > > (defn f2 [] (getObj))
> >
> > > (time (dotimes [n 1] (f1)))
> > > (time (dotimes [n 1] (f1)))
> > > (time (dotimes [n 1] (f1)))
> > > (time (dotimes [n 1] (f2)))
> > > (time (dotimes [n 1] (f2)))
> > > (time (dotimes [n 1] (f2)))
> >
> > > "Elapsed time: 67.758744 msecs"
> > > "Elapsed time: 68.555306 msecs"
> > > "Elapsed time: 68.725147 msecs"
> > > "Elapsed time: 104.810459 msecs"
> > > "Elapsed time: 103.273618 msecs"
> > > "Elapsed time: 103.374595 msecs"
> >
> > > --
> > > --
> > > 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, visithttps://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 moder

Re: Do functions never get inlined by jvm?

[Alice]

Primitive hinted funtions seem to be not an exception.

(defn my-inc ^long [^long l] (inc l))

(defn f1 [^long l] (inc l))
(defn f2 [^long l] (my-inc l))

(time (dotimes [n 1] (f1 1)))
(time (dotimes [n 1] (f1 1)))
(time (dotimes [n 1] (f1 1)))
(time (dotimes [n 1] (f2 1)))
(time (dotimes [n 1] (f2 1)))
(time (dotimes [n 1] (f2 1)))

"Elapsed time: 68.683431 msecs"
"Elapsed time: 68.964182 msecs"
"Elapsed time: 68.105047 msecs"
"Elapsed time: 108.576746 msecs"
"Elapsed time: 100.992193 msecs"
"Elapsed time: 100.945511 msecs"

On Apr 25, 10:32 pm, David Nolen  wrote:
> primitive hinted fns will get inlined. You can also play the same kinds of
> games that Clojure does with definterface+deftype and fns that declare
> :inline metadata.
>
> If you don't want to learn the subtleties of Clojure performance tuning
> then you can always write your performance critical bits in Java and call
> into it. Some folks, like the people at Prismatic, seem to be doing pretty
> well writing all their performance critical code in Clojure, but they've
> built some tools to avoid the various potential pitfalls.
>
>
>
>
>
>
>
> On Thu, Apr 25, 2013 at 9:19 AM, Alice  wrote:
> > I create many small methods in java without worrying about the
> > performance since it's usually the target of inline optimization. For
> > example,
>
> > public class Foo {
> >   public static long inc(long l) {
> >     return ++l;
> >   }
>
> >   public static long f1() {
> >     long l = 0;
> >     for (int i=0; i < 10; i++) {
> >       l++;
> >     }
> >     return l;
> >   }
>
> >   public static long f2() {
> >     long l = 0;
> >     for (int i=0; i < 10; i++) {
> >       l = inc(l);
> >     }
> >     return l;
> >   }
> > }
>
> > (time (Foo/f1))
> > (time (Foo/f1))
> > (time (Foo/f1))
> > (time (Foo/f2))
> > (time (Foo/f2))
> > (time (Foo/f2))
>
> > "Elapsed time: 23.309532 msecs"
> > "Elapsed time: 23.333039 msecs"
> > "Elapsed time: 21.714753 msecs"
> > "Elapsed time: 22.943366 msecs"
> > "Elapsed time: 21.612783 msecs"
> > "Elapsed time: 21.71376 msecs"
>
> > But clojure funtions seem to be never get inlined.
>
> > (def obj (Object.))
>
> > (defn getObj [] obj)
>
> > (defn f1 [] obj)
> > (defn f2 [] (getObj))
>
> > (time (dotimes [n 1] (f1)))
> > (time (dotimes [n 1] (f1)))
> > (time (dotimes [n 1] (f1)))
> > (time (dotimes [n 1] (f2)))
> > (time (dotimes [n 1] (f2)))
> > (time (dotimes [n 1] (f2)))
>
> > "Elapsed time: 67.758744 msecs"
> > "Elapsed time: 68.555306 msecs"
> > "Elapsed time: 68.725147 msecs"
> > "Elapsed time: 104.810459 msecs"
> > "Elapsed time: 103.273618 msecs"
> > "Elapsed time: 103.374595 msecs"
>
> > --
> > --
> > 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, visithttps://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: Do functions never get inlined by jvm?

[David Nolen]

primitive hinted fns will get inlined. You can also play the same kinds of
games that Clojure does with definterface+deftype and fns that declare
:inline metadata.

If you don't want to learn the subtleties of Clojure performance tuning
then you can always write your performance critical bits in Java and call
into it. Some folks, like the people at Prismatic, seem to be doing pretty
well writing all their performance critical code in Clojure, but they've
built some tools to avoid the various potential pitfalls.


On Thu, Apr 25, 2013 at 9:19 AM, Alice  wrote:

> I create many small methods in java without worrying about the
> performance since it's usually the target of inline optimization. For
> example,
>
> public class Foo {
>   public static long inc(long l) {
> return ++l;
>   }
>
>   public static long f1() {
> long l = 0;
> for (int i=0; i < 10; i++) {
>   l++;
> }
> return l;
>   }
>
>   public static long f2() {
> long l = 0;
> for (int i=0; i < 10; i++) {
>   l = inc(l);
> }
> return l;
>   }
> }
>
> (time (Foo/f1))
> (time (Foo/f1))
> (time (Foo/f1))
> (time (Foo/f2))
> (time (Foo/f2))
> (time (Foo/f2))
>
> "Elapsed time: 23.309532 msecs"
> "Elapsed time: 23.333039 msecs"
> "Elapsed time: 21.714753 msecs"
> "Elapsed time: 22.943366 msecs"
> "Elapsed time: 21.612783 msecs"
> "Elapsed time: 21.71376 msecs"
>
>
> But clojure funtions seem to be never get inlined.
>
> (def obj (Object.))
>
> (defn getObj [] obj)
>
> (defn f1 [] obj)
> (defn f2 [] (getObj))
>
> (time (dotimes [n 1] (f1)))
> (time (dotimes [n 1] (f1)))
> (time (dotimes [n 1] (f1)))
> (time (dotimes [n 1] (f2)))
> (time (dotimes [n 1] (f2)))
> (time (dotimes [n 1] (f2)))
>
> "Elapsed time: 67.758744 msecs"
> "Elapsed time: 68.555306 msecs"
> "Elapsed time: 68.725147 msecs"
> "Elapsed time: 104.810459 msecs"
> "Elapsed time: 103.273618 msecs"
> "Elapsed time: 103.374595 msecs"
>
> --
> --
> 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.

Do functions never get inlined by jvm?

[Alice]

I create many small methods in java without worrying about the
performance since it's usually the target of inline optimization. For
example,

public class Foo {
  public static long inc(long l) {
return ++l;
  }

  public static long f1() {
long l = 0;
for (int i=0; i < 10; i++) {
  l++;
}
return l;
  }

  public static long f2() {
long l = 0;
for (int i=0; i < 10; i++) {
  l = inc(l);
}
return l;
  }
}

(time (Foo/f1))
(time (Foo/f1))
(time (Foo/f1))
(time (Foo/f2))
(time (Foo/f2))
(time (Foo/f2))

"Elapsed time: 23.309532 msecs"
"Elapsed time: 23.333039 msecs"
"Elapsed time: 21.714753 msecs"
"Elapsed time: 22.943366 msecs"
"Elapsed time: 21.612783 msecs"
"Elapsed time: 21.71376 msecs"


But clojure funtions seem to be never get inlined.

(def obj (Object.))

(defn getObj [] obj)

(defn f1 [] obj)
(defn f2 [] (getObj))

(time (dotimes [n 1] (f1)))
(time (dotimes [n 1] (f1)))
(time (dotimes [n 1] (f1)))
(time (dotimes [n 1] (f2)))
(time (dotimes [n 1] (f2)))
(time (dotimes [n 1] (f2)))

"Elapsed time: 67.758744 msecs"
"Elapsed time: 68.555306 msecs"
"Elapsed time: 68.725147 msecs"
"Elapsed time: 104.810459 msecs"
"Elapsed time: 103.273618 msecs"
"Elapsed time: 103.374595 msecs"

-- 
-- 
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: New CSS library - Garden

[JeremyS]

Hi Murtaza,

the simple way to go is have something like

(def rules1 [...])
(def rules2 [...])

(spit "rules.css" 
  (css (concat rules1 rules2)))

I am not sure about my good use of the library here but I think the idea is 
there. When you develop with the repo
you can just eval the (spit ...) call when you have changed your rules and 
voilà !

I hope this helps...

Jeremy.

On Thursday, April 25, 2013 3:44:25 AM UTC+2, Murtaza Husain wrote:
>
> Joel,
>
> Thanks for the lib. Its great and I plan to use it in my projects.
>
> How does Garden compare to other pre processors such as sass and less ?
>
> Also can I use it in my clojurescript projects ? I mean does it have any 
> java lib dependencies that would prevent it?
>
> What is the workflow when using Garden ? If I am using Sass, I would 
> create a .scss file, and the sass daemon would watch over any changes to 
> the file and compile it to .css.
>
> As I understand garden is generating css when called with the fn/macro 
> (css [...]). Would it make sense to have a similar workflow like above; 
> where a leiningen plugin watches for any .garden files and compiles them to 
> .css files ? Or is there a better workflow that I am missing? 
>
> Thanks,
> Murtaza 
>
>
> On Tuesday, April 23, 2013 2:42:55 AM UTC+5:30, Joel Holdbrooks wrote:
>>
>> As of today, Garden is officially out of alpha and in to beta!
>>
>> The library now sports media 
>> queries (via 
>> meta data) and parent selector 
>> references 
>> (ie. 
>> "&hover"). With these new features it is now possible to build more 
>> sophisticated stylesheets bringing us a step closer to having a viable CSS 
>> alternative in Clojure.
>>
>> Over the course of the next few weeks, I plan to continue improving the 
>> library by adding "missing" features and functions to make the library as 
>> powerful as possible when it's release as 0.1.0 stable.
>>
>> Now more than ever, I would like to encourage others in the community to 
>> reach out with suggestions and code review. This my first "real" Clojure 
>> library and after only six months with the language I'm sure it could 
>> benefit greatly from both of these things.
>>
>

-- 
-- 
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: What's the difference between a "sequence" and a "seq"?

[Rostislav Svoboda]

+100. Thx a lot!

On 25 April 2013 13:45, fb  wrote:
> the conceptional differences between collection and sequences are confusing
> quite a bit.
> A nice wrap up by Tim McCormack can be found here:
>
> http://www.brainonfire.net/files/seqs-and-colls/main.html
> (via Sean Corfield)
>
> -fb
>
> Am Sonntag, 31. März 2013 14:58:15 UTC+2 schrieb Alice:
>>
>> On http://clojure.org/lazier,
>>
>>   Changed: (rest aseq) - returns a logical collection (Sequence) of
>> the remaining items, not (necessarily) a seq
>>
>> rest simply calls RT.more and here's the code of RT.more:
>>
>>   static public ISeq more(Object x){
>> if(x instanceof ISeq)
>>   return ((ISeq) x).more();
>> ISeq seq = seq(x);
>> if(seq == null)
>>   return PersistentList.EMPTY;
>> return seq.more();
>>   }
>>
>> So, it seems to return just a seq and not some logical collection?
>
> --
> --
> 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: [GSoC 2013] core.logic CLP(Prob)

[Michał Marczyk]

I've actually taken a stab at porting slpKanren; I think there was
something I wanted to tweak, so I'll take another look at the code, do
the tweaking (if any) and post it sometime soon. (I'm a bit overloaded
this week, so it might take longer than it otherwise would...)

Probabilistic programming looks *so* exciting, it would be cool to
experiment with some approaches in Clojure. (Needless to say, I'm
quite enthusiastic about CLP(Prob) in core.logic.)

Cheers,
Michał


On 25 April 2013 14:10, David Nolen  wrote:
> On Thu, Apr 25, 2013 at 5:29 AM, Martin Forsgren 
> wrote:
>>
>> What are your thoughts on slpKanren? Could it be used as a base for
>> probabilistic programming in core.logic?
>> https://github.com/webyrd/slpKanren
>>
>> - Martin
>
>
> It's definitely worth taking a look at and assessing. It does have the
> benefit that it would be relatively simple to implement.
>
> David
>
> --
> --
> 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: [GSoC 2013] core.logic CLP(Prob)

[David Nolen]

On Thu, Apr 25, 2013 at 5:29 AM, Martin Forsgren
wrote:

> What are your thoughts on slpKanren? Could it be used as a base for
> probabilistic programming in core.logic?
> https://github.com/webyrd/slpKanren
>
> - Martin
>

It's definitely worth taking a look at and assessing. It does have the
benefit that it would be relatively simple to implement.

David

-- 
-- 
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: What's the difference between a "sequence" and a "seq"?

[fb]

the conceptional differences between collection and sequences are confusing 
quite a bit. 
A nice wrap up by Tim McCormack can be found here:

http://www.brainonfire.net/files/seqs-and-colls/main.html 
(via Sean Corfield)

-fb

Am Sonntag, 31. März 2013 14:58:15 UTC+2 schrieb Alice:
>
> On http://clojure.org/lazier, 
>
>   Changed: (rest aseq) - returns a logical collection (Sequence) of 
> the remaining items, not (necessarily) a seq 
>
> rest simply calls RT.more and here's the code of RT.more: 
>
>   static public ISeq more(Object x){ 
> if(x instanceof ISeq) 
>   return ((ISeq) x).more(); 
> ISeq seq = seq(x); 
> if(seq == null) 
>   return PersistentList.EMPTY; 
> return seq.more(); 
>   } 
>
> So, it seems to return just a seq and not some logical collection? 
>

-- 
-- 
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: Performance of calling primitive type hinted functions passed as arguments

[Alice]

The reason foo2 is faster is that foo1 is passing a primitive long
value to cb, which caused boxing. Without that, the performance seems
to be exactly the same, which it should be!

On Apr 25, 6:50 pm, Alice  wrote:
> Wow! That's awesome. It's even faster! Thanks.
>
> (defn foo1 [^long l cb] (cb l))
> (defn foo2 [^long l cb] (invoke-primitive O [L] cb l))
>
> (time
>   (dotimes [n 100]
>     (foo1 n (fn [l] nil
>
> (time
>   (dotimes [n 100]
>     (foo2 n (fn [^long l] nil
>
> "Elapsed time: 7.622627 msecs"
> "Elapsed time: 5.341534 msecs"
>
> On Apr 25, 4:17 pm, Gunnar Völkel 
> wrote:
>
>
>
>
>
>
>
> > Some time ago I dug into primitive type hints and how the Clojure compiler
> > uses them.
> > When the compiler finds primitive type hints on a function, say (defn f
> > [^long n] ...), the generated class for that function implements a
> > primitive interface, IFn$LO in this case,
> > and generates appropriate code in the interface's only method Object
> > invokePrim(long arg0).
>
> > For a defn which is used as symbol in code the compiler detects the
> > primitive interface and generates code using invokePrim if the infered type
> > of the parameters matches.
> > Long story short, currently the compiler is not able to use primitive
> > invocation for higher order functions automatically because it would need
> > to generate code that checks at runtime.
>
> > You can fix this with Java interop. I implemented an `invoke-primitive`
> > macro over here:https://gist.github.com/guv/5458038
> > It could be used like follows:
> > (defn calc [^long n] ...)
> > (defn dosomething [f, ^long n]
> >   (invoke-primitive O [L] f n))
>
> > The macro expands to (.invokePrim ^IFn$LO f n) using several checks at
> > compile time.
>
> > Am Mittwoch, 24. April 2013 19:15:49 UTC+2 schrieb Alice:
>
> > > So, is there a way to type hint on cb that it has a function accepting
> > > a long argument?
>
> > > On Apr 25, 12:55 am, Stuart Sierra 
> > > wrote:
> > > > I'm taking a guess here: The compiler doesn't know the type signature of
> > > > `cb` when compiling `foo`, so it's going to use the IFn.invoke(Object)
> > > > signature. Clojure's type inference is only local, and it won't assume
> > > that
> > > > a primitive-type signature is available for an arbitrary function.
>
> > > > So there's probably some extra typecasting going on when `fn` is
> > > > type-hinted to a primitive.
>
> > > > In general, type-hinting to primitive types doesn't do you any good in
> > > the
> > > > presence of higher-order functions like `map`.
>
> > > > -S
>
> > > > On Wednesday, April 24, 2013 11:35:11 AM UTC-4, Alice wrote:
>
> > > > > (defn foo [^long l cb] (cb l))
>
> > > > > (time
> > > > >   (dotimes [n 100]
> > > > >     (foo n (fn [l] nil
>
> > > > > (time
> > > > >   (dotimes [n 100]
> > > > >     (foo n (fn [^long l] nil
>
> > > > > "Elapsed time: 7.861 msecs"
> > > > > "Elapsed time: 11.770973 msecs"
>
> > > > > Why is the latter slower?

-- 
-- 
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: Performance of calling primitive type hinted functions passed as arguments

[Alice]

Wow! That's awesome. It's even faster! Thanks.

(defn foo1 [^long l cb] (cb l))
(defn foo2 [^long l cb] (invoke-primitive O [L] cb l))

(time
  (dotimes [n 100]
(foo1 n (fn [l] nil

(time
  (dotimes [n 100]
(foo2 n (fn [^long l] nil

"Elapsed time: 7.622627 msecs"
"Elapsed time: 5.341534 msecs"

On Apr 25, 4:17 pm, Gunnar Völkel 
wrote:
> Some time ago I dug into primitive type hints and how the Clojure compiler
> uses them.
> When the compiler finds primitive type hints on a function, say (defn f
> [^long n] ...), the generated class for that function implements a
> primitive interface, IFn$LO in this case,
> and generates appropriate code in the interface's only method Object
> invokePrim(long arg0).
>
> For a defn which is used as symbol in code the compiler detects the
> primitive interface and generates code using invokePrim if the infered type
> of the parameters matches.
> Long story short, currently the compiler is not able to use primitive
> invocation for higher order functions automatically because it would need
> to generate code that checks at runtime.
>
> You can fix this with Java interop. I implemented an `invoke-primitive`
> macro over here:https://gist.github.com/guv/5458038
> It could be used like follows:
> (defn calc [^long n] ...)
> (defn dosomething [f, ^long n]
>   (invoke-primitive O [L] f n))
>
> The macro expands to (.invokePrim ^IFn$LO f n) using several checks at
> compile time.
>
> Am Mittwoch, 24. April 2013 19:15:49 UTC+2 schrieb Alice:
>
>
>
>
>
>
>
>
>
> > So, is there a way to type hint on cb that it has a function accepting
> > a long argument?
>
> > On Apr 25, 12:55 am, Stuart Sierra 
> > wrote:
> > > I'm taking a guess here: The compiler doesn't know the type signature of
> > > `cb` when compiling `foo`, so it's going to use the IFn.invoke(Object)
> > > signature. Clojure's type inference is only local, and it won't assume
> > that
> > > a primitive-type signature is available for an arbitrary function.
>
> > > So there's probably some extra typecasting going on when `fn` is
> > > type-hinted to a primitive.
>
> > > In general, type-hinting to primitive types doesn't do you any good in
> > the
> > > presence of higher-order functions like `map`.
>
> > > -S
>
> > > On Wednesday, April 24, 2013 11:35:11 AM UTC-4, Alice wrote:
>
> > > > (defn foo [^long l cb] (cb l))
>
> > > > (time
> > > >   (dotimes [n 100]
> > > >     (foo n (fn [l] nil
>
> > > > (time
> > > >   (dotimes [n 100]
> > > >     (foo n (fn [^long l] nil
>
> > > > "Elapsed time: 7.861 msecs"
> > > > "Elapsed time: 11.770973 msecs"
>
> > > > Why is the latter slower?

-- 
-- 
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: Defining custom tags using hiccup ?

[Dave Sann]

one other thought.

It is possible just to manipulate the hiccup data as suggested by Walter 
above. This may be better because it is independent. But I wonder about 
performance costs of processing the structures twice (expand and then 
render) rather than once (render).

Dave

-- 
-- 
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: [GSoC 2013] core.logic CLP(Prob)

[Martin Forsgren]

What are your thoughts on slpKanren? Could it be used as a base for 
probabilistic programming in core.logic?
https://github.com/webyrd/slpKanren

- Martin

Den onsdagen den 24:e april 2013 kl. 17:34:05 UTC+2 skrev David Nolen:
>
> This is great, thanks for the thoughts, gist & links!
>
>
> On Wed, Apr 24, 2013 at 5:34 AM, Zack Maril 
> > wrote:
>
>> Lately, I've been on a bit of a jag into probabilistic programming with 
>> Clojure, specifically embedding Church inside of Clojure. The results so 
>> far are promising from a syntactic level, but, like David said, getting it 
>> to actually work is another matter entirely. I wanted to share what I've 
>> been able to get working so far and some of the potential challenges of 
>> embedding Church in Clojure. 
>>
>> https://gist.github.com/zmaril/5447488
>>
>> The above gist is a self contained Clojure program that implements, among 
>> other things, `query-by-rejection` and `flip`. With these two functions, we 
>> can already do most of what Church seems to do. What's missing from 
>> a functionality standpoint is support for various distributions and some 
>> useful functions related to tolerance (and, of course, a good MCMC/Gibbs 
>> implementation). What's been gained is, via some careful macro writing, the 
>> ability to reuse code, specifically to reuse memoized functions. 
>>
>> One of the key ideas behind Church is that memoization allows one to 
>> express complicated scenarios very concisely. So, to code up a randomized 
>> persistent trait (like a person's eye color), you simply define a memoized 
>> function that takes in a person and returns their eye color. Every time a 
>> new world is generated, the memoized function gets recreated. But within 
>> the world (or current experiment), the trait persists and can be referenced 
>> again in various places without too much hassle.  Note that a new memoized 
>> function must be created for each experiment, i.e. you can't just memoize 
>> the function outside the query and bring that back in. Within the gist 
>> above, binding is used to carefully rebind any function provided in the 
>> :memobound clause for each experiment. By declaring a var to be dynamic, we 
>> can write queries that are pretty short but all rely on the same logic. 
>> From a syntactic standpoint, it took about one evening of work to cut down 
>> the length of most of the Church examples by at least half. 
>>
>> From a speed standpoint, Church is way, way ahead of the above. Sampling 
>> via rejection is quite slow compared to modern methods like MCMC or Gibbs. 
>> It might not even be possible to do the dynamic rebinding of memoized 
>> functions mentioned above and get as fast as Church is. I really don't 
>> know. Here's one of the first papers on Church:
>> http://www.stanford.edu/~ngoodman/papers/churchUAI08_rev2.pdf
>>
>> The paper is about five years old now, but section 4.1 goes into how 
>> Church was first implemented with a MCMC. The key idea they introduce here 
>> is the computation trace. I won't try to summarize it here because I don't 
>> fully understand it yet. If it means what I think it means though, then it 
>> should be possible to build and keep track of the computation trace thanks 
>> to the JVM and Clojure. My intuition says that a very dedicated student 
>> could probably produce a Clojure library to catch Church in terms of speed 
>> by the end of the summer, simply by emulating what they have done and 
>> letting pmap take care of the rest.  
>> -Zack
>>
>> On Wednesday, April 24, 2013 12:48:56 AM UTC+4, David Nolen wrote:
>>
>>> On Tue, Apr 23, 2013 at 2:10 PM, Radosław Piliszek 
>>> wrote:
>>>
 1) Is this place the best to discuss this?

>>>
>>> Yes.
>>>  
>>>
 2) Are there some set goals that CLP(Prob) should achieve? (,,Basic 
 support of CLP(Prob).'' does not express it too well! :-P )

>>>
>>> This seems like a pretty challenging one as there are a variety of 
>>> possible approaches. Basic support for CLP(Prob) could very well mean 
>>> *several* prototypes. That said the probabilistic Prolog variants are 
>>> probably worthy of the most study as core.logic is closest to that model.
>>>  
>>>
 3) Is there any API sketch that should be followed? Is it still yet to 
 be discussed? And, most importantly, how would you see CLP(Prob) fit in 
 core.logic's ecosystem?

>>>
>>> There is no API sketch. It's extremely important to survey the links, 
>>> try out existing implementations, assess their advantages / disadvantages 
>>> and devise a syntax (or several) that works reasonably well with what we've 
>>> already established in core.logic. 
>>>
>>> Of the projects listed this is probably the most experimental and 
>>> research-y. I think if anyone seriously wants to take this on they have to 
>>> be extremely focused / self-directed and be willing to put in a 
>>> *considerable* amount of time. I'm of course willing to help in whatever 
>>> way I can as far as imple

Re: Defining custom tags using hiccup ?

[Dave Sann]

see this commit for main changes to hiccup

https://github.com/davesann/hiccup/commit/e8c06d884eb22a2cdd007f880a9dd5e1c13669a4

On Thursday, 25 April 2013 18:55:52 UTC+10, Dave Sann wrote:
>
> I replied to this a long time ago and in the original case - I did not see 
> huge value in the suggestion. But recently I wanted to do exactly what 
> Murtaza suggests.
>
> There are a couple of reasons why I think this capability would be useful. 
> (And rereading Murtaza's email - I think this is what he meant)
>
> 1. The functions defined in hiccup and other libraries are not portable. 
> if you rely on these, they will only work if the library maintained has 
> copied the function interface exactly. This is not always the case. (as a 
> separate comment these utility functions 
> would be better separated from the rendering code).
>
> 2. I would be great to write markup that describes your domain, not HTML so
> [:address :street "here" :city "there"]
>
> rather than [:div lots of html specific bits ... street...]
>
> 3. It would be great to be able to switch the rendering of your domain 
> without editing the overall markup structure.
>
> 4. if webcomponents take off - which I hope they do - you may be able to 
> gracefully transition by disabling the various tag rewriting again, not 
> touching the main markup logic.
>
> So I had a look to see if this can be done - and it can - relatively 
> easily. 
> I implemented it the easiest way initially - but there are alternative 
> possibilities for how this might work. Currently it uses a multimethod - 
> but it might be better to pass in "tag expanding functions" when rendering 
> - this would be more flexible.
>
> The changes to hiccup to achieve this are quite minor.
>
> See here: https://github.com/davesann/hiccup/commit/custom-tags
>
> I added a basic repl example file
> https://github.com/davesann/hiccup/blob/custom-tags/repl/example.clj
>
> A nice thing here is that incompatibilities between hiccup and cljs 
> equivalents could be mitigated if we could agree on a "standard" for 
> allowing custom tags.
>
> Thoughts anyone?
>
> Dave
>
>
>
>
>
>
>
>
> On Monday, 14 May 2012 00:31:48 UTC+10, Walter Tetzner wrote:
>>
>> You could do this without adding anything to hiccup.
>>
>> If you wrote a function that, say, used walk, you could have it go
>> through the vectors, and replace the custom tags with what they
>> represent. Then you could just call that before calling `html'.
>>
>> (html
>>   (transform
>> [:html
>>   [:head
>> [:title "some page"]]
>>   [:body
>> [:link-to {:url "http://www.google.com/"} "Hi this is 
>> Google"]]]))
>>
>> The benefit to doing it this way over having the macro is that it's
>> clear where the custom tags come from when looking at the invocation
>> of `html'.
>>
>> If you really want `html' to handle it, maybe it could be called with
>> a map of tranform functions?
>>
>> (html {:link-to link-to}
>>  [:html
>>[:head
>>  [:title "some page"]]
>>   [:body
>> [:link-to {:url "http://www.google.com/"} "Hi this is Google"]]])
>>
>> Either way, I think this ends up being nicer than a macro that changes
>> the behavior of `html'.
>>
>>
>> On Sunday, May 13, 2012 12:35:46 AM UTC-4, Murtaza Husain wrote:
>>>
>>>
>>>

-- 
-- 
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: Defining custom tags using hiccup ?

[Dave Sann]

I replied to this a long time ago and in the original case - I did not see 
huge value in the suggestion. But recently I wanted to do exactly what 
Murtaza suggests.

There are a couple of reasons why I think this capability would be useful. 
(And rereading Murtaza's email - I think this is what he meant)

1. The functions defined in hiccup and other libraries are not portable. if 
you rely on these, they will only work if the library maintained has copied 
the function interface exactly. This is not always the case. (as a separate 
comment these utility functions 
would be better separated from the rendering code).

2. I would be great to write markup that describes your domain, not HTML so
[:address :street "here" :city "there"]

rather than [:div lots of html specific bits ... street...]

3. It would be great to be able to switch the rendering of your domain 
without editing the overall markup structure.

4. if webcomponents take off - which I hope they do - you may be able to 
gracefully transition by disabling the various tag rewriting again, not 
touching the main markup logic.

So I had a look to see if this can be done - and it can - relatively 
easily. 
I implemented it the easiest way initially - but there are alternative 
possibilities for how this might work. Currently it uses a multimethod - 
but it might be better to pass in "tag expanding functions" when rendering 
- this would be more flexible.

The changes to hiccup to achieve this are quite minor.

See here: https://github.com/davesann/hiccup/commit/custom-tags

I added a basic repl example file
https://github.com/davesann/hiccup/blob/custom-tags/repl/example.clj

A nice thing here is that incompatibilities between hiccup and cljs 
equivalents could be mitigated if we could agree on a "standard" for 
allowing custom tags.

Thoughts anyone?

Dave








On Monday, 14 May 2012 00:31:48 UTC+10, Walter Tetzner wrote:
>
> You could do this without adding anything to hiccup.
>
> If you wrote a function that, say, used walk, you could have it go
> through the vectors, and replace the custom tags with what they
> represent. Then you could just call that before calling `html'.
>
> (html
>   (transform
> [:html
>   [:head
> [:title "some page"]]
>   [:body
> [:link-to {:url "http://www.google.com/"} "Hi this is Google"]]]))
>
> The benefit to doing it this way over having the macro is that it's
> clear where the custom tags come from when looking at the invocation
> of `html'.
>
> If you really want `html' to handle it, maybe it could be called with
> a map of tranform functions?
>
> (html {:link-to link-to}
>  [:html
>[:head
>  [:title "some page"]]
>   [:body
> [:link-to {:url "http://www.google.com/"} "Hi this is Google"]]])
>
> Either way, I think this ends up being nicer than a macro that changes
> the behavior of `html'.
>
>
> On Sunday, May 13, 2012 12:35:46 AM UTC-4, Murtaza Husain wrote:
>>
>>
>>

-- 
-- 
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: Question about code style

[Stefan Kamphausen]

You might want to consider adding it to 
https://github.com/bbatsov/clojure-style-guide :-)


-- 
-- 
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: Performance of calling primitive type hinted functions passed as arguments

[Gunnar Völkel]

Some time ago I dug into primitive type hints and how the Clojure compiler 
uses them.
When the compiler finds primitive type hints on a function, say (defn f 
[^long n] ...), the generated class for that function implements a 
primitive interface, IFn$LO in this case,
and generates appropriate code in the interface's only method Object 
invokePrim(long arg0).

For a defn which is used as symbol in code the compiler detects the 
primitive interface and generates code using invokePrim if the infered type 
of the parameters matches.
Long story short, currently the compiler is not able to use primitive 
invocation for higher order functions automatically because it would need 
to generate code that checks at runtime.

You can fix this with Java interop. I implemented an `invoke-primitive` 
macro over here: https://gist.github.com/guv/5458038
It could be used like follows: 
(defn calc [^long n] ...)
(defn dosomething [f, ^long n]
  (invoke-primitive O [L] f n))

The macro expands to (.invokePrim ^IFn$LO f n) using several checks at 
compile time.


Am Mittwoch, 24. April 2013 19:15:49 UTC+2 schrieb Alice:
>
> So, is there a way to type hint on cb that it has a function accepting 
> a long argument? 
>
> On Apr 25, 12:55 am, Stuart Sierra  
> wrote: 
> > I'm taking a guess here: The compiler doesn't know the type signature of 
> > `cb` when compiling `foo`, so it's going to use the IFn.invoke(Object) 
> > signature. Clojure's type inference is only local, and it won't assume 
> that 
> > a primitive-type signature is available for an arbitrary function. 
> > 
> > So there's probably some extra typecasting going on when `fn` is 
> > type-hinted to a primitive. 
> > 
> > In general, type-hinting to primitive types doesn't do you any good in 
> the 
> > presence of higher-order functions like `map`. 
> > 
> > -S 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > On Wednesday, April 24, 2013 11:35:11 AM UTC-4, Alice wrote: 
> > 
> > > (defn foo [^long l cb] (cb l)) 
> > 
> > > (time 
> > >   (dotimes [n 100] 
> > > (foo n (fn [l] nil 
> > 
> > > (time 
> > >   (dotimes [n 100] 
> > > (foo n (fn [^long l] nil 
> > 
> > > "Elapsed time: 7.861 msecs" 
> > > "Elapsed time: 11.770973 msecs" 
> > 
> > > Why is the latter slower? 
>

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