Re: slackpocalypse? next steps?

['Adrian A.' via Clojure]

> We’re almost certainly not going to find a *replacement* for Slack (or 
any other communications medium) 

Have you tried Mattermost? 
 - https://about.mattermost.com/
 - https://github.com/mattermost/platform


regards.

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

Java like static typing for Clojure?

[A. Levy]

Have you heard of Typed Clojure? (http://typedclojure.org)

It is an optional, gradual type system for Clojure. Does it offer enough to be 
useful or are you looking for something different?

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

Re: Lym - written by clojurescript and react native is on apple store

['Adrian A.' via Clojure]

> also support 1-on-1 video chat
Could you please detail how was this feature implemented?

Thanks.

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

Re: Frustrations so far

['Adrian A.' via Clojure]

The point is that an 'Integer' 
> (abstraction) has no sense of 'emptiness' or 'fullness'. 
>
> IMHO that might be true for a statically typed language, but in the case 
of a dynamic language like Clojure it makes perfect sense, and most users 
expect
this behavior. 

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

Re: [ANN] Edneditor.com

['Adrian A.' via Clojure]

>
> Very rudimentary at this point - so a lot of TODOs. But have a look, let 
> me know your thoughts. Hopefully it can help you out. 
>
> Seeing the name of the project, my first thought was: maybe finally a web 
based component/editor like https://github.com/josdejong/jsoneditor but for 
EDN :).
 

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

Re: dependency problem

[Juan A. Ruz @tangrammer]

(sorry previous comment was sent before I wanted  :- )
Hi Alan,
I think you should keep commons-code 1.9 as far as is the last-version 
required by any dep of your project
so ...

you could exclude globally (using :exclusions)  your dependencies that are 
causing the conflict and specified later in your :dependencies 
  :exclusions [org.clojure/clojure
 commons-codec]
  :dependencies [[org.clojure/clojure "1.7.0"]
   [commons-codec "1.9"]
   [twitter-api "0.7.8"]]

or just exclude it locally
  :dependencies [[org.clojure/clojure "1.7.0"]
   [commons-codec "1.9"]
   [twitter-api "0.7.8" :exclusions 
[commons-codec]]]

Hope it works for you!
Juan

El viernes, 13 de mayo de 2016, 12:41:43 (UTC+2), Juan A. Ruz @tangrammer 
escribió:
>
> Hi Alan,
> I think you should keep commons-code 1.9 as far as is the last-version 
> required by any dep of your project
> so ...
>
> you can 
>   :exclusions [org.clojure/clojure
>commons-codec]
>   :dependencies [[org.clojure/clojure "1.7.0"]
>  [commons-codec "1.9"]
>  [twitter-api "0.7.8"]]
>
>
>
>
>
> El viernes, 13 de mayo de 2016, 10:27:34 (UTC+2), Alan Forrester escribió:
>>
>> I have been trying to use the Twitter API library by Adam Wynne: 
>>
>> https://github.com/adamwynne/twitter-api 
>>
>> and it appears to have a dependency problem. 
>>
>> My project.clj file looks like this 
>>
>> (defproject hash-tag-counting-thingy "0.1.0-SNAPSHOT" 
>>   :description "FIXME: write description" 
>>   :url "http://example.com/FIXME"; 
>>   :license {:name "Eclipse Public License" 
>> :url "http://www.eclipse.org/legal/epl-v10.html"} 
>>   :dependencies [[org.clojure/clojure "1.7.0"] 
>> [twitter-api "0.7.8"]]) 
>>
>> And when I ran "lein deps :tree” I got 
>>
>> [twitter-api "0.7.8"] -> [clj-oauth "1.5.1"] -> [commons-codec "1.8"] 
>>  overrides 
>> [twitter-api "0.7.8"] -> [clj-oauth "1.5.1"] -> [clj-http "0.9.1"] -> 
>> [commons-codec "1.9" :exclusions [org.clojure/clojure]] 
>>
>> What is the recommended way to deal with a problem like this? 
>>
>> Alan
>
>

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

Re: dependency problem

[Juan A. Ruz @tangrammer]

Hi Alan,
I think you should keep commons-code 1.9 as far as is the last-version 
required by any dep of your project
so ...

you can 
  :exclusions [org.clojure/clojure
   commons-codec]
  :dependencies [[org.clojure/clojure "1.7.0"]
 [commons-codec "1.9"]
 [twitter-api "0.7.8"]]





El viernes, 13 de mayo de 2016, 10:27:34 (UTC+2), Alan Forrester escribió:
>
> I have been trying to use the Twitter API library by Adam Wynne: 
>
> https://github.com/adamwynne/twitter-api 
>
> and it appears to have a dependency problem. 
>
> My project.clj file looks like this 
>
> (defproject hash-tag-counting-thingy "0.1.0-SNAPSHOT" 
>   :description "FIXME: write description" 
>   :url "http://example.com/FIXME"; 
>   :license {:name "Eclipse Public License" 
> :url "http://www.eclipse.org/legal/epl-v10.html"} 
>   :dependencies [[org.clojure/clojure "1.7.0"] 
> [twitter-api "0.7.8"]]) 
>
> And when I ran "lein deps :tree” I got 
>
> [twitter-api "0.7.8"] -> [clj-oauth "1.5.1"] -> [commons-codec "1.8"] 
>  overrides 
> [twitter-api "0.7.8"] -> [clj-oauth "1.5.1"] -> [clj-http "0.9.1"] -> 
> [commons-codec "1.9" :exclusions [org.clojure/clojure]] 
>
> What is the recommended way to deal with a problem like this? 
>
> Alan

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

Similar lisps and emacs reimplementations?

[A. Levy]

Can you elaborate a little more on those nightmare scenarios? From my (amateur) 
reading of the EPL, it looks like the patent clauses apply to contributors to 
the program. In this case, Clojure. Does developing something in Clojure force 
you to release it under the EPL?

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

[ANN] DEEP-IMPACT-AG/flowgic

[Juan A. Ruz @tangrammer]

 

Hi guys, here sharing an (alpha) approach to write logic flows in a 
declarative way

https://github.com/DEEP-IMPACT-AG/flowgic 


One of the final purposes of this utility is to visualise the 
intended/written logic as you can see here 
https://cloud.githubusercontent.com/assets/731829/10277888/8a5bf848-6b59-11e5-96de-1b67fab4981b.png


Looking forward  your impressions and comments ... so I could keep 
improving it


Have a good day!


PS: it uses https://github.com/DEEP-IMPACT-AG/flowgic.graph to 
connect https://github.com/ztellman/rhizome as graph visualisation



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

Re: Flow control in Clojure

[Juan A. Ruz @tangrammer]

Hi Ditlev, 
I was struggling with same flow-control logic and I reached to this (alpha) 
solution based in describing logic flows
https://github.com/DEEP-IMPACT-AG/flowgic

so far It worked fine in my current code and i think that it also answers 
the 2 points that Daniel Compton mentioned 

>  1) decompose functions into smaller functions, regardless of these helper 
> functions being of no use anywhere else.
>  2) define a bunch of helper functions in a top-level let-expression - 
> again to avoid having functions which are too heavily indented?


Cheers!


El martes, 8 de diciembre de 2015, 21:18:18 (UTC+1), Ditlev Tøjner escribió:
>
> In designing our (by now) two clojure-based REST services we are 
> struggling with managing flow-control.
>
> (Disclaimer: earlier backgrounds are with Python, C, Javascript and once 
> upon a time Java/C# etc)
>
> What we'd like is to accomplish a series of steps which we feel are 
> universal to REST-services.
> In the context of PUT/POST that is:
> ---
> 1. ensure that the content is of a given format (application/json)
>
> 2. receive & validate input
> 2a. if the input is invalid, return error output (in our case describing 
> what went wrong)
>
> 3. create a new entry / update an existing entry
> (Note if you know the entire URI, then using PUT for both 
> updating/creating is acceptable)
>
> 4. format a response (typically containing the created/updated object)
> ---
>
> Fig1 details how, after several passes, we're dealing with this. The 
> approach is heavily inspired
> by Ref1 and essentially executes each step outlined above with the 
> understanding that failure might
> occur. If a failure occurs, an error message is returned (of course).
>
> We chose an approach similar to Ref1 because we wanted to abort on errors, 
> occasionally recover
> (such as update becoming create if no record is found) and we wanted 
> detailed errors which
> precludes the use of (and ...).
>
> The astute observer may note that our model fails to capture the concept 
> of recoverable failures
> - update-record* may fail for more reasons than simply not having a row 
> (transient errors, actual
> logic-related errors etc) some of which are non-recoverable. 
>
> As it stands, this means the function needs refactoring, *again*. 
> What all this boils down to is this: given the unique interplay of 
> immutability with LISP-style
> (AST) syntax - which techniques are successfully employed to avoid heavily 
> indented code ? Is
> the only solution really to either:
>
> 1) decompose functions into smaller functions, regardless of
> these helper functions being of no use anywhere else.
>
> 2) define a bunch of helper functions in a top-level let-expression - 
> again to avoid having
>functions which are too heavily indented?
>
>
> Does it ever get easier ? Are we missing something ? It seems extreme to 
> reach for monads for
> something of this nature.
>
> References
> 1. https://brehaut.net/blog/2011/error_monads (Ref1)
>
> Fig. 1. - a PUT endpoint
> 
> (defn update*
>   "create/update a pin."
>   [cid source rq]
>   (err/attempt-all
>[_ (chk/mediatype-in? (get rq :content-type) ["application/json"])
> rq (clojure.walk/keywordize-keys rq)
> ;; data which can come from the user
> input (merge {:method "app"
>   :seen_at (-> (at/now-utc) (at/->dt-utc-str))}
>  (get rq :body)
>  {:source_type (get source :type) :source_id (get source :
> id)})
> _ (av/input-valid? validate-pin-params input)
>
>
> ;; additional data extracted from URI & token
> record-data (merge input
>{:cid cid
> :uid (rq->uid* rq)})
> record (err/any (update-record* record-data)
> (new-record* record-data))]
>;; Success
>(rsp/created
> (url cid source)
> {:key-name "pinid"
>  :body {:request (model/transform record)}})
>;; Failure
>err/handle-failure))
>
> 
>

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

Any plan to add log4j 2 support to tools.logging?

[Didier A.]

Hi all,

I was wondering if any work is being planned on tools.logging to add log4j 
2 support?

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

Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

[A]

Here's another benchmark for comparison: 
https://code.google.com/p/redsvd/wiki/English

-A


