Re: Cross platform date/time libarary

[Sean Corfield]

On 4/3/16, 7:36 PM, "JvJ"  wrote:
> Is there a date/time library that is written for both clojure and 
> clojurescript?

Probably the closest thing is this pair of libraries:

https://github.com/clj-time/clj-time

https://github.com/andrewmcveigh/cljs-time

Same API, different implementations.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood






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

Re: Core.async performance with many channels

[Rangel Spasov]

Without knowing too much about the internals, but having used 
core.async/channels a lot, I don't think "hundreds" of channels will be a 
problem ever. However, as always the devil is in the details. People might 
be able to give better feedback if you give more details about your use 
case. 

On Saturday, April 2, 2016 at 7:59:50 PM UTC-7, JvJ wrote:
>
>
> Lately, I've been working on a game in Clojure, and I've been trying out 
> various ways of modelling the game state and objects.
>
> One of these ideas is to give each object its own channel and make a fully 
> asynchronous architecture.
>
> I would like to know if having potentially hundreds of channels operating 
> at once would be a significant performance issue.
>
> Thanks.
>

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

Cross platform date/time libarary

[JvJ]

Is there a date/time library that is written for both clojure and 
clojurescript?

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

Re: ClojureScript def, vars, and binding

[whitespace]

Any chance that this could be supported now core.async is here? I think the 
arguments of brandon bloom are still valid. I have implemented Erlang-like 
supervisors for core.async and now got stuck in the last step when I 
realized that the supervisor binding is broken in cljs. (1) I can pass 
explicit arguments everywhere as a work-around, but this is not necessary 
on the JVM and makes the error-handling a lot less seamless. A binding fits 
nice for supervision. core.async would need to be extended as well, but I 
would be willing to put the effort in, if the approach is acceptable.

Cheers,
Christian

(1) 
https://github.com/whilo/full.monty/blob/master/full.async/src/full/lab.cljc#L74

