Re: [ANN] getclojure.org

[Timothy Baldridge]

This is awesome! I remember you mentioning this project last year at the
Madison Clojure Meetup, it's cool to see it in action.

This would make a pretty cool test framework for a new Clojure
implementation.

Timothy


On Thu, May 16, 2013 at 9:41 PM, Devin Walters  wrote:

> There are some tweaks required on the analyzer/filter/tokenizer to allow
> certain queries. I wish Michael Klishin of ClojureWerkz fame was here to
> take a peek and offer his elasticsearch advice. ;)
>
> --
> {:∂evin :√valters}
>
> On Thursday, May 16, 2013 at 10:39 PM, atkaaz wrote:
>
> nevermind :) it acts the same as ->> even when -\>\>
> so I don't know what I was talking about :D
>
>
> On Fri, May 17, 2013 at 6:37 AM, atkaaz  wrote:
>
> like 
> http://getclojure.org/search?q=-\%3E\%3E&num=0
>
>
> On Fri, May 17, 2013 at 6:36 AM, Ramesh  wrote:
>
> Looks like "->>" is not supported. I quoted it!
>
> http://getclojure.org/search?q=%22-%3E%22&num=0
>
> -ramesh
>
>
> On Thu, May 16, 2013 at 6:12 PM, Devin Walters  wrote:
>
>  Hey All,
>
> I put this ( http://getclojure.org ) together and wanted to share it with
> all of you. It's a nifty way to search for example usage of clojure. It's
> far less curated than ClojureDocs, so you may pick up some interesting
> ideas by simply browsing.
>
> It supports boolean queries like: "comp AND juxt" and will let you search
> for "->>" (but you must quote it).
>
> If you're interested in contributing: https://github.com/devn/getclojure is
> the place to do it.
>
> Thanks,
> --
> {:∂evin :√valters}
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>
>
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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

Re: Why the need for an explicit new operator in Clojure?

[Timothy Baldridge]

>>how do you distinguish between accessing the class itself and creating a
new >>instance of it?

(Foo. 42)

vs

(instance? Foo 42)

Is that what you mean?

Timothy

On Thu, May 16, 2013 at 11:43 PM, Meikel Brandmeyer (kotarak)
wrote:

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



-- 
“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: Time complexity of operations on collections

[Timothy Baldridge]

A few corrections:

Lists are single linked lists, so nth on them (as well as last) is O(n).
Get on lists is unsupported.

Cons on a vector is O(1) since cons converts things to seqs (O(1)) before
constructing the cons.

Count on everything but Cons and LazySeq is O(1). For those two it's O(n)
until it hits something in the list that implements Counted (normally
PersistentList), then it's O(1) from there on. You might want to list
Cons/LazySeq separate from PersistentList for this reason.

So, cons on a String. That's a interesting question. Cons on anything is
O(1). For a string it's the cost of creating a StringSeq on the Java
String, then creating a Cons cell who's next pointer references the
StringSeq. So that's O(1). But you're now left with a seq, not a string. If
you're looking for something like this (str "c" "bar") then yes, that is
O(n).

Timothy


On Wed, May 22, 2013 at 8:05 AM, John Jacobsen wrote:

> I'm studying for an interview and thought it might be nice to know the
> time complexity of primitive operations on collections in Clojure.  A quick
> googling didn't turn up a definitive resource.  I would be happy to put one
> together.  What I had in mind was something like:
>
> Collections: strings, sets, maps, Java arrays, lists, vectors
> Operations: peek, pop, conj, cons, assoc/dissoc, get, nth, count
>
> What I have in mind is to fill out this table with the appropriate average
> big-O (my *guesses* from googling/experimenting/thinking are entered, and
> may be completely wrong!; sorry for any formatting problems due to varying
> type styles, perhaps I should have used s-expressions :-) - should be OK
> with fixed width font):
>
> Collection   getnth   cons  conj  assoc   pop  peek  count
> List "1"?   "1"?   1 1  X  11 1
> Vector   "1""1"?   n 1 "1"?11 1
> Set  "1"X "1""1"X  XX 1?
> Map  "1"X  1 "1"?  "1"?XX 1?
> String1 1  n X  X  XX 1
> Java Array1 1  n X  X  XX 1
>
> Where O("1") is really O(log_{32}(n)), "effectively constant time" as
> opposed to "true" O(1).  X obviously means you can't do the operation on
> that type.  Some operations involve casting e.g. a string to a seq; I
> assume O(n) in that case (?).
>
> (It's probably obvious to everyone else, but it's cool that there are so
> few 'n's in the table.)
>
> Any corrections, operations to add, data structures to add?  I imagine
> between all the readers of the list, correcting this table will be trivial.
>  I am happy to post the resulting table on my blog or anywhere else.
>
> Thanks!
> John
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: Time complexity of operations on collections

[Timothy Baldridge]

You might also want to switch "cons" to "conj". This is a super ugly part
of the Java api that no one really ever sees. PersistentVector.cons is
actually called by clojure.core/conj. clojure.core/cons is something else
completely. When talking about how the java code performs it might be best
to specify which one you mean.

Yes it's confusing, I'm sure there is a historical reason for it.

Timothy


On Wed, May 22, 2013 at 8:24 AM, John Jacobsen wrote:

> I should probably also have added sorted-map to the table, though the
> complexity for each operation is less clear to me.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: Time complexity of operations on collections

[Timothy Baldridge]

No, what I'm saying is that in each persistent collection there is a method
called "cons":

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/PersistentVector.java#L167

However, this is the function called by clojure.core/conj:

https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L75
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L562

Compare this to what clojure.core/cons calls:
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L22
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L565

Basically, clojure.core/cons always converts the collection to a seq, then
creates a Cons cell. Conj dispatches to coll.cons and runs whatever code
the collection considers best.

Timothy


On Wed, May 22, 2013 at 10:00 AM, John Jacobsen wrote:

> I am indeed confused.  I have both cons and conj operations in my table.
>  Are you saying (conj coll item) and (cons item coll) are implemented the
> same way under the hood?  That wasn't my understanding.  Can you clarify?
>
>
> On Wednesday, May 22, 2013 10:05:22 AM UTC-5, tbc++ wrote:
>
>> You might also want to switch "cons" to "conj". This is a super ugly part
>> of the Java api that no one really ever sees. PersistentVector.cons is
>> actually called by clojure.core/conj. clojure.core/cons is something else
>> completely. When talking about how the java code performs it might be best
>> to specify which one you mean.
>>
>> Yes it's confusing, I'm sure there is a historical reason for it.
>>
>> Timothy
>>
>>
>> On Wed, May 22, 2013 at 8:24 AM, John Jacobsen wrote:
>>
>>> I should probably also have added sorted-map to the table, though the
>>> complexity for each operation is less clear to me.
>>>
>>> --
>>> --
>>> 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
>>> .
>>>
>>>
>>>
>>
>>
>>
>> --
>> “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.
>
>
>



-- 
“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: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Timothy Baldridge]

I did a fair amount of programming in C# before switching to Clojure. I
noticed an interesting fact: the more lazy (as in using lazy-seqs) and
functional my code became, the more erratic the was the flow of execution.
It's my personal opinion, that as these features are used more and more in
a program, the harder it would be to get any sort of useful information out
of a debugger.

For instance, look at the implementation of for, map or Clojure's reducers.
I'd really hate to step through that code with a debugger.

While sometimes I feel a debugger would be nice, I think they are much more
useful in imperative languages than they are in functional languages like
Clojure.

Timothy Baldridge


On Tue, May 28, 2013 at 12:05 PM, Warren Lynn  wrote:

>
> May I suggest that as useful as your strategies are, they cannot replace a
> debugger? Let's be clear about our logic before claiming "it is not much
> needed". Maybe YOU really don't need it, but that is different from
> claiming it is not needed.
>
>
> A debugger as good as it is cannot replace the 4 first strategies.
>>
>> Luc P.
>>
>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
“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: [ANN] lein-pedantic is now deprecated

[Timothy Baldridge]

+1 for both features, it really helps for major version upgrades on large
projects.


On Wed, May 29, 2013 at 8:35 PM, Brian Tatnall  wrote:

> +1 Both of those features extremely helpful when adding new dependencies
> to any sizable project.
>
>
> On Wed, May 29, 2013 at 8:31 PM, Dave Kincaid wrote:
>
>> I am definitely interested in that. I've been using lein-pedantic all the
>> time. It's helped immensely.
>>
>>
>> On Wednesday, May 29, 2013 8:25:22 PM UTC-5, Nelson Morris wrote:
>>>
>>> Good news everybody! As of leiningen 2.2.0 using `lein deps :tree` will
>>> perform version checks and version range detection. Therefore, I have
>>> deprecated lein-pedantic.  I appreciate all of the users of the plugin that
>>> found it useful.
>>>
>>> I believe there are two pieces of functionality that do not currently
>>> have a replacement:
>>> 1) ability to fail the task when a "bad" dependency resolution happens
>>> 2) exact instructions of what to place in project.clj to make things work
>>>
>>> If you are interested in these, please let me know here, and I'll see
>>> about adding them in a future leiningen release.
>>>
>>> -
>>> Nelson Morris
>>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from 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: What is the status of Clojure on LLVM or C?

[Timothy Baldridge]

No, you're not missing something. In the past I've turned down the idea of
using RPython due to the lack of threading support. But in the past year
major, major headway has been made (as you mentioned) so perhaps RPython
isn't as crazy of an idea after all.

As far as a GC goes, yes, RPython can use one of many JITs, with a
simple command-line switch, the RPython translator can create binaries that
use reference counting, Boehm GCs or a custom mark-and-sweep generational
(compacting?) GC. The only downside is that IIRC the more complex GCs are
not yet thread-safe. But once again, major work is being done there.


Timothy


On Thu, May 30, 2013 at 4:51 AM, Dax Fohl  wrote:

> I've got no idea about RPython itself, but the PyPy toolchain takes an
> interpreter for any language specified in RPython, and generates a native
> interpreter for that language, complete with JIT, garbage collection, etc.
>  (Here's an example
> http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html
> ).
>
> Given there's an RPython interpreter for Python (aka PyPy), which
> dynamically generates the JIT, GC, etc, it seems logical that one could
> write an RPython interpreter for Clojure in the same way and get all the
> benefits of their toolchain.  Apparently they've got STM working there too.
>  And my understanding is that their generated tracing JIT is awesome for
> things marked as immutable (I forget where I read that), which would have
> insane performance consequences for Clojure.
>
> On Thursday, May 30, 2013 6:11:38 PM UTC+8, Michael Klishin wrote:
>>
>> 2013/5/30 Dax Fohl 
>>
>> Am I missing something?  What are the downsides of this approach?
>>
>>
>> is RPython garbage collected? Key ideas in Clojure pretty much assume
>> memory management is not something you
>> have to worry about.
>>
>> What about concurrency primitives? Clojure builds its reference types on
>> top of JDK/.NET ones (and mimics them
>> in ClojureScript).
>> --
>> MK
>>
>> http://github.com/**michaelklishin 
>> http://twitter.com/**michaelklishin 
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
“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: What is the status of Clojure on LLVM or C?

[Timothy Baldridge]

There are two things I see that reduce the viability of ref-count GCs with
Clojure:

a) Clojure is insanely alloc heavy. Look at the source of the data
structures, merging two hash-maps (for instance) requires about 2-3
allocations per assoc, per kv in the merged map:

(merge map1 map2)
allocs = ~((tree-depth of map1) * (count map2)

b) Every time you transverse a persistent structure's tree you'll need to
increment and decrement the refcounts. Consider multi-core, now the
refcounts have to be thread safe (atomic inc & dec). So if you have two
cores reading (not just writing) from the same hash-map, they'll be
fighting over the cache lines that the refcount is stored in, and that'll
kill performance.

Timothy


On Thu, May 30, 2013 at 8:47 AM, Gary Trakhman wrote:

> At first glance, those issues seem like they could be mitigated, so I
> think I see room here for some real-time ref-counted clojure.  I imagine
> it'd still have a lot of allocations so it wouldn't be that great for
> low-memory systems.
>
>
> On Thu, May 30, 2013 at 9:44 AM, Jean Niklas L'orange <
> jeann...@hypirion.com> wrote:
>
>>
>>
>> On Thursday, May 30, 2013 2:21:36 PM UTC+2, Gary Trakhman wrote:
>>>
>>> I just thought about this recently, but does the value-oriented nature
>>> of clojure mostly void the need for a cycles-aware GC?  It seems like you
>>> won't ever have cycles without identities, or pointers (java references).
>>>  Maybe this would be a problem only when you need identities, ie deftype or
>>> defprotocol implementing objects.
>>>
>>
>> Sure thing, the value-oriented nature removes a lot of cycles in
>> practice. However, you may for instance have an atom which contain itself,
>> so they are not nonexistant. As such, the GC cannot be completely
>> cycle-ignorant, but perhaps it doesn't have to be efficient at finding them
>> either.
>>
>> Another place where cycles happen are in (mutually) recursive functions,
>> they may be iffy if you define many recursive anonymous functions at
>> runtime.
>>
>> -- Jean Niklas L'orange
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from 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: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Timothy Baldridge]

Not really true, most of my programs contain this function:

(defn debug [x]
  (pprint x)
  x)

Now I can do this:

(comp foo debug bar)

Also, with some reader literal magic, I could write something to let me do
this:

(myfunc foo #dbg bar)



On Thu, May 30, 2013 at 6:12 PM, David Jacobs  wrote:

> Two more things:
>
> 1) printing is often not a viable option for lazily eval-ed sequences or
> async processes -- the output gets jumbled! And believe me, when a new
> Clojure dev sees that for the first time, he/she wants to quit.
> 2) printing is terrible for elegant clojure code -- thing (comp f g h
> (partial map z)) -- in order to figure out anything about dynamic data
> flowing through, you have to break apart that composition or add a let
> binding in one of those functions before returning a value. Both of those
> involve a lot of friction.
>
>
> On Thursday, May 30, 2013 5:00:13 PM UTC-7, raould wrote:
>>
>> for a long time haskell did not have a debugger. that sucked, imho.
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: [pre-ANN] test2, the last Clojure testing framework

[Timothy Baldridge]

>> 1) testing recursive functions. I want to test what a recursion STEP
does, not the >> whole function. Can I mock 'recur'?

You shouldn't need to, pull the body of the loop out as as separate
function, then test that function.

>> 2) testing sequence, esp. lazy

For this, I often create a generator function, or do what I suggested for
1). If your code is functional you should be able to test subsets of a lazy
seq by supplying the correct arguments to your generation function.

>> 3) IoC typically makes code more testable. What are Clojure alternatives
for IoC? Pass all dependencies as parameters to your function?

That's exactly what you should do. Functions should be small enough to only
need a few dependencies. If they need more, consider putting them into a
hash-map.

Some systems like Midje or Speclj have systems for helping with this, but I
have only  ever been frustrated with them. In the case of Speclj,
var-redefs are prefered, which assume that you'll have global vars to hold
your state, which is exactly the behavior I try to avoid.

Midje on the other hand, is a massive pile of macros and DSLs that
so complicate your code that advanced tests are insanely hard to debug. Pop
Quiz: Midje's "fact" and "provided", how are those parsed and executed? I
don't know! It's a black box, and I'd have to go and read the codebase to
understand why they don't work the way I think they should. Because Midje
exposes tests in a custom DSL, you can't approach it as if it was Clojure,
it's a different language with different semantics.

I want my tests to be in the same language as my code, this is why I tend
to stick with clojure.test. What are tests? Functions. What are assertions?
a simple wrapper around "assert". Simplicity at its finest. Sure, the
library is a bit underpowered, but I've never been frustrated with
clojure.test. And I can't tell you how many dozens of hours I've lost
trying to figure out why Midje doesn't like my test results.

Oh, and lein-difftestthat's one awesome bit of code. It provides extra
information, and yet doesn't add needless complexity.

Timothy


On Sun, Jun 9, 2013 at 11:22 PM, julianrz  wrote:

> This may be a little off topic, but does this, or any other framework,
> solve some testing inconveniences that exist in Clojure and probably other
> functional languages:
> 1) testing recursive functions. I want to test what a recursion STEP does,
> not the whole function. Can I mock 'recur'?
> 2) testing sequence, esp. lazy
> 3) IoC typically makes code more testable. What are Clojure alternatives
> for IoC? Pass all dependencies as parameters to your function?
>
> I wonder if code=data philosophy of Lisp enables some testing techniques
> that are impossible in languages like Java. Typically you can only test a
> function programmatically, not arbitrary code block. But you can probably
> introspect code very easily in Clojure, and test parts, regardless if they
> are functions or not. A test framework could support that in principle...
>
> I found that functional code is harder to separate, which would make it
> harder to test...
>
> Any thoughts?
> Thanks,
> Julian
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: [pre-ANN] test2, the last Clojure testing framework

[Timothy Baldridge]

>> You can certainly use with-redefs with any testing library/framework, or
you can pass dependencies into your production-code functions. I think
perhaps I'm missing the detail you're seeing on how using a particular test
framework encourages using global vars - can you elaborate?

You're right, my bad. I just looked at the Speclj docs as it's been some
time since I used the framework. I forgot that "with" defines a new var
that is passed in to the functions. I like that approach. Seems like I saw
a demo once that used with-redefs, but I'm probably hallucinating.

Timothy


On Mon, Jun 10, 2013 at 9:11 AM, Colin Jones  wrote:

>
>
> On Monday, June 10, 2013 9:20:31 AM UTC-5, tbc++ wrote:
>>
>> >> 1) testing recursive functions. I want to test what a recursion STEP
>> does, not the >> whole function. Can I mock 'recur'?
>>
>> You shouldn't need to, pull the body of the loop out as as separate
>> function, then test that function.
>>
>> >> 2) testing sequence, esp. lazy
>>
>> For this, I often create a generator function, or do what I suggested for
>> 1). If your code is functional you should be able to test subsets of a lazy
>> seq by supplying the correct arguments to your generation function.
>>
>> >> 3) IoC typically makes code more testable. What are Clojure
>> alternatives for IoC? Pass all dependencies as parameters to your function?
>>
>> That's exactly what you should do. Functions should be small enough to
>> only need a few dependencies. If they need more, consider putting them into
>> a hash-map.
>>
>> Some systems like Midje or Speclj have systems for helping with this, but
>> I have only  ever been frustrated with them. In the case of Speclj,
>> var-redefs are prefered, which assume that you'll have global vars to hold
>> your state, which is exactly the behavior I try to avoid.
>>
>>
> You can certainly use with-redefs with any testing library/framework, or
> you can pass dependencies into your production-code functions. I think
> perhaps I'm missing the detail you're seeing on how using a particular test
> framework encourages using global vars - can you elaborate?
>
>
>
>
>> Midje on the other hand, is a massive pile of macros and DSLs that
>> so complicate your code that advanced tests are insanely hard to debug. Pop
>> Quiz: Midje's "fact" and "provided", how are those parsed and executed? I
>> don't know! It's a black box, and I'd have to go and read the codebase to
>> understand why they don't work the way I think they should. Because
>> Midje exposes tests in a custom DSL, you can't approach it as if it was
>> Clojure, it's a different language with different semantics.
>>
>> I want my tests to be in the same language as my code, this is why I
>> tend to stick with clojure.test. What are tests? Functions. What are
>> assertions? a simple wrapper around "assert". Simplicity at its finest.
>> Sure, the library is a bit underpowered, but I've never been frustrated with
>> clojure.test. And I can't tell you how many dozens of hours I've lost
>> trying to figure out why Midje doesn't like my test results.
>>
>> Oh, and lein-difftestthat's one awesome bit of code. It provides
>> extra information, and yet doesn't add needless complexity.
>>
>> Timothy
>>
>>
>> On Sun, Jun 9, 2013 at 11:22 PM, julianrz  wrote:
>>
>>> This may be a little off topic, but does this, or any other framework,
>>> solve some testing inconveniences that exist in Clojure and probably other
>>> functional languages:
>>> 1) testing recursive functions. I want to test what a recursion STEP
>>> does, not the whole function. Can I mock 'recur'?
>>> 2) testing sequence, esp. lazy
>>> 3) IoC typically makes code more testable. What are Clojure alternatives
>>> for IoC? Pass all dependencies as parameters to your function?
>>>
>>> I wonder if code=data philosophy of Lisp enables some testing techniques
>>> that are impossible in languages like Java. Typically you can only test a
>>> function programmatically, not arbitrary code block. But you can probably
>>> introspect code very easily in Clojure, and test parts, regardless if they
>>> are functions or not. A test framework could support that in principle...
>>>
>>> I found that functional code is harder to separate, which would make it
>>> harder to test...
>>>
>>> Any thoughts?
>>> Thanks,
>>> Julian
>>>
>>>  --
>>> --
>>> 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 

Re: [pre-ANN] test2, the last Clojure testing framework

[Timothy Baldridge]

>> It might surprise you to know that there are actual human beings with
feelings who write the software you slam.

You are right. And I apologize for my strong words. For the goals that
Midje strives for, it is an excellent library.

My reaction is more against the ideas behind Midje (from the docs): "I
believe you should have the same reaction to test suites written like that:
a slavish adherence to Lisp style in tests incorrectly exalts purity over
user-friendliness. "

I disagree strongly with this assertion. I wish to see my tests in the same
language as my code. Midje succeeds in reaching the goals that it sets
forth. I can write tests, top-to-bottom, left-to-right. But at the expense
of debugging power, and intuitiveness.

It may be harder to read:

(is (= (foo 1) 42))

But even a beginner programmer in Clojure can parse and understand it.

I think the ideals Midje enspouses may be more applicable in other
languages, and IMO they are not needed in Clojure.

These are all my own, highly biased, opinions. I congratulate you, Brian,
on a well written, mature, library. I simply question the premise.

Timothy


On Mon, Jun 10, 2013 at 5:30 PM, Brian Marick  wrote:

>
> On Jun 10, 2013, at 9:20 AM, Timothy Baldridge 
> wrote:
> > Midje on the other hand, is a massive pile of macros and DSLs that so
> complicate your code that advanced tests are insanely hard to debug. ...
> And I can't tell you how many dozens of hours I've lost trying to figure
> out why Midje doesn't like my test results.
>
> It might surprise you to know that there are actual human beings with
> feelings who write the software you slam.
>
> Before people spend dozens of hours being frustrated, I suggest they post
> to the Midje mailing list. I try to be reasonably responsive, and I have a
> good track record helping people with their problems.
>
> 
> Latest book: /Functional Programming for the Object-Oriented Programmer/
> https://leanpub.com/fp-oo
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: generating core.logic queries

[Timothy Baldridge]

One reason why Datomic works so well with core.logic is that it exposes raw
index data to the client. I am unaware of any other database that decouples
data storage from the query engine. If you can find one that does, I'm sure
someone could expose a core.logic interface to that DB as well.

But, if you really can't stand the idea of using Datomic, and would prefer
to see examples running against other DBs, I would recommend this tutorial
that shows how core.logic can be used to query a graph database:
http://tsdh.wordpress.com/2012/01/06/using-clojures-core-logic-with-custom-data-structures/

Timothy


On Fri, Jun 21, 2013 at 10:41 AM, Cedric Greevey  wrote:

> Perhaps not, but apparently the developers of core.logic are. And it's
> only one of several similar instances to come to my attention in recent
> weeks.
>
>
> On Fri, Jun 21, 2013 at 12:22 PM, David Nolen wrote:
>
>> I wasn't suggesting using Datomic.
>>
>>
>> On Fri, Jun 21, 2013 at 12:19 PM, Cedric Greevey wrote:
>>
>>> On Fri, Jun 21, 2013 at 11:56 AM, David Nolen wrote:
>>>
 Datomic integration notes on the core.logic wiki

>>>
>>> I'm concerned with this trend towards favoring Datomic over other
>>> solutions when adding database integration to libraries. If one DB is going
>>> to be singled out for preferred treatment by a lot of Clojure developers,
>>> I'd prefer it to be an open source one, and I doubt I am alone in this.
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/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.
>
>
>



-- 
“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: Lazy seq race condition?

[Timothy Baldridge]

Reading the LazySeq.java file should make this all clear, but yes, no race
conditions.

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37

Synchronized methods basically lock the current instance of the object
while the method runs, so it is impossible for two threads to execute the
lazy seq fn at the same time.

Timothy


On Mon, Jun 24, 2013 at 4:17 PM, Cedric Greevey  wrote:

