Re: Prismatic Plumbing and Graph Open-Source Release

[Brent Millare]

Hi,

Very nice work. I'm interested in using graph but just curious in terms of 
your priorities for future development.

I noticed that you listed as a todo, you might want to save the body of a 
fnk which I see as a potential for inlining the bodies and thus eliminating 
the fn call when creating the final composite fnk. Is this correct?

Also how would you advice situations when you have mutual recursion (with 
conditions to bound execution) but still want the compositional power of 
graph? (like being able to substitute only certain components of the graphs 
in different situations). I understand that my usage of recursion implies 
there will be cycles and graph only emits code in topological order so its 
currently not supported. Is there future support for this or is this 
outside the scope of graph? Any tips for reclaiming compositional power?

-Brent

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

[Brent Millare]

>From what I understand, the reader will call the tag function, thus being 
executed at read time and not compile time.

On Thursday, March 7, 2013 4:04:15 AM UTC-5, Akhil Wali wrote:
>
> IMHO features expressions should be evaluated at read-time only.
> Putting it off till the compilation phase only complicates things.
> So I'm actually favoring a preprocessing step like here -  
> http://dev.clojure.org/display/design/Feature+Expressions?focusedCommentId=6390066#comment-6390066
>
> The idea is simple; when the reader parses a sexpr, and if there's a 
> feature expression,then  only use the part that's relevant to the current 
> Clojure dialect.
> The only complication with this scheme is that all information in 
> *clojure-version* is related to the version numbers only; however, this 
> could be changed easily.
>
>
>
> On Thu, Mar 7, 2013 at 7:46 AM, Brent Millare 
> 
> > wrote:
>
>> +1
>>
>> Isn't is possible to accomplish all these efforts using tagged literals? 
>> https://github.com/miner/wilkins
>>
>> This way the facilities for read-time code generation can be customized 
>> and any reader that supports tagged-literals will support this. All of this 
>> is data provided as arguments, no evaluation. Evaluation happens from the 
>> tag function.
>>
>> On Wednesday, March 6, 2013 8:24:15 PM UTC-5, Brian Goslinga wrote:
>>>
>>> Do we really need new syntax for feature expressions? Although it would 
>>> be more ugly than CL's feature expressions, we could use a reader literal. 
>>> For example #feature [ ]. Using a reader literal 
>>> is simple, compatible with EDN, and allows for the feature expressions to 
>>> be backported to an older version of Clojure using a library.
>>
>>  -- 
>> -- 
>> 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.
>>  
>>  
>>
>
>
>
> -- 
> Akhil Wali 
>
> # http://github.com/darth10 
> # http://darth10.github.com
>
>  

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

Re: what is a good book about Java queues?

[Shantanu Kumar]

On Mar 8, 1:32 am, larry google groups 
wrote:
> At some point on this mailist, someone suggested that to best understand
> concurrency in Java, once should read:
>
> Java Concurrency In Practice
>
> http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/032134...
>
> So I read it, but I am surprised that it says fairly little about working
> with queues. I am curious if anyone would recommend a book for learning
> more about working with Java queues?
>
> I suffer the problem that I learned Clojure without first learning Java,
> and Clojure leans on Java rather heavily, so I am now trying to come up to
> speed on Java.

I've found their Javadoc content to be quite informative. Looking at
the source code should be useful too. The ConcurrentLinkedQueue doc
mentions http://www.cs.rochester.edu/u/michael/PODC96.html as the
reference.

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: Clojure Performance For Expensive Algorithms

[arun . kumar]

I did a board on clojure performance, if you'd like check it out. Hopefully 
it 
helps. http://www.verious.com/board/AKumar/improving-performance-with-clojure/

On Monday, February 18, 2013 8:16:51 PM UTC-8, Geo wrote:
>
> Hello,
>
> I am cross-posting my Clojure question from StackOverflow.  I am trying to 
> get an algorithm in Clojure to match Java speed and managed to get the 
> performance to within one order of magnitude and wondering if more is 
> possible. The full question is here:
>
>
> http://stackoverflow.com/questions/14949705/clojure-performance-for-expensive-algorithms
>
> Thank you.
>

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

[Jonathan Fischer Friberg]

