Re: soft question: should remote channels appear like local channels

[Cedric Greevey]

You do need to handle connection loss in some way, which is never a concern
with purely local channels. The middle level needs to detect a broken
connection (as distinct from a full buffer on put or an empty one on take)
and signal it somehow (OOB value, exception, put to a control channel, or
etc., possibly after one or more automatic attempts to reestablish the
connection in a manner transparent to the rest of the system).


On Fri, Jan 31, 2014 at 2:36 AM,  wrote:

>  My question would be "Why not?"
>
> If you have a client using core.async and a server using core.async and
> you have a library that feeds data from certain channels back and forth
> over websockets, then you have channels everywhere.
>
> So I'm not sure why you think your "con" is actually a thing?
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org
> World Singles, LLC - http://worldsingles.com
>
> *From:* t x 
> *Sent:* Thursday, January 30, 2014 9:43 PM
> *To:* clojure@googlegroups.com
>
> Hi,
>
> With apologies for a soft question:
>
> This question is NOT:
>
>   I'm in a situation where client = cljs, server = clj, and I want to
> figure out how to setup a core.async channel, using pr-str and
> edn/read-string, where I can seamlessly push data back and forth
> between client and server.
>
> This question is:
>
>   Should I do the above?
>
>   The pro being: yay, channels everywhere, everything looks the same.
>
>   The con being: a local core.async channel and a remote core.async
> channel over a websocket are _NOT_ the same thing, and thus should not
> appear to be the same thing.
>
> ## Responses:
>
> Although detailed responses are always appreciated, given the nature
> of this "soft" question, responses of "go read _link_" are perfectly
> welcome too.
>
> I suspect someone in this world has thought deeply about the question,
> written up their insights, and pointing me at this primary resource
> (rather than trying to summarize it in a three paragraph email) is
> perfectly fine too.
>
> 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/groups/opt_out.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: ANN: Another binary parser combinator - this time for java's streams

[Steffen Dienst]

Thanks, I fixed the documentation issues. Feel free to share your id3 tags 
parser, if you like :) You can see that mine is still stuck at the very 
beginning..


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

Re: When should I use non-blocking >! / threads and blocking >!! / goroutines with clojure core.async

[Jozef Wagner]

Thank you for the clarification. If I understand it correctly, these 
callbacks in case of go 'threads' resume the parked state machine, so if 
there is a blocking IO inside go block, it ends up waiting in one of these 
callbacks, thus tying up a thread from a fixed sized pool until IO 
operation unblocks it.

JW

On Friday, January 31, 2014 4:51:11 AM UTC+1, tbc++ wrote:
>
> To quote Jozef "it can happen all in one thread". This is somewhat true, 
> there are some rare situations where this can happen, but it is fairly 
> rare. 
>
> Many times putting a value into a channel will mean that the callback on 
> the other end of the channel needs to be dispatched. In that case Mauricio 
> is correct, these callbacks are executed in a fixed sized thread pool. 
>
> Timothy
>
>
> On Thu, Jan 30, 2014 at 8:41 PM, Mauricio Aldazosa <
> mauricio...@ciencias.unam.mx > wrote:
>
>>
>> On Thu, Jan 30, 2014 at 12:48 PM, Jozef Wagner 
>> 
>> > wrote:
>>  
>>>
>>> go blocks, together with >!, >> threads and are not run in separate thread. There is no thread pool for go 
>>> blocks.
>>>
>>
>> I thought that go blocks do run in a thread pool of size 42 + (2 * Num of 
>> processors). In the definition of the go macro there is a 
>> dispatch/runwhose
>>  
>> docstringsays
>>  it uses a thread pool. 
>>
>> Am I misunderstanding something?
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

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

Re: David Nolen's sudoku solver not compatible with Peter Norvig's generator?

[Jim - FooBar();]

On 31/01/14 00:47, Norman Richards wrote:


I don't know how many solutions there are, but it seems like there are 
a lot...  I think you are just generating all of them and it's taking 
a long time.


spot on!!! I was just being stupid (again)...tried with `first` and 
worked immediately :)


Thanks!

Jim

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

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

Re: Integration testing in Clojure

[Nebojša Stričević]

Hey,

I had success using https://github.com/xeqi/kerodon for integration testing.

Cheers,

Strika