On Monday, June 22, 2015 at 12:27:57 PM UTC-7, Dragan Djuric wrote:
>
> core.matrix claims that it is fast on its project page (with which I agree 
> in some cases). I expected from that, and from the last couple of your 
> posts in this discussion, that there are some concrete numbers to show, 
> which I can't find.
>
> My claim to win "ALL benchmarks" (excluding maybe tiny objects) came only 
> as a response to mike's remarks that I have only proven that neanderthal is 
> faster for dgemm etc.
>
> OK, maybe the point is that other libraries do not care that much about 
> speed, or that current speed is enough, or whatever, and I am ok with that. 
> I would just like it to be explicitly said, so I do not lose time arguing 
> about what is not important. Or it would be nice to see some numbers shown 
> to draw at least rough picture of what can be expected. I am glad if my 
> raising this issue would improve the situation, but I do not insist...
>
> On Monday, June 22, 2015 at 9:16:15 PM UTC+2, Christopher Small wrote:
>>
>> Well, we also weren't claiming to win "ALL benchmarks" compared to 
>> anything :-)
>>
>> But your point is well taken, better benchmarking should be pretty 
>> valuable to the community moving forward.
>>
>> Chris
>>
>>
>> On Mon, Jun 22, 2015 at 12:10 PM, Dragan Djuric  
>> wrote:
>>
>>> So, there are exactly two measurements there: matrix multiplication and 
>>> vector addition for dimension 100 (which is quite small and should favor 
>>> vectorz). Here are the results on my machine:
>>>
>>> Matrix multiplications are given at the neanderthal web site at 
>>> http://neanderthal.uncomplicate.org/articles/benchmarks.html in much 
>>> more details than that, so I won't repeat that here.
>>>
>>> Vector addition according to criterium: 124ns vectorz vs 78ns 
>>> neanderthal on my i7 4790k
>>>
>>> Mind you that the project you pointed uses rather old library versions. 
>>> I updated them to the latest versions. Also, the code does not run for both 
>>> old and new versions properly (it complains about :clatrix) so I had to 
>>> evaluate it manually in the repl.
>>>
>>> I wonder why you complained that I didn't show more benchmark data about 
>>> my claims when I had shown much more (and relevant) data than it is 
>>> available for core.matrix, but I would use the opportunity to appeal to 
>>> core.matrix community to improve that.
>>>
>>> On Monday, June 22, 2015 at 8:13:29 PM UTC+2, Christopher Small wrote:
>>>>
>>>> For benchmarking, there's this: 
>>>> https://github.com/mikera/core.matrix.benchmark. It's pretty simple 
>>>> though. It would be nice to see something more robust and composable, and 
>>>> with nicer output options. I'll put a little bit of time into that now, 
>>>> but 
>>>> again, a bit busy to do as much as I'd like here :-)
>>>>
>>>> Chris
>>>>
>>>>
>>>> On Mon, Jun 22, 2015 at 9:14 AM, Dragan Djuric  
>>>> wrote:
>>>>
>>>>>
>>>>>> As for performance benchmarks, I have to echo Mike that it seemed 
>>>>>> strange to me that you were claiming you were faster on ALL benchmarks 
>>>>>> when 
>>>>>> I'd only seen data on one. Would you mind sharing your full benchmarking 
>>>>>> analyses?
>>>>>>
>>>>>
>>>>> I think this might be a very important issue, and I am glad that you 
>>>>> raised it. Has anyone shared any core.matrix (or, to be precise, 
>>>>> core.matrix) benchmark data? I know about Java benchmark code project 
>>>>> that 
>>>>> include vectorz, but I think it would help core.matrix users to see the 
>>>>> actual numbers. One main thing vectorz (and core.matrix) is claiming is 
>>>>> that it is *fast*. Mike seemed a bit (pleasantly) surprised when I shared 
>>>>> my results for vectorz mmul... 
>>>>>
>>>>> So, my proposal would be that you (or anyone else able and willing) 
>>>>> create a simple Clojure project that simply lists typical core.matrix use 
>>>>> cases, or just the core procedures in core.matrix code that you want to 
>>>>> measure and that you are interested

Re: separation of concerns w/o encapsulation

[Juan A. Ruz @tangrammer]

Hi guys, 
when you talk about encapsulation do you mean using defrecords + protocols ?
In this case, we are talking of choosing defrecords instead of plain 
functions. Maybe it would be better if we talk too about the drawbacks of 
this choice. For example, can we compose or extend protocol functions (I 
mean to extend existent component protocol functions). 

In some occasion, I wanted to use juxt/bolt [(formerly juxt/cylon) security 
component based system] in GoogleAppEngine but juxt/bolt uses http-kit and 
GAE dont' let you use this lib dependency. So at last I had to fork 
juxt/bolt to switch the http client library for plain java.net classes. So, 
I wonder myself which are the limits of reusability in component pattern. 








El viernes, 8 de mayo de 2015, 18:29:50 (UTC+2), Brian Craft escribió:
>
> Talk on the list about encapsulation usually comes back to some variation 
> of "you don't need it when you have immutable data structures". But in the 
> long term I'm finding the problem of working w/o encapsulation is not the 
> danger of data being mutated under you. Rather, it's the danger of all the 
> module boundaries blurring over time, leading to the big ball of mud: a 
> very fragile code base where everything depends on everything else.
>
> E.g. if you model your application with a plain data structure which you 
> pass around to different modules, each concerned with a small part of that 
> data structure, the tendency over time is for every module to become 
> concerned with every part of that data structure.  Then you have no 
> separation, nothing is reusable, and the code is very fragile.
>
> How do you avoid this, practically? In OO it would be enforced with 
> encapsulation, so the next developer (which might be me, six months later) 
> trying to fix a bug, or add a feature, knows "Oh, I shouldn't peek in here: 
> this module isn't supposed to depend on that piece of data".
>

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

wondering the reasons to choose defrecord vs reify in stuartsierra/component

[Juan A. Ruz @tangrammer]

Hi guys, 
I'm just wondering the pros/contras that justify to choose defrecord vs 
reify as component fn constructor.

in the component README we can read 
"To create a component, define a Clojure record that implements the 
Lifecycle protocol."

Yes I know that "defrecord creates an immutable persistent map which 
implements a protocol." but I think that the same thing can be achieved 
with reify (BTW: "om" way to define component) over a persistent map... 

Do you think there are more reasons to set defrecord as default base fn for 
components?

Thanks in advance
Juan

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

Which could be the best clojure alternative to replace play framework?

[Juan A. Ruz @tangrammer]

Hi guys,

just looking for possible (and hopefully experienced) directions to replace 
Play Framework and its popular Akka support that as the doc page states 
<https://www.playframework.com/documentation/2.0/JavaAkka>: "Akka provides 
a better platform to build correct concurrent and scalable applications"


Thanks in advance and have great clojure coding!
Juan

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

Re: clojure, not the go to for data science

[A]

Can't recall which one, but I believe one of the aforementioned books has a 
chapter on Weka use with examples.

-A


On Monday, April 6, 2015 at 12:40:20 PM UTC-7, Goldritter wrote:
>
>  I wonder, has somebody ever tried to write something like a clojure 
> wrapper for WEKA (http://www.cs.waikato.ac.nz/ml/weka/) or added WEKA to 
> a clojure project? 
>
> I have done this for a classification problem, but it was rather inchoate 
> and only to create some libsvm and naive bayes classifier.
>
> Marcus
>
> Am 06.04.2015 um 21:15 schrieb Christopher Small:
>  
>
> OK; Here's my humble stab at something along these lines: 
> http://clojure-datascience.herokuapp.com/ (source code here: 
> https://github.com/metasoarous/clojure-datascience).
>
> The data is currently just an edn file, so contributions should come in 
> the form of pull requests. However, we could look at moving the data to a 
> db or something in the future if we want a more dynamic submission process. 
> Right now I've seeded it with A's resource list, and not much else, so 
> please contribute!
>
> Also happy to accept other improvements here if anyone has any good ideas. 
> This includes discussion over the right category breakdown and assignments, 
> and any interface improvements which might better utilize the data. I 
> suggest using github issues for anything that needs discussion, or via this 
> thread for general direction thoughts.
>
> Cheers
>
> Chris
>
>  -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>  

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

Re: clojure, not the go to for data science

[A]

Thanks for taking the initiative :) Looks good.

My two cents is to prefer something instead of the word "goto" though, 
which could imply an archaic coding semantic.  Perhaps "...a growing 
resource to consolidate links to Clojure Data Science topics"?
or perhaps something that describes the goals and motivations, in the 
spirit that https://www.refheap.com/about does for RefHeap could be useful 
as well

best,
-A