The macro doesn't have that problem - as long as the code is inside the
macro.

I.e. this works (in clojure):
(case-dialect :clojurescript some.class/PROP)

But this doesn't:
(defn get-PROP [] some.class/PROP)

(case-dialect :clojurescript (get-PROP))

If I'm not mistaken, the proposed expressions has the same problem.

Jonathan


On Thu, Mar 7, 2013 at 4:10 PM, Andy Fingerhut wrote:

> I may be wrong, but I think this, and anything else that tries to solve
> this problem after read time, will fail for one of the primary uses of
> feature macros: Java packages/namespaces that exist for Clojure/JVM but not
> ClojureScript, and JavaScript namespaces that exist for ClojureScript but
> not Clojure/JVM.  Each of those would cause a compilation error for the
> other, I believe.
>
> e.g. java.lang.Long and java.util.Date don't exist in ClojureScript, and
> are the kinds of things you would want to conditionally compile on for
> Clojure/JVM.
>
> Andy
>
>
> On Thu, Mar 7, 2013 at 5:44 AM, Jonathan Fischer Friberg <
> odysso...@gmail.com> wrote:
>
>> Isn't it possible to solve this with a simple macro?
>>
>> (case-dialect
>>:clojure (... clojure code ...)
>>:clojurescript (... clojurescript code ...))
>>
>> Then, in jvm clojure, it could be implemented as:
>> (defmacro case-dialect [& {:keys [clojure]}] clojure)
>>
>> and in clojurescript:
>> (defmacro case-dialect [& {:keys [clojurescript]}] clojurescript)
>>
>> Alternatively, we could have a def, say *clojure-dialect*, then:
>> (defmacro case-dialect [& {:as m}] (get m *clojure-dialect*))
>>
>> (although the dialect should probably be part of *clojure-version* ...
>> you get the idea)
>>
>> Jonathan
>>
>>
>> On Thu, Mar 7, 2013 at 10:04 AM, Akhil Wali wrote:
>>
>>> IMHO features expressions should be evaluated at read-time only.
>>> Putting it off till the compilation phase only complicates things.
>>> So I'm actually favoring a preprocessing step like here -
>>> http://dev.clojure.org/display/design/Feature+Expressions?focusedCommentId=6390066#comment-6390066
>>>
>>> The idea is simple; when the reader parses a sexpr, and if there's a
>>> feature expression,then  only use the part that's relevant to the current
>>> Clojure dialect.
>>> The only complication with this scheme is that all information in
>>> *clojure-version* is related to the version numbers only; however, this
>>> could be changed easily.
>>>
>>>
>>>
>>> On Thu, Mar 7, 2013 at 7:46 AM, Brent Millare 
>>> wrote:
>>>
 +1

 Isn't is possible to accomplish all these efforts using tagged
 literals? https://github.com/miner/wilkins

 This way the facilities for read-time code generation can be customized
 and any reader that supports tagged-literals will support this. All of this
 is data provided as arguments, no evaluation. Evaluation happens from the
 tag function.

 On Wednesday, March 6, 2013 8:24:15 PM UTC-5, Brian Goslinga wrote:
>
> Do we really need new syntax for feature expressions? Although it
> would be more ugly than CL's feature expressions, we could use a reader
> literal. For example #feature [ ]. Using a
> reader literal is simple, compatible with EDN, and allows for the feature
> expressions to be backported to an older version of Clojure using a 
> 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.



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

what is a good book about Java queues?

[larry google groups]

At some point on this mailist, someone suggested that to best understand 
concurrency in Java, once should read: 

Java Concurrency In Practice

http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601/ref=sr_1_1?ie=UTF8&qid=1362688125&sr=8-1&keywords=java+concurrency+in+practice

So I read it, but I am surprised that it says fairly little about working 
with queues. I am curious if anyone would recommend a book for learning 
more about working with Java queues? 

I suffer the problem that I learned Clojure without first learning Java, 
and Clojure leans on Java rather heavily, so I am now trying to come up to 
speed on Java. 







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

[Kevin Downey]

Class names are read in as symbols
On Mar 7, 2013 7:10 AM, "Andy Fingerhut"  wrote:

