Re: Reviewers needed for new Clojure book!

[Akhil Wali]

Yes, "second Clojure book" is exactly what this book aims to be.

Thanks for the overwhelming response, guys!

On Thursday, August 27, 2015 at 12:27:56 PM UTC+5:30, Nathan Smutz wrote:
>
>  It sounds like you're aiming for a good "second Clojure book."

-- 
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] Grenada 1.0.0-rc.2

[Chris Zheng]

Hey Francesco,

crossclj is a great project. I use it a lot and it’s actually the one tool that 
keeps references up to date. However, it’d be great if the source code is open 
sourced.

Chris.

> On 26 Aug 2015, at 12:43 pm, Francesco Bellomi  
> wrote:
> 
> Hi Chris,
> 
> CrossClj is similar in spirit to Hoogle, although it is more focused on 
> cross-project browsing
> 
> https://crossclj.info/ 
> 
> However, you cannot search by type signature, being Clojure not statically 
> typed ;-)
> 
> Francesco
> 
> 

-- 
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: top-level lets or private globals

[pmf]

On Thursday, August 27, 2015 at 1:15:14 AM UTC+2, red...@gmail.com wrote:
>
> I have found the access control stuff in Java to be an incredible pain. 
> When attempting to compose a larger system from the parts. Generally 
> everything is compulsively private, so if an api doesn't exactly expose 
> what you want, you either have to write what you want completely from 
> scratch, or use reflection to get a the bits you want to compose in to 
> what you want.
>

Do you want to program against an API or against a Big Ball of Mud? There 
is no such thing as an open API; either you accept the constraints imposed 
by the API (and thus can rely on the contractually guaranteed behavior) or 
you are effectively creating a runtime fork of the library exposed by the 
API with undefined semantics.

In practice, you are of course right that more often than not, Java APIs 
are badly designed. For a  really, really nice book about the issues of 
balancing usability, extensibility and maintainability of Java APIs 
(including a discussion of some intricate issues of source compatibility 
vs. binary compatibility that I have not seen discussed anywhere else) is 
"Practical API Design" by Jaroslav Tulach.

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

Homoiconicity in Clojure - the broken promise

[Olek]

Hi!

Today I fall into:

 java.lang.RuntimeException: java.lang.ClassFormatError: Invalid method 
Code length 88118 in class file xxx$eval304 (xxx.clj:274) (xxx.clj:3)

problem.

The reason is that I tried to use data as code and just execute the slurped 
AST in order to produce another form of code (I'm converting the code from 
one language to another).
Is there any way to switch Clojure to interpreted mode instead of compiling 
the data structure form? The structure what causes the headache are arrays 
initializers.
I would like to keep the code simple since the language should solve the 
problem for me, not me for the case of stupid 64kb method limit.

Thanks in advance,
Olek

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

My Zipper isn't deleting what I thought is going to delete

[Hussein B.]

Hi,

I'm trying to remove an element from nested data structure (nesting in 
unknown, so I'm trying to come up with a generic solution:

 (def z [
  {"a" {"b" 1 "c" 2}
   "children" [{"a" {"b" 3 "c" 4}
"children" []}]}
  {"a" {"b" 5 "c" 6}
   "children" []}
  {"a" {"b" 7 "c" 8}
   "children" [{"a" {"b" 9 "c" 10}
"children" []}
   {"a" {"b" 11 "c" 12}
"children" [{"a" {"b" 13 "c" 14} "children" []} {"a" 
{"b" 15 "c" 16} "children" []}]}]}])




(def loz (z/zipper #(get % "children") #(get % "children") (fn [_ x ] x) 
{"children" z}))



(defn to-change? [loc]
 (if (= 11 (get-in (z/node loc) ["a" "b"]))
 true
 false))