> Ah, thanks. The locking granularity is local to the cons cell (or
> analogue; first/rest pair) being realized, I hope? So one thread actually
> calculates an element and neither call returns until it's calculated, and
> then both promptly return the calculated value, but threads realizing other
> lazy seqs or crawling along earlier parts of the same one don't get
> blocked? (And given they can share tails, how would "same one" even be
> defined anyway?)
>
>
> On Mon, Jun 24, 2013 at 5:56 PM, Nicola Mometto wrote:
>
>>
>> Realizing a lazy-seq is done through a synchronized method see:
>>
>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37
>>
>> No race conditions.
>>
>> Cedric Greevey writes:
>>
>> > What, precisely, happens if two threads sharing a reference to a single
>> > lazy sequence try to realize the same element at the same time? If the
>> > sequence is completely pure and deterministic, so any attempt to
>> realize a
>> > particular element will produce a single particular value consistently
>> > (unlike, say, (repeatedly rand) or a file-seq where relevant parts of
>> the
>> > filesystem are being concurrently modified), is the worst-case scenario
>> > that the two threads will redundantly perform the same calculation,
>> with no
>> > effect other than a minor hit to performance and, in particular, no
>> effect
>> > on the program semantics?
>> >
>> > --
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from 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: Lazy seq race condition?

[Timothy Baldridge]

It corresponds to the execution of the LazySeq fn. That fn will be called
once and only once, the rest of the data in the object is immutable and
side-effect free and therefore does not need to be synchronized.

Timothy


On Mon, Jun 24, 2013 at 8:51 PM, Cedric Greevey  wrote:

> I'm familiar with what "synchronized Type foo (args)" does -- my last
> question was more about what aspect of a lazy seq the object with the
> method corresponds to. Cons cell or similar subunit? I could read half of
> clojure.lang, learn how all the various types of seq (Cons, LazySeq,
> ChunkedSeq, etc...) work under the hood, and thereby eventually figure it
> out, but it's probably a lot fewer man-hours of work for me to ask someone
> who's already intimately familiar with that codebase and for him to
> answer...
>
>
>
> On Mon, Jun 24, 2013 at 10:32 PM, Timothy Baldridge 
> wrote:
>
>> Reading the LazySeq.java file should make this all clear, but yes, no
>> race conditions.
>>
>>
>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37
>>
>> Synchronized methods basically lock the current instance of the object
>> while the method runs, so it is impossible for two threads to execute the
>> lazy seq fn at the same time.
>>
>> Timothy
>>
>>
>> On Mon, Jun 24, 2013 at 4:17 PM, Cedric Greevey wrote:
>>
>>> Ah, thanks. The locking granularity is local to the cons cell (or
>>> analogue; first/rest pair) being realized, I hope? So one thread actually
>>> calculates an element and neither call returns until it's calculated, and
>>> then both promptly return the calculated value, but threads realizing other
>>> lazy seqs or crawling along earlier parts of the same one don't get
>>> blocked? (And given they can share tails, how would "same one" even be
>>> defined anyway?)
>>>
>>>
>>> On Mon, Jun 24, 2013 at 5:56 PM, Nicola Mometto wrote:
>>>
>>>>
>>>> Realizing a lazy-seq is done through a synchronized method see:
>>>>
>>>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37
>>>>
>>>> No race conditions.
>>>>
>>>> Cedric Greevey writes:
>>>>
>>>> > What, precisely, happens if two threads sharing a reference to a
>>>> single
>>>> > lazy sequence try to realize the same element at the same time? If the
>>>> > sequence is completely pure and deterministic, so any attempt to
>>>> realize a
>>>> > particular element will produce a single particular value consistently
>>>> > (unlike, say, (repeatedly rand) or a file-seq where relevant parts of
>>>> the
>>>> > filesystem are being concurrently modified), is the worst-case
>>>> scenario
>>>> > that the two threads will redundantly perform the same calculation,
>>>> with no
>>>> > effect other than a minor hit to performance and, in particular, no
>>>> effect
>>>> > on the program semantics?
>>>> >
>>>> > --
>>>>
>>>> --
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To post to this group, send email to clojure@googlegroups.com
>>>> Note that posts from new members are moderated - please be patient with
>>>> your first post.
>>>> To unsubscribe from this group, send email to
>>>> clojure+unsubscr...@googlegroups.com
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/clojure?hl=en
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To unsubscribe from 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
>&

Re: Lazy seq race condition?

[Timothy Baldridge]

The first 100 lines of LazySeq.java contain all the answers. Read it, and
be enlightened. :-) And as a bonus, you'll better understand the language
as a whole.

Timothy


On Mon, Jun 24, 2013 at 9:08 PM, Cedric Greevey  wrote:

> So, is the granularity that of seq realization -- individual [first &
> rest] cells for (iterate inc 0), single chunks for (range), etc.? I'd
> appreciate a straight, direct, yes-or-no answer to that question.
>
>
> On Mon, Jun 24, 2013 at 11:03 PM, Timothy Baldridge 
> wrote:
>
>> It corresponds to the execution of the LazySeq fn. That fn will be called
>> once and only once, the rest of the data in the object is immutable and
>> side-effect free and therefore does not need to be synchronized.
>>
>> Timothy
>>
>>
>> On Mon, Jun 24, 2013 at 8:51 PM, Cedric Greevey wrote:
>>
>>> I'm familiar with what "synchronized Type foo (args)" does -- my last
>>> question was more about what aspect of a lazy seq the object with the
>>> method corresponds to. Cons cell or similar subunit? I could read half of
>>> clojure.lang, learn how all the various types of seq (Cons, LazySeq,
>>> ChunkedSeq, etc...) work under the hood, and thereby eventually figure it
>>> out, but it's probably a lot fewer man-hours of work for me to ask someone
>>> who's already intimately familiar with that codebase and for him to
>>> answer...
>>>
>>>
>>>
>>> On Mon, Jun 24, 2013 at 10:32 PM, Timothy Baldridge <
>>> tbaldri...@gmail.com> wrote:
>>>
>>>> Reading the LazySeq.java file should make this all clear, but yes, no
>>>> race conditions.
>>>>
>>>>
>>>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37
>>>>
>>>> Synchronized methods basically lock the current instance of the object
>>>> while the method runs, so it is impossible for two threads to execute the
>>>> lazy seq fn at the same time.
>>>>
>>>> Timothy
>>>>
>>>>
>>>> On Mon, Jun 24, 2013 at 4:17 PM, Cedric Greevey wrote:
>>>>
>>>>> Ah, thanks. The locking granularity is local to the cons cell (or
>>>>> analogue; first/rest pair) being realized, I hope? So one thread actually
>>>>> calculates an element and neither call returns until it's calculated, and
>>>>> then both promptly return the calculated value, but threads realizing 
>>>>> other
>>>>> lazy seqs or crawling along earlier parts of the same one don't get
>>>>> blocked? (And given they can share tails, how would "same one" even be
>>>>> defined anyway?)
>>>>>
>>>>>
>>>>> On Mon, Jun 24, 2013 at 5:56 PM, Nicola Mometto 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Realizing a lazy-seq is done through a synchronized method see:
>>>>>>
>>>>>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37
>>>>>>
>>>>>> No race conditions.
>>>>>>
>>>>>> Cedric Greevey writes:
>>>>>>
>>>>>> > What, precisely, happens if two threads sharing a reference to a
>>>>>> single
>>>>>> > lazy sequence try to realize the same element at the same time? If
>>>>>> the
>>>>>> > sequence is completely pure and deterministic, so any attempt to
>>>>>> realize a
>>>>>> > particular element will produce a single particular value
>>>>>> consistently
>>>>>> > (unlike, say, (repeatedly rand) or a file-seq where relevant parts
>>>>>> of the
>>>>>> > filesystem are being concurrently modified), is the worst-case
>>>>>> scenario
>>>>>> > that the two threads will redundantly perform the same calculation,
>>>>>> with no
>>>>>> > effect other than a minor hit to performance and, in particular, no
>>>>>> effect
>>>>>> > on the program semantics?
>>>>>> >
>>>>>> > --
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "Clojure" group.
>>>>>> To post

Re: core.async implemented on top of Pulsar

[Timothy Baldridge]

It's my opinion that core.async shouldn't be used a concurrency mechanism,
or as a new programming paradigm. Instead, it should be used as a
communication method between sequential processes, and as a de-coupling
method between modules. Let's go back to Rich's original post on the
library:

"There comes a time in all good programs when components or subsystems must
stop communicating directly with one another. This is often achieved via
the introduction of queues between the producers of data and the
consumers/processors of that data."

Thus, this library should be uses as a communication system between
subsystems, and not as a low level building block for the internals of a
subsystem. Now, in some languages (e.g. CLJS) this library may be the only
form of concurrency, but that's beyond the point.

So your concerns with multi-consumer, and the limitations of  wrote:

> Oh, yeah. It's 0.2-SNAPSHOT.
>
>
> On Monday, July 1, 2013 11:24:40 AM UTC+3, puzzler wrote:
>>
>> I'd love to try this out, but when I follow the getting started
>> directions and add [co.paralleluniverse/pulsar "0.1.1"] to my dependencies,
>> I seem to get a completely different API and namespace layout than what is
>> given in the documentation.  Is there a "snapshot" release that contains
>> the latest changes?
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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 implemented on top of Pulsar

[Timothy Baldridge]

Ben, you make a good point. I guess I was stating was something more along
the lines of the following. We have really really good concurrency
primitives (atom, ref, agent) and I think it would be a mistake to reach
for channels when one of those would do.

core.async is pretty fast, but reducers will probably work faster for
normal map/reduce needs. You can write something like an agent using
channels, but it won't be as fast as Clojure's agents.

So I should have stated this much clearer "to focus a system purely on
core.async would be to ignore the other features of Clojure. Use core.async
when other core language features won't work"

Timothy


On Mon, Jul 1, 2013 at 9:27 AM, Ben Wolfson  wrote:

