Re: [ANN] org.clojure/tools.cli 0.4.1

[Pierre-Yves Ritschard]

Thanks for tools.cli, it's a pillar of a number of our projects, present in 
almost all our `main.clj` files :-)

On Sunday, September 23, 2018 at 11:16:34 PM UTC+2, Sean Corfield wrote:
>
> Alex says the auto-generation process is broken and needs to be run 
> manually for each project right now. I figured out that was 
> `clojure/contrib-api-doc` and ran it on `tools.cli` so those docs are 
> up-to-date now.
>
>  
>
> I also ran it manually for `java.jdbc` so that’s up-to-date 
> (0.7.9-SNAPSHOT) as well.
>
>  
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
> --
> *From:* Sean Corfield >
> *Sent:* Sunday, September 23, 2018 1:35:42 PM
> *To:* clo...@googlegroups.com 
> *Subject:* RE: [ANN] org.clojure/tools.cli 0.4.1 
>  
>
> That documentation is auto-generated behind the scenes as part of the 
> build system (I think, or maybe some other process) so if it isn’t 
> up-to-date, maybe Alex Miller can take a look?
>
>  
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
> --
> *From:* clo...@googlegroups.com   > on behalf of Patrick Kristiansen  >
> *Sent:* Sunday, September 23, 2018 12:54:25 PM
> *To:* Clojure
> *Subject:* Re: [ANN] org.clojure/tools.cli 0.4.1 
>  
> Thanks, Sean. 
>
> Any chance you could update the API documentation here: 
> http://clojure.github.io/tools.cli/index.html
>
> On Sunday, September 23, 2018 at 5:18:44 AM UTC+2, Sean Corfield wrote: 
>>
>> Tools for working with command line arguments. 
>> https://github.com/clojure/tools.cli clj -Sdeps '{:deps 
>> {org.clojure/tools.cli {:mvn/version "0.4.1"}}}' 
>> Boot/Leiningen: [org.clojure/tools.cli "0.4.1"] This is a minor update 
>> that introduces new options :update-fn and :default-fn that make it easier 
>> to work with non-idempotent command line options (such as 
>> incrementing/counting options) and addresses a problem raised in 
>> https://dev.clojure.org/jira/browse/TCLI-90 (poor interaction between 
>> the existing :assoc-fn and :default options).
>> -- 
>> Sean A Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>> World Singles, LLC. -- http://worldsingles.com/
>>
>> "Perfection is the enemy of the good."
>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to 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.

[JOB] Senior software engineer - backend at Exoscale | Switzerland or remote in Europe

[Pierre-Yves Ritschard]

Hi,

For the past 6 years, critical backend systems at Exoscale have been 
written in Clojure and help power very large cloud workloads across several 
industries, even down to 10k+ core workloads for CERN. The team is spread 
across Europe with headquarters in Lausane, Switzerland.

We're growing the team, here's the job description:

As parts of its ongoing efforts to bring new features to the platform, 
Exoscale is hiring a senior software engineer.

The senior software engineer position is focused on creating and 
maintaining new functionality for Exoscale in areas such as storage, 
network, and overall orchestration. The engineering team at Exoscale works 
on all aspects of Exoscale from developing products, to their operation and 
support.

Backend engineers at Exoscale focus on the orchestration layer. This 
involves building APIs, writing stream processing consumers, and daemons 
which perform orchestration duties. In cooperation with the SRE team 
backend engineers help ensure all Exoscale components are resilient and 
observable.

Backend systems at Exoscale are written primarily in Clojure and also 
depend on a mix of Java, Python, and Go.


https://www.exoscale.com/jobs/


Cheers,

Pierre-Yves

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

[JOBS] Clojure and ClojureScript at Exoscale

[Pierre-Yves Ritschard]

Hi!