On Thursday, January 30, 2014 10:41:45 PM UTC+1, ronen wrote:
>
> Hey Conan, I'm using midje with selectors to separate integration test 
> from unit test (like for example in 
> thisproject)
>  
>
> Regarding VCR iv spotted https://github.com/sonian/cartridge which seems 
> to offer similar functionality
>
> From initial look at maven failsafe  it looks like a workaround for maven 
> particularities I think that with lein and midje you have all you need to 
> get going
>
> On Wednesday, January 29, 2014 5:47:15 PM UTC+2, Conan Cook wrote:
>>
>> Hi, I'm trying to decide how we should go about testing our services that 
>> are written in Clojure.  I'm used to doing this using Maven, where I'd 
>> expect to fire up things like a webserver and database and then throw 
>> requests at them, using stuff like the 
>> maven-failsafe-plugin.
>>  
>>  I can mock calls to external systems using something like 
>> VCR. 
>>  My aim is to write a set of integration tests to give me confidence that 
>> the various services that make up our applications are interoperating 
>> correctly.  
>>
>> Can anyone suggest a good way of doing this in Clojure?  At the moment 
>> we're using Leiningen and Midje, and the projects are pure Clojure, and for 
>> this reason I'd like (if possible) to avoid introducing something like 
>> Maven or Gradle, but if that's the best option then I'm happy with that.
>>
>> 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/groups/opt_out.

Re: Recommendations for parsing/validating a JSON structure

[Ivan L]

Schema is really awesome.  Very easy to use and even though the validation 
messages are a little cryptic, I think they'll work for libraries.

My only irk with it so far is that it appears to modify the function 
prototype.  
(extend-protocol Schema  js/Function ...

Not sure why they need to extend it directly, but its modifying a core 
object prototype is considered a big no-no (just look at the backlash to 
prototype.js).

Other than that though, been loving it.


On Monday, January 27, 2014 7:43:52 AM UTC-5, Korny wrote:
>
> Parsing is easy - use either https://github.com/clojure/data.json or 
> https://github.com/dakrone/cheshire (Cheshire used to have some 
> advantages over data.json but I have the impression data.json has caught 
> up).
>
> For validation I've used Prismatic Schema - 
> https://github.com/prismatic/schema - it's good for structural 
> validation, correct data types, valid keys etc.  If you want user-friendly 
> validation failures for individual fields you might want to use something 
> more user-focused - there are quite a few validation libraries at 
> http://www.clojure-toolbox.com/ you could try.
>
> - Korny
> On 27 Jan 2014 12:17, "David Simmons" > 
> wrote:
>
>> Hi Folks.
>>
>> I'm writing a web app which receives a JSON structure. I'd like to 
>> validate that the structure is correct i.e. mandatory fields are present, 
>> and then convert into the relevant Clojure data structure. As a bonus if  a 
>> particular field in the JSON structure is incorrect I'd like to be able to 
>> define the error message generated (in a similar way I can do for 
>> noir.validation).
>>
>> Does anyone have any recommended libraries or the best way to approach 
>> this issue - I'm sure I'm not the first with this requirement.
>>
>> cheers
>>
>> Dave
>>  
>> -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>  

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

Re: soft question: should remote channels appear like local channels

[Thomas Heller]

Hi,

only advice I can give is: no or don't.

In the many years I have done web development one of the most important 
things I have learned is to keep the server as stateless as possible. Data 
is easily kept externally while channels are not. Channels also aren't 
exactly simple state since they are usually also attached to some go-blocks 
and the like. While its very common the handle disconnects of the client on 
the server und not as common to handle disconnects of the server on the 
client. 

Disconnects are very frequent so you need to respect them, machines go to 
sleep, wireless goes away, servers get restarted, jvms crash, etc.

Never assume that a "remote" channel actually exist when writing to it, 
unless you have some really solid error recovery (which probably is more 
work than using traditional approaches).

Just my 2 cents.

/thomas

On Friday, January 31, 2014 6:43:14 AM UTC+1, t x wrote:
>
> Hi, 
>
> With apologies for a soft question: 
>
> This question is NOT: 
>
>   I'm in a situation where client = cljs, server = clj, and I want to 
> figure out how to setup a core.async channel, using pr-str and 
> edn/read-string, where I can seamlessly push data back and forth 
> between client and server. 
>
> This question is: 
>
>   Should I do the above? 
>
>   The pro being: yay, channels everywhere, everything looks the same. 
>
>   The con being: a local core.async channel and a remote core.async 
> channel over a websocket are _NOT_ the same thing, and thus should not 
> appear to be the same thing. 
>
> ## Responses: 
>
> Although detailed responses are always appreciated, given the nature 
> of this "soft" question, responses of "go read _link_" are perfectly 
> welcome too. 
>
> I suspect someone in this world has thought deeply about the question, 
> written up their insights, and pointing me at this primary resource 
> (rather than trying to summarize it in a three paragraph email) is 
> perfectly fine too. 
>
> 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/groups/opt_out.

