{ANN} defun: A beautiful macro to define clojure functions with pattern match.

2014-09-13 Thread dennis zhuang
Hi , i am pleased to introduce defun :
a beautiful macro to define clojure functions with pattern match.

Some examples:


(defun say-hi

  ([:dennis] "Hi,good morning, dennis.")

  ([:catty] "Hi, catty, what time is it?")

  ([:green] "Hi,green, what a good day!")

  ([other] (str "Say hi to " other)))


(say-hi :dennis)

;;  "Hi,good morning, dennis."

(say-hi :catty)

;;  "Hi, catty, what time is it?"

(say-hi :green)

;;  "Hi,green, what a good day!"

(say-hi "someone")

;;  "Say hi to someone"


Recursive function? It's all right:

(defun count-down

  ([0] (println "Reach zero!"))

  ([n] (println n)

 (recur (dec n

(defun fib

([0] 0)

([1] 1)

([n] (+ (fib (- n 1)) (fib (- n 2)



Guard functions? it's all right:

(defun valid-geopoint?

([(_ :guard #(and (> % -180) (< % 180)))

  (_ :guard #(and (> % -90) (< % 90)))] true)

([_ _] false))


(valid-geopoint? 30 30)

;; true

(valid-geopoint? -181 30)

;; false


It's really cool,all the magic are from core.match, much more details
please see
https://github.com/killme2008/defun


-- 
庄晓丹
Email:killme2...@gmail.com xzhu...@avos.com
Site:   http://fnil.net
Twitter:  @killme2008

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

2014-09-13 Thread cees van Kemenade
Thanks  Stu & Lee,

I will be more careful next time I order a cocktail in a bar.

I wasn't aware that pr-str depended on *out*, as it could be implemented as 
a pure function, without this harmful mixing effect. I guess pr-str is used 
to get something in edn-shape without (yet) going to the none-pure 
real-world. But I expect the current implementation is (via with-out-str) 
is the fastest and the most compact implementation.

Lee, thanks for your suggestions on how to tackle the dreadful HeisenBugs.

Regards,
Cees.

On Saturday, September 13, 2014 4:01:53 PM UTC+2, Lee wrote:
>
>
> A man walks into a bar and says "I used lazy evaluation and things were 
> confusing." Bartender says "You might have mixed it with I/O, but then 
> again maybe you're getting tripped up by other some other 
> not-purely-functional aspect of your program or the JVM, like GC or thread 
> transitions."   
>
> Okay, it's not as good a joke that way, but it may be more accurate. 
>
> While the OP's issue was IO-related, I've run into confusing 
> laziness-related bugs, some of which were indeed Heisenbugs, that didn't 
> have anything obvious to do with IO. I think some were related to GC not 
> knowing that it could collect something, while others had to do with 
> something lazy being realized in a different thread than I expected. For 
> some, I've never really figured out what was happening, but I've 
> nonetheless found that the problem went away when I switched map to mapv, 
> or filter to filterv, etc. 
>
> So now one of my first steps when I'm faced with a confusing bug is to 
> stamp out all of the laziness except where I'm really doing things lazily 
> on purpose, for a good reason. I've also come to think that the 
> pervasiveness and defaultness of laziness in Clojure may not really be so 
> wonderful after all. Laziness is beautiful when you want it, and when you 
> do want it it's beautiful that so much of Clojure works with it so 
> effortlessly and transparently, but it can also produce subtle problems 
> when things aren't purely functional (which is a lot of the time, in my 
> experience, sometimes for subtle reasons). 
>
>  -Lee 
>
>
> On Sep 13, 2014, at 9:32 AM, Stuart Halloway  > wrote: 
>
> > A man walks into a bar and says "I used lazy evaluation and things were 
> confusing." Bartender says "You mixed it with I/O" without bothering to 
> look at the code.  :-) 
> > 
> > Your experiment uses pr-str, which uses a dynamically scoped resource 
> *out* in order to create its result.  Your observation uses println, which 
> uses the same dynamically scoped resource.  Mix in different evaluation 
> strategies, and races can lead to different outcomes. Here is a much 
> smaller example: 
> > 
> > (pr-str [1 2]) 
> > (pr-str (map #(doto % println) [1 2])) 
> > 
> > So this result is expected.  Beware I/O, and in the presence of I/O be 
> very careful in concluding that something is a value.  Your quoted-pr-str 
> is not a pure function, and so it does not make values. 
> > 
> > Regards, 
> > Stu 
> >   
>
>

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


Designing API for a Markov Model

2014-09-13 Thread RJ Nowling
Hi all,

I'm new to Clojure and implementing a Markov Model as part of a larger 
project.  I'd like some advice on the API for a progress-state function.

I see two possible options.  In the first option, we always ask the user to 
provide and keep track of the MSM state themselves:

(progress-state markov-model previous-state) -> new-state

In the second approach, we create a record that combines a model and a 
current state:

(defrecord MarkovProcess [model current-state])

(progress-state markov-process) -> updated-markov-process, new-state

Which of these approaches is more idiomatic for Clojure?  Are multiple 
return types an accepted practice in Clojure?  Is there a third, better way?

Thanks in advance!

RJ

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

2014-09-13 Thread Wilker
I forgot to post before, here is the actual error:

BindException Address already in use  sun.nio.ch.Net.bind0 (Net.java:-2)

Also, adding a (Thread/sleep 1000) seems to increase the success rate, but
would be nice to be able to really wait on Jetty to shutdown instead of
using arbitrary sleep.

Thanks.

---
Wilker Lúcio
http://about.me/wilkerlucio/bio
Woboinc Consultant
+55 81 82556600

On Sat, Sep 13, 2014 at 8:20 PM, Wilker  wrote:

> Hi,
>
> I'm trying to apply the ideas from the component library:
> https://github.com/stuartsierra/component
>
> My problems is being about stop/start the Jetty server, for that purpose I
> created this component:
>
>   (defrecord WebServer [app port join? jetty log]
> component/Lifecycle
> (start [c]
>   (log "Starting jetty server...")
>   (let [jetty (jetty/run-jetty (:handler app) {:port port :join?
> join?})]
> (log "Server started at port" port)
> (assoc c :jetty jetty)))
>
> (stop [c]
>   (when (:jetty c)
> (log "Stopping jetty...")
> (.stop (:jetty c))
> (log "Server stopped."))
>
>   (assoc c :jetty nil)))
>
>   (defn webserver-component
> ([port] (webserver-component port true))
> ([port join?]
>  (map->WebServer {:port port :join? join?})))
>
> It works, sometimes, but often I get this when I try to reset:
>
>   Error starting # component :server in system com.stuartsierra.component.SystemMap calling
> #'com.stuartsierra.component/start {:reason
> :com.stuartsierra.component/component-function-threw-exception, :function
> #'com.stuartsierra.component/start, :system-key :server, :component
> #cadegp.components.web_server.WebServer{:app
> #cadegp.components.web_app.CadegpApp{:conn
> #cadegp.components.database.Database{:uri
> datomic:free://localhost:4334/cadegp, :connection # cadegp-48d87324-7849-4255-b798-865b02ee9d9d, :index-rev 0, :basis-t 1176,
> :next-t 1177, :unsent-updates-queue 0, :pending-txes 0}>}, :handler
> # ring.middleware.reload$wrap_reload$fn__1728@6608b223>, :handler-ext
> #}, :port 8000,
> :join? false, :jetty nil, :log #},
> :system #}>
>
> Seems that it tries to start the server before it have time to shut it
> down.
>
> Any of you had a similar issue or know how to work around that?
>
> Thanks.
>
> ---
> Wilker Lúcio
> http://about.me/wilkerlucio/bio
> Woboinc Consultant
> +55 81 82556600
>

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


jetty restart failing

2014-09-13 Thread Wilker
Hi,

I'm trying to apply the ideas from the component library:
https://github.com/stuartsierra/component

My problems is being about stop/start the Jetty server, for that purpose I
created this component:

  (defrecord WebServer [app port join? jetty log]
component/Lifecycle
(start [c]
  (log "Starting jetty server...")
  (let [jetty (jetty/run-jetty (:handler app) {:port port :join?
join?})]
(log "Server started at port" port)
(assoc c :jetty jetty)))

(stop [c]
  (when (:jetty c)
(log "Stopping jetty...")
(.stop (:jetty c))
(log "Server stopped."))

  (assoc c :jetty nil)))

  (defn webserver-component
([port] (webserver-component port true))
([port join?]
 (map->WebServer {:port port :join? join?})))

It works, sometimes, but often I get this when I try to reset:

  Error starting #}, :handler
#, :handler-ext
#}, :port 8000,
:join? false, :jetty nil, :log #},
:system #}>

Seems that it tries to start the server before it have time to shut it down.

Any of you had a similar issue or know how to work around that?

Thanks.

---
Wilker Lúcio
http://about.me/wilkerlucio/bio
Woboinc Consultant
+55 81 82556600

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

2014-09-13 Thread Lee Spector

A man walks into a bar and says "I used lazy evaluation and things were 
confusing." Bartender says "You might have mixed it with I/O, but then again 
maybe you're getting tripped up by other some other not-purely-functional 
aspect of your program or the JVM, like GC or thread transitions."  

Okay, it's not as good a joke that way, but it may be more accurate.

While the OP's issue was IO-related, I've run into confusing laziness-related 
bugs, some of which were indeed Heisenbugs, that didn't have anything obvious 
to do with IO. I think some were related to GC not knowing that it could 
collect something, while others had to do with something lazy being realized in 
a different thread than I expected. For some, I've never really figured out 
what was happening, but I've nonetheless found that the problem went away when 
I switched map to mapv, or filter to filterv, etc. 

So now one of my first steps when I'm faced with a confusing bug is to stamp 
out all of the laziness except where I'm really doing things lazily on purpose, 
for a good reason. I've also come to think that the pervasiveness and 
defaultness of laziness in Clojure may not really be so wonderful after all. 
Laziness is beautiful when you want it, and when you do want it it's beautiful 
that so much of Clojure works with it so effortlessly and transparently, but it 
can also produce subtle problems when things aren't purely functional (which is 
a lot of the time, in my experience, sometimes for subtle reasons).

 -Lee


On Sep 13, 2014, at 9:32 AM, Stuart Halloway  wrote:

> A man walks into a bar and says "I used lazy evaluation and things were 
> confusing." Bartender says "You mixed it with I/O" without bothering to look 
> at the code.  :-)
> 
> Your experiment uses pr-str, which uses a dynamically scoped resource *out* 
> in order to create its result.  Your observation uses println, which uses the 
> same dynamically scoped resource.  Mix in different evaluation strategies, 
> and races can lead to different outcomes. Here is a much smaller example:
> 
> (pr-str [1 2])
> (pr-str (map #(doto % println) [1 2]))
> 
> So this result is expected.  Beware I/O, and in the presence of I/O be very 
> careful in concluding that something is a value.  Your quoted-pr-str is not a 
> pure function, and so it does not make values.
> 
> Regards,
> Stu
>  

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

2014-09-13 Thread Stuart Halloway
A man walks into a bar and says "I used lazy evaluation and things were
confusing." Bartender says "You mixed it with I/O" without bothering to
look at the code.  :-)

Your experiment uses pr-str, which uses a dynamically scoped resource *out*
in order to create its result.  Your observation uses println, which uses
the same dynamically scoped resource.  Mix in different evaluation
strategies, and races can lead to different outcomes. Here is a much
smaller example:

(pr-str [1 2])
(pr-str (map #(doto % println) [1 2]))

So this result is expected.  Beware I/O, and in the presence of I/O be very
careful in concluding that something is a value.  Your quoted-pr-str is not
a pure function, and so it does not make values.

Regards,
Stu


On Sat, Sep 13, 2014 at 4:41 AM, cees van Kemenade <
cees.van.kemen...@gmail.com> wrote:

>
> By watching (println) the experiment we influence the outcome.
> Is the Schrodinger's cat present in Clojure?
>
> This example program that shows how printing a value can change the value
> under
> specific circumstances. It seems the case that it has to do with the lazy
> evaluation
> that happen in Clojure. Basically I map a pr-str over a list. When I print
> the list
> before realization it seems that println is modifies the value.
> Doing a doall or turning the lazy-list into a vector makes the circumvents
> the issue.
>
> The code showing this behavior is is attached. Loading the file will show
> the issue.
> I've tested it in Clojure 1.5.1, Clojure 1.6.0.
> I also tested it in Clojure-clr 1.5.0, and observed the same issue.
>
> Please let me know whether this is expected behavior, a known issue, or a
> new one.
>
> Cees.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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


Schrodinger's cat in clojure?

2014-09-13 Thread cees van Kemenade

By watching (println) the experiment we influence the outcome.
Is the Schrodinger's cat present in Clojure?

This example program that shows how printing a value can change the value 
under
specific circumstances. It seems the case that it has to do with the lazy 
evaluation
that happen in Clojure. Basically I map a pr-str over a list. When I print 
the list
before realization it seems that println is modifies the value.
Doing a doall or turning the lazy-list into a vector makes the circumvents 
the issue.

The code showing this behavior is is attached. Loading the file will show 
the issue.
I've tested it in Clojure 1.5.1, Clojure 1.6.0.
I also tested it in Clojure-clr 1.5.0, and observed the same issue.

Please let me know whether this is expected behavior, a known issue, or a 
new one.

Cees. 

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


issue.clj
Description: Binary data


Re: Is Transit / core.async suitable for remote function invocation?

2014-09-13 Thread Matthias Nehlsen
Sente works really well, I am using it in the Clojure rewrite of an 
application and I am using it to call functions on the server from the 
client by putting messages on core.async channels. I am even using it to 
get around the current limitation on the ClojureScript side that there's no 
*pprint* implementation (yet). Instead, I send my data structure for visual 
inspection to the server during the development process and have that 
pretty print to the console. Sounds like a hack but works really well. 
Here's the source code of that project: github.com/matthias/BirdWatch

However, *@Mikera* I don't really think you want synchronous function 
invocation. You send messages and then move on and at some point, a result 
comes back. Why would you want to wait for anything to finish when you do 
not have the wire under control? *@Shaun* I don't think a client can ever 
be trusted enough to allow it to send arbitrary code for evaluation to the 
server. The idea alone makes me cringe, just like eval() in JavaScript does.

Cheers, Matthias

On Thursday, September 11, 2014 3:06:26 PM UTC+2, Shaun Robinson wrote:
>
> Check out Sente. It meets all your requirements. EDN is used as a 
> transport mechanism, with experimental support for Transit -- but these are 
> really implementation details. Values sent from the client shows up in tact 
> on the server, and vice versa. 
>
> https://github.com/ptaoussanis/sente
>
> * Sente provides a send function and a core.async channel on both the 
> Clojure and Clojurescript sides. 
> * Any value sent via the client's send function shows up on the server's 
> channel intact, and vice versa
> * The server keeps an atom of connected clients, and a message from the 
> server can target one or all of them
> * The excellent core.match is commonly used for pattern matching messages 
> on the client and server sides and dispatching functions
> * There is robust support for re-connecting
> * The software is mature, and terse (~1000 lines). I've used it as a comms 
> layer in several production apps with great success.
> * Regarding remote function serialization / invocation, assuming you trust 
> your client, you could pass a function from client->server as data, and 
> invoke it on the server side. No need for serialization, normal 'quoting' 
> would work.
>
> - Shaun
>
> On Wednesday, September 10, 2014 1:39:24 AM UTC-4, Mikera wrote:
>>
>> I've encountered a couple of use cases where it would helpful to have 
>> some form of remote function invocation in Clojure/ClojureScript with the 
>> following characteristics:
>> - Arbitrary functions can be effectively "serialised" and sent to remote 
>> machines
>> - Remote functions can be invoked either synchronously or asynchronously 
>> - Parameters get passed as serialised values, which might in turn be 
>> other functions
>> - Works across Clojure/ClojureScript boundary
>> - Would need to allow for various error conditions (network failure etc.)
>>
>> Could this be achieved in a reasonably sane way with some combination of 
>> Transit and/or core.async? Has anyone tried this?
>>
>

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


Re: (Request) Rich Hickey's EuroClojure 2014 slides

2014-09-13 Thread Andy L
Thank you. BTW, I really liked Clojure/West video editing style.

Andy

On Fri, Sep 12, 2014 at 8:55 AM, John Gabriele  wrote:

> A format I particularly like is when there's simply one video file where:
>
>   * the main portion of the window shows the slides,
>   * a small thumbnail-size portion shows the speaker, and
>   * the remaining rectangle shows static details such as the name of the
> talk, name of speaker, subject, and date.
>
> As in this style: <
> https://skillsmatter.com/skillscasts/3445-functional-web>.
>
> -- John
>
>
>
> On Thursday, September 11, 2014 10:33:41 AM UTC-4, Alex Miller wrote:
>>
>> Usually Rich doesn't release his slides as he prefers for them to be
>> consumed in the context of the talk.
>>
>> On Thursday, September 11, 2014 8:44:47 AM UTC-5, Leon Grapenthin wrote:
>>>
>>> Hi,
>>>  I am looking for the slides of this talk because one can't see them in
>>> the video:
>>>
>>> http://vimeo.com/100518968
>>>
>>> Thanks,
>>>  Leon.
>>>
>>>
>>>
>>>
>>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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