Re: MyType cannot be cast to MyType?

[Laurent PETIT]

Hello Jonathan,

As Stuart said, the problem is probably appearing the second (and more)
times you evaluate the namespace in the repl, whatever the method.

To mitigate the issue, you can also try to avoid redefining the
whole namespace containing the type definitions, and just use Ctrl+enter to
send fine grained too level definitions to the repl.

Le mercredi 22 janvier 2014, Jonathan Barnard 
a écrit :

> Thank you for that. I've found that the code works correctly if I just
> copy it into the repl and run it; it's only when I load it in Eclipse (with
> Counterclockwise) using ctrl-alt-s that it displays the error. Is there
> some way to reset the repl to a blank state (remove all previous class
> definitions) other than just closing and re-opening it?
>
> On Wednesday, 22 January 2014 12:11:07 UTC+11, Stuart Sierra wrote:
>>
>> Hello Jonathan,
>>
>> In my experience, an error along the lines of "class Foo cannot be cast
>> to Foo" is usually caused by re-evaluating class definitions, either by
>> reloading files or by re-evaluating definitions in your REPL or IDE.
>>
>> Here is a smaller example that demonstrates the problem:
>>
>> (deftype Foo [x])
>>
>> (def a-foo (Foo. 1))
>>
>> (defn use-foo [^Foo foo]
>>   (prn (.x foo)))
>>
>> ;; Re-evaluate the definition of Foo,
>> ;; perhaps in a REPL or editor:
>> (deftype Foo [x])
>>
>> (type a-foo) ;;=> user.Foo
>>
>> (= Foo (type a-foo)) ;;=> false
>>
>> (use-foo a-foo)
>> ;; java.lang.ClassCastException:
>> ;; user.Foo cannot be cast to user.Foo
>>
>> The object `*a-foo*` is an instance of the **first** definition of the
>> type Foo, which was overwritten by the **second** definition of the type
>> Foo.
>>
>> This problem is caused by a combination of Clojure's runtime generation
>> of Java classes and the way JVM ClassLoaders work.
>>
>> -S
>>
>>
>>
>> On Sunday, January 19, 2014 9:20:03 PM UTC-5, Jonathan Barnard wrote:
>>>
>>> For fun, I've been porting a very simple particle animation from Java to
>>> Clojure. It was somewhat slow so to see how fast I could make it I decided
>>> to try using mutation. I've defined a Particle type, and a PSlice type that
>>> contains an array of objects and a length (number of non-nil objects in the
>>> slice), but when I try to provide type hints for this slice type, I get the
>>> error:
>>>
>>> *ClassCastException MyProject.core.PSlice cannot be cast to *
>>>
>>> *MyProject.core.PSlice *Is this a bug, or am I doing something wrong?
>>> My code defining the two types is:
>>>
>>> (definterface IPt
>>>   (^Double gx []) (^Double gy []) (^Double gz []) (^Double gvx [])
>>> (^Double gvy []) (^Double gvz []) (^Double gR []) (^Double glife [])
>>> (^Boolean gis [])
>>>   (sx [^Double v]) (sy [^Double v]) (sz [^Double v]) (svx [^Double v])
>>> (svy [^Double v]) (svz [^Double v]) (sR [^Double v]) (slife [^Double v])
>>> (^Boolean sis [^Boolean v]))
>>>
>>> (deftype Particle [^:unsynchronized-mutable ^Double x
>>> ^:unsynchronized-mutable ^Double y ^:unsynchronized-mutable ^Double z
>>>^:unsynchronized-mutable ^Double vx
>>> ^:unsynchronized-mutable ^Double vy ^:unsynchronized-mutable ^Double vz
>>>^:unsynchronized-mutable ^Double R
>>> ^:unsynchronized-mutable ^Double life ^:unsynchronized-mutable ^Boolean is]
>>>   IPt
>>>   (gx [_] x) (gy [_] y) (gz [_] z) (gvx [_] vx) (gvy [_] vy) (gvz [_]
>>> vz) (gR [_] R) (glife [_] life) (gis [_] is)
>>>   (sx [this v] (set! x v)) (sy [this v] (set! y v)) (sz [this v] (set! z
>>> v))
>>>   (svx [this v] (set! vx v)) (svy [this v] (set! vy v)) (svz [this v]
>>> (set! vz v))
>>>   (sR [this v] (set! R v)) (slife [this v] (set! life v)) (sis [this v]
>>> (set! is v)))
>>>
>>> (definterface ISlice
>>>   (^Long gLen [])
>>>   (sLen [^Long x])
>>>   (^Particle gPt [^Long n])
>>>   (sPt [^Long n ^Particle pt] ))
>>>
>>> (deftype PSlice [^"[Ljava.lang.Object;" pts ^:unsynchronized-mutable
>>> ^Long len]
>>>   ISlice
>>>   (gLen [_] len)
>>>   (sLen [this new-len] (set! len new-len))
>>>   (gPt [this n] (aget pts n))
>>>   (sPt [this n pt] (aset pts n pt)))
>>>
>>>
>>> Then the error occurs if I define a PSlice, such as by:
>>>
>>> (def tslice (PSlice. (make-array Object 100) 0))
>>>
>>> and a function:
>>>
>>> (defn test-fn [^PSlice slice]
>>>   (print (.gLen slice))
>>>   )
>>>
>>> Then call (test-fn tslice).
>>>
>>> Note that the function will work as intended if no type hints are
>>> provided, but will run quite slowly due to reflection, defeating the point
>>> of using mutation.
>>>
>>  --
> --
> 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 '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  'clojure%2bunsubscr...@googlegroups.com');>

[ANN] clj-flume-node 0.1.0

[Yoshitaka Kawashima]

Hi,

I released clj-flume-node v0.1.0. 
It's a clojure library for Apache 
Flume .

Apache Flume is a very useful tool for collecting events and logs. But Its 
configuration file is Java properties. It's boring for me.
So, I enabled to write the flume configuration by Clojure as following:

(defagent :a1
  (flume/source :r1
:type "syslogudp"
:host "127.0.0.1"
:port 
:channels :c1)
  (flume/sink :k1
  :type "logger"
  :channel :c1)
  (flume/channel :c1
 :type "memory"
 :capacity 1000
 :transactionCapacity 100))

As usual available from Clojars or GitHub:
- https://clojars.org/net.unit8/clj-flume-node
- https://github.com/kawasima/clj-flume-node


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

[Gal Dolber]

clojure-objc is a clojure compiler that generates java(instead of bytecode) 
and uses j2objc(https://code.google.com/p/j2objc/) to translate it to objc.

Goals
 * Write iOS and MacOS apps in clojure
 * Future proof: new features on clojure should be easy to add 
 * Distribute clojure-objc libs using maven
 * Pure clojure libs should 'just work' (if they only use the jre emulated 
classes)
 * ObjC dynamic interop
 * Run tests in the jvm (with no ObjC interop)
 
For more information:
https://github.com/galdolber/clojure-objc

Lein plugin:
https://github.com/galdolber/lein-objcbuild

Sample project:
https://github.com/galdolber/clojure-objc-sample

-- 
-- 
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: MyType cannot be cast to MyType?

[Jonathan Barnard]

Excellent, that looks quite useful, thank you.

On Thursday, 23 January 2014 01:59:21 UTC+11, Mauricio Aldazosa wrote:
>
> Take a look at Stuart's tools.namespace (
> https://github.com/clojure/tools.namespace), although be wary of the 
> protocol issue as it is something that is pointed out in the warnings 
> section of that project.
>
> Mauricio
>

-- 
-- 
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: semantics of >! on closed channels

[john walker]

This is a common windows problem.

On Thursday, January 23, 2014 9:17:09 PM UTC-5, Cedric Greevey wrote:
>
> [meta, but about something apparently triggered by the message, from this 
> thread, that I'm quoting]
>
> Why did reading this post cause gmail to go bonkers? I saw this thread had 
> new articles since earlier today, brought it up, and read the previous 
> message, then just after I'd scrolled down to this one, leaned back, and 
> started reading it the browser just suddenly began spinning on its own and 
> navigated by itself. Apparently about 10 seconds after I sat back 
> *something* input a click on the little down-triangle in the upper right 
> corner of the page and then clicked "sign out" because it went to the gmail 
> login page. And a second or so before that the chat thingy at the left 
> crashed as a popup there distracted me by appearing suddenly and saying 
> something like "Oops, problem connecting to chat".
>
> I don't like having my stuff suddenly go spinning out of control like 
> that. I wasn't touching the keyboard or the mouse at the time. The browser 
> should not have done anything but sit there patiently displaying this page 
> until *I* *CHOSE* to navigate away from it. If there is something in your 
> message that hijacks the browsers of people reading it, then I would like 
> you to know that I consider such a thing to be extremely poor etiquette and 
> in extremely poor taste. Do not do it again. If it was not that particular 
> message then I'd like to know what *did* reach into *MY* computer and start 
> issuing instructions on *MY* behalf *without* *MY* permission, and how to 
> stop that from ever happening again. This is *MY* copy of Firefox and it 
> goes where *I* say it does, when *I* say it does it, and not a moment 
> sooner. Is that absofrickinglutely clear? That is non-negotiable. Anyone 
> who willfully violates this edict *will* be added to my spam filter and I 
> will not see any future post by that author. Is *that* clear?
>
>
>
>
> On Thu, Jan 23, 2014 at 7:21 AM, t x >wrote:
>
>> Hi,
>>
>>   * This is the time I've heard "the one who's feeding the channel is the 
>> one in charge of closing it" -- previously, my channel code was fairly 
>> ad-hoc and agressive (since I need to kill many (go-loop [msg (> (when msg ...)) blocks).
>>
>>   * I still feel this breaks the "conveyor belt" metaphor -- when a 
>> conveyor belt shuts down, it's understandable that we after we take what's 
>> on the belt, in future takes, we get nothing.
>>
>>   However, when putting items on a stopped conveyor belt, messages should 
>> not just *poof* vanish into the void. :-)
>>
>>   * This existing semantics makes debugging annoying (perhaps this is due 
>> to my lack of skill). When something should be happening, and nothing is 
>> happening, I'm basically going around hunting for "where did I do a put on 
>> a closed channel", whereas if it threw an exception of some form, it'd be 
>> easier to handle then this "silent fail."
>>
>>
>>
>>
>> On Thu, Jan 23, 2014 at 3:50 AM, Meikel Brandmeyer (kotarak) <
>> m...@kotka.de > wrote:
>>
>>> Hi,
>>>
>>> probably the idea is, that the one who's feeding the channel is the one 
>>> in charge of closing it. After all, they know when there is no more input 
>>> available. Do you have a use case where this problem manifests? Or is that 
>>> just a vague fear that it might happen?
>>>
>>> Kind regards
>>> Meikel
>>>
>>>  -- 
>>> -- 
>>> 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 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 beca

Re: semantics of >! on closed channels

[Cedric Greevey]

I didn't say "a virus". I pointed out that it appeared to be triggered by
viewing a particular message in this thread. It may be that there's some
gimmick text you can embed in a mail that screws up gmail -- there's
certainly precedent, anyone on a dialup connection will get their line
dropped when they load this message because it contains "+++ATH0". In any
case, what the incident most resembled to me was a prank of a similar sort
to that old classic from the BBS days and any of numerous commonplace
college dorm pranks; in which case the place to address it is right here
where the person who perpetrated the inappropriate prank can explain that
that's what it was (if that *is* what it was) and apologize, and/or the
group's moderators can take any appropriate action against the perpetrator.
(I'd be happy with their receiving a warning, *if* this was a first
offense.)


On Thu, Jan 23, 2014 at 9:49 PM, Timothy Baldridge wrote:

> >
> Which part didn't you understand?
>
> The part where you think that this is the appropriate channel for
> discussing general IT problems you are having with your computer
>
> > I don't know if it was something in "t x"'s message that triggered it
>
> Well you accused him of that pretty much right off the bat...
>
> > In any event, if anyone can shed any light on this incident I'd
> appreciate information.
>
> Sure, it can be a number of things. a) a bug in your mouse driver. b) a
> failing mouse battery. c) dirt on/in the mouse d) a bug in your browser e)
> a virus on your computer. f) a bug in gmail.
>
> All of these are much, much more likely than what
> you originally suggested. The idea that someone posting to a google group
> can get a virus through a text email, and that that virus somehow affected
> your browser, is just laughable.
>
> Timothy
>
>
> On Thu, Jan 23, 2014 at 7:34 PM, Cedric Greevey wrote:
>
>> Which part didn't you understand? When I scrolled down to "t x"'s
>> message, after a short delay *something* wrested control of Firefox away
>> from me and issued a sequence of navigation commands the effect of which
>> was to log me out of gmail, much as if I'd clicked the little down arrow by
>> my username and then clicked "signout".
>>
>> I don't know if it was something in "t x"'s message that triggered it (if
>> so, it didn't have the same effect when I viewed it again after logging
>> back in), but I do know that I do not appreciate having my computer
>> hijacked. I'm sure you can understand how it's rather alarming to have your
>> stuff just suddenly start acting on "its own initiative", right in front of
>> your eyes, when the damned thing isn't supposed to *have* its own
>> initiative.
>>
>> In any event, if anyone can shed any light on this incident I'd
>> appreciate information. (For example: does an expert on browser security
>> see anything in "t x"'s post, or any other in this thread, that could have
>> triggered anything unusual in susceptible versions of Firefox? Should I
>> wipe and reinstall this machine on the presumption that the seemingly
>> superficial hijack left it infected with a nasty rootkit of some sort, or
>> was it just a prank, or even a known software bug somewhere?)
>>
>>
>> On Thu, Jan 23, 2014 at 9:20 PM, Timothy Baldridge 
>> wrote:
>>
>>> Umwat?
>>> On Jan 23, 2014 7:17 PM, "Cedric Greevey"  wrote:
>>>
 [meta, but about something apparently triggered by the message, from
 this thread, that I'm quoting]

 Why did reading this post cause gmail to go bonkers? I saw this thread
 had new articles since earlier today, brought it up, and read the previous
 message, then just after I'd scrolled down to this one, leaned back, and
 started reading it the browser just suddenly began spinning on its own and
 navigated by itself. Apparently about 10 seconds after I sat back
 *something* input a click on the little down-triangle in the upper right
 corner of the page and then clicked "sign out" because it went to the gmail
 login page. And a second or so before that the chat thingy at the left
 crashed as a popup there distracted me by appearing suddenly and saying
 something like "Oops, problem connecting to chat".

 I don't like having my stuff suddenly go spinning out of control like
 that. I wasn't touching the keyboard or the mouse at the time. The browser
 should not have done anything but sit there patiently displaying this page
 until *I* *CHOSE* to navigate away from it. If there is something in your
 message that hijacks the browsers of people reading it, then I would like
 you to know that I consider such a thing to be extremely poor etiquette and
 in extremely poor taste. Do not do it again. If it was not that particular
 message then I'd like to know what *did* reach into *MY* computer and start
 issuing instructions on *MY* behalf *without* *MY* permission, and how to
 stop that from ever happening again. This is *MY* copy of F

Re: [ANN] Stasis - not another static site framework

[Ryan McGowan]

Thanks! I agree. I think they both have there uses as things stand right 
now.

Maybe Incise could even use Stasis as a lib to build its more elaborate 
> features on top of?


I was thinking the same thing. Unfortunately, I think there are a few 
blockers right now (serving is done very differently, string content is not 
required). I'll have to think more about how the stasis way of serving and 
exporting compares to incise's.

On Thursday, January 23, 2014 6:07:32 PM UTC-8, Magnar Sveen wrote:
>
> Very minimalist. I appreciate that.
>>
>
> Thank you :-) And let me say that out of the five frameworks, I think 
> Incise is the most exciting - with its focus on extensibility.
>
> This makes sharing implementations easier. The stasis way to do this is 
>> for everyone to write it and integrate themselves.  Often the later is more 
>> fun and offers a bit more control, but the former is easier.
>>
>
> Agreed. Now, I prefer control and fun over ease - but that might be a bad 
> choice in many situations.
>
> My feeling is that both Stasis and Incise have their place, and can live 
> happily alongside each other. Maybe Incise could even use Stasis as a lib 
> to build its more elaborate features on top of?
>
> - Magnar
>
>