> On Mon, Jul 1, 2013 at 7:10 AM, Timothy Baldridge wrote:
>
>> It's my opinion that core.async shouldn't be used a concurrency
>> mechanism, or as a new programming paradigm. Instead, it should be used as
>> a communication method between sequential processes, and as a de-coupling
>> method between modules. Let's go back to Rich's original post on the
>> library:
>>
>> "There comes a time in all good programs when components or subsystems
>> must stop communicating directly with one another. This is often achieved
>> via the introduction of queues between the producers of data and the
>> consumers/processors of that data."
>>
>
> Well, if you're looking for guidance as to how the library should be used
> by reading tea leaves in a blog post introducing them, compare:
>
> "Note that, unlike other Clojure concurrency constructs, channels, like
> all communications, are subject to deadlocks, the simplest being waiting
> for a message that will never arrive, which must be dealt with manually via
> timeouts etc."
>
> "Unlike other ... concurrency constructs" == "this is also a concurrency
> construct". It's possible, I suppose, to maintain that it's a concurrency
> construct that shouldn't be used for concurrency-in-general, but that
> strikes me as a losing proposition; it *is* a concurrency construct, and
> nothing about the library itself requires that it be used the way you're
> suggesting.  (It would be nice if there were some guarantee of linearity
> for channels so that I don't try to pass one to e.g. take-while and then
> also try to read from it elsewhere, but that's not directly related.) Also,
> if---as the references to go and Erlang suggest---it will be possible to
> have hundreds of thousands of go blocks talking over channels to each
> other, performance considerations seem pretty reasonable.
>
> --
> Ben Wolfson
> "Human kind has used its intelligence to vary the flavour of drinks, which
> may be sweet, aromatic, fermented or spirit-based. ... Family and social
> life also offer numerous other occasions to consume drinks for pleasure."
> [Larousse, "Drink" entry]
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
“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: Microsoft Rx -style operations with core.async

[Timothy Baldridge]

These look great!

I would, however, avoid using go-as. In the JCSP example a style such as
this is prefered most of the time:

(defn inc-all
  "increments every int received in the input channel"
 ([in]
  (let [out (chan)]
   (inc-all in out)
   out))
 ([in out]
  (go (while true
   (>! out (inc (wrote:

> When I first wrote this code, I intentionally avoided any custom
> syntactical sugar and worked as closely with the primitives as I could.
>
> After a few days away, I've used fresh eyes to abstract and revamp. The
> new code is *dramatically* cleaner and I only needed to introduce a few
> simple and predictable macros.
>
> With regards to my prior feedback:
>
> > 1) The (let [c chan] (go ...) c) pattern is *extremely-common*. Might be
> nice to have something like (go-as c ...) that expands to that pattern.
>
> I've implemented go-as without buffer parameterization. This was a huge
> cleanup.
>
> > 2) It's somewhat annoying to always have to consider boolean false all
> the time.
>
> I've introduced two macros: if-recv and when-recv. (if-recv [x p] ...) is
> equivalent to (let [x ( what you'd expect.
>
> Currently, these macros only operate on a single port to read from. I need
> to give this a bit more thought before I attempt a multiplexing version of
> this macro.
>
> > 3) Not mentioned in my prior feedback: Looping receives over a channel
> is pretty common too.
>
> For that, I've got the (dorecv [x port] ...) macro, which is analogous to
> doseq, but reads from port via 
> Similarly, a multiplexing variant of dorecv needs more thought before I
> attempt that.
>
> I think you'll agree that the new code is much nicer looking:
> https://github.com/brandonbloom/asyncx/blob/89fe35eae8be9a3350855bf841fc11c46ea04b0f/src/asyncx/core.clj
> (doc strings available for these new macros too)
>
> Each one of these primitives is about an order of magnitude more useful
> than any of the original Rx operators... So I guess that means I can
> consider this a successful learning experience! In fact, I think these 4
> macros might even be useful enough for the core.async namespace after some
> more field testing. Please let me know if these are helpful to you. I'd
> also love to know if there are any little patterns or macros like these
> that you've "discovered".
>
> Cheers,
> Brandon
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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 go - out of memory

[Timothy Baldridge]

Go blocks are GC'd but not until they complete running. The problem is that
you're creating go blocks faster than they can run. Creating go blocks is
very cheap, taking/putting into channels is also cheap but not quite as
cheap. Therefore the outer loop will eventually allocate so many blocks
that you're run OOM.

Timothy


On Sat, Jul 6, 2013 at 10:19 AM, MikeM wrote:

>
> On Saturday, July 6, 2013 11:46:51 AM UTC-4, David Nolen wrote:
>>
>> This isn't a bug, you're in a infinite loop constructing go blocks. You
>> should probably move the loops into the go blocks.
>>
>>  I assumed go blocks are garbage collected when they go out of scope, but
> maybe I don't understand the scope of a go block. You're saying every go
> block created in the loop should be expected to hang around indefinitely?
> My (possibly broken) thinking was that after the first iteration, whatever
> is constructed by the go blocks in the first iteration would be candidates
> for garbage collection.
>
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: Don't understand why this core.async code fails

[Timothy Baldridge]

A few thoughts on ways to improve this code:

Using agents and go blocks in the same code is a bit odd. If you need a
queue plus a process,  just do something like this:

(defn faux-agent [c]
  (go (loop []
   (when-let [msg (! req-chan :req)

do something like this:

(>! req-chan [file-name my-response-channel])
( wrote:

> As you can read here:
> http://martintrojer.github.io/clojure/2013/07/07/coreasync-and-blocking-iodoing
>  blocking IO in a go block should be avoided. So I was thinking that
> an alternative to non-blocking IO APIs is using agents and channels.
>
> The following sample program intends to illustrate the technique:
>
> (require '[clojure.core.async :as async :refer :all])
> (import '[java.util.concurrent Executors])
>
> (spit "bar" (apply str (shuffle (range 100
>
> (def slurper (agent nil))
>
> (def spitter (agent nil))
>
> (def max-concurrency 1)
>
> ;; when a go block wants to slurp a file, it communicates it by writing to
> thins channel
> (def slurping-request (chan max-concurrency))
>
> ;; where requested slurped content gets served
> (def slurps (chan max-concurrency))
>
> (def rw-pool (Executors/newFixedThreadPool max-concurrency))
>
> (def serving
>   (future
> (while (   (send-via rw-pool slurper (fn [_] (>!! slurps (seq (slurp "bar")))
> _)
>
> (go (while true
>   (>! slurping-request :req)
>   (let [old ( new (apply str (shuffle old))]
> (send-via rw-pool spitter (fn [_] (spit "bar" new))
>
> It is supposed to constantly modify a file, until you (close!
> slurping-request). However, somehow nil-related issues crept in:
>
>
>- With max-concurrency set to 1, at times an empty string gets written
>to the file.
>- With max-concurrency set to 4, the spitter agent fails.
>
>
> What is going on? Maybe files need locking? Or am I misunderstanding some
> aspect of core.async itself?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: Don't understand why this core.async code fails

[Timothy Baldridge]

Eh, you're right, there is however, a blocking version of go, called thread:

So perhaps something like this?

(thread
  (while true
(let [[filename response-chan] (!! response-chan (slurp filename)

Or perhaps I'm missing something.

Timothy


On Mon, Jul 8, 2013 at 10:09 AM, vemv  wrote:

> Took me a while to get the idea but higher-order channels are brilliant -
> that way one ensures a given reply was actually targeted at one's request.
> Thanks for the suggestion!
>
> Faux-agents would have the limitation of not being to (reasonably) perform
> blocking I/O - which is the point of my sample program.
>
> An improved version:
>
> (require '[clojure.core.async :as async :refer :all])
> (import '[java.util.concurrent Executors]
> '[java.util.concurrent.locks ReentrantReadWriteLock])
>
>
> (spit "bar" (apply str (shuffle (range 100
>
> (def max-concurrency 4)
>
> (def requests (chan max-concurrency))
>
> ;; only ensures exclusive access within the app - not across the OS
> ;; too lazy to use a FileLock :)
> (def lock (ReentrantReadWriteLock.))
>
> (def rw-pool (Executors/newFixedThreadPool max-concurrency))
>
> ;; one sends actions to anonymous one-off multiple agents
> ;; (as opposed to a single, named one), in order to increase concurrency
>
> (dotimes [_ max-concurrency]
>   (go (loop []
> (when-let [request (   (send-via rw-pool (agent nil) (fn [_]
>   (try
> (-> lock .readLock .lock)
> (>!! request (seq (slurp
> "bar")))
> (finally
>   (-> lock .readLock
> .unlock)
>   (recur)
>
> (go (loop []
>   (let [request (chan)
> _ (>! requests request)
> response ( (send-via rw-pool (agent nil) (fn [_]
> (try
>   (-> lock .writeLock .lock)
>   (spit "bar" (apply str (shuffle
> response)))
>   (finally
> (-> lock .writeLock
> .unlock)
> (recur
>
> As commented, locking is only partially useful (that's why opening the
> file might display an empty string at times). Also, don't know what would
> be the best way to indicate termination to the second go block...
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
“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: Clojure: Elegance vs. Performance?

[Timothy Baldridge]

The thing that should be mentioned, is that we're talking about some pretty
insane performance optimizations for a dynamic language. Let's take
something like Python for example. All ints are boxed, all the time. If you
want to optimize your code, you drop to C (or Cython) so you end up
re-writing your performance critical code.

Clojure stands on some pretty unique ground in being one of the few dynamic
languages out there that allow you to specify types to improve performance
in some specific situations.

In short, how would you get this level of performance from scheme?
Optimization and code clarity are very often at odds. And expressiveness
often comes at the cost of performance.

Timothy


On Tue, Jul 9, 2013 at 9:51 AM, Alexander Gunnarson <
alexandergunnar...@gmail.com> wrote:

> Perhaps I didn't choose my examples in a very illustrative way. It was
> meant to be a general approach. There are probably several other examples
> where the need for performance causes elegance to suffer, but I'm drawing a
> blank right now because I'm not a Clojure expert. As I familiarize myself
> with the language I'll be able to cite more varied examples.
>
> Thanks for your feedback. I see your point with the *:else* keyword.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: communicating termination

[Timothy Baldridge]

It's interesting to note that blocking go blocks can actually be GC'd. For
example, run this in a repl:

(loop [] (let [c (chan)]
 (go (>! c 42)))
  (recur))

On my box the CPU and memory spikes, but after I CTRL+C and kill the loop,
the GC kicks in and collects all the channels and gos

When go's are parked, they are put into a queue on the channel, thus when
the channel is unreachable (besides inside the go block) both are
collected, and the thread of execution is effectively terminated.



Timothy


On Thu, Jul 11, 2013 at 4:53 PM, Michał Marczyk wrote:

> I think you could pass the producer a higher-order (chan 1) with the
> actual communication channel placed in the buffer.
>
> Then at each step the producer would do
>
> (when-let [c (   (>! c (rand))
>   (>! communication-channel c))
>
> Once you close communication-channel, the put succeeds, but then the
> take on communication-channel returns nil and the producer stops.
>
> Cheers,
> M.
>
>
> On 12 July 2013 00:37, Alex Miller  wrote:
> > I haven't been in any discussions about this with the team, so it's
> entirely
> > possible I am ignorant of some established future direction... but
> >
> > - "closed?" seems useful to me. (It may also be useful to ask "drained?"
> > (closed + empty).)
> > - >! returning an indicator of success also seems useful. However, since
> it
> > executes asynchronously, I suspect adding that functionality may not be
> > feasible (or may be feasible but incur a synchronization or complexity
> cost
> > that is unacceptable).
> >
> > If you'd like to file a ticket at
> http://dev.clojure.org/jira/browse/ASYNC
> > that would help to track the request.
> >
> > With respect to other strategies for dealing with this:
> >
> > 1) You could simply ignore the producer. If no one is requesting new
> values,
> > the producer will not be run and no thread time should be consumed
> (there is
> > of course heap being used). Not really recommending this but it's an
> option!
> >
> > 2) You could create a control channel for the producer (and other
> interested
> > processes) that could transmit a stop message. Then alts! on the control
> > channel in combination with the >! so that you're waiting on either the
> need
> > to stop or the ability to put a new value in the channel.
> >
> > Alex
> >
> >
> > On Thursday, July 11, 2013 7:16:56 AM UTC-5, vemv wrote:
> >>
> >> Consider a happy, oblivious producer of values:
> >>
> >> (def c (chan 42))
> >>
> >> (go (while true (>! c (rand
> >>
> >> It doesn't know where/now the channel is consumed (which part of the
> point
> >> of channels/queues). However, we do know that at some point, nobody will
> >> need the result of our producing, so we should stop our activity.
> >>
> >> It seems to me that a natural way to tell the producer to stop is to
> close
> >> the channel. However:
> >>
> >> * there's nothing like a clojure.core.async/chan-closed? fn, AFAICT
> >> * The >! fn unconditionally returns nil, whether the channel is open or
> >> not. Only the blocking nature of the call can potentially vary - which
> is
> >> not particularly useful for the purpose.
> >>
> >> What would be an adequate way to indicate termination? Just telling the
> >> producer to stop (e.g. (reset! keep-producing false)) would break the
> >> indirection one gains by using channels.
> >>
> >> What if >! returned true/false depending on whether the value was put
> >> (because the channel was open)?
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from 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 

Re: core.async: exception handling

[Timothy Baldridge]

In the latest copy of core.async (taken from github master), I get this
error:

 (go
 (try
   (go (throw (Exception.)))
   (catch Exception ex
 (println "catched"

xception in thread "async-dispatch-2" java.lang.Error: java.lang.Exception
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1151)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.Exception
at
user$eval2509$fn__2510$state_machine__2342__auto2511$fn__2517$fn__2518$state_machine__2342__auto2519.invoke(NO_SOURCE_FILE:1)
at
clojure.core.async.impl.ioc_macros$run_state_machine.invoke(ioc_macros.clj:763)
at
user$eval2509$fn__2510$state_machine__2342__auto2511$fn__2517$fn__2518.invoke(NO_SOURCE_FILE:1)
at clojure.lang.AFn.run(AFn.java:24)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
... 2 more
#


This is exactly as expected. In your code snippet, the exception is
escaping the inner go. If you want to catch that exception, you need to put
the try/catch inside the go block.


Timothy


On Mon, Jul 15, 2013 at 10:20 PM, Alice  wrote:

> user=> (go
>  (try
>(go (throw (Exception.)))
>(catch Exception ex
>  (println "catched"
>
> IllegalArgumentException contains? not supported on type:
> clojure.lang.PersistentList  clojure.lang.RT.contains (RT.java:724)
>
>
> Why am I getting this error?
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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

[Timothy Baldridge]

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 (http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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

[Timothy Baldridge]

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 wrote:

> 2013/7/17 Timothy Baldridge :
> > 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 ( > (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

[Timothy Baldridge]

After a channel is closed, any gets ( 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 
> wrote:
>
>> 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 
>> wrote:
>>
>>> 2013/7/17 Timothy Baldridge :
>>> > 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 (>> > (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 pa

ANN: Fafnir, a library for inserting complex data structures into Datomic

[Timothy Baldridge]

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: core.async: leak in the examples

[Timothy Baldridge]

Yes, channels are GC'd and so are any gos that are connected to them (who
are not also being held by some other reference).

Timothy


On Thu, Jul 18, 2013 at 9:42 AM, Alice  wrote:

> https://github.com/clojure/core.async/blob/master/examples/ex-async.clj
> https://github.com/clojure/core.async/blob/master/examples/ex-go.clj
>
> One uses future, and the other uses go. The code runs query twice for
> each search type, and takes only one, whichever comes first, from the
> channel, so I'm sure 3 threads are blocked in the future version after
> running the code.
>
> But what about the go version? Is it also leaked? My guess is that because
> there's no reference to the channel, it's GC'd. But I'm not sure.
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



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

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

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

[Timothy Baldridge]

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

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

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

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

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

Hopefully this helps a bit,

Timothy Baldridge


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

> It brother me too.
>
> Thanks
>
>
> On Friday, July 5, 2013 3:28:54 AM UTC+8, Hussein B. wrote:
>>
>> Hi,
>>
>> How core.async compares to agents, future and promise?
>>
>> When to use core.async and when to use agents, future and promise?
>>
>> Thanks for help and time.
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



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

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

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

[Timothy Baldridge]

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

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


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

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



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

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

Re: Confused again by core.async

[Timothy Baldridge]

I think the problem is in your service function, notice how you are reading
data from a channel then writing data to that same channel, within the same
process? Try fixing that and see where it gets you.

Timothy


On Tue, Jul 23, 2013 at 11:25 PM, Alan Shaw  wrote:

> Hi,
> I hope I can get a lightbulb on what's happening here:
>
> https://github.com/nodename/async-plgd/blob/master/src/hoare/problem.clj
>
> Testing fan-in on a pair of processes and getting nutty results.
>
> Thanks,
>
> -A
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
“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: Confused again by core.async

[Timothy Baldridge]

Take a look at your code again, service is reading a value from a,
modifying it, and sticking it back into a. You also have a "put" process
putting values into a, and fan-in taking values from a. So what is keeping
values from flowing from your "put" process directly to fan-in, skipping
service completely? It's a race-condition...

Timothy


On Wed, Jul 24, 2013 at 12:41 PM, nodename  wrote:

> I do not think that is the problem. In fact I believe that reading a
> request from a channel and writing the response to the same channel is the
> canonical service pattern in Go.
> I have added a test-service function that works as expected, and a
> test-fan-in-2 function that fails in a slightly different way.
> My fan-in function is copied from David Nolen so I have some confidence in
> that...
>
> -A
>
>
> On Wednesday, July 24, 2013 5:28:31 AM UTC-7, tbc++ wrote:
>
>> I think the problem is in your service function, notice how you are
>> reading data from a channel then writing data to that same channel, within
>> the same process? Try fixing that and see where it gets you.
>>
>> Timothy
>>
>>
>> On Tue, Jul 23, 2013 at 11:25 PM, Alan Shaw  wrote:
>>
>>> Hi,
>>> I hope I can get a lightbulb on what's happening here:
>>>
>>> https://github.com/nodename/**async-plgd/blob/master/src/**
>>> hoare/problem.clj
>>>
>>> Testing fan-in on a pair of processes and getting nutty results.
>>>
>>> Thanks,
>>>
>>> -A
>>>
>>> --
>>> --
>>> 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
>>> .
>>>
>>>
>>>
>>
>>
>>
>> --
>> “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.
>
>
>



-- 
“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: querying a clojure data structure

[Timothy Baldridge]

I think the first hint to an answer is found in your question. You are
dealing with complex data, simplify the data, and querying the data is much
simpler.

For instance, if you have a tree, you could flatten the tree into a hash
map like this:

{parent-id {:children [child-id1 child-id2]}
 child-id1 {:children [child-id3 child-id4]}
 child-id2 ...}

Now it's very simple to say things like "who are the parents of this child
node?". Cedric is right, once you get a somewhat normalized data structure
it's fairly trivial to query it with core.logic (using hash maps like the
one above). You just have to write some code to get it into a format that
core.logic can consume.

However, to be honest, this is where I reach for Datomic. It has a wicked
fast query engine (datalog), you can run it in-memory (no disk access
required), it has an excellent Clojure interface, the free version should
do everything you need, and it has many many other features. For instance,
given a child node in Datomic, you can find it's parents via:

(let [parents (:_children child-node)]
  ...)

Not to mention that you can also create Datalog rules that allow you to
create pre-defined queries that simplify your code quite a bit.

In short, when I hear my self saying "find X where Y" or "I'd like to query
this structure", I reach for Datomic, when that doesn't work for me (for
whatever reason) then I start coding with core.logic.

Timothy



On Wed, Jul 24, 2013 at 1:14 PM, Cedric Greevey  wrote:

> Don't quote me on this, but it might be the sort of problem for which
> core.logic is well suited. Though really it seems like what's wanted is a
> variation on the theme of core.match but which does destructuring
> assignments rather than flow control.
>
>
> On Wed, Jul 24, 2013 at 8:16 AM, Phillip Lord <
> phillip.l...@newcastle.ac.uk> wrote:
>
>>
>> I have a relatively complex data structure, a simple example of which
>> looks
>> likes like this. This is the print representation -- the bits like
>> "" are java classes.
>>
>> {:annotation
>>#{(annotation #>   >
>>   "PizzaTopping" "en")
>>  (annotation #>   >
>>   "Phillip Lord" "en")
>>   (label "Ingredienti di Pizza" "it")},
>>  :disjoint #{#http://www.ncl.ac.uk/pizza#Pizza>>
>>  #http://www.ncl.ac.uk/pizza#PizzaBase>>},
>>  :type :class}
>>
>> I want to be able to query this data structure, mostly by equality
>> testing,
>> although in some cases, I will need to call methods on the Java objects
>> embedded. And all of this needs to be nil safe because any of the
>> components
>> might be missing.
>>
>> So, with this case, say I want the Italian label, in the set which is the
>> value of the annotation key, find any list with the first element 'label,
>> and
>> third element "it", and return the second element. Of course, this can be
>> done
>> in Clojure, but the code gets complex very quickly.
>>
>> What I'd really want to be able to do is to use some sort of query; so I'd
>> write a data structure like so:
>>
>> {:annotation
>>  #{(label ? "it")}}
>>
>> and have this match and return
>>
>> {:annotation
>>  #{(label "Ingredienti di Pizza" "it")}}
>>
>> which is the bit that matches.
>>
>> I was wondering whether I am missing a trick here, or whether there is
>> some library which does something similar to this.
>>
>> These data structures can get larger and quite heavily nested. To give
>> some
>> idea, this is a more complex example!
>>
>> Thanks!
>>
>>
>>
>> {:annotation
>>   #{(annotation
>>  #>  >
>>  "Parmense" "en")
>> (label "Parmense" "it")
>> (annotation #> > "Phillip Lord" "en")},
>>  :disjoint
>>#{#http://www.ncl.ac.uk/pizza#CapricciosaPizza>>
>>  #http://www.ncl.ac.uk/pizza#MargheritaPizza>>
>>  #http://www.ncl.ac.uk/pizza#CajunPizza>>
>>  #http://www.ncl.ac.uk/pizza#SohoPizza>>},
>>  :type :class,
>>  :subclass
>> #{(owlonly
>> #http://www.ncl.ac.uk/pizza#hasTopping>>
>>   (owlor
>> #http://www.ncl.ac.uk/pizza#AsparagusTopping>>
>> #http://www.ncl.ac.uk/pizza#HamTopping>>
>> #http://www.ncl.ac.uk/pizza#MozzarellaTopping>>
>> #http://www.ncl.ac.uk/pizza#ParmesanTopping>>
>> #http://www.ncl.ac.uk/pizza#TomatoTopping>>))
>> #http://www.ncl.ac.uk/pizza#NamedPizza>>
>> (owlsome #>   >
>>   #http://www.ncl.ac.uk/pizza#HamTopping>>)
>> (owlsome #> http://www.ncl.ac.uk/pizza#hasTopping>>
>>   #http://www.ncl.ac.uk/pizza#AsparagusTopping>>)
>> (owlsome #> http://www.ncl.ac.uk/pizza#hasTopping>>
>>   #http://www.ncl.ac.uk/pizza#MozzarellaTopping>>)
>> (owlsome #> http://www.ncl.ac.uk/pizza#hasTopping>>
>>   #http://www.ncl.ac.uk/pizza#TomatoTopping>>)
>> (owlsome #> http://www.ncl.ac.uk/pizza#hasTopping>>
>>   #http:

Re: querying a clojure data structure

[Timothy Baldridge]

Eh...use the right tool for the job...


On Wed, Jul 24, 2013 at 2:00 PM, Cedric Greevey  wrote:

> On Wed, Jul 24, 2013 at 3:27 PM, Timothy Baldridge 
> wrote:
>
>> However, to be honest, this is where I reach for Datomic. It has a wicked
>> fast query engine (datalog), you can run it in-memory (no disk access
>> required), it has an excellent Clojure interface, the free version should
>> do everything you need, and it has many many other features.
>>
>
> Except for one that many people consider quite important: it's not free
> (libre) software...
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: is intellij idea a good ide for clojure development?

[Timothy Baldridge]

+1 to Charlie. If I ever went back to Python development I would plop down
whatever the going rate is for PyCharm (InteliJ Python IDE), that thing is
an awesome piece of tech. There are very few times I've been utterly blown
away by an idea all the standard features of Python (testing, debugging,
code coverage, project structure, etc) are defaults in PyCharm. It even
detects multiple versions of Python on your system and adds them to the
intelisense and run menus.

To be honest, I can't wait until we have something like that for Clojure.
Give me a fast, light, InteliJ based IDE that "just works" 100% of the
time, and I'd pay several hundred dollars for that software.

Timothy


On Fri, Jul 26, 2013 at 8:29 AM, Charlie Griefer
wrote:

> On Jul 25, 2013, at 8:15 PM, Cedric Greevey  wrote:
>
> Someone makes free software plugins for nonfree software?!
>
>
> On Thu, Jul 25, 2013 at 11:04 PM, Greg  wrote:
>
>> You submit patches to nonfree software?!
>>
>>
>>
> I may regret asking this… but don't people deserve to get paid for their
> work? I mean if they choose to charge (I'm not putting down the free model
> at all)?
>
> And at $70 for ST 2, well as a developer I use an editor pretty
> frequently. I'm thinking that at $70, if I find the software helps me be
> productive, then it pretty much pays for itself some time during the first
> day.
>
> --
> Charlie Griefer
> http://charlie.griefer.com
>
> "Give light, and the darkness will disappear of itself."
> -- Desiderius Erasmus
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: What is a "state monad binding plan" (referring to code in core.async)

[Timothy Baldridge]

Well, I wrote the code, so I suppose I should comment on it a bit. The
ioc_macros use a very loosely defined version of the state-monad. I don't
know if the functions/macros follow all the monad laws, and I really don't
care, but here's the problem:

I needed to be able to track some state while parsing the clojure code. I
needed to be able to define blocks while defining other blocks, to have
instructions reference each other, etc. All this could be done with a atom,
but I really don't like mutable state. So I decided to write the entire
thing in a fully immutable way.

Thus, the first step is to start defining functions that return functions
that will take a state:

(defn assoc-plan [k v]
  (fn [state]
[nil (assoc state k v)]))

So each "monadic function" is a function that takes a state, and returns a
vector of [value new-state]. This allows me to write functions like
add-instruction that both add an instruction to a block and also return a
id to that instruction.

All the other functions in the code are built off this simple concept.
gen-plan then wires them all up together, and is basically monadic "bind",
except it's optimized to use lets instead of nested fns.

All this allows the parsing code to remain rather simple, while tracking
state, and remaining fully immutable. The code below looks as if it is
mutating state, but is actually fully immutable.

(defmethod sexpr-to-ssa 'if
  [[_ test then else]]
  (gen-plan
   [test-id (item-to-ssa test)
then-blk (add-block)
else-blk (add-block)
final-blk (add-block)
_ (add-instruction (->CondBr test-id then-blk else-blk))

_ (set-block then-blk)
then-id (item-to-ssa then)
_ (if (not= then-id ::terminated)
(gen-plan
 [_ (add-instruction (->Jmp then-id final-blk))]
 then-id)
(no-op))

_ (set-block else-blk)
else-id (item-to-ssa else)
_ (if (not= else-id ::terminated)
(gen-plan
 [_ (add-instruction (->Jmp else-id final-blk))]
 then-id)
(no-op))

_ (set-block final-blk)
val-id (add-instruction (->Const ::value))]
   val-id))



Most of the time, I recommend people start reading the at functions such as
add-block, get-block, set-block, etc. Ignore the implementation of
gen-plan, and just examine how it's used. After about 30 minutes the light
will go on, and it'll all make sense.

Pretty printing (via the debug function) the output of
parse-to-state-machine will also help you make sense of what's being
constructed.

I hope this helps.

Timothy Baldridge


On Fri, Jul 26, 2013 at 8:51 AM, john  wrote:

> Hi,
> I am trying to understand the code in  
> ioc_macros.clj<https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/ioc_macros.clj>
> .
> I stumbled on the macro gen-plan which doc reads "Allows a user to define
> a state monad binding plan"
> I am wondering what makes the macro a "state monad" and how does it
> simplify the building of the state-machine data structure?
>
> Many Greetings
> John
>
>
>
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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 + swing

[Timothy Baldridge]

I recommend using invokeLater to send a fn to Swing to do the rendering.

http://docs.oracle.com/javase/6/docs/api/javax/swing/SwingUtilities.html#invokeLater(java.lang.Runnable)


If you need Swing to notify the go channel when the rendering is complete,
you can do something like this:

(go
  (let [c (chan)]
(SwingUtilities/invokeLater (fn [] (do ...stuff ) (close! c)))
( wrote:

> Hi, I'm playing around with core.async a bit.
> Is it possible to put java.awt.Graphics object into a channel and do the
> drawing in a go loop consuming this channel.
> The problem I'm having is that when I consume the channel, core.async has
> switched to another thread. I'm not in the Swing thread anymore.
> Is there a way to stay in the Swing thread while doing this?
>
> This is how I setup the producer:
>
> (defn create-canvas [paint-channel]
>   (proxy [JButton] []
>  (getPreferredSize [] (Dimension. 300 300))
>  (paintComponent [g]
>(go
>  (proxy-super paintComponent g)
>  (>! paint-channel g) ;I've tried put! too
>
> Thanks!
> --anders
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: In-order triggering of watches on mutable state

[Timothy Baldridge]

Code? It's hard to debug if we can't see what's going on.


On Wed, Jul 31, 2013 at 9:00 AM, Michael Drogalis wrote:

> Problem:
>
> I have a ref representing a queue of people in line.
> I add a watch to the ref to print out the contents of the queue whenever
> it changes.
> Naturally, and expected, the following can happen if queuing happens in
> rapid succession:
>
> Queue: []
> 
> 
>
> console: "Queue is Mike, John"
> console: "Queue is Mike"
>
> I'd like to write a UI for this program, but I clearly can't reliably
> render based on the result delivered
> by the add-watch hook. What's the solution for this problem?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: In-order triggering of watches on mutable state

[Timothy Baldridge]

The answer is here:

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LockingTransaction.java#L361

Agents and watches are dispatched outside of the transaction locking. This
means that multiple transactions could be executing watches in parallel,
and hence execute out of order.

Timothy Baldridge


On Wed, Jul 31, 2013 at 9:43 AM, Michael Drogalis wrote:

> I can precisely exemplify the behavior here:
>
> https://gist.github.com/MichaelDrogalis/6123177
>
>
> On Wednesday, July 31, 2013 11:13:17 AM UTC-4, Michael Drogalis wrote:
>>
>> Aaron: Yep, I'm aware - and am using the value provided by the last
>> parameter.
>>
>> This is going to be tough to show the problem without bringing more
>> details of my concurrency set up.
>> I'm not sure if this will exhibit the problem, but this is what it boils
>> down to:
>>
>> https://gist.github.com/**MichaelDrogalis/6122834<https://gist.github.com/MichaelDrogalis/6122834>
>>
>> When enough threads are trying to write to the queue, the watches
>> triggered later can finish before watches triggered earlier.
>>
>>
>> On Wednesday, July 31, 2013 11:05:16 AM UTC-4, Aaron Cohen wrote:
>>>
>>> A watcher fn has 4 parameters: key, reference, old-state, new-state
>>>
>>> If you use old-state and new-state rather than the reference, you should
>>> not see your problem.
>>>
>>> --Aaron
>>>
>>>
>>> On Wed, Jul 31, 2013 at 11:00 AM, Michael Drogalis 
>>> wrote:
>>>
>>>> Problem:
>>>>
>>>> I have a ref representing a queue of people in line.
>>>> I add a watch to the ref to print out the contents of the queue
>>>> whenever it changes.
>>>> Naturally, and expected, the following can happen if queuing happens in
>>>> rapid succession:
>>>>
>>>> Queue: []
>>>> 
>>>> 
>>>>
>>>> console: "Queue is Mike, John"
>>>> console: "Queue is Mike"
>>>>
>>>> I'd like to write a UI for this program, but I clearly can't reliably
>>>> render based on the result delivered
>>>> by the add-watch hook. What's the solution for this problem?
>>>>
>>>> --
>>>> --
>>>> 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<http://groups.google.com/group/clojure?hl=en>
>>>> ---
>>>> You received this message because you 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<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: In-order triggering of watches on mutable state

[Timothy Baldridge]

You might want to consider switching to agents (or something else) I don't
think it's possible to do what you want with refs.

Timothy Baldridge


On Wed, Jul 31, 2013 at 10:08 AM, Mike Drogalis wrote:

> Thanks for the link. :) I understand that the behavior I'm seeing is
> correct. Any idea how to achieve the desired behavior, though?
>
>
> On Wed, Jul 31, 2013 at 12:06 PM, Timothy Baldridge 
> wrote:
>
>> The answer is here:
>>
>>
>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LockingTransaction.java#L361
>>
>> Agents and watches are dispatched outside of the transaction locking.
>> This means that multiple transactions could be executing watches in
>> parallel, and hence execute out of order.
>>
>> Timothy Baldridge
>>
>>
>> On Wed, Jul 31, 2013 at 9:43 AM, Michael Drogalis 
>> wrote:
>>
>>> I can precisely exemplify the behavior here:
>>>
>>> https://gist.github.com/MichaelDrogalis/6123177
>>>
>>>
>>> On Wednesday, July 31, 2013 11:13:17 AM UTC-4, Michael Drogalis wrote:
>>>>
>>>> Aaron: Yep, I'm aware - and am using the value provided by the last
>>>> parameter.
>>>>
>>>> This is going to be tough to show the problem without bringing more
>>>> details of my concurrency set up.
>>>> I'm not sure if this will exhibit the problem, but this is what it
>>>> boils down to:
>>>>
>>>> https://gist.github.com/**MichaelDrogalis/6122834<https://gist.github.com/MichaelDrogalis/6122834>
>>>>
>>>> When enough threads are trying to write to the queue, the watches
>>>> triggered later can finish before watches triggered earlier.
>>>>
>>>>
>>>> On Wednesday, July 31, 2013 11:05:16 AM UTC-4, Aaron Cohen wrote:
>>>>>
>>>>> A watcher fn has 4 parameters: key, reference, old-state, new-state
>>>>>
>>>>> If you use old-state and new-state rather than the reference, you
>>>>> should not see your problem.
>>>>>
>>>>> --Aaron
>>>>>
>>>>>
>>>>> On Wed, Jul 31, 2013 at 11:00 AM, Michael Drogalis >>>> > wrote:
>>>>>
>>>>>> Problem:
>>>>>>
>>>>>> I have a ref representing a queue of people in line.
>>>>>> I add a watch to the ref to print out the contents of the queue
>>>>>> whenever it changes.
>>>>>> Naturally, and expected, the following can happen if queuing happens
>>>>>> in rapid succession:
>>>>>>
>>>>>> Queue: []
>>>>>> 
>>>>>> 
>>>>>>
>>>>>> console: "Queue is Mike, John"
>>>>>> console: "Queue is Mike"
>>>>>>
>>>>>> I'd like to write a UI for this program, but I clearly can't reliably
>>>>>> render based on the result delivered
>>>>>> by the add-watch hook. What's the solution for this problem?
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> 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<http://groups.google.com/group/clojure?hl=en>
>>>>>> ---
>>>>>> You received this message because you 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<https://groups.google.com/groups/opt_out>
>>>>>> .
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>  --
>>> --
>>> You received this message because you are subscribed to the 

Re: In-order triggering of watches on mutable state

[Timothy Baldridge]

Deadlocks? Imagine a watch that ended up running a transaction against the
ref it was triggered from. Sounds insane, but it could be fairly easy to do
in a situation like this:

ref -> calls watchers -> calls fn1 -> calls fn 2 -> calls fn3 -> starts
transaction on ref

Since watchers are notified outside of a ref transaction deadlocking is
impossible. Inside a transaction you'd have a instant deadlock.

Timothy Baldridge


On Wed, Jul 31, 2013 at 10:47 AM, Mike Drogalis wrote:

> I'll play around with agents for this when I get some more free time.
>
> I find it odd that, as the sole perceiver of an indentity, events are
> capable of being perceived out of order.
> If I were watching a line queue up in person, events are obviously
> "dispatched" in order through my visual perception.
> I trust there's a good reason it's designed this way, at any rate.
>
>
> On Wed, Jul 31, 2013 at 12:25 PM, Timothy Baldridge 
> wrote:
>
>> You might want to consider switching to agents (or something else) I
>> don't think it's possible to do what you want with refs.
>>
>> Timothy Baldridge
>>
>>
>> On Wed, Jul 31, 2013 at 10:08 AM, Mike Drogalis wrote:
>>
>>> Thanks for the link. :) I understand that the behavior I'm seeing is
>>> correct. Any idea how to achieve the desired behavior, though?
>>>
>>>
>>> On Wed, Jul 31, 2013 at 12:06 PM, Timothy Baldridge <
>>> tbaldri...@gmail.com> wrote:
>>>
>>>> The answer is here:
>>>>
>>>>
>>>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LockingTransaction.java#L361
>>>>
>>>> Agents and watches are dispatched outside of the transaction locking.
>>>> This means that multiple transactions could be executing watches in
>>>> parallel, and hence execute out of order.
>>>>
>>>> Timothy Baldridge
>>>>
>>>>
>>>> On Wed, Jul 31, 2013 at 9:43 AM, Michael Drogalis >>> > wrote:
>>>>
>>>>> I can precisely exemplify the behavior here:
>>>>>
>>>>> https://gist.github.com/MichaelDrogalis/6123177
>>>>>
>>>>>
>>>>> On Wednesday, July 31, 2013 11:13:17 AM UTC-4, Michael Drogalis wrote:
>>>>>>
>>>>>> Aaron: Yep, I'm aware - and am using the value provided by the last
>>>>>> parameter.
>>>>>>
>>>>>> This is going to be tough to show the problem without bringing more
>>>>>> details of my concurrency set up.
>>>>>> I'm not sure if this will exhibit the problem, but this is what it
>>>>>> boils down to:
>>>>>>
>>>>>> https://gist.github.com/**MichaelDrogalis/6122834<https://gist.github.com/MichaelDrogalis/6122834>
>>>>>>
>>>>>> When enough threads are trying to write to the queue, the watches
>>>>>> triggered later can finish before watches triggered earlier.
>>>>>>
>>>>>>
>>>>>> On Wednesday, July 31, 2013 11:05:16 AM UTC-4, Aaron Cohen wrote:
>>>>>>>
>>>>>>> A watcher fn has 4 parameters: key, reference, old-state, new-state
>>>>>>>
>>>>>>> If you use old-state and new-state rather than the reference, you
>>>>>>> should not see your problem.
>>>>>>>
>>>>>>> --Aaron
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jul 31, 2013 at 11:00 AM, Michael Drogalis <
>>>>>>> madru...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Problem:
>>>>>>>>
>>>>>>>> I have a ref representing a queue of people in line.
>>>>>>>> I add a watch to the ref to print out the contents of the queue
>>>>>>>> whenever it changes.
>>>>>>>> Naturally, and expected, the following can happen if queuing
>>>>>>>> happens in rapid succession:
>>>>>>>>
>>>>>>>> Queue: []
>>>>>>>> 
>>>>>>>> 
>>>>>>>>
>>>>>>>> console: "Queue is Mike, John"
>>>>>>>> console: "Queue is Mike"
>>>>>>>>
>>>>>>>> I'd like to write a UI 

Re: core.async: async java.jdbc

[Timothy Baldridge]

Why not use  wrote:

> It doesn't produce a compile time error but I think it's not the correct
> code because the transaction can be committed while insert-async! is still
> executing.
>
> On Thursday, August 1, 2013 2:46:29 AM UTC+9, Sean Corfield wrote:
>
>> On Wed, Jul 31, 2013 at 10:29 AM, Alice  wrote:
>> > (go
>> >   (jdbc/db-transaction [t-con db-spec]
>> > (>
>> Does this work:
>>
>> (jdbc/db-transaction [t-con db-spec]
>>   (go
>>  (>
>> --
>> Sean A Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>> World Singles, LLC. -- http://worldsingles.com/
>>
>> "Perfection is the enemy of the good."
>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



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

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

Re: core.async: async java.jdbc

[Timothy Baldridge]

DB work is a IO operation, and IO shouldn't be done inside a go block (go
blocks use limited thread pools).

So what about something like this?

(defn handle-db [chan]
 (thread
(while true
  (let [[data result] (! result :done)

Now spin up a few of these:

(def db-chan (let [c (chan 4)]
 (dotimes [x 4]
   (handle-db c))
 c))

Now it's trivial to use this from a go block:

(defn db-async [data]
  (go
(let [c (chan)]
  (>! db-chan [data c])
  ( wrote:

> I have an async http handler and I don't want it to consume a thread.
>
> On Thursday, August 1, 2013 3:16:52 AM UTC+9, tbc++ wrote:
>
>> Why not use >
>> Timothy
>>
>>
>> On Wed, Jul 31, 2013 at 11:58 AM, Alice  wrote:
>>
>>> It doesn't produce a compile time error but I think it's not the correct
>>> code because the transaction can be committed while insert-async! is still
>>> executing.
>>>
>>> On Thursday, August 1, 2013 2:46:29 AM UTC+9, Sean Corfield wrote:
>>>
 On Wed, Jul 31, 2013 at 10:29 AM, Alice  wrote:
 > (go
 >   (jdbc/db-transaction [t-con db-spec]
 > (>>>
 Does this work:

 (jdbc/db-transaction [t-con db-spec]
   (go
  (>>>
 --
 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 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
>>> .
>>>
>>>
>>>
>>
>>
>>
>> --
>> “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.
>
>
>



-- 
“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: throwing an exception into the channel

[Timothy Baldridge]

The position of core.async is to not specify how exceptions should be done
(instead leaving it up to the user). So if that method works well for you,
write some macros and use it!

Other methods may be the use of supervisor channels. In this model, go
blocks that die would enqueue the exception into a global (or shared)
channel and the go block would then be re-started by a monitor process.

Both methods (and may more) are supported by core.async...it simply doesn't
care how you handle exceptions, but it is up to you to specify how they are
handled.

Timothy


On Wed, Jul 31, 2013 at 11:49 AM, Alice  wrote:

> It would be nice to have a function throw>! that puts an exception into
> the channel and throws it when taken, so that I can write
>
> (let [c (chan)]
>   (go (throw>! c (Exception.)))
>   (go (try
> (prn ( (catch Throwable t
>   (prn "exception")
>
> instead of
>
> (let [c (chan)]
>   (go (>! c (Exception.)))
>   (go (try
> (let [res (   (if (instance? Throwable res)
> (throw res)
> (prn res)))
> (catch Throwable t
>   (prn "exception")
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: In-order triggering of watches on mutable state

[Timothy Baldridge]

"Try using an agent send from inside a transaction. Such sends are only
dispatched if the transaction commits, and successive sends to the same
agent from a single thread are run by the agent in the same order the
thread sent them."

That's not the problem. The problem is that agent sends (just like
watchers) are dispatched outside of the transaction. So multiple threads
accessing the same refs can be releasing sends to agents at the same time.
This in turn means that the messages being sent to the agents can arrive
out-of-order since one thread could pause allowing the other to send
messages.

Something to think about though is that you probably should be dealing with
commutative operations. So instead of sending "set bank account to X" to
refs/agents, instead send "increment bank account by 10". In this way many
of these race-conditions no longer exist.

Timothy


On Thu, Aug 1, 2013 at 6:54 AM, Mike Drogalis  wrote:

> Cedric: Will agents give me the guarantee that if I have something in
> Agent A, and I want to move it to agent B, and I do this inside a
> transaction:
> - perceivers will see it in A at read point
> - perceivers will see it in B at write point
> - perceivers will never see it in neither nor both?
>
> If that's the case, which is effectively synchronous coordination (I
> think?), what do refs buy you that agents don't?
>
>
> On Thu, Aug 1, 2013 at 5:57 AM, Cedric Greevey  wrote:
>
>> Try using an agent send from inside a transaction. Such sends are only
>> dispatched if the transaction commits, and successive sends to the same
>> agent from a single thread are run by the agent in the same order the
>> thread sent them.
>>
>>
>> On Wed, Jul 31, 2013 at 1:12 PM, Mike Drogalis wrote:
>>
>>> Good reasoning; that makes a lot of sense -- even if intuitively it
>>> doesn't follow through.
>>>
>>> I'll do some more thinking about my concurrency needs and come back with
>>> a follow up question later. Thanks man!
>>>
>>>
>>> On Wed, Jul 31, 2013 at 12:51 PM, Timothy Baldridge <
>>> tbaldri...@gmail.com> wrote:
>>>
>>>> Deadlocks? Imagine a watch that ended up running a transaction against
>>>> the ref it was triggered from. Sounds insane, but it could be fairly easy
>>>> to do in a situation like this:
>>>>
>>>> ref -> calls watchers -> calls fn1 -> calls fn 2 -> calls fn3 -> starts
>>>> transaction on ref
>>>>
>>>> Since watchers are notified outside of a ref transaction deadlocking is
>>>> impossible. Inside a transaction you'd have a instant deadlock.
>>>>
>>>> Timothy Baldridge
>>>>
>>>>
>>>> On Wed, Jul 31, 2013 at 10:47 AM, Mike Drogalis 
>>>> wrote:
>>>>
>>>>> I'll play around with agents for this when I get some more free time.
>>>>>
>>>>> I find it odd that, as the sole perceiver of an indentity, events are
>>>>> capable of being perceived out of order.
>>>>> If I were watching a line queue up in person, events are obviously
>>>>> "dispatched" in order through my visual perception.
>>>>> I trust there's a good reason it's designed this way, at any rate.
>>>>>
>>>>>
>>>>> On Wed, Jul 31, 2013 at 12:25 PM, Timothy Baldridge <
>>>>> tbaldri...@gmail.com> wrote:
>>>>>
>>>>>> You might want to consider switching to agents (or something else) I
>>>>>> don't think it's possible to do what you want with refs.
>>>>>>
>>>>>> Timothy Baldridge
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 31, 2013 at 10:08 AM, Mike Drogalis >>>>> > wrote:
>>>>>>
>>>>>>> Thanks for the link. :) I understand that the behavior I'm seeing is
>>>>>>> correct. Any idea how to achieve the desired behavior, though?
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jul 31, 2013 at 12:06 PM, Timothy Baldridge <
>>>>>>> tbaldri...@gmail.com> wrote:
>>>>>>>
>>>>>>>> The answer is here:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LockingTransaction.java#L361
>>>>>>>>
>>>>>>>> Agents and watc

Re: In-order triggering of watches on mutable state

[Timothy Baldridge]

Ding! You said the magic words! For queues, can I recommend one of the
following?

http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/BlockingQueue.html

According to Rich "why doesn't Clojure provide queues? The Java ones are
just fine! Use them"

Also, if you have a large number of queues and don't want to tie up
threads, have a look a core.async (http://github.com/clojure/core.async)
it's designed exactly for this sort of thing.

With either of these you may still have some fun with having shared state
between the threads, but perhaps these approaches may help a bit.

Timothy


On Thu, Aug 1, 2013 at 7:21 AM, Mike Drogalis  wrote:

> Unfortunately, my problem is not one where the operation is communitive.
> To be concrete,
> I am dealing with multiple threads plucking elements off the top of many
> different queues, and
> putting them into a new queue. So adding element A, then B results in line
> [A, B], whereas
> adding element B, then A results in line [B, A], which aren't equal.
>
> Maybe I'm misunderstanding my problem, perhaps it is communitive. I just
> don't see it though.
>
>
> On Thu, Aug 1, 2013 at 9:13 AM, Timothy Baldridge wrote:
>
>> "
>> Try using an agent send from inside a transaction. Such sends are only
>> dispatched if the transaction commits, and successive sends to the same
>> agent from a single thread are run by the agent in the same order the
>> thread sent them."
>>
>> That's not the problem. The problem is that agent sends (just like
>> watchers) are dispatched outside of the transaction. So multiple threads
>> accessing the same refs can be releasing sends to agents at the same time.
>> This in turn means that the messages being sent to the agents can arrive
>> out-of-order since one thread could pause allowing the other to send
>> messages.
>>
>> Something to think about though is that you probably should be dealing
>> with commutative operations. So instead of sending "set bank account to X"
>> to refs/agents, instead send "increment bank account by 10". In this way
>> many of these race-conditions no longer exist.
>>
>> Timothy
>>
>>
>> On Thu, Aug 1, 2013 at 6:54 AM, Mike Drogalis wrote:
>>
>>> Cedric: Will agents give me the guarantee that if I have something in
>>> Agent A, and I want to move it to agent B, and I do this inside a
>>> transaction:
>>> - perceivers will see it in A at read point
>>> - perceivers will see it in B at write point
>>> - perceivers will never see it in neither nor both?
>>>
>>> If that's the case, which is effectively synchronous coordination (I
>>> think?), what do refs buy you that agents don't?
>>>
>>>
>>> On Thu, Aug 1, 2013 at 5:57 AM, Cedric Greevey wrote:
>>>
>>>> Try using an agent send from inside a transaction. Such sends are only
>>>> dispatched if the transaction commits, and successive sends to the same
>>>> agent from a single thread are run by the agent in the same order the
>>>> thread sent them.
>>>>
>>>>
>>>> On Wed, Jul 31, 2013 at 1:12 PM, Mike Drogalis wrote:
>>>>
>>>>> Good reasoning; that makes a lot of sense -- even if intuitively it
>>>>> doesn't follow through.
>>>>>
>>>>> I'll do some more thinking about my concurrency needs and come back
>>>>> with a follow up question later. Thanks man!
>>>>>
>>>>>
>>>>> On Wed, Jul 31, 2013 at 12:51 PM, Timothy Baldridge <
>>>>> tbaldri...@gmail.com> wrote:
>>>>>
>>>>>> Deadlocks? Imagine a watch that ended up running a transaction
>>>>>> against the ref it was triggered from. Sounds insane, but it could be
>>>>>> fairly easy to do in a situation like this:
>>>>>>
>>>>>> ref -> calls watchers -> calls fn1 -> calls fn 2 -> calls fn3 ->
>>>>>> starts transaction on ref
>>>>>>
>>>>>> Since watchers are notified outside of a ref transaction deadlocking
>>>>>> is impossible. Inside a transaction you'd have a instant deadlock.
>>>>>>
>>>>>> Timothy Baldridge
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 31, 2013 at 10:47 AM, Mike Drogalis >>>>> > wrote:
>>>>>>
>>>>>>> I'll play around with agents for this when I get some more f

Re: RPC over channels

[Timothy Baldridge]

How would a blocking call be created? How would you implement this in a way
that wouldn't lock one machine to another machine's performance. For quite
some time now, RPC has been considered a very bad idea since it mixes
reliable and unreliable semantics.

With a network you're never actually sure that a message will arrive (see
the messenger problem). And yet one expects procedure calls to be reliable.
So what happens when you make a RPC call, and then the remote server dies?
What are the semantics on the sender side?

Secondly, RPC kind of flies in the face of Clojure in general. Sending
procedure calls? Why not send data?

I've been thinking about this a lot recently, and how the entire process
can be made to be lock safe. That is, when a remote server dies, the system
continues to respond as normal (see Joe Armstrong's thesis). I'm not
completely convinced that the CSP style works well in this context, and
that instead we should perhaps model these systems after unreliable message
passing, as that's really all that you are promised by the network protocol
anyways.

Timothy Baldridge


On Thu, Aug 1, 2013 at 9:32 AM,  wrote:

> With core.async, cljzmq <https://github.com/zeromq/cljzmq>, and now
> zmq-async <https://github.com/lynaghk/zmq-async>, there's an opportunity
> to link RPC to channels and be free of the underlying transport system.
> I'm proposing an RPC library that sends and receives data over channels.
>
> The idea is to have a two-way communication context as a map with a
> send-channel, receive-channel, serializer, and deserializer.  The user
> would be responsible for the transport mechanism between the "client" and
> the "server".
>
> When a user makes a request, the library would create a map to follow the
> JSON-RPC <http://www.jsonrpc.org/specification> and attach a UUID to it
> then send it down the send-channel.  This UUID could be used in conjunction
> with pulling items off of the receive-channel to handle responses.
>
> The data flow would be:
> user-request -> wrap-in-specification -> client-serializer ->
> client-send-channel -> transport-provider -> server deserializer ->
> server-receive-channel -> user-function -> server-serializer ->
> server-send-channel -> transport-provider -> client-deserializer ->
> unwrap-specification -> client-receive-channel -> user-response-handling.
>
> The library would be responsible for wrapping the requests and responses
> according to the specification, but not the serialization mechanism nor the
> transport, since those could be very different depending on the problem.
> Utilities could be provided for a "blocking call" and managing cycling
> through responses on the receive-channel in order to find a specific
> response that has not yet been processed.
>
> As an example, the above workflow should be able to work seamlessly with
> the channels provided by zmq-async.  The send-channels provided would be
> used as is, and the receive-channels would be used with an additional
> channel outside of it to take the responses off and deserialize them before
> returning to the user.  The transport provider, of course, would be ZeroMQ.
>
> Are there any projects already doing this?  Would people be interested?
> Any feedback?
>
> -ToBeReplaced
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: RPC over channels

[Timothy Baldridge]

RPC ties a local process (and all the memory its currently using) to a
remote process. It glosses over the fact that that the link between these
two processes is quite unreliable. In his thesis, Joe Armstrong also points
that this system is not only susceptible to hardware/network failure, it's
also very susceptible to programming failures. A bug in your code could
cause every 100th RPC call to fail, for example.

So instead of all of this, Erlang (or actually Erlang's OTP libraries)
proposes a different view:

1) all messages are sent async and unreliable. This is the way networks are
designed anyways, if you sent a message to a remote system and it gets
thrown into a queue, you really don't know what happens to that message in
the end, except by asking the remote system again, and again until you
finally get an ACK.

2) If we follow the above model, then we can start programming in a
fail-fast mode. This is what OTP is based on. Supervisor processes that
reset dead sub processes. This is also why I'm not a fan of populating
error messages across channels. Instead, errors should kill go blocks, and
then those blocks should be restarted by supervisors.

So RPC assumes that every call will succeed. Message passing systems assume
that it's kind-of-sort-of-not-really-likely that your message will arrive
at the remote system. It's a pessimistic view of the world. And with the
systems I work with, this is the best approach.

So I guess this is a super long way of saying I love the OTP style and
would love to see it ported to core.async. But RPC is not the way, blocking
send/recv is not the way. To get reliable systems you need your system to
always be capable of forward progress, and having a local process tightly
coupled to a remote process will not get you there.

Timothy


On Thu, Aug 1, 2013 at 1:55 PM, ToBeReplaced  wrote:

>  A client could use a timeout channel as its receive channel to get
> timeouts on a blocking call, though I don't think that's the right way to
> do it.  Alternatively, implementing a blocking call with an optional
> timeout wouldn't be difficult, it just can't be the default.
>
> I think if you disallowed nil as a response, then it would be easy to use
> a variety of different blocking calls -- wait forever, wait 30 seconds,
> wait until (f) returns truthy, etc.
>
> -ToBeReplaced
>
>
> On 08/01/2013 03:36 PM, Cedric Greevey wrote:
>
>  On Thu, Aug 1, 2013 at 1:09 PM,  wrote:
>
>> There would be no intent to solve the messenger problem explicitly --
>> those semantics are up to the user.  By default, in the case of server
>> death, the client side will just no longer receive responses on its
>> receive-channel.  In the case of a blocking call, this means that the
>> client side will hang.
>>
>
>  Ugh. At the *very* least it should eventually return with some kind of a
> timeout exception.
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 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/P95cOfuXBUs/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.
>
>
>



-- 
“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:/

Re: core.async: macro and visibilities of async operations

[Timothy Baldridge]

Your macro is incorrect. Notice what happens to un-namespaced symbols
inside a syntax quote:

(ns 'user)
(macroexpand `(foo))

=>(user/foo)

So your use of >! is getting translated into mynamespace/>!. Core.async
sees your macro and expands it, it just doesn't condsider mynamespace/>! to
be a put! call. Instead it sees it as any other function.

To get this to work the way you want, you need to do one of the following

`(~'>! c 42)

or

`(clojure.core.async/>! c 42)

Or, if you've done the following

(ns user
  (require [clojure.core.async :as async))

Then you can do this:

`(async/>! c 42)

Timothy Baldridge


On Mon, Aug 5, 2013 at 5:52 AM, Tassilo Horn  wrote:

> Alice  writes:
>
> > I didn't know that macros can do that!
>
> Then you might want to have a look at `macroexpand-1` and `macroexpand`
> from clojure.core and `mexpand-1`, `mexpand`, and `mexpand-all` from
> clojure.tools.macro.
>
> Bye,
> Tassilo
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: macro and visibilities of async operations

[Timothy Baldridge]

Right, so if syntax quote fully qualifies unqualified symbols with the
current namespace, what good is user/>! to core.async? It has no clue that
you want that to be a put and not something else. So yes, either async/>!
or a fully qualified symbol is what you want here.

Timothy Baldridge


On Mon, Aug 5, 2013 at 7:40 AM, Alice  wrote:

> I'm not sure I understand your point. Syntax-quote fully qualifies
> unqualified symbols with the current namespace, so it shouldn't be a
> problem as long as I don't redefine the >! in the file that defines the
> macro. On the other hand, ~'>! would be dangerous because you don't know
> what it will be evaluated to in the user's namespace.
>
>
> On Monday, August 5, 2013 9:39:16 PM UTC+9, tbc++ wrote:
>
>> Your macro is incorrect. Notice what happens to un-namespaced symbols
>> inside a syntax quote:
>>
>> (ns 'user)
>> (macroexpand `(foo))
>>
>> =>(user/foo)
>>
>> So your use of >! is getting translated into mynamespace/>!. Core.async
>> sees your macro and expands it, it just doesn't condsider mynamespace/>! to
>> be a put! call. Instead it sees it as any other function.
>>
>> To get this to work the way you want, you need to do one of the following
>>
>> `(~'>! c 42)
>>
>> or
>>
>> `(clojure.core.async/>! c 42)
>>
>> Or, if you've done the following
>>
>> (ns user
>>   (require [clojure.core.async :as async))
>>
>> Then you can do this:
>>
>> `(async/>! c 42)
>>
>> Timothy Baldridge
>>
>>
>> On Mon, Aug 5, 2013 at 5:52 AM, Tassilo Horn  wrote:
>>
>>> Alice  writes:
>>>
>>> > I didn't know that macros can do that!
>>>
>>> Then you might want to have a look at `macroexpand-1` and `macroexpand`
>>> from clojure.core and `mexpand-1`, `mexpand`, and `mexpand-all` from
>>> clojure.tools.macro.
>>>
>>> Bye,
>>> Tassilo
>>>
>>> --
>>> --
>>> 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<http://groups.google.com/group/clojure?hl=en>
>>> ---
>>> You received this message because you 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<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.
>
>
>



-- 
“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: macro and visibilities of async operations

[Timothy Baldridge]

This works fine on my box:

foo=> (ns foo (require [clojure.core.async :refer [go !!]]))
nil
foo=> (defmacro foo
 #_=>   [c]
 #_=>   `(

foo=> (let [c (chan)]
 #_=>   (go (prn (foo c)))
 #_=>   (>!! c :hi))
:hi
nil
foo=>

Timothy Baldridge


On Mon, Aug 5, 2013 at 7:59 AM, Alice  wrote:

> I didn't have to fully qualify >! because I referred it using :refer. I'm
> Sorry if that was not clear.
>
>
> On Monday, August 5, 2013 10:45:16 PM UTC+9, tbc++ wrote:
>
>> Right, so if syntax quote fully qualifies unqualified symbols with the
>> current namespace, what good is user/>! to core.async? It has no clue that
>> you want that to be a put and not something else. So yes, either async/>!
>> or a fully qualified symbol is what you want here.
>>
>> Timothy Baldridge
>>
>>
>> On Mon, Aug 5, 2013 at 7:40 AM, Alice  wrote:
>>
>>> I'm not sure I understand your point. Syntax-quote fully qualifies
>>> unqualified symbols with the current namespace, so it shouldn't be a
>>> problem as long as I don't redefine the >! in the file that defines the
>>> macro. On the other hand, ~'>! would be dangerous because you don't know
>>> what it will be evaluated to in the user's namespace.
>>>
>>>
>>> On Monday, August 5, 2013 9:39:16 PM UTC+9, tbc++ wrote:
>>>
>>>> Your macro is incorrect. Notice what happens to un-namespaced symbols
>>>> inside a syntax quote:
>>>>
>>>> (ns 'user)
>>>> (macroexpand `(foo))
>>>>
>>>> =>(user/foo)
>>>>
>>>> So your use of >! is getting translated into mynamespace/>!. Core.async
>>>> sees your macro and expands it, it just doesn't condsider mynamespace/>! to
>>>> be a put! call. Instead it sees it as any other function.
>>>>
>>>> To get this to work the way you want, you need to do one of the
>>>> following
>>>>
>>>> `(~'>! c 42)
>>>>
>>>> or
>>>>
>>>> `(clojure.core.async/>! c 42)
>>>>
>>>> Or, if you've done the following
>>>>
>>>> (ns user
>>>>   (require [clojure.core.async :as async))
>>>>
>>>> Then you can do this:
>>>>
>>>> `(async/>! c 42)
>>>>
>>>> Timothy Baldridge
>>>>
>>>>
>>>> On Mon, Aug 5, 2013 at 5:52 AM, Tassilo Horn  wrote:
>>>>
>>>>> Alice  writes:
>>>>>
>>>>> > I didn't know that macros can do that!
>>>>>
>>>>> Then you might want to have a look at `macroexpand-1` and `macroexpand`
>>>>> from clojure.core and `mexpand-1`, `mexpand`, and `mexpand-all` from
>>>>> clojure.tools.macro.
>>>>>
>>>>> Bye,
>>>>> Tassilo
>>>>>
>>>>> --
>>>>> --
>>>>> 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<http://groups.google.com/group/clojure?hl=en>
>>>>> ---
>>>>> You received this message because you 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/**grou**ps/opt_out<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 yo

Re: PoC: Combining Wikidata and Clojure logic programming

[Timothy Baldridge]

This looks a re-implementation of many of the goals of Datomic. Perhaps you
can use Datomic as a datastore, and then use Datomic's datalog, or a custom
query engine (such as core.logic
https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic/datomic.clj)
to do your queries?

Timothy


On Mon, Aug 5, 2013 at 10:52 AM, David Nolen  wrote:

> Very interesting. The rel feature is really still a bit of an experimental
> thing and we'd like to replace it eventually with something less
> problematic like pldb http://github.com/threatgrid/pldb.
>
> Still, core.logic isn't really a database and your needs may be better
> served by something with different goals.
>
> David
>
>
> On Mon, Aug 5, 2013 at 12:41 PM, Mingli Yuan wrote:
>
>> Hi, folks,
>>
>> After one night quick work, I had gave a proof-of-concept to demonstrate
>> the feasibility that we can combine Wikidata and Clojure logic programming
>> together.
>>
>> The source code is at here:
>> https://github.com/mountain/knowledge
>>
>> An example of an entity:
>>
>> https://github.com/mountain/knowledge/blob/master/src/entities/albert_einstein.clj
>>
>> Example of types:
>> https://github.com/mountain/knowledge/blob/master/src/meta/types.clj
>>
>> Example of predicates:
>> https://github.com/mountain/knowledge/blob/master/src/meta/properties.clj
>>
>> Example of inference:
>> https://github.com/mountain/knowledge/blob/master/test/knowledge/test.clj
>>
>> Also we found it is very easy to get any other language version than
>> English.
>>
>> Since I am new to Clojure logic programming, I have questions for the way
>> I take - what will happen when we have millions of triples? Should I
>> take another approach by using some RDF store?
>>
>>- How many memory will it cost?
>>- How about the performance?
>>- How about the loading process of one million clojure source file or
>>java class file?
>>
>> Hope you can give some helpful comments. Thanks in advance.
>>
>> Regards,
>> Mingli
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from 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: [Proposal] Simplified 'ns' declaration

[Timothy Baldridge]

I don't really understand why we would need to simplify something that is
already so simple. Teach people the following:

(ns my-namespace
  ...calls to import fns...)

Where import functions can be either :require or :import:

(:import [clojure.lang Number AFn]) ;; use for Java imports

(:require [clojure.string :as string :refer [split]]) ;; use for clojure
imports

:refer :all can be used to refer everything

Boom! everything you need to know to get started with Clojure's ns. What's
the problem?

That being said, if you really want your syntax above, nothing is stopping
you from using your own import function, they are pluggable after all:

(ns foo
  (:println "Hello World"))

Hello World
=> nil

So you could easily write something like this:

(ns foo
  (:simple-ns/simple
[clojure.core match logic async]))

Timothy Baldridge




On Mon, Aug 5, 2013 at 11:21 AM, Greg  wrote:

> OK, that's enough from me on this for now, gotta run (lot of work to do!).
>
>
> Sorry, after sending that, I couldn't resist simplifying 'ns' even further!
>
> (ns two.namespace
>   "optional doc string goes here"
>   [core :refer-all [matrix math bs]]
>   [clojure :refer-all [core :except (ancestors printf)]]
>   [ring.adapter.jetty :refer (run-jetty)]
>   [ring.middleware.file :refer (wrap-file)]
>   [ring.middleware.file-info :refer (wrap-file-info)]
>   [ring.middleware.stacktrace :refer (wrap-stacktrace)]
>   [ring.util.response :refer (file-response)]
>   [one :refer reload]
>   [one :refer middleware]
>   [net.cgrand :refer [enlive-html :as html]]
>   [org.apache.maven.artifact.resolver :refer ArtifactResolver]
>   [java.io :refer File])
>
>
> Look at the beauty of that! :-D
>
> Now not only have we gotten rid of :use, :require, :import,
> :refer-clojure, but we're starting to chip away at the mountain of keywords
> and we still have *all* of the power we had before! We got rid of :as-ns,
> :as-class and :all!
>
> Keep simplifying till you can't simplify anymore! That's the Lisp way! :-)
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Aug 5, 2013, at 1:14 PM, Greg  wrote:
>
> (ns one.fresh-server
>  [core :refer-all [matrix math bs]])
>
>
> I like it.
>
>
> Ideally, the whole thing would be well thought out enough to allow these
> very basic principles to be combined in complicated ways (kinda like the
> idea behind Lisp itself).
>
> Getting rid of ambiguities might help make it more readable and
> "generalizable". For example, it could be specified that vectors can
> contain only namespaces and keywords, and lists can only contain functions.
>
> If that rule is applied, the original example plus the :refer-all keyword
> would look like this:
>
> *New School:*
>
> (ns two.namespace
>   "optional doc string goes here"
>   [core :refer-all [matrix math bs]]
>   [clojure :refer-all [core :except (ancestors printf)]]
>   [ring.adapter.jetty :refer (run-jetty)]
>   [ring.middleware.file :refer (wrap-file)]
>   [ring.middleware.file-info :refer (wrap-file-info)]
>   [ring.middleware.stacktrace :refer (wrap-stacktrace)]
>   [ring.util.response :refer (file-response)]
>   [one.reload :as-ns]
>   [one.middleware :as-ns]
>   [net.cgrand.enlive-html :as html]
>   [org.apache.maven.artifact.resolver.ArtifactResolver :as-class]
>   [java.io.File :as-class])
>
>
> Now the functions are emphasized as being functions (because only
> functions are allowed in lists).
>
> Notice that this:
>
> [clojure.core :refer-except (ancestors printf)]
>
>
> Has now changed to:
>
> [clojure :refer-all [core :except (ancestors printf)]]
>
>
> What if we want to :refer-all everything that's in the first level of the
> namespace? I see no reason why we couldn't just do this then:
>
> [:refer-all [core]]
>
>
> Or optionally, in the case where there's just one namespace in the vector:
>
> [:refer-all core]
>
>
> OK, that's enough from me on this for now, gotta run (lot of work to do!).
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Aug 5, 2013, at 12:59 PM, Lee Spector  wrote:
>
>
> On Aug 5, 2013, at 12:41 PM, Greg wrote:
>
> Can you build in a way to get :require :refer :all to work on a bunch of
> sub-namespaces together on one line, as one currently can with :use,
> without listing each namespace completely on a separate line with a
> separate :refer :all?
>
>
> Certainly. I'm not saying this is how the exact syntax would go, but the
> general id

Re: [Proposal] Simplified 'ns' declaration

[Timothy Baldridge]

There's no syntax to ns, ns simply assumes that everything after the
symbol/doc is in the form (function-to-execute & args). The only special
case is gen-class, and even that is fixed up to look like everything else.
Why invent special syntax where none exists now?

I think the issue is more around people not understanding the difference
(and problems behind) refer vs import instead of an actual problem with the
require macro.

On that subject when last discussed, it was mentioned that Clojure doesn't
have a import * method because it's basically impossible to implement.

To quote Rich: "Java packages are not enumerable. The only way to do so is
to walk the classpath/jars etc. I don't think import * is a good idea, as
it brings more into a namespace than you are going to use, making Clojure's
namespace enumeration, e.g. ns-imports, that much less useful. "

https://groups.google.com/forum/#!searchin/clojure/import$20wildcard/clojure/-gCg_0wmT5o/LnxDCU6W538J

Timothy


On Mon, Aug 5, 2013 at 11:58 AM, Greg  wrote:

> I don't really understand why we would need to simplify something that is
> already so simple.
>
>
> Because it's not simple to many people. It's one of the main things people
> use as an example when discussing complexity in clojure.
>
> There are many threads and blog posts where people explain why they
> consider the "ns" declaration to be complicated.
>
>
> That being said, if you really want your syntax above, nothing is stopping
> you from using your own import function
>
>
> When I have time, I might do something like that, but not the way you
> illustrated, because that's unnecessarily complicated in my view.
>
> I might either add a hook to to 'ns', or if that's not possible, overwrite
> it to support both syntaxes, or create a different name, like "include".
>
> Then it would be this:
>
> (include two.namespace
>
>   [clojure :refer-all [core :except (ancestors printf)]]
>   [core :refer-all [matrix math bs]]
>   [ring.adapter.jetty :refer (run-jetty)]
>   [ring.middleware.file :refer (wrap-file)]
>   [ring.middleware.file-info :refer (wrap-file-info)]
>   [ring.middleware.stacktrace :refer (wrap-stacktrace)]
>   [ring.util.response :refer (file-response)]
>   [one :refer [reload middleware]]
>
>   [net.cgrand :refer [enlive-html :as html]]
>   [org.apache.maven.artifact.resolver :refer ArtifactResolver]
>   [java.io :refer File])
>
>
> Instead of:
>
>
> (ns one.fresh-server
>   (:refer-clojure :exclude [ancestors printf])
>   (:use core.matrix
> [ring.adapter.jetty :only (run-jetty)]
> [ring.middleware.file :only (wrap-file)]
> [ring.middleware.file-info :only (wrap-file-info)]
> [ring.middleware.stacktrace :only (wrap-stacktrace)]
> [ring.util.response :only (file-response)])
>   (:require [one.reload :as reload]
> [one.middleware :as middleware]
> [net.cgrand.enlive-html :as html])
>   (:import (org.apache.maven.artifact.resolver ArtifactResolver)
>(java.io File
>
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Aug 5, 2013, at 1:46 PM, Timothy Baldridge 
> wrote:
>
> I don't really understand why we would need to simplify something that is
> already so simple. Teach people the following:
>
> (ns my-namespace
>   ...calls to import fns...)
>
> Where import functions can be either :require or :import:
>
> (:import [clojure.lang Number AFn]) ;; use for Java imports
>
> (:require [clojure.string :as string :refer [split]]) ;; use for clojure
> imports
>
> :refer :all can be used to refer everything
>
> Boom! everything you need to know to get started with Clojure's ns. What's
> the problem?
>
> That being said, if you really want your syntax above, nothing is stopping
> you from using your own import function, they are pluggable after all:
>
> (ns foo
>   (:println "Hello World"))
>
> Hello World
> => nil
>
> So you could easily write something like this:
>
> (ns foo
>   (:simple-ns/simple
> [clojure.core match logic async]))
>
> Timothy Baldridge
>
>
>
>
> On Mon, Aug 5, 2013 at 11:21 AM, Greg  wrote:
>
>> OK, that's enough from me on this for now, gotta run (lot of work to do!).
>>
>>
>> Sorry, after sending that, I couldn't resist simplifying 'ns' even
>> further!
>>
>> (ns two.namespace
>>   "optional doc string goes here"
>>   [core :refer-all [matrix math bs]]
>>   [clojure :refer-all [core :except (ancesto

Re: [Proposal] Simplified 'ns' declaration

[Timothy Baldridge]

For this to even have a chance at making it into Clojure you need to
consider all the edge cases. So I have two questions

a) How do you plan on having this backwards-compatible with existing code?
You will have to support both the old and new versions on the same Clojure
compiler. Notice that this is completely valid in the current compiler:

(ns foo
  [require [clojure.string :as c]])

b) You will also need a very concise, clear definition on why the new
approach is better. Once again, please notice that your "old school"
example could also have been written in a much more concise manner:

(ns one.fresh-server
  (:refer-clojure :exclude [ancestors printf])
  (:require [one.reload :as reload]
[one.middleware :as middleware]
[net.cgrand.enlive-html :as html]
[ring.adapter.jetty :refer (run-jetty)]
[ring.middleware.file :refer (wrap-file)]
[ring.middleware.file-info :refer (wrap-file-info)]
[ring.middleware.stacktrace :refer (wrap-stacktrace)]
[ring.util.response :refer (file-response)])
  (:import (org.apache.maven.artifact.resolver ArtifactResolver)
   (java.io File

As a support to the current method let me point out the following. We have
3 constructs in this case, each only does one thing:

a) refer-clojure - allows you to :exclude certain symbols from being
imported by default
b) require loads clojure namespaces
c) import loads Java classes

Your example also has the following problem:

bar=> (ns foo.bar)
nil
foo.bar=>

foo.bar=> (ns foo)
nil
foo=> (defprotocol bar (dostuff [this]))
bar
foo=> (ns user)
nil
user=> (ns user (:require [foo.bar]) (:import [foo.bar]))
nil
user=> bar
foo.bar
user=> (class bar)
java.lang.Class

With the current design we can clearly distinguish between loading a java
class, and loading a clojure namespace. In the example above, we need this
if we want to clearly load both the java interface foo.bar as well as the
clojure namespace foo.bar.

How would the new syntax express such a ns statement, and how would the
semantics be clearer in this approach?

Timothy Baldridge


On Tue, Aug 6, 2013 at 8:51 AM, Greg  wrote:

> Folks, I feel this thread has gotten derailed by the discussion of
> implicit imports.
>
> This thread is not about that. It's not about asterisks, or :use, it's
> about a simplified syntax for the 'ns' form.
>
> PLEASE use the "Re: Can we please deprecate the :use directive ?" thread
> to discuss whether implicit imports are a good idea or not. All of comments
> here about implicitly interning symbols from a namespace are just as
> relevant to this proposed syntax as they are to the currently existing one.
>
> Once again, the (latest version) of the syntax being proposed is:
>
> *Old School:*
>
> (ns one.fresh-server
>   (:refer-clojure :exclude [ancestors printf])
>   (:use core.matrix
> [ring.adapter.jetty :only (run-jetty)]
> [ring.middleware.file :only (wrap-file)]
> [ring.middleware.file-info :only (wrap-file-info)]
> [ring.middleware.stacktrace :only (wrap-stacktrace)]
> [ring.util.response :only (file-response)])
>   (:require [one.reload :as reload]
> [one.middleware :as middleware]
> [net.cgrand.enlive-html :as html])
>   (:import (org.apache.maven.artifact.resolver ArtifactResolver)
>(java.io File
>
>
> *New School:*
>
> (ns two.namespace
>   [clojure [core :except (ancestors printf)]]
>   [core [matrix math bs]] ; same as (:use (core matrix math bs))
>   [[some-ns]] ; same as (:use some-ns)
>   [ring.adapter.jetty (run-jetty :as jetty)]
>   [ring.middleware.file ("warp-*")] ; refers all functions beginning with
> "wrap-"
> ; regex not supported because too
> confusing
>   [ring.middleware.file-info (wrap-file-info)]
>   [ring.middleware.stacktrace (wrap-stacktrace)]
>   [ring.util.response (file-response)]
>   [one reload middleware]
>   [net.cgrand enlive-html :as html]
>   [org.apache.maven.artifact.resolver ArtifactResolver]
>   [java.io File InputStream])
>
>
> *Four key rules to the new syntax:*
>
> 1) vectors can only contain namespaces and the keywords :as and :except
> 2) vectors within vectors will refer everything in the the namespaces
> specified in them
> 3) lists can only contain functions and the keyword :as to rename
> functions.
> 4) namespaces are referred by placing a space after the namespace prefix
>
> Also, an added feature/rule is that globbing-based strings can be used to
> save on typing (as shown in the example above).
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
>

Re: [Proposal] Simplified 'ns' declaration

[Timothy Baldridge]

>> (ns foo
>>  [require [clojure.string :as c]])


>> I've never seen that before. What does it do?

It's exactly the same as a normal require. Ns allows vectors/seqs
symbols/keywords to be used interchangeably. Some people use (:require)
others use (require), ns just uses ns/namespace to get the data on the
first of each item after the symbol.


Yeah, there's a bug in the code, but let me try to redefine the problem.
Assume I have a namespace called foo that defines a protocol (and hence an
interface) called bar. I then also have a namespace called foo.bar. How do
I tell the new syntax to import each? If I simply say "go get foo.bar" what
are you going to load, the .clj file, or the java interface?

Timothy


On Tue, Aug 6, 2013 at 9:39 AM, Phillip Lord
wrote:

> Greg  writes:
>
> >> I am dubious about distinguishing between lists and vectors. Currently,
> >> as far as I can tell, the ns is agnostic, and only cares about them
> >> being sequential. This is probably one of the sources of confusion for
> >> beginners -- they see both and don't see why
> >
> > The reason for distinguishing between lists and vectors is as you say,
> it's
> > confusing for beginnings. Also, it allows the syntax to have greater
> > functionality/power.
>
> Really dubious about this. Having to keep in my head when I need to use
> [] and when I need to use () is a significant problem when starting. It
> was my realisation that for the ns declaration you don't that made
> things easier.
>
> >> Also, I am confused as to how you distinguish between
> >> [core [matrix math bs]] being equivalent to :use while
> >> Is [one reload middleware] also :use? Or :require?
> >
> > Nested vectors = :use.
> >
> > Thus, as the comment says, [core [matrix math bs]] => (:use (core matrix
> math
> > bs))
> >
> > It's a bit confusing in the current syntax (if I have it correct),
> because
> > from it, it's not clear why "core" isn't "used".
> >
> > [one reload middleware]
> >
> > Is equivalent to:
> >
> > (:require [one.reload :as reload]
> >   [one.middleware :as middleware])
>
> Scares me to be honest. You now have an implicit alias ":as reload", and
> are distinguishing between having an alias and having no qualification
> by nesting or otherwise.
>
> I do like the idea of enforcing nesting though in
>
> [core [matrix math bs]]
>
> Phil
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: [Proposal] Simplified 'ns' declaration

[Timothy Baldridge]

>> I just view that as yet another reason to change the syntax.

You're going to have to prove the new syntax better, because now you have
to justify it in the face of breaking existing code.


>>I think part of the problem here is that I'm not very well educated on
this topic yet. Perhaps you can help:

>> - If you defined a protocol Foo in user, is it referenced as user.Foo
from another ns, or user/Foo ? Or both??

user.Foo is the interface defined by the protocol, user/Foo is the protocol
information

>> - Can you have a function Foo at the same time as a protocol Foo in the
same namespace?

No.

>> - What about records? Can you have a record Foo and a protocol Foo?

No

>> - Can you have a class Foo and an protocol Foo?

Yes

Clojure and I are already confused here:

baz=> (defprotocol g (dostuff [this]))
g
baz=> g
{:on-interface baz.g, :on baz.g, :sigs {:dostuff {:doc nil, :arglists
([this]), :name dostuff}}, :var #'baz/g, :method-map {:dostuff :dostuff},
:method-builders {#'baz/dostuff #}}
baz=> (defn g [] "a")
#'baz/g
baz=> g
#

You can't get the protocol back it's been redefined. However the interface
baz.g still exists.

The problem is that you are confusing Java classes with Clojure Namespaces.
Clojure defines namespaces where it keeps vars (see Namespace.java in the
clojure source). So creating a protocol in Clojure does two things. 1) it
creates a java interface with the name of the protocol. 2) it defines a
hashmap assigned to a var in a Clojure namespace that describes how to find
that interface.

This is why I go back to my original comments. You are taking two
completely different concepts (interacting with Java classes, and
interacting with Clojure namespaces) and smashing them together in an
arbitrary syntax. I would assert that this is a very bad idea.

Instead let's keep separate things separate. The fact that we have Java
classes and Clojure namespaces is a fact of life when programming Clojure.
We should be educating users about the differences instead of hiding it
behind custom syntax.

Timothy


On Tue, Aug 6, 2013 at 10:41 AM, Greg  wrote:

> > It's exactly the same as a normal require. Ns allows vectors/seqs
> symbols/keywords to be used interchangeably. Some people use (:require)
> others use (require), ns just uses ns/namespace to get the data on the
> first of each item after the symbol.
>
> Wow that's confusing!
>
> I just view that as yet another reason to change the syntax.
>
> To answer your question though, I'd do both syntax's a favor and interpret
> "[require [clojure.string :as c]]" using the new syntax. It would save a
> lot of newbies many headaches. Think of the newbies.
>
> > Yeah, there's a bug in the code, but let me try to redefine the problem.
> Assume I have a namespace called foo that defines a protocol (and hence an
> interface) called bar. I then also have a namespace called foo.bar. How do
> I tell the new syntax to import each? If I simply say "go get foo.bar" what
> are you going to load, the .clj file, or the java interface?
>
> I think part of the problem here is that I'm not very well educated on
> this topic yet. Perhaps you can help:
>
> - If you defined a protocol Foo in user, is it referenced as user.Foo from
> another ns, or user/Foo ? Or both??
>
> - Can you have a function Foo at the same time as a protocol Foo in the
> same namespace?
>
> - What about records? Can you have a record Foo and a protocol Foo?
>
> - Can you have a class Foo and an protocol Foo?
>
> Clojure and I are already confused here:
>
> baz=> (defprotocol g (dostuff [this]))
> g
> baz=> g
> {:on-interface baz.g, :on baz.g, :sigs {:dostuff {:doc nil, :arglists
> ([this]), :name dostuff}}, :var #'baz/g, :method-map {:dostuff :dostuff},
> :method-builders {#'baz/dostuff # baz$eval300$fn__301@7c2aa00c>}}
> baz=> (defn g [] "a")
> #'baz/g
> baz=> g
> #
>
> And I'm not sure how to get the protocol back...
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Aug 6, 2013, at 11:43 AM, Timothy Baldridge 
> wrote:
>
> >> >> (ns foo
> >> >>  [require [clojure.string :as c]])
> >
> > >> I've never seen that before. What does it do?
> >
> > It's exactly the same as a normal require. Ns allows vectors/seqs
> symbols/keywords to be used interchangeably. Some people use (:require)
> others use (require), ns just uses ns/namespace to get the data on the
> first of each item after the symbol.
> >
> >
> > Yeah, there's a bug in the code, but let me try to redefine 

Re: [Proposal] Simplified 'ns' declaration

[Timothy Baldridge]

Sure, put this into a repl:

(ns foo)

(defprotocol IBar
  (do-stuff [this]))

(ns user
  (require [foo])
  (import [foo IBar]))

(class foo/IBar)
(class foo.IBar)


If this syntax were unified into something like you suggest we have a
problem:

(ns user
  [foo IBar]) ;; What is IBar, a class or a var?

Timothy


On Tue, Aug 6, 2013 at 10:56 AM, Greg  wrote:

> >> Yeah, there's a bug in the code, but let me try to redefine the
> problem. Assume I have a namespace called foo that defines a protocol (and
> hence an interface) called bar. I then also have a namespace called
> foo.bar. How do I tell the new syntax to import each? If I simply say "go
> get foo.bar" what are you going to load, the .clj file, or the java
> interface?
>
> It would also help to have an example of how it's currently done.
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Aug 6, 2013, at 12:41 PM, Greg  wrote:
>
> >> It's exactly the same as a normal require. Ns allows vectors/seqs
> symbols/keywords to be used interchangeably. Some people use (:require)
> others use (require), ns just uses ns/namespace to get the data on the
> first of each item after the symbol.
> >
> > Wow that's confusing!
> >
> > I just view that as yet another reason to change the syntax.
> >
> > To answer your question though, I'd do both syntax's a favor and
> interpret "[require [clojure.string :as c]]" using the new syntax. It would
> save a lot of newbies many headaches. Think of the newbies.
> >
> >> Yeah, there's a bug in the code, but let me try to redefine the
> problem. Assume I have a namespace called foo that defines a protocol (and
> hence an interface) called bar. I then also have a namespace called
> foo.bar. How do I tell the new syntax to import each? If I simply say "go
> get foo.bar" what are you going to load, the .clj file, or the java
> interface?
> >
> > I think part of the problem here is that I'm not very well educated on
> this topic yet. Perhaps you can help:
> >
> > - If you defined a protocol Foo in user, is it referenced as user.Foo
> from another ns, or user/Foo ? Or both??
> >
> > - Can you have a function Foo at the same time as a protocol Foo in the
> same namespace?
> >
> > - What about records? Can you have a record Foo and a protocol Foo?
> >
> > - Can you have a class Foo and an protocol Foo?
> >
> > Clojure and I are already confused here:
> >
> > baz=> (defprotocol g (dostuff [this]))
> > g
> > baz=> g
> > {:on-interface baz.g, :on baz.g, :sigs {:dostuff {:doc nil, :arglists
> ([this]), :name dostuff}}, :var #'baz/g, :method-map {:dostuff :dostuff},
> :method-builders {#'baz/dostuff # baz$eval300$fn__301@7c2aa00c>}}
> > baz=> (defn g [] "a")
> > #'baz/g
> > baz=> g
> > #
> >
> > And I'm not sure how to get the protocol back...
> >
> > - Greg
> >
> > --
> > Please do not email me anything that you are not comfortable also
> sharing with the NSA.
> >
> > On Aug 6, 2013, at 11:43 AM, Timothy Baldridge 
> wrote:
> >
> >>>>> (ns foo
> >>>>> [require [clojure.string :as c]])
> >>
> >>>> I've never seen that before. What does it do?
> >>
> >> It's exactly the same as a normal require. Ns allows vectors/seqs
> symbols/keywords to be used interchangeably. Some people use (:require)
> others use (require), ns just uses ns/namespace to get the data on the
> first of each item after the symbol.
> >>
> >>
> >> Yeah, there's a bug in the code, but let me try to redefine the
> problem. Assume I have a namespace called foo that defines a protocol (and
> hence an interface) called bar. I then also have a namespace called
> foo.bar. How do I tell the new syntax to import each? If I simply say "go
> get foo.bar" what are you going to load, the .clj file, or the java
> interface?
> >>
> >> Timothy
> >>
> >>
> >> On Tue, Aug 6, 2013 at 9:39 AM, Phillip Lord <
> phillip.l...@newcastle.ac.uk> wrote:
> >> Greg  writes:
> >>
> >>>> I am dubious about distinguishing between lists and vectors.
> Currently,
> >>>> as far as I can tell, the ns is agnostic, and only cares about them
> >>>> being sequential. This is probably one of the sources of confusion for
> >>>> beginners -- they see both and don't see why
> >>>
> >

Re: core.async: loop bindings can't see prior brindings

[Timothy Baldridge]

Yep, this is bug, please submit a bug report through JIRA, and I'll try to
get it fixed ASAP.

Timothy


On Thu, Aug 8, 2013 at 9:22 AM, David Nolen  wrote:

> You can report issues here: http://dev.clojure.org/jira/browse/ASYNC
>
>
>
> On Thu, Aug 8, 2013 at 7:02 AM, Kemar  wrote:
>
>> Hi there,
>>
>> it seems that loop bindings cant's see prior bindings made in
>> the same loop when the loop is in a go block:
>>
>> (require '[clojure.core.async :refer [go]])
>>> (go (loop [x 41 y (inc x)] (println y)))
>>>
>>
>> Rather than printing 42, it either complains that x can't be
>> resolved in that context (in Clojure), or that x ist an undeclared
>> Var (in ClojureScript).
>>
>> Cheers,
>> Kevin
>>
>>
>> P.S.: is there a better place to post bug reports for core.async?
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from 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: tools for minimizing forward declaration

[Timothy Baldridge]

And also note that protocol functions and multimethods also don't need
forward declarations as they are polymorphic and the interface is defined
ahead of time. So mutually recursive multimethods don't need to use declare
at all.

Timothy Baldridge


On Fri, Aug 16, 2013 at 10:53 AM, Stuart Sierra  wrote:

> Forward declarations are rarely necessary in my experience: you just get
> used to defining your namespaces with low-level primitive functions at the
> top and higher-level functions at the bottom. You only need forward
> declarations (`declare`) in cases of mutual recursion, i.e. two functions
> that call each other.
>
> -S
>
>
>
>
> On Wednesday, August 14, 2013 8:56:06 AM UTC-4, Phillip Lord wrote:
>>
>>
>> One of the things that I find unusual with clojure is the requirement
>> for forward declaration. While I can see the advantages, managing it by
>> hand can be a pain.
>>
>> So I was wondering, are there any tools for adding declare statements
>> when necessary. And better for working out how to reorder function
>> declarations to minimize the requirement for forward declarations.
>>
>> Phil
>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: function creation, partial or #()

[Timothy Baldridge]

I'm just going to throw this out there, but I almost always consider using
#() instead of (fn []) to be bad practice. Like all syntactic sugar, it has
its place, but I reach for fn more often then not, because it allows me to
name the arguments and track in my mind the data with which I am working. %
means nothing to me, (fn [person]) at least gives me, as the reader of your
code, some context to go on when trying to parse what you've written.

So I see it as a few less characters, at the expense of harder to
understand code.

Timothy


On Fri, Aug 16, 2013 at 1:49 PM, Gregg Reynolds  wrote:

> On Tue, Aug 13, 2013 at 1:50 PM, John D. Hume 
> wrote:
> > Though in some cases the performance impact could be significant, my
> concern
> > is readability. My understanding of the concept of partial function
> > application is that it's about supplying some but not all of the
> arguments.
> > So when I see `partial` in code, I expect more arguments to be supplied
> > later, which is confusing when that's not the case. (Obviously context
> can
> > make it easy to see that there will be no more arguments, but often that
> > context is not present.)
> >
>
> +1.  Using partial to convert a unary func into a nullary func when
> #() is available strikes me as malpractice.  Suppose you were to come
> across something like this in legacy code:
>
> >> (do-work (partial say-hello "bob"))
>
> For me, the natural inference would be that say-hello must want at
> least one more arg (otherwise why partial?), so do-work must be
> feeding some arg to the result of (partial say-hello "bob"), like
> adding "Don't worry, we're not watching you", in case the NSA owns
> do-work.  Execution efficiency aside, downstream programmer confusion
> due to implied semantics also has a cost.
>
> -Gregg
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: lazy seq from reducers with core.async

[Timothy Baldridge]

Although this looks like it might work, it's not exactly a good idea. Look
at what you're doing inside the reducer, a call to >!! will block a OS
level thread until someone takes from the channel. Since reducers use
fork-join pools, I wouldn't be surprised if it caused some serious
side-effects. Since reducing over things like vectors and maps happen in
parallel, you could end up blocking unknown numbers of threads until these
seqs get realized. So the pool may go out and create more threads, just to
have those blocked by this code.  Either that, or the fork/join pool will
just clog up, keeping other reducers from running properly.


Timothy Baldridge


On Sun, Aug 25, 2013 at 8:43 PM, Alan Busby  wrote:

> Here is something similar pulled from bagotricks "1.5.2", using Java's
> linked blocking queue;
>
> https://github.com/thebusby/bagotricks/blob/master/src/bagotricks.clj#L204-L238
>
> It uses fold instead of reduce to run in parallel, so has a slightly
> different use case than above.
>
>
> On Mon, Aug 26, 2013 at 10:14 AM, Mikera wrote:
>
>> Nice idea Jozef!
>>
>> Hmmm this is another example of why nil-as-end-of-channel is a
>> slightly problematic design decision for core.async: it makes this kind of
>> code much more fiddly.
>>
>>
>> On Monday, 26 August 2013 01:47:14 UTC+8, Jozef Wagner wrote:
>>>
>>> Hi,
>>>
>>> A distinctive feature of reducers is that "reducing is a one-shot
>>> thing". The common understanding is that reducers are fast for cases where
>>> you want to process whole collection at once, but for infinite and lazy
>>> seqs, you have to use good old seqs.
>>>
>>> With core.async, it is now easy to create a transformation which
>>> produces lazy seq from any reducible collection.
>>>
>>>   (defn lazy-seq*
>>> [reducible]
>>> (let [c (chan)
>>>   NIL (Object.)
>>>   encode-nil #(if (nil? %) NIL %)
>>>   decode-nil #(if (identical? NIL %) nil %)]
>>>   (thread
>>>(reduce (fn [r v] (>!! c (encode-nil v))) nil reducible)
>>>(close! c))
>>>   (take-while (complement nil?) (repeatedly #(decode-nil (>>
>>>
>>>   (def s (lazy-seq* (clojure.core.reducers/map inc (range
>>>
>>>   (first s)
>>>
>>>   (take 100 s)
>>>
>>> This approach can be also extended to produce chunked seqs and chan
>>> buffer can also be used to further tune the performance.
>>>
>>> JW
>>>
>>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: lazy seq from reducers with core.async

[Timothy Baldridge]

Although this also ties up a thread for every reduce. Not exactly efficient
IMO.

Timothy


On Sun, Aug 25, 2013 at 11:50 PM, Alan Busby  wrote:

>
> On Mon, Aug 26, 2013 at 1:37 PM, Timothy Baldridge 
> wrote:
>
>> Since reducers use fork-join pools,
>
>
> Reducers use multiple threads and fork-join pools when called with "fold"
> on vectors (anything else?), not "reduce".
> By making the single producer thread of the reducer block on writes, per
> Jozef's code, he's making it act like a lazy-seq.
>
> If fold was used, then something similar to the code snippet I provided
> may be more appropriate.
> It would really depend on the use-case though.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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 - handling nils

[Timothy Baldridge]

The reason for not allowing nils isn't a complex one, and basically boils
down to the following:

a) to avoid race conditions, we need a single value to signal "the channel
is closed". As mentioned, nil is the obvious choice for this as it matches
lazy seqs and fits well with the rest of clojure:

(when-let [v ( wrote:

> It's a real problem for me too, I also wonder what was the intention
> behind this. I guess there could be a very good reason for this special
> treatement of nils, but I haven't seen it yet.
>
> I would love to hear about this from people involved in core.async
> development.
>
> On Friday, August 16, 2013 4:44:48 AM UTC+2, Mikera wrote:
>>
>> Hi all,
>>
>> I'm experimenting with core.async. Most of it is exceptionally good, but
>> bit I'm finding it *very* inconvenient that nil can't be sent over
>> channels. In particular, you can't pipe arbitrary Clojure sequences through
>> channels (since sequences can contain nils).
>>
>> I see this as a pretty big design flaw given the ubiquity of sequences in
>> Clojure code - it appears to imply that you can't easily compose channels
>> with generic sequence-handling code without some pretty ugly special-case
>> handling.
>>
>> Am I missing something? Is this a real problem for others too?
>>
>> If it is a design flaw, can it be fixed before the API gets locked down?
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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 - handling nils

[Timothy Baldridge]

All your arguments come down to this:

"I have an arbitrary seq of things I want to send down a channel". It's
exactly that concept I that I push against. Everything you've mentioned
thus far is a data structure. Channels are not data structures they are
concurrency management primitives, treat them as such and I doubt you'll
ever have a need for nils in a channel.

If we treat channels as ways of co-ordinating concurrent processes, then
nil doesn't have a use case. In every use of channels I've had thus far,
nil is better expressed as an empty collection, false, 0, :tick, or some
other "ground value".

It's these Rx style programming methods that make people think they need
this feature.

Timothy




On Tue, Aug 27, 2013 at 8:51 AM, Mike Anderson  wrote:

> On 27 August 2013 20:45, Timothy Baldridge  wrote:
>
>> The reason for not allowing nils isn't a complex one, and basically boils
>> down to the following:
>>
>> a) to avoid race conditions, we need a single value to signal "the
>> channel is closed". As mentioned, nil is the obvious choice for this as it
>> matches lazy seqs and fits well with the rest of clojure:
>>
>>
> Agreed that you want a single sentinel value.
>
> It doesn't match lazy-seqs at all though: lazy seqs can contain nils just
> fine. There's a big difference between (next some-lazy-seq) [which could be
> nil, indicating an empty sequence] and the actual values in the seq [which
> could also be nil but don't indicate the end of the seq].
>
>
>> (when-let [v (>   (process v))
>>
>> If we chose a different value, this becomes much more ugly:
>>
>> (let [v (>   (when-not (= v :async/closed)
>> (process v)))
>>
>>
> This can be solved easily by providing a macro or some other predicate
> that knows how to check for the sentinel value correctly. e.g.
>
> (when-more [v (   (process v))
>
>
>> b) I question if there are any valid uses for putting nil in a channel.
>> With all due respect to all who have written here, thus far, every
>> complaint about nils and channels boils down to a conversion from seqs to
>> channels. This is the wrong way to look at the problem. Channels are
>> co-ordination primitives not data structures. Simply because a lazy seq
>> looks like a channel, doesn't mean that they should be treated as such.
>>
>>
>> In all the core.async code I've written I've never had to put a nil in a
>> channel, so I'm left with the uncomfortable conclusion that most complaints
>> on this subject are contrived. I could be wrong, but I just haven't seen a
>> valid use case yet.
>>
>>
> To me it's all about consistency with other Clojure constructs. You can
> safely put nils in sequences, vectors, lists, sets etc.. nil is a valid
> "value" just like anything else. So why can't you put them in a channel?
>
> Two use cases I have encountered that motivate this:
>
> a) what if you want to send a sequence through a channel? Since nil as a
> value represents the empty sequence, you have to put in some extra special
> case handling with the current core.async model.
>
> b) what if you want to write generic code to send all the values in an
> arbitrary collection through a channel? you would have to wrap/unwrap nils
> at either end to make this work currently.
>
> Both of these, I think, are reasonable and common enough use cases that
> it's worth supporting them elegantly rather than forcing users to implement
> their own nil-wrapping functionality.
>
>
>> This all being said, there really isn't a technical reason to not allow
>> nils, it just simplifies much of the design and that probably translates to
>> better performance. So the restriction could be lifted if a rock solid
>> reason could be found, but as of yet, I haven't seen it.
>>
>
> I don't believe there is any noticeable performance difference between
> checking for nil and checking if a value is identical? to some sentinel
> value (which would presumably be static, final, immutable and hence very
> well optimised by the JVM). In addition, not allowing nils just means you
> have to do extra work to wrap/unwrap nils as a user - which is almost
> certainly a net loss on overall performance.
>
> Still, I think consistency is more significant than the performance
> argument in this case.
>
>
>>
>> Timothy Baldridge
>>
>>
>> On Tue, Aug 27, 2013 at 2:12 AM, Max Penet  wrote:
>>
>>> It's a real problem for me too, I also wonder what was the intention
>>> behind this. I guess t

Re: core.async - handling nils

[Timothy Baldridge]

Right, the use of false is a special case. I'm thinking of a mouse event
stream, may have a button channel that sends true or false based on the
state of the mouse button. Even saying that though, I would probably opt
for :clicked and :unclicked or somethig of that nature.

Timothy


On Tue, Aug 27, 2013 at 9:15 AM, Brandon Bloom wrote:

> > In every use of channels I've had thus far, nil is better expressed as
> an empty collection, false, 0, :tick, or some other "ground value".
>
> I agree completely. But I'll note that you mention false being useful...
>
> If you're writing completely general operators, like map, which are
> *sometimes* quite useful, then you have no choice but to do something like
> if-recv or explicitly test against nil.
>
> > It's these Rx style programming methods that make people think they
> need this feature.
>
> I built my little Rx with channels library (asyncx) without intention to
> use it directly, but because I wanted to learn how to work with channels. I
> rapidly learned that the techniques are a lot more different than they
> look. In particular, it's more difficult to write channel & process
> combinators precisely because they are more powerful. However, in
> practice, each new reusable channel/process combinator yields more
> complexity than it tends to save. I'd rather intentionally choose strictly
> less powerful primitives where appropriate and enforce that with
> encapsulation.
>
> With that in mind, if I ever revisit asyncx, I'll probably define "push
> sequences" or "streams" in terms of protocols and deftypes. I'd use
> core.async to implement them, but only for the lowest level primitives. I'd
> provide ways to get in to or out of the stream subsystem for interop with
> channels, but the public interface would take IStream objects.
>
>
> On Tue, Aug 27, 2013 at 10:58 AM, Timothy Baldridge 
> wrote:
>
>> All your arguments come down to this:
>>
>> "I have an arbitrary seq of things I want to send down a channel". It's
>> exactly that concept I that I push against. Everything you've mentioned
>> thus far is a data structure. Channels are not data structures they are
>> concurrency management primitives, treat them as such and I doubt you'll
>> ever have a need for nils in a channel.
>>
>> If we treat channels as ways of co-ordinating concurrent processes, then
>> nil doesn't have a use case. In every use of channels I've had thus far,
>> nil is better expressed as an empty collection, false, 0, :tick, or some
>> other "ground value".
>>
>> It's these Rx style programming methods that make people think they need
>> this feature.
>>
>> Timothy
>>
>>
>>
>>
>> On Tue, Aug 27, 2013 at 8:51 AM, Mike Anderson <
>> mike.r.anderson...@gmail.com> wrote:
>>
>>> On 27 August 2013 20:45, Timothy Baldridge  wrote:
>>>
>>>> The reason for not allowing nils isn't a complex one, and basically
>>>> boils down to the following:
>>>>
>>>> a) to avoid race conditions, we need a single value to signal "the
>>>> channel is closed". As mentioned, nil is the obvious choice for this as it
>>>> matches lazy seqs and fits well with the rest of clojure:
>>>>
>>>>
>>> Agreed that you want a single sentinel value.
>>>
>>> It doesn't match lazy-seqs at all though: lazy seqs can contain nils
>>> just fine. There's a big difference between (next some-lazy-seq) [which
>>> could be nil, indicating an empty sequence] and the actual values in the
>>> seq [which could also be nil but don't indicate the end of the seq].
>>>
>>>
>>>> (when-let [v (>>>   (process v))
>>>>
>>>> If we chose a different value, this becomes much more ugly:
>>>>
>>>> (let [v (>>>   (when-not (= v :async/closed)
>>>> (process v)))
>>>>
>>>>
>>> This can be solved easily by providing a macro or some other predicate
>>> that knows how to check for the sentinel value correctly. e.g.
>>>
>>> (when-more [v (>>   (process v))
>>>
>>>
>>>> b) I question if there are any valid uses for putting nil in a channel.
>>>> With all due respect to all who have written here, thus far, every
>>>> complaint about nils and channels boils down to a conversion from seqs to
>>>> channels. This is the wrong way to look at the proble

Re: core.async and referential transparency

[Timothy Baldridge]

What you are describing is a pub sub type system. This could be built on
top of core.async, but it doesn't have to change the core library at all.

But yes, you are mis-understanding the main use-case for a library like
core.async. The library was created to allow for the building of systems
that consist of queues and workers that pull items from those queues. As
Rich explained it a few times, consider an assembly plant. Workers take
items from conveyor belts, perform some work and place them on other belts.
In this use case, duplicating items and giving a copy to each worker
doesn't make a whole lot of sense.

Timothy


On Tue, Sep 3, 2013 at 8:00 AM, bertschi
wrote:

> Hi,
>
> recently I got interested core.async (also thanks to great blog post such
> as the ones by David Nolen) and wanted to understand better how it compares
> to other reactive libraries, in particular coming from the research on
> Functional Reactive Programming (FRP).
>
> Compared to FRP, core.async appears to be build around side-effects on
> channels which breaks referential transparency. What I mean here, is that
> channels are somewhat like reference types and connect a (time varying)
> value to an identity.
>
> As an example consider a map-like channel transformer (as found in many
> posts explaining core.async) (map-ch f in out) which takes values x from
> the input channel in and writes (f x) to the output channel out.
>
> (defn map-ch
>   ([f in]
>  (map-ch f in (chan)))
>   ([f in out]
> (go (loop []
>  (if-let [x ( (do (>! out (f x))
>  (recur))
> (close! out
> out))
>
> Now, the following two snippets behave rather differently:
>
> (let [out-1 (map-ch inc ( data to it>))
>   out-2 (map-ch dec ( data to it>))]
>   (go (loop []
>   (when-let [x (   (println "receiving " x)
>   (recur)
>
> (let [in ()
>   out-1 (map-ch inc in)
>   out-2 (map-ch dec in)]
>   (go (loop []
>   (when-let [x (   (println "receiving " x)
>   (recur)
>
> Whereas the first example receives all incremented values, the second one
> receives potentially less since both consumers read from the very same
> input channel! This also means that one can break working code, by
> (accidently) attaching an additional consumer ... note that in Rx I can
> subscribe as many times as I want to an observable without any effect on
> the rest of the data flow.
>
> Maybe I'm misunderstanding CSP and how it allows to compose and
> synchronize processes, but somehow I feel that channels complect the idea
> of state varying values and identity. Regarding that referential
> transparency, which is required for equational reasoning, is one of the
> best properties of purely functional programs, breaking  it seems to be at
> least problematic.
>
> Any thoughts?
>
>Nils
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: binding and core.async? (trying to use shoreleave-remote in go block)

[Timothy Baldridge]

As David said, binding preservation works with Clojure, not with
ClojureScript. That being said, while I can see a use for bindings in
Clojure (thread-local redef), I fail to see a use-case for binding in
ClojureScript. Seems like code could/should be structured in a better way.


On Thu, Sep 5, 2013 at 7:54 AM, Jacek Lach wrote:

> That is not what happens in lein repl:
>
> user=> (use 'clojure.core.async)
> nil
> user=> (def pingc (chan))
> #'user/pingc
> user=> (def ^:dynamic *text* "OUPS BAD ASYNC")
> #'user/*text*
> user=> (binding [*text* "good boy"]
>   #_=>   (go (while true
>   #_=> (   #_=> (println *text*
> # clojure.core.async.impl.channels.ManyToManyChannel@79d236c2>
> user=> (defn ping [] (put! pingc :ping))
> #'user/ping
> user=> (ping)
> good boy
> nil
>
> It's of course up to core.async to preserve bindings within its body. But
> since it tries to pretend to run your `go` code 'as if it was synchronous',
> that's probably desirable?
>
>
> On Thursday, September 5, 2013 3:48:10 PM UTC+1, Meikel Brandmeyer
> (kotarak) wrote:
>>
>> Hi,
>>
>> Am Donnerstag, 5. September 2013 16:36:37 UTC+2 schrieb Mathias Picker:
>>>
>>> I just tried this test case (from Anderkent on IRC):
>>>
>>> (def pingc (chan))
>>>
>>> (def ^:dynamic *text* "OUPS BAD ASYNC")
>>>
>>> (binding [*text* "good boy"]
>>>   (go (while true
>>> (>> (js/alert *text*
>>>
>>> (defn ping []
>>>   (put! pingc :ping))
>>>
>>> (ping)
>>>
>>> and I get "OUPS BAD ASYNC".
>>>
>>> So, is this bug in cljs core.async?
>>>
>>>
>> This is to be expected, because the binding is reverted after the go call
>> returns. So the code in the go block (executed later on) sees the old,
>> initial binding.
>>
>> Meikel
>>
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
“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: binding and core.async? (trying to use shoreleave-remote in go block)

[Timothy Baldridge]

I used to think the same, until I wrote the current incarnation of the go
macro in core.async. A few months back I ripped out all global vars (and
bindings). The go "compiler" is now functionally pure, except for a single
atom on the edge that counts locals. More and more I'm convinced that
dynamic vars, while pragmatic, are used way more often than they should be.

A classic example, is this OP use case, why are we storing a url in a
public dynamic var?


Timothy

On Thu, Sep 5, 2013 at 10:08 AM, David Nolen  wrote:

> Your example doesn't accomplish what dynamic binding does. You don't need
> to look much further than Clojure / ClojureScript compilers to see cases
> where trying to propagate information through an environment like you are
> with ctx is absolutely too tedious, the aspect oriented nature of binding
> is really what you want.
>
> David
>
>
> On Thu, Sep 5, 2013 at 1:03 PM, Timothy Baldridge wrote:
>
>> That can easily be done thusly:
>>
>> (defn do-stuff [ctx c]
>>(go (loop []
>> (let [v (>   (swap! ctx process v)
>>   (recur)))
>>(go (loop []
>> (let [v (>   (swap! ctx process v)
>>   (recur)))
>>(go (loop []
>> (let [v (>   (swap! ctx process v)
>>   (recur))
>>
>> What am I missing here? Every time I've thought I needed binding, I've
>> been able to find a cleaner, more functionally pure way of doing it that
>> didn't require binding.
>>
>> Timothy
>>
>>
>> On Thu, Sep 5, 2013 at 9:01 AM, David Nolen wrote:
>>
>>> I actually disagree a here as core.async brings a pretty nice
>>> concurrency model into play - I suspect there are instances where you might
>>> want to construct a series of go blocks with some shared context that you'd
>>> rather not put into every go loop.
>>>
>>> In anycase improved binding support is something I'd like to see in
>>> ClojureScript and I don't see the downside of keeping the core.async
>>> behavior the same between Clojure and ClojureScript.
>>>
>>>
>>> On Thu, Sep 5, 2013 at 11:30 AM, Timothy Baldridge >> > wrote:
>>>
>>>> As David said, binding preservation works with Clojure, not with
>>>> ClojureScript. That being said, while I can see a use for bindings in
>>>> Clojure (thread-local redef), I fail to see a use-case for binding in
>>>> ClojureScript. Seems like code could/should be structured in a better way.
>>>>
>>>>
>>>> On Thu, Sep 5, 2013 at 7:54 AM, Jacek Lach >>> > wrote:
>>>>
>>>>> That is not what happens in lein repl:
>>>>>
>>>>> user=> (use 'clojure.core.async)
>>>>> nil
>>>>> user=> (def pingc (chan))
>>>>> #'user/pingc
>>>>> user=> (def ^:dynamic *text* "OUPS BAD ASYNC")
>>>>> #'user/*text*
>>>>> user=> (binding [*text* "good boy"]
>>>>>   #_=>   (go (while true
>>>>>   #_=> (>>>>   #_=> (println *text*
>>>>> #>>>> clojure.core.async.impl.channels.ManyToManyChannel@79d236c2>
>>>>> user=> (defn ping [] (put! pingc :ping))
>>>>> #'user/ping
>>>>> user=> (ping)
>>>>> good boy
>>>>> nil
>>>>>
>>>>> It's of course up to core.async to preserve bindings within its body.
>>>>> But since it tries to pretend to run your `go` code 'as if it was
>>>>> synchronous', that's probably desirable?
>>>>>
>>>>>
>>>>> On Thursday, September 5, 2013 3:48:10 PM UTC+1, Meikel Brandmeyer
>>>>> (kotarak) wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Am Donnerstag, 5. September 2013 16:36:37 UTC+2 schrieb Mathias
>>>>>> Picker:
>>>>>>>
>>>>>>> I just tried this test case (from Anderkent on IRC):
>>>>>>>
>>>>>>> (def pingc (chan))
>>>>>>>
>>>>>>> (def ^:dynamic *text* "OUPS BAD ASYNC")
>>>>>>>
>>>>>>> (binding [*text* "good boy"]
>>>>>>>   (go (while true
>>>>>>> 

Re: binding and core.async? (trying to use shoreleave-remote in go block)

[Timothy Baldridge]

That can easily be done thusly:

(defn do-stuff [ctx c]
   (go (loop []
(let [v ( wrote:

> I actually disagree a here as core.async brings a pretty nice concurrency
> model into play - I suspect there are instances where you might want to
> construct a series of go blocks with some shared context that you'd rather
> not put into every go loop.
>
> In anycase improved binding support is something I'd like to see in
> ClojureScript and I don't see the downside of keeping the core.async
> behavior the same between Clojure and ClojureScript.
>
>
> On Thu, Sep 5, 2013 at 11:30 AM, Timothy Baldridge 
> wrote:
>
>> As David said, binding preservation works with Clojure, not with
>> ClojureScript. That being said, while I can see a use for bindings in
>> Clojure (thread-local redef), I fail to see a use-case for binding in
>> ClojureScript. Seems like code could/should be structured in a better way.
>>
>>
>> On Thu, Sep 5, 2013 at 7:54 AM, Jacek Lach 
>> wrote:
>>
>>> That is not what happens in lein repl:
>>>
>>> user=> (use 'clojure.core.async)
>>> nil
>>> user=> (def pingc (chan))
>>> #'user/pingc
>>> user=> (def ^:dynamic *text* "OUPS BAD ASYNC")
>>> #'user/*text*
>>> user=> (binding [*text* "good boy"]
>>>   #_=>   (go (while true
>>>   #_=> (>>   #_=> (println *text*
>>> #>> clojure.core.async.impl.channels.ManyToManyChannel@79d236c2>
>>> user=> (defn ping [] (put! pingc :ping))
>>> #'user/ping
>>> user=> (ping)
>>> good boy
>>> nil
>>>
>>> It's of course up to core.async to preserve bindings within its body.
>>> But since it tries to pretend to run your `go` code 'as if it was
>>> synchronous', that's probably desirable?
>>>
>>>
>>> On Thursday, September 5, 2013 3:48:10 PM UTC+1, Meikel Brandmeyer
>>> (kotarak) wrote:
>>>>
>>>> Hi,
>>>>
>>>> Am Donnerstag, 5. September 2013 16:36:37 UTC+2 schrieb Mathias Picker:
>>>>>
>>>>> I just tried this test case (from Anderkent on IRC):
>>>>>
>>>>> (def pingc (chan))
>>>>>
>>>>> (def ^:dynamic *text* "OUPS BAD ASYNC")
>>>>>
>>>>> (binding [*text* "good boy"]
>>>>>   (go (while true
>>>>> (>>>> (js/alert *text*
>>>>>
>>>>> (defn ping []
>>>>>   (put! pingc :ping))
>>>>>
>>>>> (ping)
>>>>>
>>>>> and I get "OUPS BAD ASYNC".
>>>>>
>>>>> So, is this bug in cljs core.async?
>>>>>
>>>>>
>>>> This is to be expected, because the binding is reverted after the go
>>>> call returns. So the code in the go block (executed later on) sees the old,
>>>> initial binding.
>>>>
>>>> Meikel
>>>>
>>>>
>>>  --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
>>
>> --
>> “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 

Re: Putting in alts! - haven't seen it used

[Timothy Baldridge]

He's talking about puts and alts. You can actually do multiple puts at once
inside an alts! and only one of them will be used. Yes I haven't seen them
used either, I'm sure there's a use case, I haven't found it yet though.

Timothy


On Sun, Sep 8, 2013 at 9:35 PM, Sean Corfield wrote:

> We're using alts! to take a value or timeout, as part of machinery to
> detect whether a popup opens or is blocked.
>
> On Sun, Sep 8, 2013 at 7:21 PM, Alan Shaw  wrote:
> > I'm accustomed to using alts! to allow taking from a collection of
> > core.async ports, but haven't come up with a use case for a put in alts!,
> > either with or without takes.
> > Have you?
> >
> > -A
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



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

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

Re: Putting in alts! - haven't seen it used

[Timothy Baldridge]

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

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

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

Timothy



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

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

Re: Clojure, floats, ints and OpenGL

[Timothy Baldridge]

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

Timothy


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

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

Re: Clojure, floats, ints and OpenGL

[Timothy Baldridge]

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

Timothy


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

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

Re: Functional purity and "globals" in Clojure

[Timothy Baldridge]

This Clojure/West talk deals with many of these concepts.

http://www.infoq.com/presentations/Clojure-Large-scale-patterns-techniques

Timothy


On Tue, Sep 10, 2013 at 6:35 AM, Philipp Meier  wrote:

>
>
> Am Dienstag, 10. September 2013 12:58:46 UTC+2 schrieb Luc:
>
>> I agree more or less, I hate having my configuration data spread
>> everywhere.
>> I prefer to dedicate a name space to maintain/access configuration data.
>> I usually split access to resources using bundles.
>> A bundle can reflect anything you want in your design, including a
>> controller...
>>
>
> You can always use a global config system and pass through the
> configuration information into the sub systems.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: Clojure, floats, ints and OpenGL

[Timothy Baldridge]

e crazy new performance-oriented JVM Lisp).
>
>
> On Thursday, 12 September 2013 23:11:40 UTC+8, tbc++ wrote:
>
>> There are a combination of issues all contributing to the lack of
>> response on this subject. But before I continue let me state that these
>> opinions are my own. I have worked on Clojure and core.async, but these
>> comments are going to be personal conjecture and opinions:
>>
>> 1) As mentioned there is a high amount of complexity required to
>> implement all the interfaces needed for the different variants of functions
>> you want. Primitive hinted functions currently implement Java interfaces,
>> implementing every combination of float, double, object, short, int, long,
>> and byte for arities up to 5 would require the addition of over 16,000
>> interfaces. With the current config, we only need 81 interfaces. I'm not
>> saying this couldn't be changed to happen on-the-fly, it would just take
>> some serious work, and would cause problems with Java Interop
>>
>> 2) The current system works, there are production databases (see
>> Datomic), neural networks (see the work by Prismatic), and many high
>> performance libraries (Zach Tellman has a reputation for bending Clojure to
>> his will in this area), all written in Clojure.
>>
>> 3) Because of #2, some may even go so far as to say that we should drop
>> everything but longs and doubles. Other dynamic languages (Python for
>> instance) do this without problems, they simply relegate all the high
>> performance stuff to highly optimized libraries. This is what Prismatic did
>> with HipHop (http://blog.getprismatic.com/**blog/2013/7/10/introducing-**
>> hiphip-array-fast-and-**flexible-numerical-**computation-in-clojure<http://blog.getprismatic.com/blog/2013/7/10/introducing-hiphip-array-fast-and-flexible-numerical-computation-in-clojure>
>> ).
>>
>> 4) Writing small functional libraries in Java that interop with Clojure
>> is actually quite nice. So perhaps the answer is to build the inner kernels
>> of your system in Java and then wrap them? I know that doesn't sound fun,
>> but you won't get much faster code than that.
>>
>> So all the above make me sit back and say "what is it about your problem
>> that is unique and really requires floats? Why haven't we had problems like
>> this in the past."
>>
>> 5) And I think the problem really comes down to your API and target
>> platform (GPU). See, most of us would just typehint to doubles and take the
>> memory hit. Doubles are fast on modern CPUs and memory is cheap. Not so in
>> your case, as you mentioned you have concerns about memory size and
>> performance of certain primitives.
>>
>> My conclusion is that you'd probably be best looking at the HipHop
>> library, and figuring out how you can adapt their ideas to your own code.
>> That is, write a small Java library that contains all the kernel code you
>> need, and then stitch together these primitives with Clojure.
>>
>> As it stands, Clojure's support for type hinting floats is poor, but
>> that's not likely to change soon.
>>
>> 
>>
>> TL;DR - The reason you haven't heard back is because no one has a good
>> answer as to how to fix it, or if it even needs to be fixed. That's not the
>> answer anyone likes to hear, but I'm afraid that's the truth. Anyone else
>> on this list can feel free to correct me.
>>
>> Timothy Baldridge
>>
>>
>> On Thu, Sep 12, 2013 at 8:38 AM, Alex Fowler  wrote:
>>
>>>
>>> Does somebody from the development team read this user group? Or maybe I
>>> have addressed my questions to a wrong place?
>>>
>>> --
>>> --
>>> 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<http://groups.google.com/group/clojure?hl=en>
>>> ---
>>> You received this message because you 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.
>>>
>>

Re: Clojure, floats, ints and OpenGL

[Timothy Baldridge]

There are a combination of issues all contributing to the lack of response
on this subject. But before I continue let me state that these opinions are
my own. I have worked on Clojure and core.async, but these comments are
going to be personal conjecture and opinions:

1) As mentioned there is a high amount of complexity required to implement
all the interfaces needed for the different variants of functions you want.
Primitive hinted functions currently implement Java interfaces,
implementing every combination of float, double, object, short, int, long,
and byte for arities up to 5 would require the addition of over 16,000
interfaces. With the current config, we only need 81 interfaces. I'm not
saying this couldn't be changed to happen on-the-fly, it would just take
some serious work, and would cause problems with Java Interop

2) The current system works, there are production databases (see Datomic),
neural networks (see the work by Prismatic), and many high performance
libraries (Zach Tellman has a reputation for bending Clojure to his will in
this area), all written in Clojure.

3) Because of #2, some may even go so far as to say that we should drop
everything but longs and doubles. Other dynamic languages (Python for
instance) do this without problems, they simply relegate all the high
performance stuff to highly optimized libraries. This is what Prismatic did
with HipHop (
http://blog.getprismatic.com/blog/2013/7/10/introducing-hiphip-array-fast-and-flexible-numerical-computation-in-clojure
).

4) Writing small functional libraries in Java that interop with Clojure is
actually quite nice. So perhaps the answer is to build the inner kernels of
your system in Java and then wrap them? I know that doesn't sound fun, but
you won't get much faster code than that.

So all the above make me sit back and say "what is it about your problem
that is unique and really requires floats? Why haven't we had problems like
this in the past."

5) And I think the problem really comes down to your API and target
platform (GPU). See, most of us would just typehint to doubles and take the
memory hit. Doubles are fast on modern CPUs and memory is cheap. Not so in
your case, as you mentioned you have concerns about memory size and
performance of certain primitives.

My conclusion is that you'd probably be best looking at the HipHop library,
and figuring out how you can adapt their ideas to your own code. That is,
write a small Java library that contains all the kernel code you need, and
then stitch together these primitives with Clojure.

As it stands, Clojure's support for type hinting floats is poor, but that's
not likely to change soon.



TL;DR - The reason you haven't heard back is because no one has a good
answer as to how to fix it, or if it even needs to be fixed. That's not the
answer anyone likes to hear, but I'm afraid that's the truth. Anyone else
on this list can feel free to correct me.

Timothy Baldridge


On Thu, Sep 12, 2013 at 8:38 AM, Alex Fowler wrote:

>
> Does somebody from the development team read this user group? Or maybe I
> have addressed my questions to a wrong place?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: Clojure, floats, ints and OpenGL

[Timothy Baldridge]

; my weekends on speculative work that might not be accepted or appreciated.
>>> I suspect this is true for others too.
>>>
>>> If, on the other hand, the "official" answer is "Clojure will never
>>> support anything other than Objects, doubles and longs" then I'd want to
>>> know that too. I think that would be a *really* poor design decision
>>> because good compiled performance and good JVM interop ("embracing the host
>>> platform") seem to be two key principles of Clojure that have attracted
>>> many people. But hey, then I could at least save my weekends and focus on
>>> writing performance-oriented code in other languages (whether that is Java,
>>> Scala, pure bytecode, or some crazy new performance-oriented JVM Lisp).
>>>
>>>
>>> On Thursday, 12 September 2013 23:11:40 UTC+8, tbc++ wrote:
>>>
>>>> There are a combination of issues all contributing to the lack of
>>>> response on this subject. But before I continue let me state that these
>>>> opinions are my own. I have worked on Clojure and core.async, but these
>>>> comments are going to be personal conjecture and opinions:
>>>>
>>>> 1) As mentioned there is a high amount of complexity required to
>>>> implement all the interfaces needed for the different variants of functions
>>>> you want. Primitive hinted functions currently implement Java interfaces,
>>>> implementing every combination of float, double, object, short, int, long,
>>>> and byte for arities up to 5 would require the addition of over 16,000
>>>> interfaces. With the current config, we only need 81 interfaces. I'm not
>>>> saying this couldn't be changed to happen on-the-fly, it would just take
>>>> some serious work, and would cause problems with Java Interop
>>>>
>>>> 2) The current system works, there are production databases (see
>>>> Datomic), neural networks (see the work by Prismatic), and many high
>>>> performance libraries (Zach Tellman has a reputation for bending Clojure to
>>>> his will in this area), all written in Clojure.
>>>>
>>>> 3) Because of #2, some may even go so far as to say that we should drop
>>>> everything but longs and doubles. Other dynamic languages (Python for
>>>> instance) do this without problems, they simply relegate all the high
>>>> performance stuff to highly optimized libraries. This is what Prismatic did
>>>> with HipHop (http://blog.getprismatic.com/
>>>> blog/2013/7/10/introducing-**hip**hip-array-fast-and-**flexible-**
>>>> numerical-**computation-in-**clojure<http://blog.getprismatic.com/blog/2013/7/10/introducing-hiphip-array-fast-and-flexible-numerical-computation-in-clojure>
>>>> ).
>>>>
>>>> 4) Writing small functional libraries in Java that interop with Clojure
>>>> is actually quite nice. So perhaps the answer is to build the inner kernels
>>>> of your system in Java and then wrap them? I know that doesn't sound fun,
>>>> but you won't get much faster code than that.
>>>>
>>>> So all the above make me sit back and say "what is it about your
>>>> problem that is unique and really requires floats? Why haven't we had
>>>> problems like this in the past."
>>>>
>>>> 5) And I think the problem really comes down to your API and target
>>>> platform (GPU). See, most of us would just typehint to doubles and take the
>>>> memory hit. Doubles are fast on modern CPUs and memory is cheap. Not so in
>>>> your case, as you mentioned you have concerns about memory size and
>>>> performance of certain primitives.
>>>>
>>>> My conclusion is that you'd probably be best looking at the HipHop
>>>> library, and figuring out how you can adapt their ideas to your own code.
>>>> That is, write a small Java library that contains all the kernel code you
>>>> need, and then stitch together these primitives with Clojure.
>>>>
>>>> As it stands, Clojure's support for type hinting floats is poor, but
>>>> that's not likely to change soon.
>>>>
>>>> 
>>>>
>>>> TL;DR - The reason you haven't heard back is because no one has a good
>>>> answer as to how to fix it, or if it even needs to be fixed. That's not the
>>>> answer anyone likes to hear, but I'm afraid that's th

Re: Clojure, floats, ints and OpenGL

[Timothy Baldridge]

ack from others unless you start offering money. But
once again I want to come back to something I've said a lot in this
conversation: I work with Clojure a lot. If someone came to me and said
"how do I do this in Clojure?". I'd say the following: put your math in
static java methods, and call them from Clojure. This is really the way it
should be done. Low level stuff in Java, high level stuff in Clojure. The
nice thing is, lein has very nice features for just this use case:

http://stackoverflow.com/questions/7511789/clojure-lein-how-do-i-include-a-java-file-in-my-project

So you can write your java code, stick it in a folder, and then it'll be
compiled by lien on startup.

That's my professional opinion.

Timothy Baldridge



On Sat, Sep 14, 2013 at 8:08 AM, Alex Fowler wrote:

> Excuse me, when I said "Vertex3f" I meant "Vector3f".
>
> суббота, 14 сентября 2013 г., 15:14:01 UTC+4 пользователь Alex Fowler
> написал:
>
>> Timothy, thanks,for giving a thorough answer to my questions, I
>> appreciate this! As far as I understood, you did some work for Clojure
>> team, and you have the necessary knowledge to express a knowing opinion on
>> what are the implications of the matter. That was one of the things I
>> wanted to know - the cause of the present situation. However, still I don't
>> understand (although you mentioned a reason) why no one from the core team
>> gives a definite, cut-off answer, like the one, Mikera is also asking for -
>> what is for the future? Probably, as somebody mentioned here (sorry, I look
>> and can't find the message, deleted?), the question would probably be
>> better addressed to clojure-dev. But I have no good knowledge of Clojure
>> internals and would be easily suppressed by an answer of a person, showing
>> a technical knowledge, like yours. Yes, I understand what you're saying,
>> but I do not have knowledge of Clojure or JVM to answer you on par. Simply
>> I do not know what to say, although I feel there is a break between JVM and
>> Clojure that should not be. And I feel, that you have a right in what
>> you're saying - you know the language, you know the people here, more than
>> me. But not to let a discussion on such a topic to die, here I am glad that
>> Mikera, someone who has that knowledge, can sympathise me and say what I
>> cannot say.
>>
>> James, for some numbers on OpenGL penalties, please refer to message #6
>> in thread (my initial answer for Timothy). You can also google on it, I am
>> sure, you will find more information, or, why not, simply call NVIDIA or
>> ATI support lines, and ask them. A perfectly valid question for them to
>> consult you on :) As for more Java-friendly answers, you might also be
>> interested in asking on LWJGL or JOGL forums. Personally I work with OpenGL
>> for quite a long time already. Even when we were on C/C++ we never used
>> doubles. Then we went Java, and there too,  doubles are nowhere. One of the
>> cornerstone computational workhorses of LWJGL, for example, the class
>> Vertex3f, has no double version. And that is for a reason, not because Java
>> bindings are bad and we must go C-plus-plusing now. Probably, after 10
>> years we will have only doubles and longs on GPUs... do you believe in it?
>> Why we need them there at all?
>>
>> I still strongly believe that primitives support should be made one of
>> the highest priorities to support.
>>
>> Lets look from a perspective of someone who researches the language,
>> considering if to adhere to it. Here is a couple of frustrations that hit
>> me so much that I think could even diverse somone from using the language.
>> Warning: the following three points may cause rage in some individuals
>> (they do cause a rage in me at least, because I really like Clojure) :
>>
>>  1) Clojure is said to be "data-oriented". Rich Hickey says that in the
>> videos. Cool! I have a stream of millions floats and ints to be processed
>> on the fly! Now we find that it is not data-oriented. It is double, long
>> and Object oriented. Data does not just come as "information" it comes with
>> its data-type. Bending data-sources and data-consumers to your will usually
>> does not sign a good data-processing.
>>  2) Clojure is said to make simple things easy. Alright, that's a PC in
>> front of me? With a JVM? Alright, I want to add,multiply, divide and
>> subtract some billion floats. What could be simpler?... Uh... typehints..
>> alright, sure JVM is typed, we have types in Java and Scala, that's ok! Oh,
>> only local... oh, still always returns doubles... err.. 

Re: Clojure, floats, ints and OpenGL

[Timothy Baldridge]

want to go. Without official blessing, I'm
>>>>> unlikely to spend my weekends on speculative work that might not be
>>>>> accepted or appreciated. I suspect this is true for others too.
>>>>>
>>>>> If, on the other hand, the "official" answer is "Clojure will never
>>>>> support anything other than Objects, doubles and longs" then I'd want to
>>>>> know that too. I think that would be a *really* poor design decision
>>>>> because good compiled performance and good JVM interop ("embracing the 
>>>>> host
>>>>> platform") seem to be two key principles of Clojure that have attracted
>>>>> many people. But hey, then I could at least save my weekends and focus on
>>>>> writing performance-oriented code in other languages (whether that is 
>>>>> Java,
>>>>> Scala, pure bytecode, or some crazy new performance-oriented JVM Lisp).
>>>>>
>>>>>
>>>>> On Thursday, 12 September 2013 23:11:40 UTC+8, tbc++ wrote:
>>>>>
>>>>>> There are a combination of issues all contributing to the lack of
>>>>>> response on this subject. But before I continue let me state that these
>>>>>> opinions are my own. I have worked on Clojure and core.async, but these
>>>>>> comments are going to be personal conjecture and opinions:
>>>>>>
>>>>>> 1) As mentioned there is a high amount of complexity required to
>>>>>> implement all the interfaces needed for the different variants of 
>>>>>> functions
>>>>>> you want. Primitive hinted functions currently implement Java interfaces,
>>>>>> implementing every combination of float, double, object, short, int, 
>>>>>> long,
>>>>>> and byte for arities up to 5 would require the addition of over 16,000
>>>>>> interfaces. With the current config, we only need 81 interfaces. I'm not
>>>>>> saying this couldn't be changed to happen on-the-fly, it would just take
>>>>>> some serious work, and would cause problems with Java Interop
>>>>>>
>>>>>> 2) The current system works, there are production databases (see
>>>>>> Datomic), neural networks (see the work by Prismatic), and many high
>>>>>> performance libraries (Zach Tellman has a reputation for bending Clojure 
>>>>>> to
>>>>>> his will in this area), all written in Clojure.
>>>>>>
>>>>>> 3) Because of #2, some may even go so far as to say that we should
>>>>>> drop everything but longs and doubles. Other dynamic languages (Python 
>>>>>> for
>>>>>> instance) do this without problems, they simply relegate all the high
>>>>>> performance stuff to highly optimized libraries. This is what Prismatic 
>>>>>> did
>>>>>> with HipHop (http://blog.getprismatic.com/**
>>>>>> blog/2013/7/10/introducing-**hiphip-array-fast-and-**flexible-**
>>>>>> nu**merical-**computation-in-**clojure<http://blog.getprismatic.com/blog/2013/7/10/introducing-hiphip-array-fast-and-flexible-numerical-computation-in-clojure>
>>>>>> **).
>>>>>>
>>>>>> 4) Writing small functional libraries in Java that interop with
>>>>>> Clojure is actually quite nice. So perhaps the answer is to build the 
>>>>>> inner
>>>>>> kernels of your system in Java and then wrap them? I know that doesn't
>>>>>> sound fun, but you won't get much faster code than that.
>>>>>>
>>>>>> So all the above make me sit back and say "what is it about your
>>>>>> problem that is unique and really requires floats? Why haven't we had
>>>>>> problems like this in the past."
>>>>>>
>>>>>> 5) And I think the problem really comes down to your API and target
>>>>>> platform (GPU). See, most of us would just typehint to doubles and take 
>>>>>> the
>>>>>> memory hit. Doubles are fast on modern CPUs and memory is cheap. Not so 
>>>>>> in
>>>>>> your case, as you mentioned you have concerns about memory size and
>>>>>> performance of certain primitives.
>>>>>>
>>>>>> My conclusio

Re: Clojure for Desktop UI Design Application

[Timothy Baldridge]

Before coming to Clojure I did 2 years of work on WPF/Silverlight apps, and
let me say what those platforms offer blows the web stuff out of the water.
Yes it's not cross-platform, but the ability to describe a layout with data
is unparalleled in the web world. I could sit down, and have a UI to a CRUD
app in half a day. No CSS, no DOM elements to force into a layout I wanted,
etc. Ask anyone who's worked with WPF and they'll tell you "yep it's based
on mutability, but writing a UI is really easy".

JavaFX comes close to this, but I'd like to use pure data to interact with
it. I did some work on that in the past, and came up with something that
was pretty usable, but I think a React approach could take it even further.
Anyways, the results of my work allowed you to create JavaFX interfaces
like this:


{:type   :border-pane :center {:type :group
  :children [{:type:circle
 :radius  (planet-sizes size)
:centerY (/ (planet-sizes size) 2)
 :centerX 0}]} :bottom
{:type   :stack-pane  :maxHeight  110
:prefHeight 110
  :children   [{:type :pie-chart
 :data (map(fn
[{percent :planet.biome/percentage
 type:planet.biome/type}]
(slide/build-item {:type
:pie-chart-data
 :name  (str type)
:value percent}))
  (:planet/biomes planet))}]}}

Notice how you don't have to muck with all the junk found in the
browser, you just describe an panel, say what you want to put where
(center, bottom, etc). and the layout engine takes care of the rest.
And this entire thing is GPU accelerated so drawing of the GUI is
pretty fast. The web side of things has a place, but it's also mired
in decades of legacy, that's stuff you don't find in modern UI
toolkits like JavaFX, QT and WPF.


Timothy


On Tue, Jan 13, 2015 at 12:46 PM, Gary Trakhman 
wrote:

> On Tue Jan 13 2015 at 2:05:03 PM Christopher Small 
> wrote:
>>
>> On the other hand, while the web app route may feel a bit overwhelming,
>> it really is worth learning. Once you program web, you can deliver to any
>> platform. It's ubiquitous. And once you get the hang of it, the paradigm
>> isn't really all that challenging. But up to you obviously.
>>
>>
> This rationale is the basis for my last 1.5 years of extra-work effort.
> Good luck :-).
>
> Coming from clojure, React really made investing in the web seem sane and
> worthwhile by offering composable abstraction.  I still think it's a good
> idea to learn web tech, but it was kind of a frustrating slog.
>
> Another really helpful piece of 'tech' that fits with clojure philosophies
> is http://suitcss.github.io/
> https://github.com/suitcss/suit/blob/master/doc/design-principles.md
>
> I think that plus React are great starting points.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

Re: Satisfies? seems strangely slow

[Timothy Baldridge]

The logic of extends? is much simpler, so try that. IIRC it's something
like "extends? returns true if any method on the protocol is implemented by
x", "satisfies? returns true if all methods of a protocol are implemented
by x".

The docs don't seem to give much help here, so play with it in the repl a
bit.

Timothy

On Thu, Jan 22, 2015 at 6:14 PM, Michael Blume  wrote:

> (defprotocol my-protocol
>   (foo [this]))
>
> (extend-protocol my-protocol
>   clojure.lang.IPersistentMap
>   (foo [this] "hello from map"))
>
> (criterium.core/quick-bench
>   (satisfies? my-protocol {}))
>
> (criterium.core/quick-bench
>   (foo {}))
>
> Simply calling foo on an empty map takes 7 ns,
> but checking whether the map satisfies my-protocol takes 22 µs, 3000 times
> longer.
>
> It seems like to call foo, some mechanism has to look up an implementation
> of my-protocol for maps -- how is it we can do that so quickly for a call
> and so slowly for satisfies?
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

Re: Architectural doubts

[Timothy Baldridge]

Since the data you are handing to the datomic query engine is un-indexed,
portions of the query will effectively be O(n). However if you do as Jan
suggests and put the data into Datomic the data will automatically indexed
several ways. Then when you query against the datomic db, the engine will
pick up on these indexes and your queries could be much faster. In
addition, Datomic has some rather advanced caching logic that should help
with data usage if you are writing the data to a transactor (i.e. using the
in-memory storage won't help much here, use free or dev storage).

Timothy



On Sat, Jan 31, 2015 at 5:53 AM, Jan-Paul Bultmann <
janpaulbultm...@googlemail.com> wrote:

> Why not stream frames directly into the datomic db as they fall out of
> gloss?
> This should be faster at query time anyhow due to indexes,
> and let's datomic handle the memory management.
>
> cheers Jan
>
> On 31 Jan 2015, at 11:39, Milton Silva  wrote:
>
> While using wireshark to analyse libpcap files (>= 200 MB) I routinely
> think that it would be great to preform relational queries but, wireshark
> only supports search.
>
> I thought I would decode the entire file, hold it in memory as clojure
> data structures and use datomic's datalog.
>
> Besides relational queries, a requirement is for the file to be decoded
> (libpcap, ethernet-II, IP, TCP, diameter) in less then a minute(for a
> 200MB) and the "typical" queries should also be less than a minute.
>
> I thought the frames could be represented like this:
>
> {:frame-id 1
> :timestamp java's instant-object
> :src-mac string
> :dest-mac string
> :src-ip
> :dest-ip ...
> ...}
>
> {:frame-ids [1 3]
> :diameter-session-id ...}
>
> So, I started by using gloss to decode a 200MB file. Gloss is fantastic to
> specify frames  but, it is not meeting the time requirements. It appear the
> problem has to do with the creation of a lot of objects. Even with 3G of
> ram for the heap, it still crawls to a halt.
>
> I could try to perform some experiments to determine approximate answers
> but, I think it is better to talk with people with more experience in order
> to avoid common pitfalls..
> My questions are:
>
> Will the JVM (with 3G) support a million hashmaps like the above?
> Is Buffy able to do something like what I want?
> Will datomic be able to handle this use case?
> What would you suggest to solve this(e.g. don't use clojure data
> structures.. but then datomic's datalog is not available to query?)?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

[Timothy Baldridge]

Most of the time, if you are using a component like system, you'll also
want some level of polymorphism as well. This is what the defrecord
approach enables, it not only provides dependency injection, but also
provides a type that calls to that component can dispatch against. In
testing it's then quite easy to swap out a component with a mock component,
that's something that's pretty hard to do with just functions.

Timothy

On Wed, Feb 4, 2015 at 6:42 AM, Shantanu Kumar 
wrote:

>
>
> On Wednesday, 4 February 2015 18:26:43 UTC+5:30, Lucas Bradstreet wrote:
>>
>> Component is more for managing state, whereas graph is for structuring
>> computation. All I can really tell you is that after using component I am
>> never going back (at least in Clojure).
>>
>
> With Prismatic graph you can structure a hierarchy of functions that
> initialize parts of app and return functions/protocol implementations, thus
> using it like a dependency injection mechanism. The advantage is you don't
> have to pass a giant map around in the app, avoiding runtime overhead. The
> downside is, this style makes REPL-driven development more challenging.
>
> 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/d/optout.
>



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

Re: OO Programmer trying to move to Clojure: Namespace Organization

[Timothy Baldridge]

When I first came to Clojure (from C# of all things), I had questions like
this too. But over time I've become convinced that it was something I
worried to much about. The guiding rule for code organization should be
this: does it slow you down from the complexity? Are there so many files,
that you're constantly context switching from one file to another? Are
there so few files that you're having problems introducing new programmers
to the code. I don't think there's any one size fits all solution to this.
I think it's different from one project to another.

I have clojure files with just 4 lines of code, and others with 3000 lines
of code (that's a lot for Clojure). It's also not hard to refactor these
things when needed. Especially if you don't use :refer :all in your
namespace declarations. Use one of these forms:

(ns my-ns
  (:require [foo.bar :as f]
[foo.baz :refer [qux qox]]))

Both of these allow for rather quick namespace conversion. If a function
moves locations, it's fairly easy to just do a find/replace on the code.
And the Clojure compiler will also help you, complaining about undefined
vars.

I hope this helps, in short, relax, it's not as big of a problem as it
seems.

Timothy

On Sun, Feb 8, 2015 at 2:48 AM, Atamert Ölçgen  wrote:

> Hi Dru,
>
> I find it easier to organize things when I follow TDD. It's easier for me
> to spot something is in the wrong place (module or maybe as a
> responsibility of a function) by looking at the tests. (This is true for
> any language I work with.)
>
> http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
>
>
> On Sat, Feb 7, 2015 at 6:23 PM, Dru Sellers  wrote:
>
>> Greetings,
>>
>> I am trying to convert my mind from OO (C#) to one more functionally
>> friendly. I am increasingly comfortable with simple applications in
>> clojure, but as I start to build more complex applications, I start to fall
>> down about how to structure my application. I don't want to just shove OO
>> ideas into the functional nature of Clojure. I'm looking for any help
>> someone can provide to help shimmy my brain into the right mental patterns.
>>
>> Background: Long time C# developer who leans heavily on IoC / DI /
>> Interfaces / Testing / Object Encapsulation.
>>
>> Specific Questions: Namespace Organization
>>
>> Now I know this is almost entirely personal preference, but I'm playing
>> with a namespace model that looks like this and I'd love some feed back.
>> Tear it about, bust that red pen out and help me to better think of things
>> in clojure way. I only have my C# / OO background to lean on and need some
>> fresh brain juice. :)
>>
>> I currently organize my projects like this. a spin off of 'duct'
>> https://github.com/weavejester/duct but i'm looking for a bit more
>> detail.
>>
>> Context: Project name is going to be "ford", feature is going to be a
>> simple log of text
>>
>>
>> ~/
>>   src/
>> ford/ - the project
>>   log/ - the feature name
>> http.clj - contains clojure routes at 'http/routes' - orchestrate
>> the business calls
>> model.clj - contains my 'defrecords' / yesql / db calls
>> core.clj - the "business" calls
>>
>>
>> I def have a preference for shorter files rather than longer files
>> I also tend to have a heavy use of 'ceremony' - right now I need a lot of
>> structure because I'm still learning to think in terms of clojure. and I
>> spend a lot of time still reading it rather than thinking about it.
>>
>> Again, thank you.
>>
>> -d
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Kind Regards,
> Atamert Ölçgen
>
> -+-
> --+
> +++
>
> www.muhuk.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For 

Re: Comparison with atom values

[Timothy Baldridge]

deref is used to pull the value out of an atom, ref, or atom (or other
reference type).

(= (deref a) 0)  gives --> true

Also there is a shorthand operator:

(= @a 0)

Timothy

On Thu, Feb 12, 2015 at 12:27 PM, Newbie  wrote:

> I am trying to compare atom values with numbers. For e.g. -
>
> (def a (atom 0))
> (print a) gives --> #
> (= a 0) gives --> false
>
> How do I make this work? How do I compare 0 with the atom value? I want to
> do the same for a string to?
> I cannot use compare-and-set! for my situation.
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

Re: [newbie] strange behaviour in self-referential primes lazy-seq attempt

[Timothy Baldridge]

Oh, it's much worse than anyone has mentioned yet. The whole (def primes
...) bit is also a problem. What you are saying to the compiler is "create
a var named primes and assign it this lazy-seq...", and then while defining
that lazy seq you are creating closures that use "primes". That sort of
circular referencing is not only not recommended for code clarity reasons,
but also a problem because parts of the code are delayed.

What you are attempting to do is something akin to this:

(def foo (fn [] (foo)))

Which makes no sense at all. This is pretty much what Clojure lazy seqs
are, a list who's contents are delayed via a closure.

So yes, I would say most Clojure programmers are completely fine with this,
as no one writes Clojure code in a self-referential way like this. Not only
is it completely undefined, it's also quite hard to understand.

Timothy

On Thu, Feb 12, 2015 at 9:24 PM, Justin Smith  wrote:

> Not unbound primes, primes as (cons 2 ...). If you look at my post above
> where I added a print statement to prime? the first 32 inputs see (2) as
> the value of primes. 32 is the chunking size of the range function.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

Re: Removing the 5th, 10th, 15th ... element of a list

[Timothy Baldridge]

True, that works, but he wants to remove based on element position, not
element value.

Timothy

On Tue, Feb 17, 2015 at 12:28 PM, Ivan L  wrote:

> this works
>
> => (filter #(not= (mod % 5) 0) (range 22))
> (1 2 3 4 6 7 8 9 11 12 13 14 16 17 18 19 21)
>
>
> On Tuesday, February 17, 2015 at 2:21:20 PM UTC-5, Cecil Westerhof wrote:
>>
>> What is the best way to remove all elements which position (counting from
>> 1) is a multiply of five out of a list?
>>
>> So the list:
>> (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21)
>> ​becomes:
>> (1 2 3 4 6 7 8 9 11 12 13 14 16 17 18 19 21)​
>>
>> --
>> Cecil Westerhof
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

Re: Removing the 5th, 10th, 15th ... element of a list

[Timothy Baldridge]

Tweak as needed:

(keep-indexed
  (fn [i v]
(if (= 0 (mod i 5))
  nil
  v))
  (range 30))

On Tue, Feb 17, 2015 at 12:21 PM, Cecil Westerhof 
wrote:

> What is the best way to remove all elements which position (counting from
> 1) is a multiply of five out of a list?
>
> So the list:
> (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21)
> ​becomes:
> (1 2 3 4 6 7 8 9 11 12 13 14 16 17 18 19 21)​
>
> --
> Cecil Westerhof
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

Re: Removing the 5th, 10th, 15th ... element of a list

[Timothy Baldridge]

Clearly the answer is a program that runs every snippet posted to this
mailing list through kibit (https://github.com/jonase/kibit).

On Tue, Feb 17, 2015 at 1:49 PM, Colin Yates  wrote:

> Style police would point out zero? and when-not :).
> On 17 Feb 2015 20:40, "Cecil Westerhof"  wrote:
>
>> 2015-02-17 20:26 GMT+01:00 Timothy Baldridge :
>>
>>> Tweak as needed:
>>>
>>> (keep-indexed
>>>   (fn [i v]
>>> (if (= 0 (mod i 5))
>>>   nil
>>>   v))
>>>   (range 30))
>>>
>>
>> ​I made the following:
>> ​
>>
>> ​(defn indexed-sieve [index this-list]
>>   (keep-indexed
>> (fn [i v]
>>   (if (= 0 (mod (inc i) index))
>>   nil
>> v))
>> this-list))
>>
>> The first element should not be filtered (counting from 1) and because I
>> will use it more often I created a function.​
>>
>>
>>
>>> On Tue, Feb 17, 2015 at 12:21 PM, Cecil Westerhof <
>>> cldwester...@gmail.com> wrote:
>>>
>>>> What is the best way to remove all elements which position (counting
>>>> from 1) is a multiply of five out of a list?
>>>>
>>>> So the list:
>>>> (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21)
>>>> ​becomes:
>>>> (1 2 3 4 6 7 8 9 11 12 13 14 16 17 18 19 21)​
>>>>
>>>
>> --
>> Cecil Westerhof
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

Re: core.async why 42 extra threads?

[Timothy Baldridge]

The  number of threads is meant to be semi-tolerant to usage of blocking IO
in go blocks. You can't be certain that some go block won't call a function
that calls a function in some library that blocks for just a few
milliseconds. So we tried to make it high enough to be tolerant of mis-use,
but low enough to be bounded somewhat.

So yes, the number + 42 is arbitrary (and somewhat of a joke) but the fact
that it's more than 2 * CPUs is intentional.

Timothy

On Thu, Feb 19, 2015 at 5:02 AM, Robin Heggelund Hansen <
skinney...@gmail.com> wrote:

> From the source of core.async, I see that it is started with a threadpool
> of *2 + 42.
>
> I can understand the number of processors * 2 part, erlang does the same
> thing. But Hitchicker's references aside, why add 42 to this? Won't that
> many threads do more harm than good, in terms of overhead related to
> context switching?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

Re: Side Effects and compiler optimzation

[Timothy Baldridge]

In short, it doesn't. And I think the fact that Clojure is as fast as it is
is testament to how little of an impact many of these optimizations have.

But also, don't assume that Clojure doesn't get many of these optimizations
for free from the JVM. Auto-caching is a weird one,  I think most people
just don't compute the same thing twice. But out-of-order execution is an
optimization performed by both the JVM and x86 CPUs. If a given line of
code doesn't call a native (non-JVM) function and if a given bit of code
doesn't depend on another bit of code, those two bits may be reordered or
executed in a different way. And modern CPUs may actually execute those
bits in parallel if given conditions are met.

So it's true, the Clojure compiler isn't that sophisticated, but combined
with the JVM it's optimizations are actually quite powerful.

Timothy

On Thu, Feb 19, 2015 at 5:11 AM, Ashish Negi 
wrote:

> I tried to find old threads for my question but could not find any
> suitable answer.
>
> My question is that unlike haskell, which separates I/O side effect code
> from pure code, and hence can easily do other optimizations
> like auto-caching results, out of flow execution etc, what is the clojure
> way of doing these optimizations ?
>
> I ponder over that since one can call side-effecting-functions any where
> in clojure code, How is it possible to do all those optimizations that we
> talk
> about in case of FP ?
>
> Thanks
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

Re: defmulti: dispatch function is not called

[Timothy Baldridge]

Except that doesn't work, since the var is de-reffed when handed to the
defmulti. You can var quote it, and that should work:

(defmulti create-fact #'create-fact-dispatch)


Timothy


On Mon, Feb 23, 2015 at 8:44 AM, Francis Avila  wrote:

> You can work around this by using a symbol for the dispatch function
> instead of inlining the function:
>
> (defn create-fact-dispatch [item-vector]
>   (do
> (print item-vector)
> (first item-vector)))
>
>
> (defmulti create-fact create-fact-dispatch)
>
>
>
> When you reload in the REPL the defmulti will not be redefed, but the
> dispatch function will. This is usually all you need when you are messing
> around in the REPL.
>
> There may be some performance cost, but I don't know if it is significant.
> There is at least the var lookup cost. Maybe defmulti dispatch result can't
> be cached? (not sure)
>
> On Sunday, February 22, 2015 at 12:19:24 PM UTC-6, Timur wrote:
>>
>> Thank you all for your answers. The problem was caused by not starting
>> the REPL. I did not know that defmulti had defonce semantics.
>>
>> On Sunday, February 22, 2015 at 7:04:58 PM UTC+1, Jeremy Heiler wrote:
>>>
>>> On 2/22/15 12:52 PM, Timur wrote:
>>> > Hi everyone,
>>> >
>>> > I have the following question regarding the defmultis of clojure:
>>> >
>>> > (defmulti create-fact
>>> >(fn [item-vector] (do
>>> >(print item-vector)
>>> >(first item-vector
>>> >
>>> > (defmethod create-fact [:a] [item-vector]
>>> >(str "a"))
>>> >
>>> > (defmethod create-fact [[:a "safs"]] [item-vector]
>>> >(str "safs"))
>>> >
>>> >
>>> > (mapv create-fact {:a "safs"})
>>> >
>>> >
>>> > Dispatch function is not called in this case and return is "safs" so
>>> the
>>> > matching key is [[:a "safs"]]. I except it to be :a, why is that [[:a
>>> > "safs"]]?
>>>
>>> First, observe:
>>>
>>>  > (seq {:a 1 :b 2})
>>> ([:a 1] [:b 2])
>>>
>>> A map is converted into a sequence with each element being a key/value
>>> pair. The mapv function does this under the hood so that it can operate
>>> on the map as a sequence.
>>>
>>> Now, when I run your code, I get an IllegalArgumentException stating
>>> that :a is not a dispatch value. This is correct, because the two
>>> dispatch values defined are [:a] and [[:a "safs"]]. If you change the
>>> [:a] method to be :a, then the return value will be "a". The dispatch
>>> values in each defmethod must be literal, and not wrapped in a vector
>>> like when defining the arguments to a fn.
>>>
>>> Does that clear things up?
>>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

Re:

[Timothy Baldridge]

I normally either do something like this:

(apply str (concat ["a" "b"]
(map name :c :d)
["e" "f"]))

Or use java's StringBuilder, it's a mutable black box, but appending is
pretty efficient, and doesn't involve the creation of a ton of seqs like
the above method does.

Timothy

On Thu, Feb 26, 2015 at 12:39 PM, Cecil Westerhof 
wrote:

> At the moment I have the following code:
> (str ""
>  "  "style='font-family:Arial; font-size:16px; margin:
> 10px;width:100%'>"
>  ""
>  "Quote"
>  "Author"
>  "")
>
> But I want to make it more generic: the th lines should be data-driven.
> There is a headers variable and when this contains:
> '(:quote "Quote" :author "Author")
>
> Then the above should be generated. So for every odd position (counting
> from 0) a th string should be inserted. How would I do this?
>
> --
> Cecil Westerhof
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

Re: Disk based caching for Clojure app

[Timothy Baldridge]

The whole "SSD fails after X number of writes" thing is pretty much a myth
now that most drives implement pretty aggressive write leveling. These
modern drives introduce a mapping layer between the physical disk locations
and the location written to by the OS. This means that writing to "KB 4242"
on the disk actually is written to a different part of the disk each time
it is written.

Some recent tests report about 1PB of writes before failure (
http://techreport.com/review/27436/the-ssd-endurance-experiment-two-freaking-petabytes).
Let's say your caching system generated and trashed 20GB of data a day,
that would leave you with about 130 years before the drive failed. So yes,
it's limited but not very limited.

On Fri, Mar 6, 2015 at 3:53 PM, Luc Prefontaine  wrote:

> We have been running builds on the same SSDs, doing intensive logging, ...
> for three years now.
>
> None deteriorated.
>
> Builds are mainly scrap & write thousands of small files plus a few big
> ones (the targets).
>
> Write speed makes a huge difference for this kind of task.
>
> Aws allows to get VMs with SSDs of decent sizes and not to store only the
> OS.
>
> I think they would restrict usage if
> rewrites were a huge concern...
>
> Luc P.
>
> > On Friday, March 6, 2015 at 3:16:09 PM UTC-5, Michael Blume wrote:
> > >
> > > Possibly stupid question: can you just pretend you have more memory
> than
> > > you do and let the operating system do the heavy lifting?
> > >
> > As in, put the swap partition on the SSD and jack up the virtual memory
> in
> > the OS config?
> >
> > Isn't it a bad idea to put swap on an SSD, because of the limited number
> of
> > times an SSD byte can be rewritten before it sticks permanently? Thus
> > making SSD more suited to storing stuff where speed counts, but which
> > doesn't change very much, like the operating system kernel and modules
> and
> > core libraries, plus your most often used applications? Then you get
> faster
> > boot and app-startup times without constant writes to the SSD (just when
> > something is upgraded).
> >
> > Of course, SSD being less well suited to frequently-written data would
> also
> > militate against using it for a cache managed by the application, rather
> > than by the OS ...
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
> --
> Luc Prefontaine sent by ibisMail!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

Re: volatile vs java.util.concurrent.atomic.* vs atom

[Timothy Baldridge]

This is interesting, but there could be many things in play here. Try
re-running the tests outside of lein (via compilation to a uberjar and then
running with java -jar) and also use criterium, as it will warn about many
things that coul effect performance .

https://github.com/hugoduncan/criterium

Timothy Baldridge

On Wed, Mar 11, 2015 at 9:38 AM, Brent Millare 
wrote:

> Doing some simple microbenchmarks, I found something unexpected:
>
> (time
>  (let [v (volatile! 1)]
>(dotimes [x 1]
>  (vreset! v @v
> "Elapsed time: 1016.992146 msecs"
>
> (time
>  (let [v (java.util.concurrent.atomic.AtomicLong. 1)]
>(dotimes [x 1]
>  (.set v (.get v)
> "Elapsed time: 672.869727 msecs"
>
> (time
>  (let [v (java.util.concurrent.atomic.AtomicReference. {})]
>(dotimes [x 1]
>  (.set v (.get v)
> "Elapsed time: 678.143133 msecs"
>
> (time
>  (let [v (atom 1)]
>(dotimes [x 1]
>  (reset! v @v
> "Elapsed time: 1100.689493 msecs"
>
> I expected volatile's to be faster. Maybe I'm not understanding the
> correct use case for volatiles but java.util.concurrent.atomic.Atomic*
> seems to be clearly the most performant. Given the downsides of using
> volatiles, is their existence justified when safer and faster alternatives
> exist?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

Re: volatile vs java.util.concurrent.atomic.* vs atom

[Timothy Baldridge]

There's many other factors involved here though, GC, JIT warmup, etc.
That's kindof what criterium helps out with, removing all the variables and
running something until the JIT has warmed up enough (10 iterations
probably isn't enough).

Timothy

On Wed, Mar 11, 2015 at 10:19 AM, Brent Millare 
wrote:

> Well not exactly what you said cause I'm lazy, but a little bit more
> controlled:
>
> timereference.clj:
> (println "Java: "(System/getProperty "java.version"))
> (println (clojure-version))
>
> (dotimes [y 10]
>   (print "volatile: ")
>   (time
>(let [v (volatile! 1)]
>  (dotimes [x 1]
>(vreset! v @v
>
>   (print "AtomicLong: ")
>   (time
>(let [v (java.util.concurrent.atomic.AtomicLong. 1)]
>  (dotimes [x 1]
>(.set v (.get v)
>
>   (print "AtomicReference: ")
>   (time
>(let [v (java.util.concurrent.atomic.AtomicReference. {})]
>  (dotimes [x 1]
>(.set v (.get v)
>
>   (print "atom: ")
>   (time
>(let [v (atom 1)]
>  (dotimes [x 1]
>(reset! v @v)
>
>
> [bmillare@sakura ~]$ java -server -cp
> .m2/repository/org/clojure/clojure/1.7.0-alpha5/clojure-1.7.0-alpha5.jar
> clojure.main timereference.clj
> Java:  1.7.0_75
> 1.7.0-alpha5
> volatile: "Elapsed time: 793.525092 msecs"
> AtomicLong: "Elapsed time: 606.658899 msecs"
> AtomicReference: "Elapsed time: 606.253989 msecs"
> atom: "Elapsed time: 881.198546 msecs"
> volatile: "Elapsed time: 787.714655 msecs"
> AtomicLong: "Elapsed time: 603.810759 msecs"
> AtomicReference: "Elapsed time: 603.811366 msecs"
> atom: "Elapsed time: 1417.625552 msecs"
> volatile: "Elapsed time: 794.154652 msecs"
> AtomicLong: "Elapsed time: 603.718131 msecs"
> AtomicReference: "Elapsed time: 603.723479 msecs"
> atom: "Elapsed time: 866.220579 msecs"
> volatile: "Elapsed time: 787.459397 msecs"
> AtomicLong: "Elapsed time: 603.735881 msecs"
> AtomicReference: "Elapsed time: 603.720108 msecs"
> atom: "Elapsed time: 866.208679 msecs"
> volatile: "Elapsed time: 787.455661 msecs"
> AtomicLong: "Elapsed time: 603.720906 msecs"
> AtomicReference: "Elapsed time: 603.735316 msecs"
> atom: "Elapsed time: 866.226066 msecs"
> volatile: "Elapsed time: 787.455482 msecs"
> AtomicLong: "Elapsed time: 603.720222 msecs"
> AtomicReference: "Elapsed time: 603.718667 msecs"
> atom: "Elapsed time: 866.205402 msecs"
> volatile: "Elapsed time: 789.429405 msecs"
> AtomicLong: "Elapsed time: 603.71242 msecs"
> AtomicReference: "Elapsed time: 603.717922 msecs"
> atom: "Elapsed time: 866.212896 msecs"
> volatile: "Elapsed time: 787.461736 msecs"
> AtomicLong: "Elapsed time: 603.728396 msecs"
> AtomicReference: "Elapsed time: 603.727234 msecs"
> atom: "Elapsed time: 866.203579 msecs"
> volatile: "Elapsed time: 787.462185 msecs"
> AtomicLong: "Elapsed time: 603.721207 msecs"
> AtomicReference: "Elapsed time: 603.716769 msecs"
> atom: "Elapsed time: 866.207913 msecs"
> volatile: "Elapsed time: 787.468805 msecs"
> AtomicLong: "Elapsed time: 603.721715 msecs"
> AtomicReference: "Elapsed time: 603.73172 msecs"
> atom: "Elapsed time: 866.210223 msecs"
>
>
> On Wednesday, March 11, 2015 at 11:57:50 AM UTC-4, tbc++ wrote:
>>
>> This is interesting, but there could be many things in play here. Try
>> re-running the tests outside of lein (via compilation to a uberjar and then
>> running with java -jar) and also use criterium, as it will warn about many
>> things that coul effect performance .
>>
>> https://github.com/hugoduncan/criterium
>>
>> Timothy Baldridge
>>
>> On Wed, Mar 11, 2015 at 9:38 AM, Brent Millare 
>> wrote:
>>
>>> Doing some simple microbenchmarks, I found something unexpected:
>>>
>>> (time
>>>  (let [v (volatile! 1)]
>>>(dotimes [x 1]
>>>  (vreset! v @v
>>> "Elapsed time: 1016.992146 msecs"
>>>
>>> (time
>>>  (let [v (java.util.concurrent.atomic.AtomicLong. 1)]
>>>(dotimes [x 1]
>>>  (.set v (.get v)
>>> "Elapsed time: 672.869727 msecs"
>>>
>>> (time
>>>  (let [v (java.util.concurrent.atomic.Atomic