Exoscale is growing fast and adding a number of Clojure and ClojureScript 
positions.
We have been building our European cloud with Clojure since 5 years now and 
work on large orchestration and stream processing projects.
This year marks the year where we will switch to ClojureScript for a number 
of frontend interfaces.

We're adding 5 members in our Lausanne team, and will shortly open a 
similar number of positions in Vienna.
We do not open fully remote positions and administratively we have a hard 
time hiring people coming from outside of the EU or Switzerland.

A bit more information here: https://www.exoscale.ch/jobs/

Cheers,
  - pyr

-- 
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: What is juxt really doing?

[Pierre-Yves Ritschard]

A while back I showed how to use it for simplistic pattern matching too: 
http://spootnik.org/entries/2013/05/21/poor-mans-pattern-matching-in-clojure/

On Monday, July 17, 2017 at 3:10:14 AM UTC+2, lawrence...@gmail.com wrote:
>
> Thank you for all the responses. The examples of using juxt to sort among 
> results that are otherwise the same is a good example. 
>
>
> On Sunday, July 16, 2017 at 3:18:07 AM UTC-4, Boris V. Schmid wrote:
>>
>> I don't use juxt much, but the example that I did pick up is where juxt 
>> is used for sorting on one function first, and in the case of a tie, on the 
>> second function. That is quite useful to me.
>>
>> > 
>> (sort-by (juxt first second) (map vector (repeatedly 10 #(rand-int 3)) 
>> (shuffle (range 10
>> ([0 1] [0 4] [0 5] [0 6] [0 7] [0 8] [1 2] [1 3] [2 0] [2 9])
>>
>> On Sunday, July 16, 2017 at 5:52:44 AM UTC+2, lawrence...@gmail.com 
>> wrote:
>>>
>>>
>>>
>>> Does anyone use juxt in the real world, or is mostly for examples? 
>>>
>>>
>>>
>>  
>>
>

-- 
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] net: the clojure netty companion 0.3.3-beta2

[Pierre-Yves Ritschard]

Hi,

Some time ago, I followed a path which involved not depending on aleph[1] 
for asynchronous programming.
Some bits that we use internally at Exoscale where carved out in what is 
now net[2].

This library aims to provide a thin layer on top of netty, staying a bit 
closer to netty than aleph permits, with less dependencies.
I'd like to point out that this might not be for everyone, and that if you 
want an all-encompassing framework, aleph may be better suited.

That being said, a smaller and more lightweight library might be of 
interest to some, so here is net, now with guides[3] and api 
documentation[4] to help explain the
netty programming model.

Next up: more guides, tests and specs.

[1]: http://aleph.io
[2]: https://github.com/pyr/net
[3]: http://pyr.github.io/net/intro.html
[4]: http://pyr.github.io/net

-- 
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: Libraries for dealing with DNS

[Pierre-Yves Ritschard]

Hi Kyle,

If you don't mind synchronous queries, "InetAddress/getByName" will do the
job just fine and use your system resolving parameters.
http://docs.oracle.com/javase/6/docs/api/index.html?java/net/InetAddress.html#getByName

Cheers,
  - pyr

On Mon, Oct 19, 2015 at 9:56 AM, JvJ  wrote:

> DNS clients happen to be my job.  If you can't find one, maybe I'll
> conttibute to something.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] Clojure 1.8.0-beta1

[Pierre-Yves Ritschard]

Hi Mike,

The code at here seems to contradict you:
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/APersistentVector.java#L448-L460,
as does "(key [:a :b])" in the REPL.

The only limitation is that vectors need to be of size two to act as
IMapEntries (otherwise an IllegalOperation exception is thrown).

The change seems logical and allows key & val to be used more generically.

You're right that will fail on code that checks for (instance? IMapEntry).

A good alternative - paging Alex Miller - could be for (empty) on a
MapEntry to return an empty PersistentVector instead of nil, which would
ensure that calls to (into (empty ) (map f ))
would return a valid map entry (instead of a collection).

I'm happy to create a ticket for this use-case if deemed valid.

Cheers,
  - pyr



On 10/16/2015 01:28 AM, Mike Rodriguez wrote:
> Someone else looked at the issue on 
> https://github.com/ztellman/riddley/issues/18
> 
> This issue makes the current version of riddley, and therefore potemkin, not 
> work on Clojure 1.8 beta1
> 
> There is a pull request to fix it at 
> https://github.com/ztellman/riddley/pull/19
> 
> However I am wondering if it is going to affect more places. The problem is 
> that in Clojuee 1.8 APersistentVector now implements IMapEntry (therefore 
> j.u.Map$Entry as well), but it doesn't implement the key or val methods. 
> What is the reason for that change and/or is this a desired side effect of 
> the change?
> 

-- 
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: component: dynamic configuration

[Pierre-Yves Ritschard]

Thanks for the clarifications!

On 07/07/2015 11:52 PM, Stuart Sierra wrote:
 Hi pyr,
 
 There are many downsides to hierarchical structure of components and
 systems. The effects are complicated and hard to understand. See, for
 example, the discussion at
 https://groups.google.com/forum/#!topic/clojure/2-baBp61XTs/discussion
 
 I recommend that system maps be kept flat, without any nested systems.
 
 To prevent name clashes, you can always generate unique keys for the
 components.
 
 –S
 
 
 On Tuesday, July 7, 2015 at 2:47:03 PM UTC-4, Pierre-Yves Ritschard wrote:
 
 Would you directly assoc :inputA :inputB :outputA :outputB components
 in the first layer of the system map or would you retain a hierarchical
 structure and if so, are there any downsides to this ?
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to 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 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.

component: dynamic configuration

[Pierre-Yves Ritschard]

Hi,

I've been using an approximation of what component provides in my
applications for quite a while, and I'm trying to see if it's feasible
to move to component, in the sake of homogeneity with the rest of the
clojure world and to see if there are things that make my life easier.

I have a couple of apps which expose a somewhat generic way of
manipulating data in a certain way. Most follow the pattern of having
several possible inputs (which must all adhere to a protocol), an engine
that does its work and several possible outputs (again, adhering to a
protocol).

While configuring each of these inputs or outputs as components is
straightforward, I failed to find a good strategy for storing them and
constructing the system-map correctly.

Did anyone tackle this yet and if so are they willing to share their
approach ?

Cheers,
  - pyr

-- 
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: component: dynamic configuration

[Pierre-Yves Ritschard]

Hi,

I did get this far indeed. My general question was rather: what's your
general approach ?

Say I happen to have a config that loosely looks like:

   {:inputs [{:type :inputA ...} {:type :inputB ...}]
:engine {:engine-opt1 :engine-arg1}
:outputs [{:type :outputA ...} {:type :outputB ...}]}

Would you directly assoc :inputA :inputB :outputA :outputB components
in the first layer of the system map or would you retain a hierarchical
structure and if so, are there any downsides to this ?

Cheers,
  - pyr

On 07/07/2015 07:07 PM, Stuart Sierra wrote:
 Not sure if this helps, but remember that components and systems are
 just records, and records behave like maps. You can construct an empty
 `system-map` and then `assoc` components or even `merge` other maps into it.
 
 –S
 
 
 On Tuesday, July 7, 2015 at 1:00:51 PM UTC-4, Pierre-Yves Ritschard wrote:
 
 Hi,
 
 I've been using an approximation of what component provides in my
 applications for quite a while, and I'm trying to see if it's feasible
 to move to component, in the sake of homogeneity with the rest of the
 clojure world and to see if there are things that make my life easier.
 
 I have a couple of apps which expose a somewhat generic way of
 manipulating data in a certain way. Most follow the pattern of having
 several possible inputs (which must all adhere to a protocol), an
 engine
 that does its work and several possible outputs (again, adhering to a
 protocol).
 
 While configuring each of these inputs or outputs as components is
 straightforward, I failed to find a good strategy for storing them and
 constructing the system-map correctly.
 
 Did anyone tackle this yet and if so are they willing to share their
 approach ?
 
 Cheers,
   - pyr
 
 -- 
 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
 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 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] unilog 0.7.5: logging should be easy

[Pierre-Yves Ritschard]

Hi #clojure,

I just released unilog 0.7.5 (previously logconfig). Unilog provides a
map-based configuration interface for logback, which will be picked up
by clojure.tools.logging, log4j, JuL and commons-logging - the standard
JVM logging mechanisms.

If you're writing executables (daemons, batches, etc) unilog can provide
your users with an easy way of configuring logging, it's map based
interface makes it simple for you to integrate in your existing
configuration mechanism.

The rationale behind the project is that I found it quite hard back when
I was a JVM  Clojure beginner to piece together the necessary bits to
get a sane logging experience.

If you rely on specific appenders or encoders, unilog provides a
multi-method based mechanism to add support for new logging methods.

https://github.com/pyr/unilog

Cheers,
  - pyr

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

JDK8

[Pierre-Yves Ritschard]

Hi,

There hasn't been a JDK version thread in a while and a few projects we
rely on will soon require a JDK8. Are people running large apps on JDK8 and
if so, which one ? I'd be intent on trying to stick with OpenJDK if at all
possible.

Cheers,

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

moving from core.async/reduce to transducers

[Pierre-Yves Ritschard]

Hi clojure,

There's a thing I find myself doing often in some of my projects where
I reduce over a core.async channel this way:

(core.async/reduce update-fn init-state input-channel)

By doing this on a stream of inbound events.
When looking at doing this with transducers, it's a bit unclear how to fit
the fact that I'm not doing any modification on the input-channel, do you
usually just use identity there ?

(transduce update-fn identity init-state input)

Moving to a transducer based approach is tempting, especially since it
would allow for a simpler REPL-based workflow, but I want to make sure I
get this right.

Cheers!

-- 
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] logconfig 0.7.1

[Pierre-Yves Ritschard]

I wrote a few more words to describe the motivation behind logconfig:
http://spootnik.org/entries/2014/10/15_easy-clojure-logging-set-up-with-logconfig.html

On Tue, Oct 14, 2014 at 11:17 PM, Pierre-Yves Ritschard p...@spootnik.org
wrote:

 Hi,

 While clojure.tools.logging does a great job at logging, writing programs
 in clojure involves
 setting up the logging, which for people not familiar with the JVM can
 mean a lot of head scratching before figuring out how log4j.properties work
 and can be fed to a JVM.

 logconfig was meant to help in this scenario, allowing external
 log4j.properties to exist if need be
 but defaulting to a simpler method which can coexist with the
 application's main configuration method.

 logconfig provides a simple map-based config (which you might deserialize
 from a YAML/Json/EDN configuration file, or elsewhere) and supports console
 appenders as well as timebased rolling appenders, pattern layout and json
 layouts for easy interaction with syslog-ng, logstash and friends.

 https://github.com/pyr/logconfig
 http://pyr.github.io/logconfig

 Hope this helps!

   - pyr


-- 
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] logconfig 0.7.1