-- 
-- 
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: semantics of >! on closed channels

[Timothy Baldridge]

>Which part didn't you understand?

The part where you think that this is the appropriate channel for
discussing general IT problems you are having with your computer

> I don't know if it was something in "t x"'s message that triggered it

Well you accused him of that pretty much right off the bat...

> In any event, if anyone can shed any light on this incident I'd
appreciate information.

Sure, it can be a number of things. a) a bug in your mouse driver. b) a
failing mouse battery. c) dirt on/in the mouse d) a bug in your browser e)
a virus on your computer. f) a bug in gmail.

All of these are much, much more likely than what you originally suggested.
The idea that someone posting to a google group can get a virus through a
text email, and that that virus somehow affected your browser, is just
laughable.

Timothy


On Thu, Jan 23, 2014 at 7:34 PM, Cedric Greevey  wrote:

> Which part didn't you understand? When I scrolled down to "t x"'s message,
> after a short delay *something* wrested control of Firefox away from me and
> issued a sequence of navigation commands the effect of which was to log me
> out of gmail, much as if I'd clicked the little down arrow by my username
> and then clicked "signout".
>
> I don't know if it was something in "t x"'s message that triggered it (if
> so, it didn't have the same effect when I viewed it again after logging
> back in), but I do know that I do not appreciate having my computer
> hijacked. I'm sure you can understand how it's rather alarming to have your
> stuff just suddenly start acting on "its own initiative", right in front of
> your eyes, when the damned thing isn't supposed to *have* its own
> initiative.
>
> In any event, if anyone can shed any light on this incident I'd appreciate
> information. (For example: does an expert on browser security see anything
> in "t x"'s post, or any other in this thread, that could have triggered
> anything unusual in susceptible versions of Firefox? Should I wipe and
> reinstall this machine on the presumption that the seemingly superficial
> hijack left it infected with a nasty rootkit of some sort, or was it just a
> prank, or even a known software bug somewhere?)
>
>
> On Thu, Jan 23, 2014 at 9:20 PM, Timothy Baldridge 
> wrote:
>
>> Umwat?
>> On Jan 23, 2014 7:17 PM, "Cedric Greevey"  wrote:
>>
>>> [meta, but about something apparently triggered by the message, from
>>> this thread, that I'm quoting]
>>>
>>> Why did reading this post cause gmail to go bonkers? I saw this thread
>>> had new articles since earlier today, brought it up, and read the previous
>>> message, then just after I'd scrolled down to this one, leaned back, and
>>> started reading it the browser just suddenly began spinning on its own and
>>> navigated by itself. Apparently about 10 seconds after I sat back
>>> *something* input a click on the little down-triangle in the upper right
>>> corner of the page and then clicked "sign out" because it went to the gmail
>>> login page. And a second or so before that the chat thingy at the left
>>> crashed as a popup there distracted me by appearing suddenly and saying
>>> something like "Oops, problem connecting to chat".
>>>
>>> I don't like having my stuff suddenly go spinning out of control like
>>> that. I wasn't touching the keyboard or the mouse at the time. The browser
>>> should not have done anything but sit there patiently displaying this page
>>> until *I* *CHOSE* to navigate away from it. If there is something in your
>>> message that hijacks the browsers of people reading it, then I would like
>>> you to know that I consider such a thing to be extremely poor etiquette and
>>> in extremely poor taste. Do not do it again. If it was not that particular
>>> message then I'd like to know what *did* reach into *MY* computer and start
>>> issuing instructions on *MY* behalf *without* *MY* permission, and how to
>>> stop that from ever happening again. This is *MY* copy of Firefox and it
>>> goes where *I* say it does, when *I* say it does it, and not a moment
>>> sooner. Is that absofrickinglutely clear? That is non-negotiable. Anyone
>>> who willfully violates this edict *will* be added to my spam filter and I
>>> will not see any future post by that author. Is *that* clear?
>>>
>>>
>>>
>>>
>>> On Thu, Jan 23, 2014 at 7:21 AM, t x  wrote:
>>>
 Hi,

   * This is the time I've heard "the one who's feeding the channel is
 the one in charge of closing it" -- previously, my channel code was fairly
 ad-hoc and agressive (since I need to kill many (go-loop [msg (>>> (when msg ...)) blocks).

   * I still feel this breaks the "conveyor belt" metaphor -- when a
 conveyor belt shuts down, it's understandable that we after we take what's
 on the belt, in future takes, we get nothing.

   However, when putting items on a stopped conveyor belt, messages
 should not just *poof* vanish into the void. :-)

   * This existing semantics makes debugging

Re: semantics of >! on closed channels

[Cedric Greevey]

Which part didn't you understand? When I scrolled down to "t x"'s message,
after a short delay *something* wrested control of Firefox away from me and
issued a sequence of navigation commands the effect of which was to log me
out of gmail, much as if I'd clicked the little down arrow by my username
and then clicked "signout".

I don't know if it was something in "t x"'s message that triggered it (if
so, it didn't have the same effect when I viewed it again after logging
back in), but I do know that I do not appreciate having my computer
hijacked. I'm sure you can understand how it's rather alarming to have your
stuff just suddenly start acting on "its own initiative", right in front of
your eyes, when the damned thing isn't supposed to *have* its own
initiative.

In any event, if anyone can shed any light on this incident I'd appreciate
information. (For example: does an expert on browser security see anything
in "t x"'s post, or any other in this thread, that could have triggered
anything unusual in susceptible versions of Firefox? Should I wipe and
reinstall this machine on the presumption that the seemingly superficial
hijack left it infected with a nasty rootkit of some sort, or was it just a
prank, or even a known software bug somewhere?)


On Thu, Jan 23, 2014 at 9:20 PM, Timothy Baldridge wrote:

> Umwat?
> On Jan 23, 2014 7:17 PM, "Cedric Greevey"  wrote:
>
>> [meta, but about something apparently triggered by the message, from this
>> thread, that I'm quoting]
>>
>> Why did reading this post cause gmail to go bonkers? I saw this thread
>> had new articles since earlier today, brought it up, and read the previous
>> message, then just after I'd scrolled down to this one, leaned back, and
>> started reading it the browser just suddenly began spinning on its own and
>> navigated by itself. Apparently about 10 seconds after I sat back
>> *something* input a click on the little down-triangle in the upper right
>> corner of the page and then clicked "sign out" because it went to the gmail
>> login page. And a second or so before that the chat thingy at the left
>> crashed as a popup there distracted me by appearing suddenly and saying
>> something like "Oops, problem connecting to chat".
>>
>> I don't like having my stuff suddenly go spinning out of control like
>> that. I wasn't touching the keyboard or the mouse at the time. The browser
>> should not have done anything but sit there patiently displaying this page
>> until *I* *CHOSE* to navigate away from it. If there is something in your
>> message that hijacks the browsers of people reading it, then I would like
>> you to know that I consider such a thing to be extremely poor etiquette and
>> in extremely poor taste. Do not do it again. If it was not that particular
>> message then I'd like to know what *did* reach into *MY* computer and start
>> issuing instructions on *MY* behalf *without* *MY* permission, and how to
>> stop that from ever happening again. This is *MY* copy of Firefox and it
>> goes where *I* say it does, when *I* say it does it, and not a moment
>> sooner. Is that absofrickinglutely clear? That is non-negotiable. Anyone
>> who willfully violates this edict *will* be added to my spam filter and I
>> will not see any future post by that author. Is *that* clear?
>>
>>
>>
>>
>> On Thu, Jan 23, 2014 at 7:21 AM, t x  wrote:
>>
>>> Hi,
>>>
>>>   * This is the time I've heard "the one who's feeding the channel is
>>> the one in charge of closing it" -- previously, my channel code was fairly
>>> ad-hoc and agressive (since I need to kill many (go-loop [msg (>> (when msg ...)) blocks).
>>>
>>>   * I still feel this breaks the "conveyor belt" metaphor -- when a
>>> conveyor belt shuts down, it's understandable that we after we take what's
>>> on the belt, in future takes, we get nothing.
>>>
>>>   However, when putting items on a stopped conveyor belt, messages
>>> should not just *poof* vanish into the void. :-)
>>>
>>>   * This existing semantics makes debugging annoying (perhaps this is
>>> due to my lack of skill). When something should be happening, and nothing
>>> is happening, I'm basically going around hunting for "where did I do a put
>>> on a closed channel", whereas if it threw an exception of some form, it'd
>>> be easier to handle then this "silent fail."
>>>
>>>
>>>
>>>
>>> On Thu, Jan 23, 2014 at 3:50 AM, Meikel Brandmeyer (kotarak) <
>>> m...@kotka.de> wrote:
>>>
 Hi,

 probably the idea is, that the one who's feeding the channel is the one
 in charge of closing it. After all, they know when there is no more input
 available. Do you have a use case where this problem manifests? Or is that
 just a vague fear that it might happen?

 Kind regards
 Meikel

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

Re: semantics of >! on closed channels

[Timothy Baldridge]

Umwat?
On Jan 23, 2014 7:17 PM, "Cedric Greevey"  wrote:

> [meta, but about something apparently triggered by the message, from this
> thread, that I'm quoting]
>
> Why did reading this post cause gmail to go bonkers? I saw this thread had
> new articles since earlier today, brought it up, and read the previous
> message, then just after I'd scrolled down to this one, leaned back, and
> started reading it the browser just suddenly began spinning on its own and
> navigated by itself. Apparently about 10 seconds after I sat back
> *something* input a click on the little down-triangle in the upper right
> corner of the page and then clicked "sign out" because it went to the gmail
> login page. And a second or so before that the chat thingy at the left
> crashed as a popup there distracted me by appearing suddenly and saying
> something like "Oops, problem connecting to chat".
>
> I don't like having my stuff suddenly go spinning out of control like
> that. I wasn't touching the keyboard or the mouse at the time. The browser
> should not have done anything but sit there patiently displaying this page
> until *I* *CHOSE* to navigate away from it. If there is something in your
> message that hijacks the browsers of people reading it, then I would like
> you to know that I consider such a thing to be extremely poor etiquette and
> in extremely poor taste. Do not do it again. If it was not that particular
> message then I'd like to know what *did* reach into *MY* computer and start
> issuing instructions on *MY* behalf *without* *MY* permission, and how to
> stop that from ever happening again. This is *MY* copy of Firefox and it
> goes where *I* say it does, when *I* say it does it, and not a moment
> sooner. Is that absofrickinglutely clear? That is non-negotiable. Anyone
> who willfully violates this edict *will* be added to my spam filter and I
> will not see any future post by that author. Is *that* clear?
>
>
>
>
> On Thu, Jan 23, 2014 at 7:21 AM, t x  wrote:
>
>> Hi,
>>
>>   * This is the time I've heard "the one who's feeding the channel is the
>> one in charge of closing it" -- previously, my channel code was fairly
>> ad-hoc and agressive (since I need to kill many (go-loop [msg (> (when msg ...)) blocks).
>>
>>   * I still feel this breaks the "conveyor belt" metaphor -- when a
>> conveyor belt shuts down, it's understandable that we after we take what's
>> on the belt, in future takes, we get nothing.
>>
>>   However, when putting items on a stopped conveyor belt, messages should
>> not just *poof* vanish into the void. :-)
>>
>>   * This existing semantics makes debugging annoying (perhaps this is due
>> to my lack of skill). When something should be happening, and nothing is
>> happening, I'm basically going around hunting for "where did I do a put on
>> a closed channel", whereas if it threw an exception of some form, it'd be
>> easier to handle then this "silent fail."
>>
>>
>>
>>
>> On Thu, Jan 23, 2014 at 3:50 AM, Meikel Brandmeyer (kotarak) > > wrote:
>>
>>> Hi,
>>>
>>> probably the idea is, that the one who's feeding the channel is the one
>>> in charge of closing it. After all, they know when there is no more input
>>> available. Do you have a use case where this problem manifests? Or is that
>>> just a vague fear that it might happen?
>>>
>>> Kind regards
>>> Meikel
>>>
>>>  --
>>> --
>>> 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 t

Re: semantics of >! on closed channels

[Cedric Greevey]

[meta, but about something apparently triggered by the message, from this
thread, that I'm quoting]

Why did reading this post cause gmail to go bonkers? I saw this thread had
new articles since earlier today, brought it up, and read the previous
message, then just after I'd scrolled down to this one, leaned back, and
started reading it the browser just suddenly began spinning on its own and
navigated by itself. Apparently about 10 seconds after I sat back
*something* input a click on the little down-triangle in the upper right
corner of the page and then clicked "sign out" because it went to the gmail
login page. And a second or so before that the chat thingy at the left
crashed as a popup there distracted me by appearing suddenly and saying
something like "Oops, problem connecting to chat".

I don't like having my stuff suddenly go spinning out of control like that.
I wasn't touching the keyboard or the mouse at the time. The browser should
not have done anything but sit there patiently displaying this page until
*I* *CHOSE* to navigate away from it. If there is something in your message
that hijacks the browsers of people reading it, then I would like you to
know that I consider such a thing to be extremely poor etiquette and in
extremely poor taste. Do not do it again. If it was not that particular
message then I'd like to know what *did* reach into *MY* computer and start
issuing instructions on *MY* behalf *without* *MY* permission, and how to
stop that from ever happening again. This is *MY* copy of Firefox and it
goes where *I* say it does, when *I* say it does it, and not a moment
sooner. Is that absofrickinglutely clear? That is non-negotiable. Anyone
who willfully violates this edict *will* be added to my spam filter and I
will not see any future post by that author. Is *that* clear?




On Thu, Jan 23, 2014 at 7:21 AM, t x  wrote:

> Hi,
>
>   * This is the time I've heard "the one who's feeding the channel is the
> one in charge of closing it" -- previously, my channel code was fairly
> ad-hoc and agressive (since I need to kill many (go-loop [msg ( (when msg ...)) blocks).
>
>   * I still feel this breaks the "conveyor belt" metaphor -- when a
> conveyor belt shuts down, it's understandable that we after we take what's
> on the belt, in future takes, we get nothing.
>
>   However, when putting items on a stopped conveyor belt, messages should
> not just *poof* vanish into the void. :-)
>
>   * This existing semantics makes debugging annoying (perhaps this is due
> to my lack of skill). When something should be happening, and nothing is
> happening, I'm basically going around hunting for "where did I do a put on
> a closed channel", whereas if it threw an exception of some form, it'd be
> easier to handle then this "silent fail."
>
>
>
>
> On Thu, Jan 23, 2014 at 3:50 AM, Meikel Brandmeyer (kotarak) 
> wrote:
>
>> Hi,
>>
>> probably the idea is, that the one who's feeding the channel is the one
>> in charge of closing it. After all, they know when there is no more input
>> available. Do you have a use case where this problem manifests? Or is that
>> just a vague fear that it might happen?
>>
>> Kind regards
>> Meikel
>>
>>  --
>> --
>> 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...@goog

Re: [ANN] Stasis - not another static site framework

[Magnar Sveen]

>
> Very minimalist. I appreciate that.
>

Thank you :-) And let me say that out of the five frameworks, I think 
Incise is the most exciting - with its focus on extensibility.

This makes sharing implementations easier. The stasis way to do this is for 
> everyone to write it and integrate themselves.  Often the later is more fun 
> and offers a bit more control, but the former is easier.
>

Agreed. Now, I prefer control and fun over ease - but that might be a bad 
choice in many situations.

My feeling is that both Stasis and Incise have their place, and can live 
happily alongside each other. Maybe Incise could even use Stasis as a lib 
to build its more elaborate features on top of?

- Magnar

-- 
-- 
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] Stasis - not another static site framework

[Ryan McGowan]

Very minimalist. I appreciate that. As the author of incise I'd like to 
point out a few things though. :)

   1. You did not specifically say that incise forced some sort of 
   templating option though it was implied (along with the other static site 
   generators). Incise does not force any such options on you (in fact hiccup 
   will not even be included in incise-core in 0.2.0). It is also not specific 
   to html file generation though there are some helpful functions built in to 
   incise to support that very common use case. The layouts feature (similar 
   to create-page in what-the-emacs) is entirely opt in as well.
   2. You can create your own stylesheets too. I'm not sure what this was 
   getting at...
   3. While incise does require an input directory and an output directory 
   it is configurable.

Of course, if stasis has been around when I decided I wanted to start a 
blog, incise probably wouldn't be around. The two tools can be 
easily contrasted by this statement though:

No configuration options. You have to make them.
>

Incise's goal is to be extensible so someone can write an asciidoc parser 
(that may take some user defined configuration options) that leverages all 
of the other things that have already been done by integrating with it. 
 This makes sharing implementations easier. The stasis way to do this is 
for everyone to write it and integrate themselves.  Often the later is more 
fun and offers a bit more control, but the former is easier.

Those are my initial thoughts at least.

On Thursday, January 23, 2014 2:31:17 AM UTC-8, Magnar Sveen wrote:
>
> Oh, look at that. Thanks! :)
>
>
> On Thu, Jan 23, 2014 at 11:27 AM, Dmitry Groshev 
> 
> > wrote:
>
>> And here is a link to the project, just in case you've missed it like I 
>> did: https://github.com/magnars/stasis :)
>>
>>
>> On Thursday, January 23, 2014 2:16:48 PM UTC+4, Magnar Sveen wrote:
>>>
>>> Stasis
>>>
>>> A Clojure library of tools for developing static web sites.
>>> Another
>>>  
>>> static site framework? Why? 
>>>
>>> Well, that's exactly it. I didn't want to use a framework. I don't like 
>>> the restrained feeling I get when using them. I prefer coding things over 
>>> messing around with configuration files.
>>>
>>> I want to
>>>
>>>- code my own pages
>>>- set up my own configuration
>>>- choose my own templating library
>>>- create my own damn stylesheets
>>>
>>> *Statis offers a few functions that are pretty useful when creating 
>>> static web sites.*
>>>
>>> No more. There are no batteries included.
>>>
>>> If you want a framework that makes it really quick and easy to create a 
>>> blog, you should take a look at these:
>>>
>>>- misaki  is a Jekyll inspired 
>>>static site generator in Clojure. 
>>>- Madness  is a static site 
>>>generator, based on Enlive and Bootstrap.
>>>- Static  is a simple static site 
>>>generator written in Clojure. 
>>>- Ecstatic  creates static web pages and 
>>>blog posts from Hiccup templates and Markdown.
>>>- incise  is an extensible static 
>>>site generator written in Clojure. 
>>>
>>> They generally come with a folder where you put your blog posts in some 
>>> templating language, and a set of configuration options about how to set up 
>>> your blog. They often generate code for you to tweak.
>>>  Usage 
>>>
>>> The core of Stasis is two functions: serve-pages and export-pages. Both 
>>> take a map from path to contents:
>>>
>>> (def pages {"/index.html" "Welcome!"})
>>>
>>> The basic use case is to serve these live on a local server while 
>>> developing - and then exporting them as static pages to deploy on some 
>>> server.
>>> Serving
>>>  
>>> live pages locally 
>>>
>>> Stasis can create a Ring handler to serve your pages.
>>>
>>> (ns example
>>>   (:require [stasis.core :as stasis]))
>>> (def app (stasis/serve-pages pages))
>>>
>>> Like with any Ring app, you point to your app in project.clj:
>>>
>>> :ring {:handler example/app}
>>>
>>> and start it with lein ring server-headless.
>>> Exporting
>>>  
>>> the pages 
>>>
>>> To export, just give Stasis some pages and a target directory:
>>>
>>> (defn export []
>>>   (stasis/export-pages pages target-dir))
>>>
>>> When you've got this function, you can create an alias for leiningen:
>>>
>>> :aliases {"build-site" ["run" "-m" "example/export"]}
>>>
>>> and run lein build-site on the command line. No need for a lein plugin.
>>>  Exa

Re: core.async over websocket + cljs + clojure

[Alexander Hudek]

We've had something like this working for a while now, though our system 
uses browserchannel rather than websockets since we need to support older 
browsers. On the plus side, browserchannel handles some issues already such 
as managing the state of the connection to the server and retrying when it 
fails. We also have it connected up to rabbitmq on the server side for 
server-to-server communication. It's possible for a backend service to 
broadcast messages right up to multiple connected browsers (e.g. service -> 
web-server-nodes -> clients).

Not all parts are as generic as we'd like for an open source release, but 
seeing as people might be interested we'll try to get some pre-release code 
out somewhat soon.



On Thursday, January 23, 2014 2:55:51 AM UTC-5, Sean Corfield wrote:
>
> Ah, what good timing!
>
> David Pollak's project Plugh does this, essentially as an implementation 
> detail. I spent some time with him today discussing this, as I want to use 
> exactly this functionality in a project I'm building.
>
> The plan is for me to create a standalone project, based on the kernel of 
> David's code, and enhance it to address a number of issues that he 
> identified as needing work before the project could be used in production 
> code, and then - hopefully - people will use it and provide additional 
> integrations (such as core.async over a message hub to provide 
> server-to-server operation, or core.async between browser client and server 
> using more transmission methods than just web sockets).
>
> David's code addresses naming using a registry of channels, identified by 
> GUIDs, on both sides. The web socket reconnection issue is one of the 
> specific enhancements he identified that I plan to figure out and address. 
> There are several others (including actually "GC'ing" closed channels on 
> the other side of the address space divide).
>
> Sean
>  
> On Jan 22, 2014, at 11:39 PM, t x > wrote:
>
> Hi,
>
>   I apologize for my vague question.
>
>   Does anyone have a good example / blog / library for using the 
> core.async abstraction across a websocket.
>
>   * one side of the channel is in clojure land
>   * other side of the channel is in cljs land
>
>   * I promise that all messages can be encoded via pr-str and read via 
> clojure.edn/read-string
>
>   What I'm struggling with are matters of:
>
>   * how to ensure data is not lost even when websocket disconects / 
> reconnects
>
>   * "naming" on client/server side to ensure messages go to right channels 
> on both sides
>
>   * issues I haven't even begun to imagine.
>
>   Good news:
>
>   * I control both sides: both the clj and cljs side, so any workable 
> design is fine.
>
> Thanks!
>
> -- 
> -- 
> 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.
>
>
> 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: core.async over websocket + cljs + clojure

[t x]

Fantastic! I will study these solutions and spam questions later.


On Thu, Jan 23, 2014 at 3:59 PM, Mark Mandel  wrote:

> I'm sure Plugh probably does similar things, but my "learning clojure app"
> has my own custom RPC mechanism over websockets that I wrote (because it
> was fun) that is all based around core.async and uses edn to transfer data
> back and forth.
>
> https://github.com/markmandel/chaperone
>
> Server Side:
>
> https://github.com/markmandel/chaperone/blob/master/src/chaperone/web/websocket.clj
>
> https://github.com/markmandel/chaperone/blob/master/src/chaperone/web/rpc.clj
>
> Client Side:
>
> https://github.com/markmandel/chaperone/blob/master/src-cljs/chaperone/websocket.cljs
>
> Hope that helps.  The project isn't hugely far along, but the RPC
> mechanism works.
>
> Mark
>
>
>
> On Thu, Jan 23, 2014 at 6:55 PM, Sean Corfield  wrote:
>
>> Ah, what good timing!
>>
>> David Pollak's project Plugh does this, essentially as an implementation
>> detail. I spent some time with him today discussing this, as I want to use
>> exactly this functionality in a project I'm building.
>>
>> The plan is for me to create a standalone project, based on the kernel of
>> David's code, and enhance it to address a number of issues that he
>> identified as needing work before the project could be used in production
>> code, and then - hopefully - people will use it and provide additional
>> integrations (such as core.async over a message hub to provide
>> server-to-server operation, or core.async between browser client and server
>> using more transmission methods than just web sockets).
>>
>> David's code addresses naming using a registry of channels, identified by
>> GUIDs, on both sides. The web socket reconnection issue is one of the
>> specific enhancements he identified that I plan to figure out and address.
>> There are several others (including actually "GC'ing" closed channels on
>> the other side of the address space divide).
>>
>> Sean
>>
>> On Jan 22, 2014, at 11:39 PM, t x  wrote:
>>
>> Hi,
>>
>>   I apologize for my vague question.
>>
>>   Does anyone have a good example / blog / library for using the
>> core.async abstraction across a websocket.
>>
>>   * one side of the channel is in clojure land
>>   * other side of the channel is in cljs land
>>
>>   * I promise that all messages can be encoded via pr-str and read via
>> clojure.edn/read-string
>>
>>   What I'm struggling with are matters of:
>>
>>   * how to ensure data is not lost even when websocket disconects /
>> reconnects
>>
>>   * "naming" on client/server side to ensure messages go to right
>> channels on both sides
>>
>>   * issues I haven't even begun to imagine.
>>
>>   Good news:
>>
>>   * I control both sides: both the clj and cljs side, so any workable
>> design is fine.
>>
>> 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.
>>
>>
>> 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)
>>
>>
>>
>>
>
>
> --
> E: mark.man...@gmail.com
> T: http://www.twitter.com/neurotic
> W: www.compoundtheory.com
>
> 2 Devs from Down Under Podcast
> http://www.2ddu.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.
>

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

Re: [ANN] Jig

[Joachim De Beule]

Hi Malcolm,

Thank you for your very helpful reply! 

Indeed, I've also been thinking about "database components", "elasticsearch 
components", "memcache components" and so on that all are async/channels 
(or something) but failed to find the right abstraction so far, so probably 
it is best to separate concerns (if that is what you mean?)  

I have a follow up question if you don't mind. Suppose I want to define a 
component that starts a thread and regularly checks a resource. If the 
resource changes, this has repercussions for other (dependent) components. 
How would you do that in jig? 

-- 
-- 
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: core.async over websocket + cljs + clojure

[Mark Mandel]

I'm sure Plugh probably does similar things, but my "learning clojure app"
has my own custom RPC mechanism over websockets that I wrote (because it
was fun) that is all based around core.async and uses edn to transfer data
back and forth.

https://github.com/markmandel/chaperone

Server Side:
https://github.com/markmandel/chaperone/blob/master/src/chaperone/web/websocket.clj
https://github.com/markmandel/chaperone/blob/master/src/chaperone/web/rpc.clj

Client Side:
https://github.com/markmandel/chaperone/blob/master/src-cljs/chaperone/websocket.cljs

Hope that helps.  The project isn't hugely far along, but the RPC mechanism
works.

Mark


On Thu, Jan 23, 2014 at 6:55 PM, Sean Corfield  wrote:

> Ah, what good timing!
>
> David Pollak's project Plugh does this, essentially as an implementation
> detail. I spent some time with him today discussing this, as I want to use
> exactly this functionality in a project I'm building.
>
> The plan is for me to create a standalone project, based on the kernel of
> David's code, and enhance it to address a number of issues that he
> identified as needing work before the project could be used in production
> code, and then - hopefully - people will use it and provide additional
> integrations (such as core.async over a message hub to provide
> server-to-server operation, or core.async between browser client and server
> using more transmission methods than just web sockets).
>
> David's code addresses naming using a registry of channels, identified by
> GUIDs, on both sides. The web socket reconnection issue is one of the
> specific enhancements he identified that I plan to figure out and address.
> There are several others (including actually "GC'ing" closed channels on
> the other side of the address space divide).
>
> Sean
>
> On Jan 22, 2014, at 11:39 PM, t x  wrote:
>
> Hi,
>
>   I apologize for my vague question.
>
>   Does anyone have a good example / blog / library for using the
> core.async abstraction across a websocket.
>
>   * one side of the channel is in clojure land
>   * other side of the channel is in cljs land
>
>   * I promise that all messages can be encoded via pr-str and read via
> clojure.edn/read-string
>
>   What I'm struggling with are matters of:
>
>   * how to ensure data is not lost even when websocket disconects /
> reconnects
>
>   * "naming" on client/server side to ensure messages go to right channels
> on both sides
>
>   * issues I haven't even begun to imagine.
>
>   Good news:
>
>   * I control both sides: both the clj and cljs side, so any workable
> design is fine.
>
> 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.
>
>
> 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)
>
>
>
>


-- 
E: mark.man...@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

2 Devs from Down Under Podcast
http://www.2ddu.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: core.async over websocket + cljs + clojure

[Logan Linn]

I've been working on a game in my spare time that does this.

The Clojure backend and ClojureScript client communicate with core.async 
over WebSocket carrying edn data

Game: https://github.com/loganlinn/ji
Client WebSocket using: https://github.com/loganlinn/cljs-websockets-async
Server WebSocket using: https://github.com/lynaghk/jetty7-websockets-async

I had hoped to have writeup about this technique by now, but coding seems 
to take higher priority when I get free time :P

On Wednesday, January 22, 2014 11:39:06 PM UTC-8, t x wrote:
>
> Hi,
>
>   I apologize for my vague question.
>
>   Does anyone have a good example / blog / library for using the 
> core.async abstraction across a websocket.
>
>   * one side of the channel is in clojure land
>   * other side of the channel is in cljs land
>
>   * I promise that all messages can be encoded via pr-str and read via 
> clojure.edn/read-string
>
>   What I'm struggling with are matters of:
>
>   * how to ensure data is not lost even when websocket disconects / 
> reconnects
>
>   * "naming" on client/server side to ensure messages go to right channels 
> on both sides
>
>   * issues I haven't even begun to imagine.
>
>   Good news:
>
>   * I control both sides: both the clj and cljs side, so any workable 
> design is fine.
>
> 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: semantics of >! on closed channels

[t x]

Everything works as expected now.

Thanks!


On Thu, Jan 23, 2014 at 12:54 PM, Timothy Baldridge wrote:

> This document should help you find the repo you need to add:
>
> http://dev.clojure.org/display/community/Maven+Settings+and+Repositories
>
> Timothy
>
>
> On Thu, Jan 23, 2014 at 1:49 PM, t x  wrote:
>
>> With apologies for my ignorance:
>>
>> Is there a way to tell lein:
>>
>>   I want to pull the code state defined by this commit: ?
>>
>> https://github.com/clojure/core.async/commit/76b25bf91c670b0c3542ed9cb687ff29fb2183a7
>>
>> (I tried "0.1.0-SNAPSHOT" but it appears not updated yet.)
>>
>>
>> On Thu, Jan 23, 2014 at 6:07 AM, Timothy Baldridge 
>> wrote:
>>
>>> t x, these change you suggest are almost exactly what we have done in
>>> the "put ret" branch. I merged these changes into master this morning, and
>>> would be interested in your feedback. Within a few hours these changes
>>> should be available via the 0.1.0-SNAPSHOT version of core.async, or via
>>> downloading the core.async source and doing "lein install" from the
>>> directory.
>>>
>>> I just sent an email to this mailing list that explains these changes
>>> and the updated semantics.
>>>
>>> I hope this helps,
>>>
>>> Timothy Baldridge
>>>
>>>
>>> On Thu, Jan 23, 2014 at 5:53 AM, Meikel Brandmeyer (kotarak) <
>>> m...@kotka.de> wrote:
>>>
 Hi,

 there is only one reason I can imagine to close a channel: the one in
 charge determined that there is not more input. And the one in charge is
 either the producing side, or a kind of supervisor. In the latter case a
 separate way of communication is needed to inform the sender, that they
 should stop sending. This could be done via the channel. Or something
 completely separate.

 I haven't used core.async much. I'm trying to understand myself what
 useful patterns are. Do you have a simple use case, where the pattern you
 describe (a supervisor closes an input channel without notifying senders
 about it) is the most straight-forward way?

 (All that doesn't mean that core.async couldn't be modified as you
 suggest.)

 Meikel

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

Re: [ANN?]: ring-jetty-adapter with jetty 9.1.x

[James Reeves]

You might want to give it a different name, like ring-jetty9-adapter,
otherwise it might be confused with the ring-jetty-adapter package in Ring
itself.

- James


On 23 January 2014 22:39, Andrey Antukh  wrote:

> Hi!
>
> I have port the current ring-jetty-adapter from current ring repository to
> use jetty 9.1.1 version.
>
> I understand that current ring-jetty-adapter uses 7.6.x branch for java
> 1.5 compatibility, but in environments when all apps runs over jdk7, jetty
> 9.x seems more modern environment.
>
> if the main project in a future is going to have intention to update to
> Jetty 9.x, I will mark my package/library as deprecated.
>
> https://github.com/niwibe/ring-jetty-adapter
>
> Greetings.
> Andrey
> --
> Andrey Antukh - Андрей Антух -  / <
> n...@niwi.be>
> http://www.niwi.be 
> https://github.com/niwibe
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

[ANN?]: ring-jetty-adapter with jetty 9.1.x

[Andrey Antukh]

Hi!

I have port the current ring-jetty-adapter from current ring repository to
use jetty 9.1.1 version.

I understand that current ring-jetty-adapter uses 7.6.x branch for java 1.5
compatibility, but in environments when all apps runs over jdk7, jetty 9.x
seems more modern environment.

if the main project in a future is going to have intention to update to
Jetty 9.x, I will mark my package/library as deprecated.

https://github.com/niwibe/ring-jetty-adapter

Greetings.
Andrey
-- 
Andrey Antukh - Андрей Антух -  / 
http://www.niwi.be 
https://github.com/niwibe

-- 
-- 
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: core.async over websocket + cljs + clojure

[ckirkendall]

I recently gave a talk about doing this.  You can find the code for my talk 
here:  https://github.com/ckirkendall/chatter-box,  Its a group chat 
application that has the feel of twitter.  It uses core.async and 
websockets.  The core.async code is bit dated but the websocket stuff 
should be good to go.  If your interested in seeing the talk: 
http://www.youtube.com/watch?v=jj6eQieGWqo&list=TLaY6nSMlp35yusQFm7HAZPE607i_re1Cv

CK

On Thursday, January 23, 2014 2:39:06 AM UTC-5, t x wrote:
>
> Hi,
>
>   I apologize for my vague question.
>
>   Does anyone have a good example / blog / library for using the 
> core.async abstraction across a websocket.
>
>   * one side of the channel is in clojure land
>   * other side of the channel is in cljs land
>
>   * I promise that all messages can be encoded via pr-str and read via 
> clojure.edn/read-string
>
>   What I'm struggling with are matters of:
>
>   * how to ensure data is not lost even when websocket disconects / 
> reconnects
>
>   * "naming" on client/server side to ensure messages go to right channels 
> on both sides
>
>   * issues I haven't even begun to imagine.
>
>   Good news:
>
>   * I control both sides: both the clj and cljs side, so any workable 
> design is fine.
>
> 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.

[ANN] Counterclockwise 0.23.0

[Laurent PETIT]

Hello,

New release for Counterclockwise.

It is a small release, but with features important for end users:

- works again with Eclipse Indigo
- Version numbers are more apparent in the Install section of the
documentation, the About page of the Standalone product, and in the
filename of the Standalone products.

Whole story in the ChangeLog, as usual.

Install
=

Installation instructions are in the documentation:

http://doc.ccw-ide.org/documentation.html#_install_counterclockwise

Release Note
==
http://doc.ccw-ide.org/ChangeLog.html#_changes_between_counterclockwise_0_22_0_and_0_23_0

Cheers,

-- 
Laurent Petit

-- 
-- 
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: [core.async] New put api

[Timothy Baldridge]

Sadly, put! on a closed channel has never thrown an exception (regardless
of what the docstring says).

I'll list the semantics, but note that the wording gets a bit clumsy due to
the way threading works. So if I say "if the channel is closed when the
put! occurs", the "occurs" is at the time that the lock happens internally
to the channel. So it's possible to call put! and then close the channel
before the call to put returns. I assume that this behavior makes sense to
most.

Semantics are thus:

Definition of terms:

put succeeded - the channel was not closed, and the put found a pending take
put enqueued - the channel was not closed, and no takers were found.


With this patch:

>!, >!! now returns true if the put succeeded. A falsey value is returned
if the put was discarded due to the channel being closed.

(put! c val) returns true if the put was enqueued or succeeded.

(put! c val callback) callback is called with true if the put succeeded.
The callback is called with falsey if the value was discarded due to the
channel being closed.

The part that trips some people up is that the value returned by the put is
both returned and handed to the callback, so there are two ways to get the
value.

--

So to answer your question about closing with pending puts.

1) call put! on an open channel with no takes.
2) put! returns true, since the put was enqueued. But since it was
enqueued, the callback has not been dispatched.
3) close! the channel. Still no dispatch as close! does not discard data
4) call take!. The take will succeed instantly (due to the pending put),
and the callback will be dispatched with true since the put succeeded.

