Re: GSOC Algebraic Expressions

[Maik Schünemann]

Great resource!
I hope you don't mind if I steal ideas from it :)


On Thu, May 30, 2013 at 8:42 AM, Jonas  wrote:

> This is a very interesting project. I look forward to following its
> development.
>
> I did a presentation[1] on the implementation of the kibit[2] rule system
> a few weeks ago which you might find interesting since it's using
> core.logic as well.
>
> [1] http://jonase.github.io/kibit-demo/
> [2] https://github.com/jonase/kibit
>
> Jonas
>
> On Wednesday, May 29, 2013 6:10:52 PM UTC+3, Maik Schünemann wrote:
>>
>> Hello,
>> I am glad to announce that my proposal got accepted for google summer of
>> code.
>> I am doing the algebraic expression project idea which could lay the
>> foundation for a clojure CAS System by providing a library to manipulate
>> expressions syntactically
>> and also solving equations and optimizing them for evaluation on top of
>> core.matrix.
>>
>> I have created a blog post in which I explained it in more detail and
>> also the design decisions I have to make in the beginning, such as how to
>> represent an expression,
>> a rule, how to deal with core.logic ...
>> http://kimavcrp.blogspot.de/**201blog post3/05/gsoc-project-**
>> algebraic-expressions-pre.html
>>
>> Please comment if you have feedback or feature request or have a concrete
>> use case for what you would want to use it. The more feedback I get the
>> better I can make the
>> library.
>>
>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Use of io!

[Alex Baranosky]

Do any of you ever use io! ?  I've never used it, but could see using it if
I had a transaction-heavy application.

On Wed, May 29, 2013 at 11:43 PM, Michael Klishin <
michael.s.klis...@gmail.com> wrote:

> 2013/5/30 Josh Kamau 
>
>> Whats the point of using io! inside dosync if all it does is make an
>> exception to be thrown?
>
>
> The point is to mark side-effecting code so that you can't accidentally
> use it in a transaction.
> --
> 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.
>
>
>

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

[Kris Jenkins]

PS: I've created an Emacs major-mode for 
wisp: https://github.com/krisajenkins/wisp-mode

On Monday, 27 May 2013 11:09:56 UTC+1, Kris Jenkins wrote:
>
> I've played around with it a fair bit and it's got promise. Despite 
> appearances, it's not really a Clojure - as David says it's missing a lot 
> of features that make Clojure more than Just Another Lisp. It's probably 
> best to think of it as its own Lisp that's adopted Clojure's modernised 
> syntax.
>
> With that in mind, there are some things I really like about it. It's nice 
> to be able to write Lisp for the browser without using the JVM as a 
> middle-man. It's nice to get a small compiled file without having to 
> negotiate with the Google Closure compiler. JavaScript interop is easy, as 
> is using existing Node packages. And there's good reason to 
> thinkit'll get source map support 
> support first, which will be a godsend for 
> debugging.
>
> On the downside, the first things that come to mind are a lack of 
> destructing binds, and its lazy-seq implementation is borked. There's 
> plenty that you'll miss if you go in expecting Clojure.
>
> I think it's a project to keep an eye on. I'm using it in some personal 
> projects, but I wouldn't use it for production. With some work, it'll still 
> be a lesser language than ClojureScript, but one with a better development 
> & deployment experience. Personally I hope it spurs some more work on 
> ClojureScript-in-ClojureScript...
>
> Kris
>
> On Saturday, 25 May 2013 00:59:22 UTC+1, Rich Morin wrote:
>>
>> I saw  mention of Wisp the other day (on Hacker News, IIRC), but I 
>> haven't noticed any discussion of it on the Clojure email list, 
>> (def newsletter), etc: 
>>
>>   Wisp is a homoiconic JavaScript dialect with clojure syntax, 
>>   s-expressions and macros.  Unlike clojurescript, Wisp code 
>>   compiles to human-readable JavaScript.  The goal of Wisp is 
>>   to compile to the JavaScript you would have written anyway. 
>>   Think of Wisp asmarkdown for JS programing! 
>>
>>   Homoiconic syntax and macros are the primary motivations! 
>>
>>   -- https://github.com/Gozala/wisp 
>>
>>   See also   http://jeditoolkit.com/try-wisp/ 
>>
>> Has anyone here played with Wisp?  Any reactions? 
>>
>> -r 
>>
>>  -- 
>> http://www.cfcl.com/rdmRich Morin 
>> http://www.cfcl.com/rdm/resume r...@cfcl.com 
>> http://www.cfcl.com/rdm/weblog +1 650-873-7841 
>>
>> Software system design, development, and documentation 
>>
>>
>>  
>

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

[Josh Kamau]

Thanks guys. Now i understand its for "marking" functions containing io so
that they blow up if they are used inside transactions.  I am still
learning clojure and i have decided to take some time to understand every
function in the core API.

Josh.


On Thu, May 30, 2013 at 11:10 AM, Alex Baranosky <
alexander.barano...@gmail.com> wrote:

> Do any of you ever use io! ?  I've never used it, but could see using it
> if I had a transaction-heavy application.
>
>
> On Wed, May 29, 2013 at 11:43 PM, Michael Klishin <
> michael.s.klis...@gmail.com> wrote:
>
>> 2013/5/30 Josh Kamau 
>>
>>> Whats the point of using io! inside dosync if all it does is make an
>>> exception to be thrown?
>>
>>
>> The point is to mark side-effecting code so that you can't accidentally
>> use it in a transaction.
>> --
>> 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.
>>
>>
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: [ANN] lein-pedantic is now deprecated

[Murtaza Husain]

+1 for both features. Nelson thanks for the plugin, I have been using it on 
my projects.

On Thursday, May 30, 2013 9:11:17 AM UTC+5:30, tbc++ wrote:
>
> +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 clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com 
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>  
>>>  
>>>
>>
>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to 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.

Re: Future/Promise and not using threads

[Mark Engelberg]

According to this article, Clojure does not yet have this facility:
http://java.dzone.com/articles/promises-and-futures-clojure

This is something that is being worked on and discussed, though:
http://dev.clojure.org/display/design/Promises
https://groups.google.com/forum/#!topic/clojure-dev/7BKQi9nWwAw/discussion
http://dev.clojure.org/display/design/Async+blocks

I've been hearing a lot about Tellman's lamina library as a rich Clojure
toolset for working with asynchronicity.  I haven't had a need for it
myself, but you might want to check it out and see if it has relevance to
what you want to do.

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

Re: A blocking lazy sequence populated by multiple worker threads

[Colin Yates]

Can you not use 
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/LinkedBlockingQueue.html?
 
 That will provide the blocking element.  

To execute N (i.e. 10 in your example) use a 
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html.
 
 The 'glue' would be an infinite loop which .takes from the incoming 
sequence (which could also be a LBQ) and then puts it on the thread pool.

That gets stuff happening in parallel.  

To consume the results of that stuff in a sequence have a(nother) LBQ which 
the consumers consume (using the blocking .take) and have the glue code 
wrap the function it received from the LBQ in a function which takes the 
result of that function and puts it on the sequence.  

This looks like (clojure forgiveness is required):

[code]
(def incoming-queue (javaLinkedBlockingQueue.))
(def outgoing-queue (javaLinkedBlockingQueue.))
(def workers (java... some thread pool/executor.))

; the following would need to reify itself to be a Runnable, not got that 
far yet :)
(defn execute [job result-queue] (let [result (job)] (.put result-queue 
result)))

(def stop-loop (atom false))
(while (not @stop-loop)
  (def next (.take incoming-queue))
  (execute next outgoing-queue))
[/code]

A few caveats/notes:
 - this uses a lot of Java constructs - that is fine.  It is perfectly 
idiomatic to use the right Clojure or Java constructs.  LBQs rock.
 - the above won't compile and the 'execute' needs to return a Runnable - 
not sure how.
 - it ties up a worker thread until the result can be put onto the outgoing 
LBQ.  If the outgoing LBQ is bounded and you don't have enough consumers 
then eventually all the worker threads will be effectively idle until the 
results can be consumed.  
 - if you didn't want to use a ThreadPool then you could update 'executor' 
to maintain an (atom) number of currently executing jobs.  The glue code is 
single threaded so no chance of multiple jobs starting in parallel.  The 
single threaded 'cost' is fine as it is doing nothing other than moving 
things around.

I am a (Clojure) newbie so be warned!  I fully look forward to somebody 
providing a much nicer and more idiomatic Clojure implementation :).

Hope this helps.

Col

On Thursday, 30 May 2013 06:19:29 UTC+1, Artem Boytsov wrote:
>
> Hello, folks!
>
> I'm a relative noob in Clojure especially when it comes to concurrency, so 
> please forgive my ignorance. I have a processing stage (producer) that 
> feeds to another one (consumer). The producer has a bunch of items to 
> process and it's I/O blocking which takes random time, but the order of the 
> items is insignificant, so ideally they would materialize on the consumer 
> side on the first come first serve basis.
>
> I would like to create a blocking lazy sequence I could just give to the 
> consumer. I know how to create a lazy sequence (lazy-seq), or how to make 
> it run in background and block on results (seque), but what I can't wrap my 
> head around is how parallelize the processing the Clojure way. I was 
> considering kicking off multiple agents, but how can I wait for *any one *of 
> them to finish, not all of them (as await does)? I'm not sure but I think 
> the same goes for futures/promises. I could have multiple agents putting 
> the results into some shared sequence, but then how do I block on the 
> sequence itself?
>
> What I'm trying to do can be described in the following way in a silly 
> imperative pseudo-code:
>
> workers = new Worker[10]   ; initially w.got_data == 
> nil 
> for each x in source_data:
>w = wait_for_any_worker_ready(workers)  ; initially all of them are 
> ready
>if (w.got_data) 
>  output.enqueue(w.data); the consumer will read 
> output in a blocking way
>  w.process(x)  ; non-blocking, kicks off 
> in the background
>
> Or, another way to describe it, given a seq of integers:
>
> [ 1, 2, 3, 4 ... ]
>
> and a simple function with a variable delay:
>
> (defn process [x]
>(Thread/sleep (* 1 (rand)))
>(* 2 x))
>
> How can I write a function which would return a blocking lazy sequence of 
> processed integers, in arbitrary order, parallelizing the processing in up 
> to 10 threads?
>
> Thank you!
>
> Artem.
>

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

Re: Future/Promise and not using threads

[Gary Trakhman]