[Pierre-Yves Ritschard]

Hi,

While clojure.tools.logging does a great job at logging, writing programs
in clojure involves
setting up the logging, which for people not familiar with the JVM can mean
a lot of head scratching before figuring out how log4j.properties work and
can be fed to a JVM.

logconfig was meant to help in this scenario, allowing external
log4j.properties to exist if need be
but defaulting to a simpler method which can coexist with the application's
main configuration method.

logconfig provides a simple map-based config (which you might deserialize
from a YAML/Json/EDN configuration file, or elsewhere) and supports console
appenders as well as timebased rolling appenders, pattern layout and json
layouts for easy interaction with syslog-ng, logstash and friends.

https://github.com/pyr/logconfig
http://pyr.github.io/logconfig

Hope this helps!

  - pyr

-- 
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: Is Korma still a good current choice for DB backend?

[Pierre-Yves Ritschard]

For the record, I never ran in any structural issue when working with
clojure.java.jdbc and clojure.java.jdbc.sql. It lets you write clean and
composable queries and removes takes care of the essential (escaping and
the like).




On Wed, Jul 23, 2014 at 11:14 AM, David Powell djpow...@djpowell.net
wrote:

 I'm using honeysql for constructing dynamic queries (eg conditionally
 adding complex clauses).  It feels a bit more composable to me, and seemed
 much easier to add the OR of several clauses to a query etc.



 On Tue, Jul 22, 2014 at 1:28 PM, Michael Klishin 
 michael.s.klis...@gmail.com wrote:

 On 22 July 2014 at 16:10:31, Jonathon McKitrick (jmckitr...@gmail.com)
 wrote:
   Development and support seem to have slowed down. Are there
  newer or better choices out there with momentum right now?

 Just use clojure.jdbc or clojure.java.jdbc with a validation library
 (Validateur,
 Schema, Bouncer,  etc).

 There is no rush to use the newest hotness in the Clojure community so
 Korma
 should work OK if that's what you want.
 --
 @michaelklishin, github.com/michaelklishin

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


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


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

