Re: core.async and channel flushing

[Alexander L.]

Sorry for bringing this back up, but I was wondering if anyone figured out 
something better...

On Saturday, September 14, 2013 10:49:08 PM UTC+3, Alexander L. wrote:
>
>
> I am developing an application and I use core.async to push data from 
> multiple threads within an infinite 
>
> (go (while true 
>>   (let [data (> (do processing here...)))
>
>
> in order to be processed. As you probably already figured out, I store my 
> channel inside an atom defined at the start of my app.
>
> If an exception occurs in one of the threads, then I am calling a global 
> exception handler which will reset the atom that holds the channel in order 
> to flush it and make sure the processing of the data it contains will stop.
>
> Now, my question is, does anyone know a better way to flush a core.async 
> channel or the only way is to re-create the channel?
>
> Thank you for your time.
>
> Regards,
>
> Alexander
>

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

Macro problem: passing a function to a macro

[Tassilo Horn]

Hi all,

I'd like to have a macro that I can call and pass it some function that
the macro uses inside.  Concretely, the macro iterates over some class
model and should expand to a ns declaration with one defn per class in
the model.  Currently, the macro calls a generate-defn-for-class
function internally that returns a valid defn-form like so.

(defmacro mymacro [model-file]
  (let [model (load-model model-file)]
`(do
   ;; ...
   ~@(for [class model]
   (generate-defn-for-class class)


That works fine, but now I have a similar use-case where different defns
have to be generated.  So I'd like to refactor my macro so that I can
pass it a defn-generating function.  However, that doesn't seem to work.

Here's a super-minimal version of what I'm trying to do:

  (defmacro do-do [x afn]
`(do ~(afn x)))

So when I'd call it like

  (do-do 1 inc)

I'd expect it to expand to (do 2).  However, it expands to (do nil).
Why is that?

Bye,
Tassilo

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

Re: Compulsive over-optimization

[Niels van Klaveren]

I can imagine this behavior. Unlike premature performance optimization, 
readability / terseness are well worth optimizing for when learning 
Clojure, as long as you value readability over terseness to keep well away 
from code golf territory. 

With Clojure, I always have the idea that things could be done in a simpler 
way, and usually it can. A lot of what I consider 'draft' code that works 
can be cleaned up drastically, and sometimes after cleaning I still have 
some niggles.  However, with time my 'draft' code tends to get cleaner and 
cleaner, and I also see up front where algorithms and function input / 
output can be changed to prevent code getting needlessly complex, and 
having to handle more exceptions than rules.

While doing 4clojure problems, some of my first attempts were 4 or 5  
lines. While this is considered next nothing in Javaland, getting them down 
to 1 line, and comparing them to some of the Clojure vets you get a good 
feel for what's the idiomatic Clojure way to solve certain problems. So I 
guess it's all part of the learning process. I would not worry about it too 
much, you can only clean up for readability / terseness up to a point.

Be sure to stay away from performance optimization unless absolutely 
necessary. There's way too many options, and it needs a really good insight 
into Clojure's implementation details to do effectively. Most idiomatic 
Clojure code performs on par or better compared to other dynamic languages 
like Python and Ruby.

On Saturday, October 19, 2013 1:20:33 AM UTC+2, queshaw wrote:
>
> With clojure in particular, I am having trouble not rearranging my code 
> to be what I think is more optimal in ways that seem probably not 
> practical. I've noticed myself doing that when I'm newish to languages 
> and apis. But, I go bonkers with clojure. 
>
> Do you have any thoughts about how to avoid that, other than Bob 
> Newhart's advice: 
>
> http://www.youtube.com/watch?v=Ow0lr63y4Mw 
>
> Kendall 
>
>

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

RE: Macro problem: passing a function to a macro

[Phillip Lord]

Is it because you're expansion returns the symbol and not the function.

 ('inc 2) 

returns nil which is what I think is happening.


From: clojure@googlegroups.com [clojure@googlegroups.com] on behalf of Tassilo 
Horn [t...@gnu.org]
Sent: 22 October 2013 10:37
To: clojure@googlegroups.com
Subject: Macro problem: passing a function to a macro

Hi all,

I'd like to have a macro that I can call and pass it some function that
the macro uses inside.  Concretely, the macro iterates over some class
model and should expand to a ns declaration with one defn per class in
the model.  Currently, the macro calls a generate-defn-for-class
function internally that returns a valid defn-form like so.

(defmacro mymacro [model-file]
  (let [model (load-model model-file)]
`(do
   ;; ...
   ~@(for [class model]
   (generate-defn-for-class class)


That works fine, but now I have a similar use-case where different defns
have to be generated.  So I'd like to refactor my macro so that I can
pass it a defn-generating function.  However, that doesn't seem to work.

Here's a super-minimal version of what I'm trying to do:

  (defmacro do-do [x afn]
`(do ~(afn x)))

So when I'd call it like

  (do-do 1 inc)

I'd expect it to expand to (do 2).  However, it expands to (do nil).
Why is that?

Bye,
Tassilo

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

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

Re: [ANN] Timeline - a library for time-varying data values

[Mikera]

Just released Timeline 0.3.0 to clojars:

https://clojars.org/net.mikera/timeline

Some new (still experimental) features:

 - timelines are now "Counted" for you can do (count timeline) in the 
normal way
 - timelines can be sliced with arbitrary start and end times (exploiting 
the efficiency of RRB-vectors)
 - support for logging of changes only (so you don't store duplicate events)
 - ISO8601 date parsing
 - "resample" function for taking regular samples at intervals along a 
timeline

Comments / ideas / patches welcome as always.

GitHub repo:
https://github.com/mikera/timeline

On Tuesday, 15 October 2013 13:15:29 UTC+1, Mikera wrote:
>
> Hi All,
>
> I just created a new, small, experimental library because I needed to 
> represent a "timeline" of values as an immutable object.
>
> Target use cases:
> - Efficient logging of timestamped events
> - Storage of sensor data event streams (Internet of Things etc.)
>
> It's far from finished but I thought it would be worth sharing early in 
> case others find it useful, have feature requests, or have ideas to 
> contribute.
>
> Key features / design points:
> - Each value (event) on the timeline has a timestamp 
> - Given a timeline, it is possible to quickly query the value at any point 
> in time.
> - Integrates with Joda time / clj-time
> - Uses RRB trees (thanks Michal for clojure/core.rrb-vector) so that 
> timelines can be efficiently cut and spliced together
> - Backed by a protocol, allowing for alternative implementations (not sure 
> if this is useful. but maybe)
>
> Repository is here:
>
> https://github.com/mikera/timeline
>
> Have fun!
>
>   Mike.
>

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

Re: Macro problem: passing a function to a macro

[Tassilo Horn]

Phillip Lord  writes:

> Is it because you're expansion returns the symbol and not the
> function.
>
>  ('inc 2) 
>
> returns nil which is what I think is happening.

Ah, indeed.  I really whished that would throw an error.  I mean, it's
cool that keywords can lookup themselves in maps, but I don't think
that's needed for symbols.  At least I've never seen occurences of

  ('foo my-map)
  ('foo my-map ::default)

in real code, and it's likely to shadow errors such as mine.

Anyway, using `resolve` works:

  (defmacro do-do [x afn]
`(do ~((resolve afn) x)))

Is that what one would use, or is there something better?

Bye,
Tassilo

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

Re: Macro problem: passing a function to a macro

[Phillip Lord]

Tassilo Horn  writes:

> Phillip Lord  writes:
>
>> Is it because you're expansion returns the symbol and not the
>> function.
>>
>>  ('inc 2) 
>>
>> returns nil which is what I think is happening.
>
> Ah, indeed.  I really whished that would throw an error.  I mean, it's
> cool that keywords can lookup themselves in maps, but I don't think
> that's needed for symbols.  At least I've never seen occurences of
>
>   ('foo my-map)
>   ('foo my-map ::default)
>
> in real code, and it's likely to shadow errors such as mine.


I'd agree. I have to admit I didn't know symbols implemented IFn  -- in
fact, I looked up the code to make sure. I think that ('foo my-map) looks
fairly pathological and (get my-map 'foo) seems more likely. Although,
of course, you might do something like

(def x
 {'symb 1})

(def foo
   (let [x] (fn[y](y x

(foo 'symb)

But still a crash seems more sensible to me. I'd be interested if anyone
can show a sensible use for this.


> Anyway, using `resolve` works:
>
>   (defmacro do-do [x afn]
> `(do ~((resolve afn) x)))
>
> Is that what one would use, or is there something better?

My solution involved "eval"; I think yours is better.

Phil

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

problems with state-t monad transformer

[Mark Fisher]

I originally posted this in Stack
Overflow,
but realised I might get more response from the google group. Apologies for
duplication.

I'm seeing some issues using a parser monad created from the state monad
transformer.

I've written a full test case on the SO page outlining the issue, which is
that when I use m-plus for the combined monad, it always evaluates the
first 2 methods, even though it uses the return values from the first (if
it is valid), and any state changes in the second occur but are discarded
(however side effects do - like d/b updates etc).

e.g.

(def parser-m (state-t maybe-m))
(def world-destroyer
  (domonad parser-m
   [_ (fetch-state)
result (m-plus
(check-we-are-chilled)
(destroy-planet))]
   result))
(world-destroyer {:chill-out true})

In this implementation, destroy-planet is always evaluated.
Both of these monadic functions can terminate by using a :when condition on
the state.

If I add a dummy method to the m-plus call list at the start (as first or
as second method in list) that does nothing (using a :when nil predicate to
stop its evaluation), the results are fine, no planet is destroyed because
it's never called, and the dummy monadic function takes the hit of stopping
m-plus spilling into the destroy-planet function.

Interestingly, any state changes I make in the method erroneously called do
not get reflected in the final return value (clearly due to immutability of
the state map), but side effects are happening - and that's my issue.

I've reverted to using a hand-crafted parser-m as given on Jim Duey's monad
blog  which
doesn't exhibit this behaviour.

I'm relatively inexperienced with clojure and monads (I was using this as
an excuse to learn them both), so I thought i'd try and work out why it's
happening.

>From looking at the definitions of state-t monad-m, the only thing i can
see m-plus doing different to Jim's version is:

state-t monad-m:
(defn x [s]
  (apply (fn [& xs]
   (first (drop-while nil? xs)))
 (map #(% s) flist)))

jim's:
(defn y [s]
  (first (drop-while nil?
 (map #(% s) flist

for some list of functions flist, e.g.
(def flist
  [(fn [x]
 (println "f a : " x)
 (when-let [r (:a x)] r))
   (fn [x]
 (println "f b: "x)
 (when-let [r (:b x)] r))
   (fn [x]
 (println "f nil : " x)
 nil)])

(x {:b 2})
(y {:b 2})

and running either of these produces same result (2), however they both
produce the println side effects of *all 3* functions in the list, so now
i'm even more confused.

I thought everything in y is lazy, so only the first two methods would be
used from the array. I can't find anything saying apply is lazy, so thought
I was getting closer.

Anyone have any thoughts on this? Am I using m-plus in the right way inside
a domonad call?

Cheers,
Mark

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

[Adam Clements]

This is an emacs plugin which uses lein-ancient[1] to automatically insert
the latest version vector of a library at the cursor in emacs. This works
with clojars, maven central and even compatible private repositories.

Simply M-x latest-clojure-libraries-insert-dependency, type the name of
your desired library, e.g. cheshire, and [cheshire "5.2.0"] will be
inserted at the cursor position.

Better yet, if you have an nrepl running and pomegranate[2] in your
dependencies, it will ask you if you want to inject the dependency into the
running nrepl, meaning you can add dependencies without restarting your
program!

Further details and installation instructions are in the README at:
https://github.com/AdamClements/latest-clojure-libraries

Many thanks to Yannick Scherer (xsc) for incorporating the necessary
command into lein-ancient

Adam Clements

[1] https://github.com/xsc/lein-ancient
[2] https://github.com/cemerick/pomegranate

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

Getting lengths/dimensions in vectorz-clj

[P Martin]

Hi there,

I am using vectors-clj to do some optimization work, but I am having 
trouble getting the dimensions of the matrices I build. I come from Matlab, 
so I am used to commands such as "size(M)" which returns the (n,m) 
dimensions of the matrix M. I am including clojure.core.matrix in my code 
and I saw a call for "get-shape" online, but it does not appear. Do I need 
to add more use commands to get a supporting api?

I am using the following commands to bring vectorz-clj into my namespace:

(use '[clojure.core.matrix :as mat])

(set-current-implementation :vectorz)

Thanks!

Patrick

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

[Mikera]

You probably want:

  (shape M) ;; returns a vector [4 6] for a 4x6 Matrix

Though you can also access the individual dimension sizes as follows, which 
is sometimes useful:

  (dimension-count M 0) ;; returns 4 as the count of the first dimension
  (dimension-count M 1) ;; returns 6 as the count of the second dimension

More generally, check out the clojure.core.matrix namespace for all the 
public API functions.

On Tuesday, 22 October 2013 23:30:01 UTC+8, P Martin wrote:
>
> Hi there,
>
> I am using vectors-clj to do some optimization work, but I am having 
> trouble getting the dimensions of the matrices I build. I come from Matlab, 
> so I am used to commands such as "size(M)" which returns the (n,m) 
> dimensions of the matrix M. I am including clojure.core.matrix in my code 
> and I saw a call for "get-shape" online, but it does not appear. Do I need 
> to add more use commands to get a supporting api?
>
> I am using the following commands to bring vectorz-clj into my namespace:
>
> (use '[clojure.core.matrix :as mat])
>
> (set-current-implementation :vectorz)
>
> Thanks!
>
> Patrick
>

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

Request for help optimising a Clojure program

[Paul Butcher]

I've been playing around with a generalised version of the N-Queens problem 
that handles other chess pieces. I have a Scala implementation that uses an 
eager depth-first search. Given enough RAM (around 12G - it's very memory 
hungry!) it can solve a 6x9 board with 6 pieces in around 2.5 minutes on my 
MacBook Pro.

I then created a Clojure version of the same algorithm with the intention of 
(eventually) using laziness to avoid the memory issue. However, the performance 
of the Clojure version is several orders of magnitude worse than the Scala 
version (I've left it running overnight on the problem that the Scala version 
solves in 2.5 minutes and it still hasn't completed).

I'm struggling to see why the performance of the Clojure version is so much 
worse than the Scala. Profiling in YourKit suggests that it's spending 99% of 
its time in PersistentHashSet.cons, but I'm at a loss to explain why. I would 
be grateful for any insight.

The code for the two different versions is on GitHub:

https://github.com/paulbutcher/chess-scala
https://github.com/paulbutcher/chess-clojure

Notes:

- I know that an exhaustive depth-first search isn't a great way to tackle this 
problem. But I'd like to understand why I see such a dramatic difference 
between the performance of the Scala and Clojure versions.

- I believe that I've implemented the same algorithm in both Scala and Clojure 
- certainly they both generate the same results for small problems (there are 
3x3 and 4x4 problems commented out in the source). But clearly I can't rule out 
the possibility that I've made a mistake in the Clojure implementation. If 
anyone can spot my stupid mistake, I'd greatly appreciate it.

Thanks in advance for any insight that anyone can offer.

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: p...@paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher

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

[Mark Engelberg]

I looked briefly at the code and can confirm that to my eye, the two
implementations appear to be implementing the same algorithm.

My first guess would be that the performance difference comes from
Clojure's use of boxed numbers for all the positions.  Possibly you could
get better performance by using something like (defrecord Posn [^int x ^int
y]) rather than vectors for the positions.  It's tricky though, in Clojure,
to make sure that the numbers remain primitives everywhere they are used.

This hypothesis doesn't fit, however, with your observation that most of
the time is spent in conjing things into sets.  I can't explain why that
would be a bottleneck.

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

[P Martin]

Great! Thanks for the clarification.

Patrick

On Tuesday, October 22, 2013 12:21:33 PM UTC-4, Mikera wrote:
>
> You probably want:
>
>   (shape M) ;; returns a vector [4 6] for a 4x6 Matrix
>
> Though you can also access the individual dimension sizes as follows, 
> which is sometimes useful:
>
>   (dimension-count M 0) ;; returns 4 as the count of the first dimension
>   (dimension-count M 1) ;; returns 6 as the count of the second dimension
>
> More generally, check out the clojure.core.matrix namespace for all the 
> public API functions.
>
> On Tuesday, 22 October 2013 23:30:01 UTC+8, P Martin wrote:
>>
>> Hi there,
>>
>> I am using vectors-clj to do some optimization work, but I am having 
>> trouble getting the dimensions of the matrices I build. I come from Matlab, 
>> so I am used to commands such as "size(M)" which returns the (n,m) 
>> dimensions of the matrix M. I am including clojure.core.matrix in my code 
>> and I saw a call for "get-shape" online, but it does not appear. Do I need 
>> to add more use commands to get a supporting api?
>>
>> I am using the following commands to bring vectorz-clj into my namespace:
>>
>> (use '[clojure.core.matrix :as mat])
>>
>> (set-current-implementation :vectorz)
>>
>> Thanks!
>>
>> Patrick
>>
>

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

binding and lazy seqs

[Brian Craft]

I just came across this example in "Clojure Programming", chapt 4:

(def ^:dynamic *max-value* 255)
(defn valid-value? [v] (<= v *max-value*))

(binding [*max-value* 500] (map valid-value? [299]))
;= (false)

It's not really explained in the text. I'm guessing this happens because 
when the (binding...) expression is evaluated, it merely returns the head 
of the seq. The values of the seq aren't evaluated until the repl 
implicitly realizes the return value. (I can see the point of this repl 
behavior, but it has often misled me by giving me different results than I 
get when running code outside the repl).

The workaround in the book is to move the "binding" into the map function, 
though I would think "doall" would be a better solution.

(binding [*max-value* 500] (doall (map valid-value? [299])))
;= (true)

This seems like the same issue that comes up with libraries that implement 
a with- API: with-db, and so-forth. You have to walk any seqs within 
the binding form if the binding is to have any affect on the values in the 
seqs.

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

[David Nolen]

I note that the Clojure version isn't being given 12gigs of RAM, is this
something you're giving to the JVM after when you run a AOTed version of
the Clojure code.

You also haven't said whether the timings for the smaller problems are
significantly different between Scala and Clojure.

David


On Tue, Oct 22, 2013 at 12:28 PM, Paul Butcher  wrote:

> I've been playing around with a generalised version of the N-Queens
> problem that handles other chess pieces. I have a Scala implementation that
> uses an eager depth-first search. Given enough RAM (around 12G - it's very
> memory hungry!) it can solve a 6x9 board with 6 pieces in around 2.5
> minutes on my MacBook Pro.
>
> I then created a Clojure version of the same algorithm with the intention
> of (eventually) using laziness to avoid the memory issue. However, the
> performance of the Clojure version is several orders of magnitude worse
> than the Scala version (I've left it running overnight on the problem that
> the Scala version solves in 2.5 minutes and it still hasn't completed).
>
> I'm struggling to see why the performance of the Clojure version is so
> much worse than the Scala. Profiling in YourKit suggests that it's spending
> 99% of its time in PersistentHashSet.cons, but I'm at a loss to explain
> why. I would be grateful for any insight.
>
> The code for the two different versions is on GitHub:
>
> https://github.com/paulbutcher/chess-scala
> https://github.com/paulbutcher/chess-clojure
>
> Notes:
>
> - I know that an exhaustive depth-first search isn't a great way to tackle
> this problem. But I'd like to understand why I see such a dramatic
> difference between the performance of the Scala and Clojure versions.
>
> - I believe that I've implemented the same algorithm in both Scala and
> Clojure - certainly they both generate the same results for small problems
> (there are 3x3 and 4x4 problems commented out in the source). But clearly I
> can't rule out the possibility that I've made a mistake in the Clojure
> implementation. If anyone can spot my stupid mistake, I'd greatly
> appreciate it.
>
> Thanks in advance for any insight that anyone can offer.
>
> --
> paul.butcher->msgCount++
>
> Snetterton, Castle Combe, Cadwell Park...
> Who says I have a one track mind?
>
> http://www.paulbutcher.com/
> LinkedIn: http://www.linkedin.com/in/paulbutcher
> MSN: p...@paulbutcher.com
> AIM: paulrabutcher
> Skype: paulrabutcher
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and 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: binding and lazy seqs

[Tassilo Horn]

Brian Craft  writes:

Hi Brian,

> I just came across this example in "Clojure Programming", chapt 4:
>
> (def ^:dynamic *max-value* 255)
> (defn valid-value? [v] (<= v *max-value*))
>
> (binding [*max-value* 500] (map valid-value? [299]))
> ;= (false)
>
> It's not really explained in the text. I'm guessing this happens because 
> when the (binding...) expression is evaluated, it merely returns the head 
> of the seq. The values of the seq aren't evaluated until the repl 
> implicitly realizes the return value.

Right.

> The workaround in the book is to move the "binding" into the map
> function, though I would think "doall" would be a better solution.
>
> (binding [*max-value* 500] (doall (map valid-value? [299])))
> ;= (true)
>
> This seems like the same issue that comes up with libraries that
> implement a with- API: with-db, and so-forth. You have to walk
> any seqs within the binding form if the binding is to have any affect
> on the values in the seqs.

Another way is to use `bound-fn' which has the benefit that you don't
need to realize the complete lazy seq in advance:

  (binding [*max-value* 500]
(map (bound-fn [x] (valid-value? x)) [299]))

Bye,
Tassilo

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

Re: Request for help optimising a Clojure program

[Paul Butcher]

On 22 Oct 2013, at 18:45, Mark Engelberg  wrote:

> I looked briefly at the code and can confirm that to my eye, the two 
> implementations appear to be implementing the same algorithm.

Thanks - always good to have a second pair of eyes :-)

> My first guess would be that the performance difference comes from Clojure's 
> use of boxed numbers

That was my first thought too - but I thought that I'd look at a profile first 
:-)

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: p...@paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher

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

[Paul Butcher]

On 22 Oct 2013, at 19:55, David Nolen  wrote:

> I note that the Clojure version isn't being given 12gigs of RAM, is this 
> something you're giving to the JVM after when you run a AOTed version of the 
> Clojure code.

Yeah - I have tried giving it more RAM without any effect on the timing 
whatsoever. And I couldn't see the point of stopping people with less RAM than 
that from being able to run it :-)

> You also haven't said whether the timings for the smaller problems are 
> significantly different between Scala and Clojure.

They both run in less than a second in both Clojure and Scala, so no 
significant difference.

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: p...@paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher

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

[Alex Baranosky]

Well said Niels.

As far as performance optimization. Imo that's premature until you profile.


On Tue, Oct 22, 2013 at 2:42 AM, Niels van Klaveren <
niels.vanklave...@gmail.com> wrote:

> I can imagine this behavior. Unlike premature performance optimization,
> readability / terseness are well worth optimizing for when learning
> Clojure, as long as you value readability over terseness to keep well away
> from code golf territory.
>
> With Clojure, I always have the idea that things could be done in a
> simpler way, and usually it can. A lot of what I consider 'draft' code that
> works can be cleaned up drastically, and sometimes after cleaning I still
> have some niggles.  However, with time my 'draft' code tends to get cleaner
> and cleaner, and I also see up front where algorithms and function input /
> output can be changed to prevent code getting needlessly complex, and
> having to handle more exceptions than rules.
>
> While doing 4clojure problems, some of my first attempts were 4 or 5
> lines. While this is considered next nothing in Javaland, getting them down
> to 1 line, and comparing them to some of the Clojure vets you get a good
> feel for what's the idiomatic Clojure way to solve certain problems. So I
> guess it's all part of the learning process. I would not worry about it too
> much, you can only clean up for readability / terseness up to a point.
>
> Be sure to stay away from performance optimization unless absolutely
> necessary. There's way too many options, and it needs a really good insight
> into Clojure's implementation details to do effectively. Most idiomatic
> Clojure code performs on par or better compared to other dynamic languages
> like Python and Ruby.
>
>
> On Saturday, October 19, 2013 1:20:33 AM UTC+2, queshaw wrote:
>>
>> With clojure in particular, I am having trouble not rearranging my code
>> to be what I think is more optimal in ways that seem probably not
>> practical. I've noticed myself doing that when I'm newish to languages
>> and apis. But, I go bonkers with clojure.
>>
>> Do you have any thoughts about how to avoid that, other than Bob
>> Newhart's advice:
>>
>> http://www.youtube.com/watch?**v=Ow0lr63y4Mw
>>
>> Kendall
>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and 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: Request for help optimising a Clojure program

[David Nolen]

On Tue, Oct 22, 2013 at 3:11 PM, Paul Butcher  wrote:

> Yeah - I have tried giving it more RAM without any effect on the timing
> whatsoever. And I couldn't see the point of stopping people with less RAM
> than that from being able to run it :-)
>

But without enough RAM most JVMs will thrash in GC when running that code.

Saying both run in less than a second is not particularly informative for
the small problems :) Does Scala take 4ms and Clojure takes 400ms on the
small problems? That's a big difference.

David

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

[Sean Corfield]

It sounds like you're running into the chunked sequence behavior of
map (it's lazy but it realizes chunks of the sequence for efficiency
rather than strictly on-demand).

I'd say the possibilities are: don't use side-effecting functions in
your monads or define a fully lazy version of map and define m-plus in
terms of that?

Sean

On Tue, Oct 22, 2013 at 4:23 AM, Mark Fisher  wrote:
> I originally posted this in Stack Overflow, but realised I might get more
> response from the google group. Apologies for duplication.
>
> I'm seeing some issues using a parser monad created from the state monad
> transformer.
>
> I've written a full test case on the SO page outlining the issue, which is
> that when I use m-plus for the combined monad, it always evaluates the first
> 2 methods, even though it uses the return values from the first (if it is
> valid), and any state changes in the second occur but are discarded (however
> side effects do - like d/b updates etc).
>
> e.g.
>
> (def parser-m (state-t maybe-m))
> (def world-destroyer
>   (domonad parser-m
>[_ (fetch-state)
> result (m-plus
> (check-we-are-chilled)
> (destroy-planet))]
>result))
> (world-destroyer {:chill-out true})
>
> In this implementation, destroy-planet is always evaluated.
> Both of these monadic functions can terminate by using a :when condition on
> the state.
>
> If I add a dummy method to the m-plus call list at the start (as first or as
> second method in list) that does nothing (using a :when nil predicate to
> stop its evaluation), the results are fine, no planet is destroyed because
> it's never called, and the dummy monadic function takes the hit of stopping
> m-plus spilling into the destroy-planet function.
>
> Interestingly, any state changes I make in the method erroneously called do
> not get reflected in the final return value (clearly due to immutability of
> the state map), but side effects are happening - and that's my issue.
>
> I've reverted to using a hand-crafted parser-m as given on Jim Duey's monad
> blog which doesn't exhibit this behaviour.
>
> I'm relatively inexperienced with clojure and monads (I was using this as an
> excuse to learn them both), so I thought i'd try and work out why it's
> happening.
>
> From looking at the definitions of state-t monad-m, the only thing i can see
> m-plus doing different to Jim's version is:
>
> state-t monad-m:
> (defn x [s]
>   (apply (fn [& xs]
>(first (drop-while nil? xs)))
>  (map #(% s) flist)))
>
> jim's:
> (defn y [s]
>   (first (drop-while nil?
>  (map #(% s) flist
>
> for some list of functions flist, e.g.
> (def flist
>   [(fn [x]
>  (println "f a : " x)
>  (when-let [r (:a x)] r))
>(fn [x]
>  (println "f b: "x)
>  (when-let [r (:b x)] r))
>(fn [x]
>  (println "f nil : " x)
>  nil)])
>
> (x {:b 2})
> (y {:b 2})
>
> and running either of these produces same result (2), however they both
> produce the println side effects of all 3 functions in the list, so now i'm
> even more confused.
>
> I thought everything in y is lazy, so only the first two methods would be
> used from the array. I can't find anything saying apply is lazy, so thought
> I was getting closer.
>
> Anyone have any thoughts on this? Am I using m-plus in the right way inside
> a domonad call?
>
> Cheers,
> Mark
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

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

Re: Compulsive over-optimization

[Kendall Shaw]

Optimizing too much for readability, can't be well worth doing, I think. 
It's a contradiction in terms. Watching out for changes that make the 
code shorter instead of more readable seems like useful advice and maybe 
a sign that I am "optimizing" too much. I'm pretty sure I could figure 
out a way to waste time making something insignificantly more readable.


I don't have much of a problem with the abstract idea that good is 
better than bad. I have a problem with degrees of goodness. I doubt that 
there is a formula to guard against that, but advice like comparing 
readability vs.l terseness is what I was looking for.


Kendall

On 10/22/2013 02:42 AM, Niels van Klaveren wrote:
I can imagine this behavior. Unlike premature performance 
optimization, readability / terseness are well worth optimizing for 
when learning Clojure, as long as you value readability over terseness 
to keep well away from code golf territory.


With Clojure, I always have the idea that things could be done in a 
simpler way, and usually it can. A lot of what I consider 'draft' code 
that works can be cleaned up drastically, and sometimes after cleaning 
I still have some niggles.  However, with time my 'draft' code tends 
to get cleaner and cleaner, and I also see up front where algorithms 
and function input / output can be changed to prevent code getting 
needlessly complex, and having to handle more exceptions than rules.


While doing 4clojure problems, some of my first attempts were 4 or 5  
lines. While this is considered next nothing in Javaland, getting them 
down to 1 line, and comparing them to some of the Clojure vets you get 
a good feel for what's the idiomatic Clojure way to solve certain 
problems. So I guess it's all part of the learning process. I would 
not worry about it too much, you can only clean up for readability / 
terseness up to a point.


Be sure to stay away from performance optimization unless absolutely 
necessary. There's way too many options, and it needs a really good 
insight into Clojure's implementation details to do effectively. Most 
idiomatic Clojure code performs on par or better compared to other 
dynamic languages like Python and Ruby.


On Saturday, October 19, 2013 1:20:33 AM UTC+2, queshaw wrote:

With clojure in particular, I am having trouble not rearranging my
code
to be what I think is more optimal in ways that seem probably not
practical. I've noticed myself doing that when I'm newish to
languages
and apis. But, I go bonkers with clojure.

Do you have any thoughts about how to avoid that, other than Bob
Newhart's advice:

http://www.youtube.com/watch?v=Ow0lr63y4Mw


Kendall

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

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

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



--
ThisIsHardToRead, asIsThis. This_is_easier, unless_it_is_underlined. 
This.is.easy. This-is-easy-too. Almost as easy to read as this.

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

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

Re: problems with state-t monad transformer

[Mark Fisher]

It's difficult to see how it's a chunked issue, the original code is just 
calling monadic functions, the only map is the state (the latter part of my 
post was an attempt to manually recreate what the monad macros are doing 
and I'm sure i didn't do a perfect job of it).

It's my understanding that the contract of m-plus is to return the results 
from the first function that returns non-nil. e.g. from 
http://onclojure.com/2009/03/23/a-monad-tutorial-for-clojure-programmers-part-3/
 
by Konrad Hinsen:

"m-plus is a function that combines the results of two or more computations 
into a single one. For the sequence monad, it is the concatenation of 
several sequences. For the maybe monad, it is a function that returns the 
first of its arguments that is not nil."

By which I wouldn't expect it to call the second function if the first was 
non-nil.

Also, in Jim Duey's 
http://www.intensivesystems.net/tutorials/monads_101.html, he says it 
similarly:

"Taking advantage of the fact that first, drop-while and map are all lazy, 
m-plus applies only as many parsers as it needs to in order to get a 
result. If no parsers succeed, a nil is returned."

I've reverted to using the parser definition in the last link, as it's all 
I need for now. I'd be wary of using the "state-t maybe-m" monad though in 
future as it doesn't seem to be working as i'd expect.

Mark

On Tuesday, 22 October 2013 20:26:44 UTC+1, Sean Corfield wrote:
>
> It sounds like you're running into the chunked sequence behavior of 
> map (it's lazy but it realizes chunks of the sequence for efficiency 
> rather than strictly on-demand). 
>
> I'd say the possibilities are: don't use side-effecting functions in 
> your monads or define a fully lazy version of map and define m-plus in 
> terms of that? 
>
> Sean 
>
> On Tue, Oct 22, 2013 at 4:23 AM, Mark Fisher 
> > 
> wrote: 
> > I originally posted this in Stack Overflow, but realised I might get 
> more 
> > response from the google group. Apologies for duplication. 
> > 
> > I'm seeing some issues using a parser monad created from the state monad 
> > transformer. 
> > 
> > I've written a full test case on the SO page outlining the issue, which 
> is 
> > that when I use m-plus for the combined monad, it always evaluates the 
> first 
> > 2 methods, even though it uses the return values from the first (if it 
> is 
> > valid), and any state changes in the second occur but are discarded 
> (however 
> > side effects do - like d/b updates etc). 
> > 
> > e.g. 
> > 
> > (def parser-m (state-t maybe-m)) 
> > (def world-destroyer 
> >   (domonad parser-m 
> >[_ (fetch-state) 
> > result (m-plus 
> > (check-we-are-chilled) 
> > (destroy-planet))] 
> >result)) 
> > (world-destroyer {:chill-out true}) 
> > 
> > In this implementation, destroy-planet is always evaluated. 
> > Both of these monadic functions can terminate by using a :when condition 
> on 
> > the state. 
> > 
> > If I add a dummy method to the m-plus call list at the start (as first 
> or as 
> > second method in list) that does nothing (using a :when nil predicate to 
> > stop its evaluation), the results are fine, no planet is destroyed 
> because 
> > it's never called, and the dummy monadic function takes the hit of 
> stopping 
> > m-plus spilling into the destroy-planet function. 
> > 
> > Interestingly, any state changes I make in the method erroneously called 
> do 
> > not get reflected in the final return value (clearly due to immutability 
> of 
> > the state map), but side effects are happening - and that's my issue. 
> > 
> > I've reverted to using a hand-crafted parser-m as given on Jim Duey's 
> monad 
> > blog which doesn't exhibit this behaviour. 
> > 
> > I'm relatively inexperienced with clojure and monads (I was using this 
> as an 
> > excuse to learn them both), so I thought i'd try and work out why it's 
> > happening. 
> > 
> > From looking at the definitions of state-t monad-m, the only thing i can 
> see 
> > m-plus doing different to Jim's version is: 
> > 
> > state-t monad-m: 
> > (defn x [s] 
> >   (apply (fn [& xs] 
> >(first (drop-while nil? xs))) 
> >  (map #(% s) flist))) 
> > 
> > jim's: 
> > (defn y [s] 
> >   (first (drop-while nil? 
> >  (map #(% s) flist 
> > 
> > for some list of functions flist, e.g. 
> > (def flist 
> >   [(fn [x] 
> >  (println "f a : " x) 
> >  (when-let [r (:a x)] r)) 
> >(fn [x] 
> >  (println "f b: "x) 
> >  (when-let [r (:b x)] r)) 
> >(fn [x] 
> >  (println "f nil : " x) 
> >  nil)]) 
> > 
> > (x {:b 2}) 
> > (y {:b 2}) 
> > 
> > and running either of these produces same result (2), however they both 
> > produce the println side effects of all 3 functions in the list, so now 
> i'm 
> > even more confused. 
> > 
> > I thought everything in y is lazy, so only the first two methods would 
> be 
> > used from the array. I can't f

Remote Clojure job opportunities

[givenbygod]

Hello!

Sorry for bringing this topic once again, but after delving into functional 
programming and Clojure in particular I really want to try to use it for 
something bigger than just small scripts and test programs.
Hence the question - are there any open Clojure developer positions for 
which a remote work is possible? I'll provide my CV on a request.

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.

Overwrite equals in defrecord

[Marc Dzaebel]

(defrecord R [x y]) automatically defines a reasonable *equals* method 
using x & y. However, is it possible to overwrite the method as it should 
use X only? My tries resulted in *"Duplicate method name&signature in class 
...". Do I have to use extend-type?*

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

[Ben Wolfson]

based on what you posted to stack overflow I would guess it's because the
side-effects (the prints) are coming too soon---you have a println as the
first line of check-k-v, so if the expression (mplus (check-k-v ...)
(check-k-v ...)) is evaluated, then, given that mplus is not a macro, both
arguments will be evaluated, and both prints will happen.

Since the state modifications aren't both happening, I assume that the
actual computation returned---the domonad block---is being correctly
treated.


On Tue, Oct 22, 2013 at 4:23 AM, Mark Fisher wrote:

> I originally posted this in Stack 
> Overflow,
> but realised I might get more response from the google group. Apologies for
> duplication.
>
> I'm seeing some issues using a parser monad created from the state monad
> transformer.
>
> I've written a full test case on the SO page outlining the issue, which is
> that when I use m-plus for the combined monad, it always evaluates the
> first 2 methods, even though it uses the return values from the first (if
> it is valid), and any state changes in the second occur but are discarded
> (however side effects do - like d/b updates etc).
>
> e.g.
>
> (def parser-m (state-t maybe-m))
> (def world-destroyer
>   (domonad parser-m
>[_ (fetch-state)
> result (m-plus
> (check-we-are-chilled)
> (destroy-planet))]
>result))
> (world-destroyer {:chill-out true})
>
> In this implementation, destroy-planet is always evaluated.
> Both of these monadic functions can terminate by using a :when condition
> on the state.
>
> If I add a dummy method to the m-plus call list at the start (as first or
> as second method in list) that does nothing (using a :when nil predicate to
> stop its evaluation), the results are fine, no planet is destroyed because
> it's never called, and the dummy monadic function takes the hit of stopping
> m-plus spilling into the destroy-planet function.
>
> Interestingly, any state changes I make in the method erroneously called
> do not get reflected in the final return value (clearly due to immutability
> of the state map), but side effects are happening - and that's my issue.
>
> I've reverted to using a hand-crafted parser-m as given on Jim Duey's
> monad blog  which
> doesn't exhibit this behaviour.
>
> I'm relatively inexperienced with clojure and monads (I was using this as
> an excuse to learn them both), so I thought i'd try and work out why it's
> happening.
>
> From looking at the definitions of state-t monad-m, the only thing i can
> see m-plus doing different to Jim's version is:
>
> state-t monad-m:
> (defn x [s]
>   (apply (fn [& xs]
>(first (drop-while nil? xs)))
>  (map #(% s) flist)))
>
> jim's:
> (defn y [s]
>   (first (drop-while nil?
>  (map #(% s) flist
>
> for some list of functions flist, e.g.
> (def flist
>   [(fn [x]
>  (println "f a : " x)
>  (when-let [r (:a x)] r))
>(fn [x]
>  (println "f b: "x)
>  (when-let [r (:b x)] r))
>(fn [x]
>  (println "f nil : " x)
>  nil)])
>
> (x {:b 2})
> (y {:b 2})
>
> and running either of these produces same result (2), however they both
> produce the println side effects of *all 3* functions in the list, so now
> i'm even more confused.
>
> I thought everything in y is lazy, so only the first two methods would be
> used from the array. I can't find anything saying apply is lazy, so thought
> I was getting closer.
>
> Anyone have any thoughts on this? Am I using m-plus in the right way
> inside a domonad call?
>
> Cheers,
> Mark
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure."
[Larousse, "Drink" entry]

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - pl

Re: Overwrite equals in defrecord

[Marc Dzaebel]

http://cmayes.wikispaces.com/PracticalClojure13: ...

> defrecord does not support Java class inheritance, so it cannot override 
> methods of Java classes, even abstract classes. However, it does permit you 
> to override methods of java.lang.Object such as hashCode, equals, and 
> toString. Simply include java.lang.Object in the defrecord as if it were an 
> interface. Clojure will generate good value-based implementations of the 
> hashCode and equals methods, so it is rarely necessary to implement them 
> yourself.
>

(defrecord R [x y] java.lang.Object (equals [_ r](= x(.x r
--> Duplicate method name&signature in class file

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

[Mark Fisher]

The state modifications are both happening, if i inspect it after the 2nd 
function does an update the change is there, but the wind out of the return 
value from the first function is a different object, and immutability is 
giving me it before the 2nd update, which is a discarded object.

I am seeing the cache get read (fn 1 - returns a value), and then 
immediately the live fetch (fn 2) which should only happen if the cache hit 
failed (fn 1).
If I put a filler monad function at the front of the queue, then this 
doesn't happen.

So:

(m-plus filler mfn1 mfn2)
works, as in, mfn2 does *not* get called if mfn1 returns a value.

but
(m-plus mfn1 mfn2) does call both functions.

and all the filler function does is:

(def filler
  (domonad parser-m
[:when nil]
   nil))

If I go with Jim Duey's version of the parser monad (which is hand written 
and not created through the state-t transform), then I don't need the 
filler function at all, (m-plus mfn1 mfn2) works as expected - when mfn1 
returns a value, mfn2 is not called. This is all with or without debug, i 
can swap the 2 in and out for each other easily and the problem happens in 
the transform case, not in hand-crafted case, with no other changes than 
changing the definition of the parser-m.

I think there's a subtle flaw in resultant tranformed monad of (state-t 
maybe-m) but my clojure-foo is lacking in working out exactly what. I do 
believe it's supposed to work as I'm trying to use it

Mark


On Tuesday, 22 October 2013 22:35:59 UTC+1, Ben wrote:
>
> based on what you posted to stack overflow I would guess it's because the 
> side-effects (the prints) are coming too soon---you have a println as the 
> first line of check-k-v, so if the expression (mplus (check-k-v ...) 
> (check-k-v ...)) is evaluated, then, given that mplus is not a macro, both 
> arguments will be evaluated, and both prints will happen.
>
> Since the state modifications aren't both happening, I assume that the 
> actual computation returned---the domonad block---is being correctly 
> treated.
>
>
> On Tue, Oct 22, 2013 at 4:23 AM, Mark Fisher 
> > wrote:
>
>> I originally posted this in Stack 
>> Overflow,
>>  
>> but realised I might get more response from the google group. Apologies for 
>> duplication.
>>
>> I'm seeing some issues using a parser monad created from the state monad 
>> transformer.
>>
>> I've written a full test case on the SO page outlining the issue, which 
>> is that when I use m-plus for the combined monad, it always evaluates the 
>> first 2 methods, even though it uses the return values from the first (if 
>> it is valid), and any state changes in the second occur but are discarded 
>> (however side effects do - like d/b updates etc).
>>
>> e.g.
>>
>> (def parser-m (state-t maybe-m))
>> (def world-destroyer
>>   (domonad parser-m
>>[_ (fetch-state)
>> result (m-plus
>> (check-we-are-chilled)
>> (destroy-planet))]
>>result))
>> (world-destroyer {:chill-out true})
>>
>> In this implementation, destroy-planet is always evaluated.
>> Both of these monadic functions can terminate by using a :when condition 
>> on the state.
>>
>> If I add a dummy method to the m-plus call list at the start (as first or 
>> as second method in list) that does nothing (using a :when nil predicate to 
>> stop its evaluation), the results are fine, no planet is destroyed because 
>> it's never called, and the dummy monadic function takes the hit of stopping 
>> m-plus spilling into the destroy-planet function.
>>
>> Interestingly, any state changes I make in the method erroneously called 
>> do not get reflected in the final return value (clearly due to immutability 
>> of the state map), but side effects are happening - and that's my issue.
>>
>> I've reverted to using a hand-crafted parser-m as given on Jim Duey's 
>> monad blog  which 
>> doesn't exhibit this behaviour.
>>
>> I'm relatively inexperienced with clojure and monads (I was using this as 
>> an excuse to learn them both), so I thought i'd try and work out why it's 
>> happening.
>>
>> From looking at the definitions of state-t monad-m, the only thing i can 
>> see m-plus doing different to Jim's version is:
>>
>> state-t monad-m:
>> (defn x [s]
>>   (apply (fn [& xs]
>>(first (drop-while nil? xs)))
>>  (map #(% s) flist)))
>>
>> jim's:
>> (defn y [s]
>>   (first (drop-while nil?
>>  (map #(% s) flist
>>
>> for some list of functions flist, e.g.
>> (def flist
>>   [(fn [x]
>>  (println "f a : " x)
>>  (when-let [r (:a x)] r))
>>(fn [x]
>>  (println "f b: "x)
>>  (when-let [r (:b x)] r))
>>(fn [x]
>>  (println "f nil : " x)
>>  nil)])
>>
>> (x {:b 2})
>> (y {:b 2})
>>
>> and running eit

Re: Overwrite equals in defrecord

[Jim - FooBar();]

use deftype which is more low-level and I think doesn't define equals or 
put y in meta data that don't participate in equality...:)


Jim


On 22/10/13 22:44, Marc Dzaebel wrote:

http://cmayes.wikispaces.com/PracticalClojure13: ...

defrecord does not support Java class inheritance, so it cannot
override methods of Java classes, even abstract classes. However,
it does permit you to override methods of java.lang.Object such as
hashCode, equals, and toString. Simply include java.lang.Object in
the defrecord as if it were an interface. Clojure will generate
good value-based implementations of the hashCode and equals
methods, so it is rarely necessary to implement them yourself.


(defrecord R [x y] java.lang.Object (equals [_ r](= x(.x r
--> Duplicate method name&signature in class file
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

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

structuring a db load, back pressure

[Brian Craft]

I'm doing a load to db, which looks roughly like "read, transform, insert, 
repeat".

Blocking on the inserts leaves the cores sitting cold while they could be 
doing the next read/transform. It's tempting to try an agent for the 
inserts. If I understand them correctly, that would queue the inserts as 
they are ready, allowing the read/transform to continue. I'm concerned that 
this would just fill memory, as the inserts can't keep up with the reads.

Is there some other obvious way to structure this? The only relevant hits 
I've found on this list are about the async lib, which I gather can handle 
this by keeping a bounded queue that can block the producer. I was hoping 
to put off learning the async stuff until later. ;)

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

apps uploaded using lein-beanstalk don't show up in amazon beanstalk management console.

[Romeo Van Snick]

Hi,

I'm pretty new to clojure webdev as well as amazon aws but I'm trying to 
build
a small vanilla web app using lein-beanstalk to deploy the app without 
having 
to know the gritty details of aws-hosting.

I'm getting along with lein-beanstalk since I can succesfully upload and 
use the webapp
but I have one thing thats strikes me as quirky.

The webapp only shows up in the amazon S3 management console, and not in the
Elastic Beanstalk console.

So i can only find a bunch of war files in S3, wich I cannot manipulate or 
configurate
using the management console.

What's up with this? Could someone enlighten me as in how this works (where 
do these war files get executed for example, and do they enjoy 
load-balancing,
CDN etc.?)

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

[Alex Miller]

I'd love to see a stack trace when that happens (could even be triggered by 
dumping stack in your static initializer if nothing else).

On Saturday, October 12, 2013 3:17:50 AM UTC-5, Wujek Srujek wrote:
>
> So you are saying compilation is trying to instantiate class and run 
> static initializers? This seems very backward, are you sure?
>
>
> On Sat, Oct 12, 2013 at 8:30 AM, Zach Oakes 
> > wrote:
>
>> I should add, I am aware I can bring in a class dynamically with 
>> Class/forName, and that is what I ended up doing for the Timer class. 
>> However, this is not always practical, and sometimes is simply not an 
>> option if aot-compilation is required.
>>
>>
>> On Saturday, October 12, 2013 2:28:38 AM UTC-4, Zach Oakes wrote:
>>>
>>> I recently learned that merely importing a Java class in Clojure causes 
>>> static initializers to be run. Sometimes, this causes compilation errors, 
>>> because they are written with the assumption that they will only be run 
>>> during runtime.
>>>
>>> I ran into this just now while trying to make a simple Clojure game with 
>>> LibGDX. After simply importing its Timer class, I began getting compilation 
>>> errors. The stack trace shows it is due to a static 
>>> initializerattempting
>>>  to instantiate the class!
>>>
>>> I also ran into this recently while trying to use RoboVM. My question 
>>> is, do I have any options? I haven't found many discussions about this here 
>>> or elsewhere. This surprises me, because it seems like something more 
>>> people should be running into.
>>>
>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

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

[Zach Oakes]

Here's the error I get when I import LibGDX's Timer class:

http://pastebin.com/q7wys8yi

On Tuesday, October 22, 2013 9:55:16 PM UTC-4, Alex Miller wrote:
>
> I'd love to see a stack trace when that happens (could even be triggered 
> by dumping stack in your static initializer if nothing else).
>
> On Saturday, October 12, 2013 3:17:50 AM UTC-5, Wujek Srujek wrote:
>>
>> So you are saying compilation is trying to instantiate class and run 
>> static initializers? This seems very backward, are you sure?
>>
>>
>> On Sat, Oct 12, 2013 at 8:30 AM, Zach Oakes  wrote:
>>
>>> I should add, I am aware I can bring in a class dynamically with 
>>> Class/forName, and that is what I ended up doing for the Timer class. 
>>> However, this is not always practical, and sometimes is simply not an 
>>> option if aot-compilation is required.
>>>
>>>
>>> On Saturday, October 12, 2013 2:28:38 AM UTC-4, Zach Oakes wrote:

 I recently learned that merely importing a Java class in Clojure causes 
 static initializers to be run. Sometimes, this causes compilation errors, 
 because they are written with the assumption that they will only be run 
 during runtime.

 I ran into this just now while trying to make a simple Clojure game 
 with LibGDX. After simply importing its Timer class, I began getting 
 compilation errors. The stack trace shows it is due to a static 
 initializerattempting
  to instantiate the class!

 I also ran into this recently while trying to use RoboVM. My question 
 is, do I have any options? I haven't found many discussions about this 
 here 
 or elsewhere. This surprises me, because it seems like something more 
 people should be running into.

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

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

[Shantanu Kumar]

Hi Brian,

On Wednesday, 23 October 2013 05:33:30 UTC+5:30, Brian Craft wrote:
>
> I'm doing a load to db, which looks roughly like "read, transform, insert, 
> repeat".
>
> Blocking on the inserts leaves the cores sitting cold while they could be 
> doing the next read/transform. It's tempting to try an agent for the 
> inserts. If I understand them correctly, that would queue the inserts as 
> they are ready, allowing the read/transform to continue. I'm concerned that 
> this would just fill memory, as the inserts can't keep up with the reads.
>

Since the inserts are for the same kind of data, one idea could be to use 
ArrayBlockingQueue or LinkedBlockingQueue to queue the inserts and another 
thread (possibly a future and optionally an agent) could retrieve this data 
to insert to the database. Batching the inserts (with right batch size) may 
be faster than individual inserts. The thread that reads from the DB can 
track the level of the insert queue and pause to avoid over-feeding.

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.

[JOB] Clojure Job Posting

[Michael Lim]

Hi, 

We are a  Singapore-based company that specializing social media analytics 
and insights, and we are looking to hire people for the role of system 
engineer, ideally someone who knows Clojure. 

Systems Engineer 
=== 
- 2+ years software development experience 
- Knowledge of Java, Python, Clojure, Ruby, or any functional languages 
- Knowledge of machine learning, data analysis techniques or Hadoop will be 
a plus 
- Candidates who possess knowledge of functional languages will be looked 
upon favourably 

We are looking for a systems engineer to help develop and advance our 
cutting edge social analytics backend. 

If you live and breathe backend systems, are passionate about working with 
Big Data or machine learning algorithms, and excel in an agile open 
environment, JamiQ may be for you. This job would ideally be on-site, but 
remote working is also a possibility. 

Please email me at michael.lim [at] jamiq.com if you are interested.

Thanks,
Michael

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

[Jonah Benton]

I tend to think of pull operations in these situations. So perhaps wrap a
lazy sequence around a chunked form of the read + transform operation,
perhaps parallelizing the transform, and do the insert in a doseq on the
lazy sequence?




On Tue, Oct 22, 2013 at 8:03 PM, Brian Craft  wrote:

> I'm doing a load to db, which looks roughly like "read, transform, insert,
> repeat".
>
> Blocking on the inserts leaves the cores sitting cold while they could be
> doing the next read/transform. It's tempting to try an agent for the
> inserts. If I understand them correctly, that would queue the inserts as
> they are ready, allowing the read/transform to continue. I'm concerned that
> this would just fill memory, as the inserts can't keep up with the reads.
>
> Is there some other obvious way to structure this? The only relevant hits
> I've found on this list are about the async lib, which I gather can handle
> this by keeping a bounded queue that can block the producer. I was hoping
> to put off learning the async stuff until later. ;)
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and 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] clojure.data.priority-map 0.0.3

[Mark Engelberg]

https://github.com/clojure/data.priority-map/

A priority map is similar to a sorted map, but sorts the entries by the
values rather than the keys in the map.  Think of it as a kind of priority
queue with a full map-like API to query, add, adjust, and remove items and
their priorities.

The new 0.0.3 version addresses a common need where the items map to
complex values which contain the priority, or from which the priority can
be derived.
For example, consider a map:
{:apple {:weight 2, :color :red}, :orange {:weight 2, color :orange},
:banana {:weight 3, color :yellow}}
where you want to sort the map by the fruit's weight.

A common pitfall was to try to solve this with a custom comparator which
compares only on weight.  This doesn't work properly because of the
Clojure/Java rule that valid comparators must be "total orders".  Among
other things, this means the comparator can't have "ties" between unequal
objects (known as the trichotomy property).

[See https://groups.google.com/forum/#!msg/clojure/VKvH_eg_FtE/Kpy18zGtio4Jfor
one such discussion about this pitfall]

Users were instructed to rework their comparator into a total order, but
for some use cases, this can be a tricky proposition.

To address this need, the new version allows one to specify a "keyfn" which
extracts or computes the sort keys (i.e., priority) from the map's values.

This is done with one of two new constructors:
priority-map-keyfn (takes a custom keyfn)
priority-map-keyfn-by (takes a custom keyfn and custom comparator)

So for example, the above map could be expressed as:
(priority-map-keyfn :weight
  :apple {:weight 2, :color :red}, :orange {:weight 2, color :orange},
  :banana {:weight 3, color :yellow})

See the README for further explanation, and let me know if you have any
questions.

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