Re: Integration testing in Clojure

[mynomoto]

You could also use https://github.com/semperos/clj-webdriver for 
integration testing.

On Wednesday, January 29, 2014 1:47:15 PM UTC-2, Conan Cook wrote:
>
> Hi, I'm trying to decide how we should go about testing our services that 
> are written in Clojure.  I'm used to doing this using Maven, where I'd 
> expect to fire up things like a webserver and database and then throw 
> requests at them, using stuff like the 
> maven-failsafe-plugin.
>  
>  I can mock calls to external systems using something like 
> VCR. 
>  My aim is to write a set of integration tests to give me confidence that 
> the various services that make up our applications are interoperating 
> correctly.  
>
> Can anyone suggest a good way of doing this in Clojure?  At the moment 
> we're using Leiningen and Midje, and the projects are pure Clojure, and for 
> this reason I'd like (if possible) to avoid introducing something like 
> Maven or Gradle, but if that's the best option then I'm happy with that.
>
> 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/groups/opt_out.

Re: [ANN] clj-refactor.el 0.10.0

[Akhil Wali]

Great job by the clj-refactor.el team!! 
Really nice additions.

On Thursday, January 30, 2014 6:43:36 PM UTC+5:30, Magnar Sveen wrote:
>
> clj-refactor.el
> Since the last update, there's been lots of activity for 
> clj-refactor.el
> . Alex Baranosky  and Lars 
> Andersen have 
> joined the team, and here are the new features:
> More let refactorings
>
> Starting with:
>
> (defn handle-request
>   (let [body (find-body abc)]
> {:status 200
>  :body body})) 
>
> With the cursor in front of 200, I do cljr-move-to-let:
>
> (defn handle-request
>   (let [body (find-body abc)
> X 200]
> {:status X
>  :body body}))
>
> Again I have two cursors where the Xes are, so I type out the name, and 
> press enter:
>
> (defn handle-request
>   (let [body (find-body abc)
> status 200]
> {:status status
>  :body body}))
>
> Pretty handy. And it works with if-let and when-let too.
>
> *Thread first all, thread last all, unwind all*
>
> Convenience functions to thread all the way down, or unwind the entire 
> threading macro.
> Cycling Privacy
>
> Given this function:
>
> (defn add [a b]
>   (+ a b))
>
> I do cljr-cycle-privacy:
>
> (defn- add [a b]
>   (+ a b))
>
> I do cljr-cycle-privacy again to return to the original:
>
> (defn add [a b]
>   (+ a b))
>
> Given this def:
>
> (def config
>   "docs"
>   {:env "staging"})
>
> I do cljr-cycle-privacy:
>
> (def ^:private config
>   "docs"
>   {:env "staging"})
>
> I do cljr-cycle-privacy again to return to the original:
>
> (def config
>   "docs"
>   {:env "staging"})
>
> Cycling 
> Collection Type
>
> Given this collection:
>
> (:a 1 :b 2)
>
> I do cljr-cycle-coll to return:
>
> {:a 1 :b 2}
>
> ... and then 3 more times:
>
> [:a 1 :b 2]#{:a 1 :b 2}(:a 1 :b 2)
>
>
> Cycling
>  
> Between Strings and Keywords
>
> Given this string:
>
> "refactor"
>
> I do cljr-cycle-stringlike to return:
>
> :refactor
>
> ... and then 3 more times:
>
> "refactor":refactor"refactor"
>
> Thanks to Jay Fields  and 
> emacs-live for 
> these cycling features. Good idea!
> Destructuring keys
>
> Given this:
>
> (defn- render-recommendation [rec]
>   (list [:h3 (:title rec)]
> [:p (:by rec)]
> [:p (:blurb rec) " "
>  (render-link (:link rec))]))
>
> I place the cursor on rec inside [rec] and do cljr-destructure-keys:
>
> (defn- render-recommendation [{:keys [title by blurb link]}]
>   (list [:h3 title]
> [:p by]
> [:p blurb " "
>  (render-link link)]))
>
> If rec had still been in use, it would have added an :as clause.
>
> For now this feature is limited to top-level symbols in a let form. PR 
> welcome.
> Stop referring
>
> Given this:
>
> (ns cljr.core
>   (:require [my.lib :as lib :refer [a b]]))
> (+ (a 1) (b 2))
>
> I place cursor on my.lib and do cljr-stop-referring:
>
> (ns cljr.core
>   (:require [my.lib :as lib]))
> (+ (lib/a 1) (lib/b 2))
>
> Even more
> There's also 
>
>-  cljr-sort-ns to sort the namespace
>-  cljr-replace-use to replace old :use statements with new :refer 
>:all statements.
>-  cljr-add-declaration to declare the defn you're in.
>
> So, clj-refactor.el still knows nothing about your code. At some point we 
> want to piggyback on an nrepl-connection to do the tricky parts of 
> refactoring, but for now we're happy to make life a little easier.
>
> Hope you enjoy!
>
>
>

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

