Re: every? expected behavior

[Simon Brooke]

On Tuesday, 8 April 2014 07:08:56 UTC+1, Jeff Mad wrote:
>
> Hi, 
> I am new to Clojure, so please forgive me if this does not make sense. 
>
> I was surprised to find out in the REPL that every? returns true if you 
> pass in an empty or nil collection. 
>
> user=> (every? #(= 77 %) nil)
>
> true
>
> user=> (every? #(= 77 %) '())
>
> true
>
Every item in the list () is equal to 77, so of course it returns true. 
There are no items in the list () that are not equal to 77.

Clojure is a bit muddled about nil. Nil, generally speaking, is the empty 
list - which is why (every? #(= 77 %) nil) is true. But in Clojure, it's 
not true that (= nil ()). There's no point in saying this is a mistake. But 
it does result in some very hard to explain design decisions.

 

-- 
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: "true" lightweight threads on clojurescript?

[t x]

I believe 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/1.7
suffices.

However, it's currently Firefox only and no Chrome.

On Tue, Apr 8, 2014 at 8:51 PM, Timothy Baldridge  wrote:
> What is going to fulfill a promise? How will you know when a promise is
> fulfilled. In a single threaded VM like JS you're stuck with callbacks.
> Nothing short of full program transformation will give you any better
> experience than core.async.
>
> A good way to look at it is this...if you do this in ClojureScript what
> javascript is this supposed to execute?
>
> (deref (promise))
>
> The only way this can work is with a code transform like go. Perhaps someday
> a new version of JS will arise that presents a different solution, but until
> then core.async is the best you're going to get.
>
> Timothy
>
>
> On Tue, Apr 8, 2014 at 3:11 PM, t x  wrote:
>>
>> I'm guilty of the X-Y problem.
>>
>>
>> I'm trying to, inside of CLJS, write a simple WebOS.
>>
>>
>> So I want to simultaneously be able to run things like:
>>   * a notepad app
>>   * an IRC app
>>   * a webRTC video chat app
>>
>>
>> I have built each of these individual pieces in CLJS, -- but combining
>> them / having them work well together in a clean, non-spaghetti way is
>> harder than I thought.
>>
>>
>>
>> ### The main problems here I have are:
>>
>>   * multi-threading (run all three apps at once) and
>>   * have is inter-"process" (in this case app) communication
>>
>>
>> I'd also prefer to do this in a way where I write each app as if it's
>> the only app running (i.e. no callback hell.)
>>
>>
>> One possible approach is to make each app a "go-thread", but then I
>> run into the issue of:
>>
>>   (go ... (>! ... ) (>
>>
>>
>> I'm looking for alternatives to this. By using:
>>
>>   settimeout(func, 0); I should be able to fire off 3 threads
>>
>>   now, if I had something like promises, I can do inter-process
>> communication
>>
>>
>>
>> I'm still working this through -- so if my thinking is sloppy /
>> unclear, please point it out so I can make it clearer.
>>
>>
>> Thanks!
>>
>> On Tue, Apr 8, 2014 at 2:05 PM, James Reeves 
>> wrote:
>> > What exactly are you trying to do? Could you describe the problem you're
>> > trying to solve in more detail?
>> >
>> > - James
>> >
>> >
>> > On 8 April 2014 22:02, t x  wrote:
>> >>
>> >> I'd really like to avoid callbacks. :-)
>> >>
>> >> If cljs had promises, it would suffice. :-)
>> >>
>> >> On Tue, Apr 8, 2014 at 2:00 PM, Gary Trakhman 
>> >> wrote:
>> >> > I think you might be able to use put! with a callback, or (go (>!
>> >> > ..))
>> >> > within foo for a transient go process.  Not sure if there's any ill
>> >> > effects.
>> >> >
>> >> >
>> >> > On Tue, Apr 8, 2014 at 4:51 PM, t x  wrote:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >>
>> >> >>   * I am aware of core.async. However, I don't like the fact that
>> >> >> (go
>> >> >> ... ) is a macro, thus forcing the >! and > >> >> body",
>> >> >> and I can't do nested things like:
>> >> >>
>> >> >>   (defn foo [chan]
>> >> >>  (let [x (> >> >>
>> >> >>   (go ... (foo ... ))
>> >> >>
>> >> >>
>> >> >>   * For the following, I only need it to work in ClojureScript. I
>> >> >> don't need it to work in Clojure. Furthermore, we can assume browser
>> >> >> =
>> >> >> latest Firefox, or browser = latest Chrome.
>> >> >>
>> >> >>
>> >> >>   Now, my question: is there a library which provides "true"
>> >> >> lightweight Clojurescript threads?
>> >> >>
>> >> >>
>> >> >> 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.
>> >> >
>> >> >
>> >> > --
>> >> > 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
>

Re: rant / cljs in cljs ? :-)

[t x]

I recently started using livejs.

It's fucking awesome.

basically livejs + lein cljsbuild auto (without cljx) + optimizations :none =

* I edit code in emacs.
* I hit C-x C-s
* I see compiling window flyby in milliseconds.
* I see browser reload.

This is happiness. :-)

On Sat, Apr 5, 2014 at 4:52 PM, Dave Sann  wrote:
> or livejs
>
> http://livejs.com/
>
>
> On Sunday, 6 April 2014 04:58:51 UTC+10, Henrik Eneroth wrote:
>>
>> If that is your criterion, use something that reloads the browser
>> automatically when the js is changed. I use CodeKit personally.
>>
>> On Wednesday, April 2, 2014 10:09:45 PM UTC+2, lypanov wrote:
>>>
>>> I hate REPLs. I also hate large compile times.
>>> For me the hardest part of the ~5s compile time is not waiting, it's the
>>> watching of the progress of the auto build and waiting until exactly that
>>> moment
>>> before pressing reload in the browser.
>>>
>>> That being said, I find "run this currently selected code block in my
>>> connected browser" functionality in editors (lighttable is the one I
>>> use/know) to be
>>> the best solution to this problem. It's painful as hell at first though.
>>>
>>> I had a work around in the past via a fork of noir-cljs which would delay
>>> the load of the .js files until compile completed via some hacks but
>>> now that I've switched to a browser <> editor work flow I find myself
>>> doing as much work as possible in the editor via the "run it in the browser
>>> REPL"
>>> script tag trick from  lighttable that I'm no longer even noticing
>>> compile times. I leave them to the end of the pomodoro.
>>>
>>> On Friday, March 21, 2014 7:48:59 AM UTC+1, t x wrote:

 Hi,

 *  I'm already using:

   :incremental true
   :compiler { :optimizations :none }

 * I'm also aware of cljs brepl


 However:

 1) the cljs compiler is still too slow for my liking (even though it's
 not calling closure)

 2) I don't like the cljs repl nearly as much as I like the clj repl


 Now, my dumb/stupid question:

   Is there any cljs in cljs _slow_ interpreter? I'm perfectly happy
 with an interpreter that runs 10x slower, if, in exchange, I get to
 hit "refresh" and my new code starts running.

   Furthermore, I'm _okay_ with their being a big delay every time I
 introduce a new macro from clj land.


   I realize this sounds spoiled -- but -- the cljs compiler delays are
 really really breaking my flow.


 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.

-- 
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: "true" lightweight threads on clojurescript?

[Moritz Ulrich]

What on this page would solve your problem? I just see
Generators/Iterators, Array Comprehensions, lexical let and
destructuring assignment.

On Wed, Apr 9, 2014 at 9:39 AM, t x  wrote:
> I believe 
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/1.7
> suffices.
>
> However, it's currently Firefox only and no Chrome.
>
> On Tue, Apr 8, 2014 at 8:51 PM, Timothy Baldridge  
> wrote:
>> What is going to fulfill a promise? How will you know when a promise is
>> fulfilled. In a single threaded VM like JS you're stuck with callbacks.
>> Nothing short of full program transformation will give you any better
>> experience than core.async.
>>
>> A good way to look at it is this...if you do this in ClojureScript what
>> javascript is this supposed to execute?
>>
>> (deref (promise))
>>
>> The only way this can work is with a code transform like go. Perhaps someday
>> a new version of JS will arise that presents a different solution, but until
>> then core.async is the best you're going to get.
>>
>> Timothy
>>
>>
>> On Tue, Apr 8, 2014 at 3:11 PM, t x  wrote:
>>>
>>> I'm guilty of the X-Y problem.
>>>
>>>
>>> I'm trying to, inside of CLJS, write a simple WebOS.
>>>
>>>
>>> So I want to simultaneously be able to run things like:
>>>   * a notepad app
>>>   * an IRC app
>>>   * a webRTC video chat app
>>>
>>>
>>> I have built each of these individual pieces in CLJS, -- but combining
>>> them / having them work well together in a clean, non-spaghetti way is
>>> harder than I thought.
>>>
>>>
>>>
>>> ### The main problems here I have are:
>>>
>>>   * multi-threading (run all three apps at once) and
>>>   * have is inter-"process" (in this case app) communication
>>>
>>>
>>> I'd also prefer to do this in a way where I write each app as if it's
>>> the only app running (i.e. no callback hell.)
>>>
>>>
>>> One possible approach is to make each app a "go-thread", but then I
>>> run into the issue of:
>>>
>>>   (go ... (>! ... ) (>>
>>>
>>>
>>> I'm looking for alternatives to this. By using:
>>>
>>>   settimeout(func, 0); I should be able to fire off 3 threads
>>>
>>>   now, if I had something like promises, I can do inter-process
>>> communication
>>>
>>>
>>>
>>> I'm still working this through -- so if my thinking is sloppy /
>>> unclear, please point it out so I can make it clearer.
>>>
>>>
>>> Thanks!
>>>
>>> On Tue, Apr 8, 2014 at 2:05 PM, James Reeves 
>>> wrote:
>>> > What exactly are you trying to do? Could you describe the problem you're
>>> > trying to solve in more detail?
>>> >
>>> > - James
>>> >
>>> >
>>> > On 8 April 2014 22:02, t x  wrote:
>>> >>
>>> >> I'd really like to avoid callbacks. :-)
>>> >>
>>> >> If cljs had promises, it would suffice. :-)
>>> >>
>>> >> On Tue, Apr 8, 2014 at 2:00 PM, Gary Trakhman 
>>> >> wrote:
>>> >> > I think you might be able to use put! with a callback, or (go (>!
>>> >> > ..))
>>> >> > within foo for a transient go process.  Not sure if there's any ill
>>> >> > effects.
>>> >> >
>>> >> >
>>> >> > On Tue, Apr 8, 2014 at 4:51 PM, t x  wrote:
>>> >> >>
>>> >> >> Hi,
>>> >> >>
>>> >> >>
>>> >> >>   * I am aware of core.async. However, I don't like the fact that
>>> >> >> (go
>>> >> >> ... ) is a macro, thus forcing the >! and >> >> >> body",
>>> >> >> and I can't do nested things like:
>>> >> >>
>>> >> >>   (defn foo [chan]
>>> >> >>  (let [x (>> >> >>
>>> >> >>   (go ... (foo ... ))
>>> >> >>
>>> >> >>
>>> >> >>   * For the following, I only need it to work in ClojureScript. I
>>> >> >> don't need it to work in Clojure. Furthermore, we can assume browser
>>> >> >> =
>>> >> >> latest Firefox, or browser = latest Chrome.
>>> >> >>
>>> >> >>
>>> >> >>   Now, my question: is there a library which provides "true"
>>> >> >> lightweight Clojurescript threads?
>>> >> >>
>>> >> >>
>>> >> >> 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.
>>> >> >
>>> >> >
>>> >> > --
>>> >> > 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

Re: Real World Example

[Colin Yates]

Hello back!

We are using Clojure on the JVM as the implementation language for a 
platform that will underpin our applications for the next decade.  It is 
relatively new and so far we have implemented the analysis module which is 
essentially a generic charting engine.  

So far we have 5547 lines of production code (including comments) and 2600 
lines of production code (including comments).

That doesn't sound like much but I can tell you it is replacing a similar, 
but slightly smaller in scope analysis module written in Java which was 
around 40K lines of production code.

Our architecture is Clojure on the back end exporting a number of JSON end 
points.  It is backed by MS SQL using the fantastic 
https://github.com/jkk/honeysql library.

For me, it is a dream coming from Java (and to a much lesser extent Scala), 
but it does have its costs.  Moving from an OO world to an FP world isn't 
easy, particularly in the shapes your solutions end up with.  I am also 
feeling the pain of not having types - everything is a sequence.  This is a 
joy but it also means a whole bunch of information (i.e. type information) 
is lost.  

One of the wins in OO languages is the many number of places to hang 
semantic information - the name of the class, the structure of the class, 
the names of the methods etc.  I also find many more intermediary variables 
in OO where as in Clojure it seems more idiomatic to have pipelines of 
transformation.  I am feeling the lost of static types as I refactor APIs 
particularly.

This is undoubtedly my failing not Clojure's and I just need to absorb more 
good FP paradigms.  Would I give up my emacs and Clojure and paredit 
combination?  Not a chance :).

Col

On Tuesday, 8 April 2014 20:23:06 UTC+1, Anthony Ortiz wrote:
>
> Hello world!
>
> I'm a C# developer who recently went to an interview at a major bank here 
> in NYC and found that they've been using Clojure for their business logic 
> for over a year already and that got me curious, so I find myself on 
> unfamiliar territory learning how to program in a functional language. So 
> far so good, Moxley Stratton's online tutorial combined with Try Clojure 
> (the online interpreter) has been very helpful (kudos to you guys!) and I'm 
> now going through the book 'Programming Clojure'. So far I've seen a lot of 
> utility/academic examples such as fibonacci but little in the way of an 
> actual real-world example of a top-to-bottom desktop application built 
> using Clojure on either the JVM or CLR, something simple that would 
> demonstrate how Clojure fits into the event-driven model on the client-side 
> behind, let's say, WPF, and how it would interact with more Clojure on the 
> service-side via, let's say, WCF. Does anyone know of an example they can 
> direct me to?
>
> Many thanks!
>
> Anthony
>

-- 
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: Real World Example

[Colin Yates]

Gah - 5547 production, 2600 of tests.  A lot of that discrepancy is down to 
the very extensive documentation that https://github.com/gdeer81/marginalia 
allows you to write.

Please forgive any other mistakes, working on less than an hours sleep due 
to my lovely kids.

On Wednesday, 9 April 2014 09:14:38 UTC+1, Colin Yates wrote:
>
> Hello back!
>
> We are using Clojure on the JVM as the implementation language for a 
> platform that will underpin our applications for the next decade.  It is 
> relatively new and so far we have implemented the analysis module which is 
> essentially a generic charting engine.  
>
> So far we have 5547 lines of production code (including comments) and 2600 
> lines of production code (including comments).
>
> That doesn't sound like much but I can tell you it is replacing a similar, 
> but slightly smaller in scope analysis module written in Java which was 
> around 40K lines of production code.
>
> Our architecture is Clojure on the back end exporting a number of JSON end 
> points.  It is backed by MS SQL using the fantastic 
> https://github.com/jkk/honeysql library.
>
> For me, it is a dream coming from Java (and to a much lesser extent 
> Scala), but it does have its costs.  Moving from an OO world to an FP world 
> isn't easy, particularly in the shapes your solutions end up with.  I am 
> also feeling the pain of not having types - everything is a sequence.  This 
> is a joy but it also means a whole bunch of information (i.e. type 
> information) is lost.  
>
> One of the wins in OO languages is the many number of places to hang 
> semantic information - the name of the class, the structure of the class, 
> the names of the methods etc.  I also find many more intermediary variables 
> in OO where as in Clojure it seems more idiomatic to have pipelines of 
> transformation.  I am feeling the lost of static types as I refactor APIs 
> particularly.
>
> This is undoubtedly my failing not Clojure's and I just need to absorb 
> more good FP paradigms.  Would I give up my emacs and Clojure and paredit 
> combination?  Not a chance :).
>
> Col
>
> On Tuesday, 8 April 2014 20:23:06 UTC+1, Anthony Ortiz wrote:
>>
>> Hello world!
>>
>> I'm a C# developer who recently went to an interview at a major bank here 
>> in NYC and found that they've been using Clojure for their business logic 
>> for over a year already and that got me curious, so I find myself on 
>> unfamiliar territory learning how to program in a functional language. So 
>> far so good, Moxley Stratton's online tutorial combined with Try Clojure 
>> (the online interpreter) has been very helpful (kudos to you guys!) and I'm 
>> now going through the book 'Programming Clojure'. So far I've seen a lot of 
>> utility/academic examples such as fibonacci but little in the way of an 
>> actual real-world example of a top-to-bottom desktop application built 
>> using Clojure on either the JVM or CLR, something simple that would 
>> demonstrate how Clojure fits into the event-driven model on the client-side 
>> behind, let's say, WPF, and how it would interact with more Clojure on the 
>> service-side via, let's say, WCF. Does anyone know of an example they can 
>> direct me to?
>>
>> Many thanks!
>>
>> Anthony
>>
>

-- 
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] friendui 0.2.0 released

[Sven Richter]

Hi,

I just released friendui into the 
wild: https://github.com/sveri/friend-ui/. Friendui is a wrapper around 
cemericks friend and datomic. 

This is the first time I am contributing something to the clojure 
community, mainly because I just started using clojure some months ago. If 
someone finds this useful, then please go ahead and use it or add some 
feature requests to it.

I would be happy about any feedback, but especially feedback regarding the 
clojure code, so if someone is bored and got some time, just go ahead, I 
would really like to learn more about best practices and newbie mistakes.

Best Regards,
Sven

-- 
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: A thought on Om/React

[David Nolen]

React is already headed in the direction you suggest. Still there would be
advantages to having something native in Clojure of course and perhaps
someone feels inclined to pursue that.

On Tuesday, April 8, 2014, Dave Sann  wrote:

> I haven't built anything with OM or react as yet. But I have read about it
> and I like the model in principle.
>
> A thought which repeatedly pops into my mind when I read about this is -
> ok, react in written in js. which is great for the web. What would happen
> if it were written in Clojure and available on server (As well as client (I
> am not thinking nodejs here).
>
> Going on slightly, it might be possible to
>
> 1. have a generally useful delta calculation - for this sort of use.
> 2. have a DOM structure and event model that could be mapped/bridged to
> swing or javafx or other.
> 3. have different UI models other than DOM that could be mapped to DOM or
> swing of javafx or other.
>
> I have no plans to do anything with this currently - but am interested in
> peoples thoughts.
>
> Dave
>
>  --
> 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: Real World Example

[Aditya Athalye]

Welcome, Anthony. 

I'm not aware of complete applications that fit your requirement, 
however I think you'll find value in the newly-minted Clojure Cookbook 
http://clojure-cookbook.com/ ... many, many examples of real-world 
problems, 
across domains, solved by Clojure practitioners.

All the examples and solutions are available here:
https://github.com/clojure-cookbook/clojure-cookbook

Cheers, and once again, welcome!



On Wednesday, April 9, 2014 12:53:06 AM UTC+5:30, Anthony Ortiz wrote:
>
> Hello world!
>
> I'm a C# developer who recently went to an interview at a major bank here 
> in NYC and found that they've been using Clojure for their business logic 
> for over a year already and that got me curious, so I find myself on 
> unfamiliar territory learning how to program in a functional language. So 
> far so good, Moxley Stratton's online tutorial combined with Try Clojure 
> (the online interpreter) has been very helpful (kudos to you guys!) and I'm 
> now going through the book 'Programming Clojure'. So far I've seen a lot of 
> utility/academic examples such as fibonacci but little in the way of an 
> actual real-world example of a top-to-bottom desktop application built 
> using Clojure on either the JVM or CLR, something simple that would 
> demonstrate how Clojure fits into the event-driven model on the client-side 
> behind, let's say, WPF, and how it would interact with more Clojure on the 
> service-side via, let's say, WCF. Does anyone know of an example they can 
> direct me to?
>
> Many thanks!
>
> Anthony
>

-- 
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: How do I update a record in a vector, matching certain criteria?

[Ivan Schuetz]

Hi,

thanks a lot! I ended putting the question in StackOverflow, yesterday, and 
also got this answer. It would have took a while until I came up with this. 
But now I understand.

For my concrete case I needed to update the record with all fields passed 
in a map. So I did:

 (commute items
  #(mapv (fn [i]
   (if (= (:id i) id)
 (merge i params)
 i))
 %)))



Am Mittwoch, 9. April 2014 03:24:21 UTC+2 schrieb Leif:
>
> Hi, Ivan.
>
> (defn set-item-name [data id newname]
>   (mapv #(if (not= (:id %) id)  ; <- NB mapv keeps it a vector 
> % ; no-op
>  (assoc % :name newname))
> data))
>
> (dosync (commute items set-item-name 1 "foo"))
>
> This really only makes sense if :id is *not* actually a primary key in 
> your data, 
>
> If, however, :id *is* a primary key, and most of the operations on the 
> data are only updating one element, you will want to follow Gary's advice 
> and change your data to
>
> {1 {:id 1 :name ...}
>  2 {:id 2 :name ...}
>  ...}
>
> I would also like to validate your feeling that this shouldn't be a 
> one-liner; you can generalize 'set-item-name', and then if you do want to 
> change the data structure later, you only have to change the general 
> function.
>
> --Leif
>
> On Tuesday, April 8, 2014 7:10:13 PM UTC-4, Ivan Schuetz wrote:
>>
>> As I said I already looked in the docs, and know these basic examples, 
>> but I don't know how to do:
>>
>> *"How can I say in a vector of records e.g. "set name of element to "foo" 
>> where id is equal 1"?"*
>>
>>
>> The remove by Id works, I posted it only to show something which might be 
>> similar to the update I'm looking for.
>>
>> I also wrote filter:
>>
>> (nth (filtered (filter #(= (:id %) id) @dataprovider/products)) 0)
>>
>> This gives me the element I need to update, but I still don't know how I 
>> update this element in the vector.
>>
>>
>>
>> Am Mittwoch, 9. April 2014 00:27:41 UTC+2 schrieb Gary Trakhman:
>>>
>>> Maybe this will help:
>>>
>>> > (update-in [[] 2 3 4] [0] (constantly 1))
>>> [1 2 3 4]
>>>
>>> > (update-in [[] 2 3 4] [2] (constantly 1))
>>> [ [ ] 2 1 4]
>>>
>>> > (update-in [[] 2 3 4] [1] (constantly 1))
>>> [ [ ] 1 3 4]
>>>
>>> > (update-in [[] 2 3 4] [0 :a] (constantly :b))
>>> java.lang.IllegalArgumentException: Key must be integer
>>>
>>> > (update-in [[] 2 3 4] [0 0 :a] (constantly :b))
>>> [ [{:a :b}] 2 3 4]
>>>
>>>
>>> On Tue, Apr 8, 2014 at 6:22 PM, Ivan Schuetz  wrote:
>>>
 I would use merge to update the record with the map... but I don't know 
 how to get it from filter operation. Maybe I should not solve this with 
 1-liner.

 Am Mittwoch, 9. April 2014 00:14:09 UTC+2 schrieb Ivan Schuetz:

> Ahh dataprovider/products should be "items". Forgot to "simplify".
>
>
> Am Mittwoch, 9. April 2014 00:12:48 UTC+2 schrieb Ivan Schuetz:
>>
>> Hi,
>>
>> sorry I don't get it. I just started learning Clojure.
>>
>> I did this to remove element with id 1
>>
>>  (commute items #(remove (fn [x](= (:id x) id)) %))
>>
>> From your statement I understand update-in would work for the update, 
>> but I don't know the syntax. Something like
>>
>> (commute dataprovider/products #(update-in % {:id id}  (->Item 
>> ???) ))
>>
>>
>>
>>
>> Am Mittwoch, 9. April 2014 00:01:00 UTC+2 schrieb Gary Trakhman:
>>>
>>>
 But 1. Can't find examples with records, 2. Not sure if I can use 
 it to update a different field than the one I'm using to do the query. 
 In 
 the examples fields seem to be the same.



>>> Leave off the last path segment and return the full updated record, 
>>> not just the new field's value.
>>>
>>  -- 
 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/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,

Re: Real World Example

[Fergal Byrne]

Hi Anthony,

I'm building a fairly large real-world system called Clortex [1], which is
a rewrite of the Numenta Platform for Intelligent Computing (NuPIC) [2]. As
it's a greenfield project, I've chosen to use Clojure components all the
way through instead of fitting in with Java-based or .Net-based frameworks.
There are good reasons why you should do this if you can, but obviously
that doesn't help you directly with your question.

There are many people introducing Clojure as a component in an existing
ecosystem, as Colin explains, but usually this is done deep inside a big
Java or .Net shop, and they're not showing the world the code. One possible
route would be to see if any of the big Java or CLR Open Source apps are
looking at doing some subsystems in Clojure.

Colin,

Great to hear your experiences. I'm no expert, but it's likely that you
could ease much of the pain using protocols, type hints and deftypes or
records. Also, Typed Clojure [3] is definitely worth looking at.

[1] Clortex will be public on Github shortly, see
http://fergalbyrne.github.io for docs, http://inbits.com for blog.
[2] http://numenta.org
[3] https://github.com/clojure/core.typed

Regards,

Fergal Byrne




On Wed, Apr 9, 2014 at 10:18 AM, Aditya Athalye wrote:

> Welcome, Anthony.
>
> I'm not aware of complete applications that fit your requirement,
> however I think you'll find value in the newly-minted Clojure Cookbook
> http://clojure-cookbook.com/ ... many, many examples of real-world
> problems,
> across domains, solved by Clojure practitioners.
>
> All the examples and solutions are available here:
> https://github.com/clojure-cookbook/clojure-cookbook
>
> Cheers, and once again, welcome!
>
>
>
> On Wednesday, April 9, 2014 12:53:06 AM UTC+5:30, Anthony Ortiz wrote:
>>
>> Hello world!
>>
>> I'm a C# developer who recently went to an interview at a major bank here
>> in NYC and found that they've been using Clojure for their business logic
>> for over a year already and that got me curious, so I find myself on
>> unfamiliar territory learning how to program in a functional language. So
>> far so good, Moxley Stratton's online tutorial combined with Try Clojure
>> (the online interpreter) has been very helpful (kudos to you guys!) and I'm
>> now going through the book 'Programming Clojure'. So far I've seen a lot of
>> utility/academic examples such as fibonacci but little in the way of an
>> actual real-world example of a top-to-bottom desktop application built
>> using Clojure on either the JVM or CLR, something simple that would
>> demonstrate how Clojure fits into the event-driven model on the client-side
>> behind, let's say, WPF, and how it would interact with more Clojure on the
>> service-side via, let's say, WCF. Does anyone know of an example they can
>> direct me to?
>>
>> Many thanks!
>>
>> Anthony
>>
>  --
> 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.
>



-- 

Fergal Byrne, Brenter IT

Author, Real Machine Intelligence with Clortex and NuPIC
https://leanpub.com/realsmartmachines

http://inbits.com - Better Living through
Thoughtful Technology
http://ie.linkedin.com/in/fergbyrne/
https://github.com/fergalbyrne

e:fergalbyrnedub...@gmail.com t:+353 83 4214179
Formerly of Adnet edi...@adnet.ie http://www.adnet.ie

-- 
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 Langohr 2.9.0 is released

[Michael Klishin]

Langohr [1] is a small, feature complete Clojure client for RabbitMQ.

Release notes:
http://blog.clojurewerkz.org/blog/2014/04/09/langohr-2-dot-9-0-is-released/

1. http://clojurerabbitmq.info
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
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: Real World Example

[Colin Yates]

Hi Fergal,

Thanks for those links.  I started using protocols and defrecords but I 
(maybe mistakenly) got the impression that they were "frowned upon".  As it 
turns out, maps (typically with a :type key) and multi methods go a long 
long way, but I still end up with fairly deep nesting of maps.  

Maybe that is the key - deep nesting of maps maybe cries out "one object 
[data model] to rule them all" and I need to decompose it further.  

Without types almost all the type hints would be either the map of sequence 
interface.  It isn't so much the structure that is obscure, but the 
semantics of what that structure is modelling.

As I hinted at, I am sure it is because my implementation model is still 
influenced too much by my OO background.

Onwards and upwards as they say.

Col


On Wednesday, 9 April 2014 11:37:52 UTC+1, Fergal Byrne wrote:
>
> Hi Anthony,
>
> I'm building a fairly large real-world system called Clortex [1], which is 
> a rewrite of the Numenta Platform for Intelligent Computing (NuPIC) [2]. As 
> it's a greenfield project, I've chosen to use Clojure components all the 
> way through instead of fitting in with Java-based or .Net-based frameworks. 
> There are good reasons why you should do this if you can, but obviously 
> that doesn't help you directly with your question.
>
> There are many people introducing Clojure as a component in an existing 
> ecosystem, as Colin explains, but usually this is done deep inside a big 
> Java or .Net shop, and they're not showing the world the code. One possible 
> route would be to see if any of the big Java or CLR Open Source apps are 
> looking at doing some subsystems in Clojure.
>
> Colin,
>
> Great to hear your experiences. I'm no expert, but it's likely that you 
> could ease much of the pain using protocols, type hints and deftypes or 
> records. Also, Typed Clojure [3] is definitely worth looking at. 
>
> [1] Clortex will be public on Github shortly, see 
> http://fergalbyrne.github.io for docs, http://inbits.com for blog.
> [2] http://numenta.org
> [3] https://github.com/clojure/core.typed
>
> Regards,
>
> Fergal Byrne
>
>
>
>
> On Wed, Apr 9, 2014 at 10:18 AM, Aditya Athalye 
> 
> > wrote:
>
>> Welcome, Anthony. 
>>
>> I'm not aware of complete applications that fit your requirement, 
>> however I think you'll find value in the newly-minted Clojure Cookbook 
>> http://clojure-cookbook.com/ ... many, many examples of real-world 
>> problems, 
>> across domains, solved by Clojure practitioners.
>>
>> All the examples and solutions are available here:
>> https://github.com/clojure-cookbook/clojure-cookbook
>>
>> Cheers, and once again, welcome!
>>
>>
>>
>> On Wednesday, April 9, 2014 12:53:06 AM UTC+5:30, Anthony Ortiz wrote:
>>>
>>> Hello world!
>>>
>>> I'm a C# developer who recently went to an interview at a major bank 
>>> here in NYC and found that they've been using Clojure for their business 
>>> logic for over a year already and that got me curious, so I find myself on 
>>> unfamiliar territory learning how to program in a functional language. So 
>>> far so good, Moxley Stratton's online tutorial combined with Try Clojure 
>>> (the online interpreter) has been very helpful (kudos to you guys!) and I'm 
>>> now going through the book 'Programming Clojure'. So far I've seen a lot of 
>>> utility/academic examples such as fibonacci but little in the way of an 
>>> actual real-world example of a top-to-bottom desktop application built 
>>> using Clojure on either the JVM or CLR, something simple that would 
>>> demonstrate how Clojure fits into the event-driven model on the client-side 
>>> behind, let's say, WPF, and how it would interact with more Clojure on the 
>>> service-side via, let's say, WCF. Does anyone know of an example they can 
>>> direct me to?
>>>
>>> Many thanks!
>>>
>>> Anthony
>>>
>>  -- 
>> 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/d/optout.
>>
>
>
>
> -- 
>
> Fergal Byrne, Brenter IT
>
> Author, Real Machine Intelligence with Clortex and NuPIC 
> https://leanpub.com/realsmartmachines
>
> http://inbits.com - Better Living through 
> Thoughtful Technology
> http://ie.linkedin.com/in/fergbyrne/
> https://github.com/fergalbyrne
>
> e:fergalby...@gmail.com  t:+353 83 4214179
> Formerly of Adnet edi...@adnet.ie  http://www.adnet.ie
>  

--

Re: "true" lightweight threads on clojurescript?

[t x]

For the purposes of building a webos:

Having yield + co-routines gives me cooperative multi-threading --
which is basically all I need.


The main difference between co-routines and go-routines. Is that for
(go ... ) blocks, the ! must be lexically embedded within the
block; whereas with co-routines, the send/receive can be called in
functions I call.


On Wed, Apr 9, 2014 at 1:11 AM, Moritz Ulrich  wrote:
> What on this page would solve your problem? I just see
> Generators/Iterators, Array Comprehensions, lexical let and
> destructuring assignment.
>
> On Wed, Apr 9, 2014 at 9:39 AM, t x  wrote:
>> I believe 
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/1.7
>> suffices.
>>
>> However, it's currently Firefox only and no Chrome.
>>
>> On Tue, Apr 8, 2014 at 8:51 PM, Timothy Baldridge  
>> wrote:
>>> What is going to fulfill a promise? How will you know when a promise is
>>> fulfilled. In a single threaded VM like JS you're stuck with callbacks.
>>> Nothing short of full program transformation will give you any better
>>> experience than core.async.
>>>
>>> A good way to look at it is this...if you do this in ClojureScript what
>>> javascript is this supposed to execute?
>>>
>>> (deref (promise))
>>>
>>> The only way this can work is with a code transform like go. Perhaps someday
>>> a new version of JS will arise that presents a different solution, but until
>>> then core.async is the best you're going to get.
>>>
>>> Timothy
>>>
>>>
>>> On Tue, Apr 8, 2014 at 3:11 PM, t x  wrote:

 I'm guilty of the X-Y problem.


 I'm trying to, inside of CLJS, write a simple WebOS.


 So I want to simultaneously be able to run things like:
   * a notepad app
   * an IRC app
   * a webRTC video chat app


 I have built each of these individual pieces in CLJS, -- but combining
 them / having them work well together in a clean, non-spaghetti way is
 harder than I thought.



 ### The main problems here I have are:

   * multi-threading (run all three apps at once) and
   * have is inter-"process" (in this case app) communication


 I'd also prefer to do this in a way where I write each app as if it's
 the only app running (i.e. no callback hell.)


 One possible approach is to make each app a "go-thread", but then I
 run into the issue of:

   (go ... (>! ... ) (>>>


 I'm looking for alternatives to this. By using:

   settimeout(func, 0); I should be able to fire off 3 threads

   now, if I had something like promises, I can do inter-process
 communication



 I'm still working this through -- so if my thinking is sloppy /
 unclear, please point it out so I can make it clearer.


 Thanks!

 On Tue, Apr 8, 2014 at 2:05 PM, James Reeves 
 wrote:
 > What exactly are you trying to do? Could you describe the problem you're
 > trying to solve in more detail?
 >
 > - James
 >
 >
 > On 8 April 2014 22:02, t x  wrote:
 >>
 >> I'd really like to avoid callbacks. :-)
 >>
 >> If cljs had promises, it would suffice. :-)
 >>
 >> On Tue, Apr 8, 2014 at 2:00 PM, Gary Trakhman 
 >> wrote:
 >> > I think you might be able to use put! with a callback, or (go (>!
 >> > ..))
 >> > within foo for a transient go process.  Not sure if there's any ill
 >> > effects.
 >> >
 >> >
 >> > On Tue, Apr 8, 2014 at 4:51 PM, t x  wrote:
 >> >>
 >> >> Hi,
 >> >>
 >> >>
 >> >>   * I am aware of core.async. However, I don't like the fact that
 >> >> (go
 >> >> ... ) is a macro, thus forcing the >! and >>> >> >> body",
 >> >> and I can't do nested things like:
 >> >>
 >> >>   (defn foo [chan]
 >> >>  (let [x (>>> >> >>
 >> >>   (go ... (foo ... ))
 >> >>
 >> >>
 >> >>   * For the following, I only need it to work in ClojureScript. I
 >> >> don't need it to work in Clojure. Furthermore, we can assume browser
 >> >> =
 >> >> latest Firefox, or browser = latest Chrome.
 >> >>
 >> >>
 >> >>   Now, my question: is there a library which provides "true"
 >> >> lightweight Clojurescript threads?
 >> >>
 >> >>
 >> >> 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

Re: "true" lightweight threads on clojurescript?

[Timothy Baldridge]

One can build go like things on top of generators, however this doesn't
solve your problem, as these generators (pointed to in your link) cannot
yield through more than a single function. They have the same semantics as
yield in python or C# (or go in Clojure). That is to say every function in
the chain must do:

for(x in generator)
  yield x;

In order to pass along the value. This is exactly the same as making every
function in your system contain a go, and that go's body containing
something like:

(go (>! ret-chan ( wrote:

> What on this page would solve your problem? I just see
> Generators/Iterators, Array Comprehensions, lexical let and
> destructuring assignment.
>
> On Wed, Apr 9, 2014 at 9:39 AM, t x  wrote:
> > I believe
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/1.7
> > suffices.
> >
> > However, it's currently Firefox only and no Chrome.
> >
> > On Tue, Apr 8, 2014 at 8:51 PM, Timothy Baldridge 
> wrote:
> >> What is going to fulfill a promise? How will you know when a promise is
> >> fulfilled. In a single threaded VM like JS you're stuck with callbacks.
> >> Nothing short of full program transformation will give you any better
> >> experience than core.async.
> >>
> >> A good way to look at it is this...if you do this in ClojureScript what
> >> javascript is this supposed to execute?
> >>
> >> (deref (promise))
> >>
> >> The only way this can work is with a code transform like go. Perhaps
> someday
> >> a new version of JS will arise that presents a different solution, but
> until
> >> then core.async is the best you're going to get.
> >>
> >> Timothy
> >>
> >>
> >> On Tue, Apr 8, 2014 at 3:11 PM, t x  wrote:
> >>>
> >>> I'm guilty of the X-Y problem.
> >>>
> >>>
> >>> I'm trying to, inside of CLJS, write a simple WebOS.
> >>>
> >>>
> >>> So I want to simultaneously be able to run things like:
> >>>   * a notepad app
> >>>   * an IRC app
> >>>   * a webRTC video chat app
> >>>
> >>>
> >>> I have built each of these individual pieces in CLJS, -- but combining
> >>> them / having them work well together in a clean, non-spaghetti way is
> >>> harder than I thought.
> >>>
> >>>
> >>>
> >>> ### The main problems here I have are:
> >>>
> >>>   * multi-threading (run all three apps at once) and
> >>>   * have is inter-"process" (in this case app) communication
> >>>
> >>>
> >>> I'd also prefer to do this in a way where I write each app as if it's
> >>> the only app running (i.e. no callback hell.)
> >>>
> >>>
> >>> One possible approach is to make each app a "go-thread", but then I
> >>> run into the issue of:
> >>>
> >>>   (go ... (>! ... ) ( function.
> >>>
> >>>
> >>>
> >>> I'm looking for alternatives to this. By using:
> >>>
> >>>   settimeout(func, 0); I should be able to fire off 3 threads
> >>>
> >>>   now, if I had something like promises, I can do inter-process
> >>> communication
> >>>
> >>>
> >>>
> >>> I'm still working this through -- so if my thinking is sloppy /
> >>> unclear, please point it out so I can make it clearer.
> >>>
> >>>
> >>> Thanks!
> >>>
> >>> On Tue, Apr 8, 2014 at 2:05 PM, James Reeves 
> >>> wrote:
> >>> > What exactly are you trying to do? Could you describe the problem
> you're
> >>> > trying to solve in more detail?
> >>> >
> >>> > - James
> >>> >
> >>> >
> >>> > On 8 April 2014 22:02, t x  wrote:
> >>> >>
> >>> >> I'd really like to avoid callbacks. :-)
> >>> >>
> >>> >> If cljs had promises, it would suffice. :-)
> >>> >>
> >>> >> On Tue, Apr 8, 2014 at 2:00 PM, Gary Trakhman <
> gary.trakh...@gmail.com>
> >>> >> wrote:
> >>> >> > I think you might be able to use put! with a callback, or (go (>!
> >>> >> > ..))
> >>> >> > within foo for a transient go process.  Not sure if there's any
> ill
> >>> >> > effects.
> >>> >> >
> >>> >> >
> >>> >> > On Tue, Apr 8, 2014 at 4:51 PM, t x  wrote:
> >>> >> >>
> >>> >> >> Hi,
> >>> >> >>
> >>> >> >>
> >>> >> >>   * I am aware of core.async. However, I don't like the fact that
> >>> >> >> (go
> >>> >> >> ... ) is a macro, thus forcing the >! and  >>> >> >> body",
> >>> >> >> and I can't do nested things like:
> >>> >> >>
> >>> >> >>   (defn foo [chan]
> >>> >> >>  (let [x ( >>> >> >>
> >>> >> >>   (go ... (foo ... ))
> >>> >> >>
> >>> >> >>
> >>> >> >>   * For the following, I only need it to work in ClojureScript. I
> >>> >> >> don't need it to work in Clojure. Furthermore, we can assume
> browser
> >>> >> >> =
> >>> >> >> latest Firefox, or browser = latest Chrome.
> >>> >> >>
> >>> >> >>
> >>> >> >>   Now, my question: is there a library which provides "true"
> >>> >> >> lightweight Clojurescript threads?
> >>> >> >>
> >>> >> >>
> >>> >> >> 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 po

Re: "true" lightweight threads on clojurescript?

[Timothy Baldridge]

I'd also caution against attempting to use >! and  wrote:

> For the purposes of building a webos:
>
> Having yield + co-routines gives me cooperative multi-threading --
> which is basically all I need.
>
>
> The main difference between co-routines and go-routines. Is that for
> (go ... ) blocks, the ! must be lexically embedded within the
> block; whereas with co-routines, the send/receive can be called in
> functions I call.
>
>
> On Wed, Apr 9, 2014 at 1:11 AM, Moritz Ulrich 
> wrote:
> > What on this page would solve your problem? I just see
> > Generators/Iterators, Array Comprehensions, lexical let and
> > destructuring assignment.
> >
> > On Wed, Apr 9, 2014 at 9:39 AM, t x  wrote:
> >> I believe
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/1.7
> >> suffices.
> >>
> >> However, it's currently Firefox only and no Chrome.
> >>
> >> On Tue, Apr 8, 2014 at 8:51 PM, Timothy Baldridge 
> wrote:
> >>> What is going to fulfill a promise? How will you know when a promise is
> >>> fulfilled. In a single threaded VM like JS you're stuck with callbacks.
> >>> Nothing short of full program transformation will give you any better
> >>> experience than core.async.
> >>>
> >>> A good way to look at it is this...if you do this in ClojureScript what
> >>> javascript is this supposed to execute?
> >>>
> >>> (deref (promise))
> >>>
> >>> The only way this can work is with a code transform like go. Perhaps
> someday
> >>> a new version of JS will arise that presents a different solution, but
> until
> >>> then core.async is the best you're going to get.
> >>>
> >>> Timothy
> >>>
> >>>
> >>> On Tue, Apr 8, 2014 at 3:11 PM, t x  wrote:
> 
>  I'm guilty of the X-Y problem.
> 
> 
>  I'm trying to, inside of CLJS, write a simple WebOS.
> 
> 
>  So I want to simultaneously be able to run things like:
>    * a notepad app
>    * an IRC app
>    * a webRTC video chat app
> 
> 
>  I have built each of these individual pieces in CLJS, -- but combining
>  them / having them work well together in a clean, non-spaghetti way is
>  harder than I thought.
> 
> 
> 
>  ### The main problems here I have are:
> 
>    * multi-threading (run all three apps at once) and
>    * have is inter-"process" (in this case app) communication
> 
> 
>  I'd also prefer to do this in a way where I write each app as if it's
>  the only app running (i.e. no callback hell.)
> 
> 
>  One possible approach is to make each app a "go-thread", but then I
>  run into the issue of:
> 
>    (go ... (>! ... ) ( function.
> 
> 
> 
>  I'm looking for alternatives to this. By using:
> 
>    settimeout(func, 0); I should be able to fire off 3 threads
> 
>    now, if I had something like promises, I can do inter-process
>  communication
> 
> 
> 
>  I'm still working this through -- so if my thinking is sloppy /
>  unclear, please point it out so I can make it clearer.
> 
> 
>  Thanks!
> 
>  On Tue, Apr 8, 2014 at 2:05 PM, James Reeves 
>  wrote:
>  > What exactly are you trying to do? Could you describe the problem
> you're
>  > trying to solve in more detail?
>  >
>  > - James
>  >
>  >
>  > On 8 April 2014 22:02, t x  wrote:
>  >>
>  >> I'd really like to avoid callbacks. :-)
>  >>
>  >> If cljs had promises, it would suffice. :-)
>  >>
>  >> On Tue, Apr 8, 2014 at 2:00 PM, Gary Trakhman <
> gary.trakh...@gmail.com>
>  >> wrote:
>  >> > I think you might be able to use put! with a callback, or (go (>!
>  >> > ..))
>  >> > within foo for a transient go process.  Not sure if there's any
> ill
>  >> > effects.
>  >> >
>  >> >
>  >> > On Tue, Apr 8, 2014 at 4:51 PM, t x  wrote:
>  >> >>
>  >> >> Hi,
>  >> >>
>  >> >>
>  >> >>   * I am aware of core.async. However, I don't like the fact
> that
>  >> >> (go
>  >> >> ... ) is a macro, thus forcing the >! and   >> >> body",
>  >> >> and I can't do nested things like:
>  >> >>
>  >> >>   (defn foo [chan]
>  >> >>  (let [x (  >> >>
>  >> >>   (go ... (foo ... ))
>  >> >>
>  >> >>
>  >> >>   * For the following, I only need it to work in ClojureScript.
> I
>  >> >> don't need it to work in Clojure. Furthermore, we can assume
> browser
>  >> >> =
>  >> >> latest Firefox, or browser = latest Chrome.
>  >> >>
>  >> >>
>  >> >>   Now, my question: is there a library which provides "true"
>  >> >> lightweight Clojurescript threads?
>  >> >>
>  >> >>
>  >> >> 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 th

Re: Real World Example

[Fergal Byrne]

Hi Colin,

Cheers. I had exactly the same problem, so I've been trying out a few other
ideas. One is to use datalog (or cascalog etc) and represent "objects" with
entities and relationships between objects with refs (for datalog). I have
some enormous data structures (2-300m synapses per layer, for example) but
I find that Datomic and datalog are great for modelling really big and
complex structures.

There's a datomic wrapper library called adi [1] which adds a nice map-like
interface on top of datalog. It's perfect for getting your schema right
(you start off with a big map and it automagically does the schema), and
you can do some really long link-following, but I'm not using it
extensively yet (because everything is data, you can use adi for schema
design and some queries, and raw datomic for the rest).

I'll be writing extensively about each library or tool I've used on my blog
(see sig). I'm writing about lein-midje-doc (also by zcaudate) at the
moment, it's just wonderful.

[1] https://github.com/zcaudate/adi

Regards,

Fergal Byrne


On Wed, Apr 9, 2014 at 12:22 PM, Colin Yates  wrote:

> Hi Fergal,
>
> Thanks for those links.  I started using protocols and defrecords but I
> (maybe mistakenly) got the impression that they were "frowned upon".  As it
> turns out, maps (typically with a :type key) and multi methods go a long
> long way, but I still end up with fairly deep nesting of maps.
>
> Maybe that is the key - deep nesting of maps maybe cries out "one object
> [data model] to rule them all" and I need to decompose it further.
>
> Without types almost all the type hints would be either the map of
> sequence interface.  It isn't so much the structure that is obscure, but
> the semantics of what that structure is modelling.
>
> As I hinted at, I am sure it is because my implementation model is still
> influenced too much by my OO background.
>
> Onwards and upwards as they say.
>
> Col
>
>
> On Wednesday, 9 April 2014 11:37:52 UTC+1, Fergal Byrne wrote:
>
>> Hi Anthony,
>>
>> I'm building a fairly large real-world system called Clortex [1], which
>> is a rewrite of the Numenta Platform for Intelligent Computing (NuPIC) [2].
>> As it's a greenfield project, I've chosen to use Clojure components all the
>> way through instead of fitting in with Java-based or .Net-based frameworks.
>> There are good reasons why you should do this if you can, but obviously
>> that doesn't help you directly with your question.
>>
>> There are many people introducing Clojure as a component in an existing
>> ecosystem, as Colin explains, but usually this is done deep inside a big
>> Java or .Net shop, and they're not showing the world the code. One possible
>> route would be to see if any of the big Java or CLR Open Source apps are
>> looking at doing some subsystems in Clojure.
>>
>> Colin,
>>
>> Great to hear your experiences. I'm no expert, but it's likely that you
>> could ease much of the pain using protocols, type hints and deftypes or
>> records. Also, Typed Clojure [3] is definitely worth looking at.
>>
>> [1] Clortex will be public on Github shortly, see
>> http://fergalbyrne.github.io for docs, http://inbits.com for blog.
>>  [2] http://numenta.org
>> [3] https://github.com/clojure/core.typed
>>
>> Regards,
>>
>> Fergal Byrne
>>
>>
>>
>>
>> On Wed, Apr 9, 2014 at 10:18 AM, Aditya Athalye wrote:
>>
>>> Welcome, Anthony.
>>>
>>> I'm not aware of complete applications that fit your requirement,
>>> however I think you'll find value in the newly-minted Clojure Cookbook
>>> http://clojure-cookbook.com/ ... many, many examples of real-world
>>> problems,
>>> across domains, solved by Clojure practitioners.
>>>
>>> All the examples and solutions are available here:
>>> https://github.com/clojure-cookbook/clojure-cookbook
>>>
>>> Cheers, and once again, welcome!
>>>
>>>
>>>
>>> On Wednesday, April 9, 2014 12:53:06 AM UTC+5:30, Anthony Ortiz wrote:

 Hello world!

 I'm a C# developer who recently went to an interview at a major bank
 here in NYC and found that they've been using Clojure for their business
 logic for over a year already and that got me curious, so I find myself on
 unfamiliar territory learning how to program in a functional language. So
 far so good, Moxley Stratton's online tutorial combined with Try Clojure
 (the online interpreter) has been very helpful (kudos to you guys!) and I'm
 now going through the book 'Programming Clojure'. So far I've seen a lot of
 utility/academic examples such as fibonacci but little in the way of an
 actual real-world example of a top-to-bottom desktop application built
 using Clojure on either the JVM or CLR, something simple that would
 demonstrate how Clojure fits into the event-driven model on the client-side
 behind, let's say, WPF, and how it would interact with more Clojure on the
 service-side via, let's say, WCF. Does anyone know of an example they can
 direct me to?

 Many thanks!

Re: Real World Example

[Colin Yates]

lein-midje-doc really does look excellent.  I went with marginalia but if 
that had been around at the time I would have jumped on it without a doubt.

On Wednesday, 9 April 2014 13:20:51 UTC+1, Fergal Byrne wrote:
>
> Hi Colin,
>
> Cheers. I had exactly the same problem, so I've been trying out a few 
> other ideas. One is to use datalog (or cascalog etc) and represent 
> "objects" with entities and relationships between objects with refs (for 
> datalog). I have some enormous data structures (2-300m synapses per layer, 
> for example) but I find that Datomic and datalog are great for modelling 
> really big and complex structures.
>
> There's a datomic wrapper library called adi [1] which adds a nice 
> map-like interface on top of datalog. It's perfect for getting your schema 
> right (you start off with a big map and it automagically does the schema), 
> and you can do some really long link-following, but I'm not using it 
> extensively yet (because everything is data, you can use adi for schema 
> design and some queries, and raw datomic for the rest).
>
> I'll be writing extensively about each library or tool I've used on my 
> blog (see sig). I'm writing about lein-midje-doc (also by zcaudate) at the 
> moment, it's just wonderful.
>
> [1] https://github.com/zcaudate/adi
>
> Regards,
>
> Fergal Byrne
>
>
> On Wed, Apr 9, 2014 at 12:22 PM, Colin Yates 
> > wrote:
>
>> Hi Fergal,
>>
>> Thanks for those links.  I started using protocols and defrecords but I 
>> (maybe mistakenly) got the impression that they were "frowned upon".  As it 
>> turns out, maps (typically with a :type key) and multi methods go a long 
>> long way, but I still end up with fairly deep nesting of maps.  
>>
>> Maybe that is the key - deep nesting of maps maybe cries out "one object 
>> [data model] to rule them all" and I need to decompose it further.  
>>
>> Without types almost all the type hints would be either the map of 
>> sequence interface.  It isn't so much the structure that is obscure, but 
>> the semantics of what that structure is modelling.
>>
>> As I hinted at, I am sure it is because my implementation model is still 
>> influenced too much by my OO background.
>>
>> Onwards and upwards as they say.
>>
>> Col
>>
>>
>> On Wednesday, 9 April 2014 11:37:52 UTC+1, Fergal Byrne wrote:
>>
>>> Hi Anthony,
>>>
>>> I'm building a fairly large real-world system called Clortex [1], which 
>>> is a rewrite of the Numenta Platform for Intelligent Computing (NuPIC) [2]. 
>>> As it's a greenfield project, I've chosen to use Clojure components all the 
>>> way through instead of fitting in with Java-based or .Net-based frameworks. 
>>> There are good reasons why you should do this if you can, but obviously 
>>> that doesn't help you directly with your question.
>>>
>>> There are many people introducing Clojure as a component in an existing 
>>> ecosystem, as Colin explains, but usually this is done deep inside a big 
>>> Java or .Net shop, and they're not showing the world the code. One possible 
>>> route would be to see if any of the big Java or CLR Open Source apps are 
>>> looking at doing some subsystems in Clojure.
>>>
>>> Colin,
>>>
>>> Great to hear your experiences. I'm no expert, but it's likely that you 
>>> could ease much of the pain using protocols, type hints and deftypes or 
>>> records. Also, Typed Clojure [3] is definitely worth looking at. 
>>>
>>> [1] Clortex will be public on Github shortly, see 
>>> http://fergalbyrne.github.io for docs, http://inbits.com for blog.
>>>  [2] http://numenta.org
>>> [3] https://github.com/clojure/core.typed
>>>
>>> Regards,
>>>
>>> Fergal Byrne
>>>
>>>
>>>
>>>
>>> On Wed, Apr 9, 2014 at 10:18 AM, Aditya Athalye wrote:
>>>
 Welcome, Anthony. 

 I'm not aware of complete applications that fit your requirement, 
 however I think you'll find value in the newly-minted Clojure Cookbook 
 http://clojure-cookbook.com/ ... many, many examples of real-world 
 problems, 
 across domains, solved by Clojure practitioners.

 All the examples and solutions are available here:
 https://github.com/clojure-cookbook/clojure-cookbook

 Cheers, and once again, welcome!



 On Wednesday, April 9, 2014 12:53:06 AM UTC+5:30, Anthony Ortiz wrote:
>
> Hello world!
>
> I'm a C# developer who recently went to an interview at a major bank 
> here in NYC and found that they've been using Clojure for their business 
> logic for over a year already and that got me curious, so I find myself 
> on 
> unfamiliar territory learning how to program in a functional language. So 
> far so good, Moxley Stratton's online tutorial combined with Try Clojure 
> (the online interpreter) has been very helpful (kudos to you guys!) and 
> I'm 
> now going through the book 'Programming Clojure'. So far I've seen a lot 
> of 
> utility/academic examples such as fibonacci but little in the way of an 
> act

Re: Real World Example

[Fergal Byrne]

I'm using both: Marginalia for straight docstrings in the source code [1],
lein-midje-doc for TDD in a literate style [2]. Some of the components I
wanted to discuss with others, for example a new design for a Scalar
Encoder [3] (I found and fixed a bug in the algorithm using this approach).

[1] http://fergalbyrne.github.io/uberdoc.html
[2] http://fergalbyrne.github.io/
[3] http://fergalbyrne.github.io/rdse.html

Regards,

Fergal Byrne


On Wed, Apr 9, 2014 at 2:20 PM, Colin Yates  wrote:

> lein-midje-doc really does look excellent.  I went with marginalia but if
> that had been around at the time I would have jumped on it without a doubt.
>
>
> On Wednesday, 9 April 2014 13:20:51 UTC+1, Fergal Byrne wrote:
>
>> Hi Colin,
>>
>> Cheers. I had exactly the same problem, so I've been trying out a few
>> other ideas. One is to use datalog (or cascalog etc) and represent
>> "objects" with entities and relationships between objects with refs (for
>> datalog). I have some enormous data structures (2-300m synapses per layer,
>> for example) but I find that Datomic and datalog are great for modelling
>> really big and complex structures.
>>
>> There's a datomic wrapper library called adi [1] which adds a nice
>> map-like interface on top of datalog. It's perfect for getting your schema
>> right (you start off with a big map and it automagically does the schema),
>> and you can do some really long link-following, but I'm not using it
>> extensively yet (because everything is data, you can use adi for schema
>> design and some queries, and raw datomic for the rest).
>>
>> I'll be writing extensively about each library or tool I've used on my
>> blog (see sig). I'm writing about lein-midje-doc (also by zcaudate) at the
>> moment, it's just wonderful.
>>
>> [1] https://github.com/zcaudate/adi
>>
>> Regards,
>>
>> Fergal Byrne
>>
>>
>> On Wed, Apr 9, 2014 at 12:22 PM, Colin Yates  wrote:
>>
>>> Hi Fergal,
>>>
>>> Thanks for those links.  I started using protocols and defrecords but I
>>> (maybe mistakenly) got the impression that they were "frowned upon".  As it
>>> turns out, maps (typically with a :type key) and multi methods go a long
>>> long way, but I still end up with fairly deep nesting of maps.
>>>
>>> Maybe that is the key - deep nesting of maps maybe cries out "one object
>>> [data model] to rule them all" and I need to decompose it further.
>>>
>>> Without types almost all the type hints would be either the map of
>>> sequence interface.  It isn't so much the structure that is obscure, but
>>> the semantics of what that structure is modelling.
>>>
>>> As I hinted at, I am sure it is because my implementation model is still
>>> influenced too much by my OO background.
>>>
>>> Onwards and upwards as they say.
>>>
>>> Col
>>>
>>>
>>> On Wednesday, 9 April 2014 11:37:52 UTC+1, Fergal Byrne wrote:
>>>
 Hi Anthony,

 I'm building a fairly large real-world system called Clortex [1], which
 is a rewrite of the Numenta Platform for Intelligent Computing (NuPIC) [2].
 As it's a greenfield project, I've chosen to use Clojure components all the
 way through instead of fitting in with Java-based or .Net-based frameworks.
 There are good reasons why you should do this if you can, but obviously
 that doesn't help you directly with your question.

 There are many people introducing Clojure as a component in an existing
 ecosystem, as Colin explains, but usually this is done deep inside a big
 Java or .Net shop, and they're not showing the world the code. One possible
 route would be to see if any of the big Java or CLR Open Source apps are
 looking at doing some subsystems in Clojure.

 Colin,

 Great to hear your experiences. I'm no expert, but it's likely that you
 could ease much of the pain using protocols, type hints and deftypes or
 records. Also, Typed Clojure [3] is definitely worth looking at.

 [1] Clortex will be public on Github shortly, see
 http://fergalbyrne.github.io for docs, http://inbits.com for blog.
  [2] http://numenta.org
 [3] https://github.com/clojure/core.typed

  Regards,

 Fergal Byrne




 On Wed, Apr 9, 2014 at 10:18 AM, Aditya Athalye 
 wrote:

> Welcome, Anthony.
>
> I'm not aware of complete applications that fit your requirement,
> however I think you'll find value in the newly-minted Clojure Cookbook
> http://clojure-cookbook.com/ ... many, many examples of real-world
> problems,
> across domains, solved by Clojure practitioners.
>
> All the examples and solutions are available here:
> https://github.com/clojure-cookbook/clojure-cookbook
>
> Cheers, and once again, welcome!
>
>
>
> On Wednesday, April 9, 2014 12:53:06 AM UTC+5:30, Anthony Ortiz wrote:
>>
>> Hello world!
>>
>> I'm a C# developer who recently went to an interview at a major bank
>> here in NYC and fo

Re: "true" lightweight threads on clojurescript?

[t x]

Regarding yield:

  Understood, thanks for clarifying my misunderstandings!

-- 
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.

Om and core.async: Necessary together?

[Kendall Buchanan]

Hi,

I have a question about Om's "Basic Tutorial", and perhaps core.async's 
role generally:

The example given in the section, "Intercomponent Communication", uses 
core.async for communication between two components. Is this necessary? Or, 
is it demonstration? It seems in testing that I can even more easily pass 
functions between components as I might a channel, but without go loops?

I've used React.js to some extent and obviously it lacks Clojurescripts 
asynchronous fanciness. Where might core.async excel in Om?

-- 
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: Om and core.async: Necessary together?

[David Nolen]

It's mostly for demonstration purposes, but I think it will be a common
pattern when more complex coordination is required. I think components
should probably communicate via callbacks and applications can glue things
together with core.async if it's beneficial.

David


On Wed, Apr 9, 2014 at 10:54 AM, Kendall Buchanan
wrote:

> Hi,
>
> I have a question about Om's "Basic Tutorial", and perhaps core.async's
> role generally:
>
> The example given in the section, "Intercomponent Communication", uses
> core.async for communication between two components. Is this necessary? Or,
> is it demonstration? It seems in testing that I can even more easily pass
> functions between components as I might a channel, but without go loops?
>
> I've used React.js to some extent and obviously it lacks Clojurescripts
> asynchronous fanciness. Where might core.async excel in Om?
>
> --
> 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.

Quotient *and* Remainder

[Anthony Ortiz]

Hello everyone,

I am able to get the quotient or remainder by doing the following :

(quot 22 7)
-> 3

(rem 22 7)
-> 1

Is there a way to get back both the quotient and the remainder in one 
calculation rather than performing two separate calculations? And I don't 
mean writing a function that does both calculations behind the scenes and 
returning a list of both results.

Cheers!

Anthony

-- 
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: Quotient *and* Remainder

[Sam Ritchie]

So you DON'T mean:

(juxt quot rem)

?


Anthony Ortiz 
April 9, 2014 11:01 AM
Hello everyone,

I am able to get the quotient or remainder by doing the following :

(quot 22 7)
-> 3

(rem 22 7)
-> 1

Is there a way to get back both the quotient and the remainder in one 
calculation rather than performing two separate calculations? And I 
don't mean writing a function that does both calculations behind the 
scenes and returning a list of both results.


Cheers!

Anthony
--
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.


--
Sam Ritchie (@sritchie)
Paddleguru Co-Founder
703.863.8561
www.paddleguru.com 
Twitter // Facebook 



--
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: Quotient *and* Remainder

[Ben Wolfson]

Many languages expose a quotrem or divmod function that returns both at
once, since they can both be calculated at once.


On Wed, Apr 9, 2014 at 10:05 AM, Sam Ritchie  wrote:

> So you DON'T mean:
>
> (juxt quot rem)
>
> ?
>
>   Anthony Ortiz 
>  April 9, 2014 11:01 AM
> Hello everyone,
>
> I am able to get the quotient or remainder by doing the following :
>
> (quot 22 7)
> -> 3
>
> (rem 22 7)
> -> 1
>
> Is there a way to get back both the quotient and the remainder in one
> calculation rather than performing two separate calculations? And I don't
> mean writing a function that does both calculations behind the scenes and
> returning a list of both results.
>
> Cheers!
>
> Anthony
> --
> 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.
>
>
> --
> Sam Ritchie (@sritchie)
> Paddleguru Co-Founder
> 703.863.8561
> www.paddleguru.com
> Twitter  // 
> Facebook
>
> --
> 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.
>



-- 
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 - 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: Quotient *and* Remainder

[Anthony Ortiz]

No because that's simply calling what is essentially the same function 
twice. Internally the quotient and remainder functions are the same, the 
only difference is which part of the result they return. If I call the 
quotient function and then I call the remainder function then I am 
performing the same exact division twice and from a performance perspective 
I am wondering if there's a function that returns both values but only 
performs the division calculation once.

On Wednesday, April 9, 2014 1:05:12 PM UTC-4, Sam Ritchie wrote:
>
> So you DON'T mean:
>
> (juxt quot rem)
>
> ?
>
>  

-- 
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: Quotient *and* Remainder

[James Reeves]

AFAIK, the JVM doesn't have a bytecode instruction for this, and therefore
there's no mechanism to do this in Clojure except by using quot and rem
separately.

- James


On 9 April 2014 18:11, Anthony Ortiz  wrote:

> No because that's simply calling what is essentially the same function
> twice. Internally the quotient and remainder functions are the same, the
> only difference is which part of the result they return. If I call the
> quotient function and then I call the remainder function then I am
> performing the same exact division twice and from a performance perspective
> I am wondering if there's a function that returns both values but only
> performs the division calculation once.
>
>
> On Wednesday, April 9, 2014 1:05:12 PM UTC-4, Sam Ritchie wrote:
>>
>> So you DON'T mean:
>>
>> (juxt quot rem)
>>
>> ?
>>
>>   --
> 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: Quotient *and* Remainder

[Anthony Ortiz]

Ah yes of course... the same applies to the CLR. 

On Wednesday, April 9, 2014 1:46:37 PM UTC-4, James Reeves wrote:
>
> AFAIK, the JVM doesn't have a bytecode instruction for this, and therefore 
> there's no mechanism to do this in Clojure except by using quot and rem 
> separately.
>
> - James
>
>
> On 9 April 2014 18:11, Anthony Ortiz >wrote:
>
>> No because that's simply calling what is essentially the same function 
>> twice. Internally the quotient and remainder functions are the same, the 
>> only difference is which part of the result they return. If I call the 
>> quotient function and then I call the remainder function then I am 
>> performing the same exact division twice and from a performance perspective 
>> I am wondering if there's a function that returns both values but only 
>> performs the division calculation once.
>>
>>
>> On Wednesday, April 9, 2014 1:05:12 PM UTC-4, Sam Ritchie wrote:
>>>
>>> So you DON'T mean:
>>>
>>> (juxt quot rem)
>>>
>>> ?
>>>
>>>   -- 
>> 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/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.

Questions regarding Map vs Record and usage

[Anthony Ortiz]

I see that there are several ways of instantiating a record :


(->Book "Lord of the Rings", "Tolkien")

(Book. "Lord of the Rings", "Tolkien")

#user.Book{:title "Lord of the Rings", :author "Tolkien"}


Questions :
1) The second version is referred to as the "original" version so I'm 
wondering which is the preferred method. 
2) Why is the third version not within a list? I thought that for the 
language to consider something "callable" it had to be the first argument 
in a list (eg : (+ 1 2))
3) The record that is returned via (def b [version of choice goes here]) is 
treated as a map when using the form (:title b) but doesn't treat it as a 
map when using the form (b :title) which seems pretty inconsistent to me; 
is there are valid reason for this inconsistency? I'm sure I'm missing 
something.

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.

Re: Real World Example

[Sean Corfield]

And for comparison at World Singles:

Clojure source 101 files 17952 total loc,
1321 fns, 666 of which are private,
203 vars, 8 macros, 29 atoms
Clojure tests 43 files 3790 total loc
Clojure WebDriver tests 14 files 560 total loc

(includes comments / whitespace etc - this is just the output of a simple 
script we run every week to track where we are on migration from our legacy 
code base and growth of our Clojure code)

The atoms are nearly all just caches. We're moving away from private functions.

Sean

On Apr 9, 2014, at 1:17 AM, Colin Yates  wrote:

> Gah - 5547 production, 2600 of tests.  A lot of that discrepancy is down to 
> the very extensive documentation that https://github.com/gdeer81/marginalia 
> allows you to write.
> 
> Please forgive any other mistakes, working on less than an hours sleep due to 
> my lovely kids.
> 
> On Wednesday, 9 April 2014 09:14:38 UTC+1, Colin Yates wrote:
> Hello back!
> 
> We are using Clojure on the JVM as the implementation language for a platform 
> that will underpin our applications for the next decade.  It is relatively 
> new and so far we have implemented the analysis module which is essentially a 
> generic charting engine.  
> 
> So far we have 5547 lines of production code (including comments) and 2600 
> lines of production code (including comments).
> 
> That doesn't sound like much but I can tell you it is replacing a similar, 
> but slightly smaller in scope analysis module written in Java which was 
> around 40K lines of production code.
> 
> Our architecture is Clojure on the back end exporting a number of JSON end 
> points.  It is backed by MS SQL using the fantastic 
> https://github.com/jkk/honeysql library.
> 
> For me, it is a dream coming from Java (and to a much lesser extent Scala), 
> but it does have its costs.  Moving from an OO world to an FP world isn't 
> easy, particularly in the shapes your solutions end up with.  I am also 
> feeling the pain of not having types - everything is a sequence.  This is a 
> joy but it also means a whole bunch of information (i.e. type information) is 
> lost.  
> 
> One of the wins in OO languages is the many number of places to hang semantic 
> information - the name of the class, the structure of the class, the names of 
> the methods etc.  I also find many more intermediary variables in OO where as 
> in Clojure it seems more idiomatic to have pipelines of transformation.  I am 
> feeling the lost of static types as I refactor APIs particularly.
> 
> This is undoubtedly my failing not Clojure's and I just need to absorb more 
> good FP paradigms.  Would I give up my emacs and Clojure and paredit 
> combination?  Not a chance :).
> 
> Col
> 
> On Tuesday, 8 April 2014 20:23:06 UTC+1, Anthony Ortiz wrote:
> Hello world!
> 
> I'm a C# developer who recently went to an interview at a major bank here in 
> NYC and found that they've been using Clojure for their business logic for 
> over a year already and that got me curious, so I find myself on unfamiliar 
> territory learning how to program in a functional language. So far so good, 
> Moxley Stratton's online tutorial combined with Try Clojure (the online 
> interpreter) has been very helpful (kudos to you guys!) and I'm now going 
> through the book 'Programming Clojure'. So far I've seen a lot of 
> utility/academic examples such as fibonacci but little in the way of an 
> actual real-world example of a top-to-bottom desktop application built using 
> Clojure on either the JVM or CLR, something simple that would demonstrate how 
> Clojure fits into the event-driven model on the client-side behind, let's 
> say, WPF, and how it would interact with more Clojure on the service-side 
> via, let's say, WCF. Does anyone know of an example they can direct me to?
> 
> Many thanks!
> 
> Anthony




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Questions regarding Map vs Record and usage

[A. Webb]

You can refer-in the first (factory function) to another namespace; for the 
second you'd have to import the class. I prefer the first. The third is 
special syntax for the reader.

As to the last question, I don't know, but it allows you to define your 
own. For example, 

(defrecord Book [title author] 
  clojure.lang.IFn 
  (invoke [this x] (get this x)) 
  (invoke [this x not-found] (get this x not-found)))

(def b (->Book "Lord of the Rings", "Tolkien"))

(b :title) ;=> "Lord of the Rings"

But you could alter the behavior as desired.


On Wednesday, April 9, 2014 1:51:01 PM UTC-5, Anthony Ortiz wrote:
>
> I see that there are several ways of instantiating a record :
>
>
> (->Book "Lord of the Rings", "Tolkien")
>
> (Book. "Lord of the Rings", "Tolkien")
>
> #user.Book{:title "Lord of the Rings", :author "Tolkien"}
>
>
> Questions :
> 1) The second version is referred to as the "original" version so I'm 
> wondering which is the preferred method. 
> 2) Why is the third version not within a list? I thought that for the 
> language to consider something "callable" it had to be the first argument 
> in a list (eg : (+ 1 2))
> 3) The record that is returned via (def b [version of choice goes here]) 
> is treated as a map when using the form (:title b) but doesn't treat it as 
> a map when using the form (b :title) which seems pretty inconsistent to me; 
> is there are valid reason for this inconsistency? I'm sure I'm missing 
> something.
>
> 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.

Re: every? expected behavior

[Sean Corfield]

On Apr 9, 2014, at 12:11 AM, Simon Brooke  wrote:
> Clojure is a bit muddled about nil. Nil, generally speaking, is the empty 
> list - which is why (every? #(= 77 %) nil) is true. But in Clojure, it's not 
> true that (= nil ()). There's no point in saying this is a mistake. But it 
> does result in some very hard to explain design decisions.

I think that's a bit misleading. If you look at the source of every? it checks 
(nil? (seq coll)) and returns true. In other words, it's not that "Nil, 
generally speaking, is the empty list", it's more to do with the idiomatic use 
of seq to determine whether a collection is an empty sequence or not.

We typically see:

(if (seq coll)
  ;; process coll as a non-empty sequence with first / rest
  ;; we're "done" - nothing to process
  )

I don't consider that a "hard to explain design decision" but it is a standard 
idiom that is initially unfamiliar to many people coming from certain other 
languages...

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

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





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Questions regarding Map vs Record and usage

[Ben Mabey]

On 4/9/14, 12:51 PM, Anthony Ortiz wrote:

I see that there are several ways of instantiating a record :


(->Book "Lord of the Rings", "Tolkien")

(Book. "Lord of the Rings", "Tolkien")

#user.Book{:title "Lord of the Rings", :author "Tolkien"}


You missed one:

(map->Book {:title "Lord of the Rings", :author "Tolkien"})



Questions :
1) The second version is referred to as the "original" version so I'm 
wondering which is the preferred method.
The helper constructor fns are preferred and not the older dot form.  
IIRCC you have to import the record to use that constructor, but with 
the constructor fns you can :require them like any other clojure fn.  
Not a big deal, but it is nicer and doesn't let the interop abstraction 
bleed into your ns declarations.


2) Why is the third version not within a list? I thought that for the 
language to consider something "callable" it had to be the first 
argument in a list (eg : (+ 1 2))
Your third version is using tagged literals and so the semantics of the 
reader is different in that case.  See 
http://clojure.org/reader#The%20Reader--extensible%20data%20notation%20(edn)
3) The record that is returned via (def b [version of choice goes 
here]) is treated as a map when using the form (:title b) but doesn't 
treat it as a map when using the form (b :title) which seems pretty 
inconsistent to me; is there are valid reason for this inconsistency? 
I'm sure I'm missing something.


I agree that it is inconsistent.  I don't know why that inconsistency 
exists but I would be curious to know the reason if someone on the list 
knows...  As A. Webb just pointed out you can add that behavior yourself 
if you want to.


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.


--
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.

Logo usage

[Plínio Balduino]

Hi there

Is there any restriction about the usage of Clojure logo in magazines, books 
and printed materials?

Thank you

Plinio Balduino

-- 
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: Logo usage

[Tim Visher]

On Wed, Apr 9, 2014 at 4:06 PM, Plínio Balduino  wrote:

> Hi there
>
> Is there any restriction about the usage of Clojure logo in magazines,
> books and printed materials?
>

Yes. You must get permission from Tom Hickey, I believe, who listens on
this list (or at least used to).

--

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail

-- 
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: Questions regarding Map vs Record and usage

[Greg D]

FWIW, I use:

   - (->Book "Lord of the Rings", "Tolkien")
  - when I define the record instance with the default fields, and the 
  number of default fields is a small number
   - (map->Book {:title "The Fellowship of the Ring",
  :author "Tolkien",
  :series "The Lord of the Rings",
  :publisher "Mariner Books",
  :year 2012,
  :ISBN-10 "0547928211",
  :my-rating 10}) 
  - The explicit key names are good documentation when 
  - there are many fields in the defrecord, or
 - when adding entries not in the defrecord (eg. my-rating)
  
Greg

-- 
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: Any experience with Cognitect?

[Mike Haney]

Thanks for the feedback.

Resume updated - check
Cover letter written - check
Email sent - check
Ego intact - pending

-- 
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: Any experience with Cognitect?

[Tim Visher]

👍


On Wed, Apr 9, 2014 at 4:47 PM, Mike Haney  wrote:

> Thanks for the feedback.
>
> Resume updated - check
> Cover letter written - check
> Email sent - check
> Ego intact - pending
>
> --
> 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: Meta-eX - The Music of Code

[Samuel Aaron]

For those that enjoyed the interview and are interested in how we sound this 
month, we just pushed out a new track, lovingly live coded in Clojure:

https://soundcloud.com/meta-ex/spiked-with-recursive-dreams

Sam

---
http://sam.aaron.name

On 2 Apr 2014, at 21:33, Samuel Aaron  wrote:

> Howdy there Clojuristaritorians!
> 
> For those of you that enjoy seeing applications of code in none-business 
> contexts, you might be excited to see Clojure being mentioned in Imperica - a 
> Digital Arts & Culture Magazine:
> 
> http://www.imperica.com/en/in-conversation-with/meta-ex-the-music-of-code
> 
> Enjoy, and happy (arts) hacking!
> 
> Sam
> 
> ---
> http://sam.aaron.name

-- 
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: Om and core.async: Necessary together?

[Brendan Stromberger]

How can one build up the intuition to know, in what situation, whether it 
would be more beneficial to use callbacks or channels? Are there 
'rules-of-thumb' that I could follow until that intuition is established?

On Wednesday, April 9, 2014 8:40:19 AM UTC-7, David Nolen wrote:
>
> It's mostly for demonstration purposes, but I think it will be a common 
> pattern when more complex coordination is required. I think components 
> should probably communicate via callbacks and applications can glue things 
> together with core.async if it's beneficial.
>
> David
>
>
> On Wed, Apr 9, 2014 at 10:54 AM, Kendall Buchanan 
> 
> > wrote:
>
>> Hi,
>>
>> I have a question about Om's "Basic Tutorial", and perhaps core.async's 
>> role generally:
>>
>> The example given in the section, "Intercomponent Communication", uses 
>> core.async for communication between two components. Is this necessary? Or, 
>> is it demonstration? It seems in testing that I can even more easily pass 
>> functions between components as I might a channel, but without go loops?
>>
>> I've used React.js to some extent and obviously it lacks Clojurescripts 
>> asynchronous fanciness. Where might core.async excel in Om?
>>
>> -- 
>> 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/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: Om and core.async: Necessary together?

[David Nolen]

Reusable components - use callbacks
Application components (non-reusable or less re-usable) - use channels

David


On Wed, Apr 9, 2014 at 7:53 PM, Brendan Stromberger <
brendanstromber...@gmail.com> wrote:

> How can one build up the intuition to know, in what situation, whether it
> would be more beneficial to use callbacks or channels? Are there
> 'rules-of-thumb' that I could follow until that intuition is established?
>
>
> On Wednesday, April 9, 2014 8:40:19 AM UTC-7, David Nolen wrote:
>
>> It's mostly for demonstration purposes, but I think it will be a common
>> pattern when more complex coordination is required. I think components
>> should probably communicate via callbacks and applications can glue things
>> together with core.async if it's beneficial.
>>
>> David
>>
>>
>> On Wed, Apr 9, 2014 at 10:54 AM, Kendall Buchanan > > wrote:
>>
>>> Hi,
>>>
>>> I have a question about Om's "Basic Tutorial", and perhaps core.async's
>>> role generally:
>>>
>>> The example given in the section, "Intercomponent Communication", uses
>>> core.async for communication between two components. Is this necessary? Or,
>>> is it demonstration? It seems in testing that I can even more easily pass
>>> functions between components as I might a channel, but without go loops?
>>>
>>> I've used React.js to some extent and obviously it lacks Clojurescripts
>>> asynchronous fanciness. Where might core.async excel in Om?
>>>
>>> --
>>> 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/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.
>

-- 
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: Om and core.async: Necessary together?

[David Nolen]

Also don't use a channel unless you actually need complex coordination. I
would always default to a callback first.

David


On Wed, Apr 9, 2014 at 7:56 PM, David Nolen  wrote:

> Reusable components - use callbacks
> Application components (non-reusable or less re-usable) - use channels
>
> David
>
>
> On Wed, Apr 9, 2014 at 7:53 PM, Brendan Stromberger <
> brendanstromber...@gmail.com> wrote:
>
>> How can one build up the intuition to know, in what situation, whether it
>> would be more beneficial to use callbacks or channels? Are there
>> 'rules-of-thumb' that I could follow until that intuition is established?
>>
>>
>> On Wednesday, April 9, 2014 8:40:19 AM UTC-7, David Nolen wrote:
>>
>>> It's mostly for demonstration purposes, but I think it will be a common
>>> pattern when more complex coordination is required. I think components
>>> should probably communicate via callbacks and applications can glue things
>>> together with core.async if it's beneficial.
>>>
>>> David
>>>
>>>
>>> On Wed, Apr 9, 2014 at 10:54 AM, Kendall Buchanan <
>>> ken...@teachbanzai.com> wrote:
>>>
 Hi,

 I have a question about Om's "Basic Tutorial", and perhaps core.async's
 role generally:

 The example given in the section, "Intercomponent Communication", uses
 core.async for communication between two components. Is this necessary? Or,
 is it demonstration? It seems in testing that I can even more easily pass
 functions between components as I might a channel, but without go loops?

 I've used React.js to some extent and obviously it lacks Clojurescripts
 asynchronous fanciness. Where might core.async excel in Om?

 --
 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/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.
>>
>
>

-- 
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: Logo usage

[Plínio Balduino]

Thank you


On Wed, Apr 9, 2014 at 5:16 PM, Tim Visher  wrote:

> On Wed, Apr 9, 2014 at 4:06 PM, Plínio Balduino wrote:
>
>> Hi there
>>
>> Is there any restriction about the usage of Clojure logo in magazines,
>> books and printed materials?
>>
>
> Yes. You must get permission from Tom Hickey, I believe, who listens on
> this list (or at least used to).
>
> --
>
> In Christ,
>
> Timmy V.
>
> http://blog.twonegatives.com/
> http://five.sentenc.es/ -- Spend less time on mail
>
> --
> 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: Meta-eX - The Music of Code

[Earl Jenkins]

Good stuff, all the hard work you've done in the field of live coding, yet 
no mention of Meta-ex nor clojure in the Computer Music Journal which has a 
whole issue dedicated to this subject  ;(
of course this is just from me scanning the issue.

keep up the inspiring work
I'll soon brush up on my theory for reentry into overtone

http://www.mitpressjournals.org/toc/comj/38/1

On Wednesday, April 2, 2014 1:33:54 PM UTC-7, Sam Aaron wrote:
>
> Howdy there Clojuristaritorians! 
>
> For those of you that enjoy seeing applications of code in none-business 
> contexts, you might be excited to see Clojure being mentioned in Imperica - 
> a Digital Arts & Culture Magazine: 
>
> http://www.imperica.com/en/in-conversation-with/meta-ex-the-music-of-code 
>
> Enjoy, and happy (arts) hacking! 
>
> Sam 
>
> --- 
> http://sam.aaron.name

-- 
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: Om and core.async: Necessary together?

[Mike Haney]

David,

This seems to be a different take on things than you proposed in your 
series of CSP articles last summer.  I'm not saying that is a bad thing - 
if an idea doesn't pan out, it needs to be scrapped (and most of us cling 
to bad ideas longer than we should).  I'm just curious why the change of 
heart (if that is the case, maybe I'm just misunderstanding you).  You've 
mentioned reusability a couple of times, but I just don't see how the Om 
approach improves that over the architecture you described in those 
articles.

What attracted me to the React approach initially was how well it seemed to 
fit in with CSP.  The idea of separate coordinated processes manipulating 
the application state, while the UI representation is just a function of 
that state (i.e. a pure transformation from the app state to a DOM, or 
virtual DOM in React's case) is very appealing. I know things are usually 
uglier in practice, and you have far more experience with this stuff than I 
do, so maybe you have just hit enough ugly parts to rethink the approach 
(if so, please share)?

I thought I had figured out the missing piece to my comprehension when I 
read one of your posts on the Clojurescript group the other day, where you 
talked about Om components that don't render.  I didn't even know that was 
possible before you mentioned it, and then the lightbulb came on and I 
started thinking about how to adapt your CSP examples in that context.  It 
seems like you could have processes like a highlighter or selector that are 
implemented as non-rendering Om components and they could wrap and compose 
with other components.  I was anxious to try that out on my current 
project, but I've been tied up on Datomic stuff all week and didn't get the 
chance yet.

But after reading this post, I'm not so sure about that now.  I know you've 
been thinking through some of the reusability issues over the last week, so 
maybe I just need to wait until you write up your ideas.  I really want to 
figure this out and use it on a non-trivial real-world project (the one I 
mentioned above).  So if you need a lab rat for some of these ideas...   

On Wednesday, April 9, 2014 6:57:50 PM UTC-5, David Nolen wrote:
>
> Also don't use a channel unless you actually need complex coordination. I 
> would always default to a callback first.
>
> David
>
>
> On Wed, Apr 9, 2014 at 7:56 PM, David Nolen 
> > wrote:
>
>> Reusable components - use callbacks
>> Application components (non-reusable or less re-usable) - use channels
>>
>> David
>>
>>
>> On Wed, Apr 9, 2014 at 7:53 PM, Brendan Stromberger <
>> brendanst...@gmail.com > wrote:
>>
>>> How can one build up the intuition to know, in what situation, whether 
>>> it would be more beneficial to use callbacks or channels? Are there 
>>> 'rules-of-thumb' that I could follow until that intuition is established?
>>>
>>>
>>> On Wednesday, April 9, 2014 8:40:19 AM UTC-7, David Nolen wrote:
>>>
 It's mostly for demonstration purposes, but I think it will be a common 
 pattern when more complex coordination is required. I think components 
 should probably communicate via callbacks and applications can glue things 
 together with core.async if it's beneficial.

 David


 On Wed, Apr 9, 2014 at 10:54 AM, Kendall Buchanan <
 ken...@teachbanzai.com> wrote:

> Hi,
>
> I have a question about Om's "Basic Tutorial", and perhaps 
> core.async's role generally:
>
> The example given in the section, "Intercomponent Communication", uses 
> core.async for communication between two components. Is this necessary? 
> Or, 
> is it demonstration? It seems in testing that I can even more easily pass 
> functions between components as I might a channel, but without go loops?
>
> I've used React.js to some extent and obviously it lacks 
> Clojurescripts asynchronous fanciness. Where might core.async excel in Om?
>
> -- 
> 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/d/optout.
>

  -- 
>>> 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 

Re: Om and core.async: Necessary together?

[David Nolen]

I would probably still do an async autocompleter component with channels
where it seems useful *internally*. I just wouldn't expose channels as an
interface to users of this component. I think most of points from my CSP
posts still hold even with React/Om.

David


On Wed, Apr 9, 2014 at 11:57 PM, Mike Haney  wrote:

> David,
>
> This seems to be a different take on things than you proposed in your
> series of CSP articles last summer.  I'm not saying that is a bad thing -
> if an idea doesn't pan out, it needs to be scrapped (and most of us cling
> to bad ideas longer than we should).  I'm just curious why the change of
> heart (if that is the case, maybe I'm just misunderstanding you).  You've
> mentioned reusability a couple of times, but I just don't see how the Om
> approach improves that over the architecture you described in those
> articles.
>
> What attracted me to the React approach initially was how well it seemed
> to fit in with CSP.  The idea of separate coordinated processes
> manipulating the application state, while the UI representation is just a
> function of that state (i.e. a pure transformation from the app state to a
> DOM, or virtual DOM in React's case) is very appealing. I know things are
> usually uglier in practice, and you have far more experience with this
> stuff than I do, so maybe you have just hit enough ugly parts to rethink
> the approach (if so, please share)?
>
> I thought I had figured out the missing piece to my comprehension when I
> read one of your posts on the Clojurescript group the other day, where you
> talked about Om components that don't render.  I didn't even know that was
> possible before you mentioned it, and then the lightbulb came on and I
> started thinking about how to adapt your CSP examples in that context.  It
> seems like you could have processes like a highlighter or selector that are
> implemented as non-rendering Om components and they could wrap and compose
> with other components.  I was anxious to try that out on my current
> project, but I've been tied up on Datomic stuff all week and didn't get the
> chance yet.
>
> But after reading this post, I'm not so sure about that now.  I know
> you've been thinking through some of the reusability issues over the last
> week, so maybe I just need to wait until you write up your ideas.  I really
> want to figure this out and use it on a non-trivial real-world project (the
> one I mentioned above).  So if you need a lab rat for some of these
> ideas...
>
>
> On Wednesday, April 9, 2014 6:57:50 PM UTC-5, David Nolen wrote:
>
>> Also don't use a channel unless you actually need complex coordination. I
>> would always default to a callback first.
>>
>> David
>>
>>
>> On Wed, Apr 9, 2014 at 7:56 PM, David Nolen  wrote:
>>
>>> Reusable components - use callbacks
>>> Application components (non-reusable or less re-usable) - use channels
>>>
>>> David
>>>
>>>
>>> On Wed, Apr 9, 2014 at 7:53 PM, Brendan Stromberger <
>>> brendanst...@gmail.com> wrote:
>>>
 How can one build up the intuition to know, in what situation, whether
 it would be more beneficial to use callbacks or channels? Are there
 'rules-of-thumb' that I could follow until that intuition is established?


 On Wednesday, April 9, 2014 8:40:19 AM UTC-7, David Nolen wrote:

> It's mostly for demonstration purposes, but I think it will be a
> common pattern when more complex coordination is required. I think
> components should probably communicate via callbacks and applications can
> glue things together with core.async if it's beneficial.
>
> David
>
>
> On Wed, Apr 9, 2014 at 10:54 AM, Kendall Buchanan <
> ken...@teachbanzai.com> wrote:
>
>> Hi,
>>
>> I have a question about Om's "Basic Tutorial", and perhaps
>> core.async's role generally:
>>
>> The example given in the section, "Intercomponent Communication",
>> uses core.async for communication between two components. Is this
>> necessary? Or, is it demonstration? It seems in testing that I can even
>> more easily pass functions between components as I might a channel, but
>> without go loops?
>>
>> I've used React.js to some extent and obviously it lacks
>> Clojurescripts asynchronous fanciness. Where might core.async excel in 
>> Om?
>>
>> --
>> 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