Re: [ClojureScript] ANN: core.match 0.2.0-beta2

[Pierre-Yves Ritschard]

Thank you for the AOT fixes!


On Mon, Jun 17, 2013 at 7:10 AM, Ambrose Bonnaire-Sergeant 
abonnaireserge...@gmail.com wrote:

 Fantastic news!


 On Mon, Jun 17, 2013 at 1:04 PM, David Nolen dnolen.li...@gmail.comwrote:

 At long last I've come around to overhauling core.match.

 Changes/Fixes/Enhancements are documented here:
 http://github.com/clojure/core.match/blob/master/CHANGES.md

 core.match should no longer have AOT issues as far as I know and many
 long outstanding bugs have been eliminated. The ClojureScript support is
 now more or less at parity with Clojure JVM.

 Less obvious - because of the overhaul, addressing issues should now be
 considerably simpler. Feedback very welcome and I promise to be more
 responsive on core.match issues moving forward :)

 http://github.com/clojure/core.match

 David

 --
 Note that posts from new members are moderated - please be patient with
 your first post.
 ---
 You received this message because you are subscribed to the Google Groups
 ClojureScript group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojurescript+unsubscr...@googlegroups.com.
 To post to this group, send email to clojurescr...@googlegroups.com.
 Visit this group at http://groups.google.com/group/clojurescript.




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

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




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