> I may be wrong, but I think this, and anything else that tries to solve
> this problem after read time, will fail for one of the primary uses of
> feature macros: Java packages/namespaces that exist for Clojure/JVM but not
> ClojureScript, and JavaScript namespaces that exist for ClojureScript but
> not Clojure/JVM.  Each of those would cause a compilation error for the
> other, I believe.
>
> e.g. java.lang.Long and java.util.Date don't exist in ClojureScript, and
> are the kinds of things you would want to conditionally compile on for
> Clojure/JVM.
>
> Andy
>
> On Thu, Mar 7, 2013 at 5:44 AM, Jonathan Fischer Friberg <
> odysso...@gmail.com> wrote:
>
>> Isn't it possible to solve this with a simple macro?
>>
>> (case-dialect
>>:clojure (... clojure code ...)
>>:clojurescript (... clojurescript code ...))
>>
>> Then, in jvm clojure, it could be implemented as:
>> (defmacro case-dialect [& {:keys [clojure]}] clojure)
>>
>> and in clojurescript:
>> (defmacro case-dialect [& {:keys [clojurescript]}] clojurescript)
>>
>> Alternatively, we could have a def, say *clojure-dialect*, then:
>> (defmacro case-dialect [& {:as m}] (get m *clojure-dialect*))
>>
>> (although the dialect should probably be part of *clojure-version* ...
>> you get the idea)
>>
>> Jonathan
>>
>>
>> On Thu, Mar 7, 2013 at 10:04 AM, Akhil Wali wrote:
>>
>>> IMHO features expressions should be evaluated at read-time only.
>>> Putting it off till the compilation phase only complicates things.
>>> So I'm actually favoring a preprocessing step like here -
>>> http://dev.clojure.org/display/design/Feature+Expressions?focusedCommentId=6390066#comment-6390066
>>>
>>> The idea is simple; when the reader parses a sexpr, and if there's a
>>> feature expression,then  only use the part that's relevant to the current
>>> Clojure dialect.
>>> The only complication with this scheme is that all information in
>>> *clojure-version* is related to the version numbers only; however, this
>>> could be changed easily.
>>>
>>>
>>>
>>> On Thu, Mar 7, 2013 at 7:46 AM, Brent Millare 
>>> wrote:
>>>
 +1

 Isn't is possible to accomplish all these efforts using tagged
 literals? https://github.com/miner/wilkins

 This way the facilities for read-time code generation can be customized
 and any reader that supports tagged-literals will support this. All of this
 is data provided as arguments, no evaluation. Evaluation happens from the
 tag function.

 On Wednesday, March 6, 2013 8:24:15 PM UTC-5, Brian Goslinga wrote:
>
> Do we really need new syntax for feature expressions? Although it
> would be more ugly than CL's feature expressions, we could use a reader
> literal. For example #feature [ ]. Using a
> reader literal is simple, compatible with EDN, and allows for the feature
> expressions to be backported to an older version of Clojure using a 
> 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.



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

Re: features expression

[Gary Verhaegen]

I have not read all of the discussions about this topic, so I
apologize if it has already been discussed, but I was wondering why
there does not seem to be any discussion about the openness of such a
system. As far as I know, CL-style feature expressions are closed in
the same sense that a cond form is closed by comparison with a
protocol : you cannot add in a new form without touching the original
source code.

I would like the final system to offer the possibility for a library
author to document the host-specific functionality that has to be
present, and to allow for that functionality to be provided
externally, just as I can extend a protocol to make my new record work
with existing code.

I guess that would kind of boil down to what vemv was saying :
conceptually, this would be the same as isolating all of your
platform-specific code inside a protocol and passing an instance of
that protocol to all of your functions, though I am pretty sure there
is a better way to implement this, as it should definitely be a
compile-time replacement instead of a runtime invocation.

Why not take some inspiration from internationalization à la NIB file?
This is kind of the same issue. Say I could write my clojure code for
the JVM normally:

(defn blank? [s] (every? #(Character/isWhitespace %) s))

but with an extra annotation, either through a data literal or a
reader extension. Say:

(defn blank? [s] (every? #platform #(Character/isWhitespace %) s))

To produce a clojurescript version, for example, I could run some tool
that traverses the code and finds all the forms annotated with
#platform, creates a "translation file" if it does not already exist
(adds entries if it does) which would basically be a map of the forms
as they are in the code to the forms as they should be for the new
platform. This file could for example contain a map like :

{"#(Character/isWhitespace %)" (throw)}

As this file would be platform specific, the default value of
"(throw)" would obviously be the platform-specific version. If I
wanted it to work for clojurescript, I could go into that file and
change the file to look like

{"#(Character/isWhitespace %)" #(gstring/isEmpty %)}

Tools such as kibit could be used to automatically find most of the
places where a platform-specific form is used and generate that
sort-of-NIB file.

The map could contain more information (such as source file and such),
but presumably if you have two identical platform-specific forms in
your code their translation should also be identical.

On 7 March 2013 16:10, Andy Fingerhut  wrote:
> I may be wrong, but I think this, and anything else that tries to solve this
> problem after read time, will fail for one of the primary uses of feature
> macros: Java packages/namespaces that exist for Clojure/JVM but not
> ClojureScript, and JavaScript namespaces that exist for ClojureScript but
> not Clojure/JVM.  Each of those would cause a compilation error for the
> other, I believe.
>
> e.g. java.lang.Long and java.util.Date don't exist in ClojureScript, and are
> the kinds of things you would want to conditionally compile on for
> Clojure/JVM.
>
> Andy
>
>
> On Thu, Mar 7, 2013 at 5:44 AM, Jonathan Fischer Friberg
>  wrote:
>>
>> Isn't it possible to solve this with a simple macro?
>>
>> (case-dialect
>>:clojure (... clojure code ...)
>>:clojurescript (... clojurescript code ...))
>>
>> Then, in jvm clojure, it could be implemented as:
>> (defmacro case-dialect [& {:keys [clojure]}] clojure)
>>
>> and in clojurescript:
>> (defmacro case-dialect [& {:keys [clojurescript]}] clojurescript)
>>
>> Alternatively, we could have a def, say *clojure-dialect*, then:
>> (defmacro case-dialect [& {:as m}] (get m *clojure-dialect*))
>>
>> (although the dialect should probably be part of *clojure-version* ... you
>> get the idea)
>>
>> Jonathan
>>
>>
>> On Thu, Mar 7, 2013 at 10:04 AM, Akhil Wali 
>> wrote:
>>>
>>> IMHO features expressions should be evaluated at read-time only.
>>> Putting it off till the compilation phase only complicates things.
>>> So I'm actually favoring a preprocessing step like here -
>>> http://dev.clojure.org/display/design/Feature+Expressions?focusedCommentId=6390066#comment-6390066
>>>
>>> The idea is simple; when the reader parses a sexpr, and if there's a
>>> feature expression,then  only use the part that's relevant to the current
>>> Clojure dialect.
>>> The only complication with this scheme is that all information in
>>> *clojure-version* is related to the version numbers only; however, this
>>> could be changed easily.
>>>
>>>
>>>
>>> On Thu, Mar 7, 2013 at 7:46 AM, Brent Millare 
>>> wrote:

 +1

 Isn't is possible to accomplish all these efforts using tagged literals?
 https://github.com/miner/wilkins

 This way the facilities for read-time code generation can be customized
 and any reader that supports tagged-literals will support this. All of this
 is data provided as arguments, no evaluation. Evaluation

Re: ANN: Iota 1.0.2 release (Reducers for text files)

[bernardH]

Hi,

On Wednesday, March 6, 2013 2:53:26 PM UTC+1, Alan Busby wrote:
>
>
> With the release of Clojure 1.5 and it's new reducers, I figured this 
> would be a good time to release a library to help with file IO for 
> reducers. As reducers can only operate in parallel over specific 
> collections, like vec, it requires some work to use them against files.
>
> Iota wraps a text files using Java NIO's mmap() so you can treat files 
> larger than memory like a vector. Clojure's normal collection functions 
> (first, last, nth, etc) work, while enabling 1.5's reducer's to operate in 
> parallel for fold.
>

Thanks,  I already love your lib !
However, in order to squeeze the last bits of performance, what I'd really 
need would to be directly access the raw data as byte arrays.
The ideal API would provide my function with things looking and quaking 
like bytes arrays but doing the idx offset maths to directly access the 
maped data (read-only ), the next-to ideal would provide my function the 
ref to whole bytes array and give me the start and end idx for current line.

(I'd like to port a Java code where the most significant performance boost 
was avoiding Strings creation when at all possible, which was possible by 
only peeking at most of the lines).

Cheers,

B.

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

Re: How to ensure consistency when accessing database?

[Scott Reynolds]

Use mongo findandmodify command. Only way I know
On Mar 6, 2013 8:36 AM, "bruce li"  wrote:

> Hello,
> I'm working on a piece of code that uses congomongo to access mongodb.
> What I want to implement is to use one collection of the DB as a
> queue(let's say, it's called "task").
>
> Using congomongo, it's easy to fetch a task that is of status :queue :
> (def t (fetch-one :task :where {:status :queue})),
> and also it's simple to update it: (update! :task t (assoc t :status
> :running))
>
> But how to make a safe and consistent "dequeue" operation in concurrent
> context? A naive dequeue should look like this:
>
> (let [t (fetch-one:task :where {:status :queue})]
>   (update! :task t (assoc t :status :running))
>   t)
>
> But taking concurrency into consideration, this implementation is
> error-prone, at least from my point of view. Consider this:
>
> When 2 threads are fetching the task, it's very likely that the task is
> fetched twice using the previous piece of code and they would be executed
> twice.
>
> Do we have something like transaction? Something that will enforce the
> "fetch-one" and "update!" statement are both executed before another
> “fetch-one" operation is adopted?
>
> What I can think of is to use an agent. And my code looks like this:
>
> (def db-agent (agent nil))
> (defn dequeue []
>   (letfn [(do-dequeue [da]
> (let [task (mongo/fetch-one :task :where {:status :queue})]
>   (when task
> (mongo/update! :task feed (assoc task :status :running)))
>   task))]
> (send db-agent do-dequeue)
> @db-agent)))
>
> However, I still doubt the correctness of this solution. Right before the
> @db-agent is called, won't another thread call "dequeue", which will
> involve another "send” and change the value of db-agent?
>
> I'm wondering if anyone can help. Thanks.
>
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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: features expression

[Andy Fingerhut]

I may be wrong, but I think this, and anything else that tries to solve
this problem after read time, will fail for one of the primary uses of
feature macros: Java packages/namespaces that exist for Clojure/JVM but not
ClojureScript, and JavaScript namespaces that exist for ClojureScript but
not Clojure/JVM.  Each of those would cause a compilation error for the
other, I believe.

e.g. java.lang.Long and java.util.Date don't exist in ClojureScript, and
are the kinds of things you would want to conditionally compile on for
Clojure/JVM.

Andy

On Thu, Mar 7, 2013 at 5:44 AM, Jonathan Fischer Friberg <
odysso...@gmail.com> wrote:

> Isn't it possible to solve this with a simple macro?
>
> (case-dialect
>:clojure (... clojure code ...)
>:clojurescript (... clojurescript code ...))
>
> Then, in jvm clojure, it could be implemented as:
> (defmacro case-dialect [& {:keys [clojure]}] clojure)
>
> and in clojurescript:
> (defmacro case-dialect [& {:keys [clojurescript]}] clojurescript)
>
> Alternatively, we could have a def, say *clojure-dialect*, then:
> (defmacro case-dialect [& {:as m}] (get m *clojure-dialect*))
>
> (although the dialect should probably be part of *clojure-version* ... you
> get the idea)
>
> Jonathan
>
>
> On Thu, Mar 7, 2013 at 10:04 AM, Akhil Wali wrote:
>
>> IMHO features expressions should be evaluated at read-time only.
>> Putting it off till the compilation phase only complicates things.
>> So I'm actually favoring a preprocessing step like here -
>> http://dev.clojure.org/display/design/Feature+Expressions?focusedCommentId=6390066#comment-6390066
>>
>> The idea is simple; when the reader parses a sexpr, and if there's a
>> feature expression,then  only use the part that's relevant to the current
>> Clojure dialect.
>> The only complication with this scheme is that all information in
>> *clojure-version* is related to the version numbers only; however, this
>> could be changed easily.
>>
>>
>>
>> On Thu, Mar 7, 2013 at 7:46 AM, Brent Millare wrote:
>>
>>> +1
>>>
>>> Isn't is possible to accomplish all these efforts using tagged literals?
>>> https://github.com/miner/wilkins
>>>
>>> This way the facilities for read-time code generation can be customized
>>> and any reader that supports tagged-literals will support this. All of this
>>> is data provided as arguments, no evaluation. Evaluation happens from the
>>> tag function.
>>>
>>> On Wednesday, March 6, 2013 8:24:15 PM UTC-5, Brian Goslinga wrote:

 Do we really need new syntax for feature expressions? Although it would
 be more ugly than CL's feature expressions, we could use a reader literal.
 For example #feature [ ]. Using a reader literal
 is simple, compatible with EDN, and allows for the feature expressions to
 be backported to an older version of Clojure using a 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.
>>>
>>>
>>>
>>
>>
>>
>> --
>> Akhil Wali
>>
>> # http://github.com/darth10 
>> # http://darth10.github.com
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to 

Re: features expression

[Jonathan Fischer Friberg]

Isn't it possible to solve this with a simple macro?

(case-dialect
   :clojure (... clojure code ...)
   :clojurescript (... clojurescript code ...))

Then, in jvm clojure, it could be implemented as:
(defmacro case-dialect [& {:keys [clojure]}] clojure)

and in clojurescript:
(defmacro case-dialect [& {:keys [clojurescript]}] clojurescript)

Alternatively, we could have a def, say *clojure-dialect*, then:
(defmacro case-dialect [& {:as m}] (get m *clojure-dialect*))

(although the dialect should probably be part of *clojure-version* ... you
get the idea)

Jonathan


On Thu, Mar 7, 2013 at 10:04 AM, Akhil Wali  wrote:

> IMHO features expressions should be evaluated at read-time only.
> Putting it off till the compilation phase only complicates things.
> So I'm actually favoring a preprocessing step like here -
> http://dev.clojure.org/display/design/Feature+Expressions?focusedCommentId=6390066#comment-6390066
>
> The idea is simple; when the reader parses a sexpr, and if there's a
> feature expression,then  only use the part that's relevant to the current
> Clojure dialect.
> The only complication with this scheme is that all information in
> *clojure-version* is related to the version numbers only; however, this
> could be changed easily.
>
>
>
> On Thu, Mar 7, 2013 at 7:46 AM, Brent Millare wrote:
>
>> +1
>>
>> Isn't is possible to accomplish all these efforts using tagged literals?
>> https://github.com/miner/wilkins
>>
>> This way the facilities for read-time code generation can be customized
>> and any reader that supports tagged-literals will support this. All of this
>> is data provided as arguments, no evaluation. Evaluation happens from the
>> tag function.
>>
>> On Wednesday, March 6, 2013 8:24:15 PM UTC-5, Brian Goslinga wrote:
>>>
>>> Do we really need new syntax for feature expressions? Although it would
>>> be more ugly than CL's feature expressions, we could use a reader literal.
>>> For example #feature [ ]. Using a reader literal
>>> is simple, compatible with EDN, and allows for the feature expressions to
>>> be backported to an older version of Clojure using a 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.
>>
>>
>>
>
>
>
> --
> Akhil Wali
>
> # http://github.com/darth10 
> # http://darth10.github.com
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

[ANN] Complete authentication app using Compojure and lib-noir

[xavi]

noir-auth-app is a complete authentication web app based on Compojure, 
lib-noir, Enlive and CongoMongo. It also uses a bit of ClojureScript, jayq 
and shoreleave-remote.

It's meant to be used as a base app for building Clojure web apps that 
require authentication.

https://github.com/xavi/noir-auth-app

Hope it's useful!

Xavi

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

[BJG145]

(Thanks Konrad; a nice summary.)

On Thursday, March 7, 2013 7:28:57 AM UTC, Konrad Hinsen wrote:
>
> My latest article in "Computing in Science and Engineering", with example 
> code in Clojure, in free access for a while: 
>
>A Glimpse of the Future of Scientific Programming 
>http://bit.ly/15yeIjw 
>
> Konrad. 
>
>

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

[BJG145]

Re: this "Snapshot" thing - it's not very convenient for me to work this 
way as I need to be online for Leiningen to pull down the updates. I 
understand that it's possible to freeze the snapshot so I can keep a single 
stable copy in .m2, but how is this done...?

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

Re: How to ensure consistency when accessing database?

[Akhil Wali]

Well, traditional transactions map to refs in Clojure.
You could use a ref, as in any transactional stuff must be performed
in a dosync
form.

However, using a agent is a much cleaner solution for your needs IMHO.
An agent, by definition, can be executing only one operation at a given
time, and other requests/actions are queued.
So, an agent would guarantee that only 1 task is removed from the queue and
then served.

If a different thread calls dequeue, its actually sent to the agent's
internal action queue.
But dereferencing the agent would return you the value in the agent at that
given time itself, not after executing the task.
If you would actually want to wait until the de-queued task is finished,
then use await to wait until all actions sent to the agent are served.




On Wed, Mar 6, 2013 at 10:06 PM, bruce li  wrote:

> Hello,
> I'm working on a piece of code that uses congomongo to access mongodb.
> What I want to implement is to use one collection of the DB as a
> queue(let's say, it's called "task").
>
> Using congomongo, it's easy to fetch a task that is of status :queue :
> (def t (fetch-one :task :where {:status :queue})),
> and also it's simple to update it: (update! :task t (assoc t :status
> :running))
>
> But how to make a safe and consistent "dequeue" operation in concurrent
> context? A naive dequeue should look like this:
>
> (let [t (fetch-one:task :where {:status :queue})]
>   (update! :task t (assoc t :status :running))
>   t)
>
> But taking concurrency into consideration, this implementation is
> error-prone, at least from my point of view. Consider this:
>
> When 2 threads are fetching the task, it's very likely that the task is
> fetched twice using the previous piece of code and they would be executed
> twice.
>
> Do we have something like transaction? Something that will enforce the
> "fetch-one" and "update!" statement are both executed before another
> “fetch-one" operation is adopted?
>
> What I can think of is to use an agent. And my code looks like this:
>
> (def db-agent (agent nil))
> (defn dequeue []
>   (letfn [(do-dequeue [da]
> (let [task (mongo/fetch-one :task :where {:status :queue})]
>   (when task
> (mongo/update! :task feed (assoc task :status :running)))
>   task))]
> (send db-agent do-dequeue)
> @db-agent)))
>
> However, I still doubt the correctness of this solution. Right before the
> @db-agent is called, won't another thread call "dequeue", which will
> involve another "send” and change the value of db-agent?
>
> I'm wondering if anyone can help. Thanks.
>
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
Akhil Wali

