easier way to write not not?
Not that it's a big deal, but is there a standard library function for #(not (not %))? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: easier way to write not not?
On Wednesday, 17 July 2013 11:42:10 UTC+5:30, JvJ wrote: Not that it's a big deal, but is there a standard library function for #(not (not %))? Just say `boolean` maybe? Shantanu -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: easier way to write not not?
`boolean`. Agreed. On Tue, Jul 16, 2013 at 11:13 PM, Shantanu Kumar kumar.shant...@gmail.comwrote: On Wednesday, 17 July 2013 11:42:10 UTC+5:30, JvJ wrote: Not that it's a big deal, but is there a standard library function for #(not (not %))? Just say `boolean` maybe? Shantanu -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: easier way to write not not?
Have you tried the complement form? 17.07.2013, 15:12, "JvJ" kfjwhee...@gmail.com:Not that it's a big deal, but is there a standard library function for #(not (not %))? -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from 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.
Things get slow if hashmap has 1000 Elements
Hello everyone,
I have a ref, which is a hashmap of monsters (they key is a unique id, the
value is the monster) like this:
*(defrecord mob [name level hp-cur hp-max])
(def mobs (ref {}))
(defn addmob []
(dosync (alter mobs assoc (gen-id) (-mob test 1 2 3)))*
Now if I add 1000 monsters, like this:
*(repeatedly 1000 addmob)*
it will take a few minutes, use a lot of RAM and might even fail if its not
a 64 bit JRE (due to RAM limitations).
As it seems the problem isn't exactly clojure, its the fact that the result
is being shown in the REPL (which is a huge string).
If I modify my addmob function to return nil:
*(defn addmob []
(dosync (alter mobs assoc (gen-id) (-mob test 1 2 3))
nil)
*Then *(repeatedly 1000 addmob)* is really fast because it doesn't show the
whole result in the REPL.
*(Please note that the problem has nothing to do with the repeatedly
function. Even if I already have 1000 mobs in my hashmap and then only add
another one, it also takes forever to show the result in the REPL.)*
Does anyone know a elegant solution to my problem, besides writing
something like alter-silent that always returns nil instead of the whole
ref? Am I just using things the wrong way? Or could it have something to do
with Eclipse?
Thanks in advance!
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from 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: Things get slow if hashmap has 1000 Elements
This might help: http://clojuredocs.org/clojure_core/clojure.core/*print-length* -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: is it possible to join on lazy seqs?
Perhaps you could post a minimal example of the two datasets you're trying
to join ?
To do multiple types of joins (left, right, inner, natural cross) on
collections of maps/records, I use Sean Devlin's table-utils library.
There's no jar, but there's instructions on how to make a version without
dependencies other than Clojure in this stackoverflow
questionhttp://stackoverflow.com/questions/13009939/outer-join-in-clojure/13032032#13032032
.
On Tuesday, July 16, 2013 4:43:21 PM UTC+2, mond wrote:
Sorry if this is a RTFM style question ... this is what I have in terms of
types and was wondering if there is another form of join or another library
/ collection combination that can achieve the same relational join?
Thanks in advance,
Ray
check-delta-feeds.core= (def changed-records (map find-changed-records
(set/select #(= (:entity %) (entity-names :project)) query-parts)))
#'check-delta-feeds.core/changed-records
check-delta-feeds.core=check-delta-feeds.core=
check-delta-feeds.core= (def feed-entries (obtain-feed-entries
(fetch-atom-feed-until tgb-feed-url until-datetime)))
#'check-delta-feeds.core/feed-entries
check-delta-feeds.core= (type changed-records )
clojure.lang.LazySeq
check-delta-feeds.core= (type feed-entries)
clojure.lang.LazySeq
check-delta-feeds.core= (set/join changed-records feed-entries {:ID
:dh-uuid})
ClassCastException clojure.lang.LazySeq cannot be cast to java.util.Map
clojure.lang.RT.find (RT.java:733)
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from 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: Things get slow if hashmap has 1000 Elements
Awesome, thanks a lot! On Wednesday, July 17, 2013 11:19:06 AM UTC+2, puzzler wrote: This might help: http://clojuredocs.org/clojure_core/clojure.core/*print-length* -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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.
[EuroClojure 2013] Call for Presentations now open
Hi all, we’re excited to announce EuroClojure 2013 to be held in Berlin, Germany: “EuroClojure is the first 2-day, full-blown conference in Europe for the Clojure community. After an extremely successful 2012 edition in London we are replicating in Berlin this year! The conference will be held on Monday 14th and Tuesday 15th October in Central Berlin http://euroclojure.com/2013/venue/.” The Call for Presentations is now open, all the details and the form here: http://euroclojure.com/2013/call-for-presentations/http://euroclojure.com/2012/call-for-presentations/ Looking forward to it, for any info please do not hesitate to contact us: i...@euroclojure.com. Spread the word and follow us on Twitter: @EuroClojurehttps://twitter.com/EuroClojure Regards The EuroClojure Team -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: Things get slow if hashmap has 1000 Elements
One side node, *repeatedly* produces a lazy-seq. Since the REPL forces that
seq when it tries do print everything you get the desired results, but if
you were to
(def x (repeatedly 1000 addmod)
and then inspects mobs it would be empty, since no one forced the seq. If
you want to force side-effects (alter the ref), use
(dotimes [_ 1000] (addmob))
It has the added benetfit of returning nil, so nothing is printed.
HTH,
/thomas
On Wednesday, July 17, 2013 10:50:42 AM UTC+2, vis wrote:
Hello everyone,
I have a ref, which is a hashmap of monsters (they key is a unique id, the
value is the monster) like this:
*(defrecord mob [name level hp-cur hp-max])
(def mobs (ref {}))
(defn addmob []
(dosync (alter mobs assoc (gen-id) (-mob test 1 2 3)))*
Now if I add 1000 monsters, like this:
*(repeatedly 1000 addmob)*
it will take a few minutes, use a lot of RAM and might even fail if its
not a 64 bit JRE (due to RAM limitations).
As it seems the problem isn't exactly clojure, its the fact that the
result is being shown in the REPL (which is a huge string).
If I modify my addmob function to return nil:
*(defn addmob []
(dosync (alter mobs assoc (gen-id) (-mob test 1 2 3))
nil)
*Then *(repeatedly 1000 addmob)* is really fast because it doesn't show
the whole result in the REPL.
*(Please note that the problem has nothing to do with the repeatedly
function. Even if I already have 1000 mobs in my hashmap and then only add
another one, it also takes forever to show the result in the REPL.)*
Does anyone know a elegant solution to my problem, besides writing
something like alter-silent that always returns nil instead of the whole
ref? Am I just using things the wrong way? Or could it have something to do
with Eclipse?
Thanks in advance!
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: merge nested maps
Thank you for finding and posting this! Been wracking my brain trying to
figure out a good way to do a full map merge
On Thursday, April 25, 2013 5:26:53 PM UTC-4, Stuart Sierra wrote:
Here's a way to do it from the Pedestal demo source
codehttps://github.com/pedestal/demo/blob/17eeac7a5e50d31eb81901de465f3f1d863f2f01/hammock-cafe/src/hammock_cafe/config.clj#L37
:
(defn deep-merge
Recursively merges maps. If keys are not maps, the last value wins.
[ vals]
(if (every? map? vals)
(apply merge-with deep-merge vals)
(last vals)))
-S
On Thursday, April 25, 2013 4:41:33 PM UTC-4, Joachim De Beule wrote:
Hi list,
I was searching for an easy way to combined nested maps, e.g. as in
(combine {:foo {:bar baz}} {:foo {:x y}})
= {:foo {:bar baz, :x y}}
I would expect that there is some core map operation to do this, but
neither merge nor unify work as they simply return {:foo {:x y}}, and I
don't see anything else. Am I missing something?
Joachim.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: easier way to write not not?
user= (mapv #(not (not %)) [1 :a true false nil]) [true true true false false] user= (mapv boolean [1 :a true false nil]) [true true true false false] On Wed, Jul 17, 2013 at 3:45 AM, Kelker Ryan theinter...@yandex.com wrote: Have you tried the complement form? 17.07.2013, 15:12, JvJ kfjwhee...@gmail.com: Not that it's a big deal, but is there a standard library function for #(not (not %))? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: core.async: close! and control channels
It appears that you cannot call close! within a go block and so to signal the end of input to a channel you have to use another channel upon which the receiver can alt!. That's shouldn't be true. What problems did you run into with this? And yes, channels and go's are automatically GC'd when they can no longer be access by the system. So these channels/gos get GC'd as fast as they are created. (loop [] (let [c (chan)] (go (! c)) (recur))) Timothy -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: easier way to write not not?
Just for the record: I stumbled across the same question just a week ago. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: core.async: close! and control channels
True, but I'll mention the semantics of channels once again. Go blocks are attached to channels, and channels exist on their own as values. No where in this entire system is there some global list of channels or go blocks (except for in the executors, but let's not get into that right now). This means that entire chains of gos and channels can be reclaimed by the GC if neither end of the chain is anchored in a GC root. Timothy On Wed, Jul 17, 2013 at 8:17 AM, Laurent PETIT laurent.pe...@gmail.comwrote: 2013/7/17 Timothy Baldridge tbaldri...@gmail.com: It appears that you cannot call close! within a go block and so to signal the end of input to a channel you have to use another channel upon which the receiver can alt!. That's shouldn't be true. What problems did you run into with this? Silly suggestion : maybe the OP is trying to call close! on a channel which is unbuffered, after having put a value. I can imagine, then, that it is only when a consumer has taken the value out of the unbuffered channel, that the producer will be unblocked, and the call to close! will be executed. So maybe using a channel of size 1 may help make the symptom disappear ? And yes, channels and go's are automatically GC'd when they can no longer be access by the system. So these channels/gos get GC'd as fast as they are created. (loop [] (let [c (chan)] (go (! c)) (recur))) Timothy -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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. -- “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: core.async: close! and control channels
2013/7/17 Timothy Baldridge tbaldri...@gmail.com: It appears that you cannot call close! within a go block and so to signal the end of input to a channel you have to use another channel upon which the receiver can alt!. That's shouldn't be true. What problems did you run into with this? Silly suggestion : maybe the OP is trying to call close! on a channel which is unbuffered, after having put a value. I can imagine, then, that it is only when a consumer has taken the value out of the unbuffered channel, that the producer will be unblocked, and the call to close! will be executed. So maybe using a channel of size 1 may help make the symptom disappear ? And yes, channels and go's are automatically GC'd when they can no longer be access by the system. So these channels/gos get GC'd as fast as they are created. (loop [] (let [c (chan)] (go (! c)) (recur))) Timothy -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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
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 dinn...@gmail.com 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 clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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
Note the original discussion was from 2010. On Wed, Jul 17, 2013 at 11:49 AM, Alexander Yakushev unlo...@bytopia.orgwrote: 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 dinn...@gmail.com 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 clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: core.async: close! and control channels
The problem I am having is in the function at line 41 of https://github.com/nodename/async-plgd/blob/master/src/hoare/coroutines.clj. Any insight into this is appreciated. -A On Wed, Jul 17, 2013 at 7:23 AM, Timothy Baldridge tbaldri...@gmail.comwrote: True, but I'll mention the semantics of channels once again. Go blocks are attached to channels, and channels exist on their own as values. No where in this entire system is there some global list of channels or go blocks (except for in the executors, but let's not get into that right now). This means that entire chains of gos and channels can be reclaimed by the GC if neither end of the chain is anchored in a GC root. Timothy On Wed, Jul 17, 2013 at 8:17 AM, Laurent PETIT laurent.pe...@gmail.comwrote: 2013/7/17 Timothy Baldridge tbaldri...@gmail.com: It appears that you cannot call close! within a go block and so to signal the end of input to a channel you have to use another channel upon which the receiver can alt!. That's shouldn't be true. What problems did you run into with this? Silly suggestion : maybe the OP is trying to call close! on a channel which is unbuffered, after having put a value. I can imagine, then, that it is only when a consumer has taken the value out of the unbuffered channel, that the producer will be unblocked, and the call to close! will be executed. So maybe using a channel of size 1 may help make the symptom disappear ? And yes, channels and go's are automatically GC'd when they can no longer be access by the system. So these channels/gos get GC'd as fast as they are created. (loop [] (let [c (chan)] (go (! c)) (recur))) Timothy -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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. -- “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. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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
I'm sorry for jumping in then. Should have paid more attention to the dates. Nevertheless I wonder why while standing on such a solid ground, the Core team eventually gave in. I could see a use for cond-, but as- is basically the same macro that was suggested in topics like this, and was rejected by Rich and company. Have anything changed in Clojure since then, that arguments against as- are no longer valid? On Wednesday, July 17, 2013 7:55:37 PM UTC+3, Nelson Morris wrote: Note the original discussion was from 2010. On Wed, Jul 17, 2013 at 11:49 AM, Alexander Yakushev unl...@bytopia.orgjavascript: 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 dinn...@gmail.com 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.comjavascript: 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 javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you 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 javascript:. 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
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 unlo...@bytopia.orgwrote: 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 dinn...@gmail.com 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 clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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
In that case, shouldn't it be named let- instead of as-? On Wed, Jul 17, 2013 at 12:03 PM, David Nolen dnolen.li...@gmail.comwrote: 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 unlo...@bytopia.orgwrote: 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 dinn...@gmail.com 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 clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: core.async: close! and control channels
After a channel is closed, any gets (!) from the channel will return nil. I think some part of your code is taking that nil return value and trying to forward it on to a channel. That's what the error is about. Timothy On Wed, Jul 17, 2013 at 11:02 AM, Alan Shaw noden...@gmail.com wrote: The problem I am having is in the function at line 41 of https://github.com/nodename/async-plgd/blob/master/src/hoare/coroutines.clj. Any insight into this is appreciated. -A On Wed, Jul 17, 2013 at 7:23 AM, Timothy Baldridge tbaldri...@gmail.comwrote: True, but I'll mention the semantics of channels once again. Go blocks are attached to channels, and channels exist on their own as values. No where in this entire system is there some global list of channels or go blocks (except for in the executors, but let's not get into that right now). This means that entire chains of gos and channels can be reclaimed by the GC if neither end of the chain is anchored in a GC root. Timothy On Wed, Jul 17, 2013 at 8:17 AM, Laurent PETIT laurent.pe...@gmail.comwrote: 2013/7/17 Timothy Baldridge tbaldri...@gmail.com: It appears that you cannot call close! within a go block and so to signal the end of input to a channel you have to use another channel upon which the receiver can alt!. That's shouldn't be true. What problems did you run into with this? Silly suggestion : maybe the OP is trying to call close! on a channel which is unbuffered, after having put a value. I can imagine, then, that it is only when a consumer has taken the value out of the unbuffered channel, that the producer will be unblocked, and the call to close! will be executed. So maybe using a channel of size 1 may help make the symptom disappear ? And yes, channels and go's are automatically GC'd when they can no longer be access by the system. So these channels/gos get GC'd as fast as they are created. (loop [] (let [c (chan)] (go (! c)) (recur))) Timothy -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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. -- “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. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com.
Re: [ANN] simple-sheck - A QuickCheck inspired testing tool
On Jul 17, 2013, at 12:56 AM, Alex Baranosky alexander.barano...@gmail.com wrote: Hi Reid, I dig how nicely it integrates with clojure.test. Does simple-check implement some form of shrinking? It does. The README has an example of the output when a property fails (and the input is shrunk), but it's also easy to just write a failing property and see it shrink yourself. Overall I'm quite proud of how well shrinking has been working in simple-check. Reid -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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
Thank you for the explanation, it makes sense to me now. On Wednesday, July 17, 2013 8:03:41 PM UTC+3, 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 unl...@bytopia.orgwrote: 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 dinn...@gmail.com 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. On Wednesday, July 17, 2013 8:03:41 PM UTC+3, 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 unl...@bytopia.orgjavascript: 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 dinn...@gmail.com 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.comjavascript: 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 javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you 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 javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups
communicating quits to timeouts AND parent loop in core.async
Hi all, In a number of places where I'm trying core.async I have run across the pattern of having a loop inside a go block with some timeouts in the loop body. Contrived example: (go (while true (println Hello World!) (! (timeout 1)) (println I'm done sleeping, going to recur now...))) In situations like these I almost always want to be able to stop the loop and prematurely stop the timeouts. Using alt! we can easily handle the need of stopping the timeout. Stopping the overall loop is easy as well but I can't seem to do it without the use of an atom. Here are some macros I've come up with using a channel, an atom, and an additional go block: https://gist.github.com/bmabey/6023231 Is there a better way to do this that doesn't involve an atom? If we had a `closed?` fn for channels one could write: (let [stop (chan)] (go (while (not (closed? stop)) (println Hello World!) (alts! [(timeout 1) stop]) (println I'm done sleeping, going to recur now...))) stop) This seems ideal and a good use case for adding some sort of function to detect termination. Thoughts? Thanks, Ben -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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] Vertigo: fast, idiomatic C-style structs
How did this affect performance in your Go AI? On Tuesday, July 9, 2013 10:56:03 PM UTC-5, Zach Tellman wrote: Last year, I gave a talk at the Conj on my attempt to write an AI for the board game Go. Two things I discovered is that it was hard to get predictable performance, but even once I made sure I had all the right type hints, there was still a lot of room at the bottom for performance improvements. Towards the end [1], I mentioned a few ideas for improvements, one of which was simply using ByteBuffers rather than objects to host the data. This would remove all the levels of indirection, giving much better cache coherency, and also allow for fast unsynchronized mutability when the situation called for it. So, ten months and several supporting libraries [2] [3] later, here it is: https://github.com/ztellman/vertigo At a high level, this library is useful whenever your datatype has a fixed layout and is used more than once. Depending on your type, it will give you moderate to large memory savings, and if you're willing to forgo some of core library in favor of Vertigo's operators, you can get significant performance gains on batch operations. And, in the cases where performance doesn't matter, it will behave exactly like any other Clojure data structure. I want to point out that something like this would be more or less impossible in Java; reading from an offset in a ByteBuffer without the compile-time inference and validation provided by this library would be pointlessly risky. There's not a lot of low-level Clojure libraries, but there's an increasing amount of production usage where people are using Clojure for performance-sensitive work. I'm looking forward to seeing what people do with Vertigo and libraries like it. Zach [1] http://www.youtube.com/watch?feature=player_detailpagev=v5dYE0CMmHQ#t=1828s [2] https://github.com/ztellman/primitive-math [3] https://github.com/ztellman/byte-streams -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: merge nested maps
By the way, this is already in contrib:
http://clojuredocs.org/clojure_contrib/clojure.contrib.map-utils/deep-merge-with
On Wednesday, July 17, 2013 5:42:24 AM UTC-7, Chris Gill wrote:
Thank you for finding and posting this! Been wracking my brain trying to
figure out a good way to do a full map merge
On Thursday, April 25, 2013 5:26:53 PM UTC-4, Stuart Sierra wrote:
Here's a way to do it from the Pedestal demo source
codehttps://github.com/pedestal/demo/blob/17eeac7a5e50d31eb81901de465f3f1d863f2f01/hammock-cafe/src/hammock_cafe/config.clj#L37
:
(defn deep-merge
Recursively merges maps. If keys are not maps, the last value wins.
[ vals]
(if (every? map? vals)
(apply merge-with deep-merge vals)
(last vals)))
-S
On Thursday, April 25, 2013 4:41:33 PM UTC-4, Joachim De Beule wrote:
Hi list,
I was searching for an easy way to combined nested maps, e.g. as in
(combine {:foo {:bar baz}} {:foo {:x y}})
= {:foo {:bar baz, :x y}}
I would expect that there is some core map operation to do this, but
neither merge nor unify work as they simply return {:foo {:x y}}, and I
don't see anything else. Am I missing something?
Joachim.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: communicating quits to timeouts AND parent loop in core.async
Why not the following? (let [stop (chan)] (go (loop [] (println Hello World!) (let [[v c]] (alts! [(timeout 1) stop])] (if (= c stop) :done (do (println I'm done sleeping, going to recur now...) (recur))) On Wed, Jul 17, 2013 at 2:47 PM, Ben Mabey b...@benmabey.com wrote: Hi all, In a number of places where I'm trying core.async I have run across the pattern of having a loop inside a go block with some timeouts in the loop body. Contrived example: (go (while true (println Hello World!) (! (timeout 1)) (println I'm done sleeping, going to recur now...))) In situations like these I almost always want to be able to stop the loop and prematurely stop the timeouts. Using alt! we can easily handle the need of stopping the timeout. Stopping the overall loop is easy as well but I can't seem to do it without the use of an atom. Here are some macros I've come up with using a channel, an atom, and an additional go block: https://gist.github.com/**bmabey/6023231https://gist.github.com/bmabey/6023231 Is there a better way to do this that doesn't involve an atom? If we had a `closed?` fn for channels one could write: (let [stop (chan)] (go (while (not (closed? stop)) (println Hello World!) (alts! [(timeout 1) stop]) (println I'm done sleeping, going to recur now...))) stop) This seems ideal and a good use case for adding some sort of function to detect termination. Thoughts? Thanks, Ben -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com . For more options, visit https://groups.google.com/**groups/opt_outhttps://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.
Penumbra vs. LibGDX
Lately, I've been working on games with Clojure and LibGDX. However, many of the advantages of interactive development are not present, because LibGDX apps are built around Java development, and don't work well if you try to run multiple apps within a single program (i.e. from the REPL). Penumbra has this ability, but doesn't seem to be portable to other platforms (i.e. Android, HTML5), and doesn't have built-in Box2D support (although it can be added). If anyone has worked with one or both of these systems, can they suggest the pros and cons of using each. Furthermore, is it possible to use both? (i.e. have apps implemented in either penumbra or libgdx, but using the same opengl/box2d code in both) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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: communicating quits to timeouts AND parent loop in core.async
You can also use the alt! macro: (let [stop (chan)] (go (loop [] (println Hello World!) (alt! (timeout 1000) (do (println I'm done sleeping...) (recur)) stop :ok))) (!! (timeout 1)) (!! stop :now) (println We're done.)) On Wednesday, July 17, 2013 10:31:50 PM UTC+3, David Nolen wrote: Why not the following? (let [stop (chan)] (go (loop [] (println Hello World!) (let [[v c]] (alts! [(timeout 1) stop])] (if (= c stop) :done (do (println I'm done sleeping, going to recur now...) (recur))) On Wed, Jul 17, 2013 at 2:47 PM, Ben Mabey b...@benmabey.comjavascript: wrote: Hi all, In a number of places where I'm trying core.async I have run across the pattern of having a loop inside a go block with some timeouts in the loop body. Contrived example: (go (while true (println Hello World!) (! (timeout 1)) (println I'm done sleeping, going to recur now...))) In situations like these I almost always want to be able to stop the loop and prematurely stop the timeouts. Using alt! we can easily handle the need of stopping the timeout. Stopping the overall loop is easy as well but I can't seem to do it without the use of an atom. Here are some macros I've come up with using a channel, an atom, and an additional go block: https://gist.github.com/**bmabey/6023231https://gist.github.com/bmabey/6023231 Is there a better way to do this that doesn't involve an atom? If we had a `closed?` fn for channels one could write: (let [stop (chan)] (go (while (not (closed? stop)) (println Hello World!) (alts! [(timeout 1) stop]) (println I'm done sleeping, going to recur now...))) stop) This seems ideal and a good use case for adding some sort of function to detect termination. Thoughts? Thanks, Ben -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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 javascript: For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you 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 javascript:. For more options, visit https://groups.google.com/**groups/opt_outhttps://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: communicating quits to timeouts AND parent loop in core.async
This approach works for the simple case but gets cumbersome it a more realistic loop with several timeouts and conditional logic. For example, here is a reduced use case which I am using my go-loop macro I posted earlier: (let [heads? (fn [] ( (rand) 0.5)) heads-time-out 1 loop-time-out 100] (go-loop [stop-timeout] (if (heads?) (do (println HEADS! I'm doing some stuff...) (sleep heads-time-out stop-timeout) (println doing some more stuff)) (sleep loop-time-out stop-timeout The problem, as I see it, is that with your approach the channel from each alts! needs to propagated to the end of the loop. So, I would either need to restructure the code above to do that or use an atom and have the go-loop/sleep macros take care of it for me. -Ben On 7/17/13 1:31 PM, David Nolen wrote: Why not the following? (let [stop (chan)] (go (loop [] (println Hello World!) (let [[v c]] (alts! [(timeout 1) stop])] (if (= c stop) :done (do (println I'm done sleeping, going to recur now...) (recur))) On Wed, Jul 17, 2013 at 2:47 PM, Ben Mabey b...@benmabey.com mailto:b...@benmabey.com wrote: Hi all, In a number of places where I'm trying core.async I have run across the pattern of having a loop inside a go block with some timeouts in the loop body. Contrived example: (go (while true (println Hello World!) (! (timeout 1)) (println I'm done sleeping, going to recur now...))) In situations like these I almost always want to be able to stop the loop and prematurely stop the timeouts. Using alt! we can easily handle the need of stopping the timeout. Stopping the overall loop is easy as well but I can't seem to do it without the use of an atom. Here are some macros I've come up with using a channel, an atom, and an additional go block: https://gist.github.com/bmabey/6023231 Is there a better way to do this that doesn't involve an atom? If we had a `closed?` fn for channels one could write: (let [stop (chan)] (go (while (not (closed? stop)) (println Hello World!) (alts! [(timeout 1) stop]) (println I'm done sleeping, going to recur now...))) stop) This seems ideal and a good use case for adding some sort of function to detect termination. Thoughts? Thanks, Ben -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com mailto:clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com mailto:clojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com mailto:clojure%2bunsubscr...@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: communicating quits to timeouts AND parent loop in core.async
Ah, very nice. I had not seen the alt! macro in use but upon close look it is just what I need when using the :default option. My go-loop macro now only requires the single stop channel: (defmacro go-loop [bindings body] (let [stop (first bindings)] `(let [~stop (chan)] (go (while (alt! ~stop false :default :keep-going) ~@body)) ~stop))) Thanks for the tip! On 7/17/13 2:26 PM, Jonas wrote: You can also use the alt! macro: (let [stop (chan)] (go (loop [] (println Hello World!) (alt! (timeout 1000) (do (println I'm done sleeping...) (recur)) stop :ok))) (!! (timeout 1)) (!! stop :now) (println We're done.)) On Wednesday, July 17, 2013 10:31:50 PM UTC+3, David Nolen wrote: Why not the following? (let [stop (chan)] (go (loop [] (println Hello World!) (let [[v c]] (alts! [(timeout 1) stop])] (if (= c stop) :done (do (println I'm done sleeping, going to recur now...) (recur))) On Wed, Jul 17, 2013 at 2:47 PM, Ben Mabey b...@benmabey.com javascript: wrote: Hi all, In a number of places where I'm trying core.async I have run across the pattern of having a loop inside a go block with some timeouts in the loop body. Contrived example: (go (while true (println Hello World!) (! (timeout 1)) (println I'm done sleeping, going to recur now...))) In situations like these I almost always want to be able to stop the loop and prematurely stop the timeouts. Using alt! we can easily handle the need of stopping the timeout. Stopping the overall loop is easy as well but I can't seem to do it without the use of an atom. Here are some macros I've come up with using a channel, an atom, and an additional go block: https://gist.github.com/bmabey/6023231 https://gist.github.com/bmabey/6023231 Is there a better way to do this that doesn't involve an atom? If we had a `closed?` fn for channels one could write: (let [stop (chan)] (go (while (not (closed? stop)) (println Hello World!) (alts! [(timeout 1) stop]) (println I'm done sleeping, going to recur now...))) stop) This seems ideal and a good use case for adding some sort of function to detect termination. Thoughts? Thanks, Ben -- -- 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 javascript: 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 javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en http://groups.google.com/group/clojure?hl=en --- You received this message because you 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 javascript:. For more options, visit https://groups.google.com/groups/opt_out 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
ANN: Fafnir, a library for inserting complex data structures into Datomic
Over the past few months I've been working a lot with Datomic and have often wanted a purely functional way to insert complex data structures (deep trees, graphs, etc.) into a database. I haven't been able to find a good library to help me with this, so I wrote my own: Introducing Fafnir. It's available on clojars and the source is available on github: https://github.com/halgari/fafnir For some trivial examples of how it works, the tests may be a bit instructive: https://github.com/halgari/fafnir/blob/master/test/fafnir/core_test.clj Hopefully this will be of use to someone besides myself. Timothy Baldridge -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Performance Patterns
- really helpful links - accepting performance as more relevant, would IMHO strengthen Clojure So your wishes would be: - Systematically organized samples - Comments on causation - Using libraries to increase quality Thanks for your help, Marc -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Performance Patterns
Frantisek, your timings macro is really helpful and you already have many interesting examples in the code. So I combine yours, mine and Alex recommendations as: - Programmatic creation of tests/docs to adapt to current Clojure versions - Systematically organized/grouped/sorted samples - Comments on causation - Using benchmarking libraries to increase quality - Nice, compact, tabular presentation with source, ratio, percentage etc. - My: Prioritize over all cases according to frequency * impact - My: Short description of the example Hope to have time to contribute to such a list, may be in the clojure wiki. Marc -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Performance Patterns
I have a variant of the timings macro that I used to profile some numeric
code recently. You sprinkle it in your code, and it aggregates timings
during a run by keywords of your choice.:
(def ^:dynamic *times* nil)
(defmacro timek
Evaluates expr and prints the time it took. Returns the value of
expr.
{:added 1.0}
[k expr]
(let [plus (fn [val val2] (if val (+ val val2) val2))]
`(let [start# (. System (nanoTime))
ret# ~expr
t# (/ (double (- (. System (nanoTime)) start#)) 100.0)]
(swap! *times* update-in [~k] ~plus t#)
ret#)))
(defmacro with-timek
[ body]
`(binding [*times* (atom {})]
~@body
(clojure.pprint/pprint @*times*)))
On Wednesday, July 17, 2013 6:03:50 PM UTC-4, Marc Dzaebel wrote:
Frantisek,
your timings macro is really helpful and you already have many interesting
examples in the code. So I combine yours, mine and Alex recommendations as:
- Programmatic creation of tests/docs to adapt to current Clojure versions
- Systematically organized/grouped/sorted samples
- Comments on causation
- Using benchmarking libraries to increase quality
- Nice, compact, tabular presentation with source, ratio, percentage etc.
- My: Prioritize over all cases according to frequency * impact
- My: Short description of the example
Hope to have time to contribute to such a list, may be in the clojure wiki.
Marc
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from 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: core.async: close! and control channels
Ah, that's put me on the right track. Thanks Timothy! -A On Wed, Jul 17, 2013 at 10:16 AM, Timothy Baldridge tbaldri...@gmail.comwrote: After a channel is closed, any gets (!) from the channel will return nil. I think some part of your code is taking that nil return value and trying to forward it on to a channel. That's what the error is about. Timothy On Wed, Jul 17, 2013 at 11:02 AM, Alan Shaw noden...@gmail.com wrote: The problem I am having is in the function at line 41 of https://github.com/nodename/async-plgd/blob/master/src/hoare/coroutines.clj. Any insight into this is appreciated. -A On Wed, Jul 17, 2013 at 7:23 AM, Timothy Baldridge tbaldri...@gmail.comwrote: True, but I'll mention the semantics of channels once again. Go blocks are attached to channels, and channels exist on their own as values. No where in this entire system is there some global list of channels or go blocks (except for in the executors, but let's not get into that right now). This means that entire chains of gos and channels can be reclaimed by the GC if neither end of the chain is anchored in a GC root. Timothy On Wed, Jul 17, 2013 at 8:17 AM, Laurent PETIT laurent.pe...@gmail.comwrote: 2013/7/17 Timothy Baldridge tbaldri...@gmail.com: It appears that you cannot call close! within a go block and so to signal the end of input to a channel you have to use another channel upon which the receiver can alt!. That's shouldn't be true. What problems did you run into with this? Silly suggestion : maybe the OP is trying to call close! on a channel which is unbuffered, after having put a value. I can imagine, then, that it is only when a consumer has taken the value out of the unbuffered channel, that the producer will be unblocked, and the call to close! will be executed. So maybe using a channel of size 1 may help make the symptom disappear ? And yes, channels and go's are automatically GC'd when they can no longer be access by the system. So these channels/gos get GC'd as fast as they are created. (loop [] (let [c (chan)] (go (! c)) (recur))) Timothy -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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. -- “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. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google
Re: Penumbra vs. LibGDX
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.
Re: Socket.IO and Clojure?
Hi Sean, We are in process for going with a similar solution on clojure. Lets keep sharing notes. We were on heroku till last week. Websockets wont work on heroku. Lack of sticky session caused other issues. So we moved to elabstic beanstalk. However elastic beanstalk doesn't support jetty and I do not like tomcat. Plus on elastic beanstalk whenever you push code they have a down time upto 5 minutes. So over the past 2 days, we moved things to chef on ec2 which I am really happy with. Now we have a system as easy to use as heroku, with much more control. I am mentioning these because you or others might go through the same steps. Coming to your main point about Socket.IO. We spent around a week exploring Socket.IO. It was super easy to hack up a demo, however we ended up leaving it for couple of reasons: 1. Though the community looks very active in terms of forks etc, the development on Socket.IO is completely stopped. The dev team is focussed on engine.IO and they are very opaque. When you post on socket.io google group, posts do not have get approved. If you propose to help, you do not get any response. 2. The library has lot of features - like rooms etc. However they are not built to scale. I looked at the code and was very disappointed. User-Room mapping, Room-User mapping were stored in memory which will make it not scale beyond a point. Bad coding (e.g. using lists traversal where hash maps should be used) is very common in nodejs community and I am very wary of developing on that platform. 3. There was a memory leak in Socket.IO which would cause memory to increase linearly with usage. Given that most projects using nodejs dont move beyond prototypes these kind of issues do not get highlighted. I used to manage the mobile server at LinkedIn and we had to deal with a lot of memory leaks with node.js. 4. Javascript So finally, if you really have to use Socket.IO, I would recommend using https://github.com/einaros/ws for just websocket and built everything else yourselves. I am not a big fan of keeping two different setups at the stage of our product. We are fine with long-poll for now. So we will start there and eventually get to web sockets. We are considering http://http-kit.org/ for that. For communication between message generators and open client sockets we are exploring some pub sub solution. Hope this helps. Thanks Anand 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: Socket.IO and Clojure?
Just to clarify, we don't _want_ to use Socket.IO on Node.js but combined with the client-side library it has a lot of benefits (multiple transports, automatic fallback, good cross-browser support, namespaces and rooms match our problem domain). The server component is sufficiently complex that we don't want to replicate all of that functionality ourselves. We don't need huge scalability (at least, not in foreseeable future) so the in-memory aspect of Node.js's implementation isn't really a concern if we have to fallback on it and expose our services via REST to it. We'd rather have the whole server side on the JVM however. We can't use direct WebSockets because browser support is not good enough (and won't be for our target market for a long time I suspect). That's why we are looking at netty-socketio since it seems to support the Socket.IO client out of the box and is reasonably easy to use from Clojure. The reasons stated above are also why we can't just use http-kit (which was my first thought) - we need more machinery than just WebSockets. I had found this by Chris Granger - https://github.com/ibdknox/clj-socketio - but it's outdated and when I reached out to him, he confirmed the first point above - that the server side of Socket.IO is too complex to warrant trying to replicate ourselves (and that Socket.IO had evolved sufficiently that his project wouldn't be a useful starting point either). Sean On Wed, Jul 17, 2013 at 4:37 PM, Anand Prakash anand.prak...@gmail.com wrote: Hi Sean, We are in process for going with a similar solution on clojure. Lets keep sharing notes. We were on heroku till last week. Websockets wont work on heroku. Lack of sticky session caused other issues. So we moved to elabstic beanstalk. However elastic beanstalk doesn't support jetty and I do not like tomcat. Plus on elastic beanstalk whenever you push code they have a down time upto 5 minutes. So over the past 2 days, we moved things to chef on ec2 which I am really happy with. Now we have a system as easy to use as heroku, with much more control. I am mentioning these because you or others might go through the same steps. Coming to your main point about Socket.IO. We spent around a week exploring Socket.IO. It was super easy to hack up a demo, however we ended up leaving it for couple of reasons: 1. Though the community looks very active in terms of forks etc, the development on Socket.IO is completely stopped. The dev team is focussed on engine.IO and they are very opaque. When you post on socket.io google group, posts do not have get approved. If you propose to help, you do not get any response. 2. The library has lot of features - like rooms etc. However they are not built to scale. I looked at the code and was very disappointed. User-Room mapping, Room-User mapping were stored in memory which will make it not scale beyond a point. Bad coding (e.g. using lists traversal where hash maps should be used) is very common in nodejs community and I am very wary of developing on that platform. 3. There was a memory leak in Socket.IO which would cause memory to increase linearly with usage. Given that most projects using nodejs dont move beyond prototypes these kind of issues do not get highlighted. I used to manage the mobile server at LinkedIn and we had to deal with a lot of memory leaks with node.js. 4. Javascript So finally, if you really have to use Socket.IO, I would recommend using https://github.com/einaros/ws for just websocket and built everything else yourselves. I am not a big fan of keeping two different setups at the stage of our product. We are fine with long-poll for now. So we will start there and eventually get to web sockets. We are considering http://http-kit.org/ for that. For communication between message generators and open client sockets we are exploring some pub sub solution. Hope this helps. Thanks Anand 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
Re: Penumbra vs. LibGDX
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.
Re: [ANN] Vertigo: fast, idiomatic C-style structs
I actually haven't applied it yet. I'll post results once I have. On Wed, Jul 17, 2013 at 11:49 AM, Daniel doubleagen...@gmail.com wrote: How did this affect performance in your Go AI? On Tuesday, July 9, 2013 10:56:03 PM UTC-5, Zach Tellman wrote: Last year, I gave a talk at the Conj on my attempt to write an AI for the board game Go. Two things I discovered is that it was hard to get predictable performance, but even once I made sure I had all the right type hints, there was still a lot of room at the bottom for performance improvements. Towards the end [1], I mentioned a few ideas for improvements, one of which was simply using ByteBuffers rather than objects to host the data. This would remove all the levels of indirection, giving much better cache coherency, and also allow for fast unsynchronized mutability when the situation called for it. So, ten months and several supporting libraries [2] [3] later, here it is: https://github.com/**ztellman/vertigohttps://github.com/ztellman/vertigo At a high level, this library is useful whenever your datatype has a fixed layout and is used more than once. Depending on your type, it will give you moderate to large memory savings, and if you're willing to forgo some of core library in favor of Vertigo's operators, you can get significant performance gains on batch operations. And, in the cases where performance doesn't matter, it will behave exactly like any other Clojure data structure. I want to point out that something like this would be more or less impossible in Java; reading from an offset in a ByteBuffer without the compile-time inference and validation provided by this library would be pointlessly risky. There's not a lot of low-level Clojure libraries, but there's an increasing amount of production usage where people are using Clojure for performance-sensitive work. I'm looking forward to seeing what people do with Vertigo and libraries like it. Zach [1] http://www.youtube.com/**watch?feature=player_** detailpagev=v5dYE0CMmHQ#t=**1828shttp://www.youtube.com/watch?feature=player_detailpagev=v5dYE0CMmHQ#t=1828s [2] https://github.com/ztellman/**primitive-mathhttps://github.com/ztellman/primitive-math [3] https://github.com/**ztellman/byte-streamshttps://github.com/ztellman/byte-streams -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/BayfuaqMzvs/unsubscribe. To unsubscribe from this group and all its topics, 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.
How do I setup a Clojurescript REPL with emacs?
I'm trying to setup an environment for Clojurescript. The problem I'm having is not knowing how to set it up so that I can connect to a Clojurescript Browser REPL from emacs, so I can evaluate forms right from the editor and have it show up in the browser. Things I've tried: I tried using Cemerick's piggieback and piggybacking on nREPL. I don't really know how to configure it from the documentation. I was able to get it to work after figuring out I had to make an index.html file in the root of the project folder. Except the server doesn't serve my assets. I tried setting up inferior-lisp with the bash script from the Clojurescript wiki. However, whenever I try to run the inferior-lisp-program I'm getting Wrong type argument: stringp, nil. Here's my ideal workflow: I have a project folder/resources/public folder that has my assets and html files. I can start a web server that serves those files somehow, either by ring or using python's simple http server. I'd be able to connect to a REPL from emacs and evaluate forms into it. Thanks in advance. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from 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 do I setup a Clojurescript REPL with emacs?
I could be wrong but, I think you can use the cljs-build plugin for lein and use the repl-listen command to start a REPL server. Can you not use M-x nrepl to connect? https://github.com/emezeske/lein-cljsbuild/blob/0.3.2/doc/REPL.md#repl-listen 18.07.2013, 13:04, "Chris Bui" hesbornaliarhelldieal...@gmail.com:I'm trying to setup an environment for Clojurescript. The problem I'm having is not knowing how to set it up so that I can connect to a Clojurescript Browser REPL from emacs, so I can evaluate forms right from the editor and have it show up in the browser.Things I've tried:I tried using Cemerick's piggieback and piggybacking on nREPL. I don't really know how to configure it from the documentation. I was able to get it to work after figuring out I had to make an index.html file in the root of the project folder. Except the server doesn't serve my assets.I tried setting up inferior-lisp with the bash script from the Clojurescript wiki. However, whenever I try to run the inferior-lisp-program I'm getting "Wrong type argument: stringp, nil".Here's my ideal workflow:I have a project folder/resources/public folder that has my assets and html files. I can start a web server that serves those files somehow, either by ring or using python's simple http server. I'd be able to connect to a REPL from emacs and evaluate forms into it.Thanks in advance. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email toclojure+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from 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.