Maybe an easy solution: wrap the first future in another future that
blocking-derefs, then performs your extra computation?  Do an extra
'realized?' check for the optimization you mention.  That would still
consume threads in the case that it's not realized, but I think it gets you
what you want.


On Thu, May 30, 2013 at 5:09 AM, Mark Engelberg wrote:

> According to this article, Clojure does not yet have this facility:
> http://java.dzone.com/articles/promises-and-futures-clojure
>
> This is something that is being worked on and discussed, though:
> http://dev.clojure.org/display/design/Promises
> https://groups.google.com/forum/#!topic/clojure-dev/7BKQi9nWwAw/discussion
> http://dev.clojure.org/display/design/Async+blocks
>
> I've been hearing a lot about Tellman's lamina library as a rich Clojure
> toolset for working with asynchronicity.  I haven't had a need for it
> myself, but you might want to check it out and see if it has relevance to
> what you want to do.
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

[Gary Trakhman]

by the second future, I mean an instance of
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Future.html ,
which just has to conform to the interface, and doesn't actually have to
execute on a different thread.  Clojure's 'future' function returns an
instance of one of these that uses the unbounded agent thread-pool, but you
would be free to return one using reify or something.

https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L6320


On Thu, May 30, 2013 at 5:14 AM, Gary Trakhman wrote:

> Maybe an easy solution: wrap the first future in another future that
> blocking-derefs, then performs your extra computation?  Do an extra
> 'realized?' check for the optimization you mention.  That would still
> consume threads in the case that it's not realized, but I think it gets you
> what you want.
>
>
> On Thu, May 30, 2013 at 5:09 AM, Mark Engelberg 
> wrote:
>
>> According to this article, Clojure does not yet have this facility:
>> http://java.dzone.com/articles/promises-and-futures-clojure
>>
>> This is something that is being worked on and discussed, though:
>> http://dev.clojure.org/display/design/Promises
>> https://groups.google.com/forum/#!topic/clojure-dev/7BKQi9nWwAw/discussion
>> http://dev.clojure.org/display/design/Async+blocks
>>
>> I've been hearing a lot about Tellman's lamina library as a rich Clojure
>> toolset for working with asynchronicity.  I haven't had a need for it
>> myself, but you might want to check it out and see if it has relevance to
>> what you want to do.
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>

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

[Bruce Durling]

I've been using it as well. so +1

cheers,
Bruce

On Thu, May 30, 2013 at 10:07 AM, Murtaza Husain
 wrote:
>
> +1 for both features. Nelson thanks for the plugin, I have been using it on
> my projects.
>
>
> On Thursday, May 30, 2013 9:11:17 AM UTC+5:30, tbc++ wrote:
>>
>> +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 clo...@googlegroups.com

 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com

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

 For more options, visit https://groups.google.com/groups/opt_out.


>>>
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to 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.
>
>



-- 
@otfrom | CTO & co-founder @MastodonC | mastodonc.com
See recent coverage of us in the Economist http://econ.st/WeTd2i and
the Financial Times http://on.ft.com/T154BA

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

[Michael Klishin]

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.

Re: What is the status of Clojure on LLVM or C?

[Dax Fohl]

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.

Re: [ANN] peridot 0.2.1 released

[Nelson Morris]

Thanks for posting the link. I'll have to make sure to follow an ANN guide
instead of memory next time.
On May 29, 2013 11:40 PM, "Michał Marczyk"  wrote:

> https://github.com/xeqi/peridot
>
>
> On 30 May 2013 06:13, Michael Klishin  wrote:
> >
> > 2013/5/30 Nelson Morris 
> >>
> >> peridot is a library for interacting with ring apps while maintaining
> >> state between requests, such as a cookie jar
> >
> >
> > Nelson,
> >
> > Does your project have a site or a github repo? There are no links in
> your
> > announcement.
> > --
> > 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.
> >
> >
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and 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.

clojure-west videos clarification

[Jim - FooBar();]

Hi all,

I just stumbled upon this: 
http://clojurewest.org/news/2013/5/29/clojurewest-2013-videos-1.html
but I have a question! Can anyone clarify (maybe Alex?) what the dates 
right next to the presentation topic mean? Are they when the talk was 
given or when the talk will be released on infoq?


I'm asking this because the first 2 talks (which have indeed been 
released) show date [ 5/20/2013] which I suppose is the date they were 
released on infoq.
However, the 3rd and 4rth presentation are nowhere to be found, even 
though the 27th of May has passed...I must be missing something yes?... :-(


thanks in advance,

Jim

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

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

query edn

[Mimmo Cosenza]

Hi,
is there an already defined query language for EDN as we have for JASON? Is 
there an already defined data modeling language for EDN as we have for 
jason? 

Does someone working on it? Do Datomic/Datalogic have something similar to 
be used/adapted? 

Thanks so much

Mimmo


 

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

[John D. Hume]

On May 30, 2013 4:12 AM, "Colin Yates"  wrote:
> ; the following would need to reify itself to be a Runnable, not got that
far yet :)
> (defn execute [job result-queue] (let [result (job)] (.put result-queue
result)))
>

A no-args fn is both a perfectly good Callable and a perfectly good
Runnable, making interop with java.util.concurrent pretty painless.

So it takes as little as
#(execute my-job my-queue)

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

[Benjamin R. Haskell]

On Thu, 30 May 2013, Jim - FooBar(); wrote:


Hi all,

I just stumbled upon this: 
http://clojurewest.org/news/2013/5/29/clojurewest-2013-videos-1.html
but I have a question! Can anyone clarify (maybe Alex?) what the dates 
right next to the presentation topic mean? Are they when the talk was 
given or when the talk will be released on infoq?



From that page:


"Videos are listed by the week of release (day will vary)."

--
Best,
Ben

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

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

Re: What is the status of Clojure on LLVM or C?

[Gary Trakhman]

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.


On Thu, May 30, 2013 at 8:15 AM, Timothy Baldridge wrote:

> 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.
>
>
>

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

[Dax Fohl]

So what do you see as the advantage in going the clojure-metal path?  Is it 
that RPython is such a pain to debug that it ends up not being worth it in 
the end?  Is the tradeoff essentially being able to do things exactly how 
you want in LLVM versus having to put up with warts that might not quite 
fit in PyPy?  Or is there something the clojure-metal path will make easier 
than going with RPython?  (Also didn't I see in the clojure-py blog once 
that you overcame the lack of threading by launching separate processes? 
 Is there a reason that wouldn't work in the real world?)

On Thursday, May 30, 2013 8:15:29 PM UTC+8, tbc++ wrote:
>
> 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. 
>

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

[Colin Yates]

Nice.


On 30 May 2013 12:57, John D. Hume  wrote:

> On May 30, 2013 4:12 AM, "Colin Yates"  wrote:
> > ; the following would need to reify itself to be a Runnable, not got
> that far yet :)
> > (defn execute [job result-queue] (let [result (job)] (.put result-queue
> result)))
> >
>
> A no-args fn is both a perfectly good Callable and a perfectly good
> Runnable, making interop with java.util.concurrent pretty painless.
>
> So it takes as little as
> #(execute my-job my-queue)
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 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/C6JRJfruoQA/unsubscribe?hl=en.
> 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.

Re: Future/Promise and not using threads

[David Pollak]

Okay... I wrote my own:

https://github.com/projectplugh/plugh/blob/master/src/plugh/util/misc.clj#L51

One can register for on-done and on-fail. I'll work on adding fail-fast and
also map (so one can transform the future and execute code when the
transformed future has been realized/delivered/finished).

Thanks for your help!



On Thu, May 30, 2013 at 2:17 AM, Gary Trakhman wrote:

> by the second future, I mean an instance of
> http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Future.html ,
> which just has to conform to the interface, and doesn't actually have to
> execute on a different thread.  Clojure's 'future' function returns an
> instance of one of these that uses the unbounded agent thread-pool, but you
> would be free to return one using reify or something.
>
>
> https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L6320
>
>
> On Thu, May 30, 2013 at 5:14 AM, Gary Trakhman wrote:
>
>> Maybe an easy solution: wrap the first future in another future that
>> blocking-derefs, then performs your extra computation?  Do an extra
>> 'realized?' check for the optimization you mention.  That would still
>> consume threads in the case that it's not realized, but I think it gets you
>> what you want.
>>
>>
>> On Thu, May 30, 2013 at 5:09 AM, Mark Engelberg > > wrote:
>>
>>> According to this article, Clojure does not yet have this facility:
>>> http://java.dzone.com/articles/promises-and-futures-clojure
>>>
>>> This is something that is being worked on and discussed, though:
>>> http://dev.clojure.org/display/design/Promises
>>>
>>> https://groups.google.com/forum/#!topic/clojure-dev/7BKQi9nWwAw/discussion
>>> http://dev.clojure.org/display/design/Async+blocks
>>>
>>> I've been hearing a lot about Tellman's lamina library as a rich Clojure
>>> toolset for working with asynchronicity.  I haven't had a need for it
>>> myself, but you might want to check it out and see if it has relevance to
>>> what you want to do.
>>>
>>>  --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
Telegram, Simply Beautiful CMS https://telegr.am
Lift, the simply functional web framework http://liftweb.net
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

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

[Jim - FooBar();]

On 30/05/13 13:17, Benjamin R. Haskell wrote:

On Thu, 30 May 2013, Jim - FooBar(); wrote:


Hi all,

I just stumbled upon this: 
http://clojurewest.org/news/2013/5/29/clojurewest-2013-videos-1.html
but I have a question! Can anyone clarify (maybe Alex?) what the 
dates right next to the presentation topic mean? Are they when the 
talk was given or when the talk will be released on infoq?


From that page:

"Videos are listed by the week of release (day will vary)."



oops! you're right...apologies!

Jim

ps: the clojure-scheme presentation is scheduled for Augustcan't 
wait! :)


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

To unsubscribe from this group and 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?

