Re: Help with timestamp with timezone in YeSQL

[gvim]

'Turns out I was looking in the wrong place. YeSQL relieves you of all 
the clj-time formatting as you can simply add the PostgreSQL cast 
directly to your placeholder so this:


-- name: add-birth
On Sunday, 17 May 2015 01:46:14 UTC+10, g vim wrote:



   (c/to-timestamp "1967-07-31 06:30:00 America/Caracas")

 evaluates to nil. However:

(c/to-timestamp "1967-07-31 06:30:00")

 gives me an:  #inst "1967-07-31T06:30:00.0-00:00" ,
whatever that is, so I checked the clj-time docs and it appears
to-timestamp doesn't handle timezones.

Any ideas?


Looks like you might want this:

user> (clj-time.format/parse (clj-time.format/formatter "-MM-dd
HH:mm:ss ZZZ") "1967-07-31 06:30:00 America/Caracas")
#object[org.joda.time.DateTime 0x79e05a0 "1967-07-31T10:30:00.000Z"]

I suspect you'll then need some further work to make sure that the Joda
DateTime object correctly converts into what you actually want stored in
the database when it's set on the SQL PreparedStatement (something like
this
,
but extending the type to Joda's DateTime rather than java.util.Date) --
or alternatively you might be OK just coercing the above to a
java.sql.Date or java.sql.Timestamp.

gvim

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


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

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

Re: Help with async operations

[Atamert Ölçgen]

Hi Oleg,

On Sun, May 17, 2015 at 6:48 AM, Oleg Dashevskii 
wrote:

> Hi,
>
> I’m new to Clojure async operations (while have a good understanding of
> other things) and want to get a bit of advice. Atoms & agents still confuse
> me.
>
> What I’m implementing is a small REST webservice with custom in-memory
> database. Database is indexed by unique key, basically it’s a map (I’ll
> denote it as MAP). There are two basic operations:
>
> *PUT /api/…/.* Initiate an update for given KEY. The HTTP response
> should be returned immediately, and the processing should be done
> asynchronously. The processing consists of downloading a data file from web
> and doing some data crunching, the result should go into MAP.
>
> *GET /api/…/.* Use (get MAP KEY) and request params to generate
> response synchronously.
>
> The tricky part (well, for me :) is that parallel PUT requests should be
> possible. The downloading and processing can and should go in parallel,
> independently, whereas updating the MAP should come synchronized,
> one-after-the-other.
>
> How would you implement this?
>

While this can be done with atoms & agents, perhaps you should check out
core.async or Lamina first.

Neither atoms nor agents can be updated in a parallel manner. Only one
update runs on a single atom/agent at a given time. If you really need
parallelism and the updates affect small parts of MAP, perhaps you can
model it using refs, but then it's not one big map anymore. (Still you
can't update a single ref in more than one thread at the same time.)

You probably also want to control how the files are downloaded and
processed, so that there's not duplication of effort. So an event driven
solution seems to fit this problem.



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



-- 
Kind Regards,
Atamert Ölçgen

◻◼◻
◻◻◼
◼◼◼

www.muhuk.com
www.olcgen.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/d/optout.

Using :refer 'sparingly'

[Akiva]

In Stuart Sierra's article here 
(http://stuartsierra.com/2015/05/10/clojure-namespace-aliases), he 
recommends to use :refer sparingly but doesn't explain why this is a 
good idea. Only thing I could think of without putting too much effort 
into it is that it makes it slightly more tedious when you want to use a 
function from a namespace that hasn't been already explicitly referred.


Are there no benefits other than possibly excluding function names that 
might otherwise suffer a namespace clash (assuming their namespace isn't 
being aliased already)?


Thanks,
Akiva

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

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

Re: Using :refer 'sparingly'

[Max Countryman]

I wonder if a reason could be to ensure it’s obvious where a function came 
from? For example (foo …) is ambiguous, it could be defined in the current 
namespace or it may have been referred from another whereas (my-ns/foo …) is 
explicit.


> On May 17, 2015, at 08:04, Akiva  wrote:
> 
> In Stuart Sierra's article here 
> (http://stuartsierra.com/2015/05/10/clojure-namespace-aliases), he recommends 
> to use :refer sparingly but doesn't explain why this is a good idea. Only 
> thing I could think of without putting too much effort into it is that it 
> makes it slightly more tedious when you want to use a function from a 
> namespace that hasn't been already explicitly referred.
> 
> Are there no benefits other than possibly excluding function names that might 
> otherwise suffer a namespace clash (assuming their namespace isn't being 
> aliased already)?
> 
> Thanks,
> Akiva
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: Using :refer 'sparingly'

[Stuart Sierra]

Just like the rest of the article, it's about readability. With `:refer` 
you don't know where a symbol came from when you encounter it in the middle 
of the code.

–S



On Sunday, May 17, 2015 at 4:05:14 PM UTC+1, Akiva Schoen wrote:
>
> In Stuart Sierra's article here 
> (http://stuartsierra.com/2015/05/10/clojure-namespace-aliases), he 
> recommends to use :refer sparingly but doesn't explain why this is a 
> good idea. Only thing I could think of without putting too much effort 
> into it is that it makes it slightly more tedious when you want to use a 
> function from a namespace that hasn't been already explicitly referred. 
>
> Are there no benefits other than possibly excluding function names that 
> might otherwise suffer a namespace clash (assuming their namespace isn't 
> being aliased already)? 
>
> Thanks, 
> Akiva 
>

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

Re: Using :refer 'sparingly'

[Akiva]

Makes sense. I guess my other question then would be if there are any 
benefits to using :refer along with :as.


:A.


Stuart Sierra 
May 17, 2015 at 10:21 AMvia Postbox 

Just like the rest of the article, it's about readability. With 
`:refer` you don't know where a symbol came from when you encounter it 
in the middle of the code.


--S



On Sunday, May 17, 2015 at 4:05:14 PM UTC+1, Akiva Schoen wrote:
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

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

For more options, visit https://groups.google.com/d/optout.
Akiva 
May 17, 2015 at 10:04 AMvia Postbox 

In Stuart Sierra's article here 
(http://stuartsierra.com/2015/05/10/clojure-namespace-aliases), he 
recommends to use :refer sparingly but doesn't explain why this is a 
good idea. Only thing I could think of without putting too much effort 
into it is that it makes it slightly more tedious when you want to use 
a function from a namespace that hasn't been already explicitly referred.


Are there no benefits other than possibly excluding function names 
that might otherwise suffer a namespace clash (assuming their 
namespace isn't being aliased already)?


Thanks,
Akiva


--
Sent from Postbox 



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

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

Re: Using :refer 'sparingly'

[Colin Yates]

As stated in the article, I find the extra context of using :as aids
maintenance more than you might expect. The only time I use refer is
if the referred vars are conceptually owned, or the context is
implicit by the name space using them. For me it is about
responsibility and ignorance. :as implies distance/ignorance, :refer
implies closeness/knowledge.

A concrete example, in my use-case tests I refer most vars from
clojure.test for convenience but the thing being tested is aliased as
'sut'. I could swallow referring the forms being tested in the test
case as well but I am used to the convention of 'sut' (subject under
test).


On 17 May 2015 at 16:23, Akiva  wrote:
> Makes sense. I guess my other question then would be if there are any
> benefits to using :refer along with :as.
>
> :A.
>
> Stuart Sierra
> May 17, 2015 at 10:21 AM via Postbox
> Just like the rest of the article, it's about readability. With `:refer` you
> don't know where a symbol came from when you encounter it in the middle of
> the code.
>
> –S
>
>
>
> On Sunday, May 17, 2015 at 4:05:14 PM UTC+1, Akiva Schoen wrote:
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> Akiva
> May 17, 2015 at 10:04 AM via Postbox
> In Stuart Sierra's article here
> (http://stuartsierra.com/2015/05/10/clojure-namespace-aliases), he
> recommends to use :refer sparingly but doesn't explain why this is a good
> idea. Only thing I could think of without putting too much effort into it is
> that it makes it slightly more tedious when you want to use a function from
> a namespace that hasn't been already explicitly referred.
>
> Are there no benefits other than possibly excluding function names that
> might otherwise suffer a namespace clash (assuming their namespace isn't
> being aliased already)?
>
> Thanks,
> Akiva
>
>
> --
> Sent from Postbox
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: Using :refer 'sparingly'

[John Wiseman]

There's a close parallel in Python, where the same issue comes up of
typically using several modules or packages in a source file and the
language offers a way to import the functions and classes of those modules
in such a way that they can be used without any syntactic marker of their
origin.  For years I've used the Google style guideline

which says "Use imports for packages and modules only", as distinct from
functions, classes, etc., and the justification is "The source of each
identifier is indicated in a consistent way; x.Obj says that object Obj is
defined in module x".

I've found that when reading code that I haven't written it lowers the
friction for understanding just a little bit but that's multiplied by
roughly the number of names in the source code.  It makes it (mostly)
self-evident whether an identifier names a concept from the file I'm
looking at, or somewhere else.  And if it's from somewhere else, it says
right there where that other place is.  It's a significant advantage and I
think the same advantage applies to clojure source code.




On Sun, May 17, 2015 at 8:28 AM, Colin Yates  wrote:

> As stated in the article, I find the extra context of using :as aids
> maintenance more than you might expect. The only time I use refer is
> if the referred vars are conceptually owned, or the context is
> implicit by the name space using them. For me it is about
> responsibility and ignorance. :as implies distance/ignorance, :refer
> implies closeness/knowledge.
>
> A concrete example, in my use-case tests I refer most vars from
> clojure.test for convenience but the thing being tested is aliased as
> 'sut'. I could swallow referring the forms being tested in the test
> case as well but I am used to the convention of 'sut' (subject under
> test).
>
>
> On 17 May 2015 at 16:23, Akiva  wrote:
> > Makes sense. I guess my other question then would be if there are any
> > benefits to using :refer along with :as.
> >
> > :A.
> >
> > Stuart Sierra
> > May 17, 2015 at 10:21 AM via Postbox
> > Just like the rest of the article, it's about readability. With `:refer`
> you
> > don't know where a symbol came from when you encounter it in the middle
> of
> > the code.
> >
> > –S
> >
> >
> >
> > On Sunday, May 17, 2015 at 4:05:14 PM UTC+1, Akiva Schoen wrote:
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> > Akiva
> > May 17, 2015 at 10:04 AM via Postbox
> > In Stuart Sierra's article here
> > (http://stuartsierra.com/2015/05/10/clojure-namespace-aliases), he
> > recommends to use :refer sparingly but doesn't explain why this is a good
> > idea. Only thing I could think of without putting too much effort into
> it is
> > that it makes it slightly more tedious when you want to use a function
> from
> > a namespace that hasn't been already explicitly referred.
> >
> > Are there no benefits other than possibly excluding function names that
> > might otherwise suffer a namespace clash (assuming their namespace isn't
> > being aliased already)?
> >
> > Thanks,
> > Akiva
> >
> >
> > --
> > Sent from Postbox
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google

Re: [ANN] darwin and algebolic - genetic algorithms, and evolving mathematics

[Paul deGrandis]

It's great to see all of these!  Thank you both!

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

Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Daniel]

Actually, I'm more than a little curious about performance optimizations to my 
solution as well[0]. Running Yourkit shows that most of the execution time is 
spent in reduce, so I've tried switching to group-by instead. Also tried 
replacing with iterate. Neither of these improved overall execution time.  
Using 1.6.

[0] 
https://www.reddit.com/r/dailyprogrammer/comments/35s2ds/20150513_challenge_214_intermediate_pile_of_paper/crbs3co?context=3

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

Re: Using :refer 'sparingly'

[Daniel Compton]

I'm not sure if this is idiomatic, but I often like to refer any def*
functions or macros, and :as alias the rest. I just prefer the visual look
of a bare def without a prefix. There's usually only a couple of those in a
codebase so it doesn't add too much overhead.
On Mon, 18 May 2015 at 4:05 am John Wiseman  wrote:

> There's a close parallel in Python, where the same issue comes up of
> typically using several modules or packages in a source file and the
> language offers a way to import the functions and classes of those modules
> in such a way that they can be used without any syntactic marker of their
> origin.  For years I've used the Google style guideline
> 
> which says "Use imports for packages and modules only", as distinct from
> functions, classes, etc., and the justification is "The source of each
> identifier is indicated in a consistent way; x.Obj says that object Obj is
> defined in module x".
>
> I've found that when reading code that I haven't written it lowers the
> friction for understanding just a little bit but that's multiplied by
> roughly the number of names in the source code.  It makes it (mostly)
> self-evident whether an identifier names a concept from the file I'm
> looking at, or somewhere else.  And if it's from somewhere else, it says
> right there where that other place is.  It's a significant advantage and I
> think the same advantage applies to clojure source code.
>
>
>
>
> On Sun, May 17, 2015 at 8:28 AM, Colin Yates 
> wrote:
>
>> As stated in the article, I find the extra context of using :as aids
>> maintenance more than you might expect. The only time I use refer is
>> if the referred vars are conceptually owned, or the context is
>> implicit by the name space using them. For me it is about
>> responsibility and ignorance. :as implies distance/ignorance, :refer
>> implies closeness/knowledge.
>>
>> A concrete example, in my use-case tests I refer most vars from
>> clojure.test for convenience but the thing being tested is aliased as
>> 'sut'. I could swallow referring the forms being tested in the test
>> case as well but I am used to the convention of 'sut' (subject under
>> test).
>>
>>
>> On 17 May 2015 at 16:23, Akiva  wrote:
>> > Makes sense. I guess my other question then would be if there are any
>> > benefits to using :refer along with :as.
>> >
>> > :A.
>> >
>> > Stuart Sierra
>> > May 17, 2015 at 10:21 AM via Postbox
>> > Just like the rest of the article, it's about readability. With
>> `:refer` you
>> > don't know where a symbol came from when you encounter it in the middle
>> of
>> > the code.
>> >
>> > –S
>> >
>> >
>> >
>> > On Sunday, May 17, 2015 at 4:05:14 PM UTC+1, Akiva Schoen wrote:
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with
>> your
>> > first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojure?hl=en
>> > ---
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Clojure" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to clojure+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>> > Akiva
>> > May 17, 2015 at 10:04 AM via Postbox
>> > In Stuart Sierra's article here
>> > (http://stuartsierra.com/2015/05/10/clojure-namespace-aliases), he
>> > recommends to use :refer sparingly but doesn't explain why this is a
>> good
>> > idea. Only thing I could think of without putting too much effort into
>> it is
>> > that it makes it slightly more tedious when you want to use a function
>> from
>> > a namespace that hasn't been already explicitly referred.
>> >
>> > Are there no benefits other than possibly excluding function names that
>> > might otherwise suffer a namespace clash (assuming their namespace isn't
>> > being aliased already)?
>> >
>> > Thanks,
>> > Akiva
>> >
>> >
>> > --
>> > Sent from Postbox
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with
>> your
>> > first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojure?hl=en
>> > ---
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Clojure" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to clojure+unsubscr...@googlegroups.com.
>> > 

can't type hint on an empty vector directly

[Sergey Didenko]

Hello,

I have encountered a somewhat inconsistent behavior when applying type
hinting on an empty vector.

Lucene 5.1 CharArraySet has a few constructors, one of which is

public CharArraySet(Collection c, boolean ignoreCase)

So I get a reflection warning only in the first case:

1. (CharArraySet. ^Collection [] false)

2. (CharArraySet. ^Collection ["a"] false)

3. (def ^Collection empty-collection [])
(CharArraySet. empty-collection false)

Is it a bug or a feature?

P.S.
*clojure-version*
{:major 1, :minor 7, :incremental 0, :qualifier "beta3"}

java -version
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

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

Re: [ANN] Sparkling, a Clojure-API to Apache Spark.

[Tilak Thapa]

Hi,
could anybody please help me to figure out following error with 
group-by-key fn?

(defn sorted-tuple [p f]
  (if (< (.compareTo p f) 0)
(spark/tuple p f)
(spark/tuple f p)))

(defn tuples-list [[p & frens]]
  (map #(spark/tuple (sorted-tuple p %) frens) frens))


(->> (spark/parallelize sc ["100 200 300 400 500 600", "200 100 300 400", "300 
100 200 400 500", "400 100 200 300", "500 100 300", "600 100"])
 (spark/map #(split-at-space %))
 (spark/flat-map #(tuples-list %))
 (spark/group-by-key))


CompilerException java.lang.IllegalArgumentException: No matching field found: 
groupByKey for class org.apache.spark.api.java.JavaRDD, compiling:


I'm trying hard to figure out but could not. It works if I replace 
'group-by-key' with 

(spark/group-by #(._1 %))

but that's not what I want.


Anybody please?



thanks

-tilak



On Wednesday, January 7, 2015 at 6:23:42 AM UTC-6, chris_betz wrote:
>
> Hi,
>
>
> we just released Sparkling (https://gorillalabs.github.io/sparkling/), 
> our take on an API to Apache Spark.
>
>
>
> With an eye on speed for very large amounts of data we improved clj-spark 
> and flambo to get us the speed we need for our production environment.
>
>
> See https://gorillalabs.github.io/sparkling/articles/getting_started.html 
> for a quickstart or dive directly into our playground project by 
> git clone https://github.com/gorillalabs/sparkling-getting-started.git
>
>
>
> Happy hacking
>
> Chris
> (@gorillalabs_de )
>

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

Re: Help with async operations

[Rangel Spasov]

You can checkout the new pipeline stuff, I think it fits what you're 
looking for nicely:

https://gist.github.com/raspasov/7c9d8f2872d6065b2145


On Saturday, May 16, 2015 at 10:54:16 PM UTC-7, Oleg Dashevskii wrote:
>
> Hi,
>
> I’m new to Clojure async operations (while have a good understanding of 
> other things) and want to get a bit of advice. Atoms & agents still confuse 
> me.
>
> What I’m implementing is a small REST webservice with custom in-memory 
> database. Database is indexed by unique key, basically it’s a map (I’ll 
> denote it as MAP). There are two basic operations:
>
> *PUT /api/…/.* Initiate an update for given KEY. The HTTP response 
> should be returned immediately, and the processing should be done 
> asynchronously. The processing consists of downloading a data file from web 
> and doing some data crunching, the result should go into MAP.
>
> *GET /api/…/.* Use (get MAP KEY) and request params to generate 
> response synchronously.
>
> The tricky part (well, for me :) is that parallel PUT requests should be 
> possible. The downloading and processing can and should go in parallel, 
> independently, whereas updating the MAP should come synchronized, 
> one-after-the-other.
>
> How would you implement this?
>
> --
> Oleg.
>

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

neocons get record from cypher query

[Sam Raker]

I'm using neocons to put some data into a Neo4j database. I need to create 
relationships between nodes I've just created and nodes in the DB. I can't 
retrieve the nodes based on id without caching them locally, and they're 
not unique enough to retrieve using e.g. rest.nodes/find, so I need to use 
Cypher to get at them. I'm wondering if there's a better way to do this 
than what I currently am working with, namely 

(nn/get conn (->  (cy/tquery conn "START person=node({sid}) MATCH 
person-[:foo]->o RETURN o" {:sid 1}) first (get-in ["o" :metadata :id]

(this is just a toy example, so if the Cypher query is too simple, forgive 
me).

This seems...too complicated? Am I missing something? Is there a more 
idiomatic way to convert cypher results into neocons records?

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

Re: Using :refer 'sparingly'

[Christopher Small]

I agree with the general sentiment expressed here, but would just like to 
add that `:refer`-ing a few frequently used functions (as Colin Yates 
stated, particularly when it's assumed there is strong coupling or 
closeness between the two namespaces involved), is a much more minor 
nuisance than `:refer :all`. At least with `:refer [some-fn 
some-other-fn]`, you _can_ figure out where the function came from by going 
up to the `ns` declaration, and if you're fast with your editor, this is 
easy to do. Both `:refer :all` and `:use`/ `(use)` should (IMHO) only be 
used for hacking around at the repl.

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

Re: Help with async operations

[Oleg Dashevskii]

Hi Atamert,

воскресенье, 17 мая 2015 г., 19:35:57 UTC+6 пользователь Atamert Ölçgen 
написал:
>
> I’m new to Clojure async operations (while have a good understanding of 
>> other things) and want to get a bit of advice. Atoms & agents still confuse 
>> me.
>>
>> What I’m implementing is a small REST webservice with custom in-memory 
>> database. Database is indexed by unique key, basically it’s a map (I’ll 
>> denote it as MAP). There are two basic operations:
>>
>> *PUT /api/…/.* Initiate an update for given KEY. The HTTP response 
>> should be returned immediately, and the processing should be done 
>> asynchronously. The processing consists of downloading a data file from web 
>> and doing some data crunching, the result should go into MAP.
>>
>> *GET /api/…/.* Use (get MAP KEY) and request params to generate 
>> response synchronously.
>>
>> The tricky part (well, for me :) is that parallel PUT requests should be 
>> possible. The downloading and processing can and should go in parallel, 
>> independently, whereas updating the MAP should come synchronized, 
>> one-after-the-other.
>>
>> How would you implement this?
>>
>
> While this can be done with atoms & agents, perhaps you should check out 
> core.async or Lamina first.
>
> Neither atoms nor agents can be updated in a parallel manner. Only one 
> update runs on a single atom/agent at a given time. If you really need 
> parallelism and the updates affect small parts of MAP, perhaps you can 
> model it using refs, but then it's not one big map anymore. (Still you 
> can't update a single ref in more than one thread at the same time.)
>
> You probably also want to control how the files are downloaded and 
> processed, so that there's not duplication of effort. So an event driven 
> solution seems to fit this problem.
>

In fact, I don't use the MAP as a whole, each read/update operation is 
scoped by KEY. So a map of refs sounds good.

Speaking of event driven solution and core.async. I came up with the 
following scheme:

[PUT request handler] > processing queue channel > Download/process 
> update queue channel > [updating the MAP].

*[updating the MAP]* is basically a (go ...) block which does synchronous 
updates.

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

Re: neocons get record from cypher query

[Sam Raker]

Figured it out: `neocons.rest.records/instantiate-record-from` does the 
trick.

On Sunday, May 17, 2015 at 7:09:35 PM UTC-4, Sam Raker wrote:
>
> I'm using neocons to put some data into a Neo4j database. I need to create 
> relationships between nodes I've just created and nodes in the DB. I can't 
> retrieve the nodes based on id without caching them locally, and they're 
> not unique enough to retrieve using e.g. rest.nodes/find, so I need to use 
> Cypher to get at them. I'm wondering if there's a better way to do this 
> than what I currently am working with, namely 
>
> (nn/get conn (->  (cy/tquery conn "START person=node({sid}) MATCH 
> person-[:foo]->o RETURN o" {:sid 1}) first (get-in ["o" :metadata :id]
>
> (this is just a toy example, so if the Cypher query is too simple, forgive 
> me).
>
> This seems...too complicated? Am I missing something? Is there a more 
> idiomatic way to convert cypher results into neocons records?
>

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

[CFP] SECOND NOTICE: Scheme and Functional Programming Workshop 2015

[Andy Keep]

*SECOND NOTICE: DEADLINE THIS FRIDAY!*

*Call For Papers:*

*Scheme and Functional Programming Workshop 2015*
*Vancouver, British Columbia, Canada*
*(Co-located with ICFP 2015)*

http://andykeep.com/SchemeWorkshop2015/

Submissions related to Scheme, Racket, Clojure, and functional
programming are welcome and encouraged. Topics of interest include
but are not limited to:

   -  Program-development environments, debugging, testing
   - Implementation (interpreters, compilers, tools, benchmarks, etc.)
   - Syntax, macros, hygiene
   - Distributed computing, concurrency, parallelism
   - Interoperability with other languages, FFIs
   - Continuations, modules, object systems, types
   - Theory, formal semantics, correctness
   - History, evolution and standardization of Scheme
   - Applications, experience and industrial uses of Scheme
   - Education
   - Scheme pearls (elegant, instructive uses of Scheme)

We also welcome submissions related to dynamic or multiparadigmatic
languages and programming techniques.

*Important Dates:*

May 22nd, 2015 - Paper deadline
June 26th, 2015 - Author notification
July 19th, 2015 - Camera-ready deadline
September 4th, 2015 - Workshop

Submissions must be in ACM proceedings format, no smaller than 9-point
type (10-point type preferred). Microsoft Word and LaTeX templates for
this format are available at:
http://www.acm.org/sigs/sigplan/authorInformation.htm

Submissions should be in PDF and printable on US Letter.

To encourage authors to submit their best work, this year we are
encouraging shorter papers (around 6 pages, excluding references). This
is to allow authors to submit longer, revised versions of their papers
to archival conferences or journals. Longer papers (10--12 pages) are
also acceptable, if the extra space is needed. There is no maximum
length limit on submissions, but good submissions will likely be in the
range of 6 to 12 pages.

More information available at: http://andykeep.com/SchemeWorkshop2015/


*Organizers:*

Andy Keep, Cisco Systems Inc. (General Chair)
Ryan Culpepper, Northeastern University (Program Chair)

(Apologies for duplications from cross-posting.)

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