On Monday, April 6, 2015 at 12:15:02 PM UTC-7, Christopher Small wrote:
>
>
> OK; Here's my humble stab at something along these lines: 
> http://clojure-datascience.herokuapp.com/ 
> <http://www.google.com/url?q=http%3A%2F%2Fclojure-datascience.herokuapp.com%2F&sa=D&sntz=1&usg=AFQjCNEr1tBFRIBOE0yFGrzQK5ZkuVjT-w>
>  
> (source code here: https://github.com/metasoarous/clojure-datascience).
>
> The data is currently just an edn file, so contributions should come in 
> the form of pull requests. However, we could look at moving the data to a 
> db or something in the future if we want a more dynamic submission process. 
> Right now I've seeded it with A's resource list, and not much else, so 
> please contribute!
>
> Also happy to accept other improvements here if anyone has any good ideas. 
> This includes discussion over the right category breakdown and assignments, 
> and any interface improvements which might better utilize the data. I 
> suggest using github issues for anything that needs discussion, or via this 
> thread for general direction thoughts.
>
> Cheers
>
> Chris
>
>

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

Re: clojure, not the go to for data science

[A]

Please feel free to create something like http://www.clojure-toolbox.com/ 
for data science in Clojure, that would be great.

On Sunday, April 5, 2015 at 3:33:11 PM UTC-7, Sayth Renshaw wrote:
>
> Would be good to get that on a wiki for all so we could update and share 
> as a resourcee.
>
> Sayth
>
> On Mon, 6 Apr 2015 at 04:47 Christian Weilbach  > wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> >>
>>
>> >> http://viewer.gorilla-repl.org/view.html?source=github&;
>> user=ghubber&repo=cnc&path=rincanter.clj
>> >>  I am not sure whether this fits the design atm. though. I also
>> >> had a look at renjin, but I think the native plugins mandate an
>> >> RVM integration atm.
>> >>
>> >
>> > You might find http://beakernotebook.com interesting, if you
>> > haven't seen it before. It allows several languages in the same
>> > notebook, and has  a simple mechanism for sharing data between the
>> > language environments. It's pretty green at the moment, but it has
>> > some serious backing, so could be pretty useful once it's got a bit
>> > more polish on it. I chatted a little with someone who was hoping
>> > to implement a Clojure plugin for it, although I don't know how
>> > they've gotten on since.
>>
>> This is really nice, thank you for pointing out! Effectively though
>> this means you need to manually(!) convert data between all cells,
>> which only works if serialization between the environments is a lot
>> less work than processing the data and you don't want to call alien
>> procedures e.g. in a loop. It also means that part of datasets need to
>> be hold in memory in all runtimes at the same time. So I am not sure
>> whether JSON synchronisation of state between runtimes is good in the
>> long run, it feels fairly hacky and having that many runtimes already
>> causes a big type-conversion matrix and probably many subtle
>> incompatibilities. It is the most pragmatic approach though and
>> probably the most successful for now.
>>
>> They are not opinionated about languages, while I would like to
>> integrate data science tooling in Clojure, so it is easier to bring
>> people on board, not to make language hopping the top goal, which is
>> for mentioned performance reasons and from a Lisp/Clojure perspective
>> a bit questionable imo (esp. since all these languages have to drop to
>> C to get some performance). I also would like to have the environment
>> written in Clojure (read: gorilla). I would be happy to integrate
>> Python and R on the JVM, e.g. through Jython and RServe/renjin, which
>> allows to share code much better down to direct method dispatch. Do
>> you think integrating R cells in this way would be reasonable for you?
>> Or just allowing plugins for new cell-types...
>> (With RServe manual synchronisation with the RVM is still necessary
>> btw., renjin would solve this, but needs more support for CRAN
>> packages imho).
>>
>> >
>> > I also have taken a paper I liked and implemented a quick version
>> > of
>> >
>> >> SNE, which was fairly nice to do in Gorilla REPL:
>> >>
>> >> http://viewer.gorilla-repl.org/view.html?source=github&;
>> user=ghubber&repo=cnc&path=stochastic-neighbour-embedding.clj
>> >>  A problem seems to be unicode support, I tried to use some math
>> >>  symbols from the notation in the paper directly, but the viewer
>> >> seems to have a problem with it.
>> >>
>> >
>> > Not sure what the problem is there - my feeling is it should just
>> > work, on the Gorilla side. If there's a test case you can point to
>> > (with an expected result) I can take a look at it.
>>
>> The problem is just that viewer.gorilla-repl.org seems to have some
>> encoding problems with UTF-8. See the sum sigma symbol for instance:
>> https://github.com/ghubber/cnc/blob/master/stochastic-
>> neighbour-embedding.clj#L72
>> which is corrupted in the viewer. I hoped that was easy to fix.
>>
>>
>> Christian
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJVIYNTAAoJEKel+aujRZMk5wsIAIl/CoX0E7u6lSJIHQfWI8U5
>> HZWUPjHJie+sbIt+G4qm8SozAbmPEc6mRSDC3kP1v2JhoJv4y1j6klWmHH9Xm3dj
>> eqxNgVTNClk5ZUUcAFhcy2gUCc9RP6AJF27TnSO+ArG4qApueU+s297uHTAfGefk
>> hj+AbzCGoQOgvw1F6sUOTQ4KV6Z51/pYsjIgxwPC5vvzIKgv+qiKXMWLow1mM9uu
>> tG4h/HDSxdjCWdVm4sCuipi5tJJmdYEuYHjtFiMVbpVA5YZT3KleL4K6Gn

Re: clojure, not the go to for data science

[A]

>> Thanks, that is an awesome list of resources. 
kudos to the respective authors. 
-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/d/optout.

Re: clojure, not the go to for data science

[A]

Caveats... there is a lot to explore, things are continually changing and 
evolving, I haven't made an exhaustive search, but here is what is quickly 
google-able... YMMV

# Books
- Eric Rochester: 
https://www.packtpub.com/big-data-and-business-intelligence/mastering-clojure-data-analysis
 
and  
http://www.ericrochester.com/pages/announcements/clj-data-analysis/index.html
- Akhil Wali:  
https://www.packtpub.com/big-data-and-business-intelligence/clojure-machine-learning
   


# Youtube videos
- Jony Epsilon: http://gorilla-repl.org/
- Edmund Jackson: "Clojure Data Science" 
https://www.youtube.com/watch?v=RVmY2lQ4DHE
- Mike Anderson: "Enter the Matrix" 
https://www.youtube.com/watch?v=_h9TLJtjSJo and "Machine Learning Live" 
https://www.youtube.com/watch?v=QJ1qgCr09j8
- Aysylu Greenberg: "Loom and Graphs in Clojure" 
https://www.youtube.com/watch?v=wEEutxTYQQU
- Cascalog: https://www.youtube.com/results?search_query=cascalog

# Clojure (wrappers)
- clj-vw: https://github.com/engagor/clj-vw
- deeplearning4j.org e.g. [org.deeplearning4j/dl4j-spark 
"0.0.3.3.2.alpha1"] 
- core.matrix (https://github.com/mikera/core.matrix)
- Raynes/Conch (shell out to the executable of your choice.) 
https://github.com/Raynes/conch
- loom (https://github.com/aysylu/loom)
- https://github.com/marcliberatore/mallet-lda
- java interop

I recommend settling on a particular topic/method/problem you are 
interested in solving and then searching specifically on that, craft a few 
functions, try some approaches, existing tools, etc... 

best,
-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/d/optout.

Re: clojure, not the go to for data science

[A]

Clojure is an Amazing tool for data science.  If people are slow to realize 
this, that is their disadvantage.

The premise that "Clojure hasn't developed as a go to for data science" 
simply doesn't ring true to me at all.  There are numerous examples of 
Clojure use for data science, there are books about it, there are youtube 
videos about it, there are practitioners, there is Incanter, there are 
Transducers, there are Notebooks (Gorilla is awesome), there are Java 
libraries, there are wrapper Clojure libraries, there are a lot of useful 
tools.  

Clojure is my "go to for data science" and I often use it either directly, 
or to manage runs using fast tools (like vw), or to prepare SQL-izations of 
data etc... (Btw, your SQL often runs as easily in 
Postgres/Redshift/Hive/Spark with minimal changes if any if you need to 
scale etc... If you treat your SQL the way you treat HTML, let your customs 
functions write it, you get a lot of analytic power that is not tied to any 
particular database).  There is Clojurescript for visualization... There is 
so much that I am certain I am forgetting to mention some of it.

Also, Big +1 for emacs use (cider is awesome! I rarely want to touch a 
mouse... ) 

Thanks for an amazing, innovative Emacs and Clojure commuity!!

-Avram

The sky is the limit.  







On Sunday, March 29, 2015 at 2:55:34 AM UTC-7, Sayth Renshaw wrote:
>
> Hi 
>
> I last learned clojure in 1.2. Just curious why Clojure hasn't developed 
> as a go to for data science? 
>
> It never seems to get a mention R,Python and now Julia get the attention. 
> By design it would appear that Clojure would be a good fit. Is it a lack of 
> libraries, ease of install, no good default environment  (R Rstudio, 
> IPython ) where as you would need to use emacs with clojure, or is there 
> just a better default use of Clojure? 
>
> Sayth

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

Re: which are the pros and cons between stuartsierra/component and prismatic/graph?

[Juan A. Ruz @tangrammer]

Thanks to all for your good points!

Sorry for the delay answering but I needed to review the docs first, now 
I'll try to be brave and summarise here Graph vs Component features and/or 
properties ...

1. *graph* and *component* solve "dependency injection" 
2. *component* solves "state management" (Lifecyle protocol and SystemMap 
record)
3. *component* comes with "reloaded workflow"
4. *graph* lets you "analyze, change and compose" your functional 
computation
5. *component* forces you to use defrecord

Ok, so I'm convinced now that component is great for state management!
... but, *how can you "analyze, change and compose" the internals 
(functional computation) of your defrecords???*
I mean that component lib is really great for composing your system (and 
repl development including mocking components!) but forces you to use 
closed component that others projects can't *easily* extend [1] or change,
so for example, which would be the good pattern to follow if you need 
monitoring/logging your system in *component (*having that defrecord 
limitation)? 

what do you think if you *write your components using graph*?
So we keep 
+ system composable using component
+ component composable using graph
=> example code here 
<https://github.com/milesian/system-examples/blob/318f58383a7a4917c08147c3d0023e5bd5d93af8/src/milesian/graph_example.clj>

 
Thanks again!
Juan


[1] This was my own newbie attempt to extend defrecords 
tangrammer/defrecord-wrapper 
<https://github.com/tangrammer/defrecord-wrapper> , and milesian/aop 
<https://github.com/milesian/aop> the component integration one


El miércoles, 4 de febrero de 2015, 13:46:33 (UTC+1), Juan A. Ruz 
@tangrammer escribió:
>
> Hi guys!
>
> Can anyone give some insight on the features or downsides of choosing 
> component vs graph libs?
>
> Or maybe explain the advantages of using defrecords instead of plain fns?
>
> thanks in advance! 
> Juan
>
>  

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

which are the pros and cons between stuartsierra/component and prismatic/graph?

[Juan A. Ruz]

Hi guys!

Can anyone give some insight on the features or downsides of choosing 
component vs graph libs?

Or maybe explain the advantages of using defrecords instead of plain fns?

thanks in advance! 
Juan

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

StackOverflow TV Opportunity to Promote Clojure

[A. Webb]

StackOverflow just announced an experimental project to produce videos in 
its New York City office. This could be a great opportunity to polish up 
one of your presentations and promote Clojure to a wide audience. No 
speaker fees, but reasonable travel costs covered.

Post: http://meta.stackoverflow.com/q/270574/1756702
Email: t...@stackoverflow.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/d/optout.

ANN: [R User Conference]

[A]

I hope it's allright to mention here that the R User Conference is 
happening June 30-July 3 in Los Angeles.  There are a number of ways 
Clojure and R can be used together for statistical programming and data 
analysis.  

Observing the R community may be insightful for the Clojure community with 
respect to the Incanter project and other data science oriented efforts in 
Clojure.

"R is a free software programming language and software environment for 
statistical computing and graphics. The R language is widely used among 
statisticians and data miners for developing statistical software and data 
analysis." -wikipedia

The R User Conference
June 30 - July 3 2014
UCLA, Los Angeles, CA
http://user2014.stat.ucla.edu 

- great speakers
- free tutorials
- both research and business topics
- interesting to both novices as well as professionals 
- affordable

- twitter: #useR2014. 

Both for novice and professional data scientists in industry/academia 
welcome.


Regards,
Avram

P.S.  R in the functional programming idiom:  
http://adv-r.had.co.nz/Functional-programming.html



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

Re: Best way to create a namespace at runtime from a web app

[A. Webb]

Have you tried the aptly named 
create-ns
?

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

Re: regex

[A. Webb]

On Friday, April 18, 2014 8:28:03 AM UTC-5, Thumbnail wrote:
>
>
> I had a couple of insights.  First, to allow the dfa to be generated 
>> programmatically, I changed it from a map to a vector.  This means 
>> that the next state can just be an integer.  Second, I decided that 
>> the terminal state would always be at index 0 ... 
>>
>
> Shouldn't a DFA allow for *any* *set* of states to be terminal? For 
> instance, the minimal DFA for (ab)*(1 + a) has two states, both terminal. 
>

I haven't read through the above, but will have to later as I am familiar 
with the excellent linked article, so thanks for bumping this back to the 
top.

As to your question, there is a straightforward translation from multiple 
terminal states to a single one. Add a special terminal input symbol to 
your alphabet and consider any input strings to be terminated by that 
symbol. For each of the terminal states add a transition to a single 
terminal state for the terminal symbol.

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

Re: The Cons in iterate's return value

[A. Webb]

On Wednesday, April 16, 2014 10:35:14 PM UTC-5, Mars0i wrote:
>
>
> But then should realized? be able to deal with a Cons containing a LazySeq?
>
> (Is this an issue worthy of JIRA? I've never submitted there, and am not 
> sure I know enough to do so.  Willing to try to figure it out.)
>

No, realized? works as intended on a single object. If you want to know if 
there is an unrealized portion remaining of a sequence, just roll your own 
function to step through it, being careful not to force realization of 
unrealized portions while doing so. Untested example:

(defn seq-realized? 
  "Returns false if there is an unrealized tail in the sequence,
  otherwise true."
  [s] 
  (if (instance? clojure.lang.IPending s) 
(if (realized? s) 
  (if (seq s) 
(recur (rest s)) 
true) 
  false) 
(if (seq s) 
  (recur (rest s)) 
  true)))

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

Re: Questions regarding Map vs Record and usage

[A. Webb]

You can refer-in the first (factory function) to another namespace; for the 
second you'd have to import the class. I prefer the first. The third is 
special syntax for the reader.

As to the last question, I don't know, but it allows you to define your 
own. For example, 

(defrecord Book [title author] 
  clojure.lang.IFn 
  (invoke [this x] (get this x)) 
  (invoke [this x not-found] (get this x not-found)))

(def b (->Book "Lord of the Rings", "Tolkien"))

(b :title) ;=> "Lord of the Rings"

But you could alter the behavior as desired.


On Wednesday, April 9, 2014 1:51:01 PM UTC-5, Anthony Ortiz wrote:
>
> I see that there are several ways of instantiating a record :
>
>
> (->Book "Lord of the Rings", "Tolkien")
>
> (Book. "Lord of the Rings", "Tolkien")
>
> #user.Book{:title "Lord of the Rings", :author "Tolkien"}
>
>
> Questions :
> 1) The second version is referred to as the "original" version so I'm 
> wondering which is the preferred method. 
> 2) Why is the third version not within a list? I thought that for the 
> language to consider something "callable" it had to be the first argument 
> in a list (eg : (+ 1 2))
> 3) The record that is returned via (def b [version of choice goes here]) 
> is treated as a map when using the form (:title b) but doesn't treat it as 
> a map when using the form (b :title) which seems pretty inconsistent to me; 
> is there are valid reason for this inconsistency? I'm sure I'm missing 
> something.
>
> Thanks! 
>

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