[Jean Niklas L'orange]

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.

Leiningen on CLR

[Plínio Balduino]

Hi there

I'm playing with Clojure CLR (good job, guys) and I miss something like
Leiningen. I quickly saw Kumar's lein-clr, but I don't know if it could be
used in a production environment (or explaining better, in a dev
environment for a production application) and if there is any other
solution.

Thanks in advance

Plinio

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

ref-history-count always return 0?

[Josh Kamau]

(def my-ref (ref 1))



(defn update-my-ref
  [new-value]
  (dosync
(alter my-ref #(+ % new-value))
(ref-history-count my-ref)))

Hi guys ;

I am trying to understand (ref-history-count ref) . I thought it counts the
number of "old" values in the ref.  But in all my tests, its always
returning zero. How is it used?

Josh

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

[Marc Limotte]

Take a look at the 11 minute diatomic query video:
http://www.datomic.com/videos.html#query
That may be what you're looking for, I believe it can work with local
Clojure data sets (e.g. eval'ed EDN) without any connection to a Datomic
database.

Marc


On Thu, May 30, 2013 at 7:56 AM, Mimmo Cosenza wrote:

> Hi,
> is there an already defined query language for EDN as we have for JASON?
> Is there an already defined data modeling language for EDN as we have for
> jason?
>
> Does someone working on it? Do Datomic/Datalogic have something similar to
> be used/adapted?
>
> Thanks so much
>
> Mimmo
>
>
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: query edn

[Giacomo Cosenza]

thanks Marc. I'll take a look at it

Obviously I intended json, non jason..
mimmo


On May 30, 2013, at 4:05 PM, Marc Limotte wrote:

> Take a look at the 11 minute diatomic query video: 
> http://www.datomic.com/videos.html#query
> That may be what you're looking for, I believe it can work with local Clojure 
> data sets (e.g. eval'ed EDN) without any connection to a Datomic database.
> 
> Marc
> 
> 
> On Thu, May 30, 2013 at 7:56 AM, Mimmo Cosenza  
> wrote:
> Hi,
> is there an already defined query language for EDN as we have for JASON? Is 
> there an already defined data modeling language for EDN as we have for jason? 
> 
> Does someone working on it? Do Datomic/Datalogic have something similar to be 
> used/adapted? 
> 
> Thanks so much
> 
> Mimmo
> 
> 
>  
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
> 
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

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

Re: What is the status of Clojure on LLVM or C?

[Gary Trakhman]

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  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.

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: ref-history-count always return 0?

[xumingmingv]

ref-count only increment when one of the following occurs:
* min-history > 0
* ref-read-faults > 0 && current-ref-history-count < max-history-count.

;; ref-count increment because min-history > 0
(let [r (ref 1 :min-history 1)
  f1 (future (dosync (Thread/sleep 1000)
 (println "ref-count: " (ref-history-count r))
 @r))
  f2 (future (dosync (ref-set r 2)))]
  [@f1 @f2])

;; ref-count increment because there's read faults
(let [r (ref 1)
  f1 (future (dosync (Thread/sleep 1000)
 (println "ref-count: " (ref-history-count r))
 @r))
  f2 (future (dosync (ref-set r 2)))
  f3 (future (dosync (Thread/sleep 1500) (ref-set r 2)))]
  [@f1 @f2])


Checkout related clojure source here: 
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LockingTransaction.java#L321-L326

On 2013-5-30, at 下午10:05, Josh Kamau  wrote:

> (def my-ref (ref 1))
> 
> 
> 
> (defn update-my-ref
>   [new-value]
>   (dosync
> (alter my-ref #(+ % new-value))
> (ref-history-count my-ref)))
> 
> Hi guys ; 
> 
> I am trying to understand (ref-history-count ref) . I thought it counts the 
> number of "old" values in the ref.  But in all my tests, its always returning 
> zero. How is it used?  
> 
> Josh
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

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

Re: ref-history-count always return 0?

[Neale Swinnerton]

On Thu, May 30, 2013 at 3:05 PM, Josh Kamau  wrote:
>
> I am trying to understand (ref-history-count ref) . I thought it counts
> the number of "old" values in the ref.  But in all my tests, its always
> returning zero. How is it used?
>

In clojure's STM, history is created only when required. This is a
performance choice, the assumption is that 'most' STM transactions won't
contend. In your case you have only one transaction so no history is ever
created.

Try creating a long running transaction in one thread and executing short
running transactions in other thread(s) all altering the same ref and you
will see history in action.

HTH.

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

[Gary Trakhman]

Yes, it's a half-baked idea, but I'm curious if it might be worth an
experiment.
re: a) yea, I suspected this could get pretty bad, and your comment about
having to mutate counts while traversing it definitely amplifies the effect
of it.

b) real-time is about latency and jitter and such, if throughput is
sufficient. I'm curious how bad it would actually be.  Something that comes
to mind is to simply be careful about sharing data between threads, and to
perform full copies in memory when it's worthwhile to avoid cache misses,
or some thread-local optimizations if possible (I'll go google some papers
before I speculate some more on this). I imagine multi-process python and
clojure would have a similar coordination problem.

I appreciate the feedback, I've been wistfully interested in the topic for
a long time.


On Thu, May 30, 2013 at 10:56 AM, Timothy Baldridge wrote:

> 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 unsubscri

Re: A blocking lazy sequence populated by multiple worker threads

[Artem Boytsov]

Hello, Colin,

I suspected I should turn to existing Java concurrency constructs. Thank 
you very much for your response, and this is what I'm going to do. I was 
just hoping there's some Clojure idiomatic way to solve this, using agents, 
futures, promises, refs, and other Clojure stuff. For example, if there 
were a function taking a list of agents and return any one of them which is 
ready (vs. all of them), I would be able to implement my example relatively 
simply. Just wanted to make sure I'm not missing anything.

Artem.

On Thursday, May 30, 2013 2:12:02 AM UTC-7, Colin Yates wrote:
>
> Can you not use 
> http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/LinkedBlockingQueue.html?
>  
>  That will provide the blocking element.  
>
> To execute N (i.e. 10 in your example) use a 
> http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html.
>  
>  The 'glue' would be an infinite loop which .takes from the incoming 
> sequence (which could also be a LBQ) and then puts it on the thread pool.
>
> That gets stuff happening in parallel.  
>
> To consume the results of that stuff in a sequence have a(nother) LBQ 
> which the consumers consume (using the blocking .take) and have the glue 
> code wrap the function it received from the LBQ in a function which takes 
> the result of that function and puts it on the sequence.  
>
> This looks like (clojure forgiveness is required):
>
> [code]
> (def incoming-queue (javaLinkedBlockingQueue.))
> (def outgoing-queue (javaLinkedBlockingQueue.))
> (def workers (java... some thread pool/executor.))
>
> ; the following would need to reify itself to be a Runnable, not got that 
> far yet :)
> (defn execute [job result-queue] (let [result (job)] (.put result-queue 
> result)))
>
> (def stop-loop (atom false))
> (while (not @stop-loop)
>   (def next (.take incoming-queue))
>   (execute next outgoing-queue))
> [/code]
>
> A few caveats/notes:
>  - this uses a lot of Java constructs - that is fine.  It is perfectly 
> idiomatic to use the right Clojure or Java constructs.  LBQs rock.
>  - the above won't compile and the 'execute' needs to return a Runnable - 
> not sure how.
>  - it ties up a worker thread until the result can be put onto the 
> outgoing LBQ.  If the outgoing LBQ is bounded and you don't have enough 
> consumers then eventually all the worker threads will be effectively idle 
> until the results can be consumed.  
>  - if you didn't want to use a ThreadPool then you could update 'executor' 
> to maintain an (atom) number of currently executing jobs.  The glue code is 
> single threaded so no chance of multiple jobs starting in parallel.  The 
> single threaded 'cost' is fine as it is doing nothing other than moving 
> things around.
>
> I am a (Clojure) newbie so be warned!  I fully look forward to somebody 
> providing a much nicer and more idiomatic Clojure implementation :).
>
> Hope this helps.
>
> Col
>
> On Thursday, 30 May 2013 06:19:29 UTC+1, Artem Boytsov wrote:
>>
>> Hello, folks!
>>
>> I'm a relative noob in Clojure especially when it comes to concurrency, 
>> so please forgive my ignorance. I have a processing stage (producer) that 
>> feeds to another one (consumer). The producer has a bunch of items to 
>> process and it's I/O blocking which takes random time, but the order of the 
>> items is insignificant, so ideally they would materialize on the consumer 
>> side on the first come first serve basis.
>>
>> I would like to create a blocking lazy sequence I could just give to the 
>> consumer. I know how to create a lazy sequence (lazy-seq), or how to make 
>> it run in background and block on results (seque), but what I can't wrap my 
>> head around is how parallelize the processing the Clojure way. I was 
>> considering kicking off multiple agents, but how can I wait for *any one 
>> *of them to finish, not all of them (as await does)? I'm not sure but I 
>> think the same goes for futures/promises. I could have multiple agents 
>> putting the results into some shared sequence, but then how do I block on 
>> the sequence itself?
>>
>> What I'm trying to do can be described in the following way in a silly 
>> imperative pseudo-code:
>>
>> workers = new Worker[10]   ; initially w.got_data == 
>> nil 
>> for each x in source_data:
>>w = wait_for_any_worker_ready(workers)  ; initially all of them 
>> are ready
>>if (w.got_data) 
>>  output.enqueue(w.data); the consumer will read 
>> output in a blocking way
>>  w.process(x)  ; non-blocking, kicks off 
>> in the background
>>
>> Or, another way to describe it, given a seq of integers:
>>
>> [ 1, 2, 3, 4 ... ]
>>
>> and a simple function with a variable delay:
>>
>> (defn process [x]
>>(Thread/sleep (* 1 (rand)))
>>(* 2 x))
>>
>> How can I write a function which would return a blocking lazy sequence of 
>> processed integers, in arbitrary order, paralle

Re: [GSoC] core.matrix NDArray project feature requests

[Dmitry Groshev]

Thank you. I've found it yesterday, too; just in time :)

On Wednesday, May 29, 2013 7:42:58 AM UTC+4, Ben Mabey wrote:
>
> On Tue May 28 02:40:33 2013, Dmitry Groshev wrote: 
> > Sorry, I wasn't clear enough in my proposal. 
> > 
> > I've mentioned clojurecheck [1] in it and the possibility of extending 
> > it, because in my Erlang experience property-based testing is 
> > extremely helpful for things that operates on something pure in 
> > complicated way — exactly like core.matrix. But clojurecheck (AFAIK) 
> > doesn't support a (arguably) critical feature of "shrinking" — that 
> > is, reducing a failing randomly generated test case (that can be huge 
> > and very unwieldy to check by hand) to a minimal one. So, I suppose, 
> > given the fair amount of literature on the topic, shrinking can be 
> > done during this project. It's not a "plan" yet, though, just an idea. 
> > 
>
> I just ran across this new github project with shrinkage: 
> https://github.com/reiddraper/simple-check 
>

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

[Sean Corfield]

On Thu, May 30, 2013 at 1:10 AM, Alex Baranosky
 wrote:
> Do any of you ever use io! ?  I've never used it, but could see using it if
> I had a transaction-heavy application.
>
> On Wed, May 29, 2013 at 11:43 PM, Michael Klishin
>  wrote:
>> The point is to mark side-effecting code so that you can't accidentally
>> use it in a transaction.

I gather the intent is for *all* side-effecting code to be wrapped in
io! so that you can't accidentally use it with STM transactions?

The only places in Clojure and its contribs that use this are:
* await - clojure.core
* await-for - clojure.core
* transaction - java.jdbc (deprecated)
* db-transaction - java.jdbc

It sounds like all inserts and updates in java.jdbc should also be
wrapped in io! and I would expect io! to be needed in a lot of other
places in Clojure libraries across the board...?
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: Use of io!

[Gary Trakhman]

What if you really want the 'bad' effects on retries?  We need io! versions
and non-io! versions of side-effect functions :-)