Am Montag, 14. Januar 2013 13:29:10 UTC+1 schrieb David Nolen:
>
> There is not.
>
> On Monday, January 14, 2013, Stuart Campbell wrote:
>
>> Sorry to dig up such an old thread.
>>
>> I'd also like to maintain the bindings of dynamic vars across 
>> asynchronous function calls.
>>
>> Is there a workaround that people use in the absence of bound-fn, etc?
>>
>> Cheers,
>> Stuart
>>
>> On Friday, 27 January 2012 16:49:10 UTC+11, Brandon Bloom wrote:
>>>
>>> The ClojureScript wiki 
>>>  
>>> states that "the user experience of [binding] is similar to that in 
>>> Clojure" but my very first experiment produced wildly different results 
>>> between platforms.
>>>
>>> Here's a Clojure on the JVM session:
>>>
>>> user=> (import java.lang.Thread)
>>> java.lang.Thread
>>> user=> (defn set-timeout [ms fn] (.run (Thread. #(do (Thread/sleep ms) 
>>> (fn)
>>> #'user/set-timeout
>>> user=> (def x "top level")
>>> #'user/x
>>> user=> (binding [x "in binding"] (println x) (set-timeout 1000 #(println 
>>> x)))
>>> in binding
>>> in binding
>>> nil
>>>
>>> And here's the analogous ClojureScript session:
>>>
>>> ClojureScript:cljs.user> (def x "top level")
>>> "top level"
>>> ClojureScript:cljs.user> (binding [x "in binding"] (println x) 
>>> (js/setTimeout #(println x) 1000))
>>> in binding
>>> 21
>>> top level
>>>
>>> So ignoring the sequencing and nil vs timeout-id return values, the 
>>> binding of 'x wasn't preserved in the asynchronous callback.
>>>
>>> I raised this issue in #clojure and @dnolen said that "that's the 
>>> behavior there's nothing much to fix", but that didn't sit right with me. 
>>> This seems like either 'binding is bugged, or maybe I don't understand 
>>> something about its intent.
>>>
>>> On the topic of "Vars" proper, I understand their usefulness in 
>>> repl-centric development, where you can redefine functions at runtime. The 
>>> wiki also makes some mention of this, but I can't wrap my head around the 
>>> context and jargon. I've run into this problem before in Javascript, where 
>>> some level of indirection is necessary to support run-time redefinitions. 
>>> You can't do `var fn = package.fn;` and dynamically redefine `fn` from 
>>> `package` later because a copy of the reference is made. How does 
>>> ClojureScript address this problem?
>>>
>>> Cheers,
>>> Brandon
>>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
>

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

Re: [ANN] Aleph 0.4.1

[Zach Tellman]

Hi Adrian,

Glad to hear that you're getting good use out of Aleph.  As for the UDP
side of things, if you're using it (as games often do) to reimplement half
of TCP, that may not work well with the functional operators in
manifold.stream.  However, using `put!`, `take!`, and a few operators from
manifold.deferred like `chain` and `loop`, you should be able to easily
build any arbitrary call and response logic you need.  The code you write
will end up being pretty imperative, but sometimes that's just the best way
to reason about your problem.

I'm not sure I'll have time to look at the spec you linked anytime soon,
but I think it's reasonable to have some UDP-related code in the literate
examples.  I'll think about what would be a decent use case.

Best,
Zach

On Sun, Apr 3, 2016 at 12:52 PM  wrote:

> Awesome! At Vital Labs we use Aleph in production for our HTTP and (soon
> to be) websocket services. I have nothing but good things to say about it.
> It makes using Netty a breeze in Clojure.
>
> For an unrelated side project, I have been using Aleph to communicate over
> UDP with an old MMORPG called Star Wars Galaxies. Since UDP is not stream
> oriented, some of the architecture which make Aleph easy to reason about
> through Manifold for HTTP/TCP do not seem to carry over as cleanly when
> dealing with UDP services.
>
> Would you be open to writing a comprehensive UDP example for Aleph so that
> potential users could see how the author intends such services to be
> written in tandem with your other libraries, namely Manifold, Gloss, and
> byte-streams?
>
> In particular, SWG uses a convoluted protocol which involves optional XOR
> decryption of the body using an integer exchanged in the first packet you
> see from the game client (and saved for all future communication with the
> client until they go link dead), followed by optional decompression with
> DEFLATE of the body (not the header nor footer) depending on a value in the
> decrypted first byte of the footer, followed by variable-length (opcode
> driven) body decoding. To deal with the problem of unreliable transmission,
> you also need to ack sequenced packets before responding to a specific kind
> of message. Sometimes this needs to be repeated due to loss, etc. To
> respond you also need to invert the decoding process, so compress ->
> encrypt -> etc.
>
> Here's an overview of the protocol if you're interested in seeing the
> potential complexities that come up with protocols like these:
> http://wiki.swganh.org/index.php/Packet_Guides
>
> Since many of these requirements break the more functional, streaming
> nature of Manifold's design I have found that the code quickly devolves
> into madness. I imagine it would be very enlightening to see how you would
> solve these or similar problems with Aleph.
>
> Thanks for the great library,
> Adrian
>
> On Sunday, April 3, 2016 at 2:44:53 AM UTC-4, Zach Tellman wrote:
>>
>> This release represents a number of incremental improvements to 0.4.0,
>> which has been handling billions of daily requests for close to a year.
>>
>> * Documentation can be found at http://aleph.io/
>> * Literate examples of usage can be found at
>> http://aleph.io/aleph/literate.html
>> * Comparative benchmarks can be found at
>> https://www.techempower.com/benchmarks/#section=data-r12=peak=plaintext=4,
>> which may or may not be relevant to your particular use case
>>
>> If anyone has questions, I'm happy to answer them.
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/cNRTnvlPVG4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Aleph 0.4.1

[adrian . medina]

Awesome! At Vital Labs we use Aleph in production for our HTTP and (soon to 
be) websocket services. I have nothing but good things to say about it. It 
makes using Netty a breeze in Clojure. 

For an unrelated side project, I have been using Aleph to communicate over 
UDP with an old MMORPG called Star Wars Galaxies. Since UDP is not stream 
oriented, some of the architecture which make Aleph easy to reason about 
through Manifold for HTTP/TCP do not seem to carry over as cleanly when 
dealing with UDP services. 

Would you be open to writing a comprehensive UDP example for Aleph so that 
potential users could see how the author intends such services to be 
written in tandem with your other libraries, namely Manifold, Gloss, and 
byte-streams? 

In particular, SWG uses a convoluted protocol which involves optional XOR 
decryption of the body using an integer exchanged in the first packet you 
see from the game client (and saved for all future communication with the 
client until they go link dead), followed by optional decompression with 
DEFLATE of the body (not the header nor footer) depending on a value in the 
decrypted first byte of the footer, followed by variable-length (opcode 
driven) body decoding. To deal with the problem of unreliable transmission, 
you also need to ack sequenced packets before responding to a specific kind 
of message. Sometimes this needs to be repeated due to loss, etc. To 
respond you also need to invert the decoding process, so compress -> 
encrypt -> etc. 

Here's an overview of the protocol if you're interested in seeing the 
potential complexities that come up with protocols like 
these: http://wiki.swganh.org/index.php/Packet_Guides

Since many of these requirements break the more functional, streaming 
nature of Manifold's design I have found that the code quickly devolves 
into madness. I imagine it would be very enlightening to see how you would 
solve these or similar problems with Aleph. 

Thanks for the great library,
Adrian

On Sunday, April 3, 2016 at 2:44:53 AM UTC-4, Zach Tellman wrote:
>
> This release represents a number of incremental improvements to 0.4.0, 
> which has been handling billions of daily requests for close to a year.  
>
> * Documentation can be found at http://aleph.io/
> * Literate examples of usage can be found at 
> http://aleph.io/aleph/literate.html
> * Comparative benchmarks can be found at 
> https://www.techempower.com/benchmarks/#section=data-r12=peak=plaintext=4,
>  
> which may or may not be relevant to your particular use case
>
> If anyone has questions, I'm happy to answer them.
>

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

Re: [ANN] [book] Mastering Clojure published!

[Timothy Baldridge]

gvim, aside from the rather poor taste of critiquing a book's pricing in
the second reply to the announcement of that book. Perhaps also consider
that one book is named "Mastering", while the other is a introduction to
web programming. I have not read either of these books, but shouldn't we
prefer to evaluate the monetary worth of a work based on the content and
the amount of time it took to produce?

On Sun, Apr 3, 2016 at 5:14 AM, gvim  wrote:

> On 03/04/2016 05:46, Akhil Wali wrote:
>
>> I'm pleased to announce that Mastering Clojure has been published.
>> This book is a fast paced exploration of the more advanced features of
>> the Clojure language.
>> It also demonstrates a handful of interesting libraries, such as
>> core.async, pulsar, core.logic and cats.
>>
>> https://www.packtpub.com/application-development/mastering-clojure
>> https://github.com/PacktPublishing/Mastering-Clojure
>> http://www.amazon.com/Mastering-Clojure-Akhil-Wali/dp/1785889745/
>>
>> It's been almost a year since I've started working on this book.
>> A big thanks to everyone involved!
>>
>>
> Congratulations, Akhil.
>
> To anyone intending to publish, please think twice before going with Packt
> as their pricing is ridiculous. Compare "Mastering Clojure" with "Web
> Development with Clojure" (Pragmatic Bookshelf):
>
> "Mastering Clojure" - 266 pages / 42.82 Euros = $48.81
> "Web Development with Clojure" - 250 pages / $24 = 21.05 Euros
>
> O'Reilly and Prag Prog books are also better produced, IMHO, with less of
> the sidebar padding you find in Packt books.
>
> gvim
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

Re: [ANN] [book] Mastering Clojure published!

[gvim]

On 03/04/2016 05:46, Akhil Wali wrote:

I'm pleased to announce that Mastering Clojure has been published.
This book is a fast paced exploration of the more advanced features of
the Clojure language.
It also demonstrates a handful of interesting libraries, such as
core.async, pulsar, core.logic and cats.

https://www.packtpub.com/application-development/mastering-clojure
https://github.com/PacktPublishing/Mastering-Clojure
http://www.amazon.com/Mastering-Clojure-Akhil-Wali/dp/1785889745/

It's been almost a year since I've started working on this book.
A big thanks to everyone involved!



Congratulations, Akhil.

To anyone intending to publish, please think twice before going with 
Packt as their pricing is ridiculous. Compare "Mastering Clojure" with 
"Web Development with Clojure" (Pragmatic Bookshelf):


"Mastering Clojure" - 266 pages / 42.82 Euros = $48.81
"Web Development with Clojure" - 250 pages / $24 = 21.05 Euros

O'Reilly and Prag Prog books are also better produced, IMHO, with less 
of the sidebar padding you find in Packt books.


gvim

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

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

Re: Clojure library

[Ashish Negi]

By default build tool : lein would not do AOT i.e. create .class files. So, 
your jar with `lein uberjar` would have .clj files. You can verify with 
un-tar the jar.

If you have a `-main` then you can use :skip-aot for not doing aot.. 
see 
https://github.com/technomancy/leiningen/blob/master/sample.project.clj#L189

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

Re: [ANN] [book] Mastering Clojure published!

[Colin Yates]

Congratulations! - I know how much effort goes into this sort of
thing. I look forward to reading a copy at some point.

On 3 April 2016 at 05:46, Akhil Wali  wrote:
> I'm pleased to announce that Mastering Clojure has been published.
> This book is a fast paced exploration of the more advanced features of the
> Clojure language.
> It also demonstrates a handful of interesting libraries, such as core.async,
> pulsar, core.logic and cats.
>
> https://www.packtpub.com/application-development/mastering-clojure
> https://github.com/PacktPublishing/Mastering-Clojure
> http://www.amazon.com/Mastering-Clojure-Akhil-Wali/dp/1785889745/
>
> It's been almost a year since I've started working on this book.
> A big thanks to everyone involved!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: Trouble using r/fold to optimise a reduce

[Divyansh Prakash]

Thanks a lot for taking the time out to explain this stuff in detail! 
Will go through your solution shortly.

On Sunday, April 3, 2016 at 12:02:48 PM UTC+5:30, Francis Avila wrote:
>
> I had some fun with playing around with faster solutions. 
> https://gist.github.com/favila/0573e3f644dea252bdaaed5be9d1519f
>
> The biggest speedup comes from avoiding set creation in expanded-range 
> (i.e., the function that produces the collection of affected coordinates) 
> and ensuring that the ops run on the accumulating set of on-lights using 
> transients.  clojure.set/* functions require both items be sets and does 
> not use transients internally, so it was much slower.
>
> Another big speedup comes from encoding the light coordinates more 
> efficiently. You can encode a light as a number (in my case, a long, with 
> high bits the x coordinate and low bits the y coordinate) instead of a 
> vector. This creates fewer objects which are easier to hash.
>
> Finally, I tried an approach which doesn't use sets, but instead naively 
> creates a 1000x1000 array of booleans and mutates it in place with every 
> op. This is the fastest approach: 4 seconds on a 2010-era i3! I'm sure a 
> proper matrix library (e.g. core.matrix) could do even better.
>

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

[ANN] Aleph 0.4.1

[Zach Tellman]

This release represents a number of incremental improvements to 0.4.0, 
which has been handling billions of daily requests for close to a year.  

* Documentation can be found at http://aleph.io/
* Literate examples of usage can be found 
at http://aleph.io/aleph/literate.html
* Comparative benchmarks can be found 
at 
https://www.techempower.com/benchmarks/#section=data-r12=peak=plaintext=4,
 
which may or may not be relevant to your particular use case

If anyone has questions, I'm happy to answer them.

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

Re: Trouble using r/fold to optimise a reduce

[Francis Avila]

I had some fun with playing around with faster 
solutions. https://gist.github.com/favila/0573e3f644dea252bdaaed5be9d1519f

The biggest speedup comes from avoiding set creation in expanded-range 
(i.e., the function that produces the collection of affected coordinates) 
and ensuring that the ops run on the accumulating set of on-lights using 
transients.  clojure.set/* functions require both items be sets and does 
not use transients internally, so it was much slower.

Another big speedup comes from encoding the light coordinates more 
efficiently. You can encode a light as a number (in my case, a long, with 
high bits the x coordinate and low bits the y coordinate) instead of a 
vector. This creates fewer objects which are easier to hash.

Finally, I tried an approach which doesn't use sets, but instead naively 
creates a 1000x1000 array of booleans and mutates it in place with every 
op. This is the fastest approach: 4 seconds on a 2010-era i3! I'm sure a 
proper matrix library (e.g. core.matrix) could do even better.

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