Therefore, the value given the callback is less about the status of the
channel, and more about if the value has been given to a taker.

One more example:

1) call put! on a closed channel
2) put returns falsey
3) the callback is dispatched with falsey


Hopefully this helps.

Timothy


On Thu, Jan 23, 2014 at 2:28 PM, Sean Corfield  wrote:

> Can you confirm:
>
> * Today, calling put! on a closed channel throws an exception (according
> to its docstring).
> * After this change, calling put! on a closed channel will return nil
> instead.
>
> The current docstring says that the function will be called "when
> complete" which I took to mean when the value is actually placed in the
> channel (i.e., no longer pending) so I'm confused by your comment about
> pending puts... What happens if a put is enqueued on an open channel and
> then it is closed before the put is "complete"? It seems like put! would
> return true and the function would simply not be called?
>
> Just trying to make sure I understand this properly.
>
> I think it's a good change (even tho' it breaks any code that uses put!
> and expects it to throw an exception).
>
> Sean
>
> On Jan 23, 2014, at 6:05 AM, Timothy Baldridge 
> wrote:
> > I'm looking for some feedback on recent changes Rich and I have made to
> core.async:
> >
> > I merged the "put ret" branch into master of core.async. This commit
> introduces some changes to the core.async API that provides feedback during
> a put! operation.
> >
> > The changes to the public api are fairly simple:
> >
> > (let [result (put! c 42 (fn [result] nil))]
> >   nil)
> >
> > In this snippet, both result variables (in the callback and in the
> return value) will return true, unless the channel is already closed. Since
> this value is propagated to >! as well, termination of writers is now
> fairly easy:
> >
> > (loop [x 0]
> >   (when (>! c x)
> > (recur (inc x
> >
> > Note: these new semantics don't change how pending puts are handled when
> a channel closes. So if a put! returns true, the callback will not later be
> called with false if the channel is closed. Once a put operation is
> enqueued it will stay enqueued until a taker removes the operation. Close!
> will still not remove pending puts.
> >
> > WARNING!!! The inclusion of these changes means we have to break the
> public API. The function handed to put! now takes one argument instead of
> zero arguments. This will instantly break any code that uses put!.
> Therefore when upgrading to 0.1.0-SNAPSHOT you will need to update all
> calls to put!. I'm sorry about this, but there's really no other way to get
> these changes into the api.
> >
> > Please let me know about any bugs you find in the current 0.1.0-SNAPSHOT.
>
>


-- 
"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/cloju

Re: [core.async] New put api

[Sean Corfield]

Can you confirm:

* Today, calling put! on a closed channel throws an exception (according to its 
docstring).
* After this change, calling put! on a closed channel will return nil instead.

The current docstring says that the function will be called "when complete" 
which I took to mean when the value is actually placed in the channel (i.e., no 
longer pending) so I'm confused by your comment about pending puts... What 
happens if a put is enqueued on an open channel and then it is closed before 
the put is "complete"? It seems like put! would return true and the function 
would simply not be called?

Just trying to make sure I understand this properly.

I think it's a good change (even tho' it breaks any code that uses put! and 
expects it to throw an exception).

Sean

On Jan 23, 2014, at 6:05 AM, Timothy Baldridge  wrote:
> I'm looking for some feedback on recent changes Rich and I have made to 
> core.async: 
> 
> I merged the "put ret" branch into master of core.async. This commit 
> introduces some changes to the core.async API that provides feedback during a 
> put! operation. 
> 
> The changes to the public api are fairly simple:
> 
> (let [result (put! c 42 (fn [result] nil))]
>   nil)
> 
> In this snippet, both result variables (in the callback and in the return 
> value) will return true, unless the channel is already closed. Since this 
> value is propagated to >! as well, termination of writers is now fairly easy:
> 
> (loop [x 0]
>   (when (>! c x)
> (recur (inc x
> 
> Note: these new semantics don't change how pending puts are handled when a 
> channel closes. So if a put! returns true, the callback will not later be 
> called with false if the channel is closed. Once a put operation is enqueued 
> it will stay enqueued until a taker removes the operation. Close! will still 
> not remove pending puts. 
> 
> WARNING!!! The inclusion of these changes means we have to break the public 
> API. The function handed to put! now takes one argument instead of zero 
> arguments. This will instantly break any code that uses put!. Therefore when 
> upgrading to 0.1.0-SNAPSHOT you will need to update all calls to put!. I'm 
> sorry about this, but there's really no other way to get these changes into 
> the api. 
> 
> Please let me know about any bugs you find in the current 0.1.0-SNAPSHOT.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Clojure run time isolation with the ability to share data structures

[Arnout Roemers]

Hi Giri,

At my company, we also desired multiple, isolated Clojure runtimes in one 
JVM instance, sharing Clojure data structures/types. So indeed, we also 
created special ClassLoaders in order to do this. We had the same problem 
with some data types being tied to the Clojure runtime somehow. Even more, 
there is also the problem with package protected fields in some of those 
data structure/type classes, causing issues when an isolated 
clojure.lang.RT tries to access a commonly loaded data structure/type. 

Our solution: patch the Clojure runtime. For us, the result is that we can 
share almost anything, including keywords, functions and vars. Our patched 
Clojure can be found at http://github.com/touch/clojure. It is not a tidy 
patch (as the diff shows many whitespace/indent changes), but maybe it is 
of some use to you.

In the long run, we plan to make a tidy patch, and also release our Clojure 
runtime container software as an open source project.

-Arnout

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

Solutions for subclassing java.io.InputStream

[James Reeves]

Hi folks,

Is anyone aware of any Clojure solutions or libraries for subclassing the
java.io.InputStream class?

The proxy function doesn't work in this case, and gen-class requires some
fiddling to get operational.

Ideally I'd be looking for a library that derives an InputStream from an
IFn. Is there anything like that around already?

- James

-- 
-- 
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: Informatica Online Training By Experienced Trainers in Australia, USA, Canada

[Andy Fingerhut]

Banned from the Clojure group for reason of spamming.

Andy


On Thu, Jan 23, 2014 at 1:11 PM, Sean Corfield  wrote:

> This company has been spamming various technical lists lately with this
> same generic promotion. Can a moderator please report them for spam and ban
> them?
>
> Thank you!
>
> Sean
>
> On Jan 23, 2014, at 2:04 AM, Online Training 
> wrote:
>
> SunItLabs provides the best Software's training for various Computer IT
> courses through Webex, Gotomeeting. We are providing Informatica 
> Trainingbased on specific 
> needs of the learners especially we will give innovative
> one to one Classes which has great opportunities in the present IT market.
> We also provides Class room course to contend with today's competitive IT
> world.
>
> Please call us for the Demo Classes we have regular batches and weekend
> batches.
>
> Contact Number : India :+91 9030928000,
>
> Email : i...@sunitlabs.com ,
>
> Web: http://sunitlabs.com/informatica-online-training/
>
>
>
>

-- 
-- 
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: Informatica Online Training By Experienced Trainers in Australia, USA, Canada

[Sean Corfield]

This company has been spamming various technical lists lately with this same 
generic promotion. Can a moderator please report them for spam and ban them?

Thank you!

Sean

On Jan 23, 2014, at 2:04 AM, Online Training  wrote:

> SunItLabs provides the best Software’s training for various Computer IT 
> courses through Webex, Gotomeeting. We are providing Informatica Training 
> based on specific needs of the learners especially we will give innovative 
> one to one Classes which has great opportunities in the present IT market. We 
> also provides Class room course to contend with today’s competitive IT world. 
> 
> Please call us for the Demo Classes we have regular batches and weekend 
> batches.
> 
> Contact Number : India :+91 9030928000,
> 
> Email : i...@sunitlabs.com ,
> 
> Web: http://sunitlabs.com/informatica-online-training/
> 




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: semantics of >! on closed channels

[Timothy Baldridge]

This document should help you find the repo you need to add:

http://dev.clojure.org/display/community/Maven+Settings+and+Repositories

Timothy


On Thu, Jan 23, 2014 at 1:49 PM, t x  wrote:

> With apologies for my ignorance:
>
> Is there a way to tell lein:
>
>   I want to pull the code state defined by this commit: ?
>
> https://github.com/clojure/core.async/commit/76b25bf91c670b0c3542ed9cb687ff29fb2183a7
>
> (I tried "0.1.0-SNAPSHOT" but it appears not updated yet.)
>
>
> On Thu, Jan 23, 2014 at 6:07 AM, Timothy Baldridge 
> wrote:
>
>> t x, these change you suggest are almost exactly what we have done in the
>> "put ret" branch. I merged these changes into master this morning, and
>> would be interested in your feedback. Within a few hours these changes
>> should be available via the 0.1.0-SNAPSHOT version of core.async, or via
>> downloading the core.async source and doing "lein install" from the
>> directory.
>>
>> I just sent an email to this mailing list that explains these changes and
>> the updated semantics.
>>
>> I hope this helps,
>>
>> Timothy Baldridge
>>
>>
>> On Thu, Jan 23, 2014 at 5:53 AM, Meikel Brandmeyer (kotarak) > > wrote:
>>
>>> Hi,
>>>
>>> there is only one reason I can imagine to close a channel: the one in
>>> charge determined that there is not more input. And the one in charge is
>>> either the producing side, or a kind of supervisor. In the latter case a
>>> separate way of communication is needed to inform the sender, that they
>>> should stop sending. This could be done via the channel. Or something
>>> completely separate.
>>>
>>> I haven't used core.async much. I'm trying to understand myself what
>>> useful patterns are. Do you have a simple use case, where the pattern you
>>> describe (a supervisor closes an input channel without notifying senders
>>> about it) is the most straight-forward way?
>>>
>>> (All that doesn't mean that core.async couldn't be modified as you
>>> suggest.)
>>>
>>> Meikel
>>>
>>> --
>>> --
>>> 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.
>>
>
>  --
> --
> 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/c

Re: semantics of >! on closed channels

[t x]

With apologies for my ignorance:

Is there a way to tell lein:

  I want to pull the code state defined by this commit: ?
https://github.com/clojure/core.async/commit/76b25bf91c670b0c3542ed9cb687ff29fb2183a7

(I tried "0.1.0-SNAPSHOT" but it appears not updated yet.)


On Thu, Jan 23, 2014 at 6:07 AM, Timothy Baldridge wrote:

> t x, these change you suggest are almost exactly what we have done in the
> "put ret" branch. I merged these changes into master this morning, and
> would be interested in your feedback. Within a few hours these changes
> should be available via the 0.1.0-SNAPSHOT version of core.async, or via
> downloading the core.async source and doing "lein install" from the
> directory.
>
> I just sent an email to this mailing list that explains these changes and
> the updated semantics.
>
> I hope this helps,
>
> Timothy Baldridge
>
>
> On Thu, Jan 23, 2014 at 5:53 AM, Meikel Brandmeyer (kotarak) 
> wrote:
>
>> Hi,
>>
>> there is only one reason I can imagine to close a channel: the one in
>> charge determined that there is not more input. And the one in charge is
>> either the producing side, or a kind of supervisor. In the latter case a
>> separate way of communication is needed to inform the sender, that they
>> should stop sending. This could be done via the channel. Or something
>> completely separate.
>>
>> I haven't used core.async much. I'm trying to understand myself what
>> useful patterns are. Do you have a simple use case, where the pattern you
>> describe (a supervisor closes an input channel without notifying senders
>> about it) is the most straight-forward way?
>>
>> (All that doesn't mean that core.async couldn't be modified as you
>> suggest.)
>>
>> Meikel
>>
>> --
>> --
>> 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.
>

-- 
-- 
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: leiningen and local maven repo

[Andy Fingerhut]

Why did you add that to your repositories?

You can do 'lein install' to install a project into your local Maven repo,
and by default Leiningen will check for local copies of JARs in your local
Maven repo before going out to the Internet to look for them.

Andy


On Thu, Jan 23, 2014 at 9:35 AM, Maris  wrote:

>
> I added this to project.clj
>
> :repositories {"project" "file:/home/maris/.m2/repository"}
>
>
> Exception in thread "FileRepositoryConnector-1"
> java.lang.IllegalArgumentException: number of transferred bytes cannot be
> negative
> at
> org.sonatype.aether.util.listener.DefaultTransferEvent.setTransferredBytes(DefaultTransferEvent.java:123)
> at
> org.sonatype.aether.connector.file.FileRepositoryWorker.run(FileRepositoryWorker.java:299)
> at
> org.sonatype.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:60)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Uberjar aborting because jar failed: number of transferred bytes cannot be
> negative
>
> --
> --
> 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] mod-lang-clojure (for Vert.x) 1.0.0.Beta1 released

[Josh Kamau]

Awesome work guys.   I noted there is also some activity on the lein-vertx
github project.

Josh


On Tue, Jan 21, 2014 at 7:32 PM, Toby Crawley  wrote:

> mod-lang-clojure[0] 1.0.0.Beta1 is no available in Maven Central.
>
> With this release, the API should be complete, and we hope to get a
> 1.0.0.Final out in time to be included in bundled language
> implementation list in Vert.x 2.1.Final (due to be released in the next
> few weeks).
>
> So if you are interested in Clojure support on Vert.x, take this for a
> spin and help us shake out any issues before 1.0.0.
>
> You can see what changed in this release in the ChangeLog[1], and see
> how to use it with Vert.x 2.1M3 in the README[2].
>
> # What is mod-lang-clojure?
>
> mod-lang-clojure is the Clojure language module for Vert.x[3]. Vert.x is
> an asynchronous polyglot application platform based on Netty.
>
> - Toby
>
> [0]: https://github.com/vert-x/mod-lang-clojure/
> [1]:
> https://github.com/vert-x/mod-lang-clojure/blob/master/ChangeLog.md[1]
> [2]: https://github.com/vert-x/mod-lang-clojure#mod-lang-clojure[2]
> [3]: http://vertx.io/
>
> --
> --
> 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.

leiningen and local maven repo

[Maris]

I added this to project.clj

:repositories {"project" "file:/home/maris/.m2/repository"}


Exception in thread "FileRepositoryConnector-1" 
java.lang.IllegalArgumentException: number of transferred bytes cannot be 
negative
at 
org.sonatype.aether.util.listener.DefaultTransferEvent.setTransferredBytes(DefaultTransferEvent.java:123)
at 
org.sonatype.aether.connector.file.FileRepositoryWorker.run(FileRepositoryWorker.java:299)
at 
org.sonatype.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:60)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Uberjar aborting because jar failed: number of transferred bytes cannot be 
negative

-- 
-- 
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: Help about using clojure in org mode in Emacs with CIDER

[Bastien]

Hi Greg,

greg r  writes:

> I would like to edit this page to bring it up to date with Cider, and
> I would like to help
> as soon as I figure out the process with keys and git!

Great -- the steps

1. Create your public key if needed: ~$ ssh-keygen
2. Send ~/.ssh/id_rsa.pub to me
3. Wait for my confirmation that I added you to Worg
4. Clone Worg: ~$ git clone w...@orgmode.org:worg.git
5. Edit... commit... push!

That's it.  Let me know if I can help a bit more,
I'm glad some more people take care of Worg!

Best,

-- 
 Bastien

-- 
-- 
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: Help about using clojure in org mode in Emacs with CIDER

[greg r]

We had a discussion about this in the cider-emacs group:

https://groups.google.com/forum/#!topic/cider-emacs/xj-HYTAA-D0

Bastien's page on using Overtone with Clojure in org code blocks is very 
informative with regards to setting it all up:

http://bzg.fr/emacs-org-babel-overtone-intro.html

Note that the worg page for Clojure is out of date:

http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-clojure.html

This references swank-clojure which is depracated.
I would like to edit this page to bring it up to date with Cider, and I 
would like to help
as soon as I figure out the process with keys and git!

Good luck with org-mode, cider and Clojure code blocks.  It's a great way 
to code and experiment, as well
as create dynamic documents.  I've had very good results with the system.

Regards,
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/groups/opt_out.

Re: semantics of >! on closed channels

[Timothy Baldridge]

t x, these change you suggest are almost exactly what we have done in the
"put ret" branch. I merged these changes into master this morning, and
would be interested in your feedback. Within a few hours these changes
should be available via the 0.1.0-SNAPSHOT version of core.async, or via
downloading the core.async source and doing "lein install" from the
directory.

I just sent an email to this mailing list that explains these changes and
the updated semantics.

I hope this helps,

Timothy Baldridge


On Thu, Jan 23, 2014 at 5:53 AM, Meikel Brandmeyer (kotarak) 
wrote:

> Hi,
>
> there is only one reason I can imagine to close a channel: the one in
> charge determined that there is not more input. And the one in charge is
> either the producing side, or a kind of supervisor. In the latter case a
> separate way of communication is needed to inform the sender, that they
> should stop sending. This could be done via the channel. Or something
> completely separate.
>
> I haven't used core.async much. I'm trying to understand myself what
> useful patterns are. Do you have a simple use case, where the pattern you
> describe (a supervisor closes an input channel without notifying senders
> about it) is the most straight-forward way?
>
> (All that doesn't mean that core.async couldn't be modified as you
> suggest.)
>
> Meikel
>
> --
> --
> 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.

[core.async] New put api

[Timothy Baldridge]

I'm looking for some feedback on recent changes Rich and I have made to
core.async:

I merged the "put ret" branch into master of core.async. This commit
introduces some changes to the core.async API that provides feedback during
a put! operation.

The changes to the public api are fairly simple:

(let [result (put! c 42 (fn [result] nil))]
  nil)

In this snippet, both result variables (in the callback and in the return
value) will return true, unless the channel is already closed. Since this
value is propagated to >! as well, termination of writers is now fairly
easy:

(loop [x 0]
  (when (>! c x)
(recur (inc x

Note: these new semantics don't change how pending puts are handled when a
channel closes. So if a put! returns true, the callback will not later be
called with false if the channel is closed. Once a put operation is
enqueued it will stay enqueued until a taker removes the operation. Close!
will still not remove pending puts.

WARNING!!! The inclusion of these changes means we have to break the public
API. The function handed to put! now takes one argument instead of zero
arguments. This will instantly break any code that uses put!. Therefore
when upgrading to 0.1.0-SNAPSHOT you will need to update all calls to put!.
I'm sorry about this, but there's really no other way to get these changes
into the api.

Please let me know about any bugs you find in the current 0.1.0-SNAPSHOT.

Thanks,

Timothy Baldridge

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

[Malcolm Sparks]

Hi Joachim

The component lifecycle protocol is used to group together the init, start
and stop functions tied to ephemeral services common to many Java
server-side applications. I'm not sure it makes sense for components to
satisfy other protocols that are functional in nature, as this invite
coupling of concerns. The intention is that component functions
inject/reject state into/from the system map. Your suggestion of retaining
a JDBC connection under [:jdbc-component :db] is exactly what Jig intends.
Clojure applications should, as far as possible, avoid state. But when
applications need to retain state, they should do so in a system map that
is continually subject to repetitive creation and destruction, if only to
avoid the detrimental effect that stale state can have on the speedy and
iterative development of applications.

I have toyed with the idea of adding core.async protocols and
provides/requires metadata to components, but none of my approaches have
felt satisfactory. I think it's better to keep components as lightweight as
possible, letting them setup and teardown state within the system map, and
with that as their single responsibility. (However, if you have alternative
suggestions, do let me know)

Regards,

Malcolm


On 22 January 2014 22:22, Joachim De Beule wrote:

> (follow up)
>
> I just realized that another approach would be to hold the jdbc connection
> type implementing the JDBCProtocol in system under [:jdbc-component :db] or
> something, and then call the clojure.java.jdbc/query like functions on
> that. Anyway, I would be very happy to hear your comments on this!
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/E0BdR_AksiA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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: avoiding repetition in ns declarations

[Phillip Lord]

Konrad Hinsen  writes:
>>   I have the following problem:
>>
>> (ns foo.bar
>>   ...
>>   ...
>>   ... )
>>
>> There's basically 10 lines of require that I want as part of nearly
>> _every_ ns I declare is there a way to define some soft of alias /
>> abbrevraviation that is used in namespaces at will?
>
> The nstools library lets you do exactly that:
>
>   https://code.google.com/p/clj-nstools/


That looks nice; why not open up the reference-map though, so that it
would become extensible.

Phil

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

Re: semantics of >! on closed channels

[Meikel Brandmeyer (kotarak)]

Hi,

there is only one reason I can imagine to close a channel: the one in 
charge determined that there is not more input. And the one in charge is 
either the producing side, or a kind of supervisor. In the latter case a 
separate way of communication is needed to inform the sender, that they 
should stop sending. This could be done via the channel. Or something 
completely separate.

I haven't used core.async much. I'm trying to understand myself what useful 
patterns are. Do you have a simple use case, where the pattern you describe 
(a supervisor closes an input channel without notifying senders about it) 
is the most straight-forward way?

(All that doesn't mean that core.async couldn't be modified as you suggest.)

Meikel

-- 
-- 
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: Help about using clojure in org mode in Emacs with CIDER

[Bastien]

Rui Yang  writes:

> Sorry if missed sth.

No, my bad: cider is supported in the master (development)*
branch, not in the latest stable Org release.

> I will try to install org from master and have a try.

 ~$ git clone git://orgmode.org/org-mode.git
 ~$ make autoloads

and update your load-path in Emacs.

HTH,

-- 
 Bastien

-- 
-- 
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: semantics of >! on closed channels

[t x]

Following up on this, will something terrible happen if:

https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj#L59

was changed from
(box nil)
to
(box :chan-closed)


On Thu, Jan 23, 2014 at 4:21 AM, t x  wrote:

> Hi,
>
>   * This is the time I've heard "the one who's feeding the channel is the
> one in charge of closing it" -- previously, my channel code was fairly
> ad-hoc and agressive (since I need to kill many (go-loop [msg ( (when msg ...)) blocks).
>
>   * I still feel this breaks the "conveyor belt" metaphor -- when a
> conveyor belt shuts down, it's understandable that we after we take what's
> on the belt, in future takes, we get nothing.
>
>   However, when putting items on a stopped conveyor belt, messages should
> not just *poof* vanish into the void. :-)
>
>   * This existing semantics makes debugging annoying (perhaps this is due
> to my lack of skill). When something should be happening, and nothing is
> happening, I'm basically going around hunting for "where did I do a put on
> a closed channel", whereas if it threw an exception of some form, it'd be
> easier to handle then this "silent fail."
>
>
>
>
> On Thu, Jan 23, 2014 at 3:50 AM, Meikel Brandmeyer (kotarak) 
> wrote:
>
>> Hi,
>>
>> probably the idea is, that the one who's feeding the channel is the one
>> in charge of closing it. After all, they know when there is no more input
>> available. Do you have a use case where this problem manifests? Or is that
>> just a vague fear that it might happen?
>>
>> Kind regards
>> Meikel
>>
>>  --
>> --
>> 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: semantics of >! on closed channels

[t x]

Hi,

  * This is the time I've heard "the one who's feeding the channel is the
one in charge of closing it" -- previously, my channel code was fairly
ad-hoc and agressive (since I need to kill many (go-loop [msg (wrote:

> Hi,
>
> probably the idea is, that the one who's feeding the channel is the one in
> charge of closing it. After all, they know when there is no more input
> available. Do you have a use case where this problem manifests? Or is that
> just a vague fear that it might happen?
>
> Kind regards
> Meikel
>
>  --
> --
> 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: Help about using clojure in org mode in Emacs with CIDER

[Rui Yang]

Thanks for the quick reply.

Emacs version: 24.3.1
Org version: Org-mode version 8.2.4

I actually copied codes of ob-clojure from master to include support for 
cider (sorry, my bad hack). 
But I found it strange in the org-mode git.
the latest stable tag is 8.2.5g doesn't include supporting of *cider*? I 
didn't see the custom variable *org-babel-clojure-backend *in ob-clojure.el.
http://orgmode.org/w/?p=org-mode.git;a=tree;f=lisp;h=7b8c717b559fc55ae22b10ca7c21aec9e94992f2;hb=e5259962f61c398d84d43d33c29a6f021c9b326a

But actually the cider support was introduced in 2013-11-04.
and the code appear in ac7fb4dd79ebfa07e3357f012206186bf3923c08 which is 
the one after the 8.2.5g tag

Sorry if missed sth.

I will try to install org from master and have a try.

Thanks,
Rui

On Thursday, 23 January 2014 22:36:52 UTC+11, Bastien Guerry wrote:
>
> Hi Rui, 
>
> Rui Yang > writes: 
>
> > Any suggestions on fixing this or it is by design ob-clojure only 
> > evaluate one statement? 
>
> What version of Emacs/Org are you using? 
>
> C-h v emacs-version RET 
> C-h v org-version RET 
>
> ob-clojure.el in latest stable release of Org works fine. 
> The one bundled with current Emacs stable version is not. 
>
> HTH, 
>
> -- 
>  Bastien 
>

-- 
-- 
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: semantics of >! on closed channels

[Meikel Brandmeyer (kotarak)]

Hi,

probably the idea is, that the one who's feeding the channel is the one in 
charge of closing it. After all, they know when there is no more input 
available. Do you have a use case where this problem manifests? Or is that 
just a vague fear that it might happen?

Kind regards
Meikel

-- 
-- 
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: trouble with setting up cider within org mode

[Bastien]

Rui Yang  writes:

> I tried to setup cider to use within org mode. I managed to evaluate
> single clojure statement but not multiple.

See my reply in the other group where you posted this.

This works fine with latest stable Org-mode version, which is
not the one that comes with latest stable Emacs version.

-- 
 Bastien

-- 
-- 
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: Help about using clojure in org mode in Emacs with CIDER

[Bastien]

Hi Rui,

Rui Yang  writes:

> Any suggestions on fixing this or it is by design ob-clojure only
> evaluate one statement?

What version of Emacs/Org are you using?

C-h v emacs-version RET
C-h v org-version RET

ob-clojure.el in latest stable release of Org works fine.
The one bundled with current Emacs stable version is not.

HTH,

-- 
 Bastien

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

trouble with setting up cider within org mode

[Rui Yang]

Hi,
I tried to setup cider to use within org mode. I managed to evaluate single 
clojure statement but not multiple.

For example:
#+name: basic-clojure
#+begin_src clojure
(defn greeting
"Returns a greeting of the form 'Hello, username.'"
[username]
(str "Hello, " username))
#+end_src

will be ok.

But 
#+name: basic-clojure
#+begin_src clojure
(defn greeting
"Returns a greeting of the form 'Hello, username.'"
[username]
(str "Hello, " username))
(greeting "Tom")
#+end_src

will throw exception:

java.lang.ClassCastException: java.lang.String cannot be cast to 
java.io.Writer
   column_writer.clj:78 clojure.pprint/column-writer[fn]
   (Unknown Source) 
clojure.pprint.proxy$java.io.Writer$IDeref$db53459f.write
   (Unknown Source) 
sun.reflect.GeneratedMethodAccessor9.invoke
   DelegatingMethodAccessorImpl.java:25 
sun.reflect.DelegatingMethodAccessorImpl.invoke
Method.java:597 java.lang.reflect.Method.invoke
  Reflector.java:93 
clojure.lang.Reflector.invokeMatchingMethod
  Reflector.java:28 
clojure.lang.Reflector.invokeInstanceMethod
  pretty_writer.clj:443 clojure.pprint/start-block[fn]
AFn.java:18 clojure.lang.AFn.call
LockingTransaction.java:263 clojure.lang.LockingTransaction.run
LockingTransaction.java:231 
clojure.lang.LockingTransaction.runInTransaction
  pretty_writer.clj:433 clojure.pprint/start-block
   Var.java:427 clojure.lang.Var.invoke
   dispatch.clj:130 clojure.pprint/pprint-ideref[fn]
   dispatch.clj:130 clojure.pprint/pprint-ideref
   MultiFn.java:227 clojure.lang.MultiFn.invoke
pprint_base.clj:194 clojure.pprint/write-out
pprint_base.clj:250 clojure.pprint/pprint[fn]
pprint_base.clj:248 clojure.pprint/pprint
   NO_SOURCE_FILE:5 user/eval611
 Compiler.java:6619 clojure.lang.Compiler.eval
 Compiler.java:6582 clojure.lang.Compiler.eval
  core.clj:2852 clojure.core/eval
   main.clj:259 clojure.main/repl[fn]
   main.clj:259 clojure.main/repl[fn]
   main.clj:277 clojure.main/repl[fn]
   main.clj:277 clojure.main/repl
   RestFn.java:1096 clojure.lang.RestFn.invoke
  interruptible_eval.clj:56 
clojure.tools.nrepl.middleware.interruptible-eval/evaluate[fn]
   AFn.java:159 clojure.lang.AFn.applyToHelper
   AFn.java:151 clojure.lang.AFn.applyTo
   core.clj:617 clojure.core/apply
  core.clj:1788 clojure.core/with-bindings*
RestFn.java:425 clojure.lang.RestFn.invoke
  interruptible_eval.clj:41 
clojure.tools.nrepl.middleware.interruptible-eval/evaluate
 interruptible_eval.clj:171 
clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval[fn]
  core.clj:2330 clojure.core/comp[fn]
 interruptible_eval.clj:138 
clojure.tools.nrepl.middleware.interruptible-eval/run-next[fn]
AFn.java:24 clojure.lang.AFn.run
ThreadPoolExecutor.java:886 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask
ThreadPoolExecutor.java:908 
java.util.concurrent.ThreadPoolExecutor$Worker.run
Thread.java:662 java.lang.Thread.run

Digging into ob-clojure under org-mode. I managed to repro it like the 
following in Emacs:

(defvar expanded "")
(setq expanded "(clojure.pprint/pprint (defn greeting
\"Returns a greeting of the form 'Hello, username.'\"
[username]
(str \"Hello, \" username))
(greeting \"Tom\"))")

(nrepl-send-string-sync
   expanded
   (cider-current-ns)
   (nrepl-current-tooling-session))


Could someone suggest on how to fix it or it is by design?

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: avoiding repetition in ns declarations

[Phillip Lord]

t x  writes:

> Staurt, Phillip:
>
> Correct me if I'm wrong, the main idea recommended is:
>
> (1) don't try to do it via (:require ...) inside of (ns ... )
> (2) define a function, which calls (require ... ) [i.e. the function,
> outside of (ns ... )]
>
> Thus, the end solution ends up being:
>
> magic.cljx
>
> (defn load-standard-requires []
>   (require ... )
>   (require ... ))

You can make this a little neater, as require is a function. So
something like (untested)...

(defn load-standard-requires[]
(doall [n [[foo][bar]]]
 (require n)))

> foo.cljx:
>
> (ns foo ... )

This needs to require magic.clj

> Can either of you confirm this is the main plan of attack you have
> suggested? (It seems reasonable, but I want to make sure I understand what
> you're recommending.)


It's the only way that I can see.


Phil

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

Re: [ANN] Stasis - not another static site framework

[Magnar Sveen]

Oh, look at that. Thanks! :)


On Thu, Jan 23, 2014 at 11:27 AM, Dmitry Groshev wrote:

> And here is a link to the project, just in case you've missed it like I
> did: https://github.com/magnars/stasis :)
>
>
> On Thursday, January 23, 2014 2:16:48 PM UTC+4, Magnar Sveen wrote:
>>
>> Stasis
>>
>> A Clojure library of tools for developing static web sites.
>> Another
>> static site framework? Why?
>>
>> Well, that's exactly it. I didn't want to use a framework. I don't like
>> the restrained feeling I get when using them. I prefer coding things over
>> messing around with configuration files.
>>
>> I want to
>>
>>- code my own pages
>>- set up my own configuration
>>- choose my own templating library
>>- create my own damn stylesheets
>>
>> *Statis offers a few functions that are pretty useful when creating
>> static web sites.*
>>
>> No more. There are no batteries included.
>>
>> If you want a framework that makes it really quick and easy to create a
>> blog, you should take a look at these:
>>
>>- misaki  is a Jekyll inspired
>>static site generator in Clojure.
>>- Madness  is a static site
>>generator, based on Enlive and Bootstrap.
>>- Static  is a simple static site
>>generator written in Clojure.
>>- Ecstatic  creates static web pages and
>>blog posts from Hiccup templates and Markdown.
>>- incise  is an extensible static
>>site generator written in Clojure.
>>
>> They generally come with a folder where you put your blog posts in some
>> templating language, and a set of configuration options about how to set up
>> your blog. They often generate code for you to tweak.
>>  Usage
>>
>> The core of Stasis is two functions: serve-pages and export-pages. Both
>> take a map from path to contents:
>>
>> (def pages {"/index.html" "Welcome!"})
>>
>> The basic use case is to serve these live on a local server while
>> developing - and then exporting them as static pages to deploy on some
>> server.
>> Serving
>> live pages locally
>>
>> Stasis can create a Ring handler to serve your pages.
>>
>> (ns example
>>   (:require [stasis.core :as stasis]))
>> (def app (stasis/serve-pages pages))
>>
>> Like with any Ring app, you point to your app in project.clj:
>>
>> :ring {:handler example/app}
>>
>> and start it with lein ring server-headless.
>> Exporting
>> the pages
>>
>> To export, just give Stasis some pages and a target directory:
>>
>> (defn export []
>>   (stasis/export-pages pages target-dir))
>>
>> When you've got this function, you can create an alias for leiningen:
>>
>> :aliases {"build-site" ["run" "-m" "example/export"]}
>>
>> and run lein build-site on the command line. No need for a lein plugin.
>>  Example
>> apps?
>>
>> The static page that prompted me to write Stasis is currently closed
>> source, but I'm in the process of turning my 4 other static sites over. The
>> simplest, and first to be done, is:
>>
>>-
>>
>>whattheemacsd.com (source)
>>
>>Uses Enlive  for templating, and
>>Optimus  for frontend
>>optimization.
>>
>> I'm also working on the Emacs Rocks!  webpage,
>> where I'll use hiccup instead of Enlive.
>>  Is
>> it stable?
>>
>> It's still on a 0.x release, but I feel the API has jelled enough now to
>> open source it. I don't expect any major changes at this point. I'll likely
>> push it to 1.0 at the end of the month.
>>
>> Again,
>> why not use one of the existing frameworks?
>>
>> I think the existing frameworks are great if they fit your style. Stasis
>> imposes no styles. There are very few decisions made for you - no markdown
>> vs asciidoc, no enlive vs hiccup. No configuration options. You have to
>> make them.
>>
>> So, yeah ... I think Stasis would be a great starting point if you want
>> to create the 6th static site framework to go in that list at the top. :-)
>>
>>
>> - Magnar
>>
>  --
> --
> 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 grou

Re: [ANN] Stasis - not another static site framework

[Dmitry Groshev]

And here is a link to the project, just in case you've missed it like I 
did: https://github.com/magnars/stasis :)

On Thursday, January 23, 2014 2:16:48 PM UTC+4, Magnar Sveen wrote:
>
> Stasis
>
> A Clojure library of tools for developing static web sites.
>
> Another
>  
> static site framework? Why?
>
> Well, that's exactly it. I didn't want to use a framework. I don't like 
> the restrained feeling I get when using them. I prefer coding things over 
> messing around with configuration files.
>
> I want to
>
>- code my own pages
>- set up my own configuration
>- choose my own templating library
>- create my own damn stylesheets
>
> *Statis offers a few functions that are pretty useful when creating static 
> web sites.*
>
> No more. There are no batteries included.
>
> If you want a framework that makes it really quick and easy to create a 
> blog, you should take a look at these:
>
>- misaki  is a Jekyll inspired 
>static site generator in Clojure.
>- Madness  is a static site 
>generator, based on Enlive and Bootstrap.
>- Static  is a simple static site 
>generator written in Clojure.
>- Ecstatic  creates static web pages and 
>blog posts from Hiccup templates and Markdown.
>- incise  is an extensible static 
>site generator written in Clojure.
>
> They generally come with a folder where you put your blog posts in some 
> templating language, and a set of configuration options about how to set up 
> your blog. They often generate code for you to tweak.
> Usage
>
> The core of Stasis is two functions: serve-pages and export-pages. Both 
> take a map from path to contents:
>
> (def pages {"/index.html" "Welcome!"})
>
> The basic use case is to serve these live on a local server while 
> developing - and then exporting them as static pages to deploy on some 
> server.
>
> Serving
>  
> live pages locally
>
> Stasis can create a Ring handler to serve your pages.
>
> (ns example
>   (:require [stasis.core :as stasis]))
> (def app (stasis/serve-pages pages))
>
> Like with any Ring app, you point to your app in project.clj:
>
> :ring {:handler example/app}
>
> and start it with lein ring server-headless.
> Exporting
>  
> the pages
>
> To export, just give Stasis some pages and a target directory:
>
> (defn export []
>   (stasis/export-pages pages target-dir))
>
> When you've got this function, you can create an alias for leiningen:
>
> :aliases {"build-site" ["run" "-m" "example/export"]}
>
> and run lein build-site on the command line. No need for a lein plugin.
> Example 
> apps?
>
> The static page that prompted me to write Stasis is currently closed 
> source, but I'm in the process of turning my 4 other static sites over. The 
> simplest, and first to be done, is:
>
>- 
>
>whattheemacsd.com (source) 
>
>Uses Enlive  for templating, and 
>Optimus  for frontend optimization.
>
> I'm also working on the Emacs Rocks!  webpage, 
> where I'll use hiccup instead of Enlive.
> Is it 
> stable?
>
> It's still on a 0.x release, but I feel the API has jelled enough now to 
> open source it. I don't expect any major changes at this point. I'll likely 
> push it to 1.0 at the end of the month.
>
> Again,
>  
> why not use one of the existing frameworks?
>
> I think the existing frameworks are great if they fit your style. Stasis 
> imposes no styles. There are very few decisions made for you - no markdown 
> vs asciidoc, no enlive vs hiccup. No configuration options. You have to 
> make them.
>
> So, yeah ... I think Stasis would be a great starting point if you want to 
> create the 6th static site framework to go in that list at the top. :-)
>
>
> - Magnar
>

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

[ANN] Stasis - not another static site framework

[Magnar Sveen]

Stasis

A Clojure library of tools for developing static web sites.
Another
 
static site framework? Why?

Well, that's exactly it. I didn't want to use a framework. I don't like the 
restrained feeling I get when using them. I prefer coding things over 
messing around with configuration files.

I want to

   - code my own pages
   - set up my own configuration
   - choose my own templating library
   - create my own damn stylesheets

*Statis offers a few functions that are pretty useful when creating static 
web sites.*

No more. There are no batteries included.

If you want a framework that makes it really quick and easy to create a 
blog, you should take a look at these:

   - misaki  is a Jekyll inspired static 
   site generator in Clojure.
   - Madness  is a static site 
   generator, based on Enlive and Bootstrap.
   - Static  is a simple static site 
   generator written in Clojure.
   - Ecstatic  creates static web pages and 
   blog posts from Hiccup templates and Markdown.
   - incise  is an extensible static 
   site generator written in Clojure.

They generally come with a folder where you put your blog posts in some 
templating language, and a set of configuration options about how to set up 
your blog. They often generate code for you to tweak.
Usage

The core of Stasis is two functions: serve-pages and export-pages. Both 
take a map from path to contents:

(def pages {"/index.html" "Welcome!"})

The basic use case is to serve these live on a local server while 
developing - and then exporting them as static pages to deploy on some 
server.
Serving
 
live pages locally

Stasis can create a Ring handler to serve your pages.

(ns example
  (:require [stasis.core :as stasis]))
(def app (stasis/serve-pages pages))

Like with any Ring app, you point to your app in project.clj:

:ring {:handler example/app}

and start it with lein ring server-headless.
Exporting
 
the pages

To export, just give Stasis some pages and a target directory:

(defn export []
  (stasis/export-pages pages target-dir))

When you've got this function, you can create an alias for leiningen:

:aliases {"build-site" ["run" "-m" "example/export"]}

and run lein build-site on the command line. No need for a lein plugin.
Example 
apps?

The static page that prompted me to write Stasis is currently closed 
source, but I'm in the process of turning my 4 other static sites over. The 
simplest, and first to be done, is:

   - 
   
   whattheemacsd.com (source) 
   
   Uses Enlive  for templating, and 
   Optimus  for frontend optimization.
   
I'm also working on the Emacs Rocks!  webpage, 
where I'll use hiccup instead of Enlive.
Is it 
stable?

It's still on a 0.x release, but I feel the API has jelled enough now to 
open source it. I don't expect any major changes at this point. I'll likely 
push it to 1.0 at the end of the month.
Again,
 
why not use one of the existing frameworks?

I think the existing frameworks are great if they fit your style. Stasis 
imposes no styles. There are very few decisions made for you - no markdown 
vs asciidoc, no enlive vs hiccup. No configuration options. You have to 
make them.

So, yeah ... I think Stasis would be a great starting point if you want to 
create the 6th static site framework to go in that list at the top. :-)


- Magnar

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

Informatica Online Training By Experienced Trainers in Australia, USA, Canada

[Online Training]

SunItLabs provides the best Software’s training for various Computer IT 
courses through Webex, Gotomeeting. We are providing Informatica 
Trainingbased on specific 
needs of the learners especially we will give innovative 
one to one Classes which has great opportunities in the present IT market. 
We also provides Class room course to contend with today’s competitive IT 
world. 

Please call us for the Demo Classes we have regular batches and weekend 
batches.

Contact Number : India :+91 9030928000,

Email : i...@sunitlabs.com ,

Web: http://sunitlabs.com/informatica-online-training/

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

Help about using clojure in org mode in Emacs with CIDER

[Rui Yang]

Trying to use org mode with clojure. I'd like to use cider as the REPL 
server.
Things is fine if I have only one statement in org source block. If I have 
more than one, then I got exception.

for example

#+name: basic-clojure
#+begin_src clojure
(defn greeting
"Returns a greeting of the form 'Hello, username.'"
[username]
(str "Hello, " username))
#+end_src

will be fine. But

#+name: basic-clojure
#+begin_src clojure
(defn greeting
"Returns a greeting of the form 'Hello, username.'"
[username]
(str "Hello, " username))
*(greeting "Tom")*
#+end_src

will throw exception:

java.lang.ClassCastException: java.lang.String cannot be cast to 
java.io.Writer
   column_writer.clj:78 clojure.pprint/column-writer[fn]
   (Unknown Source) 
clojure.pprint.proxy$java.io.Writer$IDeref$db53459f.write
   (Unknown Source) 
sun.reflect.GeneratedMethodAccessor9.invoke
   DelegatingMethodAccessorImpl.java:25 
sun.reflect.DelegatingMethodAccessorImpl.invoke
Method.java:597 java.lang.reflect.Method.invoke
  Reflector.java:93 
clojure.lang.Reflector.invokeMatchingMethod
  Reflector.java:28 
clojure.lang.Reflector.invokeInstanceMethod
  pretty_writer.clj:443 clojure.pprint/start-block[fn]
AFn.java:18 clojure.lang.AFn.call
LockingTransaction.java:263 clojure.lang.LockingTransaction.run
LockingTransaction.java:231 
clojure.lang.LockingTransaction.runInTransaction
  pretty_writer.clj:433 clojure.pprint/start-block
   Var.java:427 clojure.lang.Var.invoke
   dispatch.clj:130 clojure.pprint/pprint-ideref[fn]
   dispatch.clj:130 clojure.pprint/pprint-ideref
   MultiFn.java:227 clojure.lang.MultiFn.invoke
pprint_base.clj:194 clojure.pprint/write-out
pprint_base.clj:250 clojure.pprint/pprint[fn]
pprint_base.clj:248 clojure.pprint/pprint
   NO_SOURCE_FILE:5 user/eval611
 Compiler.java:6619 clojure.lang.Compiler.eval
 Compiler.java:6582 clojure.lang.Compiler.eval
  core.clj:2852 clojure.core/eval
   main.clj:259 clojure.main/repl[fn]
   main.clj:259 clojure.main/repl[fn]
   main.clj:277 clojure.main/repl[fn]
   main.clj:277 clojure.main/repl
   RestFn.java:1096 clojure.lang.RestFn.invoke
  interruptible_eval.clj:56 
clojure.tools.nrepl.middleware.interruptible-eval/evaluate[fn]
   AFn.java:159 clojure.lang.AFn.applyToHelper
   AFn.java:151 clojure.lang.AFn.applyTo
   core.clj:617 clojure.core/apply
  core.clj:1788 clojure.core/with-bindings*
RestFn.java:425 clojure.lang.RestFn.invoke
  interruptible_eval.clj:41 
clojure.tools.nrepl.middleware.interruptible-eval/evaluate
 interruptible_eval.clj:171 
clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval[fn]
  core.clj:2330 clojure.core/comp[fn]
 interruptible_eval.clj:138 
clojure.tools.nrepl.middleware.interruptible-eval/run-next[fn]
AFn.java:24 clojure.lang.AFn.run
ThreadPoolExecutor.java:886 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask
ThreadPoolExecutor.java:908 
java.util.concurrent.ThreadPoolExecutor$Worker.run
Thread.java:662 java.lang.Thread.run

Digging into ob-clojure.el and I was able to reproduce it in Emacs as:

(defvar expanded "")
(setq expanded "(clojure.pprint/pprint (defn greeting
\"Returns a greeting of the form 'Hello, username.'\"
[username]
(str \"Hello, \" username))
(greeting \"Tom\"))")

(nrepl-send-string-sync
   expanded
   (cider-current-ns)
   (nrepl-current-tooling-session))

Any suggestions on fixing this or it is by design ob-clojure only evaluate 
one statement?

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: avoiding repetition in ns declarations

[Konrad Hinsen]

--On 21 janvier 2014 23:15:50 -0800 t x  wrote:


  I have the following problem:

(ns foo.bar
  ...
  ...
  ... )

There's basically 10 lines of require that I want as part of nearly
_every_ ns I declare is there a way to define some soft of alias /
abbrevraviation that is used in namespaces at will?


The nstools library lets you do exactly that:

  https://code.google.com/p/clj-nstools/

Konrad.

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

[Joachim De Beule]

Op maandag 21 oktober 2013 02:41:43 UTC+2 schreef frye:
>
> Also, is there a Google Group for Jig? I'm playing around with it, can see 
> the potential, and already have some questions. 
>

+1 for the google group ..

-- 
-- 
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: core.async over websocket + cljs + clojure

[Sean Corfield]

On Jan 23, 2014, at 12:18 AM, t x  wrote:
> For anyone else interested, http://www.youtube.com/watch?v=Nb3ztFeFfdw is the 
> talk.

That's David Pollak's talk at Clojure/conj. You'll probably also want to watch 
his Strange Loop talk first, where he introduced the concepts:

http://www.infoq.com/presentations/pushy-data

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: core.async over websocket + cljs + clojure

[t x]

For anyone else interested, http://www.youtube.com/watch?v=Nb3ztFeFfdw is
the talk.


On Wed, Jan 22, 2014 at 11:55 PM, Sean Corfield  wrote:

> Ah, what good timing!
>
> David Pollak's project Plugh does this, essentially as an implementation
> detail. I spent some time with him today discussing this, as I want to use
> exactly this functionality in a project I'm building.
>
> The plan is for me to create a standalone project, based on the kernel of
> David's code, and enhance it to address a number of issues that he
> identified as needing work before the project could be used in production
> code, and then - hopefully - people will use it and provide additional
> integrations (such as core.async over a message hub to provide
> server-to-server operation, or core.async between browser client and server
> using more transmission methods than just web sockets).
>
> David's code addresses naming using a registry of channels, identified by
> GUIDs, on both sides. The web socket reconnection issue is one of the
> specific enhancements he identified that I plan to figure out and address.
> There are several others (including actually "GC'ing" closed channels on
> the other side of the address space divide).
>
> Sean
>
> On Jan 22, 2014, at 11:39 PM, t x  wrote:
>
> Hi,
>
>   I apologize for my vague question.
>
>   Does anyone have a good example / blog / library for using the
> core.async abstraction across a websocket.
>
>   * one side of the channel is in clojure land
>   * other side of the channel is in cljs land
>
>   * I promise that all messages can be encoded via pr-str and read via
> clojure.edn/read-string
>
>   What I'm struggling with are matters of:
>
>   * how to ensure data is not lost even when websocket disconects /
> reconnects
>
>   * "naming" on client/server side to ensure messages go to right channels
> on both sides
>
>   * issues I haven't even begun to imagine.
>
>   Good news:
>
>   * I control both sides: both the clj and cljs side, so any workable
> design is fine.
>
> 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.
>
>
> 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.

semantics of >! on closed channels

[t x]

## What I believe should be right:

** case 1:

  (>! on-closed-channel val) ==> exception thrown

or

** case 2:

  (>! open-channel val) ==> returns val

  (>! closed-channel val) ==> returns nil


## race condition:

  note: I do not consider the following to be a valid "solution"

  (if (open? chan)
(>! chan ...)) ;; race condition prone


## What I consider to be wrong

I understand why ! on a closed channel return nil.

For !, on the sender, I can NOT distinguish "send msg" from "channel is
closed."


Thus, for >! on a sync-channel, it is:

  well, either the channel is open, and we sent it OR the channel is
closed, and we'll silently drop


Also, for >!! on a buffered-channel, it is:

  well, if it's not full, we'll send it, if it's full, we'll park OR if the
channel is closed, we'll pretend the channel was not full and silently drop


Now, here is the thing I don't understand -- why are core.async semantics
defined as such? And is there anyway I can get around this? (It's not clear
I can solve this problem by re-interpreting at either the channel or the
buffer layer).

## Question:

core.async is designed by people far smarter than me. Yet, I can't get this
case to work. What am I doing wrong?

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.