Re: [ANN] Vertigo: fast, idiomatic C-style structs

[Patrick Wright]

Zach,  

it might be interesting to keep an eye on the newly-announced ObjectLayout 
project by Gil Tene and Martin Thompson. Discussion/overview is on this 
mail thread
https://groups.google.com/forum/m/#!topic/mechanical-sympathy/9PNuQKuWVa4

and the project is here
http://objectlayout.github.io/ObjectLayout/

Regards
Patrick

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

Re: Proposed change to let-> syntax

[Daniel Dinnyes]

Hi,

This will sound strange from me, but are these macros really to be added to 
the core?

Firstly, I don't see they extend the language in any way new. Instead they 
ease some very special cases, which could have been done with the 
combination of existing core functions/macros just as well, and that even 
might be more readable (as the confusion around naming and meaning 
suggests). It is a complexity. I would expect that everything in the core 
is important to know. If it turns out these new macros will not be used 
that much in real life (it doesn't matter if there are real life code where 
it COULD be used, what matters is that eventually will it GET used there), 
then it's just a burden for comprehending the core for any newcomer.

Second, I have not seen myself using similar macros from other 
"contrib-like" libraries, neither writing similar stuff myself. I often 
feel the limitations of the parameter order of the "->" and "->>" macros, 
yes, but until we get feedback on the usage of such new macros, that they 
really get traction, I would feel worried about including them in the core 
name-space (for example in any reasonable project I find myself overriding 
"group-by"with
 a three parameter version).

And thirdly, the "why" to my last sentence: because including them in the 
core namespace is a commitment. It should not be just removed later if it 
turns out no one really needs them. Should not be modified, or patched up, 
or prettified, or renamed later either. Because it can break someone's 
production code, someone's business, maybe someone's L.I.F.E. I'm not 
saying it CAN'T be changed, but it can reflect bad on us. There is no 
problem in saying "well, it turned out I was wrong, and now comes the hard 
work to get things right", but only if all the precautions were done 
beforehand.

Why don't we have a "candidate" name-space, a separate library, like the 
contrib before, which most people who prefer to be on the cutting edge just 
include automatically. That would give reasonable feedback on how much 
traction new stuff like these get, and keeps it physically obvious what is 
considered The Core.

Regards,

Daniel


On Friday, November 30, 2012 3:37:44 PM UTC, Rich Hickey wrote:
>
> I'm not satisfied with the names for the new threading macros either. 
>
> The new names being considered for let->, test-> and when-> are: 
>
> A) let-> becomes as-> 
>
> reduces arg order and destructuring expectations. 
>
> B) test-> becomes cond-> 
>
> cond-> was the original name, and, protestations about not 
> short-circuiting like cond notwithstanding, it is still the best fit. The 
> doc string will say: 
>
> "Note that, unlike cond branching, cond-> threading does 
>   not short circuit after the first true test expression." 
>
> C) when-> becomes some-> 
>
> and in doing so, tests for non-nil rather than truth. 
>
> == 
> This last one touches on the general area of non-nil-ness, often needed. 
> Other possible (future) ideas in line with this are: 
>
> (some? x) == (not (nil? x)) 
>
> (some coll) ;;note no pred, == (some some? coll) 
>
> this is tricky, as we are bridging CL's some and Maybe's Some 
>
> if-some, when-some et al. 
>
> (some! x) ;;(or somex ?) identity for all but nil, which throws 
>
> etc 
> == 
>
> Last chance for fabulous and better names than these: (as->, cond-> and 
> some->). Note that "cond-> doesn't match cond's short-circuit" has been 
> considered already, please do not repeat. 
>
> Thanks, 
>
> Rich 
>
>

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

[Michał Marczyk]

On 19 July 2013 10:24, Daniel Dinnyes  wrote:
> Why don't we have a "candidate" name-space, a separate library, like the
> contrib before, which most people who prefer to be on the cutting edge just
> include automatically. That would give reasonable feedback on how much
> traction new stuff like these get, and keeps it physically obvious what is
> considered The Core.

https://github.com/clojure/core.incubator

Cheers,
Michał

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

[Alex Baranosky]

I use some-> and cond-> pretty heavily... I know I'm just one dude, but I
am grateful they're in core so I don't have to cajole all my teammates into
accepting them in the code base :)

On Fri, Jul 19, 2013 at 1:38 AM, Michał Marczyk wrote:

> On 19 July 2013 10:24, Daniel Dinnyes  wrote:
> > Why don't we have a "candidate" name-space, a separate library, like the
> > contrib before, which most people who prefer to be on the cutting edge
> just
> > include automatically. That would give reasonable feedback on how much
> > traction new stuff like these get, and keeps it physically obvious what
> is
> > considered The Core.
>
> https://github.com/clojure/core.incubator
>
> Cheers,
> Michał
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Domain-specific language design books

[Sam Griffith]

This book has examples in several JVM languages like Java, Scala, Clojure, 
Ruby, and Groovy and contains fully explained code snippets that implement 
real-world DSL designs.

http://www.manning.com/ghosh/

I found it quite good.

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

Wrapping LevelDB with ring/compojure app

[Tarik Ansari]

Hello Folks,

I am a complete Clojure newbie and trying to achieve something pretty 
simple and looking for an idiomatic, if I can make it work at all, way to 
do it.

My issue is I need to retain the LevelDB descriptor and share it between 
requests, LevelDB is already thread-safe.
For example:

(defn -main
  "I don't do a whole lot ... yet."
  [& args]

  (println "Opening LevelDB file in db/main")
  (with-open [main-db (db/open "db/main")]

(println "Running server on port 3000")
(run-jetty #'web/app {:port 3000})))

Now, how can I access that main-db descriptor in my requests handlers?
This, obviously won't work, as main-db is not defined in web/app:

(GET "/test" []
(db/put main-db (.getBytes "testKey2") (.getBytes "testValue2"))
"Hello World")


PS: If it helps anyone for setup, I have made a Clojar for the LevelDB JNI 
Clojure wrapper based on Sedward's: 
https://clojars.org/org.clojars.aircart/leveldb-clj

Thanks in advance for your insight/help!

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

[Jay Fields]

this is a great book:
http://www.amazon.com/Domain-Specific-Languages-Addison-Wesley-Signature-Series/dp/0321712943

don't let the language selection deter you. the patterns are abstract and
can easily be applied to Clojure.


On Thu, Jul 18, 2013 at 4:30 PM, JvJ  wrote:

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

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

Re: Proposed change to let-> syntax

[Jay Fields]

I'm already using as-> in prod. I think the ship has sailed on convincing
Rich not to include them.


On Fri, Jul 19, 2013 at 5:39 AM, Alex Baranosky <
alexander.barano...@gmail.com> wrote:

> I use some-> and cond-> pretty heavily... I know I'm just one dude, but I
> am grateful they're in core so I don't have to cajole all my teammates into
> accepting them in the code base :)
>
>
> On Fri, Jul 19, 2013 at 1:38 AM, Michał Marczyk 
> wrote:
>
>> On 19 July 2013 10:24, Daniel Dinnyes  wrote:
>> > Why don't we have a "candidate" name-space, a separate library, like the
>> > contrib before, which most people who prefer to be on the cutting edge
>> just
>> > include automatically. That would give reasonable feedback on how much
>> > traction new stuff like these get, and keeps it physically obvious what
>> is
>> > considered The Core.
>>
>> https://github.com/clojure/core.incubator
>>
>> Cheers,
>> Michał
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: How core.async compares to agents, future and promise?

[Timothy Baldridge]

Let me give a short description of each and perhaps that will help explain
when each would be preferred:

promise - creates a object that can be deref'd. The result of the promise
can be delivered once, and deref-ing a undelivered will cause the deref-ing
thread to block. A single producer can give a single value to multiple
threads

future - just like a promise, but it the delivering code is given to the
future and the future will go off and execute that code in a different
thread. Single producer delivers a single value produced in a undefined
thread, to multiple consumers

agents - couples a unbounded queue of functions with a single mutable
value. Mutating that value is accomplished by enqueue'ing functions to be
executed against that mutable state. Multiple producers use functions to
modify a mutable ref. Can be deref-ed by may different consumers

channels - allow multiple producers to provide data to multiple consumers
on a one-to-one basis. That is to say, a single value put into a channel
can only be taken by a single consumer. However, multiple values can be
inflight at a single time. This is all delivered by a bounded queue (notice
the difference with unbounded agents). This allows for back-pressure, where
slow producers can block faster consumers. So perhaps the best way to think
about channels is a bounded mutable queue of promises

Hopefully this helps a bit,

Timothy Baldridge


On Thu, Jul 18, 2013 at 10:54 PM, julius  wrote:

> It brother me too.
>
> Thanks
>
>
> On Friday, July 5, 2013 3:28:54 AM UTC+8, Hussein B. wrote:
>>
>> Hi,
>>
>> How core.async compares to agents, future and promise?
>>
>> When to use core.async and when to use agents, future and promise?
>>
>> Thanks for help and 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.
>
>
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

Re: Proposed change to let-> syntax

[Daniel Dinnyes]

Yeah, seemingly I am still a newcomer here. As long as no one minds me 
coming up with "great ideas", I don't mind looking stupid either... it will 
improve hopefully :)

On Friday, July 19, 2013 9:38:48 AM UTC+1, Michał Marczyk wrote:
>
> On 19 July 2013 10:24, Daniel Dinnyes > 
> wrote: 
> > Why don't we have a "candidate" name-space, a separate library, like the 
> > contrib before, which most people who prefer to be on the cutting edge 
> just 
> > include automatically. That would give reasonable feedback on how much 
> > traction new stuff like these get, and keeps it physically obvious what 
> is 
> > considered The Core. 
>
> https://github.com/clojure/core.incubator 
>
> Cheers, 
> Michał 
>

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

Re: How core.async compares to agents, future and promise?

[Cedric Greevey]

On Fri, Jul 19, 2013 at 8:25 AM, Timothy Baldridge wrote:

> channels - allow multiple producers to provide data to multiple consumers
> on a one-to-one basis. That is to say, a single value put into a channel
> can only be taken by a single consumer.
>

Although, you can implement a "cable splitter", e.g.

(go
  (loop []
(let [x (! c2 x)
  (>! c3 x))
(recur)))

if you need to send some stuff to multiple consumers. Or even implement a
subscription service:

(def submap (atom {}))

(defn subscribe [c f]
  (swap! submap #(merge-with into % {c #{f}})))

(defn unsubscribe [c f]
  (swap! submap #(let [s (disj (% c) f)]
(if (empty? s)
  (dissoc % c)
  (assoc % c s

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

Re: How core.async compares to agents, future and promise?

[Timothy Baldridge]

But notice that each of these  examples uses either uses multiple channels.
Or is unrecommended behavior.

In your latter example, you're throwing parallelism out of the window. It
might work better if you had something like (go (f x)) but that then
creates an unbounded queue. Why not allow subscribers to hand a channel
instead of a function? That way your system is uniform and back-pressure
would work as expected. In addition, subscribers to could pass in buffered
or sliding-buffered channels and this would allow slower consumers to not
hold up the entire system.


On Fri, Jul 19, 2013 at 7:03 AM, Cedric Greevey  wrote:

> On Fri, Jul 19, 2013 at 8:25 AM, Timothy Baldridge 
> wrote:
>
>> channels - allow multiple producers to provide data to multiple consumers
>> on a one-to-one basis. That is to say, a single value put into a channel
>> can only be taken by a single consumer.
>>
>
> Although, you can implement a "cable splitter", e.g.
>
> (go
>   (loop []
> (let [x (   (>! c2 x)
>   (>! c3 x))
> (recur)))
>
> if you need to send some stuff to multiple consumers. Or even implement a
> subscription service:
>
> (def submap (atom {}))
>
> (defn subscribe [c f]
>   (swap! submap #(merge-with into % {c #{f}})))
>
> (defn unsubscribe [c f]
>   (swap! submap #(let [s (disj (% c) f)]
> (if (empty? s)
>   (dissoc % c)
>   (assoc % c s
>
> (defn submit-channel [c]
>   (go
> (loop []
>   (let [x ( (doseq [f (@submap c)]
>   (f x)))
>   (recur
>
> or something like that (untested, but subscribing a function to a
> submitted channel should result in it getting called with each item put
> onto the channel until it's unsubscribed or the producer stops putting
> things onto it; replacing the callbacks with channels that will get copies
> put onto them while subscribed should be a trivial transformation).
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

Re: How core.async compares to agents, future and promise?

[Cedric Greevey]

Occurs to me that a common async pattern is going to be to put an
unconditional infinite loop in a go block, so we might want a macro for
such loops if they'll become much more common:

(defmacro endlessly
  "Executes the body over and over again."
  [& body]
  `(loop [] ~@(concat body '(recur

(go
  (endlessly
(let [x ( c2 x)
  (!> c3 x

Or even a go-forever:

(defmacro go-forever
  "Like 'go', but repeats its body forever."
  [& body]
  `(go (loop [] ~@(concat body '(recur)

Also, if the go is only useful as long as there's a value from some source:

(defmacro while-let
  "Like when-let, but repeats its body if it succeeded the last time"
  [[s expr] & body]
  `(loop []
 (when-let [~s ~expr]
   ~@body
   (recur

(go
  (while-let [x ( c2 x)
(!> c3 x)))

That version should halt if c1 is closed by its producer. (It won't close
c2 and c3; on the other hand a go consuming from either will park forever
once those stop receiving values. The original splitter would park forever
if c1 stopped getting values, but would load c2 and c3 with nils for as
long as something was consuming from each channel if c1 was closed.)

One can also envision (go (while-let [x (alt! ...)] ...)), which would run
until all of the alternatives were closed.

If one wants to close c2 and c3 if c1 is closed, though, it's more
annoying, as one wants a multiline body if c1 has a value and a different
multiline body to execute a single time when c1 is closed. At that point
there's no nice macrology that can make things much more concise than, but
as readable as, a loop with an if-let and two do blocks inside:

(go
  (loop []
(if-let [x (! c2 x) (>! c3 x) (recur))
  (do (close! c2) (close! c3)

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

Re: How core.async compares to agents, future and promise?

[Cedric Greevey]

On Fri, Jul 19, 2013 at 9:16 AM, Timothy Baldridge wrote:

> But notice that each of these  examples uses either uses multiple
> channels. Or is unrecommended behavior.
>
> In your latter example, you're throwing parallelism out of the window. It
> might work better if you had something like (go (f x)) but that then
> creates an unbounded queue. Why not allow subscribers to hand a channel
> instead of a function? That way your system is uniform and back-pressure
> would work as expected. In addition, subscribers to could pass in buffered
> or sliding-buffered channels and this would allow slower consumers to not
> hold up the entire system.
>

I mentioned that transforming the subscriber system to subscribe channels
rather than functions should be trivial, and left that and any further
sophistications as exercises for the reader. :)

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

[gaz jones]

Instead of using the var #'web/app in run-jetty, use a function that takes
your main-db as an argument and returns the routes for your app. You can
use the compojure.core/routes to build your app routes rather than using a
global var.


On Fri, Jul 19, 2013 at 3:42 AM, Tarik Ansari  wrote:

> Hello Folks,
>
> I am a complete Clojure newbie and trying to achieve something pretty
> simple and looking for an idiomatic, if I can make it work at all, way to
> do it.
>
> My issue is I need to retain the LevelDB descriptor and share it between
> requests, LevelDB is already thread-safe.
> For example:
>
> (defn -main
>   "I don't do a whole lot ... yet."
>   [& args]
>
>   (println "Opening LevelDB file in db/main")
>   (with-open [main-db (db/open "db/main")]
>
> (println "Running server on port 3000")
> (run-jetty #'web/app {:port 3000})))
>
> Now, how can I access that main-db descriptor in my requests handlers?
> This, obviously won't work, as main-db is not defined in web/app:
>
> (GET "/test" []
> (db/put main-db (.getBytes "testKey2") (.getBytes "testValue2"))
> "Hello World")
>
>
> PS: If it helps anyone for setup, I have made a Clojar for the LevelDB JNI
> Clojure wrapper based on Sedward's:
> https://clojars.org/org.clojars.aircart/leveldb-clj
>
> Thanks in advance for your insight/help!
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: --> macro proposal

[Daniel Dinnyes]

On Monday, July 15, 2013 11:53:09 PM UTC+1, Jeremy Heiler wrote:
>
> On July 15, 2013 at 6:30:28 PM, Daniel Dinnyes 
> (dinn...@gmail.com) 
> wrote:
>
> Hmm, good point, especially the `let` one... What is `as->`? I can't find 
> anything about that.
>
> http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/as-%3E
>
> There is one benefit over `let` though: it is more explicit. Let allows 
> you to define independent bindings mixed together with multiple threads of 
> dependent bindings (which can be mixed in random combinations). As the 
> number of bindings increase it becomes quite messy, and hard to decipher 
> which line depends on which. I have seen, even written myself (shame on 
> me), such code. I feel that this is the main reason for the `core` 
> threading macros too ("why not use let instead?" would still apply then). 
> On the other hand as my simple example code demonstrates (off the top of my 
> hat, cuz ya need to show da code!), in a functional language the parameter 
> order shouldn't matter, and there shouldn't be privileged (main!?) 
> parameter positions (Clojure is the landguage of multimethods after all!)
>
> Your ->>> is a bit awkward because the symbol to the left represents the 
> value of the previous expression, not the value of the following expression 
> as is the case with most "bindings forms" in Clojure. Also, as-> simplifies 
> your use case by only needing to identify one name that is used in all the 
> threaded forms. Honestly, if I'm going to do anything more complicated that 
> as->, I would rethink how I want to express my code.
>
 You are trying to pick it up on the wrong end. Check this out:

(-> "test-string-with-lots-of-dashes"
(fn [x] (s/split x #"-"))
(fn [y] (interleave y (range)))
(fn [z] (s/join #"_" z))
(fn [z] (s/join " * " ["I am serious" z "Not Kidding!!" z])))

The above code is not valid, as the -> macro sees the function declarations 
as lists, and tries to thread the argument through it. It is quite 
intuitive though IMHO. Now with that in mind, check this baby once more:

(->>> "test-string-with-lots-of-dashes"
x (s/split x #"-")
y (interleave y (map count y))
z (apply assoc {} z)
{:strs [test string with lots of dashes]}
(s/join " " ["test is" test ";" "string is" string ";" "with is" 
with ";" "lots is" lots ";" "of is" of ";" "dashes is" dashes ";" "TOTAL:" 
(+ test string with lots of dashes)]))

> "test is 4 ; string is 6 ; with is 4 ; lots is 4 ; of is 2 ; dashes is 6 
; TOTAL: 26"

Yee-haw !!!

Anyway, I see the reason for -> and ->> macros and indeed the first and 
> last positions are special in some sense. The -> is good for navigating 
> protocols, and ->> is good for functions expected/designed to be partially 
> applied. Is that correct?
>
> The threading macros operate on the forms directly, so I'm not sure what 
> you mean by "partially applied" here. The big win for ->> is that the 
> sequence functions in Clojure core expect the sequence to be last. This is 
> handy for threading a sequence through multiple transformations.
>
By partially applied I mean using the `partial` function on them to 
partially apply all parameters except the last few. If a function can be 
partially applied so that only the last parameter is not applied, where it 
could accept the argument in question, then it would work well with ->> 
macro.

(let [myfun (partial apply assoc {})]
  (->> ["test" "string" "with" "lots" "of" "dashes"]
   myfun))

(->> ["test" "string" "with" "lots" "of" "dashes"]
 (apply assoc {}))

Hope that makes it clearer what I meant.

Regards,

Daniel

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

[Stuart Sierra]

On Thursday, July 18, 2013 4:34:49 AM UTC-4, Jozef Wagner wrote:

> Compiler loads and refers clojure.core namespace for each
> new namespace. In my projects, I often have one or two
> namespaces I use nearly in every other namespace. (e.g.
> clojure.tools.logging or clojure.string). It would be
> convenient if I could specify ns defaults somewhere and
> those declarations would be used for every compiled
> namespace.


You can do this without hacking the compiler if you're
willing to add one extra line to your source files.

Just define a function that `require`s and `refer`s all the
symbols you want, and call it at the top of each namespace.
You'll break tools that expect to be able to infer namespace
dependencies from the literal source (e.g. tools.namespace)
but it will do what you want.

-S

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

[Daniel Dinnyes]

Cheers mate, good point there!


On Wednesday, July 17, 2013 6:03:41 PM UTC+1, David Nolen wrote:
>
> While the macro can do what the original enhancement request suggested 
> that's not the actual problem the new threading macros were intended to 
> solve. They were primarily added to eliminate:
>
> (let [x ...
>   x ...
>   x ...]
>...)
>
> Which is pretty ugly and also it's pretty easy to get into trouble.
>
> David
>
>
> On Wed, Jul 17, 2013 at 12:49 PM, Alexander Yakushev 
> 
> > wrote:
>
>> What a twist.
>>
>> Does any of the participants care to comment on this one? A hundred posts 
>> of bashing a person from the position of authority while the macro in 
>> question already sits in Core. I am against the usage of it myself, and 
>> closely followed previous discussions on this topic to understand the 
>> arguments being brought there; but arguing against something you already 
>> accepted is beyond my comprehension, tbh.
>>
>>
>> On Wednesday, July 17, 2013 6:07:53 AM UTC+3, Gary Johnson wrote:
>>>
>>> Ugh. What a pointless thread. Someone could have just said:
>>>
>>>  ---
>>>  It's already in clojure 1.5. The form you are looking for is called 
>>> as->.
>>>  Your original example would be written like this:
>>>
>>>   (as-> 3 x (+ 1 x 4) (prn "answer:" x))
>>>   ---
>>>
>>> Done. Yeesh.
>>>
>>> On Sunday, July 14, 2013 12:34:02 PM UTC-4, Jeremy Heiler wrote:

 On Sat, Jul 13, 2013 at 9:08 PM, Daniel Dinnyes  
 wrote: 
 > Just made a quick search on `main arguments` on both Google and 
 Wikipedia. 
 > Do you mean the arguments in `public static void main (String[] 
 args)`? If 
 > not please provide some definition what do you mean by main 
 arguments. Else 
 > the point is meaningless. 

 He means the arguments you are threading. 

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

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

[ANN] Immutant 1.0.0.cr1 released

[Toby Crawley]

We just released[0] v1.0.0.cr1 of Immutant, and plan to have 1.0.0 final
out in about a week. If you are an Immutant user, please upgrade as soon
as you can to help us track down any remaining bugs.

## What is Immutant?

Immutant[1] is an application server for Clojure. It's an integrated
platform built on JBoss AS7[2] that aims to reduce the inherent
incidental complexity[3] in real world applications.

[0]: http://bit.ly/imm100cr1
[1]: http://immutant.org/
[2]: http://www.jboss.org/as7
[3]: http://en.wikipedia.org/wiki/Accidental_complexity

- Toby

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

[Mikera]

If you want to do in in "pure functional style" then I would suggest a 
single atom / ref that contains the whole game state (including monsters, 
players, map, items etc.)

That's the approach I've taken in the two Clojure games I've written so 
far, and it has worked pretty well. You might be interested in the blog 
posts I wrote about Alchemy, a 7 day Roguelike game in Clojure. There's a 
series of these starting with this: 
http://clojurefun.wordpress.com/2013/03/12/alchemy-day-1-a-room-with-a-view/

On Friday, 19 July 2013 16:55:20 UTC+1, vis wrote:
>
> Hey guys,
>
> I am playing around with a gameserver in clojure, here is the situation:
> - I have a *ref of a hashmap that holds refs of players*
> - I have a *ref of a hashmap that holds refs of monsters*
> I used "refs of players" and "refs of monsters" because at some point I 
> might have to transfer things from a player to a monster (like items). 
> Since this would be a transaction, refs should be the right choice.
>
> But now I also need some kind of AI loop for each monster. So my question 
> is, what would be the "clojure way" to do this?
> - use* *a* ref of a hashmap that holds agents of monsters *so I can just 
> use send-off for each monster?
> - use a *ref of a hashmap that holds refs of monsters* that each have a 
> agent property that I can send things to?
> - or simply use a java.thread for each one?
> - or am I completely missing something?
>
> Thanks in advance,
> vis
>

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

ANN: Pulsar 0.2.0 Released

[pron]

Featuring: distributed actors, supervisors, fiber-blocking IO, and an 
implementation of core.async.
Read the announcement 
here
.

Imagine running an entire Ring handler inside a go-block...

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

[vis]

Note: what concerns me about using a* ref of a hashmap that holds agents of 
monsters* is that I would loose the transaction benefits of the ref (hence 
I can't safely move items from a player to a monster).

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

Design Question: Agents vs. Refs

[vis]

Hey guys,

I am playing around with a gameserver in clojure, here is the situation:
- I have a *ref of a hashmap that holds refs of players*
- I have a *ref of a hashmap that holds refs of monsters*
I used "refs of players" and "refs of monsters" because at some point I 
might have to transfer things from a player to a monster (like items). 
Since this would be a transaction, refs should be the right choice.

But now I also need some kind of AI loop for each monster. So my question 
is, what would be the "clojure way" to do this?
- use* *a* ref of a hashmap that holds agents of monsters *so I can just 
use send-off for each monster?
- use a *ref of a hashmap that holds refs of monsters* that each have a 
agent property that I can send things to?
- or simply use a java.thread for each one?
- or am I completely missing something?

Thanks in advance,
vis

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

[Jonathan Fischer Friberg]

While I haven't tried libgdx myself, you should be able to do something
like this:

1. Create a "global" namespace (or similar), which should contain global
variables
and/or functions that should never be reloaded. In this namespace you
essentially
put the things that there can only be one of - the "app" that you're
talking about.

2. Use https://github.com/clojure/tools.namespace to reload your code. With
this,
as long as you don't change the "global" namespace, the "app" will never be
reloaded.

Again, I don't know if this will work for libgdx, but it sounds like it
might. It's also
not very idiomatic to use a global "app", but since you can only have more
than
one, it should never be a problem. Of course, you will have to make sure
that
the old state is removed when restarting, but that should be manageable.

Jonathan


On Thu, Jul 18, 2013 at 5:19 AM, JvJ  wrote:

> 1) Phonegap seems like it just makes HTML5.  So, does it work with
> android, IOS, and desktop?
> 2) I haven't done much clj-script development.  What's the REPL situation
> like with that?
> 3) Nice job using PITA in that sense.
>
>
> On Wednesday, 17 July 2013 16:30:08 UTC-7, Chris Bui wrote:
>>
>> I haven't worked with Penumbra, but I've tried getting LibGDX to work
>> with Clojure and it's just a PITA. Totally agree that you lose the REPL
>> with LibGDX.
>>
>> I'm writing another game now, although much if it is server side. I did
>> however, discover that you can use Phonegap to write HTML5 applications and
>> deploy them to Android, iOS. And if you can do that, you can write games
>> with Clojurescript using the canvas. Also, there are Box2d libraries for
>> javascript that you can use. Just throwing another option out there.
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Socket.IO and Clojure?

[cma]

If you want something robust I'd recommend something like http-kit or Netty 
on the backend + using websockets (and a shim) directly on the frontend, or 
possibly browserchannel if you need to worry about firewalls and ancient 
browsers.

Socket.IO is a moving target intended for a single audience (not 
multiplatform). It's not going to win you more than you'll pay in bugs and 
performance issues in the long run.

On Tuesday, July 16, 2013 10:07:34 PM UTC-7, Sean Corfield wrote:
>
> At work we're starting down the path of building a new piece of 
> functionality based on WebSockets and the external team we're working 
> with is a Node.js shop so their go to solution is Socket.IO and 
> they've produced a very nice front end in CoffeeScript and a prototype 
> back end on Node.js. 
>
> I'd really like to have our back end on the JVM, of course, and so I'd 
> like to find a JVM-based Socket.IO solution that I use from/with 
> Clojure... 
>
> This seems like a reasonable option: 
>
> https://github.com/mrniko/netty-socketio 
>
> A little bit of experimentation with lein-try (Thank you Ryan!) shows 
> that it's pretty easy to get a basic server up and running in the REPL 
> - and I was able to get several of their demos running unchanged 
> against Clojure, instead of their Java applications, so that was 
> promising. 
>
> Are there other folks out there doing Socket.IO stuff with Clojure? 
> What approaches have you taken? 
>
> Obviously, we could run Node.js and have it hit a Clojure-based REST 
> API to do the integration, and that might be less pain long term 
> but... 
> -- 
> Sean A Corfield -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
> World Singles, LLC. -- http://worldsingles.com/ 
>
> "Perfection is the enemy of the good." 
> -- Gustave Flaubert, French realist novelist (1821-1880) 
>

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

Re: --> macro proposal

[Daniel Dinnyes]

Oh, and the implementation is clean and simple. Just cleaned it up a bit 
from all the clutter:

;;; The DUH..IT'S SO SIMPLE! macro
(defmacro duh->
  ([x alias form]
 `(let [~alias ~x] ~form))
  ([x alias form & more]
 `(duh-> (duh-> ~x ~alias ~form) ~@more)))

This gives YOU the full power of destructuring and threading through 
functions with ANY parameter order. Full `let` power! Why not use let then? 
True, the only difference is the restriction to a single thread of 
bindings, not allowing for mixing things up. As David Nolen points out 
below though, that is a HUGE benefit, the reason why all the threading 
macros exist. Beside that restriction, this fine macro above won't struggle 
to take away any of the `let` goodies, unlike ->, ->>, as->, or anything.

I need a beer.


On Friday, July 19, 2013 3:18:15 PM UTC+1, Daniel Dinnyes wrote:
>
>
>
> On Monday, July 15, 2013 11:53:09 PM UTC+1, Jeremy Heiler wrote:
>>
>> On July 15, 2013 at 6:30:28 PM, Daniel Dinnyes (dinn...@gmail.com) wrote:
>>
>> Hmm, good point, especially the `let` one... What is `as->`? I can't find 
>> anything about that.
>>
>> http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/as-%3E
>>
>> There is one benefit over `let` though: it is more explicit. Let allows 
>> you to define independent bindings mixed together with multiple threads of 
>> dependent bindings (which can be mixed in random combinations). As the 
>> number of bindings increase it becomes quite messy, and hard to decipher 
>> which line depends on which. I have seen, even written myself (shame on 
>> me), such code. I feel that this is the main reason for the `core` 
>> threading macros too ("why not use let instead?" would still apply then). 
>> On the other hand as my simple example code demonstrates (off the top of my 
>> hat, cuz ya need to show da code!), in a functional language the parameter 
>> order shouldn't matter, and there shouldn't be privileged (main!?) 
>> parameter positions (Clojure is the landguage of multimethods after all!)
>>
>> Your ->>> is a bit awkward because the symbol to the left represents the 
>> value of the previous expression, not the value of the following expression 
>> as is the case with most "bindings forms" in Clojure. Also, as-> simplifies 
>> your use case by only needing to identify one name that is used in all the 
>> threaded forms. Honestly, if I'm going to do anything more complicated that 
>> as->, I would rethink how I want to express my code.
>>
>  You are trying to pick it up on the wrong end. Check this out:
>
> (-> "test-string-with-lots-of-dashes"
> (fn [x] (s/split x #"-"))
> (fn [y] (interleave y (range)))
> (fn [z] (s/join #"_" z))
> (fn [z] (s/join " * " ["I am serious" z "Not Kidding!!" z])))
>
> The above code is not valid, as the -> macro sees the function 
> declarations as lists, and tries to thread the argument through it. It is 
> quite intuitive though IMHO. Now with that in mind, check this baby once 
> more:
>
> (->>> "test-string-with-lots-of-dashes"
> x (s/split x #"-")
> y (interleave y (map count y))
> z (apply assoc {} z)
> {:strs [test string with lots of dashes]}
> (s/join " " ["test is" test ";" "string is" string ";" "with is" 
> with ";" "lots is" lots ";" "of is" of ";" "dashes is" dashes ";" "TOTAL:" 
> (+ test string with lots of dashes)]))
>
> > "test is 4 ; string is 6 ; with is 4 ; lots is 4 ; of is 2 ; dashes is 6 
> ; TOTAL: 26"
>
> Yee-haw !!!
>
> Anyway, I see the reason for -> and ->> macros and indeed the first and 
>> last positions are special in some sense. The -> is good for navigating 
>> protocols, and ->> is good for functions expected/designed to be partially 
>> applied. Is that correct?
>>
>> The threading macros operate on the forms directly, so I'm not sure what 
>> you mean by "partially applied" here. The big win for ->> is that the 
>> sequence functions in Clojure core expect the sequence to be last. This is 
>> handy for threading a sequence through multiple transformations.
>>
> By partially applied I mean using the `partial` function on them to 
> partially apply all parameters except the last few. If a function can be 
> partially applied so that only the last parameter is not applied, where it 
> could accept the argument in question, then it would work well with ->> 
> macro.
>
> (let [myfun (partial apply assoc {})]
>   (->> ["test" "string" "with" "lots" "of" "dashes"]
>myfun))
>
> (->> ["test" "string" "with" "lots" "of" "dashes"]
>  (apply assoc {}))
>
> Hope that makes it clearer what I meant.
>
> Regards,
>
> Daniel
>
>

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

Re: ns defaults

[Stuart Sierra]

On Fri, Jul 19, 2013 at 3:03 PM, Jozef Wagner wrote:

> Yes, but this seems to work only in Clojure, not in ClojureScript.



That's true.

-S

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

[Thorsten Wilms]

On 07/19/2013 08:46 PM, Timothy Washington wrote:

There would just be a core data model of posts, assets and tags, that
would exists as definitions, and could be pulled into a runtime soup.


How about unifying everything that may be mapped to its own URL as 
"resource"? Such a resource would have a unique name (or path/name 
combination), created and modified timestamps, owner, permissions ...


Such a data set would then be associated with an entity-type specific 
data set to store what's special to a post or a comment or an image ...



--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

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

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

Re: Interest in a Full Featured Clojure Blog Engine

[Timothy Washington]

Ok, so I've thought a little more about the architecture of a
Clojure-based, composable blogging system. I put up my initial notes in
this github repo: Stefon . I've ordered
the system components, based on core functionality, outwards.

   - There would just be a core data model of posts, assets and tags, that
   would exists as definitions, and could be pulled into a runtime soup.
   - Then one has your CRUD + List + Find functions for those pieces of
   data.
   - Weaved into those core functions, would be a workflow that would
   handle preview, collaboration / editor review, versioning, and, I think an
   interface to the outside (plug-in) world.


I've deliberately proposed a small core, so that you can use only the
pieces you absolutely need. Additionally, I think it encourages a clean
design, forcing explicit interaction semantics between system components.
If we accept this premise, the only question then, is what mechanism we
should use to separate the core of stefon, from the rest of its plug-in
components. Now, I was looking into the nrepl
protocol.
I think it conceptually gives us the separation we need, with the added
bonus that a stefon service, and it's plug-ins, could be in separate
locations. But while I like the concept, I think the host would need a way
to i) declare the stefon service (nrepl versioning?), ii) list / publish
actions (??) iii) pass around binary data (base64 encoding?). Also, I saw
that there was a discussion around updating the nrepl protocol
(nRepl.Next),
and don't know if that's been implemented.

I think the first step is to get a clean plugin architecture (ie,
communication channel) around the above core functions. The idea is that
the core stefon service publishes it's actions, and it's up to each plug-in
to decide what, if anything, they want to do with it. So for example, if I
fire up a stefon service in my repl, I can programmatically pull some txt
or rtf from my filesystem, and add a blog entry. Stefon will notify this
action, but if no plug-ins have registered, then nothing happens. The entry
just sits in memory until the VM shuts down. Now, if a Mongo plugin has
registered to listen for new blog posts, it will get that message, and
persist the data out to some configured location.

And of course stefon would be able to listen for a plug-in to supply data.
So a web UI plug-in could pass stefon a new blog post. Internally, the same
wiring occurs. And the Mongo plug-in would see the new post, and persist
it. Given this last scenario, I think this architecture would allow
composability, with the trade-off of being very communication heavy. Having
said that, I like this approach, and have some ideas as to the tools needed
to get the job done. Also, I'll want to know if nrepl is a good fit. And if
not, what other approach to take.

Thoughts? See Stefon here .


Thanks

Tim Washington
Interruptsoftware.ca  /
Bkeeping.com



On Thu, Jul 18, 2013 at 12:25 PM, Timothy Washington wrote:

> Hadn't thought about spam detection, comment design, or versioning. But I
> like the ideas a lot. I'll design with these features in mind.
>
>
>
>
> On Thu, Jul 18, 2013 at 12:17 PM, Thorsten Wilms  wrote:
>
>> On 07/18/2013 04:24 PM, Timothy Washington wrote:
>>
>>> I know that I currently wish I had a Clojure weblog engine that I could
>>> stick into a site I'm building. If there's already something available,
>>> I'll obviously just use that. But otherwise, is this something that
>>> would be interesting to people?
>>>
>>
>> Oh yes.
>>
>> I put some effort into a blogging engine myself, but got sidetracked a
>> lot. Repo: https://github.com/thorwil/**tlog
>>
>> It's written as single account blog, but since I'm using Friend, that
>> should be straightforward to change.
>>
>> For editing, I rely on Aloha (http://aloha-editor.org/). The unfinished
>> comment system works only with JS enabled and has no spam protection or
>> email notifications. Comments can be nested and the design is meant to
>> encourage people to read previous comments, before they add their own (this
>> at the cost of varying distance between a comment and its Reply field).
>>
>> Having Aloha-like editing, but without inheriting such a chunk of JS,
>> rather using ClojureScript would rock.
>>
>> One of the more interesting parts might be how pages are assembled:
>> https://github.com/thorwil/**tlog/blob/master/src/tlog/**
>> render/html/assemble.clj#L83
>>
>> Further down the road, I wanted to look into versioning, perhaps backed
>> by git and realtime collaborative editing. I haven't be traveling, lately :}
>>
>>
>> --
>> Thorsten Wilms
>>
>> thorwil's design for free software:
>> ht

Importing another data_readers

[JvJ]

I'm not 100% on how the data_readers.clj file works.  It's just a map with 
no namespace that appears to get loaded by some kind of black magic.

Is it possible to provide a library which includes its reader macros, so 
that the library user's project doesn't need to include their own 
data_readers.clj?

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

[Jeremy Heiler]

On July 19, 2013 at 11:28:50 AM, Daniel Dinnyes (dinny...@gmail.com) wrote:
Oh, and the implementation is clean and simple. Just cleaned it up a bit from 
all the clutter:

;;; The DUH..IT'S SO SIMPLE! macro
(defmacro duh->
  ([x alias form]
 `(let [~alias ~x] ~form))
  ([x alias form & more]
 `(duh-> (duh-> ~x ~alias ~form) ~@more)))

This gives YOU the full power of destructuring and threading through functions 
with ANY parameter order. Full `let` power! Why not use let then? True, the 
only difference is the restriction to a single thread of bindings, not allowing 
for mixing things up. As David Nolen points out below though, that is a HUGE 
benefit, the reason why all the threading macros exist. Beside that 
restriction, this fine macro above won't struggle to take away any of the `let` 
goodies, unlike ->, ->>, as->, or anything.
I understood David's comment differently, that the current threading macros 
exist so that explicit bindings for each threaded form are not needed for they 
very specific cases they intend to simplify. I'm not saying your macro is dumb, 
I just don't find the sugar particularly tasty. ;-)

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

[ANN] tools.namespace 0.2.4

[Stuart Sierra]

*tools.namespace:* utilities to search for, parse, move, and
reload namespaces with awareness of their dependencies

Release 0.2.4: bug fixes only

README and source code:
https://github.com/clojure/tools.namespace

Leiningen dependency information:

[org.clojure/tools.namespace "0.2.4"]

Changes in this release:

  * Fix TNS-10: Forbid circular dependency when a namespace
depends on itself

  * Fix TNS-9 and TNS-11: support other prefix-list forms

  * Fix TNS-8: Do not modify files whose contents does not
change in `move-ns`

This is a clojure-contrib project:
http://dev.clojure.org/display/community/Contributing

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

[Timothy Washington]

My spidey sense is that the proposed data types (posts, assets, tags,
comments too ?), will have to be handled differently.

What I plan to do though, is go through some basic workflow cases, and work
out the best data relationships. That's the point at which I think common
data types could be unified. Plus, a function, like export, could also be a
URL. So I wouldn't want to tie core resources to the concept of Http URLs.
Even though they may map neatly to stefon's actions. Thoughts ?

Sent from my Android
On Jul 19, 2013 3:26 PM, "Thorsten Wilms"  wrote:
>
> On 07/19/2013 08:46 PM, Timothy Washington wrote:
>>
>> There would just be a core data model of posts, assets and tags, that
>> would exists as definitions, and could be pulled into a runtime soup.
>
>
> How about unifying everything that may be mapped to its own URL as
"resource"? Such a resource would have a unique name (or path/name
combination), created and modified timestamps, owner, permissions ...
>
> Such a data set would then be associated with an entity-type specific
data set to store what's special to a post or a comment or an image ...
>
>
>
> --
> Thorsten Wilms
>
> thorwil's design for free software:
> http://thorwil.wordpress.com/
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

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

[Stuart Sierra]

When Clojure starts it will search for files named data_readers.clj at the 
root the Java classpath. Every library JAR can have its own 
data_readers.clj and they will all be loaded and merged.

Be careful with this: if there's a conflict in data reader bindings, 
Clojure won't start. If your library provides a data reader tag that other 
users may want to override in their applications, don't put it in the 
data_readers.clj file in your library. On the other hand, if your library 
uses data readers in its own sources, then it needs to include them in its 
data_readers.clj file.

-S


On Friday, July 19, 2013 4:08:54 PM UTC-4, JvJ wrote:
>
> I'm not 100% on how the data_readers.clj file works.  It's just a map with 
> no namespace that appears to get loaded by some kind of black magic.
>
> Is it possible to provide a library which includes its reader macros, so 
> that the library user's project doesn't need to include their own 
> data_readers.clj?
>

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

[JvJ]

"Facades and workarounds for things that are more difficult than they 
should be."  Very nice.

On Friday, 19 July 2013 13:06:50 UTC-7, JvJ wrote:
>
> I'm creating a library with a lot of available functions in a lot of 
> different namespaces, and I'd like many of them to be available to users of 
> the library without having to specify a number of different import 
> statements.
>
> Is there a way to have the core namespace 'export' the other namespaces 
> without having to place all the important functions in one monolithic 
> core.clj?
>

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

[Alex Baranosky]

I'll second that you are usually doing something unidiomatic if you're
using refs of refs.

On Fri, Jul 19, 2013 at 2:44 PM, vis  wrote:

> Good point, I didn't think about that for some reason.
> Yes I will give it a read, thanks for the link!
>
>
> On Friday, July 19, 2013 6:19:03 PM UTC+2, Mikera wrote:
>>
>> If you want to do in in "pure functional style" then I would suggest a
>> single atom / ref that contains the whole game state (including monsters,
>> players, map, items etc.)
>>
>> That's the approach I've taken in the two Clojure games I've written so
>> far, and it has worked pretty well. You might be interested in the blog
>> posts I wrote about Alchemy, a 7 day Roguelike game in Clojure. There's a
>> series of these starting with this: http://clojurefun.**
>> wordpress.com/2013/03/12/**alchemy-day-1-a-room-with-a-**view/
>>
>> On Friday, 19 July 2013 16:55:20 UTC+1, vis wrote:
>>>
>>> Hey guys,
>>>
>>> I am playing around with a gameserver in clojure, here is the situation:
>>> - I have a *ref of a hashmap that holds refs of players*
>>> - I have a *ref of a hashmap that holds refs of monsters*
>>> I used "refs of players" and "refs of monsters" because at some point I
>>> might have to transfer things from a player to a monster (like items).
>>> Since this would be a transaction, refs should be the right choice.
>>>
>>> But now I also need some kind of AI loop for each monster. So my
>>> question is, what would be the "clojure way" to do this?
>>> - use* *a* ref of a hashmap that holds agents of monsters *so I can
>>> just use send-off for each monster?
>>> - use a *ref of a hashmap that holds refs of monsters* that each have a
>>> agent property that I can send things to?
>>> - or simply use a java.thread for each one?
>>> - or am I completely missing something?
>>>
>>> Thanks in advance,
>>> vis
>>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Design Question: Agents vs. Refs

[vis]

Good point, I didn't think about that for some reason. 
Yes I will give it a read, thanks for the link!

On Friday, July 19, 2013 6:19:03 PM UTC+2, Mikera wrote:
>
> If you want to do in in "pure functional style" then I would suggest a 
> single atom / ref that contains the whole game state (including monsters, 
> players, map, items etc.)
>
> That's the approach I've taken in the two Clojure games I've written so 
> far, and it has worked pretty well. You might be interested in the blog 
> posts I wrote about Alchemy, a 7 day Roguelike game in Clojure. There's a 
> series of these starting with this: 
> http://clojurefun.wordpress.com/2013/03/12/alchemy-day-1-a-room-with-a-view/
>
> On Friday, 19 July 2013 16:55:20 UTC+1, vis wrote:
>>
>> Hey guys,
>>
>> I am playing around with a gameserver in clojure, here is the situation:
>> - I have a *ref of a hashmap that holds refs of players*
>> - I have a *ref of a hashmap that holds refs of monsters*
>> I used "refs of players" and "refs of monsters" because at some point I 
>> might have to transfer things from a player to a monster (like items). 
>> Since this would be a transaction, refs should be the right choice.
>>
>> But now I also need some kind of AI loop for each monster. So my question 
>> is, what would be the "clojure way" to do this?
>> - use* *a* ref of a hashmap that holds agents of monsters *so I can just 
>> use send-off for each monster?
>> - use a *ref of a hashmap that holds refs of monsters* that each have a 
>> agent property that I can send things to?
>> - or simply use a java.thread for each one?
>> - or am I completely missing something?
>>
>> Thanks in advance,
>> vis
>>
>

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

Exporting Multiple Namespaces

[JvJ]

I'm creating a library with a lot of available functions in a lot of 
different namespaces, and I'd like many of them to be available to users of 
the library without having to specify a number of different import 
statements.

Is there a way to have the core namespace 'export' the other namespaces 
without having to place all the important functions in one monolithic 
core.clj?

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

[Jonathan Fischer Friberg]

Hehe, yep. I mean, it's super useful for any library that needs more than
one file. Which is most of them.

Jonathan

On Sat, Jul 20, 2013 at 12:57 AM, JvJ  wrote:

> "Facades and workarounds for things that are more difficult than they
> should be."  Very nice.
>
>
> On Friday, 19 July 2013 13:06:50 UTC-7, JvJ wrote:
>>
>> I'm creating a library with a lot of available functions in a lot of
>> different namespaces, and I'd like many of them to be available to users of
>> the library without having to specify a number of different import
>> statements.
>>
>> Is there a way to have the core namespace 'export' the other namespaces
>> without having to place all the important functions in one monolithic
>> core.clj?
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Interest in a Full Featured Clojure Blog Engine

[Timothy Washington]

Ok, that makes sense. Thanks Chas.


On Fri, Jul 19, 2013 at 7:53 PM, Chas Emerick  wrote:

> On Jul 19, 2013, at 2:46 PM, Timothy Washington wrote:
>
> I've deliberately proposed a small core, so that you can use only the
> pieces you absolutely need. Additionally, I think it encourages a clean
> design, forcing explicit interaction semantics between system components.
> If we accept this premise, the only question then, is what mechanism we
> should use to separate the core of stefon, from the rest of its plug-in
> components. Now, I was looking into the nrepl 
> protocol.
> I think it conceptually gives us the separation we need, with the added
> bonus that a stefon service, and it's plug-ins, could be in separate
> locations. But while I like the concept, I think the host would need a way
> to i) declare the stefon service (nrepl versioning?), ii) list / publish
> actions (??) iii) pass around binary data (base64 encoding?). Also, I saw
> that there was a discussion around updating the nrepl protocol 
> (nRepl.Next),
> and don't know if that's been implemented.
>
>
> Only barely following along, but FYI: the nREPL.Next page you linked to is
> quite old, and described the state of affairs a couple of years ago.  One
> of the paths described therein was taken, and is represented in nREPL
> releases starting with 0.2.0.  There are no plans currently for changing
> the default nREPL transport's wire protocol.
>
> I've updated the wiki page to note this to avoid further confusion, thanks
> for mentioning it. :-)
>
> - Chas
>
>

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

[Daniel Dinnyes]

> I understood David's comment differently, that the current threading 
> macros exist so that explicit bindings for each threaded form are not 
> needed for they very specific cases they intend to simplify. I'm not saying 
> your macro is dumb, I just don't find the sugar particularly tasty. ;-)
>
That's indeed quite different how I understood his comment. For me it meant 
that the old threading macros like -> and ->> caused people to use the `let 
[x ... x ... x ... ]` forms. The reason why people would do that in my 
interpretation is because they needed to thread trough varying parameter 
order. The x-s for me there try to emphasize the rebinding of the same 
symbol, i.e. one thread of bindings. The rebinding of the same symbol 
though, like what as-> does, removes the possibility of using 
destructuring, one of my goodies point above, unless you thread through 
structurally similar return values. Also, in this mail conversation there 
was no mentioning of the other new threaded forms besides as->, so I am not 
sure why he would be referring to some->, cond->, etc. Since that's quite a 
big difference in interpretation, I would like to hear David's point on 
this.

Btw, I don't like sugary-sweet dreams either, rather the bitter delirium of 
a strong Belgian ale... rare to find here in the UK, but sometimes you can 
get lucky ;)

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

[Jeremy Heiler]

Got a link?

On July 19, 2013 at 8:37:13 PM, Sebastian Rojas 
(sebastian.rojas.viva...@gmail.com) wrote:

A library for RESTFul applications built on top of Compojure, includes routing 
abstractions with reverse routing functionalities and validation helpers.
--  
--  
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---  
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

Re: [ANN] REST in Peace 0.1.0

[Steven Degutis]

https://github.com/sebastiansen/rip


On Fri, Jul 19, 2013 at 7:49 PM, Jeremy Heiler wrote:

> Got a link?
>
> On July 19, 2013 at 8:37:13 PM, Sebastian Rojas (
> sebastian.rojas.viva...@gmail.com) wrote:
>
> A library for RESTFul applications built on top of Compojure, includes
> routing abstractions with reverse routing functionalities and validation
> helpers.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Interest in a Full Featured Clojure Blog Engine

[Chas Emerick]

On Jul 19, 2013, at 2:46 PM, Timothy Washington wrote:

> I've deliberately proposed a small core, so that you can use only the pieces 
> you absolutely need. Additionally, I think it encourages a clean design, 
> forcing explicit interaction semantics between system components. If we 
> accept this premise, the only question then, is what mechanism we should use 
> to separate the core of stefon, from the rest of its plug-in components. Now, 
> I was looking into the nrepl protocol. I think it conceptually gives us the 
> separation we need, with the added bonus that a stefon service, and it's 
> plug-ins, could be in separate locations. But while I like the concept, I 
> think the host would need a way to i) declare the stefon service (nrepl 
> versioning?), ii) list / publish actions (??) iii) pass around binary data 
> (base64 encoding?). Also, I saw that there was a discussion around updating 
> the nrepl protocol (nRepl.Next), and don't know if that's been implemented. 

Only barely following along, but FYI: the nREPL.Next page you linked to is 
quite old, and described the state of affairs a couple of years ago.  One of 
the paths described therein was taken, and is represented in nREPL releases 
starting with 0.2.0.  There are no plans currently for changing the default 
nREPL transport's wire protocol.  

I've updated the wiki page to note this to avoid further confusion, thanks for 
mentioning it. :-)

- Chas

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

[Brian Craft]

On Friday, July 19, 2013 7:18:15 AM UTC-7, Daniel Dinnyes wrote:
>
>  You are trying to pick it up on the wrong end. Check this out:
>
> (-> "test-string-with-lots-of-dashes"
> (fn [x] (s/split x #"-"))
> (fn [y] (interleave y (range)))
> (fn [z] (s/join #"_" z))
> (fn [z] (s/join " * " ["I am serious" z "Not Kidding!!" z])))
>
> The above code is not valid, as the -> macro sees the function 
> declarations as lists, and tries to thread the argument through it. It is 
> quite intuitive though IMHO. 
>


It's valid if you make them function calls.

user=> 
(-> "test-string-with-lots-of-dashes"
((fn [x] (s/split x #"-")))
((fn [y] (interleave y (range
((fn [z] (s/join #"_" z)))
((fn [z] (s/join " * " ["I am serious" z "Not Kidding!!" z]
"I am serious * test_0_string_1_with_2_lots_3_of_4_dashes_5 * Not Kidding!! 
* test_0_string_1_with_2_lots_3_of_4_dashes_5"

Maybe I'm missing the point of this example.

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

[ANN] REST in Peace 0.1.0

[Sebastian Rojas]

A library for RESTFul applications built on top of Compojure, includes 
routing abstractions with reverse routing functionalities and validation 
helpers.

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

primitive array casts

[Brian Craft]

I'm unable to find any examples of primitive array casts, and the docs are 
not helpful. Can someone point me to examples or docs that explain 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 unsubscribe from 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: ns defaults

[Jozef Wagner]

On Friday, July 19, 2013 4:20:36 PM UTC+2, Stuart Sierra wrote:
>
> On Thursday, July 18, 2013 4:34:49 AM UTC-4, Jozef Wagner wrote:
>
> > Compiler loads and refers clojure.core namespace for each
> > new namespace. In my projects, I often have one or two
> > namespaces I use nearly in every other namespace. (e.g.
> > clojure.tools.logging or clojure.string). It would be
> > convenient if I could specify ns defaults somewhere and
> > those declarations would be used for every compiled
> > namespace.
>
>
> You can do this without hacking the compiler if you're
> willing to add one extra line to your source files.
>
> Just define a function that `require`s and `refer`s all the
> symbols you want, and call it at the top of each namespace.
> You'll break tools that expect to be able to infer namespace
> dependencies from the literal source (e.g. tools.namespace)
> but it will do what you want.
>
> -S
>

Yes, but this seems to work only in Clojure, not in ClojureScript.

JW
 

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

java interop: passing int[]

[Brian Craft]

For implementing a method with this signature

int getType(int[] inputTypes) 

How would I declare inputTypes in gen-class?

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

{{ANN} clj-xmemcached release 0.2.3

[dennis zhuang]

An opensource memcached client for clojure,it wraps xmemcached.

0.2.3 releases, main highlights:

1.Supports delete with CAS value in binary protocol


 ;;delete with CAS
(xm/delete "num" (:cas (gets "num")))

2.Supports lighweight distribution lock with try-lock macro:


(def counter (atom 0))
(future (try-lock "lock" 5 (do (Thread/sleep 3000)
   (swap! counter inc))
(println "else1")))
(future (try-lock "lock" 5 (do (Thread/sleep 3000)
   (swap! counter inc))
(println "else2")))
(future (try-lock "lock" 5 (do (Thread/sleep 3000)
   (swap! counter inc))
(println "else3")))

(Thread/sleep 4000)
(is (nil? (get "lock")))
(is (= 1 @counter))

3.Through macro:


(through uid (get-user-from-databse uid))

Equals to:


(if-let [rt (get uid)]
rt
(let [rt (get-user-from-database uid)]
(when rt
(add uid rt 0))
rt))

4.Upgrade xmemcached to 1.4.2

More tutorial please visit https://github.com/killme2008/clj-xmemcached

--

庄晓丹
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/groups/opt_out.

Re: [ANN] tools.namespace 0.2.4

[Ambrose Bonnaire-Sergeant]

Thanks for your hard work Stuart.

Ambrose


On Sat, Jul 20, 2013 at 4:37 AM, Stuart Sierra wrote:

> *tools.namespace:* utilities to search for, parse, move, and
> reload namespaces with awareness of their dependencies
>
> Release 0.2.4: bug fixes only
>
> README and source code:
> https://github.com/clojure/tools.namespace
>
> Leiningen dependency information:
>
> [org.clojure/tools.namespace "0.2.4"]
>
> Changes in this release:
>
>   * Fix TNS-10: Forbid circular dependency when a namespace
> depends on itself
>
>   * Fix TNS-9 and TNS-11: support other prefix-list forms
>
>   * Fix TNS-8: Do not modify files whose contents does not
> change in `move-ns`
>
> This is a clojure-contrib project:
> http://dev.clojure.org/display/community/Contributing
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Exporting Multiple Namespaces

[Jonathan Fischer Friberg]

Yes, there is https://github.com/ztellman/potemkin

Jonathan

On Fri, Jul 19, 2013 at 10:06 PM, JvJ  wrote:

> I'm creating a library with a lot of available functions in a lot of
> different namespaces, and I'd like many of them to be available to users of
> the library without having to specify a number of different import
> statements.
>
> Is there a way to have the core namespace 'export' the other namespaces
> without having to place all the important functions in one monolithic
> core.clj?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Interest in a Full Featured Clojure Blog Engine

[James Ashley]

>From the peanut gallery:

I think this basic idea sounds fabulous. I've been kicking clojure's tires, 
and I keep meaning to slap a blog engine together. But then I go into 
tailspin because I want to blog about the experience, but my blogs are down 
and I don't want to go through setting up WP yet again, and...yeah. It's 
been kind of a "This is a fairly interesting project to introduce yourself 
to the language, but is it *really* worth doing yourself?" thing for me.

For me, the answer (so far) has been "That looks fun, and I'd like to be a 
contributor, but I just don't have time to tackle it now...maybe next 
weekend."

So, anyway, before I disagree below, I'll add a basic +1. (For whatever my 
lurker n00b opinion might be worth).


On Friday, July 19, 2013 2:53:30 PM UTC-5, frye wrote:
>
> My spidey sense is that the proposed data types (posts, assets, tags, 
> comments too ?), will have to be handled differently. 
>
> What I plan to do though, is go through some basic workflow cases, and 
> work out the best data relationships. That's the point at which I think 
> common data types could be unified. Plus, a function, like export, could 
> also be a URL. So I wouldn't want to tie core resources to the concept of 
> Http URLs. Even though they may map neatly to stefon's actions. Thoughts ?
>

Isn't that basically the point to a URL?
Especially when you consider the basic REST principles? *Someone* will want 
a RESTful blog eventually. Even if that's "just" a plugin, keeping those 
ideas in mind from the beginning seems like a wise practice. I haven't 
worked on a project yet where anyone ever wished that we hadn't invested in 
that up front. Though it's been far more common that we didn't, so it's 
mostly been a matter of trying to deal with the pain of replicating it 
later.

I don't actually have a clue what you have in mind for stefon's actions. So 
maybe I'm actually agreeing with you.

I apologize if this isn't coherent...it's been a long, brutal day. I saw 
this thread this morning, and this is the first chance I've had to respond 
(after I'm totally exhausted).

Regards,
James



 Sent from my Android
> On Jul 19, 2013 3:26 PM, "Thorsten Wilms" > 
> wrote:
> >
> > On 07/19/2013 08:46 PM, Timothy Washington wrote:
> >>
> >> There would just be a core data model of posts, assets and tags, that
> >> would exists as definitions, and could be pulled into a runtime soup.
> >
> >
> > How about unifying everything that may be mapped to its own URL as 
> "resource"? Such a resource would have a unique name (or path/name 
> combination), created and modified timestamps, owner, permissions ...
> >
> > Such a data set would then be associated with an entity-type specific 
> data set to store what's special to a post or a comment or an image ...
> >
> >
> >
> > -- 
> > Thorsten Wilms
> >
> > thorwil's design for free software:
> > http://thorwil.wordpress.com/
> >
> > -- 
> > -- 
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clo...@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+u...@googlegroups.com 
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > --- You received this message because you are subscribed to the Google 
> Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@googlegroups.com .
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>  

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

Re: Importing another data_readers

[JvJ]

Thanks.  I'll make sure users know about it.  It's a game engine, so I'll 
mostly be using it for things like Box2D vector literals  (i.e. v#(1,2)), 
and floating-point numbers ( f#(1.4), so they don't have to say  (float 
1.4)).

On Friday, 19 July 2013 13:48:50 UTC-7, Stuart Sierra wrote:
>
> When Clojure starts it will search for files named data_readers.clj at the 
> root the Java classpath. Every library JAR can have its own 
> data_readers.clj and they will all be loaded and merged.
>
> Be careful with this: if there's a conflict in data reader bindings, 
> Clojure won't start. If your library provides a data reader tag that other 
> users may want to override in their applications, don't put it in the 
> data_readers.clj file in your library. On the other hand, if your library 
> uses data readers in its own sources, then it needs to include them in its 
> data_readers.clj file.
>
> -S
>
>
> On Friday, July 19, 2013 4:08:54 PM UTC-4, JvJ wrote:
>>
>> I'm not 100% on how the data_readers.clj file works.  It's just a map 
>> with no namespace that appears to get loaded by some kind of black magic.
>>
>> Is it possible to provide a library which includes its reader macros, so 
>> that the library user's project doesn't need to include their own 
>> data_readers.clj?
>>
>

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

[Shantanu Kumar]

Thanks for the release. Coincidentally, yesterday I wrote a command-line 
Kestrel client (a script) using clj-xmemcached 0.2.2, lein-exec and 
tools.cli - it works very well.

Shantanu

On Saturday, 20 July 2013 08:50:02 UTC+5:30, dennis wrote:
>
> An opensource memcached client for clojure,it wraps xmemcached.
>
> 0.2.3 releases, main highlights:
>
> 1.Supports delete with CAS value in binary protocol
>
>  ;;delete with CAS
> (xm/delete "num" (:cas (gets "num")))
>
> 2.Supports lighweight distribution lock with try-lock macro:
>
> (def counter (atom 0))
> (future (try-lock "lock" 5 (do (Thread/sleep 3000)
>(swap! counter inc))
> (println "else1")))
> (future (try-lock "lock" 5 (do (Thread/sleep 3000)
>(swap! counter inc))
> (println "else2")))
> (future (try-lock "lock" 5 (do (Thread/sleep 3000)
>(swap! counter inc))
> (println "else3")))
>
> (Thread/sleep 4000)
> (is (nil? (get "lock")))
> (is (= 1 @counter))
>
> 3.Through macro:
>
> (through uid (get-user-from-databse uid))
>
> Equals to:
>
> (if-let [rt (get uid)]
> rt
> (let [rt (get-user-from-database uid)]
> (when rt
> (add uid rt 0))
> rt))
>
> 4.Upgrade xmemcached to 1.4.2
>
> More tutorial please visit https://github.com/killme2008/clj-xmemcached
>
> --
>   
> 庄晓丹 
> Email:killm...@gmail.com  xzh...@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/groups/opt_out.

Re: Wrapping LevelDB with ring/compojure app

[Tarik Ansari]

Thanks you, this actually works great! Now I have an other question, are 
there any arguments against doing that with ring-jetty? Is there a 
possibility that Jetty isolate the requests and those lose context of the 
descriptor in-between? Or is it fine as long as it's not run as a servlet?
If so, is this a scenario where using something like 
alpeh/http-kit/netty/aloha makes more sense?

On Friday, July 19, 2013 9:49:09 AM UTC-4, Gareth Jones wrote:
>
> Instead of using the var #'web/app in run-jetty, use a function that takes 
> your main-db as an argument and returns the routes for your app. You can 
> use the compojure.core/routes to build your app routes rather than using a 
> global var. 
>
>
> On Fri, Jul 19, 2013 at 3:42 AM, Tarik Ansari 
> > wrote:
>
>> Hello Folks,
>>
>> I am a complete Clojure newbie and trying to achieve something pretty 
>> simple and looking for an idiomatic, if I can make it work at all, way to 
>> do it.
>>
>> My issue is I need to retain the LevelDB descriptor and share it between 
>> requests, LevelDB is already thread-safe.
>> For example:
>>
>> (defn -main
>>   "I don't do a whole lot ... yet."
>>   [& args]
>>
>>   (println "Opening LevelDB file in db/main")
>>   (with-open [main-db (db/open "db/main")]
>>
>> (println "Running server on port 3000")
>> (run-jetty #'web/app {:port 3000})))
>>
>> Now, how can I access that main-db descriptor in my requests handlers?
>> This, obviously won't work, as main-db is not defined in web/app:
>>
>> (GET "/test" []
>> (db/put main-db (.getBytes "testKey2") (.getBytes "testValue2"))
>> "Hello World")
>>
>>
>> PS: If it helps anyone for setup, I have made a Clojar for the LevelDB 
>> JNI Clojure wrapper based on Sedward's: 
>> https://clojars.org/org.clojars.aircart/leveldb-clj
>>
>> Thanks in advance for your insight/help!
>>
>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>

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