On Thu, May 30, 2013 at 1:24 PM, Sean Corfield wrote:

> On Thu, May 30, 2013 at 1:10 AM, Alex Baranosky
>  wrote:
> > Do any of you ever use io! ?  I've never used it, but could see using it
> if
> > I had a transaction-heavy application.
> >
> > On Wed, May 29, 2013 at 11:43 PM, Michael Klishin
> >  wrote:
> >> The point is to mark side-effecting code so that you can't accidentally
> >> use it in a transaction.
>
> I gather the intent is for *all* side-effecting code to be wrapped in
> io! so that you can't accidentally use it with STM transactions?
>
> The only places in Clojure and its contribs that use this are:
> * await - clojure.core
> * await-for - clojure.core
> * transaction - java.jdbc (deprecated)
> * db-transaction - java.jdbc
>
> It sounds like all inserts and updates in java.jdbc should also be
> wrapped in io! and I would expect io! to be needed in a lot of other
> places in Clojure libraries across the board...?
> --
> 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.
>
>
>

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

[Josh Kamau]

Thanks guys.  I have been able to get the ref-history-count greater than 0
by increasing ref-min-history to something greater than 0 and by using long
 (using Thread/sleep) running transactions.

Now i get it
Josh


On Thu, May 30, 2013 at 6:01 PM, Neale Swinnerton wrote:

>
> On Thu, May 30, 2013 at 3:05 PM, Josh Kamau  wrote:
>>
>> I am trying to understand (ref-history-count ref) . I thought it counts
>> the number of "old" values in the ref.  But in all my tests, its always
>> returning zero. How is it used?
>>
>
> In clojure's STM, history is created only when required. This is a
> performance choice, the assumption is that 'most' STM transactions won't
> contend. In your case you have only one transaction so no history is ever
> created.
>
> Try creating a long running transaction in one thread and executing short
> running transactions in other thread(s) all altering the same ref and you
> will see history in action.
>
> HTH.
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Use of io!

[Gary Trakhman]

Well, more seriously, I would be against any facility that prevents me from
doing something potentially useful that I might want to do.  Sprinkling
potential problem spots with io! might make more sense in an application
than a library.


On Thu, May 30, 2013 at 1:27 PM, Gary Trakhman wrote:

> What if you really want the 'bad' effects on retries?  We need io!
> versions and non-io! versions of side-effect functions :-)
>
>
> On Thu, May 30, 2013 at 1:24 PM, Sean Corfield wrote:
>
>> On Thu, May 30, 2013 at 1:10 AM, Alex Baranosky
>>  wrote:
>> > Do any of you ever use io! ?  I've never used it, but could see using
>> it if
>> > I had a transaction-heavy application.
>> >
>> > On Wed, May 29, 2013 at 11:43 PM, Michael Klishin
>> >  wrote:
>> >> The point is to mark side-effecting code so that you can't accidentally
>> >> use it in a transaction.
>>
>> I gather the intent is for *all* side-effecting code to be wrapped in
>> io! so that you can't accidentally use it with STM transactions?
>>
>> The only places in Clojure and its contribs that use this are:
>> * await - clojure.core
>> * await-for - clojure.core
>> * transaction - java.jdbc (deprecated)
>> * db-transaction - java.jdbc
>>
>> It sounds like all inserts and updates in java.jdbc should also be
>> wrapped in io! and I would expect io! to be needed in a lot of other
>> places in Clojure libraries across the board...?
>> --
>> 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.
>>
>>
>>
>

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

[Shantanu Kumar]

On Thursday, 30 May 2013 19:27:34 UTC+5:30, Plinio Balduino wrote:
>
> Hi there
>
> I'm playing with Clojure CLR (good job, guys) and I miss something like 
> Leiningen. I quickly saw Kumar's lein-clr, but I don't know if it could be 
> used in a production environment (or explaining better, in a dev 
> environment for a production application) and if there is any other 
> solution.
>

You should be able to compile the ClojureCLR app sources into .EXE or .DLL 
files (lein clr compile :all) and use them in production. BTW, there's also 
nleiningen: https://github.com/aaronc/nleiningen

You may find a more focused audience for your question here: 
http://gplus.to/clojureclr

Shantanu

>

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

Re: Future/Promise and not using threads

[Paul deGrandis]

I'm not entirely sure what you're trying to accomplish in a larger context, 
but perhaps you're looking for something like this?