Re: Name for this pattern: side-effect from swap!

[A. Webb]

See https://groups.google.com/d/topic/clojure/2dHvX7bf7nA/discussion, 
http://stackoverflow.com/a/22409846/1756702, where the old and new state of 
an atom is returned using the lower-level compare-and-set! operation.

On Tuesday, April 8, 2014 10:41:50 AM UTC-5, John Hume wrote:
>
> I sometimes find that after mutating an atom, I want to create some 
> side-effect that depends on the old and new state as well as the context in 
> which the change was made. Because of the dependence on context, a watch 
> doesn't work (unless there's something I'm not thinking of). So I add 
> things to the new atom state (returned by swap!) purely to tell the calling 
> code what side-effect to have (or give it the data it needs to decide what 
> side-effect to have). That additional state isn't used anywhere other than 
> the fn that called swap!.
>
> One gotcha to this approach is that one must be careful not to leave some 
> old side-effect causing state in place to cause another side-effect based 
> on stale data.
>
> Is there a name for this pattern? A standard way of implementing it? A 
> better alternative?
>
> One alternative I'm aware of is using mutable locals (provided by 
> https://github.com/ztellman/proteus) as a side-channel of communication 
> from swap!. Both approaches strike me as messy, though a let-mutable 
> probably makes it more obvious that something funny is going on, and it 
> doesn't pollute the atom.
>
> Thanks.
> -hume.
>

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

Re: Lazy sequence - how they work internally

[A. Webb]

On Tuesday, April 8, 2014 7:57:10 AM UTC-5, sorin cristea wrote:
>
>   
> What exactly you mean by '*The point was you aren't using lazy-seq as 
> intended here since you are always creating a singleton sequence*' ? In 
> my sum function...I intend to compute sum of elements of a collection.
>

Lazy-seq is intended to build sequences. Generally you'd have each 
invocation of lazy-seq produce one or more elements of a sequence. You are 
only nominally building a sequence. It is always just one element. You are 
reducing a collection to a sum. That is the job of reduce. If you want to 
delay evaluation for a given argument, use a thunk or a delay.

(defn my-sum [n] (reduce + (range n)))

(def my-result 10) ; my-result is 45 (eagerly evaluated)

(def my-thunked-result (fn [] (my-sum 10))) ; the sum is not 
calculated until evaluating (my-thunked-result), answer is not cached

(def my-delayed-result (delay (my-sum 10))) ; the sum is not 
calculated until forcing @my-delayed-result, answer is cached for 
subsequent use


 

> [I]f I [d]o this *(def x **(test-fc ...))*, and then *x,* this is not the 
> same thing with *(test-fc ...)* ?, I understand the issue related to time 
> to compute this sum, but the same time is taken when I call x, right ?
>
> Yes, that's what I said. Only in the first case evaluation is delayed 
until you request the value of `x` and in the second it is requested 
immediately to print at the REPL. You might find it instructive to put some 
`println`s in your code to see how and when your calculation is progressing 
and to use a large but still reasonable size collection, say 1 million 
elements.
 

> Thanks for the hint with trampoline function, really interested .
>
> Sorin.
>
>

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

Re: Lazy sequence - how they work internally

[A. Webb]

The point was you aren't using lazy-seq as intended here since you are 
always creating a singleton sequence. What's going on behind the scenes 
here is in effect just trampolining thunks.

(defn thunked-sum [sum coll]
  (if-let [[x & more] (seq coll)] 
(fn [] (thunked-sum (+ sum x) more))
sum))

(trampoline (thunked-sum 0 (range 10))) ;=> 45

The "trampoline" portion of your lazy seq is the while loop in this part of 
the Java implementation of LazySeq

final synchronized public ISeq seq(){
sval();
if(sv != null)
{
Object ls = sv;
sv = null;
while(ls instanceof LazySeq)
{
ls = ((LazySeq)ls).sval();
}
s = RT.seq(ls);
}
return s;
}


If you do (test-fc (range 210432423543654675765876879)) at your REPL, 
evaluation is forced for the print, but because your input is so large, the 
calculation time is prohibitively long. If you placed this in a def 
instead, evaluation would be delayed until requested at which point it 
would then take prohibitively long to complete.