Re: Integration testing in Clojure

[Conan Cook]

Thanks for the suggstions!  I've managed to fire up my app just using 
midje's (against-background) macro, and am hitting an H2 database as well.  

@ronen That cartridge library looks like just the ticket for taking the 
last bits offline, I'll give it a shot next week!

@Nebojša/mynomoto I'll pass both of those tools onto our front-end testing 
guys, they'll be pretty happy to have options like those as well!

I'll come back with the results if I find any problems or anything that's 
particularly awesome.

Conan


On Friday, January 31, 2014 11:08:00 AM UTC, mynomoto wrote:
>
> You could also use https://github.com/semperos/clj-webdriver for 
> integration testing.
>
> On Wednesday, January 29, 2014 1:47:15 PM UTC-2, Conan Cook wrote:
>>
>> Hi, I'm trying to decide how we should go about testing our services that 
>> are written in Clojure.  I'm used to doing this using Maven, where I'd 
>> expect to fire up things like a webserver and database and then throw 
>> requests at them, using stuff like the 
>> maven-failsafe-plugin.
>>  
>>  I can mock calls to external systems using something like 
>> VCR. 
>>  My aim is to write a set of integration tests to give me confidence that 
>> the various services that make up our applications are interoperating 
>> correctly.  
>>
>> Can anyone suggest a good way of doing this in Clojure?  At the moment 
>> we're using Leiningen and Midje, and the projects are pure Clojure, and for 
>> this reason I'd like (if possible) to avoid introducing something like 
>> Maven or Gradle, but if that's the best option then I'm happy with that.
>>
>> 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/groups/opt_out.

Re: soft question: should remote channels appear like local channels

[Timothy Baldridge]

A quick thought...there really isn't much of a difference between a failing
network connection and a (chan (dropping-buffer 1024))

Both may (or may not) drop information that you put into them, but also,
both can be expected to work "normally" as long as certain conditions hold.
Namely, the net connection doesn't die, or the consumer can keep up with
the data being put into the dropping buffer.

So that's my advice, if you can't guarantee the data will reach the remote
end, or you can't perfectly match core.async back pressure semantics,
simply use a dropping buffer at the edges and code to those semantics.

Timothy

Timothy


On Fri, Jan 31, 2014 at 3:37 AM, Thomas Heller  wrote:

> Hi,
>
> only advice I can give is: no or don't.
>
> In the many years I have done web development one of the most important
> things I have learned is to keep the server as stateless as possible. Data
> is easily kept externally while channels are not. Channels also aren't
> exactly simple state since they are usually also attached to some go-blocks
> and the like. While its very common the handle disconnects of the client on
> the server und not as common to handle disconnects of the server on the
> client.
>
> Disconnects are very frequent so you need to respect them, machines go to
> sleep, wireless goes away, servers get restarted, jvms crash, etc.
>
> Never assume that a "remote" channel actually exist when writing to it,
> unless you have some really solid error recovery (which probably is more
> work than using traditional approaches).
>
> Just my 2 cents.
>
> /thomas
>
>
> On Friday, January 31, 2014 6:43:14 AM UTC+1, t x wrote:
>>
>> Hi,
>>
>> With apologies for a soft question:
>>
>> This question is NOT:
>>
>>   I'm in a situation where client = cljs, server = clj, and I want to
>> figure out how to setup a core.async channel, using pr-str and
>> edn/read-string, where I can seamlessly push data back and forth
>> between client and server.
>>
>> This question is:
>>
>>   Should I do the above?
>>
>>   The pro being: yay, channels everywhere, everything looks the same.
>>
>>   The con being: a local core.async channel and a remote core.async
>> channel over a websocket are _NOT_ the same thing, and thus should not
>> appear to be the same thing.
>>
>> ## Responses:
>>
>> Although detailed responses are always appreciated, given the nature
>> of this "soft" question, responses of "go read _link_" are perfectly
>> welcome too.
>>
>> I suspect someone in this world has thought deeply about the question,
>> written up their insights, and pointing me at this primary resource
>> (rather than trying to summarize it in a three paragraph email) is
>> perfectly fine too.
>>
>> 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/groups/opt_out.
>



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

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