(delay (deref (future (and (Thread/sleep 2000) (+ 1 2)

... or maybe you want just `delay`

Cheers,
Paul


On Thursday, May 30, 2013 6:09:02 AM UTC-7, David Pollak wrote:
>
> Okay... I wrote my own:
>
>
> https://github.com/projectplugh/plugh/blob/master/src/plugh/util/misc.clj#L51
>
> One can register for on-done and on-fail. I'll work on adding fail-fast 
> and also map (so one can transform the future and execute code when the 
> transformed future has been realized/delivered/finished).
>
> Thanks for your help!
>
>
>
> On Thu, May 30, 2013 at 2:17 AM, Gary Trakhman 
> 
> > wrote:
>
>> by the second future, I mean an instance of 
>> http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Future.html , 
>> which just has to conform to the interface, and doesn't actually have to 
>> execute on a different thread.  Clojure's 'future' function returns an 
>> instance of one of these that uses the unbounded agent thread-pool, but you 
>> would be free to return one using reify or something.
>>
>>
>> https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L6320
>>  
>>
>> On Thu, May 30, 2013 at 5:14 AM, Gary Trakhman 
>> 
>> > wrote:
>>
>>> Maybe an easy solution: wrap the first future in another future that 
>>> blocking-derefs, then performs your extra computation?  Do an extra 
>>> 'realized?' check for the optimization you mention.  That would still 
>>> consume threads in the case that it's not realized, but I think it gets you 
>>> what you want.
>>>  
>>>
>>> On Thu, May 30, 2013 at 5:09 AM, Mark Engelberg 
>>> 
>>> > wrote:
>>>
 According to this article, Clojure does not yet have this facility:
 http://java.dzone.com/articles/promises-and-futures-clojure

 This is something that is being worked on and discussed, though:
 http://dev.clojure.org/display/design/Promises

 https://groups.google.com/forum/#!topic/clojure-dev/7BKQi9nWwAw/discussion
 http://dev.clojure.org/display/design/Async+blocks

 I've been hearing a lot about Tellman's lamina library as a rich 
 Clojure toolset for working with asynchronicity.  I haven't had a need for 
 it myself, but you might want to check it out and see if it has relevance 
 to what you want to do.

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

>>>
>>>
>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to 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.
>>  
>>  
>>
>
>
>
> -- 
> Telegram, Simply Beautiful CMS https://telegr.am
> Lift, the simply functional web framework http://liftweb.net
> Follow me: http://twitter.com/dpp
> Blog: http://goodstuff.im
>
>  

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

.Net Engineer --- Atlanta, GA --- Full Time --- USC or GC

[Dhruv Kumar]

*Dear Associate,*
*Please check the below requirement and advise us the right consultant’s
along with Rate, Availability, Contact Details, Current Location & Visa
Status.*
*It’s an immediate requirement please sent me the suitable resumes ASAP.
Please make sure the candidate has all the required skills.Send me the
resumes on Email: dhruv.ku...@panzersolutions.com


**Job Title: .Net Engineer
Location: Atlanta, GA
Duration: Full Time
Visa Status: USC or GC only
Interview: F2F(Expenses Paid)
*
*POSITION DESCRIPTION:
**The .Net Software Engineer is responsible for full lifecycle design and
development of our Mobile Device Management and Mobile Content Management
solutions. Our engineers work in a fast paced, Agile-based environment and
focus on cutting edge SaaS-based applications. Our engineers have the
opportunity to solve complex technical problems to address mobility
challenges in the enterprise.
*
*POSITION RESPONSIBILITIES:
**.Net Engineer who will work closely with leadership, product management
and R&D team to:
Create innovative software to advance product development through the R&D
development cycles
Translate business requirements into elegant designs to engineer through to
a finished product for release
Develop in a dynamic, team environment to design and build highly scalable
.Net applications
Drive innovation of AirWatch software while staying ahead of platform
updates for iOS, Android, Windows Phone ect.

Requirements
B.S. degree in Computer Science or equivalent experience
Experience in full lifecycle, .Net application development
Experience with Service Oriented Architectures, RESTful web services
Experience developing secure, highly scalable, distributed systems
Experience with XML, JSON and data modeling
Experience building web user interfaces using HTML, JavaScript, jQuery and
MVC patterns
Experience building commercial software, preferred
Ability to handle confidential information
Proactive, results-driven attitude

***
*

*Best Regards,

Dhruv Kumar || Technical Recruiter
Panzer Solutions LLC
Email: dhruv.ku...@panzersolutions.com
GTalk: dhruv.kumar510*
*Skype: live:dhruv.kumar*
*Voice : 203 652 1444 Ext: 104*

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

[David Nolen]

You might find this work in progress interesting then:
http://github.com/clojure/core.async


On Thu, May 30, 2013 at 3:46 PM, David Pollak  wrote:

> Paul,
>
> Thanks... but I want the opposite of delay.
>
> Basically, I do not want to consume a thread waiting for a Future to be
> satisfied. I want to continue a computation on a different thread once the
> Future/Promise is satisfied. Why?
>
> Think of a web app that's serving either a long poll or a web socket.
> Basically, you don't want to consume a thread waiting for some computation
> to take place. Rather, you want the computation to take place and then for
> the computation of sending the result to continue/resume once the
> computation has completed. Futures/Promises are excellent vehicles for
> this, especially when functions close over local scope and most of the
> local scope is persistant) and we use them extensively in Lift-land.
>
> I will move a lot of the stuff I've developed in Lift-land over to Clojure
> as many of the constructs will, I believe, play as well on Clojure as they
> do on Scala.
>
> Thanks,
>
> David
>
>
>
> On Thu, May 30, 2013 at 12:36 PM, Paul deGrandis  > wrote:
>
>> I'm not entirely sure what you're trying to accomplish in a larger
>> context, but perhaps you're looking for something like this?
>>
>> (delay (deref (future (and (Thread/sleep 2000) (+ 1 2)
>>
>> ... or maybe you want just `delay`
>>
>> Cheers,
>> Paul
>>
>>
>>
>> On Thursday, May 30, 2013 6:09:02 AM UTC-7, David Pollak wrote:
>>
>>> Okay... I wrote my own:
>>>
>>> https://github.com/**projectplugh/plugh/blob/**
>>> master/src/plugh/util/misc.**clj#L51
>>>
>>> One can register for on-done and on-fail. I'll work on adding fail-fast
>>> and also map (so one can transform the future and execute code when the
>>> transformed future has been realized/delivered/finished).
>>>
>>> Thanks for your help!
>>>
>>>
>>>
>>> On Thu, May 30, 2013 at 2:17 AM, Gary Trakhman wrote:
>>>
 by the second future, I mean an instance of http://docs.oracle.com/**
 javase/6/docs/api/java/util/**concurrent/Future.html
  ,
 which just has to conform to the interface, and doesn't actually have to
 execute on a different thread.  Clojure's 'future' function returns an
 instance of one of these that uses the unbounded agent thread-pool, but you
 would be free to return one using reify or something.

 https://github.com/clojure/**clojure/blob/master/src/clj/**
 clojure/core.clj#L6320


 On Thu, May 30, 2013 at 5:14 AM, Gary Trakhman wrote:

>  Maybe an easy solution: wrap the first future in another future that
> blocking-derefs, then performs your extra computation?  Do an extra
> 'realized?' check for the optimization you mention.  That would still
> consume threads in the case that it's not realized, but I think it gets 
> you
> what you want.
>
>
> On Thu, May 30, 2013 at 5:09 AM, Mark Engelberg 
> wrote:
>
>> According to this article, Clojure does not yet have this facility:
>> http://java.dzone.com/**articles/promises-and-futures-**clojure
>>
>> This is something that is being worked on and discussed, though:
>> http://dev.clojure.org/**display/design/Promises
>> https://groups.google.com/**forum/#!topic/clojure-dev/**
>> 7BKQi9nWwAw/discussion
>> http://dev.clojure.org/**display/design/Async+blocks
>>
>> I've been hearing a lot about Tellman's lamina library as a rich
>> Clojure toolset for working with asynchronicity.  I haven't had a need 
>> for
>> it myself, but you might want to check it out and see if it has relevance
>> to what you want to do.
>>
>>  --
>> --
>> 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 opt

Re: Future/Promise and not using threads

[Paul deGrandis]

Oh!  I see, you want promises with callbacks (which you want to be futures).
Once a promise is delivered, you want to kick off a future (in Clojure, 
futures consume a thread from the thread pool to do their work).

It's been discussed before: 
https://groups.google.com/forum/?fromgroups=#!topic/clojure-dev/7BKQi9nWwAw

You may find a more elegant solution in the upcoming async work: 
https://github.com/clojure/core.async

As previously stated you can use some mix of promise, delay, future, map, 
pmap, and reducers (much as you have already done).

If you're just looking for a completely async solution right now, I'd 
suggest lamina: https://github.com/ztellman/lamina

Paul

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

[atucker]

Hi!  I'm an interested spectator but understand very little :)  I wonder if 
anyone would take a moment to explain?
E.g. I can't see why reading from a data structure should ever lead to a 
change in the refcounts.
A


On Thursday, 30 May 2013 15:56:42 UTC+1, tbc++ wrote:
>
> 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 <
>> jean...@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 clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com 
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>  
>>>  
>>>
>>
>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to 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.

Re: Future/Promise and not using threads

[David Pollak]

Paul,

Thanks... but I want the opposite of delay.

Basically, I do not want to consume a thread waiting for a Future to be
satisfied. I want to continue a computation on a different thread once the
Future/Promise is satisfied. Why?

Think of a web app that's serving either a long poll or a web socket.
Basically, you don't want to consume a thread waiting for some computation
to take place. Rather, you want the computation to take place and then for
the computation of sending the result to continue/resume once the
computation has completed. Futures/Promises are excellent vehicles for
this, especially when functions close over local scope and most of the
local scope is persistant) and we use them extensively in Lift-land.

I will move a lot of the stuff I've developed in Lift-land over to Clojure
as many of the constructs will, I believe, play as well on Clojure as they
do on Scala.

Thanks,

David



On Thu, May 30, 2013 at 12:36 PM, Paul deGrandis
wrote:

> I'm not entirely sure what you're trying to accomplish in a larger
> context, but perhaps you're looking for something like this?
>
> (delay (deref (future (and (Thread/sleep 2000) (+ 1 2)
>
> ... or maybe you want just `delay`
>
> Cheers,
> Paul
>
>
>
> On Thursday, May 30, 2013 6:09:02 AM UTC-7, David Pollak wrote:
>
>> Okay... I wrote my own:
>>
>> https://github.com/**projectplugh/plugh/blob/**
>> master/src/plugh/util/misc.**clj#L51
>>
>> One can register for on-done and on-fail. I'll work on adding fail-fast
>> and also map (so one can transform the future and execute code when the
>> transformed future has been realized/delivered/finished).
>>
>> Thanks for your help!
>>
>>
>>
>> On Thu, May 30, 2013 at 2:17 AM, Gary Trakhman wrote:
>>
>>> by the second future, I mean an instance of http://docs.oracle.com/**
>>> javase/6/docs/api/java/util/**concurrent/Future.html
>>>  ,
>>> which just has to conform to the interface, and doesn't actually have to
>>> execute on a different thread.  Clojure's 'future' function returns an
>>> instance of one of these that uses the unbounded agent thread-pool, but you
>>> would be free to return one using reify or something.
>>>
>>> https://github.com/clojure/**clojure/blob/master/src/clj/**
>>> clojure/core.clj#L6320
>>>
>>>
>>> On Thu, May 30, 2013 at 5:14 AM, Gary Trakhman wrote:
>>>
 Maybe an easy solution: wrap the first future in another future that
 blocking-derefs, then performs your extra computation?  Do an extra
 'realized?' check for the optimization you mention.  That would still
 consume threads in the case that it's not realized, but I think it gets you
 what you want.


 On Thu, May 30, 2013 at 5:09 AM, Mark Engelberg 
 wrote:

> According to this article, Clojure does not yet have this facility:
> http://java.dzone.com/**articles/promises-and-futures-**clojure
>
> This is something that is being worked on and discussed, though:
> http://dev.clojure.org/**display/design/Promises
> https://groups.google.com/**forum/#!topic/clojure-dev/**
> 7BKQi9nWwAw/discussion
> http://dev.clojure.org/**display/design/Async+blocks
>
> I've been hearing a lot about Tellman's lamina library as a rich
> Clojure toolset for working with asynchronicity.  I haven't had a need for
> it myself, but you might want to check it out and see if it has relevance
> to what you want to do.
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
>
> Note that posts from new members are moderated - please be patient
> with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@**googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/**group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+u...@**googlegroups.com.
>
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>
>
>


>>>  --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...

Re: What is the status of Clojure on LLVM or C?

[Gary Trakhman]

Well, ref-counting in C++ is used by something like smart-pointers, the
implementation uses operator overloading to overload the pointer
dereference operator *, and it manages an internal pointer to the actual
value.  Instantiating a smart-pointer increases the count for that object,
and once that smart-pointer object goes out of scope (free/delete or
popping off the stack), it'll automatically decrement the ref count again
by action of its destructor.

The thing I'm proposing would use something like that, by my understanding,
and data structures could either be implemented in native bits or further
up once deftypes and protocols are defined on top of something like this.

So, in order to actually read from a memory value and guarantee that the
object still exists, you have to allocate a wrapper that manages these
reference counts. HTH.

On Thu, May 30, 2013 at 4:00 PM, atucker  wrote:

> Hi!  I'm an interested spectator but understand very little :)  I wonder
> if anyone would take a moment to explain?
> E.g. I can't see why reading from a data structure should ever lead to a
> change in the refcounts.
> A
>
>
> On Thursday, 30 May 2013 15:56:42 UTC+1, tbc++ wrote:
>
>> 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 <
>>> jean...@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 clo...@googlegroups.com

 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@**googlegroups.com

 For more options, visit this group at
 http://groups.google.com/**group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to clojure+u...@**googlegroups.com.

 For more options, visit 
 https://groups.google.com/**groups/opt_out
 .



>>>
>>>  --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to 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...@**goog

cyclic dependencies out of nowhere?

[Jim - FooBar();]

Hi everyone,

I've re-arranged some code in a project of mine and it seems I've 
introduced cyclic dependencies...It doesn't make sense though! I get the 
following message:


=> (load-file "src/Clondie24/games/chess.clj")
Exception Cyclic load dependency: [ /Clondie24/lib/core 
]->/Clondie24/games/chess->[ /Clondie24/lib/core ] 
clojure.core/check-cyclic-dependency (core.clj:5430)


presumably, that means that it tried to load chess.clj which depends on 
core.clj but while loading core.clj it detected a dependency back to 
chess! However, look at my ns declarations:


(ns Clondie24.lib.core ;;as you can see core.clj depends on no game but 
all games depend on core.clj

   (:require [Clondie24.lib.util :as ut]
 [clojure.core.reducers :as r]
 [enclog.training :as evo]
 [enclog.normalization :refer [prepare input output]])
   (:import  [encog_java.customGA CustomNeuralGeneticAlgorithm Referee]
  [org.encog.neural.networks BasicNetwork]))


(ns Clondie24.games.chess
(:require [Clondie24.lib.util :as ut]
  [Clondie24.lib.core :as core]
  [Clondie24.lib.search :as s]
  [Clondie24.lib.rules :as rul]
  [Clondie24.lib.gui :as gui]
  [enclog.nnets :as ai]
  [enclog.training :as evol]
  [enclog.normalization :as norm])
(:import  #_[encog_java.customGA CustomNeuralGeneticAlgorithm
   CustomGeneticScoreAdapter Referee]
  [Clondie24.lib.core Player]))

Suddenly the same happens with all my games!!! If I try to load into 
core.clj directly everything goes fine...
I should point out that there is some Java glue code which loads some 
functions from core.clj as well...In fact, that is the major change that 
I did today...I wanted the ability to genetically train all my games and 
thus the relevant functions should be in the core ns - not in chess.clj. 
So I moved them into core and now this...weird stuff!!!


also, util.clj obviously doesn't depend on chess.clj...

any ideas guys? I've had this error before but it was pretty obvious 
where the cycle was...Here, I'm very confused! core.clj and util.clj are 
the lowest level code and thus depend on nothing from the same project!


thanks in advance for your time,

Jim




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

To unsubscribe from this group and 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?

[atucker]

Wait... maybe I do :)  Perhaps I was thinking that you needn't increment 
the refcount of a node when you're just looking at it, but only if you're 
going to return it or attach it to something else...  Sorry to know so 
little...


On Thursday, 30 May 2013 21:00:59 UTC+1, atucker wrote:
>
> Hi!  I'm an interested spectator but understand very little :)  I wonder 
> if anyone would take a moment to explain?
> E.g. I can't see why reading from a data structure should ever lead to a 
> change in the refcounts.
> A
>
>
> On Thursday, 30 May 2013 15:56:42 UTC+1, tbc++ wrote:
>>
>> 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 <
>>> jean...@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 clo...@googlegroups.com
 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google 
 Groups "Clojure" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to clojure+u...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  

>>>
>>>  -- 
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to 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 m

Re: What is the status of Clojure on LLVM or C?

[Gary Trakhman]

I might have missed some details about the implementation of smart pointers
there, (whoops, I guess I failed the C++ interview), but I think it's got
the basic idea.


On Thu, May 30, 2013 at 4:27 PM, atucker  wrote:

> Wait... maybe I do :)  Perhaps I was thinking that you needn't increment
> the refcount of a node when you're just looking at it, but only if you're
> going to return it or attach it to something else...  Sorry to know so
> little...
>
>
> On Thursday, 30 May 2013 21:00:59 UTC+1, atucker wrote:
>>
>> Hi!  I'm an interested spectator but understand very little :)  I wonder
>> if anyone would take a moment to explain?
>> E.g. I can't see why reading from a data structure should ever lead to a
>> change in the refcounts.
>> A
>>
>>
>> On Thursday, 30 May 2013 15:56:42 UTC+1, tbc++ wrote:
>>>
>>> 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 <
 jean...@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 clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient
> with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/**group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+u...@googlegroups.com.
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>
>
>

  --
 --
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to 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 te

Gloss parsing question

[Alexander Duscheleit]

Hi,
I'm trying to parse a "binary" file with the help of gloss. My problem
is, the data is in a format that gloss seeminglydoesn't deal with at all.

The file start with a plaintext header, followed by some binary data,
which may be compressed in various formats. What I'm trying to
do is parse the header, and then store the binary blobs away to be 
decompressed later.

A typical header looks like this:
SPKCycrow;4.20;1;727\r\n
[...]

That's in order: FileType magic string, FileType version, enum for
compression format, length of compressed data, linebreak, :int32-be
length of decompressed data and then the data (in my case zlib).

Here's how far I got:
---
(defcodec compression (enum :byte {:none \0, :zlib \1, :7zip \2,
   :lzma \3, :best \4}))

(defcodec file-header
  (ordered-map :filetype(string :utf-8 :delimiters [";"])
   :spkversion  (string :utf-8 :delimiters [";"])
   :compression compression
   :junk:byte
   ))

(defcodec blocksize (string-integer :utf-8 :delimiters ["\n"]))

(defcodec value
  (ordered-map :size   blocksize
   :decompsize :int32-be
   :data   (finite-frame ??? (repeated :byte :prefix 
:none

(defcodec payload (repeated :byte :prefix :none))

(defcodec spkfile [file-header value payload])
---

My 2 problems:
- note the :junk in file-header, this I had to do since enum only accepts 
  primitives. (This also means enum switches on the ASCII-value of the
  number instead of the actual number.) Is there a better way to coerce
  "1;", "2;", etc. into an enum?
- the ??? in the finite-frame of value, what do I put there? how do I get
  blocksize into the size definition of the frame? Gloss seems to assume
  that any such definitions *directly* precede the following data.

Any pointers are greatly appreciated.

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

[atucker]

Thanks for this!  I do see now that it's probably a little trickier than I 
first thought :)  Still, like you, I am left with the feeling it might be 
possible to do well...

On Thursday, 30 May 2013 21:25:27 UTC+1, Gary Trakhman wrote:
>
> Well, ref-counting in C++ is used by something like smart-pointers, the 
> implementation uses operator overloading to overload the pointer 
> dereference operator *, and it manages an internal pointer to the actual 
> value.  Instantiating a smart-pointer increases the count for that object, 
> and once that smart-pointer object goes out of scope (free/delete or 
> popping off the stack), it'll automatically decrement the ref count again 
> by action of its destructor.
>
> The thing I'm proposing would use something like that, by my 
> understanding, and data structures could either be implemented in native 
> bits or further up once deftypes and protocols are defined on top of 
> something like this.
>
> So, in order to actually read from a memory value and guarantee that the 
> object still exists, you have to allocate a wrapper that manages these 
> reference counts. HTH.
>
> On Thu, May 30, 2013 at 4:00 PM, atucker 
> > wrote:
>
>> Hi!  I'm an interested spectator but understand very little :)  I wonder 
>> if anyone would take a moment to explain?
>> E.g. I can't see why reading from a data structure should ever lead to a 
>> change in the refcounts.
>> A
>>
>>
>> On Thursday, 30 May 2013 15:56:42 UTC+1, tbc++ wrote:
>>
>>> 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 <
 jean...@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 clo...@googlegroups.com
>
> Note that posts from new members are moderated - please be patient 
> with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@**googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/**group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google 
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@**googlegroups.com.
>
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>  
>  
>

  -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clo...@googlegroups.com

 Note that posts from new members are moderated - please be patient with 
 your first post.
 To

newbie question about symbols

[Brian Craft]

What's up with the 3rd result here?

user=> (symbol? +)
false
user=> (symbol? clojure.core/+)
false
user=> (symbol? (first `(,+ 5)))
true
user=> (first `(,+ 5))
clojure.core/+

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

[Chris Jeris]

Commas are whitespace in Clojure.  If you are looking for the unquote
operator, it is ~.

user=> (first `(~+ 5))
#

peace, Chris


On Thu, May 30, 2013 at 5:42 PM, Brian Craft  wrote:

> What's up with the 3rd result here?
>
> user=> (symbol? +)
> false
> user=> (symbol? clojure.core/+)
> false
> user=> (symbol? (first `(,+ 5)))
> true
> user=> (first `(,+ 5))
> clojure.core/+
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
Chris Jeris
cje...@brightcove.com
freenode/twitter/github: ystael

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

[atkaaz]

looks like you found it:
https://github.com/jimpil/Clondie24/commit/16f92fccc0c65d3c250b7a880649b940f792ea92



On Thu, May 30, 2013 at 11:25 PM, Jim - FooBar(); wrote:

> Hi everyone,
>
> I've re-arranged some code in a project of mine and it seems I've
> introduced cyclic dependencies...It doesn't make sense though! I get the
> following message:
>
> => (load-file "src/Clondie24/games/chess.**clj")
> Exception Cyclic load dependency: [ /Clondie24/lib/core
> ]->/Clondie24/games/chess->[ /Clondie24/lib/core ]
> clojure.core/check-cyclic-**dependency (core.clj:5430)
>
> presumably, that means that it tried to load chess.clj which depends on
> core.clj but while loading core.clj it detected a dependency back to chess!
> However, look at my ns declarations:
>
> (ns Clondie24.lib.core ;;as you can see core.clj depends on no game but
> all games depend on core.clj
>(:require [Clondie24.lib.util :as ut]
>  [clojure.core.reducers :as r]
>  [enclog.training :as evo]
>  [enclog.normalization :refer [prepare input output]])
>(:import  [encog_java.customGA CustomNeuralGeneticAlgorithm Referee]
>   [org.encog.neural.networks BasicNetwork]))
>
>
> (ns Clondie24.games.chess
> (:require [Clondie24.lib.util :as ut]
>   [Clondie24.lib.core :as core]
>   [Clondie24.lib.search :as s]
>   [Clondie24.lib.rules :as rul]
>   [Clondie24.lib.gui :as gui]
>   [enclog.nnets :as ai]
>   [enclog.training :as evol]
>   [enclog.normalization :as norm])
> (:import  #_[encog_java.customGA CustomNeuralGeneticAlgorithm
>CustomGeneticScoreAdapter Referee]
>   [Clondie24.lib.core Player]))
>
> Suddenly the same happens with all my games!!! If I try to load into
> core.clj directly everything goes fine...
> I should point out that there is some Java glue code which loads some
> functions from core.clj as well...In fact, that is the major change that I
> did today...I wanted the ability to genetically train all my games and thus
> the relevant functions should be in the core ns - not in chess.clj. So I
> moved them into core and now this...weird stuff!!!
>
> also, util.clj obviously doesn't depend on chess.clj...
>
> any ideas guys? I've had this error before but it was pretty obvious where
> the cycle was...Here, I'm very confused! core.clj and util.clj are the
> lowest level code and thus depend on nothing from the same project!
>
> thanks in advance for your time,
>
> Jim
>
>
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscribe@**googlegroups.com
> For more options, visit this group at
> http://groups.google.com/**group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 
> clojure+unsubscribe@**googlegroups.com
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>
>
>

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

Re: newbie question about symbols

[Brian Craft]

ah, thanks.

On Thursday, May 30, 2013 2:48:00 PM UTC-7, cjeris wrote:
>
> Commas are whitespace in Clojure.  If you are looking for the unquote 
> operator, it is ~.
>
> user=> (first `(~+ 5))
> #
>
> peace, Chris
>
>
> On Thu, May 30, 2013 at 5:42 PM, Brian Craft 
> > wrote:
>
>> What's up with the 3rd result here?
>>
>> user=> (symbol? +)
>> false
>> user=> (symbol? clojure.core/+)
>> false
>> user=> (symbol? (first `(,+ 5)))
>> true
>> user=> (first `(,+ 5))
>> clojure.core/+
>>
>>  -- 
>> -- 
>> 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.
>>  
>>  
>>
>
>
>
> -- 
> Chris Jeris
> cje...@brightcove.com 
> freenode/twitter/github: ystael
>  

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

[Plínio Balduino]

Thank you, mr. Kumar.

Plinio

On Thu, May 30, 2013 at 4:23 PM, Shantanu Kumar
 wrote:
>
>
>
> On Thursday, 30 May 2013 19:27:34 UTC+5:30, Plinio Balduino wrote:
>>
>> Hi there
>>
>> I'm playing with Clojure CLR (good job, guys) and I miss something like 
>> Leiningen. I quickly saw Kumar's lein-clr, but I don't know if it could be 
>> used in a production environment (or explaining better, in a dev environment 
>> for a production application) and if there is any other solution.
>
>
> You should be able to compile the ClojureCLR app sources into .EXE or .DLL 
> files (lein clr compile :all) and use them in production. BTW, there's also 
> nleiningen: https://github.com/aaronc/nleiningen
>
> You may find a more focused audience for your question here: 
> http://gplus.to/clojureclr
>
> Shantanu
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

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

Re: cyclic dependencies out of nowhere?

[Jim - FooBar();]

hehe :)

yep, I found it...some stupid class files had been left along with the 
java source files and they were interfering with the proper class files 
(under target/classes) since they were both under the classpath!!! I 
felt very stupid for having done this and that's why I didn't post back 
with the "solution"...but of course nothing is secret, as you 
demonstrated :)


btw, the commit you're showing is not exactly what fixed it...that was 
before my post I think...


Jim

On 30/05/13 22:58, atkaaz wrote:
looks like you found it: 
https://github.com/jimpil/Clondie24/commit/16f92fccc0c65d3c250b7a880649b940f792ea92




On Thu, May 30, 2013 at 11:25 PM, Jim - FooBar(); 
mailto:jimpil1...@gmail.com>> wrote:


Hi everyone,

I've re-arranged some code in a project of mine and it seems I've
introduced cyclic dependencies...It doesn't make sense though! I
get the following message:

=> (load-file "src/Clondie24/games/chess.clj")
Exception Cyclic load dependency: [ /Clondie24/lib/core
]->/Clondie24/games/chess->[ /Clondie24/lib/core ]
clojure.core/check-cyclic-dependency (core.clj:5430)

presumably, that means that it tried to load chess.clj which
depends on core.clj but while loading core.clj it detected a
dependency back to chess! However, look at my ns declarations:

(ns Clondie24.lib.core ;;as you can see core.clj depends on no
game but all games depend on core.clj
   (:require [Clondie24.lib.util :as ut]
 [clojure.core.reducers :as r]
 [enclog.training :as evo]
 [enclog.normalization :refer [prepare input output]])
   (:import  [encog_java.customGA CustomNeuralGeneticAlgorithm
Referee]
  [org.encog.neural.networks BasicNetwork]))


(ns Clondie24.games.chess
(:require [Clondie24.lib.util :as ut]
  [Clondie24.lib.core :as core]
  [Clondie24.lib.search :as s]
  [Clondie24.lib.rules :as rul]
  [Clondie24.lib.gui :as gui]
  [enclog.nnets :as ai]
  [enclog.training :as evol]
  [enclog.normalization :as norm])
(:import  #_[encog_java.customGA CustomNeuralGeneticAlgorithm
   CustomGeneticScoreAdapter Referee]
  [Clondie24.lib.core Player]))

Suddenly the same happens with all my games!!! If I try to load
into core.clj directly everything goes fine...
I should point out that there is some Java glue code which loads
some functions from core.clj as well...In fact, that is the major
change that I did today...I wanted the ability to genetically
train all my games and thus the relevant functions should be in
the core ns - not in chess.clj. So I moved them into core and now
this...weird stuff!!!

also, util.clj obviously doesn't depend on chess.clj...

any ideas guys? I've had this error before but it was pretty
obvious where the cycle was...Here, I'm very confused! core.clj
and util.clj are the lowest level code and thus depend on nothing
from the same project!

thanks in advance for your time,

Jim




-- 
-- 
You received this message because you are subscribed to the Google

Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com

Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com

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

Re: cyclic dependencies out of nowhere?

[atkaaz]

 I posted to make sure others reading it  know not to start looking for a
solution, since it was found - so saving their time. Also, I was sure you
were going to post it as soon as you had the time (for the same reason, at
least). I didn't mean to call you out or anything; I see making
mistakes&failing a requirement to programming: if you don't constantly fail
then you're doing it wrong ;)   (I'm still struggling to accept this though
xD)
 I only superficially looked at that commit and it seemed to me to be the
fix, now that I look again it makes some sense: in core clj you imported
Referee java class whose static init. block did a require of chess clj, but
the commit changed this require to be core. I guess this class remained
there in its old format and then interfered, as you said.

Peace out,


On Fri, May 31, 2013 at 1:43 AM, Jim - FooBar(); wrote:

>  hehe :)
>
> yep, I found it...some stupid class files had been left along with the
> java source files and they were interfering with the proper class files
> (under target/classes) since they were both under the classpath!!! I felt
> very stupid for having done this and that's why I didn't post back with the
> "solution"...but of course  nothing is secret, as you demonstrated :)
>
> btw, the commit you're showing is not exactly what fixed it...that was
> before my post I think...
>
> Jim
>
>
> On 30/05/13 22:58, atkaaz wrote:
>
> looks like you found it:
> https://github.com/jimpil/Clondie24/commit/16f92fccc0c65d3c250b7a880649b940f792ea92
>
>
>
> On Thu, May 30, 2013 at 11:25 PM, Jim - FooBar(); wrote:
>
>> Hi everyone,
>>
>> I've re-arranged some code in a project of mine and it seems I've
>> introduced cyclic dependencies...It doesn't make sense though! I get the
>> following message:
>>
>> => (load-file "src/Clondie24/games/chess.clj")
>> Exception Cyclic load dependency: [ /Clondie24/lib/core
>> ]->/Clondie24/games/chess->[ /Clondie24/lib/core ]
>> clojure.core/check-cyclic-dependency (core.clj:5430)
>>
>> presumably, that means that it tried to load chess.clj which depends on
>> core.clj but while loading core.clj it detected a dependency back to chess!
>> However, look at my ns declarations:
>>
>> (ns Clondie24.lib.core ;;as you can see core.clj depends on no game but
>> all games depend on core.clj
>>(:require [Clondie24.lib.util :as ut]
>>  [clojure.core.reducers :as r]
>>  [enclog.training :as evo]
>>  [enclog.normalization :refer [prepare input output]])
>>(:import  [encog_java.customGA CustomNeuralGeneticAlgorithm Referee]
>>   [org.encog.neural.networks BasicNetwork]))
>>
>>
>> (ns Clondie24.games.chess
>> (:require [Clondie24.lib.util :as ut]
>>   [Clondie24.lib.core :as core]
>>   [Clondie24.lib.search :as s]
>>   [Clondie24.lib.rules :as rul]
>>   [Clondie24.lib.gui :as gui]
>>   [enclog.nnets :as ai]
>>   [enclog.training :as evol]
>>   [enclog.normalization :as norm])
>> (:import  #_[encog_java.customGA CustomNeuralGeneticAlgorithm
>>CustomGeneticScoreAdapter Referee]
>>   [Clondie24.lib.core Player]))
>>
>> Suddenly the same happens with all my games!!! If I try to load into
>> core.clj directly everything goes fine...
>> I should point out that there is some Java glue code which loads some
>> functions from core.clj as well...In fact, that is the major change that I
>> did today...I wanted the ability to genetically train all my games and thus
>> the relevant functions should be in the core ns - not in chess.clj. So I
>> moved them into core and now this...weird stuff!!!
>>
>> also, util.clj obviously doesn't depend on chess.clj...
>>
>> any ideas guys? I've had this error before but it was pretty obvious
>> where the cycle was...Here, I'm very confused! core.clj and util.clj are
>> the lowest level code and thus depend on nothing from the same project!
>>
>> thanks in advance for your time,
>>
>> Jim
>>
>>
>>
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To unsubscribe from this group and 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 f

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[David Jacobs]

I'm just catching up on this discussion. I think that, regardless of 
whether any one coder uses them, debuggers are useful to a large subset of 
people. Even though Clojure likes us to be immutable, there are often times 
where we would like to debug the mutable parts of our code with something 
better than a print statement. (Importantly, it's more efficient to 
identify a problem spot in code if you can dynamically change what you're 
interested in as you get feedback from a REPL -- this is something print 
statements can't do. Print statements often have to be brute-force if you 
aren't exactly sure what to print.)

If we want Clojure to continue to be adopted, we need to support the habits 
of Web developers. And Web developers expect to:

1. Spot a problem spot in the code
2. Add the word "debugger/debug" at that spot (or make a breakpoint in an 
IDE)
3. Make the API call/run the spec/refresh the page/click the button
4. Immediately be in a debugger REPL where they can explore the environment

While it doesn't solve all problems, and while the more advanced we are, 
(perhaps) the sooner we can spot errors without a debugger, the fact is 
that a debugger is part of the standard workflow for many people. The 
essential thing is that a debugger quickly loads an execution context into 
your working memory. Instead of having to think about it for a while, you 
get immediate feedback about what's going wrong (nesting level is too high, 
that function doesn't return what you think it does, etc) and can jump into 
a new codebase easily.

So both for adoption and for a quick identify-debug-fix cycle (not all of 
us can afford hammock time for each and every bug that crops up in the 
code), I think it's important that we start thinking about creating and 
documenting debugging tools for the community.

Tangent: I don't see any documentation for inserting a debug REPL using 
Ritz. Anyone have any pointers? Does Ritz actually give me what I described 
earlier?

Best,
David

On Wednesday, May 29, 2013 8:56:08 AM UTC-7, Ben Mabey wrote:
>
> On Wed May 29 09:18:10 2013, Softaddicts wrote: 
> > The REPL is a better alternative than a debugger. No REPL available = 
> increase need for 
> > a debugger. 
> > 
> > If you write creepy code in the REPL, you would do the same in a text 
> editor and then 
> > end up debugging it in the debugger... with the old 
> fail/edit/build/break to point of 
> > failure cycle. 
> > 
> > It's not the same goals and efficiency. Maybe the following will shed 
> some light. 
> > 
> > My REPL's main usage is to tinker with my code in a name space until 
> it's resilient and 
> > composable as much as possible. I rarely use the REPL to test short 
> snippets. 
> > My code is always backed by the name space I am working with. 
> > 
> > I seldom write unit tests. I make use of pre and post conditions as much 
> as possible 
> > to knock the rough edges off. 
> > 
> > I run integrated tests starting from a root name space (whichever is 
> appropriate for the 
> > scope oftest to be done) where I may have to establish some base 
> context. 
> > I exercise the code, I can trace/untrace calls, redef fns when needed 
> and so on without 
> > restarts. 
> > 
> > This insures a minimally resilient code base. 
> > 
> > When a severe error occurs, our logging facility dumps also the 
> environment 
> > with all the current bindings in scope where the exception was trapped. 
> > We can log bindings up to the top of the call stack... 
> > 
> > This is usable (as clojure maps) to reconstruct the call context and 
> rerun the 
> > culprit chunk of code to pinpoint were are the shortcomings that made it 
> fail. 
> > When running full integrated tests, we have access to this data. 
> > 
> > This is also available from production, we then obtain data to reinject 
> in dev to 
> > understand what happened with a limited wiring to establish the global 
> context. 
> > We can then reflect this our integrated tests to stress the code. 
> > 
> > This is more or less easy depending on the code that failed based on 
> > how much side effects are impacting the context. 
> > 
> > The more you use pure fns, the easier it is to rerun failures from the 
> appropriate 
> > call site and fix them. 
> > The more composable your code is, the less bugs you end up with, fns are 
> smaller, 
> > their scope is smaller, ... 
> > 
> > When I trigger a debugger it's because I hit a strange error from the 
> > Clojure compiler that I do not understand upfront or when I deal with 
> interop code 
> > and I need to look at the exception and internal states of Java objects 
> in situ. 
> > I never need to look at Clojure bindings in the debugger aside from the 
> obscure 
> > compilation errors I may hit. 
> > 
> > I became much more efficient swapping my time spent in a debugger by 
> time 
> > spent in the REPL. This is the bottom line and I am convinced from 
> comments 
> > I got from colleagues well versed in the use of debugg

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[Raoul Duke]

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.

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

[David Jacobs]

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.

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

[David Jacobs]

That's true -- that's why I wrote up the Letters debugging mini-library for 
Ruby (lettersrb.com). However, there's friction there, too, and a surprising 
number of people don't think to do this.  


On Thursday, May 30, 2013 at 5:25 PM, Timothy Baldridge wrote:

> 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  (mailto:da...@wit.io)> 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 
> > (mailto:clojure@googlegroups.com)
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com 
> > (mailto:clojure%2bunsubscr...@googlegroups.com)
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---  
> > You received this message because you are subscribed to the Google Groups 
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to clojure+unsubscr...@googlegroups.com 
> > (mailto:clojure%2bunsubscr...@googlegroups.com).
> > For more options, visit https://groups.google.com/groups/opt_out.
> >  
> >  
>  
>  
>  
>  
> --  
> “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 
> (mailto:clojure@googlegroups.com)
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com 
> (mailto:clojure+unsubscr...@googlegroups.com)
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---  
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com 
> (mailto:clojure+unsubscr...@googlegroups.com).
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  



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

Re: What is the status of Clojure on LLVM or C?

[Dax Fohl]

So what I'm gathering (I'm still trying to grok) is that clojure-metal is 
an approach that somewhat parallels PyPy, except in Clojure, and except 
that instead of defining a type-inferrable subset RClojure, you instead 
define an internal DSL via mjolnir that allows you to specify the types 
within Clojure?  But unlike RPython which can run as a CPython program 
without any special handling, the mjolnir DSL is only intended to be run as 
a bytecode generator.  Is that about right?  I'm wondering, if the 
intention is to parallel PyPy, but use Clojure instead, would a more 
generic thing to do be to start with PyPy toolchain, but abstract it so 
that the input is not RPython, but rather any type-inferrable language and 
a corresponding AST generator, and make it so that PyPy is no longer 
Python-specific at all?  (Well except the toolchain code would still be 
python, but that's just an implementation detail).  So from that toolchain 
it'd be possible to define RuRu, CloClo, maybe dynamic MLML or CC, or of 
course cross-version CloML or RuC?  Or is the PyPy toolchain still too 
specific to "Python-like" languages that it'd produce something suboptimal 
for Clojure and other languages?

On Thursday, May 30, 2013 8:15:29 PM UTC+8, tbc++ wrote:
>
> 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. 
>

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

[Dax Fohl]

(or the slightly hackier but probably easier version: create a tool that 
translates a subset of Clojure to RPython)

On Friday, May 31, 2013 10:26:56 AM UTC+8, Dax Fohl wrote:
>
> So what I'm gathering (I'm still trying to grok) is that clojure-metal is 
> an approach that somewhat parallels PyPy, except in Clojure, and except 
> that instead of defining a type-inferrable subset RClojure, you instead 
> define an internal DSL via mjolnir that allows you to specify the types 
> within Clojure?  But unlike RPython which can run as a CPython program 
> without any special handling, the mjolnir DSL is only intended to be run as 
> a bytecode generator.  Is that about right?  I'm wondering, if the 
> intention is to parallel PyPy, but use Clojure instead, would a more 
> generic thing to do be to start with PyPy toolchain, but abstract it so 
> that the input is not RPython, but rather any type-inferrable language and 
> a corresponding AST generator, and make it so that PyPy is no longer 
> Python-specific at all?  (Well except the toolchain code would still be 
> python, but that's just an implementation detail).  So from that toolchain 
> it'd be possible to define RuRu, CloClo, maybe dynamic MLML or CC, or of 
> course cross-version CloML or RuC?  Or is the PyPy toolchain still too 
> specific to "Python-like" languages that it'd produce something suboptimal 
> for Clojure and other languages?
>>
>>

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

[Adam Getchell]

On Tuesday, March 19, 2013 4:22:59 PM UTC-7, John SJ Anderson wrote:
>
>
> I had this same issue when working through the tutorial. The text 
> makes it sound like you should replace the entire contents of the test 
> file, but that's not the case -- you just need to replace the (deftest 
> ...) form. (I ended up having to generate the project tree under a 
> slightly different name to get a good copy of the file back.) 
>

I have a similar issue, except that I did leave my file intact:

(ns command-line-args.core-test
  (:require [clojure.test :refer :all]
[command-line-args.core :refer :all]))

(deftest pairs-of-values
  (let [args ["--server" "localhost"
  "--port" "8080"
  "--environment" "production"]]
(is (= {:server "localhost"
:port "8080"
:environment "production"}
   (parse-args args)

(defn parse-args [args]
  {})

Results in:

clojure.lang.Compiler$CompilerException: java.lang.RuntimeException: Unable 
to resolve symbol: parse-args in this context, 
compiling:(/Users/getchell/Projects/clojure/command-line-args/test/command_line_args/core_test.clj:12:12)
 at clojure.lang.Compiler.analyze (Compiler.java:6380)
clojure.lang.Compiler.analyze (Compiler.java:6322)
clojure.lang.Compiler$InvokeExpr.parse (Compiler.java:3573)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6562)
clojure.lang.Compiler.analyze (Compiler.java:6361)
clojure.lang.Compiler.analyze (Compiler.java:6322)
clojure.lang.Compiler$InvokeExpr.parse (Compiler.java:3624)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6562)
clojure.lang.Compiler.analyze (Compiler.java:6361)
clojure.lang.Compiler.access$100 (Compiler.java:37)
clojure.lang.Compiler$LetExpr$Parser.parse (Compiler.java:5973)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6560)
clojure.lang.Compiler.analyze (Compiler.java:6361)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6548)
clojure.lang.Compiler.analyze (Compiler.java:6361)
clojure.lang.Compiler.analyze (Compiler.java:6322)
clojure.lang.Compiler$BodyExpr$Parser.parse (Compiler.java:5708)
clojure.lang.Compiler$TryExpr$Parser.parse (Compiler.java:2156)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6560)
clojure.lang.Compiler.analyze (Compiler.java:6361)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6548)
clojure.lang.Compiler.analyze (Compiler.java:6361)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6548)
clojure.lang.Compiler.analyze (Compiler.java:6361)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6548)
clojure.lang.Compiler.analyze (Compiler.java:6361)
clojure.lang.Compiler.analyze (Compiler.java:6322)
clojure.lang.Compiler$BodyExpr$Parser.parse (Compiler.java:5708)
clojure.lang.Compiler$LetExpr$Parser.parse (Compiler.java:6009)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6560)
clojure.lang.Compiler.analyze (Compiler.java:6361)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6548)
clojure.lang.Compiler.analyze (Compiler.java:6361)
clojure.lang.Compiler.analyze (Compiler.java:6322)
clojure.lang.Compiler$BodyExpr$Parser.parse (Compiler.java:5708)
clojure.lang.Compiler$FnMethod.parse (Compiler.java:5139)
clojure.lang.Compiler$FnExpr.parse (Compiler.java:3751)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6558)
clojure.lang.Compiler.analyze (Compiler.java:6361)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6548)
clojure.lang.Compiler.analyze (Compiler.java:6361)
clojure.lang.Compiler.analyze (Compiler.java:6322)
clojure.lang.Compiler$MapExpr.parse (Compiler.java:2879)
clojure.lang.Compiler.analyze (Compiler.java:6369)
clojure.lang.Compiler.analyze (Compiler.java:6322)
clojure.lang.Compiler$DefExpr$Parser.parse (Compiler.java:528)
clojure.lang.Compiler.analyzeSeq (Compiler.java:6560)
clojure.lang.Compiler.analyze (Compiler.java:6361)
clojure.lang.Compiler.analyze (Compiler.java:6322)
clojure.lang.Compiler.eval (Compiler.java:6623)
clojure.lang.Compiler.load (Compiler.java:7064)
command_line_args.core_test$eval1168.invoke (NO_SOURCE_FILE:1)
clojure.lang.Compiler.eval (Compiler.java:6619)
clojure.lang.Compiler.eval (Compiler.java:6582)
clojure.core$eval.invoke (core.clj:2852)
clojure.main$repl$read_eval_print__6588$fn__6591.invoke (main.clj:259)
clojure.main$repl$read_eval_print__6588.invoke (main.clj:259)
clojure.main$repl$fn__6597.invoke (main.clj:277)
clojure.main$repl.doInvoke (main.clj:277)
clojure.lang.RestFn.invoke (RestFn.java:1096)

clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__588.invoke 
(interruptible_eval.clj:56)
clojure.lang.AFn.applyToHelper (AFn.java:159)
clojure.lang.AFn.applyTo (AFn.java:151)
clojure.core$apply.invoke (core.clj:617)
clojure.core$with_bindings_STAR_.doInvoke (core.clj:1788)
clojure.lang.RestFn.invoke (RestFn.java:425)
clo