(loop [loc loz]
(if (z/end? loc)
  (z/root loc)
  (recur (z/next
  (cond (to-change? loc)
(modify loc)
:else loc)


That gives a very wrong output:

({"a" {"b" 1, "c" 2}, "children" [{"a" {"b" 3, "c" 4}, "children" []}]} {"a" 
{"b" 5, "c" 6}, "children" []} ({"a" {"b" 9, "c" 10}, "children" []}))



Parent {"a" {"b" 7 "c" 8} is getting deleted which is wrong.

What I'm doing wrong?

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: My Zipper isn't deleting what I thought is going to delete

[Hussein B.]

The modify function

(defn modify [loc]
 (-> loc z/remove))


On Thursday, August 27, 2015 at 11:58:31 AM UTC+2, Hussein B. wrote:
>
> Hi,
>
> I'm trying to remove an element from nested data structure (nesting in 
> unknown, so I'm trying to come up with a generic solution:
>
>  (def z [
>   {"a" {"b" 1 "c" 2}
>"children" [{"a" {"b" 3 "c" 4}
> "children" []}]}
>   {"a" {"b" 5 "c" 6}
>"children" []}
>   {"a" {"b" 7 "c" 8}
>"children" [{"a" {"b" 9 "c" 10}
> "children" []}
>{"a" {"b" 11 "c" 12}
> "children" [{"a" {"b" 13 "c" 14} "children" []} {
> "a" {"b" 15 "c" 16} "children" []}]}]}])
>
>
>
>
> (def loz (z/zipper #(get % "children") #(get % "children") (fn [_ x ] x) 
> {"children" z}))
>
>
>
> (defn to-change? [loc]
>  (if (= 11 (get-in (z/node loc) ["a" "b"]))
>  true
>  false))
>
>
> (loop [loc loz]
> (if (z/end? loc)
>   (z/root loc)
>   (recur (z/next
>   (cond (to-change? loc)
> (modify loc)
> :else loc)
>
>
> That gives a very wrong output:
>
> ({"a" {"b" 1, "c" 2}, "children" [{"a" {"b" 3, "c" 4}, "children" []}]} {
> "a" {"b" 5, "c" 6}, "children" []} ({"a" {"b" 9, "c" 10}, "children" []}))
>
>
>
> Parent {"a" {"b" 7 "c" 8} is getting deleted which is wrong.
>
> What I'm doing wrong?
>
> 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: My Zipper isn't deleting what I thought is going to delete

[Moe Aboulkheir]

Hussein,

Making this change to the zipper definition:

(z/zipper #(get % "children") #(get % "children") (fn [p c] (assoc p
"children" c)) {"children" z})

looks like it'll do the right thing here.

Take care,
Moe

On Thu, Aug 27, 2015 at 11:03 AM, Hussein B.  wrote:
> The modify function
>
> (defn modify [loc]
>  (-> loc z/remove))
>
>
> On Thursday, August 27, 2015 at 11:58:31 AM UTC+2, Hussein B. wrote:
>>
>> Hi,
>>
>> I'm trying to remove an element from nested data structure (nesting in
>> unknown, so I'm trying to come up with a generic solution:
>>
>>  (def z [
>>   {"a" {"b" 1 "c" 2}
>>"children" [{"a" {"b" 3 "c" 4}
>> "children" []}]}
>>   {"a" {"b" 5 "c" 6}
>>"children" []}
>>   {"a" {"b" 7 "c" 8}
>>"children" [{"a" {"b" 9 "c" 10}
>> "children" []}
>>{"a" {"b" 11 "c" 12}
>> "children" [{"a" {"b" 13 "c" 14} "children" []}
>> {"a" {"b" 15 "c" 16} "children" []}]}]}])
>>
>>
>>
>>
>> (def loz (z/zipper #(get % "children") #(get % "children") (fn [_ x ] x)
>> {"children" z}))
>>
>>
>>
>> (defn to-change? [loc]
>>  (if (= 11 (get-in (z/node loc) ["a" "b"]))
>>  true
>>  false))
>>
>>
>> (loop [loc loz]
>> (if (z/end? loc)
>>   (z/root loc)
>>   (recur (z/next
>>   (cond (to-change? loc)
>> (modify loc)
>> :else loc)
>>
>>
>> That gives a very wrong output:
>>
>> ({"a" {"b" 1, "c" 2}, "children" [{"a" {"b" 3, "c" 4}, "children" []}]}
>> {"a" {"b" 5, "c" 6}, "children" []} ({"a" {"b" 9, "c" 10}, "children" []}))
>>
>>
>>
>> Parent {"a" {"b" 7 "c" 8} is getting deleted which is wrong.
>>
>> What I'm doing wrong?
>>
>> 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.

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

Manifold questions: Creating sinks/sources

[Atamert Ölçgen]

Hi,

AFAIK the only way to create (just) a source (or sink) is:

(def my-source (s/source-only (s/stream ...)))

This results in creating a stream and then wrapping it with a SourceProxy.
We don't keep a reference to the stream and the SourceProxy doesn't allow
taking.

But if I'm not missing something since SourceProxy keeps a reference of the
original stream, there is a sink nobody is using there.

If I create a sink separately and connect my-source to it, now
my-source would be connected to two sinks.

My questions are:

1. Is there another method for creating only sinks or sources?
2. Should the extra/unused source/sink I mentioned above cause concern?

PS: I'm not talking about a scenario where we're creating thousands streams
and connecting them all like there's no tomorrow.


-- 
Kind Regards,
Atamert Ölçgen

◻◼◻
◻◻◼
◼◼◼

www.muhuk.com

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

Re: My Zipper isn't deleting what I thought is going to delete

[Hussein B.]

Thanks a lot Moe for your help. I always appreciate your patience and 
skills.

Would you explain why your zipper works in this case?

Thanks again.

On Thursday, August 27, 2015 at 12:11:14 PM UTC+2, Moe Aboulkheir wrote:
>
> Hussein, 
>
> Making this change to the zipper definition: 
>
> (z/zipper #(get % "children") #(get % "children") (fn [p c] (assoc p 
> "children" c)) {"children" z}) 
>
> looks like it'll do the right thing here. 
>
> Take care, 
> Moe 
>
> On Thu, Aug 27, 2015 at 11:03 AM, Hussein B.  > wrote: 
> > The modify function 
> > 
> > (defn modify [loc] 
> >  (-> loc z/remove)) 
> > 
> > 
> > On Thursday, August 27, 2015 at 11:58:31 AM UTC+2, Hussein B. wrote: 
> >> 
> >> Hi, 
> >> 
> >> I'm trying to remove an element from nested data structure (nesting in 
> >> unknown, so I'm trying to come up with a generic solution: 
> >> 
> >>  (def z [ 
> >>   {"a" {"b" 1 "c" 2} 
> >>"children" [{"a" {"b" 3 "c" 4} 
> >> "children" []}]} 
> >>   {"a" {"b" 5 "c" 6} 
> >>"children" []} 
> >>   {"a" {"b" 7 "c" 8} 
> >>"children" [{"a" {"b" 9 "c" 10} 
> >> "children" []} 
> >>{"a" {"b" 11 "c" 12} 
> >> "children" [{"a" {"b" 13 "c" 14} "children" []} 
> >> {"a" {"b" 15 "c" 16} "children" []}]}]}]) 
> >> 
> >> 
> >> 
> >> 
> >> (def loz (z/zipper #(get % "children") #(get % "children") (fn [_ x ] 
> x) 
> >> {"children" z})) 
> >> 
> >> 
> >> 
> >> (defn to-change? [loc] 
> >>  (if (= 11 (get-in (z/node loc) ["a" "b"])) 
> >>  true 
> >>  false)) 
> >> 
> >> 
> >> (loop [loc loz] 
> >> (if (z/end? loc) 
> >>   (z/root loc) 
> >>   (recur (z/next 
> >>   (cond (to-change? loc) 
> >> (modify loc) 
> >> :else loc) 
> >> 
> >> 
> >> That gives a very wrong output: 
> >> 
> >> ({"a" {"b" 1, "c" 2}, "children" [{"a" {"b" 3, "c" 4}, "children" []}]} 
> >> {"a" {"b" 5, "c" 6}, "children" []} ({"a" {"b" 9, "c" 10}, "children" 
> []})) 
> >> 
> >> 
> >> 
> >> Parent {"a" {"b" 7 "c" 8} is getting deleted which is wrong. 
> >> 
> >> What I'm doing wrong? 
> >> 
> >> 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 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.

Re: Homoiconicity in Clojure - the broken promise

[Phillip Lord]

Don't compile it, use the EDN reader instead.

You can't do functions and that sort of thing, but the data structures
will work.

Phil

Olek  writes:

> Hi!
>
> Today I fall into:
>
>  java.lang.RuntimeException: java.lang.ClassFormatError: Invalid method 
> Code length 88118 in class file xxx$eval304 (xxx.clj:274) (xxx.clj:3)
>
> problem.
>
> The reason is that I tried to use data as code and just execute the slurped 
> AST in order to produce another form of code (I'm converting the code from 
> one language to another).
> Is there any way to switch Clojure to interpreted mode instead of compiling 
> the data structure form? The structure what causes the headache are arrays 
> initializers.
> I would like to keep the code simple since the language should solve the 
> problem for me, not me for the case of stupid 64kb method limit.
>
> Thanks in advance,
> Olek

-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
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: Homoiconicity in Clojure - the broken promise

[James Reeves]

On 27 August 2015 at 10:31, Olek  wrote:
>
> Today I fall into:
>
>  java.lang.RuntimeException: java.lang.ClassFormatError: Invalid method
> Code length 88118 in class file xxx$eval304 (xxx.clj:274) (xxx.clj:3)
>
> problem.
>
> The reason is that I tried to use data as code and just execute the
> slurped AST in order to produce another form of code (I'm converting the
> code from one language to another).
> Is there any way to switch Clojure to interpreted mode instead of
> compiling the data structure form? The structure what causes the headache
> are arrays initializers.
> I would like to keep the code simple since the language should solve the
> problem for me, not me for the case of stupid 64kb method limit.
>

No, Clojure doesn't have an "interpreted mode" that would get around the
64kb method limit. But why do you need to eval in the first place if you're
just converting code from one language to another?

- James

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

Re: Homoiconicity in Clojure - the broken promise

[Olek]

For the sake of simplicity. I've just define functions or macros which can 
appear in the data structure and simply call eval on that structure. The 
defined functions and macros has side effect which is println to the binded 
output stream.

The example structure looks like this:

(Stmt_If {
:cond (Expr_FuncCall {
:name (Name {
:parts [
"preg_match"
]})
:args [
(Arg {
:value (Scalar_String {
:value 
"%2F%5E%5B0-9a-fA-F%5D%7B6%7D%24%2F"})
:byRef false
:unpack false})
(Arg {
:value (Expr_Variable {
:name "col"})
:byRef false
:unpack false})
]})
:stmts [
(Stmt_Return {
:expr (Expr_Variable {
:name "col"})})
]
:elseifs [
]
:else nil})



On Thursday, 27 August 2015 16:16:17 UTC+2, James Reeves wrote:
>
> On 27 August 2015 at 10:31, Olek > 
> wrote:
>>
>> Today I fall into:
>>
>>  java.lang.RuntimeException: java.lang.ClassFormatError: Invalid method 
>> Code length 88118 in class file xxx$eval304 (xxx.clj:274) (xxx.clj:3)
>>
>> problem.
>>
>> The reason is that I tried to use data as code and just execute the 
>> slurped AST in order to produce another form of code (I'm converting the 
>> code from one language to another).
>> Is there any way to switch Clojure to interpreted mode instead of 
>> compiling the data structure form? The structure what causes the headache 
>> are arrays initializers.
>> I would like to keep the code simple since the language should solve the 
>> problem for me, not me for the case of stupid 64kb method limit.
>>
>
> No, Clojure doesn't have an "interpreted mode" that would get around the 
> 64kb method limit. But why do you need to eval in the first place if you're 
> just converting code from one language to another?
>
> - James
>

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

Deploying Lein Template to Clojars

[Matthew Molloy]

According to the current documentation I create a leiningen plugin using 
the pattern

(defproject your-template-name/lein-template "0.1.0-SNAPSHOT"

however the clojars tutorial indicates that projects should be named as 

(defproject org.clojars.whamtet/too-hot "1.0.0"

where whamtet is my clojars username.  How then do I deploy a leiningen 
template to clojars?

-- 
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: My Zipper isn't deleting what I thought is going to delete

[Moe Aboulkheir]

Hussein,

The previous example (from your other thread) worked, as it happened
to involve removing the parents of nodes which match the predicate -
the make-node function I'd given you worked more or less by accident
in that one specific case, but not here.  Apologies if you lost time
due to my mistake.

To explain what's happening, let's look at the two interesting
functions we pass to clojure.zip/zipper - "children", which is
required to return a seq of a branch's children, and "make-node",
described as "a fn that, given an existing node and a seq of children,
returns a new branch node with the supplied children."   When you do
what amounts to (z/remove {a {b 11 c 12}}), clojure.zip needs some way
to accomplish that, without having a perfect understanding of exactly
how your data is structured.  When combined with the navigation
functions exposed by the library, children & make-node are enough to
get us there.

In this instance, calling z/remove on a grandchild of the root
triggers calls to make-node in order to reconstruct the parent ({b 7 c
8}) of the removed node with a new child seq not containing the node.
And, in turn, needs to be called on the removed node's grandparent
(the root - {children []}) -to reconstruct it with a node seq
containing the modified {b 7 c 8} node from the previous step.

The correct make-node implementation (assoc p "children" c) attaches
the sequence of children to the given parent node, in the place we
expect it.

Take care,
Moe

On Thu, Aug 27, 2015 at 1:59 PM, Hussein B.  wrote:
> Thanks a lot Moe for your help. I always appreciate your patience and
> skills.
>
> Would you explain why your zipper works in this case?
>
> Thanks again.
>
> On Thursday, August 27, 2015 at 12:11:14 PM UTC+2, Moe Aboulkheir wrote:
>>
>> Hussein,
>>
>> Making this change to the zipper definition:
>>
>> (z/zipper #(get % "children") #(get % "children") (fn [p c] (assoc p
>> "children" c)) {"children" z})
>>
>> looks like it'll do the right thing here.
>>
>> Take care,
>> Moe
>>
>> On Thu, Aug 27, 2015 at 11:03 AM, Hussein B.  wrote:
>> > The modify function
>> >
>> > (defn modify [loc]
>> >  (-> loc z/remove))
>> >
>> >
>> > On Thursday, August 27, 2015 at 11:58:31 AM UTC+2, Hussein B. wrote:
>> >>
>> >> Hi,
>> >>
>> >> I'm trying to remove an element from nested data structure (nesting in
>> >> unknown, so I'm trying to come up with a generic solution:
>> >>
>> >>  (def z [
>> >>   {"a" {"b" 1 "c" 2}
>> >>"children" [{"a" {"b" 3 "c" 4}
>> >> "children" []}]}
>> >>   {"a" {"b" 5 "c" 6}
>> >>"children" []}
>> >>   {"a" {"b" 7 "c" 8}
>> >>"children" [{"a" {"b" 9 "c" 10}
>> >> "children" []}
>> >>{"a" {"b" 11 "c" 12}
>> >> "children" [{"a" {"b" 13 "c" 14} "children" []}
>> >> {"a" {"b" 15 "c" 16} "children" []}]}]}])
>> >>
>> >>
>> >>
>> >>
>> >> (def loz (z/zipper #(get % "children") #(get % "children") (fn [_ x ]
>> >> x)
>> >> {"children" z}))
>> >>
>> >>
>> >>
>> >> (defn to-change? [loc]
>> >>  (if (= 11 (get-in (z/node loc) ["a" "b"]))
>> >>  true
>> >>  false))
>> >>
>> >>
>> >> (loop [loc loz]
>> >> (if (z/end? loc)
>> >>   (z/root loc)
>> >>   (recur (z/next
>> >>   (cond (to-change? loc)
>> >> (modify loc)
>> >> :else loc)
>> >>
>> >>
>> >> That gives a very wrong output:
>> >>
>> >> ({"a" {"b" 1, "c" 2}, "children" [{"a" {"b" 3, "c" 4}, "children" []}]}
>> >> {"a" {"b" 5, "c" 6}, "children" []} ({"a" {"b" 9, "c" 10}, "children"
>> >> []}))
>> >>
>> >>
>> >>
>> >> Parent {"a" {"b" 7 "c" 8} is getting deleted which is wrong.
>> >>
>> >> What I'm doing wrong?
>> >>
>> >> 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 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

Re: [ANN] io.aviso/rook 0.1.36

[Howard Lewis Ship]

Rook is considerably more opinionated than Liberator and is based on
extending the Ring metaphor: building up the functionality of the web
application by introducing layers of middleware.

The explicit goal is a mapping of URIs to endpoint functions within a
namespace, and the introduction of customized-per-endpoint middleware to
facilitate it.  It also adapts idea from the Inversion-of-Control world in
terms of what argument values are passed to the endpoint function.

Liberator is a bit more compliant and flexible in certain areas, but that
comes at some cost. For some applications, Liberator's approach is likely
better, but for most cases (such as building a REST API to support a rich
client web application), I feel that most people will be more productive in
Rook.

For example, Rook somewhat "normalizes" the submission; you can define a
schema for the incoming request, and Rook can validate that the submitted
request body matches the request (and even leverage some of Prismatic
Schema's coercions) BUT it would be difficult to have one schema for
application/json and a different schema for application/edn.

In practice, we use schemas like {:user_id s/UUID, s/Any s/Any} if we want
to make life simpler for JSON clients.

For the kinds of application I've been writing, I feel I am writing less
code in Rook that I would in Liberator ... but I have not used Liberator,
just attended a conj session on it, and skimmed the docs (and worked quite
a bit in Bishop, which predates Liberator and - if you notice the pun -
inspired Rook).

On Mon, Aug 24, 2015 at 8:38 PM, Daniel Compton <
daniel.compton.li...@gmail.com> wrote:

> Hi Howard
>
> Thanks for sharing this. Can you comment briefly on how this compares and
> contrasts to Liberator? I know they're not exactly the same, but they're
> definitely in the same neighbourhood.
>
> On Tue, Aug 25, 2015 at 3:31 AM Howard Lewis Ship 
> wrote:
>
>> Rook is a set of middleware and handlers to enable metadata-based routing
>> for Ring web applications.
>>
>> The intention is to expose a Clojure namespace as a web service resource;
>> there’s a default mapping of HTTP verbs and paths to function names; these
>> can be extended or overridden by metadata on the functions in the namespace.
>>
>> The end result is that a compliant web service resource can be created in
>> very little code.
>>
>> Rook also supports Swagger 2.0: a detailed JSON description of your web
>> service is generated directly from the functions and metadata.
>>
>> Recent changes:
>>
>> * Described more of the APIs using Prismatic Schema
>> * Added ability to reuse the argument resolution logic outside of
>> endpoint functions
>> * Many improvements to the Swagger 2.0 description support
>>
>> https://github.com/AvisoNovate/rook
>>
>> --
>> Howard M. Lewis Ship
>>
>> Looking for Clojure engagements: coding, architecture, mentoring & more!
>>
>> Creator of Apache Tapestry
>>
>> (971) 678-5210
>> http://howardlewisship.com
>> @hlship
>>
>> --
>> 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.
>>
> --
> --
> Daniel
>
> --
> 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.
>



-- 
Howard M. Lewis Ship

Starting with WalMart Labs on Sep 28th!

Creator of Apache Tapestry

(971) 678-5210
http://howardlewisship.com
@hlship

-- 
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://group

Re: [ANN] io.aviso/rook 0.1.36

[Howard Lewis Ship]

That's misleading.  In the case of convention function names, (index, show,
create), there's default :route metadata that is used automatically ... the
docstrings are merely supplying a reminder.

This is described in the "Getting Started" page:
https://portal.aviso.io/#/document/open-source/rook/Current/getting-started.html

If you look at the increment endpoint function, which is not a convention
name, it has explicit :route metadata.

I'll update the example to make this much more clear.


On Tue, Aug 25, 2015 at 7:43 AM, Atamert Ölçgen  wrote:

> Hi Howard,
>
> In the example application it seems the routing information is encoded in
> the beginning of the docstring and not the actual metadata. Is there an
> option to put this info in the metadata of the var?
>
> On Mon, Aug 24, 2015 at 6:31 PM, Howard Lewis Ship 
> wrote:
>
>> Rook is a set of middleware and handlers to enable metadata-based routing
>> for Ring web applications.
>>
>> The intention is to expose a Clojure namespace as a web service resource;
>> there’s a default mapping of HTTP verbs and paths to function names; these
>> can be extended or overridden by metadata on the functions in the namespace.
>>
>> The end result is that a compliant web service resource can be created in
>> very little code.
>>
>> Rook also supports Swagger 2.0: a detailed JSON description of your web
>> service is generated directly from the functions and metadata.
>>
>> Recent changes:
>>
>> * Described more of the APIs using Prismatic Schema
>> * Added ability to reuse the argument resolution logic outside of
>> endpoint functions
>> * Many improvements to the Swagger 2.0 description support
>>
>> https://github.com/AvisoNovate/rook
>>
>> --
>> Howard M. Lewis Ship
>>
>> Looking for Clojure engagements: coding, architecture, mentoring & more!
>>
>> Creator of Apache Tapestry
>>
>> (971) 678-5210
>> http://howardlewisship.com
>> @hlship
>>
>> --
>> 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.
>>
>
>
>
> --
> Kind Regards,
> Atamert Ölçgen
>
> ◻◼◻
> ◻◻◼
> ◼◼◼
>
> www.muhuk.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Howard M. Lewis Ship

Starting with WalMart Labs on Sep 28th!

Creator of Apache Tapestry

(971) 678-5210
http://howardlewisship.com
@hlship

-- 
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] io.aviso/rook 0.1.36

[Atamert Ölçgen]

Got it, thanks.

I think you still need to prepend ^'s to the metadata.

On Thu, Aug 27, 2015 at 8:40 PM, Howard Lewis Ship  wrote:

> That's misleading.  In the case of convention function names, (index,
> show, create), there's default :route metadata that is used automatically
> ... the docstrings are merely supplying a reminder.
>
> This is described in the "Getting Started" page:
> https://portal.aviso.io/#/document/open-source/rook/Current/getting-started.html
>
> If you look at the increment endpoint function, which is not a convention
> name, it has explicit :route metadata.
>
> I'll update the example to make this much more clear.
>
>
> On Tue, Aug 25, 2015 at 7:43 AM, Atamert Ölçgen  wrote:
>
>> Hi Howard,
>>
>> In the example application it seems the routing information is encoded in
>> the beginning of the docstring and not the actual metadata. Is there an
>> option to put this info in the metadata of the var?
>>
>> On Mon, Aug 24, 2015 at 6:31 PM, Howard Lewis Ship 
>> wrote:
>>
>>> Rook is a set of middleware and handlers to enable metadata-based
>>> routing for Ring web applications.
>>>
>>> The intention is to expose a Clojure namespace as a web service
>>> resource; there’s a default mapping of HTTP verbs and paths to function
>>> names; these can be extended or overridden by metadata on the functions in
>>> the namespace.
>>>
>>> The end result is that a compliant web service resource can be created
>>> in very little code.
>>>
>>> Rook also supports Swagger 2.0: a detailed JSON description of your web
>>> service is generated directly from the functions and metadata.
>>>
>>> Recent changes:
>>>
>>> * Described more of the APIs using Prismatic Schema
>>> * Added ability to reuse the argument resolution logic outside of
>>> endpoint functions
>>> * Many improvements to the Swagger 2.0 description support
>>>
>>> https://github.com/AvisoNovate/rook
>>>
>>> --
>>> Howard M. Lewis Ship
>>>
>>> Looking for Clojure engagements: coding, architecture, mentoring & more!
>>>
>>> Creator of Apache Tapestry
>>>
>>> (971) 678-5210
>>> http://howardlewisship.com
>>> @hlship
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> Kind Regards,
>> Atamert Ölçgen
>>
>> ◻◼◻
>> ◻◻◼
>> ◼◼◼
>>
>> www.muhuk.com
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Starting with WalMart Labs on Sep 28th!
>
> Creator of Apache Tapestry
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
>
> --
> 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.
>



-- 
Kind Regards,
Atamert Ölçgen

◻◼◻
◻◻◼
◼◼◼

www.muhuk.com

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

[ANN] io.aviso/pretty 0.1.19

[Howard Lewis Ship]

Pretty is a library for (among other things) printing Clojure stack traces,
prettily.

Changes in 0.1.19:

Print a blank line before the exception output, when reporting a
clojure.test exception.
Previously, the first line was was on the same line as the "actual:" label,
which
interfered with columnar output.

The built in stack frame filtering rules are now better documented, and
speclj.* is now included as :terminate.

You may now add pretty to your Leiningen :plugins list; it will
automatically add the Pretty nREPL
middleware.

Pretty is licensed with the Apache Software License 2.0.

https://github.com/AvisoNovate/pretty


-- 
Howard M. Lewis Ship

Starting with WalMart Labs on Sep 28th!

Creator of Apache Tapestry

(971) 678-5210
http://howardlewisship.com
@hlship

-- 
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] io.aviso/rook 0.1.36

[Howard Lewis Ship]

(defn ^:foo bar []) is equivalent to
(defn ^{:foo true} bar []) is equvalent to
(defn bar {:foo true} [])


In the first two cases, the metadata is actually applied to the bar symbol
(by the Clojure reader) and then copied over to the #'bar Var. In the
latter case, the #'bar Var gets the metadata directly.

On Thu, Aug 27, 2015 at 10:46 AM, Atamert Ölçgen  wrote:

> Got it, thanks.
>
> I think you still need to prepend ^'s to the metadata.
>
> On Thu, Aug 27, 2015 at 8:40 PM, Howard Lewis Ship 
> wrote:
>
>> That's misleading.  In the case of convention function names, (index,
>> show, create), there's default :route metadata that is used automatically
>> ... the docstrings are merely supplying a reminder.
>>
>> This is described in the "Getting Started" page:
>> https://portal.aviso.io/#/document/open-source/rook/Current/getting-started.html
>>
>> If you look at the increment endpoint function, which is not a convention
>> name, it has explicit :route metadata.
>>
>> I'll update the example to make this much more clear.
>>
>>
>> On Tue, Aug 25, 2015 at 7:43 AM, Atamert Ölçgen  wrote:
>>
>>> Hi Howard,
>>>
>>> In the example application it seems the routing information is encoded
>>> in the beginning of the docstring and not the actual metadata. Is there an
>>> option to put this info in the metadata of the var?
>>>
>>> On Mon, Aug 24, 2015 at 6:31 PM, Howard Lewis Ship 
>>> wrote:
>>>
 Rook is a set of middleware and handlers to enable metadata-based
 routing for Ring web applications.

 The intention is to expose a Clojure namespace as a web service
 resource; there’s a default mapping of HTTP verbs and paths to function
 names; these can be extended or overridden by metadata on the functions in
 the namespace.

 The end result is that a compliant web service resource can be created
 in very little code.

 Rook also supports Swagger 2.0: a detailed JSON description of your web
 service is generated directly from the functions and metadata.

 Recent changes:

 * Described more of the APIs using Prismatic Schema
 * Added ability to reuse the argument resolution logic outside of
 endpoint functions
 * Many improvements to the Swagger 2.0 description support

 https://github.com/AvisoNovate/rook

 --
 Howard M. Lewis Ship

 Looking for Clojure engagements: coding, architecture, mentoring & more!

 Creator of Apache Tapestry

 (971) 678-5210
 http://howardlewisship.com
 @hlship

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

>>>
>>>
>>>
>>> --
>>> Kind Regards,
>>> Atamert Ölçgen
>>>
>>> ◻◼◻
>>> ◻◻◼
>>> ◼◼◼
>>>
>>> www.muhuk.com
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Starting with WalMart Labs on Sep 28th!
>>
>> Creator of Apache Tapestry
>>
>> (971) 678-5210
>> http://howardlewisship.com
>> @hlship
>>
>> --
>> 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
>>

Re: Manifold questions: Creating sinks/sources

[Zach Tellman]

Hi Atamert,

For future reference, posting these questions 
to https://groups.google.com/forum/#!forum/aleph-lib will ensure I'll see 
them sooner.  

The `source-only` method is just a way to make sure that the chance for 
confusion is minimized, it doesn't prevent the underlying object from being 
used normally.  As for your scenario, I'm not sure I completely understand. 
 In a standard stream, the flow of data is:

[ sink -> source ]

So if you `put!` something into the sink, you can `take!` it from the 
source.  If you use `source-only` and connect that to some other sink, then 
the flow of data will be

[ sink -> source ] -> sink

So the source is only connected to one sink, not two.  Maybe I'm 
misunderstanding you, though.

Zach

On Thursday, August 27, 2015 at 4:13:35 AM UTC-7, Atamert Ölçgen wrote:
>
> Hi,
>
> AFAIK the only way to create (just) a source (or sink) is:
>
> (def my-source (s/source-only (s/stream ...)))
>
> This results in creating a stream and then wrapping it with a SourceProxy. 
> We don't keep a reference to the stream and the SourceProxy doesn't allow 
> taking.
>
> But if I'm not missing something since SourceProxy keeps a reference of 
> the original stream, there is a sink nobody is using there.
>
> If I create a sink separately and connect my-source to it, now 
> my-source would be connected to two sinks.
>
> My questions are:
>
> 1. Is there another method for creating only sinks or sources?
> 2. Should the extra/unused source/sink I mentioned above cause concern?
>
> PS: I'm not talking about a scenario where we're creating thousands 
> streams and connecting them all like there's no tomorrow.
>
>
> -- 
> Kind Regards,
> Atamert Ölçgen
>
> ◻◼◻
> ◻◻◼
> ◼◼◼
>
> www.muhuk.com
>

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

Re: Deploying Lein Template to Clojars

[James Reeves]

The "org.clojars.username/project" naming scheme is generally for your own
projects, or your own forks, that you're not publicising for general use.
For instance, perhaps you have a fork of Compojure, and decide to name it
"org.clojars.whamlet/compojure".

For Leiningen templates you should use the "template-name/lein-template"
scheme, e.g. "foobar/lein-template" would create a Leiningen template you
could use with "lein new foobar ..."

- James

On 27 August 2015 at 16:29, Matthew Molloy  wrote:

> According to the current documentation I create a leiningen plugin using
> the pattern
>
> (defproject your-template-name/lein-template "0.1.0-SNAPSHOT"
>
> however the clojars tutorial indicates that projects should be named as
>
> (defproject org.clojars.whamtet/too-hot "1.0.0"
>
> where whamtet is my clojars username.  How then do I deploy a leiningen
> template to clojars?
>
> --
> 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: Manifold questions: Creating sinks/sources

[Atamert Ölçgen]

On Thu, Aug 27, 2015 at 10:51 PM, Zach Tellman  wrote:

> Hi Atamert,
>
>
Hi Zach,


> For future reference, posting these questions to
> https://groups.google.com/forum/#!forum/aleph-lib will ensure I'll see
> them sooner.
>

I've subscribed. Thanks.



>
> The `source-only` method is just a way to make sure that the chance for
> confusion is minimized, it doesn't prevent the underlying object from being
> used normally.  As for your scenario, I'm not sure I completely
> understand.  In a standard stream, the flow of data is:
>
> [ sink -> source ]
>
> So if you `put!` something into the sink, you can `take!` it from the
> source.  If you use `source-only` and connect that to some other sink, then
> the flow of data will be
>
> [ sink -> source ] -> sink
>
> So the source is only connected to one sink, not two.  Maybe I'm
> misunderstanding you, though.
>

I have initially written it right. I was looking through the docs and the
source at the same time and I got confused. Then I replaced source with
sink and vice versa. So if you are misunderstanding, you are understanding.
:)

Let me try again. If we have:

(def my-sink (s/sink-only (s/stream ...)))
(def my-source (s/source-only (s/stream ...)))
(s/connect my-source my-sink)   ;; BTW this got me confused, I thought flow
was like my-source -> my-sink

After I have written the comment above, and playing with this code in the
REPL, I have realized the flow IS from source to sink.

I think I am un-confused now, and it all makes sense. I have a producer
side and a consumer side. Instead of repeating a function call, I want to
connect these two components using a stream. I thought I'd need half a
stream here and half a stream there. But now I realize I need two whole
streams, connect them, put! on one side, take! on the other. I hope it
makes sense. Sorry for the noise.




>
> Zach
>
> On Thursday, August 27, 2015 at 4:13:35 AM UTC-7, Atamert Ölçgen wrote:
>>
>> Hi,
>>
>> AFAIK the only way to create (just) a source (or sink) is:
>>
>> (def my-source (s/source-only (s/stream ...)))
>>
>> This results in creating a stream and then wrapping it with a
>> SourceProxy. We don't keep a reference to the stream and
>> the SourceProxy doesn't allow taking.
>>
>> But if I'm not missing something since SourceProxy keeps a reference of
>> the original stream, there is a sink nobody is using there.
>>
>> If I create a sink separately and connect my-source to it, now
>> my-source would be connected to two sinks.
>>
>> My questions are:
>>
>> 1. Is there another method for creating only sinks or sources?
>> 2. Should the extra/unused source/sink I mentioned above cause concern?
>>
>> PS: I'm not talking about a scenario where we're creating thousands
>> streams and connecting them all like there's no tomorrow.
>>
>>
>> --
>> Kind Regards,
>> Atamert Ölçgen
>>
>> ◻◼◻
>> ◻◻◼
>> ◼◼◼
>>
>> www.muhuk.com
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Kind Regards,
Atamert Ölçgen

◻◼◻
◻◻◼
◼◼◼

www.muhuk.com

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

Re: Deploying Lein Template to Clojars

[Matthew Molloy]

Great,

I was just typing the wrong password!

On Friday, August 28, 2015 at 3:51:26 AM UTC+8, James Reeves wrote:
>
> The "org.clojars.username/project" naming scheme is generally for your own 
> projects, or your own forks, that you're not publicising for general use. 
> For instance, perhaps you have a fork of Compojure, and decide to name it 
> "org.clojars.whamlet/compojure".
>
> For Leiningen templates you should use the "template-name/lein-template" 
> scheme, e.g. "foobar/lein-template" would create a Leiningen template you 
> could use with "lein new foobar ..."
>
> - James
>
> On 27 August 2015 at 16:29, Matthew Molloy 
> > wrote:
>
>> According to the current documentation I create a leiningen plugin using 
>> the pattern
>>
>> (defproject your-template-name/lein-template "0.1.0-SNAPSHOT"
>>
>> however the clojars tutorial indicates that projects should be named as 
>>
>> (defproject org.clojars.whamtet/too-hot "1.0.0"
>>
>> where whamtet is my clojars username.  How then do I deploy a leiningen 
>> template to clojars?
>>
>> -- 
>> 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.

Re: Ratio implementation questions

[waffletower]

A workaround for integer types is totally trivial:

(defn my-numerator [x]
  (if (ratio? x)
(numerator x)
x)
  )

(defn my-denominator [x]
  (if (ratio? x)
(denominator x)
1)
  )

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