On Monday, April 7, 2014 3:01:54 PM UTC-5, sorin cristea wrote:
>
>
> Hi Gianluca, 
>
>  I have a question ; why when a run/execute command/code line (test-fc 
> (range 210432423543654675765876879)) it's not executed the function 
> test-fc and return the sum for all 210432423543654675765876879 elements? 
> why should I put the test-fc reference to a variable, x, like you present 
> below. ( this is related to your phrase - "your function computes a 
> sequence of just one element (the sum of the collection members" - why ?)
>
>  In this case (def x (test-fc (range 210432423543654675765876879)) I see 
> here a problem, I keep a reference to the head of sequence and this will 
> imply that the GC will can't garbage the unused items, if is wrong what I'm 
> say please correct me. 
>
>  thanks a lot
>  Sorin.
>

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

Re: How do I detect the end of a file without catching an exception?

[A. Webb]

On Monday, April 7, 2014 1:14:40 PM UTC-5, guns wrote:
>
> On Mon  7 Apr 2014 at 11:07:37AM -0700, Simon Brooke wrote: 
> > OK, the second question I've sort of answered for myself, by riffing on 
> the 
> > source of line-seq: 
> > 
> > (defn expr-seq 
> >   "Returns forms from src (assumed to be Clojure source) as a lazy 
> sequence 
> > of expressions" 
> >   [^java.io.PushbackReader src] 
> >   (when-let [expr (read src)] 
> > (try 
> >   (cons expr (lazy-seq (expr-seq src))) 
> >   (catch RuntimeException eof 
> > 
> > However, line-seq doesn't bother with catching an exception (presumably 
> > because it's not using a PushbackReader). So I come back to my first 
> > question: how do I detect the end of a file? 
>
> Use clojure.core/read with three params: [stream eof-error? eof-value] 
> From the Slamhound source: 
>
> (take-while #(not= ::done %) (repeatedly #(read rdr false ::done))) 
>
> guns 
>

If using clojure.edn, which might be a good idea here, the syntax is 
slightly different for specifying an EOF marker, e.g.

(let [sentinel (Object.)] 
  (take-while #(not= sentinel %) (repeatedly #(edn/read {:eof sentinel} 
file

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

Re: Fn as value matcher in core.match

[A. Webb]

It is always matching the first clause because it is getting translated 
into a `let` binding. In match, the left-hand side `get` is just a symbol, 
not the `var` it resolves to, so might as well be `(let [fun assoc] (match 
fun foo "foo!"))` where `foo` will just be bound to `assoc`.

Match does not recognize vars on the left, but does recognize local 
bindings, so one option is to install them first

(let [fun assoc
  get get
  assoc assoc]
  (match fun
get "get"
assoc "assoc"
:else "other"))

Another option would be to use predicates

(let [fun assoc]
  (match fun
(_ :guard (partial identical? get)) "get"
(_ :guard (partial identical? assoc))"assoc"
    :else "other"))

Another would be to wrap the functions in a way their value is respected, 
e.g. as a key in a map

(let [fun assoc]
  (match {fun nil}
{get _} "get"
{assoc _} "assoc"
:else "other"))

None of these are ideal, but the last seems the least offensive to me. One 
might wish for a special `(:value x)` syntax for such cases. 

On Monday, April 7, 2014 7:24:10 AM UTC-5, Serzh Nechyporchuk wrote:
>
> How can I match fns as values? For example:
>
> (let [fun assoc]
>   (match [fun]
>  [get] "get"
>  [assoc] "assoc"
>  :else "other"))
>
> The example above is not match correctly. It always matches on first 
> clause.
>
> 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/d/optout.

Re: remove first?

[A. Webb]

On Wednesday, April 2, 2014 3:39:47 PM UTC-5, Christopher Howard wrote:
>
> On Wed, 2 Apr 2014 14:07:47 -0600 
> Timothy Baldridge > wrote: 
>
> > I don't know of anything built-in, but this should do the trick: 
> > 
> > (defn remove-first [f [head & tail]] 
> >   (if (f head) 
> >   tail 
> >   (cons head (lazy-seq (remove-first f tail) 
> > 
> > Timothy 
> > 
> > 
>
> Thanks. This seems to work for my purposes, although I modified it to 
> handle the empty vector: 
>
> (defn remove-first [f [head & tail]] 
>   (if (not head) [] 
>   (if (f head) 
>   tail 
>   (cons head (lazy-seq (remove-first f tail)) 
>
> This implementation doesn't seem to work on everything that "remove" 
> works on: 
>
> com.example.myapp=> (remove #(= [1 2] %) {1 2 3 4}) 
> ([3 4]) 
> com.example.myapp=> (remove-first #(= [1 2] %) {1 2 3 4}) 
> UnsupportedOperationException nth not supported on this type: 
> PersistentArrayMap  clojure.lang.RT.nthFrom (RT.java:835) 
>
 
To fix that, use `seq` on the collection argument. Also, if you want a 
emtpy sequence as a result instead of nil, just move the lazy-seq up since 
(lazy-seq nil) is an empty sequence.
 
(lazy-seq (when-let [[head & tail] (seq coll)] ...)

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

Re: Basic string modification question

[A. Webb]

Using subs (no need for join) is the way I would go, just define
 

(defn replace-at [s n c] (str (subs s 0 n) c (subs s (inc n

(replace-at "hello" 1 "a") ;=> "hallo"

and carry on.

 

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

Re: REPL: viewing data structures containing infinite lists

[A. Webb]

On Tuesday, April 1, 2014 11:00:37 AM UTC-5, Andreas Liljeqvist wrote:
>
> Is there any good reason for not providing a default value for 
> *print-length*?
> I think that if you *really* want to print a list containing 100K items, 
> you would have to set *print-length*.
>
> Basically it seems less harmful to set it to a nice value by default(42?) 
> than possible locking up the REPL.
>

For the lein REPL, merge this into your ~/.lein/profiles.clj 

{:user {:repl-options {:init (set! *print-length* 42)}}} 

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

Re: Strange behaviour for proxy when two abstract classes are passed in

[A. Webb]

On Monday, March 31, 2014 4:34:17 PM UTC-5, zcaudate wrote:
>
> I know this is a silly example but I am curious to know what is happening 
> with the proxy method.
>
> I have set up two calls to proxy:
>
> 1.
>   (def cp
> (proxy [java.util.AbstractMap clojure.asm.ClassVisitor] []))
>
> 2.
>   (def cp
> (proxy [clojure.asm.ClassVisitor java.util.AbstractMap] []))
>
>
> The first call is fine and it return cp.  The second call gives me an 
> exception.
>

You cross-posted to Stack Overflow Stack 
Overflow<http://stackoverflow.com/q/22779892/1756702>. 
Copy of my answer there:

Neither will work in Clojure 1.6.0. In 1.5, `clojure.asm.ClassVisitor` was 
an interface instead of an abstract class. Proxy expects at most one class 
followed by optional interfaces. As `java.util.AbstractMap` is an abstract 
class, it cannot appear second in the list of class-and-interfaces. 

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

Re: Function from a symbolic expression

[A. Webb]

On Monday, March 31, 2014 12:13:25 PM UTC-5, Jony Hudson wrote:
>
>
> (defmacro functionalise
>   [ex var]
>   (let [arg (gensym)
> body (postwalk-replace {var arg} ex)]
> `(fn [~arg] ~body)))
>
>
This works as written, it is just that macros do not evaluate their 
arguments, so you do not want to quote you expression. 

(def foo (functionalise (+ 2 x) x))
(foo 40) ;=> 42

If you are working with quoted expressions, you'll have to eval in the 
macro and take the one-time hit there

(defmacro functionalise2
  [ex var]
  (let [arg (gensym)
body (clojure.walk/postwalk-replace {var arg} ex)]
`(fn [~arg] ~(eval body

(def foo2 (functionalise2 '(+ 2 x) x))
(foo2 40) ;=> 42

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

Re: GSoC 2014: org applications now open

[A]

I think this is a great discussion, and there are myriad ways to get there. 
I haven't settled my own opinions firmly enough to advocate for one 
implementation over another at this point, but I do think that Incanter 
could become a killer toolbox (even more than now) with the additon of...:


1. a literate programming "Notebook" solution - inspiring repeatable 
analysis, to communicate or publish methods and results).  Perhaps RStudio 
(http://www.rstudio.com/ide/), Light Table, and Emacs should be metaphors 
for the shape this could take.  A stretch goal might be something like 
Mathematica if this is even possible.

2. a Clojurescript visualization layer to make use of the amazing 
visualization currently in the javascript world.

Perhaps these two things can effectively unify and become one via Light 
Table or Browser repl.


A last idea is the integration of Incanter analysis with Pallet 
(https://github.com/pallet/pallet , http://palletops.com/) to spawn compute 
servers as necessary (perhaps GPU, perhaps cascalog/hadoop, or vowpal 
wabbit / hadoop, etc.. )



Best regards,
Avram





On Tuesday, February 11, 2014 4:44:54 PM UTC-8, Mikera wrote:
>
> On the idea of a workbench / clojurescript integration, I always liked the 
> idea of a Light Table based analytical workbench that could connect to a 
> Clojure-based Incanter server (which might of course be running all the 
> heavy computations on a core.matrix GPU backend..)
>
> I don't know enough ClojureScript to be able to mentor such a project, but 
> happy to add it as an idea. should be feasible for a smart GSoC student 
>
> On Saturday, 8 February 2014 07:02:52 UTC+8, A wrote:
>>
>>
>> A couple ideas put forth:
>>
>> 1. Incanter charts with d3 (http://d3js.org/) ?  Perhaps facilitated by 
>> Dribnet's Strokes library (https://github.com/dribnet/strokes).
>>
>> 2. Finding ways to integrate Incanter and Clojurescript.
>>
>> Thoughts?
>>
>> -Avram
>>
>>
>>
>>
>> On Monday, February 3, 2014 11:59:24 AM UTC-8, Daniel Solano Gómez wrote:
>>>
>>> Hello, all, 
>>>
>>> Apparently, it's already time for organisations to apply for Google 
>>> Summer of Coder 2014 [1].   This is a great program, and there have been 
>>> several notable projects that have benefited as a result.  For example, 
>>> last year's successful projects included: 
>>>
>>> * Enhance Neko for Android, Alexander Yakushev 
>>> * core.typed: Extensions and Documentation, Ambrose Bonnaire-Sergeant 
>>> * Clojure Compiler port to Clojure (CinC), Bronsa 
>>> * Implementation of core.matrix-compatible multidimensional array in 
>>> Clojure, Dmitry Groshev 
>>> * Algebraic Expressions, Maik Schünemann 
>>> * ClojureScript optimization and source maps support, Michal Marczyk 
>>>
>>> I would love to see Clojure participate again this year.  In order to do 
>>> so, we need to start our application which is due in less than two weeks. 
>>>  We need volunteers to help prepare our application, and in particular it 
>>> would be great to have administrators that can help lead the process.  I am 
>>> certainly willing to help out, but if there is someone who wants to lead up 
>>> this effort, I would happy to assist. 
>>>
>>> Ideally, we could have multiple administrators to spread out the 
>>> following duties: 
>>>
>>> * Updating the community wiki for the year [2] 
>>> * Recruiting potential mentors 
>>> * Raising the profile of GSoC within the community 
>>>
>>> If we are accepted as a GSoC organisation, administrator duties include: 
>>>
>>> * Ensuring we meet the deadlines 
>>> * Arranging for travel to the mentor submit 
>>> * Arranging for students' travel to conferences 
>>> * If necessary, solve problems 
>>>
>>> I am afraid that last year I let the ball drop a bit with the mentor 
>>> summit and getting students to conferences.  With multiple administrators 
>>> to help spread the work around, I am sure we can make GSoC an even better 
>>> experience for everyone involved. 
>>>
>>> If you are interested in helping out in this effort, please set up a 
>>> profile on Melange [3] and e-mail me your profile name.   
>>>
>>> Thanks for your help. 
>>>
>>> Sincerely, 
>>>
>>> Daniel 
>>>
>>>
>>> [1]: 
>>> http://google-opensource.blogspot.com/2014/02/mentoring-organization-applications-now.html
>>>  
>>> [2]: http:/

Re: GSoC 2014: org applications now open

[A]

A couple ideas put forth:

1. Incanter charts with d3 (http://d3js.org/) ?  Perhaps facilitated by 
Dribnet's Strokes library (https://github.com/dribnet/strokes).

2. Finding ways to integrate Incanter and Clojurescript.

Thoughts?

-Avram




On Monday, February 3, 2014 11:59:24 AM UTC-8, Daniel Solano Gómez wrote:
>
> Hello, all, 
>
> Apparently, it's already time for organisations to apply for Google Summer 
> of Coder 2014 [1].   This is a great program, and there have been several 
> notable projects that have benefited as a result.  For example, last year's 
> successful projects included: 
>
> * Enhance Neko for Android, Alexander Yakushev 
> * core.typed: Extensions and Documentation, Ambrose Bonnaire-Sergeant 
> * Clojure Compiler port to Clojure (CinC), Bronsa 
> * Implementation of core.matrix-compatible multidimensional array in 
> Clojure, Dmitry Groshev 
> * Algebraic Expressions, Maik Schünemann 
> * ClojureScript optimization and source maps support, Michal Marczyk 
>
> I would love to see Clojure participate again this year.  In order to do 
> so, we need to start our application which is due in less than two weeks. 
>  We need volunteers to help prepare our application, and in particular it 
> would be great to have administrators that can help lead the process.  I am 
> certainly willing to help out, but if there is someone who wants to lead up 
> this effort, I would happy to assist. 
>
> Ideally, we could have multiple administrators to spread out the following 
> duties: 
>
> * Updating the community wiki for the year [2] 
> * Recruiting potential mentors 
> * Raising the profile of GSoC within the community 
>
> If we are accepted as a GSoC organisation, administrator duties include: 
>
> * Ensuring we meet the deadlines 
> * Arranging for travel to the mentor submit 
> * Arranging for students' travel to conferences 
> * If necessary, solve problems 
>
> I am afraid that last year I let the ball drop a bit with the mentor 
> summit and getting students to conferences.  With multiple administrators 
> to help spread the work around, I am sure we can make GSoC an even better 
> experience for everyone involved. 
>
> If you are interested in helping out in this effort, please set up a 
> profile on Melange [3] and e-mail me your profile name.   
>
> Thanks for your help. 
>
> Sincerely, 
>
> Daniel 
>
>
> [1]: 
> http://google-opensource.blogspot.com/2014/02/mentoring-organization-applications-now.html
>  
> [2]: http://dev.clojure.org/display/community/Google+Summer+of+Code+2013 
> [3]: http://en.flossmanuals.net/melange/ 
>

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

[A]

This is so awesome.  Thanks for writing this!  


Here's my naive stab at integration with (the :iris dataset available in) 
Incanter...

 (:require [incanter.core :as i]  
[incanter.datasets :as id]
[com.stuartsierra.frequencies :as freq])

(def d (id/get-dataset :iris)) 

   


(for [k [:Sepal.Length :Sepal.Width :Petal.Length :Petal.Width ] 
]   


  (-> d 


 

  
i/to-map

   

  
k   

   

  
frequencies 

   

  
freq/stats  

   

  (assoc :field k)   ;; label the stats with the field we 
used
   

  ))  


What do people think about Incanter these days?  Is it a forgotten 
step-child of clojure data science dreams or ready for a renaissance?


Cheers,
Avram



On Saturday, January 25, 2014 9:39:36 AM UTC-8, Stuart Sierra wrote:
>
> New Clojure library "frequencies"
>
> https://github.com/stuartsierra/frequencies
>
> Basic statistical computations (mean, median, etc.) on **frequency maps**, 
> e.g. the map returned by `clojure.core/frequencies`.
>
> A frequency map can represent (or approximate) a large distribution of 
> values in a small amount of memory.
>
> Log files, benchmarks, and load tests frequently produce data sets that 
> are too large to store entirely in memory. Frequency maps are a convenient 
> way to get a summary view of these data sets.
>
>
> Leiningen dependency:
>
> [com.stuartsierra/frequencies "0.1.0-SNAPSHOT"]
>
>
> Special thanks to Craig Andera for code review and Cognitect for 20% time.
>  

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

[a...@puredanger.com]

Please be aware that we expect to make changes to the API package and class 
name in the next alpha based on a discussion today so you may want to wait for 
RC for that!



On Nov 22, 2013, at 11:06 PM,  wrote:

> Thank you.
> 
> I’d like to take this opportunity to thank the Clojure/core team for the 
> slow, measured pace of development and stability of Clojure. 1.6 looks like a 
> safe, gentle upgrade from 1.5.1.
> 
> Ironically the biggest change for me in 1.6 is the new API stuff - I look 
> forward to rewriting my cfmljure library to leverage the new API once it goes 
> gold! 😊
> 
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org
> 
> From: Alex Miller
> Sent: ‎Friday‎, ‎November‎ ‎22‎, ‎2013 ‎7‎:‎26‎ ‎PM
> To: clojure@googlegroups.com
> 
> Clojure 1.6.0-alpha3 is now available. 
>  
> Try it via 
> - Download: http://central.maven.org/maven2/org/clojure/clojure/1.6.0-alpha3/
> - Leiningen: [org.clojure/clojure "1.6.0-alpha3"]
> 
> Clojure 1.6.0-alpha3 has the following changes from 1.6.0-alpha2:
> 
> 1) Reverted: CLJ-1125 (fix for permgen leak) based on the regression reported 
> in CLJ-1299. A fix for this regression is in development and I expect it to 
> be re-applied in a future alpha.
> - http://dev.clojure.org/jira/browse/CLJ-1125
> - http://dev.clojure.org/jira/browse/CLJ-1299
> 
> 2) The following features are no longer marked "Alpha" in Clojure (woohoo!):
> 
> * Watches - add-watch, remove-watch
> * Transients - transient, persistent!, conj!, assoc!, dissoc!, pop!, disj!
> * Exception data - ex-info, ex-data
> * Promises - promise, deliver
> * Records - defrecord
> * Types - deftype
> * Pretty-print tables - print-table
> 
> 3) Applied patches for:
> 
> * [CLJ-827](http://dev.clojure.org/jira/browse/CLJ-827) - New function: 
> clojure.core/unsigned-bit-shift-right
> * [CLJ-866](http://dev.clojure.org/jira/browse/CLJ-866) - New function: 
> clojure.test/test-vars
> * [CLJ-1102](http://dev.clojure.org/jira/browse/CLJ-1102) - Better handling 
> of exceptions with empty stack traces.
> * [CLJ-939](http://dev.clojure.org/jira/browse/CLJ-939) - Exceptions thrown 
> in the top level ns form are reported without file or line number.
> * [CLJ-858](http://dev.clojure.org/jira/browse/CLJ-858) - Improve speed of 
> STM by removing System.currentTimeMillis.
> * [CLJ-669](http://dev.clojure.org/jira/browse/CLJ-669) - 
> clojure.java.io/do-copy: use java.nio for Files
> * [CLJ-1105](http://dev.clojure.org/jira/browse/CLJ-1105) - clojure.walk now 
> supports records.
> * [CLJ-949](http://dev.clojure.org/jira/browse/CLJ-949) - Removed all 
> unnecessary cases of sneakyThrow.
> * [CLJ-1238](http://dev.clojure.org/jira/browse/CLJ-1238) - Allow EdnReader 
> to read foo// (matches LispReader behavior).
> * [CLJ-1264](http://dev.clojure.org/jira/browse/CLJ-1264) - Remove uses of _ 
> as a var in the Java code (causes warning in Java 8).
> * [CLJ-1222](http://dev.clojure.org/jira/browse/CLJ-1222) - Multiplication 
> overflow issues around Long/MIN_VALUE
> * [CLJ-1118](http://dev.clojure.org/jira/browse/CLJ-1118) - Inconsistent 
> numeric comparison semantics between BigDecimals and other numerics
> 
> 3) Full change log is updated as well:
> https://github.com/clojure/clojure/blob/master/changes.md
> 
> Still on the plate are 16 tickets (I expect many but not all of those to make 
> it in) and the hashing performance work 
> (http://dev.clojure.org/display/design/Better+hashing). Once we reach 
> "completion" we'll release an RC for final testing.
> 
> Alex Miller
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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+un

Re: Graph API

[A]

Thought I'd mention a really nice Graph visualization library that I like. 
It would be great to include this into any new Graph library project.

https://github.com/pallix/lacij

>From the readme:

"Lacij is a graph visualization library written in Clojure. It allows the 
*display 
and the dynamic modification of graphs as SVG documents* that can be viewed 
with a *Web browser* or with a *Swing component*. Undo/redo is supported 
for the dynamic modification. Automatic layout is provided for the 
visualization."

I like graphviz too, but this might be a better fit.

Cheers,
Avram


On Wednesday, June 19, 2013 5:57:02 AM UTC-7, Aysylu Biktimirova wrote:
>
> If you'd like to take a stab at integrating your proposed protocol into 
> Loom, I'd be happy to merge the changes. Thanks!
>
> On Tuesday, June 18, 2013 1:12:04 PM UTC-4, Stephen Kockentiedt wrote:
>>
>> That sounds great! I'll mail you my complete code in case you want to 
>> take a look at it or want to use parts of it. And in case I can help in any 
>> other way, feel free to ask.
>>
>> Am Dienstag, 18. Juni 2013 18:44:33 UTC+2 schrieb Aysylu Biktimirova:
>>>
>>> Stephen, thanks for reaching out to me! I really like your ideas and 
>>> agree with the issues you pointed out in Loom's API. I'd like to 
>>> incorporate your ideas into Loom to improve its API and have 1 graph 
>>> library in Clojure. I'm actively working on it and would be happy to 
>>> combine our efforts.
>>>
>>> There's one implementation of the API, as far as I know, 
>>> https://github.com/aysylu/loom/blob/titanium/src/loom/titanium.clj, which 
>>> integrates Loom with Titanium. I'm planning to refactor it out of Loom and 
>>> release as a separate project. Since I'm the author and the only maintainer 
>>> of Titanium+Loom, I'd be happy to handle the transition.
>>>
>>> On Tuesday, June 18, 2013 3:10:23 AM UTC-4, Stephen Kockentiedt wrote:
>>>>
>>>> My bad. I did only find the original repository of loom and thought it 
>>>> was abandoned. I should have taken more care while looking at it. My 
>>>> approach was apparently the same in abstracting multiple graph 
>>>> implementations under one API. However, I see some problems with Loom's 
>>>> API, namely:
>>>>
>>>> 1. The specifications of the protocol functions are very sparse. E.g., 
>>>> which nodes shall a directed graph return from neighbors? Successors, 
>>>> predecessors or both?
>>>> 2. How do I know if the graph implementation works by mutating the 
>>>> given object or returning a new one?
>>>> 3. Loom assumes that every graph is editable. That is definitely not 
>>>> the case.
>>>> 4. I think a protocol should be as easy to implement as possible. The 
>>>> additional functionality can be given by functions relying on the protocol 
>>>> functions. E.g., in the user API of my code, there is a function 
>>>> direct-predecessors which provides this functionality (albeit slow) 
>>>> for graph implementations which did not implement the corresponding 
>>>> protocol function:
>>>>
>>>> (defn direct-predecessors
>>>>   "Returns a set or sequence of all nodes n2 for which
>>>>(has-edge? g n2 n) returns true. May not contain
>>>>duplicates."
>>>>   [g n]
>>>>   (if (satisfies? p/PPredecessorGraph g)
>>>> (p/direct-predecessors g n)
>>>> (filter #(p/has-edge? g % n) (p/nodes g
>>>>
>>>> E.g., implementations of Loom's API need to provide two implementations 
>>>> of neighbors and need to implement add-nodes* instead of only add-node*. 
>>>> This may not be much more work to do. However, the easier the API, the 
>>>> more 
>>>> implementations there will be.
>>>>
>>>> Please, don't get me wrong. I think that Loom is a great project, has 
>>>> the same goals and, in terms of functionality, is way ahead of my efforts.
>>>>
>>>> Said all that, I definitely don't want there to be two competing graph 
>>>> APIs. That would be counterproductive. I see the following possible 
>>>> solutions:
>>>>
>>>> 1. I keep the code to myself and let loom be the sole graph API.
>>>> 2. We transfer the advantages of my proposal to Loom and change its 
>>>> API. Do you know of any implementations of the API outside Loom 

Re: Clojure in production

[Jose A. Ortega Ruiz]

Hi Plinio,

On Mon, Jun 10 2013, Plínio Balduino wrote:

> Hi there
>
> I'm writing a talk about Clojure in the real world and I would like to
> know, if possible, which companies are using Clojure for production or
> to make internal tools.

At BigML, our backend is written almost fully (99%) in Clojure.  We've
released a couple of libraries it uses as open source:

https://github.com/bigmlcom/histogram
https://github.com/bigmlcom/sampling
https://github.com/bigmlcom/io

Cheers,
jao
-- 
Where is the Life we have lost in living? Where is the wisdom we have
lost in knowledge? Where is the knowledge we have lost in information?
  -T.S. Eliot, poet (1888-1965)

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

[Karim A. Nassar]

When using nrepl in emacs (cdoc ) emits:

CompilerException java.lang.RuntimeException: Unable to resolve symbol:
cdoc in this context, compiling:(NO_SOURCE_PATH:1)

However, in "lein repl" I see:

Loading clojuredocs-client...

How do I make nrepl as smart as lein repl?



On Fri, Dec 14, 2012 at 10:08 PM, Andy Fingerhut
wrote:

> I would recommend checking out
>
> http://clojuredocs.org
>
> If you use Leiningen version 2, you can get similar output with these two
> commands:
>
> lein repl
> user=> (doc first)
> user=> (cdoc first)
>
> doc gives the "doc string" built into Clojure.  cdoc gives the examples
> from ClojureDocs.org for that symbol, as long as you have an Internet
> connection.
>
> Andy
>
> On Dec 14, 2012, at 3:40 PM, linc...@redhandgaming.net wrote:
>
> > I'm learning Clojure, and I learn best by jumping in. I'm interested in
> using Noir. Noir has a full API reference, so when I'm reading other
> people's Noir code, I can just look up the exact function and see what it
> does.
> >
> > I can't find a similar thing for Clojure. I'm looking through other
> people's Clojure code. I see something like (keyword (or (first m) :dev))
> and I don't really know where to start understanding this. I know enough to
> know that keyword, or, and first are all functions - and with a google
> search or two, I can figure out what 'first' does. But I can't easily find
> out what 'or' and 'keyword' do, because when I google those things, I get
> all kinds of screwy results, completely unrelated to what I'm trying to
> find out.
> >
> > Where can I find, or does there exist, a place where I can view all
> Clojure's built in functions with a short description of their arguments
> and what they do?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: on lisp and scheme macros

[Jose A. Ortega Ruiz]

Hi Tassilo,

On Tue, Dec 06 2011, Tassilo Horn wrote:

> "Jose A. Ortega Ruiz"  writes:
>
> Hi Jose,
>
>>> I think that Common Lisp macros are, strictly speaking, more powerful
>>> than Scheme macros, but I don't have a citation.
>>
>> That's only true for syntax-rules macros.  syntax-case macros, which
>> most schemes provide and are required by R6RS, are, strictly speaking,
>> more powerful than CL macros.
>
> I don't know scheme macros, so could you please explain why they are
> more powerful?  What can you do with a syntax-case macro what you cannot
> do with a Common Lisp (or Clojure) macro?

In general, syntax-case lets you manipulate first-class syntax objects,
whereby all kind of neat tricks are possible out of the box.  You gain
in expressivity.  This is a good overview:

  http://blog.racket-lang.org/2011/04/writing-syntax-case-macros.html

> Wikipedia lists syntax-case as hygienic macro system, which would make
> it less powerful than CL macros, because if that was true, you could not
> write anaphoric macros with it.

It's hygienic by default, but offers ways of breaking hygiene.  As a
matter of fact, it's possible to define defmacro using syntax-case (see, e.g.,
https://mercure.iro.umontreal.ca/pipermail/gambit-list/2007-March/001195.html),
and then you can use defmacro in Scheme too :)

It's also possible to implement hygiene on top of defmacro (with the
help of CLOS's symbol-macrolet:
http://www.p-cos.net/documents/hygiene.pdf), but it's much more
convoluted (and, IIRC, some of the syntax API is still missing in that
long paper).

Even if you don't buy the expressivity argument, i think we can agree
that syntax-case macros are, at least, as powerful as CL macros.

Cheers,
jao
--
Humans think they are smarter than dolphins because we build cars and
buildings and start wars etc., and all that dolphins do is swim in the
water, eat fish and play around. Dolphins believe that they are
smarter for exactly the same reasons. -Douglas Adams

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

Re: on lisp and scheme macros

[Jose A. Ortega Ruiz]

On Sat, Dec 03 2011, Stuart Sierra wrote:

> I think that Common Lisp macros are, strictly speaking, more powerful
> than Scheme macros, but I don't have a citation.

That's only true for syntax-rules macros.  syntax-case macros, which
most schemes provide and are required by R6RS, are, strictly speaking,
more powerful than CL macros.

jao
-- 
I went to the woods because I wished to live deliberately, to front only the
essential facts of life, and see if I could not learn what it had to teach,
and not, when I came to die, discover that I had not lived.
 -Henry David Thoreau, naturalist and author (1817-1862)

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

clojure-jack-in vs. slime-connect

[Jose A. Ortega Ruiz]

Hi,

I use (technomancy's) slime with clojure-mode (both elpa-installed)
without any issues (via lein swank and slime-connect). While the newish
clojure-jack-in works too, i prefer slime-connect (because i save the
time of re-evaluating the slime code everytime i restart the REPL).

So i was wondering: is the stand-alone slime package deprecated or
lagging respect to the one that gets loaded by clojure-jack-in? Or are
both kept in sync, so that i'm not missing any new functionality or
fixes by using the slime-connect way?

Thanks,
jao
-- 
The folly of mistaking a paradox for a discovery, a metaphor for a proof, a
torrent of verbiage for a spring of capital truths, and oneself for an
oracle, is inborn in us.
 -Paul Valery, poet and philosopher (1871-1945)

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

Re: cool compiler-project?

[Sreeraj a]

Hi,
I'm trying to develop a clojure compiler for LLVM.

may need a small nudge in the right direction.
anyone who can mentor me on this project?

Thanks
Sreeraj.

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

Re: Clojure 1.3: Integrating clj-stacktrace?

[Sreeraj a]

+1
need to improve the present stacktrace, and error messages if clojure is to
attract more noobs.

On Wed, Aug 25, 2010 at 6:16 PM, Alan  wrote:

> I have the same problem, but you can usually figure that out by
> looking at the function to which the backtrace refers, as well as the
> filename:
>
>  4: clojure.lang.RT.nth(RT.java:722)
>  5: ddsolve.core$play_deal_strategically.invoke(core.clj:177)
>  6: ddsolve.core$eval2129.invoke(NO_SOURCE_FILE:1)
>  7: clojure.lang.Compiler.eval(Compiler.java:5424)
>
> Here I can tell that the problem was in ddsolve.core, not some other
> core.clj, from looking at line 5.
>
> On Aug 25, 7:06 am, David Jagoe  wrote:
> > Ahoy,
> >
> > On 25 August 2010 15:46, Stuart Halloway 
> wrote:
> >
> >
> >
> > > *Specific* documentation of pain points also welcome.
> >
> > In general I haven't found the stack traces to be too much of a
> > problem, but the lack of full paths in the trace has bitten me. Since
> > all of my namespaces have a core.clj this can mean a bit of detective
> > work to find which core.clj is being reported.
> >
> > Cheers,
> > David
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: cool compiler-project?

[Sreeraj a]

What about automatic memoization?
Does clojure already implement memoization?
is adding auto memoization to the compiler a good idea?

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

cool compiler-project?

[Sreeraj a]

Hi,
I am a post-grad student looking for a cool compiler - project to do.
I am getting comfortable with clojure and would really like to help

Ideas anyone?
or, Is there a to-do list where can i start?


Cheers
Sreeraj

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

Re: Cannot sen msg to #clojure channel

[Ernesto A.]

You might want to check the FAQ at freenode.net. They even give you hints
for setting up your client so that you don't have to manually register every
time you log in.

On Tue, Aug 10, 2010 at 10:44 AM, Laurent PETIT wrote:

> You need to register with NickServ, e.g.
> /msg NickServ identify 
>
> It's a protection so that nobody else uses limux1972 when you're not
> online.
>
> (you also need to register limux1972, but I don't remember how)
>
> 2010/8/10 limux 
>
> Why? My nickname in #clojure is limux1972.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: Installing Clojure in Emacs

[Jose A. Ortega Ruiz]

Allan Moore  writes:

> Hi. I am trying to install Clojure in Emacs under Windows using the
> Assembla Wiki instructions.  I am on the step where it says to type:
>
> M-x describe-variable inferior-lisp-program
>
> When I hit return in the command buffer I get the response in the
> buffer: "[no match]".

Sorry if i'm saying the obvious, but are you hitting RET after
'M-x describe-variable'? Another way to run that command is 'C-h v'
(after which you'll be prompted by the name of the variable to
describe).

hth,
jao
-- 
One reason that life is complex is that it has a real part and an
imaginary part.
 -Andrew Koenig

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

Re: Erlang like environment

[Jose A. Ortega Ruiz]

gary ng  writes:

> Hi,
>
> I just start to learn about clojure and is wondering if there is any
> erlang like environment for clojure ?

I don't know whether such an environment already exists, but, if not,
one could hack one based on Kilim
(http://www.malhar.net/sriram/kilim/)... klijim anyone? :)

hth,
jao

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

To unsubscribe, reply using "remove me" as the subject.

Re: Simple functional programming lexicon?

[Michael A Wright]

You might want to check out:

> http://peepcode.com/products/functional-programming-with-clojure



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

To unsubscribe from this group, send email to 
clojure+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: JTable howto

[what-a-guy]

Thanks for the help!  The code comes from the Java tutorials at

  
http://java.sun.com/docs/books/tutorial/uiswing/components/table.html#headertooltip

which compiles and runs as advertised on my system.

Here's an attempt to use it in clojure, which does display the table
correctly, but the prn inside 'createDefaultTableHeader' never gets
called.

How can I debug this?

-

(import '(javax.swing JTable JFrame JPanel SwingUtilities JScrollPane)
'(javax.swing.table AbstractTableModel JTableHeader)
'(java.awt BorderLayout))

(defn my-table
  "cols is a seq of form ((\"Name\" String) (\"Married?\" Boolean)...)
row-count-proc is a 0-ary proc which returns the number of data rows.
get-value-at-proc is 2-ary proc (row col) which returns value.
set-value-at-proc (optional) is a 3-ary proc (val row col) which sets
value.
 if nil, table is not editable.

Returns a content pane."
  [cols row-count-proc get-value-at-proc & set-value-at-proc]
  (let [col-names (map first cols)
col-classes (map second cols)
model (proxy [AbstractTableModel] []
(getColumnCount [] (count cols))
(getRowCount [] (row-count-proc))
(isCellEditable [row col] set-value-at-proc)
(getColumnName [col] (nth col-names col))
(getValueAt [row col] (get-value-at-proc row col))
(setValueAt [val row col] (set-value-at-proc val row col))
(getColumnClass [col] (nth col-classes col)))
tbl   (proxy [JTable] [model]
(createDefaultTableHeader
 []
 (let [column-model (proxy-super getColumnModel)]
   (prn 'createDefaultTableHeader)
   (proxy [JTableHeader] [column-model]
 (getToolTipText
  [evt]
  (let [p  (.getPoint evt)
index  (.getColumnIndexAtX column-model (.x p))
real-index (-> column-model
   (.getColumn index)
   .getModelIndex)]
(nth col-names real-index)))
pn (JPanel.)]
(.setLayout pn (BorderLayout.))
(.add pn (.getTableHeader tbl) BorderLayout/PAGE_START)
(.add pn (JScrollPane. tbl))
(.setOpaque pn true)
pn))

(SwingUtilities/invokeLater
 (proxy [Runnable] []
   (run []
(let [frame (JFrame. "Demo")
  tbl (my-table [["A" String] ["B?" Boolean]]
(fn [] 5) ; row-count-proc
(fn [r c] (if (= c 0) "OK" true)))] ; 
get-value-at-proc
  (doto frame
(.setContentPane tbl)
.pack
    .show)

On Feb 11, 4:33 pm, Meikel Brandmeyer  wrote:
> Hi,
>
> Am 11.02.2009 um 23:08 schrieb what-a-guy:
>
>
>
> > How would I code the following in clojure?
>
> > JTable table = new JTable(new MyTableModel()) {
> >    ...
>
> >    //Implement table header tool tips.
> >    protected JTableHeader createDefaultTableHeader() {
> >        return new JTableHeader(columnModel) {
> >            public String getToolTipText(MouseEvent e) {
> >                String tip = null;
> >                java.awt.Point p = e.getPoint();
> >                int index = columnModel.getColumnIndexAtX(p.x);
> >                int realIndex =
> >                        columnModel.getColumn(index).getModelIndex();
> >                return columnToolTips[realIndex];
> >            }
> >        };
> >    }
> > };
>
> I'm not sure about the Java notation. So this may
> be completely wrong. I'm also assuming, that
> column-model and such things are defined somewhere
> around this snippet.
>
> (proxy [JTable] [(MyTableModel.)]
>    (createDefaultTableHeader
>      []
>      (proxy [JTableHeader] [column-model]
>        (getToolTipText
>          [evt]
>          (let [p          (.getPoint evt)
>                index      (.getColumnIndexAtX column-model (.x p))
>                real-index (-> columnModel
>                             (.getColumn index)
>                             .getModelIndex)]
>            (nth column-tool-tips real-index))
>
> Sincerely
> Meikel
>
>  smime.p7s
> 5KViewDownload
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

JTable howto

[what-a-guy]

How would I code the following in clojure?

JTable table = new JTable(new MyTableModel()) {
...

//Implement table header tool tips.
protected JTableHeader createDefaultTableHeader() {
return new JTableHeader(columnModel) {
public String getToolTipText(MouseEvent e) {
String tip = null;
java.awt.Point p = e.getPoint();
int index = columnModel.getColumnIndexAtX(p.x);
int realIndex =
columnModel.getColumn(index).getModelIndex();
return columnToolTips[realIndex];
}
};
}
};
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

variable scope in an event handler

[what-a-guy]

Here's some code that works as I expected:

dyn.clj

(println *value*)

test.clj

(def *value* 'ok)
(defn test-eval []
  (load-file "dyn.clj"))
(test-eval)

=> 'ok

But when run in an event handler it fails:

test.clj

(import '(javax.swing JButton JFrame)
'(java.awt.event ActionListener))

(def *value* 'ok)
(defn test-eval []
  (load-file "dyn.clj"))

(let [frame (JFrame.)
  button (JButton. "Click Me")]

  ;; this gets exception "Unable to resolve symbol: *value*
  (.addActionListener
   button
   (proxy [ActionListener] [] (actionPerformed [evt] (test-eval

  (doto frame
(.add button)
(.pack)
(.show)))

What's happening in the ActionListener code?

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

macro help

[what-a-guy]

I'm attempting what should be a simple transformation using a macro
called dlg in the following code:
(defn fld [parent lay id text field]
  '...)

;; dlg macro.  For this input:
;;
;; (dlg "test"
;;  (field fld-1 "Field number one" (JTextField.))
;;  (field fld-2 "Field number two" (JTextField.)))
;;
;; we want this output:
;;
;; (fn [parent layout]
;;   (fld parent layout 'fld-1 "Field number one" (JTextField.))
;;   (fld parent layout 'fld-2 "Field number two" (JTextField.))
;;   parent)

(defmacro dlg [dlgid# & fields#]
  `(fn  [parent# layout#]
 ~@(map
(fn [[f# id# text# type#]]
  `(fld parent# layout# '~id# ~text# ~type#))
fields#)))

(def inp '(dlg "test"
   (field fld-1 "Field number one" (JTextField.))
   (field fld-2 "Field number two" (JTextField.

(macroexpand inp)

;; =>
;; (fn* ([parent__6 layout__7]
;;  (user/fld parent__4 layout__5 (quote fld-1) "Field number
one" (JTextField.))
;;  (user/fld parent__4 layout__5 (quote fld-2) "Field number
two" (JTextField.

(eval inp)

;; =>
;; java.lang.Exception: Unable to resolve symbol: parent__4 in this
context (NO_SOURCE_FILE:24)

I'm wondering why the macro produces 2 different "parent" symbols--I'd
like both references to be the same parent.  Any suggestions?

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

macro help

[what-a-guy]

I'm attempting what should be a simple macro transformation (dlg
below):

(defn fld [parent lay id text field]
  '...)

;; dlg macro.  For this input:
;;
;; (dlg "test"
;;  (field fld-1 "Field number one" (JTextField.))
;;  (field fld-2 "Field number two" (JTextField.)))
;;
;; we want this output:
;;
;; (fn [parent layout]
;;   (fld parent layout 'fld-1 "Field number one" (JTextField.))
;;   (fld parent layout 'fld-2 "Field number two" (JTextField.))
;;   parent)

(defmacro dlg [dlgid# & fields#]
  `(fn  [parent# layout#]
 ~@(map
(fn [[f# id# text# type#]]
  `(fld parent# layout# '~id# ~text# ~type#))
fields#)))

(def inp '(dlg "test"
   (field fld-1 "Field number one" (JTextField.))
   (field fld-2 "Field number two" (JTextField.

(macroexpand inp)

;; =>
;; (fn* ([parent__6 layout__7]
;;  (user/fld parent__4 layout__5 (quote fld-1) "Field number
one" (JTextField.))
;;  (user/fld parent__4 layout__5 (quote fld-2) "Field number
two" (JTextField.

(eval inp)

;; =>
;; java.lang.Exception: Unable to resolve symbol: parent__4 in this
context (NO_SOURCE_FILE:24)

The dlg macro seems to be generating 2 different symbols for 'parent,
when I'd like both to refer to the
same symbol.  Any suggestions?

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

macro help

[what-a-guy]

I'm getting stuck on what should be a simple macro (dlg below).  It
produces 2 different symbols (for 'parent#) when I was expecting both
to refer to the same symbol.  Here's the code:

(defn fld [parent lay id text field]
  '...)

;; dlg macro.  For this input:
;;
;; (dlg "test"
;;  (field fld-1 "Field number one" (JTextField.))
;;  (field fld-2 "Field number two" (JTextField.)))
;;
;; we want this output:
;;
;; (fn [parent layout]
;;   (fld parent layout 'fld-1 "Field number one" (JTextField.))
;;   (fld parent layout 'fld-2 "Field number two" (JTextField.))
;;   parent)

(defmacro dlg [dlgid# & fields#]
  `(fn  [parent# layout#]
 ~@(map
(fn [[f# id# text# type#]]
  `(fld parent# layout# '~id# ~text# ~type#))
fields#)))

(def inp '(dlg "test"
   (field fld-1 "Field number one" (JTextField.))
   (field fld-2 "Field number two" (JTextField.

(macroexpand inp)

;; =>
;; (fn* ([parent__6 layout__7]
;;  (user/fld parent__4 layout__5 (quote fld-1) "Field number
one" (JTextField.))
;;  (user/fld parent__4 layout__5 (quote fld-2) "Field number
two" (JTextField.

(eval inp)

;; =>
;; java.lang.Exception: Unable to resolve symbol: parent__4 in this
context (NO_SOURCE_FILE:24)

Any suggestions?

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

macro help

[what-a-guy]

I'm attempting what should be a simple transformation using a macro
called dlg in the following code:
(defn fld [parent lay id text field]
  '...)

;; dlg macro.  For this input:
;;
;; (dlg "test"
;;  (field fld-1 "Field number one" (JTextField.))
;;  (field fld-2 "Field number two" (JTextField.)))
;;
;; we want this output:
;;
;; (fn [parent layout]
;;   (fld parent layout 'fld-1 "Field number one" (JTextField.))
;;   (fld parent layout 'fld-2 "Field number two" (JTextField.))
;;   parent)

(defmacro dlg [dlgid# & fields#]
  `(fn  [parent# layout#]
 ~@(map
(fn [[f# id# text# type#]]
  `(fld parent# layout# '~id# ~text# ~type#))
fields#)))

(def inp '(dlg "test"
   (field fld-1 "Field number one" (JTextField.))
   (field fld-2 "Field number two" (JTextField.

(macroexpand inp)

;; =>
;; (fn* ([parent__6 layout__7]
;;  (user/fld parent__4 layout__5 (quote fld-1) "Field number
one" (JTextField.))
;;  (user/fld parent__4 layout__5 (quote fld-2) "Field number
two" (JTextField.

(eval inp)

;; =>
;; java.lang.Exception: Unable to resolve symbol: parent__4 in this
context (NO_SOURCE_FILE:24)

I'm wondering why the macro produces 2 different "parent" symbols--I'd
like both references to be the same parent.  Any suggestions?

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

Re: Concerned about Clojure's license choice.

[a r]

On Sat, Nov 1, 2008 at 5:33 PM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> Hello.  I am an open source programmer and fan of Clojure!
> I wanted to express my concern about your wonderful language project
> in the
> hopes it may help it succeed even more.

CPL is very liberal and I am pretty happy with this choice. This is
not our decision after all - it's the author who decides what people
can do with _his_ code.

Still, for me a dual CPL/LGPL license would be nicer. This is purely
for practical reasons - Java itself going GPL, reusing (those few) GPL
Java libraries or embedding Clojure compiler in GPL applications (this
might be OK with CPL, I'm not sure).

> You may find this article informative
>
> http://www.dwheeler.com/essays/gpl-compatible.html

Personally I think this article is rather offensive - GPL
incompatibility is (or should be) a problem for people releasing
software under GPL, not others.

-r.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: playing with metadata

[Jose A. Ortega Ruiz]

Hi Stuart and Rich,

Stuart Halloway <[EMAIL PROTECTED]> writes:

> Hi Jose,
>
> The key determinant of metadata in Clojure is whether the data is  
> orthogonal to equality. Would two tasks with identical behavior but  
> different staleness predicates be equal? I would say no, hence a  
> staleness predicate would be data, not metadata.
>

Only if you consider the staleness predicate as metadata attached to the
build procedure. In my proposal, all behaviour would be metadata, and
staleness predicates would be part of that behaviour.

I was thinking of a task as a set of generic functions (staleness,
build...) acting on data with the right structure. The whole bunch of
functions (stored in a map, actually as Rich suggests) would become
metadata attached to the data. Something like an alternative to
multimethods, if you will. That way, the actual data can be viewed as an
entity in and by itself, usable in other contexts.

One could also think of it as cheap prototypes (in the Self vein) where
method slots are stored as metadata [1]. It could be argued, though,
that two objects with different methods should be considered different,
and metadata would then be a bad implementation choice. But then again,
comparing behaviour (as represented by procedures) is always a pesky
business.

Thanks to both for chiming in!

Cheers,
jao

Footnotes:

[1] Actually, another fun project would be a port of something like
Prometheus (http://www.forcix.cx/software/prometheus/prometheus.html) to
Clojure [2], perhaps using such a mechanism.

[2] BTW, what's the accepted spelling: Clojure or clojure?



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

playing with metadata

[Jose A. Ortega Ruiz]

Hi,

In order to learn and experiment with clojure, i'm implementing a (for
now, toy) build system. The idea is to replace makefiles or ant build
files or your-favourite-make-replacement files by specifications written
in a clojure-based embedded DSL (same thing as, for example, Rake or
Scons).

A central concept in such a system is, of course, a task, which has
associated some unsurprising bits of data: a build procedure,
dependencies, a staleness predicate... In other languages (i've coded
some prototypes in Scheme and Common Lisp in the past) you would
typically define some sort of structured type to hold this data (for
instance, i was using CLOS in CL). But i was thinking that, in clojure,
it could make sense to put this information in (possibly tagged)
metadata, so that any clojure object can behave as a task.

My gut feeling is that such design would buy me some flexibility,
avoiding the usual type system straitjacket; and, anyway, it seems kinda
fun. But clojure is the first language i use providing metadata, and i
lack the experience to know whether i'm on sound ground here.

So, my question: do you think that this would be a good, idiomatic use
of metadata? Is there any code or conceptual discussion on metadata and
its uses?

Thanks,
jao
-- 
Always have a vision. Why spend your life making other people’s dreams?
 -Orson Welles (1915-1985)


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---