Re: wally: a alternative way to discover functions

[Islon Scherer]

Florian: I filter out all functions that end with ! but I can't know for 
sure which functions have side effects.

On Sunday, September 8, 2013 7:24:48 AM UTC+2, Florian Over wrote:
>
> Hi,
> you could check for io! to find forms with side-effect, but i think it is 
> seldom used.
> Florian
>
> http://clojuredocs.org/clojure_core/clojure.core/io!
>
>
> 2013/9/8 Maximilien Rzepka >
>
>> Found many times apropos useful...
>> user> (apropos "partition")
>> (partition-by partition-all partition)
>>
>> But wally approach is really cool.
>> Thanks for sharing 
>> @maxrzepka
>>
>> Le jeudi 5 septembre 2013 23:23:28 UTC+2, Islon Scherer a écrit :
>>
>>> Hey guys,
>>>
>>> I don't know about you but when I was a beginner in Clojure (and it 
>>> still happens every now and then) I had a hard time finding functions using 
>>> `doc` or `find-doc`,
>>> normally because I didn't remember the name of the function or because 
>>> my only clue was a generic name so find-doc would return too much results. 
>>> But one
>>> thing I knew: what to expect of the function, I knew the inputs and the 
>>> outputs. That's why I decided to create wally, because sometimes you don't
>>> know the name of the function you want but you know how it should behave.
>>>
>>> With wally you can tell the inputs and the output and it'll search for 
>>> functions that match those inputs/outputs.
>>>
>>> Ex:
>>>
>>> user=> (find-by-sample {1 1, 2 3, 3 1, 4 2} [1 2 3 4 4 2 
>>> 2])-clojure.core/frequencies([coll])
   Returns a map from distinct items in coll to the number of times
   they appear.


>>> user=> (find-by-sample '((1 2 3) (4 5)) (partial < 3) [1 2 3 4 5])
 -
 clojure.core/partition-by
 ([f coll])
   Applies f to each value in coll, splitting it each time f returns
a new value.  Returns a lazy seq of partitions.

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

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

Best way to pass through named arguments (destructured map)?

[Mark Mandel]

Hey all,

Relatively new to Clojure, and I'm wondering if there is a better/simpler 
way to handle what I'm doing.

I'm working with the Elastisch library for interacting with ElasticSearch, 
and it has the following function:
http://reference.clojureelasticsearch.info/clojurewerkz.elastisch.rest.document.html#var-search

(search index mapping-type & {:as options})

That's all fine, except I want to call it from another function, to provide 
my default values for `index`, but still allow for the passthrough the 
options map for the `search` function.

The solution I came up with was:

(defn search
"Search the mapping-type, with the given properties"
[mapping-type & {:as options}]
(apply esd/search (reduce (fn [coll [k, v]] (conj coll k v)) [es-index 
mapping-type] options)))

Where `es-index` is already defined as a global def.

So basically I break the options apart into a vector, and apply it over the 
top of the esd/search function (where esd is the elastisch function defined 
earlier).

Does this make sense? Is there a better way?

It works, but wondering if there is an improvement I could make, especially 
as I could see myself doing this quite often.

Thanks in advance,

Mark


-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Best way to pass through named arguments (destructured map)?

[Ulises]

If you're not planning on changing the value of your defined index,
you can always use partial, e.g.:

(def search (partial es/search es-index))

On 9 September 2013 09:42, Mark Mandel  wrote:
> Hey all,
>
> Relatively new to Clojure, and I'm wondering if there is a better/simpler
> way to handle what I'm doing.
>
> I'm working with the Elastisch library for interacting with ElasticSearch,
> and it has the following function:
> http://reference.clojureelasticsearch.info/clojurewerkz.elastisch.rest.document.html#var-search
>
> (search index mapping-type & {:as options})
>
> That's all fine, except I want to call it from another function, to provide
> my default values for `index`, but still allow for the passthrough the
> options map for the `search` function.
>
> The solution I came up with was:
>
> (defn search
> "Search the mapping-type, with the given properties"
> [mapping-type & {:as options}]
> (apply esd/search (reduce (fn [coll [k, v]] (conj coll k v)) [es-index
> mapping-type] options)))
>
> Where `es-index` is already defined as a global def.
>
> So basically I break the options apart into a vector, and apply it over the
> top of the esd/search function (where esd is the elastisch function defined
> earlier).
>
> Does this make sense? Is there a better way?
>
> It works, but wondering if there is an improvement I could make, especially
> as I could see myself doing this quite often.
>
> Thanks in advance,
>
> Mark
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: Best way to pass through named arguments (destructured map)?

[Meikel Brandmeyer (kotarak)]

Hi,

Am Montag, 9. September 2013 10:42:57 UTC+2 schrieb Mark Mandel:
>
>
> (search index mapping-type & {:as options})
>
>
>
You don't have to use a map in the destructuring.

(defn search
  "Docstring"
  [mapping-type & options]
  (apply esd/search es-index mapping-type options))

Kind regards
Meikel
 

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Putting in alts! - haven't seen it used

[Cedric Greevey]

It sounds possibly useful for a form of "load balancing". You have a
producer put onto any of several channels, each with a consumer. If some
consumers are backlogged the put will go to one that isn't backlogged,
instead of blocking, if there's a consumer available. For a CPU-bound task
where the consumer does jobs and the producer hands out jobs, you'd want as
many consumers as there are hardware CPU cores, or maybe slightly more.
Even if the jobs varied somewhat in size that might keep all the cores busy
until there was almost no work left to be done (vs. handing out jobs in
round-robin fashion, or pre-dividing the work among the CPUs).


On Mon, Sep 9, 2013 at 1:32 AM, Sean Corfield wrote:

> Ah, I missed the 'put' part of it. No, haven't used that aspect yet.
>
> On Sun, Sep 8, 2013 at 10:09 PM, Timothy Baldridge 
> wrote:
> > He's talking about puts and alts. You can actually do multiple puts at
> once
> > inside an alts! and only one of them will be used. Yes I haven't seen
> them
> > used either, I'm sure there's a use case, I haven't found it yet though.
> >
> > Timothy
> >
> >
> > On Sun, Sep 8, 2013 at 9:35 PM, Sean Corfield 
> > wrote:
> >>
> >> We're using alts! to take a value or timeout, as part of machinery to
> >> detect whether a popup opens or is blocked.
> >>
> >> On Sun, Sep 8, 2013 at 7:21 PM, Alan Shaw  wrote:
> >> > I'm accustomed to using alts! to allow taking from a collection of
> >> > core.async ports, but haven't come up with a use case for a put in
> >> > alts!,
> >> > either with or without takes.
> >> > Have you?
> >> >
> >> > -A
> >> >
> >> > --
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups "Clojure" group.
> >> > To post to this group, send email to clojure@googlegroups.com
> >> > Note that posts from new members are moderated - please be patient
> with
> >> > your
> >> > first post.
> >> > To unsubscribe from this group, send email to
> >> > clojure+unsubscr...@googlegroups.com
> >> > For more options, visit this group at
> >> > http://groups.google.com/group/clojure?hl=en
> >> > ---
> >> > You received this message because you are subscribed to the Google
> >> > Groups
> >> > "Clojure" group.
> >> > To unsubscribe from 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.
> >>
> >>
> >>
> >> --
> >> Sean A Corfield -- (904) 302-SEAN
> >> An Architect's View -- http://corfield.org/
> >> World Singles, LLC. -- http://worldsingles.com/
> >>
> >> "Perfection is the enemy of the good."
> >> -- Gustave Flaubert, French realist novelist (1821-1880)
> >>
> >> --
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> ---
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Clojure" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to clojure+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
> >
> >
> > --
> > “One of the main causes of the fall of the Roman Empire was that–lacking
> > zero–they had no way to indicate successful termination of their C
> > programs.”
> > (Robert Firth)
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe f

Re: Best way to pass through named arguments (destructured map)?

[Alex Fowler]

I would also add that in case, if you *need* to destructure the `options` 
map for some reason, like:

`(defn search
  "Docstring"
  [mapping-type & {:keys [option-1 option-2] :as options}]
  (do-smth-with-option-1 ...)
  (apply esd/search es-index mapping-type options))`

then you can use `mapply` to apply maps to functions that accept optional 
args maps. The code of mapply is the fllowing:

`(defn mapply [f & args] (apply f (apply concat (butlast args) (last 
args`

Combining it with partial, as adviced, could give you the functionality you 
may sometimes need:

`(mapply (partial es/search es-index) your-options-map)`



понедельник, 9 сентября 2013 г., 12:42:57 UTC+4 пользователь Mark Mandel 
написал:
>
> Hey all,
>
> Relatively new to Clojure, and I'm wondering if there is a better/simpler 
> way to handle what I'm doing.
>
> I'm working with the Elastisch library for interacting with ElasticSearch, 
> and it has the following function:
>
> http://reference.clojureelasticsearch.info/clojurewerkz.elastisch.rest.document.html#var-search
>
> (search index mapping-type & {:as options})
>
> That's all fine, except I want to call it from another function, to 
> provide my default values for `index`, but still allow for the passthrough 
> the options map for the `search` function.
>
> The solution I came up with was:
>
> (defn search
> "Search the mapping-type, with the given properties"
> [mapping-type & {:as options}]
> (apply esd/search (reduce (fn [coll [k, v]] (conj coll k v)) [es-index 
> mapping-type] options)))
>
> Where `es-index` is already defined as a global def.
>
> So basically I break the options apart into a vector, and apply it over 
> the top of the esd/search function (where esd is the elastisch function 
> defined earlier).
>
> Does this make sense? Is there a better way?
>
> It works, but wondering if there is an improvement I could make, 
> especially as I could see myself doing this quite often.
>
> Thanks in advance,
>
> Mark
>
>
>

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

Re: Clojure and freelancing

[Alex Fowler]

As for your question, the answer is: absolutely suitable. From my personal 
experience, http://www.luminusweb.net/ gives a good start. People say that 
Pedestal is gonna be great too, but I did not use it yet.

понедельник, 9 сентября 2013 г., 0:31:13 UTC+4 пользователь Mateusz Dobek 
написал:
>
> Is Clojure good choice for one-man-webdevelopment-team?
>
> I switched form Ruby on Rails, and now I'm learing Clojure.  It seems to 
> be really powerfull language, but will it suits for web? 
> Wanna give it a try in Pedestal framework.
>

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

[Alex Fowler]

That's really cool! Was always wondering if there's gone be something like 
that ever.. Gonna be visiting often! Wish also that it'd be near 
clojuredocs in search results if you google like "clojure parse", but 
that'a a different effort, I suppose.. keep up!

воскресенье, 8 сентября 2013 г., 12:07:33 UTC+4 пользователь Steven Degutis 
написал:
>
> ClojureDocs.org is pretty awesome, I think I use it nearly every day, 
> especially for the Examples and See Also sections. But sometimes I've 
> been wishing it had Clojure 1.5.1 support. For example, I think as-> 
> and cond-> would have been easier for me to pick up had there been 
> entries for these with community-driven Examples. 
>
> A while back, someone told me "complaining is laziness". So I worked 
> on an experiment that I'd like to propose to you all. It's a github 
> wiki that's been seeded with data scraped from in-process docs and 
> clojuredocs.org's API. Here it is: 
>
> https://github.com/sdegutis/clojuredocs/wiki 
>
> Pros: 
> - Docs are for Clojure 1.5.1 
> - Anyone logged into github can edit it 
> - Any part of it can be edited (to fix typos in docstring, etc) 
> - All namespaces are shown on the Home page for easy searching 
> - Free hosting, free database storage :) 
>
> Cons: 
> - Doesn't have dynamic relevance-based search field 
> - Doesn't have an API (but an external one could be built) 
> - Doesn't have Quick Ref tables (yet) 
> - A few URLs are kind of ugly 
> - The namespace-navigation bar is gone, you'd have to click Home 
> - Doesn't store nearly as much data as clojuredocs.org does 
>
> (But as usual, pros/cons are totally subjective to individual needs. 
> This is just how I saw it. These tables may be reversed for you, who 
> knows.) 
>
> Right now, it only has core namespaces. But I've made it easy to add 
> data from new namespaces, so long as the right dependencies are added 
> to project.clj. 
>
> Thoughts? 
>
> -Steven 
>

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

Re: Best way to pass through named arguments (destructured map)?

[Meikel Brandmeyer (kotarak)]

Hi,

Am Montag, 9. September 2013 12:31:30 UTC+2 schrieb Alex Fowler:
>
> I would also add that in case, if you *need* to destructure the `options` 
> map for some reason, like:
>
> `(defn search
>   "Docstring"
>   [mapping-type & {:keys [option-1 option-2] :as options}]
>   (do-smth-with-option-1 ...)
>   (apply esd/search es-index mapping-type options))`
>
> then you can use `mapply` to apply maps to functions that accept optional 
> args maps. The code of mapply is the fllowing:
>
> `(defn mapply [f & args] (apply f (apply concat (butlast args) (last 
> args`
>
> Combining it with partial, as adviced, could give you the functionality 
> you may sometimes need:
>
> `(mapply (partial es/search es-index) your-options-map)`
>
>
You don't have to destructure in the argument list:

(defn search
  [mapping-type & options]
  (let [{:keys [option-1]} options
index (index-based-on option-1)]
(apply esd/search index mapping-type options)))

Kind regards
Meikel

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

How to pass clojure.core/read-str reader-forms to clojure.tools.reader.edn/read-str?

[Joachim De Beule]

Hi List,

As documented at http://clojure.org/reader, defining a record with 
defrecord also installs a reader form, e.g.:

(ns test)
(defrecord X [a b])
(read-string "#test.X{:a :foo, :b :bar})
=> test.X{:a :foo, :b :bar}

However, the record reader form does not seem to be visible 
to clojure.tools.reader.edn/read-str:

(clojure.tools.reader.edn/read-str  "#test.X{:a :foo, :b :bar})
=> ExceptionInfo No reader function for tag test.X ...

So my questions are:

1) Is it really required that any non-standard reader-forms are passed to 
clojure.tools.reader.edn/read-str 
(via the :readers option)? and 

2) If so, how do I get to the reader-forms of clojure.core/read-str, e.g. 
for reading records?

Thanks!
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: How to pass clojure.core/read-str reader-forms to clojure.tools.reader.edn/read-str?

[Nicola Mometto]

Hi,
The EDN reader (both clojure.tools.reader.edn and clojure.edn) don't
read record/type literals by design.

You need to use the clojure reader for that or read them as tagged
literals.

Joachim De Beule writes:

> Hi List,
>
> As documented at http://clojure.org/reader, defining a record with
> defrecord also installs a reader form, e.g.:
>
> (ns test)
> (defrecord X [a b])
> (read-string "#test.X{:a :foo, :b :bar})
> => test.X{:a :foo, :b :bar}
>
> However, the record reader form does not seem to be visible
> to clojure.tools.reader.edn/read-str:
>
> (clojure.tools.reader.edn/read-str  "#test.X{:a :foo, :b :bar})
> => ExceptionInfo No reader function for tag test.X ...
>
> So my questions are:
>
> 1) Is it really required that any non-standard reader-forms are passed to 
> clojure.tools.reader.edn/read-str
> (via the :readers option)? and
>
> 2) If so, how do I get to the reader-forms of clojure.core/read-str, e.g.
> for reading records?
>
> Thanks!
> 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: How to pass clojure.core/read-str reader-forms to clojure.tools.reader.edn/read-str?

[Meikel Brandmeyer (kotarak)]

Hi,

