Re: [ANN] Clojure 1.9.0 is now available!

[Georgi Danov]

is the new clj CLI going to be alternative to Lein? For example can I run 
repl with middleware?

also, if I use lein repl, is deps.edn taken into account? I love that 
feature 

-- 
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: clojure.spec

[Georgi Danov]

I am aware my choice of challenge may be considered abuse. I did it as the 
grammar is big enough to allow me to (a) get to know the library (b) check 
how it handles larger inputs, as I've had problems with other libs in the 
past. 

As much as I like the UX, I'd be worried to add specs to my functions if I 
am not confident that I understand how the performance is affected (esp., 
related to the spec structure). Some info on that in the wiki would be 
great (but if I get to vote, I'd pick the clojurescript port first).

On Sunday, May 29, 2016 at 12:11:25 AM UTC+2, Rich Hickey wrote:
>
> spec is not for text parsing - there are plenty of more suitable tools for 
> that. It is not a general-purpose regex tool either. 
>
>
> > On May 28, 2016, at 5:46 PM, Georgi Danov <georgi...@gmail.com 
> > wrote: 
> > 
> > I love the regexp approach, so decided to implement JSON parser in order 
> to get acquainted with spec. The parser treats the input as char sequence. 
> > 
> > The parser works, code is very readable, however performance is horrible 
> — json file with 3.5k characters takes 350 seconds to process — 10 
> terms/sec. 
> > 
> > Here is the spec 
> https://gist.github.com/gdanov/3a0440255f7f4df262ce16ce87351a04 
> > 
> > On Monday, May 23, 2016 at 4:12:29 PM UTC+2, Rich Hickey wrote: 
> > Introducing clojure.spec 
> > 
> > I'm happy to introduce today clojure.spec, a new core library and 
> support for data and function specifications in Clojure. 
> > 
> > Better communication 
> > 
> > Clojure is a dynamic language, and thus far we have relied on 
> documentation or external libraries to explain the use and behavior of 
> functions and libraries. But documentation is difficult to produce, is 
> frequently not maintained, cannot be automatically checked and varies 
> greatly in quality. Specs are expressive and precise. Including spec in 
> Clojure creates a lingua franca with which we can state how our programs 
> work and how to use them. 
> > 
> > More leverage and power 
> > 
> > A key advantage of specifications over documentation is the leverage 
> they provide. In particular, specs can be utilized by programs in ways that 
> docs cannot. Defining specs takes effort, and spec aims to maximize the 
> return you get from making that effort. spec gives you tools for leveraging 
> specs in documentation, validation, error reporting, destructuring, 
> instrumentation, test-data generation and generative testing. 
> > 
> > Improved developer experience 
> > 
> > Error messages from macros are a perennial challenge for new (and 
> experienced) users of Clojure. specs can be used to conform data in macros 
> instead of using a custom parser. And Clojure's macro expansion will 
> automatically use specs, when present, to explain errors to users. This 
> should result in a greatly improved experience for users when errors occur. 
> > 
> > More robust software 
> > 
> > Clojure has always been about simplifying the development of robust 
> software. In all languages, dynamic or not, tests are essential to quality 
> - too many critical properties are not captured by common type systems. 
> spec has been designed from the ground up to directly support generative 
> testing via test.check https://github.com/clojure/test.check. When you 
> use spec you get generative tests for free. 
> > 
> > Taken together, I think the features of spec demonstrate the ongoing 
> advantages of a powerful dynamic language like Clojure for building robust 
> software - superior expressivity, instrumentation-enhanced REPL-driven 
> development, sophisticated testing and more flexible systems. I encourage 
> you to read the spec rationale and overview  http://clojure.org/about/spec. 
> Look for spec's inclusion in the next alpha release of Clojure, within a 
> day or so. 
> > 
> > Note that spec is still alpha, and some details are likely to change. 
> Feedback welcome. 
> > 
> > I hope you find spec useful and powerful! 
> > 
> > Rich 
> > 
> > 
> > -- 
> > 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" gro

Re: clojure.spec

[Georgi Danov]

I love the regexp approach, so decided to implement JSON parser in order to 
get acquainted with spec. The parser treats the input as char sequence.

The parser works, code is very readable, however performance is horrible — 
json file with 3.5k characters takes 350 seconds to process — 10 terms/sec. 

Here is the spec 
https://gist.github.com/gdanov/3a0440255f7f4df262ce16ce87351a04

On Monday, May 23, 2016 at 4:12:29 PM UTC+2, Rich Hickey wrote:
>
> Introducing clojure.spec 
>
> I'm happy to introduce today clojure.spec, a new core library and support 
> for data and function specifications in Clojure. 
>
> Better communication 
>
> Clojure is a dynamic language, and thus far we have relied on 
> documentation or external libraries to explain the use and behavior of 
> functions and libraries. But documentation is difficult to produce, is 
> frequently not maintained, cannot be automatically checked and varies 
> greatly in quality. Specs are expressive and precise. Including spec in 
> Clojure creates a lingua franca with which we can state how our programs 
> work and how to use them. 
>
> More leverage and power 
>
> A key advantage of specifications over documentation is the leverage they 
> provide. In particular, specs can be utilized by programs in ways that docs 
> cannot. Defining specs takes effort, and spec aims to maximize the return 
> you get from making that effort. spec gives you tools for leveraging specs 
> in documentation, validation, error reporting, destructuring, 
> instrumentation, test-data generation and generative testing. 
>
> Improved developer experience 
>
> Error messages from macros are a perennial challenge for new (and 
> experienced) users of Clojure. specs can be used to conform data in macros 
> instead of using a custom parser. And Clojure's macro expansion will 
> automatically use specs, when present, to explain errors to users. This 
> should result in a greatly improved experience for users when errors occur. 
>
> More robust software 
>
> Clojure has always been about simplifying the development of robust 
> software. In all languages, dynamic or not, tests are essential to quality 
> - too many critical properties are not captured by common type systems. 
> spec has been designed from the ground up to directly support generative 
> testing via test.check https://github.com/clojure/test.check. When you 
> use spec you get generative tests for free. 
>
> Taken together, I think the features of spec demonstrate the ongoing 
> advantages of a powerful dynamic language like Clojure for building robust 
> software - superior expressivity, instrumentation-enhanced REPL-driven 
> development, sophisticated testing and more flexible systems. I encourage 
> you to read the spec rationale and overview  http://clojure.org/about/spec. 
> Look for spec's inclusion in the next alpha release of Clojure, within a 
> day or so. 
>
> Note that spec is still alpha, and some details are likely to change. 
> Feedback welcome. 
>
> I hope you find spec useful and powerful! 
>
> Rich 
>
>

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

clojure.spec possible bug

[Georgi Danov]

I am trying to match sequences with fixed start and end but varying 
content. After lots of experiments I start to suspect there is either bug, 
or severe misunderstanding on my side.
Here is one example that behaves illogical to me

(sp/conform
 (sp/cat
   :start #{1}
   :mid (sp/+
  (sp/alt :b (sp/+ #{3}) :c (sp/+ #{9})))
   :end #{10})
 [1 3 3 3 9 9 3 10])
=> invalid ??

slight variation
(sp/conform
 (sp/cat
   :start #{1}
   :mid (sp/* ;; <<=
  (sp/alt :b (sp/+ #{3}) :c (sp/+ #{9})))
   :end #{10})
 [1 3 3 3 9 9 10]) ;; <<=
=> invalid ??



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

syntax of ^:arglists ?

[Georgi Danov]

Hi, 
 Is there some formal syntax used by ^:arglists? I want to express 
key-value pairs that are spliced, e.g. (some-fn :k1 value :k2 value)

Thanks,
Georgi

-- 
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: syntax of ^:arglists ?

[Georgi Danov]

I'd like the keys to be optional and destructuring does not support that.

On Mon, Dec 21, 2015, 3:48 PM Herwig Hochleitner 
wrote:

> I'd say, same as you would destructure them inline: [& {:keys [k1 k2]}]
>
> --
> 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/scSJ3cJg1Tw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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: safety and reusability of clojure.lang.RT, Compiler and co. in multi-classloader environment

[Georgi Danov]

Just for the record, there is one more relevant thread 
https://groups.google.com/d/topic/clojure/0AgUIiY8BQ8/discussion

On Tuesday, September 29, 2015 at 12:08:16 AM UTC+2, Georgi Danov wrote:
>
> Hi,
>  I am integrating clojure into java micro container. It has hierarchical 
> classloaders and can restart modules on the fly. It's almost REPL for Java 
> :).
>
>  I have clojure running inside it, but even after reading some of the RT 
> and Compiler classes source code I don't understand well enough how much 
> state is accumulated where (theadLocals, static class fields/Vars, 
> classloader, so on). Given that I don't want to have each module run 
> different clojure version, I would prefer to have the basic things loaded 
> once and shared.
>
>  I am also not sure what is shareable — I see the RT class has some static 
> init functionality that appears to be safe for sharing the same clojure.jar 
> classloader with all modules, but can't be sure.
>  
>  Would be glad if there is article I have missed that outlines this. 
>
> Thanks,
> Georgi
>

-- 
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: safety and reusability of clojure.lang.RT, Compiler and co. in multi-classloader environment

[Georgi Danov]

Toby, you might want to add one more thread leak — 
clojure.core.async.impl.timers/timeout-daemon, even though this is not 
official core lib


On Tuesday, September 29, 2015 at 4:14:48 AM UTC+2, Toby Crawley wrote:
>
> Note that that post is out of date - the runtime isolation pieces of 
> Immutant 1.x have been extracted into 
> https://github.com/projectodd/shimdandy (which Stephen mentioned). 
> Note that with shimdandy, shims *can't* share Clojure classes - each 
> shim will have its own copy. This is required if you want them to be 
> isolated from each other, or you want them to have different effective 
> classpaths. If you do give shimdandy a try, let me know if you have 
> any problems/questions. 
>
> - Toby 
>
> On Mon, Sep 28, 2015 at 6:57 PM, Gary Trakhman <gary.t...@gmail.com 
> > wrote: 
> > Here is another interesting read about how they solved it in immutant: 
> > http://immutant.org/news/2012/05/18/runtime-isolation/ 
> > 
> > On Mon, Sep 28, 2015 at 6:54 PM Stephen Gilardi <sque...@mac.com 
> > wrote: 
> >> 
> >> I haven’t seen discussion of isolating some of the RT data structures 
> >> while sharing others and the executable parts. 
> >> 
> >> In case you haven’t seen these, here are some references about isolated 
> >> Clojure runtimes that may be helpful: 
> >> 
> >> https://github.com/boot-clj/boot and its “pods” facility: 
> >> https://github.com/boot-clj/boot/tree/master/boot/pod which uses 
> >> https://github.com/projectodd/shimdandy . 
> >> 
> >> More on pods: https://github.com/boot-clj/boot/wiki/Pods 
> >> 
> >> A presentation about boot (including pods): 
> >> https://www.youtube.com/watch?v=TcnzB2tB-8Q . 
> >> 
> >> —Steve 
> >> 
> >> https://github.com/projectodd/shimdandy 
> >> 
> >> On Sep 28, 2015, at 6:08 PM, Georgi Danov <georgi...@gmail.com 
> > wrote: 
> >> 
> >> Hi, 
> >>  I am integrating clojure into java micro container. It has 
> hierarchical 
> >> classloaders and can restart modules on the fly. It's almost REPL for 
> Java 
> >> :). 
> >> 
> >>  I have clojure running inside it, but even after reading some of the 
> RT 
> >> and Compiler classes source code I don't understand well enough how 
> much 
> >> state is accumulated where (theadLocals, static class fields/Vars, 
> >> classloader, so on). Given that I don't want to have each module run 
> >> different clojure version, I would prefer to have the basic things 
> loaded 
> >> once and shared. 
> >> 
> >>  I am also not sure what is shareable — I see the RT class has some 
> static 
> >> init functionality that appears to be safe for sharing the same 
> clojure.jar 
> >> classloader with all modules, but can't be sure. 
> >> 
> >>  Would be glad if there is article I have missed that outlines this. 
> >> 
> >> Thanks, 
> >> Georgi 
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> >> Groups "Clojure" group. 
> >> To post to this group, send email to clo...@googlegroups.com 
>  
> >> Note that posts from new members are moderated - please be patient with 
> >> your first post. 
> >> To unsubscribe from this group, send email to 
> >> clojure+u...@googlegroups.com  
> >> For more options, visit this group at 
> >> http://groups.google.com/group/clojure?hl=en 
> >> --- 
> >> You received this message because you are subscribed to the Google 
> Groups 
> >> "Clojure" group. 
> >> To unsubscribe from this group and stop receiving emails from it, send 
> an 
> >> email to clojure+u...@googlegroups.com . 
> >> For more options, visit https://groups.google.com/d/optout. 
> >> 
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> >> Groups "Clojure" group. 
> >> To post to this group, send email to clo...@googlegroups.com 
>  
> >> Note that posts from new members are moderated - please be 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" grou

Re: safety and reusability of clojure.lang.RT, Compiler and co. in multi-classloader environment

[Georgi Danov]

Thanks, that's exactly what was needed.

On Tue, Sep 29, 2015, 4:14 AM Toby Crawley <t...@tcrawley.org> wrote:

> Note that that post is out of date - the runtime isolation pieces of
> Immutant 1.x have been extracted into
> https://github.com/projectodd/shimdandy (which Stephen mentioned).
> Note that with shimdandy, shims *can't* share Clojure classes - each
> shim will have its own copy. This is required if you want them to be
> isolated from each other, or you want them to have different effective
> classpaths. If you do give shimdandy a try, let me know if you have
> any problems/questions.
>
> - Toby
>
> On Mon, Sep 28, 2015 at 6:57 PM, Gary Trakhman <gary.trakh...@gmail.com>
> wrote:
> > Here is another interesting read about how they solved it in immutant:
> > http://immutant.org/news/2012/05/18/runtime-isolation/
> >
> > On Mon, Sep 28, 2015 at 6:54 PM Stephen Gilardi <squee...@mac.com>
> wrote:
> >>
> >> I haven’t seen discussion of isolating some of the RT data structures
> >> while sharing others and the executable parts.
> >>
> >> In case you haven’t seen these, here are some references about isolated
> >> Clojure runtimes that may be helpful:
> >>
> >> https://github.com/boot-clj/boot and its “pods” facility:
> >> https://github.com/boot-clj/boot/tree/master/boot/pod which uses
> >> https://github.com/projectodd/shimdandy .
> >>
> >> More on pods: https://github.com/boot-clj/boot/wiki/Pods
> >>
> >> A presentation about boot (including pods):
> >> https://www.youtube.com/watch?v=TcnzB2tB-8Q .
> >>
> >> —Steve
> >>
> >> https://github.com/projectodd/shimdandy
> >>
> >> On Sep 28, 2015, at 6:08 PM, Georgi Danov <georgi.da...@gmail.com>
> wrote:
> >>
> >> Hi,
> >>  I am integrating clojure into java micro container. It has hierarchical
> >> classloaders and can restart modules on the fly. It's almost REPL for
> Java
> >> :).
> >>
> >>  I have clojure running inside it, but even after reading some of the RT
> >> and Compiler classes source code I don't understand well enough how much
> >> state is accumulated where (theadLocals, static class fields/Vars,
> >> classloader, so on). Given that I don't want to have each module run
> >> different clojure version, I would prefer to have the basic things
> loaded
> >> once and shared.
> >>
> >>  I am also not sure what is shareable — I see the RT class has some
> static
> >> init functionality that appears to be safe for sharing the same
> clojure.jar
> >> classloader with all modules, but can't be sure.
> >>
> >>  Would be glad if there is article I have missed that outlines this.
> >>
> >> Thanks,
> >> Georgi
> >>
> >> --
> >> 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 http

safety and reusability of clojure.lang.RT, Compiler and co. in multi-classloader environment

[Georgi Danov]

Hi,
 I am integrating clojure into java micro container. It has hierarchical 
classloaders and can restart modules on the fly. It's almost REPL for Java 
:).

 I have clojure running inside it, but even after reading some of the RT 
and Compiler classes source code I don't understand well enough how much 
state is accumulated where (theadLocals, static class fields/Vars, 
classloader, so on). Given that I don't want to have each module run 
different clojure version, I would prefer to have the basic things loaded 
once and shared.

 I am also not sure what is shareable — I see the RT class has some static 
init functionality that appears to be safe for sharing the same clojure.jar 
classloader with all modules, but can't be sure.
 
 Would be glad if there is article I have missed that outlines this. 

Thanks,
Georgi

-- 
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 move an element within a vector?

[Georgi Danov]

How about filtering? 
BTW I don't see how it would help converting to array - what would be the 
solution then?

On Tuesday, August 25, 2015 at 7:06:30 PM UTC+2, Hussein B. wrote:

 Hi,

 For a vector like [A B C D E], how to remove an element to a specific 
 location? For example [A D B C E] ?

 I thought about converting the vector into array but I would feel bad if I 
 did that.

 What would be the idiomatic way to do that in Clojure?

 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
--- 
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: Anotating functions for pre-processing

[Georgi Danov]

thanks for all the useful replies. I underwent some pc migration so could 
not answer.

to all that suggest that I rethink the use case — I am fully aware of 
libraries like tools.trace and this approach (with-xyz ...). I am also 
aware of function composition and I enjoy it in many places, but not in 
function definitions. 
It is just that to me this looks way too invasive to my work habits. Yes, 
it's explicit, but to a java dev an annotation (or meta) is equally 
explicit while being less invasive. 

let me explain:
 - while I am developing I am used to quickly annotate methods so that they 
are instrumented to be traced, performance measured, so on
 - this means I am used to put an annotation, do some work, then comment 
it, and keep it around for when I revisit this code so that I uncomment it. 
If it's tracing with some extra config, this is worth it
 - in the final version, when I am releasing it, many, if not all of these 
annotations are gone
 - often some annotations remain in the code, but the facilities that 
process them are switched off on prod, while I switch them on locally on 
demand.
Guess using @Transactional in my example was not the best choice of 
annotation.

doing that with wrapping forms just feels too heavy. Secondary concern gets 
very prominent place and I don't think that's justified. 

How to mark certain blocks for some instrumenting seems to be matter of 
taste to big extent. However, see how the type hints are implemented as 
meta, and that's right and this is comparable to what I want.

As you properly notice the pre-processing approach might bite sometimes, 
but it's the same when using sprig, so that's something I am used to.

Thanks,
Georgi

On Friday, August 7, 2015 at 12:24:51 PM UTC+2, Shantanu Kumar wrote:

 Hi Georgi,

 Have you seen this thread?
 https://groups.google.com/forum/#!topic/clojure/0hKOFQXAwRc

 Shantanu

 On Wednesday, 5 August 2015 17:28:42 UTC+5:30, Georgi Danov wrote:

 Hi,
  I have had good 6 months of fun with Clojure and have big appreciation 
 for it's way of doing things. Coming from the Java/Spring world however, I 
 still have this nagging desire to be able to annotate functions and have 
 some preprocessor pick up these annotations and decorate the code 
 accordingly. Let me illustrate it:

 In Java + Spring
 @Transactional
 public void someFunction(){...}

 the Spring core container has excellent support for preprocessors to 
 instrument this function with some advice.

 -

 I wish I could do that in Clojure:

 (defn ^:transactional someFunction [...] ...)

 and then have somehow means to decorate someFunction (yes, I am aware 
 there is no container)

 I have read some blog posts (about dependency injection in the context of 
 testing clojure) that discuss *alter-var-root,* but that looks like very 
 brutal approach.

 What would be the advice on that? I am even happy to go with solution 
 that involves some micro-container spring-like approach.

 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.

Anotating functions for pre-processing

[Georgi Danov]

Hi,
 I have had good 6 months of fun with Clojure and have big appreciation for 
it's way of doing things. Coming from the Java/Spring world however, I 
still have this nagging desire to be able to annotate functions and have 
some preprocessor pick up these annotations and decorate the code 
accordingly. Let me illustrate it:

In Java + Spring
@Transactional
public void someFunction(){...}

the Spring core container has excellent support for preprocessors to 
instrument this function with some advice.

-

I wish I could do that in Clojure:

(defn ^:transactional someFunction [...] ...)

and then have somehow means to decorate someFunction (yes, I am aware there 
is no container)

I have read some blog posts (about dependency injection in the context of 
testing clojure) that discuss *alter-var-root,* but that looks like very 
brutal approach.

What would be the advice on that? I am even happy to go with solution that 
involves some micro-container spring-like approach.

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: Anotating functions for pre-processing

[Georgi Danov]

Thank you Steve

with the help of the robect-hooke library I got close:

(defn ^:test-meta t [a] (println a))
;;copy the metadata to the function object
(def tt (with-meta t (meta #'t)))

(defn adv1 [f a]
  (println advising f with meta (meta f))
  (f a))

(defn adv2 [f a]
  (println hey! f your meta is (meta f)) ;this is going to be nil as 
hooke provides it's own wrapper without copying the metadata
  (f a))

(add-hook #'tt #'adv1)
(add-hook #'tt #'adv2)

(tt a)


With little extra effort I will get what I want. Truth is the library uses 
alter-var-root under the hood. Well, guess that's some of the idiomatic 
Clojure way of life I will have to get used to.

On Wednesday, August 5, 2015 at 4:25:55 PM UTC+2, squeegee wrote:

 I wish I could do that in Clojure:

 (defn ^:transactional someFunction [...] ...)

 and then have somehow means to decorate someFunction (yes, I am aware 
 there is no container)


 The code you proposed does have an effect on the someFunction var (but not 
 the function it ends up bound to). That might be enough for you to 
 accomplish what you’re after.

 user= (defn ^:transactional someFunction [x] (prn x))
 #'user/some-function
 user= (meta *#'some-function*)
 {:ns #Namespace user, :name someFunction, :file ..., *:transactional 
 true*, :column 1, :line 1, :arglists ([x])}

 —Steve



-- 
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: separation of concerns w/o encapsulation

[Georgi Danov]

No tool or technology beats the combination of:
a) component/responsibility blueprint
b) discipline in communicating, following and adapting it

encapsulation can be a nice safety net once you have the things above, but 
it would never be a solution to the problem. just a convenience.

coding and designing defensively because you are concerned about your 
teammates is big waste of time. if this is the reality (in the enterprise 
it's the norm) guess clojure is not the best tech for that organization.

On Friday, May 8, 2015 at 6:29:50 PM UTC+2, Brian Craft wrote:

 Talk on the list about encapsulation usually comes back to some variation 
 of you don't need it when you have immutable data structures. But in the 
 long term I'm finding the problem of working w/o encapsulation is not the 
 danger of data being mutated under you. Rather, it's the danger of all the 
 module boundaries blurring over time, leading to the big ball of mud: a 
 very fragile code base where everything depends on everything else.

 E.g. if you model your application with a plain data structure which you 
 pass around to different modules, each concerned with a small part of that 
 data structure, the tendency over time is for every module to become 
 concerned with every part of that data structure.  Then you have no 
 separation, nothing is reusable, and the code is very fragile.

 How do you avoid this, practically? In OO it would be enforced with 
 encapsulation, so the next developer (which might be me, six months later) 
 trying to fix a bug, or add a feature, knows Oh, I shouldn't peek in here: 
 this module isn't supposed to depend on that piece of data.


-- 
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] Re: ANN: ClojureScript 0.0-3196, Conditional Reading, REPLs, and Code Motion

[Georgi Danov]

thanks!

On Saturday, April 11, 2015 at 5:15:06 PM UTC+2, David Nolen wrote:
 Yep, the clojure.main option is the one you want.
 
 
 David
 
 
 On Sat, Apr 11, 2015 at 10:45 AM, Georgi Danov georgi...@gmail.com wrote:
 I did read it very carefully several times, but kept trying to use it via 
 remote connection (headbang).
 
 
 
 I got it running using the config use clojure.main in normal JVM process, 
 is this how it's supposed to be?
 
 
 
 
 
 On Saturday, April 11, 2015 at 4:06:47 PM UTC+2, David Nolen wrote:
 
  I was able to connect IntelliJ to a REPL because Cursive can now connect to 
  a ClojureScript REPL started in the usual way. There is no special setup, 
  make sure you've taken the time to read the new ClojureScript Quick Start.
 
 
 
 
 
  HTH,
 
  David
 
 
 
 
 
  On Sat, Apr 11, 2015 at 5:06 AM, Georgi Danov georgi...@gmail.com wrote:
 
 
 
  Hi,
 
   I keep having troubles running repl with piggieback and once again I see 
  in the changelog this was improved. I also saw the screenshot in your last 
  tweet which clearly shows intellij can connect.
 
 
 
   Can you please share your project set-up? Some sort of sample project that 
  has that up  running would be of great value.
 
 
 
   Even when I follow the tutorials I end up in weird exceptions, last one 
  being
 
 
 
  No implementation of method: :-evaluate of protocol: 
  #'cljs.repl/IJavaScriptEnv found for class: clojure.lang.PersistentArrayMap
 
      at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:554)
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  --
 
 
 
  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 clojurescrip...@googlegroups.com.
 
 
 
  To post to this group, send email to clojur...@googlegroups.com.
 
 
 
 
 
  Visit this group at http://groups.google.com/group/clojurescript.
 
 
 
 --
 
 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 clojurescrip...@googlegroups.com.
 
 To post to this group, send email to clojur...@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/d/optout.

Re: ANN: ClojureScript 0.0-3196, Conditional Reading, REPLs, and Code Motion

[Georgi Danov]

Hi,
 I keep having troubles running repl with piggieback and once again I see 
in the changelog this was improved. I also saw the screenshot in your last 
tweet which clearly shows intellij can connect.

 Can you please share your project set-up? Some sort of sample project that 
has that up  running would be of great value.

 Even when I follow the tutorials I end up in weird exceptions, last one 
being 

No implementation of method: :-evaluate of protocol: 
#'cljs.repl/IJavaScriptEnv found for class: clojure.lang.PersistentArrayMap
at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:554)

-- 
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] Re: ANN: ClojureScript 0.0-3196, Conditional Reading, REPLs, and Code Motion

[Georgi Danov]

I did read it very carefully several times, but kept trying to use it via 
remote connection (headbang). 

I got it running using the config use clojure.main in normal JVM process, is 
this how it's supposed to be?


On Saturday, April 11, 2015 at 4:06:47 PM UTC+2, David Nolen wrote:
 I was able to connect IntelliJ to a REPL because Cursive can now connect to a 
 ClojureScript REPL started in the usual way. There is no special setup, make 
 sure you've taken the time to read the new ClojureScript Quick Start.
 
 
 HTH,
 David
 
 
 On Sat, Apr 11, 2015 at 5:06 AM, Georgi Danov georgi...@gmail.com wrote:
 
 Hi,
  I keep having troubles running repl with piggieback and once again I see in 
 the changelog this was improved. I also saw the screenshot in your last tweet 
 which clearly shows intellij can connect.
 
  Can you please share your project set-up? Some sort of sample project that 
 has that up  running would be of great value.
 
  Even when I follow the tutorials I end up in weird exceptions, last one 
 being 
 
 No implementation of method: :-evaluate of protocol: 
 #'cljs.repl/IJavaScriptEnv found for class: clojure.lang.PersistentArrayMap
     at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:554)
 
 
 
 
 
 
 
 
 -- 
 
 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 clojurescrip...@googlegroups.com.
 
 To post to this group, send email to clojur...@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/d/optout.