# http://github.com/darth10 
# http://darth10.github.com

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

Re: features expression

[Akhil Wali]

IMHO features expressions should be evaluated at read-time only.
Putting it off till the compilation phase only complicates things.
So I'm actually favoring a preprocessing step like here -
http://dev.clojure.org/display/design/Feature+Expressions?focusedCommentId=6390066#comment-6390066

The idea is simple; when the reader parses a sexpr, and if there's a
feature expression,then  only use the part that's relevant to the current
Clojure dialect.
The only complication with this scheme is that all information in
*clojure-version* is related to the version numbers only; however, this
could be changed easily.



On Thu, Mar 7, 2013 at 7:46 AM, Brent Millare wrote:

> +1
>
> Isn't is possible to accomplish all these efforts using tagged literals?
> https://github.com/miner/wilkins
>
> This way the facilities for read-time code generation can be customized
> and any reader that supports tagged-literals will support this. All of this
> is data provided as arguments, no evaluation. Evaluation happens from the
> tag function.
>
> On Wednesday, March 6, 2013 8:24:15 PM UTC-5, Brian Goslinga wrote:
>>
>> Do we really need new syntax for feature expressions? Although it would
>> be more ugly than CL's feature expressions, we could use a reader literal.
>> For example #feature [ ]. Using a reader literal
>> is simple, compatible with EDN, and allows for the feature expressions to
>> be backported to an older version of Clojure using a 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.
>
>
>



-- 
Akhil Wali

# http://github.com/darth10 
# http://darth10.github.com

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