Should predicates always have one argument?

[Ryan]

Hello,

I am wondering if all my predicates should be one argument functions 
because I run into a couple of cases where I needed more than one.

For example, I have a function called valid-params? which takes two 
parameters; the validator to use and a maps parameter.
Is this approach wrong/not the clojure way?

What are my alternatives? Should I just use a different function name which 
does not have a question mark at the end that implies that is a predicate?

Cheers,

Ryan

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

Re: Should predicates always have one argument?

[Andy Fingerhut]

While most of the functions and macros in Clojure core with a ? at the end
take 1 arg, there are several that take two:

contains? every? extends? identical? instance? not-any? not-every?
satisfies?

That list might not be complete.  But you would not be breaking any
traditions I know of to have multi-argument predicate functions.

Andy


On Fri, Jan 31, 2014 at 8:44 AM, Ryan  wrote:

> Hello,
>
> I am wondering if all my predicates should be one argument functions
> because I run into a couple of cases where I needed more than one.
>
> For example, I have a function called valid-params? which takes two
> parameters; the validator to use and a maps parameter.
> Is this approach wrong/not the clojure way?
>
> What are my alternatives? Should I just use a different function name
> which does not have a question mark at the end that implies that is a
> predicate?
>
> Cheers,
>
> Ryan
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: Should predicates always have one argument?

[Jim - FooBar();]

A predicate is something that returns true or false. Nothing more 
nothing less...you can have as many args as you want - it is still a 
function predicate :)


Jim


On 31/01/14 16:44, Ryan wrote:

Hello,

I am wondering if all my predicates should be one argument functions 
because I run into a couple of cases where I needed more than one.


For example, I have a function called valid-params? which takes two 
parameters; the validator to use and a maps parameter.

Is this approach wrong/not the clojure way?

What are my alternatives? Should I just use a different function name 
which does not have a question mark at the end that implies that is a 
predicate?


Cheers,

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

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

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


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

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

Re: soft question: should remote channels appear like local channels

[t x]

  Originally, I had this mental analogy of:

function call :: remote procedure call = local async :: async over websocket

  In the func vs rpc case, the distinction is important to know what
is fast / what requires a network connection.

  However, upon further reflection, this analogy / distinction doesn't
hold in the local async / async over websocket because ... async
doesn't "require immedaite return" -- the mental model is: I fire off
this message to a mailbox, and forget about it -- so whether the
destination is in the same apartment complex or another state doesn't
really matter.