Re: I tripped out

[Pierre-Yves Ritschard]

atkaaz, you can do this: (fn [ {:keys [arg1 arg2 arg3]}] ...)


On Mon, May 6, 2013 at 10:03 PM, AtKaaZ atk...@gmail.com wrote:

 I agree, I'm not sure what he means xD
 If you ask me, I'd rather have each arg be identified by a keyword instead
 of by order
 like: (somefn :arg1 somestr :arg3 100 :arg2 (+ 1 2))
 or all those in a map
 I'll probably still do that for me, so that any function will take params
 like this. There's probably a way this can be done but it's not good enough
 for me, was it with :keys and :as map ?



 On Sun, May 5, 2013 at 10:52 PM, Alex Fowler alex.murat...@gmail.comwrote:

 Tell us more about it.


 On Sunday, May 5, 2013 11:54:32 AM UTC+4, JvJ wrote:

 Is anyone else tripped out when they realize that when you write args
 for a function you're basically just destructuring an arg vector?  It
 trips me out.

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




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




-- 
-- 
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] jenkins-leiningen

[Pierre-Yves Ritschard]

Hi guys,

I wanted this for a while so here goes:
https://github.com/pyr/jenkins-leiningen.
It is very simplistic and inspired from the sbt one.

I posted a small blurb about it here as well:
http://spootnik.org/entries/2012/07/18_a-leiningen-plugin-for-jenkins.html

