Re: Using transducers in a new transducing context

Thanks for clearing all of that up Alex! Very helpful. On Monday, April 10, 2017 at 3:46:45 PM UTC-4, Alex Miller wrote: > > > > On Monday, April 10, 2017 at 2:25:48 PM UTC-5, Alexander Gunnarson wrote: >> >> I think you present a key question: what assumptions can a tran

Re: Using transducers in a new transducing context

easonable to > assume that ? > If yes, that means it's ok to use unsynchronized variables in stateful > transducers as long as they stay local. > If no, that means we'll use synchronization in all stateful transducers, > with an obvious performance penalty and a benefit

Re: Using transducers in a new transducing context

y-accessed-by-different-threads [f] (map-indexed-transducer-base f atom #(swap! % inc)) ; or an AtomicLong variant On Monday, April 10, 2017 at 1:06:14 PM UTC-4, Alex Miller wrote: > > > On Monday, April 10, 2017 at 11:48:41 AM UTC-5, Alexander Gunnarson wrote: >> >> Léo, I de

Re: Using transducers in a new transducing context

ciple ? I would be very interested to know what Rich > has in mind that could lead him to advise to overprotect local state of > transducers. > > > > On Monday, April 10, 2017 at 4:44:00 AM UTC+2, Alexander Gunnarson wrote: >> >> Thanks so much for your input Alex!

Re: Using transducers in a new transducing context

4, Alex Miller wrote: > > > > On Sunday, April 9, 2017 at 9:44:00 PM UTC-5, Alexander Gunnarson wrote: >> >> >> As an aside about the stateful `take` transducer, Tesser uses the >> equivalent of one but skirts the issue by not guaranteeing that the first n >> it

Re: Using transducers in a new transducing context

Thanks so much for your input Alex! It was a very helpful confirmation of the key conclusions arrived at in this thread, and I appreciate the additional elaborations you gave, especially the insight you passed on about the stateful transducers using `ArrayList`. I'm glad that I wasn't the only

Re: Using transducers in a new transducing context

ed into the next call to `rf`. In other words: (-> result (rf >> x1) (rf x2) (rf x3))` trying to do that in a parallel context is next to >> impossible. Not saying there isn't a way to code a transducer-like thing to >> work with multiple threads, but the result of that w

Re: Using transducers in a new transducing context

#x27;t a way to code a transducer-like thing to > work with multiple threads, but the result of that would look a lot more > like core.async or Reactive Extensions, than the transducers we have today. > > On Sun, Apr 9, 2017 at 4:57 PM, Alexander Gunnarson < > alexander...@gmail.com

Re: Using transducers in a new transducing context

bc++ wrote: > > Transducers were never designed to work in parallel context. So I'd define > any behavior that arises from using the same transducers in multiple > threads *at the same time*, as undefined behavior. > > On Sun, Apr 9, 2017 at 4:39 PM, Alexander Gunnarson &

Re: Using transducers in a new transducing context

ety guarantees, so a `volatile` in addition to a lock is indeed overkill, if that's what is happening. On Sunday, April 9, 2017 at 6:19:51 PM UTC-4, Alexander Gunnarson wrote: > > It looks that way to me too, Seth, though I'd have to comb over the > details of the locks

Re: Using transducers in a new transducing context

the transducer in channel is protected by a lock. If that's the case > volatile isn't adding anything in terms memory barriers. > > 1: > https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj#L71 > > On Sunday, April 9, 2

Re: Using transducers in a new transducing context

Thanks so much for your well-considered reply, Timothy! That makes sense about volatiles being used in e.g. core.async or core.reducers contexts where the reducing function that closes over the mutable value of the stateful transducer is called in different threads. Why, then, are unsynchronized

Re: Using transducers in a new transducing context

be careful to e.g. create different `map-indexed` transducers for single-threaded (e.g. `unsynchronized-mutable` box) and multi-threaded (e.g. `atom` box) contexts. On Sunday, April 9, 2017 at 2:10:06 AM UTC-4, Alexander Gunnarson wrote: > > I was wondering the same thing, sh

Re: Use of volatile! in stateful transducers

l to create different `map-indexed` transducers for single-threaded and multi-threaded contexts. On Sunday, April 9, 2017 at 2:11:03 AM UTC-4, Alexander Gunnarson wrote: > > I was wondering the same thing, Jörg. This thread > <https://groups.google.com/forum/#!topic/clojure/VQj0E9TJWYY&

Re: Use of volatile! in stateful transducers

I was wondering the same thing, Jörg. This thread talks about it as well. I posted a note there which I will reproduce here for your convenience: I think it's safe to assume that since `ArrayList` uses unsynchronized mutability inte

Re: Using transducers in a new transducing context

I was wondering the same thing, shintotomoe. This thread talks about it as well. I think it's safe to assume that since `ArrayList` uses unsynchronized mutability internally (a quick review of the GrepCode entry for `ArrayList` confi

Re: [ANN] Clojure 1.7.0-alpha6 released

@Alex Miller — Thanks! I appreciate it. On Tuesday, March 31, 2015 at 10:51:13 AM UTC-6, Alex Miller wrote: > > Clojure 1.7.0-alpha6 is now available. > > Try it via > - Download: > https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/ > - Leiningen: [org.clojure/clojure "1.7.0-alpha6"

Re: [ANN] Clojure 1.7.0-alpha6 released

@Sean Corfield — That's exactly my point. I use Sublime Text and I usually just copy-paste code from various buffers / open files into a REPL buffer on my workspace. Maybe that's not the most efficient way, and I want to move to some sort of auto-reload plugin for leiningen a la figwheel for Cl

Re: [ANN] Clojure 1.7.0-alpha6 released

@Alex Miller: Thanks for letting me know. I'll unfortunately have to change my workflow accordingly. On Tuesday, March 31, 2015 at 10:51:13 AM UTC-6, Alex Miller wrote: > > Clojure 1.7.0-alpha6 is now available. > > Try it via > - Download: > https://repo1.maven.org/maven2/org/clojure/clojure/1

Re: [ANN] Clojure 1.7.0-alpha6 released

This patch is incredibly useful! Great job to everyone that contributed. One question: how do I enable conditional reading by default in the REPL as opposed to passing a properties map to /read-string/, etc.? Do I set certain system properties in the command line like "cond_read=true"? On Tuesd

Re: [ANN] Clojure 1.7.0-alpha6 released

This patch is great! It's much needed for my development workflow. One question: how do I enable conditional reading by default in the REPL? Do I set certain system properties in the command line like "cond_read=true" ? -- You received this message because you are subscribed to the Google Group

Re: ClojureScript concurrency?

> > To learn more Rob Pike gave a good presentation on 'Concurrency Is Not > Parallelism': http://vimeo.com/49718712 > Good video. Thanks for the link. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to cloju

ClojureScript concurrency?

One of Clojure's main selling points is the ability to implement concurrency in a fairly straightforward way. I know that ClojureScript doesn't support concurrency because JavaScript's VM doesn't support it. I mean, of course you can try to get around that by doing crazy tricks with asynchronou

Re: Clojure: One language to rule the Web

As a side note, maybe we can keep a running list of "Clojure-ized" technologies we're aware of: - XML - *clojure/data.xml * - XLink + XPointer + XQuery - *clojure/data.xml * - JSON -* Clojure Home Page (CHP)

Re: Clojure: One language to rule the Web

> > With the exception of XML and Flash, my framework covers all of that > https://github.com/runexec/chp > Your framework seems very promising. I'll have to play around with it. Any plans for extending it to enclose XML? ActionScript/Flash seems to have been addressed somewhat by las3r

Clojure: One language to rule the Web

This idea's been on my mind lately: could Clojure be used as a unifying force for all those disparate file formats and frameworks like: - XML / XLink / XPointer / XQuery, - JSON, - HTML / XHTML, - CSS, - JavaScript / jQuery, - Flash (SVG/ActionScript), - SQL, - and (of course) Java? As a disclaim

Clojure: Superset of XML, HTML, CSS, JavaScript, Flash (SVG/ActionScript), etc.?

No comments? -- -- 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, se

Clojure: Superset of XML, HTML, CSS, JavaScript, Flash (SVG/ActionScript), etc.?

This idea's been on my mind lately: could Clojure be used as a unifying force for all those disparate file formats and frameworks like: - XML / XLink / XPointer / XQuery, - JSON, - HTML / XHTML, - CSS, - JavaScript / jQuery, - Flash (SVG/ActionScript), - SQL, - and (of course) Java? As a disclaim

Re: Clojure: Elegance vs. Performance?

> > A reasonably simple optimisation would be to automatically identify > self-recursion in tail position and convert it directly to "recur". I think > that's possibly the kind of optimisation pass that the OP was suggesting. > That's exactly the kind of thing I was thinking about with recur.

Re: Clojure: Elegance vs. Performance?

Mikera, you hit on exactly what I was trying to say. Great post. I wonder what the feasibility would be to do what you and I are suggesting... It seems like it would take a while to get implemented, if it ever were implemented. Heaven knows I don't want to "get down and dirty with the compiler"

Re: Clojure: Elegance vs. Performance?

Good point... it was rather a sloppily done example. If I wanted to do an iterative solution, I could have written: (define (expt x n) (define (iter x1 n1 result) (cond ((= 0 n1) 1) ((= 1 n1) result) (else (iter x1 (- n1 1) (* x1

Re: Clojure: Elegance vs. Performance?

> > This is not implementing expt as it is usually known, it looks more like >> repeated squaring to me. >> > > Agreed. There's a certain irony that the OP declares the code pure, > simple, and beautiful, when it isn't correct code. Seems to me that if you > can't tell at a glance what a 3-li

Re: Clojure: Elegance vs. Performance?

Perhaps I didn't choose my examples in a very illustrative way. It was meant to be a general approach. There are probably several other examples where the need for performance causes elegance to suffer, but I'm drawing a blank right now because I'm not a Clojure expert. As I familiarize myself

Clojure: Elegance vs. Performance?

Hello everyone! It's great to be here with all you fellow Clojurians. Just so you know, this is my first post on this group, so don't shoot me if it's terrible ;) As background, I've been working through SICP and have been loving Scheme. It's almost breathtaking how elegant and clean the code