Am Montag, 9. September 2013 14:21:12 UTC+2 schrieb Joachim De Beule:
>
> So my questions are:
>
> 1) Is it really required that any non-standard reader-forms are passed to 
> clojure.tools.reader.edn/read-str 
> (via the :readers option)? and 
>
> 2) If so, how do I get to the reader-forms of clojure.core/read-str, e.g. 
> for reading records?
>
>
I don't know about the first, but second should be quite easy: (edn/read 
{:readers {'test.X map->X}} ).

Kind regards
Meikel 

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Putting in alts! - haven't seen it used

[Timothy Baldridge]

Or just have multiple takers from the same channel, here's the code I
normally use:

(def c (let [c (chan 4)]
  (dotimes [x 4]
(go (loop []
(when-let [v (! c "data")

With a large enough queue size, you'd get all the benefits you mentioned
(the producer can run ahead of the consumers). And we can do this without
Alts!. alts! are cheap, but they aren't free, this code ^^ has the slight
performance benefit of not needing to use alts at all.

Timothy



On Mon, Sep 9, 2013 at 3:11 AM, Cedric Greevey  wrote:

> It sounds possibly useful for a form of "load balancing". You have a
> producer put onto any of several channels, each with a consumer. If some
> consumers are backlogged the put will go to one that isn't backlogged,
> instead of blocking, if there's a consumer available. For a CPU-bound task
> where the consumer does jobs and the producer hands out jobs, you'd want as
> many consumers as there are hardware CPU cores, or maybe slightly more.
> Even if the jobs varied somewhat in size that might keep all the cores busy
> until there was almost no work left to be done (vs. handing out jobs in
> round-robin fashion, or pre-dividing the work among the CPUs).
>
>
> On Mon, Sep 9, 2013 at 1:32 AM, Sean Corfield wrote:
>
>> Ah, I missed the 'put' part of it. No, haven't used that aspect yet.
>>
>> On Sun, Sep 8, 2013 at 10:09 PM, Timothy Baldridge 
>> wrote:
>> > He's talking about puts and alts. You can actually do multiple puts at
>> once
>> > inside an alts! and only one of them will be used. Yes I haven't seen
>> them
>> > used either, I'm sure there's a use case, I haven't found it yet though.
>> >
>> > Timothy
>> >
>> >
>> > On Sun, Sep 8, 2013 at 9:35 PM, Sean Corfield 
>> > wrote:
>> >>
>> >> We're using alts! to take a value or timeout, as part of machinery to
>> >> detect whether a popup opens or is blocked.
>> >>
>> >> On Sun, Sep 8, 2013 at 7:21 PM, Alan Shaw  wrote:
>> >> > I'm accustomed to using alts! to allow taking from a collection of
>> >> > core.async ports, but haven't come up with a use case for a put in
>> >> > alts!,
>> >> > either with or without takes.
>> >> > Have you?
>> >> >
>> >> > -A
>> >> >
>> >> > --
>> >> > --
>> >> > You received this message because you are subscribed to the Google
>> >> > Groups "Clojure" group.
>> >> > To post to this group, send email to clojure@googlegroups.com
>> >> > Note that posts from new members are moderated - please be patient
>> with
>> >> > your
>> >> > first post.
>> >> > To unsubscribe from this group, send email to
>> >> > clojure+unsubscr...@googlegroups.com
>> >> > For more options, visit this group at
>> >> > http://groups.google.com/group/clojure?hl=en
>> >> > ---
>> >> > You received this message because you are subscribed to the Google
>> >> > Groups
>> >> > "Clojure" group.
>> >> > To unsubscribe from 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.
>> >>
>> >>
>> >>
>> >> --
>> >> Sean A Corfield -- (904) 302-SEAN
>> >> An Architect's View -- http://corfield.org/
>> >> World Singles, LLC. -- http://worldsingles.com/
>> >>
>> >> "Perfection is the enemy of the good."
>> >> -- Gustave Flaubert, French realist novelist (1821-1880)
>> >>
>> >> --
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups "Clojure" group.
>> >> To post to this group, send email to clojure@googlegroups.com
>> >> Note that posts from new members are moderated - please be patient with
>> >> your first post.
>> >> To unsubscribe from this group, send email to
>> >> clojure+unsubscr...@googlegroups.com
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/clojure?hl=en
>> >> ---
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "Clojure" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> an
>> >> email to clojure+unsubscr...@googlegroups.com.
>> >> For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>> >
>> >
>> > --
>> > “One of the main causes of the fall of the Roman Empire was that–lacking
>> > zero–they had no way to indicate successful termination of their C
>> > programs.”
>> > (Robert Firth)
>> >
>> > --
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with
>> your
>> > first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojure?hl=en
>> > ---
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Clojure" group.
>> > To unsubscribe from this 

Re: How to pass clojure.core/read-str reader-forms to clojure.tools.reader.edn/read-str?

[Joachim De Beule]

Dear Nicola, Meikel,

Thanks for the quick replies! But is there a way to get at all reader forms 
recognized by clojure.core/read-string automatically, so that I don't have 
to do the bookkeeping of readers myself whenever I define a novel record 
etc?
Of course, I could define my own 'defrecord-and-edn-reader' macro, but this 
seems a bit overkill?

Joachim.

Op maandag 9 september 2013 14:30:20 UTC+2 schreef Meikel Brandmeyer 
(kotarak):
>
> Hi,
>
> Am Montag, 9. September 2013 14:21:12 UTC+2 schrieb Joachim De Beule:
>>
>> So my questions are:
>>
>> 1) Is it really required that any non-standard reader-forms are passed to 
>> clojure.tools.reader.edn/read-str 
>> (via the :readers option)? and 
>>
>> 2) If so, how do I get to the reader-forms of clojure.core/read-str, e.g. 
>> for reading records?
>>
>>
> I don't know about the first, but second should be quite easy: (edn/read 
> {:readers {'test.X map->X}} ).
>
> Kind regards
> Meikel 
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: How to pass clojure.core/read-str reader-forms to clojure.tools.reader.edn/read-str?

[Nicola Mometto]

You could use the :default option of the edn-reader e.g

(import 'clojure.lang.Reflector)
(defn- read-extended-ctor [class map]
  (Reflector/invokeStaticMethod (Class/forName (name class)) "create"
(object-array [map])))

(defrecord x [a b])
(edn/read-string {:default read-extended-ctor} "#user.x{:b 2}")
;=> #user.x{:a nil :b 2}

Joachim De Beule writes:

> Dear Nicola, Meikel,
>
> Thanks for the quick replies! But is there a way to get at all reader forms
> recognized by clojure.core/read-string automatically, so that I don't have
> to do the bookkeeping of readers myself whenever I define a novel record
> etc?
> Of course, I could define my own 'defrecord-and-edn-reader' macro, but this
> seems a bit overkill?
>
> Joachim.
>
> Op maandag 9 september 2013 14:30:20 UTC+2 schreef Meikel Brandmeyer
> (kotarak):
>>
>> Hi,
>>
>> Am Montag, 9. September 2013 14:21:12 UTC+2 schrieb Joachim De Beule:
>>>
>>> So my questions are:
>>>
>>> 1) Is it really required that any non-standard reader-forms are passed to 
>>> clojure.tools.reader.edn/read-str
>>> (via the :readers option)? and
>>>
>>> 2) If so, how do I get to the reader-forms of clojure.core/read-str, e.g.
>>> for reading records?
>>>
>>>
>> I don't know about the first, but second should be quite easy: (edn/read
>> {:readers {'test.X map->X}} ).
>>
>> Kind regards
>> Meikel
>>
>
> --

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Putting in alts! - haven't seen it used

[Philip Potter]

I can suggest one, though I haven't used it for real so can't speak for all
the design tradeoffs:

(alts! [[out val] (timeout N)])

will attempt to write to a consumer, but if the consumer is swamped, will
drop the message on the floor and move on. (I can imagine rewriting this
using alt! so that if the timeout is taken, you can log that you've dropped
something.) This is pretty similar to Sean's use-case, just with a put
instead of a take.


On 9 September 2013 03:21, Alan Shaw  wrote:

> I'm accustomed to using alts! to allow taking from a collection of
> core.async ports, but haven't come up with a use case for a put in alts!,
> either with or without takes.
> Have you?
>
> -A
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.

Clojure & Jruby (Ruby on Rails) Interop

[Ron Toland]

At Rewryte, we use Rails for the web frontend and Clojure for the data 
processing backend for exactly the reasons you described.

We use RabbitMQ to communicate between the two. This maintains separation 
between the two apps (no JRuby required), and lets us scale them both 
independently, while taking advantage of each language/framework's strengths.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: ANN: ClojureScript 0.0-1877 (Breaking change)

[Julien Eluard]

Hi David,

that is really nice! Speedup during incremental build is definitively the one 
thing that would improve my ClojureScript dev workflow.

I gave this build a try with lein-cljsbuild and got some unexpected WARNINGS.

What I am doing:
* lein cljsbuild once => everything is fine
* change some cljs file
* lein cljsbuild once
 => tons of WARNINGS, all variations of "WARNING: Use of undeclared Var 
clojure.string/reduce at line 16 
file:/Users/../clojurescript-0.0-1877.jar!/clojure/string.cljs"

It looks like unchanged cljs files also generate those warnings (but I am not 
quite sure what the incremental compilation does exactly).

Interestingly resulting js file seems correct.

Let me know if I should open a JIRA/create a simple reproducing example.

Thanks for the awesome work on ClojureScript,
Julien


Le dimanche 8 septembre 2013 20:42:51 UTC-3, David Nolen a écrit :
> ClojureScript, the Clojure compiler that emits JavaScript source code.
> 
> 
> README and source code: https://github.com/clojure/clojurescript
> 
> 
> New release version: 0.0-1877
> 
> 
> Leiningen dependency information:
> 
>     [org.clojure/clojurescript "0.0-1877"]
> 
> 
> 
> 
> 
> Breaking Changes: 
> 
> * Keywords are no longer represented as JavaScript Strings
> 
> 
> 
> 
> Enhancements: 
> 
> * Only analyze files that need re-analysis, significant speedup for 
> incremental compilation
> * Leiningen project.clj provided
> 
> 
> Fixes:
> * CLJS-582: duplicate items in sets
> 
> * CLJS-585: ChunkedCons does not implement INext
> * ClojureScript clojure.string/split same behavior as Clojure
> 
> * CLJS-565: Allow the clojurescript reader to read "%"
> * CLJS-580: def + fn bug when fn in a data literal
> 
> * CLJS-509: spurious protocol warning under incremental compilation

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

Clojure, floats, ints and OpenGL

[Alex Fowler]

Hello!

With this letter I would like to receive an answer from somebody from the 
development team (if anyone else has something to say, you're surely 
welcome :) ).

I am working for a big multimedia company and recently I have been 
considering moving to Clojure as the main language of development. We have 
been doing Java and Scala before, but now when I tried Clojure and see the 
possibilities it provides, I would definitely stand for it to be our 
ground. However, while I am so satisfied with everything - the language, 
the community, the Java interop, there is still something that hinders and 
makes me linger. Namely, the lack of good support of floats and ints in the 
language. While many people would not consider it to be a huge disadvantage 
or even notice it, things are not so bright when it comes to OpenGL.

The case is that OpenGL and 3D graphics hardware in general has no support 
for doubles or longs. Therefore, all libraries, all data and all 
computations are meant to be performed with floats and ints (shaders too). 
Due to the lack of good support of these data types in Clojure (for 
example, there are no ^float and ^int typehints, float and int values can 
only be typecasted to, all calculations always retain doubles and longs), 
results in too many extra typecasts, which are absolutely unnecessary and 
take too much time. So, calculations become very cumbersome, even if we do 
not take mandatory boxing into account.

Considering that such kinds of calculations are usually abuntant in the 
aforementioned types of applications, the penalty grows really huge. I have 
endeavoured several discussions on the IRC to find out possible 
workarounds. Although many good proposals by many good people were made, 
aimed at improving the situation, none of them could solve the fundamental 
lack of the ability to manipulate 32bit primitive (or even boxed) data 
types. That lack renders Clojure not really suitable for heavy-load OpenGL 
applications that require somewhat extensive calculations: some kinds of 
games, simulations, generative graphics and so on. Considering how superior 
Clojure is to any other language available for JVM, that black spot looks 
especially embarrasing. And I could imagine falling back to Java for fast 
computations, just like we fall back to ASM in, say C, that is very 
undesirable and discouraging, since we want to pick Clojure for Clojure and 
it will be too cumbersome to make 50/50% Java/Clojure apps just to work 
around that design decision.

Therefore, while deciding if to pick Clojure as the base for our 
development, I would like to know answers to the following questions:

1) What is the current reason for the support for these types to be missing?
2) Are there any plans for improvement of support for floats, ints and 
maybe, localized unboxed calculations? Or is there some advice on how to 
enable their support?
3) What is you vision for Clojure + OpenGL applications?
4) Is it possible to request support for floats, ints and maybe shorts for 
the language?
5) Is it possible to request support for localized unboxed calculations, 
like (with-unboxed ... ) and localized float-only and int-only 
calculations, like, say in special macros (with-floats-&-ints ... here go 
(+) (-) and stuff ONLY with floats/ints ... ) ?

Preferably, I would like to hear the answers from somebody from the 
development team, because I have already received enough support from the 
community, on the IRC, I appreciate it, but now I have to make a serious 
choice for our company and I feel quite responsible for that. I also feel 
that these questions are very important for any specialist that works with 
OpenGL and influence Clojure acceptance for OpenGL-enabled applications 
world-wide. Thank you.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: ANN: ClojureScript 0.0-1877 (Breaking change)

[albert cortez]

I'm getting the same long list of warnings as Julien

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: [ClojureScript] ANN: ClojureScript 0.0-1877 (Breaking change)

[Tim Visher]

On Sun, Sep 8, 2013 at 7:42 PM, David Nolen  wrote:
> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: https://github.com/clojure/clojurescript
>
> New release version: 0.0-1877
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "0.0-1877"]

Which repo was this published to?

--

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: ANN: ClojureScript 0.0-1877 (Breaking change)

[David Nolen]

Are you trying that with an existing project that may have a stale target
directory lying around? If you can reproduce this issue after a `lein
cljsbuild clean` then yes please open a ticket with a minimal project that
exhibits the issue.

Thanks!
David


On Mon, Sep 9, 2013 at 9:18 AM, Julien Eluard wrote:

> Hi David,
>
> that is really nice! Speedup during incremental build is definitively the
> one thing that would improve my ClojureScript dev workflow.
>
> I gave this build a try with lein-cljsbuild and got some unexpected
> WARNINGS.
>
> What I am doing:
> * lein cljsbuild once => everything is fine
> * change some cljs file
> * lein cljsbuild once
>  => tons of WARNINGS, all variations of "WARNING: Use of undeclared Var
> clojure.string/reduce at line 16
> file:/Users/../clojurescript-0.0-1877.jar!/clojure/string.cljs"
>
> It looks like unchanged cljs files also generate those warnings (but I am
> not quite sure what the incremental compilation does exactly).
>
> Interestingly resulting js file seems correct.
>
> Let me know if I should open a JIRA/create a simple reproducing example.
>
> Thanks for the awesome work on ClojureScript,
> Julien
>
>
> Le dimanche 8 septembre 2013 20:42:51 UTC-3, David Nolen a écrit :
> > ClojureScript, the Clojure compiler that emits JavaScript source code.
> >
> >
> > README and source code: https://github.com/clojure/clojurescript
> >
> >
> > New release version: 0.0-1877
> >
> >
> > Leiningen dependency information:
> >
> > [org.clojure/clojurescript "0.0-1877"]
> >
> >
> >
> >
> >
> > Breaking Changes:
> >
> > * Keywords are no longer represented as JavaScript Strings
> >
> >
> >
> >
> > Enhancements:
> >
> > * Only analyze files that need re-analysis, significant speedup for
> incremental compilation
> > * Leiningen project.clj provided
> >
> >
> > Fixes:
> > * CLJS-582: duplicate items in sets
> >
> > * CLJS-585: ChunkedCons does not implement INext
> > * ClojureScript clojure.string/split same behavior as Clojure
> >
> > * CLJS-565: Allow the clojurescript reader to read "%"
> > * CLJS-580: def + fn bug when fn in a data literal
> >
> > * CLJS-509: spurious protocol warning under incremental compilation
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: how to use clojure.java.jdbc.sql

[Abraham]

Thanks

On Monday, September 9, 2013 12:10:13 PM UTC+5:30, Sean Corfield wrote:
>
> The basic DSL cannot do 'like' so you probably want to look at 
> HoneySQL which is the recommended way to extend clojure.java.jdbc. 
>
>
> On Sun, Sep 8, 2013 at 11:07 PM, Abraham > 
> wrote: 
> > 
> > I want to generate sql string using clojure.java.jdbc.sql   for   eg. 
> > 
> > "SELECT  B.ID , B.TITLE ,B.AUTHOR , C.CATEGORY , S.STATUS 
> > FROM  BOOK B ,CATEGORY C , STATUS S 
> > WHERE (B.CATEGORY_ID=C.ID) AND 
> >  (B.STATUS_ID = B.ID) AND 
> >  (B.TITLE LIKE "%TOM%")" 
> > 
> > How to do this using clojure.java.jdbc.sql   dsl functions? 
> > 
> > -- 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com 
> > Note that posts from new members are moderated - please be patient with 
> your 
> > first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com  
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Clojure" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to clojure+u...@googlegroups.com . 
> > For more options, visit https://groups.google.com/groups/opt_out. 
>
>
>
> -- 
> Sean A Corfield -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
> World Singles, LLC. -- http://worldsingles.com/ 
>
> "Perfection is the enemy of the good." 
> -- Gustave Flaubert, French realist novelist (1821-1880) 
>

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

Re: [ANN] Austin — the ClojureScript browser-REPL, rebuilt stronger, faster, easier

[Norman Richards]

On Mon, Aug 5, 2013 at 8:21 AM, Chas Emerick  wrote:

> As you might know, I've been tinkering with an easier-to-use variant of
> ClojureScript's browser-REPL for some time.  I've finally wrapped that up
> into its own project, Austin: [...]
>


Is anyone successfully using this with nrepl in emacs?  I am able to make
it work, but something is causing both emacs and the JVM it is connected to
to use 100% CPU.  I seem to be getting a long stream of "Unable to resolve
symbol: if-let in this context, compiling:(NO_SOURCE_PATH:1:1)"

See: https://gist.github.com/orb/6496320

*nrepl-connection* fills up with:

d2:ex45:class
clojure.lang.Compiler$CompilerException2:id6:1504207:root-ex45:class
clojure.lang.Compiler$CompilerException7:session36:43e688aa-01c2-4824-b1f3-1bd05a1f02446:statusl10:eval-erroreed3:err128:CompilerException
java.lang.RuntimeException: Unable to resolve symbol: if-let in this
context, compiling:(NO_SOURCE_PATH:1:1)


I'm not sure if this is a problem with austin or if it's nrepl.el or
something on the emacs side.

As a side note, I occasionally get a similar error message using straight
nrepl when first starting up, but it usually only happens once.  With
austin/nrepl it appears to be stuck in some kind of loop erroring over and
over...  Does anyone have a known good setup I could try to reproduce?

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: ANN: ClojureScript 0.0-1877 (Breaking change)

[Sean Grove]

Also, a warning about breaking change with the strings no longer being
keywords:

Previously in ClojureScript, strings could be invoked to look themselves up
as keys inside maps, just like keywords. So both (:a {:a 10 "b" 20}) and
("b" {:a 10 "b" 20}) would work (the latter will not work in vanilla
Clojure). We had a few places where we (Zenbox) were doing this without
realizing it (think (defn my-fn [k] (k @profiles)) and k ends up being a
string).

This worked because previously ClojureScript modified the String.prototype
to add a .call and a .apply method. Many of you will have run into problems
with JS interop where this broke other libraries' type-checking (see
https://groups.google.com/forum/#!topic/clojure/NPWnikR8tro for an example
if not).

If you want to upgrade and run into problems with the unmodified
String.prototype, of course the best thing to do would be to write some
tests and fix the problems. If that's not possible, a (very) temporary
workaround is to use the old code here:
https://github.com/clojure/clojurescript/blob/a113b08a8c2811b0590cc6a36b2e9e5adc1c4c1e/src/cljs/cljs/core.cljs#L2060-L2074

Hope this might save some confusing late night debugging sessions.

Best,
Sean


On Mon, Sep 9, 2013 at 7:15 AM, David Nolen  wrote:

> Are you trying that with an existing project that may have a stale target
> directory lying around? If you can reproduce this issue after a `lein
> cljsbuild clean` then yes please open a ticket with a minimal project that
> exhibits the issue.
>
> Thanks!
> David
>
>
> On Mon, Sep 9, 2013 at 9:18 AM, Julien Eluard wrote:
>
>> Hi David,
>>
>> that is really nice! Speedup during incremental build is definitively the
>> one thing that would improve my ClojureScript dev workflow.
>>
>> I gave this build a try with lein-cljsbuild and got some unexpected
>> WARNINGS.
>>
>> What I am doing:
>> * lein cljsbuild once => everything is fine
>> * change some cljs file
>> * lein cljsbuild once
>>  => tons of WARNINGS, all variations of "WARNING: Use of undeclared Var
>> clojure.string/reduce at line 16
>> file:/Users/../clojurescript-0.0-1877.jar!/clojure/string.cljs"
>>
>> It looks like unchanged cljs files also generate those warnings (but I am
>> not quite sure what the incremental compilation does exactly).
>>
>> Interestingly resulting js file seems correct.
>>
>> Let me know if I should open a JIRA/create a simple reproducing example.
>>
>> Thanks for the awesome work on ClojureScript,
>> Julien
>>
>>
>> Le dimanche 8 septembre 2013 20:42:51 UTC-3, David Nolen a écrit :
>> > ClojureScript, the Clojure compiler that emits JavaScript source code.
>> >
>> >
>> > README and source code: https://github.com/clojure/clojurescript
>> >
>> >
>> > New release version: 0.0-1877
>> >
>> >
>> > Leiningen dependency information:
>> >
>> > [org.clojure/clojurescript "0.0-1877"]
>> >
>> >
>> >
>> >
>> >
>> > Breaking Changes:
>> >
>> > * Keywords are no longer represented as JavaScript Strings
>> >
>> >
>> >
>> >
>> > Enhancements:
>> >
>> > * Only analyze files that need re-analysis, significant speedup for
>> incremental compilation
>> > * Leiningen project.clj provided
>> >
>> >
>> > Fixes:
>> > * CLJS-582: duplicate items in sets
>> >
>> > * CLJS-585: ChunkedCons does not implement INext
>> > * ClojureScript clojure.string/split same behavior as Clojure
>> >
>> > * CLJS-565: Allow the clojurescript reader to read "%"
>> > * CLJS-580: def + fn bug when fn in a data literal
>> >
>> > * CLJS-509: spurious protocol warning under incremental compilation
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from 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://grou

Re: Clojure & Jruby (Ruby on Rails) Interop

[Oleksandr Petrov]

Forgot to mention, Zweikopf comes as a Ruby gem and as a Clojure library.
You should make a decision though wether you're running Ruby scripting
container from Clojure or start Clojure runtime from Ruby...


On Mon, Sep 9, 2013 at 5:50 PM, Oleksandr Petrov  wrote:

> I've been working with an application that written in Ruby and Clojure.
> Nothing forbids you from using some messaging system for communication
> between Ruby and Clj, although we required direct access to Ruby from
> Clojure and vice versa.
>
> That's pretty much how Zweikopf was born:
> http://github.com/ifesdjeen/zweikopf
>
> With Zweikopf you can call Ruby code from Clojure and Clojure code from
> Ruby, given that Runtime was registered properly. You can convert any
> Clojure data structure to Ruby one
> and back, custom serialisation, circular dependency detection included.
>
> I would suggest not using any serialisation means if you intend running
> both languages in a single process / JVM. That would add a significant
> overhead and you won't be able to have
> direct access to whatever class you may need at given time without
> wrapping it into some RPC container.
>
>
>
> On Mon, Sep 9, 2013 at 4:47 PM, rdelcueto  wrote:
>
>> Hey Ron,
>> Thanks for your response. Digging deeper into my question...
>>
>> When I read about the Torquebox Immutant duet, I thought it was
>> particularly interesting solution, because it was fairly easy to deploy and
>> both processes would live inside a JVM environment. I was impressed by how
>> Clojure data structures mapped to Ruby structures and vice-versa, it seemed
>> to provide a very clean and idiomatic messaging platform. Plus it would
>> provide tools for caching, clustering, and what not. Still I wasn't very
>> keen on the JRuby subject, since It's known to have compatibility issues
>> with certain gems.
>>
>> Yesterday while researching on the subject I found about ZeroMQ. Do you
>> have any particular reason to use RabbitMQ over other messaging libraries?
>> Are there any caveats to your interop model?
>> How portable is deploying a site using a messaging solution such as
>> RabbitMQ?
>>
>> I also found out about Google's Protocol Buffers, they seemed like a
>> lightweight solution to pass language agnostic data structures through the
>> messaging infrastructure.
>> Do messages need to be encapsulated somehow, or is this actually
>> unnecessary? How it's done in your case?
>>
>> Regarding security and sensible information interop; Should messages be
>> encrypted? Should they be encrypted as a whole message or partially (only
>> sensible data)?
>> What are the performance implications of this pipeline? Is the overhead
>> and footprint of such setup (Ruby + Messaging Broker + ClojureJVM) big
>> enough, for it to be worth thinking on writing everything in Clojure (using
>> the Luminus framework)?
>>
>>
>> On Monday, September 9, 2013 8:10:41 AM UTC-5, Ron Toland wrote:
>>>
>>> At Rewryte, we use Rails for the web frontend and Clojure for the data
>>> processing backend for exactly the reasons you described.
>>>
>>> We use RabbitMQ to communicate between the two. This maintains
>>> separation between the two apps (no JRuby required), and lets us scale them
>>> both independently, while taking advantage of each language/framework's
>>> strengths.
>>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from 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.
>>
>
>
>
> --
> alex p
>



-- 
alex p

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

Re: Clojure & Jruby (Ruby on Rails) Interop

[Jim Crossley]

Hi Rodrigo,

I'm one of the developers of TorqueBox and Immutant. Your email prompted me
to re-watch a screencast [1] I made in March showing how to use them
together. I realized things have changed a little since then, so I added a
few annotations to the video highlighting the differences. Hopefully enough
to get you up and experimenting.

As you've probably figured out, both TorqueBox and Immutant are integrated
stacks, bundling some commodity services that most non-trivial applications
need, e.g. scheduling, caching, and messaging. The intent of any integrated
platform is to relieve administration burden. But that only works for you
if the inherent choices within that stack fit the needs of your app. We
think/hope default Immutant configuration and abstractions (e.g. queues,
topics, request/respond) offers a good balance to fit a wide variety of
apps.

If simple integration between Ruby and Clojure apps is your chief goal, I
think Immutant/TorqueBox is compelling, but I'm biased. I would definitely
recommend using some sort of messaging broker, though, i.e. don't mix
Clojure and Ruby in the same source file or project.

Performance and security concerns are so application-specific I hate to
make any generic statements about them other than, "be fast and secure". ;-)

But do feel free to bother us in #torquebox or #immutant on freenode with
any questions about your particular app/needs.

Thanks,
Jim

[1] http://immutant.org/news/2013/03/07/overlay-screencast/



On Sun, Sep 8, 2013 at 10:25 PM, rdelcueto  wrote:

> Hi everyone,
> I'm about to start working on building a site for a startup company.
>
> We are a small team, and currently they've been coding the site using RoR
> (Ruby on Rails). I was thinking Clojure might be better suited for the
> task, specially because we'll need to implement a backend which is robust,
> scalable and secure, but also we'll need flexibility, which I think the RoR
> framework won't shine at all.
>
> At our team, we are two coders, non of us are proficient in Web
> Developing, and we have little experience with RoR, and I thought (I'm
> sure) maybe investing time learning Clojure will provide us with better
> tools.
>
> PROBLEM/QUESTION
>
> While searching for alternative solutions, I stumbled upon the
> Flightcaster case, we're they are using RoR to implement the site's
> frontend and Clojure for the system backend. I thought this was a very
> elegant solution, using each tool for what it's good at. Plus this way we
> can reuse what they've already implemented.
>
> I found a way to do this is by using Torquebox and Immutant, and using the
> messaging systems to communicate between Jruby and Clojure. Still I have no
> idea of how this works, and the performance and security implications it
> brings to the table. I found little information on the subject.
>
> I would appreciate if anyone could provide guidance, examples or
> documentation on the subject.
>
> Any reference to open source projects which use this hybrid language
> solutions on the JVM would be great to have.
>
> Is this the best way to solve the RoR interactions? Is there any other way?
>
> Thanks in advance and best regards,
>
> Rodrigo
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: ANN: ClojureScript 0.0-1877 (Breaking change)

[david]

A large percentage of tests for my core.async based library are failing.  Any 
thoughts?

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: [ClojureScript] Re: ANN: ClojureScript 0.0-1877 (Breaking change)

[David Nolen]

Can't have thoughts without a lot more details :) Specific errors,
warnings, and a minimal case is always ideal.

David


On Mon, Sep 9, 2013 at 12:04 PM,  wrote:

> A large percentage of tests for my core.async based library are failing.
>  Any thoughts?
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.
>

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

[Peter Mancini]

On Sunday, September 8, 2013 11:26:35 PM UTC-5, puzzler wrote:
>
>
> Rather than describing it in terms of how you'd implement it, can you be 
> clearer about the shape of the data and what specific sorts of operations 
> and queries you need to perform quickly on the data?  That would make it 
> easier to brainstorm another way to implement it.
>

Fair point. Here is an example tree:

{"epsilon"
 {:entity {:count 1, :name "epsilon", :n 2},
  :children
  {"phi" {:entity {:count 1, :name "phi", :n 1}, :children {,
 "beta"
 {:entity {:count 1, :name "beta", :n 4},
  :children
  {"delta"
   {:entity {:count 1, :name "delta", :n 3},
:children
{"theta"
 {:entity {:count 1, :name "theta", :n 1}, :children {}},
 "alpha"
 {:entity {:count 2, :name "alpha", :n 7},
  :children
  {"beta"
   {:entity {:count 2, :name "beta", :n 6},
:children
{"theta"
 {:entity {:count 1, :name "theta", :n 2},
  :children
  {"zeta" {:entity {:count 1, :name "zeta", :n 1}, :children {,
 "delta"
 {:entity {:count 1, :name "delta", :n 5},
  :children
  {"gamma"
   {:entity {:count 1, :name "gamma", :n 4}, :children {}

 
It captures the data perfectly and I can find anything by scanning from the 
root to the leaves. The problem is that I may have 1 items off of my 
root and high branch perplexity. The solution there is to have a head list 
of each of the entities and the ability to arbitrarily look into any node 
on the tree and then walk up it getting all of the parents until root. That 
isn't possible with this scheme as is. I thought about adding references 
and using them like pointers but then I run into the problem that the tree 
can't be saved to disk and that I would have to recreate it every time. So 
now I am starting to look at more state of the art methods and anyone who 
has a link to a paper they can share that might help would be greatly 
appreciated if they shared it here.

So, I need the ability to follow a pointer to an arbitrary point in the 
tree, read up and get the results, an ability to save the tree in parts or 
whole and read it back. Finally, have the benefits of the data compression 
that comes with trees and the fast ability to get results that come with 
this scheme.

The data that creates the tree above would look like this:

(def transaction-list [[{:name "alpha" :n 7} {:name "beta" :n 6} {:name 
"delta" :n 5} {:name "gamma" :n 4}]
   [{:name "alpha" :n 4} {:name "beta" :n 3} {:name 
"theta" :n 2} {:name "zeta" :n 1}]
   [{:name "beta" :n 4} {:name "delta" :n 3} {:name 
"theta" :n 1}]
   [{:name "epsilon" :n 2} {:name "phi" :n 1}]])


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

Re: Clojure & Jruby (Ruby on Rails) Interop

[rdelcueto]

Hey Ron,
Thanks for your response. Digging deeper into my question...

When I read about the Torquebox Immutant duet, I thought it was 
particularly interesting solution, because it was fairly easy to deploy and 
both processes would live inside a JVM environment. I was impressed by how 
Clojure data structures mapped to Ruby structures and vice-versa, it seemed 
to provide a very clean and idiomatic messaging platform. Plus it would 
provide tools for caching, clustering, and what not. Still I wasn't very 
keen on the JRuby subject, since It's known to have compatibility issues 
with certain gems.

Yesterday while researching on the subject I found about ZeroMQ. Do you 
have any particular reason to use RabbitMQ over other messaging libraries? 
Are there any caveats to your interop model?
How portable is deploying a site using a messaging solution such as 
RabbitMQ?

I also found out about Google's Protocol Buffers, they seemed like a 
lightweight solution to pass language agnostic data structures through the 
messaging infrastructure.
Do messages need to be encapsulated somehow, or is this actually 
unnecessary? How it's done in your case?

Regarding security and sensible information interop; Should messages be 
encrypted? Should they be encrypted as a whole message or partially (only 
sensible data)?
What are the performance implications of this pipeline? Is the overhead and 
footprint of such setup (Ruby + Messaging Broker + ClojureJVM) big enough, 
for it to be worth thinking on writing everything in Clojure (using the 
Luminus framework)?

On Monday, September 9, 2013 8:10:41 AM UTC-5, Ron Toland wrote:
>
> At Rewryte, we use Rails for the web frontend and Clojure for the data 
> processing backend for exactly the reasons you described.
>
> We use RabbitMQ to communicate between the two. This maintains separation 
> between the two apps (no JRuby required), and lets us scale them both 
> independently, while taking advantage of each language/framework's 
> strengths.
>

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

Re: Clojure, floats, ints and OpenGL

[Timothy Baldridge]

It's worth noting that the restrictions to IFn do not apply to definterface
and deftype. Not that solves all (or any) of your problems, I've used
definterface before to lock down the actual types used.

Timothy


On Mon, Sep 9, 2013 at 11:03 AM, Jozef Wagner wrote:

> You can typehing ints for locals (let, loop), restrictions are just for
> function arguments.
> AFAIK the reason is combinatorial explosion at
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java#L91
> I have the same problem with char. Because I cannot typehint e.g. my
> whitespace? function with ^char, I recieve a boxed Object and thus cannot
> use == for comparison.
>
> JW
>
>
> On Mon, Sep 9, 2013 at 6:02 PM, Mikera wrote:
>
>> +1 for supporting all the JVM primitive types properly.
>>
>> It is worth noting that the benefits would extend much further than just
>> OpenGL, e.g.:
>>  - int is a commonly used type in Java interop. Casting to/from it all
>> the time is a minor annoyance/overhead
>>  - int is the type used for array indexing on the JVM
>>  - all the small (< 8 byte) primitive types save memory footprint, which
>> is important since memory bandwidth is the limiting factor in some workloads
>>  - int/float fit into a register (and therefore perform much better) on
>> 32 bit machines (which still exist, believe it or not)
>>  - char is a pretty useful primitive type if you are doing text processing
>>  - byte is also frequently useful, especially for IO
>>
>> I believe that with some enhancements to the Clojure compiler, supporting
>> all the JVM primitive types shouldn't be too difficult, and it would
>> provide many benefits both in terms of overall performance and interop
>> convenience.
>>
>> On Monday, 9 September 2013 21:43:12 UTC+8, Alex Fowler wrote:
>>>
>>> Hello!
>>>
>>> With this letter I would like to receive an answer from somebody from
>>> the development team (if anyone else has something to say, you're surely
>>> welcome :) ).
>>>
>>> I am working for a big multimedia company and recently I have been
>>> considering moving to Clojure as the main language of development. We have
>>> been doing Java and Scala before, but now when I tried Clojure and see the
>>> possibilities it provides, I would definitely stand for it to be our
>>> ground. However, while I am so satisfied with everything - the language,
>>> the community, the Java interop, there is still something that hinders and
>>> makes me linger. Namely, the lack of good support of floats and ints in the
>>> language. While many people would not consider it to be a huge disadvantage
>>> or even notice it, things are not so bright when it comes to OpenGL.
>>>
>>> The case is that OpenGL and 3D graphics hardware in general has no
>>> support for doubles or longs. Therefore, all libraries, all data and all
>>> computations are meant to be performed with floats and ints (shaders too).
>>> Due to the lack of good support of these data types in Clojure (for
>>> example, there are no ^float and ^int typehints, float and int values can
>>> only be typecasted to, all calculations always retain doubles and longs),
>>> results in too many extra typecasts, which are absolutely unnecessary and
>>> take too much time. So, calculations become very cumbersome, even if we do
>>> not take mandatory boxing into account.
>>>
>>> Considering that such kinds of calculations are usually abuntant in the
>>> aforementioned types of applications, the penalty grows really huge. I have
>>> endeavoured several discussions on the IRC to find out possible
>>> workarounds. Although many good proposals by many good people were made,
>>> aimed at improving the situation, none of them could solve the fundamental
>>> lack of the ability to manipulate 32bit primitive (or even boxed) data
>>> types. That lack renders Clojure not really suitable for heavy-load OpenGL
>>> applications that require somewhat extensive calculations: some kinds of
>>> games, simulations, generative graphics and so on. Considering how superior
>>> Clojure is to any other language available for JVM, that black spot looks
>>> especially embarrasing. And I could imagine falling back to Java for fast
>>> computations, just like we fall back to ASM in, say C, that is very
>>> undesirable and discouraging, since we want to pick Clojure for Clojure and
>>> it will be too cumbersome to make 50/50% Java/Clojure apps just to work
>>> around that design decision.
>>>
>>> Therefore, while deciding if to pick Clojure as the base for our
>>> development, I would like to know answers to the following questions:
>>>
>>> 1) What is the current reason for the support for these types to be
>>> missing?
>>> 2) Are there any plans for improvement of support for floats, ints and
>>> maybe, localized unboxed calculations? Or is there some advice on how to
>>> enable their support?
>>> 3) What is you vision for Clojure + OpenGL applications?
>>> 4) Is it possible to request support for floats, ints and maybe shorts

Re: Clojure, floats, ints and OpenGL

[Timothy Baldridge]

Also, how much of this is a limit of the OpenGL library you are using? The
raw OpenGL API supports glVertex3d and glVertex3f. Is the double version
not supported by your java interface library?

Timothy


On Mon, Sep 9, 2013 at 11:07 AM, Timothy Baldridge wrote:

> It's worth noting that the restrictions to IFn do not apply to
> definterface and deftype. Not that solves all (or any) of your problems,
> I've used definterface before to lock down the actual types used.
>
> Timothy
>
>
> On Mon, Sep 9, 2013 at 11:03 AM, Jozef Wagner wrote:
>
>> You can typehing ints for locals (let, loop), restrictions are just for
>> function arguments.
>> AFAIK the reason is combinatorial explosion at
>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java#L91
>> I have the same problem with char. Because I cannot typehint e.g. my
>> whitespace? function with ^char, I recieve a boxed Object and thus cannot
>> use == for comparison.
>>
>> JW
>>
>>
>> On Mon, Sep 9, 2013 at 6:02 PM, Mikera wrote:
>>
>>> +1 for supporting all the JVM primitive types properly.
>>>
>>> It is worth noting that the benefits would extend much further than just
>>> OpenGL, e.g.:
>>>  - int is a commonly used type in Java interop. Casting to/from it all
>>> the time is a minor annoyance/overhead
>>>  - int is the type used for array indexing on the JVM
>>>  - all the small (< 8 byte) primitive types save memory footprint, which
>>> is important since memory bandwidth is the limiting factor in some workloads
>>>  - int/float fit into a register (and therefore perform much better) on
>>> 32 bit machines (which still exist, believe it or not)
>>>  - char is a pretty useful primitive type if you are doing text
>>> processing
>>>  - byte is also frequently useful, especially for IO
>>>
>>> I believe that with some enhancements to the Clojure compiler,
>>> supporting all the JVM primitive types shouldn't be too difficult, and it
>>> would provide many benefits both in terms of overall performance and
>>> interop convenience.
>>>
>>> On Monday, 9 September 2013 21:43:12 UTC+8, Alex Fowler wrote:

 Hello!

 With this letter I would like to receive an answer from somebody from
 the development team (if anyone else has something to say, you're surely
 welcome :) ).

 I am working for a big multimedia company and recently I have been
 considering moving to Clojure as the main language of development. We have
 been doing Java and Scala before, but now when I tried Clojure and see the
 possibilities it provides, I would definitely stand for it to be our
 ground. However, while I am so satisfied with everything - the language,
 the community, the Java interop, there is still something that hinders and
 makes me linger. Namely, the lack of good support of floats and ints in the
 language. While many people would not consider it to be a huge disadvantage
 or even notice it, things are not so bright when it comes to OpenGL.

 The case is that OpenGL and 3D graphics hardware in general has no
 support for doubles or longs. Therefore, all libraries, all data and all
 computations are meant to be performed with floats and ints (shaders too).
 Due to the lack of good support of these data types in Clojure (for
 example, there are no ^float and ^int typehints, float and int values can
 only be typecasted to, all calculations always retain doubles and longs),
 results in too many extra typecasts, which are absolutely unnecessary and
 take too much time. So, calculations become very cumbersome, even if we do
 not take mandatory boxing into account.

 Considering that such kinds of calculations are usually abuntant in the
 aforementioned types of applications, the penalty grows really huge. I have
 endeavoured several discussions on the IRC to find out possible
 workarounds. Although many good proposals by many good people were made,
 aimed at improving the situation, none of them could solve the fundamental
 lack of the ability to manipulate 32bit primitive (or even boxed) data
 types. That lack renders Clojure not really suitable for heavy-load OpenGL
 applications that require somewhat extensive calculations: some kinds of
 games, simulations, generative graphics and so on. Considering how superior
 Clojure is to any other language available for JVM, that black spot looks
 especially embarrasing. And I could imagine falling back to Java for fast
 computations, just like we fall back to ASM in, say C, that is very
 undesirable and discouraging, since we want to pick Clojure for Clojure and
 it will be too cumbersome to make 50/50% Java/Clojure apps just to work
 around that design decision.

 Therefore, while deciding if to pick Clojure as the base for our
 development, I would like to know answers to the following questions:

 1) What is the current reason for

Re: Clojure, floats, ints and OpenGL

[Jozef Wagner]

You can typehing ints for locals (let, loop), restrictions are just for
function arguments.
AFAIK the reason is combinatorial explosion at
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java#L91
I have the same problem with char. Because I cannot typehint e.g. my
whitespace? function with ^char, I recieve a boxed Object and thus cannot
use == for comparison.

JW


On Mon, Sep 9, 2013 at 6:02 PM, Mikera  wrote:

> +1 for supporting all the JVM primitive types properly.
>
> It is worth noting that the benefits would extend much further than just
> OpenGL, e.g.:
>  - int is a commonly used type in Java interop. Casting to/from it all the
> time is a minor annoyance/overhead
>  - int is the type used for array indexing on the JVM
>  - all the small (< 8 byte) primitive types save memory footprint, which
> is important since memory bandwidth is the limiting factor in some workloads
>  - int/float fit into a register (and therefore perform much better) on 32
> bit machines (which still exist, believe it or not)
>  - char is a pretty useful primitive type if you are doing text processing
>  - byte is also frequently useful, especially for IO
>
> I believe that with some enhancements to the Clojure compiler, supporting
> all the JVM primitive types shouldn't be too difficult, and it would
> provide many benefits both in terms of overall performance and interop
> convenience.
>
> On Monday, 9 September 2013 21:43:12 UTC+8, Alex Fowler wrote:
>>
>> Hello!
>>
>> With this letter I would like to receive an answer from somebody from the
>> development team (if anyone else has something to say, you're surely
>> welcome :) ).
>>
>> I am working for a big multimedia company and recently I have been
>> considering moving to Clojure as the main language of development. We have
>> been doing Java and Scala before, but now when I tried Clojure and see the
>> possibilities it provides, I would definitely stand for it to be our
>> ground. However, while I am so satisfied with everything - the language,
>> the community, the Java interop, there is still something that hinders and
>> makes me linger. Namely, the lack of good support of floats and ints in the
>> language. While many people would not consider it to be a huge disadvantage
>> or even notice it, things are not so bright when it comes to OpenGL.
>>
>> The case is that OpenGL and 3D graphics hardware in general has no
>> support for doubles or longs. Therefore, all libraries, all data and all
>> computations are meant to be performed with floats and ints (shaders too).
>> Due to the lack of good support of these data types in Clojure (for
>> example, there are no ^float and ^int typehints, float and int values can
>> only be typecasted to, all calculations always retain doubles and longs),
>> results in too many extra typecasts, which are absolutely unnecessary and
>> take too much time. So, calculations become very cumbersome, even if we do
>> not take mandatory boxing into account.
>>
>> Considering that such kinds of calculations are usually abuntant in the
>> aforementioned types of applications, the penalty grows really huge. I have
>> endeavoured several discussions on the IRC to find out possible
>> workarounds. Although many good proposals by many good people were made,
>> aimed at improving the situation, none of them could solve the fundamental
>> lack of the ability to manipulate 32bit primitive (or even boxed) data
>> types. That lack renders Clojure not really suitable for heavy-load OpenGL
>> applications that require somewhat extensive calculations: some kinds of
>> games, simulations, generative graphics and so on. Considering how superior
>> Clojure is to any other language available for JVM, that black spot looks
>> especially embarrasing. And I could imagine falling back to Java for fast
>> computations, just like we fall back to ASM in, say C, that is very
>> undesirable and discouraging, since we want to pick Clojure for Clojure and
>> it will be too cumbersome to make 50/50% Java/Clojure apps just to work
>> around that design decision.
>>
>> Therefore, while deciding if to pick Clojure as the base for our
>> development, I would like to know answers to the following questions:
>>
>> 1) What is the current reason for the support for these types to be
>> missing?
>> 2) Are there any plans for improvement of support for floats, ints and
>> maybe, localized unboxed calculations? Or is there some advice on how to
>> enable their support?
>> 3) What is you vision for Clojure + OpenGL applications?
>> 4) Is it possible to request support for floats, ints and maybe shorts
>> for the language?
>> 5) Is it possible to request support for localized unboxed calculations,
>> like (with-unboxed ... ) and localized float-only and int-only
>> calculations, like, say in special macros (with-floats-&-ints ... here go
>> (+) (-) and stuff ONLY with floats/ints ... ) ?
>>
>> Preferably, I would like to hear the answers from somebody from 

Re: Building Trees

[Mark Engelberg]

OK, I'm starting to understand the shape of the data better.  However, you
say, "the ability to arbitrarily look into any node on the tree and then
walk up it getting all of the parents until root."  What does the query for
this look like and specifically what information do you want returned?
What I'm getting at is, are you only querying by name (e.g. "theta") and
hoping to get all the paths down to all the nodes with a name of "theta",
or do you have some other way of distinguishing between the two theta nodes
in the tree, and you only want the path for one of them?  If the latter,
how are you uniquely identifying the nodes?

Is there any other information you need to access than the the upward path
from a node to the root?


On Mon, Sep 9, 2013 at 9:23 AM, Peter Mancini wrote:

> On Sunday, September 8, 2013 11:26:35 PM UTC-5, puzzler wrote:
>>
>>
>> Rather than describing it in terms of how you'd implement it, can you be
>> clearer about the shape of the data and what specific sorts of operations
>> and queries you need to perform quickly on the data?  That would make it
>> easier to brainstorm another way to implement it.
>>
>
> Fair point. Here is an example tree:
>
> {"epsilon"
>  {:entity {:count 1, :name "epsilon", :n 2},
>   :children
>   {"phi" {:entity {:count 1, :name "phi", :n 1}, :children {,
>  "beta"
>  {:entity {:count 1, :name "beta", :n 4},
>   :children
>   {"delta"
>{:entity {:count 1, :name "delta", :n 3},
> :children
> {"theta"
>  {:entity {:count 1, :name "theta", :n 1}, :children {}},
>  "alpha"
>  {:entity {:count 2, :name "alpha", :n 7},
>   :children
>   {"beta"
>{:entity {:count 2, :name "beta", :n 6},
> :children
> {"theta"
>  {:entity {:count 1, :name "theta", :n 2},
>   :children
>   {"zeta" {:entity {:count 1, :name "zeta", :n 1}, :children {,
>  "delta"
>  {:entity {:count 1, :name "delta", :n 5},
>   :children
>   {"gamma"
>{:entity {:count 1, :name "gamma", :n 4}, :children {}
>
>
> It captures the data perfectly and I can find anything by scanning from
> the root to the leaves. The problem is that I may have 1 items off of
> my root and high branch perplexity. The solution there is to have a head
> list of each of the entities and the ability to arbitrarily look into any
> node on the tree and then walk up it getting all of the parents until root.
> That isn't possible with this scheme as is. I thought about adding
> references and using them like pointers but then I run into the problem
> that the tree can't be saved to disk and that I would have to recreate it
> every time. So now I am starting to look at more state of the art methods
> and anyone who has a link to a paper they can share that might help would
> be greatly appreciated if they shared it here.
>
> So, I need the ability to follow a pointer to an arbitrary point in the
> tree, read up and get the results, an ability to save the tree in parts or
> whole and read it back. Finally, have the benefits of the data compression
> that comes with trees and the fast ability to get results that come with
> this scheme.
>
> The data that creates the tree above would look like this:
>
> (def transaction-list [[{:name "alpha" :n 7} {:name "beta" :n 6} {:name
> "delta" :n 5} {:name "gamma" :n 4}]
>[{:name "alpha" :n 4} {:name "beta" :n 3} {:name
> "theta" :n 2} {:name "zeta" :n 1}]
>[{:name "beta" :n 4} {:name "delta" :n 3} {:name
> "theta" :n 1}]
>[{:name "epsilon" :n 2} {:name "phi" :n 1}]])
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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, vis

Re: Clojure & Jruby (Ruby on Rails) Interop

[Oleksandr Petrov]

I've been working with an application that written in Ruby and Clojure.
Nothing forbids you from using some messaging system for communication
between Ruby and Clj, although we required direct access to Ruby from
Clojure and vice versa.

That's pretty much how Zweikopf was born:
http://github.com/ifesdjeen/zweikopf

With Zweikopf you can call Ruby code from Clojure and Clojure code from
Ruby, given that Runtime was registered properly. You can convert any
Clojure data structure to Ruby one
and back, custom serialisation, circular dependency detection included.

I would suggest not using any serialisation means if you intend running
both languages in a single process / JVM. That would add a significant
overhead and you won't be able to have
direct access to whatever class you may need at given time without wrapping
it into some RPC container.



On Mon, Sep 9, 2013 at 4:47 PM, rdelcueto  wrote:

> Hey Ron,
> Thanks for your response. Digging deeper into my question...
>
> When I read about the Torquebox Immutant duet, I thought it was
> particularly interesting solution, because it was fairly easy to deploy and
> both processes would live inside a JVM environment. I was impressed by how
> Clojure data structures mapped to Ruby structures and vice-versa, it seemed
> to provide a very clean and idiomatic messaging platform. Plus it would
> provide tools for caching, clustering, and what not. Still I wasn't very
> keen on the JRuby subject, since It's known to have compatibility issues
> with certain gems.
>
> Yesterday while researching on the subject I found about ZeroMQ. Do you
> have any particular reason to use RabbitMQ over other messaging libraries?
> Are there any caveats to your interop model?
> How portable is deploying a site using a messaging solution such as
> RabbitMQ?
>
> I also found out about Google's Protocol Buffers, they seemed like a
> lightweight solution to pass language agnostic data structures through the
> messaging infrastructure.
> Do messages need to be encapsulated somehow, or is this actually
> unnecessary? How it's done in your case?
>
> Regarding security and sensible information interop; Should messages be
> encrypted? Should they be encrypted as a whole message or partially (only
> sensible data)?
> What are the performance implications of this pipeline? Is the overhead
> and footprint of such setup (Ruby + Messaging Broker + ClojureJVM) big
> enough, for it to be worth thinking on writing everything in Clojure (using
> the Luminus framework)?
>
>
> On Monday, September 9, 2013 8:10:41 AM UTC-5, Ron Toland wrote:
>>
>> At Rewryte, we use Rails for the web frontend and Clojure for the data
>> processing backend for exactly the reasons you described.
>>
>> We use RabbitMQ to communicate between the two. This maintains separation
>> between the two apps (no JRuby required), and lets us scale them both
>> independently, while taking advantage of each language/framework's
>> strengths.
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>



-- 
alex p

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: [ANN] nativot 0.1.0 (leiningen plugin) public beta

[Alex Fowler]

The license section of the plugin page has been updated. The established 
license is EPL, same as Clojure!

среда, 28 августа 2013 г., 14:02:16 UTC+4 пользователь Alex Fowler написал:
>
> Plugin homepage: https://bitbucket.org/noncom/nativot
>
> As for the license: I have contacted JDotSoft, they're kindly giving the 
> green light! I am providing link to this post, so they can join the 
> discussion.
>
> Also, in the next version I am going to update the plugin and include the 
> current version of JarClassLoader from the website, so it can be used if no 
> internet is available. However, if internet is available, the plugin will 
> still contact the website and download the class, even if it is not newer 
> than the bundled version.
>

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

Fwd: Logos-oriented Lisp compiled to Javascript | coect.net

[Mimmo Cosenza]

It seems interesting to be watched. 

Does anyone already know something about it.

Mimmo

http://www.coect.net/metajs/

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

Re: Clojure, floats, ints and OpenGL

[Mikera]

+1 for supporting all the JVM primitive types properly.

It is worth noting that the benefits would extend much further than just 
OpenGL, e.g.:
 - int is a commonly used type in Java interop. Casting to/from it all the 
time is a minor annoyance/overhead
 - int is the type used for array indexing on the JVM
 - all the small (< 8 byte) primitive types save memory footprint, which is 
important since memory bandwidth is the limiting factor in some workloads
 - int/float fit into a register (and therefore perform much better) on 32 
bit machines (which still exist, believe it or not)
 - char is a pretty useful primitive type if you are doing text processing
 - byte is also frequently useful, especially for IO

I believe that with some enhancements to the Clojure compiler, supporting 
all the JVM primitive types shouldn't be too difficult, and it would 
provide many benefits both in terms of overall performance and interop 
convenience.

On Monday, 9 September 2013 21:43:12 UTC+8, Alex Fowler wrote:
>
> Hello!
>
> With this letter I would like to receive an answer from somebody from the 
> development team (if anyone else has something to say, you're surely 
> welcome :) ).
>
> I am working for a big multimedia company and recently I have been 
> considering moving to Clojure as the main language of development. We have 
> been doing Java and Scala before, but now when I tried Clojure and see the 
> possibilities it provides, I would definitely stand for it to be our 
> ground. However, while I am so satisfied with everything - the language, 
> the community, the Java interop, there is still something that hinders and 
> makes me linger. Namely, the lack of good support of floats and ints in the 
> language. While many people would not consider it to be a huge disadvantage 
> or even notice it, things are not so bright when it comes to OpenGL.
>
> The case is that OpenGL and 3D graphics hardware in general has no support 
> for doubles or longs. Therefore, all libraries, all data and all 
> computations are meant to be performed with floats and ints (shaders too). 
> Due to the lack of good support of these data types in Clojure (for 
> example, there are no ^float and ^int typehints, float and int values can 
> only be typecasted to, all calculations always retain doubles and longs), 
> results in too many extra typecasts, which are absolutely unnecessary and 
> take too much time. So, calculations become very cumbersome, even if we do 
> not take mandatory boxing into account.
>
> Considering that such kinds of calculations are usually abuntant in the 
> aforementioned types of applications, the penalty grows really huge. I have 
> endeavoured several discussions on the IRC to find out possible 
> workarounds. Although many good proposals by many good people were made, 
> aimed at improving the situation, none of them could solve the fundamental 
> lack of the ability to manipulate 32bit primitive (or even boxed) data 
> types. That lack renders Clojure not really suitable for heavy-load OpenGL 
> applications that require somewhat extensive calculations: some kinds of 
> games, simulations, generative graphics and so on. Considering how superior 
> Clojure is to any other language available for JVM, that black spot looks 
> especially embarrasing. And I could imagine falling back to Java for fast 
> computations, just like we fall back to ASM in, say C, that is very 
> undesirable and discouraging, since we want to pick Clojure for Clojure and 
> it will be too cumbersome to make 50/50% Java/Clojure apps just to work 
> around that design decision.
>
> Therefore, while deciding if to pick Clojure as the base for our 
> development, I would like to know answers to the following questions:
>
> 1) What is the current reason for the support for these types to be 
> missing?
> 2) Are there any plans for improvement of support for floats, ints and 
> maybe, localized unboxed calculations? Or is there some advice on how to 
> enable their support?
> 3) What is you vision for Clojure + OpenGL applications?
> 4) Is it possible to request support for floats, ints and maybe shorts for 
> the language?
> 5) Is it possible to request support for localized unboxed calculations, 
> like (with-unboxed ... ) and localized float-only and int-only 
> calculations, like, say in special macros (with-floats-&-ints ... here go 
> (+) (-) and stuff ONLY with floats/ints ... ) ?
>
> Preferably, I would like to hear the answers from somebody from the 
> development team, because I have already received enough support from the 
> community, on the IRC, I appreciate it, but now I have to make a serious 
> choice for our company and I feel quite responsible for that. I also feel 
> that these questions are very important for any specialist that works with 
> OpenGL and influence Clojure acceptance for OpenGL-enabled applications 
> world-wide. Thank you.
>

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

Re: Logos-oriented Lisp compiled to Javascript | coect.net

[Alex Fowler]

Well.. reminds me of Scala implicits. When some people think that implicits 
hurt the pure essense of good, I found them to be particulary useful, 
especially in some scenarios that involved passing many "boring" arguments. 
However, with implicits you could run into troubles, hunting invisible 
errors of type inference (Scala mark), and i am not sure how useful such 
technique will be in a lisp. How the compiler decides between, say 3 
equally valid candidates? These are the wanderings I came into while I was 
doing Scala and thinking over the whole matter, but I think that this is an 
interesting branch of research for computer languages and would like to see 
and know more of the experiments and try them.

On Tuesday, September 10, 2013 12:14:14 AM UTC+4, Mimmo Cosenza wrote:
>
> It seems interesting to be watched. 
>
> Does anyone already know something about it. 
>
> Mimmo 
>
> http://www.coect.net/metajs/ 
>

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

[Laurent PETIT]

2013/9/9 Mark Engelberg :
> OK, I'm starting to understand the shape of the data better.  However, you
> say, "the ability to arbitrarily look into any node on the tree and then
> walk up it getting all of the parents until root."  What does the query for
> this look like and specifically what information do you want returned?  What
> I'm getting at is, are you only querying by name (e.g. "theta") and hoping
> to get all the paths down to all the nodes with a name of "theta", or do you
> have some other way of distinguishing between the two theta nodes in the
> tree, and you only want the path for one of them?  If the latter, how are
> you uniquely identifying the nodes?
>
> Is there any other information you need to access than the the upward path
> from a node to the root?

This is quite an interesting post, with the underlying question in my
mind : where to put the line between pure datastructure manipulation
with clojure.core only, and a datalog (datomic)/sql engine ?

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

Re: Clojure, floats, ints and OpenGL

[Alex Fowler]

Think for youself: how much you gain for storing color in 64 bit instead of 
32? How much you gain of storing positions to be projected on a, say, 
1920x1080 screen, in 64 bit, not 32? Considering this, how much you gain 
from manufacturing 64-bit enabled GPUs for average humans to use? And 
putting at least twice much hardware in them, when nobody ever notices the 
difference? And what about the cost? Also, no magical conversion 64->32 is 
done anywhere in the drivers or hardware interface.

On Monday, September 9, 2013 9:12:49 PM UTC+4, tbc++ wrote:
>
> Also, how much of this is a limit of the OpenGL library you are using? The 
> raw OpenGL API supports glVertex3d and glVertex3f. Is the double version 
> not supported by your java interface library?
>
> Timothy
>
>
> On Mon, Sep 9, 2013 at 11:07 AM, Timothy Baldridge 
> 
> > wrote:
>
>> It's worth noting that the restrictions to IFn do not apply to 
>> definterface and deftype. Not that solves all (or any) of your problems, 
>> I've used definterface before to lock down the actual types used. 
>>
>> Timothy
>>
>>
>> On Mon, Sep 9, 2013 at 11:03 AM, Jozef Wagner 
>> 
>> > wrote:
>>
>>> You can typehing ints for locals (let, loop), restrictions are just for 
>>> function arguments.
>>> AFAIK the reason is combinatorial explosion at 
>>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java#L91
>>> I have the same problem with char. Because I cannot typehint e.g. my 
>>> whitespace? function with ^char, I recieve a boxed Object and thus cannot 
>>> use == for comparison.
>>>
>>> JW
>>>  
>>>
>>> On Mon, Sep 9, 2013 at 6:02 PM, Mikera 
>>> > wrote:
>>>
 +1 for supporting all the JVM primitive types properly.

 It is worth noting that the benefits would extend much further than 
 just OpenGL, e.g.:
  - int is a commonly used type in Java interop. Casting to/from it all 
 the time is a minor annoyance/overhead
  - int is the type used for array indexing on the JVM
  - all the small (< 8 byte) primitive types save memory footprint, 
 which is important since memory bandwidth is the limiting factor in some 
 workloads
  - int/float fit into a register (and therefore perform much better) on 
 32 bit machines (which still exist, believe it or not)
  - char is a pretty useful primitive type if you are doing text 
 processing
  - byte is also frequently useful, especially for IO

 I believe that with some enhancements to the Clojure compiler, 
 supporting all the JVM primitive types shouldn't be too difficult, and it 
 would provide many benefits both in terms of overall performance and 
 interop convenience.

 On Monday, 9 September 2013 21:43:12 UTC+8, Alex Fowler wrote:
>
> Hello!
>
> With this letter I would like to receive an answer from somebody from 
> the development team (if anyone else has something to say, you're surely 
> welcome :) ).
>
> I am working for a big multimedia company and recently I have been 
> considering moving to Clojure as the main language of development. We 
> have 
> been doing Java and Scala before, but now when I tried Clojure and see 
> the 
> possibilities it provides, I would definitely stand for it to be our 
> ground. However, while I am so satisfied with everything - the language, 
> the community, the Java interop, there is still something that hinders 
> and 
> makes me linger. Namely, the lack of good support of floats and ints in 
> the 
> language. While many people would not consider it to be a huge 
> disadvantage 
> or even notice it, things are not so bright when it comes to OpenGL.
>
> The case is that OpenGL and 3D graphics hardware in general has no 
> support for doubles or longs. Therefore, all libraries, all data and all 
> computations are meant to be performed with floats and ints (shaders 
> too). 
> Due to the lack of good support of these data types in Clojure (for 
> example, there are no ^float and ^int typehints, float and int values can 
> only be typecasted to, all calculations always retain doubles and longs), 
> results in too many extra typecasts, which are absolutely unnecessary and 
> take too much time. So, calculations become very cumbersome, even if we 
> do 
> not take mandatory boxing into account.
>
> Considering that such kinds of calculations are usually abuntant in 
> the aforementioned types of applications, the penalty grows really huge. 
> I 
> have endeavoured several discussions on the IRC to find out possible 
> workarounds. Although many good proposals by many good people were made, 
> aimed at improving the situation, none of them could solve the 
> fundamental 
> lack of the ability to manipulate 32bit primitive (or even boxed) data 
> types. That lack renders Clojure not really suitable for heavy

Re: Logos-oriented Lisp compiled to Javascript | coect.net

[Mimmo Cosenza]

Thanks Alex, I'll keep an eye open on them. 
mimmo

On Monday, September 9, 2013 10:24:08 PM UTC+2, Alex Fowler wrote:
>
> Well.. reminds me of Scala implicits. When some people think that 
> implicits hurt the pure essense of good, I found them to be particulary 
> useful, especially in some scenarios that involved passing many "boring" 
> arguments. However, with implicits you could run into troubles, hunting 
> invisible errors of type inference (Scala mark), and i am not sure how 
> useful such technique will be in a lisp. How the compiler decides between, 
> say 3 equally valid candidates? These are the wanderings I came into while 
> I was doing Scala and thinking over the whole matter, but I think that this 
> is an interesting branch of research for computer languages and would like 
> to see and know more of the experiments and try them.
>
> On Tuesday, September 10, 2013 12:14:14 AM UTC+4, Mimmo Cosenza wrote:
>>
>> It seems interesting to be watched. 
>>
>> Does anyone already know something about it. 
>>
>> Mimmo 
>>
>> http://www.coect.net/metajs/ 
>>
>

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

Re: Clojure, floats, ints and OpenGL

[Alex Fowler]

While there are "double" types for OpenGL, like GLdouble 
(reference-1, 
reference-2 ), their use is, 
softly speaking, not wide-spread: 
reference-3,
 
reference-4
 and 
reference-5.
 
I think that the real situation is very clearly described in these papers. 
You won't find an OpenGL programmer using double precision, unless he 
either has a *very* specific task or he does not know what he's doing. 
Doubles may be considered an archaism in OpenGL. At least, that's the 
current plot. I know no programmers who used doulbes in OpenGL since 
version 2.x, as far as I remember.

As for the binding that I am using, - it is LWJGL, please see their javadoc 
to find no mentions of double (for real usage at 
least). Also, the function glVertex*d is not often used from Java bindings, 
as far as I know. I did not browse through all their reference pages, but I 
am almost sure, you won't find a single mention of use of 64-bit types. You 
can only find such references in rather old info. Yeah, for what reason? 
Imagine you buy, say 4Gb super-cool NVIDIA videocard to play a game or run 
a scientific sumulation and... suddenly it becomes as if being 2Gb? No, 
doubles are not present on GPUs.

Sorry, I am pretty tired argumenting that on IRC already... :) I work in 
multimedia company, believe me, I know what I'm saying.

And Mikera is right. I did not mention that in my original message, but we 
also work with simply lots of hardware (sometimes we equip huge building 
and complexes, full with all kinds of electronics and comms and devices and 
stuff). Yes, they are 32, 16 and often even 8 bit hardware components. That 
is a huge market, really.

I understand that there can be some challenge implementing the support for 
the datatypes, but, the benifit of doing that outweights the costs so 
much.. like having two hands instead of one. And don't say that most things 
in the world require one hand to do them.. 



On Monday, September 9, 2013 9:12:49 PM UTC+4, tbc++ wrote:
>
> Also, how much of this is a limit of the OpenGL library you are using? The 
> raw OpenGL API supports glVertex3d and glVertex3f. Is the double version 
> not supported by your java interface library?
>
> Timothy
>
>
> On Mon, Sep 9, 2013 at 11:07 AM, Timothy Baldridge 
> 
> > wrote:
>
>> It's worth noting that the restrictions to IFn do not apply to 
>> definterface and deftype. Not that solves all (or any) of your problems, 
>> I've used definterface before to lock down the actual types used. 
>>
>> Timothy
>>
>>
>> On Mon, Sep 9, 2013 at 11:03 AM, Jozef Wagner 
>> 
>> > wrote:
>>
>>> You can typehing ints for locals (let, loop), restrictions are just for 
>>> function arguments.
>>> AFAIK the reason is combinatorial explosion at 
>>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java#L91
>>> I have the same problem with char. Because I cannot typehint e.g. my 
>>> whitespace? function with ^char, I recieve a boxed Object and thus cannot 
>>> use == for comparison.
>>>
>>> JW
>>>  
>>>
>>> On Mon, Sep 9, 2013 at 6:02 PM, Mikera 
>>> > wrote:
>>>
 +1 for supporting all the JVM primitive types properly.

 It is worth noting that the benefits would extend much further than 
 just OpenGL, e.g.:
  - int is a commonly used type in Java interop. Casting to/from it all 
 the time is a minor annoyance/overhead
  - int is the type used for array indexing on the JVM
  - all the small (< 8 byte) primitive types save memory footprint, 
 which is important since memory bandwidth is the limiting factor in some 
 workloads
  - int/float fit into a register (and therefore perform much better) on 
 32 bit machines (which still exist, believe it or not)
  - char is a pretty useful primitive type if you are doing text 
 processing
  - byte is also frequently useful, especially for IO

 I believe that with some enhancements to the Clojure compiler, 
 supporting all the JVM primitive types shouldn't be too difficult, and it 
 would provide many benefits both in terms of overall performance and 
 interop convenience.

 On Monday, 9 September 2013 21:43:12 UTC+8, Alex Fowler wrote:
>
> Hello!
>
> With this letter I would like to receive an answer from somebody from 
> the development team (if anyone else has something to say, you're surely 
> welcome :) ).
>
> I am working for a big multimedia company and recently I have been 
> considering moving to Clojure as the main language of development. We 
> have 
> been doing Java and Scala before, but now whe

Re: Best way to pass through named arguments (destructured map)?

[Mark Mandel]

Thanks for the help all, that gave me some things to think about.

Cheers,

Mark


On Mon, Sep 9, 2013 at 9:22 PM, Meikel Brandmeyer (kotarak) 
wrote:

> Hi,
>
> Am Montag, 9. September 2013 12:31:30 UTC+2 schrieb Alex Fowler:
>
>> I would also add that in case, if you *need* to destructure the `options`
>> map for some reason, like:
>>
>> `(defn search
>>   "Docstring"
>>   [mapping-type & {:keys [option-1 option-2] :as options}]
>>   (do-smth-with-option-1 ...)
>>   (apply esd/search es-index mapping-type options))`
>>
>> then you can use `mapply` to apply maps to functions that accept optional
>> args maps. The code of mapply is the fllowing:
>>
>> `(defn mapply [f & args] (apply f (apply concat (butlast args) (last
>> args`
>>
>> Combining it with partial, as adviced, could give you the functionality
>> you may sometimes need:
>>
>> `(mapply (partial es/search es-index) your-options-map)`
>>
>>
> You don't have to destructure in the argument list:
>
> (defn search
>   [mapping-type & options]
>   (let [{:keys [option-1]} options
> index (index-based-on option-1)]
> (apply esd/search index mapping-type options)))
>
> Kind regards
> Meikel
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>



-- 
E: mark.man...@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

2 Devs from Down Under Podcast
http://www.2ddu.com/

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

Re: Best way to pass through named arguments (destructured map)?

[Mark Mandel]

The solution I've actually gone with is:

(apply esd/search es-index mapping-type (-> options seq flatten))

Seems the most consise and shows the intent of what I'm trying to do quite
well - better than a (relatively) confusing `reduce` statement.

Again, the help is appreciated.

Mark


On Tue, Sep 10, 2013 at 8:57 AM, Mark Mandel  wrote:

> Thanks for the help all, that gave me some things to think about.
>
> Cheers,
>
> Mark
>
>
> On Mon, Sep 9, 2013 at 9:22 PM, Meikel Brandmeyer (kotarak) 
> wrote:
>
>> Hi,
>>
>> Am Montag, 9. September 2013 12:31:30 UTC+2 schrieb Alex Fowler:
>>
>>> I would also add that in case, if you *need* to destructure the
>>> `options` map for some reason, like:
>>>
>>> `(defn search
>>>   "Docstring"
>>>   [mapping-type & {:keys [option-1 option-2] :as options}]
>>>   (do-smth-with-option-1 ...)
>>>   (apply esd/search es-index mapping-type options))`
>>>
>>> then you can use `mapply` to apply maps to functions that accept
>>> optional args maps. The code of mapply is the fllowing:
>>>
>>> `(defn mapply [f & args] (apply f (apply concat (butlast args) (last
>>> args`
>>>
>>> Combining it with partial, as adviced, could give you the functionality
>>> you may sometimes need:
>>>
>>> `(mapply (partial es/search es-index) your-options-map)`
>>>
>>>
>> You don't have to destructure in the argument list:
>>
>> (defn search
>>   [mapping-type & options]
>>   (let [{:keys [option-1]} options
>> index (index-based-on option-1)]
>> (apply esd/search index mapping-type options)))
>>
>> Kind regards
>> Meikel
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from 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.
>>
>
>
>
> --
> E: mark.man...@gmail.com
> T: http://www.twitter.com/neurotic
> W: www.compoundtheory.com
>
> 2 Devs from Down Under Podcast
> http://www.2ddu.com/
>



-- 
E: mark.man...@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

2 Devs from Down Under Podcast
http://www.2ddu.com/

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

Re: Building Trees

[Mark Engelberg]

Let's assume for the moment that you do in fact absolutely need some sort
of "bidirectional" querying of the data.  In other words, from a parent you
need to get to the child, and from the child you need to get to the
parent.  There's no way to accomplish this with immutable data structures
without introducing some level of indirection.

Option 1:
Code it the way you'd code a pointer-based version, but use refs as your
"pointers".  Advantage over coding in Java with raw pointers is that you
can use the STM to change a bunch of "pointers" in one transaction.

Option 2:
Store in your immutable data structure a mapping from unique names to
nodes.  These names are your "pointers".  Nodes refer to other parent and
children nodes by their names.  For example, store the tree like so:
{"Node1" {:parent nil :children ["Node2" "Node3"]}
 "Node2" {:parent "Node1" :children []}
 "Node3" {:parent "Node1" :children []}}
Looking up a name in that map corresponds to the notion of dereferencing
your pointer.

In pointer-based code, you generally pass the pointers as arguments to
functions.  Similarly, with this approach you'd tend to write your API to
take and return names.

The main downside versus a pointer or ref version of the code is that all
queries to find a parent or child must take as parameters not only the name
of the node in question, but the whole mapping of names to nodes.  Finding
a parent, for example, is a two step process.  Lookup the name in the map,
and then you have the actual structure you need to find the name of the
parent.  You can encapsulate that, of course, in an api, for example:
(get-parent name-to-node-map name) -> returns name of parent.

The advantage of this representation is that you have one immutable entity
representing the whole tree, and it is therefore trivial to save different
versions and states of the tree in its entirety.  This is the way I usually
do it.

Option 3:
Rather than thinking of it as a tree, think of it as a directed graph.
There is one type of link from parent to child, and another type of link
from child to parent.  This way of thinking makes it easy to leverage
existing graph technologies that can be easily accessed from Clojure, for
example, http://titanium.clojurewerkz.org/.

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

[Ben Wolfson]

There's an overview of several approaches to the problem here:
http://okmij.org/ftp/Scheme/parent-pointers.txt


On Mon, Sep 9, 2013 at 4:37 PM, Mark Engelberg wrote:

> Let's assume for the moment that you do in fact absolutely need some sort
> of "bidirectional" querying of the data.  In other words, from a parent you
> need to get to the child, and from the child you need to get to the
> parent.  There's no way to accomplish this with immutable data structures
> without introducing some level of indirection.
>
> Option 1:
> Code it the way you'd code a pointer-based version, but use refs as your
> "pointers".  Advantage over coding in Java with raw pointers is that you
> can use the STM to change a bunch of "pointers" in one transaction.
>
> Option 2:
> Store in your immutable data structure a mapping from unique names to
> nodes.  These names are your "pointers".  Nodes refer to other parent and
> children nodes by their names.  For example, store the tree like so:
> {"Node1" {:parent nil :children ["Node2" "Node3"]}
>  "Node2" {:parent "Node1" :children []}
>  "Node3" {:parent "Node1" :children []}}
> Looking up a name in that map corresponds to the notion of dereferencing
> your pointer.
>
> In pointer-based code, you generally pass the pointers as arguments to
> functions.  Similarly, with this approach you'd tend to write your API to
> take and return names.
>
> The main downside versus a pointer or ref version of the code is that all
> queries to find a parent or child must take as parameters not only the name
> of the node in question, but the whole mapping of names to nodes.  Finding
> a parent, for example, is a two step process.  Lookup the name in the map,
> and then you have the actual structure you need to find the name of the
> parent.  You can encapsulate that, of course, in an api, for example:
> (get-parent name-to-node-map name) -> returns name of parent.
>
> The advantage of this representation is that you have one immutable entity
> representing the whole tree, and it is therefore trivial to save different
> versions and states of the tree in its entirety.  This is the way I usually
> do it.
>
> Option 3:
> Rather than thinking of it as a tree, think of it as a directed graph.
> There is one type of link from parent to child, and another type of link
> from child to parent.  This way of thinking makes it easy to leverage
> existing graph technologies that can be easily accessed from Clojure, for
> example, http://titanium.clojurewerkz.org/.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>



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

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

Re: Building Trees

[Mark Engelberg]

There's one other big downside to the mapping-from-names-to-nodes technique
that I forgot to mention.  If you plan to delete connections between nodes,
and the structure is intricate enough that you don't know whether you can
safely delete the node itself, then you can potentially end up with orphan
name->node pairs in your mapping that are unnecessary.  Cleaning these up
would basically mean you'd have to write your own garbage collection
routines.

If you work with real pointers, you get garbage collection for free.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Putting in alts! - haven't seen it used

[Cedric Greevey]

Sounds like that could be useful for gracefully degrading media players.
Playback lags due to CPU contention or whatever, drop a frame to keep the
audio and video and clock-time roughly in proper sync. Things like that.


On Mon, Sep 9, 2013 at 9:09 AM, Philip Potter wrote:

> I can suggest one, though I haven't used it for real so can't speak for
> all the design tradeoffs:
>
> (alts! [[out val] (timeout N)])
>
> will attempt to write to a consumer, but if the consumer is swamped, will
> drop the message on the floor and move on. (I can imagine rewriting this
> using alt! so that if the timeout is taken, you can log that you've dropped
> something.) This is pretty similar to Sean's use-case, just with a put
> instead of a take.
>
>
> On 9 September 2013 03:21, Alan Shaw  wrote:
>
>> I'm accustomed to using alts! to allow taking from a collection of
>> core.async ports, but haven't come up with a use case for a put in alts!,
>> either with or without takes.
>> Have you?
>>
>> -A
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: Clojure & Jruby (Ruby on Rails) Interop

[Michael Klishin]

2013/9/9 Oleksandr Petrov 

> Forgot to mention, Zweikopf comes as a Ruby gem and as a Clojure library.
> You should make a decision though wether you're running Ruby scripting
> container from Clojure or start Clojure runtime from Ruby


Or integrate the two using messaging, e.g. with [1] and [2].

1. http://hotbunnies.info
2. http://clojurerabbitmq.info
-- 
MK

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

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

Re: Clojure & Jruby (Ruby on Rails) Interop

[rdelcueto]

Thank you all for your advice and information provided.

It's clear to me now that a message based solution is a good option. I'm 
still unsure on which messaging framework I should start with.
Actually it was Jim's screencast, which got me into thinking in the 
messaging solution using TorqueBox and Immutant. They look like brilliant 
mature tools, and might be the way to go.

My only consideration regarding TorqueBox is having to play with JRuby. In 
my research a stumbled upon Allen Rohner's talk, "The Good, The Bad & The 
Ugly (Clojure & 
JRuby)", 
and got me thinking that this hybrid scenario can as well introduce 
unwanted complexity. The whole reason of using Clojure instead of pure RoR, 
is dodge complexity in customizing the Rails framework to my needs. What 
happens to the RoR database migration model, now that the backend is 
encharge of it?

Of course Allen's case wasn't targeting a messaging scenario, but a much 
complex and messier Clojure-Ruby interaction, which I think isn't in my 
outlook. But still he pointed out many obstacles of clashing two very 
different paradigms.

But how and what should each, the RoR frontend and Clojure backend, 
encapsulate. Which are the good practices in this scenarios?

For instance, I was thinking in delegating to Clojure the database records 
manipulation, while still letting the RoR frontend, have it's independent 
connection to the DB in a read-only fashion, for managing session logins.
Is this encapsulation violation an atrocious idea? Should all interactions 
be abstracted into the messaging framework?

Does anyone know of any opensource project which has this kind of model? It 
would be very illustrative to look at how people have actually implemented 
it.

On Monday, September 9, 2013 11:14:54 AM UTC-5, Jim Crossley wrote:
>
> Hi Rodrigo,
>
> I'm one of the developers of TorqueBox and Immutant. Your email prompted 
> me to re-watch a screencast [1] I made in March showing how to use them 
> together. I realized things have changed a little since then, so I added a 
> few annotations to the video highlighting the differences. Hopefully enough 
> to get you up and experimenting.
>
> As you've probably figured out, both TorqueBox and Immutant are integrated 
> stacks, bundling some commodity services that most non-trivial applications 
> need, e.g. scheduling, caching, and messaging. The intent of any integrated 
> platform is to relieve administration burden. But that only works for you 
> if the inherent choices within that stack fit the needs of your app. We 
> think/hope default Immutant configuration and abstractions (e.g. queues, 
> topics, request/respond) offers a good balance to fit a wide variety of 
> apps.
>
> If simple integration between Ruby and Clojure apps is your chief goal, I 
> think Immutant/TorqueBox is compelling, but I'm biased. I would definitely 
> recommend using some sort of messaging broker, though, i.e. don't mix 
> Clojure and Ruby in the same source file or project.
>
> Performance and security concerns are so application-specific I hate to 
> make any generic statements about them other than, "be fast and secure". ;-)
>
> But do feel free to bother us in #torquebox or #immutant on freenode with 
> any questions about your particular app/needs.
>
> Thanks,
> Jim
>
> [1] http://immutant.org/news/2013/03/07/overlay-screencast/
>
>
>
> On Sun, Sep 8, 2013 at 10:25 PM, rdelcueto 
> > wrote:
>
>> Hi everyone,
>> I'm about to start working on building a site for a startup company.
>>
>> We are a small team, and currently they've been coding the site using RoR 
>> (Ruby on Rails). I was thinking Clojure might be better suited for the 
>> task, specially because we'll need to implement a backend which is robust, 
>> scalable and secure, but also we'll need flexibility, which I think the RoR 
>> framework won't shine at all.
>>
>> At our team, we are two coders, non of us are proficient in Web 
>> Developing, and we have little experience with RoR, and I thought (I'm 
>> sure) maybe investing time learning Clojure will provide us with better 
>> tools.
>>
>> PROBLEM/QUESTION
>>
>> While searching for alternative solutions, I stumbled upon the 
>> Flightcaster case, we're they are using RoR to implement the site's 
>> frontend and Clojure for the system backend. I thought this was a very 
>> elegant solution, using each tool for what it's good at. Plus this way we 
>> can reuse what they've already implemented.
>>
>> I found a way to do this is by using Torquebox and Immutant, and using 
>> the messaging systems to communicate between Jruby and Clojure. Still I 
>> have no idea of how this works, and the performance and security 
>> implications it brings to the table. I found little information on the 
>> subject.
>>
>> I would appreciate if anyone could provide guidance, examples or 
>> documentation on the subject.
>>
>> Any reference to open source projects which us

Clojure newbie code review

[Igor Demura]

Hi Clojure community,

(I tried codereview.stackaxchange.com before, but no responses where) I'm 
Clojure newbie, and feel very excited about it and functional programming 
in general. I wrote tiny app (59 lines of code) which renders a directory 
tree to the terminal, filtering with a regex. I'm sure that my code is not 
perfect and something could be done much better. I'll appreciate if you 
could spent sometime to review it: 
https://github.com/idemura/incub/tree/master/tree. Don't know where to get 
help with this.

Igor.

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

[Marco Shimomoto]

That is exactly what http://www.haskell.org/hoogle/ does, you did a 
fantastic job.

Thanks,

On Monday, September 9, 2013 5:09:27 AM UTC-3, Islon Scherer wrote:
>
> Florian: I filter out all functions that end with ! but I can't know for 
> sure which functions have side effects.
>
> On Sunday, September 8, 2013 7:24:48 AM UTC+2, Florian Over wrote:
>>
>> Hi,
>> you could check for io! to find forms with side-effect, but i think it is 
>> seldom used.
>> Florian
>>
>> http://clojuredocs.org/clojure_core/clojure.core/io!
>>
>>
>> 2013/9/8 Maximilien Rzepka 
>>
>>> Found many times apropos useful...
>>> user> (apropos "partition")
>>> (partition-by partition-all partition)
>>>
>>> But wally approach is really cool.
>>> Thanks for sharing 
>>> @maxrzepka
>>>
>>> Le jeudi 5 septembre 2013 23:23:28 UTC+2, Islon Scherer a écrit :
>>>
 Hey guys,

 I don't know about you but when I was a beginner in Clojure (and it 
 still happens every now and then) I had a hard time finding functions 
 using 
 `doc` or `find-doc`,
 normally because I didn't remember the name of the function or because 
 my only clue was a generic name so find-doc would return too much results. 
 But one
 thing I knew: what to expect of the function, I knew the inputs and the 
 outputs. That's why I decided to create wally, because sometimes you don't
 know the name of the function you want but you know how it should 
 behave.

 With wally you can tell the inputs and the output and it'll search for 
 functions that match those inputs/outputs.

 Ex:

 user=> (find-by-sample {1 1, 2 3, 3 1, 4 2} [1 2 3 4 4 2 
 2])-clojure.core/frequencies([coll])
>   Returns a map from distinct items in coll to the number of times
>   they appear.
>
>
 user=> (find-by-sample '((1 2 3) (4 5)) (partial < 3) [1 2 3 4 5])
> -
> clojure.core/partition-by
> ([f coll])
>   Applies f to each value in coll, splitting it each time f returns
>a new value.  Returns a lazy seq of partitions.
>

  
 https://github.com/**stackoverflow/wally

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

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

Re: [ANN] Austin — the ClojureScript browser-REPL, rebuilt stronger, faster, easier

[Nelson Morris]

I've been using austin on a project with emacs/nrepl.  It works for a C-c
C-k, switch to nrepl, interact with app. However, some other features like
auto-complete and jump-to-symbol-definition I'm used to in a clojure
workflow don't work or cause a core to spin.  I'd suspect the eldoc call to
show the function arguments could act similar.

-
Nelson


On Mon, Sep 9, 2013 at 10:25 AM, Norman Richards wrote:

> On Mon, Aug 5, 2013 at 8:21 AM, Chas Emerick  wrote:
>
>> As you might know, I've been tinkering with an easier-to-use variant of
>> ClojureScript's browser-REPL for some time.  I've finally wrapped that up
>> into its own project, Austin: [...]
>>
>
>
> Is anyone successfully using this with nrepl in emacs?  I am able to make
> it work, but something is causing both emacs and the JVM it is connected to
> to use 100% CPU.  I seem to be getting a long stream of "Unable to resolve
> symbol: if-let in this context, compiling:(NO_SOURCE_PATH:1:1)"
>
> See: https://gist.github.com/orb/6496320
>
> *nrepl-connection* fills up with:
>
> d2:ex45:class
> clojure.lang.Compiler$CompilerException2:id6:1504207:root-ex45:class
> clojure.lang.Compiler$CompilerException7:session36:43e688aa-01c2-4824-b1f3-1bd05a1f02446:statusl10:eval-erroreed3:err128:CompilerException
> java.lang.RuntimeException: Unable to resolve symbol: if-let in this
> context, compiling:(NO_SOURCE_PATH:1:1)
>
>
> I'm not sure if this is a problem with austin or if it's nrepl.el or
> something on the emacs side.
>
> As a side note, I occasionally get a similar error message using straight
> nrepl when first starting up, but it usually only happens once.  With
> austin/nrepl it appears to be stuck in some kind of loop erroring over and
> over...  Does anyone have a known good setup I could try to reproduce?
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: Building Trees

[Cedric Greevey]

If you use a java.util.WeakHashMap (and resist the temptation to mutate it
instead of making modified copies) and the name objects are interned (so
any two that are equal are identical -- so, as usual, you want to use
:clojure :keywords), then name->node mappings get auto-GC'd if the name
stops being in use anywhere else. (Just don't include a copy of the name
*inside* the node with that name. It shouldn't be needed because you should
never have a node in hand without having first had the name, in this
architecture. If for any reason it *is* needed store it as a string instead
of a keyword so it won't be the same interned object, but can be converted
into such with (keyword foo).)


On Mon, Sep 9, 2013 at 8:05 PM, Mark Engelberg wrote:

> There's one other big downside to the mapping-from-names-to-nodes
> technique that I forgot to mention.  If you plan to delete connections
> between nodes, and the structure is intricate enough that you don't know
> whether you can safely delete the node itself, then you can potentially end
> up with orphan name->node pairs in your mapping that are unnecessary.
> Cleaning these up would basically mean you'd have to write your own garbage
> collection routines.
>
> If you work with real pointers, you get garbage collection for free.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: ANN: ClojureScript 0.0-1877 (Breaking change)

[Brandon Bloom]

> a (very) temporary workaround is to use the old code 

Why not just switch (k coll) to (get coll k) ?

If you know that coll is non-nil, you can also just use (coll k). Both 
forms also accept an optional not-found value.

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

ANN: 2nd CFP for 2013 Workshop on Scheme and Functional Programming

[William Byrd]

Please note the encouraged shorter paper length (6 pages + references), 
which should make it easier for first time authors.  The workshop will be 
co-located with Clojure/conj.  We encourage Clojure-related submissions, 
and submissions by first-time authors!

Cheers,

--Will



DEADLINE: 13 September 2013
WEBSITE:  http://webyrd.net/scheme-2013/
LOCATION: Alexandria, Virginia (Washington, D.C.) (co-located with 
Clojure/conj)
DATE: 13 November 2013

The 2013 Workshop on Scheme and Functional Programming is now
accepting submissions.

Submissions related to Scheme and functional programming are welcome
and encouraged.

We also welcome papers related to dynamic or multiparadigmatic
languages and programming techniques.

** IMPORTANT UPDATE **
To encourage authors to submit their best work, this year we are
encouraging shorter papers (around 6 pages, excluding
references). This is to allow authors to submit longer, revised
versions of their papers to archival conferences or journals. Longer
papers (10--12 pages) are also acceptable, if the extra space is
needed.

Topics of interest include but are not limited to:

 contracts;
 commercial applications of Scheme; 
 compiler-implementation techniques;
 compiler optimization;
 data structures;
 domain-specific languages;
 garbage-collection;
 language-based security;
 language design;
 macros and hygiene;
 mixing static and dynamic typing;
 module systems;
 semantics;
 static analysis; 
 syntactic extensibility;
 tools and packages; and
 web-based development.

For more information, please see:

http://webyrd.net/scheme-2013/

Sincerely,

Will Byrd, 2013 Chair

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: Best way to pass through named arguments (destructured map)?

[Leif]

Careful - `flatten` recursively flattens sequential things.  E.g.
(flatten (seq {:in [1 2 3]})) => '(:in 1 2 3), which is probably not what 
you want.

You really want `flatten1`, which doesn't exist in core.  A version that 
works on maps is
(apply concat {:in [1 2 3]}) => '(:in [1 2 3]).  This appears within Alex's 
solution.

I would personally go with Meikel's solution, though.  It seems the nicest.

--Leif

On Monday, September 9, 2013 7:02:43 PM UTC-4, Mark Mandel wrote:
>
> The solution I've actually gone with is:
>
> (apply esd/search es-index mapping-type (-> options seq flatten))
>
> Seems the most consise and shows the intent of what I'm trying to do quite 
> well - better than a (relatively) confusing `reduce` statement.
>
> Again, the help is appreciated.
>
> Mark
>
>
> On Tue, Sep 10, 2013 at 8:57 AM, Mark Mandel 
> > wrote:
>
>> Thanks for the help all, that gave me some things to think about.
>>
>> Cheers,
>>
>> Mark
>>
>>
>> On Mon, Sep 9, 2013 at 9:22 PM, Meikel Brandmeyer (kotarak) <
>> m...@kotka.de > wrote:
>>
>>> Hi,
>>>
>>> Am Montag, 9. September 2013 12:31:30 UTC+2 schrieb Alex Fowler:
>>>
 I would also add that in case, if you *need* to destructure the 
 `options` map for some reason, like:

 `(defn search
   "Docstring"
   [mapping-type & {:keys [option-1 option-2] :as options}]
   (do-smth-with-option-1 ...)
   (apply esd/search es-index mapping-type options))`

 then you can use `mapply` to apply maps to functions that accept 
 optional args maps. The code of mapply is the fllowing:

 `(defn mapply [f & args] (apply f (apply concat (butlast args) (last 
 args`

 Combining it with partial, as adviced, could give you the functionality 
 you may sometimes need:

 `(mapply (partial es/search es-index) your-options-map)`


>>> You don't have to destructure in the argument list:
>>>
>>> (defn search
>>>   [mapping-type & options]
>>>   (let [{:keys [option-1]} options
>>> index (index-based-on option-1)]
>>> (apply esd/search index mapping-type options)))
>>>
>>> Kind regards
>>> Meikel
>>>
>>>  -- 
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com 
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
>>
>> -- 
>> E: mark@gmail.com 
>> T: http://www.twitter.com/neurotic
>> W: www.compoundtheory.com
>>
>> 2 Devs from Down Under Podcast
>> http://www.2ddu.com/
>>  
>
>
>
> -- 
> E: mark@gmail.com 
> T: http://www.twitter.com/neurotic
> W: www.compoundtheory.com
>
> 2 Devs from Down Under Podcast
> http://www.2ddu.com/
>  

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

Re: Best way to pass through named arguments (destructured map)?

[Matt Mitchell]

And also:

(mapcat identity {:in [1 2 3]}) => '(:in [1 2 3])

But yeah, destructuring with *&* then using *apply* is pretty clear too.

- Matt

On Monday, September 9, 2013 10:41:12 PM UTC-4, Leif wrote:
>
> Careful - `flatten` recursively flattens sequential things.  E.g.
> (flatten (seq {:in [1 2 3]})) => '(:in 1 2 3), which is probably not what 
> you want.
>
> You really want `flatten1`, which doesn't exist in core.  A version that 
> works on maps is
> (apply concat {:in [1 2 3]}) => '(:in [1 2 3]).  This appears within 
> Alex's solution.
>
> I would personally go with Meikel's solution, though.  It seems the nicest.
>
> --Leif
>
> On Monday, September 9, 2013 7:02:43 PM UTC-4, Mark Mandel wrote:
>>
>> The solution I've actually gone with is:
>>
>> (apply esd/search es-index mapping-type (-> options seq flatten))
>>
>> Seems the most consise and shows the intent of what I'm trying to do 
>> quite well - better than a (relatively) confusing `reduce` statement.
>>
>> Again, the help is appreciated.
>>
>> Mark
>>
>>
>> On Tue, Sep 10, 2013 at 8:57 AM, Mark Mandel  wrote:
>>
>>> Thanks for the help all, that gave me some things to think about.
>>>
>>> Cheers,
>>>
>>> Mark
>>>
>>>
>>> On Mon, Sep 9, 2013 at 9:22 PM, Meikel Brandmeyer (kotarak) <
>>> m...@kotka.de> wrote:
>>>
 Hi,

 Am Montag, 9. September 2013 12:31:30 UTC+2 schrieb Alex Fowler:

> I would also add that in case, if you *need* to destructure the 
> `options` map for some reason, like:
>
> `(defn search
>   "Docstring"
>   [mapping-type & {:keys [option-1 option-2] :as options}]
>   (do-smth-with-option-1 ...)
>   (apply esd/search es-index mapping-type options))`
>
> then you can use `mapply` to apply maps to functions that accept 
> optional args maps. The code of mapply is the fllowing:
>
> `(defn mapply [f & args] (apply f (apply concat (butlast args) (last 
> args`
>
> Combining it with partial, as adviced, could give you the 
> functionality you may sometimes need:
>
> `(mapply (partial es/search es-index) your-options-map)`
>
>
 You don't have to destructure in the argument list:

 (defn search
   [mapping-type & options]
   (let [{:keys [option-1]} options
 index (index-based-on option-1)]
 (apply esd/search index mapping-type options)))

 Kind regards
 Meikel

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

>>>
>>>
>>>
>>> -- 
>>> E: mark@gmail.com
>>> T: http://www.twitter.com/neurotic
>>> W: www.compoundtheory.com
>>>
>>> 2 Devs from Down Under Podcast
>>> http://www.2ddu.com/
>>>  
>>
>>
>>
>> -- 
>> E: mark@gmail.com
>> T: http://www.twitter.com/neurotic
>> W: www.compoundtheory.com
>>
>> 2 Devs from Down Under Podcast
>> http://www.2ddu.com/
>>  
>

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

Re: Best way to pass through named arguments (destructured map)?

[Mark Mandel]

I like that mapcat solution a lot. Very nice.

For some reason I can't get the destructuring to work... clearly missing
something there.

But fair point on the flatten - I had a play with it, and I can clearly see
the issue.

Thanks for the extra help.

Mark


On Tue, Sep 10, 2013 at 2:17 PM, Matt Mitchell  wrote:

> And also:
>
> (mapcat identity {:in [1 2 3]}) => '(:in [1 2 3])
>
> But yeah, destructuring with *&* then using *apply* is pretty clear too.
>
> - Matt
>
> On Monday, September 9, 2013 10:41:12 PM UTC-4, Leif wrote:
>>
>> Careful - `flatten` recursively flattens sequential things.  E.g.
>> (flatten (seq {:in [1 2 3]})) => '(:in 1 2 3), which is probably not what
>> you want.
>>
>> You really want `flatten1`, which doesn't exist in core.  A version that
>> works on maps is
>> (apply concat {:in [1 2 3]}) => '(:in [1 2 3]).  This appears within
>> Alex's solution.
>>
>> I would personally go with Meikel's solution, though.  It seems the
>> nicest.
>>
>> --Leif
>>
>> On Monday, September 9, 2013 7:02:43 PM UTC-4, Mark Mandel wrote:
>>>
>>> The solution I've actually gone with is:
>>>
>>> (apply esd/search es-index mapping-type (-> options seq flatten))
>>>
>>> Seems the most consise and shows the intent of what I'm trying to do
>>> quite well - better than a (relatively) confusing `reduce` statement.
>>>
>>> Again, the help is appreciated.
>>>
>>> Mark
>>>
>>>
>>> On Tue, Sep 10, 2013 at 8:57 AM, Mark Mandel  wrote:
>>>
 Thanks for the help all, that gave me some things to think about.

 Cheers,

 Mark


 On Mon, Sep 9, 2013 at 9:22 PM, Meikel Brandmeyer (kotarak) <
 m...@kotka.de> wrote:

> Hi,
>
> Am Montag, 9. September 2013 12:31:30 UTC+2 schrieb Alex Fowler:
>
>> I would also add that in case, if you *need* to destructure the
>> `options` map for some reason, like:
>>
>> `(defn search
>>   "Docstring"
>>   [mapping-type & {:keys [option-1 option-2] :as options}]
>>   (do-smth-with-option-1 ...)
>>   (apply esd/search es-index mapping-type options))`
>>
>> then you can use `mapply` to apply maps to functions that accept
>> optional args maps. The code of mapply is the fllowing:
>>
>> `(defn mapply [f & args] (apply f (apply concat (butlast args) (last
>> args`
>>
>> Combining it with partial, as adviced, could give you the
>> functionality you may sometimes need:
>>
>> `(mapply (partial es/search es-index) your-options-map)`
>>
>>
> You don't have to destructure in the argument list:
>
> (defn search
>   [mapping-type & options]
>   (let [{:keys [option-1]} options
> index (index-based-on option-1)]
> (apply esd/search index mapping-type options)))
>
> Kind regards
> Meikel
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient
> with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/**group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+u...@googlegroups.com.
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>



 --
 E: mark@gmail.com
 T: http://www.twitter.com/**neurotic 
 W: www.compoundtheory.com

 2 Devs from Down Under Podcast
 http://www.2ddu.com/

>>>
>>>
>>>
>>> --
>>> E: mark@gmail.com
>>> T: http://www.twitter.com/**neurotic 
>>> W: www.compoundtheory.com
>>>
>>> 2 Devs from Down Under Podcast
>>> http://www.2ddu.com/
>>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
E: mark.man...@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundthe

[ANN] CloCoP - constraint programming for Clojure

[Alex Engelberg]

http://github.com/aengelberg/clocop

CloCoP is a Clojure wrapper of the Java library JaCoP. The acronyms stand 
for "Clojure/Java Constraint Programming". This invites comparison to the 
core.logic library, and you may wonder why we need both. There are a few 
ways in which, in my opinion, the JaCoP system is better than core.logic:

   - JaCoP is more "plug-in-able," with an extensive set of customizations 
   to the way that the search operates. There are interfaces for different 
   components of the search, and each has several implementations. 
   - I found that with core.logic, I was somewhat limited by the set of 
   available constraints. JaCoP has many different constraints that seem to 
   more suit my needs for solving challenging problems. 
   - As the core.logic people 
say,JaCoP is 
anywhere from 10X-100X faster than core.logic at solving Finite 
   Domain problems.

JaCoP has a lot of "global constraints" which are very powerful and 
essential for describing certain problems. As Radoslaw Szymanek (an author 
of JaCoP) says, "CP without global constraints is just [a] plain academic 
toy. Using problems with arithmetic constraints is doing CP bad publicity."

If you'd like to see implementations of sample problems in CloCoP, check 
out the test cases
 (https://github.com/aengelberg/clocop/tree/master/test/clocop).

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

[ANN] XCLJB v0.1.0: X protocol Clojure-language Binding

[Vincent Chen]

Hello everyone,

XCLJB is a Clojure language binding for the X Window System, similar
to the XCB (the X protocol C-language Bindings). It allows programmers
to communicate with and write GUIs for an X server in Clojure, without
having to drop down into C.

Source code, README, and examples: https://github.com/noodlewiz/xcljb

Leiningen dependency information:

[xcljb "0.1.0"]

As the version number indicates, this is a developmental release. This means
  - Things are usable, but not yet feature complete.
  - API not necessarily stable, though I won't break compatibility for
no reason.
  - Comments, suggestions welcome.

Open problems looking for suggestions:
  - How should I signal errors? XCLJB, like XCB, is mostly
asynchronous. Currently sending a request will immediately return a
Clojure promise. The promise will be delivered with either a reply or
an error when they arrive, this allows multiple requests to be sent
without blocking (this is the asynchronous part). I'd like to raise an
exception when a user deref the promise and the promise is an error,
but there seems to be no way of doing so. Should I make my own promise
type by implementing clojure.lang.IDeref? Is there another way of
achieving what I had in mind?

  - Is there an easier way to match against records? Events are
currently implemented as records, so event loops would have to look
like

(ns ...
  (:import [xcljb.gen.xproto_types ExposeEvent KeyPressEvent]))
(while true
  (let [e (wait-event conn)]
(condp instance? e
  ExposeEvent
  ...

  KeyPressEvent
  ...

  nil)))

I'd prefer not to make my user import the event types as if they
are Java classes. Is there a more Clojurey way of doing record type
matching? Is there a better way of implementing events?

Regards,

Vincent Chen

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

[David Nolen]

Nice work! :)


On Mon, Sep 9, 2013 at 9:39 PM, Alex Engelberg <
alex.benjamin.engelb...@gmail.com> wrote:

> http://github.com/aengelberg/clocop
>
> CloCoP is a Clojure wrapper of the Java library JaCoP. The acronyms stand
> for "Clojure/Java Constraint Programming". This invites comparison to the
> core.logic library, and you may wonder why we need both. There are a few
> ways in which, in my opinion, the JaCoP system is better than core.logic:
>
>- JaCoP is more "plug-in-able," with an extensive set of
>customizations to the way that the search operates. There are interfaces
>for different components of the search, and each has several
>implementations.
>- I found that with core.logic, I was somewhat limited by the set of
>available constraints. JaCoP has many different constraints that seem to
>more suit my needs for solving challenging problems.
>- As the core.logic people 
> say,JaCoP is 
> anywhere from 10X-100X faster than core.logic at solving Finite
>Domain problems.
>
> JaCoP has a lot of "global constraints" which are very powerful and
> essential for describing certain problems. As Radoslaw Szymanek (an
> author of JaCoP) says, "CP without global constraints is just [a] plain
> academic toy. Using problems with arithmetic constraints is doing CP bad
> publicity."
>
> If you'd like to see implementations of sample problems in CloCoP, check
> out the test 
> cases
>  (https://github.com/aengelberg/clocop/tree/master/test/clocop).
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: Clojure, floats, ints and OpenGL

[Mikera]

On Tuesday, 10 September 2013 01:03:12 UTC+8, Jozef Wagner wrote:

> You can typehing ints for locals (let, loop), restrictions are just for 
> function arguments.
> AFAIK the reason is combinatorial explosion at 
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java#L91
>

I never understood the point of these restrictions surely primitive 
function invocation is much better handled by:
a) generating the exact primitive function required in an AFn subclass 
(e.g. invokePrim(long, char, byte, Object); )
b) Creating a direct invocation of the method in a) at any function call 
site
c) The usual IFn.invoke(...) methods can handle the dynamic use cases when 
you pass this AFn to a higher order function

i.e. you don't really need these interfaces at all. As a bonus, the same 
method could also improve performance by avoiding type casts for 
non-primitive type-hinted arguments like String, since you aren't limited 
to casting every non-primitive argument via Object either.

Or am I missing something obvious?

 

> I have the same problem with char. Because I cannot typehint e.g. my 
> whitespace? function with ^char, I recieve a boxed Object and thus cannot 
> use == for comparison.
>
> JW
>  
>
> On Mon, Sep 9, 2013 at 6:02 PM, Mikera 
> > wrote:
>
>> +1 for supporting all the JVM primitive types properly.
>>
>> It is worth noting that the benefits would extend much further than just 
>> OpenGL, e.g.:
>>  - int is a commonly used type in Java interop. Casting to/from it all 
>> the time is a minor annoyance/overhead
>>  - int is the type used for array indexing on the JVM
>>  - all the small (< 8 byte) primitive types save memory footprint, which 
>> is important since memory bandwidth is the limiting factor in some workloads
>>  - int/float fit into a register (and therefore perform much better) on 
>> 32 bit machines (which still exist, believe it or not)
>>  - char is a pretty useful primitive type if you are doing text processing
>>  - byte is also frequently useful, especially for IO
>>
>> I believe that with some enhancements to the Clojure compiler, supporting 
>> all the JVM primitive types shouldn't be too difficult, and it would 
>> provide many benefits both in terms of overall performance and interop 
>> convenience.
>>
>> On Monday, 9 September 2013 21:43:12 UTC+8, Alex Fowler wrote:
>>>
>>> Hello!
>>>
>>> With this letter I would like to receive an answer from somebody from 
>>> the development team (if anyone else has something to say, you're surely 
>>> welcome :) ).
>>>
>>> I am working for a big multimedia company and recently I have been 
>>> considering moving to Clojure as the main language of development. We have 
>>> been doing Java and Scala before, but now when I tried Clojure and see the 
>>> possibilities it provides, I would definitely stand for it to be our 
>>> ground. However, while I am so satisfied with everything - the language, 
>>> the community, the Java interop, there is still something that hinders and 
>>> makes me linger. Namely, the lack of good support of floats and ints in the 
>>> language. While many people would not consider it to be a huge disadvantage 
>>> or even notice it, things are not so bright when it comes to OpenGL.
>>>
>>> The case is that OpenGL and 3D graphics hardware in general has no 
>>> support for doubles or longs. Therefore, all libraries, all data and all 
>>> computations are meant to be performed with floats and ints (shaders too). 
>>> Due to the lack of good support of these data types in Clojure (for 
>>> example, there are no ^float and ^int typehints, float and int values can 
>>> only be typecasted to, all calculations always retain doubles and longs), 
>>> results in too many extra typecasts, which are absolutely unnecessary and 
>>> take too much time. So, calculations become very cumbersome, even if we do 
>>> not take mandatory boxing into account.
>>>
>>> Considering that such kinds of calculations are usually abuntant in the 
>>> aforementioned types of applications, the penalty grows really huge. I have 
>>> endeavoured several discussions on the IRC to find out possible 
>>> workarounds. Although many good proposals by many good people were made, 
>>> aimed at improving the situation, none of them could solve the fundamental 
>>> lack of the ability to manipulate 32bit primitive (or even boxed) data 
>>> types. That lack renders Clojure not really suitable for heavy-load OpenGL 
>>> applications that require somewhat extensive calculations: some kinds of 
>>> games, simulations, generative graphics and so on. Considering how superior 
>>> Clojure is to any other language available for JVM, that black spot looks 
>>> especially embarrasing. And I could imagine falling back to Java for fast 
>>> computations, just like we fall back to ASM in, say C, that is very 
>>> undesirable and discouraging, since we want to pick Clojure for Clojure and 
>>> it will be too cumbersome to make 50/50% Java/Cloj

Re: Best way to pass through named arguments (destructured map)?

[Gunnar Völkel]

You can also checkout whether my library [1] suits you. Passing option maps 
to other functions with options and managing doc strings for these options 
(transitively) are the features it was written for. It will simplify 
functions with options in your own code but the calls to functions of third 
party libraries will remain the same.

[1] https://github.com/guv/clojure.options/

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