Cheers,
  - pyr

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

Re: clojure.java.jmx 0.1 - problem getiing java.lang:type=Threading :AllThreadIds attribute

[Pierre-Yves Ritschard]

MBeans will let you store serialized java objects, so you can also
find hashmaps, or arbitrary arrays.
When you encounter cases like this one, you can extend
clojure.data.json's functionnality to get the
appropriate behavior (see
http://spootnik.org/blog/2011/08/12/a-bit-of-protocol/ for hints)


On Thu, Feb 23, 2012 at 2:47 AM, zoka ztomi...@gmail.com wrote:
 I was trying to convert result of JMX attributes query to JSON, and
 encountered  problem while reading one particular attribute value of
 java.lang:type=Threading. Here is the REPL transcript:

 demo.server= (require '[clojure.java.jmx :as jmx])
 nil
 demo.server= (jmx/read  java.lang:type=Threading :AllThreadIds)
 #long[] [J@1bd97d0d
 demo.server=

 This seems to be Java long array reference,

 The jmx/mbean function that returns all attribute name as keywords
 associated with their values carries this value through. Attempt to
 convert such map to JSON string  causes exception, since in this case
 a clojure vector of longs would be expected instead of Java array.

 This particular piece information (list of application ThreadIs) is
 not of particular interest to me anyway, so it is easy just to remove
 the offending map entry as a workaround.

 I have noticed some recent activity in clojure.java.jmx github repo,
 so I thought it would be appropriate to rise this issue, since it may
 be affecting some other attributes as well.

 Regards
 Zoka

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

Re: Dynamically Loading Jar Strategy

[Pierre-Yves Ritschard]

Thanks, this clarifies why my initial tests setting the current class
loader failed.

On Thu, Dec 8, 2011 at 2:14 AM, Brent Millare brent.mill...@gmail.com wrote:
 To better understand what's going underneath, you're just calling the addURL
 method of the classloader. But since you might be evaluating this at the
 repl, there is an important point regarding the classloader. Everytime
 clojure evaluates a form, it will use a new classloader on that form, and
 the parent will be the classloader of the caller of the eval. So this means
 if you evaluate two forms consecutively, the first being the addURL, and the
 second, the command depending on the jar, the second will fail (unless you
 wrap both commands in a let). You need to ensure that the parent of the
 current classloader in the call to addURL is set. This way, all future evals
 will delegate to the classloader that knows about the jar.

 So in summary, the heart of the command should just be:

 (.addURL (.getContextClassLoader (Thread/currentThread)) (.toURL (.toURI
 file)))

 For runtime dependency management, pomegranate does this, and so does my
 library, dj https://github.com/bmillare/dj

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

Dynamically Loading Jar Strategy

[Pierre-Yves Ritschard]

Hi,

I have a use case where a daemon needs to read full namespaces from an
external jar.
I can successfuly access the namespace in the jar with tools.namespace/
find-namespaces-in-jarfile, then from the jarfile, selecting
appropriate entries, coercing into readers and then loading with load-
reader.

This approach breaks as soon as the supplied jar does requires, since
the jar is not on the classpath. I am a bit surprised that setting a
classloader in the current thread with setContextClassLoader does not
work, as my binding for *use-context-classloader* is the default:
true.

I could obviously supply a fixed directory that is always in the
classpath but that would require having two configuration files, which
I thought I could avoid.

Is there a way around this, or am I stuck ?

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

Re: Dynamically Loading Jar Strategy

[Pierre-Yves Ritschard]

I ended up doing that, all the other approaches fail for me.
Thanks for the confirmation.

On Wed, Dec 7, 2011 at 8:12 PM, vitalyper vitaly...@yahoo.com wrote:
 You can add jar to a classpath at runtime via the hack below.
 http://groups.google.com/group/clojure/browse_thread/thread/95ea6e918c430e/69c0d195defeeed3?lnk=gstq=classpath#69c0d195deeed3

 HTH

 On Dec 7, 10:26 am, Pierre-Yves Ritschard p...@spootnik.org wrote:
 Hi,

 I have a use case where a daemon needs to read full namespaces from an
 external jar.
 I can successfuly access the namespace in the jar with tools.namespace/
 find-namespaces-in-jarfile, then from the jarfile, selecting
 appropriate entries, coercing into readers and then loading with load-
 reader.

 This approach breaks as soon as the supplied jar does requires, since
 the jar is not on the classpath. I am a bit surprised that setting a
 classloader in the current thread with setContextClassLoader does not
 work, as my binding for *use-context-classloader* is the default:
 true.

 I could obviously supply a fixed directory that is always in the
 classpath but that would require having two configuration files, which
 I thought I could avoid.

 Is there a way around this, or am I stuck ?

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

Re: Dynamically Loading Jar Strategy

[Pierre-Yves Ritschard]

Thanks a lot for the good advice. Pomegranate is very nice and very
useful for testing.
As for your trick Kevin, certainly nicer that the reflection mess.

On Wed, Dec 7, 2011 at 9:00 PM, Kevin Downey redc...@gmail.com wrote:
 try something like

 https://github.com/hiredman/clojurebot/blob/master/src/clojurebot/plugin.clj

 On Wed, Dec 7, 2011 at 11:53 AM, Pierre-Yves Ritschard p...@spootnik.org 
 wrote:
 I ended up doing that, all the other approaches fail for me.
 Thanks for the confirmation.

 On Wed, Dec 7, 2011 at 8:12 PM, vitalyper vitaly...@yahoo.com wrote:
 You can add jar to a classpath at runtime via the hack below.
 http://groups.google.com/group/clojure/browse_thread/thread/95ea6e918c430e/69c0d195defeeed3?lnk=gstq=classpath#69c0d195deeed3

 HTH

 On Dec 7, 10:26 am, Pierre-Yves Ritschard p...@spootnik.org wrote:
 Hi,

 I have a use case where a daemon needs to read full namespaces from an
 external jar.
 I can successfuly access the namespace in the jar with tools.namespace/
 find-namespaces-in-jarfile, then from the jarfile, selecting
 appropriate entries, coercing into readers and then loading with load-
 reader.

 This approach breaks as soon as the supplied jar does requires, since
 the jar is not on the classpath. I am a bit surprised that setting a
 classloader in the current thread with setContextClassLoader does not
 work, as my binding for *use-context-classloader* is the default:
 true.

 I could obviously supply a fixed directory that is always in the
 classpath but that would require having two configuration files, which
 I thought I could avoid.

 Is there a way around this, or am I stuck ?

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



 --
 And what is good, Phaedrus,
 And what is not good—
 Need we ask anyone to tell us these things?

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

Re: at-at

[Pierre-Yves Ritschard]

Shameless plug, but tron provides the same kind of functionality:
https://github.com/pyr/tron

Cheers,
   - pyr
On Wed, Aug 10, 2011 at 7:58 PM, David Nolen dnolen.li...@gmail.com wrote:
 On Wed, Aug 10, 2011 at 1:37 PM, Sam Aaron samaa...@gmail.com wrote:

 Hi,

 I just wanted to announce the arrival of the newly-born at-at library -
 freshly extracted from Overtone:

 https://github.com/overtone/at-at

 at-at is an ahead-of-time function scheduler which essentially provides a
 friendly wrapper around Java's ScheduledThreadPoolExecutor.

 Enjoy!

 Sam

 Nice!
 David

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