On Fri, Jan 31, 2014 at 7:59 AM, Timothy Baldridge  wrote:
> A quick thought...there really isn't much of a difference between a failing
> network connection and a (chan (dropping-buffer 1024))
>
> Both may (or may not) drop information that you put into them, but also,
> both can be expected to work "normally" as long as certain conditions hold.
> Namely, the net connection doesn't die, or the consumer can keep up with the
> data being put into the dropping buffer.
>
> So that's my advice, if you can't guarantee the data will reach the remote
> end, or you can't perfectly match core.async back pressure semantics, simply
> use a dropping buffer at the edges and code to those semantics.
>
> Timothy
>
> Timothy
>
>
> On Fri, Jan 31, 2014 at 3:37 AM, Thomas Heller  wrote:
>>
>> Hi,
>>
>> only advice I can give is: no or don't.
>>
>> In the many years I have done web development one of the most important
>> things I have learned is to keep the server as stateless as possible. Data
>> is easily kept externally while channels are not. Channels also aren't
>> exactly simple state since they are usually also attached to some go-blocks
>> and the like. While its very common the handle disconnects of the client on
>> the server und not as common to handle disconnects of the server on the
>> client.
>>
>> Disconnects are very frequent so you need to respect them, machines go to
>> sleep, wireless goes away, servers get restarted, jvms crash, etc.
>>
>> Never assume that a "remote" channel actually exist when writing to it,
>> unless you have some really solid error recovery (which probably is more
>> work than using traditional approaches).
>>
>> Just my 2 cents.
>>
>> /thomas
>>
>>
>> On Friday, January 31, 2014 6:43:14 AM UTC+1, t x wrote:
>>>
>>> Hi,
>>>
>>> With apologies for a soft question:
>>>
>>> This question is NOT:
>>>
>>>   I'm in a situation where client = cljs, server = clj, and I want to
>>> figure out how to setup a core.async channel, using pr-str and
>>> edn/read-string, where I can seamlessly push data back and forth
>>> between client and server.
>>>
>>> This question is:
>>>
>>>   Should I do the above?
>>>
>>>   The pro being: yay, channels everywhere, everything looks the same.
>>>
>>>   The con being: a local core.async channel and a remote core.async
>>> channel over a websocket are _NOT_ the same thing, and thus should not
>>> appear to be the same thing.
>>>
>>> ## Responses:
>>>
>>> Although detailed responses are always appreciated, given the nature
>>> of this "soft" question, responses of "go read _link_" are perfectly
>>> welcome too.
>>>
>>> I suspect someone in this world has thought deeply about the question,
>>> written up their insights, and pointing me at this primary resource
>>> (rather than trying to summarize it in a three paragraph email) is
>>> perfectly fine too.
>>>
>>> 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/groups/opt_out.
>
>
>
>
> --
> "One of the main causes of the fall of the Roman Empire was that-lacking
> zero-they had no way to indicate successful termination of their C
> programs."
> (Robert Firth)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, sen

Idiomatic way to construct potentially time bound target channel in core.async

[Jan Herich]

Hello Folks,

I need to construct core.async channel with following semantics:

1. When the channel is created, timeout is attached to channel
2. After timeout passes out, channel is closed
3. It's possible to detach timeout from the channel before it passes out

Now i implemented it with something like this:

(defn create-cancel-channel
  [channel-to-notify timeout-ms]
(let [cancel-channel (async/chan)
  timeout-channel (async/timeout timeout-ms)]
  (async/go
(let [[_ c] (async/alts! [cancel-channel timeout-channel])]
  (when (= c timeout-channel)
(async/close! cancel-channel)
(async/close! channel-to-notify
  cancel-channel))
 
;; transport channel
(def transport-channel (async/chan))
 
;; cancel-channel
(def cancel-channel (create-cancel-channel transport-channel 2000))
 
;; to cancel the transport channel timeout, just close the cancel-channel
(async/close! cancel-channel)


But i'm rather unsatisfied with this solution because it seems little bit 
clunky and what's worse, 
i need to explicitly keep track of those cancel channels. 
Obviously core.async pipe would greatly simplify this, but it seems, that 
there's no way to disconnect
piped channels. Maybe mult/tap/untap, even if i won't use broadcasting 
semantic of those constructs.
Any other ideas ?  

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

[ANN] clojure.java.jdbc 0.3.3 released

[Sean Corfield]

clojure.java.jdbc - Clojure's contrib library that wraps JDBC access

https://github.com/clojure/java.jdbc

• Release 0.3.3 on 2014-01-30
 • Prevent exception/crash when query called with bare SQL string JDBC-89.
 • Add :row-fn and :result-set-fn to metadata-result function JDBC-87.
 • Support key/value configuration from URI (Phil Hagelberg).

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: Should predicates always have one argument?

[John Gabriele]

It looks like the `comparator` function wants you to give it a 2-arg 
predicate.

-- John


On Friday, January 31, 2014 11:55:30 AM UTC-5, Andy Fingerhut wrote:
>
> While most of the functions and macros in Clojure core with a ? at the end 
> take 1 arg, there are several that take two:
>
> contains? every? extends? identical? instance? not-any? not-every? 
> satisfies?
>
> That list might not be complete.  But you would not be breaking any 
> traditions I know of to have multi-argument predicate functions.
>
> Andy
>
>
> On Fri, Jan 31, 2014 at 8:44 AM, Ryan >wrote:
>
>> Hello,
>>
>> I am wondering if all my predicates should be one argument functions 
>> because I run into a couple of cases where I needed more than one.
>>
>> For example, I have a function called valid-params? which takes two 
>> parameters; the validator to use and a maps parameter.
>> Is this approach wrong/not the clojure way?
>>
>> What are my alternatives? Should I just use a different function name 
>> which does not have a question mark at the end that implies that is a 
>> predicate?
>>
>> Cheers,
>>
>> Ryan
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

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

Re: Should predicates always have one argument?

[Tassilo Horn]

Andy Fingerhut  writes:

> contains? every? extends? identical? instance? not-any? not-every?
> satisfies?
>
> That list might not be complete.

Just to add some more: =, ==, <, <=, >=, > are also predicates with more
than one arg and even no question mark at the end.

Bye,
Tassilo

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

Re: Should predicates always have one argument?

[Ivan L]

I typically wrap stuff with (partial) for easier reading.  In your example 
you might use something like following.

(defn are-valid
  [maps validator]
  (let [valid? (partial validator)]
(map valid? maps)))

On Friday, January 31, 2014 11:44:38 AM UTC-5, Ryan wrote:
>
> Hello,
>
> I am wondering if all my predicates should be one argument functions 
> because I run into a couple of cases where I needed more than one.
>
> For example, I have a function called valid-params? which takes two 
> parameters; the validator to use and a maps parameter.
> Is this approach wrong/not the clojure way?
>
> What are my alternatives? Should I just use a different function name 
> which does not have a question mark at the end that implies that is a 
> predicate?
>
> Cheers,
>
> Ryan
>

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

Re: [ANN] clojure.java.jdbc 0.3.3 released

[Mark Engelberg]

I've been having trouble figuring out how to use clojure.java.jdbc
effectively, for example, how to rename tables, do work in transactions,
etc.  Is there full documentation with examples somewhere?


On Fri, Jan 31, 2014 at 11:33 AM, Sean Corfield  wrote:

> clojure.java.jdbc - Clojure's contrib library that wraps JDBC access
>
> https://github.com/clojure/java.jdbc
>
> * Release 0.3.3 on 2014-01-30
>  * Prevent exception/crash when query called with bare SQL string JDBC-89.
>  * Add :row-fn and :result-set-fn to metadata-result function JDBC-87.
>  * Support key/value configuration from URI (Phil Hagelberg).
>
> 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)
>
>
>

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

Re: [ANN] clojure.java.jdbc 0.3.3 released

[mynomoto]

The docs are in 
http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html. There is 
also a group: https://groups.google.com/forum/#!forum/clojure-java-jdbc


On Friday, January 31, 2014 8:54:12 PM UTC-2, puzzler wrote:
>
> I've been having trouble figuring out how to use clojure.java.jdbc 
> effectively, for example, how to rename tables, do work in transactions, 
> etc.  Is there full documentation with examples somewhere?
>
>
> On Fri, Jan 31, 2014 at 11:33 AM, Sean Corfield 
> 
> > wrote:
>
>> clojure.java.jdbc - Clojure's contrib library that wraps JDBC access
>>
>> https://github.com/clojure/java.jdbc
>>
>> • Release 0.3.3 on 2014-01-30
>>  • Prevent exception/crash when query called with bare SQL string JDBC-89.
>>  • Add :row-fn and :result-set-fn to metadata-result function JDBC-87.
>>  • Support key/value configuration from URI (Phil Hagelberg).
>>
>> 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)
>>
>>
>>
>

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

Re: order of returned values from keys and vals

[Matching Socks]

Actually, http://dev.clojure.org/jira/browse/CLJ-1302 "keys and vals 
consistency not mentioned in docstring" was declined, with the comment "The 
absence of this property in the docs is correct. You should not rely on 
this."



On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
>
> On Wed, Aug 11, 2010 at 4:53 PM, Kent > 
> wrote:
> > Hi,
> >
> > Is it safe to assume that the values returned from (keys mp) and (vals
> > mp) will be in the same order? In other words, will (zipmap (keys mp)
> > (vals mp)) always return mp?
> >
> > My experience has been that this does work, and it seems very
> > reasonable that it should work, but I don't see it documented anywhere
> > and I don't want to write a bunch of code that assumes it will work
> > and then have that code break in the future.
>
> keys, vals, and seq all do walk the map in the same order.
>
> I believe this is promised, though I agree having it in the
> docstring of keys and vals would be nice.
>
> --Chouser
> http://joyofclojure.com/
>
>

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

Re: [ANN] clojure.java.jdbc 0.3.3 released

[Sean Corfield]

On Fri, Jan 31, 2014 at 2:54 PM, Mark Engelberg
 wrote:
> I've been having trouble figuring out how to use clojure.java.jdbc
> effectively, for example, how to rename tables, do work in transactions,
> etc.  Is there full documentation with examples somewhere?

Feel free to ask specific questions - either here or on the
clojure-java-jdbc mailing list. I don't know what's missing from the
documentation unless people speak up!

As for renaming tables, DDL support is deliberately minimal because it
is hard to be portable:

(db-do-commands db-spec "some DDL") ;; should do what you need

As for documentation, as mynomoto said:

http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html

which is community editable without requiring a CA etc! If anything is
missing, you can open an issue https://github.com/clojuredocs/guides
or submit a PR!
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

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

Re: soft question: should remote channels appear like local channels

[Sean Corfield]

I like that way of thinking, Timothy!

Thomas: it's very specifically two separate channels; on the client
side, code puts data on a channel and additional client code (in a
library) takes data off the channel and handles the client/server
communication; on the server side, a library reads data from the
client/server connection and puts it on a channel, and your own server
side code takes data from that channel. And the same thing in reverse.

The point is that each side is isolated and core.async is used as a
way to interact with a library that consumes data (and sends it
somewhere) and produces data (that it reads from somewhere). The
application code "doesn't care" about the client/server bridge -
that's the library's problem. Cedric's right about connection loss etc
but that's all part of what the library deals with - if it can't
consume from a channel (because it can't send data over the wire),
that's the same as any other consumer failing to take data from a
channel that you supply.

Sean

On Fri, Jan 31, 2014 at 7:59 AM, Timothy Baldridge  wrote:
> A quick thought...there really isn't much of a difference between a failing
> network connection and a (chan (dropping-buffer 1024))
>
> Both may (or may not) drop information that you put into them, but also,
> both can be expected to work "normally" as long as certain conditions hold.
> Namely, the net connection doesn't die, or the consumer can keep up with the
> data being put into the dropping buffer.
>
> So that's my advice, if you can't guarantee the data will reach the remote
> end, or you can't perfectly match core.async back pressure semantics, simply
> use a dropping buffer at the edges and code to those semantics.
>
> Timothy
>
> Timothy
>
>
> On Fri, Jan 31, 2014 at 3:37 AM, Thomas Heller  wrote:
>>
>> Hi,
>>
>> only advice I can give is: no or don't.
>>
>> In the many years I have done web development one of the most important
>> things I have learned is to keep the server as stateless as possible. Data
>> is easily kept externally while channels are not. Channels also aren't
>> exactly simple state since they are usually also attached to some go-blocks
>> and the like. While its very common the handle disconnects of the client on
>> the server und not as common to handle disconnects of the server on the
>> client.
>>
>> Disconnects are very frequent so you need to respect them, machines go to
>> sleep, wireless goes away, servers get restarted, jvms crash, etc.
>>
>> Never assume that a "remote" channel actually exist when writing to it,
>> unless you have some really solid error recovery (which probably is more
>> work than using traditional approaches).
>>
>> Just my 2 cents.
>>
>> /thomas
>>
>>
>> On Friday, January 31, 2014 6:43:14 AM UTC+1, t x wrote:
>>>
>>> Hi,
>>>
>>> With apologies for a soft question:
>>>
>>> This question is NOT:
>>>
>>>   I'm in a situation where client = cljs, server = clj, and I want to
>>> figure out how to setup a core.async channel, using pr-str and
>>> edn/read-string, where I can seamlessly push data back and forth
>>> between client and server.
>>>
>>> This question is:
>>>
>>>   Should I do the above?
>>>
>>>   The pro being: yay, channels everywhere, everything looks the same.
>>>
>>>   The con being: a local core.async channel and a remote core.async
>>> channel over a websocket are _NOT_ the same thing, and thus should not
>>> appear to be the same thing.
>>>
>>> ## Responses:
>>>
>>> Although detailed responses are always appreciated, given the nature
>>> of this "soft" question, responses of "go read _link_" are perfectly
>>> welcome too.
>>>
>>> I suspect someone in this world has thought deeply about the question,
>>> written up their insights, and pointing me at this primary resource
>>> (rather than trying to summarize it in a three paragraph email) is
>>> perfectly fine too.
>>>
>>> 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/groups/opt_out.
>
>
>
>
> --
> "One of the main causes of the fall of the Roman Empire was that-lacking
> zero-they had no way to indicate successful termination of their C
> programs."
> (Robert Firth)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new