Re: Trouble Running Chime Application outside for repl
Hi Chris, Thanks for posting an example - unfortunately I can't get onto it at the moment because it seems gitlab is down :( FWIW, I've seen a similar issue before where the schedule will run for a minute or so, then the process will exit successfully (even though you'd like it to continue) - is this what you're seeing? If so, this was caused by there being no non-daemon threads left running in the JVM, so the JVM exited - we worked around that by adding `@(promise)` to the end of our `-main` function, which had the effect of indefinitely pausing the main thread, and allowing the schedule to continue. If not, I'll try gitlab again in a bit! James On Monday, November 21, 2016 at 3:03:45 PM UTC, Chris Snyder wrote: > > > Have a program I want to run every 5 seconds unless the previous run is > not finished then I want it to wait on the previous run to finish. > To do this I used a library called Chime (https://github.com/jarohen/chime). > > > *The Problem* is the program works perfectly in repl but will not work > outside out of it? > > lein trampoline run - does not work > lein run - does not work > Java -jar (point to the uberjar file) - does not work > > lein repl then running main -does work > > Here is a small example I put together > https://gitlab.com/csnyder/chime-test/tree/master > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Introducing Yo-yo, a protocol-less, function composition-based alternative to Component
Hey Thomas, thanks for your e-mail :)
On Monday, 29 June 2015 11:25:44 UTC+1, Thomas Heller wrote:
>
> Hey,
>
> interesting approach but I don't like the nesting and "manual" wiring of
> dependencies.
>
I've found people at both ends of that particular spectrum - some that
won't live with DI, some that won't live without it :) I guess a library
like Yo-yo has two options - either be opinionated about it, or let people
choose one or the other. In this case, I've chosen to let people choose -
there's nothing about Yo-yo that mandates the nesting (except the top-level
function) - what you do within that is up to you.
> I don't quite like that every with-* function remains on the stack as
> well, but it shouldn't hurt that much.
>
Hmm - I was wondering about that too. Maybe an approach similar to
trampoline would help here?
> An uncaught exception will also take down your entire system, but I guess
> you'd have a try/catch in your "latch" anyways.
>
I'm not sure it will? If there's an exception thrown during system startup,
the components will then have an opportunity to stop themselves (in the
reverse order) because of their try/finally's - I'd say this is the
behaviour we'd want, in order to avoid half-started systems. Once the
system's started, and (latch) called, an uncaught exception in the
components won't stop the system - because it'll be thrown on a different
thread, if I understand correctly? Certainly need to write some test cases
around it!
>
> But what I miss the most is an instance of your "app" (ie. all components
> together). You create it yourself in the example but I really want that
> always. Sometimes you just want to access your system from the outside just
> to see whats up (eg. REPL into a live system). I also consider the
> webserver to be a "client" of my "app" and not part of it (or another layer
> of it if you will), but that is a topic for another day.
>
>
Yep, I agree with this - I've been using some workarounds to get values out
of the system, none of them particularly pretty. Interesting idea about the
webserver being a client of the app - would be good to see where you take
that?
> Way way back in the day I used to work with (and on) PicoContainer which
> was/is a dependency injection and lifecycle management container. I tried
> writing a DSL for it (in Groovy, this was 2003 or so) but concluded that
> Java already was good enough to set everything up, a DSL (or XML) is
> overkill. All you need to describe a "Component" is:
>
> a) what are its dependencies
> b) how do I start it
> c) how do I stop it
>
> In that light I wrote my own "dependency injection" helper functions since
> nothing like Stuart's Component existed at the time I got into Clojure. I
> don't like Component due to its invasive protocol but in essence I do the
> same.
>
> In my system I just set up a map of components and use that as a
> descriptor for wiring:
>
> {:a {:depends-on []
> :start my.components.a/start
> :stop my.components.a/stop}
> :b {:depends-on [:a]
> :start my.components.b/start
> :stop my.components.b/stop}}
>
> The key in the outer map becomes whatever the :start function returns and
> is refered to it by its name :a (the key of the map). The :start function
> of :b is called as (my.components.b/start instance-of-a). An instance of a
> component is treated as an opaque value and other components interact with
> it only via its "public" interface (ie. my.components.a). Whether this is
> done via a protocol or not doesn't matter. When a shutdown is requested the
> :stop function is called with the instance of the component as the argument.
>
> That is about it. Mocking is just assoc over default descriptor map and I
> have helper functions to only do partial start/stop calls if only a
> specific component is needed (eg. I only need :a).
>
> Like I said it basically does the same stuff as Component, just a little
> less invasive since I think a component should not know about the container
> it runs in.
>
Looks another interesting approach :) I'm currently hacking on some similar
ideas myself - think there's plenty of room for iteration in this area at
the moment!
> Hope that was somewhat useful as feedback to Yo-Yo.
>
Certainly was! Thanks! :)
>
> Cheers,
> /thomas
>
>
> On Sunday, June 28, 2015 at 4:03:34 PM UTC+2, James Henderson wrote:
>>
>> As promised, have blogged: 'Yo-yo & Component - Side by Side
>> <https://github.com/james-henderson/yoyo/blob/master/articles/si
Re: [ANN] Introducing Yo-yo, a protocol-less, function composition-based alternative to Component
don't
> have to worry about hidden functions some inner function may call on my
> client. Protocols provide abstraction.
>
> So I guess that's my critique of Yo-Yo. I'd love to see a more in-depth
> rationale, and I get nervous when people replace protocols with plain
> functions, because normally I loose some expressiveness in the process.
>
> Timothy
>
> On Sun, Jun 28, 2015 at 8:03 AM, James Henderson > wrote:
>
>> As promised, have blogged: 'Yo-yo & Component - Side by Side
>> <https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org>
>> '
>>
>> Contents:
>>
>>
>>- Making components
>>
>> <https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#making-components>
>>- Using a component as a dependency
>>
>> <https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#using-a-component-as-a-dependency>
>>- Serving a REST API
>>
>> <https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#serving-a-rest-api>
>>- Wiring it all up
>>
>> <https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#wiring-it-all-up>
>>- Yo-yo / Component Interoperability
>>
>> <https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#yo-yocomponent-interoperability>
>>- Mockable Services
>>
>> <https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#mockable-services>
>>- ‘Mocking out’ dependencies
>>
>> <https://github.com/james-henderson/yoyo/blob/master/articles/mocking-out-dependencies>
>>
>> Let me know what you think!
>>
>> Cheers,
>>
>> James
>>
>> On Thursday, 25 June 2015 09:25:56 UTC+1, James Henderson wrote:
>>>
>>> Seems like the next step for this would be for me to put together a blog
>>> with an example Component system, and its equivalent Yoyo system?! :)
>>> Should have time for that over the weekend.
>>>
>>> James
>>>
>>> On Thursday, 25 June 2015 09:05:39 UTC+1, James Henderson wrote:
>>>>
>>>>
>>>>
>>>> On Wednesday, 24 June 2015 11:17:41 UTC+1, Atamert Ölçgen wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 23, 2015 at 11:47 PM, James Henderson >>>> > wrote:
>>>>>
>>>>>> Hi Atamert - thanks :)
>>>>>>
>>>>>> I thought it might be preferable to keep the call to (latch)explicit
>>>>>> - it means that ylet can be used in nested calls, too - for example,
>>>>>> to set up and compose groups of components/sub-systems: (contrived
>>>>>> example,
>>>>>> though!)
>>>>>>
>>>>>> ;; (docs for ylet at
>>>>>> https://github.com/james-henderson/yoyo#introducing-ylet )
>>>>>>
>>>>>> (require '[yoyo :refer [ylet]])
>>>>>>
>>>>>> (defn with-connections [config f]
>>>>>> (ylet [db-pool (with-db-pool (:db config))
>>>>>> es-conn (with-es-connection (:elasticsearch config))]
>>>>>>
>>>>>> (f {:db-pool db-pool
>>>>>> :es-conn es-conn})))
>>>>>>
>>>>>> (defn make-system [latch]
>>>>>> (let [config ...]
>>>>>> (ylet [connections (with-connections system)
>>>>>>_ (with-webserver {:handler (make-handler (merge connections
>>>>>> {:config
>>>>>> config}))
>>>>>> :port 3000})]
>>>>>> (latch
>>>>>>
>>>>>>
>>>>>> How would you see the with-* functions working, btw?
>>>>>>
>>>>>
>>>>> I think the general idea should be to provide a clean API to the
>>>>> consumer (of your lib). Perhaps something that accepts a start function,
>>>>> a
>>>>> stop function and some sort of main loop (f in your example).
>>>>>
>>>>
>>>> Not sure I understand what you mean here? Tbh, I was trying to get away
>>>> from the idea of separate start & stop functions - it seems &#x
Re: [ANN] Introducing Yo-yo, a protocol-less, function composition-based alternative to Component
As promised, have blogged: 'Yo-yo & Component - Side by Side
<https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org>
'
Contents:
- Making components
<https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#making-components>
- Using a component as a dependency
<https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#using-a-component-as-a-dependency>
- Serving a REST API
<https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#serving-a-rest-api>
- Wiring it all up
<https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#wiring-it-all-up>
- Yo-yo / Component Interoperability
<https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#yo-yocomponent-interoperability>
- Mockable Services
<https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#mockable-services>
- ‘Mocking out’ dependencies
<https://github.com/james-henderson/yoyo/blob/master/articles/mocking-out-dependencies>
Let me know what you think!
Cheers,
James
On Thursday, 25 June 2015 09:25:56 UTC+1, James Henderson wrote:
>
> Seems like the next step for this would be for me to put together a blog
> with an example Component system, and its equivalent Yoyo system?! :)
> Should have time for that over the weekend.
>
> James
>
> On Thursday, 25 June 2015 09:05:39 UTC+1, James Henderson wrote:
>>
>>
>>
>> On Wednesday, 24 June 2015 11:17:41 UTC+1, Atamert Ölçgen wrote:
>>>
>>>
>>>
>>> On Tue, Jun 23, 2015 at 11:47 PM, James Henderson
>>> wrote:
>>>
>>>> Hi Atamert - thanks :)
>>>>
>>>> I thought it might be preferable to keep the call to (latch)explicit -
>>>> it means that ylet can be used in nested calls, too - for example, to
>>>> set up and compose groups of components/sub-systems: (contrived example,
>>>> though!)
>>>>
>>>> ;; (docs for ylet at
>>>> https://github.com/james-henderson/yoyo#introducing-ylet )
>>>>
>>>> (require '[yoyo :refer [ylet]])
>>>>
>>>> (defn with-connections [config f]
>>>> (ylet [db-pool (with-db-pool (:db config))
>>>> es-conn (with-es-connection (:elasticsearch config))]
>>>>
>>>> (f {:db-pool db-pool
>>>> :es-conn es-conn})))
>>>>
>>>> (defn make-system [latch]
>>>> (let [config ...]
>>>> (ylet [connections (with-connections system)
>>>>_ (with-webserver {:handler (make-handler (merge connections
>>>> {:config
>>>> config}))
>>>> :port 3000})]
>>>> (latch
>>>>
>>>>
>>>> How would you see the with-* functions working, btw?
>>>>
>>>
>>> I think the general idea should be to provide a clean API to the
>>> consumer (of your lib). Perhaps something that accepts a start function, a
>>> stop function and some sort of main loop (f in your example).
>>>
>>
>> Not sure I understand what you mean here? Tbh, I was trying to get away
>> from the idea of separate start & stop functions - it seems 'cleaner' to me
>> without them! (although of course that's subjective).
>>
>> Also, the 'with-*' functions here are consumer code - the only Yo-yo
>> functions/macros in this example are 'run-system!' and 'ylet'. Yo-yo itself
>> is *tiny* (<100 LoC) - my aim was for a library that solely dealt with
>> starting/stopping a provided system, and *no more* :)
>>
>> Maybe it'd be worth fleshing out an example of what you were looking for?
>>
>> Cheers,
>>
>> James
>>
>>
>>>
>>>>
>>>> Cheers,
>>>>
>>>> James
>>>>
>>>> On Tuesday, 23 June 2015 09:57:16 UTC+1, Atamert Ölçgen wrote:
>>>>>
>>>>> Hi James,
>>>>>
>>>>> Interesting idea. Thanks for sharing.
>>>>>
>>>>> I think you can simplify this:
>>>>>
>>>>> (yoyo/run-system!
>>>>> (fn [latch]
>>>>>(ylet [db-pool (with-db-pool {...})
>>>>> :let [server-opts {:handler (make-handler {:db-pool db-pool})
>>>>>
Re: [ANN] Introducing Yo-yo, a protocol-less, function composition-based alternative to Component
Seems like the next step for this would be for me to put together a blog
with an example Component system, and its equivalent Yoyo system?! :)
Should have time for that over the weekend.
James
On Thursday, 25 June 2015 09:05:39 UTC+1, James Henderson wrote:
>
>
>
> On Wednesday, 24 June 2015 11:17:41 UTC+1, Atamert Ölçgen wrote:
>>
>>
>>
>> On Tue, Jun 23, 2015 at 11:47 PM, James Henderson
>> wrote:
>>
>>> Hi Atamert - thanks :)
>>>
>>> I thought it might be preferable to keep the call to (latch)explicit -
>>> it means that ylet can be used in nested calls, too - for example, to
>>> set up and compose groups of components/sub-systems: (contrived example,
>>> though!)
>>>
>>> ;; (docs for ylet at
>>> https://github.com/james-henderson/yoyo#introducing-ylet )
>>>
>>> (require '[yoyo :refer [ylet]])
>>>
>>> (defn with-connections [config f]
>>> (ylet [db-pool (with-db-pool (:db config))
>>> es-conn (with-es-connection (:elasticsearch config))]
>>>
>>> (f {:db-pool db-pool
>>> :es-conn es-conn})))
>>>
>>> (defn make-system [latch]
>>> (let [config ...]
>>> (ylet [connections (with-connections system)
>>>_ (with-webserver {:handler (make-handler (merge connections
>>> {:config
>>> config}))
>>> :port 3000})]
>>> (latch
>>>
>>>
>>> How would you see the with-* functions working, btw?
>>>
>>
>> I think the general idea should be to provide a clean API to the consumer
>> (of your lib). Perhaps something that accepts a start function, a stop
>> function and some sort of main loop (f in your example).
>>
>
> Not sure I understand what you mean here? Tbh, I was trying to get away
> from the idea of separate start & stop functions - it seems 'cleaner' to me
> without them! (although of course that's subjective).
>
> Also, the 'with-*' functions here are consumer code - the only Yo-yo
> functions/macros in this example are 'run-system!' and 'ylet'. Yo-yo itself
> is *tiny* (<100 LoC) - my aim was for a library that solely dealt with
> starting/stopping a provided system, and *no more* :)
>
> Maybe it'd be worth fleshing out an example of what you were looking for?
>
> Cheers,
>
> James
>
>
>>
>>>
>>> Cheers,
>>>
>>> James
>>>
>>> On Tuesday, 23 June 2015 09:57:16 UTC+1, Atamert Ölçgen wrote:
>>>>
>>>> Hi James,
>>>>
>>>> Interesting idea. Thanks for sharing.
>>>>
>>>> I think you can simplify this:
>>>>
>>>> (yoyo/run-system!
>>>> (fn [latch]
>>>>(ylet [db-pool (with-db-pool {...})
>>>> :let [server-opts {:handler (make-handler {:db-pool db-pool})
>>>> :port 3000}]
>>>> web-server (with-web-server server-opts)]
>>>> (do-this web-server)
>>>> (do-that db-pool web-server)
>>>> (latch
>>>>
>>>>
>>>> to:
>>>>
>>>> (yoyo/foo! [db-pool (with-db-pool {...})
>>>> :let [server-opts {:handler (make-handler {:db-pool
>>>> db-pool})
>>>>:port 3000}]
>>>> web-server (with-web-server server-opts)]
>>>> (do-this web-server)
>>>> (do-that db-pool web-server))
>>>>
>>>>
>>>> I believe with-* function can also be simplified further.
>>>>
>>>>
>>>> On Tue, Jun 23, 2015 at 1:18 AM, James Henderson
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I've just released an early version of 'Yo-yo', a protocol-less,
>>>>> function composition-based alternative to Component. It's still in its
>>>>> early stages, so feedback would be very much appreciated!
>>>>>
>>>>> https://github.com/james-henderson/yoyo
>>>>>
>>>>> Yo-yo was also an experiment to see what could be de-coupled from the
>>>>> concept of 'reloadable systems', so you won't find any configuration,
>>>>> dependency injection, etc - just a way to write a syst
Re: [ANN] Introducing Yo-yo, a protocol-less, function composition-based alternative to Component
On Wednesday, 24 June 2015 11:17:41 UTC+1, Atamert Ölçgen wrote:
>
>
>
> On Tue, Jun 23, 2015 at 11:47 PM, James Henderson > wrote:
>
>> Hi Atamert - thanks :)
>>
>> I thought it might be preferable to keep the call to (latch)explicit -
>> it means that ylet can be used in nested calls, too - for example, to
>> set up and compose groups of components/sub-systems: (contrived example,
>> though!)
>>
>> ;; (docs for ylet at
>> https://github.com/james-henderson/yoyo#introducing-ylet )
>>
>> (require '[yoyo :refer [ylet]])
>>
>> (defn with-connections [config f]
>> (ylet [db-pool (with-db-pool (:db config))
>> es-conn (with-es-connection (:elasticsearch config))]
>>
>> (f {:db-pool db-pool
>> :es-conn es-conn})))
>>
>> (defn make-system [latch]
>> (let [config ...]
>> (ylet [connections (with-connections system)
>>_ (with-webserver {:handler (make-handler (merge connections
>> {:config
>> config}))
>> :port 3000})]
>> (latch
>>
>>
>> How would you see the with-* functions working, btw?
>>
>
> I think the general idea should be to provide a clean API to the consumer
> (of your lib). Perhaps something that accepts a start function, a stop
> function and some sort of main loop (f in your example).
>
Not sure I understand what you mean here? Tbh, I was trying to get away
from the idea of separate start & stop functions - it seems 'cleaner' to me
without them! (although of course that's subjective).
Also, the 'with-*' functions here are consumer code - the only Yo-yo
functions/macros in this example are 'run-system!' and 'ylet'. Yo-yo itself
is *tiny* (<100 LoC) - my aim was for a library that solely dealt with
starting/stopping a provided system, and *no more* :)
Maybe it'd be worth fleshing out an example of what you were looking for?
Cheers,
James
>
>>
>> Cheers,
>>
>> James
>>
>> On Tuesday, 23 June 2015 09:57:16 UTC+1, Atamert Ölçgen wrote:
>>>
>>> Hi James,
>>>
>>> Interesting idea. Thanks for sharing.
>>>
>>> I think you can simplify this:
>>>
>>> (yoyo/run-system!
>>> (fn [latch]
>>>(ylet [db-pool (with-db-pool {...})
>>> :let [server-opts {:handler (make-handler {:db-pool db-pool})
>>> :port 3000}]
>>> web-server (with-web-server server-opts)]
>>> (do-this web-server)
>>> (do-that db-pool web-server)
>>> (latch
>>>
>>>
>>> to:
>>>
>>> (yoyo/foo! [db-pool (with-db-pool {...})
>>> :let [server-opts {:handler (make-handler {:db-pool db-pool})
>>>:port 3000}]
>>> web-server (with-web-server server-opts)]
>>> (do-this web-server)
>>> (do-that db-pool web-server))
>>>
>>>
>>> I believe with-* function can also be simplified further.
>>>
>>>
>>> On Tue, Jun 23, 2015 at 1:18 AM, James Henderson
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I've just released an early version of 'Yo-yo', a protocol-less,
>>>> function composition-based alternative to Component. It's still in its
>>>> early stages, so feedback would be very much appreciated!
>>>>
>>>> https://github.com/james-henderson/yoyo
>>>>
>>>> Yo-yo was also an experiment to see what could be de-coupled from the
>>>> concept of 'reloadable systems', so you won't find any configuration,
>>>> dependency injection, etc - just a way to write a system that can be
>>>> easily
>>>> started, stopped, and reloaded.
>>>>
>>>> Fundamentally, we start by assuming there's a function available that
>>>> only returns 'when the system stops' - a 'latch', say. If we had such a
>>>> function, we could start our system, call that function, then stop the
>>>> system (closing any necessary resources). A database pool, for example,
>>>> might look like this:
>>>>
>>>> (defn with-db-pool [db-config f]
>>>> (let [db-pool (start-pool! db-config)]
>>>> (try
>>>> (f db-pool)
>>>>
>&
Re: [ANN] Introducing Yo-yo, a protocol-less, function composition-based alternative to Component
Hi Atamert - thanks :)
I thought it might be preferable to keep the call to (latch)explicit - it
means that ylet can be used in nested calls, too - for example, to set up
and compose groups of components/sub-systems: (contrived example, though!)
;; (docs for ylet at https://github.com/james-henderson/yoyo#introducing-ylet )
(require '[yoyo :refer [ylet]])
(defn with-connections [config f]
(ylet [db-pool (with-db-pool (:db config))
es-conn (with-es-connection (:elasticsearch config))]
(f {:db-pool db-pool
:es-conn es-conn})))
(defn make-system [latch]
(let [config ...]
(ylet [connections (with-connections system)
_ (with-webserver {:handler (make-handler (merge connections
{:config config}))
:port 3000})]
(latch
How would you see the with-* functions working, btw?
Cheers,
James
On Tuesday, 23 June 2015 09:57:16 UTC+1, Atamert Ölçgen wrote:
>
> Hi James,
>
> Interesting idea. Thanks for sharing.
>
> I think you can simplify this:
>
> (yoyo/run-system!
> (fn [latch]
>(ylet [db-pool (with-db-pool {...})
> :let [server-opts {:handler (make-handler {:db-pool db-pool})
> :port 3000}]
> web-server (with-web-server server-opts)]
> (do-this web-server)
> (do-that db-pool web-server)
> (latch
>
>
> to:
>
> (yoyo/foo! [db-pool (with-db-pool {...})
> :let [server-opts {:handler (make-handler {:db-pool db-pool})
>:port 3000}]
> web-server (with-web-server server-opts)]
> (do-this web-server)
> (do-that db-pool web-server))
>
>
> I believe with-* function can also be simplified further.
>
>
> On Tue, Jun 23, 2015 at 1:18 AM, James Henderson > wrote:
>
>> Hi all,
>>
>> I've just released an early version of 'Yo-yo', a protocol-less, function
>> composition-based alternative to Component. It's still in its early stages,
>> so feedback would be very much appreciated!
>>
>> https://github.com/james-henderson/yoyo
>>
>> Yo-yo was also an experiment to see what could be de-coupled from the
>> concept of 'reloadable systems', so you won't find any configuration,
>> dependency injection, etc - just a way to write a system that can be easily
>> started, stopped, and reloaded.
>>
>> Fundamentally, we start by assuming there's a function available that
>> only returns 'when the system stops' - a 'latch', say. If we had such a
>> function, we could start our system, call that function, then stop the
>> system (closing any necessary resources). A database pool, for example,
>> might look like this:
>>
>> (defn with-db-pool [db-config f]
>> (let [db-pool (start-pool! db-config)]
>> (try
>> (f db-pool)
>>
>> (finally
>> (stop-pool! db-pool)
>>
>> Here, we're assuming that we'll be passed 'f', the 'latch' function. A
>> web server would be similar, and, because they're both functions, they're
>> very simple to compose:
>>
>> (with-db-pool {...}
>> (fn [db-pool]
>> (with-web-server {:handler (make-handler {:db-pool db-pool})
>> :port ...}
>> (fn [web-server]
>> ;; TODO: Ah. We've run out of turtles. :(
>>
>>
>> This is where Yo-yo comes in - there’s a function called run-system!,
>> which takes a function that accepts a latch:
>>
>> (:require [yoyo])
>>
>> (yoyo/run-system!
>> (fn [latch]
>> (with-db-pool {...}
>> (fn [db-pool]
>> (with-web-server {:handler (make-handler {:db-pool db-pool}) ; n.b.
>> we have access to the db-pool here - no need for global state!
>> :port ...}
>> (fn [web-server]
>> (latch))) ; Aha!
>>
>> run-system! then returns a promise - deliver any value to it, and it'll
>> stop the system.
>>
>> And that's pretty much it! There are a few more functions - mostly to do
>> with easily starting/stopping/reloading a system through the REPL, and a
>> macro to simplify the 'function staircase' - these are covered in more
>> detail in the README. There are some also common components - a database
>> pool, a web server, and a simple integration for existing Component systems.
>>
>> It'd be great to hear your thoughts/ideas, whatever they may be - either
&
[ANN] Introducing Yo-yo, a protocol-less, function composition-based alternative to Component
Hi all,
I've just released an early version of 'Yo-yo', a protocol-less, function
composition-based alternative to Component. It's still in its early stages,
so feedback would be very much appreciated!
https://github.com/james-henderson/yoyo
Yo-yo was also an experiment to see what could be de-coupled from the
concept of 'reloadable systems', so you won't find any configuration,
dependency injection, etc - just a way to write a system that can be easily
started, stopped, and reloaded.
Fundamentally, we start by assuming there's a function available that only
returns 'when the system stops' - a 'latch', say. If we had such a
function, we could start our system, call that function, then stop the
system (closing any necessary resources). A database pool, for example,
might look like this:
(defn with-db-pool [db-config f]
(let [db-pool (start-pool! db-config)]
(try
(f db-pool)
(finally
(stop-pool! db-pool)
Here, we're assuming that we'll be passed 'f', the 'latch' function. A web
server would be similar, and, because they're both functions, they're very
simple to compose:
(with-db-pool {...}
(fn [db-pool]
(with-web-server {:handler (make-handler {:db-pool db-pool})
:port ...}
(fn [web-server]
;; TODO: Ah. We've run out of turtles. :(
This is where Yo-yo comes in - there’s a function called run-system!, which
takes a function that accepts a latch:
(:require [yoyo])
(yoyo/run-system!
(fn [latch]
(with-db-pool {...}
(fn [db-pool]
(with-web-server {:handler (make-handler {:db-pool db-pool}) ; n.b. we
have access to the db-pool here - no need for global state!
:port ...}
(fn [web-server]
(latch))) ; Aha!
run-system! then returns a promise - deliver any value to it, and it'll
stop the system.
And that's pretty much it! There are a few more functions - mostly to do
with easily starting/stopping/reloading a system through the REPL, and a
macro to simplify the 'function staircase' - these are covered in more
detail in the README. There are some also common components - a database
pool, a web server, and a simple integration for existing Component systems.
It'd be great to hear your thoughts/ideas, whatever they may be - either
through here, e-mail, Github, or Twitter - thanks!
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/d/optout.
Re: [ANN] Phoenix 0.1.0 - help with structuring & configuring Component-based systems
Just released 0.1.1 - bug when using Schema in Phoenix apps due to Phoenix's overly-enthusiastic AOT'ing. Thanks to @whodidthis for flagging the issue! James On Sunday, 29 March 2015 20:44:04 UTC+1, James Henderson wrote: > > A link would have been really helpful, I'm guessing! Here it is: > > https://github.com/james-henderson/phoenix > > James > > On Sunday, 29 March 2015 20:42:06 UTC+1, James Henderson wrote: >> >> Hi all, >> >> I've just released v0.1.0 of Phoenix - a 'batteries included, but >> removable' library to wire up and configure Component-based systems. If >> you've ever wondered whether you really have to copy and paste >> 'system.clj', 'dev.clj' and 'user.clj' from one Component project to the >> next, it's well worth having a look at! >> >> Having used Phoenix in anger on a few projects for a couple of weeks, >> it's now had a fair bit of battle-testing, kinks ironed, and the like - so >> thought I'd make another post to the list :) >> >> Features added since I last posted: >> >>- Many re-usable Components - CLJS compiler, Aleph, http-kit, JDBC >>pool, CSS compiler (using Garden) - see >>https://github.com/james-henderson/phoenix/tree/master/modules/ for >>more details. These components can be used whether or not you choose to >> use >>Phoenix, and, likewise, non-Phoenix components can be used in >>Phoenix-configured systems - hooray for composability :) >>- Support for managing passwords/credentials - you can store these, >>encrypted, in your configuration, and Phoenix will decrypt them for you. >>- Pulling configuration variables from environment variables and JVM >>properties, in addition to the Phoenix config files >>- 'Batteries removable' API - if you need a little more flexibility, >>or want to compose Phoenix with something else. >>- A fair few bugfixes/API changes through usage >> >> There's also a couple of Lein templates to get up and running quickly: >> >>- `lein new phoenix-webapp -- :reagent` will get you a >>working webapp (other options are `:om`, `:om-sablono` or `:flow`). >>- If you don't want the CLJS side, `lein new phoenix-api ` >>just has an example server-side API. >> >> Would be great to get your thoughts and feedback on this - is this a good >> way to wire up such systems? >> >> Cheers, >> >> 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/d/optout.
Re: [ANN] Phoenix 0.1.0 - help with structuring & configuring Component-based systems
Thanks Jeroen - I'd not spotted that! Yes, definitely a better idea -
will update the examples.
James
On 31/03/15 12:49, Jeroen van Dijk wrote:
Thanks for sharing James! I'll have a look.
As a side note, I see in the example code that you are dissoc-ing on
the component. This can lead to unexpected behaviour as I have
experienced (mostly in repl cases), as this will return a map instead
of a record when the field is not part of the record. This is also
mentioned in the readme of https://github.com/stuartsierra/component
where `(assoc component ::field nil)` is recommended
Jeroen
On Sun, Mar 29, 2015 at 9:44 PM, James Henderson <mailto:ja...@jarohen.me.uk>> wrote:
A link would have been really helpful, I'm guessing! Here it is:
https://github.com/james-henderson/phoenix
James
On Sunday, 29 March 2015 20:42:06 UTC+1, James Henderson wrote:
Hi all,
I've just released v0.1.0 of Phoenix - a 'batteries included,
but removable' library to wire up and configure
Component-based systems. If you've ever wondered whether you
really have to copy and paste 'system.clj', 'dev.clj' and
'user.clj' from one Component project to the next, it's well
worth having a look at!
Having used Phoenix in anger on a few projects for a couple of
weeks, it's now had a fair bit of battle-testing, kinks
ironed, and the like - so thought I'd make another post to the
list :)
Features added since I last posted:
* Many re-usable Components - CLJS compiler, Aleph,
http-kit, JDBC pool, CSS compiler (using Garden) - see
https://github.com/james-henderson/phoenix/tree/master/modules/
for more details. These components can be used whether or
not you choose to use Phoenix, and, likewise, non-Phoenix
components can be used in Phoenix-configured systems -
hooray for composability :)
* Support for managing passwords/credentials - you can store
these, encrypted, in your configuration, and Phoenix will
decrypt them for you.
* Pulling configuration variables from environment variables
and JVM properties, in addition to the Phoenix config files
* 'Batteries removable' API - if you need a little more
flexibility, or want to compose Phoenix with something else.
* A fair few bugfixes/API changes through usage
There's also a couple of Lein templates to get up and running
quickly:
* `lein new phoenix-webapp -- :reagent` will
get you a working webapp (other options are `:om`,
`:om-sablono`or `:flow`).
* If you don't want the CLJS side, `lein new phoenix-api
` just has an example server-side API.
Would be great to get your thoughts and feedback on this - is
this a good way to wire up such systems?
Cheers,
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
<mailto: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
<mailto:clojure%2bunsubscr...@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
<mailto:clojure+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a topic in the
Google Groups "Clojure" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/clojure/EgfoZK0vV08/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
clojure+unsubscr...@googlegroups.com
<mailto:clojure+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Goo
[ANN] Phoenix 0.1.0 - help with structuring & configuring Component-based systems
Hi all, I've just released v0.1.0 of Phoenix - a 'batteries included, but removable' library to wire up and configure Component-based systems. If you've ever wondered whether you really have to copy and paste 'system.clj', 'dev.clj' and 'user.clj' from one Component project to the next, it's well worth having a look at! Having used Phoenix in anger on a few projects for a couple of weeks, it's now had a fair bit of battle-testing, kinks ironed, and the like - so thought I'd make another post to the list :) Features added since I last posted: - Many re-usable Components - CLJS compiler, Aleph, http-kit, JDBC pool, CSS compiler (using Garden) - see https://github.com/james-henderson/phoenix/tree/master/modules/ for more details. These components can be used whether or not you choose to use Phoenix, and, likewise, non-Phoenix components can be used in Phoenix-configured systems - hooray for composability :) - Support for managing passwords/credentials - you can store these, encrypted, in your configuration, and Phoenix will decrypt them for you. - Pulling configuration variables from environment variables and JVM properties, in addition to the Phoenix config files - 'Batteries removable' API - if you need a little more flexibility, or want to compose Phoenix with something else. - A fair few bugfixes/API changes through usage There's also a couple of Lein templates to get up and running quickly: - `lein new phoenix-webapp -- :reagent` will get you a working webapp (other options are `:om`, `:om-sablono` or `:flow`). - If you don't want the CLJS side, `lein new phoenix-api ` just has an example server-side API. Would be great to get your thoughts and feedback on this - is this a good way to wire up such systems? Cheers, 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/d/optout.
Re: [ANN] Phoenix 0.1.0 - help with structuring & configuring Component-based systems
A link would have been really helpful, I'm guessing! Here it is: https://github.com/james-henderson/phoenix James On Sunday, 29 March 2015 20:42:06 UTC+1, James Henderson wrote: > > Hi all, > > I've just released v0.1.0 of Phoenix - a 'batteries included, but > removable' library to wire up and configure Component-based systems. If > you've ever wondered whether you really have to copy and paste > 'system.clj', 'dev.clj' and 'user.clj' from one Component project to the > next, it's well worth having a look at! > > Having used Phoenix in anger on a few projects for a couple of weeks, it's > now had a fair bit of battle-testing, kinks ironed, and the like - so > thought I'd make another post to the list :) > > Features added since I last posted: > >- Many re-usable Components - CLJS compiler, Aleph, http-kit, JDBC >pool, CSS compiler (using Garden) - see >https://github.com/james-henderson/phoenix/tree/master/modules/ for >more details. These components can be used whether or not you choose to > use >Phoenix, and, likewise, non-Phoenix components can be used in >Phoenix-configured systems - hooray for composability :) >- Support for managing passwords/credentials - you can store these, >encrypted, in your configuration, and Phoenix will decrypt them for you. >- Pulling configuration variables from environment variables and JVM >properties, in addition to the Phoenix config files >- 'Batteries removable' API - if you need a little more flexibility, >or want to compose Phoenix with something else. >- A fair few bugfixes/API changes through usage > > There's also a couple of Lein templates to get up and running quickly: > >- `lein new phoenix-webapp -- :reagent` will get you a >working webapp (other options are `:om`, `:om-sablono` or `:flow`). >- If you don't want the CLJS side, `lein new phoenix-api ` >just has an example server-side API. > > Would be great to get your thoughts and feedback on this - is this a good > way to wire up such systems? > > Cheers, > > 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/d/optout.
Re: Announcing oolong: a config-based glue for `component`
Thanks - thoughts inline :) On Wednesday, 18 March 2015 09:29:59 UTC, James Laver wrote: > > Hi James, > > ‘component’ is a difficult term to google for, so I hadn’t come across > your project :) > Same problem here when I started writing Phoenix - there could be many libraries trying to solve the same problem! > > I think your module had slightly different design goals from mine. Mine > were: > * everything in one config file (although i also provide support for > separate data-config and system config) > * be minimal. i’ve got a bunch of things i’m building on top of oolong at > present that will together provide a more “complete” experience > Fair enough! I went for giving people the option of either one config file or multiple (after all, you don't *have* to use :phoenix/includes!) mainly because I got a lot of requests in Nomad (Phoenix's predecessor) for separate apps within the same company to share common configuration. > > I see you note that phoenix is ‘batteries included’. That’s a great > experience for new users, but i wasn’t trying to build that on this > occasion :) The leiningen template and plugin are also nice additions, and > reloaded workflow integration is very handy. > Hmm - Phoenix is 'batteries included, but removable' (phrasing stolen from Docker) which is significantly different from 'batteries included'. I'm not a fan of 'batteries included' - it tends to mean libraries that are hard for users to customise at a later date, which (to me, and to you as well by the sounds of it) goes against Clojure ideals. Phoenix is deliberately written as a standalone runtime library, which composes with whatever other systems people dream up, and a separate, lightweight plugin (not so composable), which essentially just bootstraps the library and saves people the hassle of a separate 'system.clj', 'dev.clj' and 'user.clj', if they so wish. > > Reloaded workflow has been an experience for me. I haven’t yet managed to > get it working in the face of compile errors. I find myself restarting the > leiningen repl about as much as before. For this reason I chose to keep it > separate and delay dealing with it for a few weeks. Have you managed to > overcome these problems? I’m definitely interested in knowing how if so. > Happy to help with these - do you want to post some specifics? As a starting point, I've found that including an 'emergency nREPL' - an nREPL that starts before the application (and doesn't depend on the application compiling) gets you a long way. If the application doesn't compile, the system doesn't start, but I think that's actually preferable than half a system. > > I’ve only really given phoenix a few minutes of my attention so far, but I > like what I see and I’m liable to steal ideas for some of the things i’ll > be building on top of oolong. Feel free to reply offlist if you have any > further questions. > Feel free to steal ideas from Phoenix - that's what open source is all about! More than happy to work together on this as well though - seems like we have both come to very similar conclusions about how we want to wire up Clojure components. > > James > > > On 18 Mar 2015, at 09:07, James Henderson > wrote: > > > > Hi James, > > > > This looks very similar to Phoenix - a project I've been working on for > the last few months. It's pretty likely you hadn't heard of it (and that's > fine - it's not been hugely publicised!), but if you have, I was wondering > whether there was anything about it that you felt was missing/a bad design > decision? If so, would be great to get your feedback! > > > > Cheers, > > > > James > > > > On Tuesday, 17 March 2015 10:02:51 UTC, James Laver wrote: > > I've been using stuartsierra's handy component library for a while now, > but I wanted an easier way of connecting components together. > > > > To that end, I wrote oolong. The main mode of operation is to take an > edn configuration file and connect the specified systems and components. > > > > https://github.com/jjl/oolong > > > > https://clojars.org/oolong > > > > Feedback welcome. I spent quite a while documenting it so hopefully it > should be fairly clear to understand. > > > > James > > > > -- > > 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 wit
Re: Announcing oolong: a config-based glue for `component`
Hi James, This looks very similar to Phoenix <https://github.com/james-henderson/phoenix> - a project I've been working on for the last few months. It's pretty likely you hadn't heard of it (and that's fine - it's not been hugely publicised!), but if you have, I was wondering whether there was anything about it that you felt was missing/a bad design decision? If so, would be great to get your feedback! Cheers, James On Tuesday, 17 March 2015 10:02:51 UTC, James Laver wrote: > > I've been using stuartsierra's handy component library for a while now, > but I wanted an easier way of connecting components together. > > To that end, I wrote oolong. The main mode of operation is to take an edn > configuration file and connect the specified systems and components. > > https://github.com/jjl/oolong > > https://clojars.org/oolong > > Feedback welcome. I spent quite a while documenting it so hopefully it > should be fairly clear to understand. > > 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/d/optout.
Re: [ANN] Introducing 'Phoenix' - a new library for declarative configuration and wiring of Component-based systems
Hi Leif - thanks for the suggestion. You're not the only person that's questioned the auto-namespaced keywords, btw! The original reasoning behind them was to keep Phoenix-related configuration separate from the user's own configuration, but without enforcing typing :phoenix/ in front of all of the keywords. I'm not sure if this is the best/only way to do it, or even whether people would mind writing out :phoenix/component or :phoenix/dep every time they were required? Do you have any ideas/thoughts about how to do this? I'm happy to make breaking changes at the moment if necessary - Phoenix is still very much in 0.0.x territory! Also, I didn't realise the EDN spec prohibited it, although now you mention it it makes sense that it should. I think, on balance, I'd prefer to resolve the problem rather than just accepting it and renaming the configuration file - if we can find the right way to solve it! Thanks, James On Sunday, 25 January 2015 13:15:00 UTC, Leif wrote: > > Hi, James. > > I'll let people with more experience with components critique your > solution, but one thing that I thought was weird was that you had > auto-namespaced keywords in the config file. I'm referring to: > https://github.com/james-henderson/phoenix#adding-dependencies-between-components > > That means only code in your blessed ns can read the file, or things > break. Also, the edn spec disallows keywords beginning with "::". So, I'd > suggest either following the edn spec or using the ".clj" ending for the > config files. > > --Leif > > On Saturday, January 24, 2015 at 10:20:10 AM UTC-5, James Henderson wrote: >> >> Hi all, >> >> I've just released Phoenix - a library for declarative configuration and >> wiring of Component-based systems. Phoenix came out of a number of >> discussions at ClojureX, thank you to all involved for their suggestions >> and feedback :) >> >> https://github.com/james-henderson/phoenix >> >> If you’ve written a traditional Component-based system, you’ve probably >> experienced having to create and maintain a plethora of ‘system.clj’, >> ‘dev.clj’, ‘user.clj’ etc type namespaces in order to wire-up the system, >> set up configuration-based switches, and duplicate the code to >> start/stop/reload the system. Phoenix removes the need for all of this, >> replacing it with one (or more, if you choose) EDN declaration of how your >> system should be wired up. It should also compose well with any other >> Components you (or anyone else) may have already written. >> >> For a sample project, you can run 'lein new phoenix-webapp ', >> then 'cd ' and 'lein dev'. Once the nREPL is up, running ' >> (phoenix/reload!)' will stop the system, reload any namespaces, and >> restart the system. >> >> Phoenix is just one possible way of wiring up such a system - I >> understand that there are a fair few ideas floating around out there at the >> moment! I'd be really interested to hear your thoughts - whether it be >> 'this is mostly right, but I wouldn't do that part like that', or 'you've >> gone about this completely the wrong way, because ...' - let me know! >> >> Cheers, >> >> 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/d/optout.
Re: [ANN] Introducing 'Phoenix' - a new library for declarative configuration and wiring of Component-based systems
Hi Dan - it's possible to load configuration from environment variables as of version 0.0.2 (released today) - you can now put [::env :env-var-name]in your configuration to look up the 'ENV_VAR_NAME' environment variable. More info in the env-vars section <https://github.com/james-henderson/phoenix#config-in-environment-variables> of the README. Re: tagged literals: I'm pretty sure that's possible too - I can't see why it wouldn't honour readers that you put into your data-readers.edn file (haven't tried this out yet though), but there's currently no way to pass custom readers to Phoenix directly. I think this is one of the downsides of going for a plugin+library approach rather than just a library - I've split it out today so that it is possible to call the library directly, but it could still do with being a bit more flexible, I think! James On Sunday, 25 January 2015 13:10:34 UTC, Dan Kersten wrote: > > Hi James, > > This looks nice. I do have one question: is it possible to load parts of a > configuration from environment variables? > > Eg, in your "location-aware configuration" example, lets say I wanted to > specify the database user and pass configuration options as you do for the > dev configurations, but I want to load them from environment variables in > the prod configuration? > > Or, better yet, if it were pluggable (through tagged literals maybe?), so > that I can choose where to load configuration from, eg, zookeeper or etcd). > > On Sat Jan 24 2015 at 3:20:13 PM James Henderson > wrote: > >> Hi all, >> >> I've just released Phoenix - a library for declarative configuration and >> wiring of Component-based systems. Phoenix came out of a number of >> discussions at ClojureX, thank you to all involved for their suggestions >> and feedback :) >> >> https://github.com/james-henderson/phoenix >> >> If you’ve written a traditional Component-based system, you’ve probably >> experienced having to create and maintain a plethora of ‘system.clj’, >> ‘dev.clj’, ‘user.clj’ etc type namespaces in order to wire-up the system, >> set up configuration-based switches, and duplicate the code to >> start/stop/reload the system. Phoenix removes the need for all of this, >> replacing it with one (or more, if you choose) EDN declaration of how your >> system should be wired up. It should also compose well with any other >> Components you (or anyone else) may have already written. >> >> For a sample project, you can run 'lein new phoenix-webapp ', >> then 'cd ' and 'lein dev'. Once the nREPL is up, running ' >> (phoenix/reload!)' will stop the system, reload any namespaces, and >> restart the system. >> >> Phoenix is just one possible way of wiring up such a system - I >> understand that there are a fair few ideas floating around out there at the >> moment! I'd be really interested to hear your thoughts - whether it be >> 'this is mostly right, but I wouldn't do that part like that', or 'you've >> gone about this completely the wrong way, because ...' - let me know! >> >> Cheers, >> >> James >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] Introducing 'Phoenix' - a new library for declarative configuration and wiring of Component-based systems
Hi all, I've just released Phoenix - a library for declarative configuration and wiring of Component-based systems. Phoenix came out of a number of discussions at ClojureX, thank you to all involved for their suggestions and feedback :) https://github.com/james-henderson/phoenix If you’ve written a traditional Component-based system, you’ve probably experienced having to create and maintain a plethora of ‘system.clj’, ‘dev.clj’, ‘user.clj’ etc type namespaces in order to wire-up the system, set up configuration-based switches, and duplicate the code to start/stop/reload the system. Phoenix removes the need for all of this, replacing it with one (or more, if you choose) EDN declaration of how your system should be wired up. It should also compose well with any other Components you (or anyone else) may have already written. For a sample project, you can run 'lein new phoenix-webapp ', then 'cd ' and 'lein dev'. Once the nREPL is up, running ' (phoenix/reload!)' will stop the system, reload any namespaces, and restart the system. Phoenix is just one possible way of wiring up such a system - I understand that there are a fair few ideas floating around out there at the moment! I'd be really interested to hear your thoughts - whether it be 'this is mostly right, but I wouldn't do that part like that', or 'you've gone about this completely the wrong way, because ...' - let me know! Cheers, 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/d/optout.
(ANN) simple-brepl 0.1.2 released
Hi all - just a quick note to announce the release of *simple-brepl* 0.1.2. 'simple-brepl', as the name suggests, is a really simple way to connect to ClojureScript browser REPLs. It's built atop Tom Jakubowski's excellent Weasel library, which uses Websockets to communicate with the browser. Full docs and a sample project are on GitHub at https://github.com/james-henderson/simple-brepl Any problems, let me know! 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/d/optout.
[ANN] Nomad 0.7.0 and Frodo 0.4.1 - configuration made simple
Hi all, I've just released Nomad 0.7.0, a configuration management library that makes it simple to configure instances of your applications on multiple machines; and Frodo 0.4.1 - a web server that is configured using Nomad and uses Stuart Sierra's 'Reloaded' pattern. Github repos are at https://github.com/james-henderson/nomad and https://github.com/james-henderson/frodo respectively. Thanks to Dylan Paris and Luke Snape for their PRs! 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/d/optout.
Re: How to add elements to a vector that is the value of a map key?
Ah, you got there first :)
James
On Tuesday, 17 June 2014 19:20:52 UTC+1, James Henderson wrote:
>
> 'alter' expects your anonymous function to take at least one argument (the
> current value of the ref being altered), whereas you've passed a 0-arg
> function - there's no mention of a '%' so Clojure expands it to:
>
> (fn []
> (update-in @v (fnil conj [])))
>
> Indeed, I suspect you want a 2-arg function here - one for the current
> value of the ref and one for the number to conj on - if you were writing it
> in expanded form you'd write:
>
> (fn [v x]
> (update-in v (fnil conj []) x))
>
> Or, in compact form:
>
> #(update-in %1 (fnil conj []) %2)
>
> HTH,
>
> James
>
> On Tuesday, 17 June 2014 19:05:10 UTC+1, Hussein B. wrote:
>>
>> Thanks, it works.
>>
>> In case, my initial map is a ref type
>>
>> (def m (ref { } ))
>>
>> Why this isn't working?
>>
>> (dosync
>>
>>(alter m #(update-in @v [1] (fnil conj [ ])) 11))
>>
>> On Tuesday, June 17, 2014 7:55:14 PM UTC+2, Mauricio Aldazosa wrote:
>>>
>>> For updating the value of a map given a key you can use update-in:
>>>
>>> user> (update-in {1 [11]} [1] conj 22)
>>> {1 [11 22]}
>>>
>>> Now, to handle the case when the key is not present, you can use fnil:
>>>
>>> user> (update-in {} [1] (fnil conj []) 22)
>>> {1 [22]}
>>>
>>> Cheers,
>>> 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/d/optout.
Re: How to add elements to a vector that is the value of a map key?
'alter' expects your anonymous function to take at least one argument (the
current value of the ref being altered), whereas you've passed a 0-arg
function - there's no mention of a '%' so Clojure expands it to:
(fn []
(update-in @v (fnil conj [])))
Indeed, I suspect you want a 2-arg function here - one for the current
value of the ref and one for the number to conj on - if you were writing it
in expanded form you'd write:
(fn [v x]
(update-in v (fnil conj []) x))
Or, in compact form:
#(update-in %1 (fnil conj []) %2)
HTH,
James
On Tuesday, 17 June 2014 19:05:10 UTC+1, Hussein B. wrote:
>
> Thanks, it works.
>
> In case, my initial map is a ref type
>
> (def m (ref { } ))
>
> Why this isn't working?
>
> (dosync
>
>(alter m #(update-in @v [1] (fnil conj [ ])) 11))
>
> On Tuesday, June 17, 2014 7:55:14 PM UTC+2, Mauricio Aldazosa wrote:
>>
>> For updating the value of a map given a key you can use update-in:
>>
>> user> (update-in {1 [11]} [1] conj 22)
>> {1 [11 22]}
>>
>> Now, to handle the case when the key is not present, you can use fnil:
>>
>> user> (update-in {} [1] (fnil conj []) 22)
>> {1 [22]}
>>
>> Cheers,
>> 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/d/optout.
Re: ANN: ring-token-authentication. A ring middleware to authenticate API requests
Really useful, concise library - thanks! James On Saturday, 15 February 2014 18:53:58 UTC, Jason Stewart wrote: > > I've just pushed the first version of ring-token-authentication, a Ring > middleware to authenticate HTTP API requests. > > Token authentication is a popular way to authenticate API requests over > HTTP. A client sends a token in the Authorization header like so: > > Authorization: Token token=notasecret > > The token is then parsed from the authorization header and checked for > authenticity on the server side. > > This middleware aims to make it easy to add HTTP token authentication to > your application, like it is in many other frameworks. > > > This is my first open source Clojure project, and I'm excited to share it > with you. > Come check it out at https://github.com/jstewart/ring-token-authenticationor > on clojars here: > https://clojars.org/ring-token-authentication > -- 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: Chord 0.3.0 - WebSockets as core.async channels
I've just pushed v0.3.0 of Chord, a library to make a WebSockets appear as a bi-directional core.async channels. More info on GitHub <https://github.com/james-henderson/chord>. New since 0.2.2: - Messages over the channel treated as EDN by default (although option to fall back to previous raw strings) - this saves wrapping every write with `pr-str` and every read with `edn/read-string` As usual, feedback welcome! Cheers, 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.
ANN: Clidget 0.2.0
Hi all, I've just released a new version of Clidget<https://github.com/james-henderson/clidget>- a very lightweight library similar to Om, that watches your application state and re-renders your UI components when necessary. 0.2.0 is a significant performance upgrade over 0.1.0 due to better batching of DOM updates - which means that Clidget is now comparable<https://gist.github.com/james-henderson/9020774>in performance to Om. For those who haven't seen Clidget before: - Clidget has *one macro*, 'defwidget', which looks and behaves like 'defn' - you take in *values* and return a real DOM element, like any other Clojure function. When you call it, pass it *atoms*, and Clidget will work out when the DOM element needs to be re-rendered. That's all there is to it! - You choose how to render the DOM element, how to respond to events and how to update the atoms. Clidget does *one thing* - figuring out when to update widgets - there are people far better than me at designing DOM templating libraries! Useful links: - Github, Rationale and README<https://github.com/james-henderson/clidget> - A more in-depth comparison to Om, Reagent and React<https://github.com/james-henderson/clidget/blob/master/comparison.org> - Clidget 'Hello world<https://github.com/james-henderson/clidget/tree/master/clidget-sample> ' - Contact Manager Tutorial<https://github.com/james-henderson/clidget/tree/master/contacts> (along the same lines as Om + Reagent's tutorials) - TodoMVC implementation<https://github.com/james-henderson/clidget/tree/master/todomvc> Feedback always welcome! Cheers, James (@jarohen <https://twitter.com/jarohen>) -- 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
Hi folks, sorry I'm a bit late to the party, but Chord might be a good base for what you want to do? It probably falls a bit short at the moment on your disconnection semantics, but could be worth a shot. https://github.com/james-henderson/chord 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.
[ANN] Clidget, a lightweight CLJS state utility that helps you build small, composable UI ‘widgets’.
Hi all,
I've recently released *Clidget v0.1.0*, a new lightweight CLJS state
utility that allows you to build UIs through small, composable widgets.
Quick links:
- GitHub <https://github.com/james-henderson/clidget> (README, Rationale
and Getting Started)
- Sample 'counter'
application<https://github.com/james-henderson/clidget/tree/master/clidget-sample>
- TodoMVC
implementation<https://github.com/james-henderson/clidget/tree/master/todomvc>
The fundamental idea behind Clidget is to ensure that you can write widgets
declaratively, in traditional Clojure style, as a function that *takes in
immutable values and returns a DOM element*. Then, rather than calling that
function with values, you* call it with atoms*, and Clidget figures out
when each widget needs to be re-rendered.
So, a counter widget would look something like this (using Dommy to create
the DOM element and core.async for event handling - you're free to choose
whatever you like):
(:require [cljs.core.async :as a]
[dommy.core :as d]
[clidget.widget :refer [defwidget] :include-macros true])
(:require-macros [dommy.macros :refer [node]]
[cljs.core.async.macros :refer [go-loop]]))
(defwidget counter-widget [{:keys [counter]} events-ch]
(node
[:div
[:h2 "counter is now: " counter]
[:p
(doto (node [:button "Increment counter"])
(d/listen! :click #(a/put! events-ch :inc-counter)))]]))
To include a widget in the page, call it (it’s just a function!), but
provide it with the *atoms* that it needs to watch:
(set! (.-onload js/window)
(fn []
(let [!counter (atom 0)
events-ch (doto (a/chan)
;; 'watch-events!' implemented below
(watch-events! !counter))]
(d/replace-contents! (.-body js/document)
(counter-widget {:!counter !counter}
events-ch)]
(I'm prefixing the atom with '!', to easily differentiate between
atoms and values)
Finally, we implement watch-events! (no Clidget here):
(defn watch-events! [events-ch !counter]
(go-loop []
(when-let [event (a/https://github.com/james-henderson/clidget/blob/master/comparison.org>
.
*Feedback*
The idea behind Clidget is still very much experimental - I'd be very
interested to hear thoughts and feedback (good, bad, and 'what on earth
were you thinking?!') on the approach and/or implementation, please let me
know! GitHub, Twitter (@jarohen <https://twitter.com/jarohen>) or through
here are all good.
If you've got this far, thanks for reading!
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.
[ANN] Clidget, a lightweight CLJS state utility that helps you build small, composable UI ‘widgets’.
Hi all,
I've recently released Clidget v0.1.0, a new lightweight CLJS state utility
that allows you to build UIs through small, composable widgets.
Quick links:
- GitHub <https://github.com/james-henderson/clidget> (README, Rationale
and Getting Started)
- Sample 'counter'
application<https://github.com/james-henderson/clidget/tree/master/clidget-sample>
- TodoMVC
implementation<https://github.com/james-henderson/clidget/tree/master/todomvc>
The fundamental idea behind Clidget is to ensure that you can write widgets
declaratively, in traditional Clojure style, as a function that *takes in
immutable values and returns a DOM element*. Then, rather than calling that
function with values, you* call it with atoms*, and Clidget figures out
when each widget needs to be re-rendered.
So, a counter widget would look something like this (using Dommy to create
the DOM element and core.async for event handling - you're free to choose
whatever you like):
(:require [cljs.core.async :as a]
[dommy.core :as d]
[clidget.widget :refer [defwidget] :include-macros true])
(:require-macros [dommy.macros :refer [node]]
[cljs.core.async.macros :refer [go-loop]]))
(defwidget counter-widget [{:keys [counter]} events-ch]
(node
[:div
[:h2 "counter is now: " counter]
[:p
(doto (node [:button "Increment counter"])
(d/listen! :click #(a/put! events-ch :inc-counter)))]]))
To include a widget in the page, call it (it’s just a function!), but
provide it with the *atoms* that it needs to watch:
(set! (.-onload js/window)
(fn []
(let [!counter (atom 0)
events-ch (doto (a/chan)
;; 'watch-events!' implemented below
(watch-events! !counter))]
(d/replace-contents! (.-body js/document)
(counter-widget {:!counter !counter}
events-ch)]
(I'm prefixing the atom with '!', to easily differentiate between
atoms and values)
Finally, we implement watch-events! (no Clidget here):
(defn watch-events! [events-ch !counter]
(go-loop []
(when-let [event (a/https://github.com/james-henderson/clidget/blob/master/comparison.org>.
*Feedback*
The idea behind Clidget is still very much experimental - I'd be very
interested to hear thoughts and feedback (good, bad, and 'what on
earth were you thinking?!') on the approach and/or implementation,
please let me know! GitHub, Twitter (@jarohen
<https://twitter.com/jarohen>) or through here are all good.
If you've got this far, thanks for reading!
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.
[ANN] Frodo 0.2.9 - Ring-compatible web server with Stuart Sierra's 'Reloaded' workflow
Hi all, I've just released Frodo 0.2.9 - a web server plugin that allows you to develop using Stuart Sierra's 'Reloaded' workflow. It sets up a web server that you can nREPL into, easily open a CLJS browser REPL (using Chas Emerick's 'Austin' library) and, when you've made changes, to start a fresh web-server and refresh the server-side state without restarting the JVM. *https://github.com/james-henderson/frodo*<https://github.com/james-henderson/frodo> If you haven't seen it already, Stuart's written a great blog on how to develop using the 'Reloaded' workflow and its benefits - it's at http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded. There are plenty of Frodo examples and a sample project on the GitHub repo, but the basic premise is that you configure Frodo with a function that initialises your system state and returns a handler. When your server-side code changes and you run (user/reload-frodo!)in the REPL, it will reload any changed namespaces (and anything that depends on a changed namespace), restart the web server and ask your function to initialise its state and return another handler. This usually looks something like: (ns your-app.handler (:require [compojure.core :refer [routes GET]] [compojure.handler :refer [api]] [ring.util.response :refer [response]])) (defn app-routes [] (let [system (init-system)] (routes (GET "/route/:id" [id] (response (handle-get system id))) ...))) (defn app [] (-> (app-routes) wrap-with-ring-middleware api)) You'd then configure Frodo to use '*your-app.handler/app*' as its entry point. Probably the easiest way to get up and running is to use '*splat*', a Lein template: lein new splat cd lein dev If you've got any questions or feedback, it'd be great to hear it! Let me know, either through here, GitHub or Twitter (I'm @jarohen<https://twitter.com/jarohen> ) Hope you all have a great Christmas, and a happy New Year! 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: [ANN] cljs-start 0.0.7 now support source-map
Hi all, On Tuesday, 17 December 2013 16:35:24 UTC, Magomimmo wrote: > In my mind I think about something like a pair composed by of a lein template > and a lein plugin. > > > The template should serve to create new mixed clj/cljs projects and the > plugin should serve to easily manage the project itself. > I recently wrote a clj/cljs template called 'splat' which is implemented exactly as you suggest - `lein new splat ` > > I would be even better to absorb the awesome stuff my Stuart Sierra and jig, > then absorb stuff regarding continuos development, integration and deployment to try to minimize any incidental complexities caused by the used tools. > That would be great - at the moment I rely on connecting to the nREPL (in preference to the plugin naively guessing what to reload) but something based on the Reloaded workflow or Jig would be really cool. > > > A kind of reference sample could http://yeoman.io/ > Will take a look, thanks for the pointer! > > > mimmo > > 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: [ANN] Chord 0.2.1 - making WebSockets look like core.async channels in CLJ+CLJS
Unfortunately Chord only accepts raw strings on the channel at the moment -
I've been using pr-str and read-string around EDN messages until now.
It's a great idea to be able to format/parse different message formats
automatically though and something that IMO Chord should provide. I've
added a GitHub issue <https://github.com/james-henderson/chord/issues/4> -
watch this space!
Thanks,
James
On Monday, 2 December 2013 09:38:50 UTC, Henrik Eneroth wrote:
>
> Cool! I presume you're restricted to EDN on the channels though, right?
>
> On Saturday, November 30, 2013 5:23:17 PM UTC+1, James Henderson wrote:
>>
>> https://github.com/james-henderson/chord
>>
>> Chord is a library for making WebSockets look like simple core.async
>> channels in Clojure (using http-kit) and ClojureScript.
>>
>> Basic usage:
>>
>> Leiningen:
>>
>> [jarohen/chord "0.2.1"]
>>
>> ClojureScript:
>>
>> (:require [chord.client :refer [ws-ch]]
>> [cljs.core.async :refer [! put! close!]])(:require-macros
>> [cljs.core.async.macros :refer [go]])
>> (go
>> (let [ws (>(>! ws "Hello server!")
>>(loop []
>> (when-let [{:keys [message]} (>(js/console.log "Got message from server:" message)
>>(recur)
>>
>>
>> Clojure (a wrapper around http-kit's 'with-channel'):
>>
>> (:require [chord.http-kit :refer [with-channel]]
>> [clojure.core.async :refer [! put! close! go]])
>> (defn your-handler [req]
>> (with-channel req ws-ch
>> (go
>> (let [{:keys [message]} (> (println "Message received from client:" message)
>> (>! ws-ch "Hello client from server!")
>> (close! ws-ch)
>>
>>
>> There's more documentation and a few code examples on the Github page,
>> and a full example project in the repo.
>>
>> Feedback is *always very welcome* - either here, through Github in the
>> usual way or (if it fits into 140 chars!) Twitter.
>>
>> Version 0.2.1 brings the ability to specify custom buffered channels -
>> thanks to Timo Sulg for the PR!
>>
>> James (@jarohen)
>>
>
--
--
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] Chord 0.2.1 - making WebSockets look like core.async channels in CLJ+CLJS
https://github.com/james-henderson/chord
Chord is a library for making WebSockets look like simple core.async
channels in Clojure (using http-kit) and ClojureScript.
Basic usage:
Leiningen:
[jarohen/chord "0.2.1"]
ClojureScript:
(:require [chord.client :refer [ws-ch]]
[cljs.core.async :refer [! put! close!]])(:require-macros
[cljs.core.async.macros :refer [go]])
(go
(let [ws (! ws "Hello server!")
(loop []
(when-let [{:keys [message]} (! put! close! go]])
(defn your-handler [req]
(with-channel req ws-ch
(go
(let [{:keys [message]} (! ws-ch "Hello client from server!")
(close! ws-ch)
There's more documentation and a few code examples on the Github page, and
a full example project in the repo.
Feedback is *always very welcome* - either here, through Github in the
usual way or (if it fits into 140 chars!) Twitter.
Version 0.2.1 brings the ability to specify custom buffered channels -
thanks to Timo Sulg for the PR!
James (@jarohen)
--
--
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: How do you configure your Ring apps?
Hi Gordon/all, Hope you'll forgive the plug, but it sounds like Nomad<https://github.com/james-henderson/nomad.git> does what you want here. In particular, it allows you to store configuration for multiple different environments as a simple EDN config file in your project repo (Gordon's 'global.clj'), meaning that it's versioned with the rest of your project code (i.e. there's no need to configure Puppet etc separately, and keep the project and Puppet versions co-ordinated). It also allows for 'private config files' (Gordon's 'local.clj'), to store passwords etc that you don't want in version control. HTH! James On Sunday, 8 September 2013 02:44:24 UTC+1, Gordon Stratton wrote: > > I'm only starting out with Clojure/Ring, but I was thinking about this > recently too. I had something like the following in mind, borrowing > some concepts from other projects/frameworks/strategies that I've had > success with. > > The project could contain something like 'config/global.clj' which > contains a simple Clojure map with configuration for your app that is > appropriate for version control. Maybe it has some default values, > comments, etc. You could build this in to your app somewhere, too. > > The project would then have another Clojure map in a file named like > 'config/local.clj' in your project root which would be ignored by > version control, and deployed alongside your application. You'd > probably template it with Puppet or Chef or Ansible and it would > contain your deep, dark secrets. You'd have a project-local one of > these for development. You could even have more than one, if that's > your thing. > > At application initialization, the maps are then read in, merged and > made available to your application exactly like weavejester's environ > that you mentioned. environ already handles leiningen profiles for > things like AWS access keys which might be annoying to duplicate > across all of your projects in development, and such a system as I've > described would fit in fairly naturally with environ. In any event, I > hadn't found that project yet, but I definitely plan to use it now. > Thanks for pointing it out! > > On Sat, Sep 7, 2013 at 11:53 PM, Alexandr Kurilin > > > wrote: > > I'm curious to find out how you folks decided to organize configuration > for > > your Ring applications, assuming you also use configuration management > like > > Puppet/Ansiblet etc to deploy them. > > > > So far I've been using a combination of daemontools' envdir (through > runit) > > + weavejester's environ for things like db address, db password, cookie > > secret keys, logging level etc. Each one is an individual file in > root-only > > folder that runit envdirs from. > > > > I honestly can't decide whether a single configuration file (YAML, EDN, > > whatever) would be more appropriate for this scenario or if I should go > > ahead and continue keeping each configuration value in its own file and > use > > env to load them. > > > > What are people's thoughts on this? Any reason why one or the other > would be > > better, or is there an even better option out there I'm not considering? > -- -- 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: Current state of the art in Web deployment?
Hi John, Building on Ray's answer to use Upstart, I've recently started using a Git-based deployment method that essentially uses a Git post-receive hook to re-deploy the application with a simple git push. To set-up, create a bare repo and a working tree on the deploy host, and the relevant Upstart job. We then deploy using *`git push deployhost:path/to/deploy-repo.git master:deploy`*. When a push is received on the deploy branch, the hook on the remote repo updates the working tree, and restarts the Upstart job. (I use SystemD services in place of Upstart when I get the choice - IMO it beats Upstart hands-down, but that's an aside!) I've put the post-receive hook at https://gist.github.com/james-henderson/6263386 - hope this helps! Regards, James On Sunday, 18 August 2013 17:21:22 UTC+1, John Jacobsen wrote: > > Many thanks to everyone who replied about deploying a Web server to > production. Specific replies: > > On Aug 17, 2013, at 6:51 PM, Mark Mandel > > wrote: > > > > > On Sun, Aug 18, 2013 at 6:52 AM, John Jacobsen > > > > wrote: > >> After some prototyping and development, we are now getting to the stage > where "lein run" and a Jetty server running from -main aren't going to cut > it. > > > > At the risk of asking a dumb question, but being quite new to Clojure, I > don't mind - why do you say they won't cut it? > > On Aug 18, 2013, at 9:25 AM, Norman Richards > > > wrote: > > > Other than that, mechanically our deploy is not significantly different > from a lein ring server, so maybe you can explain what your concerns with > that are? > > My main concern was just the need to ssh into the server and run leiningen > in the background, as opposed to setting up a "real" server which starts at > boot time. I'm OK w/ wrapping 'lein ring server-headless' with > Apache/Nginx, if there are no known issues w/ that approach. > > > On Aug 17, 2013, at 4:52 PM, Ray Miller > > wrote: > > > One option is simply to write an upstart script that invokes 'lein > > ring server-headless' and sit an apache or nginx proxy in front of it. > > That's how my website is currently running. Alternatively, you could > > deploy your application as a war to tomcat or jetty. > > > > The upstart configuration, which is installed to /etc/init/cms.conf, > > can be found here: https://gist.github.com/ray1729/6258845 > > That's very helpful -- can you be a little more specific about what you > mean by "sit an apache or nginx proxy in front of it"? It looks like your > example is self-contained (need Clojure/lein + upstart, and that's it). > > Thanks again everyone. > > John > > > > -- -- 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: Would you please help in migrating this code from Bishop to Liberator?
For anyone stumbling upon this question - it was answered on the Liberator
Github repository, at
https://github.com/clojure-liberator/liberator/issues/6
James
On Wednesday, 19 September 2012 14:05:08 UTC+1, Hussein B. wrote:
>
> Hi,
>
> I want to migrate this code written in Bishop REST framework to Liberator
> REST framework:
>
> (bishop/defresource ticket
> {
> "text/html"
> (fn [request]
> (let [request-method (:request-method request)]
> (case request-method
> :get (list-all-tickets request)
> :post (create-ticket-per-uploaded-file request
> }
>
> {
> :allowed-methods (fn [request] [:get :post])
> })
>
> I'm not really digesting the liberator approach.
>
> Thanks for help and time.
>
--
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
